[gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )

2009-10-23 Thread Torsten Veller 
* Robin H. Johnson (robbat2) robb...@gentoo.org:
 1.1  app-arch/hardlink/hardlink-0.1.1.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain

 src_install() {
   emake DESTDIR=${D} install
 ^ || die
 }


 1.1  app-arch/duff/duff-0.4.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain

 src_install() {
   emake DESTDIR=${D} install
 ^ || die
   dodoc AUTHORS ChangeLog HACKING NEWS README* TODO
 }


An imprecise search (/make .*install$/) revealed another 200 packages:
http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt

Let it die before replacing a working package with a broken one.

Thanks

[gentoo-dev] eapi files and profiles

2009-10-23 Thread Samuli Suominen 
So I was told Council needs to approve inheritance of eapi files from
parent profiles?

I'm not sure why, because we shouldn't have any files in default/linux/
which was decided long ago when the new profiles was introduced...

gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l
63

That's 63 duplicated files. We should only have one releases/10.0/eapi
file, and others wouldn't be required as it would cover all the 10.0
profiles.

See, http://bugs.gentoo.org/288320

Can we get a decision on this soon, so we can drop the duplication for
10.1 (or whatever the name for next profile set will be called) ?

Re: [gentoo-dev] eapi files and profiles

2009-10-23 Thread Ulrich Mueller 
 On Fri, 23 Oct 2009, Samuli Suominen wrote:

 So I was told Council needs to approve inheritance of eapi files
 from parent profiles?

Doesn't http://bugs.gentoo.org/288320#c7 cover this? Why would you
need explicit inheritance?

And which EAPI should be taken, if you have more than one parent
profile? (All of them? Can a profile have multiple EAPIs?)

Ulrich

Re: [gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )

2009-10-23 Thread Victor Ostorga 
On Fri, 23 Oct 2009 09:28:47 +0200
Torsten Veller ml...@veller.net wrote:

 * Robin H. Johnson (robbat2) robb...@gentoo.org:
  1.1  app-arch/hardlink/hardlink-0.1.1.ebuild
  
  file :
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup
  plain:
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain
 
  src_install() {
  emake DESTDIR=${D} install
  ^ || die
  }
 
 
  1.1  app-arch/duff/duff-0.4.ebuild
  
  file :
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup
  plain:
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain
 
  src_install() {
  emake DESTDIR=${D} install
  ^ || die
  dodoc AUTHORS ChangeLog HACKING NEWS README* TODO
  }
 
 
 An imprecise search (/make .*install$/) revealed another 200 packages:
 http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt
 
 Let it die before replacing a working package with a broken one.
 
 Thanks
 

maintainer-needed done

Detail:
app-dicts/qvortaro/qvortaro-0.3.0.ebuild
app-dicts/qvortaro/qvortaro-0.3.1.ebuild
app-misc/muttprint/muttprint-0.72d-r1.ebuild already done
app-shells/fish/fish-1.23.0.ebuild
dev-lang/nqc/nqc-2.5.1.ebuild
dev-util/valkyrie/valkyrie-1.3.0.ebuild
dev-util/valkyrie/valkyrie-1.4.0.ebuild
sys-auth/libnss-cache/libnss-cache-0.1.ebuild
sys-block/unieject/unieject-5.3.2.ebuild
www-apps/swish-e/swish-e-2.4.3-r1.ebuild
www-apps/swish-e/swish-e-2.4.3.ebuild

Víctor.

Re: [gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )

2009-10-23 Thread Justin 
Torsten Veller wrote:
 * Robin H. Johnson (robbat2) robb...@gentoo.org:
 1.1  app-arch/hardlink/hardlink-0.1.1.ebuild

 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain
 
 src_install() {
  emake DESTDIR=${D} install
  ^ || die
 }
 
 
 1.1  app-arch/duff/duff-0.4.ebuild

 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain
 
 src_install() {
  emake DESTDIR=${D} install
  ^ || die
  dodoc AUTHORS ChangeLog HACKING NEWS README* TODO
 }
 
 
 An imprecise search (/make .*install$/) revealed another 200 packages:
 http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt
 
 Let it die before replacing a working package with a broken one.
 
 Thanks
 

sci-chemistry/caver/caver-0.99.2.ebuild
sci-chemistry/caver/caver-0.99.4.ebuild

Are both outdated and can be removed. (if someone would proxy me for that).
I am maintaining a newer version in sci overlay.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Amount of useflags enabled by default

2009-10-23 Thread Thomas Sachau 
Hi,

i would like to start a discussion about reducing the amount of default-enabled 
USE flags in
profiles, especially in inherited basic profiles.

Is there any policy, when they are added, how the reason for addition is 
documented and when they
are removed from profiles?

In addition, i see a trend to enabled more more more USE flags (either over 
profiles or via IUSE
+flag). Whats the reason for forcing a big load of default enabled USE flags on 
every user including
more dependencies, more compile time, more wasted disk space and more possible 
vulnerabilities
except some users, who complain about a missing feature and are not able to 
think and enable a USE
flag for that feature?


-- 
Thomas Sachau

Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )

2009-10-23 Thread Justin Bronder 
On 23/10/09 09:28 +0200, Torsten Veller wrote:
 An imprecise search (/make .*install$/) revealed another 200 packages:
 http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt
 
 Let it die before replacing a working package with a broken one.
 
 Thanks
 

Fixed:

sys-cluster/osc-mpiexec/osc-mpiexec-0.83.ebuild
sys-cluster/pvfs2/pvfs2-2.7.0-r2.ebuild

Thanks.

-- 
Justin Bronder


pgpPkLOszttX4.pgp
Description: PGP signature

[gentoo-dev] Re: make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )

2009-10-23 Thread Jonathan Callen 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Torsten Veller wrote:
 An imprecise search (/make .*install$/) revealed another 200 packages:
 http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt
 
 Let it die before replacing a working package with a broken one.

Removed from tree:
kde-base/kdebase/kdebase-3.5.9.ebuild
kde-base/kdebase/kdebase-3.5.9-r1.ebuild
kde-base/kdebase/kdebase-3.5.9-r2.ebuild
kde-base/kdebase/kdebase-3.5.9-r3.ebuild

Fixed:
kde-base/kdebase/kdebase-3.5.9-r4.ebuild
kde-base/kdm/kdm-3.5.10.ebuild

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

iEYEARECAAYFAkrh9VoACgkQOypDUo0oQOrTKgCdEPCduNbtJROucNWoc/2m6Nh2
3IgAnjTcTVmWl/4/iwL2umsf+QDiq3Sv
=GNW7
-END PGP SIGNATURE-

Re: [gentoo-dev] Amount of useflags enabled by default

2009-10-23 Thread Sebastian Pipping 
Thomas Sachau wrote:
 In addition, i see a trend to enabled more more more USE flags (either over 
 profiles or via IUSE
 +flag).

I'm not sure for how much of the IUSE=+foo cases this applies but I
can explain one of them:

In  xfce-base/xfce4-session-4.6.1-r1  there is  +fortune  in IUSE
because otherwise previous users of 4.6.1 would be missing the feature
enabled by it.

If you worry that +foo is becoming a trend _without_ strong reason you
could try enforcing documentation for in metadata.xml (through new tags)
maybe.



Sebastian

Re: [gentoo-dev] Amount of useflags enabled by default

2009-10-23 Thread Petteri Räty 
Thomas Sachau wrote:
 
 In addition, i see a trend to enabled more more more USE flags (either over 
 profiles or via IUSE
 +flag). Whats the reason for forcing a big load of default enabled USE flags 
 on every user including
 more dependencies, more compile time, more wasted disk space and more 
 possible vulnerabilities
 except some users, who complain about a missing feature and are not able to 
 think and enable a USE
 flag for that feature?
 

One possible reason is that our packages should follow upstream policy
and maybe upstreams usually like to keep things enabled rather than
disabled.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] eapi files and profiles

2009-10-23 Thread Petteri Räty 
Ulrich Mueller wrote:
 On Fri, 23 Oct 2009, Samuli Suominen wrote:
 
 So I was told Council needs to approve inheritance of eapi files
 from parent profiles?
 
 Doesn't http://bugs.gentoo.org/288320#c7 cover this? Why would you
 need explicit inheritance?
 

Well technically you still shouldn't add EAPI 2 atoms to the child
profiles without them being marked with the appropriate eapi file entry.
Do all the levels of 10.0 profiles use EAPI 2 entries?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] eapi files and profiles

2009-10-23 Thread Ciaran McCreesh 
On Fri, 23 Oct 2009 23:26:47 +0300
Petteri Räty betelge...@gentoo.org wrote:
 Well technically you still shouldn't add EAPI 2 atoms to the child
 profiles without them being marked with the appropriate eapi file
 entry. Do all the levels of 10.0 profiles use EAPI 2 entries?

Down that way leads madness...

Mark any profile directory that itself uses EAPI 1 (there's nothing that
makes sense EAPI 2-wise for profiles) as EAPI 1. Leave any other
directory alone.

Doing it any other way requires far too much careful attention.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] eapi files and profiles

2009-10-23 Thread Ciaran McCreesh 
On Fri, 23 Oct 2009 11:24:27 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
 So I was told Council needs to approve inheritance of eapi files from
 parent profiles?

As a full explanation of why this idea sucks, since some people have
asked:

You need to decide which way eapi inherits go. Are you saying that any
profile directory with a parent using EAPI X is itself EAPI X? If so,
the implications are:

* that we can't change the format of the parent file ever (and we have
  done so in the past)

* that it gets a lot harder to remove certain syntax in newer EAPIs.
  For example, say we want to replace =...* with ranged dependencies in
  EAPI 4. Then you can't change a profile directory to use EAPI 4
  without checking that everything that uses that directory doesn't
  make use of =...*.

Or are you saying that the package manager should use the eapi it picks
up for any parents it follows? If so, the implications are:

* that removing =...* in EAPI 4 (for example) becomes impossible,
  because it would be impossible to use that syntax in high level
  profiles that might be inherited by profiles using EAPI 4.

Either way, putting eapi files in any directory that itself
specifically needs it is a heck of a lot easier for everyone.

On top of that, if you do change it, there's the usual year wait before
you can use it, since current package managers don't inherit eapis.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] eapi files and profiles

2009-10-23 Thread Brian Harring 
On Fri, Oct 23, 2009 at 11:24:27AM +0300, Samuli Suominen wrote:
 So I was told Council needs to approve inheritance of eapi files from
 parent profiles?
 
 I'm not sure why, because we shouldn't have any files in default/linux/
 which was decided long ago when the new profiles was introduced...
 
 gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l
 63
 
 That's 63 duplicated files. We should only have one releases/10.0/eapi
 file, and others wouldn't be required as it would cover all the 10.0
 profiles.
 
 See, http://bugs.gentoo.org/288320
 
 Can we get a decision on this soon, so we can drop the duplication for
 10.1 (or whatever the name for next profile set will be called) ?

This is going to break compatibility for pkgcore at least- we limit 
what forms of atoms are allowed dependant on the eapi of that profile 
node.  I'd hope paludis does the same- I know portage doesn't however.

Further... the more I think about this, the more I'm inclined to think 
this will blow someones foot off.  If the eapi is inherited from the 
parent, what happens when the parent switches to an EAPI that changes 
the atom parsing rules?  Specifically, *restricts* the atom parsing 
rules?

Say that we got rid of the ~ operator w/in EAPI4.  '~' is completely 
valid in the default EAPI=0; if the parent profile switches to EAPI4, 
it suddenly breaks parsing of any defaulted EAPI that used revision 
matching.

So... inheritance sucks.  It gets worse when you have user 
configuration (custom profiles) inheriting from gentoo-x86 provided 
profiles- I'd expect user config to use things that are more cutting 
edge.

Alternative approach- the default EAPI currently is 0, and isn't 
overridable.  Add a file into the base of the profile directory that 
specifies the default EAPI.

Via that, you can do your file optimizations- if the majority of 
profile nodes are eapi=2, then you set the default to 2 and update the 
nodes that were reliant on the previous default.

Note this still requires having this change sit in the tree for a 
while for compatibilty reasons- but it is a good idea regardless to 
avoid requiring EAPI to be specified for every single profile node 
when we've hit EAPI=7

~harring


pgppWjhuwFp66.pgp
Description: PGP signature

Re: [gentoo-dev] Amount of useflags enabled by default

2009-10-23 Thread Alistair Bush 
 Hi,
 
 i would like to start a discussion about reducing the amount of
  default-enabled USE flags in profiles, especially in inherited basic
  profiles.

Sounds like a reasonable idea to me, for the base profiles at least.

 In addition, i see a trend to enabled more more more USE flags (either over
  profiles or via IUSE +flag). Whats the reason for forcing a big load of
  default enabled USE flags on every user including more dependencies, more
  compile time, more wasted disk space and more possible vulnerabilities
  except some users, who complain about a missing feature and are not able
  to think and enable a USE flag for that feature?
 

 who complain about a enabled feature and are not able to think and 
disable a USE flag for that feature?

What a couple of changes make

It would be nice if we actually documented why they were enabled.  Does the 
use flag enable significant functionality that would otherwise make the 
software 
less useful.

I believe we should be trying to find a nice 'middle of the road' balance.   DE 
related use flags should be enabled in profiles ( unless of coarse they 
package is already DE related e.g if a kde package has a use flag for kde's 
sound system, this could be enabled at a package level while a package with a 
kde use flag should not default enable it.).

So,  if we were looking at what use flags ppl are enabling/disabling we should 
be seeing similar numbers for the +'s and the -'s.  Not an easy thing to 
do, I admit.   Would be interesting if something like Color Graphing [1] or 
some algorithm could be used to determine whether a use flag should be enabled 
in a profile (including which profile)/package.  Maybe we should have some 
addition metadata for use flags.  Like a category/type/blah/blee. As an example 
we could have a category of DE containing kde/gnome/etc.  How do we know that 
the dirac use flag is codec related without knowing what dirac is?


Alistair


[1] http://en.wikipedia.org/wiki/Graph_coloring