date:20130116

On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge pe...@stuge.se wrote:
 Rich Freeman wrote:
 Not that anybody is taking requests, but it would be really handy
 if serial ports were deterministically labeled.

 Does /dev/serial/* solve the problem?

I don't see this directory at all on my system.

Rich

Re: [gentoo-dev] Chromium system ffmpeg

On Tue, 15 Jan 2013 21:10:12 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 On 1/15/13 4:55 AM, Alexis Ballier wrote:
  On Mon, 14 Jan 2013 20:34:42 -0800
  Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
  I'm trying to make Chromium be more compatible with more versions
  of ffmpeg:
  https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
  (although not stated there, that includes libav).
  
  I've done quite a lot of work for various packages among the past
  years on that side, so if you have specific questions, feel free to
  ask.
 
 Alright:
 
 1. What's the difference between libav and ffmpeg? Do the projects
 merge each other's changes? If not, in what direction do patches flow?

ffmpeg merges daily from libav; for libav, better ask Luca or Diego I
think, but I've seen they manually port some patches from ffmpeg from
time to time.

 2. What are API compatibility policies for ffmpeg and libav?

There's no policy AFAIK. For what I understood, libav doesn't care;
ffmpeg tries to be API and ABI compatible with libav (ie: provide the
same API and ABI + their additions)

 3. Same as above for making releases (i.e. how frequent they are, how
 much they change, and how much released libav and ffmpeg are in sync
 with each other in practice).

libav release schedule is independent; in the last years, ffmpeg
releases have been more frequent and there's always been a ffmpeg
release on par with a libav release (now we have libav-9 and ffmpeg-1.1
that should be on par)

 4. What are typical incompatibilities (if possible), and usual ways to
 deal with them?

For most of the API, there's none, but because of the above, during the
years, small incompatibilities have accumulated and you can see them
between the supposed to be on par releases. For example, libavfilter
differs a lot between the two; the major/minor/micro versions are
completely different between the two (usually you do #if version  foo
conditions which become messy if you want to support both).

 5. Do you think it's possible / worth trying to convince upstream
 ffmpeg / libav to have a more stable API over time? Which one could
 be possibly more willing to listen and why?

It is already the case for both: once a symbol / API is deprecated at
major release N, it's still there at major N+1 and removed at major N+2.
That's why I told you if you build without any deprecation warning,
you should be safe for some time :)

[...]
  What is the min. version it works with?
 
 Currently, for masked system-ffmpeg USE flag for chromium, it's
 ffmpeg-1.0.

And what is the problem with, say, 0.10.6 ?

  As a distro we have two options:
  1) patch chromium to add #if's for older ffmpeg versions and be
  compatible: this may or may not be accepted by upstream, supporting
  older versions is just garbage code for them.
 
 I'm pretty sure upstream won't accept trench warfare #ifdefs (I'm
 also an upstream dev). I'm also not enthusiastic about having an
 out-of-tree Gentoo-side patch for a fast-moving project like that.
 The additional cost on each version bump is also something to take
 into account (fixing incompatibilities is one thing, but I'm also
 thinking about like merge conflicts on the patches).
 
  2) (preferred) coordinate the other packages to be compatible with
  newer versions and unmask latest (we should be very close to be
  able to unmask ffmpeg-1) and make chromium require this version
  (this require chromium upstream to figure out what is the min. req.
  version)
 
 What when chromium upstream uses code more recent than latest ffmpeg
 release and it doesn't compile against latest release?

Blame them, it's stupid to break support for the latest release.
Usually, it's quite trivial to maintain compatibility and you should
probably lobby upstream to get this as a rule, it'd make life simpler
for everyone. Or just patch releases not to use too bleeding-edge code
(see mplayer for example).

 Now what about libav? At one time I could compile against latest
 masked ffmpeg in tree but couldn't compile against latest masked
 libav (or any other version of it I think). Ideally I would like to
 make it compilable against both. Does that sound like much more
 difficult?

It depends what the problem is: it may be just some missing #includes,
some CODEC_ID present in ffmpeg but not in libav in which case you'd
have to #ifdef its usage out, or more complicated if you use an API
from ffmpeg not in libav like some libavfilter stuff.
 
  we should probably do something in-between 1 and 2 in order not to
  hold off sec. stabilizations of chromium because dozens of stable
  packages do not build with latest ffmpeg.
 
 Yup. Just note there is just ~6 weeks before each stable release.
 That's not a very long time for most projects, and I think we won't
 get other packages into shape that quickly.

Probably, unfortunately. We could do like for mplayer then, patch it so
that it builds with current releases.

[...]
  Usually, if you

Re: [gentoo-dev] Chromium system ffmpeg

On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier aball...@gentoo.org wrote:
 On Tue, 15 Jan 2013 21:10:12 -0800
 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 What when chromium upstream uses code more recent than latest ffmpeg
 release and it doesn't compile against latest release?

 Blame them, it's stupid to break support for the latest release.
 Usually, it's quite trivial to maintain compatibility and you should
 probably lobby upstream to get this as a rule, it'd make life simpler
 for everyone. Or just patch releases not to use too bleeding-edge code
 (see mplayer for example).

While I agree in principle, that is much easier said than done.  I
think upstream is more likely to consider the concept of a linux
distro broken than their code.

The unpacked chromium distfile is 1.1G, of which 694M is third party
source-code.  The chromium team has done an excellent job of disabling
much of that, but the upstream attitude clearly is to cherry-pick
their dependencies.  This is pretty typical for Google projects from
what I've seen - ChromeOS basically is a fork of Gentoo with many
packages being fairly dated, and Android does just about everything
its own way, typically releasing third-party code into production
before any upstream packages have access to it.

Of course, we should encourage upstream to improve its practices.  I
just wouldn't count on it, so I think we need to give the chromium
team discretion on just how much patching they think they can handle.
They're obviously pretty good at it already.

Rich

Re: [gentoo-dev] Chromium system ffmpeg

On 15/01/13 05:34, Paweł Hajdan, Jr. wrote:
 I'm trying to make Chromium be more compatible with more versions of
 ffmpeg:
 https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
 (although not stated there, that includes libav).
 
 Now the initial response there is not enthusiastic (which doesn't
 surprise me), but do you think there are some points useful for the
 discussion I'm not aware of?
 
 What are the main challenges of keeping up-to-date with latest ffmpeg
 API changes? How do other projects deal with that?

I guess it had been stated there, but is worth noting again that
chromium has a specific fork of ffmpeg and they merge and adapt/fix as
they need.

As Libav we try to see what they are doing and when possible either
import their fix or redo it in a more general way if it doesn't fit
normal consumption (see our review process policy for more details).

Their API usage is quite normal nowadays (after we convinced them to use
AVIO instead of the deprecate URLProtocol, for our and their respective
pleasure since it resulted in slashing a good chunk of cruft)

Feel free to nag me if something breaks with a system libav.

lu

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: linux-info.eclass

2013-01-16 Thread Markos Chandras

On 14 January 2013 21:19, Mike Frysinger (vapier) vap...@gentoo.org wrote:
 -   local   RESULT
 -   local config
 +   localRESULT config

There is a typo^^^ here leading to errors like this

 * QA Notice: command not found:
 *
 *  /usr/portage/eclass/linux-info.eclass: line 326: localRESULT:
command not found

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Panagiotis Christopoulos

On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0 transition would 
 be a good moment to finally remove the (also in my opinion rather useless) 
 server profiles. 
 

The server profiles are not useless, if we can maintain them, and if
they actually are, nowadays, they shouldn't be.

-1, unless other profile options being offered are minimal enough for the job 
and enabling certain things that someone may need in a server. 

-- 
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )


pgppYe9oEAYWg.pgp
Description: PGP signature

Re: [gentoo-dev] Chromium system ffmpeg

On 16/01/13 12:54, Alexis Ballier wrote:
 On Tue, 15 Jan 2013 21:10:12 -0800
 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
 
 On 1/15/13 4:55 AM, Alexis Ballier wrote:
 On Mon, 14 Jan 2013 20:34:42 -0800
 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
 I'm trying to make Chromium be more compatible with more versions
 of ffmpeg:
 https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
 (although not stated there, that includes libav).

 I've done quite a lot of work for various packages among the past
 years on that side, so if you have specific questions, feel free to
 ask.

 Alright:

 1. What's the difference between libav and ffmpeg? Do the projects
 merge each other's changes? If not, in what direction do patches flow?
 
 ffmpeg merges daily from libav; for libav, better ask Luca or Diego I
 think, but I've seen they manually port some patches from ffmpeg from
 time to time.

Libav has defined review rules so patches get hand picked and discussed
as any other contributions, there isn't any kind of fast track.

If somebody wants something in ffmpeg, ffmpeg-chromium,
${personal_libav_fork} and such, can just pick the patch and send over
the mailing list.

 2. What are API compatibility policies for ffmpeg and libav?
 
 There's no policy AFAIK. For what I understood, libav doesn't care;

As said above our development policy is quite simple. Regarding API
changes they get discussed as for any other patch, new API can land on
the master, old api gets removed after a major release deprecating it.

 3. Same as above for making releases (i.e. how frequent they are, how
 much they change, and how much released libav and ffmpeg are in sync
 with each other in practice).

In general we aim to have a major release per season, depending on how
involving the update is we postpone till downstream catches up.

Point releases happen when enough bugfixes are piled up. Usually we keep
one or two major release in maintainance mode (releases and fixes) while
we develop the next one.

For the release 9 branch I'm trying to keep the fixes in sync so people
doesn't have to backport them in mass.
Release branches 0.8 and 0.7 are synced more seldom.

 4. What are typical incompatibilities (if possible), and usual ways to
 deal with them?

Use only the common subset, e.g. Do not use swresample and use avresample.

 5. Do you think it's possible / worth trying to convince upstream
 ffmpeg / libav to have a more stable API over time? Which one could
 be possibly more willing to listen and why?

Libav API is evolving but you have about 1/2 year or more to update.

 What when chromium upstream uses code more recent than latest ffmpeg
 release and it doesn't compile against latest release?

They will gladly tell you that the patches they use are available and
you should nag upstream.

Jokes aside, tell us and in a way or another you'll have something working.

 Now what about libav? At one time I could compile against latest
 masked ffmpeg in tree but couldn't compile against latest masked
 libav (or any other version of it I think). Ideally I would like to
 make it compilable against both. Does that sound like much more
 difficult?
 
 It depends what the problem is: it may be just some missing #includes,
 some CODEC_ID present in ffmpeg but not in libav in which case you'd
 have to #ifdef its usage out, or more complicated if you use an API
 from ffmpeg not in libav like some libavfilter stuff.

Usually Libav does not expose private API and depending on the release
timing you might find software not updated fully (see about about the
6-8 months of grace time)

 Yup. Just note there is just ~6 weeks before each stable release.
 That's not a very long time for most projects, and I think we won't
 get other packages into shape that quickly.

If then need arises I think we can snapshot, a monthly point release
might be coordinated if enough people need it.

 I could make a leightweight compatibility layer, don't underestimate

Better nag me till your problem isn't solved on our side, chromium is
huge and making changes on the media part of it is gorier than you'd expect.

lu

Re: [gentoo-dev] January stabilization candidates

2013-01-16 Thread Rick Zero_Chaos Farina

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/12/2013 05:49 PM, Paweł Hajdan, Jr. wrote:
 Please review attached automatically generated stabilization candidates
 for January.
 
 I don't want to annoy people with automatically filed bugs, and at the
 same time I also received lots of positive feedback about the effort to
 keep the stable tree more up-to-date.
 
 I think the best way to proceed is to listen to that feedback and
 continue the effort, while also keeping an updated list of exclusions
 for packagers/herds that are actively stabilized by maintainers.
 
 Paweł
 


net-wireless/b43-fwcutter-017

be my guest, although I prefer the bugs personally.

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

iQIcBAEBAgAGBQJQ9rIDAAoJEKXdFCfdEflKnDoQALfr9pMXLYw9R7WvCpcZ9lpj
yUUlSdLl5TS5ZnwxAM4cRG+VuoPEzn/1QQwh9VavFkfb09acRqaz4azeXMqkSdnt
OthaylBKe2AwmAi7CYnmsyKFo6WSe+Nwl0pNNOoiw9JhOa/TwJzYDgqbQdCGZrB7
WkIjgngZ1I4/YYownNyTJ+TWD6pwEnbN3/pmbcKHwDrh4+/IPgDRcycVevr6l1jF
8adIOfDxgnmB823acboY5oJdgNe40+kajLXpLrXbiVUM1LPyPgwCXHX88hyyCFC6
qb6umJHSgQ7M1EC7KQWagnUpSYfehtp/eHFfLK5D8/7w60Vg3n5bJOTxq5yrXDwN
PmdiamCTXbz7pIwFyJK7ryYYZgQ6LBvAcfZwxIFZcBeDkPjY8ktfA+yzdUEiz3D+
wZxNCfw7Y8ETWvs9biN4Br2G2YXe3HSCzXgo4SiEscom1H4+OryYWINhqKsGBd31
lvB4fBw/rl5Ca+6lUYhSH3/5l6WIJzZV55qbOMUhopMlttL2xFNDXrwiEzTn9br9
SVIiW+nm2azWxiHRhsbzVOYoocifxDzNPw5DTZjl3KhJgPqazQpe3kBbA+6A+v2y
7YHQRzTjfTTcjt+2wN/3ljmq+MOfxRkKfEOCE2iFhw3AUXyI49DgEOB47eQzHH0l
JUk4p7iDqCE5YtqhtaME
=8OSJ
-END PGP SIGNATURE-

Re: [gentoo-dev] January stabilization candidates

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

 I don't want to annoy people with automatically filed bugs, and at
 the same time I also received lots of positive feedback about the
 effort to keep the stable tree more up-to-date.
you can add me to the whitelist for bug filing.
Would you mind adding my
# xmw
app-laptop/thinkfan-0.8.1-r1
Thanks!

 I think the best way to proceed is to listen to that feedback and 
 continue the effort, while also keeping an updated list of
 exclusions for packagers/herds that are actively stabilized by
 maintainers.

Do you/we have any ready-to-use script to file stable requestst?
I know it's just dome lines of python but I'm lazy.
To lazy to get all these 10-something clicks'n'paste right to file
such bugs on first attempt.

Michael

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlD2tEgACgkQknrdDGLu8JCXjwEAmnSj0mvW7hxJgNHSux+P0P/I
ikSyI6XM357KIvU7DX0BAI1Nb6IyKJUq2GNhJCMUaX9RAEL1BvZLczPq+uCAkPvU
=X8G6
-END PGP SIGNATURE-

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Michael Mol

On Wed, Jan 16, 2013 at 8:32 AM, Panagiotis Christopoulos
pchr...@gentoo.org wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0 transition would
 be a good moment to finally remove the (also in my opinion rather useless)
 server profiles.


 The server profiles are not useless, if we can maintain them, and if
 they actually are, nowadays, they shouldn't be.

 -1, unless other profile options being offered are minimal enough for the 
 job
 and enabling certain things that someone may need in a server.

The problem, I think, is that 'server' is a very generic thing. Am I
looking for a NAS? A SAN? A web server? A proxy server? An X11
application server? A font server? VOIP?

If people who use the server profile are looking for a minimalist
profile, I think they'd probably be best served with a profile that's
specifically designed for we disable everything we can to still wind
up with a working stage 3. Enable what you need from there.

That also suggests a way to help automate maintenance; if building a
stage 3 with the minimal profile fails, then either the package has a
bug or the profile needs an update...with a strong bias toward the
former.

-- 
:wq

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Rick Zero_Chaos Farina

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 08:32 AM, Panagiotis Christopoulos wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0 transition would 
 be a good moment to finally remove the (also in my opinion rather useless) 
 server profiles. 

 
 The server profiles are not useless, if we can maintain them, and if
 they actually are, nowadays, they shouldn't be.
 
 -1, unless other profile options being offered are minimal enough for the 
 job 
 and enabling certain things that someone may need in a server. 
 

We have a base profile, we have a desktop profile... wouldn't that make
the base the minimal profile that would likely be fit for a server? If
not, we really should move that way.  Having a base, desktop, and server
profile seems silly. Base profile is for servers in my eyes (and in my use).

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

iQIcBAEBAgAGBQJQ9rZZAAoJEKXdFCfdEflKqOEP/ix6hTdghZ5ZNHPRAfaoUXvq
pDh956sSwOsRrqkOLltPi9GRHmfGxJoVSHLzDy17V00UyB+N9nC7naWGTDCu2YyZ
GCIi03nFfI4FSO9iMZVTnCCiAq2/xpWehloWcwu/m4nT8L7KqMl+LE3Gt+/aGzm4
+CdAuR8R5ceZKbquEiyJ4wwlsugMp386OB90+z9a7xSMKHotxkkhlii/1M9SnOaW
M1ngsQDuSFowa9B+gxCYnsP8TZDE5cgeihWW7sAfc/MmImfGEXLZ6OkyNWD6ZG+5
pPFi8hlP+9A0Xe4ovcfU46c8hwWnZHL+pe/UCzTC287bMEgzdgpVBmBKQVVSwzLa
wMlWNx/9B/COB5c5jcMb8N2EZ356/0xdDIDNDgdTHJr71eNa/5+BfXSbRwKxs3Ar
rZbBEAa+MUOP4bPA5IHktHl+HanVcz8VssS1mrGJKWFnKfqZXjJKRfhunv3M3Q0j
3o/qtUQ3vzAh72Mdd3w3x2zXhJBTo8RsgzSPR9wmVpwtnp6v/31wakF0WGAfG8eZ
zunFf8dMxgj2SsZrdmVfRoAnMoJj6etzkwO6C2I4A1+A7XTatARntCQZeO3Rl0Vz
cZTasaphgHQCNSu7g2xE70PN/NmSHmUdz/Y/w4PXjIsQqAFN7j1ZMnxH1IJBb2cT
Bp+lEn7jNn4Bs1av/jn9
=deIt
-END PGP SIGNATURE-

Re: [gentoo-dev] removing the server profiles...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0
 transition would be a good moment to finally remove the (also in
 my opinion rather useless) server profiles.
 
 
 The server profiles are not useless, if we can maintain them, and
 if they actually are, nowadays, they shouldn't be.
 
 -1, unless other profile options being offered are minimal enough
 for the job and enabling certain things that someone may need in a
 server.
 

Just to summarize the last massive thread on this:

1 - they aren't maintained; they haven't changed for years

2 - the only difference between server profiles and the base profile
is USE=+snmp and maybe one other flag

3 - there isn't any general consensus on what makes a server, as such
there isn't any consensus on how to make server profiles more useful.

... i think that's about it?

PS: +1 from me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD2tjQACgkQ2ugaI38ACPDGbwEAr4WGmtio2d+uWTkroEGCbu4U
53GdR5R3A4Fti8UXzj8A/iM805vMnkojNTNGw8b5XYVXPbYrZ9TJ4GPp0onE8AK8
=6Lja
-END PGP SIGNATURE-

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-16 Thread Tobias Klausmann

Hi! 

On Tue, 15 Jan 2013, Greg KH wrote:
 So anyone who relies on network names right now to be deterministic, and
 you have more than one network device in your system, should seriously
 reconsider how they are naming their devices, as it will not work if you
 only rely on the kernel.
 
 You might have gotten lucky for the past 5 years, but you never know
 what could happen if you reboot today.  Seriously, I've seen it happen
 all the time.

It has been rather nifty that if I walk up to a random machine
with exactly one NIC (that I've been asked to examine/fix), I
_know_ that there will be eth0 and only that.

OTOH, maybe it's a good idea to make admins do ip link sh and
ip addr sh every time they examine a new computer -- it goes a
long way to root out wrong assumptions in that field.

Regards,
Tobias

PS: Do not use ifconfig. Ever. Except if there's no iproute. And
then you should only use ifconfig to enable downloading of
iproute :)

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-16 Thread Mike Gilbert

On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann klaus...@gentoo.org wrote:
 Hi!

 On Tue, 15 Jan 2013, Greg KH wrote:
 So anyone who relies on network names right now to be deterministic, and
 you have more than one network device in your system, should seriously
 reconsider how they are naming their devices, as it will not work if you
 only rely on the kernel.

 You might have gotten lucky for the past 5 years, but you never know
 what could happen if you reboot today.  Seriously, I've seen it happen
 all the time.

 It has been rather nifty that if I walk up to a random machine
 with exactly one NIC (that I've been asked to examine/fix), I
 _know_ that there will be eth0 and only that.

 OTOH, maybe it's a good idea to make admins do ip link sh and
 ip addr sh every time they examine a new computer -- it goes a
 long way to root out wrong assumptions in that field.

 Regards,
 Tobias

 PS: Do not use ifconfig. Ever. Except if there's no iproute. And
 then you should only use ifconfig to enable downloading of
 iproute :)


I would actually like to see iproute2 added to the system set.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On 01/15/2013 09:51 PM, Dirkjan Ochtman wrote:
 On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge pe...@stuge.se wrote:
 emerge --sync
   layman -S
   eix-sync #layman...
   porticron # from porticron
   update-gentoo # cvs setup https://xmw.de/dotfiles/bin/update-gentoo

 emerge --upgrade
with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
EMERGE_DEFAULT_OPTS lives).

But ++ on that
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-16 Thread viv...@gmail.com


Il 16/01/2013 17:25, Mike Gilbert ha scritto:

On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann klaus...@gentoo.org wrote:

Hi!

On Tue, 15 Jan 2013, Greg KH wrote:

So anyone who relies on network names right now to be deterministic, and
you have more than one network device in your system, should seriously
reconsider how they are naming their devices, as it will not work if you
only rely on the kernel.

You might have gotten lucky for the past 5 years, but you never know
what could happen if you reboot today.  Seriously, I've seen it happen
all the time.

It has been rather nifty that if I walk up to a random machine
with exactly one NIC (that I've been asked to examine/fix), I
_know_ that there will be eth0 and only that.

OTOH, maybe it's a good idea to make admins do ip link sh and
ip addr sh every time they examine a new computer -- it goes a
long way to root out wrong assumptions in that field.

Regards,
Tobias

PS: Do not use ifconfig. Ever. Except if there's no iproute. And
then you should only use ifconfig to enable downloading of
iproute :)


I would actually like to see iproute2 added to the system set.

additionally (or indipendently) I would like to see it in bin instead of 
sbin

Re: [gentoo-dev] call for testers: udev predictable network interface names

On 01/16/2013 05:25 PM, Mike Gilbert wrote:
 It has been rather nifty that if I walk up to a random machine
 with exactly one NIC (that I've been asked to examine/fix), I
 _know_ that there will be eth0 and only that.
++

 I would actually like to see iproute2 added to the system set.
++

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org

Re: [gentoo-dev] Chromium system ffmpeg

2013-01-16 Thread Alec Warner

On Wed, Jan 16, 2013 at 4:59 AM, Rich Freeman ri...@gentoo.org wrote:
 On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier aball...@gentoo.org wrote:
 On Tue, 15 Jan 2013 21:10:12 -0800
 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 What when chromium upstream uses code more recent than latest ffmpeg
 release and it doesn't compile against latest release?

 Blame them, it's stupid to break support for the latest release.
 Usually, it's quite trivial to maintain compatibility and you should
 probably lobby upstream to get this as a rule, it'd make life simpler
 for everyone. Or just patch releases not to use too bleeding-edge code
 (see mplayer for example).

 While I agree in principle, that is much easier said than done.  I
 think upstream is more likely to consider the concept of a linux
 distro broken than their code.

 The unpacked chromium distfile is 1.1G, of which 694M is third party
 source-code.  The chromium team has done an excellent job of disabling
 much of that, but the upstream attitude clearly is to cherry-pick
 their dependencies.  This is pretty typical for Google projects from
 what I've seen - ChromeOS basically is a fork of Gentoo with many
 packages being fairly dated, and Android does just about everything
 its own way, typically releasing third-party code into production
 before any upstream packages have access to it.

Google generally prefers agility. Particularly when machines have gobs
of memory (so bundling is not as big of a deal as it was previously)
and they can staff security fixes for all their bundled libs. This is
quite a pervasive attitude there. Coming from a distribution
background it can be weird to see the different priorities (and
terrible systems that build the packages that work on $DISTRO, ew.)

-A


 Of course, we should encourage upstream to improve its practices.  I
 just wouldn't count on it, so I think we need to give the chromium
 team discretion on just how much patching they think they can handle.
 They're obviously pretty good at it already.

 Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On 01/16/2013 11:36 AM, Michael Weber wrote:
 
 emerge --upgrade
 with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
 EMERGE_DEFAULT_OPTS lives).

+1 so I can stop adding --oneshot onto every upgrade.

Re: [gentoo-dev] Chromium system ffmpeg

2013-01-16 Thread Paweł Hajdan, Jr.

On 1/16/13 8:40 AM, Alec Warner wrote:
 Google generally prefers agility. Particularly when machines have gobs
 of memory (so bundling is not as big of a deal as it was previously)
 and they can staff security fixes for all their bundled libs. This is
 quite a pervasive attitude there. Coming from a distribution
 background it can be weird to see the different priorities (and
 terrible systems that build the packages that work on $DISTRO, ew.)

Bundling is not a problem because of build time, memory usage of disk
space concerns (they are to some degree, but that's _not_ the primary
reason).

The biggest problem are incompatible forks (which we have in chromium
tree), which actually hinder agility.

For example, system ICU is more recent than the bundled one. Same for
several other bundled libraries. A lot of effort goes into maintaining
the forks and cherry-picked patches - that effort could be spent on
something else.

People often speak about the cost of unforking/unbundling, but
forking/bundling has its cost too. Because of Windows and Mac, some
libraries have to be bundled, but there should be no reason to fork (at
least not long-term).

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On 01/16/2013 11:47 AM, Michael Orlitzky wrote:
 On 01/16/2013 11:36 AM, Michael Weber wrote:

 emerge --upgrade
 with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
 EMERGE_DEFAULT_OPTS lives).
 
 +1 so I can stop adding --oneshot onto every upgrade.

Oh, damn, this isn't suggesting what I thought. Allow me to suggest that
having both --update and --upgrade might be confusing, then =)


p.s. EMERGE_UPDATE_OPTS would still be nice.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/01/13 11:49 AM, Michael Orlitzky wrote:
 On 01/16/2013 11:47 AM, Michael Orlitzky wrote:
 On 01/16/2013 11:36 AM, Michael Weber wrote:
 
 emerge --upgrade
 with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
 EMERGE_DEFAULT_OPTS lives).
 
 +1 so I can stop adding --oneshot onto every upgrade.
 
 Oh, damn, this isn't suggesting what I thought. Allow me to suggest
 that having both --update and --upgrade might be confusing, then
 =)
 
 
 p.s. EMERGE_UPDATE_OPTS would still be nice.
 


- --upgrade wouldn't (couldn't, imo) replace --update.

emerge --upgrade would ideally meant to be run with no options
(except for maybe --keep-going and --jobs), and would consider @world
without specifying it.  We would, I think, need to define what happens
when other things are specified as options (ie throw them out and/or
error), which is why I have reservations of emerge --upgrade over a
separate say, eupgrade command; i don't think the usual pile-on
should occur.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD24joACgkQ2ugaI38ACPA4vwD8DqGsXOXKiKEzeQI98VytM9zg
4FX6fQ1ENwBeiZu17rkA/2IxItrBer06jy5bIWONCxjy+ysqj+BBTrY5oININVNE
=3chs
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/01/13 11:47 AM, Michael Orlitzky wrote:
 On 01/16/2013 11:36 AM, Michael Weber wrote:
 
 emerge --upgrade
 with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
 EMERGE_DEFAULT_OPTS lives).
 
 +1 so I can stop adding --oneshot onto every upgrade.
 
 

btw, why are you adding --oneshot when upgrading??  emerge -u doesn't
ever modify the world file...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD24mMACgkQ2ugaI38ACPBJnwEAhHm7oV8MNKpWnHnZ/Vqvxy6C
OTXNJzErpfJvuLXIAdYA/jdOQDT441rgC8Y11E32GKBJp2kTiK25vF3hEC7s95v2
=ZAyY
-END PGP SIGNATURE-

Re: [gentoo-dev] removing the server profiles...

Other option: kill the server subprofiles, keep profiles/target/server
and let people finally set /etc/make.profile as a dir and play with
multiple inheritance. We don't need dozens of subprofiles with only
eapi and parent files in them...

A.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
 On 16/01/13 11:47 AM, Michael Orlitzky wrote:
 On 01/16/2013 11:36 AM, Michael Weber wrote:
 
 emerge --upgrade
 with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
 EMERGE_DEFAULT_OPTS lives).
 
 +1 so I can stop adding --oneshot onto every upgrade.
 
 
 
 btw, why are you adding --oneshot when upgrading??  emerge -u
 doesn't ever modify the world file...
 

I strongly believe that it shouldn't; nevertheless, it does.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ9uQiAAoJEBxJck0inpOiIgMP/A7prLxpcPh3ZNF0ZWmcbj35
igZi6qXJJHCKYRUzXNYbUfVWFnMc/l9ryjVn9fosvpggyQBBq99zneAh+IARcDPI
XpXGe+wzg3NHvvTa9Xe93Wg2VQ5a/efGaH9mEeQ0YPQd0b/NNodfxn4nSKa48Ulb
7aWumzW4I4Xmu5E77L7q1alfatKf/0w1YGMLZpvnITAdBRNDcDQZtXpzXvRl6zwr
eUwnbjqNJanmaKtvjPXU+BCW+sjtO2JjVX4L/o/qwMHMHJtVk44mNY262BLkg99N
dJ1evNg/1sU+CAni/sPOgyjttR+UGgRq7x7nWXBPmQRS2X1Z5Beira/GqZ/8mKFC
pUOQ3+AFcbK8h6BupwFazybQGbFUODs2eh/J9TfSnw1j4sicoGHAwz8Z2EPYtRIc
Pa3NCqvaOyPSP5W4SCbYN5OOGEFxmHKPH3oK3ddtJ+6BOci58dcbSm3+FMGbuCpu
txKQxfPtNRvZ4CdKkvocz83nMLpFYqr7uSQFSYARjXH0shnS40ajM6E5LZy+LELa
94rPLgAct7E4KZOjKm+o6wvStMi0S+aP3+1DI1dciOF0xlTSYZic6ggt39G+pNqU
dIgXaKRrd2e4+aeP2IP8iiTddfnUkOXOlxa047dNfOS7B8d6d/aJ6CZKYRWKf6gS
ZYIkpFr3OJDYPGp7oxhx
=BsDW
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
 
 --upgrade wouldn't (couldn't, imo) replace --update.
 

Yes, sorry for the confusion. I use more than one package manager, and
when doing an update or upgrade I'm basically flipping a coin.

I just mistook upgrade for update, there.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ9uRUAAoJEBxJck0inpOiLSYQAIHekN2gLD8XRhd6kCulCWkk
p4RcBmuuHM8p06GC1VzSlGmOlhezIXnt3lnstsUG3tJvIDz443Q7EChqLfg5mLTX
x1zrPxgIoFaJ7go+EbbmiyP2UNd6Hx2sWIuc7ed+NE49UZ59ZmG38SjhYdEtkZ8e
D62BMfUqYmEbibIKXq93S6WawAuolFTYwLINbiebThHUT3dSid21LdEk2isI1+tS
QMqnwqPPobYoAECrWCLQawLkMU1SHHcokGriNDEQDb2pNgHr8SJu85CkgGk/PcAX
sFDB/X7IwKVzwsdB9/YGxyt896VhtgUs83szqNbhNxiTzt17FtyFhtVehIoS9nbg
GTMteIIU5vHNXDaksnSigegYtcRWv9vf+tJHTTHkj4O+Z0SLN5cSFSjMOveYKVVA
3MXAvz/2KD2vPqv9yJ1pXhdvaqTu93mx3Ps20a6AWyOyjn4m7FNEyyhM0LEVMijA
mEP5krIO6QFaI50Z3hDVxX/Djwf+uynHUVQERxrqaZVeRwVBmeQTQw4ZMjNmGsNv
Cm4xDabivluvRVdmBV9hpiiFWnJlwvgEFBurCSqgeOAr7NRa3P5z37YqISno5zKg
8EGmqdPv9xjcSLkD5q9GoI3V1l7uBwCq0NTsXOJaHXxmW7HG1CbprL1dehSQPiCB
Wle+0CtUdW2Dr0hUE5XR
=i6LB
-END PGP SIGNATURE-

Re: [gentoo-dev] January stabilization candidates

2013-01-16 Thread Matt Turner

On Wed, Jan 16, 2013 at 5:58 AM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
 net-wireless/b43-fwcutter-017

 be my guest, although I prefer the bugs personally.

That's what he's doing... asking maintainers if it's okay to open
stabilization bugs for their packages.

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Ben de Groot

On 16 January 2013 22:16, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote:
 We have a base profile, we have a desktop profile... wouldn't that make
 the base the minimal profile that would likely be fit for a server? If
 not, we really should move that way.  Having a base, desktop, and server
 profile seems silly. Base profile is for servers in my eyes (and in my use).

+1

-- 
Cheers,

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

Re: [gentoo-dev] app-emulation/qemu-user mask

2013-01-16 Thread Doug Goldstein

On Mon, Jan 14, 2013 at 11:01 AM, Doug Goldstein car...@gentoo.org wrote:
 On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov ale...@gentoo.org wrote:
 В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал:
 On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote:
  Hi!
 
  For cross-chroots its needed to have static qemu-$arch user translators.
  May be you can introduce user-static use flag for them? Also it will be
  cool to have init script for kvm

 USE=static is available for app-emulation/qemu. I'll get a chroot for
 arm setup soon and test everything to make sure its working well.

 It doesnt allow to build dynamik qemu-system* and static user targets

 That can be fixed. File a bug.


To follow this up. I've successfully installed and am using an arm
chroot on my amd64 box using app-emulation/qemu-1.2.2 not using
USE=static. But it required a little bit of effort (using ldd or
readelf to bring in the necessary libraries) so I'll introduce
USE=static-user and USE=static-softmmu, both of which will be enabled
by USE=static.


-- 
Doug Goldstein

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Doug Goldstein

On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0
 transition would be a good moment to finally remove the (also in
 my opinion rather useless) server profiles.


 The server profiles are not useless, if we can maintain them, and
 if they actually are, nowadays, they shouldn't be.

 -1, unless other profile options being offered are minimal enough
 for the job and enabling certain things that someone may need in a
 server.


 Just to summarize the last massive thread on this:

 1 - they aren't maintained; they haven't changed for years

I think you're confusing updates with maintenance. They work fine as
is therefore no need for updates.


 2 - the only difference between server profiles and the base profile
 is USE=+snmp and maybe one other flag

USE=-perl -python snmp truetype xml


 3 - there isn't any general consensus on what makes a server, as such
 there isn't any consensus on how to make server profiles more useful.

Just make the base profile as minimal as possible and people will be happy.



 ... i think that's about it?

 PS: +1 from me.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)

 iF4EAREIAAYFAlD2tjQACgkQ2ugaI38ACPDGbwEAr4WGmtio2d+uWTkroEGCbu4U
 53GdR5R3A4Fti8UXzj8A/iM805vMnkojNTNGw8b5XYVXPbYrZ9TJ4GPp0onE8AK8
 =6Lja
 -END PGP SIGNATURE-




-- 
Doug Goldstein

Re: [gentoo-dev] app-emulation/qemu-user mask

On 12/01/13 05:45, Doug Goldstein wrote:
 Just wanted to give everyone a heads up. app-emulation/qemu provides
 all the functionality of app-emulation/qemu-user without all the
 outstanding security bugs and issues the package has. For users using
 a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I
 presently use an arm chroot with app-emulation/qemu. Should there
 truly be a missing feature, open a bug and I'll fix it. The only item
 I'm aware of that app-emulation/qemu does not have is the binfmt
 initscript. But I plan on adding that to the unstable version shortly.
 
 If there are no objections for 30 days, I'll send a treecleaner notice
 in 30 days and remove it 30 days after that (60 days from now).

And once I have enough time I will reinstate it... beside the fact
qemu-user does NOT have security issues...

Again please do not mix qemu system emulation with qemu userspace
wrappers. They have different needs and requirements.

lu

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Matthew Thode

On 01/16/2013 01:18 PM, Doug Goldstein wrote:
 On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius a...@gentoo.org wrote:
 On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0
 transition would be a good moment to finally remove the (also in
 my opinion rather useless) server profiles.


 The server profiles are not useless, if we can maintain them, and
 if they actually are, nowadays, they shouldn't be.

 -1, unless other profile options being offered are minimal enough
 for the job and enabling certain things that someone may need in a
 server.

 
 Just to summarize the last massive thread on this:
 
 1 - they aren't maintained; they haven't changed for years
 
 I think you're confusing updates with maintenance. They work fine as
 is therefore no need for updates.
 
 
 2 - the only difference between server profiles and the base profile
 is USE=+snmp and maybe one other flag
 
 USE=-perl -python snmp truetype xml
 
 
 3 - there isn't any general consensus on what makes a server, as such
 there isn't any consensus on how to make server profiles more useful.
 
 Just make the base profile as minimal as possible and people will be happy.
 
 
 
 ... i think that's about it?
 
 PS: +1 from me.

 
 
 

Agreed on making the base copy as minimal as possible.  (which it is, at
least good enough for me).


-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Mike Gilbert

On Wed, Jan 16, 2013 at 2:18 PM, Doug Goldstein car...@gentoo.org wrote:
 On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius a...@gentoo.org wrote:
 2 - the only difference between server profiles and the base profile
 is USE=+snmp and maybe one other flag

 USE=-perl -python snmp truetype xml


As has been pointed out previously, the base profile does not set
USE=perl python, so negating those flags in the server profile does
basically nothing. If certain packages have IUSE=+perl +python it
might make a difference, but I don't think I have ever seen that.

IMO, setting truetype and xml for a server profile is just weird.

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

On Wed, 16 Jan 2013 12:40:02 + (UTC)
Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote:

 scarabeus13/01/16 12:40:02
 
   Modified: ChangeLog
   Added:ffmpeg-9.ebuild
   Removed:  ffmpeg-0.10.2-r1.ebuild
   Log:
   Add new virtual for 1.1/9 series. Masked. Also it has switched dep
 order as will be announced upon unmasking. 

... and since we are committing silently without any real discussion I
will switch the dep order again and announce it much later without
leaving room for discussion :)

More seriously: Why ? Who decided this ?
Let's be realistic, both upstreams claim they're better than the other
in one way or another, and let's think like serious downstreams, not
like upstream playground.

As a downstream, I can see plenty of reasons against, but none in favor
of this change:
- There are still a couple of non-trivial packages that need to be
  fixed to work with libav while I don't know any that works with libav
  but not ffmpeg.
- All (but the one discovered in Nov. 2012) of the security issues
  fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012
  (!!) for ffmpeg according to the website... 8 months before...

Alexis.

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Daniel Campbell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 08:12 AM, Michael Mol wrote:
 On Wed, Jan 16, 2013 at 8:32 AM, Panagiotis Christopoulos 
 pchr...@gentoo.org wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0
 transition would be a good moment to finally remove the (also
 in my opinion rather useless) server profiles.
 
 
 The server profiles are not useless, if we can maintain them, and
 if they actually are, nowadays, they shouldn't be.
 
 -1, unless other profile options being offered are minimal
 enough for the job and enabling certain things that someone may
 need in a server.
 
 The problem, I think, is that 'server' is a very generic thing. Am
 I looking for a NAS? A SAN? A web server? A proxy server? An X11 
 application server? A font server? VOIP?
 
 If people who use the server profile are looking for a minimalist 
 profile, I think they'd probably be best served with a profile
 that's specifically designed for we disable everything we can to
 still wind up with a working stage 3. Enable what you need from
 there.
 
 That also suggests a way to help automate maintenance; if building
 a stage 3 with the minimal profile fails, then either the package
 has a bug or the profile needs an update...with a strong bias
 toward the former.
 

Agreed. An extremely minimal profile would also interest those looking
to learn the fundamentals of Gentoo or come from other distros that
start with almost nothing. I'd certainly be interested in testing that
profile on a separate machine.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ9wwqAAoJEJUrb08JgYgH+o4H/394Ugp+Khdgmwn054QADhb9
pncIA+UPM5CkU6CfK3PAH8ZQShbU055Yc8mx9buraj1Ie+O8gJceZGGIkJNIzCDS
iCUMfzcSpam6EF2Zj9FDWeKJLWOuX/i15fs+p30ITy27eq5RDasU4t7umhw1pUdX
XkC4HGz9TDnHnjC9valfb7B7spuQuqngTnEf6IMosjVe0wMptRHozHaXvCnyoAWa
db9zpJ8gOLWBRC7G4/826sif74i+WHIIq3Af+g3F5VhVpfrtfDA/1h8O0p/Oe9Nk
FWU2bKjhZ/oPwSg90rrpOYcXhJBP+wQkpwtsWHA8OwgafeQ5Wgk+W5GQdg2BBJo=
=ho30
-END PGP SIGNATURE-

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

2013-01-16 Thread Kevin Chadwick

I never meant it is rubbish as such but I saw it as rediculously
inferior to sudo before I even read this.

http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/

Perhaps I'm misunderstanding, but that is talking about a specific set
of problems that I don't think polkit was actually designed to
address. Polkit is basically for authenticating applications via
users, not the applications themselves. If I am running app foo, and
app foo wants to inhibit hibernation; polkit is there to ask 'hey is
antarus allowed to inhibit hibernation? Does antarus need to auth to
do so? Is antarus already authenticated? Now one may say 'hey but I
only want certain applications to hibernate' and while that may be an
interesting problem...I don't think the existing polkit intends to
solve it.

The point is that it is inferior in every way and so pointlessly causing
more work and other problems not to mention guaranteed increased
security risk having extra code constantly running as root. Why was it
started, rather than contributing to sudo.

It is however, designed for graphical UI single-seat systems.
Its command line support sucks (they only added a CLI auth agent in
May) and it is not well adopted. Multi-user systems do not work well
with polkit. Certainly with polkit and dbus you can allow users to
take more specific action without complex wrappers, setuid scripts, or
sudo.

Except you can't, it only encourages more coarse grained approaches,
less useful commands available and devs to learn an api rather than C
and simply moves code into a far less secure mechanism and increases the
chance that the code will not be well designed to the task at hand and
running as root. It can be a real pain to work out exactly what polkit
allows and you cannot just edit it to suit your application and it
completely ignores the existing unix security technologies with
brilliant track records.

One could say that 'a discrete set of APIs will be no match for
the..fined grain control that is the command line!' I would agree. I
don't agree that this is a one-size fits all deal though. There can be
a command line AND an API. I'd rather grant my users 'access to the
install authenticated packages action' than have to own a complex sudo
rule.

How about uncommenting a line that does so. All you are buying into is
a default setup.

I don't understand 'the APIs that coders will learn instead of C.' Can
you elaborate? Polkit has a C api...

It has an api that is simply not needed? Small tools are better.

I don't understand how the code will 'not be well designed to the
application at hand.' I mean ideally the API and the CLI are
essentially just wrappers around the same library of functions.

If you search for sites that evaluate polkit you will see that it is
considered to encourage granting more permissions than necessary rather
than coding a specific tool.

Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
you will have to read some manpages. However i don't think the
concepts are difficult.

Man pages won't help with polkit and it actually generally ships with no
configs by default.

There are plenty of helpers (pkcheck springs
to mind) that assist the user in figuring out what is 'allowed'.

I know about pkaction, the problem is that the actions tells you next to
nothing about what is actually allowed. I haven't time to dig out one
of the rediculous comments from the source now unfortunately. With
small tools it's much better all round.

The
configuration for polkit is all in /usr/share and /etc. The configs
are configurable..again in /etc. This is not something I would term
'challenging.'

Generally there aren't any rules files, the defaults are built in and
your expected to use a webbrowser, even on a server?!?! You shouldn't
run lynx never mind X on a server.

If some configs are in /usr/share rather than /etc perhaps that explains
why one tutorial said so and it has no effect on some systems.

You could try to argue that many eyes will look at a central piece of
code but in fact less implementations will likely mean less eyes and
just assumption that a guy who got JS through as a config language has
everything covered. Granted, unmaintained code running as root may be
higher with sudo but if it needs maintaining, should it be running as
root at all or is it actually simply doing too much.

Its not a matter of many-eyes. It is a matter of 'some other guy is in
charge of maintaining that component.' It means I can focus on stuff
that matters, and not focus on 'wrappers to make random things work.'

That can apply to sudo, would be more secure and cause less problems
and you see why I brought it up and asked why not, because that should
be the case.

Is the polkit maintain any less 'trustworthy' than the gnome
maintainers? the kde maintainers? the kernel maintainers? At the end

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

On 16/01/13 21:09, Alexis Ballier wrote:
 More seriously: Why ? Who decided this ?

I never pushed my weight over it before since as you are involved in
FFmpeg directly, I am involved in Libav directly.

Thus anything I say on this topic has a clear bias. Same goes for you.

Tomas is not related to libav beside one of his core project using it by
transition, so I would expect him to be less biased than us.

 Let's be realistic, both upstreams claim they're better than the other
 in one way or another, and let's think like serious downstreams, not
 like upstream playground.

VLC uses it since ffmpeg doesn't work with rtmp properly last time they
checked and other interesting situations.

gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus
the rename)

ubuntu and debian just use Libav.

 As a downstream, I can see plenty of reasons against, but none in favor
 of this change:
 - There are still a couple of non-trivial packages that need to be
   fixed to work with libav while I don't know any that works with libav
   but not ffmpeg.

See above for the other way round.

 - All (but the one discovered in Nov. 2012) of the security issues
   fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012
   (!!) for ffmpeg according to the website... 8 months before...

The security game is fun. Given the number of additional features the
surface impact is bigger in FFmpeg and currently all but one of the bugs
claimed as security issues originate from the same guy he claim to fix
them (sometimes the fix doesn't address the underlying issue but just
_that_ specific sample).

I'd rather avoid having another mud sliding contest.

I stopped caring about FFmpeg since somebody gave a sample of his humor
wishing my death.


Lu

[gentoo-dev] revdep-rebuild bikeshedding

2013-01-16 Thread Paul Varner

All:

Time for some bikeshedding :)

For the gentoolkit-0.3.0 series, I removed any filtering of emerge
options set in EMERGE_DEFAULT_OPS for revdep-rebuild.  This has caused
some people to complain because some of the flags in their
EMERGE_DEFAULT_OPTS are not suitable for a revdep-rebuild run.

I am not going to go back to filtering any of the emerge options,
however, I just added support for a make.conf variable called
REVDEP_DEFAULT_OPTS which currently gets appended to the list of options
after the EMERGE_DEFAULT_OPTS and before the command line options.

Here is where the bikeshedding begins:
1. What variable name do we prefer? REVDEP_DEFAULT_OPTS or
REVDEP_EMERGE_DEFAULT_OPTS
2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
EMERGE_DEFAULT_OPTS

Regards,
Paul

Re: [gentoo-dev] revdep-rebuild bikeshedding

On Wed, Jan 16, 2013 at 3:43 PM, Paul Varner fuzzy...@gentoo.org wrote:
 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
 EMERGE_DEFAULT_OPTS

Replace is probably better.  You can always manually append if you
want to, but it is much harder to remove unless portage has logic to
handle a inverse of every option and processing them in order (ie
--with-bdeps=y --with-bdeps=n works out to a no, and vice-versa).  If
you just replace it you'll eliminate a bunch of issues.

Rich

Re: [gentoo-dev] removing the server profiles...

On Wed, Jan 16, 2013 at 3:01 PM, Mike Gilbert flop...@gentoo.org wrote:
 As has been pointed out previously, the base profile does not set
 USE=perl python, so negating those flags in the server profile does
 basically nothing. If certain packages have IUSE=+perl +python it
 might make a difference, but I don't think I have ever seen that.

 IMO, setting truetype and xml for a server profile is just weird.


Yup, server profile is essentially base profile plus snmp, truetype,
and xml.  That really doesn't make sense.

++ to just dropping it, and by all means if people see ways to make
the base profile even more minimal please chime in, but it is already
the most minimal profile out there.

If somebody wants to come up with a server profile that actually makes
sense by all means do so, but I think the current one is just baggage.
 If we wanted server profiles that made sense most likely it would be
part of some more holistic program (with docs, etc) and broken down by
server type (mail, web, LAMP, etc).  That doesn't exist now, and I'm
not planning to build it.  :)

Rich

Re: [gentoo-dev] revdep-rebuild bikeshedding

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/01/13 03:43 PM, Paul Varner wrote:
 All:
 
 Time for some bikeshedding :)
 
 For the gentoolkit-0.3.0 series, I removed any filtering of emerge 
 options set in EMERGE_DEFAULT_OPS for revdep-rebuild.  This has
 caused some people to complain because some of the flags in their 
 EMERGE_DEFAULT_OPTS are not suitable for a revdep-rebuild run.
 
 I am not going to go back to filtering any of the emerge options, 
 however, I just added support for a make.conf variable called 
 REVDEP_DEFAULT_OPTS which currently gets appended to the list of
 options after the EMERGE_DEFAULT_OPTS and before the command line
 options.
 
 Here is where the bikeshedding begins: 1. What variable name do we
 prefer? REVDEP_DEFAULT_OPTS or REVDEP_EMERGE_DEFAULT_OPTS

+1 on REVDEP_DEFAULT_OPTS , but if things are going to be verbose
might as well make them completely verbose with
REVDEP_REBUILD_DEFAULT_EMERGE_OPTS

 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or
 replace EMERGE_DEFAULT_OPTS

+1 on the replace.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD3FDIACgkQ2ugaI38ACPC3gQEAvUlApXInabHifnIXlqsUJhJX
syeaaDkOXLzSO1L3vskA/2xX2YxAMnnmtFkv+QLBi+Kx+fLi60ZE/0QD1Zd5LH/3
=h5CO
-END PGP SIGNATURE-

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Andreas K. Huettel

Am Mittwoch, 16. Januar 2013, 00:36:18 schrieb Andreas K. Huettel:
 Hi,
 
 several people have pointed out to me that the 10.0 - 13.0 transition
 would be a good moment to finally remove the (also in my opinion rather
 useless) server profiles.


OK, I consider this consensus enough. 

[One nay conditional on other profiles not being minimal enough, and several 
people giving good reason why the server profile does not provide any 
additional value.]

Being the one that does the work, the server profiles are disappearing in 
13.0.

-- 

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] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

On Wed, 16 Jan 2013 21:39:04 +0100
Luca Barbato lu_z...@gentoo.org wrote:

 On 16/01/13 21:09, Alexis Ballier wrote:
  More seriously: Why ? Who decided this ?
 
 I never pushed my weight over it before since as you are involved in
 FFmpeg directly, I am involved in Libav directly.

I don't know what you mean by involved directly, but ffmpeg happens to
be what I use and care about, hence I have a couple of commits there
but their number is quite ridiculous in comparison. [Actually, I should
be honored that you compare my involvement with yours :)]

 Thus anything I say on this topic has a clear bias. Same goes for you.

... but I admit I have some bias, however, I'm rather a consumer than a
developer when it comes to ffmpeg and believe we need to think as
consumers as a downstream distro.

 Tomas is not related to libav beside one of his core project using it
 by transition, so I would expect him to be less biased than us.
 
  Let's be realistic, both upstreams claim they're better than the
  other in one way or another, and let's think like serious
  downstreams, not like upstream playground.
 
 VLC uses it since ffmpeg doesn't work with rtmp properly last time
 they checked and other interesting situations.

interesting, did they report it? OTOH, they switched _after_ the 2.0.5
release which happens to be the latest one. Since vlc is probably the
ffmpeg/libav interface the most popular in the world (due to their
windows and mac builds), I'd like to see an actual release with it and
see if there is any regression before claiming they use libav.

 gst-ffmpeg/gst-libav works only with libav as per upstream desire
 (thus the rename)

you mean use libav internally? because 'per upstream desire'
gst-ffmpeg or gst-libav always only worked with the internal libs :)
it also appears to build and work fine with ffmpeg-0.10

 ubuntu and debian just use Libav.

Speaking about bias, the maintainer happens to be part of libav core
developers and was even part of what is known as the 'ffmpeg coup' :)

  As a downstream, I can see plenty of reasons against, but none in
  favor of this change:
  - There are still a couple of non-trivial packages that need to be
fixed to work with libav while I don't know any that works with
  libav but not ffmpeg.
 
 See above for the other way round.

None of what you cited is a problem for a downstream distribution,
except maybe vlc+rtmp which should be fixed regardless.
xbmc and mplayer did not build last time I tried. xbmc will be a pain
because it uses some libavfilter features not in libav.

  - All (but the one discovered in Nov. 2012) of the security issues
fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May
  2012 (!!) for ffmpeg according to the website... 8 months before...
 
 The security game is fun. Given the number of additional features
 the surface impact is bigger in FFmpeg and currently all but one of
 the bugs claimed as security issues originate from the same guy he
 claim to fix them (sometimes the fix doesn't address the underlying
 issue but just _that_ specific sample).

I don't want to verify this and will trust you there, but I still
don't consider 8 months to be a correct delay for handling a published
vulnerability, whatever its origin may be.

 I'd rather avoid having another mud sliding contest.
 
 I stopped caring about FFmpeg since somebody gave a sample of his
 humor wishing my death.

This is getting personal :) I'm sure the fork didn't happen because
some day some devs woke up angry because they didn't have had their
coffee. However, I'm also sure the fork is a pain for downstream
distros and a lot of upstreams.

Alexis.

Re: [gentoo-dev] revdep-rebuild bikeshedding

2013-01-16 Thread Albert Hopkins



On Wed, Jan 16, 2013, at 03:57 PM, Ian Stakenvicius wrote:
[...]
 +1 on the replace.

+1

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

On 16/01/13 22:31, Alexis Ballier wrote:
 interesting, did they report it? OTOH, they switched _after_ the 2.0.5
 release which happens to be the latest one. Since vlc is probably the
 ffmpeg/libav interface the most popular in the world (due to their
 windows and mac builds), I'd like to see an actual release with it and
 see if there is any regression before claiming they use libav.

Reported, dismissed as bug on their side IIRC.

 gst-ffmpeg/gst-libav works only with libav as per upstream desire
 (thus the rename)
 
 you mean use libav internally? because 'per upstream desire'
 gst-ffmpeg or gst-libav always only worked with the internal libs :)
 it also appears to build and work fine with ffmpeg-0.10

To be more clear, latest gst-libav release does not build with latest
ffmpeg release, same said for the gst-libav backport.

 Speaking about bias, the maintainer happens to be part of libav core
 developers and was even part of what is known as the 'ffmpeg coup' :)

Meanwhile I preferred let people pick their poison since it is easy to
switch from one to another, in retrospect would had been better if I
just removed ffmpeg from the tree from day 0.

 None of what you cited is a problem for a downstream distribution,
 except maybe vlc+rtmp which should be fixed regardless.

 xbmc and mplayer did not build last time I tried. xbmc will be a pain
 because it uses some libavfilter features not in libav.

mplayer2 works decently here. I didn't try to look at xbmc yet.

 I don't want to verify this and will trust you there, but I still
 don't consider 8 months to be a correct delay for handling a published
 vulnerability, whatever its origin may be.

Crashes are always bad, we fix a lot of them every day, we obviously
introduce few new since we aren't perfect, calling all of them security
problems is a tad extreme in my opinion.

The problem with the published vulnerabilities had been usually us
being prevented from accessing the example vectors, now the situation is
way better.

 I'm sure the fork didn't happen because
 some day some devs woke up angry because they didn't have had their
 coffee. However, I'm also sure the fork is a pain for downstream
 distros and a lot of upstreams.

The rationale is on libav.org/about.html, I spent about 3 months trying
to prevent it. I failed.

lu

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

On Wed, 16 Jan 2013 22:52:52 +0100
Luca Barbato lu_z...@gentoo.org wrote:

 On 16/01/13 22:31, Alexis Ballier wrote:
  interesting, did they report it? OTOH, they switched _after_ the
  2.0.5 release which happens to be the latest one. Since vlc is
  probably the ffmpeg/libav interface the most popular in the world
  (due to their windows and mac builds), I'd like to see an actual
  release with it and see if there is any regression before claiming
  they use libav.
 
 Reported, dismissed as bug on their side IIRC.

Hard to blame anyone without more info nor a description of the problem,
it can even be a too quick analysis before dismissing it.

  gst-ffmpeg/gst-libav works only with libav as per upstream desire
  (thus the rename)
  
  you mean use libav internally? because 'per upstream desire'
  gst-ffmpeg or gst-libav always only worked with the internal libs :)
  it also appears to build and work fine with ffmpeg-0.10
 
 To be more clear, latest gst-libav release does not build with latest
 ffmpeg release, same said for the gst-libav backport.

meaning bug #447838 ??? are you kidding ?

  Speaking about bias, the maintainer happens to be part of libav core
  developers and was even part of what is known as the 'ffmpeg
  coup' :)
 
 Meanwhile I preferred let people pick their poison since it is easy to
 switch from one to another, in retrospect would had been better if I
 just removed ffmpeg from the tree from day 0.

Fortunately we're not debian and do not like when people impose their
choice on us.

  None of what you cited is a problem for a downstream distribution,
  except maybe vlc+rtmp which should be fixed regardless.
 
  xbmc and mplayer did not build last time I tried. xbmc will be a
  pain because it uses some libavfilter features not in libav.
 
 mplayer2 works decently here. I didn't try to look at xbmc yet.

mplayer2 is a good player but unfortunately for me it doesn't come with
a mencoder2. Being the one that did most of the porting to the recent
APIs of libav* for xbmc, I can assure you that any help is very welcome
to have a sane support for libav.
 
  I don't want to verify this and will trust you there, but I still
  don't consider 8 months to be a correct delay for handling a
  published vulnerability, whatever its origin may be.
 
 Crashes are always bad, we fix a lot of them every day, we obviously
 introduce few new since we aren't perfect, calling all of them
 security problems is a tad extreme in my opinion.

It's probably the fault of the current trend of tagging most of the
crashes as sec. issues. The problem here is that a crash fix is almost
invisible, while a CVE gets very high visibility, and leaving time to
malicious people for reinventing an attack is bad.

 The problem with the published vulnerabilities had been usually us
 being prevented from accessing the example vectors, now the situation
 is way better.

This is news to me, but good it improved.

[...]

A.

Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Panagiotis Christopoulos

On 22:14 Wed 16 Jan , Andreas K. Huettel wrote:
 Am Mittwoch, 16. Januar 2013, 00:36:18 schrieb Andreas K. Huettel:
 OK, I consider this consensus enough. 

 ... 
 
 Being the one that does the work, the server profiles are disappearing in 
 13.0.
 

Err, ok, so now guys, we 're offering a base profile* with dri, cups, gmp,
fortran and pppd(?) enabled, at the same time openmp enabled but threads
disabled, no sockets, no caps no apache2 or mysql that I would probably
want if I wanted to build a server box etc. and we officially drop the
server profiles (which is true, they're unmaintained for ages). 

I've been devaway for long, probably this was discussed in the past (as
Ian (axs) pointed out), but am I the only one who finds it a little wrong? Don't
get me wrong on my example, above. Eg. I love fortran, however I don't know why 
I should
build it on every gcc update if I don't use it in my server (of course I
can disabled it, yes I know). 

Many have said that a server is something very generic, so is
desktop. I think profiles were invented to make things easier and
safer for users, so now we 're doing it for desktop users but people
who want to build a server box have to scratch their heads from the
first moment. I'm fine with that if our community is fine with that. 

I'm not blaming anyone, as the server profiles are useless atm, it was the
right call to remove them. I'm just wondering if this happened because they
were not maintained properly or because we really don't need them. 

Panagiotis

* I took as example the base default/linux/amd64/10.0 .

ps. I'll try find the old discussions which may help me understand
things better.

-- 
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )


pgpNAsDOu3bR2.pgp
Description: PGP signature

How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)

2013-01-16 Thread Andreas K. Huettel


I think we agree that the last state of the server profiles was not useful. So 
let's discuss what would be useful. For the medium-term future, not for this 
current step now.

 
 Err, ok, so now guys, we 're offering a base profile* with dri, cups, gmp,
 fortran and pppd(?) enabled, at the same time openmp enabled but threads
 disabled, no sockets, no caps no apache2 or mysql that I would probably
 want if I wanted to build a server box etc. and we officially drop the
 server profiles (which is true, they're unmaintained for ages).
 

my 2ct:
* dri and cups should probably be moved to desktop profile
* pppd is a local useflag and should be enabled by default in the capi ebuild

* for apache2 and mysql see below, should be off imho even in a server 
profile...

* caps should be discussed in a wider context (portage)

 
 Many have said that a server is something very generic, so is
 desktop. I think profiles were invented to make things easier and
 safer for users, so now we 're doing it for desktop users but people
 who want to build a server box have to scratch their heads from the
 first moment. I'm fine with that if our community is fine with that.
 

Sure a server is something generic, too. 
However, since you mentioned mysql above, how about a postgres server?
Or a web server using a daemon different from apache? :)

This is why I think (as others) a server profile should basically be the same 
as a minimal profile. 
And then, defining a minimal profile separate from the base profile does not 
make too much sense. Rather, carefully try to move all specific stuff out of 
the base profile.

[ That said, CVS is such a pain, I'll not do anything like this again before 
we finish the GIT migration... :D ]

-- 

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] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/16/2013 06:33 PM, Michael Orlitzky wrote:
 Yes, sorry for the confusion. I use more than one package manager,
 and when doing an update or upgrade I'm basically flipping a
 coin.
hehe, as long as we don't --dist-upgrade ;-)
the g was intentional.

how does portage @preserved-libs work? maybe we could emerge
@update[s] and @glsa.

https://wiki.archlinux.org/index.php/Pacman_Rosetta

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlD3PyYACgkQknrdDGLu8JDKOAEAlSRRrurL7VWpeMMtB2sVZeH4
Ik+D3d5LL1Nahflz+PIBAIWVFvyuNmzgnvE+wOpU70AIacTbprFcFJFOe9JaVBVr
=gKRT
-END PGP SIGNATURE-

Re: [gentoo-dev] January stabilization candidates

2013-01-16 Thread Rick Zero_Chaos Farina

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 01:09 PM, Matt Turner wrote:

honestly this list is such a tinderbox that I hardly read it. I actually
missed the email at first and had to go back in the thread when I saw a
lot of responses. Hence, I would prefer to get bugs than random emails
that I have to search through.

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

iQIcBAEBAgAGBQJQ90VqAAoJEKXdFCfdEflKC5QQAJ1CIMjcJabTxEgbnno1uXFM
wB1eC8JD6BWeUfHIRs3APW2Klw4Tnx9eGl0wvRaJLmpMULSO2f1DCregzcuIpvpC
L8Vk2RdVzVOzhU4ff7dYkc+MGRsh1ouTD9UMsALeyRorlOIQ74dkaqooDIm7WbPn
CnzDBWg/kCECNOtFUGI+aMifpqyPABAKauFi9qHisdHnUrg6+g7bUmenFEEaWYU+
vFIcWt3LYAFkzwkd3pg1ym3qsiEEMzBqE4BVhmTVKKCP85hyfe1wgBNPyL7bkxOx
b2W8wpcj5Uh9ddcX5CIPlfmS3L6qEN9lChteDCfuMS7AVnttcQi+NyQIpl/spKVz
L1G3OjZOxPyS3D+nV/V10vQKsvXgXvrTKo64adzzJccjKGowG0ZNSh8li4Xgpkw5
PzABq1eQfjFCC175fG+T3v/j1lGse8216YJTv6X17rYj9X7gRuT6gGRdFci3MuFn
KfeSLhoojdS2o3M/Cuqbt47YvARrNA3OLLYzrXvQr8EgC3K6VyusBIQEqxYn1a4b
KxXJtksgCXbUllMTCV8qNXXY2Izv0Ojhvx8hxgKumWXiDyMBOjXwvcYR2Opl8TPK
yKCeRFopmO/gahfArd/J8WvZWxDU0HTxkFplRfjx6Gwf57g9GeYDoCuEvHLp+SqU
6x6AKLLHVntMe0/Vpq3v
=6mSE
-END PGP SIGNATURE-

Re: [gentoo-dev] January stabilization candidates

2013-01-16 Thread Matt Turner

 honestly this list is such a tinderbox that I hardly read it. I actually
 missed the email at first and had to go back in the thread when I saw a
 lot of responses. Hence, I would prefer to get bugs than random emails
 that I have to search through.

So ignore it and he'll open bugs just the same. This was just an early
opportunity for people to say no, this shouldn't be stabilized.

Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)

2013-01-16 Thread Walter Dnes

On Thu, Jan 17, 2013 at 12:59:11AM +0100, Andreas K. Huettel wrote

 Sure a server is something generic, too.  However, since you mentioned
 mysql above, how about a postgres server?  Or a web server using a
 daemon different from apache? :)
 
 This is why I think (as others) a server profile should basically be
 the same as a minimal profile.  And then, defining a minimal profile
 separate from the base profile does not make too much sense. Rather,
 carefully try to move all specific stuff out of the base profile.

  If someone wants a *REALLY* basic system, they can start off with
USE=-* and add on stuff as necessary when portage complains and/or
ebuilds break.  That's what I'd recommend to someone wanting to set up a
basic server machine.

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-16 Thread Greg KH

On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
 On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge pe...@stuge.se wrote:
  Rich Freeman wrote:
  Not that anybody is taking requests, but it would be really handy
  if serial ports were deterministically labeled.
 
  Does /dev/serial/* solve the problem?
 
 I don't see this directory at all on my system.

Do you have a usb-serial device plugged in?  You need a serial device
for it to show up, and you need to be using udev.

greg k-h

Re: [gentoo-dev] call for testers: udev predictable network interface names

On Wed, Jan 16, 2013 at 9:49 PM, Greg KH gre...@gentoo.org wrote:
 On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
 On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge pe...@stuge.se wrote:
  Rich Freeman wrote:
  Not that anybody is taking requests, but it would be really handy
  if serial ports were deterministically labeled.
 
  Does /dev/serial/* solve the problem?

 I don't see this directory at all on my system.

 Do you have a usb-serial device plugged in?  You need a serial device
 for it to show up, and you need to be using udev.

Yes, I have two plugged in and they're working fine.  However, perhaps
my custom rules are preventing them from showing up:
SUBSYSTEM==tty, DRIVERS==pl2303, KERNELS==4-1:1.0,
KERNEL==ttyUSB*, SYMLINK=mythser/rca1
SUBSYSTEM==tty, DRIVERS==pl2303, KERNELS==3-3:1.0,
KERNEL==ttyUSB*, SYMLINK=mythser/rca2

I'm not sure if rules are additive - if these symlinks would show up
in addition to whatever other ones are created by other rules, or if
these would be exclusive.  I hard-coded them to specific physical USB
ports so that they would be persistent.  If I plug them in elsewhere
they still get ttyUSBn devices, but no symlinks.

Rich

Re: [gentoo-dev] removing the server profiles...

On Wed, Jan 16, 2013 at 5:53 PM, Panagiotis Christopoulos
pchr...@gentoo.org wrote:
 Err, ok, so now guys, we 're offering a base profile* with dri, cups, gmp,
 fortran and pppd(?) enabled, at the same time openmp enabled but threads
 disabled, no sockets, no caps no apache2 or mysql that I would probably
 want if I wanted to build a server box etc. and we officially drop the
 server profiles (which is true, they're unmaintained for ages).

Keep in mind that the current server profile has all the problems you
just listed as well.

Oh, and keep in mind that flags really only have an effect if the
corresponding packages are actually installed.  For example, the cups
flag doesn't really have an effect unless you install apps that do
printing, so it seems pretty safe to leave in a minimal profile (would
you really want to install libreoffice, chromium, or foomatic and not
have cups support?).  The only non-desktopy package I see that uses
cups is samba, and if you're setting up a samba server there is a
decent chance you'd want cups anyway.

So, I wouldn't equate minimal as -*.  I think that it makes sense to
have use flags that result in a very conservative installation of the
core packages (which isn't necessarily completely minimal), and which
don't pull in a lot of dependencies for other packages unless most
would want them anyway.

By all means point out use flags that actually do cause issues with
servers.  However, be careful about knee-jerk reactions.  Many flags
really do make sense in context - they don't do anything on a minimal
system, and when they do bring in dependencies they tend to be ones
you'd want anyway.

And, of course, when many of those profiles were first crafted there
were not package-level USE defaults, so that is something we can also
leverage to cut down on global flag settings (one way or the other).

Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes