Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 02/01/13 17:28, Matt Turner wrote: On Wed, Jan 2, 2013 at 4:11 AM, Samuli Suominen ssuomi...@gentoo.org wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. As a data point: pkgconfig and glib:2 are built during stage3 and removed during --depclean. Switching to pkgconf avoids glib:2 entirely and saves some stage3 building time. so it's really an non-issue. and if someone finds this really an important issue: catalyst could be fixed to enable USE=internal-glib during stage building, heck, I think we could wrap that functionality to USE=build ?
[gentoo-dev] Should portage tree CVS impose a commit moratorium during snapshot creation?
In latest portage tree snapshot: * Digest verification failed: * /usr/portage/dev-libs/gobject-introspection/gobject-introspection-1.34.2-r1.ebuild * Reason: Filesize does not match recorded size * Got: 2598 * Expected: 2582 The problem is that the directory was apparently included into daily snapshot between 00:31:07 UTC (ebuild commit) and 00:31:13 UTC (Manifest commit). For those that don't remember, CVS does not have atomic commits, so it's not possible to instead use something like svn export / git archive. Since Gentoo Handbook now recommends using emerge-webrsync to fetch the tree, perhaps some guards should be put in place to avoid having a snapshot with bad digests for 24 hours? E.g., a commit moratorium, or verification of all digests in a temporary tree copy before archiving, or synchronizing to a copy tree until the result is stable. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Should portage tree CVS impose a commit moratorium during snapshot creation?
On Thu, Jan 3, 2013 at 10:46 AM, Maxim Kammerer m...@dee.su wrote: The problem is that the directory was apparently included into daily snapshot between 00:31:07 UTC (ebuild commit) and 00:31:13 UTC (Manifest commit). For those that don't remember, CVS does not have atomic commits, so it's not possible to instead use something like svn export / git archive. Note that this problem is compounded by Manifest signing: because ebuilds are committed before the Manifest is signed, there is a potentially long gap between the commit of the ebuilds and the commit of the Manifest. I ran into this yesterday, when I forgot about the password dialog sitting in some terminal I wasn't looking at for about half an hour, and at some point someone in IRC noticed that the Manifest was out of date. I'm not sure how common it is for people to interactively enter their password on each commit like me. In any case, we probably shouldn't spend a whole lot of effort on this given the somewhat-impending git migration, which neatly solves this problem. Maybe there's some low-hanging fruit in the commit ordering, though? I was thinking it might be possible to have the Manifest signed before committing the ebuilds, but it's entirely likely that CVS keywords get in the way of that... Cheers, Dirkjan
Re: [gentoo-dev] Should portage tree CVS impose a commit moratorium during snapshot creation?
On 01/03/2013 02:09 AM, Dirkjan Ochtman wrote: In any case, we probably shouldn't spend a whole lot of effort on this given the somewhat-impending git migration, which neatly solves this problem. Maybe there's some low-hanging fruit in the commit ordering, though? I was thinking it might be possible to have the Manifest signed before committing the ebuilds, but it's entirely likely that CVS keywords get in the way of that... The CVS keyword expansion causes the ebuild digest to mutate during the commit. If we repoman could predict correctly emulate the CVS keywords expansion on the client side, then it could generate a correct Manifest in advance. However, that seems difficult given that the CVS keyword expansion contains a timestamp with 1 second precision. -- Thanks, Zac
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
On 03/01/13 03:28, Rick Zero_Chaos Farina wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/02/2013 06:11 PM, Pacho Ramos wrote: El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió: On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), ++ but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. Rich How this ended finally? :/ It ended with my setting PORTAGE_BZIP2_COMMAND=lbzip2 in my profile and moving on with my life. I am very not good at eselect scripts and I've not had the time to dig at it. You are welcome to work on the eselect script if you like. Feel free to steal the code used in eselect-pinentry. It was originally written by mgorny for eselect-sh, but then later modified by me, and has not had a single bug ever since.
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
On 03/01/2013 11:30, Samuli Suominen wrote: Feel free to steal the code used in eselect-pinentry. It was originally written by mgorny for eselect-sh, but then later modified by me, and has not had a single bug ever since. Can I reiterate that it'd be cool to have an eselect tools? :) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? I dont really understand your question here. So do you: - simply have 2 64bit apps wanting to use ffmpeg? - have 2 32bit binary packages wanting to use ffmpeg? - want to build foo and bar on a 64bit platform for a 32bit platform? - want a 64bit or a 32bit version of ffmpeg or both? - if you want a 32bit version of ffmpeg, do you only want 32bit libs or also a 32bit binary? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. Isnt out-of-tree build just building in a seperate location, so in the end doing one unpack instead of 2, while everything else still needs to be done for each target? However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) Please keep in mind, that the USE flags are different, depending on your arch. E.g. on amd64, you may additionally have x86 and x32, while on ppc64, you may have ppc64 and ppc. You dont want the later on amd64 nor the first on ppc. So how do you want to add different (use-expanded) USE flags based on the arch the user is running? You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? While the variable export, the build for each target and the merge of the results should also be possible inside an eclass, the dependency and USE flag parts seems more tricky. And additionally, with support of this in (multilib-)portage (not depending on EAPI, but enabled via FEATURES), i already get all of this without having to wait for a new EAPI/eclass and ebuilds moving to it. What finally occurred with this? What would be the problem of opting by this mixed solution (eclass for some packages and PM features requiring newer eapi for others)? I guess nothing new. Nobody yet provided an eclass providing the full support for everything i have in multilib-portage and i did not create the requested PMS-diff yet. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 00:43 +0100, Chí-Thanh Christopher Nguyễn escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pacho Ramos schrieb: Looks like finally you added yourself to metadata but with instructions to bug-wranglers to CC you and assign to herd. I would like to confirm this way of assigning things The difference is almost inconsequential in practice. Bugmail will be sent to both assignee and CC:. Only for maintainers without bugzilla privileges they need to ping their proxy to make certain updates to the bug. x11 team has similar instructions in the metadata for their proxy maintained package. Best regards, Chí-Thanh Christopher Nguyễn Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
El mié, 02-01-2013 a las 18:59 -0500, Mike Gilbert escribió:
On 1/2/2013 6:54 PM, Mike Gilbert wrote:
On 1/2/2013 6:41 PM, Pacho Ramos wrote:
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
It prevents eclasses from being sourced more than once. It is meant as a
performance enhancement for when eclasses inherit other eclasses. vapier
posted some stats on this list a while back.
We have a similar thing in python-single-r1. We call it
_PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.
Here's the thread.
http://archives.gentoo.org/gentoo-dev/msg_18dab542c1c59873f8cb68c96cdf6619.xml
OK thanks, maybe this should be added to devmanual as looks like it's
not documented apart of gentoo-dev list :/
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió: [...] Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) will - with signature.asc Description: This is a digitally signed message part
[gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
This comes from the following gentoo-dev thread:
http://www.gossamer-threads.com/lists/gentoo/dev/264888
Its usage will lead to the installation of a CONFIGURATION file
under /usr/share/doc/${PF} and show of elog messages with its content
first time package is installed, relying in doc file for future
installations or people simply going there to review configuration tips.
I also attach acpid ebuild as example.
Currently I have doubts about how to handle formatting, it is now using
fmt as kernel-2.eclass to format it and, then, you can set:
CONFIGURATION_INSTRUCTIONS=
You may wish to read the Gentoo Linux Power Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
and it will be properly formatted at the end. The problem is that I find
no way to force a jump to a new line (for example if somebody want to
show a command to run in a new line).
Other option would be to simply add quotes to:
echo ${CONFIGURATION_INSTRUCTIONS}
and drop fmt usage.
It will respect formatting specified in ebuild, but this needs to be
taken into account as, for example, acpid ebuild used as example should
be changed to use:
CONFIGURATION_INSTRUCTIONS=You may wish to read the Gentoo Linux Power
Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
or people will get an empty line at the top of the messages.
Maybe an option to toggle fmt/formatting usage could be used, but I am
unsure about how to handle it at eclass level in a short way (I could
add some ifs running either variant (with quotes or without them and
fmt usage), but not sure if a shorter way could be used)
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: configuration-doc
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_CONFIGURATION_DOC} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_CONFIGURATION_DOC=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at src_install phase.
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
fi
}
# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read
-r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
fi
}
# @FUNCTION: configuration-doc_src_install
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
configuration_create_doc
}
# @FUNCTION: configuration-doc_pkg_postinst
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
configuration_print_elog
}
fi
# Copyright 1999-2012 Gentoo Foundation
# Distributed under
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
On Jan 3, 2013 6:54 AM, Pacho Ramos pa...@gentoo.org wrote: El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió: [...] Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) will - with Pacho, I have been taking care of ekiga, ptlib and opal. Feel free to make me the assignee for bugs in those packages. I should be on metadata for those...
Re: [gentoo-dev] Packages without source code (was: Clarify the as-is license?)
On Sat, 29 Sep 2012, Rich Freeman wrote: On Sat, Sep 29, 2012 at 5:21 PM, Ulrich Mueller u...@gentoo.org wrote: On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote: If we start to measure the software freedom of the code inside the package, then maybe LICENSE is the wrong variable to express this. I'm aware that we can't distinguish the two cases. Should we have a binary-only license to catch it? The license isn't binary-only. The license is BSD. It just happens that the thing they're licensing is the binary and not the source. Coming back to this. I agree that the license is BSD. Does it really matter? Before we start overloading the LICENSE flag to represent something other than the license we should probably have a problem to actually fix. There is a real problem, namely that we use it for filtering with ACCEPT_LICENSE, and for BSD we currently cannot distinguish between free (i.e. source is available) and non-free software. As far as freedom of code goes, arguably the code is perfectly free - it just isn't open source. You could legally decompile, modify, recompile, and redistribute it and your assembly language sources as much as you like. The code is only free as in beer. But it is neither Free Software nor Open Source. The Free Software Definition [1] is very clear about this point: A program is free software if the program's users have the four essential freedoms: [...] • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. [...] • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this. [...] In order for freedoms 1 and 3 (the freedom to make changes and the freedom to publish the changed versions) to be meaningful, you must have access to the source code of the program. Therefore, accessibility of source code is a necessary condition for free software. So is The Open Source Definition [2]: 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. We could easily solve this by adding a binary-only or no-source-code tag to such packages. It would be included in the @BINARY-REDISTRIBUTABLE license group, but not in @FREE. So such packages would be excluded for users with ACCEPT_LICENSE=-* @FREE. Thinking about the name, no-source-code might be a better choice than binary-only. As the GPL defines it, The source code for a work means the preferred form of the work for making modifications to it. This may be binary, e.g. for pictures in a bitmap format. Ulrich [1] http://www.gnu.org/philosophy/free-sw.html [2] http://opensource.org/osd
Re: [gentoo-dev] Packages without source code (was: Clarify the as-is license?)
On Thu, Jan 3, 2013 at 9:39 AM, Ulrich Mueller u...@gentoo.org wrote: We could easily solve this by adding a binary-only or no-source-code tag to such packages. It would be included in the @BINARY-REDISTRIBUTABLE license group, but not in @FREE. So such packages would be excluded for users with ACCEPT_LICENSE=-* @FREE. As long as it is also marked with the BSD license I don't have a problem with this. The license is, in fact, BSD, so we do need to keep that info around. Thinking about the name, no-source-code might be a better choice than binary-only. As the GPL defines it, The source code for a work means the preferred form of the work for making modifications to it. This may be binary, e.g. for pictures in a bitmap format. I understand the distinction adds value to our users, but I find it amusing that a computer scientist would even try to define the term source code. :) Rich
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 09:33 -0500, Jesus Rivero (Neurogeek) escribió: On Jan 3, 2013 6:54 AM, Pacho Ramos pa...@gentoo.org wrote: El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió: [...] Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) will - with Pacho, I have been taking care of ekiga, ptlib and opal. Feel free to make me the assignee for bugs in those packages. I should be on metadata for those... Thanks, will then assign to you and CC herd, if voip people want to completely drop, please talk! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
On Thu, Jan 03, 2013 at 02:01:03PM +0100, Pacho Ramos wrote:
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: configuration-doc
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_CONFIGURATION_DOC} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_CONFIGURATION_DOC=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
Why does it matter if the unsupported eapi is too old or unknown? I
think you can combine the first and last branches of this case
statement.
On the other hand, if you don't export phase functions, you don't have
to worry about EAPIS; you can just allow ebuild developers to call your
functions directly. This is what I see happening in your sample ebuild
below.
EXPORT_FUNCTIONS src_install pkg_postinst
Drop this export_functions call. You don't need it based on what I see
in your ebuild.
# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at src_install phase.
You can pass in the content as $1 instead of using a global variable for
it:
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${1} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
I would use ${T}/CONFIGURATION here.
echo ${1} | fmt ${T}CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
Again, ${T}/CONFIGURATION
fi
}
# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
I would recommend using the CONFIGURATION file here, as follows:
if [ -f ${T}/CONFIGURATION ]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
This is an issue if I want to add display some tips that have changed
between different versions of the software. I would propose not trying
to do this, but let the user call this function.
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read
-r ELINE; do elog ${ELINE}; done
cat ${T}/CONFIGURATION | fmt | while read -r ELINE;
do elog ${ELINE}; done
eshopts_pop
fi
fi
}
# @FUNCTION: configuration-doc_src_install
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
configuration_create_doc
}
# @FUNCTION: configuration-doc_pkg_postinst
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
configuration_print_elog
}
fi
These can go; your example ebuild doesn't need them since it calls the
eclass functions.
Below, I am showing how the ebuild would change based on my changes to
the eclass.
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild,v 1.6
2012/11/25 18:59:25 armin76 Exp $
EAPI=4
inherit configuration-doc systemd
DESCRIPTION=Daemon for Advanced Configuration and Power Interface
HOMEPAGE=http://tedfelix.com/linux/acpid-netlink.html;
SRC_URI=http://tedfelix.com/linux/${P}.tar.xz;
LICENSE=GPL-2
SLOT=0
KEYWORDS=amd64 ia64 -ppc x86
Re: [gentoo-dev] collision-protect - protect-owned ?
On 01/02/2013 10:13 PM, Alexandre Rostovtsev wrote:
On Thu, 2013-01-03 at 00:25 -0500, Rick Zero_Chaos Farina wrote:
On 01/03/2013 12:06 AM, Michał Górny wrote:
On Wed, 02 Jan 2013 19:49:02 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918,
and I think it's worth to think about a better fix. I still keep hitting
mysterious collisions with orphaned files from time to time.
How about switching the developer profile from collision-protect to
protect-owned, and proceeding with enabling protect-owned by default for
all profiles? (not all developers are using the developer profile)
Well, it all depends.
protect-owned is easy and lazy. You just get errors on package
collisions, care about nothing else.
collision-protect cares about every collision. It can help you notice
that *your* package lefts orphaned files for some reason or writes
where it is not supposed to write.
In the years I ran collision-protect I can say it prevented hundreds of
merges of linux-firmware (because the kernel also installs firmware) and
not much else.
Would you be able to share more specific insight on how
collision-protect helped protect files that need to be protected where
protect-owned would have been inferior?
It protects files that cannot be owned by any one package, but must still
be protected, for example /usr/share/glib-2.0/schemas/gschemas.compiled
This file contains the compiled database of all your gsettings schemas.
It needs to be updated by running glib-compile-schemas every time you
install or remove a gsettings schemas xml file. Ebuilds for glib-based
stuff have to run glib-compile-schemas in pkg_postinst(), and the
gschemas.compiled must remain outside package manager control.
However, some packages' build systems have make or make install call
glib-compile-schemas by default. A careless developer who doesn't use
collision-protect *and* doesn't pay attention to protect-owned's warning
messages might accidentally allow his ebuild to compile and install
/usr/share/glib-2.0/schemas/gschemas.compiled in src_install(), marking
the file as owned by his ebuild. When his ebuild is uninstalled, the
gschemas.compiled file would be removed, breaking the system.
For special files like these, maybe it makes sense to delegate a single
owner, have that owner do special handling in pkg_preinst. For
gschemas.compiled, the natural owner would be dev-libs/glib:2 since it
installs the glib-compile-schemas program. For special handling in
pkg_preinst, it could do like preserve_old_lib in eutils.eclass, and
copy the existing file from ${ROOT} to ${D}.
--
Thanks,
Zac
Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
El jue, 03-01-2013 a las 14:29 -0600, William Hubbs escribió:
[...]
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
Why does it matter if the unsupported eapi is too old or unknown? I
think you can combine the first and last branches of this case
statement.
Well, I saw it in other eclasses and thought the distinction was
preferred, but have no problems on changing it
On the other hand, if you don't export phase functions, you don't have
to worry about EAPIS; you can just allow ebuild developers to call your
functions directly. This is what I see happening in your sample ebuild
below.
It exports src_install and pkg_postinst, at least the second one could
be used in other ebuilds that are only setting a package specific one
for showing this kind of messages (for example bumblebee ebuilds).
For src_install case, probably some other ebuilds could benefit, but
didn't find them when I fast checked yesterday :/. Its purpose is to
ensure doc CONFIGURATION file is created, the ideal would be to be able
to only add it to create it and leave other eclasses or eapi defaults to
handle the rest of src_install, but I think it's not possible :| (and,
then, it will behave like eapi = 4 default src_install phase + creating
the file)
Anyway, EAPI = 4 is still needed for REPLACING_VERSIONS usage, that
allows to simplify things preventing us from needing to set pkg_preinst
also
EXPORT_FUNCTIONS src_install pkg_postinst
Drop this export_functions call. You don't need it based on what I see
in your ebuild.
They can be needed if ebuild doesn't need to have a custom
src_install/pkg_postinst only for this purposes
# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at src_install phase.
You can pass in the content as $1 instead of using a global variable for
it:
But, how to share CONFIGURATION_INSTRUCTIONS contents then for
create_doc and print_elog? The idea is to share the same message, and
using global variable for this purpose is already done with
kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps)
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${1} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
I would use ${T}/CONFIGURATION here.
echo ${1} | fmt ${T}CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
Again, ${T}/CONFIGURATION
I have no problem but, what is its advantage? (to remember it more
easily next time). Thanks :)
fi
}
# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
I would recommend using the CONFIGURATION file here, as follows:
if [ -f ${T}/CONFIGURATION ]; then
That is interesting as ensures file was created, but, will it be still
there at pkg_postinst phase?
if ! [[ ${REPLACING_VERSIONS} ]]; then
This is an issue if I want to add display some tips that have changed
between different versions of the software. I would propose not trying
to do this, but let the user call this function.
This is intentional because the kind of messages that are always the
same and, then, need to only be shown with elog first time the package
is installed need this checking. From packages I have seen, those
messages that are related with updating from version XXX should still
be handled manually.
The eclass could, of course, be handled to also handle this cases, but I
would like to keep the automatic way of it showing the message only
first time package is installed.
[...]
CONFIGURATION_INSTRUCTIONS=
You may wish to read the Gentoo Linux Power Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
Delete this and make it a local below if you want the variable,
otherwise pass it as a constant.
sorry for the ignorance but, how should I pass it as a constant? Using
readonly? Also, I am not using here any external tool and, then,
global scope shouldn't be discouraged
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
src_install() {
emake DESTDIR=${D} install
newdoc kacpimon/README
[gentoo-dev] Re: Packages without source code (was: Clarify the as-is license?)
Rich Freeman posted on Thu, 03 Jan 2013 10:40:08 -0500 as excerpted: On Thu, Jan 3, 2013 at 9:39 AM, Ulrich Mueller u...@gentoo.org wrote: We could easily solve this by adding a binary-only or no-source-code tag to such packages. It would be included in the @BINARY-REDISTRIBUTABLE license group, but not in @FREE. So such packages would be excluded for users with ACCEPT_LICENSE=-* @FREE. As long as it is also marked with the BSD license I don't have a problem with this. The license is, in fact, BSD, so we do need to keep that info around. What about two licenses, BSD, and BSD-no-sources? The second license file would simply note at the top that there's no source available, but the license is BSD, with the BSD license underneath the note. That would allow the first to be included in @FREE, while the second was only included in @BINARY_REDISTRIBUTABLE. -- 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
Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
On Thu, Jan 03, 2013 at 10:03:21PM +0100, Pacho Ramos wrote:
El jue, 03-01-2013 a las 14:29 -0600, William Hubbs escribió:
[...]
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
Why does it matter if the unsupported eapi is too old or unknown? I
think you can combine the first and last branches of this case
statement.
Well, I saw it in other eclasses and thought the distinction was
preferred, but have no problems on changing it
Well, that's up to you I guess, but, I just didn't see the difference.
You can pass in the content as $1 instead of using a global variable for
it:
But, how to share CONFIGURATION_INSTRUCTIONS contents then for
create_doc and print_elog? The idea is to share the same message, and
using global variable for this purpose is already done with
kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps)
Does kernel-2.eclass save the message somewhere or just print it? If it
just prints it I can see that, but since you are saving it to a file, I
was just thinking that there is no need to keep a global variable
around.
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${1} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
I would use ${T}/CONFIGURATION here.
echo ${1} | fmt ${T}CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
Again, ${T}/CONFIGURATION
I have no problem but, what is its advantage? (to remember it more
easily next time). Thanks :)
Well, ${T} is a temporary directory where you can put anything you want,
and it is defined in PMS, so I just use it instead of throwing files in
the working tree.
# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
I would recommend using the CONFIGURATION file here, as follows:
if [ -f ${T}/CONFIGURATION ]; then
That is interesting as ensures file was created, but, will it be still
there at pkg_postinst phase?
Yes, it should be.
if ! [[ ${REPLACING_VERSIONS} ]]; then
This is an issue if I want to add display some tips that have changed
between different versions of the software. I would propose not trying
to do this, but let the user call this function.
This is intentional because the kind of messages that are always the
same and, then, need to only be shown with elog first time the package
is installed need this checking. From packages I have seen, those
messages that are related with updating from version XXX should still
be handled manually.
Say I have foobar-1 installed, and it has configuration instructions.
Now, foobar-2 comes along with different configuration instructions
that do not work for foobar-1.
What happens to the CONFIGURATION file when I upgrade? Does it now have
foobar-2's instructions? If not, this is a bug.
William
pgpRBCciB_l4o.pgp
Description: PGP signature
