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
[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] RFC: fox.eclass update
On Mon, Feb 9, 2009 at 11:52 PM, Matti Bickel 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
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] 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
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] 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 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 0x47F370A0
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: > > 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. That's basically exactly what I've proposed, I'd just add (possibly optional) weight or relevance of tag as well, for example: foo bar 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] [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 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-
[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.
[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.
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: >> 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-
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] 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
On Sun, 08 Feb 2009 14:43:01 -0800 Zac Medico 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
[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: fox.eclass update
Peter Volkov 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="!=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 - elibtoolize + #elibtoolize } fox_src_compile() { @@ -150,21 +124,21 @@ $(use_with profile profiling) \ || die "configure error" - cd ${S}/${FOX_COMPO
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] 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] [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] 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
Petteri Räty a écrit : Ciaran McCreesh wrote: On Mon, 09 Feb 2009 14:30:58 +0200 Petteri Räty 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] DIGESTS metadata variable for cache validation
On Mon, 09 Feb 2009 16:15:55 +0200 Petteri Räty 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
Ciaran McCreesh wrote: > On Mon, 09 Feb 2009 14:30:58 +0200 > Petteri Räty 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 14:30:58 +0200 Petteri Räty 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
Zac Medico wrote: > 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. > 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] 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