Re: [blfs-dev] Acknowledgement to Ken.
On Sun, Mar 20, 2016 at 09:11:28PM -0300, Fernando de Oliveira wrote: > Thank you for undoing all you can find that I did. Even when the book > becomes worse (less exact) or even wrong. > > This is a characteristics I did not know you had. > Like every other editor over the years, apart from you, I do what seems to me to be right. I understand that you, on the other hand, do what actually is right. I am lucky that I have not had to put up with the sort of comments you have directed at other editors. For what it is worth, I am unlikely to waste my time on other tickets for the next several weeks. I understand that you disagree with my change to pango-0.40, and perhaps you are correct - it was a month ago, and for once I did my testing in /tmp and also put my intermittent notes there [ it was a rush to get things in before -rc2 ]. I can recall that I built that damned package several times, as well as checking things which used it, and perhaps I used a version where I had not downloaded the testfiles when I came to try to run the tests. But I know you will not believe that - why attribute to accident or incompetence that which can be attributed to malice ? This post to which I am replying gives no context - I obviously did something else to piss you off, but I have no idea what it was, and I do not care. As for tests in general: for most packages, and particularly for desktop packages, the tests are rarely useful. Where I can, I will separate the time, and space, requirements for them. In the last few days I have seen posts from people on the lists who run tests, so perhaps your attitude will prevail. Meanwhile, I have nothing further to say to you. ĸen -- This email was written using 100% recycled letters. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Acknowledgement to Ken.
Thank you for undoing all you can find that I did. Even when the book becomes worse (less exact) or even wrong. This is a characteristics I did not know you had. Until recently I liked you even more than Bruce. Perhaps my masochism should make me change may aka. -- []s, Fernando, aka Sísifo -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Typo (introduction/changelog.html)
Yukio Shiiya wrote: Hi, I found a typo on the following page. http://www.linuxfromscratch.org/blfs/view/svn/introduction/changelog.html - [bdubbs] - Add a note that openssl does not support parallel tets. Fixes #7486. + [bdubbs] - Add a note that openssl does not support parallel test. Fixes #7491. Could you correct it? OK. At next commit. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] S-Lang 'make install' needs -j1?
On 03/20/2016 06:38 PM, Ken Moffat wrote: On Sun, Mar 20, 2016 at 08:41:33AM +0100, ALZ (phyglos.org) wrote: I'm sticking to the general recommendation of deleting the source tree before each build. My scripts do untar from source at every build command I issue. And do so into a new timestamped directory so each build is in a new clean tree but all previous logs and objects are kept for comparison. Just a reminder that for libreoffice (if you build that) it is sometimes necessary to resume the build - only if it fails a CppunitTest. ĸen That's a good reminder! I'm expecting ccache will take care of that, but I haven't tried it yet on libreoffice, so I'd better take note of that case. Thank you, Ken. Alz. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] S-Lang 'make install' needs -j1?
On Sun, Mar 20, 2016 at 08:41:33AM +0100, ALZ (phyglos.org) wrote: > > I'm sticking to the general recommendation of deleting the source tree > before each build. My scripts do untar from source at every build command I > issue. And do so into a new timestamped directory so each build is in a new > clean tree but all previous logs and objects are kept for comparison. > Just a reminder that for libreoffice (if you build that) it is sometimes necessary to resume the build - only if it fails a CppunitTest. ĸen -- This email was written using 100% recycled letters. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Typo (introduction/changelog.html)
Hi,
I found a typo on the following page.
http://www.linuxfromscratch.org/blfs/view/svn/introduction/changelog.html
- [bdubbs] - Add a note that openssl does not support parallel tets. Fixes
#7486.
+ [bdubbs] - Add a note that openssl does not support parallel test. Fixes
#7491.
Could you correct it?
Thanks,
--
Yukio Shiiya
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] S-Lang 'make install' needs -j1?
Well, the question is not what I want to do, but what happens in the context of an LFS/BLFS build by following the instructions. From the point of view of an LFS builder, I understood (maybe incorrectly) that I can set MAKEFLAGS to whatever I prefer and go using the instructions as they are written. When a package has shown problems with parallel makes, editors clearly advise so in the specific instruction on the page. This is done with all "make" and "make check" that are know to need that. Yes, but we also say: IF a problem occurs "the best way to proceed is to drop back to a single processor build." I suppose we could say that we do not recommend MAKEFLAGS or -jN, N>1 for the install phase. Yes, I'm aware of that. The book has that covered. It was the workaround I ended applying in this case and the problem with S-Lang is solved. What I'm trying to convey is that from the point of view of a LFS reader one could infer the opposite: "you are free to use MAKEFLAGS, because '-j1' will properly be advised at each required spot". Whether the recommendation "always 'make -j1 install' for all packages" is explicitly reflected in the book or not is an editorial decision. On your question about why using parallel install, I'd like to do so while developing/improving my scripts. I've been doing so with LFS and haven't had trouble until S-Lang. Generally wouldn't you be installing to a DESTDIR for that? That's what I've been doing for my LFS-based scripts for the past two months. Now I do install using DESTDIR, pack it up to tar.zx, unpack it again to copy to the filesystem while logging the untarred files with porg, so I end up with the binaries installed on the system plus a nice 'package.tar.xz' that I can reinstall on the same or some other machine without compiling, plus a nice set of auxiliary scripts to compile and test, list files installed, remove packages, etc, etc. This is a major refactor for all packages scripts plus adding several new scripts (a simple package manager indeed). It takes a lot of time and doing so you don't care much about a perfect installation until it first simply works. You just want it fast in development, so I like the idea that 'make install' uses MAKEFLAGS (which to be honest I didn't think about until S-Lang). I ran a test and for slang, the install at -j1 takes about 14 seconds because it wants to do some extra compilation in the install phase. Good point!! Maybe it's that extra compilation at install phase that can cause problems. That makes a lot of sense: you are still compiling at 'make install'...so you still need to keep '-j1'. Nice! If you are changing code, you have most of the files already compiled. My test when I modified a C file then shows make install to take less than a second at -j1. I'm sticking to the general recommendation of deleting the source tree before each build. My scripts do untar from source at every build command I issue. And do so into a new timestamped directory so each build is in a new clean tree but all previous logs and objects are kept for comparison. Sure, this is overkill, but warranties me (I believe) a consistent build for even a tiny modification in the scripts (unless you don't mess up with ccache...) I think we are dealing with three different issues now: * S-Lang needs 'make -j1 install' unconditionally... * An explicit recommendation of doing 'make -j1 install' for either S-Lang or all packages could be added to the book... * How to set up or improve your development/building infrastructure. To me, the first is not only solved but now explained. The second is an editorial decision that I respect. And the third we could go for hours but then we should change the subject of the thread ;-) Thank you! Alz. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] BLFS 7.9 missing dependency on GLibmm-2.46.3
Victor Wren wrote: I'm building a 32-bit version of BLFS on an Intel platform. I've spent most of the day trying to get a clean make check out of GLibmm, and it kept coming up with a fail on "giomm_tls_client/test". Mentions of that exact error in the BLFS mailing list archive say that the failure indicates a missing GnuTLS, but I knew that didn't apply to my situation. I rebuilt GnuTLS multiple times, even going back and rebuilding its dependencies. After doing some research, I found a mention of glib-networking implementing the TLS back-end ( http://code.metager.de/source/xref/gnome/Bindings/glibmm/tests/giomm_tls_client/main.cc, which was probably in my source tree, but was easier to find on the Internet, oddly enough). It would seem that GLibmm depends on glib-networking to register that the GnuTLS backend is available. After I installed glib-networking, make check on GLibmm ran through without an error. It would seem that whether or not GlibMM is functional without glib-networking, it may/will fail at least that test if it doesn't find it. Created ticket http://wiki.linuxfromscratch.org/blfs/ticket/7600 -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
