Re: popt's debian patch

Randy McMurchy wrote: > Tushar Teredesai wrote these words on 01/18/06 00:57 CST: > > >>I don't think you checked the link that I mentioned. It has a tarball >>(tar.gz). > > > Cool! > > For those like me that don't understand why a link wasn't provided > initially to the tarball, here it is:

Re: popt's debian patch

Tushar Teredesai wrote these words on 01/18/06 01:45 CST: > Like Jermey said, you are expected to click on a link before commenting ;-) No, folks are expected to provide links to the actual thing, and not just a tease. Keep in mind, you are trying to convince us to change; making one do some rese

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: What bothers me the most now, and what everyone should consider, is that the guy that is pushing this whole deal said earlier this evening that he would like to start tomorrow with the conversion to put this crap in production... Please re-read the post: http://www.lin

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: Randy McMurchy wrote: What is on Anduin is not a test run. The BLFS stuff there is very incomplete. It is not even close to being current with exiting Bugzilla. What am I missing here? I didn't import all the bugs from the BLFS bugzilla database. One bug was giving m

Re: RFC: Implementing Trac [long]

Tushar Teredesai wrote these words on 01/18/06 01:40 CST: > I have only been skimming this thread but I *think* he is planning to > upgrade subversion tomorrow, not move over everything to trac > tomorrow. Also I believe he said if we run into problems with trac, we > can hit the panic button and

Re: RFC: Implementing Trac [long]

On 1/18/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > What bothers me the most now, and what everyone should consider, is > that the guy that is pushing this whole deal said earlier this > evening that he would like to start tomorrow with the conversion to > put this crap in production... I ha

Re: RFC: Implementing Trac [long]

DJ Lucas wrote these words on 01/18/06 01:03 CST: > Well, that changes things. It's definately not ready. Toss my last > review right out the window for now. What bothers me the most now, and what everyone should consider, is that the guy that is pushing this whole deal said earlier this eveni

Re: ICA on LFS-svn

On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > > I was wrong in retracting, my LFS-svn results definitely show this for > all builds after the first. I can't yet see why the symlink is moving > (and I've spent twenty minutes looking at readline's shlib/Makefile and > support/shlib-install).

Re: RFC: Implementing Trac [long]

Bruce Dubbs wrote these words on 01/18/06 00:48 CST: > No. It just means that there was a glitch that needs to be worked out > as a part of the conversion. We won't (can't) upgrade to the new system > until all such problems are worked out. And, the decision gets made before the "problems are w

Re: popt's debian patch

Randy McMurchy wrote: > Bruce Dubbs wrote these words on 01/18/06 00:36 CST: > >>Tushar Teredesai wrote: >> >>>It looks like upstream has a new release of popt >> >>Where is the source? > > > Perhaps a better question is: > > Who(what) is upstream with the popt package? I was a little short in

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: DJ Lucas wrote: I trust this is for testing purposes... This isn't to do with Trac, but Trac benefits by it. We are running Subversion 1.1, IIRC. And 1.3.0 has been released and we feel it's a good time to upgrade. If you have a concern with that, please voice it.

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/18/06 00:15 CST: > Finally, it wasn't a copout, it was unecessary work. Apply the same > advice here that you hand out to newbies in lfs-support. If you can't be > bothered to read, why should I answer the questions for you? Absolutely ludricrous. Never min

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Jeremy Huntwork wrote these words on 01/18/06 00:21 CST: >>I didn't import all the bugs from the BLFS bugzilla database. One bug >>was giving me trouble and I stopped after that. There is a python script >>that converts them, it was hanging on one of the BLFS bugs. > Does

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/18/06 00:21 CST: > I didn't import all the bugs from the BLFS bugzilla database. One bug > was giving me trouble and I stopped after that. There is a python script > that converts them, it was hanging on one of the BLFS bugs. Does this mean the rest of them

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: It took approximately 10 seconds here, just now. It started loading the page immediately, and tickets appended into the list on the bottom within the 10 seconds. Yeah, that page with all bugs is 2.5MB in size, it just takes some time to send it. Here on my lousy dsl c

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/18/06 00:23 CST: > Randy McMurchy wrote: >>Yes, more than 60 seconds. Actually, worse than what we have. I > > It took approximately 10 seconds here, just now. It started loading the > page immediately, and tickets appended into the list on the bottom > with

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Justin R. Knierim wrote these words on 01/18/06 00:08 CST: > > >>It looks pretty complete to me. I see every bugzilla bug imported into >>it. Click 'View Tickets' and then '{6}'. Caution, only an example, >>takes a while to load all tickets. > > > Yes, more than 60

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > What is on Anduin is not a test run. The BLFS stuff there is very > incomplete. It is not even close to being current with exiting > Bugzilla. > > What am I missing here? > I didn't import all the bugs from the BLFS bugzilla database. One bug was giving me trouble and I s

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: Yes, more than 60 seconds. Actually, worse than what we have. I actually had to check my internet connection. But this is me being stupid and naive on how to use the software. What does the time compare for bugzilla to display a list of all 1000+ (or 2000+) bugs, for ea

Re: RFC: Implementing Trac [long]

Alexander E. Patrakov wrote: > Looks good, but some functionality is not obvious. E.g., how to search > all open LFS tickets for the word "udev" in their name (not in comments)? I am sorry I never answered this. You would click 'View Tickets' and then 'Custom Query' underneath it. Or, and proba

Re: RFC: Implementing Trac [long]

Justin R. Knierim wrote these words on 01/18/06 00:08 CST: > It looks pretty complete to me. I see every bugzilla bug imported into > it. Click 'View Tickets' and then '{6}'. Caution, only an example, > takes a while to load all tickets. Yes, more than 60 seconds. Actually, worse than what w

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Jeremy, I suppose you and I will never agree on this point, so let's > just drop it. It was your job to do some research and relay to the > community your findings. You failed in this. At least this is my > opinion. > > "Go to the links provided" is a cop-out. The software

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: What is on Anduin is not a test run. The BLFS stuff there is very incomplete. It is not even close to being current with exiting Bugzilla. It looks pretty complete to me. I see every bugzilla bug imported into it. Click 'View Tickets' and then '{6}'. Caution, only an

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 23:52 CST: > There already has been a test run. What is on Anduin is not a test run. The BLFS stuff there is very incomplete. It is not even close to being current with exiting Bugzilla. What am I missing here? -- Randy rmlscsi: [GNU ld version 2.

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 23:39 CST: > I don't see why I should be expected to spell out things that are > spelled out via links provided. A2D in a big way. And, thankfully to I'm sure everyone, my last contribution to this thread. But, Jeremy, you are dead wrong. More w

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 23:11 CST: > You said 'Let the community speak', I said they already have. That's the > point. I think perhaps you didn't understand what I was driving at. You've probably contributed 20,000 words on the subject, most of them reiterating what you had

Re: RFC: Implementing Trac [long]

DJ Lucas wrote: > I trust this is for testing purposes... This isn't to do with Trac, but Trac benefits by it. We are running Subversion 1.1, IIRC. And 1.3.0 has been released and we feel it's a good time to upgrade. If you have a concern with that, please voice it. > I've been sitting back and

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: I need to upgrade Subversion on Belgarath first (we should do that regardless of Trac). Because it's a major upgrade, we need to svn dump and load all our repos. I've dumped all of them already. I trust this is for testing purposes... Next step is building Subversion,

Re: Why does shadow need a patch?

Chris Staub wrote: The shadow installation in {C}LFS has a patch to "fix" the issue of pam, auditing, and selinux support being enabled by default. Shadow seems to compile just fine without the patch if I just add "--without-selinux --without-libpam --without-audit" to configure. Is there any

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > My comments tonight I suppose are because it is just now, tonight, > after, what? a week or two of your proposal that we find out that > you cannot divorce the different capabilities of Trac from one > another? That you must more-or-less go all or nothing? > > This was not

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: Then we install Trac and create an environment for each project. Lastly, we import the bugzilla database for each one. (This might take some time, a week, perhaps) Sounds reasonable. I think it will be a good replacement, from playing around with it. The 3 component

Re: RFC: Implementing Trac [long]

Bruce Dubbs wrote: > > Jeremy, what do you see for an implementation schedule? I need to upgrade Subversion on Belgarath first (we should do that regardless of Trac). Because it's a major upgrade, we need to svn dump and load all our repos. I've dumped all of them already. Next step is building

Why does shadow need a patch?

The shadow installation in {C}LFS has a patch to "fix" the issue of pam, auditing, and selinux support being enabled by default. Shadow seems to compile just fine without the patch if I just add "--without-selinux --without-libpam --without-audit" to configure. Is there any reason for patching

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > No, it cannot. Yes, it can. >From m-w.com "2 : anxious concern : SOLICITUDE" What's more, the phrase I used is well known and never, in my experience, has it referred to terror. > there. Some would say that is being too worrisome, I just think > it is you being argument

Re: RFC: Implementing Trac [long]

Bruce Dubbs wrote these words on 01/17/06 22:37 CST: > I don't agree with you on this, Randy. Jeremy's subjective feelings > developed from installing and working with the system are relevant. He > is also qualifying his statements as subjective which is good practice > when data is incomplete.

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 22:26 CST: > I wasn't trying to be dramatic. 'Fear' can mean concern or caution, and > is how I intended it. No, it cannot. Fear to most English speakers is associated with "afraid, danger, panic, alarm, fright, horror, terror" and many others that I

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Jeremy Huntwork wrote these words on 01/17/06 21:08 CST: > >>Apart from the fact that I >>tested Trac on Anduin, which would have helped Trac's processing time, >>Trac uses SQLite as a backend. I'm inclined to believe that is a mite >>faster than Bugzilla's MySQL database,

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Then please, restrict your comments (as they pertain to your suggestions) > to material you have researched and know to be a fact. Quite frankly, > your subjective guesses are meaningless. Fine, in the future I will. But tell me why you are so venomous towards me but would

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > There are no fears. Please don't use words that don't accurately > describe what I've said. Drama isn't needed here, just the facts. I wasn't trying to be dramatic. 'Fear' can mean concern or caution, and is how I intended it. Why is there is a problem between us reading th

Re: Unzip 5.52 Max file size limit

Tushar Teredesai wrote: > On 1/17/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > >>It would be nice to do it in zip >>too, but I couldn't find an equivalent construct (didn't look a lot). > > > The var is similar to unzip's - LOCAL_ZIP. I don't understand your comment. I see that LOCAL_ZIP is a

Re: HLFS-uClibc, module-init-tools is installing in /usr/local

> I'm rebuilding at present with prefix changed back to "" to see if that > works as expected... Same problem, module-init-tools stuff being put in /usr/local/ so now I'm rebuilding with prefix set to "/usr". -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscrat

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 21:08 CST: > Apart from the fact that I > tested Trac on Anduin, which would have helped Trac's processing time, > Trac uses SQLite as a backend. I'm inclined to believe that is a mite > faster than Bugzilla's MySQL database, but I have no raw data to

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 21:08 CST: > Let me try to put some of your fears to rest. There are no fears. Please don't use words that don't accurately describe what I've said. Drama isn't needed here, just the facts. >From the sounds of things, I am against the proposal. If th

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > Then, after Trac proves itself a success as a Bugzilla replacement, > another component of our on-line presence can be migrated over, if it > is deemed that we should go that route. Let me try to put some of your fears to rest. The source viewing capacity of Trac is so mu

Re: fr_FR.UTF-8: No such file or directory

Dan McGhee spotted a typo on Glibc page in Chapter 6: localedef -i fr_FR.UTF-8 -f UTF-8 fr_FR Should be: localedef -i fr_FR -f UTF-8 fr_FR.UTF-8 Thanks for the report. I hope that editors will fix this quickly. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-d

Perl security vulnerability

A while ago I posted on lfs-security about a Perl security vulnerability and a patch that remedies it: I thought the patch should be added to LFS SVN and the 6.1.1 errata. Or shouldn't it? Tim -- http://linuxfromscratc

Re: RFC: Implementing Trac [long]

Bruce Dubbs wrote these words on 01/17/06 18:38 CST: > I think he means that we should benchmark both trac and bugzilla on the > same hardware and under the same load to make a judgement about > performance. IS that right, Randy? Well, I simply *loathe* using Bugzilla on Belgarath right now. Shi

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: > Randy McMurchy wrote: > > >>I've often thought that the way Trac is being presented is less >>than a "fair trial". > > > Offer suggestions, please, on what you think would be a fair trial. I'm > sorry that my excitement about it carries me along sometimes. :) > > FWIW

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote: >Offer suggestions, please, on what you think would be a fair trial. I'm >sorry that my excitement about it carries me along sometimes. :) > > > Give it a run for its money, let the people that are going to use it, use it, and see how it works under a load with people usi

Re: RFC: Implementing Trac [long]

Jeremy Huntwork wrote these words on 01/17/06 18:22 CST: > FWIW, I believe all of the project leads have said that they'd like to > use Trac. Also, the implementation of it won't be done overnight, so we > should be able to hit a panic button if we need to. I don't think anyone has argued that se

Re: RFC: Implementing Trac [long]

Randy McMurchy wrote: > I've often thought that the way Trac is being presented is less > than a "fair trial". Offer suggestions, please, on what you think would be a fair trial. I'm sorry that my excitement about it carries me along sometimes. :) FWIW, I believe all of the project leads have s

HLFS-uClibc, module-init-tools is installing in /usr/local

Ch.6, module-init-tools has "./configure --prefix=/ --enable-zlib" as per current SVN version. I used to have prefix specifed as "" as per an older version of the SVN book. Looking through the build logs I now see that the module tools are being installed into /usr/local/bin/. Strange... I'm reb

Re: RFC: Implementing Trac [long]

Archaic wrote these words on 01/17/06 17:58 CST: > Trac is on a faster computer than belg, so this may be a red herring. > Bugzilla on anduin would be fast, too. I'm in favor of trac replacing > BZ, though, so don't read it wrong. Just trying to be honest. I've often thought that the way Trac is

Re: RFC: Implementing Trac [long]

Archaic wrote: > On Mon, Jan 16, 2006 at 08:07:46AM -0500, Jeremy Huntwork wrote: > >>* Reading and searching through bugs/tickets is noticeably faster. > > > Trac is on a faster computer than belg, so this may be a red herring. > Bugzilla on anduin would be fast, too. I'm in favor of trac repla

Re: RFC: Implementing Trac [long]

On Mon, Jan 16, 2006 at 08:07:46AM -0500, Jeremy Huntwork wrote: > > * Reading and searching through bugs/tickets is noticeably faster. Trac is on a faster computer than belg, so this may be a red herring. Bugzilla on anduin would be fast, too. I'm in favor of trac replacing BZ, though, so don't

Re: Parameter in Makefile

El Martes, 17 de Enero de 2006 12:36, Alexander E. Patrakov escribió: > Filip Bartmann wrote: > >Why is in Makefiles for LFS books parameters "-nonet"? If I don't remove > >this parameters I can't build this books, because I have errors "failed > >to load external entity". Have I something wrong? >

Re: TeX and LFS-BOOK

El Martes, 17 de Enero de 2006 10:14, Filip Bartmann escribió: > How can I make TeX output from LFS book XML sources? I find, that under > directory stylesheet is file lfs-tex.xsl-how can I use this file for > converting from xml to TeX? That stylesheet depend on db2latex (http://db2latex.sourcefo

Re: куплю б/у автомобил ь

Alexander E. Patrakov wrote: > Richard A Downing wrote: > >> Way to go, Alexander! I actually get Cyrillic in Sylpheed-claws on >> this UTF-8-built LFS. It's encoded Windows-1251. I've never seen a >> cyrillic spam before, other than as those odd 'I can't render this' =cf >> stuff. >> >> > It'

Re: ICA on LFS-svn

On Tue, 17 Jan 2006, Dan Nicholson wrote: Seems to me like this whole issue with the .old libraries for readline should just be eliminated. It's the only package that does this. DIY has sed -i.bak '/MV.*old/d' Makefile Well, when it works, it looks good (update in place, decide you don't

Re: ICA on LFS-svn

On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > On Mon, 16 Jan 2006, Ken Moffat wrote: > > > On Mon, 16 Jan 2006, Tushar Teredesai wrote: > > > >> On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > >>> libhistory.so.5 (symlink, points to .old after in-place rebuild) > >>> libreadline.so.5

Re: Parameter in Makefile

Filip Bartmann wrote: Why is in Makefiles for LFS books parameters "-nonet"? If I don't remove this parameters I can't build this books, because I have errors "failed to load external entity". Have I something wrong? Yes, old version of DocBook XML DTD and stylesheets.. -- Alexander E. Patr

Parameter in Makefile

Why is in Makefiles for LFS books parameters "-nonet"? If I don't remove this parameters I can't build this books, because I have errors "failed to load external entity". Have I something wrong? Filip Bartmann -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratc

Re: куплю б/у автомобиль

Richard A Downing wrote: On Mon, 16 Jan 2006 15:50:04 -0500 "Waywardness D. Norma" <[EMAIL PROTECTED]> wrote: (spam) Way to go, Alexander! I actually get Cyrillic in Sylpheed-claws on this UTF-8-built LFS. It's encoded Windows-1251. I've never seen a cyrillic spam before, other than

TeX and LFS-BOOK

How can I make TeX output from LFS book XML sources? I find, that under directory stylesheet is file lfs-tex.xsl-how can I use this file for converting from xml to TeX? Filip Bartmann -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: Se