Re: [blfs-support] Failed to boot from USB stick
>On Tue, 11 Mar 2014 20:08:45 +0100 >Alexey Orishko wrote: > I can't boot BLFS 7.4 system (Intel Atom 32-bit) from USB stick on > some motherboards, but I can do it on the same motherboard type with > different (old) BIOS version. > I've read BIOS release notes and found nothing relevant to the problem > neither seen anything significantly different in BIOS menu. > - If I connect the same USB stick to the motherboard with old BIOS, > it boots ok. > - I can boot from SATA HDD with exactly the same root fs as USB stick > (I've copied root partition with cpio and updated UUID value in grub > and fstab). > - I can boot from USB stick only if it has FAT32, for example MSDOS > boot disk or Ubuntu install disk made by Universal-USB-Installer.exe. > > I wonder, what else do I need to check in order to get to the bottom > of this problem? Returning back to the root of the problem, can you give a bit more light? If you have an USB with ext2 (or whatever), you can not boot a new BIOS, correct? If you have an USB with FAT32, and with the exact same filesystem (except ownership and permissions) that the USB with ext2 has, you can boot it? The question being, can you make a USB bootable just by switching the filesystem? And a thing I just came up with: does your ext2 USB have the "bootable" flag set on its boot partition? -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] WebKitGTK-1/Flash
>On Thu, 2 Jan 2014 16:21:57 +0100 >Aleksandar Kuktin wrote: > > >On Thu, 02 Jan 2014 12:43:45 + > >lf...@cruziero.com (akhiezer) wrote: > > I see 'lightspark' mentioned quite often; never tried it, or read up > > on it. > > I'll check it out next weekend and report back with the results. Veni, vidi, I need a new compiler. I use an old version of GCC (because it works and I'm lazy to recompile everything) and lightspark requires GCC-4.6 or newer. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] WebKitGTK-1/Flash
>On Thu, 02 Jan 2014 12:43:45 + >lf...@cruziero.com (akhiezer) wrote: > > > Date: Thu, 2 Jan 2014 11:33:49 + (GMT) > > From: Richard > > To: BLFS Support List > > Subject: Re: [blfs-support] WebKitGTK-1/Flash > > I am aware of this and would welcome a viable FOSS alternative. For > > the moment flash remains a necessity. It has been a couple of years > > since I looked at any FOSS flash alternatives - but my recollection > > is that they fell far short of the mark. > > > > ( - so does flash ;) ). > > I see 'lightspark' mentioned quite often; never tried it, or read up > on it. I'll check it out next weekend and report back with the results. > > So, does anybody have any other good ideas? Have I misunderstood > > some vital concept? One vital concept comes to mind: does uzbl understand the format that libflashplayer.so is in? Alternatively, can uzbl use some other plugin files originally compiled and linked for Firefox/Chromium? It has been ages since I last read anything about uzbl and I don't remember anything relating to the answer to the above question. That may be the best direction to try probing for now. *** @akhiezer: I'm cc'ing you in this e-mail because your e-mail (the post to which I am replying) has the Reply-To header field set, with your e-mail in it. I don't normally cc people when posting to the list, so that's why I'm pointing this out like this. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] WebKitGTK-1/Flash
>On Mon, 30 Dec 2013 11:41:26 + (GMT) >Richard wrote: > > Is there some 'trick' or undocumented procedure for building/using > webkitgtk-1 with flash? Some build flag that I may have missed or > variable which needs to be set? > > I have downloaded the appropriate archive from Adobe - with a readme > which tells me to put libflashplayer.so in the 'appropriate > directory' (not very helpful). A quick search around stackoverflow > tended to hint at directories such > as: /usr/lib/mozilla/plugins/ /opt/google/chrome/plugins so I have > copied the library to both locations with no success. I have searched > as best online and I can find nothing helpful. > > So - how do you guys get flash working? > > Many thanks, R. Well, you don't use WebKit with flash. You use flash with a browser. Assuming you downloaded what I think you downloaded from Adobe's site, you downloaded a binary browser plugin in a standard format (so that it can be used by all (for a certain value of "all") browsers). The way you go about using libflashplayer.so is that you first build a browser of your liking (again, assuming that browser supports the above mentioned "standard plugin format"). Then you install the browser and, depending on how exactly you built it, where you installed it, and what changes (if any) you made to the code before building, the browser will look for its plugins in a list of locations. You put libflashplayer.so in one of those locations so the browser can find it and you tell the browser to load and use the Flash plugin. The exact details of the last three steps depend on the browser. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Complete Backup of {,B}LFS
>On Sun, 22 Dec 2013 16:23:49 -0600 >Dan McGhee wrote: > > On 12/22/2013 03:25 PM, Aleksandar Kuktin wrote: > > > > [snip] > > > > $ mkdir /mnt/stuff > > $ mount /dev/of/root /mnt/stuff > > $ mount /dev/of/usr /mnt/stuff/usr > > $ cd /mnt/stuff > > $ find . -print0 > /tmp/list > > $ cpio -p -0md --sparse /mnt/destination < /tmp/list > > > > That should collect everything and give you the result which is as > > close as you can get without cloning the underlying > > device/filesystem. > > > This looks really interesting and I want to "play" with it. But what > I want *is* a clone, an exact copy, of what I have now. > > Dan > Well, in that case, dd is probably your friend. dd if=/dev/source of=/dev/destination bs=512 Ofcourse, this only works if the destination partition is at least as big as the source partition. For best results, the two should be identical. If destination is bigger than the source, the extra space in the destination will be unused. I think I read somewhere that some program from e2fsprogs can be used to resize ext2/ext3 filesystems, but don't take my word for it. The other way of reclaiming the dead space is to resize partitions however this is a very touchy procedure, may not work on EFI/UEFI systems (depending on how they actually physically store partition information) and requires manually calculating offsets and filesystem and partition sizes. I did this once or twice (including recovering my HDD after accidentally overwriting the partition table) and can walk you through the process, but unless you *need* or *want* the modification timestamps on you directories to be exactly the same as on the original filesystem, you are much better off using cpio. Note that you can also clone devices with cat (and probably a host of other even more convoluted methods): cat < /dev/source > /dev/destination ...but dd is better because it prints out exact statistics on what it did while cat either prints nothing at all or just spits out a terse and not entirely informative error string. On the subject of cloning filesystems (as opposed to cloning devices), I come up blank with names of programs that can do that, even though there is probably at least one program that can do that. Ow, and one other thing: if the destination is a raw flash memory device (the kind you can find in Android phones), don't use either dd or cat because raw flash needs to be written accoding to a special protocol. There are specialized programs that do that, and you should use one of those. -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Complete Backup of {,B}LFS
>On Sun, 22 Dec 2013 12:06:23 -0600 >Dan McGhee wrote: > 1. Set up and mount a new partition for this system--done > 2. As root in / run: $ find . -xdev -depth -print0 | cpio --null -pd > > 3. Enter chroot environment as in LFS book > 4. Reconfigure kernel > 5. Boot new system Assuming find does not choke on something or makes cpio choke on something, I think this is a good plan. But there is a better one: make a new mount point and mount your / there. If you want to, mount additional filesystems under it, if you need to do that. Then, run find over the newly mounted filesystem(s) and cpio from the mount point. $ mkdir /mnt/stuff $ mount /dev/of/root /mnt/stuff $ mount /dev/of/usr /mnt/stuff/usr $ cd /mnt/stuff $ find . -print0 > /tmp/list $ cpio -p -0md --sparse /mnt/destination < /tmp/list That should collect everything and give you the result which is as close as you can get without cloning the underlying device/filesystem. -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] AbiWord build report (Was: Re: Ways to convert a .doc to something more civil.)
>On Mon, 09 Dec 2013 21:26:22 + >lf...@cruziero.com (akhiezer) wrote: > > > Date: Mon, 9 Dec 2013 20:59:51 +0100 > > From: Aleksandar Kuktin > > To: blfs-support@linuxfromscratch.org > > Subject: [blfs-support] AbiWord build report (Was: Re: Ways to > > convert a .doc to something more civil.) > > > . > . > > and pretty straightforward, unlike OpenOffice (I imagine > > LibreOffice is not mutch better). If only I can find > > a .xls/.xlsx/.od* spreadsheet and presentation program like > > AbiWord, all would be well. > > > > > Outside of office-suites, gnumeric (spreadsheet) might be worth a > look. If it's part of GNOME as its name suggests, I'm not likely to take too hard of a look. I'll look it up. > (Quite liked it, and kspread, 'way back in the day. These days, > rather than 'pollute' main os with junk for dealing with (usually > proprietary) junk, will for some types of situation, just tend to use > a distro in a vm - kindof sandboxing.) > > > > rgds, > akh -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Ways to convert a .doc to something more civil.
>On Mon, 9 Dec 2013 07:04:14 -0500 >LM wrote: > > Aleksandar Kuktin wrote: > >Is there a way to convert .doc documents to something else > >(preferably PDF) WITHOUT using *Office? > > If you're trying to convert a document from Word format, you may want > to take a look at antiword: > http://www.winfield.demon.nl/ > > Sincerely, > Laura > http://www.distasis.com/cpp Will take a look at it. Just not tonight. -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] AbiWord build report (Was: Re: Ways to convert a .doc to something more civil.)
>On Sat, 7 Dec 2013 01:34:24 +0100
>Aleksandar Kuktin wrote:
>
> Okay, I got it. I love the font AbiWord is using by default.
>
> A couple of things needed a couple of patches. I'll push them to the
> list tomorrow, it's late now.
Well, it took me a while.
These are some of AbiWords dependencies:
fribidi >= 0.10.4
glib-2.0 >= 2.6.0 gthread-2.0 >= 2.6.0 gobject-2.0 >= 2.6.0
libgsf-1 >= 1.12
wv-1.0 >= 1.2.0
enchant >= 1.2.0 gio-2.0
cairo-pdf cairo-ps pangocairo
gtk+-2.0 >= 2.12.0 gtk+-unix-print-2.0 librsvg-2.0 >= 2.16.0
Others are libpng, jpeg, zlib and possibly a few others. Libgsf also
has a dependency on libxml2.
Libgsf is the GNOME structured file library and you will have problems
with her. Basically, libgsf has a header dependency on libxml2 but it's
pkg-config file makes no mention of it. As a result of that, unless the
package requiring libgsf has the foresight to also include libxml2's
header path in its -I argument list, the build will fail. wv2 has this
problem. I solved this by adding an extra compile and link option flag
into libgsf's pkg-config file. The proper solution is to make it
include libxml2's pkg-config file to get the site-specific options in a
site-agnostic way.
AbiWord can not be built against wv2, it *needs* wv-1.*. Keep that in
mind.
New versions of packages, namely glib and libpng will give you some
headaches. I have glib-2.34.0 and libpng-1.5.10. Sometime ago, glib
decided that you can not just include its various headers directly, but
that you can only include glib.h. It will give an error if you try to
do it otherwise. Attached patches abiword-2.8.6--new_glib-1.patch and
fribidi-0.19.6--novi_glib.patch solve that particular problem.
Aditionally, libpng has, since version 1.5 changed the API and hidden a
bunch of data structures that were previously visible. As a
consequence, some packages need to be patched - among them AbiWord. The
attached patch abiword-2.8.6--libpng15-1.patch does that task.
Once libgsf has been fixed and others patched, building it is a breeze
and pretty straightforward, unlike OpenOffice (I imagine LibreOffice is
not mutch better). If only I can find a .xls/.xlsx/.od* spreadsheet and
presentation program like AbiWord, all would be well.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
diff -Naur abiword-2.8.6-old/src/af/util/xp/ut_png.cpp abiword-2.8.6-new/src/af/util/xp/ut_png.cpp
--- abiword-2.8.6-old/src/af/util/xp/ut_png.cpp 2008-02-24 04:33:07.0 +0100
+++ abiword-2.8.6-new/src/af/util/xp/ut_png.cpp 2013-12-07 00:57:34.0 +0100
@@ -71,7 +71,7 @@
* the normal method of doing things with libpng). REQUIRED unless you
* set up your own error handlers in the png_create_read_struct() earlier.
*/
- if (setjmp(png_ptr->jmpbuf))
+ if (setjmp(png_jmpbuf(png_ptr)))
{
/* Free all of the memory associated with the png_ptr and info_ptr */
png_destroy_read_struct(&png_ptr, &info_ptr, static_cast(NULL));
diff -Naur abiword-2.8.6-old/src/wp/impexp/gtk/ie_impGraphic_GdkPixbuf.cpp abiword-2.8.6-new/src/wp/impexp/gtk/ie_impGraphic_GdkPixbuf.cpp
--- abiword-2.8.6-old/src/wp/impexp/gtk/ie_impGraphic_GdkPixbuf.cpp 2009-07-01 06:02:04.0 +0200
+++ abiword-2.8.6-new/src/wp/impexp/gtk/ie_impGraphic_GdkPixbuf.cpp 2013-12-07 01:13:30.0 +0100
@@ -185,7 +185,7 @@
/** needed for the stejmp context */
UT_Error IE_ImpGraphic_GdkPixbuf::_png_write(GdkPixbuf * pixbuf)
{
- if (setjmp(m_pPNG->jmpbuf))
+ if (setjmp(png_jmpbuf(m_pPNG)))
{
DELETEP(m_pPngBB);
png_destroy_write_struct(&m_pPNG, &m_pPNGInfo);
@@ -446,7 +446,7 @@
* the normal method of doing things with libpng). REQUIRED unless you
* set up your own error handlers in the png_create_read_struct() earlier.
*/
- if (setjmp(m_pPNG->jmpbuf))
+ if (setjmp(png_jmpbuf(m_pPNG)))
{
/* Free all of the memory associated with the png_ptr and info_ptr */
png_destroy_write_struct(&m_pPNG, &m_pPNGInfo);
diff -Naur abiword-2.8.6-old/goffice-bits/goffice/app/goffice-app.h abiword-2.8.6-new/goffice-bits/goffice/app/goffice-app.h
--- abiword-2.8.6-old/goffice-bits/goffice/app/goffice-app.h 2007-01-17 00:17:27.0 +0100
+++ abiword-2.8.6-new/goffice-bits/goffice/app/goffice-app.h 2013-12-07 00:49:08.0 +0100
@@ -22,7 +22,7 @@
#ifndef GOFFICE_APP_H
#define GOFFICE_APP_H
-#include
+#include
G_BEGIN_DECLS
diff -Naur abiword-2.8.6-old/src/af/util/xp/ut_go_file.h abiword-2.8.6-new/src/af/util/xp/ut_go_file.h
--- abiword-2.8.6-old/src/af/util/xp/ut_go_file.h 2009-08-27 15:27:10.0 +0200
+++ abiword-2.8.6-new/src/af/util/xp/ut_go_file.h 2013-12-07 00:53:26.0 +0100
@@ -31,7 +31,6 @@
#include
#include
-#include
#include
G_BEGIN_DECLS
diff -Naur fribidi-0.19.6-old/charset/fribidi-char-sets.c fribidi-0.19.6-new/charset/fribidi-char-sets.c
--- fribidi-0.19.6-old/charset/f
Re: [blfs-support] Ways to convert a .doc to something more civil.
>On Fri, 06 Dec 2013 22:37:57 +0100 >"Armin K." wrote: > You could use AbiWord if you don't want to build entire Libreoffce. > > But it seems that wv package (available in BLFS) could help you do > what you want. > > See http://wvware.sourceforge.net/ "wv Utilities". They recommend > using abiword executable though. Okay, I got it. I love the font AbiWord is using by default. A couple of things needed a couple of patches. I'll push them to the list tomorrow, it's late now. -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Ways to convert a .doc to something more civil.
Hi all! Is there a way to convert .doc documents to something else (preferably PDF) WITHOUT using *Office? The thing is that I have moved to new harware, rebuilt most of (B)LFS, but would want to read these bunch of documents without first having to spend the entire weekend hacking OpenOffice. It has been 3 or 4 years since I last built it and I remember it not being a breeze. BTW, this e-mail is not signed because of a mixup with keys when I migrated to the new machine. I'll get them when I get back home for Christmas. I also forgot my SSL certificate files so now I can't really SSL around the net - at least untill I rebuild them. I *really* hope I remembered to bring the PGP keys for various packages I spent years collecting. Have to check that in the morning. -- You don't need an AI for a robot uprising. Humans will do just fine. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Comment/Question/Flame on "probably the most used admin tool", 'find'
>On Thu, 7 Nov 2013 16:02:43 -0500 >alex lupu wrote: > > [snip] > > []% date > Thu Nov 7 13:05:10 EST 2013 > []% hrs2date 2013-11-07 > toDATEhrs = 13 > []% hrs2date 2013-11-06 > toDATEhrs = 37 > []% hrs2date 2013-11-05 > toDATEhrs = 61 > []% hrs2date 2013-11-04 > toDATEhrs = 85 > []% hrs2date 2013-11-03 > toDATEhrs = 110 # Oops! 110 - 85 = 25, NOT 24 !!! > []% hrs2date 2013-11-02 > toDATEhrs = 134 I can not replicate this oops. No, wait. I can. Guess the clock change was on 2013-10-27th where I am. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Comment/Question/Flame on "probably the most used admin tool", 'find'
>On Thu, 7 Nov 2013 16:02:43 -0500 >alex lupu wrote: > [snip] > #!/bin/bash > # hrs2date > if [ "$1" == "" ]; then > # for people who didn't read my post > echo "Enter a date (-mm-dd)" ; exit 2 > fi > > DATE=$1 > > NOWsecs=`date +%s` # This moment (in sec. since > Jan. 1, 1970) > DATEsecs=`date -d $DATE +%s` # DATE's seconds since Jan. 1, > 1970 > > toDATEsecs=$(( $NOWsecs - $DATEsecs )) > toDATEhrs=$(( $toDATEsecs / 3600 )) # damn the > minutes. > > echo toDATEhrs = $toDATEhrs This is actually very good. I'm gonna use this algorithm from now on. :) -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to clean up /usr/lib/
>On Thu, 17 Oct 2013 13:22:26 -0300 >Fernando de Oliveira wrote: > Actually, when it was closed, I was agreeing to close it, but because > it was "overcomebyevents". It is too long since the issue. Today, > even a small sentence such as "If jpeg-8d is installed, remove it, > before installing libjpeg-turbo" seems not so relevant, I am not sure > anymore if it would be useful, or just reply to support? I think abberations like should be noted in the book. At the very least, it will alert the reader that such things are possible and will therefore probably shorten the time said reader needs to find the error if such behaviour repeats with other packages. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to clean up /usr/lib/
>On Thu, 17 Oct 2013 10:20:47 -0500 >Bruce Dubbs wrote: > > Aleksandar Kuktin wrote: > >> On Wed, 16 Oct 2013 22:52:00 -0500 > >> Bruce Dubbs wrote: > >> > >> alex lupu wrote: > >>> Not pretty. Apparently, a sizable dead space waiting to be > >>> reclaimed. > >> > >> Actually, the files needed are the .so and .so.0 links and, of > >> course, the file they point to. The .so file is what the linker > >> looks for and the loader looks for the .so.0 file. You can delete > >> the rest. > > > > Isn't it that the run-time linker uses whatever *.so was pointing > > to at build time? > > The build time linker embeds what the .so file says to use. > Generally it's the so.# value. Devs can then update the library if > the ABI doesn't change, but the internals do. > > If the ABI changes, then the library version (so.#) needs to be > incremented. It is valid to have something like: > > lib.so -> lib.so.2 > lib.so.2 -> lib.so. > lib.so.1 -> lib.so. > lib.so. > lib.so. > > Apps can then use whatever was current when built, but new apps will > use the .2 version. > >-- Bruce Aha. So the file (*.so after deref.) itself has its name printed on its forehead, the build linker puts that name into the executable (or library, if the library built links to other libraries) and then the run-time linker uses that to find the *.so# file needed. Okay, thanks. :) -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to clean up /usr/lib/
>On Wed, 16 Oct 2013 22:52:00 -0500 >Bruce Dubbs wrote: > > alex lupu wrote: > > Not pretty. Apparently, a sizable dead space waiting to be > > reclaimed. > > Actually, the files needed are the .so and .so.0 links and, of > course, the file they point to. The .so file is what the linker > looks for and the loader looks for the .so.0 file. You can delete > the rest. Isn't it that the run-time linker uses whatever *.so was pointing to at build time? As for deleting, perhaps a script is in order. The script would collect all the *.so links, dereference the chain they point to and delete the rest. Some constrains should be in order however, so maybe the script should delete all files that begin with the "*.so" part of *.so.* and are not being pointed to. Also, one may create a second script that goes through all the executables in */bin and collects the libraries used for run-time linking. These would then be exempt from deletion by the first script. This is all still reasonably risky, ofcourse. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gvolwheel
>On Mon, 7 Oct 2013 02:04:43 +0200 >Aleksandar Kuktin wrote: > > >On Mon, 7 Oct 2013 01:53:31 +0200 > >Aleksandar Kuktin wrote: > > > > First, sorry for the delay. I've only just now got to trying this > > thing. Aaaand... how do you start this? > > > > [blahblahblah] > > > > Aha, OK! Your mixer has to have the PCM device as well. So, if it does > not appear on alsamixer, then you have to start some program that will > instantiate (or whatever) the PCM and *then* you can start gvolwheel, > and you do so without any arguments. > > But, I was hoping I could run it even without the system tray. > Unfortunately, no, you NEED a windowmanager that can do that. Good > thing I still have those blackbox sources lying around. Be back in a > second. Or two. > Right, so the blackbox doesn't compile (again) but IceWM did, and I managed to make gvolwheel run, try it out and see that it works. Since you asked for version of cairo, my is: cairo-1.11.2. Everything has been built before gvolwheel, and nothing (but IceWM) has been built after gvolwheel. Obviously. Now, if only my default window manager (dwm) supported the tray... -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gvolwheel
>On Mon, 7 Oct 2013 01:53:31 +0200 >Aleksandar Kuktin wrote: > > First, sorry for the delay. I've only just now got to trying this > thing. Aaaand... how do you start this? > > [blahblahblah] > Aha, OK! Your mixer has to have the PCM device as well. So, if it does not appear on alsamixer, then you have to start some program that will instantiate (or whatever) the PCM and *then* you can start gvolwheel, and you do so without any arguments. But, I was hoping I could run it even without the system tray. Unfortunately, no, you NEED a windowmanager that can do that. Good thing I still have those blackbox sources lying around. Be back in a second. Or two. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gvolwheel
>On Sat, 5 Oct 2013 00:38:02 +0100 >Ken Moffat wrote: > > On Fri, Oct 04, 2013 at 05:34:16AM +0200, Igor Živković wrote: > > On 10/04/2013 04:12 AM, Aleksandar Kuktin wrote: > > > > > > Well, I use raw alsa but now you got me interested in gvolwheel. > > > Is it a GNOME specific application, or can it be run without any > > > desktop environments? > > > > It is GTK+3 specific which almost as bad as GNOME. :-) > > > LOL, but yes, gtk+-3 is heading that way. Gvolwheel needs a > windowmanager which provides a tray. Works in icewm. I don't use > DEs. It _only_ works with the default alsa output (/dev/mixer) - > one of my boxes with an intel HDMI chip defaults to using HDMI which > is useless for me : alsa can be overridden, but my attempts to force > gvolwheel to work there only succeeded once - maybe I'll need to look > for another lightweight volume control. > > The 0.7 version was gtk+-2, but I had to build gtk+-3 for audacious > so I went with 1.0. > > ĸen First, sorry for the delay. I've only just now got to trying this thing. Aaaand... how do you start this? I was under the impression that you only type `gvolwheel' and that the thing automatically starts and sprouts rainbows and what not. But I got an enigmatic message that "Error opening mixer device". After delving into the source, I determined that I need to pass it an argument and experimented with '-d hw:1' (as per the --help text) and what not, but to no awail. Sometimes ALSA reports something like $gvolwheel -d /dev/mixer ALSA lib control.c:882:(snd_ctl_open_noupdate) Invalid CTL /dev/mixer Error opening mixer device othertimes I just get $gvolwheel -d 'hw:1' Error opening mixer device I could dig deeper, but is there a known-to-work way to start it? Oh, and BTW, the BLFS page on gvolwheel should be updated to also include Glib as a dependency (although Glib is also a dependency of GTK+-3). I tried all this with alsa-utils-1.0.24.2, GTK+-3.2.1, Intltool-0.50.0 and XML::Parser-2.41. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] google chrome browser building woes
>On Sat, 5 Oct 2013 13:11:05 -0400 >alex lupu wrote: > I told integ that in my experience with Gmail, my links, no matter > how long, seem to always arrive at the destination in one piece, > ready for the addressee to use. > As further proof I re-sent him his original address using Gmail, _and_ > if he would get it correctly in one piece, ready to use, I dared offer > (humbly) > Gmail as an alternative in these "tricky" situations. > End of story. Oh! I'm sorry. Terribly sorry. I misunderstood what was going on. I thought that *you* and not Lux-integ were the one having problems since your mail comes from a Gmail address, while Lux-integ's comes from a Btconnect address. But it turns out that that was the opposite of what really happened. And there is nothing wrong, strange or bad in using a technological solution without knowing its underpinnings such as protocols. I'm sorry if I came out that way. I didn't mean to. Text characters have a way of not being able to transmit emotion together with words. I wanted to help and, in the case web interface was the problem, point out that there is a way around it, but it just came out bad. Really bad. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] google chrome browser building woes
>On Sat, 5 Oct 2013 11:00:18 -0400 >alex lupu wrote: > > Hi integ, > > > the bottom half ... > > < broken link to be copied and pasted> > > I'm re-sending the link you submitted: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-30.0.1599.66.ebuild?view=markup > > _If_ it arrives in one piece at a destination, maybe for long links, > an alternative would be to use (I hate to say this) Google Gmail. > > Cheers, > -- Alex Is that because of the web interface? You can also use Gmail with a mail program and use Google's servers merely as relays. That's what I have been doing for ... lemme just check the mail archive... 4 years. Give or take. For this, you can use either IMAP or POP3/SMTP. Instructions can be found somewhere in the profane depths of Google's help pages. If you want to use POP3/SMTP like I do, your POP3 server is pop.gmail.com, you use port 995 and SSL to connect to it. Interestingly, SSL is mandatory (and pretty much always was). Your SMTP server is smtp.gmail.com with port 465 and also mandatory SSL. Your MUA/MTA should be able to deal with authentication details (passwords) on its own. For sending, you may want to select "authenticate with POP3 before SMTP" if your client gives you the option (not sure if it's mandatory, but works for me). -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gvolwheel
>On Fri, 04 Oct 2013 05:34:16 +0200 >Igor Živković wrote: > > On 10/04/2013 04:12 AM, Aleksandar Kuktin wrote: > >> On Fri, 4 Oct 2013 02:38:58 +0100 > >> Ken Moffat wrote: > >> > >> Is anyone apart from me using gvolwheel ? > >> > >> [snip] > >> > >> In the meantime, comments from anyone else who has built > >> gvolwheel on recent cairo (particularly answering "does it > >> work ?", with the cairo version) would be welcome. I suppose most > >> people are using that [ expletive deleted ] package called pulse ? > >> > >> ĸen > > > > Well, I use raw alsa but now you got me interested in gvolwheel. Is > > it a GNOME specific application, or can it be run without any > > desktop environments? > > It is GTK+3 specific which almost as bad as GNOME. :-) > I'll give it a try later today. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gvolwheel
>On Fri, 4 Oct 2013 02:38:58 +0100 >Ken Moffat wrote: > > Is anyone apart from me using gvolwheel ? > > [snip] > > In the meantime, comments from anyone else who has built gvolwheel > on recent cairo (particularly answering "does it work ?", with the > cairo version) would be welcome. I suppose most people are using > that [ expletive deleted ] package called pulse ? > > ĸen Well, I use raw alsa but now you got me interested in gvolwheel. Is it a GNOME specific application, or can it be run without any desktop environments? -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] ipv6/ipv4 forwading question//update
>On Tue, 16 Jul 2013 20:23:54 +0100 >"lux-integ" wrote: > I tried > iptables \ > -A input \ > -p tcp \ > -m mac \ > --mac $badMAC \ > -j DROP > > > where badMAC="ff ff ff ff > ff ff 11 22 33 44 55 66 77 88" > > but it made no difference $badMAC should be 11:22:33:44:55:66. What you see in: 1122 3344 5566 7788 ...is the link-level header. I don't know how much you worked with this, so I'll just drop a wide explanation. Apologies if you already know this. When analyzing Internet, or any packet network, or infact any network at all, people have decided to talk about layers (or levels). A layer encompases one complete part of all the work that needs to be done to get the message across. There is a relatively nice Wikipedia page at https://en.wikipedia.org/wiki/Internet_protocol_suite that explains much of this (if in perhaps too much detail). There is a more novice-friendly document at http://www.netfilter.org/documentation entitled "Networking Concepts HOWTO". I learned what Internet actually *IS* by reading that document. So, basically, now that I have bailed on explaining layers (and you either know this already or have just learned it), lets just focus on the link layer. This encompases the packets that ethernet cards send to each other. Like internet packets, these have headers and payloads (and checksums). Headers consist of the following: 1. destination address (6 octets) 2. source address (6 octets) 3. type field, called ethertype (2 octets). There is an elaborate diagram with a jumbo explanation on https://en.wikipedia.org/wiki/Ethernet_frame . So, the interpretation of the header your kernel gave us is: "Packet from 11:22:33:44:55:66 (which, incidentaly, is a broadcast address and therefore probably falls under the definition of 'martians'), for destination ff:ff:ff:ff:ff:ff (which is a global broadcast address - nothing strange or unusual about that) with the ethertype 0x7788 (unknown ethertype)". Seeing as how the source MAC is a broadcast address, disabling the logging of martians will probably remove that as well. However, I have to point out that the address given by the kernel may not be correct. Namely, with the hexdump the kernel gave us the ASCII interpretation of that dump. The string "Oj}" should really be "0x4f, 0x6a, 0x7d". I don't know how did that happen. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] ipv6/ipv4 forwading question//update
>On Tue, 16 Jul 2013 12:23:15 -0500 >Bruce Dubbs wrote: > > Aleksandar Kuktin wrote: > > > If you could make it not log martians, you should be set. There's an > > option somewhere in iptables manpage but it's been ages since I last > > read it. > > No, it's in the kernel: > > echo "0" > /proc/sys/net/ipv4/conf/all/log_martians > > There are several other places for specific control: > > /proc/sys/net/ipv4/conf/default/log_martians > /proc/sys/net/ipv4/conf/eth0/log_martians > /proc/sys/net/ipv4/conf/lo/log_martians > >-- Bruce Whoopsie. Also - I like the redundancy embeded in numerous log_martians options. :) -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] ipv6/ipv4 forwading question//update
>On Tue, 16 Jul 2013 17:16:15 +0100 >"lux-integ" wrote: > I had the system running fine for a day then sudddenly I keep > getting these flood of lines like the below in /var/log/messages:- > > (remark the internal net does not use the 192.168.2.0/ subnet ) > > ## > Jul 16 13:37:50 biker kernel: [ 57.617604] IPv4: martian source > 192.168.2.254 from 192.168.2.1, on dev eth1 > Jul 16 13:37:50 biker kernel: [ 57.622549] ll header: : ff > ff ff ff ff ff 11 22 33 44 55 66 77 88Oj}... > ## > > I have checked the 48-bit mac code wich I gave as as 11 22 33 etc > does not represent the MAC address of the NIC asigned as eth1 ( or > any ther NIC on tjhe mchine. ) Seems like someone is ratcheting the doors of your digital fortress. Not sure about where was that 192.168.2.1 packet captured. I think you said something about the ethernet being on the inside in your first e-mail. But while that packet is excusable, the other one (the one with the bogus MAC adress) is not. And BTW, it's pretty obvious that is a bogus packet. There is a nice series of numbers which extends into the ethertype field and probably into the rest of the packet. Now, generally, this is normal if troubling. From my firends stories, I concluded that those living outside any firewalls have this sort of thing happen to them constantly. We never were able to figure out if it was the ISP that sent out such packets or someone masquerading as the ISP but we did conclude that you don't want to live without a firewall, and a good one at that. You can have even more hair-raising fun if you set up tcpdump on your outside interface and then later go through all the crap it sniffed up. Just make sure to inform (and get consent from, if applicable) all other users of your sniffing router that packet capture is live. You'll probably have to make it not record TCP streams though, because that will eat up your hard drive in three to four hours. And make you wonder how the hell does NSA plan to capture AND STORE all Internet traffic starting this september. > I also put a line such as > iptables -A INPUT -s 192.168.2.1-192.168.2.254 > -j DROP > > (or some such ) > but it made zilchdifference. If you could make it not log martians, you should be set. There's an option somewhere in iptables manpage but it's been ages since I last read it. No idea how to make it not log bogus MAC addresses, though. >On Tue, 16 Jul 2013 10:24:49 -0400 >"Baho Utot" wrote: > > https://en.wikipedia.org/wiki/Martian_packet Huh? I thought only 127.0.0.1 is martian. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] SDL-1.2.15 Build Fails (chrooted environment)
>On Sat, 13 Jul 2013 20:51:33 -0500
>Tyrin Price wrote:
>
> On 07/13/2013 08:57 PM, Aleksandar Kuktin wrote:
> > Since LONG64 is not defined in sources of either package, you might
> > want to first check the build log (you log the build, right?).
> I have not been... by this do you mean redirecting stdout and stderr
> to a file?
Yes.
> I booted my LFS partition and tried it with the same negative result.
Hmm.. You tried it from the beggining, right? Configure, make, make
install. I suppose you did.
After you try it all again with logging, and if it fails, check to see
if there are any mention (in the sense of definitions) of LONG64 in the
log, and also in the working directory.
grep --color -Hn -C1 LONG64 your_log_file.log
find /your/working/directory -exec grep --color -Hn -C1 LONG64 {} \;
If there are no results, and especially if noone else has a solution,
then things are about to get really, really messy.
What architecture are you using? What does `uname -m' say?
--
You don't need an AI for a robot uprising.
Humans will do just fine.
signature.asc
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] SDL-1.2.15 Build Fails (chrooted environment)
>On Sat, 13 Jul 2013 20:10:20 -0500 >Tyrin Price wrote: > > I get the following error in my LFS-7.3 build during the make of > SDL-1.2.15 which says it builds on LFS-7.3 > > In file included from ./src/video/x11/SDL_x11dyn.c:96:0: > ./src/video/x11/SDL_x11sym.h:168:1: error: conflicting types for > '_XData32' In file included from ./src/video/x11/SDL_x11dyn.h:34:0, > from ./src/video/x11/SDL_x11dyn.c:26: > /usr/include/X11/Xlibint.h:595:12: note: previous declaration of > '_XData32' was here > make: *** [build/SDL_x11dyn.lo] Error 1 > > I am trying to build in a chroot environment on my main distribution > (Debian Wheezy). > > Is that what is causing the problem? DO I need to actually boot my > LFS for this one? > > -- > > -=[Ty]=- > No... This appears to be a problem where two headers collide, trying to both define the same thing. I don't know if this is a issue known to others, so I'll just try to make myself usefull and write up what I find while digesting the issue. The collision appears to be between the X system headers and SDL headers. The SDL version you are using is the same one I am using (I have no problems). Xlibint.h is coming from libX11, and _XData32() has been in there since 2004, accoding to my copy of the git repository. This is getting interesting. From the header, I see that the macro LONG64 needs to be defined for the libX11's definition of _XData32() to go live. At the same time, that same definition in SDL_x11sym.h is also under the control of by the same macro. It also has the following comment: /* Not required...these only exist in code in headers on some 64-bit platforms, and are removed via macros elsewhere, so it's safe for them to be missing. */ So, from all this, it would seem that on your system, LONG64 gets defined, but on for example, my system it does not. Since LONG64 is not defined in sources of either package, you might want to first check the build log (you log the build, right?). See if there are some `-DLONG64' flags passed to the compiler. There are none in my logs. Maybe some have been added by `./configure'? If that fails, I guess you might as well try booting your system and trying it like that. Doesn't seem to me that there should be a reason your build fails when it passes for others. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] ipv6/ipv4 forwading question
>On Fri, 12 Jul 2013 23:19:51 +0100 >"lux-integ" wrote: > > > greetings > > I have a computer with blfs two network cards and a pppmodem. One > card has an ipv6 address the other ipv4 as does the ppp interface. > > I am not bothering with ipv6 for now and for packet-routing I use > the > > echo 1 > /proc/sys/net/ipv4/ip_forward (as in the blfs book ) and > seemingly > get routing for ipv4. However as soon as I enable iptables > forwarding seems to dissappear > > Do I need to enable ipv6 frwarding as well and if so how so? > Ideas on where I am going wrong would be gratfully received. > > thanks in advance. > > luxInteg Perhaps the firewall is eating the packets? The `filter' table of iptables has the FORWARD chain. If it is empty and set to policy "DROP", then the firewall will drop all packets to be forwarded. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adding 32-Bit Libraries to an Existing 64-Bit LFS-7.3?
>On Thu, 04 Jul 2013 22:23:03 -0500 >Tyrin Price wrote: > > On 07/04/2013 09:51 PM, Aleksandar Kuktin wrote: > > an happen if you > > set /tools/bin/gcc to try using /lib/libc.so. The symlink hack I > > suggested is only really usefull for running applications. It should > > never be used for building otherwise you run the risk of opening the > > gates of hell. > Thanks for the pointers. I may just rebuild with clfs. I need to > install the 32-bit Adobe AIR and I am not sure if the method you > outline will work for me or if I will inadvertently open the gates of > hell. :-) First build what you need from CLFS, then link the linker into /lib and start your application. That way you will never overlap building and running. > Still, that is a lot of work when I really only need one 32-bit app. Yeah, I know. I also recently had to make a piece of proprietary software run on my system, but the documentation specified that the application needed libstdc++.so.5. That version of the standard C++ library last shipped with GCC-3.. So yeah, I built the ancient GCC just for a single old library. :) Ofcourse, later on it turned out that the application will run perfectly well with the current library (libstdc++.so.6). -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adding 32-Bit Libraries to an Existing 64-Bit LFS-7.3?
>On Thu, 4 Jul 2013 20:34:54 -0500 >Tyrin Price wrote: > > > You can use CLFS instructions to build the 32-bit /tools directory > > and then put a link to /tools/lib/ld-linux.so.2 into /lib. > > > > This way, when the application requests the /lib/ld-linux.so.2 > > dynamic linker, it will get one and the linker will then use > > libraries in /tools for linking. > > The linker will automatically use libraries in /tools just by putting > a symlink to /tools/lib/ld-linux.so.2 into /lib? > Yes. You will have two linkers. /lib/ld-linux-x86-64.so.2 will be part of the Glibc that lives in /lib. It will link against /lib/libc.so.6 and friends. /lib/ld-linux.so.2 will be part of the Glibc that lives in /tools/lib (or in my case /opt/linux32/lib) and will link against that library. One thing: make sure you don't mixup /lib/libc.so.6 and /tools/lib/libc.so.6 when building. This can happen if you set /tools/bin/gcc to try using /lib/libc.so. The symlink hack I suggested is only really usefull for running applications. It should never be used for building otherwise you run the risk of opening the gates of hell. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adding 32-Bit Libraries to an Existing 64-Bit LFS-7.3?
>On Thu, 04 Jul 2013 19:51:04 -0500 >Tyrin Price wrote: > > I cannot find a suitable substitute for a particular program that > needs Adobe AIR. Unfortunately, adobe no longer supports Linux. The > old 32-bit Adobe AIR platform is still available for Linux, but I > have a 64-bit system with 16GB of RAM. > > Is there a way to add 32-bit support to an existing 64-Bit LFS-7.3 > build or do I need to start over with a Cross Linux From Scratch > build to have 32-bit support on a 64-bit system? > > -- > > -=[Ty]=- > You can use CLFS instructions to build the 32-bit /tools directory and then put a link to /tools/lib/ld-linux.so.2 into /lib. This way, when the application requests the /lib/ld-linux.so.2 dynamic linker, it will get one and the linker will then use libraries in /tools for linking. Remember that you also have to build the X system libraries and all the other dependecies and put them into /tools/lib or otherwise the run-time linking will fail. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] YouTube audio
>On Tue, 18 Jun 2013 17:51:28 -0500 >Bruce Dubbs wrote: > > Aleksandar Kuktin wrote: > >> On Tue, 18 Jun 2013 16:53:29 -0500 > >> Bruce Dubbs wrote: > > > >> Well that didn't work. It gets to a point where is is linking > >> libxul.so and dies because it can't find the entries > >> 'vorbis_block_init' and similar links. The build log is 42K lines > >> when it dies and libxul.so seems to include about 3000 object > >> files. In any case is does *not* have -lvorbis where the > >> references are located. > > > > Did you try manually adding -lvorbis to the command? Assuming > > vorbis_block_init is defined in libvorbis.so. > > It was a really long command and had: > > /tmp/firefox-21.0/firefox-build-dir/toolkit/library/tmpPriw67.list > > in it. The log showed several thousand .o commands, but when I > looked for the list, it was gone. I could look for the Makefile and > add it to that. Ow. Well, I guess you could go the Makefile route. If you want to. > > For the record, I also don't have audio in my Firefox when viewing > > HTML5 videos on YouTube, but I run my browser as a separate user and > > that user is not added to group "audio" in /etc/group (I use ALSA). > > Since I wrote a special script to download the video files from > > YouTube so I can view them later with Mplayer, I never cared about > > this. > > In my case, I am in the audio group. > > It would be interesting to see if my mplayer can play html5 files. > Can you share your script? > >-- Bruce Script is attached. A short manual: the script uses wget to do all the heavy lifting. The script takes a (theoretically infinite) list of video IDs. If you view a YouTube URL, for example http://www.youtube.com/watch?v=o4NaBrFkiDo, then you see that it has the 'v' argument, in this case "o4NaBrFkiDo". That is what I call YouTube URL and the script needs those. These can be passed naked, but the script will also detect them within constructs such as a complete YouTube link (like the one above) and a bunch of others. See lines 118-120 for details. Other than that, you can pass arguments to it. --user-agent is passed to wget. --limit-rate is also passed to wget. The remaining arguments have to do with video quality (the itag parameter). They set the maximum allowable quality setting, and the actual video quality is selected as the largest available from a decending list, whose top just got defined. The order of these flags is (highest to lowest) --uhq, --vhq, --hq, (no argument), --lq, --vlq, --ulq, --slq. The parameter --music is special in that it generates a quality list which is optimized for music download, that is: as small as possible, while not compromising on sound quality. The option -e terminates the options list and -h and --help display the help, as is customary. I should point out that this script is VERY old - at the very least it's older than HTML5. And because of that, the script homes in on all itag quality values that correspond to FLV and MP4 files while ignoring the rest. Therefore, it will not download WebM files, except by mistake (which only happens when there is a change with the YouTube page). As far as network activity, the script does a bit of browser impersionation: it spoofs the "User-Agent" field to an old version of Google Chrome by default and does a nice little job of keeping tabs on all cookies (deleted at script exit). The script downloads the HTML of the video page, digests it, and downloads the video stream file, provided it found one. The default bandwith limitation (--limit-rate argument) is 200k. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet get_from_youtube.sh Description: application/shellscript -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] YouTube audio
>On Tue, 18 Jun 2013 16:53:29 -0500 >Bruce Dubbs wrote: > Well that didn't work. It gets to a point where is is linking > libxul.so and dies because it can't find the entries > 'vorbis_block_init' and similar links. The build log is 42K lines > when it dies and libxul.so seems to include about 3000 object files. > In any case is does *not* have -lvorbis where the references are > located. Did you try manually adding -lvorbis to the command? Assuming vorbis_block_init is defined in libvorbis.so. For the record, I also don't have audio in my Firefox when viewing HTML5 videos on YouTube, but I run my browser as a separate user and that user is not added to group "audio" in /etc/group (I use ALSA). Since I wrote a special script to download the video files from YouTube so I can view them later with Mplayer, I never cared about this. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] More about stripping
>On Sun, 28 Apr 2013 20:17:48 +0100 >Matt Burgess wrote: > Well-behaved/correctly packaged projects should have no need for > those packages to be installed. And therein lies the rub. Should LFS (base version) be built to handle only well-behaved stuff, or should it be built to also withstand a messed up package here and there? And to immediately give my opinion: I think LFS should contain everything to enable building and rebuilding packages a user may want to install later on. I believe that moving auto* stuff to BLFS would only needlessly prolong and possibly increase the pain of having to hunt down the dependencies for packages a user may want to install. Only somewhat related to previous, I also believe LFS could use a package for human networking. It is true that a ftp client is installed, but I have not had much luck in using it. I was only able to access the contents of some FTP servers, while others kept returning errors. I think the error code I got was 500. When I first built my LFS, I worked around this problem by copying the lynx executable from the LFS live disk I used as my base system. I am fully aware that similar proposals have been floated and rejected previously. The reasons for rejection are understandable and I ultimately concur with the decision to not include such a software package in LFS. But the fact still remains that a text web browser would be a nice addition. If maybe a little over-the-top for the base system. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] A question about KDE - and a suggestion
>On Sat, 20 Apr 2013 05:55:00 -0700 >William Tracy wrote: > > Just to provide a dissenting view: > http://xkcd.com/1200/ > > William Tracy > afishion...@gmail.com > (408) 685-4819 Did you know I also thought of that comic as I was opening my mailer today? :) -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] A question about KDE - and a suggestion
>On Fri, 19 Apr 2013 20:22:54 +0200 >"Niels Terp" wrote: > > [snip] > > I know that I am poking my face into a beehive here, and I am well > aware of the dangers by logging in as root. It is possible on my SuSE > system, and have never given me any problems. And I ALLWAYS have a > backup of my system. So PLEASY tell me, how can I autostart KDE, and > still log in as root ? Words fail to express just how bad an idea this is. Yet, I must try. The first and main problem, obviously, is that running as root destroys the compartmenalization of your system. This compartmenalization is critical to normal and RELIABLE system operation. I won't spend more words on that problem, because there is a much bigger problem here. It specifically has to do with KDE. One word before I begin. I have never used KDE, in the sense that I have never written a program that uses KDE. What follows has been pieced together by reling on documentation and the general knowledge regarding objects and object-based programing systems. While I may be wrong regarding KDE, I am not wrong regarding the general idea. KDE is object based. I am sure you and everione else reading this knows what an object is. For the sake of those who don't, let me reiterate. An "object" is a construct consisting of code and data. It has an internal state. The state is held in the data. The code implements functions. Some of these functions are public - other object can call them - and some functions are private - only the object itself can call them. As a rule, the only way to access an objects data is to call a function in that object and let it return data to you. KDE has something called Kparts. I think Kparts is the main inter-process comunication method used, but I may be wrong. If I am wrong, that would be very good. Kparts are objects. They ferry data from one process to another. If I know this part correctly, the undelying method by which this is done is by using shared memory to contain said objects. So far so good. Now, application A uses Kparts to send information to application B. A passes an object to B. The only way for B to gain the data is to get it from within the object and there is only one way to do this: to call a function within the object. Let me reiterate: when objects are used for IPC (inter-process comunication), the only way for the receiver to gain the passed data is for it to execute the passed object. The question now, ofcourse, is what happens if that function that returns data is booby-traped to take over the receiving application? There is no way for the receiving application to know what will happen once it passes control to the object yet it has no other choice but to do so. Thus, objects used for IPC enable simple and easy process takeover. Ultimately, there vulnerabilities are unprotectable. Regarding your idea to log in to a KDE session as root... I hope I don't have to go on explaining why is that such a bad idea. With the system being completely de-compartmenalized, you will have no security both from legitimate errors and mistakes and from any and all attacks. And without being protected from errors and mistakes, you will not have a reliable system. One final word. While I may be wrong regarding Kparts and KDE, KDE is not the only thing in existance which uses object-based IPC. I hear GNOME also uses them, but the biggest culprit.. realy, the elephant in the room that needs to be mentioned is Windows. If I read the documentation right, all the way since 1991. (or some such) and the adoption of COM, MS-DOS and Windows have used object-based IPC as their workhorse. This is the number one problem of Windows. And it has gotten worse over the years. The most recent SURE instance of this being used that I could find is in the newest Windowses Power shell. One of the key selling points for the Power shell is how the pipes are implemented using object passing. The sales pitch goes on to elaborate how previous versions of the Windows shell would serialize object before passing them (serialization means that the data was extracted from the object and passed alone) but the new Power shell passes object and thus eliminates the cost of serialization and deserialization. In my mind, the possibilities for abuse of that are endless. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] device drivers
>On Fri, 19 Apr 2013 17:40:49 +0200 >Aleksandar Kuktin wrote: > > >On Fri, 19 Apr 2013 17:25:03 +0200 > >svenbartsc...@yahoo.de wrote: > > > > Hey guys! > > I'm now searched a long while through the net for a information > > which option in the kernel (compilation) contains the driver for my > > soundcard (Realtek ALC662), i found nothing. So my question is: > > Where is a good place to look which deviece needs which kernel > > configuration. > > Practice. > > Option A: enable all drivers for that piece of hardware an > then tick them off one-by-one untill you find the one that > is required for the device to work. > Option B: enable all drivers, then use lspci to find the device on > your bus and see which driver it uses. > Option C: compile all drivers as modules and set the module-auto-load > option. After booting, use lsmod and lspci to see which > driver is used. > Try Device drivers->ALSA->PCI sound devices->Intel HD Audio. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] device drivers
>On Fri, 19 Apr 2013 17:25:03 +0200 >svenbartsc...@yahoo.de wrote: > > Hey guys! > I'm now searched a long while through the net for a information which > option in the kernel (compilation) contains the driver for my > soundcard (Realtek ALC662), i found nothing. So my question is: Where > is a good place to look which deviece needs which kernel > configuration. Practice. Option A: enable all drivers for that piece of hardware an then tick them off one-by-one untill you find the one that is required for the device to work. Option B: enable all drivers, then use lspci to find the device on your bus and see which driver it uses. Option C: compile all drivers as modules and set the module-auto-load option. After booting, use lsmod and lspci to see which driver is used. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Unable to load certain websites
>On Sat, 23 Mar 2013 20:25:49 -0400 >Alexander Spitzer wrote: > > Aleksandar, > > Thanks for your reply. Installing polipo and using its DNS resolver > did not solve the issue but setting dnsQueryIPv6 to false did! Turns > out the entire issue was with IPv6 querying. Now with ipv6 disabled > in the kernel everything loads fine. I should have tried that > earlier. I think the ipv6 problem is with my home router setup so > when I go back to school I will reenable ipv6 and see if there is > still an issue. > > Thanks for everyone's help! Glad that's out of the way, then. Yes, IPv6 can make that happen. If the DNS resolver resolves the name into a IPv6 address, and the kernel believes it can handle the IPv6 while in reality there is no IPv6 path between you and the target, then TCP/IPv6 will first have to timeout which takes a while. Forcing the utilisation of IPv4-only addresses makes the problem go away. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Unable to load certain websites
>On Wed, 20 Mar 2013 12:26:04 -0400
>Alexander Spitzer wrote:
>
> > Have you tried konqueror from kde or firefox?
>
>
> No, but I've tried python. It can't be the rendering. Running
> "urllib.urlopen("http://en.wikipedia.org";)" stalls like in the
> browser. Adding a line to /etc/hosts with the wikipedia server's IP
> and the same line runs instantaneously.
> Running "dig @8.8.8.8 (my configured DNS) en.wikipedia.org" resolves
> the name in under 30 ms! So something wierd is happening. I could try
> looking into glibc but like you said why would it fail for only some
> websites?
>
> I guess I could install Firefox anyway. What I really want is Google
> Chrome but that's going to be a challenge.
Chiming in...
>From the description in this thread, the location of the problem is in
the DNS resolver. AKA glibc.
This hypothesis can be verified by using a different DNS resolver. The
easiest way to do this is to put a HTTP proxy with it's own DNS resolver
on your system and have the browser use it. You can use Polipo for
testing because it is a simple and straightforward proxy.
http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/
Now, IF using polipos own DNS resolver makes the problem go away, but
configuring polipo to use glibc's DNS resolver makes the problem
appear, then you have your diagnosis.
The problem then becomes "what is causing glibc to behave like that"?
If the Polipo test comes back positive, then I think you should
escalate the debugging and - I'm not joking - use tcpdump to sniff your
own traffic to see what *exactly* is going on on the wire. I'll guide
you through the process, because glibc behaving in this way is
untolerable and we must get to the bottom of it, especially if you are
willing to put up with the debugging.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--Skynet
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Speech Dispatcher in BLFS?
>On Fri, 1 Feb 2013 20:43:09 -0500 >alex lupu wrote: > Seems you're not easily swayed by ugly financial reasons like Google > crashing everything in its path (so you join it to avoid certain > harm). In his infinite wisdom, God set a time and a place for everyone. Google became what it is mostly because it served its customers (IOW, society) well. That is, better that the competitors. But, should Google turn its back to the society that gave it the mountain of money it has, and should Google waste itself in shoveling unwanted crap down our throats, then there will be no Google. Point: Google glasses. Which iteration of the "virtual reality glasses" product are these? Unlike Microsoft and its pad, Apple made it big with the iPad because there was a need/demand for such a product at the time it was unveiled. And copious amounts of loans to broke deadbeats to finance said need, but lets ignore that for a moment - after all, Apple could have just slashed the price. Regarding Google and its glasses, I really, really, REALLY don't see a use for them. For iPad, even though I myself would never buy it, I do see a use - easy inteface device for control in industrial enviroments. Reading a book. Watching a movie. Playing a game. Looking cool is not on this list, mostly because Apple is mainstream. If really you want to convey the aura of being a part of the cool underground, use Linux. But what possible use can glasses have? Glasses that you control with YOUR VOICE!! I can't make this point hard enough. Imagine: you are standing in the middle of a packed tram (or bus) and you say out loud "glasses do blah-blah". Everyone is instantly annoyed. But, your glasses have not understood it. So now you have to say the same command louder, possibly shout it (for example, the London underground can get quite loud sometimes) while everyone looks at you like they want to cram the glasses down your throat. In some parts of the world, it is now considered rude or very rude to talk on the phone in a public transportation vehicle. I can only immagine how long will it take before giving voice commands to glasses gets the same treatment. > BTW, maybe I didn't convey it properly, my life was pretty bearable > until chrome compilation started requiring (and silently no less, so > to speak:) the presence of the Speech Dispatcher. > Disabling chrome's speech component has become too onerous lately. Looks like it is high time for someone to write a browser from scratch. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] ftp client question
>On Mon, 28 Jan 2013 23:54:50 +1300 >Simon Geard wrote: > > On Sun, 2013-01-27 at 14:55 +, lux-integ wrote: > > I have sftp but since it is only data between two neighbouring > > machines I thought a simple even if insucure > > method would suffice. Advice and suggestions on available ftp > > clients would be much appreciated. > > My advice would be not to bother - if ssh/sftp/scp is available, that > *is* the simple solution. It's not like ftp is in any way easier to > use or to set up... > > Simon. > Or you can do what I did and install a HTTP server on your machine as part of the normal BLFS desktop build. You can then hack the web pages your HTTP server serves and get a quick, easy (not counting the initial setup of the server) and configurable network interface for you desktop. And if you happen to also have a DNS server in the network, and if that DNS server talks to the DHCP server, people can access you computer seamlessly, just as if it were part of the Web (which it would technically be, if you include at least one link to the WWW). -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] For {,anti}systemd folks
>On Sun, 27 Jan 2013 01:17:04 +0100 >"Armin K." wrote: > I know it is hard to change something, but no one was born knowing > everything. For example, systemd was easy for me back then because I > didn't know shell scripting. Few text files get everything I wanted > and I needed few days to get something done like I want with shell > scripts - and that's without any shell scripting skills. Actually, this is an interesting point. For people who don't know shell, systemd may be the easier solution. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] For {,anti}systemd folks
>On Sat, 26 Jan 2013 16:07:55 -0600 >Bruce Dubbs wrote: > systemd uses binary log files that can't use standard tools like > grep. Myth or fact? Big no-no. > systemd solves problems encountered by many/most LFS users. Myth or > fact? Interesting point: I have no memmory of the last time I changed the bootscripts. > systemd has/needs over 100 pages of documentation. Myth or fact? I went to see what other posts are on the authors blog and the first thing I see is "systemd for administrators, part XX". Next is part XIX, followed by part XVIII and so on... Compare and contrast with LFS bootscripts which I was able to parse and grok with only the begginers understanding of shell. Years back. Point 1 for sysvinit+udev. * * * I read a little of the "systemd for administrators" saga (part XX) and then I ran into this little line which was quite enlightening: "[I'll explain how to derp...]Or in other words, how you can drive up the density of customer sites on a system while spending less on new hardware." For me, this sentence points the finger to the systemd's goal, and also to the reason this whole hakoohah about /dev and booting has been going on for years^H^H^H^H^Hdecades. Virtualization, or something such. People appear in a need for a good abstraction of both the hardware and (more importantly) the boot process. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Java plugin
>On Mon, 14 Jan 2013 18:15:29 +0100 >Aleksandar Kuktin wrote: > > >On Mon, 14 Jan 2013 16:13:24 +0100 > >Thomas de Roo wrote: > > > > Hello, > > > > Can somebody explain why the Java-plugin only works when it is a > > symbolic link, but not when it is simply copied > > to /usr/lib/mozilla/plugins? > > > > Groet, > > Thomas > > Maybe it's a security hack on behalf of Mozilla. > > If the plugin is a file, than the file can be modified by the Firefox > process in the event of an exploit code execution. However, if it is a > link, specifically if it is a link to a root-only part of the tree > (such as /usr ), then the plugin file can not be modified by malicious > code which may take over Firefox. > > If the file was physically present in a Firefox writable directory, > there would be no way to protect the file. However, if the file is in > a directory Firefox can not modify, setting the permission flags on > the plugin file will have a permanent effect in policing permissions. > Woops. You asked about /usr/lib/mozilla/plugins, and I told you about ~/.mozilla/(...)/plugins. Maybe the same code handles both paths? -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Java plugin
>On Mon, 14 Jan 2013 16:13:24 +0100 >Thomas de Roo wrote: > > Hello, > > Can somebody explain why the Java-plugin only works when it is a > symbolic link, but not when it is simply copied > to /usr/lib/mozilla/plugins? > > Groet, > Thomas Maybe it's a security hack on behalf of Mozilla. If the plugin is a file, than the file can be modified by the Firefox process in the event of an exploit code execution. However, if it is a link, specifically if it is a link to a root-only part of the tree (such as /usr ), then the plugin file can not be modified by malicious code which may take over Firefox. If the file was physically present in a Firefox writable directory, there would be no way to protect the file. However, if the file is in a directory Firefox can not modify, setting the permission flags on the plugin file will have a permanent effect in policing permissions. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] 5 questions, linux adsl(2)-Modems,current
>On Tue, 8 Jan 2013 12:15:41 + >"lux-integ" wrote: > > On Tuesday 08 January 2013 09:17:51 Simon Geard wrote: > > Every DSL device I've seen in years - including the free ones ISPs > > hand out to new customers - has just been a router with an ethernet > > port. The device itself takes care of the DSL part - you just need > > to plug in your PC, and do whatever you'd normally do for an > > ethernet device. > > > thats just it I dont want the routing mulki, I can do this meself > and for multiple subnets. There is a pci adsl2 modem (ikanos > chipset ??? (I think ) by sangoma (and others ) I think and support > for it is in the kernel, but it is quite expensive. > > How does bridging work and can one put router(s) behind an > ethernet bridge? > > by the way thanks for all the responses I have the same idea in my TODO folder. The way I understand it, at a bare minimum, you need (1) a physical and link level connection to the first station and (2) a carbon copy of whatever mechanism ISPs modem-router uses to route the packets. There is a HOWTO which sheds a bit of light on all this: http://www.tldp.org/HOWTO/DSL-HOWTO/index.html Regarding the physical connection, that is done with DSL. AFAIK, DSL lives exclusively in the physical layer and either can not signal, or can not signal enough. Therefore, a link layer is put over DSL. The most likely candidate for this link layer is ATM. Maybe PPP can also be used. Maybe they can even put raw ethernet frames on top of DSL. You can gain a bit of information regarding this by loging into the modem-router your ISP gives you. Read the manual and try to figure out what the device is doing, and then copy that. As far as bridging, the idea is simple - take packets from one interface and just send them on the other. In the kernels menuconf, look under Networking for something called Bridging. Also see http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge But, the problems only begin when you get to this point. The ISP assumes it owns the firmware in the router and as a consequence of that, the "routing" part can be arbitrarily complex. For example, I have noticed that my ADSL router appears to be using VLANs. But not just any VLANs, sometimes it uses normal once-tagged ethernet frames, but some other times it uses double-tagged (QinQ) ethernet frames. It appears no more that two tags are ever used. Currently, I have ZERO idea which frames get a single tag, and which get two tags, not to mention having less than zero ideas on what is the content of those tags. Further compicating matters, it appears that yet some other frames have an even more bizarre treatment. If I ever want to connect to my ISP, I need to carbon copy the mechanism by which the tags are generated. I also need to do this while not reverse engeneering the modem-router, lest the ISP press a lawsuit against me. Or just cut off my Internet pipe, which would be an even bigger problem. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Wirenet, the first (?) real malware for Linux.
Note that this mail is cross-posted to lfs-support, blfs-support and lfs-security, with a "Reply-To" set to lfs-security. This is also the first mail on the lfs-security list in at least three years. Yaay! Anyway, the news is from august/september of 2012, so it's a little stale. However, the search function over on LWN returns NULL when asked for "wirenet". OTOH, Forbes and The Register both wrote a small article each on the subject. A bunch of other sites copy-pasted the content from each other. H-Online also wrote a /very/ interesting article on the subject, discussed below. I have discovered this only today, and purely by accident. And then I thought it would be prudent to warn the LFS community about it. https://www.virustotal.com/file/1c4ba1bf8003b9d66b4423e0503bf5489cd4de13b1a3038499d039baa553cd0e/analysis/ http://blog.webroot.com/2012/09/14/wirenet-the-password-stealing-trojan-lands-on-linux-and-os-x/ http://news.techworld.com/security/3378804/linux-users-targeted-by-password-stealing-wirenet-trojan/ http://news.drweb.com/show/?i=2679&lng=en A Russian security firm called Dr. Web has discovered (made public ?) what they call a trojan capable of infecting Windows, MacOS X and Linux. Unlike the event about a year ago when a Java worm accidentally infected the Java plugins of browsers running on Linux, this is the real deal. ELF executable, X system API calls, Linux syscalls. According to Techworld, Dr. Web received the sample from Virustotal. I have not found any infomation regarding "the dropper" (a different malicious program which installs this malware on the computer), or any information regarding the specifics of Wirenet's point and method of entry. There is also no word on the method Wirenet uses to survive the shutdown-bootup barier. The post on Webroot goes to great lengths to explain (some) details of Wirenet's operation. Wirenet goes after the password caches of Firefox, SeaMonkey, Chrome/Chromium, Opera, Pidgin and Thunderbird. No word on whether it also targets keyrings of various PGP implementations (which is THE treasure stash, IMO). Wirenet is also capable of taking screenshots, keylogging (both of these via Xlib), remote code execution and possibly other things. http://www.h-online.com/security/news/item/Hackers-turn-remote-maintenance-tool-into-trojan-1697425.html H-Online has a very interesting take on the subject matter. They basically assert that the program was written by World Wide Labs under the name NetWire as a legit (ha-ha) remote administration/remote monitoring tool, but that it got coopted to operate as a malicious trojan. In light of that, and taking into account the current lack of a clear infection/boot-cycle-survival mechanism, it is entirely possible that Wirenet is a tempest in a teapot, malware without the dropper, a horsecart without horses (I'll stop now). IOW, I am not sure if it "exists" and does damage in the wild or not. The really interesting thing here, and the thing that really got me thinking, is the fact that Wirenet neither uses nor needs to use root to do it's thing. It exist entirely in nonpriviled userspace. Which makes its mitigation hard(er then neccessary). Speaking of mitigation, the Internets main advice seems to be "Linux is invulnerable to malware and you should stop worring about this, period, new paragraf, lalalala." Needless to say, this sort of attitude can only get one killed and/or robbed. In the interest of mutual safety, I will now describe my method of using browsers, together with modifications that should make one almost completely safe from this and other similar things (ha-ha). Starting with the premise that the browser has a code execution vulnerability, which holds true for them all on at least some days (WebKit, you eternal beta, I am looking at you), you can expect the browser to drop and start Wirenet. This is my premise. I start with "a day will dawn when my browser will betray me". If this happens, Wirenet will rob my (nonexistant - I don't store my passwords with the browser) password caches blind, possibly connect to the X server and do all sorts of bad things through it. However, for years I have not trusted my browsers and I have run them as separate users, sandboxed. My browser doesn't even connect to the net. It is firewalled and connects to a locally running HTTP proxy (polipo) and then the proxy connects to the net. Until today, the script which started the browser would have left the .Xauthority file in the browsers home directory, but in the light of Wirenet, that may be a bit too risky. So now it removes .Xauthority 1 second after forking the browser. I have attached the script starting Firefox for reference. So, I think that that is probabbly the only surefire way of protecting oneself: run the browser as a separate, sandboxed user and make sure it is only exposed to the X cookie for as little as it needs. Assuming your X server is not promiscous (I have found that running Xorg 1.11 or 1.9 or so
Re: [blfs-support] 64bit lfs question
>On Mon, 17 Dec 2012 12:36:27 +
>Ken Moffat wrote:
>
> On Mon, Dec 17, 2012 at 11:23:19AM +, lux-integ wrote:
> > Greetings
> >
> > For the past 4/5 years I have been doing exclusively pure64bit
> > (amd64cpu) clfs builds.
> > I urgently need to upgrade to a build that uses glibc-2.16 (to see
> > if nfs4/rpcbind/gssd works !) and clfs is currently embedded in
> > eglibc-2.15/gcc-4.6.3.I am thinking of jumping ship back to
> > lfs. Ii have the following question:-
> >
> > are pure 64bit (amd64 cpu ) builds possible with lfs?
>
> Yes, I've only built pure64 x86_64 LFS for the past few years.
> The difference in LFS is that it has the /lib64 symlinks so it isn't
> quite so 'clean'.
This, however, can be fixed, so that a x86_64 is indistinguishable from
an i686 system.
This requires a patch to the compiler (attached) and, I think,
configuring glibc (I use glibc, hopefully eglibc can use the same
method) with --libdir=/usr/lib.
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
diff -Naur gcc-4.3.4/gcc/config/i386/linux64.h gcc-4.3.4-pec/gcc/config/i386/linux64.h
--- gcc-4.3.4/gcc/config/i386/linux64.h 2007-08-02 12:49:31.0 +0200
+++ gcc-4.3.4-pec/gcc/config/i386/linux64.h 2009-10-07 22:30:23.0 +0200
@@ -53,8 +53,8 @@
When the -shared link option is used a final link is not being
done. */
-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
-#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-linux-x86-64.so.2"
#if TARGET_64BIT_DEFAULT
#define SPEC_32 "m32"
diff -Naur gcc-4.3.4/gcc/config/i386/t-linux64 gcc-4.3.4-pec/gcc/config/i386/t-linux64
--- gcc-4.3.4/gcc/config/i386/t-linux64 2007-09-27 21:56:06.0 +0200
+++ gcc-4.3.4-pec/gcc/config/i386/t-linux64 2009-10-07 22:31:53.0 +0200
@@ -13,7 +13,8 @@
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
-MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
+
+MULTILIB_OSDIRNAMES = ../lib $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32)
LIBGCC = stmp-multilib
INSTALL_LIBGCC = install-multilib
diff -Naur gcc-4.3.4/gcc/config/mips/linux64.h gcc-4.3.4-pec/gcc/config/mips/linux64.h
--- gcc-4.3.4/gcc/config/mips/linux64.h 2007-08-02 12:49:31.0 +0200
+++ gcc-4.3.4-pec/gcc/config/mips/linux64.h 2009-10-07 22:33:03.0 +0200
@@ -38,9 +38,9 @@
%{!shared: \
%{profile:-lc_p} %{!profile:-lc}}"
-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
-#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
-#define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld.so.1"
+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld.so.1"
+#define GLIBC_DYNAMIC_LINKERN32 "/lib64/ld.so.1"
#define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
#define LINUX_DYNAMIC_LINKERN32 \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKERN32, UCLIBC_DYNAMIC_LINKERN32)
diff -Naur gcc-4.3.4/gcc/config/mips/t-linux64 gcc-4.3.4-pec/gcc/config/mips/t-linux64
--- gcc-4.3.4/gcc/config/mips/t-linux64 2006-06-06 14:51:24.0 +0200
+++ gcc-4.3.4-pec/gcc/config/mips/t-linux64 2009-10-07 22:33:27.0 +0200
@@ -1,6 +1,6 @@
MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64
MULTILIB_DIRNAMES = n32 32 64
-MULTILIB_OSDIRNAMES = ../lib32 ../lib ../lib64
+MULTILIB_OSDIRNAMES = ../lib64 ../lib32 ../lib
EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
diff -Naur gcc-4.3.4/gcc/config/rs6000/linux64.h gcc-4.3.4-pec/gcc/config/rs6000/linux64.h
--- gcc-4.3.4/gcc/config/rs6000/linux64.h 2007-08-02 12:49:31.0 +0200
+++ gcc-4.3.4-pec/gcc/config/rs6000/linux64.h 2009-10-07 22:34:18.0 +0200
@@ -339,8 +339,8 @@
#undef LINK_OS_DEFAULT_SPEC
#define LINK_OS_DEFAULT_SPEC "%(link_os_linux)"
-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
-#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld64.so.1"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld.so.1"
+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld64.so.1"
#define UCLIBC_DYNAMIC_LINKER32 "/lib/ld-uClibc.so.0"
#define UCLIBC_DYNAMIC_LINKER64 "/lib/ld64-uClibc.so.0"
#if UCLIBC_DEFAULT
diff -Naur gcc-4.3.4/gcc/config/rs6000/t-linux64 gcc-4.3.4-pec/gcc/config/rs6000/t-linux64
--- gcc-4.3.4/gcc/config/rs6000/t-linux64 2007-09-27 21:56:06.0 +0200
+++ gcc-4.3.4-pec/gcc/config/rs6000/t-linux64 2009-10-07 22:34:47.0 +0200
@@ -19,7 +19,7 @@
MULTILIB_EXTRA_OPTS = fPIC mstrict-align
MULTILIB_EXCEPTIONS = m64/msoft-float
MULTILIB_EXCLUSIONS = m64/!m32/msoft-float
-MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) nof
+MULTILIB_OSDIRNAMES = ../lib $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32) nof
MULTILIB_MATCHES= $(MULTILIB_MATCHES_FLOAT)
softfp_wrap_start := '\#ifn
Re: [blfs-support] LFS and updates
>On Mon, 17 Dec 2012 20:04:29 +1300 >Simon Geard wrote: > > On Sun, 2012-12-16 at 13:36 +0100, Jean-Philippe MENGUAL wrote: > > I can't believe everyone on lfs rebuild all his system at each > > update. Rebuilding some part, yes; but all the blfs system... > > Living with LFS is a great way to learn advanced shell scripting... :) > > Simon. And many, many other things you wouldn't know otherwise. :D -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] A new LFS Blog
>On Sun, 09 Dec 2012 19:20:22 -0600 >Bruce Dubbs wrote: > > I would like to announce the linux from scratch blog. > > http://lfsblog.linuxfromscratch.org/ > > The purpose of the blog is to expand upon LFS/BLFS by providing > examples of configuration and use that go beyond the books. New > articles will appear periodically to give practical examples of > how to use applications in an LFS environment. > >-- Bruce Dubbs > linuxfromscratch.org Neat! -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] browsers (was Re: Latest news in GNOME world)
Here's another possibly interesting browser: K-Meleon. http://kmeleon.sourceforge.net/ It's based on Gecko, and licenced under GPL. It's also written exclusively for Windows. D'oh. BUT! Wine's application database claims K-Meleon runs flawlessly under wine. So, just because it's convoluted, next weekend probably I will attempt to cross-build K-Meleon and then try to run it under Wine. Just to see what will happen and if it will work. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Google Gadgets
It appears Google Gadgets is written for an older version of glib that the one you are using. The proper solution would be for ggadgets developers to port it to the new glib. However, as that is not a workable solution, something else can be done. Assuming the various function implementations in the new glib have not had subtle but critical changes (which is probably true), you can change ggadgets to include glib.h directly and before any other glib headers. To do this, just put the line `#include ' before glib headers, in this case, gnode.h. Like in this improvised patch: a/gtk/main_loop.cc b/gtk/main_loop.cc @@ -19,1, +19,2 @@ +#include #include And then repeat the same for all source files. :) -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Software version
>On Thu, 29 Nov 2012 15:45:48 -0800 (PST) >Fernando de Oliveira wrote: > > --- Em qui, 29/11/12, Ken Moffat escreveu: > > > De: Ken Moffat > > Assunto: Re: [blfs-support] Software version > > Para: "BLFS Support List" > > Data: Quinta-feira, 29 de Novembro de 2012, 19:03 > > > Some things I could revert to older gtk+-2 versions, e.g. > > gvolwheel, > > and I plan to replace gcalctool and evince with the mate > > versions > > without worrying. > > Ken, I have used gcalctool. Many times wanted to ask you: > > Have you ever tried "Qalculate!"? > > http://qalculate.sourceforge.net/ > > It can be used as very basic calculator with its own keypad, or with a > click, you have a history that you can copy any part of. I stop my use > normally here. > > But it can be used in more complex ways, as scientific calculator, > converting units, with different basis (binary, decimal, hexa, ..., > currencies, variables, functions, RPN, many other possibilities. > > []s, > Fernando Am I the only one around here who uses shell arithmetics when I want to calculate? (Sorry for the meme reference.) -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] MATE: a GNOME 2 fork
I just found this and thought you people might be interested. http://mate-desktop.org/ MATE is a fork of GNOME 2 desktop, forked about a year ago. It is the default desktop in Linux Mint 14. I personaly don't use GNOME and have not tried MATE so I can not tell anything about it's usability or usefullness, but I am sure there are people here who can benefit from it. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] browsers (was Re: Latest news in GNOME world)
>On Thu, 22 Nov 2012 22:58:51 +1300 >Simon Geard wrote: > > If a site is going to only support a couple of browsers, I typically > > don't feel their content is worth jumping through hoops to view and > > I don't feel it's worth recommending to others. > > Do you mean that they clearly block it from being used on IE? Or is it > that it just doesn't work, and they make it clear they're not going to > fix it? I have a lot of sympathy for the latter attitude - yes, it > excludes some users, but if you're trying to do anything fancy, > supporting IE ranges from difficult to outright impossible. I had a similar problem, only done by different actors. When Apple had their cloud thing, it had a habit of flat out refusing to serve a browser running on Linux. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Latest news in GNOME world
Sorry for a late reply. Also, sorry for the long post. >On Thu, 15 Nov 2012 08:49:06 -0500 >LM wrote: > However, if projects won't even bother with patches that don't meet > their agenda, > how could the software possibly be less buggy than a closed source > project? You > have the same issue as in a closed source environment, only certain > people can fix the source. Exactly. > Aleksandar Kuktin wrote: > >Firefox is already a lost cause, although it never really was a real > >hardcore > > FOSS project, and certainly never was a browser made for Unix. > > Am curious why Firefox is a lost cause and what possible alternatives > there are. For the most part, what follows is my opinion, sprinkled with some facts. To undestand why I believe Firefox is a lost cause, I must first explain what I thought of it before, as well as recap the economics of Firefox development and marketing (yes, there is a marketing). Before, I thought of Firefox as a "good thing". This was a carryover from my days of using Windows, back when there were only Internet Explorer and Firefox. But, as time went on, and Web 2.0 as they call it took hold, I began to notice that Firefox was not, in fact, the lean, mean machine I thought it to be. It was large, arcane and most of all, had an abnormal number of bells and wistles, some of them (like geolocation, persistent cookies and such) downright bad, in my opinion. Then, as if that was not enough, the Mozilla foundation had developed the idea of remorselessly adding more and more features to the browser, a good portion of them, in my opinion, either bad or just fluff. It was at this moment that I abandoned Firefox and started using different browsers (WebKit based). Since that time, Mozilla foundation went full in and is now releasing a new major version every few months (every six months, if I remember). If I understood their stance correctly, they will cease supporting all previous versions upon releasing a new one. Which means that you, as a user, have no choice but to follow the Foundation as it blazes a path forward, regardless if that path leads to desirable results or undesirable results. I find this oppressive. On the other hand, I undestand where this is coming from. As I understand, this is a systemic development, which emerges from the competition of the browser vendors. Now I have to explain how is Firefox in competition. It's simple, really. Firefox, Thunderbird, Seamonkey and other Mozilla products are (at least legally) produced by an organization, the Mozilla foundation. While this Foundation is legally a non-profit, the fact of the matter is that it still pays its employees. Which means it has some sort of revenue or revenue-like cash flow. It does - it is financed through donations. So the deal looks like this: Mozilla foundation makes (good) software, gives it to users and users then donate money to the Foundation with the implicit (or explicit) assumption that the Foundation will make more or better software. Which is a problem because at _some_point_, software reaches its maximum, its optimal state, becomes as good as it can get, and you simply CAN NOT make it better not matter how hard you try. I am strongly inclining toward the option that web browsers, as a whole, have reached that point several years back and all the development since then has been a net liability. So that is the core of my argument that Firefox is a lost cause: it is pursuing a goal which is too close to its hands with way too much zeal and looking the wrong way. Actually, this can be a good argument for any and all web browsers today. I have chills running down my spine every time I think of WebKit. Have you seen the turnover in their source code repository? It's astronomical. I am willing to bet that WebKit developers, on average, rewrite WebKit from scratch once a year. Eternal beta. NO WAY all that code is production-good. And exploit-free, the World has not quite got to that point that browser security is a matter of the same consideration as car safety, but we are very close, the only thing that is needed now are a few casualities. I think the best thing Mozilla foundation can do, regarding the software is to stop developing it and just maintain it. But this will never happen because all those programmers, social experts, managers and what not have to eat something. An impasse of sorts. And the final nail in the coffin for Firefox and me was the realization that Firefox is actually NOT a *nix browser but that it always was and always will be a Windows browser, first and foremost, with other platforms added on just so they can be there. For show, if you will. This realization gets really clear and logical if you think back to where did Firefox ultimately come from. Recall - in the ninetees, the two big boys were Microsoft with its Internet Explorer and Netscape with its Netscape Navigator
Re: [blfs-support] xorg.conf.d file serials
Offtopic. >On Thu, 15 Nov 2012 18:17:07 + >Ken Moffat wrote: > My setup is much simpler than yours - single monitor, only using > the default resolution, and prefix /usr. So I don't know if what I > say will help. If nothing comes up, perhaps google will know [ > these days, it seems to be more attuned to natural language searches > instead of the terse searches that used to work so well ]. I miss those days too. :( -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Latest news in GNOME world
>On Thu, 15 Nov 2012 01:40:06 + >"lux-integ" wrote: > > [snip] > > But Consider bsd-style bootscripts in an elegant scripting language > like python ? Ewww... python during bootstrap? It is a well-known and widely accepted fact that every solution will have at least 10% of people reeling back in horror. And python during bootstrap is the option for which I am definitely in that 10%. > with all the bullying surrounding systemd I would not be at all > surprised if soon a group emerges with such. It's a safe bet. It may even be a good solution. But not for me! :) -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Latest news in GNOME world
>On Sat, 10 Nov 2012 00:09:02 + >Ken Moffat wrote: > I loathe cmake [ reinventing the bumpy wheel of configure, but with > edges instead of the fairly smooth curves, in my biased opinion ] Ow, that's nothing. Wait 'till you get the pleasure of using Scons, the opaque build system. Without exagerating, Scons is 40% of the reason I hate Python. The other 60% is Plone, a CMS which I truly hate with a passion. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Latest news in GNOME world
>On Fri, 09 Nov 2012 16:27:59 -0600 >Bruce Dubbs wrote: > > Armin K. wrote: > > Good morning/afternoon/evening. > > > That said, I won't maintain GNOME in the book and if you ask me, > > you can drop it completely. In BLFS we don't tend to force users to > > do something and keeping GNOME would force (some) users to use mesa > > with llvm for llvmpipe in order to use GNOME. > > > > There is 3.6.2 release comming and that would be last revision > > regarding GNOME from me. > > I understand where you are coming from. I gave up on GNOME some time > ago when I was just installing and testing one of the commercial > distros. I also had an issue with the KDE window manager, but like > their applications. My solution is to build KDE and XFCE and run the > KDE apps in XFCE. Works fine. > > As far as dropping it from the book, I'm not so sure. I think we > have a decent snapshot and can leave it alone without either > upgrading or dropping it. A note at the start would explain our > position. > > One thing I'd like to point out is that a lot of people really didn't > like KDE4 when it first came out. It took a couple of years to get > it into reasonable shape. Perhaps that will happen to GNOME. > >-- Bruce I remember reading a bunch of posts on Usenet (group hr.comp.linux, I think) several years back where people lamented that the GNOME project experienced a rotation of developers, when old people who knew what they were doing left and new (clueless) people came in. And the first thing that happend was that the new guys immediately stopped fixing bugs. Their explanation for that seems to have been "the community will take care of it" - an attitude which speaks volumes about their misunderstanding of the free/open source software culture. And, as it appears, they just plowed on. There may be signs that glibc is undergoing a similar dynamic. Firefox is already a lost cause, although it never really was a real hardcore FOSS project, and certainly never was a browser made for Unix. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xorg7.7 openbox xinitrc
>On Fri, 9 Nov 2012 17:52:42 -0500 >alex lupu wrote: > but that is pure fiction invented and spread by malicious (and > envious) M$ hacks and fan-boys purporting that Linx users "undergo" > at times the so-called BSD (under certain - unspecified - > circumstances) where the screen would freeze (go black) and a user's > alternatives would be to die (as Baho would put it and Widnow$ > mercenaries would like us to do) or > switch the friggin' machine off and back on and then go through a > lengthy, annoying and unnecessary file systems check before fully up. Funny, a few months back, my system HDD (the one with the root directory and /usr directory) died while the system was in operation. You know how I noticed? Barely did at first, since all existing programs which were already in memory just kept running (even the music kept playing). It was only when I tried to run a new process that I noticed something was... "odd". -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xorg7.7 openbox xinitrc
>On Fri, 09 Nov 2012 13:29:09 -0500 >Baho Utot wrote: > > [snip] > > So you are saying if my screen turns blue I will die? > LOL, no. When Windows' kernel panics, it turns the screen blue and displays an error message. At that point, the only thing a user can do is reboot. Thus, the screen signifies the "death" of the computer (or the death of the software instance currently running on it, for a more pedantic answer). Windows users consider BSDs, that is kernel panics, a normal occurence in a production system meant for end-users as well as mission-critical uses such as an OS for SCADA systems. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xorg7.7 openbox xinitrc
>On Fri, 09 Nov 2012 13:00:27 -0500 >Baho Utot wrote: > > On 11/09/2012 12:36 PM, alex lupu wrote: > >> uptime > > When you see Window$ users having to reboot their sorry systems > > several times a day on crazy BSDs and other indignities (like > > updates), ain't it beautiful and reassuring that we still have our > > trusted Linux which, once up, can run for years uninterrupted (and > > unattended) over hurricanes, back-ups, civil wars, domestic > > disputes, hardware upgrades, the Greek debt crisis and all ?! > > (BTW, the above sentence too) > > > > -- Alex > > What does BSD have to do with it? I don't think they were crazy. My > PC-BSD boxen is doing quite well, as it hasn't been shutdown/rebooted > since installation last Sept. He ment "the Blue Screen of Death". There is a screensaver in Xscreensaver collection which simulates the effect. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xorg7.7 openbox xinitrc
>On Fri, 09 Nov 2012 12:56:49 -0500 >Baho Utot wrote: > > On 11/09/2012 12:08 PM, Bruce Dubbs wrote: > > > > [snip] > > > > It should be 4.2 years. > > > > -- Bruce > > > > > > I would have had a greater uptime but without electric power for a > week some thing had to give. > I just could not keep peddling as my age was starting to show. > > Right. So a competition seems to be developing. For the record, my own best time was about a week or so. And I normally don't do that, but I was having problems with hardware then - the backlight for the screen was having problems turning on so I had to keep it lit at all times. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How Do I Know When to Recompile the Kernel?
>On Wed, 24 Oct 2012 17:28:30 + >"Feuerbacher, Alan" wrote: > You've come close to answering what I really want to know. I'm so new > at this (first time around doing LFS on my home computer) that I'm > not sure I'm asking the right questions. So here's a bit more: > > The BLFS doc says to do some reconfiguring (which modifies > the .config file) and then to "recompile the kernel *if necessary*". > This implies to me that some modifications to the .config file will > NOT require recompilation, while others will. So guess my questions > should have been, What modifications DO or DO NOT necessitate > recompilation? And where can I find documentation to educate myself > thoroughly about this stuff? Mmm.. when you compile the kernel, and observe the process, you will see that first there is a looong list of source files that are compiled. At the end, they are linked (or something to the same effect) and a binary image is created. Then, the compilation process continues and makes a bunch of modules, if any modules are selected in .config (translation: if any kernel parts are configured to be built as modules). Now, for example, say you selected a driver for a WiFi card to be "built-in" and a driver for an Ethernet card to be "compiled as a module". The result of this is that your kernel image will contain a driver for the WiFi card, while you will also have a separate file on the side (say, "ethernet.ko") which will contain the Ethernet driver. Which changes need recompiling the kernel? All changes to the .config file require running the build process again to actualize these changes (God I'm eloquent, now if I spelt it right that would be great :) ). But then there is a difference. Changes to the built-in driver, that is, changes that affect the kernel image, require rebooting with the new kernel image. Changes to the modules, that is, all changes that solely affect parts of the kernel that are in the modules, do not require a reboot. Now to tie it all together: the build process produces a kernel. Pieces of this kernel are in several places. The kernel's kernel and all built-in stuff is in one big file called (not entirely properly) "the kernel image". Other stuff is strung around in numerous files and these pieces (and the files that house them) are called "kernel modules". They usualy live in /lib/modules. When booting, the bootloader does its thing and finds "the kernel image", then loads it into memory and passes control to it. Now the memory some pieces of the kernel, but not all. To complete the loading, the part of kernel present in memory finds the rest of its pieces, loads them in memory and runs them. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Removing perl
>On Mon, 1 Oct 2012 01:47:46 +0700 >Kenno Han wrote: > > Hi, I'm planning on removing some stuff. > One of them is perl. > Now my question is: > Is it okay if I do that? Are there any package expecting it on > run-time? This is almost like cuting half your gut off. But it could work. Many builds expect perl, to generate some files, but most of those files are documentation. Perhaps you can make it. I think you can. Do report back and tell us what were the results. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libdrm Self Doubts
>On Tue, 28 Aug 2012 19:48:40 -0400 >alex lupu wrote: > Am I now condemned to run MesaLib-8.0.3 in perpetuity? > Having just read the article, > www.cnn.com/2012/08/27/tech/web/apple-linux-desktop/index.html?hpt=hp_t3 > all that had me slide into a really dark mood. How Apple WHAT?!? And that was my reaction after reading only the title. I will probably develop brain haemorrhage by the time I finish reading it. Well, of I go! -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] more on trying to get the drm nouveau kernel module loaded
>On Wed, 18 Jul 2012 17:53:27 + >John Burrell wrote: > You're right, it makes no difference and of course setting acpi=off > means the nouveau module is not loaded and it falls back to using > vesa. > > I guess this will have to stay as one of those quirky things that > doesn't have an obvious solution. I expect a nvidia driver programmer > could solve it but I don't have access to one of those. In the first or second mail with this topic, you wrote that you installed, among other things, the kernel module from the nouveau site. There is no need to do this. The kernel side of the nouveau driver suite has been added to the mainline kernel tree about a year ago and a month or so ago has been moved out of staging. This means that there is no need to pull things from the nouveau site for the kernel. You can just take any newer kernel. Say, Linux-3.0 or any after that. You should also try using releases instead of git snapshots in mid-development, at least to verify it works. Also, don't forget the Xorg driver for the server: git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/ I haven't seen you state that you built and installed it and there is no way X will start without it. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] more on trying to get the drm nouveau kernel module loaded
>On Tue, 17 Jul 2012 21:47:35 +0200 >"Armin K." wrote: > Yay, you missed the world. This is LFS, it does not use initrd ... > > And blacklisting nouveau does not disable KMS, it just disables the > driver from loading automatically by udev. That way you can boot > using VESA. Nouveau gets loaded when: Xorg Server starts or you > modprobe it manually. In either way, KMS will be enabled. > > Have you ever tried using nouveau with Ubuntu? Did it have same > behaviour? I think VESA is coliding with nouveau. Try not using it (use only the text console). The other possible problem is that you are using the newest (AKA still explosive) code from git for all three components. I have had amirable success with libdrm-2.4.26, mesa-7.11 and linux-3.4.4. Neither are bleeding edge, and they work together. Try rolling back to _releases_ of the packages and you may have success. "Success" defined as "IT WORKS AND DOESN'T CRASH!!!" and not as "I can play Mass Effect 3 with all settings maxed out and the game looks as good as on Windows!", although God may have mercy on thee. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Good DNS server for personal and home use?
>On Thu, 05 Jul 2012 18:02:47 -0500 >Bruce Dubbs wrote: > > Aleksandar Kuktin wrote: > > Hi guys! > > > > I have a question. I want to have my own DNS server. The main reason > > for this is to increase fault tolerance of my computer, make > > browsing the Web and Internet faster and more enjoyable and have a > > local miror of as much of the Internet as possible. > > > > But I am lost as to what DNS server I should put. > > > > For now, I want to run the server on my computer, serving only my > > computer. I will firewall it from the rest of the world. Later, > > when I move to my own place, I want it to run on a dedicated > > "master of the network" machine, serving the whole home. > > > > I was originaly going to go with BIND, but I have cold feet now > > because of it's many security holes, the ones they still keep > > discovering all the time. > > Which ones are those? I don't follow it closely any more, but bind-9 > has been pretty good AFAIK. The older versions (5, 8) did have a > reputation for problems, but I think 9 is OK. Okay, I let it slip here. I am subscribed to an aggregator of several distro security maillists and a few weeks ago there were a lot of fixes for BIND 9 coming in from there. Not that I actually took the time to look them over, they turned out to be a crash on an zero-length RDATA field and a defect in the DNS protocol. I do not consider crashes (Denials of Service) to be real security problems and the other one is not specific to BIND. I have also read that BIND 9 is secure, but am sometimes (all the time) paranoid. > Also, I would kind-of like to avoid reading a huge manual to > > set it up in a simple enviroment like this. > > Use the instructions in the bind configuration section of the book. > As far a bind goes, just make sure it uses udp and not tcp. The > problems in the past have been with regard to zone transfers, but > those only occur with tcp. > > Another reference that looks OK is > http://en.gentoo-wiki.com/wiki/HOWTO_Setup_a_DNS_Server_with_BIND > > On the other hand, using something without reading a huge manual can > be a problem. You need to know what you are doing when working with > low level internet protocols. > >-- Bruce Well, I made BIND run. Ended up reading most of the big fat manual so no time and effort savings there. But I had a lot of fun setting up my own top-level domain. :) Unfortunately, I only have one machine so all domains resolve to 127.0.0.1. The performance increase is admirable and about what I expected. However, I do have a problem with the perisheable cache. One of the alternatives, pdnsd, writes its cache to disk on shutdown and re-reads it on startup. This enables it to carry the cache over the power cycle, a feature I would like to have. Is there a way to make BIND do the same? I went over the configuration options in BIND Administrator Reference Manual but found nothing. Maybe there is something in the source tree? I should probably look there too. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Good DNS server for personal and home use?
Hi guys! I have a question. I want to have my own DNS server. The main reason for this is to increase fault tolerance of my computer, make browsing the Web and Internet faster and more enjoyable and have a local miror of as much of the Internet as possible. But I am lost as to what DNS server I should put. For now, I want to run the server on my computer, serving only my computer. I will firewall it from the rest of the world. Later, when I move to my own place, I want it to run on a dedicated "master of the network" machine, serving the whole home. I was originaly going to go with BIND, but I have cold feet now because of it's many security holes, the ones they still keep discovering all the time. Also, I would kind-of like to avoid reading a huge manual to set it up in a simple enviroment like this. Do you have any sugestions for a program which would fit my bill? I am going through Wikipedia, looking for interesting picks, and there are a few, but I would like to hear some real-world experience first. The number one priority is security, even though it will not be available to the public. The number two priority is hackability - I want to be able to fix it to suit my needs. Ideas? -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Thoughts on Xorg-7.7+
>On Mon, 25 Jun 2012 16:08:40 -0400 >alex lupu wrote: > Not a thought, just being picayunishly nit-picky: > > On the "libdrm-2.4.33" procedure (configure), > "--enable-nouveau-experimental-api; &&", > the semi-colon appears somehow extraneous to me. That's actually invalid syntax. The semicolon should fly. $false; && echo la bash: syntax error near unexpected token `&&' $ -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Browsers and Linux
>On Tue, 22 May 2012 19:28:49 -0400 >alex lupu wrote: > > > Jeremy Henty schrieb am 22.05.2012 um 14:47 Uhr > > > This belongs on blfs-chat, if anywhere. > > but I don't wanna chat :'( > > Regards, > -- Alex Then post it to lfs-chat (there is no such thing as blfs-chat, but there is lfs-chat) and we'll have ourselves a nice little rantwar. :) -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] vlc and DVDs
>On Mon, 16 Apr 2012 00:03:38 +0100 >Ken Moffat wrote: > In an infinite universe, I would devote a little time to this. In > reality, my accumulated backlog of computer things I *want* to do > covers about 2 years of my time. Ah yes, the age old problem. :) -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] vlc and DVDs
>On Sun, 15 Apr 2012 21:39:54 +0100 >Ken Moffat wrote: > > On Sun, Apr 15, 2012 at 03:27:23PM -0400, Michael Shell wrote: > > On Sun, 15 Apr 2012 17:50:25 +0100 > > Ken Moffat wrote: > > > > > i.e. it (slowly: the file is on a local disk) fills the > > > buffer, plays the buffer, then waits while it refills the > > > buffer. > > > > I doubt this is the problem, especially on a new machine, > > but in the past issues like this were a symptom that DMA > > mode was not enabled for the drive(s) in question. Are > > you sure the kernel is enabling DMA I/O for the DVD and > > the HD? > > > The disk is SATA, so using libata. All the googling I did in the > past suggests DMA is always on with libata for SATA devices (but see > below). > > BTW, is there a way to check for a drive's DMA mode in > > /proc on the newer (/dev/sda using) kernels? (In the old > > days it was in /proc/ide, but all that is routed through > > the scsi i/o system today.) > > I haven't found one. 'hdparm -t' reports > 112 MB/sec for the > disk, so I think DMA is definitely in use. However, it only reports > between 2 and 3 MB/sec for the DVD drive on /dev/sr0. BUT, that > plays fine (with minimal cpu load) if I use vlc without the DVD > menus, and similarly plays fine in xine. The wait for the buffer to > fill was on the hard disk. > > ĸen Sounds to me like a problem with VLC. Perhaps you should focus on it. Maybe a different version, some changes in configure switches... or maybe some of the underlying libraries? It has been a long time since I last compiled or used VLC so I don't remember what things it links to. If it uses one of the libdvd* packages, maybe the problem is in that direction, especially if Xine does that part differently (Xine is also ancient history with me). -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Opera 11.60 crash report LFS-7.0/BLFS 01/10/12
>On Thu, 12 Jan 2012 09:10:17 -0600 >rhubarbpie...@gmail.com wrote: > > [snip] > > I realize Opera isn't open source, but it's easily my favorite > browser. I'm confused as Opera works fine until closing. Is there a > dependency I'm missing? How can I determine the cause? You can try running it from the terminal. If it emits any messages, you may find them there. Alternatively, you could use a debbuger like gdb to pinpoint the exact instruction that crashes. Although the crash dialog probably gives you the information you would get in this way. And again, that information probably would not be very useful as there is no way to fix the problem in Opera, if it turns out Opera is the problem. And using a debbuger requires considerable skill and knowledge. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gdb and Cairo
>On Wed, 23 Nov 2011 19:35:46 +1100 >Wayne Blaszczyk wrote: > > ./configure --prefix=/usr --disable-werror > make > make -C gdb install > > This only installs the binaries and one of the libraries which is not > shared by binutils. This should make it into BLFS. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gdb and Cairo
>On Wed, 23 Nov 2011 00:56:00 + >Andrew Benton wrote: > > Indeed, gdb also > overwrites /usr/lib/libiberty.a, /usr/lib/libopcodes.a and a bunch of > header files all originally installed by binutils. It's like a > rootkit. > > Andy ... and heaven forbid your binutils and gdb have substantially differing content of those or all hell could break loose. No comment. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gdb and Cairo
>On Tue, 22 Nov 2011 23:59:40 + >Andrew Benton wrote: > > On Tue, 22 Nov 2011 15:29:13 +0100 > Aleksandar Kuktin wrote: > > > [snip] > > If you do that, won't it overwrite the libbfd.a that was installed by > gdb? > > Andy !?! I didn't even know gdb has it's own copy libbfd. Yes, it will overwrite gdb's copy which itself overwrote binutils' copy when gdb was installed. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gdb and Cairo
>On Tue, 22 Nov 2011 19:11:55 +1100 >Wayne Blaszczyk wrote: > > Hi, > Has anyone successfully built Cairo with GDB (GNU Debugger)? > I've have gdb 7.3.1 installed which is the latest and I get the > following error when building Cairo: > > > CC libcairo_trace_la-lookup-symbol.lo > CCLD libcairo-trace.la > /usr/bin/ld: /usr/lib/libbfd.a(format.o): relocation R_X86_64_32S > against `binary_vec' can not be used when making a shared object; > recompile with -fPIC > /usr/lib/libbfd.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[4]: *** [libcairo-trace.la] Error 1 > make[4]: Leaving directory `/sources/cairo-1.10.0/util/cairo-trace' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/sources/cairo-1.10.0/util' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/sources/cairo-1.10.0/util' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/sources/cairo-1.10.0' > make: *** [all] Error 2 > > I've tried versions 1.10.0 and 1.10.2 with the same result. > Any ideas on a fix? > > Thanks, > Wayne. > > PS. gdb is a dependency of nemiver, which is part of Gnome 3.2. Oh Jesus, I had this one too. Cairo-1.11.2. The solution was to go ALLL the way back and recompile the BFD library of binutils with -fPIC. It worked after that little nugget of wisdom. I did a "hot" install, which means I did not recompile everything after putting the new library. These are the commands: *in binutils-build: export CFLAGS=-fPIC ../binutils/configure [options] make configure-bfd make all-bfd make install-bfd unset CFLAGS I think this has no effect on statically linking stuff with libbfd.a. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libIDL-0.8.14
>On Mon, 21 Nov 2011 15:55:53 -0500 (EST) >Danny Vukobratovich wrote: > when I configure the package, here it error I get during configure: > > checking for LIBIDL...configure: error: in '/cources/libIDL-0.8.14': > configure: error: The pkg-config script could not be found or is too > old. Make sure it is in your PATH or set the PKG_CONFIG environment > variable to the full patch of the pkg-config. Well, welcome to dependency hell, if you haven't seen it before. You are missing pkg-config. It is a utility which keeps track of installed packages and compilation options necessary for using those packages. Look here: http://www.linuxfromscratch.org/blfs/view/svn/general/pkgconfig.html -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Using gpg1 was Re: Linux-PAM-1.1.3 and LFS 7.0
>On Sat, 19 Nov 2011 00:00:48 + >Jeremy Henty wrote: > > > Ken Moffat wrote: > > > If verifying keys means I need to create my own key, [...] > > It doesn't. For years I have used GPG/GPG2 to verify keys and I have > never told it to trust my key or anyone else's. The downside is that > GPG will complain every time that it can't trust the identity of the > keyholder even though it has verified that the file was signed with > the key. If you can tolerate that noise then you can use GPG to > verify signatures without worrying about trust. > > Regards, > > Jeremy Henty On the heels of the previous two e-mails, perhaps a hands on explanation could also help: When using GnuPG to verify e-mails, the task is split between the MUA and gpg in that MUA handles the mails to be verified and their signatures, while gpg handles the keys and the actual checking. So, to be able to check, your mail agent must be able to do so. I will assume you have that covered. Next, you have to get the keys. You probably know that, in public cryphography, a "key" has to halves: the private one, which is jelously guarded by the key owner, and the public part, which is let to wander the world. To ease the finding of the keys, there are such things as keyservers. They are just repositories of public keys. One is at pgp.mit.edu . Next, you need to know the identifier of the key. It is a 32-bit number, expressed in hexadecimal. For example: E608E56E, which is the identifier for Bryan Kadzban's key. When trying to verify, if gpg can not find the key, it will alert you and tell you the ID of the key. Get that ID and do this: gpg --keyserver pgp.mit.edu --recv-keys You can use any other keyserver, they sync with each other. If all went well, you will now have the key you can use to verify stuff. $gpg --verify ~/sigs/polipo-1.0.4.1.tar.gz.asc polipo-1.0.4.1.tar.gz gpg: Signature made Mon Feb 1 00:14:37 2010 CET using RSA key ID 0F8DA163 gpg: Good signature from "Mangrin Remailer Admin " gpg: aka "Christopher Davis " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 50D0 B58E 839F 5037 7D19 769F CEDB EE06 0F8D A163 $gpg --list-key 0F8DA163 pub 2048R/0F8DA163 2008-12-19 uid Mangrin Remailer Admin uid Christopher Davis sub 4096R/FA130C4A 2008-12-19 [expires: 2012-12-18] You can clearly see the warning that the key has not been verified. This is suboptimal, but not that bad, given the context: I have the key for some time and have checked earlier versions of Polipo. Also, the checks were diluted in time and space - by downloading the same signature several times over a few weeks/months, I reduce the chance of a successful attack against me: they may MiM me once, but three times is unlikely. I also had the benefit of being abroad for studies (I'm from Serbia and was studying in Croatia) and literaly changing both the country and the IP route to the Internet twice a year, further reducing likelyhood of a successful attack. This may also be done if you have two ISPs. Say, one broadband and one dial-up. Just download the signature first by broadband, then dial-up and verify the tarball with both. If all works, especially over a period of time, then you probably have the right signature. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux sites down for maintenance?
>On Fri, 16 Sep 2011 15:29:01 -0700 >Johnneylee Rollins wrote: > > On Fri, Sep 16, 2011 at 3:04 PM, wrote: > > Rumor is some Linux sites (kernel.org, etc.) have been down for > > more than two weeks: > So when you use plurals, you really mean singular? > > www.theinquirer.net/inquirer/news/2105947/hackers-break-linux-kernel-home > > > > Hope, everybody keeps it on the qt. > Linus has started to use github a bit and released a version on > github. He's even started playing with pull requests, though he > doesn't like the button for it. > > ~Johnneylee In the meantime, is there a place we can find the new Linux sources?? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: No X screen
>On Sat, 28 May 2011 09:46:49 +0100 >spiky wrote: > > I,m building an LFS/BLFS system and I,m having trouble getting X > screen, I have tried all the drivers EVEN the vesa 1,s none give ms a > Xscreen, I have updated the Kernel from 2.6.35.4 to 2.6.38 . but no > joy. Now the laptop worked with ubuntu 9.10 on it. What i,m looking > at is the kernel FOR ubuntu which might of been modified for ubuntu > (worth a try) Is it possible to get that in tar,bz form any where? > > Graphics card is > > Intel Corporation 82852/855GM Integrated Graphics Device (rev 01) > What, if eny, errors do you see when the X fails? Let us see them too. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg_librarie
>On Tue, 24 May 2011 15:59:52 -0500 >William Immendorf wrote: > > On Tue, May 24, 2011 at 11:02 AM, Aleksandar Kuktin > wrote: > > @ William: Are you sure you are not being trolled? > I don't think so, as he does follow directions sometimes. I think he > just doesn't understand the volunteer tech support here. > Okay. It's still a little weird... -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg_librarie
>On Tue, 24 May 2011 07:04:28 -0500 >William Immendorf wrote: > > (Janu: JUST SEND TO THE DAMN LIST!) > > On Tue, May 24, 2011 at 6:25 AM, janu mam > wrote: > > so here i added below one exactly in /etc/profile and saved # Set > > the initial PKG_CONFIG_PATH > > export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig > > started chapter 23 again:x window system:[see attachement file] > Where did you place it? Placement is important. It needs to go right > after the line that sets $PATH, otherwise, it will not work. > > (what follows is analysis from Janu's log file) > > (in /etc/profile.d/xorg.sh) > >XORG_PREFIX="" > You need to decide on a X.org installation prefix before you go ahead > and proceed with the rest of the instructions. Most Linux distros use > /usr, I personally use /opt/X11 myself. > > Remember, if you are using a prefix other than user, follow the book > on what it says to do next. > > And before I analize this any further, I really want to say two > things: FBBG and NRTUTRN. That's Follow Book, Book Good, and No > Running Testsuites Unless They are Really Needed. > > As for the last message: I think Bash thought the xtrans dir was a > command at some point. You probally have a typo in your script. Retype > it from it's source EXACTLY and try again. @ William: Are you sure you are not being trolled? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Mon, 20 Dec 2010 23:38:32 + >bendeguz wrote: > > > I'll see the test sources tonight to get more detail, but I think > > that is one of those test whose failure you can safely ignore. > Well, actually, I already did that. > Now I'm using the pached glibc build. I haven't built anything with > the "new" glibc, but I'm hoping the best:) Well, I've taken a peek at the sources, and I wouldn't know what to say. Perhaps it's something to do with the kernel version mismatch? Impossible to tell without a hard-grinding investigation. So go forth and watch out for anomalies, I guess. :) IF threading a potentially dangerous terrain is not a problem for you. You should know that glibc's tests are not always consistent. For example: when I rebuild my system, if I do tests for the temporary toolchain, those usually have no failures (apart from a few well-known ones). When I do them for the end system, they have them. ?? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Mon, 20 Dec 2010 12:25:55 +0100 >bendeguz wrote: > > bash-4.1$ grep Error glibc-check-log > make[2]: [/mnt/hd/buhera/glibc-build/posix/annexc.out] Error 1 > (ignored) make[2]: *** > [/mnt/hd/buhera/glibc-build/rt/tst-cputimer1.out] Error 1 make[1]: > *** [rt/tests] Error 2 make: *** [check] Error 2 > > the end of glibc-check-log: > > termios/sys/ttychars.h time/time.h time/sys/time.h time/sys/timeb.h > wcsmbs/wchar.h wctype/wctype.h > > /mnt/hd/buhera/glibc-build/begin-end-check.out make[1]: Target > > `check' not remade because of errors. make[1]: Leaving directory > > `/mnt/hd/buhera/glibc-2.11.1' > make: *** [check] Error 2 > > The script that's failing is the begin-end-check.pl > Maybe I can skip that test to see if the remaining test are runinng... You can do that by issuing `make -k check'. It will run all tests... mm.. actually, it will complete the Make target (check) without regards to errors. Same thing. I'll see the test sources tonight to get more detail, but I think that is one of those test whose failure you can safely ignore. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Sun, 19 Dec 2010 21:46:05 +0100 >bendeguz wrote: > The compiling runs fine, but the test fails. > I've tried with an unpatched glibc source as well. > I haven't updated any LFS packeges from my first build, > just BLFS packages and the kernel (and bzip). > Could that be a problem that I haven't updated the linux > API headers? > > bendeguz Do NOT, under any circumstances, update the linux API headers on a finished system. The cpp will become confused and the toolchain will brake. My first LFS went down the drain when I made that mistake. As for the glibc test mistakes.. Well, what are they? If you know what you are doing, you can ignore some of them, but first you need to verify what _exactly_ is failing, why, and can you live with that. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Sat, 13 Nov 2010 13:38:31 +0100 >bendeguz wrote: > > On Fri, Nov 12, 2010 at 09:50:08PM +0100, Aleksandar Kuktin wrote: > > > Do I have to recompile everything in minor glibc version changes > > > as well? > > > > > > regards > > > > You mean like 2.7->2.8 ? > > I would say 'absolutely, definitely yes'. > > > > For 2.7.1->2.7.2, I would recommend it. > > > Darn, I thought so... > And what if I apply a patch on glibc-2.11.1 and > rebuild it? Maybe it depends on the patch itself... If you apply the patch on you current library, and rebuild it with all options identical to those you used while first building it, you should not have any problems. The patches do not affect the outside library interface, only it's internal code and internal interfaces. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Fri, 12 Nov 2010 19:34:10 +0100 >bendeguz wrote: > > On Thu, Nov 11, 2010 at 11:31:03PM +0100, Aleksandar Kuktin wrote: > > > > Then again, I am a bit paranoid when it comes to my system's > > security. > > > So am I, but it scares me to upgrade glibc. I haven't done it on LFS, > yet. > Well, in fact not upgrading glibc scares me, but rebuilding my > system. > Do I have to recompile everything in minor glibc version changes as > well? > > regards You mean like 2.7->2.8 ? I would say 'absolutely, definitely yes'. For 2.7.1->2.7.2, I would recommend it. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: glibc vulnerability, CVE-2010-3847
>On Thu, 11 Nov 2010 21:16:53 + >Ken Moffat wrote: > > If you have no-one else with access to your machine, it probably > *is* a low priority - but we are all our own sysadmins, so we ought > to keep on top of vulnerabilities in everything we have installed. > > ĸen I'd just like to add that there is a loophole in this. Small, but still. This vulnerability is probably better classified as a "privilege escalation" vulnerability. The only way to exploit it is to first run code on your machine. Now, I may be a liiittle too paranoid about this, but I don't truly trust my browser. If one were to exploit the browser, one would be presumably able to exploit the glibc vulnerability. I would be even more paranoid if it were an invasive HTML5-ready browser, implementing the filesystem interface for web applications. Mind that I have not spent time learning about that interface, but if it allows creation of links, you my have a problem. Then again, I am a bit paranoid when it comes to my system's security. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Setting up transparent system-wide SSL/TLS infrastructure.
Has anyone experience on setting up fully transparent SSL across the system? Here is the gist: when first pushing through BLFS, I concentrated on having ANY network capabilities at all. I had some SSL/TLS capabilities, but not that many and I had almost no idea how to administer them. When I switched to Midori, I had to start thinking about this. I now have a CA bundle, generated from certificated coming with Mozilla sources. It is in /etc/ssl/certs and Midori now handles SSL by itself. But, other programs still need my help, like wget; and other, like the Subversion client, stil don't talk SSL for me. How am I supposed to set the infrastructure up? I have my certificates in: /etc/ssl/certs/ca-certificates.crt and a hard link to that file: /etc/ssl/certs/ca-bundle.crt -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnash-0.8.8
>On Mon, 30 Aug 2010 16:24:18 +0100 >Andrew Benton wrote: > > On 30/08/10 16:02, Aleksandar Kuktin wrote: > > Question: how do you get Midori to do that? > > Is it by that beta feature of Youtube where you first register and > > then you can get "raw" video streams (IOW without the flash)? > > > > Yes, you have to opt in and accept the cookie: > > http://www.youtube.com/html5 > > Andy OK, thanks. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnash-0.8.8
>On Mon, 30 Aug 2010 15:52:29 +0200 >bendeguz wrote: > > On Mon, Aug 30, 2010 at 01:14:06AM +0100, Andrew Benton wrote: > > > Midori will play h264 youtube videos as well as webm > > youtube videos so there are not many youtube videos it won't play. > > > > Tkanks! > I'm trying to get it working. I already have picture with h264, > but no audio, yet. But that's another thread... > > Regards, > bendeguz > Question: how do you get Midori to do that? Is it by that beta feature of Youtube where you first register and then you can get "raw" video streams (IOW without the flash)? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnash-0.8.8
>On Mon, 30 Aug 2010 00:40:49 +0200 >bendeguz wrote: > > I've installed agg and rebuilt gnash. I didn't specify > renderers, so now i have agg opengl and cairo. > I've tried an swf from the net. agg and cairo is working, > opengl has issues > > AFAIK, I can't use it as a plugin in midori. Am I right? > > So I found this guide to use gnash with youtube, but it looks crazy:) > > I don't understand it yet, so it needs more time for me:S > > bendeguz No, you can use it as a plugin. At least I did, and have experienced very few problems, apart from sites not working altogether (Vimeo) and that some 5-6 open flash objects can grind Midori to a halt (Gnash is a CPU hog). BTW, its real simple: compile and install Gnash, find libgnashplugin.so in the build tree and copy it to /usr/lib/mozilla/plugins. Midori will take care of the rest (I experince up to 20 second delays before it actually starts playing videos, so that too). This problem of yours may be due to various other packages. OpenGL may require some newer version of Mesa than you have. For sound, you may need SDL. Gstreamer works, but it may need some of its plugins (plugins-ffmpeg to be precise). I also noticed gnash links libcurl. So, presumably, you also need Curl to use Youtube? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnash-0.8.8
>On Tue, 24 Aug 2010 10:17:13 +0100 >luxInteg wrote: > > do you know if it works with gtk-2.18.9? > or indeed qt-4.x It does (tried with gtk-2.18.3). And rather nicely, also. :) You may need to think about adding --disable-glext and --enable-renderer=agg,cairo configure options. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Csound5.12.1 on 64-bit amd64cpu setup
>On Wed, 23 Jun 2010 12:50:41 +0100
>lI wrote:
>
> Greetings,
>
> Although not on the blfs/cblfs list Csound is useful for programs
> such as Gnash useful for programs such as konqueror. I had a go at
> compiling Csound5.12.1 a while ago and gave up. I returned recently
> on a box with the following features:-
> -(Linux{CBLFS}(64bit amd64 CPU kernel2.6.34 gcc4.4.2)/
> -I used the scons recipe shipped with the Csound5.12.1 tarball.
>
>
> I obtained the following output (with minor variations if
> 'DoublePrecision' is enabled or disabled in the scons recipe) on a
> number of occasions:-
>
> #
> [snip]
> ##
>
> I tried changing to in InOut/widglobals.h with the
> same result except for the reference
> to /usr/lib/gcc/x86_64-unknown-linux-
> gnu/4.4.2/../../../../...etc in the compiler output.
>
> Advice/help would be appreciated
>
> sincerely
> lux-integ
Hello,
>From what I can see in here, the breakage is somewhere in coordinating
the headers. I will now assume that your cmath header
in /usr/include/c++/4.4.2 is normally working (this ofcourse may not
necessarily be the case, but if you successfully built BLFS, then it
by itself probably works).
I have just double-checked on my system (CBLFS with GCC-4.4.3), and
what may (or may not) be the likely source of trouble is the math.h
header. The one you need is /usr/include/math.h . With all those -I
flags up there, could it be that another math.h (or a different cmath
for that matter?) is being preloaded??
`gcc -M' should help you pinpoint all the headers that are being
included (do not forget to remove the -o what/ever.o flag).
-AKuktin
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
