[gentoo-dev] NOTICE default-linux/amd64/{2007.0,dev} profiles has been moved to /dev/null
It was about 7 months since these was deprecated, and there was no pparent upgrade path issues. They are now gone. Thanks, Samuli
[gentoo-dev] 2009.0 profiles
We've been living with the 2008.0 profiles for a while now. I think the time has come for 2009.0 profiles so we can have some updates. Also, there are plans for an anniversary release of our LiveCD, so I think the time is right to start working on a new set of profiles. One reason I bring this up is that the Qt team would like to see the qt3 useflag dropped from desktop profiles, and I'm sure others have some suggestions as well. Traditionally, the release team has taken care of this, as the profiles were tied to releases of install media and stage3 archives. Now that we have the autobuilds, this relationship isn't as self-evident anymore, which is why I address the wider dev community. Please share your ideas on this. Cheers, Ben
Re: [gentoo-dev] Keeping profiles/ tidy
On Fri, Jul 31, 2009 at 9:11 PM, Samuli Suominenssuomi...@gentoo.org wrote: I've just closed http://bugs.gentoo.org/show_bug.cgi?id=105016. But bugs like these shouldn't be around in the first place. When you remove a package from tree, please grep the profiles/ directory for matching entries and remove them too. This seems like something that should be added to the ebuild/end quiz. -- ~Nirbheek Chauhan GNOME Team, Gentoo
[gentoo-dev] Monthly Gentoo Council Reminder for August
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
Re: [gentoo-dev] 2009.0 profiles
Ben de Groot wrote: We've been living with the 2008.0 profiles for a while now. I think the time has come for 2009.0 profiles so we can have some updates. Also, there are plans for an anniversary release of our LiveCD, so I think the time is right to start working on a new set of profiles. One reason I bring this up is that the Qt team would like to see the qt3 useflag dropped from desktop profiles, and I'm sure others have some suggestions as well. Haven't the devs just been making changes directly to the profiles since at least autobuilds came about? I'm sure I've seen some global use flag changes relatively recently. What is the actual policy on this? It seems kind of pointless to me to tie global use flag changes to a release cycle when per-package use flags are now changed on a whim (with EAPI-2 style default use flags) Traditionally, the release team has taken care of this, as the profiles were tied to releases of install media and stage3 archives. Now that we have the autobuilds, this relationship isn't as self-evident anymore, which is why I address the wider dev community. With the introduction of autobuilds, would it be a good idea to rename the profiles so that they don't have the date association? This does seem to confuse a number of new users who will appear asking where the 2009 profiles are. What does Gentoo use versioned profiles for now that use flag changes, in particular per-package use flags, don't seem to be linked at all. What should they be used for? Is this going to be another thing that isn't updated in the Handbooks? Please share your ideas on this. Cheers, Ben
[gentoo-dev] Inclusion of speech support on Gentoo release Media
Hi, It has been quite some time sinse I've found time to be on an Internet connection to post, so: I'm just posting to find out how discussions on adding app-accessibility/speakup, etc, to Gentoo release media is going, and to find out if the Gentoo release team has plans for including this for blind users such as myself who do not have a hardware synth, nor a way to see the screen, so that we might successfully install Gentoo? I will point out that even thorugh we can read the handbook, and all that, it's not easy doing so in Linux. Linux accessibility is still under constant development compared for instance, to the world of Microsoft Windows operating systems. The screen-reading access technologies have simply been under far more development. I'd like to see Gentoo be added to the list of accessible software. Only one LiveCD, from: www.grml.org has become accessible for blind folks. The truth is, I love Gentoo more than any other CD. Asking for an SSH installation degrades my indipendence from installing Gentoo successfully without sighted assistance. If someone could update me on this, I'd value an update. Thank you all. Regards, --Keith
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I would love to see the GLEP on CPE names in metadata.xml discussed, http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35155.html Any guidance on what I need to do to make it happen is very welcome. Thanks, Sebastian
Re: [gentoo-dev] Keeping profiles/ tidy
Nirbheek Chauhan wrote: On Fri, Jul 31, 2009 at 9:11 PM, Samuli Suominenssuomi...@gentoo.org wrote: I've just closed http://bugs.gentoo.org/show_bug.cgi?id=105016. But bugs like these shouldn't be around in the first place. When you remove a package from tree, please grep the profiles/ directory for matching entries and remove them too. This seems like something that should be added to the ebuild/end quiz. Ebuild quiz: 19. What is the procedure for removing packages from the tree? Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
Right now, xfce ebuilds in tree are unmaintainable because:
- Eclass sets invalid license to pkgs, they all have different ones,
GPL-2, LGPL-2*, GPL-3, BSD
- Ebuilds have started using internal functions from both xfce44 and
xfce4 eclasses. Yes, some Xfce 4.6 ebuilds are still using xfce44.eclass.
- Upstream changed SRC_URI for plugins. It was a problem even before,
some plugins are in separate locations such as Xfce4 developers own
devspaces.
Just to mention some. It's complex, and not in a smart way.
We want to deprecate all of the xfce*.eclasses in tree and switch to
this simple template ebuild.
Please comment if there's something to change. Keep it simple.
Timeframe: If you agree, I or we will convert them in within 1-2 days
from now.
Thanks, Samuli
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xfconf.eclass
# @MAINTAINER:
# XFCE maintainers x...@gentoo.org
# @BLURB: Default XFCE ebuild layout
# @DESCRIPTION:
# Default XFCE ebuild layout
inherit base fdo-mime gnome2-utils
# @FUNCTION: xfconf_src_configure
# @DESCRIPTION:
# Run econf with opts in XFCONF variable
xfconf_src_configure() {
econf \
${XFCONF}
}
# @FUNCTION: xfconf_src_compile
# @DESCRIPTION:
# Run econf with opts in XFCONF variable
xfconf_src_compile() {
xfconf_src_configure
emake || die emake failed
}
# @FUNCTION: xfconf_src_install
# @DESCRIPTION:
# Run emake install and install documentation in DOCS variable
xfconf_src_install() {
emake DESTDIR=${D} install || die emake install failed
if [[ -n ${DOCS} ]]; then
dodoc ${DOCS} || die dodoc failed
fi
}
# @FUNCTION: xfconf_pkg_preinst
# @DESCRIPTION:
# Run gnome2_icon_savelist
xfconf_pkg_preinst() {
gnome2_icon_savelist
}
# @FUNCTION: xfconf_pkg_postinst
# @DESCRIPTION:
# Run fdo-mime_{desktop,mime}_database_update and gnome2_icon_cache_update
xfconf_pkg_postinst() {
fdo-mime_desktop_database_update
fdo-mime_mime_database_update
gnome2_icon_cache_update
}
# @FUNCTION: xfconf_pkg_postrm
# @DESCRIPTION:
# Run fdo-mime_{desktop,mime}_database_update and gnome2_icon_cache_update
xfconf_pkg_postrm() {
fdo-mime_desktop_database_update
fdo-mime_mime_database_update
gnome2_icon_cache_update
}
case ${EAPI:-0} in
2)
EXPORT_FUNCTIONS src_configure src_install pkg_preinst
pkg_postinst pkg_postrm
;;
*)
EXPORT_FUNCTIONS src_compile src_install pkg_preinst
pkg_postinst pkg_postrm
;;
esac
Re: [gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
Samuli Suominen wrote:
Please comment if there's something to change. Keep it simple.
Improved version attached. EAPI checking modification.
Thanks, Samuli
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xfconf.eclass
# @MAINTAINER:
# XFCE maintainers x...@gentoo.org
# @BLURB: Default XFCE ebuild layout
# @DESCRIPTION:
# Default XFCE ebuild layout
inherit base fdo-mime gnome2-utils
EXPF=src_compile src_install pkg_preinst pkg_postinst pkg_postrm
case ${EAPI:-0} in
2) EXPF+= src_configure ;;
1|0) ;;
*) die Unknown EAPI. ;;
esac
EXPORT_FUNCTIONS ${EXPF}
# @FUNCTION: xfconf_src_configure
# @DESCRIPTION:
# Run econf with opts in XFCONF variable
xfconf_src_configure() {
econf ${XFCONF}
}
# @FUNCTION: xfconf_src_compile
# @DESCRIPTION:
# Run econf with opts in XFCONF variable
xfconf_src_compile() {
has src_configure ${EXPF} || xfconf_src_configure
emake || die emake failed
}
# @FUNCTION: xfconf_src_install
# @DESCRIPTION:
# Run emake install and install documentation in DOCS variable
xfconf_src_install() {
emake DESTDIR=${D} install || die emake install failed
if [[ -n ${DOCS} ]]; then
dodoc ${DOCS} || die dodoc failed
fi
}
# @FUNCTION: xfconf_pkg_preinst
# @DESCRIPTION:
# Run gnome2_icon_savelist
xfconf_pkg_preinst() {
gnome2_icon_savelist
}
# @FUNCTION: xfconf_pkg_postinst
# @DESCRIPTION:
# Run fdo-mime_{desktop,mime}_database_update and gnome2_icon_cache_update
xfconf_pkg_postinst() {
fdo-mime_desktop_database_update
fdo-mime_mime_database_update
gnome2_icon_cache_update
}
# @FUNCTION: xfconf_pkg_postrm
# @DESCRIPTION:
# Run fdo-mime_{desktop,mime}_database_update and gnome2_icon_cache_update
xfconf_pkg_postrm() {
fdo-mime_desktop_database_update
fdo-mime_mime_database_update
gnome2_icon_cache_update
}
Re: [gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
On Sat, 01 Aug 2009 20:58:10 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Improved version attached. EAPI checking modification. 2) EXPF+= src_configure ;; += is bash 3.1, which isn't legal for use in the tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
On Sun, Jul 26, 2009 at 5:21 PM, Arfrever Frehtes Taifersar Arahesisarfre...@gentoo.org wrote: 2009-07-26 14:40:13 Marijn Schouten (hkBst) napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: I would like to present the plan of support for multiple ABIs. It should be sufficient for Python modules and might be also appropriate for some other ABI types (e.g. for Ruby modules). In the context of which problem are you brainstorming? This proposition is intended to solve multiple problems, but Gentoo Python Project especially would like to have it available during transitions to new Python versions (e.g. Python 3.*). Python 3.1 will be added to the tree in the next week. Over 10 Python modules should work with Python 3, but the majority of packages doesn't work yet. We want to provide possibility of installing Python modules into site-packages directories of multiple Python versions (e.g. 2.6 and 3.1). In currently existing EAPIs we *will* support it, but without checking Python ABI dependencies during dependency calculation. I don't think this is easy to do, but I think the solution to this problem should be the same as the (as yet not existing) solution to the multi-ABI problem as in (x86_64 vs. ix86). The biggest issue is to handle multiple instances of the same package and how to handle overlapping (ABI independent) files. Paul -- Paul de Vrieze
Re: [gentoo-dev] 2009.0 profiles
AllenJB wrote: Ben de Groot wrote: We've been living with the 2008.0 profiles for a while now. I think the time has come for 2009.0 profiles so we can have some updates. Also, there are plans for an anniversary release of our LiveCD, so I think the time is right to start working on a new set of profiles. One reason I bring this up is that the Qt team would like to see the qt3 useflag dropped from desktop profiles, and I'm sure others have some suggestions as well. Haven't the devs just been making changes directly to the profiles since at least autobuilds came about? I'm sure I've seen some global use flag changes relatively recently. What is the actual policy on this? It seems kind of pointless to me to tie global use flag changes to a release cycle when per-package use flags are now changed on a whim (with EAPI-2 style default use flags) I think a release cycle is most useful for handling incompatible changes. This allows us to make changes in newer releases that might break older package managers. Traditionally, the release team has taken care of this, as the profiles were tied to releases of install media and stage3 archives. Now that we have the autobuilds, this relationship isn't as self-evident anymore, which is why I address the wider dev community. With the introduction of autobuilds, would it be a good idea to rename the profiles so that they don't have the date association? This does seem to confuse a number of new users who will appear asking where the 2009 profiles are. Maybe, but you could also look at this as a documentation/training issue. What does Gentoo use versioned profiles for now that use flag changes, in particular per-package use flags, don't seem to be linked at all. What should they be used for? As said above, incompatible changes. However, it might be nice to offer some unversioned profiles for power-users who update regularly and aren't concerned about compatibility issues. Is this going to be another thing that isn't updated in the Handbooks? Please share your ideas on this. Cheers, Ben -- Thanks, Zac
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
On Sat, 25 Jul 2009 12:28:44 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
I would like to present the plan of support for multiple ABIs. It
should be sufficient for Python modules and might be also appropriate
for some other ABI types (e.g. for Ruby modules).
How do you plan to handle the intersection of ABIs? What if you have to
build or depend upon a Python module for both 32 and 64 bit ABIs, and
for both 2.5 and 2.6? What if you have a package that provides both
Ruby and Python code, where the two ABIs are independent rather than a
product?
4.1. Implicitly specified ABI dependencies. During calculation of
dependencies of given package, Portage will verify if all
dependencies, which use given ABI type, have been built with enabled
support for these ABIs, which are enabled for given package.
How do you say I need only a single ABI for this, even though it looks
like I need every ABI I'm built with? For example, if your Python
module, being built for 2.5 and 2.6, runs (but does not use in a
library sense) a Python program that comes as part of a Python package
that is buildable with multiple ABIs?
4.2. Explicitly specified ABI dependencies. {,P,R}DEPEND variables
will support specifying ABI dependencies in explicit way.
{,P,R}DEPEND variables will also support ABI conditionals. I suggest
using {ABI_type[comma-delimited values]} syntax, but it can be
changed.
I think we're trying to avoid introducing new special characters if we
can get away with using existing ones. You can overload [] and existing
conditionals if you're careful.
Having said that, you can probably do everything you described slightly
less elegantly just using things that're already in EAPI 3.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
Ciaran McCreesh wrote: On Sat, 01 Aug 2009 20:58:10 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Improved version attached. EAPI checking modification. 2) EXPF+= src_configure ;; += is bash 3.1, which isn't legal for use in the tree. It's been in use for a long time in xfce's ebuilds already, noone has ever complained. One can easily match some hundreds of ebuilds in tree where it's used. Is this *really* a issue? If so, I have no trouble in reusing the var, but it's ugly. -Samuli
Re: [gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
On 01-08-2009 21:26:09 +0300, Samuli Suominen wrote: Ciaran McCreesh wrote: On Sat, 01 Aug 2009 20:58:10 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Improved version attached. EAPI checking modification. 2) EXPF+= src_configure ;; += is bash 3.1, which isn't legal for use in the tree. It's been in use for a long time in xfce's ebuilds already, noone has ever complained. One can easily match some hundreds of ebuilds in tree where it's used. http://archives.gentoo.org/gentoo-dev/msg_a5b81c2f60a80cc91e2a47a802168185.xml Is this *really* a issue? If so, I have no trouble in reusing the var, but it's ugly. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] xfconf.eclass - codename: keep it simple, stupid
On Sat, 01 Aug 2009 21:26:09 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: += is bash 3.1, which isn't legal for use in the tree. It's been in use for a long time in xfce's ebuilds already, noone has ever complained. One can easily match some hundreds of ebuilds in tree where it's used. Yes, unfortunately it's impossible to get repoman to detect it reliably. Is this *really* a issue? If so, I have no trouble in reusing the var, but it's ugly. It is. Unfortunately a whole bunch of developers moaned noisily when we tried to fix the problem, so the tree's stuck with bash 3.0 indefinitely. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Progress on Universal Select Tool
Hello all,
Once again, another productive week. This week's work focused mostly on
profiles. Uprofile's implementation exceeded my expectations and was
much easier than what I thought it would be, the reason: uselect's
simple api.
What's working on uprofile:
* uprofile when called with no arguments, finds current folder profile.
If not present, it lists available profiles.
** Available profiles are profiles other than './uprofile/folder.json'
* Profiles are written in json
** Why json and not xml? Well, whoever said that xml is human-readable
should reconsider the clause. In need of a markup language, easy bridge
between python and markup, easily human-readable, I have chosen json.
Example:
{profile: {
description: Sample Profile,
author: meph...@gmail.com,
version: 0.1,
modules: {
python: {
actions: {
bin: [
/usr/bin/python2.6,
/usr/bin/python2.6-config
]
}
}
}
}}
In this profile, uprofile would call module python, action bin with
args: python2.6 and python2.6-config.
uprofile when called:
mephx - profiledfolder $ uprofile
Setting Folder Profile...
Setting /usr/bin/python2.6 success!
Setting /usr/bin/python2.6-config success!
Folder Profile Set!
* Profiles read modules (from uselect's module dir), actions from
modules, and call's Action.do_action() method with the specified args
list.
** In order to profiles to work properly, arguments cannot be Integers
as in uselect/eselect. All modules's actions which feature profiling
capabilities, need to accept either indexed values, either absolute
string values for specific selection. Why? Example: New python bin
appears in /usr/bin, indexes change, profile gets broken.
* Decided to keep a bin/ and a env.d/ in each .uprofile directory. These
are updated as they normally would via uselect.
* Automatic profile changing in bash can be done via a specially crafted
PROMPT_COMMAND. I'm using this one now:
PROMPT_COMMAND=test -e $HOME/.uselect/env.d/
PROFILE='$HOME/.uselect' ; test -e .uprofile/env.d/
PROFILE='./.uprofile' ; source \$PROFILE/env.d/*
** This actually changes the profile quite fast and reflects the changes
on $PS1 with the folder name, neat =)
mephx - ~/ $ cd profiledfolder
[folder] mephx - profiledfolder $
** To generate .uprofile/ directory, uprofile needs to be called by
hand. Sourcing env.d/ automatically also updates the user's PATH to that
bin DIR (this is still not implemented) therefore not needing to call
uprofile every time you wish to activate the profile.
Next steps:
* Finish implementing env actions. (It's now much funnier to test env
actions using profiles)
* Implement uprofile module for uselect as suggested.
* Implement some more modules.
What do you think?
* json modules?
* profile constraints (this is basically adding if's to profiles if we
want profiles to behave differently on certain conditions (hostname,
arch, etc...)
During the next week, I will deploy a properly packed version for
testing. I will also launch a call for modules to every *-eselect dev
and *-config dev as I do not have the time to implement most of the
modules just for testing purposes. Most modules are very easy to do
(symlinking ones) and conversion of eselect to uselect can be done
instantly, yet in an ugly way of still using all eselect's libs.
Keep tuned for more. And stay in school =)
Cheers,
Sérgio
--
Sérgio Almeida - meph...@gmail.com
mephx @ freenode
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Keeping profiles/ tidy
On Sat, Aug 1, 2009 at 7:32 PM, Petteri Rätybetelge...@gentoo.org wrote: Nirbheek Chauhan wrote: This seems like something that should be added to the ebuild/end quiz. Ebuild quiz: 19. What is the procedure for removing packages from the tree? Looking back, my answer to that question was insufficient, so the answer needs to be fixed ;) -- ~Nirbheek Chauhan GNOME Team, Gentoo
Re: [gentoo-dev] Keeping profiles/ tidy
Nirbheek Chauhan wrote: On Sat, Aug 1, 2009 at 7:32 PM, Petteri Rätybetelge...@gentoo.org wrote: Nirbheek Chauhan wrote: This seems like something that should be added to the ebuild/end quiz. Ebuild quiz: 19. What is the procedure for removing packages from the tree? Looking back, my answer to that question was insufficient, so the answer needs to be fixed ;) 19. What is the procedure for removing packages from the tree? Do you need to do something in profiles/ after removing? If yes, what would it be? -Samuli
[gentoo-dev] Gentoo stats server/client @ 2009-08-02
Hello again! Just a few quick updates. By now the server side accepts Gentoo-specific data from the client (transfered as JSON) and updates that machine's previous submission in the database. (That's not as trivial as it may sound at first.) As a single submission produces a few thousand INSERTs easily (from installed packages details mainly) I have been migrating the server to do batch processing in hope to reduce server load later. If smolt upstream likes the code it might go into Smolt earlier than the Gentoo extensions itself. Sebastian
