Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread David Leverton
On Friday 15 May 2009 02:42:33 George Prowse wrote:
 Having countered those four points I guess you agree with the other five
 then. Over 50% success rate (by your definition) is hardly being
 ignorant or trolling

In that case we can assume that Patrick agrees with all my counterpoints, 
since he hasn't responded to my email at all.



Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Thilo Bangert
Richard Freeman ri...@gentoo.org said:
 AllenJB wrote:
  All that's going to happen is Gentoo will have many many buggy and
  out of date packages in the MAIN TREE. Exactly where they shouldn't
  be. You claim quality won't be sacrificed, but I simply can't see
  this without any attempt to solve the manpower issues first.
 
  Isn't the purpose of this project already somewhat covered by
  Sunrise?

 I have to agree with your points.  We need to have quality standards
 for packages.  Currently we have a couple of tiers:

 1.  Main tree - every ebuild has an official maintainer and gets prompt
 security updates/etc.  New features might get a little more stale, but
 you aren't going to be running at risk if you only use the main tree
 and routinely emerge -u world.  If a package falls behind on security
 it gets masked and booted.

 2.  Overlays - you're on your own and at the general mercy of the
 overlay maintainer.

 3.  Sunrise (just a special case of an overlay) - somewhere in-between.
   Again, you have to opt-in.


AFAIK, we have never explicitly made this distinction clear. if we had, we 
would have to remove stuff from portage which doesnt live up to the 
standards.

it is also not true from a more real world perspective: there are many 
packages in portage that have a standard which is much lower than what is 
in some overlays. and there are many packages in overlays which live up to 
a quality standard way above portage's average.

if you want to exaggerate a bit, we have roughly 500 ebuilds in portage 
which are maintainer-needed and have only a few users and thats why you 
want to keep popular packages out of the tree?

its weird, how this whole thing started with wanting to accomodate our 
users better and then other people come around and argue against it in 
order to protect our users...
user who want protection run stable arch!

given the current state of the tree, its hypocritical to be against this 
proposal, IMHO.

however, one could try to implement the above quality standards, possibly 
by splitting up the tree.

this issue, as well as some others very similar to this one, have come up 
many times before. I suggest we do something about it... (splitting the 
tree or moving more stuff wholesale into portage and have a better rating 
system... whatever)

Fedora is a much more current distribution than Gentoo - and has been for 
a couple of years...

regards
Thilo

 I think that we still need to have defined levels of quality, so if we
 start putting unmaintained stuff in the main tree then we absolutely
 need to preserve a mechanism for users to indicate what level of
 quality they desire.  Users running a typical install shouldn't
 inadvertently have dependencies pulled in which aren't fully controlled
 for security issues.

 Could something like sunrise be integrated into the main tree?  Sure.
 However, there would need to be lots of rules and QA checks like
 non-sunrise packages not depending on sunrise packages and the sunrise
 packages are somehow clearly marked.  Maybe even an ACCEPT_QUALITY =
 good-luck-with-that setting or something like that in make.conf.  We
 might also need tiered levels of security in cvs.  I'm not convinced
 that in the end it will be any better than just having those who are
 interested add an overlay to their tree.

 Maybe a better option would be a way to make overlays more seamless.
 Additionally we could have rating categories for overlays like
 security responsiveness, currency with upstream, etc.  The gentoo
 project would ask overlays to declare their policies as a condition of
 being accessible via the seamless interface, and would drop overlays if
 they don't follow their policies.  It would still be easy for users to
 pick non-standard overlays but it would be clear that they are
 venturing off on their own if they do this (just as is the case with
 layman today).

 Sure, I'd love to see an extra 1000 supported packages in portage, but
 the key is supported, not just shoveled-in.




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


Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thilo Bangert wrote:
 Richard Freeman ri...@gentoo.org said:
 AllenJB wrote:
 All that's going to happen is Gentoo will have many many buggy and
 out of date packages in the MAIN TREE. Exactly where they shouldn't
 be. You claim quality won't be sacrificed, but I simply can't see
 this without any attempt to solve the manpower issues first.

 Isn't the purpose of this project already somewhat covered by
 Sunrise?
 I have to agree with your points.  We need to have quality standards
 for packages.  Currently we have a couple of tiers:

 1.  Main tree - every ebuild has an official maintainer and gets prompt
 security updates/etc.  New features might get a little more stale, but
 you aren't going to be running at risk if you only use the main tree
 and routinely emerge -u world.  If a package falls behind on security
 it gets masked and booted.

 2.  Overlays - you're on your own and at the general mercy of the
 overlay maintainer.

 3.  Sunrise (just a special case of an overlay) - somewhere in-between.
   Again, you have to opt-in.

 
 AFAIK, we have never explicitly made this distinction clear. if we had, we 
 would have to remove stuff from portage which doesnt live up to the 
 standards.

We should try to work with the maintainers of those packages to improve things.

 it is also not true from a more real world perspective: there are many 
 packages in portage that have a standard which is much lower than what is 
 in some overlays. and there are many packages in overlays which live up to 
 a quality standard way above portage's average.

This is probably true, but without knowing which is which we can't do much about
it. Even if we did know, that still doesn't mean packages could be moved from
overlays to main tree, as they would instantly become unmaintained.

 if you want to exaggerate a bit, we have roughly 500 ebuilds in portage 
 which are maintainer-needed and have only a few users and thats why you 
 want to keep popular packages out of the tree?

If packages are popular enough someone will care enough to add and maintain 
them.

 its weird, how this whole thing started with wanting to accomodate our 
 users better and then other people come around and argue against it in 
 order to protect our users...
 user who want protection run stable arch!

Perhaps there are pros and cons to actually doing this, like with most things.
It seems like some are arguing that the value of having more ebuilds outweighs
the bad of having more less-maintained ebuilds. Others may feel differently.

 given the current state of the tree, its hypocritical to be against this 
 proposal, IMHO.

See above.

 however, one could try to implement the above quality standards, possibly 
 by splitting up the tree.

Overlays are effectively a splitting of the tree, so we are already there.

 this issue, as well as some others very similar to this one, have come up 
 many times before. I suggest we do something about it... (splitting the 
 tree or moving more stuff wholesale into portage and have a better rating 
 system... whatever)
 
 Fedora is a much more current distribution than Gentoo - and has been for 
 a couple of years...

Please elaborate what exactly you think Fedora does better than we do. I have no
first-hand experience with Fedora, but from what I read I had the impression
that sometimes they go with new stuff before it is ready, like KDE4 and 
pulseaudio.
I like about the current situation that we also have all those things available
AFAICS, but have very broad choices in how much we want to bleed.
IMO this is a different issue than having supposedly popular ebuilds not in main
tree.


I think there is a steady inflow of fresh developers from sunrise (and other
places). Does anyone have a chart? I'd also like to know from prospective
developers if they have trouble getting recruited, through sunrise or other
projects.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNPjsACgkQp/VmCx0OL2x/lgCgrvL/3f0XqLJPEe6+BOCl/0R8
j3kAn1jLAW1flDAZt7wu9IuSMO3jtmZe
=szxf
-END PGP SIGNATURE-



Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Richard Freeman

Thilo Bangert wrote:
AFAIK, we have never explicitly made this distinction clear. if we had, we 
would have to remove stuff from portage which doesnt live up to the 
standards.




I'm all for that.  In reality we tend to leave them alone until a 
security issue actually comes up, which is probably a reasonable 
compromise (since it also takes work to remove them).  In any case, 
failure to completely meet a standard does not automatically imply that 
the standard is worthless.


it is also not true from a more real world perspective: there are many 
packages in portage that have a standard which is much lower than what is 
in some overlays. and there are many packages in overlays which live up to 
a quality standard way above portage's average.




I don't think anybody has issues with overlays that choose to have 
higher quality standards than portage.  I'm all for that.  I'm concerned 
with the quality level in portage - since that is what we attach our 
name to.  If some other repository wants to do a better job than more 
power to them!


However, Gentoo cannot endorse all overlays as being official 
repositories, because clearly there is no standard for quality when all 
it takes to have an overlay is to set up an rsync or http server and put 
some ebuilds on it.


if you want to exaggerate a bit, we have roughly 500 ebuilds in portage 
which are maintainer-needed and have only a few users and thats why you 
want to keep popular packages out of the tree?




Actually, where any of those ebuilds cause problems I'm fine with 
getting rid of them.  I'm certainly not arguing for inconsistency.  I'm 
just suggesting that we shouldn't make the problem worse.


If a package is popular then somebody should volunteer to maintain it 
(whether by becoming a gentoo dev or by starting their own overlay).  If 
that isn't happening than clearly the package isn't THAT important. 
This is open source - if you have an itch, then scratch it!  Don't just 
complain that nobody else is scratching YOUR itch (even if it is a 
popular itch).


In any case, my opinion is that for packages to be in portage they 
should be of a certain level of quality, and a developer should be 
accountable for the packages they commit.  Anybody is welcome to grab 
ebuilds out of CVS, screen them, and commit them.  However, if they 
cause havoc then the developer can't just say but it was popular and 
unmaintained, so I figured I'd just commit something without looking at 
it.  If a developer is willing to commit an appropriate amount of time 
to QA then they essentially have become a maintainer and the package is 
no-longer maintainer-wanted.




Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Daniel Pielmeier
2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org:

 Thilo Bangert wrote:

 Fedora is a much more current distribution than Gentoo - and has been for
 a couple of years...

 Please elaborate what exactly you think Fedora does better than we do. I have 
 no
 first-hand experience with Fedora, but from what I read I had the impression
 that sometimes they go with new stuff before it is ready, like KDE4 and 
 pulseaudio.
 I like about the current situation that we also have all those things 
 available
 AFAICS, but have very broad choices in how much we want to bleed.
 IMO this is a different issue than having supposedly popular ebuilds not in 
 main
 tree.


AFAIK Fedora (formerly Red Hat Linux) is the playground for Red Hat
Enterprise Linux like Opensuse is for Suse Linux Enterprise. So it
makes more sense to compare it with the Gentoo unstable tree instead
of the stable one. Assuming this there is probably not a big
difference in the up-to-dateness.

-- 
Daniel Pielmeier



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Richard Freeman

Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer patr...@gentoo.org wrote:

Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=


Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

where foo is both a global and a non-global eclass that sets metadata.



This seems to come up from time to time but I don't see how this is a 
problem that GLEP 55 solves.  If the rule is first line of the ebuild 
starting with EAPI= and the ebuild is as you suggest above, then the 
EAPI is 4 (without any regard whatsoever to what might be in foo).


The counterargument seems to be that eclasses should be able to modify 
EAPI behavior.  However, if you want to do this then you DEFINITELY 
don't want to put the EAPI in the filename - unless you want eclasses to 
start renaming the ebuilds to change their EAPIs and then trigger a 
metadata regen.


This seems to be a case where a problem is proposed, with a solution. 
Somebody proposes an alternate solution and the complaint is raised that 
it doesn't handle situation X.  However, the original proposed solution 
doesn't handle situation X either, so that can hardly be grounds for 
accepting it over the alternate.


I'm actually more in favor of an approach like putting the EAPI in a 
comment line or some other place that is more out-of-band.  Almost all 
modern file formats incorporate a version number into a fixed position 
in the file header so that it is trivial for a program to figure out 
whether or not it knows how to handle the file.  Another common approach 
is to put a header-length field and add extensions to the end of a 
header, so that as long as you don't break past behavior you could 
create a file that is readable by older program versions (perhaps with 
the loss of some metadata that the older version doesn't understand). 
Just look up the UStar tar file format or the gzip file format for 
examples.   Of course, such file formats generally aren't designed to be 
human-readable or created with a text editor.


The same applies to executables.  It is impossible from the filename to 
tell if /bin/bash is in a.out or ELF format, or if it is a shell script. 
 Instead a simple standard is defined that allows the OS to figure it 
out and handle it appropriately.  If you try to run an ELF on some 
ancient version of linux it doesn't crash or perform erratic behavior - 
it will simply tell you that it doesn't understand the file format 
(invalid magic number).


In any case, I'm going to try to restrain myself from replying further 
in this thread unless something genuinely new comes up.  When I see 26 
new messages in my gentoo-dev folder I should know by now that somebody 
has managed to bring up GLEP 55 again...  :)




Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed

2009-05-15 Thread Robin H. Johnson
On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano Müller wrote:
 Thanks Robin for finally pushing this in the tree, just didn't find the
 time to.
 
 Maybe it's a good time to emphasize this: Keep in mind that changing the
 EAPI in an ebuild requires a revision bump (including reset to unstable
 keywords, etc.).
That's going to cause a large problem.

The entire point is that the STABLE ebuilds need to be changed,
otherwise they will try to depend on the libusb-1 series (and fail
dismally).

For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
then I see no reason that a slot dep change cannot be just put in with
the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further
changes are needed for that case).

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpVApNLnp2FS.pgp
Description: PGP signature


Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed

2009-05-15 Thread Tiziano Müller
Thanks Robin for finally pushing this in the tree, just didn't find the
time to.

Maybe it's a good time to emphasize this: Keep in mind that changing the
EAPI in an ebuild requires a revision bump (including reset to unstable
keywords, etc.).

Cheers,
Tiziano

Am Donnerstag, den 14.05.2009, 17:06 -0700 schrieb Robin H. Johnson:
 libusb-1 is in the tree now. 
 
 This means that you get to go and test all your apps that use it.
 There's a list further down of all packages and all ebuilds.
 
 Every one of these needs to be tested, and amended in one of two ways:
 - Does work with libusb-compat:
   1. Change your [R]DEPEND to virtual/libusb:0
 - Does not work with libusb-compat, or you don't have time to fully test right
   now:
   1. Change your [R]DEPEND to dev-libs/libusb:0 (preserve any existing version
  dependency as well).
   2. If it really doesn't work, leave a comment in the ebuild as well as on
  this thread.
 
 Both of these changes require that you move up from EAPI0 to at least EAPI1,
 where slot dependencies are supported.
 
 As part of the migration strategy, I'm going to be going through all of the
 ebuilds listed here, and just changing them to include the slot dependancy
 directly on dev-libs/libusb:0 initially, and including a notation that
 libusb-compat is untested.
 
 For the inevitable question, as to why we need to do this, while 99.9% of
 libusb-applications will be fine, there were specific bad practices that were
 previously done with libusb-0 that DO break under libusb-compat. They are
 described in detail in the libusb-compat README.
 
 List of packages:
 =
 app-accessibility/brltty
 app-accessibility/gok
 app-crypt/asedriveiiie-serial
 app-crypt/asedriveiiie-usb
 app-crypt/asekey
 app-crypt/ccid
 app-crypt/gnupg
 app-misc/acdctl
 app-misc/digitemp
 app-misc/g15daemon
 app-misc/ifp-line
 app-misc/lcd4linux
 app-misc/lcdproc
 app-misc/lirc
 app-misc/logitech-applet
 app-misc/razertool
 app-misc/rioutil
 app-mobilephone/bitpim
 app-mobilephone/gammu
 app-mobilephone/gnokii
 app-mobilephone/moto4lin
 app-mobilephone/obex-data-server
 app-mobilephone/openmoko-dfu-util
 app-pda/barry
 app-pda/coldsync
 app-pda/pilot-link
 app-text/calibre
 dev-embedded/avrdude
 dev-embedded/ftdi_eeprom
 dev-embedded/libftdi
 dev-embedded/openocd
 dev-embedded/pk2cmd
 dev-libs/cyberjack
 dev-libs/libg15
 dev-libs/libhid
 dev-libs/luise-bin
 dev-libs/openct-.ebuild
 dev-libs/openct
 dev-libs/openobex
 dev-libs/serdisplib
 dev-util/usb-robot
 kde-base/kcontrol
 kde-base/kdebase
 kde-base/systemsettings
 media-gfx/gphoto2
 media-gfx/iscan
 media-gfx/sane-backends
 media-libs/hamlib
 media-libs/libdjconsole
 media-libs/libgphoto2
 media-libs/libifp
 media-libs/libkarma
 media-libs/libmtp
 media-libs/libnjb
 media-libs/libptp2
 media-sound/ardour
 media-tv/linuxtv-dvb-apps
 media-video/isight-firmware-tools
 net-dialup/umtsmon
 net-misc/dahdi-tools
 net-misc/zaptel
 net-print/hplip
 net-print/mtink
 net-wireless/bluez
 net-wireless/bluez-utils
 net-wireless/wispy-tools
 sci-geosciences/gpsbabel
 sci-geosciences/qlandkartegt-garmindev
 sci-geosciences/qlandkarte
 sci-libs/indilib
 sci-libs/libticables2
 sys-apps/hal
 sys-apps/ifd-gempc
 sys-apps/lomoco
 sys-apps/pcsc-lite
 sys-apps/usb_modeswitch
 sys-apps/usbutils
 sys-auth/thinkfinger
 sys-fs/owfs
 sys-libs/libchipcard
 sys-power/nut
 sys-power/sispmctl
 x11-misc/ifpgui
 xfce-extra/xfce4-cellmodem
 
 List of all ebuilds:
 
 app-accessibility/brltty/brltty-3.10.ebuild
 app-accessibility/gok/gok-2.24.0.ebuild
 app-accessibility/gok/gok-2.26.0.ebuild
 app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.4.ebuild
 app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.5.ebuild
 app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.4.ebuild
 app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.5.ebuild
 app-crypt/asekey/asekey-3.3.ebuild
 app-crypt/asekey/asekey-3.4.ebuild
 app-crypt/ccid/ccid-1.3.0.ebuild
 app-crypt/ccid/ccid-1.3.10.ebuild
 app-crypt/ccid/ccid-1.3.1.ebuild
 app-crypt/ccid/ccid-1.3.5.ebuild
 app-crypt/ccid/ccid-1.3.8.ebuild
 app-crypt/gnupg/gnupg-1.4.9.ebuild
 app-misc/acdctl/acdctl-1.1.ebuild
 app-misc/digitemp/digitemp-3.3.2.ebuild
 app-misc/digitemp/digitemp-3.5.0.ebuild
 app-misc/g15daemon/g15daemon-1.2.7-r1.ebuild
 app-misc/g15daemon/g15daemon-1.9.5.3-r2.ebuild
 app-misc/ifp-line/ifp-line-0.2.4.5.ebuild
 app-misc/ifp-line/ifp-line-0.3.ebuild
 app-misc/lcd4linux/lcd4linux-0.10.0-r1.ebuild
 app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r1.ebuild
 app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r2.ebuild
 app-misc/lcdproc/lcdproc-0.5.1-r4.ebuild
 app-misc/lcdproc/lcdproc-0.5.2-r1.ebuild
 app-misc/lcdproc/lcdproc-0.5.2-r2.ebuild
 app-misc/lirc/lirc-0.8.3_pre1.ebuild
 app-misc/lirc/lirc-0.8.3-r2.ebuild
 app-misc/lirc/lirc-0.8.4a.ebuild
 app-misc/lirc/lirc-0.8.4.ebuild
 app-misc/logitech-applet/logitech-applet-0.4_pre1-r2.ebuild
 app-misc/razertool/razertool-0.0.7.ebuild
 app-misc/rioutil/rioutil-1.5.0-r1.ebuild
 

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

2009-05-15 Thread Michael Haubenwallner
On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:

  This .uselect 
  should not contain symlinks, but plain (text?) files only.

 Do we really need more than one file? 

No, at least not to define the _values_ of a profile.

 Checklist:
 * Hostname
 * Uname
 * {$chost}
 
 Mmm... Maybe we can simplify this with a parameter like:
 
 # eval something
 eval hostname superhost
 what
 to
 do
 # end something
 
 Then if command hostname outputs superhost we know what-to-do. 

Eventually, we should pass something like -Dhostname=superhost as
cmdline parameter to uselect...

 
 This way it would get ultra versatile.
 
  What if there is some hierarchy in .uselect/ much like the profiles in
  gentoo-x86 tree, using some kind of 'parent' files to inherit/override
  settings for this one project, where 'parent' can contain something like
  $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
  
 
 Would this really be necessary? We can define hierarchy into a
 single .uselect file. Even the use of folders (folder .uselect/) isn't
 necessary. I think a single file can handle all this... 

Eventually yes.

 Lets see an
 example:
 
 # profile something

I don't like to have anything interpreted after the usual and well-known
comment-marker, this just feels hackish.

 
 do this 3 - override the overridden =)

 The actions to be done like do this 3 are a simple call to uselect
 using module do and action this with 3 as parameters.

fine.

I do have something like this content-syntax in mind for .uselect (or
eventually some .uprofile) file:

888
version 0.1

include path/to/another/uselect/file

profile generic solaris {
  module A actionAX valueAX1 valueAX2
  module B actionBX valueBX1 valueBX2
}

profile generic host {
  module C actionCX valueCX1
}

profile superhost {
  inherit profile generic solaris
  inherit profile generic host
  module C actionCX newvalueCX1
  module A actionAX newvalueAX1 newvalueAX2
  module D actionDY valueBY1 valueBY2
}

profile generic user {
  module E actionEX valueEX1
}

profile user haubi {
  inherit profile generic user
  module F actionFX valueFX1
}

profile any user on superhost {
  module G actionGX valueGX1
}

profile fallback host {
  inherit profile generic host
  module A actionAX valueAX1 valueAX2
}

activation superhost activation {
  in category host
  on fallback level 0
  when $hostname matches string superhost
  activate profile superhost
}

activation haubi on superhost {
  in category user
  on fallback level 0
  when $username matches string haubi
  when $hostname matches string superhost
  activate profile any user on superhost
  activate profile user haubi
}

activation haubi {
  in category user
  on fallback level 1
  when $username matches string haubi
  activate profile user haubi
}

activation gentoo host {
  in category host
  on fallback level 1
  when $hostname matches regex .*\.gentoo\.org
  activate profile fallback host
}
888

I'm not sure to have an ascending fallback level or descending
priority value, but both should allow for negative integer values.

The selection of one or more profiles is controlled by activation
entries, independent for each category. The order and selection of
categories is done via a commandline argument, fex --categories.

Profiles are selected when all of the when entries (besides category
and fallback level) in activation {} do match.
Selected are *all* of the matching profiles in the *lowest* fallback
level *only*, which does have at least one matching profile.

And I'm thinking of something like this commandline:
$ uselect \
  --categories host,user \
  --define hostname=`hostname` \
  --define username=`whoami`

 
 Remember that profile creation/storing/managing should be automatic and
 nothing would need to be written by hand.

Yes, would be fine. When using something like above configuration file
syntax, some GUIding tool would be useful, at least to see which
profiles are selected for specific cmdline args.

  By other words, create a basic
 profile automatically using your currently running settings and then
 alter the profile with the util to add constrains to it.

Sounds interesting...

 Remember that
 all the machines that this profile is read would need to have the same
 uselect modules into it's /usr/share/uselect/modules or similar.

Indeed, yes.

  Ha! This kind of inheritance tree could be a solution for my long
  standing bug here to simplify our way too complex environment script...
  
 
 This is a basic idea from softenv so it has has it's place into uselect.

Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
Do you mean this one?

 The question now is, bloat it all into uselect or create a uprofile
 util? I like the idea of having to use only uselect for basic profiling
 and using uprofile for further managing.

That's indeed the question.

 Mmmm... As you wrote I realized: Complain if module versions are
 different is not a bad idea at all... 

Indeed, not only the configuration needs to be 

[gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Duncan
Daniel Pielmeier daniel.pielme...@googlemail.com posted
6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted
below, on  Fri, 15 May 2009 12:44:47 +0200:

 2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org:

 Thilo Bangert wrote:

 Fedora is a much more current distribution than Gentoo - and has been
 for a couple of years...

 Please elaborate what exactly you think Fedora does better than we do.
 I have no first-hand experience with Fedora, but from what I read I had
 the impression that sometimes they go with new stuff before it is
 ready, like KDE4 and pulseaudio. I like about the current situation
 that we also have all those things available AFAICS, but have very
 broad choices in how much we want to bleed. IMO this is a different
 issue than having supposedly popular ebuilds not in main tree.

 AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to
 compare it with the Gentoo unstable tree instead of the stable
 one. Assuming this there is probably not a big difference in the
 up-to-dateness.

Well, yes and no.  As the GP said, they sometimes go with new stuff 
before it's ready -- before Gentoo even has it in-tree hard-masked let 
alone ~arch, while it's still in the various project overlays.   I know 
they've had some serious issues with xorg on Intel GPUs at least, due to 
running versions that aren't in our tree yet, only in the X overlay, 
because Fedora is running clearly not even ~arch-ready packages, 
sometimes even xorg prereleases.

Years ago we'd have put these in-tree but hard-masked for those who 
wanted to try them.  Now, depending on the package and Gentoo but more 
likely as the complexity rises to meta-package levels, those who want to 
try them must load an overlay.  As someone who selectively unmasks and 
tries these, having them in-tree but hard-masked is convenient, but I 
understand why projects may prefer overlays in many cases.

However, none of this directly applies to the subject at hand, because 
while we're talking new versions of packages already in-tree here, the 
subject at hand is packages that aren't in-tree in any form yet.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: Files owned by multiple slots

2009-05-15 Thread Duncan
Sven sv...@delirium.ch posted loom.20090514t182756-...@post.gmane.org,
excerpted below, on  Thu, 14 May 2009 18:34:29 +:

 Duncan 1i5t5.duncan at cox.net writes:
 FWIW, that'd not be a portage issue per se, but an EAPI issue, since it
 
 I see, very interesting! Sounds like a lengthy process, but never mind.
 Do you know where EAPI changes are discussed? (Google and the Bugtracker
 didn't yield a useful reply.)

Here?  (See the current GLEP55 thread, among others.)  Also the council 
list and meetings, since they must approve EAPIs before they are allowed 
in the tree.

Also see the various PMS (package management spec) threads, and the 
app-doc/pms package, for the current EAPI documentation.  From the 
package metadata, the homepage is:

http://www.gentoo.org/proj/en/qa/pms.xml

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] EAPI Changes

2009-05-15 Thread William Hubbs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
 On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
  Thanks Robin for finally pushing this in the tree, just didn't find the
  time to.
  
  Maybe it's a good time to emphasize this: Keep in mind that changing the
  EAPI in an ebuild requires a revision bump (including reset to unstable
  keywords, etc.).
 That's going to cause a large problem.
 
 The entire point is that the STABLE ebuilds need to be changed,
 otherwise they will try to depend on the libusb-1 series (and fail
 dismally).
 
 For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
 then I see no reason that a slot dep change cannot be just put in with
 the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further
 changes are needed for that case).
 
 As far as I know, the only time you need to do a rev bump and reset to
 unstable is if you change the files that are installed by the package.

 So, as far as I know, unless you are migrating to an EAPI that is not
 stable or changing the files that are installed by the package, it is
 not necessary to do a rev bump just for changing the EAPI as long as
 you make sure that the ebuild emerges fine under the new EAPI.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNgNcACgkQblQW9DDEZTgorACdGfiXec4JUIC3UJDL/sGctbEi
FpwAn3UxUOjxuQUxl0w5S95M271+306Q
=jinO
-END PGP SIGNATURE-



[gentoo-dev] Last rites: Ruby 1.8 with Oniguruma patches, ruby-config

2009-05-15 Thread Alex Legler
# Alex Legler a...@gentoo.org (15 May 2009)
# Masked for removal wrt bug #251833. Due for removal in 30 days.
# Use app-admin/eselect-ruby instead.
dev-ruby/ruby-config
=dev-lang/ruby-1.8.6_p114

Ruby _p114 is the last Ruby with Oniguruma patches, however there are numerous 
security issues. Ruby 1.9.1 will contain Oniguruma again, people needing it in 
1.8 can use a gem [1].
ruby-config is superseded by eselect-ruby.

Cheers,
Alex

[1] http://oniguruma.rubyforge.org/


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


[gentoo-dev] Last rites: dev-texlive/texlive-langmanju

2009-05-15 Thread Alexis Ballier
# Merged in dev-texlive/texlive-langmongolian-2008, use that instead
# Masked for removal on 15 June 2009
dev-texlive/texlive-langmanju



Alexis.


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Robert R. Russell
On Friday 15 May 2009 05:44:47 Richard Freeman wrote:
 Ciaran McCreesh wrote:
  On Thu, 14 May 2009 20:06:51 +0200
 
  Patrick Lauer patr...@gentoo.org wrote:
  Let EAPI be defined as (the part behind the = of) the first line of
  the ebuild starting with EAPI=
 
  Uh, so horribly utterly and obviously wrong.
 
  inherit foo
  EAPI=4
 
  where foo is both a global and a non-global eclass that sets metadata.

 This seems to come up from time to time but I don't see how this is a
 problem that GLEP 55 solves.  If the rule is first line of the ebuild
 starting with EAPI= and the ebuild is as you suggest above, then the
 EAPI is 4 (without any regard whatsoever to what might be in foo).

 The counterargument seems to be that eclasses should be able to modify
 EAPI behavior.  However, if you want to do this then you DEFINITELY
 don't want to put the EAPI in the filename - unless you want eclasses to
 start renaming the ebuilds to change their EAPIs and then trigger a
 metadata regen.

 This seems to be a case where a problem is proposed, with a solution.
 Somebody proposes an alternate solution and the complaint is raised that
 it doesn't handle situation X.  However, the original proposed solution
 doesn't handle situation X either, so that can hardly be grounds for
 accepting it over the alternate.

 I'm actually more in favor of an approach like putting the EAPI in a
 comment line or some other place that is more out-of-band.  Almost all
 modern file formats incorporate a version number into a fixed position
 in the file header so that it is trivial for a program to figure out
 whether or not it knows how to handle the file.  Another common approach
 is to put a header-length field and add extensions to the end of a
 header, so that as long as you don't break past behavior you could
 create a file that is readable by older program versions (perhaps with
 the loss of some metadata that the older version doesn't understand).
 Just look up the UStar tar file format or the gzip file format for
 examples.   Of course, such file formats generally aren't designed to be
 human-readable or created with a text editor.

 The same applies to executables.  It is impossible from the filename to
 tell if /bin/bash is in a.out or ELF format, or if it is a shell script.
   Instead a simple standard is defined that allows the OS to figure it
 out and handle it appropriately.  If you try to run an ELF on some
 ancient version of linux it doesn't crash or perform erratic behavior -
 it will simply tell you that it doesn't understand the file format
 (invalid magic number).

 In any case, I'm going to try to restrain myself from replying further
 in this thread unless something genuinely new comes up.  When I see 26
 new messages in my gentoo-dev folder I should know by now that somebody
 has managed to bring up GLEP 55 again...  :)

If I understand the problem GLEP 55 is trying to solve correctly, it stems 
from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that 
assumption be changed to an unknown EAPI is equal to the latest supported 
EAPI. Now I understand that this change would have to wait until all the 
ebuilds in the portage tree correctly define their EAPI, but would the idea be 
technically feasible at least excluding EAPI0 ebuilds? I think it would be if 
all EAPIs are forward compatible up until the EAPI declaration in the ebuild.






Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Ciaran McCreesh
On Fri, 15 May 2009 11:16:11 -0500
Robert R. Russell nahoy_kb...@hushmail.com wrote:
 If I understand the problem GLEP 55 is trying to solve correctly, it
 stems from portage's assumption that an unknown EAPI is equal to EAPI
 0. Could that assumption be changed to an unknown EAPI is equal to
 the latest supported EAPI. Now I understand that this change would
 have to wait until all the ebuilds in the portage tree correctly
 define their EAPI, but would the idea be technically feasible at
 least excluding EAPI0 ebuilds? I think it would be if all EAPIs are
 forward compatible up until the EAPI declaration in the ebuild.

No, that still wouldn't help, because the package manager doesn't know
that what it thinks is the 'latest' EAPI (not that there really is such
a thing -- EAPIs aren't a linear sequence) actually is the 'latest'
EAPI.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Arun Raghavan
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote:
[...]
 So if you were a lazy Unix coder you'd just restrict the current rules a bit 
 so that there's only one line starting with EAPI= allowed (or maybe you just 
 take the first or last one, but that's annoying) and if no such line matches 
 you can safely assume EAPI0
 
 Maybe you're very lazy, so you explicitly forbid eclasses from setting or 
 changing EAPI. That also avoids weird effects that make you lose lots of time 
 for debugging because you didn't think about what would happen if foo.eclass 
 set EAPI=3.14 and bar.eclass inherited later set EAPI=1 ...
 
 And magically you haven't really changed current behaviour, can get the EAPI 
 without sourcing it and you can be lazy once more. Isn't it great?

As I've stated a long time ago, I'm for this solution. My understanding
is that there are 2 objections to this:

1) We can't change the ebuild format to XML or what have you. I think
this is a problem to deal with *if it ever happens*. I am completely
against trying to solve a problem that will not exist in the foreseeable
future.

2) There might be a performance impact for cases where the metadata is
uncached - I think the impact is acceptable in the face of the fugliness
added by putting the EAPI in the ebuild's name (Joe Peterson summarise
this quite well earlier [1]).

Really, the key issue seems to be (1), because there's no other good
reason to be trying to adopt this GLEP.

-- Arun

[1]
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html


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


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Ciaran McCreesh
On Sat, 16 May 2009 00:28:36 +0530
Arun Raghavan ford_pref...@gentoo.org wrote:
 As I've stated a long time ago, I'm for this solution. My
 understanding is that there are 2 objections to this:

3) It doesn't solve the problem. It doesn't allow things like version
format extensions.

That's the big one, not the other two.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: The fallacies of GLEP55

2009-05-15 Thread Steven J Long
Robert R. Russell wrote:

snip
 If I understand the problem GLEP 55 is trying to solve correctly, it stems
 from portage's assumption that an unknown EAPI is equal to EAPI 0.

No, portage will reject an ebuild with an unknown EAPI, as per the spec.
(This is important for shared overlays.) Search for:
def eapi_is_supported
..in pym/portage/__init__.py for the impl,  and you can see usage of it in
pym/_emerge/__init__.py, if you want to confirm this (or are just
interested in the code;)

http://sources.gentoo.org/viewcvs.py/portage/main/trunk/
(has instructions for anonymous download, should anyone be interested in
following portage development, or perhaps contributing at some stage.)

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)





Re: [gentoo-dev] Re: The fallacies of GLEP55

2009-05-15 Thread Ciaran McCreesh
On Fri, 15 May 2009 20:12:03 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
 Robert R. Russell wrote:
 snip
  If I understand the problem GLEP 55 is trying to solve correctly,
  it stems from portage's assumption that an unknown EAPI is equal to
  EAPI 0.
 
 No, portage will reject an ebuild with an unknown EAPI, as per the
 spec.

You're confusing the term 'unknown' here.

Before an ebuild has had its metadata generated, its EAPI is unknown. At
this point, the package manager assumes EAPI 0.

After an ebuild has had its metadata generated, its EAPI is either
known or unsupported, but if known may be unspecified. If it is known
but unspecified, the package manager treats it as equivalent to EAPI 0.

Conceptually, these aren't the same thing.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: The fallacies of GLEP55

2009-05-15 Thread Steven J Long
Robert Bridge wrote:

 Patrick Lauer wrote:
 On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
 On Thu, 14 May 2009 20:06:51 +0200

 Patrick Lauer patr...@gentoo.org wrote:
 Let EAPI be defined as (the part behind the = of) the first line of
 the ebuild starting with EAPI=
 Uh, so horribly utterly and obviously wrong.

 inherit foo
 EAPI=4

 where foo is both a global and a non-global eclass that sets metadata.

 Interesting, but quite subtly wrong. I'm surprised that you try to slip
 such an obvious logical mistake in in an attempt to save your arguments.
 
 Patrick, in the interest of making this comprehensible to the average
 schmuck like me, which you seem to be trying to do, could you actually
 explain WHY this is wrong? Otherwise it looks like you are simply trying
 the arrogant I am right because I say so line.

AFAIK, setting EAPI has to be done before any call to inherit. Not to do
so is considered a QA violation, and I believe repoman will scream at you
if you do so (I could be wrong as I don't use it. If it doesn't, perhaps it
should.)

Furthermore, eclasses are not supposed to set EAPI. They can test what the
ebuild's EAPI is, and act accordingly, should the need arise, but they are
not supposed to set it. (I'm informed this is disallowed by GLEP-55 in any
event, so it's not a restriction anyone cares too much about, one would
surmise.)

From conversation with Harring, who invented the whole EAPI thing, they were
never meant to change very quickly. The complementary mechanism was elibs,
that is files with useful library functions, which is often how eclasses
are used nowadays. Eclasses in that context would be able to set EAPI,
since they would effectively be a template, not a repository of
functionality.

(This is my no doubt flawed understanding of what he said; I'm sure he'll
correct, and hopefully forgive, any errors which are of course my own.)

I am curious as to why eclass versioning, which has been proposed for
donkey's years, hasn't seen as much impetus as what appear from a software
engineering perspective to be quite esoteric, and poorly thought-through,
use-cases. There does appear to be a process issue, though resolution is
another matter.

Good luck with the distro. :-)

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)





Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread William Hubbs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
 It can't, because it doesn't know the EAPI until it's sourced the thing
 using bash. Using things like += in global scope will break older bash
 versions to the point that they can't reliably extract EAPI.
 
I just figured out a line in bash that will get an EAPI without
sourcing the ebuild:

eval `grep '^EAPI=' ebuildfile | head -n 1`

will set EAPI in the current scope to EAPI in the ebuild, without
sourcing it, unless the issue with something like this would be its use
of grep and head, but these are both in the system set, so unless you
don't want to depend on the system set, I don't know what the objection
would be.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNxeEACgkQblQW9DDEZThaFACfYSQTpPTxfh3MzvErzbSNGZ8M
46AAoIyGTJxbWQ4Be7075uHXYN+hfnDl
=X3Wn
-END PGP SIGNATURE-



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread Ciaran McCreesh
On Fri, 15 May 2009 14:43:29 -0500
William Hubbs willi...@gentoo.org wrote:
 On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
  It can't, because it doesn't know the EAPI until it's sourced the
  thing using bash. Using things like += in global scope will break
  older bash versions to the point that they can't reliably extract
  EAPI.
  
 I just figured out a line in bash that will get an EAPI without
 sourcing the ebuild:
 
 eval `grep '^EAPI=' ebuildfile | head -n 1`
 
 will set EAPI in the current scope to EAPI in the ebuild, without
 sourcing it, unless the issue with something like this would be its
 use of grep and head, but these are both in the system set, so unless
 you don't want to depend on the system set, I don't know what the
 objection would be.

The objection is that your code doesn't work. It's entirely legal to
do, say:

export EAPI=1

or:

inherit versionator

if version_is_at_least 2 ; then
EAPI=2
else
EAPI=0
fi

Besides, if we were able to do what your code does, we'd just code it
natively, not use external programs.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: Re: The fallacies of GLEP55

2009-05-15 Thread Steven J Long
Ciaran McCreesh wrote:
 Steven J Long wrote:
 Robert R. Russell wrote:
 snip
  If I understand the problem GLEP 55 is trying to solve correctly,
  it stems from portage's assumption that an unknown EAPI is equal to
  EAPI 0.
 
 No, portage will reject an ebuild with an unknown EAPI, as per the
 spec.
 
 You're confusing the term 'unknown' here.
 
 Before an ebuild has had its metadata generated, its EAPI is unknown. At
 this point, the package manager assumes EAPI 0.

With the format restriction, that everyone last year seemed happy with,
apart from the few pushing GLEP-55, this isn't an issue. The mangler
*should* be scanning first for the EAPI to see if it can even handle
the rest of the ebuild (assuming it's not from the main tree or an
upstream overlay, or we're not a normal user. Developer machines rightly
need to do a bit more work, but it's not exactly onerous since portage
automatically does it for you.)

 After an ebuild has had its metadata generated, its EAPI is either
 known or unsupported, but if known may be unspecified. If it is known
 but unspecified, the package manager treats it as equivalent to EAPI 0.

Yes, empty = 0 as well-understood.

 Conceptually, these aren't the same thing.

In practical terms, this is a useless proposal. It rightly got trashed
last year. Let's just use a prefix instead of a suffix to indicate vcs,
keep branch and upstream for dep specification, not filename, to allow
inter-repo dependency for overlays for the few cases where it's actually
needed, and add debian-style epochs to guarantee future expansion.

If you have a use-case that actually requires more in a version specifier
for upstream software, please present it and explain how it cannot be
represented with the above.

In passing, I must express bewildered amusement at the idea of a format
with an unlimited amount of extensions. If you really want something so
radically different that it cannot be handled in the Gentoo scheme, or
BASH, use ONE _other_ extension.

Have a good weekend, all.

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)





Re: [gentoo-dev] Re: Re: The fallacies of GLEP55

2009-05-15 Thread Ciaran McCreesh
On Fri, 15 May 2009 21:06:13 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
  Before an ebuild has had its metadata generated, its EAPI is
  unknown. At this point, the package manager assumes EAPI 0.
 
 With the format restriction, that everyone last year seemed happy
 with, apart from the few pushing GLEP-55, this isn't an issue.

The format restriction hasn't been agreed upon, and doesn't solve the
whole problem anyway.

 If you have a use-case that actually requires more in a version
 specifier for upstream software, please present it and explain how it
 cannot be represented with the above.

Go and look at all the ebuilds using MY_PV style hacks. Group these
into necessary because upstream are being silly and we're only doing
this because of some utterly arbitrary rules imposed in the early days
of Gentoo. Most are in the second camp.

 In passing, I must express bewildered amusement at the idea of a
 format with an unlimited amount of extensions.

Not what's being proposed. We're proposing giving each format its own
file extension.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI Changes

2009-05-15 Thread Petteri Räty
William Hubbs wrote:
 On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
 On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
 Thanks Robin for finally pushing this in the tree, just didn't find the
 time to.

 Maybe it's a good time to emphasize this: Keep in mind that changing the
 EAPI in an ebuild requires a revision bump (including reset to unstable
 keywords, etc.).
 That's going to cause a large problem.
 
 The entire point is that the STABLE ebuilds need to be changed,
 otherwise they will try to depend on the libusb-1 series (and fail
 dismally).
 
 For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
 then I see no reason that a slot dep change cannot be just put in with
 the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further
 changes are needed for that case).
  
  As far as I know, the only time you need to do a rev bump and reset to
  unstable is if you change the files that are installed by the package.
 
  So, as far as I know, unless you are migrating to an EAPI that is not
  stable or changing the files that are installed by the package, it is
  not necessary to do a rev bump just for changing the EAPI as long as
  you make sure that the ebuild emerges fine under the new EAPI.
 

Indeed there's no problem switching EAPIs as long as a stable Portage
supports the EAPI you are migrating to. Portage was buggy with this when
EAPI 2 was introduced but that has since been fixed.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Re: The fallacies of GLEP55

2009-05-15 Thread David Leverton
On Friday 15 May 2009 21:06:13 Steven J Long wrote:
 In practical terms, this is a useless proposal. It rightly got trashed
 last year.

No, it did not get trashed, despite some people's attempts to make their 
side sound more popular than it really is.  Some people like the idea, some 
don't, and people have put forward various arguments in both directions.  If 
it were really as widely hated as you claim (presumably with the implication 
that the people who still support it are horrible and evil for even thinking 
about it) then it wouldn't still be under discussion.



[gentoo-dev] about gold bugs

2009-05-15 Thread Ryan Hill
Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as patches welcome.  There is no patch a user can
provide to make a package build with the gold linker. These bugs should be
assigned to toolchain, not the maintainer of the package that gold happens to
break.

Testers of gold, please check to see if your issue matches one of the general
issues already reported on the gold tracker [i] before filing a new bug.
Please assign new bugs to toolch...@g.o.

[i] http://bugs.gentoo.org/269315


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI Changes

2009-05-15 Thread Tiziano Müller
Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
 William Hubbs wrote:
  On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
  On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
  Thanks Robin for finally pushing this in the tree, just didn't find the
  time to.
 
  Maybe it's a good time to emphasize this: Keep in mind that changing the
  EAPI in an ebuild requires a revision bump (including reset to unstable
  keywords, etc.).
  That's going to cause a large problem.
  
  The entire point is that the STABLE ebuilds need to be changed,
  otherwise they will try to depend on the libusb-1 series (and fail
  dismally).
  
  For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
  then I see no reason that a slot dep change cannot be just put in with
  the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further
  changes are needed for that case).
   
   As far as I know, the only time you need to do a rev bump and reset to
   unstable is if you change the files that are installed by the package.
  
   So, as far as I know, unless you are migrating to an EAPI that is not
   stable or changing the files that are installed by the package, it is
   not necessary to do a rev bump just for changing the EAPI as long as
   you make sure that the ebuild emerges fine under the new EAPI.
  
 
 Indeed there's no problem switching EAPIs as long as a stable Portage
 supports the EAPI you are migrating to. Portage was buggy with this when
 EAPI 2 was introduced but that has since been fixed.

Wrong. For example:
- stuff like docompress may change the content being installed depending
on the package manager
- --disable-static (maybe in a later EAPI) changes content
- slot-dep-operators change the rdepend of installed packages, so it
changes how the package manager has to handle reverse packages on
uninstall (in EAPI 3)

On the other hand you also have to make sure you have a stable portage
for a time long enough so mostly everyone has it installed. Otherwise
you could break users systems pretty badly depending on the packages.
And Arch-Teams usually do a pretty good job in catching such cases.

And we also always said that a rev bump should be done on non trivial
changes or non-build-fixes and changing the EAPI is technical seen
mostly a non-trivial change.

Do we want to document the following? (do we have already?)
- When is it allowed to use an EAPI in the tree (given as offset to the
release of portage supporting that eapi)
- When is it allowed to use an EAPI in the stable tree (given as offset
of when a portage version supporting that EAPI got stable)

Cheers,
Tiziano


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [gentoo-dev] about gold bugs

2009-05-15 Thread Rémi Cardona

Le 15/05/2009 23:20, Ryan Hill a écrit :

Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as patches welcome.


Honestly, a little heads up before gold hit portage would have been nice 
too.


I already had 2 bugs with gold-related issues even before I had realized 
that binutils had gained a new USE flag... I honestly thought people 
were testing gold from an overlay or self-made ebuilds.


But point taken, gold bugs are toolchain bug :)

Best of luck with gold, I'm eager to try it out!

Cheers,

Rémi



Re: [gentoo-dev] Re: [RFC] USE_EXPAND for qemu unified ebuild

2009-05-15 Thread Luca Barbato

Luca Barbato wrote:

Duncan wrote:

Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?



Right, anyway either one or two vars, anybody has a strong feeling 
towards one of them or against any of them?




QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it.


-USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS 
FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES 
INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS 
ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES
+USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS 
FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES 
INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS 
ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES 
QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS



alpha - userspace emulation target
armeb - userspace emulation target
arm - userspace emulation target
cris - userspace emulation target
i386 - userspace emulation target
m68k - userspace emulation target
mips64el - userspace emulation target
mips64 - userspace emulation target
mipsel - userspace emulation target
mips - userspace emulation target
ppc64abi32 - userspace emulation target
ppc64 - userspace emulation target
ppc - userspace emulation target
sh4eb - userspace emulation target
sh4 - userspace emulation target
sparc32plus - userspace emulation target
sparc64 - userspace emulation target
sparc - userspace emulation target
x86_64 - userspace emulation target

arm - system emulation target
cris - system emulation target
i386 - system emulation target
m68k - system emulation target
mips64el - system emulation target
mips64 - system emulation target
mipsel - system emulation target
mips - system emulation target
ppc64 - system emulation target
ppc - system emulation target
sh4eb - system emulation target
sh4 - system emulation target
sparc - system emulation target
x86_64 - system emulation target
ppcemb - system emulation target

If anybody is against it please tell ^^

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] EAPI Changes

2009-05-15 Thread Petteri Räty
Tiziano Müller wrote:
 Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
 William Hubbs wrote:
 On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
 On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
 Thanks Robin for finally pushing this in the tree, just didn't find the
 time to.

 Maybe it's a good time to emphasize this: Keep in mind that changing the
 EAPI in an ebuild requires a revision bump (including reset to unstable
 keywords, etc.).
 That's going to cause a large problem.
 The entire point is that the STABLE ebuilds need to be changed,
 otherwise they will try to depend on the libusb-1 series (and fail
 dismally).
 For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
 then I see no reason that a slot dep change cannot be just put in with
 the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further
 changes are needed for that case).
  
  As far as I know, the only time you need to do a rev bump and reset to
  unstable is if you change the files that are installed by the package.

  So, as far as I know, unless you are migrating to an EAPI that is not
  stable or changing the files that are installed by the package, it is
  not necessary to do a rev bump just for changing the EAPI as long as
  you make sure that the ebuild emerges fine under the new EAPI.

 Indeed there's no problem switching EAPIs as long as a stable Portage
 supports the EAPI you are migrating to. Portage was buggy with this when
 EAPI 2 was introduced but that has since been fixed.
 
 Wrong. For example:
 - stuff like docompress may change the content being installed depending
 on the package manager
 - --disable-static (maybe in a later EAPI) changes content
 - slot-dep-operators change the rdepend of installed packages, so it
 changes how the package manager has to handle reverse packages on
 uninstall (in EAPI 3)
 

Switching EAPIs in my mind means taking care it works with new EAPIs.
Why switch in the first place if you aren't making modifications to the
ebuild?

 On the other hand you also have to make sure you have a stable portage
 for a time long enough so mostly everyone has it installed. Otherwise
 you could break users systems pretty badly depending on the packages.
 And Arch-Teams usually do a pretty good job in catching such cases.
 

How would this breakage happen? The ebuild in the vdb still has the old
EAPI.

 And we also always said that a rev bump should be done on non trivial
 changes or non-build-fixes and changing the EAPI is technical seen
 mostly a non-trivial change.
 

Switching between EAPI 0 and 1 for example is quite trivial. In Java
ebuilds we should always use slot deps because jars get installed to a
SLOT dependent path. I doubt our users would want to see us revision
bumping our ebuilds for that.

 Do we want to document the following? (do we have already?)
 - When is it allowed to use an EAPI in the tree (given as offset to the
 release of portage supporting that eapi)
 - When is it allowed to use an EAPI in the stable tree (given as offset
 of when a portage version supporting that EAPI got stable)
 

Currently:
1. Usage of an EAPI in the tree is allowed after council gives the OK.
2. When the Portage version supporting it goes stable

If you want please check devmanual and file a bug if it needs
updating/new info regarding this.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] EAPI Changes

2009-05-15 Thread Ciaran McCreesh
On Sat, 16 May 2009 02:31:45 +0300
Petteri Räty betelge...@gentoo.org wrote:
  On the other hand you also have to make sure you have a stable
  portage for a time long enough so mostly everyone has it installed.
  Otherwise you could break users systems pretty badly depending on
  the packages. And Arch-Teams usually do a pretty good job in
  catching such cases.
 
 How would this breakage happen? The ebuild in the vdb still has the
 old EAPI.

Portage likes to use metadata from the tree version of things even if
there's also a version installed. This is a major nuisance, but is
unfortunately considered a feature.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: EAPI Changes

2009-05-15 Thread Duncan
Petteri Räty betelge...@gentoo.org posted 4a0dd0ed.1070...@gentoo.org,
excerpted below, on  Fri, 15 May 2009 23:30:37 +0300:

 Indeed there's no problem switching EAPIs as long as a stable Portage
 supports the EAPI you are migrating to. Portage was buggy with this when
 EAPI 2 was introduced but that has since been fixed.

The case at hand is EAPI-0  EAPI-1.  I've no opinion there.

However, just this last week I tracked down and provided a patch for an 
EAPI-0  EAPI-2 conversion related bug[1] in an existing previously 
working ebuild, converted without a bump.  It was and remained ~arch so 
users should have been prepared to cope, but a bump would have been nice 
and it would have been a SERIOUS mistake to try to do that as stable.

So I agree with the earlier opinion that while it may not matter for 
EAPI-0  EAPI-1, as a general policy and certainly for conversions to 
EAPI-2 and probably EAPI-3, a revision bump and ~arch keywording, thus 
forcing the package thru a new stabilizing process, should be strongly 
recommended at minimum -- enough that a tree change to dozens of stable 
ebuilds such as is being discussed simply wouldn't be possible, without 
assuming a bump and new stabilization process, thus, effectively 
requiring 60-days working minimum process time (30 no-bugs, 30 stable-
keywording).

[1] Bug #269691, kaffeine
plain:http://bugs.gentoo.org/show_bug.cgi?id=269691
secure:  https://bugs.gentoo.org/show_bug.cgi?id=269691

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

2009-05-15 Thread Nirbheek Chauhan
Why do we let utterly *useless* discussions eat into our precious
developer time?

Why is it that this thread has 500 replies, but Mart's
maintainer-wanted thread has less than 10?

I *do not care* if the ebuild format will not be properly extensible
when the need arises. We'll cross that bridge when we get to it.

I *do not care* if support for live ebuilds is perfect. The three
major consumers of live ebuilds (x11, kde, and gnome) are *NOT*
complaining.

Why is the council spending so much time on *utterly useless*
discussions? Have we eliminated all other problems facing Gentoo that
we now have time for enhancements of questionable value in the near
future?

I would like to petition the Council to _strongly_ discourage such
discussion, and not to waste it's own time on things like this.

Hell, in my opinion EAPI-3 is a m00t discussion when we have entire
herds and archs wasting away due to inadequate developer resources and
users constantly being discouraged and turned away.

Let's not blatantly ignore our REAL problems. We can no longer afford
to maintain the status-quo of pedantic masturbatory discussions on the
finer points of ebuild formats. We cannot AFFORD to look the other way
while the distro rots away.

-- 
~Nirbheek Chauhan who is extremely worried by this denial-syndrome in
the gentoo community.