Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi! On Mon, 02 Feb 2009, Tobias Klausmann wrote: If it works, I'll test drive it for a while and report back. I've been running a patched glibc-2.9_p20081201-r1 for a week now. Nothing broke and I've been unable to trigger the lost packet syndrome by using getaddrinfo(). I was still able to produce it by sending UDP packets myself, but that was to be expected. So in essence, the patch I mentioned works. We could use it should we want to have a glibc 2.9. On the bug mentioned earlier (where I got the patch from), one of the glibc guys mentions that more work is planned for the resolver part of glibc, so this whole ordeal may pass us. Regards, Tobias -- printk(NONONONOO\n); linux-2.6.6/drivers/atm/zatm.c
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Zac Medico wrote: Ciaran McCreesh wrote: On Sun, 08 Feb 2009 15:27:54 -0800 Zac Medico zmed...@gentoo.org 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. It would probably be useful to provide a central rsync infra for overlays where overlay maintainers could subscribe their overlays to and the machine would pull in their VCS and generate the metadata for them. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Mon, 09 Feb 2009 14:30:58 +0200 Petteri Räty betelge...@gentoo.org wrote: It would probably be useful to provide a central rsync infra for overlays where overlay maintainers could subscribe their overlays to and the machine would pull in their VCS and generate the metadata for them. How much do you trust overlay maintainers? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Ciaran McCreesh wrote: On Mon, 09 Feb 2009 14:30:58 +0200 Petteri Räty betelge...@gentoo.org wrote: It would probably be useful to provide a central rsync infra for overlays where overlay maintainers could subscribe their overlays to and the machine would pull in their VCS and generate the metadata for them. How much do you trust overlay maintainers? It shouldn't be that hard to sandbox the overlays for cache generation. Trust should be much more of an issue to people actually installing stuff from overlays. Adding new overlays to the server would probably have to be manual. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Mon, 09 Feb 2009 16:15:55 +0200 Petteri Räty betelge...@gentoo.org wrote: How much do you trust overlay maintainers? It shouldn't be that hard to sandbox the overlays for cache generation. Uh. Really? I'd be interested to see how you plan to pull that one off. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Petteri Räty a écrit : Ciaran McCreesh wrote: On Mon, 09 Feb 2009 14:30:58 +0200 Petteri Räty betelge...@gentoo.org wrote: It would probably be useful to provide a central rsync infra for overlays where overlay maintainers could subscribe their overlays to and the machine would pull in their VCS and generate the metadata for them. How much do you trust overlay maintainers? It shouldn't be that hard to sandbox the overlays for cache generation. Trust should be much more of an issue to people actually installing stuff from overlays. Adding new overlays to the server would probably have to be manual. I can't possibly be the *only* one to think that the ideas in this thread are getting out of hand as far as complexity is concerned. Seriously, let's try to do simpler things that most developers can understand. Cheers, Rémi
Re: [gentoo-dev] RFC: fox.eclass update
В Вск, 08/02/2009 в 23:06 +0100, Matti Bickel пишет: +# could probably be lower +WANT_AUTOCONF=latest +WANT_AUTOMAKE=latest These are defaults. You don't need to specify them. + eautomake || die automake error eautomake dies on its own. You don't need || die here. -- Peter.
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
The primary reason to use a digest for cache validation instead of a
timestamp is that it allows the cache validation mechanism to work
even if the tree is distributed with a protocol that does not
preserve timestamps, such as git or subversion. This would make it
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].
[1] http://github.com/funtoo/portage/tree/master
Ok, after having the technical details discussed, I'd like to know which
overlays or trees could really make use of it.
Because small overlays surely won't generate the metadata because it is
cumbersome to generate the metadata and isn't really a speed issue.
Most larger overlays/repositories will probably be able to setup rsync
or implement a procedure using cron+tarball.
So, who exactly is asking about being able to distribute the metadata
cache via a VCS?
--
---
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] Race condition in Netfilter triggered by glibc 2.9
On Monday 09 February 2009 04:33:54 Tobias Klausmann wrote: On Mon, 02 Feb 2009, Tobias Klausmann wrote: If it works, I'll test drive it for a while and report back. I've been running a patched glibc-2.9_p20081201-r1 for a week now. Nothing broke and I've been unable to trigger the lost packet syndrome by using getaddrinfo(). I was still able to produce it by sending UDP packets myself, but that was to be expected. So in essence, the patch I mentioned works. We could use it should we want to have a glibc 2.9. On the bug mentioned earlier (where I got the patch from), one of the glibc guys mentions that more work is planned for the resolver part of glibc, so this whole ordeal may pass us. that patch is already in the glibc patchset, i just havent released it yet. guess i could do that this weekend. -mike
Re: [gentoo-dev] midnight commander - which screen library
On Friday 30 January 2009 08:42:24 Enrico Weigelt wrote: @mc.o (*1) we're currently discussing which screen library to keep. Either ncurses or slang will be dropped (bundled slang will anyway) Both have their pros and cons, so we haven't decided yet. considering ncurses is available on every distro by default, it's kind of a no brainer. no one includes slang out of the box. -mike
Re: [gentoo-dev] RFC: fox.eclass update
Peter Volkov p...@gentoo.org wrote:
В Вск, 08/02/2009 в 23:06 +0100, Matti Bickel пишет:
+# could probably be lower
+WANT_AUTOCONF=latest
+WANT_AUTOMAKE=latest
These are defaults. You don't need to specify them.
+ eautomake || die automake error
eautomake dies on its own. You don't need || die here.
Thanks for the comments, WANT_AUTO* was specified to make some previous
commenter happy, but removed now ;)
Where was that 'which functions || die on their own' table, anyway?
--
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-09 19:21:03.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,18 @@
# 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
+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 +42,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=!x11-libs/fox-1.0.53
- !=x11-libs/fox-1.2.4
- !~x11-libs/fox-1.2.6
- !=x11-libs/fox-1.4.11
-
-DEPEND=${INCOMPAT_DEP}
- ${DOXYGEN_DEP}
- ${RESWRAP_DEP}
- =sys-devel/automake-1.4*
+DEPEND=${RESWRAP_DEP}
+ doc? ( app-doc/doxygen )
+ =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 +83,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 +104,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
eend
-
[gentoo-dev] Re: midnight commander - which screen library
Enrico Weigelt wrote: Hi folks, @mc.o (*1) we're currently discussing which screen library to keep. Either ncurses or slang will be dropped (bundled slang will anyway) Both have their pros and cons, so we haven't decided yet. What do you suggest, which screen library to keep ? BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good.
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 08 Feb 2009 14:43:01 -0800 Zac Medico zmed...@gentoo.org wrote: 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. Ok, if we're going to encourage this, let's do it properly: * Have a branch called 'master'. Commit to it. Don't stick any metadata in it. * Have a branch called 'master-with-metadata'. Don't commit to it manually. * Have a script that merges master to master-with-metadata, and as part of the merge commit, generates all necessary metadata for the range it's merging. * Store either the partial hash or the owning repository and timestamp of each eclass used by an ebuild in its metadata. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: midnight commander - which screen library
On Monday 09 February 2009 13:32:24 Nikos Chantziaras wrote: Enrico Weigelt wrote: @mc.o (*1) we're currently discussing which screen library to keep. Either ncurses or slang will be dropped (bundled slang will anyway) Both have their pros and cons, so we haven't decided yet. What do you suggest, which screen library to keep ? BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good. that doesnt make any sense. both ncurses and slang work just fine with and without unicode. i dont think he was asking about Gentoo anyways ... he was asking about upstream mc. the proper string under Gentoo would be: ncurses? ( unicode? ( sys-libs/ncurses[unicode] ) !unicode? ( sys-libs/ncurses ) ) !ncurses? ( slang? ( =sys-libs/slang-2.1.3 ) ) -mike
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
The primary reason to use a digest for cache validation instead of a
timestamp is that it allows the cache validation mechanism to work
even if the tree is distributed with a protocol that does not
preserve timestamps, such as git or subversion. This would make it
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].
[1] http://github.com/funtoo/portage/tree/master
Ok, after having the technical details discussed, I'd like to know which
overlays or trees could really make use of it.
Because small overlays surely won't generate the metadata because it is
cumbersome to generate the metadata and isn't really a speed issue.
Most larger overlays/repositories will probably be able to setup rsync
or implement a procedure using cron+tarball.
So, who exactly is asking about being able to distribute the metadata
cache via a VCS?
All that I can say right now is that I recall questions about it in
the past from overlay maintainers (I don't have a list) and the
funtoo project is the only one which I can name offhand.
However, the ability to distribute cache via a vcs is only an
ancillary feature which is made possible by the DIGESTS data. The
DIGESTS data is useful regardless of the protocol that is used to
distribute the cache, since it allows the cache to be properly
validated for integrity. So, the real primary reason for introducing
the DIGESTS data is to provide a proper solution for cases like bug
#139134 [1] in which invalid metadata cache goes undetected.
[1] http://bugs.gentoo.org/show_bug.cgi?id=139134
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmQijwACgkQ/ejvha5XGaM2gQCguhueRSzVSr6GlFpTW6uutJ9p
mAQAoJ5LOuU9kl8wXEF3qzF5XFa2LdmH
=DTgz
-END 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 zmed...@gentoo.org wrote: 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. Ok, if we're going to encourage this, let's do it properly: * Have a branch called 'master'. Commit to it. Don't stick any metadata in it. * Have a branch called 'master-with-metadata'. Don't commit to it manually. * Have a script that merges master to master-with-metadata, and as part of the merge commit, generates all necessary metadata for the range it's merging. Yes, that's how I imagine it should be done. * Store either the partial hash or the owning repository and timestamp of each eclass used by an ebuild in its metadata. I think the partial hash is plenty of information since the package manager still needs some other way to resolve the eclass paths in order to generate the cache in the first place. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmQi+oACgkQ/ejvha5XGaNrkACg2l+CndFMKHPEx3vtw0FhohRz i5MAnA/usLTUHsSD5y0QZx8tY91sfdau =ya5w -END PGP SIGNATURE-
[gentoo-dev] KDE Team meeting for february (12.2.2009 20.00:00)
Heya, time has reach for us that we have to meet again, so interesting stuff for this time: electing a team lead (i suggest jmbsvicetto or yngwin :]) chit-chat about kde3 planning cooperation with debian and other normal distros (that dont insanely patch the kde) talking with upstream about the f#$*# svn version in their snapshots helping upstream with spliting packages and updating the splits in overlay acording to the output kde4 build system modifications we would like to see (more versions in one prefix). // hope i didnt forget anything Well as usual the meeting is mandatory so please come and help us improve the kde :] (this is ment also for HTs and padavans on them :P) Ok at last but not least when and where: WHEN: 12.2.2009 20.00 UTC (jorge cant sooner so we are moving the time bit) WHERE: #gentoo-...@freenode Anybody whom has something to say at these point is free to come and chat with us. Also if you have something not listed here and you think we should work/help with, come please along. Regards Tomas Chvatal KDE Herd Testers Lead PS: i nominate jorge (jmbsvicetto) if he forget to sent his application :P signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: midnight commander - which screen library
Mike Frysinger wrote: On Monday 09 February 2009 13:32:24 Nikos Chantziaras wrote: BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good. that doesnt make any sense. both ncurses and slang work just fine with and without unicode. MC doesn't. A patch adds Unicode to MC. It's for slang only. Anyway, I just saw that there's a new patch listed in MC's homepage that seems to add Unicode. I suppose Gentoo will switch to that and drop the current slang patch.
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Zac Medico wrote: Ciaran McCreesh wrote: On Sun, 08 Feb 2009 15:27:54 -0800 Zac Medico zmed...@gentoo.org 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. It would probably be useful to provide a central rsync infra for overlays where overlay maintainers could subscribe their overlays to and the machine would pull in their VCS and generate the metadata for them. That's fine if somebody wants to implement it. The introduction of DIGESTS data in the metadata cache does not preclude it. Like I just said in another reply [1], the ability to distribute cache via a vcs is only an ancillary feature which is made possible by the DIGESTS data. [1] http://archives.gentoo.org/gentoo-dev/msg_760e199e74796fed7e56236f248efe9e.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmQj+UACgkQ/ejvha5XGaOajACePIoV6STCE/bh7SB8X/ch4phk bpAAnjsYR9UgBVP26wIldvCX2OFNe4yy =kYc/ -END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
On Sunday 08 of February 2009 19:51:29 Tiziano Müller wrote: It's metadata-stuff, why not put it there? You have two possibilities: a) Introduce new elements: tags tagfoo/tag tagbar/tag /tags 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 maintainer and instead of writing herdfoo/herd meaning that a package is maintainer by team foo just write maintainer type=teamfoo/maintainer instead. Then you can use the herd element in metadata.xml freely as a tag. That's basically exactly what I've proposed, I'd just add (possibly optional) weight or relevance of tag as well, for example: tags tagfoo/tag !-- some less relevant tag -- tag weight=0.5bar/tag /tags as one cannot forget that tag search is *vector*, not binary search - so there are more possibilities to explore. Btw, too bad, metadat XML schema is written in DTD and not in some easier to read more expressive way - like RelaxNG. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] KDE Team meeting for february (12.2.2009 20.00:00)
Perfect timing for me as well! On Mon, Feb 9, 2009 at 9:23 PM, Tomáš Chvátal scarab...@gentoo.org wrote: Heya, time has reach for us that we have to meet again, so interesting stuff for this time: electing a team lead (i suggest jmbsvicetto or yngwin :]) chit-chat about kde3 planning cooperation with debian and other normal distros (that dont insanely patch the kde) talking with upstream about the f#$*# svn version in their snapshots helping upstream with spliting packages and updating the splits in overlay acording to the output kde4 build system modifications we would like to see (more versions in one prefix). // hope i didnt forget anything Well as usual the meeting is mandatory so please come and help us improve the kde :] (this is ment also for HTs and padavans on them :P) Ok at last but not least when and where: WHEN: 12.2.2009 20.00 UTC (jorge cant sooner so we are moving the time bit) WHERE: #gentoo-...@freenode Anybody whom has something to say at these point is free to come and chat with us. Also if you have something not listed here and you think we should work/help with, come please along. Regards Tomas Chvatal KDE Herd Testers Lead PS: i nominate jorge (jmbsvicetto) if he forget to sent his application :P -- Ioannis Aslanidis deathwing00[at]gentoo.org 0x47F370A0
Re: [gentoo-dev] Re: midnight commander - which screen library
Mike Frysinger wrote: On Monday 09 February 2009 13:32:24 Nikos Chantziaras wrote: Enrico Weigelt wrote: @mc.o (*1) we're currently discussing which screen library to keep. Either ncurses or slang will be dropped (bundled slang will anyway) Both have their pros and cons, so we haven't decided yet. What do you suggest, which screen library to keep ? BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good. that doesnt make any sense. both ncurses and slang work just fine with and without unicode. i dont think he was asking about Gentoo anyways ... he was asking about upstream mc. the proper string under Gentoo would be: ncurses? ( unicode? ( sys-libs/ncurses[unicode] ) !unicode? ( sys-libs/ncurses ) ) !ncurses? ( slang? ( =sys-libs/slang-2.1.3 ) ) -mike ncurses? ( sys-libs/ncurses[unicode?] ) !ncurses? ( slang? ( =sys-libs/slang-2.1.3 ) ) Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: midnight commander - which screen library
On Monday 09 February 2009 19:02:34 Petteri Räty wrote: Mike Frysinger wrote: On Monday 09 February 2009 13:32:24 Nikos Chantziaras wrote: Enrico Weigelt wrote: @mc.o (*1) we're currently discussing which screen library to keep. Either ncurses or slang will be dropped (bundled slang will anyway) Both have their pros and cons, so we haven't decided yet. What do you suggest, which screen library to keep ? BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good. that doesnt make any sense. both ncurses and slang work just fine with and without unicode. i dont think he was asking about Gentoo anyways ... he was asking about upstream mc. the proper string under Gentoo would be: ncurses? ( unicode? ( sys-libs/ncurses[unicode] ) !unicode? ( sys-libs/ncurses ) ) ncurses? ( sys-libs/ncurses[unicode?] ) thanks, i figured there was an easier answer -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: midnight commander - which screen library
On Monday 09 February 2009 15:36:00 Nikos Chantziaras wrote: Mike Frysinger wrote: On Monday 09 February 2009 13:32:24 Nikos Chantziaras wrote: BTW: 4.6.2 is soon coming (only 1 bug left) :) unicode? ( =sys-libs/slang-2.1.3 ) !unicode? ( sys-libs/ncurses ) If Unicode isn't possible with ncurses, keep slang :P No Unicode support would be... not good. that doesnt make any sense. both ncurses and slang work just fine with and without unicode. MC doesn't. A patch adds Unicode to MC. It's for slang only. that's a MC deficiency, not a terminal library one. i wasnt talking about MC itself (perhaps you were, but you didnt really make that clear). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
On Mon, Feb 9, 2009 at 11:52 PM, Matti Bickel m...@gentoo.org wrote: eautomake dies on its own. You don't need || die here. Thanks for the comments, WANT_AUTO* was specified to make some previous commenter happy, but removed now ;) Where was that 'which functions || die on their own' table, anyway? ls /usr/lib/portage/bin/ -- that'll give you a list of functions which don't die on their own -- ~Nirbheek Chauhan
[gentoo-dev] Can't format floppy or write to it...
I needed to make bootable floppy for graphic card BIOS reflash and noticed that I can't fdformat floppy or even write to formatted one. I can mount it -o rw, but when I try to write, write would fail. Also, fdformat /dev/fd0 seems to be working, but just to the point,where it verifies written and fails on track 0. I have checked: - floppies for write protection ( it was off ) - for dirt on heads- I have cleaned floppy thoroughly - bad unit. Exchanged it with another, with exactly same result. - bad floppy disk. Tried a few other, with same result. Same disks formatted on another Windoze machine just fine. - bad access flags on /dev/fd0. ( Access: (0660/brw-rw) Uid: ( 0/ root) Gid: ( 11/ floppy) ) Here is output of fdformat /dev/fd0: LANG=en fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048 and here is dmesg | tail: Buffer I/O error on device fd0, logical block 32 end_request: I/O error, dev fd0, sector 288 Buffer I/O error on device fd0, logical block 36 end_request: I/O error, dev fd0, sector 308 Buffer I/O error on device fd0, logical block 38 end_request: I/O error, dev fd0, sector 333 Buffer I/O error on device fd0, logical block 41 end_request: I/O error, dev fd0, sector 45 Buffer I/O error on device fd0, logical block 5 Machine: Phenom 9950 Boartd Foxconn A7DA-S 8 Gig RAM. nVidia 8800GT with 1GiG RAM DDR3 DVD+ RW unit floppy 2x 500 Gb HDD SATA Gentoo 64-bit ( 2008.0-desktop profile ) pretty much latest version of everything kernel gentoo-sources-2.6.28-r1 Has anyone noticed anything remotely similar ? I can recall being able to use floppy normally with older 2.6.27 kernels, but can't try this now... Regards, Branko
Re: [gentoo-dev] Can't format floppy or write to it...
This is not the right place to ask. Ask on either: 1. Gentoo forums: http://forums.gentoo.org 2. Gentoo user mailing list: gentoo-u...@lists.gentoo.org signature.asc Description: OpenPGP digital signature
