date:20130210

# Pacho Ramos pa...@gentoo.org (10 Feb 2013)
# Upstream dropped support for linux time ago (#434390),
# possible security issues (#360539). You can use Windows
# version with PlayOnLinux. Removal in a month.
media-gfx/picasa

# Pacho Ramos pa...@gentoo.org (10 Feb 2013)
# Abandoned by upstream, problems building (#362611).
# Removal in a month.
dev-python/papyon
net-voip/telepathy-butterfly

# Pacho Ramos pa...@gentoo.org (10 Feb 2013)
# Fails with gcc-4.7, crashes (#301946, #312073), problems with
# boost (#319921), problems with python-2.7 (#338826), really old
# version in the tree, people should move to sci overlay one (#424659).
# Removal in a month.
sci-visualization/paraview

# Pacho Ramos pa...@gentoo.org (10 Feb 2013)
# Doesn't support kernel = 2.6.22, #453202. Removal in a month.
x11-misc/xdaf




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

Re: [gentoo-dev] January stabilization candidates

2013-02-10 Thread Paweł Hajdan, Jr.

On 1/12/13 11:49 PM, Paweł Hajdan, Jr. wrote:
 Please review attached automatically generated stabilization candidates
 for January.

Oops, today I've tried my _separate_ script to file stabilization bugs
based on a generated list of packages to support that workflow.

Now the bug is that the list was the original one from January, and many
entries from that list are now stale (the new contents were appended at
the end).

I hit ctrl-c once I realized the mistake, and I'm going to wait a while
for the current batch of bugs to get handled.

I can actually batch invalidate all of them. This will generate some
further bug spam (I apologize), but can save your time dealing with the
mess. Please let me know what's your preference.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] January stabilization candidates

2013-02-10 Thread Ralph Sennhauser

On Sun, 10 Feb 2013 12:22:13 +0100
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 I can actually batch invalidate all of them. This will generate some
 further bug spam (I apologize), but can save your time dealing with
 the mess. Please let me know what's your preference.

The URL field is likely not filled out as intended either. So you might
want to do that anyway.


signature.asc
Description: PGP signature

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Patrick Lauer

On 02/10/2013 05:01 PM, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org (10 Feb 2013)
 # Fails with gcc-4.7, crashes (#301946, #312073), problems with
 # boost (#319921), problems with python-2.7 (#338826), really old
 # version in the tree, people should move to sci overlay one (#424659).
 # Removal in a month.
 sci-visualization/paraview

So instead of moving things from random overlays to the tree we remove
packages now, remove features from other packages because of that
(openfoam) and then ... tell users to use an overlay?

Somehow this appears not well thought out to me. Would anyone be
terribly upset if I started pillaging this silly overlay? (And any other
overlays that look like they are fun)

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Michał Górny

On Sun, 10 Feb 2013 19:47:58 +0800
Patrick Lauer patr...@gentoo.org wrote:

 On 02/10/2013 05:01 PM, Pacho Ramos wrote:
  # Pacho Ramos pa...@gentoo.org (10 Feb 2013)
  # Fails with gcc-4.7, crashes (#301946, #312073), problems with
  # boost (#319921), problems with python-2.7 (#338826), really old
  # version in the tree, people should move to sci overlay one (#424659).
  # Removal in a month.
  sci-visualization/paraview
 
 So instead of moving things from random overlays to the tree we remove
 packages now, remove features from other packages because of that
 (openfoam) and then ... tell users to use an overlay?
 
 Somehow this appears not well thought out to me. Would anyone be
 terribly upset if I started pillaging this silly overlay? (And any other
 overlays that look like they are fun)

+1. If you can't manage moving/updating your packages properly
and on-time from the sci overlay, please get rid of it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

El dom, 10-02-2013 a las 19:47 +0800, Patrick Lauer escribió:
 On 02/10/2013 05:01 PM, Pacho Ramos wrote:
  # Pacho Ramos pa...@gentoo.org (10 Feb 2013)
  # Fails with gcc-4.7, crashes (#301946, #312073), problems with
  # boost (#319921), problems with python-2.7 (#338826), really old
  # version in the tree, people should move to sci overlay one (#424659).
  # Removal in a month.
  sci-visualization/paraview
 
 So instead of moving things from random overlays to the tree we remove
 packages now, remove features from other packages because of that
 (openfoam) and then ... tell users to use an overlay?
 
 Somehow this appears not well thought out to me. Would anyone be
 terribly upset if I started pillaging this silly overlay? (And any other
 overlays that look like they are fun)
 

That is because looks nobody from sci team has enough time to move
things from sci overlay to the tree (probably because it's being
maintained there by people without commit access). Ideally that people
would become devs with commit rights but, until then, looks like some
packages (usually sci maintained packages) are being maintained better
in overlay than main tree :/

I guess wouldn't be problems on pillaging ebuilds from that overlay to
the tree... but I guess you would be willing to become its maintainer to
update ebuilds from overlay when needed :|


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

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

On Sun, Feb 10, 2013 at 6:48 AM, Michał Górny mgo...@gentoo.org wrote:

 +1. If you can't manage moving/updating your packages properly
 and on-time from the sci overlay, please get rid of it.

Seems like the alternative solution is to just not have these ebuilds
in the main tree.

There is nothing wrong with having an overlay that provides a better
experience than the main tree.  Most distros actually operate this way
- just look up your average non-core piece of FOSS software and the
first thing their Ubuntu install instructions will tell you to do is
to add some repository to your list.

I think the main tree can potentially provide a better experience
since it actually gets checked when dependencies are changed.
However, that is only true if somebody is maintaining it.

Pillaging the overlays is fine as long as somebody actually maintains
the package, and it isn't just a one-time copy that resets the clock.
Otherwise, purpose-driven overlays just make sense - they allow a
different set of contributors who are more familiar/interested in a
set of packages to maintain them.

Rich

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Tomáš Chvátal

Dne Ne 10. února 2013 19:47:58, Patrick Lauer napsal(a):
 On 02/10/2013 05:01 PM, Pacho Ramos wrote:
  # Pacho Ramos pa...@gentoo.org (10 Feb 2013)
  # Fails with gcc-4.7, crashes (#301946, #312073), problems with
  # boost (#319921), problems with python-2.7 (#338826), really old
  # version in the tree, people should move to sci overlay one (#424659).
  # Removal in a month.
  sci-visualization/paraview
 
 So instead of moving things from random overlays to the tree we remove
 packages now, remove features from other packages because of that
 (openfoam) and then ... tell users to use an overlay?

Agreed this is pretty bad idea. The teams should actually have their top 
priority to include user contributions to main tree as much as possible. If 
the team does not have time to maintain the named package, just add some 
contributors as maintainers and do proxy-commits for them...

The greatest problem at least from my PoV is that we can't just simply git am 
loads of stuff users are contributing and must convert to cvs (thats actually 
what takes me most of the time).

Having nice mailinglist where users can contribute simple patches would be 
briliant thing to use :-)

Cheers

Tom

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Alexander Berntsen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/13 12:47, Patrick Lauer wrote:
 So instead of moving things from random overlays to the tree we 
 remove packages now, remove features from other packages because of
  that (openfoam) and then ... tell users to use an overlay?
 
 Somehow this appears not well thought out to me.
+1

On 10/02/13 13:11, Rich Freeman wrote:
 There is nothing wrong with having an overlay that provides a
 better experience than the main tree.  Most distros actually
 operate this way
Most distros aren't very good.

 - just look up your average non-core piece of FOSS software and the
  first thing their Ubuntu install instructions will tell you to do
 is to add some repository to your list.
And the second search result is the Ubuntu troubleshooting broken
installs as a result of adding other repositories.

I accept that there may exist reasons for using overlays. Ubuntu do
it! is not one.


- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEXl8QACgkQRtClrXBQc7UKOAD+P7mFavgADIecwTm5jKLEnbq/
h81FRf2qbvwf54X6T9YA/RJ4y1EAesZOvxvpuIVTEKpLwcTipgWJZeExzWReAn/7
=po4x
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

2013-02-10 Thread Samuli Suominen


On 10/02/13 10:10, Samuli Suominen wrote:

# Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013)
# The firmware cleanup, part #1. Can be unmasked after
# cleaning up the package if it's still needed.
# Some of these install to wrong directory, /lib64/firmware
# as opposed to correct /lib/firmware
# Some of these don't have maintainer
# Some of these are replaced by the firmware from the
# linux-firmware package:
# emerge -av linux-firmware
# If you still have a reason to keep the package, please
# let us know by filing a bug report.
net-wireless/ipw2100-firmware
net-wireless/ipw2200-firmware


These two got unmasked after cleaning up the ebuilds.


net-wireless/prism54-firmware


This one doesn't have license, moved to it's own mask.

And new masked package because it's in linux-firmware:

net-wireless/i2400m-fw

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

On Sun, Feb 10, 2013 at 7:51 AM, Alexander Berntsen
alexan...@plaimi.net wrote:

 On 10/02/13 13:11, Rich Freeman wrote:
 - just look up your average non-core piece of FOSS software and the
  first thing their Ubuntu install instructions will tell you to do
 is to add some repository to your list.
 And the second search result is the Ubuntu troubleshooting broken
 installs as a result of adding other repositories.

 I accept that there may exist reasons for using overlays. Ubuntu do
 it! is not one.

I have mixed feelings on this.  I'd never advocate doing anything
simply because everybody else is doing it - if I wanted to use Ubuntu
I'd be using Ubuntu.

There are pros/cons to overlays right now:
Pros include:
1.  More flexible maintenance model.  The overlay maintainer can
choose who has access to it.  They don't have to worry about people
making tree-wide commits without knowing what they're doing, because
any damage is contained to the overlay (though obviously any package
in an overlay could mess with anything on a user's system).

2.  More flexible QA model.  Usually that means less QA, which has its
own pros and cons, but it /could/ actually mean more QA, or just
different QA.  Right now we have no way of communicating to users
(beyond masks) that packages vary in quality level, and overlays could
be a way to accomplish this.  You could also have a set of related
overlays that provide a dev/test/stable experience.

Cons include:
1.  No relationship to the tree.  If somebody messes with one of your
dependencies they will not take any care not to break your package.

2.  Non-mainstream experience.  Because Gentoo tends to be
overlay-averse, most users don't use them at all.

3.  No real organization.  Beyond an entry in the layman list there
really isn't any systematic tracking of overlays and their
quality/etc.  We don't grade overlays or anything like that.

#1 is the biggest con I'd say.  It is made worse by the fact that we
don't have a main repository QA cycle (I'm not suggesting we have
one).  For something like Ubuntu anybody maintaining a 3rd party
repository can monitor the release cycle and test against the new
dependency versions before they are released and be ready on day one.
For Gentoo you would have to pay very close attention to bugzilla,
lists, irc, and perhaps even mail aliases (not open to the public) to
have any idea that some change is about to happen to one of your
dependencies if you aren't in the main tree.

A fix for #1 might be some way to allow external parties to register
interest in upcoming changes and get alerted.  Then those changing
libs could just trigger the alerts (and that system might also file
bugs against in-tree packages to request testing).  We obviously
wouldn't consider any outside overlays blockers, but we could be nicer
to them.  Of course, that takes work and I'm skeptical that this would
ever happen.

So, those are just my thoughts on overlays.  I don't think they're a
bad thing.  However, there are some things about Gentoo that make them
less practical than on other distros.  I won't argue that you get the
best possible experience if the package is in the tree AND IT IS
MAINTAINED.  The problem is that in a volunteer-based organization the
second half of that is hard to guarantee.

Rich

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Markos Chandras

On Feb 10, 2013 8:32 AM, Ben de Groot yng...@gentoo.org wrote:

 On 10 February 2013 10:43, Douglas Freed dwfr...@mtu.edu wrote:
  * all 13.0 profiles have been created and are marked stable the same
way
  as
  10.0 was
  * all 10.0 profiles have been removed from profiles.desc
  * all 10.0 profiles have been deprecated
 
  Suggestion: perhaps a news item should be created for the migration to
the
  new profiles?  As a Gentoo user who just got a giant red warning from
  portage that his active profile was deprecated, I feel like many people
are
  going to be confused about this.
 
  -Doug

 Obviously a news item should precede any deprecation of stable profiles.

 --
 Cheers,

 Ben | yngwin
 Gentoo developer
 Gentoo Qt project lead, Gentoo Wiki admin


I think it is too late now. The big red warning is already there.

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Markos Chandras

On 10 February 2013 14:06, Andreas K. Huettel dilfri...@gentoo.org wrote:
 Am Sonntag, 10. Februar 2013, 14:34:14 schrieb Markos Chandras:
   new profiles?  As a Gentoo user who just got a giant red warning from
   portage that his active profile was deprecated, I feel like many people
   are going to be confused about this.
 
  Obviously a news item should precede any deprecation of stable profiles.
 

 I think it is too late now. The big red warning is already there.

 To be honest I did not really see the necessity since the big red warning
 exactly tells you what to do (and even which profile to pick, which would be
 more complicated in a news item).

 Then again, that's a matter of personal preference, too.

 --

 Andreas K. Huettel
 Gentoo Linux developer
 dilfri...@gentoo.org
 http://www.akhuettel.de/


I suspect most people are interested in understanding what changed
(since deprecation means that the new thing is better than the old
one). Moreover, the news item is another way to assure them that
everything is not as bad as the initial red warning might had made
them think so and keep calm and use Gentoo ;-)

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Tomáš Chvátal

Dne Ne 10. února 2013 13:51:16, Alexander Berntsen napsal(a):
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 10/02/13 12:47, Patrick Lauer wrote:
  So instead of moving things from random overlays to the tree we
  remove packages now, remove features from other packages because of
  
   that (openfoam) and then ... tell users to use an overlay?
  
  Somehow this appears not well thought out to me.
 
 +1
 
 On 10/02/13 13:11, Rich Freeman wrote:
  There is nothing wrong with having an overlay that provides a
  better experience than the main tree.  Most distros actually
  operate this way
 
 Most distros aren't very good.
 
  - just look up your average non-core piece of FOSS software and the
  
   first thing their Ubuntu install instructions will tell you to do
  
  is to add some repository to your list.
 
 And the second search result is the Ubuntu troubleshooting broken
 installs as a result of adding other repositories.
 
 I accept that there may exist reasons for using overlays. Ubuntu do
 it! is not one.
 
Don't worry,
no matter what are Richs opinions he is not the one crating global policies 
for this, so the defaults still are that we encourage adding all stuff to main 
tree where possible. Even the overlays are supposed to be just plaingrounds 
where we train upcoming devs, or pose as live ebuild/huge experimantal changes 
storage space.

Even the excuse that it is not maintained so it is to stay in overlay is 
false, because when somebody mess with the package in overlay they can became 
maintainers in the main tree too without much fuzz.

But I suppose this problem is created simply because people not wanting to 
work with cvs (and I purely agree that git workflow is much easier wrt 
this)...

Cheers

Tom

[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread hasufell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 10:01 AM, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org (10 Feb 2013) # Fails with
 gcc-4.7, crashes (#301946, #312073), problems with # boost
 (#319921), problems with python-2.7 (#338826), really old # version
 in the tree, people should move to sci overlay one (#424659). #
 Removal in a month. sci-visualization/paraview
 

people should move to sci overlay one?

Why is it not in the tree? Pointing people to overlays is wrong imo.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRF7HdAAoJEFpvPKfnPDWzdekH/0sOPq8riBUlRtfDnLWAuf4J
7md3b0KBg9sP0RZWJsAZdK/N5Zs37iJWXF+L9LAr4wmil8IwxazEMWC3xMu8Dh4E
cXIfVVgLWz8C/VW0wQBUX3jo7fr4B0gLKWdRZ6axgPdTV3pIqz6cpzsbbtb4ls+L
XteKqDHhQxfZ2vjtkImVcux4wBBZEWZX/Do+21WfC6WWbk9Q5udmrcxCpLTMl84O
G/Ia5rfwWiHtIpDzY0PBJgFnTkyfbKlas1hSDYybLDO+Tr1F6YRN3nmFWLFeBPVY
NqhGLHnyvWApSJ+qkjb2bszWHs3GVLYDec+W81R8mgO4c/hYugeoKXS6YBhTPNc=
=9xsA
-END PGP SIGNATURE-

RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Sergei Trofimovich

On Sun, 10 Feb 2013 10:10:51 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:

 # Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013)
 # The firmware cleanup, part #1. Can be unmasked after
 # cleaning up the package if it's still needed.
 # Some of these install to wrong directory, /lib64/firmware
 # as opposed to correct /lib/firmware
 # Some of these don't have maintainer
 # Some of these are replaced by the firmware from the
 # linux-firmware package:
 # emerge -av linux-firmware
 # If you still have a reason to keep the package, please
 # let us know by filing a bug report.
 net-wireless/ar9271-firmware

I didn't know linux-firmware exists at all when added that
to the tree (SRC_URI=http://linuxwireless.org).
Fine by me.

The source of confusion was non-working device by default.
Maybe 'IUSE=+firmware; RDEPEND=firmware? ( sys-kernel/linux-firmware )'
for virtual/linux-sources would help user experience a bit.

Sometimes firmware loader does not even write fw file
it expects to be present on FS in dmesg (like certain broadcom drivers)
thus it's nontrivial for user to figure out needed package to be installed.

Thanks!

-- 

  Sergei


signature.asc
Description: PGP signature

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

On Sun, Feb 10, 2013 at 9:37 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote:
 no matter what are Richs opinions he is not the one crating global policies
 for this, so the defaults still are that we encourage adding all stuff to main
 tree where possible.

Relax, and don't make it personal.

The bottom line is that some encourage putting stuff in the tree, and
others like to work from overlays.  No developer is going to get
banned for working on an overlay on the side.

In the end packages in the tree will be better maintained if
developers step up and maintain them, and packages in an overlay will
be better maintained if developers step up and maintain them.
Anything else is just flames on the lists.

I never claimed to speak for a majority, and the only time I concern
myself with majority opinion is when following policies or voting as a
trustee.

Rich

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Patrick Nagel

Hi,

On 2013-02-10 22:06, Andreas K. Huettel wrote:
 Am Sonntag, 10. Februar 2013, 14:34:14 schrieb Markos Chandras:
 new profiles?  As a Gentoo user who just got a giant red warning from
 portage that his active profile was deprecated, I feel like many people
 are going to be confused about this.

 Obviously a news item should precede any deprecation of stable profiles.


 I think it is too late now. The big red warning is already there.
 
 To be honest I did not really see the necessity since the big red warning 
 exactly tells you what to do (and even which profile to pick, which would be 
 more complicated in a news item). 
 
 Then again, that's a matter of personal preference, too.

Actually, if you could add a note that before switching to the new profile,
you should update portage if it's old, that would be even more user-friendly:

I just saw the big red warning on a not-so-well-maintained Gentoo box today,
switched to the new profile, and then portage would only do read-only
operations. So I had to figure out how to change the profile back manually
(because the old profile also isn't shown in eselect anymore), before I
could update portage and then switch to the new profile again.

Patrick.

News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)

Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras: 
 I suspect most people are interested in understanding what changed
 (since deprecation means that the new thing is better than the old
 one). Moreover, the news item is another way to assure them that
 everything is not as bad as the initial red warning might had made
 them think so and keep calm and use Gentoo ;-)

OK, here's a news item (actually two, separate for server and non-server 
profiles). Since it's a bit late now, I'll commit this or the improved version 
after discussion here in 6h (21:00 UTC) unless there are severe protests.

-- the non-server profile variant (sparing you a lot of Display-If-Profile 
lines)

Title: New 13.0 profiles and deprecation of 10.0 profiles
Author: Andreas K. Hüttel dilfri...@gentoo.org
Content-Type: text/plain
Posted: 2013-02-10
Revision: 1
News-Item-Format: 1.0
Display-If-Profile: default/linux/alpha/10.0
Display-If-Profile: default/linux/alpha/10.0/desktop
[...]
Display-If-Profile: default/linux/x86/10.0/desktop/kde
Display-If-Profile: default/linux/x86/10.0/developer

We have generated a new set of profiles for Gentoo installation. These are now 
called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but 
please make sure sys-apps/portage is updated to current stable *before* you
switch profile).
This brings (nearly) no user-visible changes. Some new files have been added
to the profile directories that make it possible for the developers to do more 
fine-grained use flag masking (see PMS-5 for the details), and this formally 
requires a new profile tree with EAPI=5.

-- the server profile variant (sparing you the headers entirely)

We have generated a new set of profiles for Gentoo installation. These are now
called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but
please make sure sys-apps/portage is updated to current stable *before* you
switch profile).
This brings (nearly) no user-visible changes. Some new files have been added
to the profile directories that make it possible for the developers to do more
fine-grained use flag masking (see PMS-5 for the details), and this formally
requires a new profile tree with EAPI=5.
In the course of this change, the server profiles will be removed; they do
not exist in the 13.0 tree anymore. You should migrate to the corresponding
parent profile. This may change the default value of some use-flags. The
specific setting in server was 
  USE=-perl -python snmp truetype xml
You may want to check the setting of these flags after switching profile, but
otherwise nothing changes.




-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread hasufell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 12:47 PM, Patrick Lauer wrote: Would anyone be
 Would anyone be terribly upset if I started pillaging this silly
 overlay? (And any other overlays that look like they are fun)
 

Go ahead, I will help you.


On 02/10/2013 12:59 PM, Pacho Ramos wrote:
 
 That is because looks nobody from sci team has enough time to move 
 things from sci overlay to the tree (probably because it's being 
 maintained there by people without commit access).

I take that as a free card to add myself to the sci herd.


As for the overlay discussion, there should only be two reasons to
have ebuilds in a seperate overlay: they depend on dropped packages or
they are unsupportable (e.g. because they are in early alpha stage or
broken in some ways).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRF7czAAoJEFpvPKfnPDWz4gsH/jpvNiLpVKrnLM2T2lwS1oFx
uvrfBbBgX6ROEF0aQ6Um8GnJFqMkpW76O7R9hVHoF1ZMISh7iTQKw8eBMMKj/3ib
1O2kgUB6Y4yMXvZrq9RM7BJzupTQp8qdMMaozf8sJ34DhGKMVS8xRHWrgkJRq8FD
ZL/tbImEVDd97IazDLXPUxN77shvo2oYHOd9peiI9aVRWti72Kyzg8M6cxQ5ek33
ahLfeNpjw+Bg+k16WM6Fi0v9H64hSOSeeZzwaBoaAO0w3JlTx8ch2/8OBPFSg6gF
2aS3DoIG1K7JR1i+LLJ2x2sPUWPjPKcDlknGuNkZ2HlTP3gZziZusclboy/NjGI=
=LGQV
-END PGP SIGNATURE-

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

El dom, 10-02-2013 a las 17:46 +0300, Sergei Trofimovich escribió:
[...]
 The source of confusion was non-working device by default.
 Maybe 'IUSE=+firmware; RDEPEND=firmware? ( sys-kernel/linux-firmware )'
 for virtual/linux-sources would help user experience a bit.
 
 Sometimes firmware loader does not even write fw file
 it expects to be present on FS in dmesg (like certain broadcom drivers)
 thus it's nontrivial for user to figure out needed package to be installed.
 
 Thanks!
 

I agree as I have also needed to google and search in forums to get
proper firmware installed in the past in some machines :/


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

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

Am Sonntag, 10. Februar 2013, 15:59:57 schrieb Patrick Nagel:

 
 Actually, if you could add a note that before switching to the new profile,
 you should update portage if it's old, that would be even more
 user-friendly:
 

Already done, see separate mail...

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

El dom, 10-02-2013 a las 16:05 +0100, hasufell escribió:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 02/10/2013 12:47 PM, Patrick Lauer wrote: Would anyone be
  Would anyone be terribly upset if I started pillaging this silly
  overlay? (And any other overlays that look like they are fun)
  
 
 Go ahead, I will help you.
 
 
 On 02/10/2013 12:59 PM, Pacho Ramos wrote:
  
  That is because looks nobody from sci team has enough time to move 
  things from sci overlay to the tree (probably because it's being 
  maintained there by people without commit access).
 
 I take that as a free card to add myself to the sci herd.
 

That would be nice as, looking to some of its assigned bugs, it needs
help on maintaining the lot of packages included there.




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

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Ben de Groot

On 10 February 2013 20:11, Rich Freeman ri...@gentoo.org wrote:
 Otherwise, purpose-driven overlays just make sense - they allow a
 different set of contributors who are more familiar/interested in a
 set of packages to maintain them.

It makes more sense to let those people be proxy-maintainers and keep
those packages in the main tree.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)

2013-02-10 Thread Ben de Groot

On 10 February 2013 23:02, Andreas K. Huettel dilfri...@gentoo.org wrote:
 Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:
 I suspect most people are interested in understanding what changed
 (since deprecation means that the new thing is better than the old
 one). Moreover, the news item is another way to assure them that
 everything is not as bad as the initial red warning might had made
 them think so and keep calm and use Gentoo ;-)

 OK, here's a news item (actually two, separate for server and non-server
 profiles). Since it's a bit late now, I'll commit this or the improved version
 after discussion here in 6h (21:00 UTC) unless there are severe protests.

 -- the non-server profile variant (sparing you a lot of Display-If-Profile
 lines)

 Title: New 13.0 profiles and deprecation of 10.0 profiles
 Author: Andreas K. Hüttel dilfri...@gentoo.org
 Content-Type: text/plain
 Posted: 2013-02-10
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Profile: default/linux/alpha/10.0
 Display-If-Profile: default/linux/alpha/10.0/desktop
 [...]
 Display-If-Profile: default/linux/x86/10.0/desktop/kde
 Display-If-Profile: default/linux/x86/10.0/developer

 We have generated a new set of profiles for Gentoo installation. These are now
 called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but
 please make sure sys-apps/portage is updated to current stable *before* you
 switch profile).
 This brings (nearly) no user-visible changes. Some new files have been added
 to the profile directories that make it possible for the developers to do more
 fine-grained use flag masking (see PMS-5 for the details), and this formally
 requires a new profile tree with EAPI=5.

 -- the server profile variant (sparing you the headers entirely)

 We have generated a new set of profiles for Gentoo installation. These are now
 called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but
 please make sure sys-apps/portage is updated to current stable *before* you
 switch profile).
 This brings (nearly) no user-visible changes. Some new files have been added
 to the profile directories that make it possible for the developers to do more
 fine-grained use flag masking (see PMS-5 for the details), and this formally
 requires a new profile tree with EAPI=5.
 In the course of this change, the server profiles will be removed; they do
 not exist in the 13.0 tree anymore. You should migrate to the corresponding
 parent profile. This may change the default value of some use-flags. The
 specific setting in server was
   USE=-perl -python snmp truetype xml
 You may want to check the setting of these flags after switching profile, but
 otherwise nothing changes.




 --

 Andreas K. Huettel
 Gentoo Linux developer
 dilfri...@gentoo.org
 http://www.akhuettel.de/


Looks good to me!

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/irda-utils: irda-utils-0.9.18-r3.ebuild irda-utils-0.9.18-r4.ebuild ChangeLog

2013-02-10 Thread Mike Gilbert

On Sun, Feb 10, 2013 at 3:16 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 10/02/13 05:08, Mike Gilbert (floppym) wrote:

 floppym 13/02/10 03:08:22
 -   insinto /etc/udev/rules.d
 +   insinto /lib/udev/rules.d


 The udevdir is dynamic, not static, so:

 inherit udev

 insinto $(get_udevdir)/rules.d

 Thanks


Fixed.

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

Tomáš Chvátal wrote:
 Having nice mailinglist where users can contribute simple patches
 would be briliant thing to use :-)

That's still a waste of time compared to gerrit. You should look at
it if you don't know it already.


//Peter

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 # Some of these install to wrong directory, /lib64/firmware
 # as opposed to correct /lib/firmware
 # Some of these don't have maintainer
 # Some of these are replaced by the firmware from the
 # linux-firmware package:

 net-wireless/b43-firmware
 net-wireless/b43legacy-firmware

These are neither of the above.

I also don't understand masking packages because the firmware is in
linux-firmware. Is this an official policy? Sometimes firmware
packages are slotted, and it's also easier to install a package than
list and update a changing set of firmware files in
/etc/portage/savedconfig/sys-kernel/linux-firmware (referring to
ar9271, rt2860, rt2870, i2400m).

On the other hand, firmware is often very stable, so why mask a
package just because it has no maintainer? Who wins by having atmel,
or zd1201/zd1211 masked? There are no open bugs, so what's the point?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

hasufell wrote:
 there should only be two reasons to have ebuilds in a seperate
 overlay: they depend on dropped packages or they are unsupportable
 (e.g. because they are in early alpha stage or broken in some ways).

Keep in mind that there may be lots of other cases which you have not
and can not think of. Overlays are a wonderfully powerful way to
arbitrarily extend Gentoo. They make Gentoo infinitely more useful.

Anyway, in the case of my overlay, the reason that I have it is very
simple: me becoming a dev needs way too much effort.

It sounds like the sci overlay situation is the same.

I don't really mind this situation in practise, but Gentoo of course
loses. :\


//Peter

Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)

2013-02-10 Thread Markos Chandras

On 10 February 2013 15:02, Andreas K. Huettel dilfri...@gentoo.org wrote:
 Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:
 I suspect most people are interested in understanding what changed
 (since deprecation means that the new thing is better than the old
 one). Moreover, the news item is another way to assure them that
 everything is not as bad as the initial red warning might had made
 them think so and keep calm and use Gentoo ;-)

 OK, here's a news item (actually two, separate for server and non-server
 profiles). Since it's a bit late now, I'll commit this or the improved version
 after discussion here in 6h (21:00 UTC) unless there are severe protests.

 -- the non-server profile variant (sparing you a lot of Display-If-Profile
 lines)

 Title: New 13.0 profiles and deprecation of 10.0 profiles
 Author: Andreas K. Hüttel dilfri...@gentoo.org
 Content-Type: text/plain
 Posted: 2013-02-10
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Profile: default/linux/alpha/10.0
 Display-If-Profile: default/linux/alpha/10.0/desktop
 [...]
 Display-If-Profile: default/linux/x86/10.0/desktop/kde
 Display-If-Profile: default/linux/x86/10.0/developer

 We have generated a new set of profiles for Gentoo installation. These are now
 called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but
 please make sure sys-apps/portage is updated to current stable *before* you
 switch profile).
 This brings (nearly) no user-visible changes. Some new files have been added
 to the profile directories that make it possible for the developers to do more
 fine-grained use flag masking (see PMS-5 for the details), and this formally
 requires a new profile tree with EAPI=5.

 -- the server profile variant (sparing you the headers entirely)

 We have generated a new set of profiles for Gentoo installation. These are now
 called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but
 please make sure sys-apps/portage is updated to current stable *before* you
 switch profile).
 This brings (nearly) no user-visible changes. Some new files have been added
 to the profile directories that make it possible for the developers to do more
 fine-grained use flag masking (see PMS-5 for the details), and this formally
 requires a new profile tree with EAPI=5.
 In the course of this change, the server profiles will be removed; they do
 not exist in the 13.0 tree anymore. You should migrate to the corresponding
 parent profile. This may change the default value of some use-flags. The
 specific setting in server was
   USE=-perl -python snmp truetype xml
 You may want to check the setting of these flags after switching profile, but
 otherwise nothing changes.




 --

 Andreas K. Huettel
 Gentoo Linux developer
 dilfri...@gentoo.org
 http://www.akhuettel.de/


Looks good to me. Thanks

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

On Sun, Feb 10, 2013 at 10:10 AM, Ben de Groot yng...@gentoo.org wrote:
 On 10 February 2013 20:11, Rich Freeman ri...@gentoo.org wrote:
 Otherwise, purpose-driven overlays just make sense - they allow a
 different set of contributors who are more familiar/interested in a
 set of packages to maintain them.

 It makes more sense to let those people be proxy-maintainers and keep
 those packages in the main tree.

I'm all for that, but until the barriers to that become lower than the
barriers to just creating your own overlay, there will always be
overlays that contain stuff better maintained that the corresponding
stuff in the main tree.

I fully support anything that will make proxy-maintenance easier.

Rich

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 03:10 AM, Samuli Suominen wrote:
 # Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013)
 # The firmware cleanup, part #1. Can be unmasked after
 # cleaning up the package if it's still needed.
 # Some of these install to wrong directory, /lib64/firmware
 # as opposed to correct /lib/firmware
 # Some of these don't have maintainer
 # Some of these are replaced by the firmware from the
 # linux-firmware package:
 # emerge -av linux-firmware
 # If you still have a reason to keep the package, please
 # let us know by filing a bug report.
 net-wireless/ar9271-firmware
 net-wireless/atmel-firmware
 net-wireless/b43-firmware
 net-wireless/b43legacy-firmware
 net-wireless/ipw2100-firmware
 net-wireless/ipw2200-firmware
 net-wireless/libertas-firmware
 net-wireless/prism54-firmware
 net-wireless/rt2860-firmware
 net-wireless/rt2870-firmware
 net-wireless/rt61-firmware
 net-wireless/rt73-firmware
 net-wireless/rtl8192su-firmware
 net-wireless/zd1201-firmware
 net-wireless/zd1211-firmware
 
 (I hope I didn't step on anyones toes here. It was certainly not the
 intention.)
 
 

atmel-firmware
ipw2100-firmware
ipw2200-firmware
b43-firmware
b43legacy-firmware
rtl8192su-firmware
zd1201-firmware
zd1211-firmware

None of these are blockers on linux-firmware, none of these are included
in linux firmware, none of these should be masked with no replacement as
we are breaking approximately 90% of wifi cards on laptops built in the
last 5 years.

Only the following acctually show masked when I update:
- -net-wireless/atmel-firmware
- -net-wireless/b43-firmware
- -net-wireless/b43legacy-firmware
- -net-wireless/rtl8192su

Due to the damage this will cause I am removing the mask on these NOW, I
will cleanup the ebuilds today but this is bad, really really bad.  If
we are cleaning up linux-firmware that's great, but someone needs to
check that the things we are masking/removing are actually in
linux-firmware...

Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRF8i0AAoJEKXdFCfdEflKtbEP/1juLtMGpSw7inSnDLJQx5+a
aEFASrcmt9tK3aiYHfdOV09sNHAbiDWUNEM82OLH+yDbZwsiVQTgYnUutQelCo4g
B6Zdn9PoFoloAP0TbSfE24NI+BO9Z9rvM9NwHKTmejbKlihhzyhLINkrZM/qzM7j
yLSTrTyR2BKilC5bdSmJBgFrYOaWrsexNVZaB00x7eXNSIfBIZtR3LnVqFmMMsaO
ZiWFCGHTCRcm7MYbRcNxtS6cA4c/PeiKDbbfEqp8izMSux0ESLZtOPaE5O54uCyi
Bc8Th7gd6q4x/FxqYWj8Uq40oiEe1nRArgEbj9gHTvPTur9pvdTfCzIHh+qfV3TW
KnEyBJh1cUORnnNpxhJa3dkhT2Zx8s4ebsN6sfsXn3U8iJ9NE5vjz+gF6f4FJ8aH
NOuCj5y4LsgUwqoz4T/wpXvN1AlKCueyQ8w6P+RYtfTxZY8yWCnqmux0IFmyCLVj
nxhz/Ib9RAUjivdqd4PfcVtZhl42OU4jcNxPCJrpw6Ss07RBEw9+u0kE/kfkSRGT
Jn5WFa4vJyLqb7lg0FDDm6ijL5o811CQ7kaDcc1h9RjmgrW3nIusokNMkZnP+dE6
BIVgTlX564rcWsKeU9gmP7C68DSVCVr7zyEbSm9/DajJny4dbHSNUUvBNEQUde6j
/iVU0w4Af3YwKJ10KEjo
=D6qM
-END PGP SIGNATURE-

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
 I agree as I have also needed to google and search in forums to get
 proper firmware installed in the past in some machines :/

for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
-n 's/^firmware=//p' | sort -u); do
  if [ ! -e /lib/firmware/${fw} ]; then
echo ${fw}
  fi
done

I guess you can do something similar with vmlinux.bin if compiling
modules into kernel. Looking into kernel sources is more robust, but
gets annoying fast. Full script I am using is here:
https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares

You can encounter superfluous warnings with modules that support
multiple firmware subversions (e.g., iwlwifi).

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Dirkjan Ochtman

On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote:
 I agree as I have also needed to google and search in forums to get
 proper firmware installed in the past in some machines :/

+1 from me; I've had a few machines break on kernel upgrades because I
didn't have the proper firmware installed (I guess older kernel
sources came with the firmware?).

Cheers,

Dirkjan

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

On Sun, Feb 10, 2013 at 6:49 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 (I guess older kernel sources came with the firmware?)

See e.g. https://bugzilla.kernel.org/show_bug.cgi?id=42689#c5

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Fabio Erculiani

On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote:
 I agree as I have also needed to google and search in forums to get
 proper firmware installed in the past in some machines :/

 +1 from me; I've had a few machines break on kernel upgrades because I
 didn't have the proper firmware installed (I guess older kernel
 sources came with the firmware?).

This is another problem, namely dependency level problem.
I don't see how having kernel sources ebuilds providing /lib/firmware
would fix any of the listed issues without causing other side
effects.
For starters, if kernel sources provide /lib/firmware, how do you deal
with file collisions?


 Cheers,

 Dirkjan




-- 
Fabio Erculiani

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Alec Warner

On Sun, Feb 10, 2013 at 7:48 AM, Peter Stuge pe...@stuge.se wrote:
 Tomáš Chvátal wrote:
 Having nice mailinglist where users can contribute simple patches
 would be briliant thing to use :-)

 That's still a waste of time compared to gerrit. You should look at
 it if you don't know it already.

I'll take patchwork over gerrit, honestly ;)

-A



 //Peter

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Dirkjan Ochtman

On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote:
 +1 from me; I've had a few machines break on kernel upgrades because I
 didn't have the proper firmware installed (I guess older kernel
 sources came with the firmware?).

 This is another problem, namely dependency level problem.
 I don't see how having kernel sources ebuilds providing /lib/firmware
 would fix any of the listed issues without causing other side
 effects.
 For starters, if kernel sources provide /lib/firmware, how do you deal
 with file collisions?

I'm sorry, I have no clue about any of this; I was just signalling
that I've run into problems twice now, where I:

- had an old kernel working fine
- upgraded it using the usual mechanism
- then the network wouldn't come up on rebooting (bnx2 or tg3, not sure)
- with an obscure error message that was really quite hard to connect
to missing firmware, and
- it turned out to work fine after installing linux-firmware.

So it would be great to prevent other users from running into these
kinds of trouble.

Cheers,

Dirkjan

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

Alec Warner wrote:
  Having nice mailinglist where users can contribute simple patches
  would be briliant thing to use :-)
 
  That's still a waste of time compared to gerrit. You should look at
  it if you don't know it already.
 
 I'll take patchwork over gerrit, honestly ;)

Did you use gerrit's ssh interface?


//Peter

[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread James Cloos

PR # Pacho Ramos pa...@gentoo.org (10 Feb 2013)
PR # Fails with gcc-4.7, crashes (#301946, #312073), problems with
PR # boost (#319921), problems with python-2.7 (#338826), really old
PR # version in the tree, people should move to sci overlay one (#424659).
PR # Removal in a month.
PR sci-visualization/paraview

Or, more responsibly, the version in the sci overlay should move
to the main tree.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 10:55 AM, Maxim Kammerer wrote:
 On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen ssuomi...@gentoo.org 
 wrote:
 # Some of these install to wrong directory, /lib64/firmware
 # as opposed to correct /lib/firmware
 # Some of these don't have maintainer
 # Some of these are replaced by the firmware from the
 # linux-firmware package:
 
 net-wireless/b43-firmware
 net-wireless/b43legacy-firmware
 
 These are neither of the above.
 
 I also don't understand masking packages because the firmware is in
 linux-firmware. Is this an official policy? Sometimes firmware
 packages are slotted, and it's also easier to install a package than
 list and update a changing set of firmware files in
 /etc/portage/savedconfig/sys-kernel/linux-firmware (referring to
 ar9271, rt2860, rt2870, i2400m).
 
 On the other hand, firmware is often very stable, so why mask a
 package just because it has no maintainer? Who wins by having atmel,
 or zd1201/zd1211 masked? There are no open bugs, so what's the point?
 
Honestly while I agree this could have been handled a little more
carefully we all win by having ONE place for firmware.  The firmware
package is like 20MB, if you don't have that much free harddrive space
then you can use the savedconfig option to tune for just your hardware
but honestly this package is rather critical for any system that does
wifi or video capture and a few other things. I don't want to have to
hunt and find firmware packages, the ones that are seperate due to
license issues (read: Broadcom) will stay seperate, the rest I'll be
poking upstream about including in the firmware tree then killing.

Having 300 -firmware packages is silly.

- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGAXwAAoJEKXdFCfdEflK+xgP/A0F+XHiZLXo5D6rqvavyocE
cKJh/E3fSMB5QcqVhK/kWXhcjDiRz+5niMR30oMX05uwvbx6Fo8Kicne6XHw9fhv
UHo5E/k5e6lwaPOeI2nr59XaQ7Pj8PbhL9xrGA+CF1Yx7tJ2DqvEzYzOsuHlZG+B
/yrFFKQ2TGeftXpKVYY9iQH3pHCzOR5P40PURwW0onvx5Q2LunAVpOmUO520jL3h
dGoPWhjxK8RxpCOp/KbzxR27SD8kSWjgROmXpoIG0cfmohk/wfSwHyqg+i3pYDu8
b9Fs0OeOMnu2AxVeBCWHGFITeDz/0XVxlBThbzPj2KTnyQXoWfOHvOmGY9RxhJwh
Cye/vWepdzUa7Vsdj37JiGfaHh9F68UwT50OelR1HJYjJHvaMbZZAfvsbENWSzn4
+esRhFxEyF7bk70+n6RXAFTx/mMPCwoADSgIqqwy/Bv5R/Z0b3hWlF3GWVeR3nRc
Kd6kqifjYf8uVoUPAe1G5k5J+lQyyEva0Y93ML20y3pR0Ya3kJRioYxY1i2UdfVx
reB1R3t/5O62dEXcyHyJeNfKYUef3fTjz4ieNhbvvmn/VueklyNJL0wmGwLCwMJn
92uYVpU0hdQFPxNZc5rHavnB6MOl49y/68/rNEaRhUe5Y38DNKEE5zL94sMXF4pf
f4wQkVOOpYFdvaTRLQRR
=Pn47
-END PGP SIGNATURE-

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 11:54 AM, Fabio Erculiani wrote:
 On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote:
 I agree as I have also needed to google and search in forums to get
 proper firmware installed in the past in some machines :/

 +1 from me; I've had a few machines break on kernel upgrades because I
 didn't have the proper firmware installed (I guess older kernel
 sources came with the firmware?).
 
 This is another problem, namely dependency level problem.
 I don't see how having kernel sources ebuilds providing /lib/firmware
 would fix any of the listed issues without causing other side
 effects.
 For starters, if kernel sources provide /lib/firmware, how do you deal
 with file collisions?
The number of collisions has been reduced drastically in the last ~year,
I don't believe there are actually any left now.  I think the kernel has
almost entirely stopped shipping firmware.  It may be time to make
linux-firmware an RDEPEND of *-sources

- -Zero

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGAahAAoJEKXdFCfdEflKz2cP/2BbuvVsYgMUHGwuD8Xs5/Iw
70Q1QyXY4SIQGh5p/YZ0XX6Z1uzGGUAwAm2tWbsFUT6VFZWyb0p/Wl5Rf3Vtn9eO
4DXx4JoKPI12bFEbJuhCMe67e01A3h88j/lp0fE372MTDUcutl3FF+i34zz/DckU
NGEVw9+IxPxxuohTT+llzPE+3gd1j1LOSL+msv5nFwcKn940iOujLpDvpiscGD68
HBb5lcyxuKcV5XBlG3oRZ8+rP1A0vW2qyMm4/IXHMEehro1N3JxMpYQq+NcUrGT8
tlAHYW4C6+Z7b8zr9kEUbuDVI1dx+AM/MXbd8bdfpSWjnrk9NCnV5Y9mTBaNJB61
kn+CEQIaGi3aNBOzVBfo02ZGONZh7c178uIa7+Lh0deyENdlptU/UdD8wNf1PCK4
MCxsLzuJ6zb0XzaxJaY5snoZ+r8pHPrMUZFv8F0ls3y4maiGQMc48MOy4mJ90hYd
52HF3tjM2H0q7KNasKgP/u4DKylRiAWEvCS7uLF/6mUA74Ph9OVac+BJeUQSVsKh
4606UogOgk03IlBmNiyj41t3auX/MfqGYa3kBdftmFHURMOx1GPL5wqibRdzQ1T6
G8ojPdKxARHowkC9oAYljO6kUoQFD/mBN53KhvoCcu83n1rfvJ2hNBlkais8jEw6
PT7FeADuNUixau15F5jm
=rqzh
-END PGP SIGNATURE-

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Bruno

On Sun, 10 February 2013 Maxim Kammerer m...@dee.su wrote:
 On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
  I agree as I have also needed to google and search in forums to get
  proper firmware installed in the past in some machines :/
 
 for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
 -n 's/^firmware=//p' | sort -u); do
   if [ ! -e /lib/firmware/${fw} ]; then
 echo ${fw}
   fi
 done
 
 I guess you can do something similar with vmlinux.bin if compiling
 modules into kernel.

Last I looked into that the list of firmwares needed by built-in drivers
is not available as is the case for modules (and in addition those
built-in drivers may need the firmware long before /lib/firmware/ is
available)

Bruno

 Looking into kernel sources is more robust, but
 gets annoying fast. Full script I am using is here:
 https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares
 
 You can encounter superfluous warnings with modules that support
 multiple firmware subversions (e.g., iwlwifi).

Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)

Am Sonntag, 10. Februar 2013, 16:02:55 schrieb Andreas K. Huettel:
 Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:
 
  I suspect most people are interested in understanding what changed
  (since deprecation means that the new thing is better than the old
  one). Moreover, the news item is another way to assure them that
  everything is not as bad as the initial red warning might had made
  them think so and keep calm and use Gentoo ;-)
 
 OK, here's a news item (actually two, separate for server and non-server
 profiles). Since it's a bit late now, I'll commit this or the improved
 version after discussion here in 6h (21:00 UTC) unless there are severe
 protests.
 

And pushed.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

On Sun, Feb 10, 2013 at 10:41 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
 Honestly while I agree this could have been handled a little more
 carefully we all win by having ONE place for firmware.  The firmware
 package is like 20MB, if you don't have that much free harddrive space
 then you can use the savedconfig option to tune for just your hardware

It's ~45MB when extracted, but the issue is not just with space, since
on a proper Gentoo system firmware is about the only thing that's
not compiled from source (besides less significant stuff like fonts,
many of which can be optionally compiled anyway). Combined with
various less-than-free licenses, installing one huge blob of firmware
is problematic for many users, also from a security point of view.

 Having 300 -firmware packages is silly.

I agree, but think that the process can be more user-friendly than a
savedconfig — perhaps a variable as was suggested already.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread James Cloos

 AKH == Andreas K Huettel dilfri...@gentoo.org writes:

AKH To be honest I did not really see the necessity since the big red
AKH warning exactly tells you what to do (and even which profile to
AKH pick, which would be more complicated in a news item).

But it doesn't tell one why the change was made, what differences to
expect once it is done.

What does:

diff -uNr profiles/default/linux/amd64/10.0/eapi 
profiles/default/linux/amd64/13.0/eapi
--- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 -0400
+++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 -0500
@@ -1 +1 @@
-2
+5

actually *do* to one's system?

A useful news item would have explained what was changing, why it was
done, and what to expect once one makes the change.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] Re: News item

2013-02-10 Thread James Cloos

Since I just sent a why to post a news item note, that exactly covers
things.

Thanks!

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-10 Thread Alec Warner

On Sun, Feb 10, 2013 at 1:06 PM, Bruno bonbon...@internet.lu wrote:
 On Sun, 10 February 2013 Maxim Kammerer m...@dee.su wrote:
 On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
  I agree as I have also needed to google and search in forums to get
  proper firmware installed in the past in some machines :/

 for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
 -n 's/^firmware=//p' | sort -u); do
   if [ ! -e /lib/firmware/${fw} ]; then
 echo ${fw}
   fi
 done

 I guess you can do something similar with vmlinux.bin if compiling
 modules into kernel.

 Last I looked into that the list of firmwares needed by built-in drivers
 is not available as is the case for modules (and in addition those
 built-in drivers may need the firmware long before /lib/firmware/ is
 available)

Most external firmware is not needed to boot. If you need it to boot,
you will have to stow it in the initramfs.

-A


 Bruno

 Looking into kernel sources is more robust, but
 gets annoying fast. Full script I am using is here:
 https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares

 You can encounter superfluous warnings with modules that support
 multiple firmware subversions (e.g., iwlwifi).

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

2013-02-10 Thread Douglas Freed

 Combined with various less-than-free licenses, installing one huge blob of
 firmware is problematic for many users, also from a security point of
view.

How does having additional firmware installed affect security at all?
Firmware is only loaded when specifically requested by a loaded driver that
needs to use it, and only if that driver is actually in use.  That's like
saying a file that can only be written to by root, only normally read when
it's specifically needed, and if for some stupid reason is executed by an
unprivileged process will just result in a crash, affects security (hint: I
just described firmware).

-Doug

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Michał Górny

On Sun, 10 Feb 2013 17:06:39 -0500
James Cloos cl...@jhcloos.com wrote:

  AKH == Andreas K Huettel dilfri...@gentoo.org writes:
 
 AKH To be honest I did not really see the necessity since the big red
 AKH warning exactly tells you what to do (and even which profile to
 AKH pick, which would be more complicated in a news item).
 
 But it doesn't tell one why the change was made, what differences to
 expect once it is done.
 
 What does:
 
 diff -uNr profiles/default/linux/amd64/10.0/eapi 
 profiles/default/linux/amd64/13.0/eapi
 --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 -0400
 +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 -0500
 @@ -1 +1 @@
 -2
 +5
 
 actually *do* to one's system?

Out of curiosity, does portage suggest switching to the new profiles
even if it doesn't support its EAPI?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

Am Montag, 11. Februar 2013, 00:34:19 schrieb Michał Górny:

  
  actually *do* to one's system?
 
 Out of curiosity, does portage suggest switching to the new profiles
 even if it doesn't support its EAPI?

Unfortunately, it seems yes. (Feature request?)

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Zac Medico

On 02/10/2013 03:34 PM, Michał Górny wrote:
 On Sun, 10 Feb 2013 17:06:39 -0500
 James Cloos cl...@jhcloos.com wrote:
 
 AKH == Andreas K Huettel dilfri...@gentoo.org writes:

 AKH To be honest I did not really see the necessity since the big red
 AKH warning exactly tells you what to do (and even which profile to
 AKH pick, which would be more complicated in a news item).

 But it doesn't tell one why the change was made, what differences to
 expect once it is done.

 What does:

 diff -uNr profiles/default/linux/amd64/10.0/eapi 
 profiles/default/linux/amd64/13.0/eapi
 --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 
 -0400
 +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 
 -0500
 @@ -1 +1 @@
 -2
 +5

 actually *do* to one's system?
 
 Out of curiosity, does portage suggest switching to the new profiles
 even if it doesn't support its EAPI?

Yes, although it's possible to include additional instructions in the
deprecated file, as you can see in the code here:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=pym/portage/package/ebuild/deprecated_profile_check.py;h=2acf8e3c2e189eb76cfda2ad4743ce238fc81230;hb=HEAD

It interprets all lines after the first one as upgrade instructions.
-- 
Thanks,
Zac

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 04:45 PM, Maxim Kammerer wrote:
 On Sun, Feb 10, 2013 at 10:41 PM, Rick Zero_Chaos Farina
 zeroch...@gentoo.org wrote:
 Honestly while I agree this could have been handled a little more
 carefully we all win by having ONE place for firmware.  The firmware
 package is like 20MB, if you don't have that much free harddrive space
 then you can use the savedconfig option to tune for just your hardware
 
 It's ~45MB when extracted, but the issue is not just with space, since
 on a proper Gentoo system firmware is about the only thing that's
 not compiled from source (besides less significant stuff like fonts,
 many of which can be optionally compiled anyway). Combined with
 various less-than-free licenses, installing one huge blob of firmware
 is problematic for many users, also from a security point of view.
Licenses are licenses, we all feel the same about non-free things.  I
whole heartedly disagree about the firmware, having a firmware on your
system doesn't affect security, sorry, it just doesn't.
 
 Having 300 -firmware packages is silly.
 
 I agree, but think that the process can be more user-friendly than a
 savedconfig — perhaps a variable as was suggested already.
 
I am marked maintainer of linux-firmware due to my desire to make sure
wifi related things work.  I have no desire at all to implement use
expand for this, HOWEVER, I am willing to accept a patch for that if it
comes out even close to sane.

- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGDKiAAoJEKXdFCfdEflKBYkQAItoT8QdhnP4V0Nu+BkUqozP
fPzDQjPbIXh0JMuVJ56zmXZ5oeiClFdcysf7vZ2sLFl4d2UPsz5EC+5Bk9ryJvjg
YrLRmT5cHuZYacW7hNTgfW7Z3gg9oqJU73dn6rUvu3dGUlN3w/Z9UGXeIj+yzmzR
w65pD9DLcQ4kPN5ekOhhznaCLANW7cVVQ4FgNDPZwAGpeUd/+OMlltNFrCcF4p4Z
/cleFDfZmw01iO86oXKkAoevD7M1Twa9aHqNwxb6xcdagmPSnXhD+TsIFAvZgsdU
+5xHL3sD6v5GJHf17lZvkHQxzKFVBqMJmuBW4lx599RDh5QgHK/RMC9bti9+adAu
JNEQfC6VBQ48azrhc8BF/5bqZ5E0Rghppr7SRpjM5no0FDeGLo6Um47WTAY15CWj
e2xqDJw1S7tWfPjqzz0IEUGHNCHfhm3s+kEQ6uYOuMqRXlJREhZ44PjxLsHBSOQs
e+WHj23LujoJ5XqmtTQlMwTa+hzSUR+a8tUmrEu15uwiZWV4wsyoLhdNEPE5cAU5
s4/E10eVmuN65Lz7hYFTBy+irA5r3ugP43m4TzegrkclroCPbSbf65GcDk32hlTO
qpw3xjEdcXu+ltUJgaNFueC57N0fPaZBNdPuyQKa1pSxHgfJvl6GiO8EWFqtM66s
t2rv7REVyIgt8zPYRb08
=9fk8
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

On Mon, Feb 11, 2013 at 1:12 AM, Douglas Freed dwfr...@mtu.edu wrote:
 How does having additional firmware installed affect security at all?
 Firmware is only loaded when specifically requested by a loaded driver that
 needs to use it, and only if that driver is actually in use.  That's like
 saying a file that can only be written to by root, only normally read when
 it's specifically needed, and if for some stupid reason is executed by an
 unprivileged process will just result in a crash, affects security (hint: I
 just described firmware).

I can play captain obvious, too. Regardless, having to explicitly
enable firmware based on need (e.g., after installing a wireless card)
provides for more security. For instance, the user can opt to not
enable the firmware and not use the card, if he doesn't trust
manufacturer's software development process. If only the firmware that
is actually used is installed, it is easier to go over it and review
its security. Some firmware has multiple subversions, with the kernel
being able to use any of them; some may be more trusted than others.
Some firmware may be unnecessary for correct functioning of hardware,
but is still loaded when available. All of these are valid reasons for
not installing all possible firmware. Don't assume that your use case
is identical to everyone else's.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

On Mon, Feb 11, 2013 at 1:52 AM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
 I am marked maintainer of linux-firmware due to my desire to make sure
 wifi related things work.  I have no desire at all to implement use
 expand for this, HOWEVER, I am willing to accept a patch for that if it
 comes out even close to sane.

It is possible to start with something much simpler but still very
useful: savedconfig in rsync include format, for glob patterns
support.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-02-10 23h59 UTC

2013-02-10 Thread Robin H. Johnson

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2013-02-10 23h59 UTC.

Removals:
x11-themes/oxygen-gtk3  2013-02-07 04:13:24 zx2c4
dev-python/wsgiref  2013-02-07 19:02:23 
prometheanfire
sys-apps/coldplug   2013-02-08 17:33:42 
ssuominen
sys-apps/hotplug2013-02-08 17:33:42 
ssuominen
sys-apps/hotplug-base   2013-02-08 17:33:43 
ssuominen
sys-apps/ezusb2131  2013-02-08 17:34:32 
ssuominen
media-sound/logitechmediaserver-bin 2013-02-10 07:57:13 pacho
net-dialup/misdn2013-02-10 07:58:50 pacho
net-dialup/misdnuser2013-02-10 07:59:17 pacho
net-misc/asterisk-chan_misdn2013-02-10 07:59:48 pacho
www-apache/mod_authn_pam2013-02-10 08:02:03 pacho
net-dialup/ltmodem  2013-02-10 08:03:08 pacho
www-apache/mod_spin 2013-02-10 08:04:54 pacho
dev-dotnet/galago-sharp 2013-02-10 08:07:01 pacho
sys-apps/galago-daemon  2013-02-10 08:07:20 pacho
dev-libs/libgalago  2013-02-10 08:07:40 pacho
www-apache/mod_transform2013-02-10 08:08:36 pacho
dev-util/monodevelop-java   2013-02-10 08:14:53 pacho
dev-util/monodevelop-python 2013-02-10 08:15:21 pacho
dev-util/monodevelop-vala   2013-02-10 08:15:46 pacho
app-admin/flexlm2013-02-10 08:16:19 pacho
net-misc/cisco-vpnclient-3des   2013-02-10 08:16:58 pacho
app-emulation/systemsim-cell2013-02-10 08:17:46 pacho
sys-block/gcloop2013-02-10 08:19:18 pacho
mail-client/claws-mail-geolocation  2013-02-10 08:27:18 pacho
app-admin/profiler  2013-02-10 08:32:39 pacho
app-admin/smolt 2013-02-10 08:36:04 pacho

Additions:
games-rpg/manaplus  2013-02-04 18:23:28 hasufell
net-misc/socket 2013-02-04 21:09:13 pinkbyte
dev-python/liblarch 2013-02-04 22:29:42 eva
app-admin/clustershell  2013-02-05 14:10:48 hasufell
dev-games/aseprite  2013-02-07 00:45:59 tomwij
x11-themes/oxygen-gtk3  2013-02-07 02:59:03 zx2c4
kde-base/picmi  2013-02-07 04:57:04 alexxy
kde-base/print-manager  2013-02-07 04:57:13 alexxy
kde-base/nepomuk-widgets2013-02-07 04:57:14 alexxy
sys-apps/flock  2013-02-07 15:18:01 aballier
dev-ml/menhir   2013-02-07 20:36:44 aballier
dev-ml/macaque  2013-02-07 20:43:32 aballier
www-servers/meteor  2013-02-07 22:13:06 tomwij
dev-util/trinity2013-02-07 22:51:32 
radhermit
net-irc/iroffer-dinoex  2013-02-08 11:44:38 pinkbyte
dev-libs/UTF8Strings2013-02-08 14:35:16 tomwij
net-wireless/dump1090   2013-02-08 17:23:51 xmw
dev-perl/Devel-Hide 2013-02-09 12:55:28 tove
dev-haskell/findbin 2013-02-09 18:54:42 slyfox
sys-apps/lnxhc  2013-02-09 18:59:10 creffett
dev-util/cdiff  2013-02-09 20:15:38 tomwij
sci-geosciences/gpxpy   2013-02-09 22:24:25 xmw
dev-python/rply 2013-02-10 06:51:59 patrick
dev-perl/Test-LeakTrace 2013-02-10 07:32:41 tove
dev-perl/Unicode-UTF8   2013-02-10 07:33:57 tove
sys-apps/iotools2013-02-10 09:47:52 vapier
app-crypt/ima-evm-utils 2013-02-10 10:23:44 swift
sci-geosciences/cdat-lite   2013-02-10 20:19:08 hasufell
sci-geosciences/harmonics-dwf-free  2013-02-10 20:28:41 hasufell
sci-geosciences/libtcd  2013-02-10 20:45:55 hasufell
sci-geosciences/congen  2013-02-10 20:55:36 hasufell
sci-geosciences/xtide   2013-02-10 21:08:30 hasufell
sci-geosciences/tcd-utils   2013-02-10 21:13:46 hasufell
sci-geosciences/tappy   2013-02-10 22:13:59 hasufell

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 07:18 PM, Maxim Kammerer wrote:
 On Mon, Feb 11, 2013 at 1:52 AM, Rick Zero_Chaos Farina
 zeroch...@gentoo.org wrote:
 I am marked maintainer of linux-firmware due to my desire to make sure
 wifi related things work.  I have no desire at all to implement use
 expand for this, HOWEVER, I am willing to accept a patch for that if it
 comes out even close to sane.
 
 It is possible to start with something much simpler but still very
 useful: savedconfig in rsync include format, for glob patterns
 support.
 
Again, I don't have the time (or desire) to implement this at this time.
 If you have an idea which you think will be sane and an improvement
then by all means, please submit it to me when you are ready.

Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGD6JAAoJEKXdFCfdEflKnJYQAKsW3Mqk9/ru47FekY6DEqYZ
3ebMgPSAe99Pqdm2XhDknlZnAxL5/yAdQnls5TWEFqAx7GynaJ3fwpHBtoOa0pp+
tVmS3a/J86McaNQfisMekFnY70fJBw8hT+w343UKIx51RLuQGPTiWK26dku4MnCc
hkVjFQCzxPeayxXslWKblo8Fi3nD2XQxgejeXsXcEddli5WRXgVhO+GPea6KgeTW
qnpj7x1dqEAqFWewx0Os843GK6hwmdWo3O0y9GcAjyyI8H9+age2A6qDaqevs2dK
L7qBr13moyeENnVoJSDFr9KZ0y9u3dI/+8Ap8MUn8yI1hB92bRuH9CldN2rOgNir
/a1zcDs4NNwzimZ1P8/NyD71mP9SJhQkKPdnDeMj+Ck6iUB9bpEqXERAhckmamzt
0O8udf88++5MiuFNW6ju3/VOpS+MV0rFXLztDgVOXoUvE/e2O6MgUnlo0+Mr9EHJ
tribU2UlvkkLyfnw44pfkv1zuo/gFkImjlZTOGzfW5iBwdi47dXh7447CoKUHFs+
OWnCAy9c/461uAUD6rizgKXO9tYfxZPBKdEpmJJiBmUz07q86lylKvzCSC0eAcTh
ZOjKS5nbxlqjzstEpcDBrFYrPamFzJHg1q3VeN0+WrA6bhZxXm0RMWpfr2L0aztc
kS2EoEhpdBjDUj7RmMZk
=pPeq
-END PGP SIGNATURE-

Re: [gentoo-dev] On the good usage of subslots

2013-02-10 Thread Alexis Ballier

On Sat, 9 Feb 2013 20:21:56 +0100
Michał Górny mgo...@gentoo.org wrote:

 On Sat, 9 Feb 2013 09:15:03 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  I hope this will be trivial to most of you but after seeing bug
  #455900 and the vast majority of developers not even thinking twice
  before sedding their dep strings, I believe this needs some
  attention.
 
 As a note for those who get irritated with those webkit-gtk:
 
--ignore-built-slot-operator-deps  y | n 
   Ignore the slot/sub-slot := operator parts of
 dependencies that have been recorded  when  packages  where  built.
 This option is intended only for debugging purposes, and it  only
 affects  built  packages  that  specify slot/sub-slot := operator
 dependencies which are supported beginning with EAPI 5.
 
 Sadly, there's probably no way to ignore them only for cases when they
 are completely useless, leaving the meaningful uses alone.

Well, if we have to advertise the usage of this option that basically
disables subslot rebuilds, it only means we are doing something
seriously wrong with subslots :=)

Alexis.

Re: [gentoo-dev] Re: On the good usage of subslots

2013-02-10 Thread Alexis Ballier

On Sun, 10 Feb 2013 01:09:38 +1100
Michael Palimaka kensing...@gentoo.org wrote:

 On 9/02/2013 23:52, Alexis Ballier wrote:
  On Sat, 09 Feb 2013 23:38:35 +1100
  Michael Palimaka kensing...@gentoo.org wrote:
 
  I even noticed some maintainers adding subslots dependencies on
  libraries that do not yet define subslots. This too seems
  reasonable, given that there would be no impact until the library
  defines a (sensible) subslot in the future.
 
  By the way, this could also be discussed: I did not check, but as
  far as I understand it subslot is equal to slot if not defined.
  When said library defines a subslot, the subslot will change and
  thus triggers a (likely useless) rebuild of your package setting
  a := dep.
 
  Alexis.
 
 
 
 Yeah. This behaviour can be avoided by introducing the explicit
 subslot only when the subslot would otherwise need bumping.

I would not count on that as this would mean extra care has to be taken
when adding a subslot.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

2013-02-10 Thread Alexis Ballier

On Sat, 09 Feb 2013 15:12:15 +0100
Luca Barbato lu_z...@gentoo.org wrote:

On 08/02/13 22:46, Alexis Ballier wrote:
On Fri, 08 Feb 2013 22:41:04 +0100
Maciej Mrozowski reave...@gmail.com wrote:

On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:

Tomáš Chvátal wrote:
we as gentoo will provide both while preffered default will be
what major distros use.

What kind of careless mainstream attitude is that? Really?

Quite the opposite, decision to use implementation A over B was
taken with utmost care for user in mind.

Not really. I was promised a discussion that hasn't happened yet.

I'm available for discussion anytime, I got a little busy in the past
days and I will busy the next 3 days, but I should be available today
evening or now.

Sorry, I was away this week end...

I stated already what I think about the whole discussion in a blog
post.

I'm not fond of discussions via blog posts and do not think it is
the right media. I wrote one only to make it clear the decision was
not anything near a general consensus, when Tomás made it sound like it
was.

To summarize it my take is quite simple, Libav leads the way regarding
the main API,

This is only because libav people do not care at all about what FFmpeg
defines, while FFmpeg seems to care more about its consumers and users
by trying to provide a compatible ABI and API. Moreover, this is not
true at all when it comes to the parts where supporting both forks is
painful: libavfilter and audio resampling. It is pretty clear that the
audio resampling wheel was reinvented on the libav part, with a
different library name and in 95% of its use cases going from ffmpeg's
audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'.
Some parts of libavfilter also appeared later in libav, sometimes with
a slightly different API, making it really awful to support both forks
in applications.
(I'm still looking forward a patch for xbmc and upstreamed patches for
mplayer btw)

it offers a more compact surface for attacks if you are
really concerned about security and usually it is a little more
compact

If you mean that ffmpeg is libav + ffmpeg additions, then yes.
However, if you are concerned by a more compact surface, then libav is
not the right answer: you can very well disable selected codecs,
(de)muxers, etc at build time. I even started to work on reflecting this
into an ebuild some years ago before reaching the conclusion that it
would be confusing for little to no gain. This can of course be done if
there is some demand, but so far I have not seen any.

It is funny to see how libav ignores completely ffmpeg even for
bugfixes, I stumbled over this recently and it sounded familiar:
http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d
vs
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b
now, you can look at the dates, there's a one year lag in libav for
reinventing the same bugfix. This is for a format almost nobody uses,
but in any case I do not consider this attitude sane.

and a bit more tested over a wider range of architectures.

If you are talking about fate, then I cannot comment. fate started
before the split, so I assume the owners of said test machines took
them within their respective fork.

I'm not for removing ffmpeg overnight since there are features that
might be of use and I'm not so hypocrite to value diversity only when
it is in favor of my interests.

Nobody talked about removing anything :)

That said as long the two project are compatible having one or another
as default is just a matter of making our life easier.

I fully agree there, but you should be careful with who you include in
'our'. In the case of a default then it is clearly 'the users'. Now,
considering there are a couple (very few) of packages that do not
compile with libav, do you consider having it as default a good idea?
Those packages can very well be fixed, but if patches do not go
upstream, this is not going to work in the long term. Also, the only
reason why I have not pinned those packages to depend only on
media-video/ffmpeg is because libav is not the default (not entirely
true btw, see later), meaning those that use libav are those that are
willing to help and know what they are doing. If people are to get
libav by default and then hit compile failures to be told to use
ffmpeg, then it is QA 101 that these packages should be depending on
media-video/ffmpeg.

[...]
Few large projects such as VLC and Gstreamer switched to Libav as
their default.

... and chrome, mplayer, xbmc use ffmpeg :=)
also as I said in another email, I have yet to see a libav based vlc
release.

Since Libav is the no-frills variant, notwithstanding the interesting
campaign of we have more security11ein! less stuff should break
since it is usually more tested and once we gather the samples
triggering a crash usually we do not stop preventing that single

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-02-10 Thread Zac Medico

On 02/10/2013 03:45 PM, Andreas K. Huettel wrote:
 Am Montag, 11. Februar 2013, 00:34:19 schrieb Michał Górny:
 

 actually *do* to one's system?

 Out of curiosity, does portage suggest switching to the new profiles
 even if it doesn't support its EAPI?
 
 Unfortunately, it seems yes. (Feature request?)

It's possible to include additional instructions in the deprecated file.
All lines after the first one as upgrade instructions.

For future portage versions, I've fixed it to behavior better:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=34d8c817080f34f1a0b44cf05b99beacfc0d6314

This fix updates the profile deprecation warning to look like this:

!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:
default/linux/x86/13.0/desktop

!!! Unable to parse profile:
'/usr/portage/profiles/default/linux/x86/13.0/desktop'
!!! ParseError: Profile contains unsupported EAPI '5':
'/usr/portage/profiles/eapi-5-files/eapi'

 * You must update portage before you can migrate to the above profile.
 * In order to update portage, run 'emerge --oneshot portage'.
-- 
Thanks,
Zac

Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory

2013-02-10 Thread Doug Goldstein

On Fri, Feb 8, 2013 at 11:53 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 Any objections if I slap a generic package.mask on every firmware package
 installing to wrong directory?
 Half of them install to /$(get_libdir)/firmware as opposed to correct
 /lib/firmware.
 Most of them are maintainer-needed@ and very old.

 Then intrested parties get to fix what they want and unmask?

 - Samuli


Whatever is correct and sticks should have a pkgmove added so that
users don't have long lasting issues.

-- 
Doug Goldstein

Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory