[gentoo-dev] [SEMI-OFF-TOPIC] PSU for a Cobalt Qube 2
I just received a Cobalt Qube 2 .It only has 16 mb of ram but i'm working on getting more memory. But the unit cammed with now PSU so i am hunting for one of these: 1- A Working PSU 2- A non working psu (to use the connector) and pinout of the psu 3- The pinout of the psu so i can hack another solution If any one out there could help it would be great. I would pay for shipping costs, but this is christmas, so a christmas present would be nice ;) If i could get this working it would become another gentoo box ;) -- Gustavo Felisberto (HumpBack) Web: http://dev.gentoo.org/~humpback Blog: http://blog.felisberto.net/ It's most certainly GNU/Linux, not Linux. Read more at http://www.gnu.org/gnu/why-gnu-linux.html . - signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] last rites for net-im/sim
Ugh, it is the only one that reliably connects to icq (yea, I am stuck using it for many people whom I contact as this is pretty much the only protocol "honored" there) *and* handles various encodings in a sane way (no, gaim, while been really nice on a protocol side, does not cut it on localization side, not even close. And kopete is the other way around :)).. So, I too would say, please at least keep it in the tree.. There is a plea in that bug, btw, to give somebody a month to fix it, so there is still hope :).. George On Sunday, 18. December 2005 09:14, Bruno wrote: > On Saturday 17 December 2005 20:54, Carsten Lohrke wrote: > > When you are interested in sim and willing to fix all bugs¹ and takeover > > maintainership) speak now. Christmas morning I'll crucify it. > For moving over to the forked sim on berlios > (http://sim-im.berlios.de/wiki/Main_Page), is it better to keep sim masked > in portage and then continue with the forked releases once they come up, or > just restart from zero? > > From user point of view I guess the continuity option may be better... > > Bruno -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Binary packages in the tree
Currently we are forcing people to either have gcc-3.3 installed, or libstdc++-v3 so that old packages that weren't recompiled yet don't break, and binary packages that need libstdc++.so.5 don't break horribly as well. I'd like to see this dependency in the gcc ebuilds go away and all of the binary packages in the tree depend on the libstdc++ version they need. This will make things easier in the future so we don't need to force 2 or 3 libstdc++'s on users just so other possible packages may work. So, everyone that has a binary package in the tree, I would appreciate it if you could put the sys-libs/libstdc++-v3 depend into your package if necessary. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpd0qxCVrlSW.pgp Description: PGP signature
Re: [gentoo-dev] Binary packages in the tree
Mark Loeser <[EMAIL PROTECTED]> said: > So, everyone that has a binary package in the tree, I would appreciate it if > you could put the sys-libs/libstdc++-v3 depend into your package if > necessary. Well, you can tell I didn't exactly think about this too much beforehand, since its been brought to my attention a virtual would probably be best for this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the virtual. I'll make one later unless anyone has strong objections to this for people to use in DEPEND, instead of writing the `or` dep out. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgp4pUkV3L5xM.pgp Description: PGP signature
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13634 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 798 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages in the tree
Mark Loeser wrote: >Well, you can tell I didn't exactly think about this too much beforehand, >since its been brought to my attention a virtual would probably be best for >this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the >virtual. I'll make one later unless anyone has strong objections to this for >people to use in DEPEND, instead of writing the `or` dep out. > > > Since gcc-3.4 is the stable version now, the best would be || ( libstdc++ gcc-3.3.* ) . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] December 15th Meeting Summary
On Thu, 15 Dec 2005 22:47:21 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > this months meeting wasnt too eventful, kind of quiet ... on the > agenda: > > - Marius: decision on multi-hash for Manifest1 > there was a bit of hearsay about why the council was asked to > review/decide on this issue since we werent able to locate any > portage devs at the time of the meeting ... Well, it would help if the actual meeting date would be announced and not pushed back without notice ;) > so our decision comes with a slight caveat. assuming the reasons > our input was asked for was summarized in the e-mail originally > sent by Marius [1], then we're for what we dubbed option (2.5.1). > that is, the portage team should go ahead with portage 2.0.54 and > include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 > should not be included as having both SHA256/SHA1 is pointless. Ok, not a problem. > it was also noted that we should probably omit ChangeLog and > metadata.xml files from the current Manifest schema as digesting > them serves no real purpose. You're all aware that this would break http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] last rites for net-im/sim
On Mon, 2005-19-12 at 12:19 +0100, George Shapovalov wrote: > Ugh, it is the only one that reliably connects to icq (yea, I am stuck using > it for many people whom I contact as this is pretty much the only protocol > "honored" there) *and* handles various encodings in a sane way (no, gaim, > while been really nice on a protocol side, does not cut it on localization > side, not even close. And kopete is the other way around :)).. You may want to try GnomeICU for ICQ. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for net-im/sim
George Shapovalov wrote: Ugh, it is the only one that reliably connects to icq (yea, I am stuck using it for many people whom I contact as this is pretty much the only protocol "honored" there) *and* handles various encodings in a sane way (no, gaim, while been really nice on a protocol side, does not cut it on localization side, not even close. And kopete is the other way around :)).. I can't really say anything about gaim's localization, but what is wrong with kopete on the protocol side of things? I haven't had a single problem with icq and kopete. MSN is a different story, however -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
Marius Mauch wrote: On Thu, 15 Dec 2005 22:47:21 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: this months meeting wasnt too eventful, kind of quiet ... on the agenda: - Marius: decision on multi-hash for Manifest1 there was a bit of hearsay about why the council was asked to review/decide on this issue since we werent able to locate any portage devs at the time of the meeting ... Well, it would help if the actual meeting date would be announced and not pushed back without notice ;) so our decision comes with a slight caveat. assuming the reasons our input was asked for was summarized in the e-mail originally sent by Marius [1], then we're for what we dubbed option (2.5.1). that is, the portage team should go ahead with portage 2.0.54 and include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 should not be included as having both SHA256/SHA1 is pointless. Ok, not a problem. it was also noted that we should probably omit ChangeLog and metadata.xml files from the current Manifest schema as digesting them serves no real purpose. You're all aware that this would break FYI, that version of portage is already broken by the virtuals glep and X11's virtual/stuff so no harm there ;) -Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: | Mark Loeser <[EMAIL PROTECTED]> said: | |>So, everyone that has a binary package in the tree, I would appreciate it if |>you could put the sys-libs/libstdc++-v3 depend into your package if |>necessary. | | | Well, you can tell I didn't exactly think about this too much beforehand, | since its been brought to my attention a virtual would probably be best for | this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the | virtual. I'll make one later unless anyone has strong objections to this for | people to use in DEPEND, instead of writing the `or` dep out. Feel free to ping me if you're interested in making a new-style virtual. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpvphXVaO67S1rtsRAn6xAKCjTkdTfy3LllQCfXNic+EJh7k/HQCgjxoM KWzSBeT7yz/lcAnIQnMZqrA= =3Mx6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, Dec 19, 2005 at 06:37:16PM +0100, Marius Mauch wrote: > On Thu, 15 Dec 2005 22:47:21 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > there was a bit of hearsay about why the council was asked to > > review/decide on this issue since we werent able to locate any > > portage devs at the time of the meeting ... > > Well, it would help if the actual meeting date would be announced and > not pushed back without notice ;) we've taken steps with automating future announcements since this months meeting was a bit under-publicized > One thing solar has pointed out is that in countries with stupid laws > pycrypto violates some patents so currently we cannot ship it in stages > or binary packages (so I'm told, I'm neither a lawyer nor someone who > is affected by such laws). This is probably something releng and the > python herd have to deal with. this shouldnt be too much of an issue Lukasz: mind if i commit support for USE=bindist or you guys want a bug to track it ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, 2005-12-19 at 18:37 +0100, Marius Mauch wrote: > On Thu, 15 Dec 2005 22:47:21 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > this months meeting wasnt too eventful, kind of quiet ... on the > > agenda: > > > > - Marius: decision on multi-hash for Manifest1 > > there was a bit of hearsay about why the council was asked to > > review/decide on this issue since we werent able to locate any > > portage devs at the time of the meeting ... > > Well, it would help if the actual meeting date would be announced and > not pushed back without notice ;) > > > so our decision comes with a slight caveat. assuming the reasons > > our input was asked for was summarized in the e-mail originally > > sent by Marius [1], then we're for what we dubbed option (2.5.1). > > that is, the portage team should go ahead with portage 2.0.54 and > > include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 > > should not be included as having both SHA256/SHA1 is pointless. > > Ok, not a problem. > > > it was also noted that we should probably omit ChangeLog and > > metadata.xml files from the current Manifest schema as digesting > > them serves no real purpose. > > You're all aware that this would break portage version older than 6 months)? Also while they don't affect the > build process they contain important information and are/will be parsed > by portage, so I'm not that comfortable with dropping also the option > of verifying them permanently. > > One thing solar has pointed out is that in countries with stupid laws > pycrypto violates some patents so currently we cannot ship it in stages > or binary packages (so I'm told, I'm neither a lawyer nor someone who > is affected by such laws). This is probably something releng and the > python herd have to deal with. It's easy enough to patch the two ciphers out when USE=bindist would be set. > So right now I'll go ahead and add the pycrypto code to portage, but > will not yet add the dep to any ebuild or change anything metadata.xml > or ChangeLog related (according to Jason 2.0.54 is still away one or > two weeks anyway). If you do that please set it as a blocker for the .54 release. Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired regression. Nothing in the portage as of <=.53 make direct use of those two files and there is no security value in bloating the digest format with them. Thats why they were removed 2.0.51.21 Making the argument for maybe portage in the future will use them is not valid as they are currently omited and we/I have been told before by the portage team (ferringb & jstubbs iirc??) that portage itself wont be doing any .xml parsing in it's core. IE So that means not today nor tomorrow will anything need to depend on those files in order to build. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for net-im/sim
Well, I cannot say anything about msn, as I have nobody using it. As for icq, good for you then :). I am hitting that famous login bug - just cannot login whether I use either of the standard login sites (are there any more?).. I should admit though, things have "improved" somewhat. Now, with kde-3.5 kopete does not spit out that message about unknown error, instead it keeps trying.. and trying, and trying... So, there is some hope that it may start working for me in, say 3.5.3, or at least 4.1 :). George On Monday, 19. December 2005 19:05, Stephen P. Becker wrote: > George Shapovalov wrote: > > Ugh, it is the only one that reliably connects to icq (yea, I am stuck > > using it for many people whom I contact as this is pretty much the only > > protocol "honored" there) *and* handles various encodings in a sane way > > (no, gaim, while been really nice on a protocol side, does not cut it on > > localization side, not even close. And kopete is the other way around > > :)).. > > I can't really say anything about gaim's localization, but what is wrong > with kopete on the protocol side of things? I haven't had a single > problem with icq and kopete. MSN is a different story, however > > -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, 19 Dec 2005 13:45:04 -0500 solar <[EMAIL PROTECTED]> wrote: > If you do that please set it as a blocker for the .54 release. > Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired > regression. Nothing in the portage as of <=.53 make direct use of > those two files and there is no security value in bloating the digest > format with them. Thats why they were removed 2.0.51.21 > > Making the argument for maybe portage in the future will use them is > not valid as they are currently omited and we/I have been told before > by the portage team (ferringb & jstubbs iirc??) that portage itself > wont be doing any .xml parsing in it's core. IE So that means not > today nor tomorrow will anything need to depend on those files in > order to build. Name a single portage version that does *not generate* manifest entries for them (hint: there is none). They are only ignored right now during verification. So it's in no way a regression. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Viability of other SCM/version control systems for big repo's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I know some of you have done research on how gentoo-x86 converts over to other systems besides CVS such as SVN, arch, etc. But I can't find the info anywhere in my archives. Could whoever's got it, post it? I'm particularly interested in hearing about CVS, SVN, mercurial, bazaar, darcs. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpw2YXVaO67S1rtsRAo3aAJ99o9SxpAsgGow3zSGcHu5hXZ13rwCgsXKl DD25pAKELMogICmdH5dSvhY= =bWsH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, 19 Dec 2005 11:44:24 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | I know some of you have done research on how gentoo-x86 converts over | to other systems besides CVS such as SVN, arch, etc. But I can't find | the info anywhere in my archives. | | Could whoever's got it, post it? The SVN stuff is over a year out of date, and SVN has supposedly gotten a lot better wrt scalability since then... I suspect someone will have to redo the tests... As for Arch, I managed to find three different "FATAL ERROR!" bugs in tla within the first five minutes of using it. Two of them were reported and known, with no fix forthcoming. Plus, we don't use a distributed development model so Arch doesn't really suit us... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] last rites for net-im/sim
Thanks, I'll try, but seeing gnome in the name I am quite skeptical. It's really nothing personal. Its just in my experience gnome/gtk apps could never handle cyrillic well enough in all situations.. Yea, cyrillic is a bitch. Its probably worse than chineese, no really :). These guys were later to the game, so even though they have like tons of variants and intrinsically more complex stuff, at least they got it right. With cyrillic we have like 4 different encodings for the very same thing, and 3 of them are widely used (ironically, the one not used much is the "official standard", well, as usual :)). So, you can imagine people having set their environment to one encoding, client reporting another and, to top it off, messages getting recoded while on the server (at least I can see a difference when some poeple shift to direct mode after having logged in, versus messaged left on server when somebody is out.. Well, that might be a server screwing some reported settings, but that does not help.). As you can guess, I can't wait for the last non-utf-8 aware app to die painfull death :) (whell, where this kind of stuff is important of course). Interestingly kde-based stuff somehow works most of the time, and when it does not, you can force the right encoding for that particular user (at least for both kopete and sim, not so with gaim). Ok, I better stop bitching and go fix some more bugs :), but thanks for the suggestion anyway.. George On Monday, 19. December 2005 18:53, Olivier Crete wrote: > On Mon, 2005-19-12 at 12:19 +0100, George Shapovalov wrote: > > Ugh, it is the only one that reliably connects to icq (yea, I am stuck > > using it for many people whom I contact as this is pretty much the only > > protocol "honored" there) *and* handles various encodings in a sane way > > (no, gaim, while been really nice on a protocol side, does not cut it on > > localization side, not even close. And kopete is the other way around > > :)).. > > You may want to try GnomeICU for ICQ. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, Dec 19, 2005 at 08:04:19PM +, Ciaran McCreesh wrote: > On Mon, 19 Dec 2005 11:44:24 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | I know some of you have done research on how gentoo-x86 converts over > | to other systems besides CVS such as SVN, arch, etc. But I can't find > | the info anywhere in my archives. > > As for Arch, I managed to find three different "FATAL ERROR!" bugs in > tla within the first five minutes of using it. Two of them were > reported and known, with no fix forthcoming. Plus, we don't use a > distributed development model so Arch doesn't really suit us... along those same lines, ive used monotone with a project or two and found it to be highly unstable and very incompatible across minor releases -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for net-im/sim
On Mon, 2005-19-12 at 21:08 +0100, George Shapovalov wrote: > Thanks, I'll try, but seeing gnome in the name I am quite skeptical. It's > really nothing personal. Its just in my experience gnome/gtk apps could never > handle cyrillic well enough in all situations.. > > Yea, cyrillic is a bitch. Its probably worse than chineese, no really :). > These guys were later to the game, so even though they have like tons of > variants and intrinsically more complex stuff, at least they got it right. > With cyrillic we have like 4 different encodings for the very same thing, and > 3 of them are widely used (ironically, the one not used much is the "official > standard", well, as usual :)). So, you can imagine people having set their > environment to one encoding, client reporting another and, to top it off, > messages getting recoded while on the server (at least I can see a difference > when some poeple shift to direct mode after having logged in, versus messaged > left on server when somebody is out.. Well, that might be a server screwing > some reported settings, but that does not help.). As you can guess, I can't > wait for the last non-utf-8 aware app to die painfull death :) (whell, where > this kind of stuff is important of course). Modern ICQ is either unicode or specifies the encoding (but as a windows locale and not a regular encoding..). Old ICQ sucks and you have to guess.. If you have problems with GnomeICU.. please file a bug at bugzilla.gnome.org .. I'm the upstream maintainer too... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, 2005-12-19 at 11:44 -0800, Donnie Berkholz wrote: > Hi all, > > I know some of you have done research on how gentoo-x86 converts over to > other systems besides CVS such as SVN, arch, etc. But I can't find the > info anywhere in my archives. > > Could whoever's got it, post it? > > I'm particularly interested in hearing about CVS, SVN, mercurial, > bazaar, darcs. I've only tried svn with the cvs2svn script. Importing with history took ~8h on a 500Mhz box (which surprised me because I had heard "it takes days"). Doing checkouts caused about the same load as cvs, but I have no data points on multi-user behaviour. http://www.keltia.net/EuroBSDCon/slides.pdf has some performance data on mercurial for FreeBSD, roughly the same size as the Gentoo cvs repositories. Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, 19 Dec 2005 22:17:56 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: | I've only tried svn with the cvs2svn script. | Importing with history took ~8h on a 500Mhz box (which surprised me | because I had heard "it takes days"). Doing checkouts caused about the | same load as cvs, but I have no data points on multi-user behaviour. The interesting part isn't really how long it takes to convert things or how long it takes to do a checkout, since they're in effect one time costs. I'm guessing we have at least a hundred full tree updates and a thousand commits for every full checkout... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, Dec 19, 2005 at 10:17:56PM +0100, Patrick Lauer wrote: | http://www.keltia.net/EuroBSDCon/slides.pdf has some performance data on | mercurial for FreeBSD, roughly the same size as the Gentoo cvs | repositories. It's not the size of the repo what matters... it is the workflow. I don't know how they work... but I definately don't think ours suits in a distributed SCM as Ciaran pointed out. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp4IZvukZIby.pgp Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, 2005-12-19 at 21:23 +, Ciaran McCreesh wrote: > On Mon, 19 Dec 2005 22:17:56 +0100 Patrick Lauer <[EMAIL PROTECTED]> > wrote: > | I've only tried svn with the cvs2svn script. > | Importing with history took ~8h on a 500Mhz box (which surprised me > | because I had heard "it takes days"). Doing checkouts caused about the > | same load as cvs, but I have no data points on multi-user behaviour. > > The interesting part isn't really how long it takes to convert things > or how long it takes to do a checkout, since they're in effect one time > costs. Yes, but generating a "realistic" workload isn't trivial.If we had cvs logs to replay we might get some good data. > I'm guessing we have at least a hundred full tree updates and a > thousand commits for every full checkout... Provide us with a script to generate partial updates/commits and I think many people will just run it for fun ... Maybe the nice Infra dudes could provide cvs snapshots for testing? Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-dev] Changing description for the xml global use flag
/usr/portage/profiles/use.desc:xml - Check/Support flag for XML library (version 1) I think the xml use flag should be more generic. There are after all other alternatives for xml support than dev-libs/libxml. Maybe something like Adds xml support? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, Dec 19, 2005 at 10:38:10PM +0100, Fernando J. Pereda wrote: > > It's not the size of the repo what matters... it is the workflow. I > don't know how they work... but I definately don't think ours suits in a > distributed SCM as Ciaran pointed out. I'm not sure about that. Having portage in arch/bazaar would let 'gentoo derivatives' to easily pull selective changes from the 'mainline', would potentially allow us to pull back from them, etc. It might facilitate the stable project to do branches of portage and snipe individual patches for updates, etc very easily. The distributed aspect of it doesn't necessary have to immediately impact core gentoo devs commiting ebuilds. Or maybe not, I dunno. The point being I don't think we should immediately write off any of the distributed SCMs without pondering how they might make a difference or be usable. -pete -- Peter Johanson <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > /usr/portage/profiles/use.desc:xml - Check/Support flag for XML library > (version 1) > > I think the xml use flag should be more generic. There are after all > other alternatives for xml support than dev-libs/libxml. Maybe something > like Adds xml support? then you'd have to deprecate the usage of xml2 is there any package which uses both xml and xml2 ? if not, i dont see why we cant condense the two down into one -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
Mike Frysinger wrote: > On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > >>/usr/portage/profiles/use.desc:xml - Check/Support flag for XML library >>(version 1) >> >>I think the xml use flag should be more generic. There are after all >>other alternatives for xml support than dev-libs/libxml. Maybe something >>like Adds xml support? > > > then you'd have to deprecate the usage of xml2 > > is there any package which uses both xml and xml2 ? if not, i dont see > why we cant condense the two down into one > -mike [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e "xml[^2]" dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads xml2" media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug doc gtk" net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml xml2" net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp xml xml2" net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml xml2" net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml xml2" Found a couple. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On 19/12/05, Peter Johanson <[EMAIL PROTECTED]> wrote: > > Or maybe not, I dunno. The point being I don't think we should immediately > write off > any of the distributed SCMs without pondering how they might make a > difference or be usable. It would be very useful for people who aren't devs but only if they have access to the repository. It would also be useful for devs to have a standard way of publishing their testing/development portage overlays. On the first point, would any of the alternative SCMs prove to be better than CVS resource wise for providing anonymous access to users? It might also be useful to facilitate non-devs contributing patches to the tree - rather than posting files into bugzilla they could point towards whereever they publish their current tree (or changes), and developers can then work with their changes directly instead of the bugzilla upload/download dance we do now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Tue, Dec 20, 2005 at 12:19:01AM +0200, Petteri R??ty wrote: > Mike Frysinger wrote: > > On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > > > >>/usr/portage/profiles/use.desc:xml - Check/Support flag for XML library > >>(version 1) > >> > >>I think the xml use flag should be more generic. There are after all > >>other alternatives for xml support than dev-libs/libxml. Maybe something > >>like Adds xml support? > > > > > > then you'd have to deprecate the usage of xml2 > > > > is there any package which uses both xml and xml2 ? if not, i dont see > > why we cant condense the two down into one > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e "xml[^2]" > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > doc gtk" > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > xml xml2" > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > xml2" > > Found a couple. then these will have to be reconciled first ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Tue, 2005-12-20 at 00:19 +0200, Petteri Räty wrote: > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e "xml[^2]" > dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads xml2" > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > doc gtk" > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > xml xml2" > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > xml2" > > Found a couple. [EMAIL PROTECTED] pykota # qgrep -v -e 'xml2\??' |egrep 'pykota|sitecopy| libwmf' media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml2? ( !xml? ( dev-libs/libxml2 ) ) media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml? ( dev-libs/expat ) net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild:xml? ( dev-libs/libxml ) net-print/pykota/pykota-1.22_p1548.ebuild: xml? ( dev-python/jaxml ) net-print/pykota/pykota-1.22_p1548.ebuild: xml2? ( dev-python/jaxml ) " net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml? ( dev-python/jaxml ) net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml2? ( dev-python/jaxml ) " net-print/pykota/pykota-1.23_p1869.ebuild: xml? ( dev-python/jaxml ) net-print/pykota/pykota-1.23_p1869.ebuild: xml2? ( dev-python/jaxml ) " net-print/pykota/pykota-1.23_p1874.ebuild: xml? ( dev-python/jaxml ) net-print/pykota/pykota-1.23_p1874.ebuild: xml2? ( dev-python/jaxml ) " pykote draws the same package, and doesn't compile anything, so I don't think they are relavent sitecopy-0.13.4-r2 does IUSE both, But uses them to determine weather or not to use XML1 || XML2. It doens't enable both. On the other hand libwmf-0.2.8.3-r1 warns you about using both. - if use xml && use xml2; then -einfo "You can specify only one flag of xml and xml2." -einfo "It will be defaulted to expat (like autocheck does)." Could we have one XML flag and an xml.eclass to determine which XML version is installed on a particular system. -Lares -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing description for the xml global use flag
On Mon, Dec 19, 2005 at 04:04:55PM -0700, Lares Moreau wrote: > On Tue, 2005-12-20 at 00:19 +0200, Petteri R?ty wrote: > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e > > "xml[^2]" > > dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads xml2" > > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > > doc gtk" > > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > > xml xml2" > > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > > > Found a couple. > > [EMAIL PROTECTED] pykota # qgrep -v -e 'xml2\??' |egrep 'pykota|sitecopy| > libwmf' > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml2? ( !xml? > ( dev-libs/libxml2 ) ) > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml? ( dev-libs/expat ) > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild:xml? ( dev-libs/libxml ) > net-print/pykota/pykota-1.22_p1548.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.22_p1548.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1869.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1869.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1874.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1874.ebuild: xml2? > ( dev-python/jaxml ) " > > pykote draws the same package, and doesn't compile anything, so I don't > think they are relavent good > sitecopy-0.13.4-r2 does IUSE both, But uses them to determine weather or > not to use XML1 || XML2. It doens't enable both. sitecopy maintainer should comment here ... > On the other hand libwmf-0.2.8.3-r1 warns you about using both. actually, this usage is sort of bogus ... the USE=xml should be changed to USE=expat > Could we have one XML flag and an xml.eclass to determine which XML > version is installed on a particular system. one XML USE flag yes, an xml.eclass no ... that's just useless cruft -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [SEMI-OFF-TOPIC] PSU for a Cobalt Qube 2
On Mon, Dec 19, 2005 at 10:51:08AM +, Gustavo Felisberto wrote: > 3- The pinout of the psu so i can hack another solution here's what mine says: AC ADAPTER ZVC36FS12 50-60Hz 12V 3.0A EOS Corp you might be able to google up something -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Chris Bainbridge wrote: > On 19/12/05, Peter Johanson <[EMAIL PROTECTED]> wrote: > >>Or maybe not, I dunno. The point being I don't think we should immediately >>write off >>any of the distributed SCMs without pondering how they might make a >>difference or be usable. > > > It would be very useful for people who aren't devs but only if they > have access to the repository. It would also be useful for devs to > have a standard way of publishing their testing/development portage > overlays. On the first point, would any of the alternative SCMs prove > to be better than CVS resource wise for providing anonymous access to > users? It might also be useful to facilitate non-devs contributing > patches to the tree - rather than posting files into bugzilla they > could point towards whereever they publish their current tree (or > changes), and developers can then work with their changes directly > instead of the bugzilla upload/download dance we do now. I am using subversion for a year now, both for work, personal data, system administration (~/, /etc/ on most machines) and gentoo development (my overlay). Migrated from CVS that was used only for some code repositories. It felt like changing a Trabant for Subaru (substitute your fav. rally car)! Because of the ease-of-use and flexibility of access (ssh, https) I started using it everywhere (See good article "My life in subversiion"). As far as speed is concerned, it is comparable with CVS. Storage-space-wise, it takes about twice the space because a pristine copy of every file is held locally (this allows diffs, reverts, etc. to be done from the local copy, so the server is not contacted). Branching/merging is logical, svn:externals is very useful to import other repositories in place. Currently lacks owner:group and permisosons storage, but can be implemented as a wrapper. Compared to CVS, it is a clear winner in my opinion. And learnig curve is steep. Just my 2 yen. Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Tue, 20 Dec 2005 00:19:01 +0200 Petteri Räty <[EMAIL PROTECTED]> wrote: > > > Mike Frysinger wrote: > > On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > > > >>/usr/portage/profiles/use.desc:xml - Check/Support flag for XML > >>library (version 1) > >> > >>I think the xml use flag should be more generic. There are after all > >>other alternatives for xml support than dev-libs/libxml. Maybe > >>something like Adds xml support? > > > > > > then you'd have to deprecate the usage of xml2 > > > > is there any package which uses both xml and xml2 ? if not, i dont > > see why we cant condense the two down into one > > -mike > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e > "xml[^2]" dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads > xml2" media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml > xml2 debug doc gtk" > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome > nls" net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres > snmp xml xml2" > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > xml xml2" > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp > xml xml2" > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp > xml xml2" > > Found a couple. Better to use the correct list: $ metascan -av IUSE xml IUSE xml2 Generating package list ... done Scanning packages for ['IUSE', 'IUSE'] ... done media-libs/libwmf-0.2.8.3-r1 net-fs/samba-3.0.20-r1 net-fs/samba-3.0.14a-r3 net-fs/samba-3.0.20b net-fs/samba-3.0.14a-r2 net-fs/samba-3.0.20a dev-lang/php-4.3.11-r4 dev-lang/php-4.4.0-r4 dev-lang/php-4.4.1-r2 net-print/pykota-1.22_p1548 net-print/pykota-1.23_p1869-r1 net-print/pykota-1.23_p1874 net-print/pykota-1.23_p1869 net-misc/sitecopy-0.13.4-r2 Marius Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Tue, 20 Dec 2005 09:17:56 +0900 Kalin KOZHUHAROV <[EMAIL PROTECTED]> wrote: | As far as speed is concerned, it is comparable with CVS. Be more specific please. We're looking for benchmarks showing how well it performs in terms of speed, bandwidth and memory usage for actions such as commit and update on a repository with 100k+ small files. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, Dec 19, 2005 at 01:45:04PM -0500, solar wrote: > > So right now I'll go ahead and add the pycrypto code to portage, but > > will not yet add the dep to any ebuild or change anything metadata.xml > > or ChangeLog related (according to Jason 2.0.54 is still away one or > > two weeks anyway). > > If you do that please set it as a blocker for the .54 release. > Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired > regression. Nothing in the portage as of <=.53 make direct use of those > two files and there is no security value in bloating the digest format > with them. Thats why they were removed 2.0.51.21 > > Making the argument for maybe portage in the future will use them is > not valid as they are currently omited and we/I have been told before > by the portage team (ferringb & jstubbs iirc??) that portage itself > wont be doing any .xml parsing in it's core. IE So that means not today > nor tomorrow will anything need to depend on those files in order to > build. Stated otherwise in irc in regards to your metadata.xml patch- metadata.xml support will be core, although due to certain constraints it'll be optional intially. At some point, we're going to have to push long desc into the cache; at that point, portage will be required to be xml aware (yay). ~harring pgpwo2Ept53wk.pgp Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Ciaran McCreesh wrote: >On Tue, 20 Dec 2005 09:17:56 +0900 Kalin KOZHUHAROV ><[EMAIL PROTECTED]> wrote: > | As far as speed is concerned, it is comparable with CVS. > >Be more specific please. We're looking for benchmarks showing how well >it performs in terms of speed, bandwidth and memory usage for actions >such as commit and update on a repository with 100k+ small files. > > > I have hardware on which I would be more than willing to perform this type of benchmark. Can you provide/point to a repository of files to benchmark, and a set of operations to perform? The obvious being the portage tree itself, with some/all of its history (however much is necessary for the benchmarks to be meaningful), but would require a set of activities to generate a relevant benchmark. For reference, I have a server that is not yet in production, but readying for production in the next few months, running Gentoo, on a raid-5 array of SCSI harddrives. I don't remember the precise specifications off hand, but I could provide them along with the results. Would this be useful? Would more/other hardware be necessary useful? (I have access to multiple workstations on which I could run simultaneous tests, causing transactions to become relevant and important, etc etc, and further hardware might be available here.) Hope this can be of some use to you in trying to make this evaluation. -Chandler Carruth -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Changing description for the xml global use flag
Petteri Räty posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 20 Dec 2005 00:19:01 +0200: > Mike Frysinger wrote: > >> then you'd have to deprecate the usage of xml2 >> >> is there any package which uses both xml and xml2 ? if not, i dont see >> why we cant condense the two down into one -mike > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e > "xml[^2]" dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads xml2" > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > doc gtk" > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > xml2" What about doing with xml what was done with gtk, when gtk2 was deprecated? IOW, where both are possible, default to one or the other, which ever one is merged, or choose one (preferably making it a Gentoo-wide default, for consistency) if both or neither are merged. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
