Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Thu, Apr 24, 2014 at 08:02:58PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > > Thanks for the pointer (I have not built systemd at the moment, > > still trying to sort out enough details for me to have a chance of > > getting the whole thing working). But your use of sysctl looks > > unnecessarily long-winded : why not just something like this ? : > > > > sed -i 's/#LogLevel=info/LogLevel=warning/' \ > >/etc/systemd/system.conf > > I'm a bit confused. Are you referring to what's in the -dev book right > now? Or the part about sysctl that I abandoned as possible but too complex? The latter - when you first mentioned it, it was the main thing that I noticed for setting the log level. The change to permit systemd was large, and mostly went in as a single commit (compare good uses of git, where there are a series of patches, hopefully each small enough to review). You have spent a few weeks on sysv-with-systemd, and got it to your liking. The rest of us have a steep learing curve, and many areas where we need to find out how to change things. For me, log level is a fairly minor thing, but with a _lot_ of scope to make the system awkward to use _when_ other things are not correct. I think examples are always useful, and had read your posting about sysctl as an example. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Wed, Apr 23, 2014 at 12:09:26AM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote: > >> > >> Last night I was trying to figure out how to set the dmesg log level in > >> systemd. It turns out that it can be done with sysctl and set: > >> > >> kernel.printk = 4 4 1 7 > >> > >> where the numbers are console_loglevel, default_message_loglevel, > >> minimum_console_loglevel, and default_console_loglevel. The only number > >> we really are concerned with is the first. > >> > >> This can be done in either sysd or sysv, but it's not as simple as > >> setting LOGLEVEL=4 and then use dmesg -n $LOGLEVEL in a script which is > >> how we do it now. > >> > > > > I think that ought to be documented somewhere in LFS. Googling for > > this, all that came up was a recommendation from Arch to pass > > loglevel=4 [ they actually recommend 3 ] among the boot arguments. > > > > Also, I haven't ever needed to use sysctl in the past - it appears > > to be something that is set at runtime, so if I had needed it I > > would have put it in an initscript. If I do this with systemd, how > > am I _supposed_ to do it ? [ google is not helpful, or I've got the > > wrong search args ]. > > Hmm. > http://www.linuxfromscratch.org/lfs/view/development/chapter07/sysd-custom.html > > 7.1.1: "The /etc/systemd/system.conf file contains a set of items to > control basic operations. The default file has all entries commented out > with the default settings indicated. This file is where the log level > may be changed as well as some basic journal settings." > > Perhaps I need to make that more obvious. > >-- Bruce > Thanks for the pointer (I have not built systemd at the moment, still trying to sort out enough details for me to have a chance of getting the whole thing working). But your use of sysctl looks unnecessarily long-winded : why not just something like this ? : sed -i 's/#LogLevel=info/LogLevel=warning/' \ /etc/systemd/system.conf ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote: > > Last night I was trying to figure out how to set the dmesg log level in > systemd. It turns out that it can be done with sysctl and set: > > kernel.printk = 4 4 1 7 > > where the numbers are console_loglevel, default_message_loglevel, > minimum_console_loglevel, and default_console_loglevel. The only number > we really are concerned with is the first. > > This can be done in either sysd or sysv, but it's not as simple as > setting LOGLEVEL=4 and then use dmesg -n $LOGLEVEL in a script which is > how we do it now. > I think that ought to be documented somewhere in LFS. Googling for this, all that came up was a recommendation from Arch to pass loglevel=4 [ they actually recommend 3 ] among the boot arguments. Also, I haven't ever needed to use sysctl in the past - it appears to be something that is set at runtime, so if I had needed it I would have put it in an initscript. If I do this with systemd, how am I _supposed_ to do it ? [ google is not helpful, or I've got the wrong search args ]. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Mon, Apr 21, 2014 at 03:28:01PM -0500, Bruce Dubbs wrote:
> Pierre Labastie wrote:
> > Le 21/04/2014 20:49, Bruce Dubbs a écrit :
> >> Pierre Labastie wrote:
> >>> Le 20/04/2014 23:26, Ken Moffat a écrit :
>
> >> For convenience I also have scripts to mount and unmount virtual file
> >> systems and to clean up $LFS prior to the start of a new build. I also
> >> have an alias to enter chroot.
>
> > All that is also in jhalfs:
> > - make -C /mnt/lfs/jhalfs devices # for mounting virtual files
> > - make -C /mnt/lfs/jhalfs teardown # for unmounting them
> > - Cleaning is done if you tick "General Settings->Rebuild files"
> > - make -C /mnt/lfs/jhalfs chroot # mount the virtual files and enter chroot.
> > Unmounting is done automatically at exit.
>
> There are times when something fails in Chapter 6. There it is nice to
> be able to enter chroot via a simple alias: lfs='...'
>
> My mounting and unmounting does a little more. For instance, I also
> bind mount /usr/src so I can build non-lfs packages in chroot.
>
> My cleaning does more than that. It removes $LFS/{bin,sbin,usr,...}
> after unmounting virtual filesystems, and /usr/src.
>
> There are lots of techniques and I'm sure a lot of users develop their
> own way of doing things. Providing ideas is a good thing though.
>
>-- Bruce
Thanks to both of you for the suggestions. I remember trying jhalfs
when I was on cross-lfs : yes, copying everything to /sources is
probably going to work, but it doesn't fit with the rest of my build
(particularly the BLFS part, and the sanity checks in my own scripts).
There is also a deeper difference - jhalfs was originally a tool for
builders. As an editor, my preference is to look at a new package
version on a completed system [ normally, just a DESTDIR ], see what
options I want to use [ e.g. omit static libs even in LFS, unless they
turn out to be required somewhere ]. Only once I'm happy that the
resulting _system_ is ok will I think about editing the XML. And on
a desktop, the resulting system is normally my full normal desktop,
so that I can pick up knock-on effects in later packages.
So, my method has the danger that the resulting instructions will
occasionally be incorrect (e.g. 'check' for 'test' in graphite).
The jhalfs method appears to require me to prepare the XML as a
first step before I have confidence it will work, and I continue to
feel that is back-to-front ;-)
Anyway, I'm unlikely to progress far with my attempt to test
sysv-systemd for a while - got a problem in kernel 3.15.0-rc2 on one
of my machines [ blank screen on one of my radeon machines ], need
to take time out to explore that. My weakest, slowest, machine -
of course. The other two (R600, intel) are fine with rc2.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Sun, Apr 20, 2014 at 06:00:51PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > On Sun, Apr 20, 2014 at 05:19:22PM -0500, Bruce Dubbs wrote: > >> However there is a method to their madness and > >> LFSers should be able to pick it up relatively quickly. > >> > > Don't get me started on what that "method" might be ;-) > > That method is different files, different formats, and different > locations. The principles are generally the same as they must be. > Generally though, they don't use executable scripts. > >-- Bruce > Yeah, change for the sake of it (aka giving everything to the "design" kiddies who wrecked gnome), or "why write a few lines of interpreted shell, when you could do something harder or buggier". ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Sun, Apr 20, 2014 at 05:19:22PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > Really, the only thing that's different through the end of Chapter 6 is > adding new packages. Skipping systemd and adding eudev is all that is > needed to do a straight traditional build (with a few packages from > BLFS). D-Bus is not started by default in the System V setup, but the > binaries are built and installed. > Yeah, but for the current LFS-svn bootscripts (see my post on -chat from a few hours ago) the name/location of udevd and udevadm have changed. > > > My impression is that you _have_ addressed the > > keyboard and font setup, > > Not yet. At least not to my satisfaction. > Oh well, I'll wait to see what you come up with. As I said, my own settings are quite different from the book so I don't pay too much attention to the existing sysvinit examples. I did see at least one example in configuring systemd and I think it probably tells me enough to sort out my own builds. >However there is a method to their madness and > LFSers should be able to pick it up relatively quickly. > Don't get me started on what that "method" might be ;-) Cheers. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote: > BLFS Trac wrote: > > > Comment (by ken@…): > > > At the moment I'm still trying to absorb the systemd changes in LFS - my > > own scripts now build a working LFS with eudev and _current_ LFS > > bootscripts, and I'm fairly confident that the systemv-on-systemd build > > will work when I test it. But I'm not yet confident about what I need to > > add so that I can successfully convert it to boot systemd (keyboard, font, > > dhcp), let alone how to convert my own private bootscripts (fix cpufreq, > > run a smartd check at boot), nor the changes to ensure that the various > > daemons will be started by systemd (e.g. postfix, nfs That will probably > > take me the rest of this month, maybe a bit longer depending how hard it > > is to convert my own initscripts to work with systemd. After that I > > intend to build the parts of BLFS which I use on my normal desktops, so > > I'll hopefully be able to fix _some_ of the issues. > > Moving to -dev for additional discussion. > > My objective is to allow users that do not want to consider or even try > systemd to continue to do what they are already doing. > And you appear to be achieving that. I don't like "that new thing", but I can see the logic of what you are doing. > (If you like your current scripts, you can keep your current scripts. > That's an inside political joke, but most Americans will get it.) > I've no idea what that refers to, but it doesn't matter. I know that (at least) you and Pierre use jhalfs, and for me that is unusable (/scratch is an nfs mount on/from my server, I _really_ do not want to try to build there - by the same token, I use different 'patch' commands). None of these things matter, and I've now developed my scripts to do better logging of what got installed, and what got modified. My point was that _many_ people who build LFS-svn will either copy and paste, or will already have their own scripts. As you said (paraphrasing), this is a major change - those of us with our own scripts will have to take the time to understand it, and all of us ought to notice that a few "new" packages are now in LFS. > I am currently reorganizing and rewriting Chapter 7. It's not an easy > rewrite because I need to figure out the organization as well as the > content. I do intend to address things like keyboard, font, etc. I > wasn't going to address dhcp because we do that in BLFS, but simple dhcp > is built into systemd, so I may say something about that. > Yes, I saw the posts this week about dhcp and checked the systemd references. That part is now in my sysv-systemd buildscripts, but not yet tested. My impression is that you _have_ addressed the keyboard and font setup, but I need to look at the detail (e.g. many of my builds will still be eudev and will not include systemd or dbus in the LFS part, so I need to confirm whichh sort of build I'm running, and perhaps make the systemd configuration conditional (e.g. if the directories were created by systemd and therefore do not exist). Also, my console sttings are quite different from the book (one of my LatGrkCyr fonts, either 8x16 or 12x22 depending on the machine, and my own keymap to give me _some_ useful compose sequences - actually, I keep hoping I'm going to be able to spend time on both of those: my fonts could do with a few improvements, and I'd like to get some sort of cyrillic and (ideally) greek input working on the console, but everything else continues to get in the way ;-) . > Actually, systemd is supposed to honor System V boot scripts, but I > haven't checked that out. > Thanks for the reminder - I had seen that before, but forgotten about it because I never wanted to use that package. Maybe I'll give it a try on this build. > Armin has created some systemd services for daemons and I want to > incorporate those in the BLFS bootscripts. I've prototyped the Makefile > so that it installs what is needed if the underlying directories are > present. The changes should be transparent to users that only want sysv > or only want sysd in addition to those who want to try both. > That sounds useful, but I dare say that I'll want to look at the details of creating systemd services in any case : partly because I'm as anal as most other LFS users, and partly so that I can support user problems. > Last night I was trying to figure out how to set the dmesg log level in > systemd. It turns out that it can be done with sysctl and set: > > kernel.printk = 4 4 1 7 > > where the numbers are console_loglevel, default_message_loglevel, > minimum_console_loglevel, and default_console_loglevel. The only number > we really are concerned with is the first. > > This can be done in either sysd or sysv, but it's not as simple as > setting LOGLEVEL=4 and then use dmesg -n $LOGLEVEL in a script which is > how we do it now. > Thanks for that - I hadn't even thought ab
Re: [blfs-dev] html5
> > Thanks Ken. I was given a URL to check out for teaching. Please see if > you can use www.TestOut.com/newlabsim > > I don't think there's a password for the beta test but I didn't get that > far. If it seems to work for you, then I'll go build FF for this platform. > >-- Bruce > It opened a new window, occupying the whole screen. And then it appears to need me to set up an ID, including email and activation code - from that I guess that they (whoever they are) will use the email to send me the activation code. I'm not inclined to do that. Going back to the the site itself, I don't think you need to bother. The first item in "List of Known Issues and Bugs" is: Mozilla Firefox not supported Mozilla Firefox is not yet supported. For now, we encourage Linux OS users to use Chrome to sign in to the HTML5 LabSim. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] html5
On Fri, Apr 18, 2014 at 11:38:53PM +0200, Aleksandar Kuktin wrote: > >On Fri, 18 Apr 2014 14:40:34 -0500 > >Bruce Dubbs wrote: > > > > I'm currently using seamonkey-2.10.1 (vs current 2.25) and I've found > > my html5 support to be a little lacking. I've found the site > > http://html5test.com/index.html and have a browser score of 337. > > What types of scores do others get for your browsers? > > > > I did check my konqueror (4.12.2) and it basically doesn't work at > > all with a score of 103. I haven't yet built firefox on this system. > > > >-- Bruce > > I get 286 with Midori-0.5.7 and WebKit-1.10.0. > > But, honestly, I think noone in their right mind would target a maximum > score of 555 since that score also includes the following things: > * Geolocation > * Webcam access > * Speech recognition (including microphone access) > * Filesystem access > * WebRTC > * DRM support (included for completeness, does not carry points) > * Javascript capability (taken for granted, also doesn't carry points) > > A browser that supports all the above misfeatures (with the exception > of DRM) is the very definition of "trojan malware". > In descending order: firefox-28.0 448. arora [ and the site correctly notes: You are using an unknown browser that imitates Safari 4.0.4 on Mac OS X 10.6.1 ] 299. Breakdown for these, in case anybody cares: firefox arora Parsing rules 10 10 Elements21/30 8/30 Forms 63/110 70/110 Microdata 5 0/5 Location and Orientation 20 0/20 that's a bit worrying re firefox, but not surprising Output 10 5/10 Input 13/20 0/20 User Interaction22/25 22/25 Performance 20/25 24/25 Security28/40 23/40 History and Navigation 10 10 Video 25/35 25/35 Note that the tests for video codecs aren't counted in the results, but my arora supports MPEG-4 and my firefox doesn't (that might be be because I build firefox early, dunno). It's also not necessarily correct - firefox can happily play back a local mp4 file, although the image size is pretty small. Audio 27/30 20/30 Peer To Peer15 0 2D graphics 19/25 0/25 3D graphics 20/25 0/25 Animation 5 0/5 Communication 35 26/35 Web Applications20 15/20 Storage 30 10/30 Files 10 10 Other 20 9/20 links - tried this for a laugh, it _really_ doesn't work at all (no javascript). Overall, my inclination is to ignore these results completely! If and when I see new breakage, perhaps I'll review that decision. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12879 - in trunk/BOOK: . introduction/welcome x/lib xsoft/graphweb
On Wed, Mar 19, 2014 at 03:24:16PM -0500, Bruce Dubbs wrote: > k...@higgs.linuxfromscratch.org wrote: > > Author: ken Date: Wed Mar 19 13:02:11 2014 New Revision: 12879 > > > > Log: mozconfigs for firefox and xulrunner : move the pulse option > > above 'It is recommended not to touch anything below this line'. > > Have I ever mentioned that I really dislike the phrase "It is > recommended..." Recommended by who? These should be reworded. > > If it's upstream, then say Upstream developers recommend... > > If it's us, then work around it. > > In this example we have > > "# It is recommended not to touch anything below this line" > > How about > > "# Users generally do not need to change anything below this line" > >-- Bruce Sounds good, but I'm doing other things at the moment. Change it if you like. 'De gustibus non est disputandum' as my old latin master would have said. What gets me is the phrase "The BLFS staff has determined", e.g. in mutt : I think 'staff' should have a plural form of the verb[¹], but I would feel a lot more comfortable with "the BLFS editors have determined". As with many things in the books, perhaps it's only me who gets upset. ¹ - a verb in the singular would be appropriate for a wizard's staff made of sapient pearwood. Let the anglo-american grammar skirmishes recommence ;) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] [BLFS Trac] #4806: sudo-1.8.10p1
On Sun, Mar 16, 2014 at 04:55:05PM -, BLFS Trac wrote:
> #4806: sudo-1.8.10p1
> -+---
> Reporter: fo | Owner: fo
> Type: enhancement | Status: assigned
> Priority: normal | Milestone: 7.6
> Component: BOOK | Version: SVN
> Severity: normal | Resolution:
> Keywords: |
> -+---
>
> Comment (by fo):
>
> Have just discovered that sudo builds static libraries:
>
>
> {{{
> --enable-static[=PKGS] build static libraries [default=yes]
> }}}
>
> Do we want that?
>
I see you've already addressed this, and at the moment I only have
1.8.9p5 here [ which had the same message in ./configure --help ],
but does it really install statics without that switch ?
I've seen many packages which say one thing in their help, and do
something else. I think this is another (unless it really did
change in 1.8.10). Please note : if I'm right, please don't waste
time reverting this - there is almost certain to be a newer version
of sudo in a day or two.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12873 - trunk/BOOK/networking/mailnews
On Sun, Mar 16, 2014 at 03:48:21PM -0700, bdu...@higgs.linuxfromscratch.org wrote: > Author: bdubbs > Date: Sun Mar 16 15:48:21 2014 > New Revision: 12873 > > Log: > Null enties don't render correctly > Sorry! The link disappeared, I didn't remember that the text to its left (but not the bullet) was also supposed to go. I'll try to remember in future. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] Files in BLFS svn missing on anduin
On Sun, Mar 16, 2014 at 12:28:47PM -0500, Bruce Dubbs wrote: > bdu...@linuxfromscratch.org wrote: > > > Missing mutt-1.5.23.tar.gz > The http url seems to be invalid. We probably should just remove it. > I usually check the http url and if it's OK, skip the ftp. However the > currency check usually starts with the ftp url unless I found out > manually that it needed to be changed to extract the latest version. > Odd, I thought that was where I got it from! I see that arch are using the ftp link, and the http:// now drops me at sf without any obvious way fo finding 1.5.23. I can't find any direct links in the announcements I originally saw, so I now have no idea how/where I got it. Will comment the http URL. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Package Currency
On Tue, Mar 11, 2014 at 10:30:13PM -0500, Bruce Dubbs wrote: > > The naming of files is also quite inconsistent. For example, we have > junit4_4.11.orig.tar.gz. First why do they need to tell us it's version > 4 twice. Second, why do they need to add 'orig'. What else would it > be? Binary? If so, then for what architecture? Actually junit is java > and you don't have binaries. > Standard debian (and its derivatives, in this case ubuntu) - they probably have a policy for it, along with the underscore in the name. Remember that debian has some very old versions of certain packages, and that different packages may depend on either the old or the new versions. So in this case, it's like libcap which they named as libcap2 when we were using them for the source. The 4.11 tells us the actual version. The '.orig' confirms it is upstream (sometimes there is an abbreviation dfsg (debian free software guidelines) which I _believe_ indicates that certain parts of the source have been removed for licencing issues. Depending on the age of the package, sometimes there is also a '.debian.tar.gz' which contains the debian files for modifying their build system, as well as patches, changelog, list of files installed, etc. Their binaries are normally packaged as _*.deb files, with an indication of the architecture such as amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, sparc and perhaps some other linux arches, as well as the non-linux. in the case of java the binary is _all.deb : for debian itself, junit is still at 3.8.2. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [lfs-dev] LFS and Git
On Sun, Mar 09, 2014 at 09:16:42PM -0500, Bruce Dubbs wrote: > > Merging is generally not needed by me, but that may be the reason Armin > wants to move to git. I can't remember the last time I needed to do a > merge. > My back story : I used to contribute to CLFS, but I dropped out when it went to git beccause at that stage i only knew enough to break things. Since then, I've moved my own buildscripts to git. I've broken things a couple of times in my own merges, but now I feel fairly confident in using it. For me, git merge --no-ff -m "some message" lets me put a message in my git log (probably not relevant ot LFS/BLFS), and when merges fail (e.g. because I put a fix in my master branch, then later put a better fix in my development branch), "git status ; git diff file-with-problem"shows what needs to be fixed. The great benefit of git is in branches - in svn, a branch is "cast in stone" and is a PITA. In git, branches are just pointers. If you want to maintain a stable branch, you can cherry-pick specific commits from another branch (such as master). To do that on LFS or BLFS, I suspect that things might work better if date changes in general.ent were separated from other changes - I think CLFS has usually done that. There have been at least two occasions in the past when I've thought about branching BLFS, but in svn it didn't seem worth the pain. As has been said, with git you can stash changes, work on fixing something else, and then go back to them. That is often a great benefit. The big benefit of svn is increasing decimal revision numbers. Mercurial seems to provide that (as well as hashed commit numbers), but I cannot see any reason to move to mercurial. When CLFS changed to git, it appeared that a "gatekeeper" was needed to pull changes, but freedesktop.org, or at least the xorg parts, appear to have many people commiting to the master branches. I understand why alfs is a good place to try out changes, but it isn't something I can use (/sources on my development machines is an nfs mount from my server, I _really_ don't fancy the time it would take to build there). Also, I think Igor has an svn->git feed to github ? I would welcome his comments. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Package stats
On Thu, Mar 06, 2014 at 02:36:02PM -0300, Fernando de Oliveira wrote: > Em 06-03-2014 13:36, Bruce Dubbs escreveu: > > > >So build size is measured as df_after - df_before. The issue to note > > is that there is activity during the build that adds or deletes space on > > /tmp, the size will be off. I have /tmp on its own partition. > > To me, that seems excessively complicated. But each to his own. > > > Thanks, Bruce. > > I find "du" more accurate, although more tome consuming, so have to to > mark some instants to avoid it from interfering in the timings. > > On example is that df wil include the log size, perhaps you think it is > relevant. When I measure for the book, I don't usually make logs! If I am making logs, I usually put them in ../ and use du for the directory and for the DESTDIR or equivalent directory. > > But all numbers we give are approximate, large error bar, so I do not > dispute methods or numbers. Agree, I see large variations - even in remeasuring the SBU. > > The problem there is that Ken found values very different, even one > negative: building the API docs takes less than installing the ones in > the tarball, is one example, and I can hardly believe this is possible: > build taking less time than just installing the documents. > Did I write that ? I intended to say that rebuilding the API docs took a lot of extra time, but that the space used was 1MB less - I guess that the recreated docs are trimmed down. > As I introduced many of these numbers, probably after what Ken used to > do with ImageMagick, what I think is that being non-english speaking > native, I am giving wrong names to what I measure. That was the reason I > detailed how and what I measure there. It seems I need to rename in the > book, some number I gave. > > What I mean is: everybody know 1 inch is different from 1 cm. But I can > use a ruler, make a measurement and tell Ken it is 1, using a cm ruler, > but he thinking I am using inches. > > He is not wrong > > I am not wrong > > We are giving numbers for different things, probably my fault of not > writing carefully what my number means. > It is clear that my rebuild of the docs was very different from Fernando's. At the moment I'm concentrating on rebuilding everything in chroot, just in case there is any breakage from accidental change in gnutls. My first attempt at LO just timed out on one of the downloads, so I guess I'm hours away from completing. After that, I'll take another look. Unfortunately, this system with gnome packages is my only 7.5 system with gtk-doc and p11-kit, so I can't do comparative tests on the other box. What I did notice was a *lot* of activity during the rebuilding of the docs (not logged, so I watched stdout scroll past, with references to html at one point. Guess I'd better create logs when I come back to this, so that I can summarise the difference in the builds. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Thu, Mar 06, 2014 at 09:40:31AM +0100, Armin K. wrote: > > Then again, when it comes to header changes it most likely results in an > ABI break too or simply removing deprecated functionality (yay ffmpeg), > so you have to rebuild one way or another. But then still, you only need > to rebuild what gets linked against the libraries. Exceptions are gcc > and glibc. > Yes, this is my point. The book is about starting from a minimal LFS system and building from source. I'm hoping that no minor breakage like this will show up, but it certainly would not be the first time. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Thu, Mar 06, 2014 at 04:18:45AM +0100, Armin K. wrote: > > That's rather not correct. > > If a package a is dynamically linked to package b and package b gets > updated to new version that doesn't have an ABI break (soname in b v1.2 > is same as in b v1.0, ie libb.so.1), you *don't* need to recompile > package a or anything else. > > In case of ABI break (b v1.4 has libb.so.2 and b v1.2 has libb.so.1), > only the packages that link against libb.so.1 have to be recompiled > against libb.so.2, NOTHING ELSE. > > In the gnutls case, you didn't need to recompile anything since there > was no ABI break (there was, but it was reverted since it was not > intentional). > > So even when you upgrade glibc from version 2.12 to version 2.19, you > don't need to rebuild anything, since libc.so.6 in 2.19 still exports > the same interfaces it did in 2.12 and also some aditional ones that got > introduced later, but they are not important since they are not used by > the software compiled against 2.12. > That is a correct statement of how things ought to be. But many developers are like me - we make mistakes. For a distro which ships binaries, no big deal. Similarly, fixing an existing BLFS-7.5 with latest gnutls works. But there have been many cases over the years where minor changes cause accidental breakage. I'm thinking of changes to headers - those sorts of things only show up when building a fresh system. Based on your previous mail, I've moved gnutls, glib-networking, and their required/recommended dependencies, to _much_ earlier in my build so that I can hope to exercise most possible users. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Thu, Mar 06, 2014 at 03:31:37AM +0100, Armin K. wrote: > On 03/06/2014 02:49 AM, Ken Moffat wrote: > > > > What I can't do at the moment is confirm what uses this. I suspect > > that it is dynamically loaded when https:// has to be negotiated. > > Can somebody remind me, please, of the package which identifies > > dynamically loaded libraries ? I think Igor mentioned it a while > > back, and I'm fairly sure that Fernando showed some output from it, > > but I can't find it in my notes. Thanks. > > > > ĸen > > > > For your information, this is list of executables and libraries that's > linked to libgnutls.so.28 on my system: > > /usr/bin/gnutls-serv > /usr/bin/gvnccapture > /usr/bin/gnutls-cli-debug > /usr/bin/p11tool > /usr/bin/crywrap > /usr/bin/certtool > /usr/bin/ocsptool > /usr/bin/danetool > /usr/bin/srptool > /usr/bin/psktool > /usr/bin/gnutls-cli > /usr/lib/libgvnc-1.0.so.0.0.1 > /usr/lib/libgtk-vnc-2.0.so.0.0.2 > /usr/lib/libavformat.so.55.19.104 > /usr/lib/samba/libauthkrb5.so > /usr/lib/gstreamer-1.0/libgstfragmented.so > /usr/lib/gio/modules/libgiognutls.so > /usr/lib/libgnutls-openssl.so.27.0.2 > /usr/lib/libgnutls-xssl.so.0.0.0 > /usr/lib/vlc/plugins/misc/libgnutls_plugin.so > /usr/lib/libgvncpulse-1.0.so.0.0.1 > /usr/lib/libgnutlsxx.so.28.1.0 > /usr/lib32/libgnutls-openssl.so.27.0.2 > /usr/lib32/libgnutls-xssl.so.0.0.0 > /usr/lib32/libgnutlsxx.so.28.1.0 > > Most of these are actually executables and libraries installed by gnutls > package itself. Others include glib-networking, which is glib's tls > implementation and any GTK+/GLib app that uses TLS is actually using > GnuTLS (including epiphany), gtk-vnc, ffmpeg, samba, vlc, > gstreamer-plugins-notsure-1.0. > Many thanks for that. I don't have libavformat, gstreamer, or vlc linked to gnutls (I build them before it), and I only built pulse on a system without gnutls. The key is obviously glib-networking. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Wed, Mar 05, 2014 at 08:17:50PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > > > For anyone who wasn't aware of this vulnerability (I suspect that > > in this case I'm behind the curve, and you've probably all already > > fixed your own affected systems), 3.2.12.1 builds with the current > > instructions, and links to the book's current version of p11-kit. > > The timings for make check and for rebuilding the docs are, however, > > quite different on my machine. I'll put it in the book when svn is > > open, > > The book is released. svn is open now. > >-- Bruce > Thanks. > > and then do a chroot gnome build to try to spot anything which > > fails to build. Started a few minutes ago. Unfortunately, gnutls is near the end of those desktop builds on which I use it (gnome, or normal+xfce), so it is going to take some time. At least I've got through gcc pass 1 with make -j4. This makes me understand why debian stable updates take so long : test everything, get ready, get hit by a new vulnerability, rebuild everything. At least the BLFS book, and my own builds using gnutls, don't have so many packages as debian. BTW I haven't seen a release announcemnt yet, so I'll take this opportunity to thank you for all the work you've put into 7.5. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Wed, Mar 05, 2014 at 11:03:15PM +, Ken Moffat wrote: > > Those who are able to read https://lwn.net/Articles/589291/ (might > be subscriber-only for the next 2 weeks, I'm not sure) will see from > nix's comment that there is already a second "fix" version of gnutls > (perhaps the first will be fine for BLFS), and _apparently_ it needs > a new version of p11-kit. > > My gut feeling is that we should get the current book out the door, > but continue to recommend that people use the development version of > the book. For anyone who wasn't aware of this vulnerability (I suspect that in this case I'm behind the curve, and you've probably all already fixed your own affected systems), 3.2.12.1 builds with the current instructions, and links to the book's current version of p11-kit. The timings for make check and for rebuilding the docs are, however, quite different on my machine. I'll put it in the book when svn is open, and then do a chroot gnome build to try to spot anything which fails to build. What I can't do at the moment is confirm what uses this. I suspect that it is dynamically loaded when https:// has to be negotiated. Can somebody remind me, please, of the package which identifies dynamically loaded libraries ? I think Igor mentioned it a while back, and I'm fairly sure that Fernando showed some output from it, but I can't find it in my notes. Thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Wed, Mar 05, 2014 at 11:10:16PM +0100, Pierre Labastie wrote: > Le 05/03/2014 22:34, Ken Moffat a écrit : > > On Wed, Mar 05, 2014 at 02:04:16PM -0600, Bruce Dubbs wrote: > >> > >> Are we ready to release? > >> > >>-- Bruce > > Yes. > > > > ĸen > > > Well, I think it's never ready anyway... > > Go for it! > > Pierre Alternatively, perhaps we should see if we can fix the now-public gnutls vulnerability (potential man-in-the-middle attack from crafted certificate), although I don't see any practical way of testing the fix. Those who are able to read https://lwn.net/Articles/589291/ (might be subscriber-only for the next 2 weeks, I'm not sure) will see from nix's comment that there is already a second "fix" version of gnutls (perhaps the first will be fine for BLFS), and _apparently_ it needs a new version of p11-kit. My gut feeling is that we should get the current book out the door, but continue to recommend that people use the development version of the book. Call me a wimp, but I don't think this will be the last known vulnerability. The real danger is that a change in either of these packages might break compilation of something which pulls them in as a dep of another package, so that the only real way to test would be on a fresh build, not on an upgrade. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Wed, Mar 05, 2014 at 02:04:16PM -0600, Bruce Dubbs wrote: > OK, strigi and pygobject are fixed. > There have also been a few typos fixed and other touchups. > libexecdir has been addresed. > > Is there anything else? > > Are we ready to release? > >-- Bruce Yes. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] strigi-0.7.8 and clucene-2.3.3.4
On Thu, Feb 27, 2014 at 01:11:16AM -0500, Chris Staub wrote: > On 02/27/14 00:37, Bruce Dubbs wrote: > > I have a problem with the book's instructions building strigi. clucene > > is listed as an optional dependency and I have that installed. The book > > has > > > > cmake -DCMAKE_INSTALL_PREFIX=/usr \ > > -DCMAKE_INSTALL_LIBDIR=lib \ > > -DCMAKE_BUILD_TYPE=Release \ > > .. && > > > > It gives a linking error with libclucene-core.so. Something about > > > > undefined reference to symbol > > '_ZN6lucene4util14atomic_threads16atomic_decrementEPj' > > /usr/lib64/libclucene-shared.so.1: error adding symbols: DSO missing > > from command line > > > > Even though the symbol is in libclucene-core.so and it is specified when > > linking. > > > > I can only get it to build with > > > > cmake -DCMAKE_INSTALL_PREFIX=/usr \ > > -DCMAKE_INSTALL_LIBDIR=lib \ > > -DCMAKE_BUILD_TYPE=Release \ > > -DENABLE_CLUCENE=OFF\ > > -DENABLE_CLUCENE_NG=OFF \ > > .. && > > > > There is a reported error at http://sourceforge.net/p/strigi/bugs/114/ > > but the comment there is: > > > > That CLucene version is not supported. We only support the stable > > CLucene version. > > The upcoming version is very different and needs quite some rewriting. > > > > The comment is October 2011, but is till marked > > > > Status: open-invalid > > > > whatever that means. > > > > Has anyone else seen this? > > I get the same error, and have the same options in my script for Strigi. > > > > Should we remove the CLucene dependency and add the defines above? > > > > -- Bruce This appears to still be outstanding ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Project contributor names
On Tue, Mar 04, 2014 at 11:46:13PM +0100, Armin K. wrote: > Hello everyone, > > I'm in process of looking at what would be necessary and how hard it > would be to convert current LFS repositories from subversion to git. > > One of the steps (optional though) is conversion of subversion user > names to proper git format "Real name ". > > highos = Jesse Tie-Ten-Quee see below > > # Not sure > spyro = Ian Molton That is right. > > # Unknown > archaic = archaic I suspect you'll never get a real name for him. > jesse = jesse Probably the same as highos above ? /me still likes the ascending decimal revision numbers in subversion, but even simple editing would often be easier in git. e.g. last night I was part-way through adding the optional --libexecdir switches to BLFS when I found that I wanted to undo a libexec from a few days ago. Too late to revert it, of course, but in git I could have stashed the other changes I was working on, and done a discrete commit to fix that one item. So, I'll be interested to see how this pans out, and good luck with it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Libexec WebKitGTK [Was ... r12813 ...]
On Mon, Mar 03, 2014 at 10:14:36PM -0300, Fernando de Oliveira wrote: > Em 03-03-2014 21:39, k...@higgs.linuxfromscratch.org escreveu: > > We had: > > WebKitGTK+-1.10.2 > --libexecdir=/usr/lib/webkitgtk2 > > WebKitGTK+-2.2.4 > --libexecdir=/usr/lib/webkitgtk3 > > And they have both been removed. > > Is there a chance of problem here? > I built 1.10.2 with : ./configure --prefix=/usr --with-gtk=2.0 --disable-webkit2 \ --disable-geolocation and I don't see any libexec files from that version. I do see WebKitPluginProcess and WebKitWebProcess from 2.2.4 on a separate build, but I cannot see any files logged in /usr/lib/webkitgtk2 from past builds. Perhaps different deps or configure switches are needed to generate them ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Mon, Mar 03, 2014 at 07:27:06PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > I thought from an earlier reply that you considered these to be > > leftovers from when we had --libexecdir=/usr/lib in the commands for > > these packages. > > We may be discussing two different things. Above I was addressing > general '' vs '' usage. > > > So, I was going to delete them. > > If we don't use --libexecdir in a package, then I don't think it needs > to be addressed at all other than the case when a new subdirectory is > created in /usr/libexecdir. Then it's only documenting it fact that the > subdirectory is created. > Too late, I've put it as an option for peopl using LFS before 7.5. I've also reinstated libexecdir for sudo : everything in it is a library. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Mon, Mar 03, 2014 at 02:43:17PM -0600, Bruce Dubbs wrote: > >> > >> 2. The following explain an optional --libexecdir switch: gnupg2, > >> emacs, librep, geoclue. I don't have a problem with leaving this > >> sort of thing in for a transitional period while people may still be > >> using older versions of LFS (does 3 years sound about right?), BUT > >> > >> (i.) the markup is '', I think it hould be '' ? > > From a logical standpoint I think both fit. They are options to the > ./configure command, but are also parameters in that they are a "set > that defines a system or sets the conditions of its operation". > > However I do think our use should be consistent. In the html, option is > inside of constructs. We define that in the css to be monospace. > For the parameter, we the text is inside tags that render > as monospace slanted on my system. We do not define em outside of a > note, warning, etc. > > Which we choose probably doesn't make much difference. I would select > option just because it is less keystrokes. > > In any case, I don't think it's enough of an issue to hold up release of > BLFS-7.5. > I thought from an earlier reply that you considered these to be leftovers from when we had --libexecdir=/usr/lib in the commands for these packages. So, I was going to delete them. Now, I'll add this for: colord, ConsoleKit, cpio, evince, git, gnome-terminal, the gstreamers, icon-naming-utils, NetworkManager, vte, webkitgtk. I'll do a separate commit, for ease of reverting it if needed. There might be other packages, but I'm just going from what is in the ChangeLog. For consistency, it has to be an option. Compare e.g. the last explanation [ --enable-slp ] in OpenLDAP. There used to be a lot more examples, before people agreed that --disable-static should be preferred. I actually think that monospace for options, but italic for parameters is back-to-front, and perhaps increases the number of false reports about a command being explained but not used, but that's just another of the things about the book's XML which has to be learned.. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Mon, Mar 03, 2014 at 06:30:21PM -0300, Fernando de Oliveira wrote: > > Command Explanations > ... > --with-apache-libexecdir: If Apache-2.4.7 is installed, the shared > Apache modules are built. This switch allows to have those modules > installed to Apache's configured module dir instead of /usr/libexec. It > has no effect if Apache is not installed. > }}} > > If I am understanding correctly, ĸen is talking about that difference, > and that it would be good to have somewhere > > --with-apache-libexecdir=$(/usr/bin/apxs -q libexecdir) > I'm sorry, this is another of my "brown paper bag" moments. I did not notice the *explanation* when I grepped for libexecdir yesterday. I did notice there was an explanation when I ran svn update an hour or so ago. I haven't actually looked at the page yet (still sorting out what I intend to alter, and I had to go back to my previous 'gnome' build in chroot because I also missed w3m, which requires gc, yesterday), but that explanation you have posted above looks good. Again, my apologies. Thanks also to Pierre for his comments. /me likes /usr/libexec, but not need for consequential changes to the book at short notice. I'll attempt to fix up the remaining libexec stuff shortly - hopefully, *before* I ask myself "Do I feel lucky ?", otherwise I might not do anything :-( ĸen, a.k.a "why should I be right when I can easily be wrong ?" -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Mon, Mar 03, 2014 at 11:59:33AM -0600, Bruce Dubbs wrote: > Fernando de Oliveira wrote: > > Em 02-03-2014 21:42, Ken Moffat escreveu: > >> > >> 3. Subversion used to run a subshell to interrogate apxs. The > >> current page looks unusual, but I haven't any desire to build it for > >> 7.5 (I only rebuilt my server in September), so I have to assume it > >> is ok ? > > > > More or less. I am comparing the two versions in BLFS svn and 7.4 (It is > > very good to having releases, so to easily comparing instructions > > versions. In "Command Explanations", of svn (7.5-rc1) I think we should > > write the complete switch, or it is almost useless: > > > > s|=...|=$(/usr/bin/apxs -q libexecdir)| > > > > In configure, I don't know how to handle the switch alone > > "--with-apache-libexecdir" > > I've just taken a look at configure. --with-apache-libexecdir runs that apxs command, so I guess just adding an explanation like "this command uses apxs to discover the libexecdir used by apache" ? [ with markup, of ocurse ]. I can pick this up if that suggestion is ok. > >> > >> 4. The following are still doing things the old way: > >> menu-cache, qemu, openbox, mc, pulseaudio. Is there any reason why > >> these should NOT drop --libexecdir ? > > > > menu-cache and openbox are my faults. I can fix them. > > And I'll fix qemu. That one is my omission. > >-- Bruce > I see that the following create directories in /usr/libexec, I suppose that we need to document these [ possibly, some are already done, I haven't checked that yet ] : file-roller, gedit, git (creates git-core/), gjs, gnome-system-monitor, gstreamer (both, they create -0.10 and -1.0), mc, menu-cache, pulse (turns out I've already built this - the directory is empty on my pulse-avoiding system), sudo, xscreensaver, totem. I can pick up any/all of this, including removing the old command explanations, but I'd like to confirm that the directories in /usr/libexec should be documented, please. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Sun, Mar 02, 2014 at 07:09:13PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > > > 4. The following are still doing things the old way: > > menu-cache, qemu, openbox, mc, pulseaudio. Is there any reason why > > these should NOT drop --libexecdir ? > > Well as far as qenu goes, it was an oversight. I tested it without > --libexecdir. > > We need to remove and correct those entries where they really are not > needed. > >-- Bruce I'll try to build all of those in '4' _except_ pulseaudio, but it might be a while before I get there : I've just completed my normal build of xorg on a new 7.5 and booted it, now I need to build glib/gtk/etc/icewm, firefox, the print/photo progs, libreoffice. I'm _sort_of_ hoping that will show my kernel problem with 3.13.5 (twice, on the previous build, rm -rf to delete a source directory was looping with one cpu pinned at 100%), but if it does then I'll actually be spending time looking at that. I s'pose I can probably build those on the other box, to check exactly what gets installed in /usr/libexec without --libexecdir. Not sure (no book in front of me), but perhaps I can also build pulse and its deps. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
On Sun, Mar 02, 2014 at 05:16:44PM -0600, Bruce Dubbs wrote: > We just released LFS-7.5 and we need to look at releasing BLFS-7.5 in > the next few days. AFAIK, all the 7.5 tickets are complete and all the > packages tagged for 7.5. It is just a matter of doing the release, but > I'm sure that there are some tweaks that are necessary. > > For planning purposes, I think we can target Wednesday. March 5. > > Comments? > The --libexecdir switches still look a bit iffy to me. 1. The following use --libexecdir with what I think are adequate explanations of why: vte2, acl, dhcpcd. Anyone who disagrees : please speak up! 2. The following explain an optional --libexecdir switch: gnupg2, emacs, librep, geoclue. I don't have a problem with leaving this sort of thing in for a transitional period while people may still be using older versions of LFS (does 3 years sound about right?), BUT (i.) the markup is '', I think it hould be '' ? (ii.) should we also do this for all other existing BLFS packages which now use /usr/libexec ? 3. Subversion used to run a subshell to interrogate apxs. The current page looks unusual, but I haven't any desire to build it for 7.5 (I only rebuilt my server in September), so I have to assume it is ok ? 4. The following are still doing things the old way: menu-cache, qemu, openbox, mc, pulseaudio. Is there any reason why these should NOT drop --libexecdir ? Thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] No man pages at all
On Sun, Mar 02, 2014 at 03:40:14PM -0300, Fernando de Oliveira wrote: > > Telling this, because ĸen tagged OJDK. If he only maintained all for > tagging and removed, no problem. But if it is there, you ned to fix my > mistake in your machine, ĸen. More apologies. > > Already fixed the book: Committed revision 12811. > I don't use the pathappend stuff - that meant I had self-inflicted fun and games to test idedtea-web. Thanks for the comment, but that part of my build is fine. Glad you found the problem and fixed it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sun, Mar 02, 2014 at 12:49:12AM +, Ken Moffat wrote: > On Sat, Mar 01, 2014 at 04:05:15PM -0600, Bruce Dubbs wrote: > > > > > > Do you perhaps have any LESSCHARSET or similar variables set ? > > > > Yes. > > > > LESS=-MX > > LESSCHARSET=latin1 > > > I would try without LESSCHARSET. It ought to be able to determine > it from the LANG/LC_CTYPE environment variables, or else from > calling setlocale. > > > What about just adding the LC_ALL variable unconditionally? It > > shouldn't hurt anything. > > > >-- Bruce > > > Umm, errm. . I'm having issues using a dirty build > tree after I exported LC_ALL=C to force the breakage. At the > moment, everything I try breaks, even after 'make clean'. In theory, > exporting LANG ought to do it, with minimal side-effects. Will play > around with it some more. > > ĸen On this machine, I need to unset LC_ALL after exporting LANG=en_US.UTF-8, otherwise it still breaks with LC_ALL=C. This is getting messy - the build will be fine (people who use BLFS can probably cope with any error messages in English), but it risks leaving their environment in an unexpected state. I guess export MYLC=$LC_ALL ; export LC_ALL=en_US.UTF-8 ; ./configure ... ; make ; export LC_ALL=$MYLC ; make install. i.e. just force LC_ALL since it would otherwise need to be unset. If nobody has any cleaner suggestions, I'll give that a whirl sometime tomorrow (technically, today). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 04:05:15PM -0600, Bruce Dubbs wrote: > > > > Do you perhaps have any LESSCHARSET or similar variables set ? > > Yes. > > LESS=-MX > LESSCHARSET=latin1 > I would try without LESSCHARSET. It ought to be able to determine it from the LANG/LC_CTYPE environment variables, or else from calling setlocale. > What about just adding the LC_ALL variable unconditionally? It > shouldn't hurt anything. > >-- Bruce > Umm, errm. . I'm having issues using a dirty build tree after I exported LC_ALL=C to force the breakage. At the moment, everything I try breaks, even after 'make clean'. In theory, exporting LANG ought to do it, with minimal side-effects. Will play around with it some more. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 11:54:17PM +, akhiezer wrote: > > Date: Sat, 1 Mar 2014 21:56:30 + > > From: Ken Moffat > > To: BLFS Development List > > Subject: Re: [blfs-dev] Policy on locale for building ? (ticket #4745) > > > . > . > > > > > > > > Root (at least) here is always still non-utf8 . > > > > > > > The book (at least in most cases) builds as a normal user. You and > > I can choose to build as root if we wish, but we get to keep both > > pieces if it breaks. ;-) > > > > > - sorry, I thought from yr orig remark (not quot above) that you meant, > that everyone should by now have/use utf8 in everyday use (& not just for > b/lfs builds): hence my remark (intending to say) that we avoid utf8 &c > for root/priv in everyday use. > > (And normally only use root in software builds at the required steps). > I did mean that :) Unfortunately, not everyone seems to want to be able to render every language [ and, in a tty, you are limited to at most 512 glyphs so in practice you can only hope to render all languages in a graphical term ]. My apologies. I still have the fanaticism of the convert. Goes back to when I wanted to put correct placenames on my holiday photos. I guess the ruby devs now assume that everyone using a current version of ruby is using unicode, and on linux the only common Unicode Translation Format is UTF-8. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 09:49:33PM +, akhiezer wrote: > > Date: Sat, 1 Mar 2014 20:18:34 + > > From: Ken Moffat > > To: blfs-dev@linuxfromscratch.org > > Subject: [blfs-dev] Policy on locale for building ? (ticket #4745) > > > . > . > > > > If I configure gegl in my normal UTF-8 locale, there is no problem > > even with ruby already installed. But if I pass LC_ALL=C to > > configure, I get the reported problem during 'make' : > > > > ../tools/create-reference.rb:331:in `block (2 levels) in ': > > invalid byte sequence in US-ASCII (ArgumentError) > . > . > > > > > Hmmm. Does it _really_ require utf8 or similar to build? Seems like a poor > idea to _require_ it. > Seems to - the workaround in the ticket is to add Encoding.default_external = Encoding::UTF_8 Encoding.default_internal = Encoding::UTF_8 to one of the .rb files. Of course, if you don't install ruby before gegl, the problem doesn't arise. Taking a quick look at fedora, http://pkgs.fedoraproject.org/cgit/gegl.git/plain/gegl.spec they have: # Needed by Ruby 1.9.3. export LANG=en_US.utf8 note the lowercase, presumably both .utf8 and .UTF-8 will work in this case. > > Root (at least) here is always still non-utf8 . > The book (at least in most cases) builds as a normal user. You and I can choose to build as root if we wish, but we get to keep both pieces if it breaks. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 03:29:08PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: [ snipped ] > > I have a problem with en_US.UTF-8. I generally do not have any LC_ > variable set and even have > > alias ls='LC_ALL=C ls --color=auto' > > because I once was running into a problem with ls ignoring case when > sorting. > > If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below. > > ... [--no-justifiâ > <80><90> > > without, it gives the expected > > ... [--no-justifi- > >-- Bruce Odd. I prefer to see case-insensitive sorting, but I haven't noticed that sort of problem recently in 'man'. At the moment, both of the --no-justification matches in that manpage look fine with LC_ALL and LANG both set to en_GB.UTF-8. I have seen that sort of problem occasionally in the past, I think it was on some av package(s) - I don't think I've looked at 'man man' in years. Do you perhaps have any LESSCHARSET or similar variables set ? Going back to gegl, do you think a note along the lines of "If you have installed ruby, and are building in a non-UTF-8 locale such as 'C', you will need to use a UTF-8 environment for compiling this package, for example by passing LC_ALL=en_US.UTF-8 to configure." would hurt ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Policy on locale for building ? (ticket #4745)
Looking at #4745, there is a workaround for a problem building gegl when ruby has already been installed. Dunno why the originator hasn't actually put this in the wiki (I assume an ID for creating a ticket provides those privilege?), but there is an easier solution: If I configure gegl in my normal UTF-8 locale, there is no problem even with ruby already installed. But if I pass LC_ALL=C to configure, I get the reported problem during 'make' : ../tools/create-reference.rb:331:in `block (2 levels) in ': invalid byte sequence in US-ASCII (ArgumentError) from ../tools/create-reference.rb:325:in `foreach' from ../tools/create-reference.rb:325:in `block in ' from ../tools/create-reference.rb:318:in `times' from ../tools/create-reference.rb:318:in `' Makefile:881: recipe for target 'api.html' failed make[3]: *** [api.html] Error 1 What I don't recall is whether we ever recommend building packages in BLFS using the C or POSIX locales ? My belief is that everyone ought to be using UTF-8 locales by now, but from support posts over the years I guess that some of our users are behind the curve in this, and see no reason to change from legacy encodings (or perhaps they have too much data to make that feasible). For this package, is it worth adding a note that it should be built from a UTF-8 environment, e.g. by passing LC_ALL=en_US.UTF-8 ? I note that in LFS we recommend a number of locales, not all UTF-8, for optimum test coverage (en_US.UTF-8 is one of these), followed by "In addition, install the locale for your own country, language and character set." so that if people decide to omit tests there is no guarantee about which locales will exist. Dunno what would be best here. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Testing that IcedTea works properly in 7.5 ?
On Thu, Feb 27, 2014 at 06:32:44PM +, Ken Moffat wrote: > > > > You will build icedtea-web, that needs icedtea and also can be seen > > wirking in browser > > > Thanks! > For the future, we java-avoiders can find notes in the 'End User' part of http://icedtea.classpath.org/wiki/IcedTea-Web ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Tagging
On Thu, Feb 27, 2014 at 11:24:51AM -0600, Bruce Dubbs wrote: > While I'm working on KDE, these are the outstanding packages that need > to be tested and tagged: > [...] > > general/prog/junit.xml:&lfs74_checked; > general/prog/openjdk.xml:&lfs74_checked; > general/prog/java.xml: &lfs74_checked; I should be able to tag these. > [...] > > gnome/platform/gnome-icon-theme-extras.xml:&lfs74_checked; > Built, but I don't know if anything is using it, and I've got a general absence of gnome icons in my recent build - got something else to try before I admit defeat on icons. > multimedia/libdriv/libdv.xml:&lfs74_checked; Built, but I have no obvious way of testing it (and I should probably drop it from my builds). > xsoft/other/icedtea-web.xml:&lfs74_checked; I'll be trying to test this one too. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Testing that IcedTea works properly in 7.5 ?
On Thu, Feb 27, 2014 at 09:02:05AM -0300, Fernando de Oliveira wrote: > Em 27-02-2014 01:23, Ken Moffat escreveu: > > > > So, is there any _simple_ test that an editing monkey can run, to > > satisfy people that it is "known to build and work properly using an > > LFS-7.5 platform" ? > > > > You will build icedtea-web, that needs icedtea and also can be seen > wirking in browser > Thanks! ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Testing that IcedTea works properly in 7.5 ?
I'm hoping to soon complete a build of IcedTea-2.4.5. (The reason I say "hoping" is that I tried (accidentally) building a previous version while running a 3.13.5 kernel, and had some pain, the first part of which is summarised on lkml). With more consequential pain to follow :-( I'm now back on 3.13.4, for the moment.) For many of the things I've built with 7.5, it's easy to say that they work - either there is an application I can try to run, or in BLFS the package is just a build dependency for something else. But there are a few others, and this is one of the more significant (at least, in terms of the hoops you have to jump through to build it). So, is there any _simple_ test that an editing monkey can run, to satisfy people that it is "known to build and work properly using an LFS-7.5 platform" ? In this case, I happen to be running the testsuite, but the book's comment doesn't fill me with any confidence that jtregcheck is an adequate test. For programming languages, which this claims to be, I can hack shell, to an extent, and on a clear day with the wind in the right direction I might manage a little perl, but otherwise I'm mostly limited to my recollections of COBOL, JCL (specifically, JES2), and AMS (Access Method Services - call it VSAM if you prefer). 8-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12792 - in trunk/BOOK: introduction/welcome postlfs/security
On Wed, Feb 26, 2014 at 09:11:32PM -0600, Bruce Dubbs wrote: > k...@higgs.linuxfromscratch.org wrote: > > Author: ken > > Date: Wed Feb 26 17:45:11 2014 > > New Revision: 12792 > > > > Log: > > acl is weird enough to need --libexecdir - thanks to Armin for pointing > > this out to me. > > Yes, I ran into that last night. I started to remove it, but it put > things in the wrong place. Perhaps a comment in the xml is warranted. > >-- Bruce > I _think_ I've explained in the command explanations. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12791 - in trunk/BOOK: general/sysutils gnome/applications introduction/welcome networking/netutils postlfs/security
On Thu, Feb 27, 2014 at 01:34:36AM +0100, Armin K. wrote:
> On 02/27/2014 01:16 AM, k...@higgs.linuxfromscratch.org wrote:
> > Author: ken
> > Date: Wed Feb 26 16:16:09 2014
> > New Revision: 12791
> >
> > Log:
> > Remove another 5 libexecdirs.
> >
> > Modified:
> >trunk/BOOK/general/sysutils/colord.xml
> >trunk/BOOK/gnome/applications/gnome-terminal.xml
> >trunk/BOOK/introduction/welcome/changelog.xml
> >trunk/BOOK/networking/netutils/networkmanager.xml
> >trunk/BOOK/postlfs/security/acl.xml
>
> I'd suggest leaving libexecdir switch for this one. Without it, it will
> install /usr/libexec/libacl.so and /usr/libexec/libacl.la as symlinks to
> /usr/lib counterparts and these do not belong in there.
>
> >trunk/BOOK/postlfs/security/consolekit.xml
> >
>
Well spotted. So many packages, such a variety of non-standard
usages. Who would ever have thought that --libexecdir was the right
switch to control where symlinks to files in ${PREFIX}/lib/ go ?
I';; rever that part, and comment it. Thanks.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Reverting my work
On Wed, Feb 26, 2014 at 05:54:18PM +0200, Gregory H. Nietsky wrote: > > There is something that is often overlooked that there are individuals > who use the "book" as a reference to get the low down on a individual > package. > if these are users or simply experimenting > with the package > its a awesome resource. not all readers of the book are builders. > > its a lot easier reading the xLFS page than wading through configure > --help/README/ > All well and good, but only if an editor cares enough to maintain the package. IMHO nobody wished to touch sendmail - partly because having more than one MTA on a system is a problem in itself, so installing a second causes grief, and actually trying to use it enough to be confident that it is properly configured is another matter entirely. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On Fri, Feb 21, 2014 at 08:51:55AM -0600, Bruce Dubbs wrote: > Fernando de Oliveira wrote: > > Em 20-02-2014 23:00, LFS Trac escreveu: > >> #3505: linux-3.13.4 > >> --+ > >> Reporter: bdubbs@… | Owner: lfs-book@… > >> Type: task | Status: new > >> Priority: normal| Milestone: 7.5 > >> Component: Book |Version: SVN > >> Severity: normal| Keywords: > >> --+ > >> New point version. > >> > >> We can do this for 7.5. The rule here is that we can update point > >> versions but not major or minor versions. > > > > Couldn't it be the same for blfs, for almost all packages? > > That's worthy of discussion. Perhaps end packages and not libraries > would be amenable to this type of rule. I'm hesitant to update > libraries right now because of possible breakages of programs already > marked as lfs75_checked. For the few packages that are marked > lfs75_built, then there is no good reason not to update. > > Is that a reasonable compromise? > >-- Bruce I'm somewhat reluctant to update even end packages, unless there is a wrthwhile fix (either a vulnerability fix, or a documented fix for a problem). For libraries and toolkits, particularly once they have been tagged, my general opinion is that they should wait until after the release - again, unless there is a major fix [ and if there is, all tags are off ]. On that basis, no to updating x264 (#4732). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] postscript viewers broken
On Thu, Feb 20, 2014 at 07:33:45PM +, Ken Moffat wrote: > > The gs fix is apparently: > http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=e64ac4c8 > > which is rather big. And doesn't seem to be remotely likely to apply to 9.10. Guess I'll have to remember to use the workaround. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12752 - in trunk/BOOK: general/genutils general/prog general/sysutils introduction/welcome multimedia/libdriv
On Thu, Feb 20, 2014 at 10:20:00PM +0100, Armin K. wrote: > > There is no /usr/sbin/rmt anymore, it's now /usr/libexec/rmt. > Thanks, I've changed it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] postscript viewers broken
On the rare occasions when I need to look at a postscript text file, and don't have TeX intalled, I normally use evince (built with libspectre). While testing this on 7.5, I discovered that .ps files were not displaying. Now that I've had time to google, I found a link from arch pointing to a ghostscript bug. People say this also affects okular, and is also seen in (at least) ubuntu. The gs fix is apparently: http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=e64ac4c8 which is rather big. There is also a workaround for those of us using the commandline : LANG=C when invoking evince or any other viewer. Supposedly this is to do with locales using a comma as a decimal separator, but in fact it happens for me in en_GB. I think I'll try that patch in my next build, because this is the sort of thing that annoys me. N.B. 'display' from ImageMagick doesn't show this problem, but it isn't useful unless the postscript file has a background (most don't) because it will put the text on a chequerboard silver-grey background which makes it incredibly difficult to read. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [BLFS Trac] #4647: Texlive build instructions are incorect
On Wed, Feb 19, 2014 at 05:27:01PM -0600, Bruce Dubbs wrote: > > Actually a couple of spaces before the lines between the pushd/popd > would be nice. Also add a blank line before the 2nd configure. > > Finally, we like to line up the backslashes, &&, --options, etc to let > the readers see the regularity in the instructions. > > Something like: > > pushd ../utils/asymptote && > echo "ac_cv_lib_m_sqrt=yes"> config.cache && > echo "ac_cv_lib_z_deflate=yes" >> config.cache && > >./configure LIBS="-ltirpc " \ >--prefix=/opt/texlive/2013 \ >--bindir=/opt/texlive/2013/bin/x86_64-linux \ >--datarootdir=/opt/texlive/2013/texmf-dist \ >--infodir=/opt/texlive/2013/texmf-dist/doc/info \ >--mandir=/opt/texlive/2013/texmf-dist/doc/man\ >--enable-texlive-build \ >--cache-file=config.cache && > popd && > >-- Bruce OK, I'll have a go when I tag it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [BLFS Trac] #4647: Texlive build instructions are incorect
On Wed, Feb 19, 2014 at 03:51:55PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > I think this should probably move beyond 7.6. Everything except > > xindy is done, but for xindy it really needs > > > > (i.) someone who has a document which can be indexed by xindy, and > > who knows how to do that, to prove that it works. > > > > (ii.) finding out how to build xindy.mem (or perhaps, just how to > > install it - I deleted my build tree without considering if there > > was a way to do this). > > > > (iii.) deps - probably clisp and libsigsegv, but maybe also other(s). > > For me, the clisp testsuite ends with a segfault and I have no idea > > if that is important or not. > > > > Hopefully, Greg will be able to join us and pick up what is left. > > Perhaps the ticket should be closed and a new one opened with just the > specific problem addressed. I'd prefer not to have the reference to the > ticket in the book. Perhaps it would be better to just say something to > the effect that xindy was not rebuilt due to a problem with the > tarball's install procedure. > OK, I'll look at those when I tag it. > Also, the page needs some white space touchups. > >-- Bruce > If you mean the blank lines between the build instructions, I disagree. The instructions are spread over many lines, and some of the instructions are unusual. I find the extra blank lines help to break it up into more comprehensible sections. If you mean something else about whitespace, what ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [BLFS Trac] #4647: Texlive build instructions are incorect
On Wed, Feb 19, 2014 at 08:12:48PM -, BLFS Trac wrote: > #4647: Texlive build instructions are incorect > -+-- > Reporter: gregnietsky | Owner: blfs-book@… > Type: defect | Status: new > Priority: normal | Milestone: 7.5 > Component: BOOK | Version: SVN > Severity: trivial | Resolution: > Keywords: | > -+-- > Changes (by bdubbs@…): > > * milestone: current => 7.5 > I think this should probably move beyond 7.6. Everything except xindy is done, but for xindy it really needs (i.) someone who has a document which can be indexed by xindy, and who knows how to do that, to prove that it works. (ii.) finding out how to build xindy.mem (or perhaps, just how to install it - I deleted my build tree without considering if there was a way to do this). (iii.) deps - probably clisp and libsigsegv, but maybe also other(s). For me, the clisp testsuite ends with a segfault and I have no idea if that is important or not. Hopefully, Greg will be able to join us and pick up what is left. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] 7.5 desktop testing plans ?
On Wed, Feb 19, 2014 at 04:32:07PM -0300, Fernando de Oliveira wrote: > > I will test gnome, less, perhaps, cheese, this, Armin probably could > test. Or all gnome, if you want, Armin. > Since Bruce is going to test KDE at some time, I'll start by updating my gnome scripts (my KDE will need a lot more work to check I've got the necessary deps covered for a separate build). If you guys leave anything in gnome which I can actually use, I'll hopefully cover it. But after xfce, I'll take a look at non-DE desktop packages in priority to doing my second build. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] 7.5 desktop testing plans ?
On Wed, Feb 19, 2014 at 01:07:06PM -0300, Fernando de Oliveira wrote: > Em 19-02-2014 12:31, Ken Moffat escreveu: > > > > So: anyone planning to test specific desktop things ? > > I will build OpenBox/LXDE, today, hopefully. > That's great - lxde hit the book after I'd started my last lot of testing, so I don't have scripts for it. Looking at the scripts I do have, I should be able to test xfce later today (it's comparatively small, I already build some of it, so no worries about space on my only-8GB '/'). Anyone planning to test either gnome or kde ? NB I can't test any wifi apps - my LFS machines are wired only. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] 7.5 desktop testing plans ?
I'm coming to the end of my first 7.5 desktop build - so far I've built all my normal packages, but some need testing, and I want to also build all the extras I sometimes use. I don't use a desktop _environment_, so I'll be tagging an eclectic mix of things here and there. After that, I _need_ to do another desktop build to check a couple of minor things re eudev, and to update the package versions where I'm accidentally slightly behind (glib, harfbuzz). I've got scripts for many of the desktop packages, as at October-November, plus a list of what has changed, so I should be able to build one or more desktop environments without too much difficulty. But I don't actually like these DEs, and I've no particular wish to build any of them if someone is actively going to build them. So: anyone planning to test specific desktop things ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LFS-7.5 tags
On Mon, Feb 17, 2014 at 01:14:22PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > > For documentation, I am ambivalent and also to remove what someone > > has already taken the time to document. > > That's a good point, but the documentation is incomplete. If a user is > looking for a library or executable, would they think to look in > /usr/libexec? Also we don't now document an installed directory such as > /usr/libexec/sudo. > True; only if they were really having problems; true. Re looking for a program - I got puzzled by something like that in gnome-3 when I was trying to test exactly how much was needed, and ended up having to run a libexec prog from .xinitrc to make progress. So yeah, probably ok to remove. > > For installing in a > > subdirectory, I'm _mostly_ not keen - extra work for no obvious gain. > > > > However, looking back at my logs from October/November when I did > > scripted builds of a lot more of BLFS, I think we might need to do > > this for one or both versions of vte : they both installed > > gnome-pty-helper, without an override it looks as if whichever is > > installed later (if both are installed) will overwrite that program > > from the earlier install. > > Do you know if the versions of gnome-pty-helper were different? If so, > were they equivalent? > They might be the same. To be honest, all the reports google finds for gnome-pty-helper, and my attempt just now to see if it will report a version, suggest most people will probably be better off without it. The subdirectory in both versions of vte contains similar code, but with updated build infrastructure. Both report themselves in config.log as version 1.95.0. Whatever, in some forms of package management, overwriting a file from a different version of a package throws up questions. The user program, headers, and lib from the gnome-3 version already have 2_90 in their name, adding --libexecdir=/usr/libexec/vte-2.90 appears to keep gnome-pty-helper separate and is in line with what we were doing ro use /usr/lib - /usr/libexec/vte2_90 might be more consistent with the rest of the package. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] /usr/man
On Mon, Feb 17, 2014 at 08:01:07AM -0300, Fernando de Oliveira wrote: > Em 17-02-2014 00:19, Ken Moffat escreveu: > > > > add MANDIR=/usr/share/man/man1 to the install for tree. > > > > I can fix these in a few days, after I confirm that the fixes are > > correct. > > > > ĸen > > > > I used that, you even referred to, after, I was able to get the good > placement without it. > > $ tree DEST-tree-1.6.0 > DEST-tree-1.6.0 > └── usr > ├── bin > │ └── tree > └── man > └── man1 > └── tree.1 > > This is without the mandir override. Do you get it different? > I too got /usr/man/man1/tree.1 - the point is that I've dropped the /usr/man -> /usr/share/man symlink. It took Armin's post a few weeks ago to make me realise _why_ I should care : I can remember Randy fixing this on something a long time ago, and my reaction at that time was "not worth doing, we have the symlink". For official 7.5 (unlike systemd-7.5) it is probably optional. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LFS-7.5 tags
On Mon, Feb 17, 2014 at 01:34:19AM -0600, Bruce Dubbs wrote: > I made the first set of LFS-7.5 tags: > > lsb_release > openssl > openssh > sudo > which > wget > > For openssl and openssh I removed the libexec override. That begs the > question whether we should continue to document the files placed in > /usr/libexec. I lean to no although I haven't removed any yet. > > Files I have now: > > $ ls -F /usr/libexec > awk/ code* frcode* getconf/ rmt* ssh-keysign* sudo/ > bigram* coreutils/ gcc/ man-db/ sftp-server* ssh-pkcs11-helper* > > In the above, bigram, code, and frcode are from findutils. > ssh* and sftp* are from openssh > getconf is from glibc > rmt is from tar > > If we really wanted to, we could probably set libexecdir for those > packages to install in a subdir of /usr/libexec like the others. I > don't want to do that for 7.5, but it's a thought for the future. > > > What do you think? > >- Bruce For documentation, I am ambivalent and also to remove what someone has already taken the time to document. For installing in a subdirectory, I'm _mostly_ not keen - extra work for no obvious gain. However, looking back at my logs from October/November when I did scripted builds of a lot more of BLFS, I think we might need to do this for one or both versions of vte : they both installed gnome-pty-helper, without an override it looks as if whichever is installed later (if both are installed) will overwrite that program from the earlier install. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] /usr/man
On Mon, Feb 17, 2014 at 03:04:28AM +0100, Armin K. wrote: > On 02/17/2014 02:19 AM, Ken Moffat wrote: > > I've just completed my normal build, on a system which is typically > > about a week old. This time, I removed the /usr/man and /usr/info > > symlinks. I don't have anything in /usr/info, but several packages > > have scribbled in /usr/man, and many of them are in BLFS. > > > > Is it worth me taking time to fix them in the book ? > > > > ĸen > > > > Yes please, I can help you there if you like. > Some of them are in fact already fixed in BLFS, I'm down only three which are in the book and not fixed. I'm not intending to run individual test builds on any of these packages (I'll be building 7.5 as soon as I've completed some functional tests in my current build, and updated my scripts for changes in the last week), so it is possible that one or more of these might not do the right thing. But what I currently think is needed is: (configure) --mandir=/usr/share/man for links, paps (and also for lsdvd, normalize and rtmpdump which are not in the book). add MANDIR=/usr/share/man/man1 to the install for tree. I can fix these in a few days, after I confirm that the fixes are correct. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] /usr/man
I've just completed my normal build, on a system which is typically about a week old. This time, I removed the /usr/man and /usr/info symlinks. I don't have anything in /usr/info, but several packages have scribbled in /usr/man, and many of them are in BLFS. Is it worth me taking time to fix them in the book ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Plan for -7.5
On Sat, Feb 15, 2014 at 05:19:44PM -0600, Bruce Dubbs wrote: > Bruce Dubbs wrote: > > Tomorrow I plan on creating and releasing -rc1 for LFS and BLFS. > > Well I've had some unplanned events come up (non-LFS) and I will now > plan on doing -rc1 on Sunday. The rest of this evening will be jsut > checking things over. > > Updating BLFS is OK for now, but please keep an eye on the email. I'll > do LFS first and announce that and then start working of BLFS. > One thing which I suppose ought to change, but which we haven't had before: in current gstreamer (1.2 series) and its plugins we have --with-package-origin="http://www.linuxfromscratch.org/blfs/view/svn/"; I guess that needs to become 7.5 for the release, and therefore it probably ought to change for the rc ? Or do we just tell people that svn is always better ? :) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Plan for -7.5
On Sat, Feb 15, 2014 at 09:27:11PM +0200, Gregory H. Nietsky wrote: > > Hi likewise been busy i linked asy bits against libtirpc and portablexdr > > http://people.redhat.com/~rjones/portablexdr/ > > i also use it to build the rpc bits of openl2tpd. > > Greg > I found some past links which led me to believe the missing xdr_ symbols were all related to static linking to old libtirpc from an old glibc. Passing LIBS="-ltirpc " when configuring aymptote (the space in that string is important) caused an interesting afternoon dealing with the consequential configury breakage. I've now built it three times like this (and also with most of xindy), so I'm fairly sure what I've committed works. Just like the old days in cross-lfs, having to use config.cache :) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Plan for -7.5
On Sat, Feb 15, 2014 at 05:50:14PM +, Ken Moffat wrote: > > I'm running late on adding the asy instructions to TeX Live (from > source) : I was ill yesterday before I could test the build, and now > I realise that I still managed to use an older binary installer - > the newer one got downloaded as \(1\) by firefox and I forgot to > delete the old one and fix that up before I started. > > Just started as fresh run, I'll start the instruction changes soon > (asy needs a patch I uploaded earlier this week, and some fun and > games to configure it with shared libtirpc). So, in one sense, this > won't break the freeze even if I haven't completed by 2000. > Done, r12712 I'm sure my wording could do with a bit of pruning here and there, but I've sent the ticket back to blfs-book (hopefully, Greg will be able to join us, and sort out xindy) so it's open season on my verbiage. Please note that I have deliberately broken deps, and now the build instructions, into multiple paragraphs for ease of reading. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Plan for -7.5
On Fri, Feb 14, 2014 at 03:07:49PM -0600, Bruce Dubbs wrote: > Tomorrow I plan on creating and releasing -rc1 for LFS and BLFS. (Armin > I can do LFS-systemd version too if you agree). > > Please have any planned package updates completed by 2000 GMT tomorrow > or let me know if you need more time. > > What will happen is that I'll create a version in the svn tag directory > for each book and make minor changes to reflect the -rc1 status. After > commit, I'll install the appropriate html, pdf, patches, etc on the web > site and make an announcement. > > I hope to be done about 2300 GMT tomorrow, but it may extend to a few > hours later. > I'm running late on adding the asy instructions to TeX Live (from source) : I was ill yesterday before I could test the build, and now I realise that I still managed to use an older binary installer - the newer one got downloaded as \(1\) by firefox and I forgot to delete the old one and fix that up before I started. Just started as fresh run, I'll start the instruction changes soon (asy needs a patch I uploaded earlier this week, and some fun and games to configure it with shared libtirpc). So, in one sense, this won't break the freeze even if I haven't completed by 2000. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] TeX Live - status and thoughts.
On Sun, Feb 09, 2014 at 04:00:04AM +, Ken Moffat wrote: > > What I am minded to do is to split the current Tex Live into > install-tl-unx (the binary installer) and TeX Live (building from > source, after the binaries have been installed). > Done at r12703. I hope to retest for asy (asymptote) in a few hours (tomorrow afternoon here), using the current version of install-tl-unx : I discovered between about 24 and 21 hours ago that trying to install while the local ctan mirror sysadmins are doing their daily updates does not work. That will leave xindy and its dependencies. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libcap
Based on my recent postings, you guys may need to be file this under "I _don't_ want whatever he's drinking", but just in case : With libcap-2.24, the commands chmod -v 755 /usr/lib/libcap.so && mv -v /usr/lib/libcap.so.* /lib && appear to be redundant. It looks as if, on x86_64, it installs to /lib64 (i.e. /lib because of the symlink). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] News about nouveau and systemd
On Mon, Feb 10, 2014 at 10:03:35AM -0300, Fernando de Oliveira wrote: > . Also, > like that ĸen is keeping alive the eudev alternative. > Actually, all I'm doing is _using_ eudev - and I haven't moved on from eudev-1.2 yet (will be trying 1.4 in my forthcoming build). Don't want anyone to get the idea tht I'm actually doing anything for it :) This isn't the first time I've taken a different stance on a package. In particular, I remained with lilo on most of my machines in the grub-legacy days. In this case, Bruce's udev-from-systemd is fine, but I would rather stick with something more general in the hope it will develop a niche for itself. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] TeX Live - status and thoughts.
The main part of making the from source build of TeX Live use system libraries is now in place. I think I've managed to identify what does and does not get installed in the from-source build. The details for the tl-installer are now starting to look messy - All the information around the installer is about the from-source recommendations / options / runtime dependencies, with a Note in the middle of the installer instructions. Certainly, the binary install linked to e.g. libGLU and libncurses on my system, but the from-source build does not. So saying the same dependencies are required is misleading. I want to confirm what is used by the binary on a fresh install, but that will have to wait until I build a new LFS system (hopefully, next week, I need to update my scripts). I already have a list of what I *think* is used, but a few of those libs might have been picked up as dependencies of other libs, because of how I installed them, so an install on a minimal system (no Xorg) is needed. I also need to deal with xindy (extra configure switches) and asy (separate build in a subdirectory of the TeX Live source), and to try to sort out my current fudge words about the Optional dependencies. What I am minded to do is to split the current Tex Live into install-tl-unx (the binary installer) and TeX Live (building from source, after the binaries have been installed). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Tex Live : luatex
On Fri, Feb 07, 2014 at 08:44:17PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > In the current instructions for Tex Live, we have --without-luatex. > > > > This is wrong, the current option is --disable-luatex. But I have > > a question: someone must have thought it was a good idea to disable > > luatex. Why ? > > > > > > Anybody like to offer a reason ? > > At the time that was added, lua was not in the book. > Thanks to you and Armin for that information. Interestingly, luatex cannot be made to use a system lua, but it ships with its own version, currently 5.2. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Tex Live : luatex
In the current instructions for Tex Live, we have --without-luatex. This is wrong, the current option is --disable-luatex. But I have a question: someone must have thought it was a good idea to disable luatex. Why ? The binary installer includes luatex, and it appears to build fine from source. As with latex, some very simple examples I found work, others don't, but running lualatex on a "good" minimal example provides a displayable PDF. I was originally going to move the corrected --disable-luatex to an optional command, but at the moment I cannot see any reason why a user who is going to the trouble of building TeX from source would want to do that. Anybody like to offer a reason ? Attaching the simple example (from StackExchange), and the PDF, in case anyone wants an example. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce luatex-first.pdf Description: Adobe PDF document luatex-first.tex Description: TeX document -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12678 - trunk/BOOK/general/graphlib
On Fri, Feb 07, 2014 at 04:33:06AM -0800, i...@higgs.linuxfromscratch.org wrote: > Author: igor > Date: Fri Feb 7 04:33:06 2014 > New Revision: 12678 > > Log: > move freetype and python to optional dependencies for graphite (used only for > tests) > Thanks. I had read the documentation in the tarball which implied they were required, but I'm happy to defer to your knowledge. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Tex (#4647)
On Tue, Feb 04, 2014 at 09:03:15PM +, Ken Moffat wrote: > This ticket lists a whole lot of changes to how we build Tex from > source. I took it, because I don't (in general) like packages which > use their own static versions of system libs. But I now see that > the following are external references: GD, t1lib, ZZIPlib, TECkit, > Graphite, and also CLISP (not needed for the main part of Tex, if > I'm now reading the ticket correctly). > > Maybe Pierre spotted this, which is why he said he hadn't got time > before the package freeze - I was thinking "just change the > instructions for the existing package version". My mistake. > > And more generally, do we want these extra packages if they are > only used by TeX ? I have no idea about the vulnerabilities history > of any of them, nor how the TeX developers handle upstream changes > to these libs. > Looking a little further after posting (I'm good at that), I see that firefox can use graphite, BUT it is turned off by default, and although 26.0 seems to include a local copy [ I'm still downloading 27 ] there is no option to use a system version. However, libreoffice DOES allow for system graphite so I guess that might be worth having. t1lib, CLISP, TECkit do not seem to have had any recent releases. Looking at fedora cgit, they patch t1lib for various vulnerabilities. For clisp they are using a mercurial snapshot, so perhaps it is one of those projects that no longer makes releases. TECkit looks to be fairly straightforward, bar a missing header for recent C++ and apparently a need to run autogen.sh to create configure. I'm coming round to the idea of adding these tools, but for at least graphite I want to confirm that libreoffice will use it, in a fresh build. > Opinions, please. > ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Cups and kernel USB printer support (/dev/usb/lp0)
On Wed, Jan 22, 2014 at 08:17:40PM +, Ken Moffat wrote: > On Wed, Jan 22, 2014 at 11:06:31AM -0300, Fernando de Oliveira wrote: > > > > Yes. Have you tried it as built in the kernel, instead of module? I > > think we need to know that for the book, when we decide it is ready. > > > No, only that one system has libusb, and the choice of packages > (basically, what was not built in my first build with make-4.0) is > not convenient for my normal usage. > OK, got back to this, and installed a new kernel (3.12.9) with the driver built in. Also changed an ink cartridge - recharging the heads apparently used up to 14% of some of the cartridges, according to escputil. Anyway, with CONFIG_USB_PRINTER=y both escputil and cups work. I'll mention this on -support, in case anybody has a different view, before I change the book. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Cups and kernel USB printer support (/dev/usb/lp0)
On Wed, Jan 22, 2014 at 11:06:31AM -0300, Fernando de Oliveira wrote:
> Hi ĸen,
>
> Em 21-01-2014 15:56, Ken Moffat escreveu:
> > On Tue, Jan 21, 2014 at 11:30:05AM -0300, Fernando de Oliveira wrote:
> >> Em 20-01-2014 21:24, Ken Moffat escreveu:
> > On my system, /dev/usb/lp0 is created for the usblp driver - i.e.
> > you have created usblp.ko in
> > /lib/modules/$(uname -r)/kernel/drivers/usb/class/
> >
> > Without that driver, the device does not exist for me.
>
> Yes. Have you tried it as built in the kernel, instead of module? I
> think we need to know that for the book, when we decide it is ready.
>
No, only that one system has libusb, and the choice of packages
(basically, what was not built in my first build with make-4.0) is
not convenient for my normal usage.
> > NB escputil is a user tool, the printer needs to be idle but you
> > don't need root permissions. For checking ink levels,
> > escputil -i -r /dev/usb/lp0
> > works for me.
>
> Not at Lubuntu:
>
> {{{
> $ env LC_ALL=C escputil --new --raw-device=/dev/usb/lp0 --identify
> Escputil version 5.2.8-pre1, Copyright (C) 2000-2006 Robert Krawitz
> Escputil comes with ABSOLUTELY NO WARRANTY; for details type 'escputil -l'
> This is free software, and you are welcome to redistribute it
> under certain conditions; type 'escputil -l' for details.
>
> Cannot open /dev/usb/lp0 read/write: Permission denied
> }
Nasty.
>
> >> Back to your subject, I did some tests in Lubuntu (my CUPS/SANE server).
> >>
> >> {{{
> >> $ lsmod | grep usb
> >> usblp 17885 0
> >> usb_storage39646 0
> >> }}}
> >>
>
> Did that for Mageia, Arch and Fedora, as promissed, there is no output,
> from Fedora:
>
> {{{
> [ fernando@VMWFedoraNG ~ ]$ lpstat -p -d
> printer Epson_Epson_Stylus_CX7300 is idle. enabled since Qua 22 Jan
> 2014 10:58:39 BRT
> system default destination: Epson_Epson_Stylus_CX7300
>
>
>
> [ fernando@VMWFedoraNG ~ ]$ lsmod | grep usb
> [ fernando@VMWFedoraNG ~ ]$
> }}}
>
> {{{
> fernando@VMWArch ~ $ lpstat -p -d
> printer Epson-Stylus-CX7300 is idle. enabled since Qua 15 Jun 2011
> 15:17:44 BRT
> File "/System/Library/ColorSync/Profiles/Generic CMYK
> Profile.icc" not available: No such file or directory
> printer Epson-Stylus-CX7300:1 disabled since Qua 24 Out 2012 11:26:58 BRT -
> Backend /usr/lib/cups/backend/tpvmgp does not exist!
> system default destination: Epson-Stylus-CX7300:1
>
>
> fernando@VMWArch ~ $ lsmod | grep usb
> usbcore 154188 3 uhci_hcd,ehci_hcd,ehci_pci
> usb_common 1604 1 usbcore
> }}}
>
> {{{
> [fernando@VMWMageia ~]$ /sbin/lsmod | grep usb
> usbhid 47320 0
> hid87153 2 hid_generic,usbhid
> usbcore 189409 4 uhci_hcd,ehci_hcd,ehci_pci,usbhid
> usb_common 12921 1 usbcore
> }}}
>
> However, Mageia is useless, cups was not installed, failed to get it
> configured.
>
> Think that those data above help nothing.
>
> > Debian and ubuntu had code to get both backends working (see the
> > link above), and I guess some of it is now upstream.
>
> That link you gave informs that upstream did not accept, IIRC.
>
Yeah, but it was an old link, well before cups-1.7.
>
> I do not know if I have anything to add to your info. It is a big move,
> bringing the printer to connect via usb, but you feel that this is
> needed, please just ask.
>
I very much doubt that will help.
My current position re printing is:
Where escputil works (some, or all, epson usb non-multifunction
printers, from the computer connected directly to the printer), it
requires the kernel usb printer driver : known to work if that is a
module, I will test (at some time in the future) if building the
driver into the kernel breaks cups, I suspect that the move to
libusb-1.0 might have fixed this, but that is just a guess.
Maybe I'll ask on -support too, to see if there are any conflicting
views there. But first, I'm still looking for some missing
paperwork, and getting increasingly desperate.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Cups and kernel USB printer support (/dev/usb/lp0)
On Tue, Jan 21, 2014 at 11:30:05AM -0300, Fernando de Oliveira wrote:
> Em 20-01-2014 21:24, Ken Moffat escreveu:
> > I think we have an overzealous "Note" in the Kernel Configuration
> > part of the cups instructions -
> >
[...]
Thanks for the reply - I was starting to think my message had got
lost (I haven't yet got a copy from the list, but that is also true
of one or two recent posts on the -support lists where I've only
>
> I have always used libusb, so, do not know much about this. But this
> subject is of much interest for me, you know...
>
> After reading your post I tried escputil, unfortunately:
>
> {{{
> $ env LC_ALL=C sudo escputil --new --raw-device=/dev/usb/lp0 --identify
On my system, /dev/usb/lp0 is created for the usblp driver - i.e.
you have created usblp.ko in
/lib/modules/$(uname -r)/kernel/drivers/usb/class/
Without that driver, the device does not exist for me.
> ...
> Unknown printer Stylus CX7300!
> EPSON Stylus CX7300
>
> ...
>
> $ escputil -M | grep CX7
> escp2-cx7000f Epson Stylus CX7000F
> escp2-cx7400Epson Stylus CX7400
> escp2-cx7700Epson Stylus CX7700
> escp2-cx7800Epson Stylus CX7800
> }}}
>
> Cups uses Epson Stylus CX7000F an sane uses Epson Stylus CX7400. I would
> like to discover how to instruct escputil to think that the printer is
> one of those two. Failed to find it in web searches.
>
You say your printer also does scanning, i.e. it is a multifunction
device. One link I found was
http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002412.html
which suggests that multifunction printers are a bit too complex for
the traditional methods.
NB escputil is a user tool, the printer needs to be idle but you
don't need root permissions. For checking ink levels,
escputil -i -r /dev/usb/lp0
works for me.
> Back to your subject, I did some tests in Lubuntu (my CUPS/SANE server).
>
> {{{
> $ lsmod | grep usb
> usblp 17885 0
> usb_storage39646 0
> }}}
>
Debian and ubuntu had code to get both backends working (see the
link above), and I guess some of it is now upstream.
> Tried using ldd to find any CUPS library or application linked to libusb
> in LFS7.4: none.
>
Yeah, the use is well hidden. And the build-system defaults to a
"quiet" output so that the commands do not get shown. With 1.7.0,
(I'm still using that) if libusb-1.0 is found it will be reported in
the CFLAGS (I can see that in my log) and it should define LIBUSB
as -lusb-1.0. That gets referenced in backend/Makefile - it is used,
if present, when backend/usb is created - and that gets
installed at /usr/lib/cups/backend/usb.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Cups and kernel USB printer support (/dev/usb/lp0)
I think we have an overzealous "Note" in the Kernel Configuration part of the cups instructions - | There is a conflict between the Cups libusb backend and the usblp | kernel driver. If you want to use Cups with libusb, do not enable | USB Printer support in your kernel. For several years, I have used the kernel's usblp driver, as a modules. and not libusb. Indeed, I removed colord from my builds when it apparently became dependant on libusb. But while I was testing everything for make-4.0 I had to build libusb, and confirmed that printing via libusb without the kernel's usblp driver worked fine. So far so good, and I decided to reinstate colord and to allow myself to use lsusb from usbutils if I ever needed it. And then I went back to that build to put a 3.13.0 kernel on it. I wanted to check my ink (using escputil), but that needs to read the raw device, /dev/usb/lp0, and I didn't have one. Googling showed that arch's wiki mentions building usblp as a module, inserting it before using escputil, and then rmmod'ing it to enable printing to work. Sounded awkward, but worth a try. In fact, with usblp as a module everything is working fine in 3.13.0 with libusb! When I connect the printer, usblp (and usb_storage - who said printers were straightforward ? :) gets loaded and escputil is able to tell me which ink is running out. And then, even without trying to rmmod usblp, printing through cups works fine. Not sure if building usblp into the kernel will work the same way ? I'll have to try that when I next build a new kernel for this system, I suppose [ CONFIG_USB_PRINTER=y ]. Meanwhile, opinions from people with different usb printers who use cups and libusb would be welcome. Maybe usblp needs to be a module so that it isn't loaded when cups start, or perhaps any previous problem has now been resolved in a recent version of one of the packages. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Util-linux
On Tue, Jan 14, 2014 at 05:18:37PM -0600, Bruce Dubbs wrote: > I found out that util-linux and udev have a circular dependency. What > we do now is OK, but there are some things disabled. What we need to do > is add util-linux-pass2 after udev. > I think you meant to send this to _lfs_-dev. Also, what is disabled ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] : Add package: lsof_4.87
On Mon, Jan 13, 2014 at 09:33:21PM -0300, Fernando de Oliveira wrote:
>
> Some experimenting I have doen, in the following.
>
> For a process run by unprivileged user, no complaints, eg, lsof -c vim.
>
> But for a process run by root, I need to run it as root, because as
> unprivileged user, it does complain, as you say:
>
> {{{
> fernando [ ~ ]$ lsof -c init
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> init 1 root cwd unknown /proc/1/cwd
> (readlink: Permission denied)
First, ignore this reply if I'm becoming overly pedantic, or
overly paranoid, or otherwise unuseful (too much aggravation trying
to find important paperwork, and then replying to a thread elsewhere
by people who are well-intentioned but don't have the item being
discussed :)
Second - consider a system with multiple (physical) users. Yeah,
uncommon for LFS, but supposedly the normal situation for a 'nix
system. You would not want ordinary users to be able to access
root's processes.
> However, when I searched in the internet, the examples all seemed to be
> given as root.
>
> It does not bother me, having to switch to root for some processes, but
> it wouldn't bother if I had always to use it as root.
>
I think that usage of lsof by a normal user is uncommon (which is
why the examples you found were all run as root - I assume the main
use is "why can't I unmount this?" or "what is preventing a normal
shutdown?"), but I've no objection to regular users being able to
use it if it is useful to them.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] [BLFS Trac] #4556: Add package: lsof_4.87
On Mon, Jan 13, 2014 at 06:45:43PM +0100, Armin K. wrote: > On 01/13/2014 06:39 PM, Bruce Dubbs wrote: > > Ken Moffat wrote: > >> > >> Does it work when installed suid (on x86_64) ? I used to build it, > >> but stopped doing that several years ago. Partly, the weird > >> packaging, and test failures, if I recall correctly, caused me to > >> discount it. But I also think that on the rare occasions I tried to > >> use it (mostly development-kernel problems, probably also when I've > >> had problems in the nfs area) it was less than useful. That was > >> with it installed non-suid. > > > > lsof needs to read: > > > > crw-r- 1 root kmem 1, 2 Jul 26 19:14 /dev/kmem > > > > That's at least one reason for the suid bit. > > > >-- Bruce > > > > > > > > Since you decided to put it in /sbin which isn't and shouldn't be in > normal user path, it should be only run as root because of that. > > On the other hand, I can perfectly run it as normal user. It might just > print a warning though, it isn't anything critical if it can't open > /dev/kmem. That shouldn't be something user should be able to read anyways. > I don't even have /dev/kmem, I regard it as a potential vulnerability. See e.g. http://lwn.net/Articles/147901/ - in particular, see Nix's comment from April 2010 near the bottom. So in my .config: # CONFIG_DEVKMEM is not set ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] [BLFS Trac] #4556: Add package: lsof_4.87
On Sun, Jan 12, 2014 at 09:02:47PM -0600, Bruce Dubbs wrote: > akhiezer wrote: > >> Date: Sun, 12 Jan 2014 17:05:27 -0600 > >> From: Bruce Dubbs > >> To: BLFS Development List > >> Subject: Re: [blfs-dev] [blfs-book] [BLFS Trac] #4556: Add package: > >> lsof_4.87 > >> > >> Some of the things it does requires root, even when run as a > >> non-privileged user. > >> > > > > > > Eeek. I'll keep it non-setuid, tyvm. > > LOL. Your distro... > >-- Bruce Does it work when installed suid (on x86_64) ? I used to build it, but stopped doing that several years ago. Partly, the weird packaging, and test failures, if I recall correctly, caused me to discount it. But I also think that on the rare occasions I tried to use it (mostly development-kernel problems, probably also when I've had problems in the nfs area) it was less than useful. That was with it installed non-suid. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] makedepend was Re: Mesalib dependencies
On Sun, Jan 12, 2014 at 07:09:53PM -0300, Fernando de Oliveira wrote: > > Thanks, ĸen. > > So, is the conclusion that makedepend can be archived correct? > Yes, IMHO. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Dependencies again
On Sat, Jan 11, 2014 at 10:21:28AM +0100, Igor Živković wrote: > On 01/11/2014 10:02 AM, Pierre Labastie wrote: > > > > I'd like to know when instructions for optional features should be given, > > and > > when deemed such, why they should not be moved to recommended instructions. > > The way I see it, recommended classification should be used for: > > 1) dependencies that require explicit switch to disable at compile time > 2) system-installed dependencies which can be used instead of bundled ones > 3) dependencies that add a feature that is required to build some other > package in the book > > Everything else is either required or optional. There is nothing wrong > with listing and explaining optional dependencies in detail or fixing > packages to build with some optional feature. > I might subjectively recommend (4) anything which I consider improves the operation/usage of a package. At the moment, I don't have any examples but I'm sure there are several in the book. Or perhaps they have already been changed to "optional". Two more comments - (i.) over time, everything changes. So some packages will be the way we used to do things, and others will follow what people think is current practice. And we will all make misjudgements. I'm not entirely sure that I understand Pierre's problem, and I'm happy to let everyone do as they wish - but I will question details if I think they are wrong or misleading. OTOH, the book is now in a far better state than it ever used to be (not just more packages, but generally up to date) and perhaps this would be a convenient time to enforce more order and consistency upon it - if that is what people wish to do. (ii.) the more we can explain, the better the book will be. Unrelated to the above, a bigger problem for maintaining the book is that we streamline dependencies so that A needs C but we don't mention that if A also needs B and B pulls in C. This does cause breakage if B is changed to not require C (happens occasionally - I'm thinking of things like pkgconfig moving to LFS, and therefore not implying glib2, but there have been other occasional examples. The obvious alternative is to list every dependency. That would make the rendered pages much longer (compare an rpm spec file for any significant package!) and I consider it would make the book much harder to read in a browser. So, I don't support it. But IFF people want to consider enforcing more order and consistency, perhaps we should also look at any other organisational changes in the book ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] makedepend was Re: Mesalib dependencies
On Fri, Jan 10, 2014 at 10:50:19AM -0300, Fernando de Oliveira wrote: [ changing the title to talk only about makedepend ] > > Run "make check" and the builds for 17 with and without makedepend in > the system, and noticed no difference but in the configure part. > > Searched other distributions, and have some difficult finding it. IIRC, > only found in one page that was stating something like "this page is too > old..." > > I may be wrong, but makedepend is a strong candidate for archive. If no > objections or if I have not committed mistakes in this analysis, this is > simple enough for me to do. > In my most-recent builds (October), makedepend still shows up as an optional dependency for attr. I used to build attr after xorg, and on those old builds attr's configure did find it. Nowadays it finds /bin/true and is happy to build without makedepend. Mesa _used_ to use makedepend, at least between 7.0.2 and 9.0.1, but as of 9.2 it no longer referenced it. Firefox used to check for makedepend, but no longer does so. It still creates makedepend files, but I guess that (and mozjs checking for makedepend) is just a leftover from the old way of building. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] add new package tree-1.6.0 [Was: Patch delete a directory]
On Fri, Jan 10, 2014 at 12:03:32AM +, Matt Burgess wrote: > On Thu, 2014-01-09 at 23:10 +0000, Ken Moffat wrote: > > > > > Thanks for the pointer. I'd forgotten about installing tree in clfs > > to get udev tests to work in the distant past, partly because Matt > > insisted that it wasn't needed for LFS. > > Me? Insist? Really? Doesn't sound like me...I'm far too > weakly-opinionated! I do remember udev using tree(1) for its tests, but > can't remember my rationale for excluding it. A quick google hints at > this being around the 2005 timeframe [0], but I can't find any > incriminating evidence pointing the finger directly at me for not > putting tree in the book. > 2005 seems about right. I don't recall the details, but I was editing both LFS and clfs at that time. Something in LFS was different from clfs (probably, clfs was technically broken for the udev tests). > I've only just realised now though that not only do we not run the tests > in LFS (which is why this has probably been unnoticed until now, at > least by me), but we don't even mention why this package isn't tested. > > Cheers, > > Matt. > I was referring specifically to eudev - my last build used what is now an old version of that, and it claimed to run tests, but didn't really. Last time I looked, there was no "make check" option in udev-from-systemd, I assume that the upstream tests needed far more infrastructure than was available in a non-systemd LFS. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] add new package tree-1.6.0 [Was: Patch delete a directory]
On Wed, Jan 08, 2014 at 07:22:50PM +0100, Igor Živković wrote: > On 01/08/2014 07:06 PM, Fernando de Oliveira wrote: > > > > It is a good package, displays in dircolors, more clear output than > > using find? > > [...] > > > > Installation, although simple, not so straight forward: > > > > make && make prefix=/usr MANDIR=/usr/share/man/man1 install > > > > Simple to add the page. > > > > Opinions, please? > > Sure, I install it in LFS before eudev as it uses tree for one of the > tests. BTW, you don't need the prefix switch as /usr is the default. > Thanks for the pointer. I'd forgotten about installing tree in clfs to get udev tests to work in the distant past, partly because Matt insisted that it wasn't needed for LFS. I'll add it to my next build, whenever that is, to see how the eudev tests pan out. So, thanks to Fernando for noting the MANDIR override - I'm now persuaded not to make the man,info symlinks but I'm sure some of the non-BLFS packages I build will show up when I do that ;-) -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Mesalib dependencies
On Wed, Jan 08, 2014 at 10:30:42AM +0100, Igor Živković wrote: > On 2014-01-08 03:11, Bruce Dubbs wrote: > > > > I'd say go ahead and change it. Igor made the most recent change, but > > since you have the changes in mind, it would be easiest for you to get > > it the way you want. We can always make additional changes if needed. > > > > Igor, are you OK with that? > > Of course, although it was Ken who actually changed it after a recent > discussion. As Armin said, current instructions satisfy all three most > commonly used graphic cards nowadays. I'd like to see more explanation > on VDPAU though. > I think that more explanation would often be useful. Let's see what Randy comes up with. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 06:51:44PM +0100, Armin K. wrote: > > Now that I've built it as module, the microcode firmware seems to load > just fine and I did notice something: > > dmesg output, early boot - before /sbin/init has been ran: > > [0.040548] perf_event_intel: PEBS disabled due to CPU errata, please > upgrade microcode > > dmesg output, after udev has been started and it has loaded the > microcode module: > > [ 10.471604] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.720949] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.722411] microcode: CPU0 updated to revision 0x28, date = 2012-04-24 > [ 10.722486] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.722555] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.723511] microcode: CPU1 updated to revision 0x28, date = 2012-04-24 > [ 10.723549] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.723617] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.724582] microcode: CPU2 updated to revision 0x28, date = 2012-04-24 > [ 10.724596] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.724631] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.725553] microcode: CPU3 updated to revision 0x28, date = 2012-04-24 > [ 10.725573] perf_event_intel: PEBS enabled due to microcode update > [ 10.725673] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > > > > I don't know what PEBS is, but in this case, microcode update seems to > enable it. > I knew it was something to do with kernel performance monitoring, (i.e. instrumenting how long is spent in various parts of the code) and eventually found it documented in http://perfmon2.sourceforge.net/pfmon_intel_core.html : Precise Event-Based Sampling. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 01:11:56AM +0100, dueff...@uwe-dueffert.de wrote: > Hi, > > On Sun, 5 Jan 2014, Aleksandar Kuktin wrote: > > > Well, there's something since I always rebuild GTK+ after I build > > librsvg. > > > > Okay, Emacs uses it, but that's not what I was after. Nevermind. > > Still sure something else requires librsvg but can't prove it. :) > I doubt that it helps, but I for one did start building librsvg (after > GTK) because gimp seemed to require it a couple of years ago. BLFS gimp > instructions mention it as optional nowadays (and GTK as required), so no > reason for a circular dependency here either. According to my logs gimp > seems to by my only package that actually uses librsvg... > > Uwe [ /me goes off and looks at my git scripts ... ] - you are right : a couple of years ago I was building librsvg in my script after firefox had been built, i.e. where I was building print packages and the gimp, as well as ImageMagick. That was for gnome-2.32-ish and gimp-2.6. Initially, I had been going to say I was surprised by your comment, because I've been building librsvg late in my sequence (at first for abiword or goffice, now for libreoffice) for as long as I can remember. Yeah, my memory is short! The only thing I can say with any confidence is that over time, all dependencies and build orders will change ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 12:14:53AM +0100, Aleksandar Kuktin wrote: > >On Sat, 04 Jan 2014 23:33:13 +0100 > >"Armin K." wrote: > > > > On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > > > > What exactly is intel-ucode-20130222 for? > > > > CPU microcode update. It updates CPU microcode at runtime using > > "microcode" driver in the kernel. It's firmware actually. > > > > Now that you mention it, it seems that it doesn't work anymore > > somehow, probably since I've built microcode driver into kernel but > > firmware is in /lib/firmware. Yeah, a similar "progress update" on lkml at the end of this week reporting (in the context of an original report that it was ok in 3.8.2 but broke in 3.8.3) that in fact it doesn't work if built in. Certainly, when I last tried firmware updates (perhaps 6 months ago) I had the impression that none of my boxes had available newer firmware, but I was almost certainly building it in. > > Hmm.. Any improvements in the way system handles itself with the new > firmware? Normally I use AMD, but I'm now on an Intel box so I have to > bother with this a bit. Apart from anything else, you need a CPU version for which updates have been issued (I guess that is usually to install workarounds for errata). In the lkml thread I got involved in, I think that kmail was unusable without the update! Not at all what I had expected. Meanwhile both my own and the other guy's AMD phenoms tend to lose their lunch when using 'make -j4' (fixed by dropping the caches and using -j3) and apparently the firmware update might not alter that. > > BTW, I found that putting firmware into the kernel binary (as opposed > to /lib/firmware) works best for me. No need to deal with helper > programs and other such stuff. > For ordinary drivers (video, particularly radeon, and nic or wifi) that seems to be easier - it does, however, waste kernel memory which is why kernel devs don't recommend it - I guess that is more important on a distro which builds everything, and for 32-bit kernels where at most 4GB (less PCI space, particularly for video) is addressable. The notes look interesting, particularly /lib and /lib32, but I'm supposed to be spending all my time on my (UK) tax return this month, and for the moment I can't afford to study them. Also, I used to think that X32 would be interesting - but modern DDR3 memory sticks are so big that I'm no longer convinced that would be worth the effort. And I don't need any 32-bit binaries in linux. So maybe I won look to deeply at multilib. But it's always interesting to see how other people build things, particularly the order, and to challenge my choices. So, thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Nitpick with Shadow Package
On Tue, Dec 31, 2013 at 09:26:53PM +, Ken Moffat wrote: > On Tue, Dec 31, 2013 at 01:36:47PM -0600, Bruce Dubbs wrote: > > > > In any case, Randy's observation that LFS and BLFS install shadow > > differently is still accurate. Should we change LFS to omit the ko/zn > > man pages or remove the sed from BLFS that does that. > > > > I lean towards removing the sed from BLFS, but will defer to those who > > do more with non-US fonts. > > > >-- Bruce > > I'm all for allowing _any_ text to render, even if I can't read it. > So, +1 for that from me - but I'd rather see the comments from the > editors who are actively maintaining the book. > And before the year gets any older, I'll offer my apologies to both Bruce and Randy for misreading Randy's original post. Anyway, everything is for the best, in the best of all possible worlds. [ Voltaire, Candide ] ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Nitpick with Shadow Package
On Tue, Dec 31, 2013 at 01:36:47PM -0600, Bruce Dubbs wrote: > > In any case, Randy's observation that LFS and BLFS install shadow > differently is still accurate. Should we change LFS to omit the ko/zn > man pages or remove the sed from BLFS that does that. > > I lean towards removing the sed from BLFS, but will defer to those who > do more with non-US fonts. > >-- Bruce I'm all for allowing _any_ text to render, even if I can't read it. So, +1 for that from me - but I'd rather see the comments from the editors who are actively maintaining the book. Meanwhile, Lang May Yer Lum Reek! ĸen - "Just a wee deoch an doruis then ..." -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Nitpick with Shadow Package
On Tue, Dec 31, 2013 at 12:17:42PM -0600, Bruce Dubbs wrote: > Armin K. wrote: > > On 12/31/2013 06:58 PM, Randy McMurchy wrote: > >> Hi all, > >> > >> Looking at the BLFS Shadow package instructions, there is a command > >> and descriptive text for disabling the Korean and Chinese man pages. > >> However, this is not done in LFS. Seems the two books would be > >> consistent as far as which man pages are installed. > >> > >> Thoughts? > >> > > > > I believe that LFS had some note for man-db that it couldn't properly > > display man pages in some languages, but that was fixed some time ago. > > I'm not sure how to check. I tried: > > $ LANG=ko man chfn > man: can't set the locale; make sure $LC_* and $LANG are correct > > but it did display the English page. We do have the ko, zh_CN, and > zh_TW pages installed. I also see that nmap installs a zh page. > >-- Bruce > From some quick tests (in urxvt on a 'buntu "desktop" on my netbook, using ssh to get to my 7.4 server) I can display the shadow pages I tried for the ja_JP, ko_KR, zh_CN, zh_TW locales : but only if I specify LC_ALL=ja_JP.UTF-8 : omitting the .UTF-8 gave me gibberish. This also requires the locales, of course, and suitable fonts. Arguably, LFS is out of date - but very few LFS users seem to care about CJK text. There is, of course, no way to display CJK in a regular tty (far too many potential glyphs). But from any desktop term which is correctly set up and has a suitable font you can display them using the form 'man /usr/share/man/ja/man1/su.1' and the same if you replace 'ja' by 'ko', 'zh_CN' or 'zh_TW'. Unfortunately, many of the other pages are not present in all four of these CJK locales. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] man pages permissions wrong: none displayed
On Tue, Dec 31, 2013 at 10:49:48AM -0300, Fernando de Oliveira wrote: > Em 31-12-2013 10:07, Fernando de Oliveira escreveu: > > Em 31-12-2013 09:19, Pierre Labastie escreveu: > >> Le 31/12/2013 12:50, Fernando de Oliveira a écrit : > >>> I discovered today that no man page was displayed. The reason was a > >>> directory with wrong permissions: > >>> > >>> $ ls -dl /usr/share/man > >>> drwxr-x--- 52 root root 4096 Dez 27 13:28 /usr/share/man > >>> > >>> No idea why. > >>> > >>> Corrected with: > >>> > >>> # chmod -c 2775 /usr/share/man > >>> > >>> Any way of discovering the source for the problem? > >>> > >>> Thanks. > >>> > >> If you have no file monitoring installed, the only indication you have is > >> the > >> date (December 27) and the time (13:28) it got modified for the last time. > >> > >> And then, try to remember (or to find logs of) what you were doing at that > >> time... > >> > >> regards > >> Pierre > > > 27-Dec-2013 13:28 xfce4-terminal-0.6.3 > > > > Now, need to see if it is really this one, the problem. > > > > It does not, just installs a man page with 664: > > /bin/sh -c 'test -d /usr/share/man || mkdir -p /usr/share/man' > }}} > > So, still a mystery. > We had this a few months ago - in that case it was the git manpages which are shipped in a separate tarball. Unfortunately, this sort of error can remain hidden for several days (or longer) until we need to check a man page. Does a git manpage upgrade seem a likely possibility ? If not, do you have any recent backups - and a list of what you installed - to help identify what range of packages were involved ? Did you install any other *separate* manpage tarballs ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] remove pcre from wireshark dependencies [Was: ... r12437 ]
On Tue, Dec 24, 2013 at 02:32:08PM +0100, Igor Živković wrote: > On 12/24/2013 12:45 PM, Fernando de Oliveira wrote: > > > > Before your post and due to Pierre's reply, I decided to do a last > > investigation. Not sure if it concludes pcre should or not be > > "Optional". All applications installed by wireshark-1.10.5 are linked to > > pcre directly. > > Not really. You're seeing libpcre.so in ldd output because > libglib-2.0.so links to it. > > A better tool for such purposes is, for example, scanelf from pax-utils: > I haven't come across pax-utils before. Added to my "to look at" list. The thread has been educational - thanks. Seasonal felicitations to you all. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Post LFS Systemd configuration
On Sun, Dec 22, 2013 at 12:42:50AM +0100, Armin K. wrote: > Here's a quickly written version what would BLFS systemd > instruction sort of look like: > > I don't think I'll have time in next two weeks to work on anything, but > this should cover most of what's needed for BLFS. > [ snipped to save space ] Thanks for documenting this - I'm sure a lot of people will try it. I guess that I too should add my "welcome back", even though I still abhor systemd. So, Welcome back and enjoy whatever seasonal festivities you've got lined up. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Totem-3.10.1 and grilo-plugins-0.2.9
On Sun, Dec 08, 2013 at 01:32:02PM -0300, Fernando de Oliveira wrote: > > Thanks, ĸen. Only now I see that I forgot to reply, I thught had replied. > > Although some plugins do not work, others do, so some some functionality > is added, as Bruce thought, and the warning messages are fixed. > > So, what do you think about adding it to the book? > Yes. I think (perhaps) grouping the dependencies by what they are used for, and some sort of note to distinguish which plugins are known to work. I'm not sure what form of words I would use if I was doing that. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Totem-3.10.1 and grilo-plugins-0.2.9
On Fri, Dec 06, 2013 at 08:18:28PM -0300, Fernando de Oliveira wrote: > > ĸen, good news!!! They are working. And I think they are working for > you, too. > > I saw the video at the address below (It is in Spanish, but what > mattered was the video playing, no need for any language): > > http://people.igalia.com/vjaquez/grilo-screencast.html > > Then I went to Totem: > > View -> Browse > > or > > View -> Search > > The plugins are there, not in the "normal" plugins. > Ack. > Could watch: > > Rai.tv -> Most popular > All -> Una grande famiglia > Si, sto guardando delle donne Slalom Gigante da Beaver Creek. (according to google translate and the title bar). Bellissimo! Or "I'm watching the women's GS (might be Super GS) from Beaver Creek. Nice." Took me a while to find where I'd built totem-3.8.2 - it's on my i686 system. > Blip.tv -> X-Files Where Are They Now > > Apple Movie Tralers -> 12 Years a Slave. > That apple works too - I feel so unclean for looking at anything apple :-o Gnome certainly fooled me by hiding the grilo plugins away there! I don't have a youtube option, and my log shows that it wasn't built. But I use firefox or arora for youtube! Well done. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Totem-3.10.1 and grilo-plugins-0.2.9
On Fri, Dec 06, 2013 at 07:12:45PM -0300, Fernando de Oliveira wrote: > > Thanks, ĸen, > > I was too fast and created the ticket (we say in Portuguese "do not go > too thirsty to the pot", in English, I think, it would be "do not get > carried away") . Will think more about it, after what you wrote. If I > have something worth, I will discuss here, if not... > Creating the ticket is fine. Actually, I hope that you do manage to get the plugins to work. But if not, in the fullness of time you can close the ticket with a note that the plugins don't seem to be used. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Mozilla Builds
On Fri, Dec 06, 2013 at 03:38:08PM -0600, Dan McGhee wrote: > That's why I tried re-compiling my kernel for SMP. Right now I get only > CPU0 out of four. But I haven't been able to get an SMP kernel to boot > and nearly gorked my whole build so far because the names of the modules > apparently get prefixed with SMP and my "old" kernel can't find them--at > least that's what I think I saw when the messages went screaming by when > I tried to boot my "old" kernel. Oh well, another project. The modules do not get prefixed with SMP on my SMP machines. What might be happening is that you haven't added an EXTRAVERSION, so 'make modules_install' first deletes the existing modules and then installs the new (SMP) modules which will not load with a uniprocessor kernel. To be honest, until you can get an SMP kernel to boot, everything else will be a waste of your time on a _build_ machine. O/T for this list, but save your non-smp config, then copy it to .config and in menuconfig ONLY change it to build for SMP. All the other things mentioned in the last couple of days for .config are just details which might improve it (but might not). A fresh kernel build on a single modern CPU is probably less than 20 minutes. OTOH, if you NEED to rebuild the UP kernel because some modules are _required_, do that first using the UP config followed by modules_install (at that point you can use the modules without rebooting) and then add an EXTRAVERSION and build an SMP kernel. > > Right now, with no actual experience and only logic (and reasonable > logic I hope), I figure that since you can build any combination of > SeaMonkey, Firefox, Thunderbird and Xulrunner from one source release, > Thunderbird should be able to compile just like Firefox. I know that I > will get Thunderbird 25.0.1 instead of the version in the book, but I'll > see what happens. > I don't think you can build SeaMonkey from firefox releases. SeaMonkey is based on an older firefox/mozilla version. Anyway, I thought SeaMonkey could include the mail client, in which case thunderbird would be redundant ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
