Re: [gentoo-dev] Devaway for me, for a whole year period(military service)
Panagiotis Christopoulos wrote: > Hi fellow devs and users, > > As some of you may already know, I won't be around this year, > cause I have to join the greek army, starting from tomorrow > morning. Feel free to touch my ebuilds. I will be in contact (via mail) > with Marijn Schouten (hkBst) in case you want to hear any news of me. > Keep up the great work, all of you, and don't break anything, cause I > will have very little time when I'll be back home, to update the "worlds of > my machinery" :P > > ps: I have left an open screen session running irssi, on a remote machine, so > you will see me online, but I'll be far away, probably :( > > Well, I'm a American but military is military. Be safe and come back in one HEALTHY piece!! Dale :-) :-)
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-02-08 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-02-08 23h59 UTC. Removals: sys-kernel/hppa-sources 2009-02-06 03:14:44 jer profiles/default-linux/hppa 2009-02-06 05:40:23 jer net-p2p/azureus 2009-02-06 11:46:56 caster sys-apps/sysutils 2009-02-08 20:08:12 vapier Additions: app-arch/lzip 2009-02-02 19:28:05 vapier net-p2p/freenet 2009-02-02 21:25:58 tommy net-mail/Freemail 2009-02-02 21:28:43 tommy dev-libs/liblinebreak 2009-02-02 22:22:33 alexxy app-text/fbreader 2009-02-02 22:28:07 alexxy games-board/pokerth 2009-02-03 01:52:57 mr_bones_ net-misc/ssvnc 2009-02-03 01:57:26 vapier kde-misc/kopete-cryptography2009-02-03 10:51:25 alexxy kde-misc/skanlite 2009-02-03 11:08:06 alexxy sci-libs/libticables2 2009-02-03 14:47:38 bicatali sci-libs/libticalcs22009-02-03 14:49:43 bicatali sci-libs/libticonv 2009-02-03 14:51:03 bicatali sci-libs/libtifiles22009-02-03 14:52:53 bicatali sci-calculators/tiemu 2009-02-03 15:49:54 bicatali sci-calculators/tilp2 2009-02-03 15:52:59 bicatali dev-python/aquarium 2009-02-03 19:19:09 patrick dev-python/html5lib 2009-02-03 19:45:28 patrick dev-python/pycipher 2009-02-03 19:55:22 patrick dev-python/librharris 2009-02-03 20:07:22 patrick dev-python/pyconstruct 2009-02-03 21:05:58 patrick dev-python/arrayterator 2009-02-03 21:22:50 patrick dev-python/pysvg2009-02-03 22:06:12 patrick dev-libs/distorm64 2009-02-03 23:12:38 patrick dev-python/python-ptrace2009-02-03 23:15:34 patrick dev-java/jettison 2009-02-05 00:22:59 betelgeuse java-virtuals/jaxp-virtual 2009-02-05 00:34:14 betelgeuse sys-cluster/osc-mpiexec 2009-02-05 02:59:51 jsbronder dev-perl/DateTime-Format-HTTP 2009-02-05 14:02:47 tove net-p2p/fms 2009-02-05 18:36:43 tommy app-admin/smolt 2009-02-05 21:24:36 bangert net-p2p/vuze-coreplugins2009-02-06 11:46:18 caster net-p2p/vuze2009-02-06 11:46:35 caster app-misc/pysmssend 2009-02-06 12:01:49 hwoarang sci-biology/snpfile 2009-02-07 18:16:12 weaver sci-biology/blossoc 2009-02-07 18:16:42 weaver app-arch/xz-utils 2009-02-07 20:32:22 vapier -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sys-kernel/hppa-sources,removed,jer,2009-02-06 03:14:44 profiles/default-linux/hppa,removed,jer,2009-02-06 05:40:23 net-p2p/azureus,removed,caster,2009-02-06 11:46:56 sys-apps/sysutils,removed,vapier,2009-02-08 20:08:12 Added Packages: app-arch/lzip,added,vapier,2009-02-02 19:28:05 net-p2p/freenet,added,tommy,2009-02-02 21:25:58 net-mail/Freemail,added,tommy,2009-02-02 21:28:43 dev-libs/liblinebreak,added,alexxy,2009-02-02 22:22:33 app-text/fbreader,added,alexxy,2009-02-02 22:28:07 games-board/pokerth,added,mr_bones_,2009-02-03 01:52:57 net-misc/ssvnc,added,vapier,2009-02-03 01:57:26 kde-misc/kopete-cryptography,added,alexxy,2009-02-03 10:51:25 kde-misc/skanlite,added,alexxy,2009-02-03 11:08:06 sci-libs/libticables2,added,bicatali,2009-02-03 14:47:38 sci-libs/libticalcs2,added,bicatali,2009-02-03 14:49:43 sci-libs/libticonv,added,bicatali,2009-02-03 14:51:03 sci-libs/libtifiles2,added,bicatali,2009-02-03 14:52:53 sci-calculators/tiemu,added,bicatali,2009-02-03 15:49:54 sci-calculators/tilp2,added,bicatali,2009-02-03 15:52:59 dev-python/aquarium,added,patrick,2009-02-03 19:19:09 dev-python/html5lib,added,patrick,2009-02-03 19:45:28 dev-python/pycipher,added,patrick,2009-02-03 19:55:22 dev-python/librharris,added,patrick,2009-02-03 20:07:22 dev-python/pyconstruct,added,patrick,2009-02-03 21:05:58 dev-python/arrayterator,added,patrick,2009-02-03 21:22:50 dev-python/pysvg,added,patrick,2009-02-03 22:06:12 dev-libs/distorm64,added,patrick,2009-02-03 23:12:38 dev-python/python-ptrace,added,patrick,2009-02-03 23:15:34 dev-java/jettison,added,betelgeuse,2009-02-05 00:22:59 java-virtuals/jaxp-virtual,added,betelgeuse,2009-02-05 00:34:14 sys-cluster/osc-mpiexec,added,jsbronder,2009-02-05 02:59:51 dev-perl/DateTime-Format-HTTP,added,tove,2009-02-05 14:02:47 net-p2p/fms,added,tommy,2009-02-05 18:36:43 app-admin/smolt,added,bangert,2009-02-05 21:24:36 net-p2p/vuze-coreplugins,added,caster,2009-02-06 11:46:18 net-p2p/vuze,added,caster,2009-02-06 11:46:35 app-misc/pysmssend,added,hwoarang,2009-02-06 12:01:49 sci-biology/snpfile,added,weaver,2009-02-07 18:16:12 sci-biology/blossoc,added,weaver,2009-02-07 18:16:42 app-ar
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 08 Feb 2009 15:27:54 -0800 > Zac Medico wrote: >>> Which is offset and more by the massive inconvenience of having to >>> keep track of and store junk under version control. >> I think you're making it out to be worse than it really is. Like I >> said, I think we have a justifiable exception to the rule. > > If you start encouraging this approach, are you prepared to make > Portage warn extremely noisily if a repository-provided (as opposed to > user generated) cache entry is found to be stale? Sure. Otherwise, it's confusing for the user when dependency calculations take longer than usual for no apparent reason. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPbV8ACgkQ/ejvha5XGaN24ACg9LFy8dag9/riCwODjknQV/Ic 0koAn00PP5WJBo5UwMR6iATwfFOipTi6 =sOk8 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 08 Feb 2009 15:27:54 -0800 Zac Medico wrote: > > Which is offset and more by the massive inconvenience of having to > > keep track of and store junk under version control. > > I think you're making it out to be worse than it really is. Like I > said, I think we have a justifiable exception to the rule. If you start encouraging this approach, are you prepared to make Portage warn extremely noisily if a repository-provided (as opposed to user generated) cache entry is found to be stale? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 08 Feb 2009 15:03:48 -0800 > Zac Medico wrote: >>> No, it's just encouraging bad development practices. >> It seems like you're making a rather arbitrary judgment. > > Not storing generated content under revision control is hardly an > arbitrary judgement. It's a well accepted software development bad > practice. In general, it's a good rule of thumb. However, in this case I think we have a justifiable exception to the rule. >>> If you're concerned that setting up an rsync mirror is difficult, >>> why not make a tool that generates a tarball, including metadata, >>> for a repo, and have people run that on a cron and distribute it >>> via http? That's just as easy to host, and anyone running an >>> overlay big enough to make this impractical already has the >>> resources to deal with rsync instead... >> I'm not saying that it necessarily "difficult" or "beyond the >> resources", but it does create an unnecessary burden. I think that >> it adds a significant level of convenience to be able to use a >> version control system as a single distribution channel. > > Which is offset and more by the massive inconvenience of having to > keep track of and store junk under version control. I think you're making it out to be worse than it really is. Like I said, I think we have a justifiable exception to the rule. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPankACgkQ/ejvha5XGaNpnQCfVHgDPmfzUbfH6mIgmpUxcWda xkYAoJ1s+DEd873rpRpDQkck6ZP7pclr =K88a -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 08 Feb 2009 15:03:48 -0800 Zac Medico wrote: > > No, it's just encouraging bad development practices. > > It seems like you're making a rather arbitrary judgment. Not storing generated content under revision control is hardly an arbitrary judgement. It's a well accepted software development bad practice. > > If you're concerned that setting up an rsync mirror is difficult, > > why not make a tool that generates a tarball, including metadata, > > for a repo, and have people run that on a cron and distribute it > > via http? That's just as easy to host, and anyone running an > > overlay big enough to make this impractical already has the > > resources to deal with rsync instead... > > I'm not saying that it necessarily "difficult" or "beyond the > resources", but it does create an unnecessary burden. I think that > it adds a significant level of convenience to be able to use a > version control system as a single distribution channel. Which is offset and more by the massive inconvenience of having to keep track of and store junk under version control. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 08 Feb 2009 14:43:01 -0800 > Zac Medico wrote: >>> Sticking metadata cache files under version control really is a >>> perfect example of doing it wrong... >> Well, if you want to use timestamps, the alternative is to >> distributors to use a protocol which preserves timestamps. This >> creates an unnecessary burden. Allowing distribution of metadata >> cache via version control systems is more flexible. > > No, it's just encouraging bad development practices. It seems like you're making a rather arbitrary judgment. > If you're concerned that setting up an rsync mirror is difficult, why > not make a tool that generates a tarball, including metadata, for a > repo, and have people run that on a cron and distribute it via http? > That's just as easy to host, and anyone running an overlay big enough > to make this impractical already has the resources to deal with rsync > instead... I'm not saying that it necessarily "difficult" or "beyond the resources", but it does create an unnecessary burden. I think that it adds a significant level of convenience to be able to use a version control system as a single distribution channel. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPZNMACgkQ/ejvha5XGaNqcgCg3GAWiklumvFhBtbWDYBPGz2+ u6IAoJ5eCaytti4FSmOHEtIrLSm10W4O =n0eG -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 08 Feb 2009 14:43:01 -0800 Zac Medico wrote: > > Sticking metadata cache files under version control really is a > > perfect example of doing it wrong... > > Well, if you want to use timestamps, the alternative is to > distributors to use a protocol which preserves timestamps. This > creates an unnecessary burden. Allowing distribution of metadata > cache via version control systems is more flexible. No, it's just encouraging bad development practices. If you're concerned that setting up an rsync mirror is difficult, why not make a tool that generates a tarball, including metadata, for a repo, and have people run that on a cron and distribute it via http? That's just as easy to host, and anyone running an overlay big enough to make this impractical already has the resources to deal with rsync instead... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sat, 07 Feb 2009 15:23:18 -0800 > Zac Medico wrote: >>> Well, usually you don't keep intermediate or generated files in a >>> VCS, so why the metadata? >> People who distribute overlays commonly ask if it's possible to >> distribute metadata cache with the overlay. Using a format that >> doesn't rely on timestamps will allow them to distribute metadata >> cache using their existing infrastructure, which is typically git or >> subversion. In addition to overlays, it would also be useful for >> forks of the entire gentoo tree, such as the funtoo tree [1]. > > Are these people really all going to remember to run some command at > the top level of the repository before every commit, and to git add the > relevant files for everything (thus making really messy commits)? The cache can be incrementally updated by a tool such as repoman, or it can be updated in periodic batches by a cron job. The periodic batch approach may be more convenient for eclass changes affect large numbers of ebuilds. > Sticking metadata cache files under version control really is a perfect > example of doing it wrong... Well, if you want to use timestamps, the alternative is to distributors to use a protocol which preserves timestamps. This creates an unnecessary burden. Allowing distribution of metadata cache via version control systems is more flexible. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPX/QACgkQ/ejvha5XGaMPewCeOZYsNt2bv+CbOV58aV7isq4f wCAAnA/10jcuad5NrP3BxyFZAYWH07ot =iRw3 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: > > I've always thought it would be cool to have user-created tag > clouds, del.icio.us-style, on packages.g.o. I expect this would be > a hell of a lot of work to set up however. initially, packages could be automatically tagges, based on the following criteria: - - category - - common* words found in $DESCRIPTION - - common* words found in metadata.xml: if any - - extend the above with description found on the net plus: - - a hidden tag to indicate that tags were assigned automatically, to be removed whenever the pkg tags are "reviewed" by a human += 2E-2 Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmPXfEACgkQV/B5axfzrPu46wCdFaTMWf4LSGCRHJJFB0xh0Vio yYwAn0siZ5oIaec3H2PfDEc6q/t02b6D =1Pjf -END PGP SIGNATURE-
[gentoo-dev] Re: Category tags on packages (was: new categories:)
On Sun, 08 Feb 2009 19:07:58 + Angelo Arrifano wrote: > I would keep existing categories and add a new TAG metadata to > existing ebuilds. Something like TAG="kde music player lyrics lastfm > visualization" for amarok, as example. > > A public list of *ALLOWED* tags would be published on our www > infrastructures. > > Then during the portage metadata regeneration process, a new tags dir > (under portage metadata dir) would be created with files for EACH tag. > Each tag file would include the fully qualified name for the ebuilds > in which the tag is present. > > This way, given a set of tags, it is easy and fast too lookup which > ebuilds match the given tags and how much (percentage) they match > them. > > For example: > The user searches for "music gnome lyrics" > > exaile is tagged as "(...) music gnome lyrics" > gnome-mplayer is tagged as "(...) music gnome" > amarok is tagged as "(...) music lyrics" > (...) > > So we can give an interest-ordered list to the user. > > Just my two cents, > Thanks all I've always thought it would be cool to have user-created tag clouds, del.icio.us-style, on packages.g.o. I expect this would be a hell of a lot of work to set up however. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sat, 07 Feb 2009 15:23:18 -0800 Zac Medico wrote: > > Well, usually you don't keep intermediate or generated files in a > > VCS, so why the metadata? > > People who distribute overlays commonly ask if it's possible to > distribute metadata cache with the overlay. Using a format that > doesn't rely on timestamps will allow them to distribute metadata > cache using their existing infrastructure, which is typically git or > subversion. In addition to overlays, it would also be useful for > forks of the entire gentoo tree, such as the funtoo tree [1]. Are these people really all going to remember to run some command at the top level of the repository before every commit, and to git add the relevant files for everything (thus making really messy commits)? Sticking metadata cache files under version control really is a perfect example of doing it wrong... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: > Am Sonntag, den 08.02.2009, 12:36 -0800 schrieb Zac Medico: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Tiziano Müller wrote: >>> But if your target is to reduce the size of the metadata cache, why >>> store the hashes of the eclasses in the ebuild's metadata and not in a >>> seperate dir? They have to be the same for every ebuild, don't they? >>> In case you have an average number of eclasses which is bigger than 4, >>> you can even store the full hash with less space used than with >>> truncated hashes for all eclasses. >> The problem with having eclass integrity data shared in a separate >> file is that it creates a requirement for all cache entries which >> reference the same eclasses to be consistent with one another. This >> means that a single cache entry can no longer be updated atomically. >> For example, before updating the shared eclass integrity data, you'd >> want to make sure that you first discard all of the cache entries >> which reference it. Although it can be done this way, I think it's >> much more convenient to have all of the integrity data encapsulated >> within each individual cache entry. > Ok, let me see if I get this: Since parts of the content of a > metadata-entry (like the DEPEND/RDEPEND vars) depend on the contents of > the eclass used by the time a cache entry got generated, you want to > store the eclass' hash in the ebuild entry to make sure the entry gets > invalidated once the eclass changes. Is that correct? Right. By having each cache entry encapsulate it's own integrity data, the program updating the cache is never required to update more than one file at a time. Having shared integrity data would imply that the program would have the burden of maintaining consistency across all cache entries. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPWTEACgkQ/ejvha5XGaOLHQCg0wGuRIkPCmQUQ2k14RjQlpv0 C54AoNqBaA6d3xyO6FuNz1GO7ZJ7y7E6 =D/ei -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: fox.eclass update
Hi,
shame on me, here i'm wondering why noone replies...
Sorry, i failed to send the updated patch o.O
Here's the patch again w/ your suggestions included.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- /usr/portage/eclass/fox.eclass 2008-10-12 14:36:35.0 +0200
+++ fox-proposed.eclass 2009-02-08 19:35:49.0 +0100
@@ -1,8 +1,12 @@
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
-# fox eclass
+# @ECLASS: fox.eclass
+# @MAINTAINER: m...@gentoo.org
+# @BLURB: Common build and install functions for fox-related apps and library
+# @DESCRIPTION: Used by the x11-libs/fox library and all applications that come
+# with the upstream source tarball.
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
@@ -19,26 +23,22 @@
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
-# Here are sample [R]DEPENDs for the fox apps
-# fox versions that do not use this eclass are blocked in INCOMPAT_DEP below
-# 1.0: '=x11-libs/fox-1.0*'
-# 1.2: '=x11-libs/fox-1.2*'
+# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
+#
+# @EXAMPLE: Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
-#
-# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
-inherit eutils libtool versionator
+# could probably be lower
+WANT_AUTOCONF="latest"
+WANT_AUTOMAKE="latest"
+inherit autotools eutils libtool versionator
FOX_PV="${FOX_PV:-${PV}}"
-PVP=(${FOX_PV//[-\._]/ })
-FOXVER="${PVP[0]}.${PVP[1]}"
-
-if [ "${FOXVER}" != "1.0" ] ; then
- FOXVER_SUFFIX="-${FOXVER}"
-fi
+FOXVER=$(get_version_component_range 1-2)
+FOXVER_SUFFIX="-${FOXVER}"
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
@@ -46,44 +46,28 @@
IUSE="debug doc profile"
-# from fox-1.0
-FOX_APPS="adie calculator pathfinder"
-# from fox-1.2+
-if [ "${FOXVER}" != "1.0" ] ; then
- FOX_APPS="${FOX_APPS} shutterbug"
- FOX_CHART="chart"
-fi
+# @ECLASS-VARIABLE: FOX_APPS
+# @DESCRIPTION: all applications that come with the fox toolkit source
+FOX_APPS="adie calculator pathfinder shutterbug chart"
if [ "${PN}" != fox ] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
-if [ "${FOXVER}" != "1.0" ] && [ -z "${FOX_COMPONENT}" ] ; then
- DOXYGEN_DEP="doc? ( app-doc/doxygen )"
-fi
-
if [ "${PN}" != reswrap ] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
-# These versions are not compatible with new fox layout
-# and will cause collissions - we need to block them
-INCOMPAT_DEP="!=sys-devel/automake-1.4
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
- cd ${S}
+ cd "${S}"
ebegin "Fixing configure"
@@ -103,14 +87,14 @@
done
# use the installed reswrap for everything else
- for d in ${FOX_APPS} ${FOX_CHART} tests ; do
+ for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
- if version_is_at_least "1.6.34" ${PV} ; then
+ if version_is_at_least "1.6.34" ${PV}; then
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
@@ -124,19 +108,13 @@
${d}/Makefile.am || die "sed ${d}/Makefile.am
error"
fi
done
-
- # Upstream often has trouble with version number transitions
- if [ "${FOXVER}" == "1.5" ] ; then
- sed -i -e 's:1.4:1.5:g' chart/Makefile.am
- fi
-
eend
ebegin "Running automake"
- automake-1.4 -a -c || die "automake error"
+ eautomake || die "automake error"
eend
- elibtoolize
+ #elibtoolize
}
fox_src_compile() {
@@ -150,21 +128,21 @@
$(use_with profile profiling) \
|| die "configure error"
- cd ${S}/${FOX_COMPONENT}
+ cd "${S}/${FOX_COMPONENT}"
emake || die "compile error"
# build class reference docs (FOXVER >= 1.2)
- if use doc && [ "${FOXVER}" != "1.0" ] && [ -z "${FOX_COMPONENT}" ] ;
then
- cd ${S}/doc
[gentoo-dev] Devaway for me, for a whole year period(military service)
Hi fellow devs and users, As some of you may already know, I won't be around this year, cause I have to join the greek army, starting from tomorrow morning. Feel free to touch my ebuilds. I will be in contact (via mail) with Marijn Schouten (hkBst) in case you want to hear any news of me. Keep up the great work, all of you, and don't break anything, cause I will have very little time when I'll be back home, to update the "worlds of my machinery" :P ps: I have left an open screen session running irssi, on a remote machine, so you will see me online, but I'll be far away, probably :( -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpkCRknmK3W1.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Am Sonntag, den 08.02.2009, 12:36 -0800 schrieb Zac Medico: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tiziano Müller wrote: > > Am Sonntag, den 08.02.2009, 00:59 -0800 schrieb Zac Medico: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Tiziano Müller wrote: > >>> Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tiziano Müller wrote: > > Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico: > I like that idea. That way it's not necessary to bump the EAPI in > order to change the hash function. So, a typical DIGESTS value might > look like this: > > You still have to bump the EAPI in case you want to use a new hash not > > already available now (like SHA-3). The advantage of noting the used > > hash is that new PMs can handle old metadata cache. > > That's true. > > SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 > >>> Sleeping over it again I don't think that truncating a hash is a good > >>> idea (truncating it from 40 to 10 digits makes the possibility of > >>> collisions much much higher). > >> The probability of collision is much higher, but it's still > >> relatively small. Given the "avalanche effect" that is typical of > >> cryptographic hash functions, it's extremely unlikely that collision > >> will occur in such a way that it will cause a problem for cache > >> validation. > > The "avalanche effect" as I understood it is required for a hash > > function to avoid simple calculations of collisions (what the diffusion > > is for crypto algorithms). So, small changes should affect as many > > numbers in the hash as possible. But you don't have only small changes > > here in case somebody patches an eclass, so, the only thing which counts > > is the probability of a collision. > > Well, the avalanche effect helps in the sense that the leftmost 10 > digits would serve approximately as well as any other 10 digits out > of all of them. But you're right about the probability of a > collision being what really matters. With 10 hex digits, we've got a > space of 16^10 = 1.1e12 possible combinations. Given a space that > large, the probability of a collision pretty small. > > >>> But if you want to go this way, I'd say you should use something like > >>> SHA1t (t for truncated) to make sure we can use full hashes once we feel > >>> it's appropriate. > >> We could, but I think SHA1 would also be fine since one can infer > >> from the length of the string that it's been truncated. > > No, guessing is a bad thing here because it could be truncated because > > of faulty metadata. But the main motivation is that if you write SHA1 > > everyone reading it expects it to be a full SHA1 hash, which it isn't. > > Well, if the metadata is faulty then the digests are unlikely to > match and the cache will be discarded anyway as invalid. However, I > think your point is still somewhat valid, so SHA1t is fine with me > if that makes more people happy. Does anyone else have a preference > here? > > > But if your target is to reduce the size of the metadata cache, why > > store the hashes of the eclasses in the ebuild's metadata and not in a > > seperate dir? They have to be the same for every ebuild, don't they? > > In case you have an average number of eclasses which is bigger than 4, > > you can even store the full hash with less space used than with > > truncated hashes for all eclasses. > > The problem with having eclass integrity data shared in a separate > file is that it creates a requirement for all cache entries which > reference the same eclasses to be consistent with one another. This > means that a single cache entry can no longer be updated atomically. > For example, before updating the shared eclass integrity data, you'd > want to make sure that you first discard all of the cache entries > which reference it. Although it can be done this way, I think it's > much more convenient to have all of the integrity data encapsulated > within each individual cache entry. Ok, let me see if I get this: Since parts of the content of a metadata-entry (like the DEPEND/RDEPEND vars) depend on the contents of the eclass used by the time a cache entry got generated, you want to store the eclass' hash in the ebuild entry to make sure the entry gets invalidated once the eclass changes. Is that correct? -- --- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
Angelo Arrifano wrote:
>
> [ -z "${GPE_MIRROR}" ] &&
> GPE_MIRROR="http://gpe.linuxtogo.org/download/source";
> [ -z "${GPE_TARBALL_SUFFIX}" ] && GPE_TARBALL_SUFFIX="gz"
> SRC_URI="${GPE_MIRROR}/${P}.tar.${GPE_TARBALL_SUFFIX}"
>
Use [[ here.
>
> # @FUNCTION: gpe_src_compile
> # @DESCRIPTION: (Cross-)Compiles a GPE package.
> gpe_src_compile() {
> tc-export CC
> has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
> # miknix: Code belo must NOT die, some packages dont really build
> anything,
> # just install.
> emake PREFIX=/usr
> }
>
The packages that don't build anything can do:
src_compile() { :; } or you can have a variable for skipping the build
step.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: > Am Sonntag, den 08.02.2009, 00:59 -0800 schrieb Zac Medico: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Tiziano Müller wrote: >>> Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: > Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico: I like that idea. That way it's not necessary to bump the EAPI in order to change the hash function. So, a typical DIGESTS value might look like this: > You still have to bump the EAPI in case you want to use a new hash not > already available now (like SHA-3). The advantage of noting the used > hash is that new PMs can handle old metadata cache. That's true. SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 >>> Sleeping over it again I don't think that truncating a hash is a good >>> idea (truncating it from 40 to 10 digits makes the possibility of >>> collisions much much higher). >> The probability of collision is much higher, but it's still >> relatively small. Given the "avalanche effect" that is typical of >> cryptographic hash functions, it's extremely unlikely that collision >> will occur in such a way that it will cause a problem for cache >> validation. > The "avalanche effect" as I understood it is required for a hash > function to avoid simple calculations of collisions (what the diffusion > is for crypto algorithms). So, small changes should affect as many > numbers in the hash as possible. But you don't have only small changes > here in case somebody patches an eclass, so, the only thing which counts > is the probability of a collision. Well, the avalanche effect helps in the sense that the leftmost 10 digits would serve approximately as well as any other 10 digits out of all of them. But you're right about the probability of a collision being what really matters. With 10 hex digits, we've got a space of 16^10 = 1.1e12 possible combinations. Given a space that large, the probability of a collision pretty small. >>> But if you want to go this way, I'd say you should use something like >>> SHA1t (t for truncated) to make sure we can use full hashes once we feel >>> it's appropriate. >> We could, but I think SHA1 would also be fine since one can infer >> from the length of the string that it's been truncated. > No, guessing is a bad thing here because it could be truncated because > of faulty metadata. But the main motivation is that if you write SHA1 > everyone reading it expects it to be a full SHA1 hash, which it isn't. Well, if the metadata is faulty then the digests are unlikely to match and the cache will be discarded anyway as invalid. However, I think your point is still somewhat valid, so SHA1t is fine with me if that makes more people happy. Does anyone else have a preference here? > But if your target is to reduce the size of the metadata cache, why > store the hashes of the eclasses in the ebuild's metadata and not in a > seperate dir? They have to be the same for every ebuild, don't they? > In case you have an average number of eclasses which is bigger than 4, > you can even store the full hash with less space used than with > truncated hashes for all eclasses. The problem with having eclass integrity data shared in a separate file is that it creates a requirement for all cache entries which reference the same eclasses to be consistent with one another. This means that a single cache entry can no longer be updated atomically. For example, before updating the shared eclass integrity data, you'd want to make sure that you first discard all of the cache entries which reference it. Although it can be done this way, I think it's much more convenient to have all of the integrity data encapsulated within each individual cache entry. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPQjkACgkQ/ejvha5XGaNFUACfQvVYgNiZNK8PVReTZKN47wQU 9wkAniltb1ivZYGgmhn/eli2fpprkOlI =2mbq -END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
Le 08/02/2009 20:07, Angelo Arrifano a écrit : I would keep existing categories and add a new TAG metadata to existing ebuilds. Something like TAG="kde music player lyrics lastfm visualization" for amarok, as example. If anything, this sort of extra information should go to metadata.xml. Cheers, Rémi
Re: [gentoo-dev] Category tags on packages (was: new categories:)
I would keep existing categories and add a new TAG metadata to existing ebuilds. Something like TAG="kde music player lyrics lastfm visualization" for amarok, as example. A public list of *ALLOWED* tags would be published on our www infrastructures. Then during the portage metadata regeneration process, a new tags dir (under portage metadata dir) would be created with files for EACH tag. Each tag file would include the fully qualified name for the ebuilds in which the tag is present. This way, given a set of tags, it is easy and fast too lookup which ebuilds match the given tags and how much (percentage) they match them. For example: The user searches for "music gnome lyrics" exaile is tagged as "(...) music gnome lyrics" gnome-mplayer is tagged as "(...) music gnome" amarok is tagged as "(...) music lyrics" (...) So we can give an interest-ordered list to the user. Just my two cents, Thanks all -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer
Re: [gentoo-dev] Category tags on packages (was: new categories:)
Am Sonntag, den 08.02.2009, 18:59 +0100 schrieb Federico Ferri:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Nirbheek Chauhan wrote:
> > ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
> > ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
> ../../../../kde-base/ksudoku
> > ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok
>
> - --
>
> I like the tag idea.
> I don't like tag as described above.
> I feel having tags organized in hierarchical way is inappropriate.
> that just makes another organization of packages in categories.
>
> tags <-> packages is a many-to-many relation.
>
>
>
> btw, if the DESCRIPTION field is well written, it functions as a tag.
Please, don't.
> e.g.:
>
> $ eix -c -S dockapp -S net
> [N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU,
> Net, Power, df, seti
> [N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network
> interfaces.
> [N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet
> connections to and from your computer.
> [N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time,
> date, and internet time
> [N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp)
> [N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp
> [N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp
> Found 7 matches.
>
> although DESCRIPTION doesn't contain "obvious" tags.
> perhaps it's worth the addition of a TAGS field (?) that has to be
> searched just like DESCRIPTION
It's metadata-stuff, why not put it there?
You have two possibilities:
a) Introduce new elements:
foo
bar
b) Think of herds as tags, then you have many packages already tagged.
To be able to add new herds/tags without messing up with the
maintainer-info, I'd then introduce new attributes for and
instead of writing foo meaning that a package is maintainer
by team "foo" just write foo
instead.
Then you can use the "herd" element in metadata.xml freely as a tag.
Cheers,
Tiziano
--
---
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Category tags on packages (was: new categories:)
Am Sonntag, den 08.02.2009, 23:41 +0530 schrieb Nirbheek Chauhan: > On Sun, Feb 8, 2009 at 11:40 PM, Nirbheek Chauhan > wrote: > > On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri > > wrote: > >> tags <-> packages is a many-to-many relation. > > > > Aren't tags _made_ to be many-to-many? > > ie, symlinking can allow that kind of relationship > No, symlinking sucks for various reasons. Here are some: - filesystem access is slow - moving packages from one category to another gets even worse because you have to check for deadlinks - you have to check for deadlinks anyway because people forget to remove them when removing packages - good luck with that on Gentoo/Prefix-Interix -- --- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nirbheek Chauhan wrote:
>> I like the tag idea. I don't like tag as described above. I feel
>> having tags organized in hierarchical way is inappropriate. that
>> just makes another organization of packages in categories.
>
> KDE and OLPC are looking towards hierarchical tags as the future of
> content management. People don't really use folders, they use
> tags:
>
> "Holidays" > "2008" > "Switzerland" "Open Source" > "Gentoo" >
> "portage"
>
the above looks exactly like folders (unless you elaborate on that)
I don't know what KDE or OLPC are thinking. when I tag my stuff I'd
probably have:
photo001.jpg {2008,holidays,nature,switzerland}
photo002.jpg {2008,holidays,fun,switzerland,zurich}
photo158.jpg {2009,computer,me,misc}
(the order of tags here is alphabetical)
> tags <-> packages is a many-to-many relation.
>>
>> Aren't tags _made_ to be many-to-many?
>
> ie, symlinking can allow that kind of relationship
can you show an example (of many-2-many relation, with symlinks)?
Federico Ferri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmPJHsACgkQV/B5axfzrPtbpACfcq8qpQdkneWplS8H3XgEiry1
1qUAoKZcMUGDyro8nHwrSvNwflm0nyGn
=PV0+
-END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
On Sun, Feb 8, 2009 at 11:40 PM, Nirbheek Chauhan wrote: > On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri wrote: >> tags <-> packages is a many-to-many relation. > > Aren't tags _made_ to be many-to-many? ie, symlinking can allow that kind of relationship -- ~Nirbheek Chauhan
Re: [gentoo-dev] Category tags on packages (was: new categories:)
On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Nirbheek Chauhan wrote:
>> ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
>> ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
> ../../../../kde-base/ksudoku
>> ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok
>
> - --
>
> I like the tag idea.
> I don't like tag as described above.
> I feel having tags organized in hierarchical way is inappropriate.
> that just makes another organization of packages in categories.
KDE and OLPC are looking towards hierarchical tags as the future of
content management. People don't really use folders, they use tags:
"Holidays" > "2008" > "Switzerland"
"Open Source" > "Gentoo" > "portage"
>
> tags <-> packages is a many-to-many relation.
Aren't tags _made_ to be many-to-many?
--
~Nirbheek Chauhan
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nirbheek Chauhan wrote:
> ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
> ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
../../../../kde-base/ksudoku
> ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok
- --
I like the tag idea.
I don't like tag as described above.
I feel having tags organized in hierarchical way is inappropriate.
that just makes another organization of packages in categories.
tags <-> packages is a many-to-many relation.
btw, if the DESCRIPTION field is well written, it functions as a tag.
e.g.:
$ eix -c -S dockapp -S net
[N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU,
Net, Power, df, seti
[N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network
interfaces.
[N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet
connections to and from your computer.
[N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time,
date, and internet time
[N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp)
[N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp
[N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp
Found 7 matches.
although DESCRIPTION doesn't contain "obvious" tags.
perhaps it's worth the addition of a TAGS field (?) that has to be
searched just like DESCRIPTION
just my 2E-2
Federico Ferri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmPHZIACgkQV/B5axfzrPu9ewCgr2XRqbTy9XycR5g0KeFWtOnV
ou8An2WKDEeIsPioWHn/lVEtPrHF4QNg
=GvLh
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Am Sonntag, den 08.02.2009, 00:59 -0800 schrieb Zac Medico:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tiziano Müller wrote:
> > Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Tiziano Müller wrote:
> >>> Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico:
> For the digest format, I suggest that we use the leftmost 10
> hexadecimal digits of the SHA-1 digest. The rationale for limiting
> it to 10 digits (out of 40) is to save space. Due to the avalanche
> effect [2], 10 digits should be sufficient to ensure that problems
> resulting from hash collisions are extremely unlikely.
> >>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
> >>> passwords) to be able to change the digest algorithm as needed
> >>> (especially in regards to the current SHA successor competition).
> >>> This allows a future package manager which might use SHA-3 for hashing
> >>> (once it's released) to still check old digests. Furthermore it would
> >>> allow for easier transition and only needs a definition of allowed
> >>> hashes instead of a specific one.
> >> I like that idea. That way it's not necessary to bump the EAPI in
> >> order to change the hash function. So, a typical DIGESTS value might
> >> look like this:
You still have to bump the EAPI in case you want to use a new hash not
already available now (like SHA-3). The advantage of noting the used
hash is that new PMs can handle old metadata cache.
> >>
> >> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
> >
> > Sleeping over it again I don't think that truncating a hash is a good
> > idea (truncating it from 40 to 10 digits makes the possibility of
> > collisions much much higher).
>
> The probability of collision is much higher, but it's still
> relatively small. Given the "avalanche effect" that is typical of
> cryptographic hash functions, it's extremely unlikely that collision
> will occur in such a way that it will cause a problem for cache
> validation.
The "avalanche effect" as I understood it is required for a hash
function to avoid simple calculations of collisions (what the diffusion
is for crypto algorithms). So, small changes should affect as many
numbers in the hash as possible. But you don't have only small changes
here in case somebody patches an eclass, so, the only thing which counts
is the probability of a collision.
>
> > But if you want to go this way, I'd say you should use something like
> > SHA1t (t for truncated) to make sure we can use full hashes once we feel
> > it's appropriate.
>
> We could, but I think SHA1 would also be fine since one can infer
> from the length of the string that it's been truncated.
No, guessing is a bad thing here because it could be truncated because
of faulty metadata. But the main motivation is that if you write SHA1
everyone reading it expects it to be a full SHA1 hash, which it isn't.
But if your target is to reduce the size of the metadata cache, why
store the hashes of the eclasses in the ebuild's metadata and not in a
seperate dir? They have to be the same for every ebuild, don't they?
In case you have an average number of eclasses which is bigger than 4,
you can even store the full hash with less space used than with
truncated hashes for all eclasses.
--
---
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tiziano Müller wrote:
> Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Tiziano Müller wrote:
>>> Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico:
For the digest format, I suggest that we use the leftmost 10
hexadecimal digits of the SHA-1 digest. The rationale for limiting
it to 10 digits (out of 40) is to save space. Due to the avalanche
effect [2], 10 digits should be sufficient to ensure that problems
resulting from hash collisions are extremely unlikely.
>>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
>>> passwords) to be able to change the digest algorithm as needed
>>> (especially in regards to the current SHA successor competition).
>>> This allows a future package manager which might use SHA-3 for hashing
>>> (once it's released) to still check old digests. Furthermore it would
>>> allow for easier transition and only needs a definition of allowed
>>> hashes instead of a specific one.
>> I like that idea. That way it's not necessary to bump the EAPI in
>> order to change the hash function. So, a typical DIGESTS value might
>> look like this:
>>
>> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
>
> Sleeping over it again I don't think that truncating a hash is a good
> idea (truncating it from 40 to 10 digits makes the possibility of
> collisions much much higher).
The probability of collision is much higher, but it's still
relatively small. Given the "avalanche effect" that is typical of
cryptographic hash functions, it's extremely unlikely that collision
will occur in such a way that it will cause a problem for cache
validation.
> But if you want to go this way, I'd say you should use something like
> SHA1t (t for truncated) to make sure we can use full hashes once we feel
> it's appropriate.
We could, but I think SHA1 would also be fine since one can infer
from the length of the string that it's been truncated.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmOnvwACgkQ/ejvha5XGaPtSACeOS21UYlvkMQy5q86B+9aKHpH
DnUAoK1P83uKFEd2uzfc2t+QhArMHeEZ
=jPpV
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tiziano Müller wrote:
> > Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico:
> >> For the digest format, I suggest that we use the leftmost 10
> >> hexadecimal digits of the SHA-1 digest. The rationale for limiting
> >> it to 10 digits (out of 40) is to save space. Due to the avalanche
> >> effect [2], 10 digits should be sufficient to ensure that problems
> >> resulting from hash collisions are extremely unlikely.
> > I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
> > passwords) to be able to change the digest algorithm as needed
> > (especially in regards to the current SHA successor competition).
> > This allows a future package manager which might use SHA-3 for hashing
> > (once it's released) to still check old digests. Furthermore it would
> > allow for easier transition and only needs a definition of allowed
> > hashes instead of a specific one.
>
> I like that idea. That way it's not necessary to bump the EAPI in
> order to change the hash function. So, a typical DIGESTS value might
> look like this:
>
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
Sleeping over it again I don't think that truncating a hash is a good
idea (truncating it from 40 to 10 digits makes the possibility of
collisions much much higher).
But if you want to go this way, I'd say you should use something like
SHA1t (t for truncated) to make sure we can use full hashes once we feel
it's appropriate.
--
---
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
