Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Michał Górny
On Wed, 24 Aug 2011 13:03:44 +0200
Andreas K. Huettel dilfri...@gentoo.org wrote:

 Am Mittwoch 24 August 2011, 12:48:35 schrieb Patrick Lauer:
  
  If you sneakily add something to cron.daily by default you can get
  pretty nice coverage. But I guess anyone trying that in Gentooland
  will meet some rather unpleasant resistance :)
  
 
 Of course, we could place it in some blatantly obvious way into a
 default configuration, together with a big fat message what it does
 and how to quickly disable it. 
 
 We'd get better coverage in an opt-out system than in an opt-in
 system.

And a larger number of angry users which missed the warning and now
have to pay for additional GPRS transfer or so. And when people use
GPRS rarely, they usually don't think about random apps that use
the connection in background.

 (First idea- package is pulled in by a default-on useflag and
 installs itself into cron.daily. BEFORE it runs the first time it
 outputs said message and asks for permission to proceed (which cannot
 be done in the cron job obviously but we'd find a way).)

And what if it can't ask for that? Assuming you're talking about
'opt-out', I guess the fallback would be to 'yes'. We don't want to end
up like Windows, where you get AFK for five minutes and then discover
the system has rebooted.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


[gentoo-dev] Re: Gentoostats, SoC 2011

2011-08-25 Thread Nikos Chantziaras

On 08/24/2011 01:48 PM, Patrick Lauer wrote:

[...]
If you sneakily add something to cron.daily by default you can get
pretty nice coverage. But I guess anyone trying that in Gentooland will
meet some rather unpleasant resistance :)


emerge always asks me after a world update whether I want to auto clean 
packages with a yes/no prompt.  I wouldn't be bad if once a month or 
whatever it would ask me whether I want to upload my stats.  Gentoostats 
should probably become a runtime dep of Portage itself by default, but 
not used automatically.





Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Roy Bamford
On 2011.08.24 11:48, Patrick Lauer wrote:
[snip]
 
 If you sneakily add something to cron.daily by default you can get
 pretty nice coverage. But I guess anyone trying that in Gentooland
 will
 meet some rather unpleasant resistance :)
 
 
 
 

This app and if its opt in or opt out will set a precedence for any 
future apps that want automatic user feedback in Gentoo

It has to be opt-in as opt out would be a dangerous precendent to set.

I don't see any harm is a gentle reminder message from emerge, provided 
that the reminder can be turned off too, if the user really does not 
want to opt in. Thats no worse than being nagged about unread news.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpz8BkPEPndt.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Rich Freeman
On Thu, Aug 25, 2011 at 6:48 AM, Roy Bamford neddyseag...@gentoo.org wrote:
 It has to be opt-in as opt out would be a dangerous precendent to set.

 I don't see any harm is a gentle reminder message from emerge, provided
 that the reminder can be turned off too, if the user really does not
 want to opt in. Thats no worse than being nagged about unread news.

I tend to agree, the more I think about it.

The simplest solution (which doesn't require any portage mods/etc), is
to simply make this a package that installs the appropriate logic in
cron.daily, and we send out a news item encouraging users to install
it voluntarily.  If the user does nothing, they don't get the package.

If somebody can come up with really good reason that we should be more
aggressive in promoting it, then we can promote it more aggressively.
That /might/ go as far as a forced opt-in/out decision.  However, the
more I think about it the more I'm concerned with pure opt-out by
default.

The big issue with opt-out is privacy law - especially in Europe
(that's leaving aside just being up-front with users).  We'd end up
having to have EULAs or such and perhaps a number of other legal
controls, and I don't think that is a direction that we want to go in.
 I'm just not seeing the upside - better to just figure out good ways
to use data that is easy and safe to obtain first.

Earlier somebody suggested that this decision wasn't really in the
domain of the Council/Trustees.  I'm not sure I agree here - any kind
of opt-out data collection is something that has potential legal
ramifications as well as huge reputation concerns for the distro (the
software is distributed from Foundation-owned hardware utilizing a
Foundation-owned domain name and the data goes back to
Foundation-owned hardware - I'm sure any lawyer could make a case for
this).  Just because there isn't a policy written down somewhere
doesn't mean that we can't use common sense.  Devs certainly don't
need to run everything past the Council, but if you want to do
something high-profile post it on -dev, and if there is an uproar look
for an official second opinion before doing it.

Rich



Re: [gentoo-dev] Re: Gentoostats, SoC 2011

2011-08-25 Thread Markos Chandras
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 25/08/2011 11:42 ??, Nikos Chantziaras wrote:
 On 08/24/2011 01:48 PM, Patrick Lauer wrote:
 [...] If you sneakily add something to cron.daily by default you
 can get pretty nice coverage. But I guess anyone trying that in
 Gentooland will meet some rather unpleasant resistance :)
 
 emerge always asks me after a world update whether I want to auto
 clean packages with a yes/no prompt.  I wouldn't be bad if once a
 month or whatever it would ask me whether I want to upload my
 stats.  Gentoostats should probably become a runtime dep of Portage
 itself by default, but not used automatically.
 
 
I like your idea and people seem to like making things complicated.
Simple solution:

opt-in

How:
Display a warning after an emerge -u{DNav} world.
Let user disable this warning by using a special variable in make.conf

STATS_ENABLE=no.

By default, this variable will be yes on base/ profiles

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOVkNbAAoJEPqDWhW0r/LCWFEP+wSHLeGuqIGIV1OcHzlrgMJn
qBusQcvWb2SbP58G+3hndPUHWsnSIRDk2zws21wZH1DLaCr3Hyc5V9s8WM7HMWeX
WHgLVN71KDSmhREvz9fJWGA08rLJHa/Xs3XdNBUp5mMGsogPmwgEmNgSyfpKe6wC
nsBC6pk/R6kvAdlinyLp2uybBDI00GtiUSN3fyvvuoE3XMlVdyYLYTKTguVmJB4A
aR97bIR2otZlWTmSGMvr899vht35Mwoe0/UHDV2SJHtWk9zzIYzWHEW9mMUoWAAw
1/2bYAafE+rp0/MPTv0tJ8WtoB6NhpJBRZGa5MuQM0V8jQqbgweq1YBO4zO8VAO+
tn6/thWk+heSklzTR1Uom1F+pYMxJBY0nBQUQ6ppZLjOM43WTT5TmPkc/rYwEB3M
8FywLV+Mryax+nQesLkgMQLLKUSuQygy+4zxoCUHkY5DwB08C5dfYua/Y+nLbb0l
iCmCNpYSKUJF2cbHm6kDfOonsyfre//+JNvycxuz5J932XqFwkv7dM8ywSwP7Srw
FfWWspLfHxyoXSHlljwXj0UxfQcjNbg3MyUt8s0pSys9GlUzdSv1vx4xGgS8dtzA
zTSvTE1xO3fUzO1Au+KaSs0GC49BO7Gf1fWFdIhr8ZcJD82+jDaooompzPqFm0lB
XZQAVwslAMQbSaJAEfCY
=V+cS
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Gentoostats, SoC 2011

2011-08-25 Thread Patrick Nagel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 2011-08-25 20:43, Markos Chandras wrote:
 On 25/08/2011 11:42 ??, Nikos Chantziaras wrote:
 On 08/24/2011 01:48 PM, Patrick Lauer wrote:
 [...] If you sneakily add something to cron.daily by default you can
 get pretty nice coverage. But I guess anyone trying that in 
 Gentooland will meet some rather unpleasant resistance :)
 
 emerge always asks me after a world update whether I want to auto 
 clean packages with a yes/no prompt.  I wouldn't be bad if once a 
 month or whatever it would ask me whether I want to upload my stats.
 Gentoostats should probably become a runtime dep of Portage itself by
 default, but not used automatically.
 
 I like your idea and people seem to like making things complicated. 
 Simple solution:
 
 opt-in
 
 How: Display a warning after an emerge -u{DNav} world. Let user disable
 this warning by using a special variable in make.conf
 
 STATS_ENABLE=no.
 
 By default, this variable will be yes on base/ profiles

That sounds perfect to me.

The prompt should offer three options:

 [s]end the data directly
 s[h]ow me the data*
 s[k]ip

 You can disable this prompt by having either 'SEND_STATS=yes' (to always
 send) or 'SEND_STATS=no (to never send) in your /etc/make.conf.

*) And in the next step, after showing the data set(s): Send? [y/n]

(why do all those words have to start with an 's'??)

Cheers,
Patrick.

- -- 
Key ID: 0x86E346D4http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5WWPoACgkQyYHmhobjRtSwewCgyJzgsLLvjfZpX5vg8XcxkNMb
tg8AoIkHz1z6b9DxTrnJxe3YyTDMOYsr
=ZKYx
-END PGP SIGNATURE-



Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Alec Warner
On Thu, Aug 25, 2011 at 5:20 AM, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 25, 2011 at 6:48 AM, Roy Bamford neddyseag...@gentoo.org wrote:
 It has to be opt-in as opt out would be a dangerous precendent to set.

 I don't see any harm is a gentle reminder message from emerge, provided
 that the reminder can be turned off too, if the user really does not
 want to opt in. Thats no worse than being nagged about unread news.

 I tend to agree, the more I think about it.

 The simplest solution (which doesn't require any portage mods/etc), is
 to simply make this a package that installs the appropriate logic in
 cron.daily, and we send out a news item encouraging users to install
 it voluntarily.  If the user does nothing, they don't get the package.

 If somebody can come up with really good reason that we should be more
 aggressive in promoting it, then we can promote it more aggressively.
 That /might/ go as far as a forced opt-in/out decision.  However, the
 more I think about it the more I'm concerned with pure opt-out by
 default.

Why is the thread bikeshedding an out-opt that we aren't even
considering doing right now?


 The big issue with opt-out is privacy law - especially in Europe
 (that's leaving aside just being up-front with users).  We'd end up
 having to have EULAs or such and perhaps a number of other legal
 controls, and I don't think that is a direction that we want to go in.
  I'm just not seeing the upside - better to just figure out good ways
 to use data that is easy and safe to obtain first.

 Earlier somebody suggested that this decision wasn't really in the
 domain of the Council/Trustees.  I'm not sure I agree here - any kind
 of opt-out data collection is something that has potential legal
 ramifications as well as huge reputation concerns for the distro (the
 software is distributed from Foundation-owned hardware utilizing a
 Foundation-owned domain name and the data goes back to
 Foundation-owned hardware - I'm sure any lawyer could make a case for
 this).  Just because there isn't a policy written down somewhere
 doesn't mean that we can't use common sense.  Devs certainly don't
 need to run everything past the Council, but if you want to do
 something high-profile post it on -dev, and if there is an uproar look
 for an official second opinion before doing it.

We did post to -dev, hence this thread. The point is that we don't
need any 'official opinion' to do anything; and I don't want to set
that precedent. If you have specific concerns about actions we plan to
take (which by the way, we are not planning an opt-out solution. If we
plan to do an opt-out solution, we will again have a thread on -dev)
then let us know. If you have specific legal concerns about the
application, data retention, encryption, logs, backups, onerous
european privacy laws, and other such questions you should raise those
concerns now.


 Rich





Re: [gentoo-dev] Re: Gentoostats, SoC 2011

2011-08-25 Thread Fabian Groffen
On 25-08-2011 22:15:22 +0800, Patrick Nagel wrote:
 The prompt should offer three options:
 
  [s]end the data directly
  s[h]ow me the data*
  s[k]ip
 
  You can disable this prompt by having either 'SEND_STATS=yes' (to always
  send) or 'SEND_STATS=no (to never send) in your /etc/make.conf.
 
 *) And in the next step, after showing the data set(s): Send? [y/n]
 
 (why do all those words have to start with an 's'??)

send
display/view
later

:)

-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Rich Freeman
On Thu, Aug 25, 2011 at 10:35 AM, Alec Warner anta...@gentoo.org wrote:
 We did post to -dev, hence this thread.

My post was intended to be general in applicability, and not critical
of the particular instance of this issue being discussed.

I would generally suggest that implementing this as a package and not
as a function built-into portage would tend to make more sense to me
(do we really want portage to do EVERYTHING?).  However, I don't think
that anybody needs anybody's blessing in particular to take one course
or the other there.  And, in the Gentoo tradition of
everybody-does-whatever-they-want-to, there is nothing wrong with one
set of devs doing it one way and another set doing it another way so
that we end up with two data repositories with somewhat redundant data
so that we can start another discussion on -dev about what the
differences in the datasets mean.  That is, until eventually devs get
bored and after enough bugs pile up one or both of the collection
mechanisms gets treecleaned.  Then in five years somebody can build a
new one. :)

If I had strong concerns with anything that seemed likely to get
adopted I'd voice them.

Rich



[gentoo-dev] Last rites: sys-boot/arcboot

2011-08-25 Thread Matt Turner
# Matt Turner matts...@gentoo.org (25 Aug 2011)
# Masked for removal in 30 days. Use arcload instead.
sys-boot/arcboot



[gentoo-dev] mesa r600 gallium news item

2011-08-25 Thread Chí-Thanh Christopher Nguyễn
Hello,

Please see the attached news item for review. The news item should be
published before mesa-7.11 goes stable.
Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349


Best regards,
Chí-Thanh Christopher Nguyễn
Title: Mesa r600 driver now defaults to gallium
Author: Chí-Thanh Christopher Nguyễn chith...@gentoo.org
Content-Type: text/plain
Posted: 2011-08-28
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-libs/mesa-7.12

This news item is relevant to you only if you have a Radeon graphics
chipset and use the free/open source driver.

The r600 driver that provides 3D acceleration for Radeon HD 2000 and
later cards comes in the classic and gallium variants. The gallium
driver is based on the new Gallium3D infrastructure and was chosen as
the default driver for media-libs/mesa-7.11.

Existing users will not be switched automatically. To switch to the
r600 gallium driver, use the following command:

eselect mesa set r600 gallium

Gallium3D requires kernel modesetting (KMS). If your system is not yet
configured for KMS, consult the X Server Configuration HOWTO for
instructions prior to switching:

http://www.gentoo.org/doc/en/xorg-config.xml


Re: [gentoo-dev] mesa r600 gallium news item

2011-08-25 Thread Matt Turner
2011/8/25 Chí-Thanh Christopher Nguyễn chith...@gentoo.org:
 Hello,

 Please see the attached news item for review. The news item should be
 published before mesa-7.11 goes stable.
 Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349


 Best regards,
 Chí-Thanh Christopher Nguyễn

Looks good to me.

Matt



Re: [gentoo-dev] mesa r600 gallium news item

2011-08-25 Thread Francisco Blas Izquierdo Riera (klondike)
El 25/08/11 23:25, Matt Turner escribió:
 2011/8/25 Chí-Thanh Christopher Nguyễn chith...@gentoo.org:
 Hello,

 Please see the attached news item for review. The news item should be
 published before mesa-7.11 goes stable.
 Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349


 Best regards,
 Chí-Thanh Christopher Nguyễn
 Looks good to me.

 Matt
You can point the reader to
http://www.x.org/wiki/RadeonFeature#Decoderringforengineeringvsmarketingnames
in order to know wether his ATI card is or not an r600 ATI card.
Specially since the reference to HD2000 includes some r500 cards.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] mesa r600 gallium news item

2011-08-25 Thread Chí-Thanh Christopher Nguyễn
Francisco Blas Izquierdo Riera (klondike) schrieb:

 You can point the reader to
 http://www.x.org/wiki/RadeonFeature#Decoderringforengineeringvsmarketingnames
 in order to know wether his ATI card is or not an r600 ATI card.
 Specially since the reference to HD2000 includes some r500 cards.

You are right, but that page is slightly confusing and still not 100%
accurate. I think I'll change it to HD 2400 and later, which should
cover exactly the r600 driven cards.


Best regards,
Chí-Thanh Christopher Nguyen



Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25-08-2011 14:35, Alec Warner wrote:
 On Thu, Aug 25, 2011 at 5:20 AM, Rich Freeman ri...@gentoo.org
 wrote:
snip
 The big issue with opt-out is privacy law - especially in Europe 
 (that's leaving aside just being up-front with users).  We'd end
 up having to have EULAs or such and perhaps a number of other
 legal controls, and I don't think that is a direction that we want
 to go in. I'm just not seeing the upside - better to just figure
 out good ways to use data that is easy and safe to obtain first.
 
 Earlier somebody suggested that this decision wasn't really in the 
 domain of the Council/Trustees.  I'm not sure I agree here - any
 kind of opt-out data collection is something that has potential
 legal ramifications as well as huge reputation concerns for the
 distro (the software is distributed from Foundation-owned hardware
 utilizing a Foundation-owned domain name and the data goes back to 
 Foundation-owned hardware - I'm sure any lawyer could make a case
 for this).  Just because there isn't a policy written down
 somewhere doesn't mean that we can't use common sense.  Devs
 certainly don't need to run everything past the Council, but if you
 want to do something high-profile post it on -dev, and if there is
 an uproar look for an official second opinion before doing it.
 
 We did post to -dev, hence this thread. The point is that we don't 
 need any 'official opinion' to do anything; and I don't want to set 
 that precedent. If you have specific concerns about actions we plan
 to take (which by the way, we are not planning an opt-out solution.
 If we plan to do an opt-out solution, we will again have a thread on
 -dev) then let us know. If you have specific legal concerns about
 the application, data retention, encryption, logs, backups, onerous 
 european privacy laws, and other such questions you should raise
 those concerns now.

I've picked this message as I want to address one point in this thread
that was focused on this sub-thread.
I disagree with the idea that adding an application to the Gentoo tree
that collects data from users and sends it to a central (or distributed)
system is the same as adding any other application to the tree.
Having the ability to add ebuilds to the tree is part of what you gain
by getting gentoo-x86 access. Issues with significant users privacy
concerns and substantial changes like adding packages to the tree that
collect data from users and compile it, should not be at the discretion
of individual developers but be subject of global policies that should
take into account the legal ramifications (trustees) and reflect the
developers desire and goals (council).

- -- 
Regards,

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

iQIcBAEBAgAGBQJOVxCXAAoJEC8ZTXQF1qEP7KAQAJBwDHp4aS+5l8gahHUrsWYI
0gUpO+qtsFODsKToQa4ZZ9jTZhFvN0iscyApXvgO8FBOnPzFCMiq+LblI/j/cnFK
OwVYJ4/tvcc1C1fE1lQecd1kNVlnVLCEvR8NbeKA184ty4kS7cJy2FqAiWbzGGno
/zNsQI+iDUg6ZCamCz29EZ5FJgfUzXzG+Ipbh61T0c/Ukugq5xHA8c5zTzoRre2u
/fSRMM9qPakmgaHJoV8t+8B0ejJccW/+MquKIyFdDnUDvQH5U/RnXl3D5oe7+0vb
Eak3VB5iUrkZifqhpOQMEeAtuNColigPy4oPr6BsQz7t0uiC2M0MHei4cigbN8kn
yp4U+RZE4PhJ/+b/U/jnaiidGu8IF+Kdl3DPgCR130N4vbpO8u7KjyphdoL7QZx5
hnc3A5ZxQxraQolKtFnl8Be8P5NvuKdiP192wYmACuCw3W95XVNDtUhc63n++fqo
0K9WTEudO+JZN7JYZFSU6OJo5hvujHcQvvIO2sG30Q56x7EfvCRFCzMUsRC8mU0L
uSKW+YFHVp1+yCJ9BbnTWp9afPUVQ56/1YtCxLDsqEi0lI7otm0TpuJFIC/fDJ1F
Hf9Kqaap9kZzc1WBKuMY0Rvvf8CKf/9bd9QTxT5Fz/tpiNGkU9MTMFPHghDFUP8h
773YR/NFapQVLHyqemla
=G4Y6
-END PGP SIGNATURE-