[blfs-dev] Certificate Authorities Certificates
Three points: First one, I could do, but the other ones, I would prefer, either is a too important decision or it is too big for me, but if necessary, can try. 1. Minor one, but noticed it, yesterday: In the book, cleaning: rm -r certs BLFS-ca-bundle* However, certdata.txt is left. Is it intentional, or should be cleaned too: rm -r certs BLFS-ca-bundle certdata.txt 2. Minor one, too: Never understood: wget is explicitly used, but only optional. Perhaps, should be placed at Recommended or Required, alternatively, the comment a web browser may be used instead of wget but the file will need to be saved with the name certdata.txt could be closer to Optional? 3. This, I think is important, although, can be delayed. However, it might be good having it for an eventual BLFS-7.4. DJ requested a blob with how to install or update cacerts for OJDK, in this page. I would like to open a ticket for us not to forget this. If needed, I could help. For example, if a xml could be sent to me with the places and some comments of the new items, and them, I could insert the commands. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 21-08-2013 19:48, Ken Moffat escreveu: On Sun, Aug 18, 2013 at 01:49:17PM -0300, Fernando de Oliveira wrote: All 5 VMs finished. They run with 4 CPU's, are i686. Two, as I said before, 1GB RAM, running in other host, 3 have 1.5GB, running on this host that have many other things, including FF and TB, running as well. In the other host, times were SBU_TIME: 36.00411522 SBU_TIME: 35.76518218 In this host, SBU_TIME: 49.10614525 SBU_TIME: 52.3750 SBU_TIME: 59.61038961 Perhaps, again, the fact that I have an AMD_64 running on a i686 host running inside a 32bit vmplayer explains why this machine always gave me trouble. It was built to replace this host. Would copy and change whatever needed, for physical, instead of virtual hardware, as done before, is more practical than what I did with LFS7.2, built directly on a physical machine. But as I have written before, discovered that, for many reasons, still need 32bit. Then, waited for LFS7.4, to build a new complete one, 32bit. I only need 64bit for creating OJDK binary for the book. Hope to start building tomorrow. A couple of comments on SBUs - not sure if they relate to what you wrote there, but I'd like to record what I do for package edits. More or less. For the book, I run with j1. Above they ran with j4. But I was amazed that the faster builds are in a much slower host. I think the issue is that I am using a larger but slower HD, here. Some time ago, speed of VM's here were almost double of the ones running in the older host. I will have to revert that, some day (fast and slow HDs are still in this host, just move the systems from one to the other. This is prompted by my LFS-7.4 build on i686. The host was LFS-7.2 and a single-threaded initial SBU was 78.392 seconds (whoot! fast!). But one of the first things I do on a new system is remove /tools, recreate an empty /tools, and run the SBU commands as root. Usually a gcc version increase means things run slower, and in this case I've gone from 4.7.1 to 4.8.1. My SBU on this machine is now 150.849 seconds. I will write down things that I think. I may be wrong, so, please tell me, if I am. SBU is good, necessary. SBU can never be trusted completely. Can never be accurate. This host has SBU=133s (about measurement method, see below), but 7.4-rc1, in a VM, in this same host, reported SBU=120s, yesterday, so one must be wrong, or, inaccurate. I have a script to generate the SBUs. However, each time it is executed in the same machine, the value is different, most of times by small amounts, but eventually, by large amounts (cannot remember if it could be double the value or such). Perhaps the machines have their own temper :-), they sometimes get slowing down, tired, have to leave X, clean swap, restart video card module, restart VM services,logout, get back... But, SBU is necessary, is a very good invention, cannot see how it could be done differently, and gives an order of magnitude for the build. About the method, I do aa thing similar to you, but run the script as normal user and install using DESTDIR. I believe this should not differ much from executing as root, in an empty tools, but if it is really very different, please, tell me. About the SBUs for mozilla's. I recall one day, VM with, perhaps, 512MB of RAM, it was taking much much longer than previous versions. So started watching libxul linking (did not understand it was linking, at that time). It was taking what I recall much more than double the time as previous ones (probably wrong memory is). Said in earlier post it had 1GB, but seems I started using them with 512MB. Point is, any changes, SBU different. When I'm putting a new version into BLFS I always try to measure it on the current release. So my recent changes were measured on 7.3, and whatever I do now will be measured on 7.4. I always do that, but thanks to remind me. Always, before, or asap, after, committing, try to build in the other machines. These will have j with the number of CPUs, intead, just to be sure it builds and works, not for SBU for the book. I very much appreciate your help, elsewhere, and also here, thanks. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Two difficulties (one in all versions)
Em 21-08-2013 19:18, Bruce Dubbs escreveu: Fernando de Oliveira wrote: Did not know if sending here, to lfs -dev or to blfs -support. 1. Happened with lfs-7.2,7.3 (both svn) and now with 7.4-rc1. ... as host), after logout and umount, had to reboot the system $ grep tty /etc/group tty:x:4: $ grep /dev/pts /etc/fstab devpts /dev/pts devpts gid=4,mode=620 0 0 But I was mounting and chrooting with gid 5, as per the book's instructions. Now, I have changed both to gid 5, to conform with the new versions, and the problem disappeared. Of course, had to change tape's gid to 4. I'm glad you figured it out. We don't change this type of thing lightly and there was a fair amount of discussion back when it was done. I remember (not details, though), but never thought It would affect me, 2. Happened, perhaps with all versions. Every time I try to create compressdoc with cat command, I obtain a corrupted unusable script. Then, use vim, instead, and copy/paste. I don't use compressdoc. I have: $ du -sh /opt/OpenJDK-1.7.0.40/man /opt/kde-4.10.3/share/man \ /opt/xorg /share/man /opt/qt-4.8.4/share/man /usr/share/man 1.8M/opt/OpenJDK-1.7.0.40/man 228K/opt/kde-4.10.3/share/man 17M /opt/xorg/share/man 16K /opt/qt-4.8.4/share/man 63M /usr/share/man That's about 2.1M on a 10G partition or about 0.02% How much space are Yes, it is not very much. Just followed the 3. After LFS Configuration Issues, without much thinking, after doing any times. It is a good point. I will stop using it, at the end, if you do not do it after each package update, could end with two versions, old compressed, new uncompressed, IIRC. That said, there may be an issue with the size of the copy buffer. When I try to select everything, I get a file of 10523 bytes, but when I do it in screen size blocks, the file is not corrupted and is 16870 bytes. I would do an md5sum on the result, but a user's result may be different if a blank line is added or missing from multiple copy/paste operations. Note too that when we are doing a copy from a browser, that it needs to remove html, so it may be a browser issue. It was not a big deal, but was worth mentioning. Now, I have better understanding; before, it was a mystery. Again, perhaps, a comment or note about the issue? This one, I think I can do. For example, just slight rephrasing: If you would prefer to download the file instead of creating it by typing or cut-and-pasting ... by Using cut-and-pasting, corrupted script creation has been reported. For this or if you would prefer to download the file, instead, ... Anyway, thanks for the explanation. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Certificate Authorities Certificates
Fernando de Oliveira wrote: Three points: First one, I could do, but the other ones, I would prefer, either is a too important decision or it is too big for me, but if necessary, can try. 1. Minor one, but noticed it, yesterday: In the book, cleaning: rm -r certs BLFS-ca-bundle* However, certdata.txt is left. Is it intentional, or should be cleaned too: rm -r certs BLFS-ca-bundle certdata.txt That's the downloaded data. Leaving it was intentional. Do you delete the tarballs after you install the package? 2. Minor one, too: Never understood: wget is explicitly used, but only optional. Perhaps, should be placed at Recommended or Required, alternatively, the comment a web browser may be used instead of wget but the file will need to be saved with the name certdata.txt could be closer to Optional? You can change it to Recommended. There are alternate ways to fetch the data, but the instructions do assume wget. 3. This, I think is important, although, can be delayed. However, it might be good having it for an eventual BLFS-7.4. DJ requested a blob with how to install or update cacerts for OJDK, in this page. I would like to open a ticket for us not to forget this. If needed, I could help. For example, if a xml could be sent to me with the places and some comments of the new items, and them, I could insert the commands. That's fine. You never need 'permission' to open a ticket. It can always be closed. Since I don't do much java, I really don't have an opinion of the OJDK cacerts, but it does seem reasonable. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Two difficulties (one in all versions)
Fernando de Oliveira wrote: Note too that when we are doing a copy from a browser, that it needs to remove html, so it may be a browser issue. It was not a big deal, but was worth mentioning. Now, I have better understanding; before, it was a mystery. Again, perhaps, a comment or note about the issue? This one, I think I can do. For example, just slight rephrasing: If you would prefer to download the file instead of creating it by typing or cut-and-pasting ... by Using cut-and-pasting, corrupted script creation has been reported. For this or if you would prefer to download the file, instead, ... Anyway, thanks for the explanation. How about a note. Doing a very large copy/paste directly to a terminal may result in a corrupted file. Copying to an editor may overcome this issue. The text should say copy and not cut. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
On Thu, Aug 22, 2013 at 09:45:03AM -0300, Fernando de Oliveira wrote: Em 21-08-2013 19:48, Ken Moffat escreveu: I will write down things that I think. I may be wrong, so, please tell me, if I am. SBU is good, necessary. SBU can never be trusted completely. Can never be accurate. This host has SBU=133s (about measurement method, see below), but 7.4-rc1, in a VM, in this same host, reported SBU=120s, yesterday, so one must be wrong, or, inaccurate. Or something else was using the processor when you first measured, or conceivably something in the kernel or VM improved. Perhaps you gave it more memory. I have a script to generate the SBUs. However, each time it is executed in the same machine, the value is different, most of times by small amounts, but eventually, by large amounts (cannot remember if it could be double the value or such). Perhaps the machines have their own temper :-), they sometimes get slowing down, tired, have to leave X, clean swap, restart video card module, restart VM services,logout, get back... But, SBU is necessary, is a very good invention, cannot see how it could be done differently, and gives an order of magnitude for the build. It will always differ, but hopefully not by more than a few seconds. OTOH if you only had one CPU then any other tasks running will make a noticeable difference. About the method, I do aa thing similar to you, but run the script as normal user and install using DESTDIR. I believe this should not differ much from executing as root, in an empty tools, but if it is really very different, please, tell me. Sorry - yes, I do this too when measuring for the book. By that time I've already installed the package and (hopefully) noticed if it works ok If you ever look at the wiki you might come across a few packages where I've noted variations of DESTDIR (typically INSTALLROOT). About the SBUs for mozilla's. I recall one day, VM with, perhaps, 512MB of RAM, it was taking much much longer than previous versions. So started watching libxul linking (did not understand it was linking, at that time). It was taking what I recall much more than double the time as previous ones (probably wrong memory is). Said in earlier post it had 1GB, but seems I started using them with 512MB. Point is, any changes, SBU different. Yes, agreed. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] strace
Just a note that strace-4.8 doesn't build with the current kernel
headers. Noted on the strace list on 13th August, but they don't
seem to have a fix. This looks as if something in the 3.10.x stable
series broke it. Error is -
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/building/strace-4.8'
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] strace
On Thu, Aug 22, 2013 at 05:06:44PM +0200, Armin K. wrote:
On 08/22/2013 04:39 PM, Ken Moffat wrote:
Just a note that strace-4.8 doesn't build with the current kernel
headers. Noted on the strace list on 13th August, but they don't
seem to have a fix. This looks as if something in the 3.10.x stable
series broke it. Error is -
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/building/strace-4.8'
ĸen
My system was built against 3.10.1 version of kernel api headers and I
didn't experience that problem.
The include/sys file comes from glibc. Looks as if
ptrace_peeksiginfo_args was added there in 2.18. Did you build strace
against glibc-2.18 ? I see that I used some earlier version of 3.10
last week, but with glibc-2.17, and strace-4.8 built ok there.
The only report that google finds is for 3.10.6 and glibc-2.18 :
http://comments.gmane.org/gmane.comp.sysutils.strace.devel/3239
I'm starting to think it might be glibc rather than the kernel
headers.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] strace
On 22.8.2013 20:42, Ken Moffat wrote:
On Thu, Aug 22, 2013 at 05:06:44PM +0200, Armin K. wrote:
On 08/22/2013 04:39 PM, Ken Moffat wrote:
Just a note that strace-4.8 doesn't build with the current kernel
headers. Noted on the strace list on 13th August, but they don't
seem to have a fix. This looks as if something in the 3.10.x stable
series broke it. Error is -
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/building/strace-4.8'
ĸen
My system was built against 3.10.1 version of kernel api headers and I
didn't experience that problem.
The include/sys file comes from glibc. Looks as if
ptrace_peeksiginfo_args was added there in 2.18. Did you build strace
against glibc-2.18 ? I see that I used some earlier version of 3.10
last week, but with glibc-2.17, and strace-4.8 built ok there.
The only report that google finds is for 3.10.6 and glibc-2.18 :
http://comments.gmane.org/gmane.comp.sysutils.strace.devel/3239
I'm starting to think it might be glibc rather than the kernel
headers.
ĸen
I have 2.17 installed. Waiting for linux 3.11 so I can rebuild Glibc
against its headers and update it to 2.18.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] acl
I just ran into a minor problem, but can't figure out how to best fix it in the book. acl installs /usr/lib/libacl.la. This file has the line: dependency_libs=' /usr/usr/lib/libattr.la' This should be /usr/lib/libattr.la. I don't see what is making this line. The obvious fix is to run a sed after installation, but is there a better way to do it? I found this when building consolekit. I don't know how many other packages will run into it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] acl
Bruce Dubbs wrote: I just ran into a minor problem, but can't figure out how to best fix it in the book. acl installs /usr/lib/libacl.la. This file has the line: dependency_libs=' /usr/usr/lib/libattr.la' This should be /usr/lib/libattr.la. I don't see what is making this line. The obvious fix is to run a sed after installation, but is there a better way to do it? I found this when building consolekit. I don't know how many other packages will run into it. Never mind. I noticed that we already make one correction to the file after installation. Might as well make another. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] acl
On 08/22/2013 10:23 PM, Bruce Dubbs wrote: Bruce Dubbs wrote: I just ran into a minor problem, but can't figure out how to best fix it in the book. acl installs /usr/lib/libacl.la. This file has the line: dependency_libs=' /usr/usr/lib/libattr.la' This should be /usr/lib/libattr.la. I don't see what is making this line. The obvious fix is to run a sed after installation, but is there a better way to do it? I found this when building consolekit. I don't know how many other packages will run into it. Never mind. I noticed that we already make one correction to the file after installation. Might as well make another. -- Bruce Hang on, I've got a better idea. I'll just make it like attr. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] acl
Armin K. wrote: On 08/22/2013 10:23 PM, Bruce Dubbs wrote: Bruce Dubbs wrote: I just ran into a minor problem, but can't figure out how to best fix it in the book. acl installs /usr/lib/libacl.la. This file has the line: dependency_libs=' /usr/usr/lib/libattr.la' This should be /usr/lib/libattr.la. I don't see what is making this line. The obvious fix is to run a sed after installation, but is there a better way to do it? I found this when building consolekit. I don't know how many other packages will run into it. Never mind. I noticed that we already make one correction to the file after installation. Might as well make another. Hang on, I've got a better idea. I'll just make it like attr. I've already fixed it and it's ready to commit. However, I can wait and revert. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r11672 - trunk/BOOK/postlfs/security
kre...@higgs.linuxfromscratch.org wrote: Author: krejzi Date: Thu Aug 22 13:45:41 2013 New Revision: 11672 Log: minor acl fixes. Modified: trunk/BOOK/postlfs/security/acl.xml trunk/BOOK/postlfs/security/attr.xml amp; -chmod -v 755 /usr/lib/libattr.so.1.1.0 amp;amp; +chmod -v 755 /usr/lib/libattr.so amp;amp; I think libattr.so is a symlink. These are the wrong permissions. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r11672 - trunk/BOOK/postlfs/security
On 08/22/2013 10:55 PM, Bruce Dubbs wrote: kre...@higgs.linuxfromscratch.org wrote: Author: krejzi Date: Thu Aug 22 13:45:41 2013 New Revision: 11672 Log: minor acl fixes. Modified: trunk/BOOK/postlfs/security/acl.xml trunk/BOOK/postlfs/security/attr.xml amp; -chmod -v 755 /usr/lib/libattr.so.1.1.0 amp;amp; +chmod -v 755 /usr/lib/libattr.so amp;amp; I think libattr.so is a symlink. These are the wrong permissions. -- Bruce Doesn't matter, still works fine. Shorter to write, safer if soname changes and it will always change permissions of the thing it's symlink to. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] strace
On 08/22/2013 01:42:11 PM, Ken Moffat wrote:
On Thu, Aug 22, 2013 at 05:06:44PM +0200, Armin K. wrote:
On 08/22/2013 04:39 PM, Ken Moffat wrote:
Just a note that strace-4.8 doesn't build with the current kernel
headers. Noted on the strace list on 13th August, but they don't
seem to have a fix. This looks as if something in the 3.10.x
stable
series broke it. Error is -
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/building/strace-4.8'
ĸen
My system was built against 3.10.1 version of kernel api headers
and I
didn't experience that problem.
The include/sys file comes from glibc. Looks as if
ptrace_peeksiginfo_args was added there in 2.18. Did you build strace
against glibc-2.18 ? I see that I used some earlier version of 3.10
last week, but with glibc-2.17, and strace-4.8 built ok there.
I also built strace-4.8 fine against linux-3.10, but did so under
uClibc.
Rob
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r11672 - trunk/BOOK/postlfs/security
Armin K. wrote: On 08/22/2013 10:55 PM, Bruce Dubbs wrote: kre...@higgs.linuxfromscratch.org wrote: Author: krejzi Date: Thu Aug 22 13:45:41 2013 New Revision: 11672 Log: minor acl fixes. Modified: trunk/BOOK/postlfs/security/acl.xml trunk/BOOK/postlfs/security/attr.xml amp; -chmod -v 755 /usr/lib/libattr.so.1.1.0 amp;amp; +chmod -v 755 /usr/lib/libattr.so amp;amp; I think libattr.so is a symlink. These are the wrong permissions. Doesn't matter, still works fine. Shorter to write, safer if soname changes and it will always change permissions of the thing it's symlink to. OK. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] strace
On Thu, Aug 22, 2013 at 04:10:58PM -0500, Rob Landley wrote: I also built strace-4.8 fine against linux-3.10, but did so under uClibc. I think it's a glibc problem - it's acquired something that was already in the kernel headers. But I may well have misunderstood. I'm puzzled that the strace developers knew of this [ I see it was xinglp who told them, so I guess he was running LFS ] but google didn't find any public mails from them about this. For the moment I don't _need_ strace so I'm happy to wait until something turns up. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] GnuPG
On 08/23/2013 12:40 AM, bdu...@higgs.linuxfromscratch.org wrote: Author: bdubbs Date: Thu Aug 22 15:40:33 2013 New Revision: 11674 Log: Update to gnupg-2.0.21. Can we make this one default and ditch 1.x version? Arch has done that too. Requires symlinks for gpgv and gpg to respective gpgv2 and gpg2 binaries in /usr/bin. They can't be installed together without some patching, ie they share some dirs (conflicts with some files might be present). I have been using such setup for some time and didn't notice any problems in either compiling packages which depend on GnuPG 1 or at runtime. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] GnuPG
Armin K. wrote: On 08/23/2013 12:40 AM, bdu...@higgs.linuxfromscratch.org wrote: Author: bdubbs Date: Thu Aug 22 15:40:33 2013 New Revision: 11674 Log: Update to gnupg-2.0.21. Can we make this one default and ditch 1.x version? Arch has done that too. Requires symlinks for gpgv and gpg to respective gpgv2 and gpg2 binaries in /usr/bin. They can't be installed together without some patching, ie they share some dirs (conflicts with some files might be present). I have been using such setup for some time and didn't notice any problems in either compiling packages which depend on GnuPG 1 or at runtime. That's OK with me. A quick check shows perl-modules, seahorse, gcr, mutt, mitkrb, and gpgme referencing gunpg. If they can use gnupg2 instead, then we can remove it. However, it is still being maintained. The last update was less than a month ago. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] GnuPG
On 08/23/2013 01:09 AM, Bruce Dubbs wrote: That's OK with me. A quick check shows perl-modules, seahorse, gcr, mutt, mitkrb, and gpgme referencing gunpg. If they can use gnupg2 instead, then we can remove it. However, it is still being maintained. The last update was less than a month ago. -- Bruce Yes, I know it's being maintained. Just no need for us to have two versions of someting that one version can cover. Maybe 1.x release is still required for some advanced stuff we don't cover. GNOME Stuff (seahorse, gcr) and gpgme works fine with 2.x version. mitkrb uses it only for key verification which should work fine. Dunno about mutt, but it works just fine with Thunderbird and engimail. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] GnuPG
On Fri, Aug 23, 2013 at 01:12:52AM +0200, Armin K. wrote: GNOME Stuff (seahorse, gcr) and gpgme works fine with 2.x version. mitkrb uses it only for key verification which should work fine. Dunno about mutt, but it works just fine with Thunderbird and engimail. I have to admit that I gave up trying to verify keys in mutt. From memory, it looked as if I would have to create my own key to do that, but nobody else is going to sign my key, so that seemed like overkill. The only signed mail I ever see is on public lists, so getting keys checked isn't even on my ToDo list. So don't let mutt stop us archiving gpg1. Unless someone is using mutt and shows that gpg2 doesn't work. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] lvm2
I am trying to update lvm2 and am running into a bit of trouble with the tests. The configure and make complete with out issue. I did a make install to a DESTDIR and that was OK too. The problem is 'make check'. If I run as a normal user, all the tests fail with what looks like permission problems. If I run the tests as root, the first test, normal:api/lvtest.sh just hangs waiting for something. I went back and tried the current version and got the same thing. The kernel does have RAID/LVM and Device Mapper Support. Any ideas? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
