Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Sebastian Pipping]

On 04/01/10 02:44, Mike Frysinger wrote:
> the rest of your gentoo-dev vs gentoo-core logic has been addressed by 
> Brian/Jorge -- this is the internet, you have no privacy, get over it.

privacy is not black and white.  i'm aware there's no leak-free zone.
i have put my point clear before, if that's where we stay - be it.



sebastian

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Mike Frysinger]

On Wednesday 31 March 2010 19:49:15 Sebastian Pipping wrote:
> On 04/01/10 01:09, Mike Frysinger wrote:
> > no one is forcing you to, nor is anyone talking about having teams use
> > it.  if Gentoo developers themselves choose to, it's going to happen
> > irregardless of what Alec is proposing.
> 
> we are talking about public, shared work on gentoo - not about stuff
> people do in private.

not necessarily.  we're talking about Gentoo developers using Google features 
however they see fit.  not everything done via your g.o e-mail address is 
required to be Gentoo related, nor will it ever be.

if a Gentoo dev as part of a Gentoo project started requiring Google docs to 
collaborate, then we can address the missing needs at that time if people feel 
that the Google requirement is "restrictive".

the rest of your gentoo-dev vs gentoo-core logic has been addressed by 
Brian/Jorge -- this is the internet, you have no privacy, get over it.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31-03-2010 23:49, Sebastian Pipping wrote:
> On 04/01/10 01:09, Mike Frysinger wrote:
>> your logic does not lead to the statement that gentoo-core is the 
>> appropriate 
>> place.
> 
> point takes, it's not the non-technical nature - i should put it
> clearer: it's the fact that everyone on the net will be able to read
> what anyone said on google in this thread.  any one of us may change his
> mind on that but the internet won't.
> does that make it clear now why that thread belongs to gentoo-core to me?

Nothing we write in an email is private from the moment it leaves our
mail client and is processed in a mail server. I understand your point,
but you should be aware that in the past mails sent to the core ml have
been leaked. It shouldn't have happened, but it did. So you better be
prepared to have them exposed to the world.
In any case, the point in using the core ml is to discuss sensitive and
or security related issues, get feedback from the developer community
before starting a discussion in the dev ml and or inform developers
about very specific issues like job offers. It's also important to
remember that we have a policy of doing Gentoo development through open
discussions. Therefore, this thread should have been started in the
project ml.

> sebastian

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLs+gRAAoJEC8ZTXQF1qEPZ2oP/3QXNexRdn50znBPBXISsLIz
5WZ0y03rpZZJh9bZi5ybYouU+Wvjf3d47x9PquBjbOTRD6HxGeYWlkNWTvqV35eP
MpCTOxm5SLWeNVCTewcL24zXJSrR0nlc7Dw6jxTUl9feBfRAxKTDYTTJQ0uWTir0
bIIged4g7F/t6L0mZx4a3F4IS5mU0P46d/nm/CYcR64rGzfi5eEGpbtx9P6LEApk
Ali5KUKcJNUisp928XA/azJ3V5LcUhKUaSNqyrL/bApF2Arfbnw7uT+LjMpWeU1e
yC5bCFX01cxb4rKqW67GOkKCA7OAjsXn2Lj2D5wUj097mh3BpG/IuJVcnUPFlsbK
Pgn3iH4uh52n9k2Ca0dLhxuxG7FGxFIortgYOt/qvJITSWCoq/ejY7A11F04f0/w
9/UXYIsNU5hrHZOs0gbNCZggweWjyTenGluwEuksTXzEbz85omIv4OYgrkn4WYCc
gWJo/hyu6gqgZIbTXvICDBL9LKN9YFIZsC5aT0NNP8NMIgwNAsAq39+KXLpnm8xR
01uG7utz+t+dvxRyA+qZUWKlkALfHhaKEVYRHLfMXLBRj71zSWfQOEqkwJM4SoDN
IQ7G20LA1Ccu3glIAqmX1yj6Nv/2rZv+cm7gKp9i+oC4Yll34i1PAYp9mYxXuMhM
gTb+YVR0vjoaMnAGe2u/
=X2Go
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Brian Harring]

On Thu, Apr 01, 2010 at 01:49:15AM +0200, Sebastian Pipping wrote:
> point takes, it's not the non-technical nature - i should put it
> clearer: it's the fact that everyone on the net will be able to read
> what anyone said on google in this thread.  any one of us may change his
> mind on that but the internet won't.

Welcome to the internet.  Things get archived, for example that 
crappy emo poem you posted after a bad breakup a decade ago is ready 
and waiting to haunt you via the wayback machine.


> does that make it clear now why that thread belongs to gentoo-core to me?

You're invalidly assuming that people don't keep mail archives.  For 
reference, I still have my archives for all of -core, including every 
dumb ass thing people said on that ml.


Either way, it's not really a justification to go closed discussion, 
more importantly this thread is well past being relevant to -dev 
(it's not technical) so take it to -project please.

Thanks-
~harring


pgpoS1JehqvKL.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Sebastian Pipping]

On 04/01/10 01:09, Mike Frysinger wrote:
> no one is forcing you to, nor is anyone talking about having teams use it.  
> if 
> Gentoo developers themselves choose to, it's going to happen irregardless of 
> what Alec is proposing.

we are talking about public, shared work on gentoo - not about stuff
people do in private.


> your logic does not lead to the statement that gentoo-core is the appropriate 
> place.

point takes, it's not the non-technical nature - i should put it
clearer: it's the fact that everyone on the net will be able to read
what anyone said on google in this thread.  any one of us may change his
mind on that but the internet won't.
does that make it clear now why that thread belongs to gentoo-core to me?


> a bit ironic you espouse using open source software on fully controlled 
> systems in one half while suggesting people use the closed gentoo-core 
> mailing 
> list in another ...

not every kind of open and closed are in contrast.  i don't see any
irony here.  the FSF is doing PR strategy stuff behind closed doors too,
what's the problem?



sebastian

Re: [gentoo-dev] List of User projects

[René 'Necoro' Neumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.03.2010 01:47, schrieb Joshua Saddler:
> 'Specially since they so often go defunct after a very short time -- I'm 
> thinking of all the Portage frontends in particular.

Don't know what you are talking about :) ... Portato is now in its
fourth year -- porthole is even older.

Though I admit, that there is some kind of "functionality-oscillation".
But if you ever tried to program against an undocumented API, with
functionality that often changes in subtle ways, you'll know why ^^.

- - René
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuz1pcACgkQ4UOg/zhYFuBOUQCcCHrH9r/m5Hh6WNyq+fjFPQC+
Rw8An0QTv0S09N/Jpqg7cNgAjF03CKye
=mA/r
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Mike Frysinger]

On Wednesday 31 March 2010 17:33:17 Sebastian Pipping wrote:
> On 03/31/10 23:20, Mike Frysinger wrote:
> > On Wednesday 31 March 2010 16:28:15 Sebastian Pipping wrote:
> >> To be very clear: Please take my vote against increasing dependencies on
> >> Google.
> > 
> > so dont use it
> > 
> >> On a side note: This is not a technical discussion only.
> >> As such please use gentoo-core for this next time.  Thanks.
> > 
> > incorrect ... it should either be gentoo-dev or gentoo-project.  there is
> > no need for use of the closed gentoo-core list.
> 
> did you even read all of my mail?

take it down a notch

> i cannot "not use it" - that's my point.  i'll be forced to, forced in
> or forced out.

no one is forcing you to, nor is anyone talking about having teams use it.  if 
Gentoo developers themselves choose to, it's going to happen irregardless of 
what Alec is proposing.

> it's nothing for gentoo-dev as it's not purely technical.
> can it be more obvious?

your logic does not lead to the statement that gentoo-core is the appropriate 
place.  as i already suggested, gentoo-project is an alternative to gentoo-dev 
for non-technical issues.  as has been said many times in the past,  gentoo-
core should not be thought of as the "non-technical gentoo-dev alternative".

a bit ironic you espouse using open source software on fully controlled 
systems in one half while suggesting people use the closed gentoo-core mailing 
list in another ...
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Sebastian Pipping]

On 03/31/10 23:20, Mike Frysinger wrote:
> On Wednesday 31 March 2010 16:28:15 Sebastian Pipping wrote:
>> To be very clear: Please take my vote against increasing dependencies on
>> Google.
> 
> so dont use it
> 
>> On a side note: This is not a technical discussion only.
>> As such please use gentoo-core for this next time.  Thanks.
> 
> incorrect ... it should either be gentoo-dev or gentoo-project.  there is no 
> need for use of the closed gentoo-core list.
> -mike

did you even read all of my mail?


i cannot "not use it" - that's my point.  i'll be forced to, forced in
or forced out.

it's nothing for gentoo-dev as it's not purely technical.
can it be more obvious?



sebastian

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Joe Peterson]

On 03/31/2010 02:28 PM, Sebastian Pipping wrote:
> I am worried that if people start using say Google Docs for
> collaborating on Gentoo content, everyone else is forced to use Google
> Docs to participate.

Gentoo could set policies that such shared resources should not be done
via google calender, or if it is, then the calender is exported to
everyone (or piped to another ical type service where everyone can
interact).

I'm mainly interested in the ability to use the gmail interface, which
is transparent to anyone not using it.  It's just what the person who
decides to use it sees.  Just as now you can forward your incoming mail
to any server you want anyway.

-Joe

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Zac Medico]

On 03/31/2010 02:16 PM, Sebastian Pipping wrote:
> On 03/31/10 23:05, Zac Medico wrote:
>> Yeah, but the "same slot" thing is a little ambiguous since the
>> given atom could possibly match multiple slots that include the one
>> whose postinst is currently running. So, I'd make has_version
>> generate a QA warning if has_version is called there and the given
>> atom only matches the one whose postinst is currently running.
> 
> Can you make a bug for it?

Sure, here it it is:

  http://bugs.gentoo.org/show_bug.cgi?id=312515
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Joe Peterson]

On 03/31/2010 01:40 PM, Mike Frysinger wrote:
>> Those, like me, who have several google apps accounts (I have a personal
>> business one, a personal one, and a work one) can keep accounts separate
>> this way.  Also, since it's the "gentoo.org" google apps account, the
>> email address looks the same as your gentoo address (rather than
>> foo-gen...@gmail.com, etc.).
>
> this too has been doable forever.  gmail has had a feature where you can set 
> the From: address to any e-maill address once you "verified" it was your e-
> mail address.

Well, that's slightly different.  I use that too, but it means you need
to have all your mail coming into one account.  Yes, you can send from
different senders, but if you want to totally separate your email to
your different addresses into different boxes, this won't work.  Even
labeling is not foolproof, since emails that are to lists or to bcc'd
addresses (i.e. do not contain your address in the header) cannot be
labeled accordingly.

> i'm not against the idea, i was just wondering what the point was

Cool.  :)

-Joe

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Mike Frysinger]

On Wednesday 31 March 2010 16:28:15 Sebastian Pipping wrote:
> To be very clear: Please take my vote against increasing dependencies on
> Google.

so dont use it

> On a side note: This is not a technical discussion only.
> As such please use gentoo-core for this next time.  Thanks.

incorrect ... it should either be gentoo-dev or gentoo-project.  there is no 
need for use of the closed gentoo-core list.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Sebastian Pipping]

On 03/31/10 23:05, Zac Medico wrote:
> Yeah, but the "same slot" thing is a little ambiguous since the
> given atom could possibly match multiple slots that include the one
> whose postinst is currently running. So, I'd make has_version
> generate a QA warning if has_version is called there and the given
> atom only matches the one whose postinst is currently running.

Can you make a bug for it?



Sebastian

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Zac Medico]

On 03/31/2010 01:52 PM, Sebastian Pipping wrote:
> On 03/31/10 22:42, Zac Medico wrote:
>> Well, it works fine when not called for the same $CATEGORY/$PN, and
>> even for the same $CATEGORY/$PN it works fine for other slots it
>> they happen to be installed.
> 
> Good point.  So the check would be:
> 
> Deny calling has_version if all of:
> - in postinst stage
> - same category and package
> - same slot
> 
> How about that?

Yeah, but the "same slot" thing is a little ambiguous since the
given atom could possibly match multiple slots that include the one
whose postinst is currently running. So, I'd make has_version
generate a QA warning if has_version is called there and the given
atom only matches the one whose postinst is currently running.
-- 
Thanks,
Zac

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Sebastian Pipping]

On 03/31/10 22:42, Zac Medico wrote:
> Well, it works fine when not called for the same $CATEGORY/$PN, and
> even for the same $CATEGORY/$PN it works fine for other slots it
> they happen to be installed.

Good point.  So the check would be:

Deny calling has_version if all of:
- in postinst stage
- same category and package
- same slot

How about that?



Sebastian

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Zac Medico]

On 03/31/2010 01:37 PM, Sebastian Pipping wrote:
> On 03/31/10 22:31, Zac Medico wrote:
>> For those who may not know, has_version can be called in pkg_preinst
>> to find the previous version, and the result can be stored in a
>> variable for us in pkg_postinst.
> 
> So has_version takes the version just installed into account when called
> from pkg_postinst?  If so wouldn't be banning it's usage from that stage
> a good idea?  I just checked the code, no such check, yet.

Well, it works fine when not called for the same $CATEGORY/$PN, and
even for the same $CATEGORY/$PN it works fine for other slots it
they happen to be installed.
-- 
Thanks,
Zac

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Sebastian Pipping]

On 03/31/10 22:31, Zac Medico wrote:
> For those who may not know, has_version can be called in pkg_preinst
> to find the previous version, and the result can be stored in a
> variable for us in pkg_postinst.

So has_version takes the version just installed into account when called
from pkg_postinst?  If so wouldn't be banning it's usage from that stage
a good idea?  I just checked the code, no such check, yet.



Sebastian

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Ciaran McCreesh]

On Wed, 31 Mar 2010 22:29:50 +0200
Sebastian Pipping  wrote:
> On 03/31/10 22:19, Ciaran McCreesh wrote:
> >> Is there some kind of evilness in this usage of has_version that I
> >> am not aware of?
> > 
> > Unfortunately, yes.
> > 
> > Historically, has_version in pkg_postinst would return results based
> > upon the version that *was* installed.
> 
> What's status quo?  What did it switch to?

Now you really need to use REPLACING_VERSIONS to do it cleanly, but
that's only in EAPI 4, which still isn't implemented in Portage. As a
hack, you can instead do the has_version check in pkg_preinst and use
environment variable saving to get the result in pkg_postinst. It is
not exactly pretty.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Sebastian Pipping]

On 03/31/10 22:19, Ciaran McCreesh wrote:
>> Is there some kind of evilness in this usage of has_version that I am
>> not aware of?
> 
> Unfortunately, yes.
> 
> Historically, has_version in pkg_postinst would return results based
> upon the version that *was* installed.

What's status quo?  What did it switch to?



Sebastian

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/31/2010 01:19 PM, Ciaran McCreesh wrote:
> On Wed, 31 Mar 2010 22:08:40 +0200
> Sebastian Pipping  wrote:
>> Is there some kind of evilness in this usage of has_version that I am
>> not aware of?
> 
> Unfortunately, yes.
> 
> Historically, has_version in pkg_postinst would return results based
> upon the version that *was* installed. This feature was widely used to
> display context-aware post-install messages, and there were examples of
> it in the documentation. Portage then silently changed this behaviour,
> without an EAPI bump and without changing the documentation, breaking
> all those packages in the process. The resulting mess discouraged many
> people from bothering with that kind of thing...

For those who may not know, has_version can be called in pkg_preinst
to find the previous version, and the result can be stored in a
variable for us in pkg_postinst.

We also have plans for a REPLACING_VERSIONS variable which would be
useful in similar cases:

  http://bugs.gentoo.org/show_bug.cgi?id=273646
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkuzsRcACgkQ/ejvha5XGaOnYQCg1+X8SnVBKqG1E+BdzjAm49lH
JYcAn3SG6fS+PJczSOMFxp1JeO6X38gK
=9MVB
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Sebastian Pipping]

Hello,


On 03/31/10 07:28, Alec Warner wrote:
> Currently a number of developers have engaged Google Apps Team Edition
> for gentoo.org.  However Team Edition does not come with gmail and a
> subset of Team Edition users would like to host their gentoo.org mail
> on gmail.
> Activating Standard Edition is free and likely requires minimal
> configuration on dev.gentoo.org to setup.  Standard Edition comes with
> Google Docs, Google Calendar, Google Mail, Google Sites, Google Video,
> and probably a bunch of other stuff we could turn on.

I am worried that if people start using say Google Docs for
collaborating on Gentoo content, everyone else is forced to use Google
Docs to participate.

While I do appreciate projects like TechTalks and Summer of Code I
personally do not trust Google with my data.  Also, most of these
services are not Free Software -- I don't trust non-free software.
If they are let's run our instance, not theirs.
if they aren't lets go for something else.

Btw if we really need a shared web-calendar let's make a project for
that and get it done.  Ironically, it may even fit for GSOC.


> This service would be opt-in (only devs that want an account get one).
>  Infra should continue to offer standard mail services on
> smtp.gentoo.org.

As mentioned before: Opt-in is an illusion from the point on, where
people need the same piece of software to collaborate.  May not apply to
some (Google Mail) but sure does to others.


> This thread is primarily engaged in gauging interest in such a setup.
> Please reply if you are interested (or go vote on the bug.)

To be very clear: Please take my vote against increasing dependencies on
Google.

On a side note: This is not a technical discussion only.
As such please use gentoo-core for this next time.  Thanks.



Sebastian

Re: [gentoo-dev] Unnecessary logs: has_version to the rescue?

[Ciaran McCreesh]

On Wed, 31 Mar 2010 22:08:40 +0200
Sebastian Pipping  wrote:
> Is there some kind of evilness in this usage of has_version that I am
> not aware of?

Unfortunately, yes.

Historically, has_version in pkg_postinst would return results based
upon the version that *was* installed. This feature was widely used to
display context-aware post-install messages, and there were examples of
it in the documentation. Portage then silently changed this behaviour,
without an EAPI bump and without changing the documentation, breaking
all those packages in the process. The resulting mess discouraged many
people from bothering with that kind of thing...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Unnecessary logs: has_version to the rescue?

[Sebastian Pipping]

Hello!


When browsing through emerge logs (using elogv) I often come across
stuff that doesn't affect me.  Two examples:

  x11-base/xorg-server-1.7.6 warns:
You must rebuild all drivers if upgrading from xorg-server 1.6
or earlier, because the ABI changed.

  dev-db/mysql-5.1.45-r1 logs:
You might want to run: "emerge --config =dev-db/mysql-1.45-r1"
if this is a new install.

I had xorg 1.7.x running before so that's pure noise in my case.
Same with mysql - I had it installed before.


So I am wondering:  Why aren't people using has_version to catch such
cases and omit things that we have seen before or that don't affect us?

  has_version -- "Returns 1 if the system has the requested
  version of a certain package. For instance
  has_version >=sys-libs/glibc-2.3.0."


Is it lazyness?  Is it unawareness?  Is there some kind of evilness in
this usage of has_version that I am not aware of?
Do we need a better framework for this?  If so what could it look like?


What do you think?



Sebastian

Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Ciaran McCreesh]

On Wed, 31 Mar 2010 12:46:26 -0700
Brian Harring  wrote:
> Actual name I don't hugely care about, I'm more interested in
> ensuring we don't rule out doing use cycle breaking via a bad design
> decision.

Cycle breaking requires explicit instructions from the ebuilds in
question (many of which are system things, which further complicates it)
along with support from Portage, so it's a distant future, lot of work
thing.

Since we need pkg_pretend to cover all the things that aren't use flag
related anyway, it makes sense to just go with that rather than
delaying things even further. When in the distant future Portage
becomes able to deal with cycle breaking, ebuilds can be converted to
use something like VALID_USE when they're also updated to export
information on which of their flags can safely be toggled.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

On Wed, Mar 31, 2010 at 08:49:26PM +0300, Alex Alexander wrote:
> VALID_USE does look a bit strange.
> 
> how about
>   IUSE_RULES
> or
>   IUSE_RESTRICTIOMS
> or
>   RUSE
> ?
It's not really IUSE; the constraints it specifies applies to USE 
only.

USE_STATES, VALID_USES, VALID_USE_STATES, ALLOWED_USE, etc.

Actual name I don't hugely care about, I'm more interested in ensuring 
we don't rule out doing use cycle breaking via a bad design decision.

~harring


pgpRJhmQQOx8l.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Mike Frysinger]

On Wednesday 31 March 2010 12:11:30 Joe Peterson wrote:
> It's a "Google Apps" account, not just a Gmail account.  You cannot have
> more than one gmail account open in your browser at one time - the
> cookies are not separate.  Whereas you *can* have your gmail and all of
> your google apps accounts (in different domains) open at one time.

OK

> Those, like me, who have several google apps accounts (I have a personal
> business one, a personal one, and a work one) can keep accounts separate
> this way.  Also, since it's the "gentoo.org" google apps account, the
> email address looks the same as your gentoo address (rather than
> foo-gen...@gmail.com, etc.).

this too has been doable forever.  gmail has had a feature where you can set 
the From: address to any e-maill address once you "verified" it was your e-
mail address.

> What Alec was asking is why not turn on the feature.  It just enables
> more functionality for those who want to use it.  It just requires we
> verify that we "own" gentoo.org.

i'm not against the idea, i was just wondering what the point was
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Alex Alexander]

On Wed, Mar 31, 2010 at 02:20:35AM -0700, Brian Harring wrote:
> Hola all-
> 
> For those who aren't familiar, pkg_pretend is in EAPI4- the main usage 
> of it is will be use dep checking- this email is specifically 
> regarding an alternative to it that *should* be superior for that use 
> case, but I'm looking for feedback.
> 
> Basically, we use the original VALID_USE proposal from way back in 
> '05- if you're familiar w/ MYOPTIONS, they're reasonably similar.
> 
> Roughly, VALID_USE is a list of constraints stating what the allowed 
> use flag combinations are for this pkg.  If you think of normal 
> depdencies (I must have openssl and python merged prior), it's the 
> same machinery.
> 
> [snip]
> 
> Comments desired; assuming no significant blowback, I'll be pushing 
> this to the council level since eapi4 is annoying feature locked right 
> now.

I like the whole concept, it is clean and straightforward.

Also, notifying the user of any possible issues and breaking so he can
make the actual decision sounds far better than making the choice for him.

VALID_USE does look a bit strange.

how about
IUSE_RULES
or
IUSE_RESTRICTIOMS
or
RUSE
?

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpYxpiVZQG04.pgp
Description: PGP signature

[gentoo-dev] Lastrite: 2 unmaintained xfce-extra plugins

[Samuli Suominen]

# Samuli Suominen  (31 Mar 2010)
# Unported to new xfce-base/exo-0.5 API and no activity
# on upstream git. Also using HAL which is deprecated.
# Masked for removal in 30 days.
xfce-extra/xfce4-volstatus-icon

# Samuli Suominen  (31 Mar 2010)
# Doesn't compile with libindicator-0.3.6, and no activity
# on http://hg.foresightlinux.org/xfce/xfce4-indicator-plugin/
# Masked for removal in 30 days
xfce-extra/xfce4-indicator-plugin

[gentoo-dev] GSoC

[Serheo]

Google summer of code test message. Sorry for interuption.
-- 
..
С уважением, Сергей Александрович.

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Joe Peterson]

On 03/31/2010 02:18 AM, Mike Frysinger wrote:
> i'm already using ~/.forward which means mail still goes to mail.g.o and that 
> server takes care of forwarding it to my private gmail.com account.  then my 
> mail client fetches it from gmail.com via the normal pop/imap methods.  there 
> is no need to share passwords between gmail.com and g.o.
> 
> so i dont see what advantage this process ive been using for years has over 
> this method.  they look pretty much equivalent.
> -mike

Hey Mike,

You are right that what you are doing gives you the ability to use gmail
for this.  However, there's one key thing that turning on Standard
Edition does:

It's a "Google Apps" account, not just a Gmail account.  You cannot have
more than one gmail account open in your browser at one time - the
cookies are not separate.  Whereas you *can* have your gmail and all of
your google apps accounts (in different domains) open at one time.

Those, like me, who have several google apps accounts (I have a personal
business one, a personal one, and a work one) can keep accounts separate
this way.  Also, since it's the "gentoo.org" google apps account, the
email address looks the same as your gentoo address (rather than
foo-gen...@gmail.com, etc.).

What Alec was asking is why not turn on the feature.  It just enables
more functionality for those who want to use it.  It just requires we
verify that we "own" gentoo.org.

-Joe

Re: [gentoo-dev] Re: pkg_pretend USE validation and VALID_USE alternative

[Paweł Hajdan, Jr.]

On 3/31/10 1:04 PM, Ulrich Mueller wrote:
> We already have enough issues with circular dependencies, and I'm
> sceptical about adding additional failures on USE flag conflicts.
> Display a warning, but don't error out.

How about only allowing local USE flags to conflict? This also seems to
be the most common use case.

Anyway, the earlier the user can react to USE flags conflict, the better.

Paweł Hajdan jr



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Ben de Groot]

On 31 March 2010 07:28, Alec Warner  wrote:
> This thread is primarily engaged in gauging interest in such a setup.
> Please reply if you are interested (or go vote on the bug.)

I am definitely interested.

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

[Piotr Jaroszyński]

>> | Occasionally, ebuilds will have conflicting USE flags for
>> | functionality. Checking for them and returning an error is not a
>> | viable solution. Instead, you must pick one of the USE flags in
>> | conflict to favour.
>>
>> [1] 
>
> I honestly consider the ebuild silently making decisions on the user's
> behalf *worse*.  Consider if openoffice silently made decisions like
> that- 4 hours later it'll wind up choosing the option you didn't
> really want and you'll be in a foul mood.

I'm pretty sure it says that because there was no way to fail early
before. And failing in the middle of 300 packages upgrade because some
useflags are in conflict wasn't reasonable.

-- 
Best Regards
Piotr Jaroszyński

[gentoo-dev] Re: pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

On Wed, Mar 31, 2010 at 01:04:39PM +0200, Ulrich Mueller wrote:
> We already have enough issues with circular dependencies, and I'm
> sceptical about adding additional failures on USE flag conflicts.
> Display a warning, but don't error out.

Solve the cyclical dependency via breaking the use cycle and doing two 
builds of the target instead.

It *does* work.  Now I'm reasonably sure I've since *broken* that 
support in pkgcore since stubbs/myself worked it out (resolver still 
supports it though), but that doesn't mean restoring it is hard.  

Frankly I'd rather see us support these things then have the PM bitch 
at the user or make guesses on the users behalf.

My 2 cents either way- mainly responding since you seem to be ignoring 
that as long as pkg_pretend isn't fricking used, we've got a way to 
break use induced cyclical deps automatically via the PM.

~harring


pgpgIeqLSwSLE.pgp
Description: PGP signature

[gentoo-dev] Re: pkg_pretend USE validation and VALID_USE alternative

[Ulrich Mueller]

> On Wed, 31 Mar 2010, Brian Harring wrote:

> Not just my proposal- council contradicted it via even letting 
> pkg_pretend into EAPI3 (now EAPI4):

> http://www.mail-archive.com/gentoo-coun...@lists.gentoo.org/msg00493.html

It says "displaying conflicting USE flags" which doesn't necessarily
imply that the ebuild should fail.

> I honestly consider the ebuild silently making decisions on the
> user's behalf *worse*.

Right, this is exactly what we should decide on, before talking about
possible implementations.

We already have enough issues with circular dependencies, and I'm
sceptical about adding additional failures on USE flag conflicts.
Display a warning, but don't error out.

Ulrich

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

Note I inadvertantly cross posted, I was intending on cc'ing 
coun...@gentoo.org.

As such one final cc to that ml to end this subthread while pulling 
this back to -dev.


On Wed, Mar 31, 2010 at 11:16:22PM +1300, Alistair Bush wrote:
> > Hola all-
> >  
> > Comments desired; assuming no significant blowback, I'll be pushing
> > this to the council level since eapi4 is annoying feature locked right
> 
> I think this solution is far better,  until someone smarter than me tells me 
> otherwise.
> 
> Don't know whether I like the VALID_USE var name,  so please at least think 
> about something a little better if you can ;).  ( I like green,  but not too 
> green if you know what I mean )
>
> Will we still have to define the use flags in IUSE?

Yes, although if folks have a better proposal that incorporates 
VALID_USE into IUSE I'm definitely open to it- the original proposal 
for VALID_USE tried to inline it into IUSE, but it got ugly (hence it 
mutating it this form).

The problem w/ trying to reuse IUSE is the following (sorry, I like 
lists of assertions)-

*) IUSE currently serves as a list of valid USE flags, just that.  No 
repeat specification of a flag (which means the dev in question is 
unlikely to typo a flag).

*) having a single specified list of valid use flags is the basis for 
doing validation of use flags used in all other metadata.  In other 
words, that list of valid use flags *really* needs to go out of it's 
way to make human error hard.

*) VALID_USE is a set of assertions on the allowed state of USE; IUSE 
is just a list of flags.  Intermixing the two in a way that is still 
readable is really ugly

*) given a library that has optional perl and python bindings 
(which can be toggled freely, they're standalone flags) I've nfc how 
one would sanely specify that w/in IUSE while adding VALID_USE 
semantics.  Possibly, you could include use conditionals into IUSE, 
and treat the () contents as assertions- but that makes adding xor in 
hard, is rather ugly/hard on the eyes, and violates the DRY (Don't 
Repeat Yourself) principle from above.

Definitely open to counterproposals that address those 
concerns however...


> I'm guessing we can't use IUSE to store this information because of the  
> whole 
> glep-55 thing.

glep-55 is unrelated to this as far as I can tell- if you think 
otherwise please clarify.

Thanks
~harring


pgp5qhvO5spL4.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

Note that while I inadvertantly cross posted (I was intending on 
cc'ing coun...@gentoo.org, not the ml), doubt they need to be cc'd 
further- my original attention was to effectively ensure they were 
paying aware of the details of this so that when I took it to them 
folk were informed.

CC'ing gentoo-council so folk following it there know it moved 
over to -dev.  Your discussion of devmanual relevance needs some -dev 
consensus anyways before the council should be deciding on it.

Also the cross posting is making betelgeuse cry anyways (and pissing 
off my procmail setup) ;)


On Wed, Mar 31, 2010 at 11:48:37AM +0200, Ulrich Mueller wrote:
> > On Wed, 31 Mar 2010, Brian Harring wrote:
> 
> > Roughly, VALID_USE is a list of constraints stating what the allowed
> > use flag combinations are for this pkg. If you think of normal
> > depdencies (I must have openssl and python merged prior), it's the
> > same machinery.
> 
> Maybe we should first discuss if we want to drop the following
> rule [1] which your proposal seems to contradict:

Not just my proposal- council contradicted it via even letting 
pkg_pretend into EAPI3 (now EAPI4):

http://www.mail-archive.com/gentoo-coun...@lists.gentoo.org/msg00493.html


> | Occasionally, ebuilds will have conflicting USE flags for
> | functionality. Checking for them and returning an error is not a
> | viable solution. Instead, you must pick one of the USE flags in
> | conflict to favour.
> 
> [1] 

I honestly consider the ebuild silently making decisions on the user's
behalf *worse*.  Consider if openoffice silently made decisions like 
that- 4 hours later it'll wind up choosing the option you didn't 
really want and you'll be in a foul mood.

Frankly is the devmanual even relevant on at this point beyond good 
practices btw?  Last I looked through it, there was a rather unhealthy 
mix of good policy that we follow, and policy that isn't relevant 
anymore- in need of some cleanup at the very least.


~harring


pgpovyLs16obS.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

[Ulrich Mueller]

> On Wed, 31 Mar 2010, Brian Harring wrote:

> Roughly, VALID_USE is a list of constraints stating what the allowed
> use flag combinations are for this pkg. If you think of normal
> depdencies (I must have openssl and python merged prior), it's the
> same machinery.

Maybe we should first discuss if we want to drop the following
rule [1] which your proposal seems to contradict:

| Occasionally, ebuilds will have conflicting USE flags for
| functionality. Checking for them and returning an error is not a
| viable solution. Instead, you must pick one of the USE flags in
| conflict to favour.

Ulrich

[1] 

[gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

Hola all-

For those who aren't familiar, pkg_pretend is in EAPI4- the main usage 
of it is will be use dep checking- this email is specifically 
regarding an alternative to it that *should* be superior for that use 
case, but I'm looking for feedback.

Basically, we use the original VALID_USE proposal from way back in 
'05- if you're familiar w/ MYOPTIONS, they're reasonably similar.

Roughly, VALID_USE is a list of constraints stating what the allowed 
use flag combinations are for this pkg.  If you think of normal 
depdencies (I must have openssl and python merged prior), it's the 
same machinery.

Examples:

# if build is set, python and openssl must be unset
VALID_USE="build? ( !python !openssl )"

# if mysql is set, sqlite must not be, and vice versa.
# note mysql/sqlite do *not* have to be set also.
VALID_USE="mysql? ( !sqlite ) !sqlite? ( mysql )"

# mysql or sqlite must be set; exclusive or.
VALID_USE="mysql? ( !sqlite ) !mysql ( sqlite )"

# alternative syntax, adding an xor group operator
# note xor isn't required- you can do the same thing
# via spelling it out, it's just a convenient thing to have.
VALID_USE="^^ ( mysql sqlite )"

# if gui is enabled, a widget set must be specified- can build
# multiple widget bindings
VALID_USE="X? ( || ( gtk qt motif ) )"


Note that like dependencies, these are assertions.  More importantly, 
they're also data rather then executable code.  Via it being data, up 
front GUI's can tell you exactly what conflicts arise, and what needs 
to be adjusted.

Doing it as executable, can, but it's iterative and reliant on the dev 
writing a clear message every time (rather then the UI tool getting 
it right once).  Clarifying iterative, consider

USE="build X"
w/ valid use states being-
VALID_USE="build? ( !X !python ) X? ( ^^ ( gtk qt ) ) gtk? ( ssl )"

The user first flips off build.  They rerun emerge- next they're told 
"you must choose gtk or qt, not both".  They change to USE="X gtk".  
Next they're told "you need ssl turned on if you want gtk".

At this point, the user goes and gets a beer because aparently Murphy 
hates them and it's going to be a long, long night.


There also is one major issue with relying on pkg_pretend 
(executable) for use state validation vs doing it as VALID_USE 
(data)- the package manager cannot know what states are valid thus 
limiting the things it can do.  Literally the pkg manager is screwed 
when it comes to use cycle breaking.  If the pkg manager doesn't know 
what states are valid, when it encounters a use cycle it doesn't know 
what intermediate builds it can do to break that cycle- literally if 
USE state validation is in pkg_pretend, the *user* will have to walk 
the PM through breaking the cycle instead of the PM figuring out the 
proper steps to break it.

Executive summary: if use validation is implemented via pkg_pretend,
1) it still has the iterative issue
2) it's harder for configuration tools to deal with (iterative issues 
above, plus the fact they get a blob of text they're stuck trying to 
parse)
3) it pretty much eliminates the possibility of doing use cycle 
breaking properly (which is already an issue, only going to get worse- 
hence why this was proposed in '04/'05 when we started playing w/ use 
deps in portage 3 at the time).


Comments desired; assuming no significant blowback, I'll be pushing 
this to the council level since eapi4 is annoying feature locked right 
now.

Thanks-
~harring


pgpcGvabzpipH.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

[Mike Frysinger]

On Wednesday 31 March 2010 02:24:24 Alec Warner wrote:
> On Tue, Mar 30, 2010 at 11:11 PM, Mike Frysinger wrote:
> > On Wednesday 31 March 2010 01:28:56 Alec Warner wrote:
> >> Currently a number of developers have engaged Google Apps Team Edition
> >> for gentoo.org.  However Team Edition does not come with gmail and a
> >> subset of Team Edition users would like to host their gentoo.org mail
> >> on gmail.
> >> Activating Standard Edition is free and likely requires minimal
> >> configuration on dev.gentoo.org to setup.  Standard Edition comes with
> >> Google Docs, Google Calendar, Google Mail, Google Sites, Google Video,
> >> and probably a bunch of other stuff we could turn on.
> > 
> > i dont really know anything about these Google things you refer to.
> >  could you provide URLs and/or some summary background ?
> 
> Well you know about calendar since you use it ;p
> 
> The corporate spiel is here.
> 
> http://www.google.com/apps/intl/en/group/index.html

yes, but i dont see what "Google Apps Team Edition" or "Standard Edition" gets 
me vs me simply going to gmail.com and creating a new account ... same for the 
calendar

> > personally, i just created a dedicated gmail account and set my dev.g.o
> > forward to that.  then i fetch the mail from gmail's pop interface.  how
> > do these offerings provide anything over that sort of setup ?
> 
> That requires giving gmail your pop password which not everyone likes.
>  In this setup you could use your d.g.o procmail to forward mail to
> something like 'google-hosted.mail.gentoo.org' which would stuff it in
> gentoo.org gmail account and you gentoo.org account could be your
> d.g.o password, or something different.

i'm already using ~/.forward which means mail still goes to mail.g.o and that 
server takes care of forwarding it to my private gmail.com account.  then my 
mail client fetches it from gmail.com via the normal pop/imap methods.  there 
is no need to share passwords between gmail.com and g.o.

so i dont see what advantage this process ive been using for years has over 
this method.  they look pretty much equivalent.
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: RFC: Google Apps Standard Edition @ gentoo.org

[Duncan]

Alec Warner posted on Tue, 30 Mar 2010 22:28:56 -0700 as excerpted:

> All content that is what I would term 'of value' to the community should
> be available anonymously; that is you should not need to sign up for a
> Google Account to be able to access documents in a read-only fashion. 
> Writing documents will require sign-in (similarly to how the calendar
> works in a previous thread.)

Thanks for taking care to verify and state that, this time. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman