[gentoo-dev] Re: Major changes to gdesklets.eclass
Hi, Joe Sapp nixpho...@gentoo.org: Thanks for looking at this Christian. Sorry for the late reply. Patch to the original revision is attached. I am fine with it. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Calling unknown commands in an ebuild
В Вск, 07/02/2010 в 21:24 -0500, Mike Frysinger пишет:
it might also be useful to add a default epatch() to the initial env that
would be clobbered when the inherit occurred.
epatch() { die you need to inherit eutils.eclass to use epatch ; }
After fixing breakage that was introduced by dropping inherit eutils
from distutils.eclass I think we must have such thing. But one function
just covers most common case while we need to cover all cases. What
about pregenerating env file with script like in attachment?
$ awk -f generate-die-eclass-env /usr/portage/eclass/*.eclass
I guess it's possible to generate such env file on server side and make
portage use it if file exists... Opinions?
--
Peter.
generate-die-eclass-env
Description: application/awk
[gentoo-dev] X vs gtk USE flags
Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools.
Re: [gentoo-dev] X vs gtk USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 8.2.2010 12:15, Nikos Chantziaras napsal(a): Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools. Sounds sane. For correct usage lately the mplayer ebuild was rewritten this way. Might be good idea to open tracker for these and all bugs cced to it. So interested persons can fix it. Note for maintainers: qa bugs are considered as issue when adding new packages. In longer perspective it is good to have them fixed, but you don't have to proactively fix old packages. Writing this before people starts complaining we are again filling lots of bugs. @qa: any objections against me opening the tracker? To sum up the issue: use X wrap all other widget useflags if there is CLI interface available, so if user don't want X usage for package he just set -X and rest widget flags don't matter at all. Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktv9fAACgkQHB6c3gNBRYdbfQCdEXeFhVbCJ/ci0yl3Z9aT/sLU d8MAn3Y0RjOioEHxNEPEGgjKO42KtoQ3 =57xz -END PGP SIGNATURE-
Re: [gentoo-dev] X vs gtk USE flags
On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools. I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). Of course, even if your system was saner, the ultimate question is: Who's going to run through all the graphical packages and update all the use flags and dependencies? AllenJB
Re: [gentoo-dev] X vs gtk USE flags
On 02/08/2010 01:30 PM, Tomáš Chvátal wrote: Dne 8.2.2010 12:15, Nikos Chantziaras napsal(a): Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools. Sounds sane. For correct usage lately the mplayer ebuild was rewritten this way. Might be good idea to open tracker for these and all bugs cced to it. So interested persons can fix it. Note for maintainers: qa bugs are considered as issue when adding new packages. In longer perspective it is good to have them fixed, but you don't have to proactively fix old packages. Writing this before people starts complaining we are again filling lots of bugs. @qa: any objections against me opening the tracker? To sum up the issue: use X wrap all other widget useflags if there is CLI interface available, so if user don't want X usage for package he just set -X and rest widget flags don't matter at all. Tomas IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. MPlayer is a bad example here. The reason for writing it like that is all the flags enabled by default with +. -Samuli
Re: [gentoo-dev] X vs gtk USE flags
On Monday 08 February 2010 06:15:38 Nikos Chantziaras wrote: A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. tell that to all the devices that use GTK/QT/FLTK w/out X11 on raw frame buffers. USE=X is not a dumping grounds for GUIs. it's for controlling X11 dependencies plain and simple. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-08 01:20:22 Brian Harring napisał(a): On Sun, Feb 07, 2010 at 12:17:17PM -0800, Zac Medico wrote: I noticed that this generates a depedency like || ( =dev-lang/python-2.7* =dev-lang/python-2.6* ) which is very similar to the way that QT3VERSIONS works in qt3.eclass. One thing that is sub-optimal about these types of dependencies is that you end up with lots of installed packages that have out-dated dependencies when the next minor version of python is released (python-2.8 in this case). In the case of the python dependencies, it might be more optimal to use a version range like =dev-lang/python-2.6 dev-lang/python-3. Thing is, the first deps are valid- the deps you posted however aren't and cannot be used as you're proposing. Under || ( dev-lang/python:2.7 dev-lang/python:2.6 ) Having python:2.6 or python:2.7 merged satisfies it. Under =dev-lang/python:2.6 dev-lang/python:3.0 having || ( python:2.6 python:2.7 ) satisfies it, as does || ( python:2.4 python:2.5 ) || ( python:3.0 python:3.1 python:3.2 ) Literally, python:2.5 and python:3.1 merged would satisfy it, which is completely contrary to the intent and an unlikely scenario (several of my machines have such a deployment). I will improve handling of cases when minimal and maximal versions aren't specified. E.g. PYTHON_DEPEND=2 will be translated into dependency on =dev-lang/python-2*. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-07 19:43:24 Markos Chandras napisał(a):
On Saturday 06 February 2010 13:03:11 Arfrever Frehtes Taifersar Arahesis
wrote:
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
- Dependency on Python 2 should be set correctly. You can specify it
directly in {,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
It might be useful to provide another example:
If given package requires e.g. Python =2.6, but does not support Python 3,
then you can set PYTHON_DEPEND=2:2.6.
Could you please update the python documentation [1] or any other online
documentation you may find useful cause I am pretty sure your recommendations
in this e-mail will be lost over time.
Yes.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: X vs gtk USE flags
Hi, Nikos Chantziaras rea...@arcor.de: A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. Your proposal does not look to appealing to me. What about people trying to keep pollution down and avoid one or the other toolkit? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 01:36 PM, AllenJB wrote: On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. [...] I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). If it would be problematic for a package to switch to X then of course it might be better to leave it as-is. But most of the time, the programs in question only state gtk or fltk in them, even though Gtk is not optional at all. A perfect example here is media-video/xvattr. If you don't set the gtk USE flag, then you don't get the graphical tool at all, only the command line tool. So in other words what I propose a bit more sanity, not some iron claw that hangs above the developer's heads. The situation right now is mixed anyway. Many packages use X, many others gtk or fltk. The sanity part in this is simple that a general rule of USE flags is: If it's *not* optional, don't make it a USE flag. In the case of xvattr for example, Gtk is not optional if you want the X utility.
Re: [gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 02:12 PM, Nikos Chantziaras wrote: On 02/08/2010 01:36 PM, AllenJB wrote: On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. [...] I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). If it would be problematic for a package to switch to X then of course it might be better to leave it as-is. But most of the time, the programs in question only state gtk or fltk in them, even though Gtk is not optional at all. A perfect example here is media-video/xvattr. If you don't set the gtk USE flag, then you don't get the graphical tool at all, only the command line tool. Very bad example. That's what people want: xvattr is used on headless VDR multimedia HTPC's, and VDR doesn't need toolkits like GTK+ installed.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-06 17:54:10 Mark Loeser napisał(a): Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a): I consider filing bugs for not adjusted packages after some months (e.g in summer). 1123 packages (440 in dev-python category) from 108 categories specify dev-lang/python or virtual/python in DEPEND or RDEPEND, so actually it might be better to start filing bugs in this month. If there are no objections, then I would like to file 1 bug per category (except dev-python category). Make trackers and make one bug per package. Its way too hard to follow a huge metabug with a bunch of packages listed in it. Average number of non-dev-python packages handled in 1 bug would be only 6.4, but I can create create 1 bug per package, if you still want it. Also, I think the concerns and suggestions that were brought up about the syntax of this new variable should be addressed first and not ignored. I will include examples in documentation of PYTHON_DEPEND to avoid misunderstanding of syntax of this variable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 01:39 PM, Samuli Suominen wrote: On 02/08/2010 01:30 PM, Tomáš Chvátal wrote: Dne 8.2.2010 12:15, Nikos Chantziaras napsal(a): Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools. Sounds sane. For correct usage lately the mplayer ebuild was rewritten this way. Might be good idea to open tracker for these and all bugs cced to it. So interested persons can fix it. Note for maintainers: qa bugs are considered as issue when adding new packages. In longer perspective it is good to have them fixed, but you don't have to proactively fix old packages. Writing this before people starts complaining we are again filling lots of bugs. @qa: any objections against me opening the tracker? To sum up the issue: use X wrap all other widget useflags if there is CLI interface available, so if user don't want X usage for package he just set -X and rest widget flags don't matter at all. Tomas IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps.
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 02:11 PM, Christian Faulhammer wrote: Hi, Nikos Chantziarasrea...@arcor.de: A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. Your proposal does not look to appealing to me. What about people trying to keep pollution down and avoid one or the other toolkit? This would mean that we favor one group of people over another :P
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 02:16 PM, Samuli Suominen wrote: On 02/08/2010 02:12 PM, Nikos Chantziaras wrote: On 02/08/2010 01:36 PM, AllenJB wrote: On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. [...] I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). If it would be problematic for a package to switch to X then of course it might be better to leave it as-is. But most of the time, the programs in question only state gtk or fltk in them, even though Gtk is not optional at all. A perfect example here is media-video/xvattr. If you don't set the gtk USE flag, then you don't get the graphical tool at all, only the command line tool. Very bad example. That's what people want: xvattr is used on headless VDR multimedia HTPC's, and VDR doesn't need toolkits like GTK+ installed. So which should be preffered? VDR people putting media-video/xvattr -X or desktop people putting media-video/xvattr +gtk? Btw, I use xvattr and I don't have a VDR HTPC or anything like that.
Re: [gentoo-dev] Re: X vs gtk USE flags
On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. AllenJB
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 03:41 PM, AllenJB wrote: On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. So I guess what I was really proposing then was a gui USE flag :P Sorry about that, I didn't fully understand the meaning of the X flag.
Re: [gentoo-dev] Re: X vs gtk USE flags
On 08/02/10 14:02, Nikos Chantziaras wrote: On 02/08/2010 03:41 PM, AllenJB wrote: On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. So I guess what I was really proposing then was a gui USE flag :P Sorry about that, I didn't fully understand the meaning of the X flag. And what purpose would this flag server that's not already covered by using USE=X fltk qt gtk kde gnome (and possibly a couple of others I've forgotten about) - which are all already in the desktop profile, which the vast majority of people who don't care what toolkit they get will already be using anyway? The current system caters perfectly for both people who want to avoid specific toolkits and those who don't care what toolkits they use. AllenJB
Re: [gentoo-dev] Re: X vs gtk USE flags
Hi all, On Mon, Feb 08, 2010 at 02:34:08PM +0200, Nikos Chantziaras wrote: On 02/08/2010 02:11 PM, Christian Faulhammer wrote: Hi, Nikos Chantziarasrea...@arcor.de: A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. Your proposal does not look to appealing to me. What about people trying to keep pollution down and avoid one or the other toolkit? This would mean that we favor one group of people over another :P If a package can run in some form without a certain toolkit, why should we force people to install that toolkit with the package? Imho that is bloating their systems unnecessarily. William pgpCPQNJ7ztNl.pgp Description: PGP signature
Re: [gentoo-dev] Python-3.2-related changes
2010-02-06 13:14:41 Brian Harring napisał(a):
On Sat, Feb 06, 2010 at 12:03:11PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
- Dependency on Python 2 should be set correctly. You can specify it
directly in
{,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
It might be useful to provide another example:
If given package requires e.g. Python =2.6, but does not support Python 3,
then you can
set PYTHON_DEPEND=2:2.6.
We really need better syntax than that. Particular reason you're
jamming py2k and py3k all into one? Breaking it down into
PYTHON2K_DEPEND and PYTHON3K_DEPEND
There's no need for 2 variables when 1 variable is sufficient.
would involve lest magic in parsing
At least I was able to exercise my bash skills and find a bug in bash :) .
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: X vs gtk USE flags
Re: [gentoo-dev] Re: X vs gtk USE flags
On 8 February 2010 16:22, AllenJB gentoo-li...@allenjb.me.uk wrote: The current system caters perfectly for both people who want to avoid specific toolkits and those who don't care what toolkits they use. I agree. The current system is best, in my opinion. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware
# Daniel Pielmeier bil...@gentoo.org (08 Feb 2010) # Masked for removal on 10 Mar 2010. # Manifest failures due to upstream source changes without version bump. # SRC_URI changes all the time. Firmware extraction fails. Overly complex # ebuild for just installing one or two files. # Will be replaced by updating the vdr-guide with information on how to obtain # and install the firmware. media-tv/linuxtv-dvb-firmware -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 05:22 PM, AllenJB wrote: On 08/02/10 14:02, Nikos Chantziaras wrote: On 02/08/2010 03:41 PM, AllenJB wrote: On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. So I guess what I was really proposing then was a gui USE flag :P Sorry about that, I didn't fully understand the meaning of the X flag. And what purpose would this flag server that's not already covered by using USE=X fltk qt gtk kde gnome (and possibly a couple of others I've forgotten about) - which are all already in the desktop profile, which the vast majority of people who don't care what toolkit they get will already be using anyway? I'm confused. First there's talk about HTPC people and now about people who have all USE flags enabled. Why do you always have to pick the extremes? The majority set it up like this: X kde qt4 -gnome -gtk and X gnome gtk -kde -qt4 The current system caters perfectly for both people who want to avoid specific toolkits and those who don't care what toolkits they use. I saw a problem with using gtk with stuff where gtk isn't actually optional and what is really meant by that use flag is not provide the gtk version of the GUI, but provide the only available GUI; happens to be Gtk. But since most people think that's the way to go, I'm obviously wrong. In any event, there's no need to continue this discussion.
Re: [gentoo-dev] desktop-misc@ needs your help
On 02/07/10 09:38, Markos Chandras wrote: On Saturday 06 February 2010 19:22:47 Samuli Suominen wrote: While we have few devs listed in desktop-misc, nobody is really looking at the bugs in general so it's like a clone of maintainer-needed alias at the moment... The bug count has escalated in /a year/ from /5 to 83/ (only counting directly assigned ones). So... as usual, if you are bored, feel free to join :) Ty, Samuli Thanks Samuli for stepping up making this announcement. I was about to join that herd anyway :) Don't forget about desktop-dock :) And as probably with any other team: if you want to help -- join! There's no time to waste :) -- Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] desktop-misc@ needs your help
I was thinking that maybe we should join the desktop-wm [1] and desktop-util [2] subprojects and elect one lead, as all herds under these projects seem to lack manpower and coordination. And we could try to recruit a few new devs for these herds as well. As I am now a full-time openbox user, I am willing to redirect some of my activity to this area. 1: http://www.gentoo.org/proj/en/desktop/wm/index.xml 2: http://www.gentoo.org/proj/en/desktop/util/index.xml -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware
On Mon, Feb 8, 2010 at 1:15 PM, Daniel Pielmeier bil...@gentoo.org wrote: # Daniel Pielmeier bil...@gentoo.org (08 Feb 2010) # Masked for removal on 10 Mar 2010. # Manifest failures due to upstream source changes without version bump. # SRC_URI changes all the time. Firmware extraction fails. Overly complex # ebuild for just installing one or two files. # Will be replaced by updating the vdr-guide with information on how to obtain # and install the firmware. media-tv/linuxtv-dvb-firmware -- Daniel Pielmeier Ignore this. Its not being removed. -- Doug Goldstein
