Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Michael Weber
On 01/18/2013 08:36 AM, Benedikt Böhm wrote:
 On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber x...@gentoo.org
 mailto:x...@gentoo.org wrote:
 I'd like to drop one strong suggestion about configuration management
 that might be beneficial here: use version control software!
 or even /etc/.git ... it saved my life on numerous occasions

Sure, bit thats's the point were diversity (hostnames, ssh_host_keys)
kicks in (which has been eliminated in mentioned example) and
the repo carries confidential information.
(Well, if somebody places an compromised update in the
 local-overlay, i'd blindly install anything)

I even have / inside git for testing, with excludes on /opt/ /usr
/{s,}/bin /etc/ssl and so on.

It works and is handy to easily add apache config, web-app-config
installed roundcube, layman overlay list, but the maintenance of the
.gitignore raises and hardlink solutions like dirvish make more sense
for being complete backups (LD_LIBRRY_PATH=/backup/.../tree/usr/lib).

 for reference, here is my updateworld script, which also handles python,
 ruby, perl, revdep-rebuild and all that
 crap: 
 https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld
cool.

So basically everyone uses personal `apt-get update` (cvs co, porticron,
emerge+layman, eix-sync) strategies and even more
funny little scripts for `apt-get upgrade` (-avuND world, aliases,
scripts).

I wonder if anybody uses unattended [backup+]emerge as cron job.
I'm really temped to do so, but with users relying on these machines I'm
always chicken-out.

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



Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 9:13 AM, Michael Weber x...@gentoo.org wrote:

 I wonder if anybody uses unattended [backup+]emerge as cron job.
 I'm really temped to do so, but with users relying on these machines I'm
 always chicken-out.


i've refrained from doing unattended upgrades for a long time, but i'm
quite confident in updateworld these days and i usually test it on 2-3
machines and then let the other 50+ machines do it unattended and it has
been working fine so far ...

but - and that's quite important i guess - i only use my own clone of the
portage tree which i sync from time to time and i also keep different
versions stable, etc.


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Michael Weber
On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
 i've refrained from doing unattended upgrades for a long time, but i'm
 quite confident in updateworld these days and i usually test it on 2-3
 machines and then let the other 50+ machines do it unattended and it has
 been working fine so far ...
good strategy.

 but - and that's quite important i guess - i only use my own clone of
 the portage tree which i sync from time to time and i also keep
 different versions stable, etc.
HEAVY USER! But you have full control.
Do you have any sophisticated mechanism to detect tree breakage (i.e. us
f*** up), like Samuli replying -commit to -dev or irc activity?

Or do you simply delay commit? (re-schedule on weekends/nights)

Delaying stabilization seems legit, but on Gentoo-stable ?!

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



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

2013-01-18 Thread Ultrabug

Thanks for your work mate !

On 14/01/2013 21:24, Andreas K. Huettel wrote:

[CC'ing this to core so noone can complain afterwards.]

Since 48h did not lead to any responses positive or negative, I'll start
implementing the procedure as given in the original e-mail (quoted below).

As also said below, each arch will get a mail before I touch their profile
tree and after I've finished.

Cheers, Andreas


Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:

Hi everyone,

since Council has approved the creation of a fresh set of EAPI=5 13.0
profiles, I would like to volunteer for creating them. The proposed
procedure is outlined below in detail, and I'd be happy for comments.
[If anything below deviates from Council decision, please tell me- not my
intention.]

One general question comes first, though: Right now, the releases/10.0
profile directory does the following things:
* mask too-old portage
* set eapi
* add USE=bzip2

Is there anything unrelated to EAPI=5 that absolutely must be added to the
new releases/13.0 directory in addition in your opinion? (Whether this is
the right place and was the right place in the beginning for USE=bzip2 is
another question.)

###

The procedure (all paths relative to profiles):

1) create directory eapi-5-files, with eapi (containing 5), skeletons for
package.stable.mask etc and a readme

2) copy releases/10.0 to releases/13.0, in releases/13.0:
* increase required portage version
* additionally inherit ../../eapi-5-files
* other changes as per question above?

3) for each arch in default/linux,
* announce on arch alias (to prevent overlapping commits)
* copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
* change inheritance in the new copy to inherit ../../../../releases/13.0
instead of ../../../../releases/10.0
* announce on arch alias (so future changes go into 13.0 tree)
[This describes the simple case. I realize that there are differences in
the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
needs extra care.]

4) edit profiles.desc and copy all 10.0 lines to 13.0 lines, with an
initial setting dev (if dev or stable before) or exp (if exp before)
This makes repoman check against the new profiles when using developer
profiles.

5) announce the state on the dev list, urging devs to update their symlink
manually and !test!

6) wait one / two weeks

7) in profiles.desc, mark all 13.0 profiles stable that were stable in
10.0, and remove the lines for the 10.0 profiles. This makes eselect
profile now only offer the new ones, and repoman test by default against
13.0 profiles.

8) mark all 10.0 profiles as deprecated by creating a deprecated file
(containing the replacement suggestion) in the directory. This makes
portage warn users to upgrade (suggesting a new profile for them), and
repoman ignore the 10.0 profiles.

9) long waiting time as decided by Council

###

Everything that does NOT use/inherit 10.0 will remain unaffected, and
whoever responsible may have to take care of that some time before (in
step 10) the main profile directory becomes EAPI=5. This means e.g.
hardened, ulibc, prefix or bsd.

Cheers,
Andreas







Re: [gentoo-dev] Re: Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c

2013-01-18 Thread Maxim Kammerer
On Fri, Jan 18, 2013 at 6:13 AM, Paul Arthur
junk+use...@flowerysong.com wrote:
 Yes. This is the exact same issue secure-delete has, since it uses
 the same approach. shred is just as useful as srm (in fact it's more
 useful, since it doesn't mandate the full, useless run of 38 passes
 that srm does.)

srm doesn't mandate rewrites either.

Anyway, I actually forgot about shred, so I remove my objection.
Other utilities in secure-delete are either simple wrappers of
rarely-used functionality (sfill, sswap), or essentially useless
for modern kernels (smem — good luck clearing free RAM in userspace,
been there, tried that).

Some comments on replies in this thread:

1. Multiple rewrites are indeed useless for modern media, see [1].
2. So journal metadata is not cleared. BFD. If you need 100%
guarantees, drop media in acid.
3. Wear leveling on flash media is rarer than you think, and most
likely doesn't do what you think, see [2].
4. Wear leveling is irrelevant for the usual attack vectors, which is
a technician copying your naked gf photos. You need special hardware
to access hidden sectors. If you are worried about that, see (2).

[1] C. Wright et al., “Overwriting Hard Drive Data: The Great Wiping
Controversy”, http://dx.doi.org/10.1007/978-3-540-89862-7_21
[2] E. Gal and S. Toledo, “Algorithms and Data Structures for Flash
Memories”, http://dx.doi.org/10.1145/1089733.1089735

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



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

2013-01-18 Thread Michael Weber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/12/2013 09:47 PM, Andreas K. Huettel wrote:
 

10) add 13 to the selectable Versions in Bugzilla.
Not that anybody cares, but 10 and 10.1 are in there.

Maybe we could drop these values (dropping the field might need a
change in the code) to reduce the number of selection a
newbie reporter is faced.

- -- 
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/

iF4EAREIAAYFAlD5KUQACgkQknrdDGLu8JBmIwD/QGdNkWVAM5JsIDIXV9SGyNeC
lkxm02p8qpbnCE+ZAuYA/3Gdf9xh6OMcCz5OAuTNnUcNrJ5JhtFMPBodqOC9lF0b
=9c48
-END PGP SIGNATURE-



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

2013-01-18 Thread Markos Chandras
On 18 January 2013 10:51, Michael Weber x...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 01/12/2013 09:47 PM, Andreas K. Huettel wrote:


 10) add 13 to the selectable Versions in Bugzilla.
 Not that anybody cares, but 10 and 10.1 are in there.

 Maybe we could drop these values (dropping the field might need a
 change in the code) to reduce the number of selection a
 newbie reporter is faced.

Yeah this field is not used (properly) and it should be removed.
Usually a bug in one profile, is also present in other
profiles as well.

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



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

2013-01-18 Thread Michael Palimaka

On 18/01/2013 21:51, Michael Weber wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/12/2013 09:47 PM, Andreas K. Huettel wrote:




10) add 13 to the selectable Versions in Bugzilla.
Not that anybody cares, but 10 and 10.1 are in there.

Maybe we could drop these values (dropping the field might need a
change in the code) to reduce the number of selection a
newbie reporter is faced.

- --
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/

iF4EAREIAAYFAlD5KUQACgkQknrdDGLu8JBmIwD/QGdNkWVAM5JsIDIXV9SGyNeC
lkxm02p8qpbnCE+ZAuYA/3Gdf9xh6OMcCz5OAuTNnUcNrJ5JhtFMPBodqOC9lF0b
=9c48
-END PGP SIGNATURE-



+1




[gentoo-dev] On tinderboxing

2013-01-18 Thread Diego Elio Pettenò
On 18/01/2013 07:12, Duncan wrote:
 Now with a bit of luck, the amount of logs to sift through for an
 ffmpeg-targeted tinderbox would be much less than those generated by
 tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with
 a total of 10/12 hr of work all in all? I wouldn't go as far as ask for
 my going hourly rate, but especially for ffmpeg, it would come for
 something a bit higher than a dinner at the next conference — more like
 the travel expenses (given a conference such as FOSDEM, not SCALE, to
 give an idea).
 
 So several days of machine time, and /very/ conservatively, at least a 
 work day of your time, more likely 1.5-2 workdays, maybe half a week.

Yes that sounds about right about timing.

 One more question.  I've read about various tinderbox runs, and now we 
 know they take several days of machine time plus say 1-2 (surely more for 
 the really involved stuff, glibc and gcc touch about everything...) days 
 of your time.

It gets trickier with gcc and glibc, because package A can stop package
B, C, D and E from merging if it fails, so a single run never is enough
for them...

 Are you queued up with tinderbox runs, or is there room for more demand?  

I've got one run that is queued that I'm not running yet which is the
pkgconf one — I'm considering setting up a clone of tbamd64 for that
since the gcc/glibc/automake one right now it's taking a long time.

 If someone like Shuttleworth came along and offered to sponsor you to 
 work on gentoo and tinderboxes full time, how far up could it scale 
 before it required more people, and would there be ever more tinderbox 
 possibilities or would the law of diminishing returns kick in?  Would you 
 consider that or find it too boring or depressing to do full time?

I'm not sure honestly if we're not very near already to that point of
diminishing returns. For sure, if I was paid to do tinderboxing full
time I would be spending more time on automating. In particular, having
a quick way to search for open bugs for the package from the analysis
interface would cut the time I spend on it considerably.

While some people have complained about the lack of attached logs, I'm
not going to focus on that just yet because for so many of the logs, it
would require compressing them with xz and even then they might not fit,
so it's not something I see much use for.

One bothersome thing is that a lot of the current process relies on me
keeping in mind packages and patterns I've seen before. You can guess
it's not an easy walk to scale to multiple people this way. So fixing
long-standing bugs to remove not-so-false positives that were already
filed two years ago might be of help.

Right now I guess one of the biggest wastes of time is the doc USE flag
that I enabled globally on the tinderbox, to catch Ruby packages'
failures, and is causing a bunch of other packages to fail as well as
those conditionals are rarely tested at all.

 So I know I've directly benefited from your tinderbox runs and other 
 projects you've done, and I really do appreciate it, especially as I know 
 much of it is volunteer, tho some is work related but benefits gentoo as 
 well.

I'm glad you feel the tinderbox has helped — sometimes I'm honestly not
sure myself. But a lot of the work that is done there couldn't be
possible without things like IUSE defaults and REQUIRED_USE, as those
used to waste much much more of my time just to follow the right
dependencies to be aable to merge the packages. So I think Zac and the
other Portage developers deserve most of the cheers there, as I've
shown, I mostly just pour in the time.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

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

Il 09/01/2013 23:13, William Hubbs ha scritto:

All,

as you probably know by now, udev-197 has hit the tree.

This new version implements a new feature called predictable network
interface names [1], which I have currently turned off for live systems, 
because it
will require migration on the part of the user.

When you upgrade to this new version of udev, you will find a file
/etc/udev/rules.d/80-net-name-slot.rules on your system. It currently
has comments explaining what is happening.

As long as this file is in place, this feature is not activated. That is
why there is not a news item. If you do nothing, nothing changes.

What I would like to do is find some people who are willing to migrate
and report any issues they find.

I would like this to be the default for everyone at some point, so I
want to document the migration process and find out if there are any
bugs in tools because they expect the eth* names.

Thoughts?

William

[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Since for servers predictable names are useful and for desktop (which 
usually have only one ethernet that never change)
Is it possible to set desktop profiles to still use ethX, and base 
profile to use new naming scheme?


For wireless situation may be different, many of them are external, 
could wireless be managed differently?




Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@gentoo.org wrote:

 On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
  but - and that's quite important i guess - i only use my own clone of
  the portage tree which i sync from time to time and i also keep
  different versions stable, etc.
 HEAVY USER! But you have full control.
 Do you have any sophisticated mechanism to detect tree breakage (i.e. us
 f*** up), like Samuli replying -commit to -dev or irc activity?

 Or do you simply delay commit? (re-schedule on weekends/nights)


i manually sync with the gentoo-x86 repo from time to time (except security
issues, which i sync as soon as they are fixed)

i have no automated way to detect any tree breakage, but when i sync the
complete tree i do extensive manual testing on a handfull of machines
(either staging machines, or ones that are not really important)

but the main reason i even have a clone is to sync updates in batches. it's
really a hassle to keep servers in sync when changes to gentoo-x86 happen
any other minute. i also need to adapt my chef cookbooks for some updates,
so i do it all in one batch (sync, test, adapt, test, deploy)


 Delaying stabilization seems legit, but on Gentoo-stable ?!


it's not really about delaying stabilization ... there is quite a big list
of packages in my repo where i always stabilize the latest version(s) even
if gentoo-x86 is unstable. e.g. i've stabled openrc a looong time before
gentoo-x86 had it stable, etc.

it's also a lot easier to add new packages because i don't have to support
everything and the kitchen sink ... my repo just supports amd64 and it also
has quite a few binary ebuilds which would not be a good fit for gentoo-x86

if you're interested, it's all on github:
https://github.com/zentoo/zentoo(all the sync tools are in the script
directory and were initially copied
from the prefix guys, but have been heavily modified since ...)

Cheers,
Bene


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 2:13 PM, Benedikt Böhm hol...@gentoo.org wrote:

 On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@gentoo.org wrote:

 On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
  but - and that's quite important i guess - i only use my own clone of
  the portage tree which i sync from time to time and i also keep
  different versions stable, etc.
 HEAVY USER! But you have full control.
 Do you have any sophisticated mechanism to detect tree breakage (i.e. us
 f*** up), like Samuli replying -commit to -dev or irc activity?

 Or do you simply delay commit? (re-schedule on weekends/nights)


 i manually sync with the gentoo-x86 repo from time to time (except
 security issues, which i sync as soon as they are fixed)

 i have no automated way to detect any tree breakage, but when i sync the
 complete tree i do extensive manual testing on a handfull of machines
 (either staging machines, or ones that are not really important)

 but the main reason i even have a clone is to sync updates in batches.
 it's really a hassle to keep servers in sync when changes to gentoo-x86
 happen any other minute. i also need to adapt my chef cookbooks for some
 updates, so i do it all in one batch (sync, test, adapt, test, deploy)


i forgot to add one main difference here: i only have ~1000 packages in my
repo, which makes it a lot faster for metadata, rsync, eix and all that ...
the repo is only used for server deployments. no desktop, no games, only
very few X11 ebuilds for headless testing etc.


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/01/13 03:13 AM, Michael Weber wrote:
 
 I wonder if anybody uses unattended [backup+]emerge as cron job. 
 I'm really temped to do so, but with users relying on these
 machines I'm always chicken-out.
 

I used to, up until around 2006-2007 , at that point too many of my
emerge -uDN @world runs would fail in the middle and require user
intervention, so it became not worth it.

Perhaps once EAPI5 and sub-slots proliferate the tree, it'll be ready
to try again..

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

iF4EAREIAAYFAlD5TU8ACgkQ2ugaI38ACPAGgQD7B1P6zsOxAXcYWIH5PRaVkWSD
s6h64Vid382u5vhgp8kBALSK2PpmIV4dMjM4SwC6eX9XAm0m3mblycXuRkxEccYa
=51W6
-END PGP SIGNATURE-



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

2013-01-18 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/01/13 07:24 AM, viv...@gmail.com wrote:
 Since for servers predictable names are useful and for desktop
 (which usually have only one ethernet that never change) Is it
 possible to set desktop profiles to still use ethX, and base 
 profile to use new naming scheme?
 
 For wireless situation may be different, many of them are
 external, could wireless be managed differently?
 

In short, no.  At least, not unless the functionality that is
currently a configure-time thing is changed into a
build-time/install-time thing controlled via a use flag.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD5TxkACgkQ2ugaI38ACPCQHAD7BEIoXLuskCfv/TllbCDaW94u
84t/PufZ03LJLjqzWlAA/Azuvil7oLWAzTxSDuHT+oheJsPvf4tBFmQUojSf+WIj
=FOCB
-END PGP SIGNATURE-



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

2013-01-18 Thread William Hubbs
On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 18/01/13 07:24 AM, viv...@gmail.com wrote:
  Since for servers predictable names are useful and for desktop
  (which usually have only one ethernet that never change) Is it
  possible to set desktop profiles to still use ethX, and base 
  profile to use new naming scheme?
  
  For wireless situation may be different, many of them are
  external, could wireless be managed differently?
  
 
 In short, no.  At least, not unless the functionality that is
 currently a configure-time thing is changed into a
 build-time/install-time thing controlled via a use flag.

Actually,this is how I set you up by dropping the file in
/etc/udev/rules.d/80-net-name-slot.rules.

Nothing changes on your system unless you remove this file and do not
have 70-persistent-net.rules.

William



pgpLqFtcVV6CJ.pgp
Description: PGP signature


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

2013-01-18 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/01/13 09:54 AM, William Hubbs wrote:
 On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 18/01/13 07:24 AM, viv...@gmail.com wrote:
 Since for servers predictable names are useful and for desktop 
 (which usually have only one ethernet that never change) Is it 
 possible to set desktop profiles to still use ethX, and base 
 profile to use new naming scheme?
 
 For wireless situation may be different, many of them are 
 external, could wireless be managed differently?
 
 
 In short, no.  At least, not unless the functionality that is 
 currently a configure-time thing is changed into a 
 build-time/install-time thing controlled via a use flag.
 
 Actually,this is how I set you up by dropping the file in 
 /etc/udev/rules.d/80-net-name-slot.rules.
 
 Nothing changes on your system unless you remove this file and do
 not have 70-persistent-net.rules.
 
 William
 

..right, but default behaviour can't be changed automatically
depending on what profile you're on, as vivo requested, since profiles
don't control configuration (just use flags)


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

iF4EAREIAAYFAlD5ZT4ACgkQ2ugaI38ACPCECQD6A78Wgm30Tx0RIfgblZhAu4d2
/2NFMtZng4JQlgmbCc8BAJZgPOgH3fxhSl+pRBpWFkZu/v5kwqxs+h+9ooBJZ5nG
=MhsO
-END PGP SIGNATURE-



Re: [gentoo-dev] RFC: new qt category

2013-01-18 Thread Markos Chandras
On 18 January 2013 04:24, Mike Frysinger vap...@gentoo.org wrote:
 On Thursday 17 January 2013 14:44:14 Ciaran McCreesh wrote:
 On Thu, 17 Jan 2013 14:35:12 -0500 James Cloos wrote:
   CM == Ciaran McCreesh writes:
  CM That's what's known as doing it wrong. You should be querying
  CM your package mangler for a list of categories, not doing an 'ls'.
 
  ls(1) isn't relevant.  find(1) is.  grep(1) is.  There are others.
 
  Using the 'package managers' isn't very helpful.  They generally do
  everything poorly.  And usually **s*l*o*w*l*y**, if they compile at
  all.

 On the other hand, they do things correctly, which your approach
 doesn't.

  I can't even remember every time I've needed to use a regex, glob or
  other pattern match where the fact that the real categories had a dash
  made things easier and faster.

 But wrong. If you want wrong answers quickly, cat /dev/urandom.

 and breaking people for no good reason is just that -- not a good reason.

 is code that makes this assumption kind of crappy ?  yes.  is this new
 proposal a compelling use case for breaking that (pretty common) assumption ?
 no.  there's no real technical overhead to have new qt categories follow the
 existing practice.
 -mike

I also like the current style for categories (foo-bar) and I also like
the qt-framework or qt-libs proposals but now that I think about
it again, I see no urgent reason to move away from x11-libs. I also
dislike the idea to drop the qt-* prefix from the Qt modules.

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



Re: [gentoo-dev] RFC: new qt category

2013-01-18 Thread Federico fox Scrinzi
On 17/01/2013 14:57, Ben de Groot wrote:
 Presently we already have a good number of split qt-* library packages
 in x11-libs.

How many?

└ ls -d /usr/portage/x11-libs/qt* | wc -l
22

 We, the Gentoo Qt team, are of the opinion that the time has
 come to split all these out into their own category.

-1
No way.

 This means x11-libs/qt-core will be moved to qt/core, and so on.

Do you really want me to do emerge core?

Moreover all other categories are called major-minor as Diego pointed
out. Consistency matters.

-- 
f.

  There are only two hard things in Computer Science: cache
   invalidation, naming things and off-by-one errors.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: new qt category

2013-01-18 Thread Christoph Junghans
2013/1/17 Ben de Groot yng...@gentoo.org:
 Hi guys,

 Presently we already have a good number of split qt-* library packages
 in x11-libs. With the arrival of Qt5 upstream has gone a lot further
 in modularization, so we expect the number of packages to grow much
 more. We, the Gentoo Qt team, are of the opinion that the time has
 come to split all these out into their own category. This category is
 to be used for the various modules and applications that belong to the
 upstream Qt Framework only (these include e.g. assistant and
 linguist). Third-party applications should remain in the current
 categories.

 After some initial bikeshedding we came to the conclusion that naming
 the category simply qt is the most elegant solution. We will then
 also be dropping the qt- prefix in package names. This means
 x11-libs/qt-core will be moved to qt/core, and so on.
-1

I don't like the idea of emerging gui instead qt-qui.

 Please let us know your thought on this.
 --
 Cheers,

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




--
Christoph Junghans
http://dev.gentoo.org/~ottxor/



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

2013-01-18 Thread Andreas K. Huettel

FYI, the new 13.0 profiles are now all available in profiles.desc, for now all 
with status dev (i.e. repoman includes them only when you request developer 
profile checking). 

This means the procedure below is complete up to and including point 5) now.

Please consider changing your profile symlink manually and testing the new 
profile tree. In case of problems, please file a bug and assign it to me (or 
tell me if I'm around).

If all goes well, we'll continue in a week. 

Cheers, 
Andreas

Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:
 Hi everyone,
 
 since Council has approved the creation of a fresh set of EAPI=5 13.0
 profiles, I would like to volunteer for creating them. The proposed
 procedure is outlined below in detail, and I'd be happy for comments.
 [If anything below deviates from Council decision, please tell me- not my
 intention.]
 
 One general question comes first, though: Right now, the releases/10.0
 profile directory does the following things:
 * mask too-old portage
 * set eapi
 * add USE=bzip2
 
 Is there anything unrelated to EAPI=5 that absolutely must be added to the
 new releases/13.0 directory in addition in your opinion? (Whether this is
 the right place and was the right place in the beginning for USE=bzip2 is
 another question.)
 
 ###
 
 The procedure (all paths relative to profiles):
 
 1) create directory eapi-5-files, with eapi (containing 5), skeletons for
 package.stable.mask etc and a readme
 
 2) copy releases/10.0 to releases/13.0, in releases/13.0:
 * increase required portage version
 * additionally inherit ../../eapi-5-files
 * other changes as per question above?
 
 3) for each arch in default/linux,
 * announce on arch alias (to prevent overlapping commits)
 * copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
 * change inheritance in the new copy to inherit ../../../../releases/13.0
 instead of ../../../../releases/10.0
 * announce on arch alias (so future changes go into 13.0 tree)
 [This describes the simple case. I realize that there are differences in
 the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
 needs extra care.]
 
 4) edit profiles.desc and copy all 10.0 lines to 13.0 lines, with an
 initial setting dev (if dev or stable before) or exp (if exp before)
 This makes repoman check against the new profiles when using developer
 profiles.
 
 5) announce the state on the dev list, urging devs to update their symlink
 manually and !test!
 
 6) wait one / two weeks
 
 7) in profiles.desc, mark all 13.0 profiles stable that were stable in
 10.0, and remove the lines for the 10.0 profiles. This makes eselect
 profile now only offer the new ones, and repoman test by default against
 13.0 profiles.
 
 8) mark all 10.0 profiles as deprecated by creating a deprecated file
 (containing the replacement suggestion) in the directory. This makes
 portage warn users to upgrade (suggesting a new profile for them), and
 repoman ignore the 10.0 profiles.
 
 9) long waiting time as decided by Council
 
 ###
 
 Everything that does NOT use/inherit 10.0 will remain unaffected, and
 whoever responsible may have to take care of that some time before (in
 step 10) the main profile directory becomes EAPI=5. This means e.g.
 hardened, ulibc, prefix or bsd.
 
 Cheers,
 Andreas


-- 

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



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


[gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Andreas K. Huettel

During the server profile discussion, it became clear that we could clean up 
the base profiles a bit. This is unrelated to the profile versions, as the 
change would affect all versions (well, at least without bigger changes). 

What I suggested and what djc and kensington supported was: 

* move setting USE=dri and USE=cups from default/linux/make.defaults to 
targets/desktop/make.defaults

* remove setting USE=pppd in default/linux/make.defaults, instead have it 
default to on in net-dialup/capi4k-utils (the only place where it is used)

Opinions?

Cheers, A

-- 

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] USE flags dri, cups, pppd

2013-01-18 Thread Mike Frysinger
On Friday 18 January 2013 15:49:38 Andreas K. Huettel wrote:
 During the server profile discussion, it became clear that we could clean
 up the base profiles a bit. This is unrelated to the profile versions, as
 the change would affect all versions (well, at least without bigger
 changes).
 
 What I suggested and what djc and kensington supported was:
 
 * move setting USE=dri and USE=cups from default/linux/make.defaults to
 targets/desktop/make.defaults
 
 * remove setting USE=pppd in default/linux/make.defaults, instead have it
 default to on in net-dialup/capi4k-utils (the only place where it is used)

+1
-mike


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


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Davide Pesavento
On Fri, Jan 18, 2013 at 12:49 PM, Andreas K. Huettel
dilfri...@gentoo.org wrote:

 During the server profile discussion, it became clear that we could clean up
 the base profiles a bit. This is unrelated to the profile versions, as the
 change would affect all versions (well, at least without bigger changes).

 What I suggested and what djc and kensington supported was:

 * move setting USE=dri and USE=cups from default/linux/make.defaults to
 targets/desktop/make.defaults

 * remove setting USE=pppd in default/linux/make.defaults, instead have it
 default to on in net-dialup/capi4k-utils (the only place where it is used)

 Opinions?


+1

Thanks,
Davide



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Chí-Thanh Christopher Nguyễn
Andreas K. Huettel schrieb:
 * move setting USE=dri and USE=cups from default/linux/make.defaults to
 targets/desktop/make.defaults

I would prefer to keep USE=dri in the default profile.
If you want to move VIDEO_CARDS that would be fine with me though.


Best regards,
Chí-Thanh Christopher Nguyễn





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

2013-01-18 Thread Michał Górny
On Fri, 18 Jan 2013 21:37:10 +0100
Andreas K. Huettel dilfri...@gentoo.org wrote:

 
 FYI, the new 13.0 profiles are now all available in profiles.desc, for now 
 all 
 with status dev (i.e. repoman includes them only when you request developer 
 profile checking). 
 
 This means the procedure below is complete up to and including point 5) now.
 
 Please consider changing your profile symlink manually and testing the new 
 profile tree. In case of problems, please file a bug and assign it to me (or 
 tell me if I'm around).
 
 If all goes well, we'll continue in a week. 

Hmm, I think we need a bit more fine-grained EAPI=5 directories, at
least for arch-specific unmasks. Not sure if I shall use the
arch-specific 13.0 profiles or something more common shall be
introduced.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


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

2013-01-18 Thread Joshua Saddler
On Wed, 16 Jan 2013 00:36:18 +0100
Andreas K. Huettel dilfri...@gentoo.org wrote:

 
 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. 
 
 The easiest way to do this would be to 
 * just not copy the server profiles from 10.0 to 13.0 and
 * have the deprecation warning for 10.0/server point to 13.0 (i.e. prompt 
 users to upgrade from the 10.0 server profile to the 13.0 base profile).

whenever the rest of the developers reach a consensus, please file a bug report 
to let the documentation team know what changes we need to make to the upgrade 
guide and other docs. thanks!



signature.asc
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Patrick McLean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/01/13 02:02 PM, Chí-Thanh Christopher Nguyễn wrote:
 Andreas K. Huettel schrieb:
 * move setting USE=dri and USE=cups from default/linux/make.defaults to 
 targets/desktop/make.defaults
 
 I would prefer to keep USE=dri in the default profile. If you want to move 
 VIDEO_CARDS that would be fine with me though.

USE=dri is usually only relevant on desktops, why enable it on all profiles?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJQ+dhBAAoJEHy/RO9cNQiDLt8P/3C8r+WtNM991Z5pAGIbabOz
ILTx2vvd2rDbo8RM+sCbr2elDF/WP0xntTwnTw3vxWMs8VC6/HZkM+LQLyaMMeMo
tWK9MtV8R7+QZ7XDoOmVDSKe9U62XGlMnnpWV3B7A4s51y71vMqY+TNDBneJWvTz
nh780899va7BVCyRtQ8ed6XjTPx2ft1bDNLr5Vcms3vp0yHXarvgqBXLJjh/Zec1
a+S1IwETNMaTr4Lg2ps5zKgoMvUb6bGTEpo4cksTAHUjISYRRJHyxhZOON2fPOw5
a1RNH0i0fWfipEU3XP5KMgH/mQYu4KNob3LjlKHuspUDjYbfeFkkYyC7jBAucioE
Z5YUfPKXPmE1tzQy59Ld0xQTXdrxES+uWwk1XC3UG+iGgKByk5rEyBX7RX3+brQQ
QdAcBuRBzZtrfAK9B9Un6jBE1bX81o/twiVvu3aTCHXXgGKuEUWfnLmjcJnuj0KE
pWyA3xYfPM11eTq5aWivizChSm7pJxcrR8+GDx4c24mlvJxb0vpuinZJlkaASVIZ
Ncvgmk8+d/L1f32Xeyz4GMDU2SzQA8lTdeUK9E7XyRRcZJOFPpdYMSIhYXAMD9SV
A8vU/zRTjAwrQ6OGVzHxowKQ6Av4pajv7hXeq7pW+dnxURdcOGMV+mbDZ1Qj4kOh
QKuxdgZxOAchIF2TSEq0
=ryu6
-END PGP SIGNATURE-



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Ciaran McCreesh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 18 Jan 2013 15:18:25 -0800
Patrick McLean chutz...@gentoo.org wrote:
 USE=dri is usually only relevant on desktops, why enable it on all
 profiles?

This question only matters if you expect there to be non-desktops where
there are packages installed that IUSE dri.

- -- 
Ciaran McCreesh

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlD52OMACgkQ96zL6DUtXhECCgCgkfNiAX7Z7M3piVUN21Hj/KAy
kwsAoMPZISStAtGjk2uXtPT3FbOYox6W
=uz0E
-END PGP SIGNATURE-


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Chí-Thanh Christopher Nguyễn
Patrick McLean schrieb:
  I would prefer to keep USE=dri in the default profile. If you want to move 
  VIDEO_CARDS that
would be fine with me though.

 USE=dri is usually only relevant on desktops, why enable it on all
profiles?

Because it should be enabled when the respective packages are installed,
and not depending on the profile the user has selected.


Best regards,
Chí-Thanh Christopher Nguyễn





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

2013-01-18 Thread Andreas K. Huettel
Am Freitag, 18. Januar 2013, 23:20:50 schrieben Sie:
 On Fri, 18 Jan 2013 21:37:10 +0100
 
 Andreas K. Huettel dilfri...@gentoo.org wrote:
  FYI, the new 13.0 profiles are now all available in profiles.desc, for
  now all with status dev (i.e. repoman includes them only when you
  request developer profile checking).
  
  This means the procedure below is complete up to and including point 5)
  now.
  
  Please consider changing your profile symlink manually and testing the
  new profile tree. In case of problems, please file a bug and assign it
  to me (or tell me if I'm around).
  
  If all goes well, we'll continue in a week.
 
 Hmm, I think we need a bit more fine-grained EAPI=5 directories, at
 least for arch-specific unmasks. Not sure if I shall use the
 arch-specific 13.0 profiles or something more common shall be
 introduced.

I think it's perfectly fine now to raise the EAPI to 5 anywhere in the profile 
trees that (also) inherit 13.0 (since they need it anyway). 

So, in my opinion, we can just do that wherever needed. 

The intention of the eapi-5-files directory is just to hold the files that 
will be moved into global scale once the old profiles are gone.

-- 

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] USE flags dri, cups, pppd

2013-01-18 Thread Markos Chandras
On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Patrick McLean schrieb:
  I would prefer to keep USE=dri in the default profile. If you want to move 
  VIDEO_CARDS that
 would be fine with me though.

 USE=dri is usually only relevant on desktops, why enable it on all
 profiles?

 Because it should be enabled when the respective packages are installed,
 and not depending on the profile the user has selected.


 Best regards,
 Chí-Thanh Christopher Nguyễn



Hell, as discussed, the base profile should contain the absolute
minimal flags, and dri does not appear to be one of these.
Having graphics support on such a profile is not expected. IMHO it
should be moved to the desktop profile

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



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Aaron W. Swenson
On Fri, Jan 18, 2013 at 11:55:07PM +, Markos Chandras wrote:
 On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
  Patrick McLean schrieb:
   I would prefer to keep USE=dri in the default profile. If you
   want to move VIDEO_CARDS that would be fine with me though.
  
   USE=dri is usually only relevant on desktops, why enable it on
   all profiles?
 
  Because it should be enabled when the respective packages are
  installed, and not depending on the profile the user has selected.
 
 
  Best regards,
  Chí-Thanh Christopher Nguyễn
 
 
 
 Hell, as discussed, the base profile should contain the absolute
 minimal flags, and dri does not appear to be one of these.
 Having graphics support on such a profile is not expected. IMHO it
 should be moved to the desktop profile
 

++ If the base profile is to become our server profile, it should not
have graphics related USE flags enabled.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgpJrpEK6gSzG.pgp
Description: PGP signature


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

2013-01-18 Thread Christopher Head
On Thu, 17 Jan 2013 15:02:48 -0500
Rich Freeman ri...@gentoo.org wrote:

 We might be talking past each other.  Sane but minimal is the target.
 
 Bottom line is that the question isn't whether a minimal system should
 have CUPS installed (that would be an argument for putting it in
 @system - ugh!).  The question is whether a minimal/base system should
 have the cups USE-flag enabled for packages that actually use it.
 
 And cups is just an example - maybe not a good one.  I just want to
 make sure we're not just dropping flags left and right that everybody
 and their uncle will either re-enable, or won't notice them being
 removed anyway.

I understand that enabling flags only affects packages if they’re
installed. I’m just saying that, in my opinion, sane-but-minimal should
have CUPS disabled because there are plenty of computers that would
want LibreOffice and/or Chromium installed but not have a printer. They
need not be servers if the target is simply sane-but-minimal.

Chris



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Ciaran McCreesh
On Fri, 18 Jan 2013 23:58:22 +
Aaron W. Swenson titanof...@gentoo.org wrote:
  Hell, as discussed, the base profile should contain the absolute
  minimal flags, and dri does not appear to be one of these.
  Having graphics support on such a profile is not expected. IMHO it
  should be moved to the desktop profile
  
 
 ++ If the base profile is to become our server profile, it should not
 have graphics related USE flags enabled.

...but that's not how USE flags work. It doesn't matter if you enable
monkeys in the base profile, since the only people who are affected are
people who install monkey-related packages. It doesn't affect server
users. Minimal is irrelevant.

-- 
Ciaran McCreesh



signature.asc
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Chí-Thanh Christopher Nguyễn
Markos Chandras schrieb:
 On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Because it should be enabled when the respective packages are
 installed, and not depending on the profile the user has selected.
 Hell, as discussed, the base profile should contain the absolute
 minimal flags, and dri does not appear to be one of these.
 Having graphics support on such a profile is not expected. IMHO it
 should be moved to the desktop profile


If you have an absolute minimal system, then none of your packages will
have the dri flag. So it won't hurt. If you remove the dri flag from the
default profile, this will break users' setups for no good reason.

Moving to EAPI=1 USE defaults would be an alternative if the dri flag is
deemed unacceptable for the default profile, but in my opinion a
pointless exercise as it would change precisely zero systems.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Aaron W. Swenson
On Sat, Jan 19, 2013 at 01:02:04AM +0100, Chí-Thanh Christopher Nguyễn wrote:
 Markos Chandras schrieb:
  On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
  chith...@gentoo.org wrote:
  Because it should be enabled when the respective packages are
  installed, and not depending on the profile the user has selected.
  Hell, as discussed, the base profile should contain the absolute
  minimal flags, and dri does not appear to be one of these.
  Having graphics support on such a profile is not expected. IMHO it
  should be moved to the desktop profile
 
 
 If you have an absolute minimal system, then none of your packages will
 have the dri flag. So it won't hurt. If you remove the dri flag from the
 default profile, this will break users' setups for no good reason.
 
 Moving to EAPI=1 USE defaults would be an alternative if the dri flag is
 deemed unacceptable for the default profile, but in my opinion a
 pointless exercise as it would change precisely zero systems.
 
 
 Best regards,
 Chí-Thanh Christopher Nguyễn
 
 

And now I'm going to reverse my original vote. The only packages that
have the `dri' USE flag are in the x11-{drivers,libs} categories. As
such, it doesn't matter very much whether or not `dri' is in the base
profile. Better to leave it than remove it seeing as Chí-Thanh says,
it will have less of an impact on the users.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgp0ClIZVb_p5.pgp
Description: PGP signature


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

2013-01-18 Thread Michał Górny
On Sat, 19 Jan 2013 00:47:09 +0100
Andreas K. Huettel dilfri...@gentoo.org wrote:

 Am Freitag, 18. Januar 2013, 23:20:50 schrieben Sie:
  On Fri, 18 Jan 2013 21:37:10 +0100
  
  Andreas K. Huettel dilfri...@gentoo.org wrote:
   FYI, the new 13.0 profiles are now all available in profiles.desc, for
   now all with status dev (i.e. repoman includes them only when you
   request developer profile checking).
   
   This means the procedure below is complete up to and including point 5)
   now.
   
   Please consider changing your profile symlink manually and testing the
   new profile tree. In case of problems, please file a bug and assign it
   to me (or tell me if I'm around).
   
   If all goes well, we'll continue in a week.
  
  Hmm, I think we need a bit more fine-grained EAPI=5 directories, at
  least for arch-specific unmasks. Not sure if I shall use the
  arch-specific 13.0 profiles or something more common shall be
  introduced.
 
 I think it's perfectly fine now to raise the EAPI to 5 anywhere in the 
 profile 
 trees that (also) inherit 13.0 (since they need it anyway). 
 
 So, in my opinion, we can just do that wherever needed. 
 
 The intention of the eapi-5-files directory is just to hold the files that 
 will be moved into global scale once the old profiles are gone.

Well, in this particular case I'm wondering if there shouldn't be
a similar solution for the arch/*. In other words arch/*/eapi-5-files
which will be moved to main arch scope once the old profiles are gone.

But I guess we could just move the files from default/linux/*/13.0.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


[gentoo-dev] Separately buildable binary blobs

2013-01-18 Thread Doug Goldstein
How important are separately buildable binary blobs? Rather than speak
in terms of app/foo and app/bar, I'll just come out and say its
app-emulation/qemu. Due to the nature of the package it relies on
firmware blobs to emulate certain aspects of the system (e.g. BIOS).
I've been working on making each of the binary blobs buildable and
adding them to the tree e.g.
sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
sys-firmware/vgabios. Unfortunately QEMU upstream keeps their own
repos of the various components and for each release builds their own
and commits it within their repo. They ship with these pre-built blobs
and that is what they install by default. The result is from the true
package upstreams there often is not a release that works with QEMU.
For example, QEMU 1.3.0 requires a git revision of SeaBIOS.

So basically, how important is it to keep supporting these separately
buildable blobs knowing that it might slow the release of QEMU within
our own tree.

-- 
Doug Goldstein



Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c

2013-01-18 Thread Doug Goldstein
On Thu, Jan 17, 2013 at 1:21 PM, Pacho Ramos pa...@gentoo.org wrote:
 # Pacho Ramos pa...@gentoo.org
 # Dead since 2003, doesn't work with journaling filesystems.
 # Also collides with dev-util/smem (#288721). Removal in a month.
 app-misc/secure-delete


FWIW, we also have app-misc/scrub in the tree which likely does similar things.

http://code.google.com/p/diskscrub/

-- 
Doug Goldstein



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Rick Zero_Chaos Farina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/18/2013 07:02 PM, Chí-Thanh Christopher Nguyễn wrote:
 Markos Chandras schrieb:
 On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Because it should be enabled when the respective packages are
 installed, and not depending on the profile the user has selected.
 Hell, as discussed, the base profile should contain the absolute
 minimal flags, and dri does not appear to be one of these.
 Having graphics support on such a profile is not expected. IMHO it
 should be moved to the desktop profile

 
 If you have an absolute minimal system, then none of your packages will
 have the dri flag. So it won't hurt. If you remove the dri flag from the
 default profile, this will break users' setups for no good reason.
 
 Moving to EAPI=1 USE defaults would be an alternative if the dri flag is
 deemed unacceptable for the default profile, but in my opinion a
 pointless exercise as it would change precisely zero systems.

I agree completely, if removing USE=dri from base will mess with users
let's just not do it.  For minimalists it will have no effect anyway.

+1 (to the moves everyone agrees on and not moving dri) and thanks for
all your hard work on this.

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

iQIcBAEBAgAGBQJQ+hzDAAoJEKXdFCfdEflK0UYP/AmqXGE4OGqMMgya5qt/9XRJ
+9Ys4Ya3iBHnEnhiHyFCYr1IDrIHMMzEv1v9uRrbMnVkDgiYyE4ELpsovM60uZOG
pRXA5MpdqKU4J+GTbTLQ9tDJ1EEtHEmlMA5y2cFF582r0Gzkz+1ygsM07KIHFfDE
ts6kltTqmMF8D6JoUy5ABQnjtv3NMlIC7AIOx3OQzB61xI3rZmSgwS/n1ta3vw+c
Mb1T0AzQxRJS6hh6Ydq3rBbR7OceMWfzOg5Mo4mz/UdKYJjvgvSmXiJ6EqsoBLWy
v5ITcD8WN4orMbZCymCYTYmI/lza8VhVo+kHBkgEbpAZlS9cHpmVKkEZ7qY8q5OM
h0qBQEm6iur1c8Khu8YgDjGwrbZSPp91H5w9cudqoZC/jJMhnIJTL5ZVBRs5l+W1
/YE+jtJMWiXWKpsH9oIiPz15MDuZxU5vJN0XE676Qo6YO2bNZVndENTX+Hg4BDEs
ZiUkOgRlvnmcfHx2rZsFJUsjrI0XDyjDcEhXaep9p7STWGO2acEVwFVfU9buMUMF
YltMTioUs/rxIAYRujyHrvj/y2l3mwHe1f6l/AI0ARhJcIjUo9Ek6mtUB35GyPuI
0x8dRSnvWpO4TeS3aRRbZiIqdmCYSUP6bIbdcjWotANZWS/dRE/CxpPa62qJlsV6
r5t6p8ttHewzLfS9pquE
=RRAI
-END PGP SIGNATURE-