[blfs-dev] Postgresql init script
FYI, we are currently using a mkdir for the pidfile in postgresql script. We have a mechanism in place for this outside of the init script (createfiles): echo "/run/postgresql dir 755 postgres postgres" >> /etc/sysconfig/createfiles Any objections if I make the change? Of note, for later, this should be a .d directory. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Berkeley DB library locations
On December 3, 2020 3:18:39 PM CST, Bruce Dubbs via blfs-dev wrote: >In some cases PAM may use Berkeley DB libraries. We should probably >change the bdb build to move the libraries to /lib: > >... I don't think that is necessary, or at least not by FHS if that's what prompted the suggestion. By the time you reach a login prompt, networking should be up, and if it's not, it'll just fail and move on to the next module in the chain (eventually making it's way to using local files), so it doesn't make any difference for the FHS case. I suppose a local db can be a concern (I've never set one up that way), but you are likely in the same boat in either case if /usr is not available at that time, as you are probably wanting to fix the missing /usr. -- DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On 10/23/2020 11:01 AM, Ken Moffat wrote: Is there an official python recommendation for that, to quote at them, please ? To bring this all back around, here is a link to the discussion I inadvertently mentioned off-list to Ken: https://github.com/python/peps/pull/893 - which ultimately led to the changes noted below. And here is the actual PEP 39*4*: https://www.python.org/dev/peps/pep-0394/ Pay attention to each of the three targets in the section titled "Recommendation" but for the purposes of this question, the recommendation for script publishers is what is important and these bullet points specifically: * In cases where the script is expected to be executed outside virtual environments, developers will need to be aware of the following discrepancies across platforms and installation methods: o Older Linux distributions will provide apythoncommand that refers to Python 2, and will likely not provide apython2command. o Some newer Linux distributions will provide apythoncommand that refers to Python 3. o Some Linux distributions will not provide apythoncommand at all by default, but will provide apython3command by default. * When potentially targeting these environments, developers may either use a Python package installation tool that rewrites shebang lines for the installed environment, provide instructions on updating shebang lines interactively, or else use more specific shebang lines that are tailored to the target environment. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On 10/24/2020 6:15 AM, DJ Lucas via blfs-dev wrote: I'm sorry, even this blurb was not entirely correct Short answer, if it still has '/usr/bin/env python' in the shebang, insert here: "isn't limited to a virtual environment," and it doesn't work with with both python2 and python3, then it's abandonware. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On 10/24/2020 6:15 AM, DJ Lucas via blfs-dev wrote: After reading PEP 393 for the umpteenth time Grr, it's PEP 394, not 393. Sorry. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On October 23, 2020 12:10:07 PM CDT, Bruce Dubbs via blfs-dev wrote: >On 10/23/20 12:00 PM, Ken Moffat via blfs-dev wrote: >> On Fri, Oct 23, 2020 at 11:22:06AM -0500, Bruce Dubbs via blfs-dev >wrote: Is there an official python recommendation for that, to quote at them, please ? >>> >>> That's a good question, but I would also like to see if there is a >survey of >>> the major distros on the subject. I know arch has had >python->python3 for a >>> long time, but I don't know what Debian, Gentoo, Fedora, SUSe, >Slackware, >>> etc currently do. Does anyone know or have access to systems that >can >>> easily check? >>> >>> In the past most had python->python2 because that was baked into the >p2 >>> Makefile. Creating a symlink is not in the current p3 Makefile. > >> I think Arch followed fedora in symlinking python3 to python. >> >> Gentoo is complicated - python is used for a lot of their build >> system and they have 'slots' for multiple versions. It looks as if >> they don't have a python symlink, but I guess there could be such a >> symlink while (re)building a package. >> >> https://wiki.gentoo.org/wiki/Python >> >> Ubuntu seems to be removing /usr/bin/python from a comment re 20.04 >that >> somebody's desktop has it from the python-is-python2 package, but >that his >> other systems don't have python2 >> >https://www.gamingonlinux.com/2020/04/distro-news-ubuntu-2004-focal-fossa-ubuntu-mate-and-other-flavours-released/page=5 >> Certainly, I've seen gimp-help suggestions to use flatpack for >> python2 scripting in ubuntu because of the absence of python2. > >I just found out that Mint 20 has python2 and python3, but no python. > > -- Bruce >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Short answer, if it still has '/usr/bin/env python' in the shebang, and it doesn't work with with both python2 and python3, then it's abandonware. They've had nine years to fix it and haven't. After reading PEP 393 for the umpteenth time, I'm now more partial to just dropping the symlink all together and making shebang lines explicit as was done with Ubuntu and its variants. PEP 393 really ultimately left it up to the distro, but my reading of it suggests this is the best path forward. The user can't expect to get an interpreter with no symlink if they type 'python' at the cli, but that makes any errors outside of BLFS rather explicit, as opposed to complaining about print() syntax (or worse). We can suggest adding an alias for python to python3 in the user's .bashrc if people complain. We can try and help out, hit it with 2to3 and follow the prompts, or better, introduce sixer, and see if it works as expected and submit upstream. But that introduces six and sixer as more dependencies upstream, sixer at least, requires itself on target for whatever version of python matches the symlink because it'll replace python2 syntax with it's own mostly compatible variant (ex: sixer.iteritems(...) rather than items(...) as a replacement for iteritems(...)), but it does a better job than 2to3 or others. Introducing future has it's own quirks as well, and like 2to3, requires some knowledge of python and manual edits. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On October 23, 2020 10:15:09 AM CDT, Ken Moffat via blfs-dev
wrote:
>On Fri, Oct 23, 2020 at 09:04:53AM +0200, Pierre Labastie via blfs-dev
>wrote:
>> On Fri, 2020-10-23 at 07:00 +0100, Ken Moffat via blfs-dev wrote:
>> > On Thu, Oct 22, 2020 at 04:44:19PM +0100, Ken Moffat via blfs-dev
>> > wrote:
>> > > On Thu, Oct 22, 2020 at 11:24:52PM +0800, Xi Ruoyao via blfs-dev
>> > > wrote:
>> > > > On 2020-10-22 16:14 +0100, Ken Moffat via blfs-dev wrote:
>> > > > > On Thu, Oct 22, 2020 at 06:25:59AM -0500, Bruce Dubbs via
>blfs-
>> > > > > dev wrote:
>> > > > > > On 10/22/20 12:56 AM, DJ Lucas via blfs-dev wrote:
>> > > > > > > On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via
>blfs-
>> > > > > > > dev
>> > > > > > > wrote:
>> > > > > > > > On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote:
>> > >
>> > > Ywah, I've now found a non-book package (youtube-dl) which
>defaults
>> > > to '/usr/bin/env python' (in its Makefile) but can be overridden
>by
>> > > passing PYTHON=/usr/bin/python3 (or probably just =python3).
>> > >
>> > > It turns out that whatever we do will probably cause some work.
>> > >
>> > Reluctantly, I have to go with a python symlink. Out of the more
>> > than 48000 tests in clang-11.0, one uses /usr/bin/env/python.
>> >
>>
>> When we find something like that, couldn't we use:
>> grep -rl '#!.*python' | xargs sed -i
>> '1{s/python$/python3/;s/python[^3]/python3}'
>>
>> or so?
>> Of course, P2 only scripts would still fail, but at least, nothing
>> would depend on a python symlink.
>>
>> Pierre
>>
>I think the problem is more that using env python is hidden deep
>within a lot of packages.
>
>I've already comments (e.g. from python2.6 -> 2.7 days) that python
>is an intrinsic part of the OS and changing it (rather than pointing
>to an extra installed version) is a bad idea which breaks things.
>My point is that this seems to be a deep assumption among peopel who
>code python scripts.
>
>In this case, when I first compiled and tested llvm-11 on this new
>ystem I had python -> python2 and that test passed. There were some
>new failures from a non-available static lib. Now that I'm
>measuring it I saw that I'd got rid of those failures, but gained an
>extra one. Finding it was somewhat painful.
>
>For tests (I had made the symlink for 3 and rebuilt before reading your
>mail, they are currently running) I don't think it matters a great
>deal. I'm more concerned about installed scripts (in other
>packages) which may randomly fail at runtime.
>
>ĸen
>--
>The people next door oppress me all night long. I tell them: I work
>all day, a man's got to have some time to learn to play the tuba.
>That's oppression, that is.[ Guards! Guards! ]
>--
>http://lists.linuxfromscratch.org/listinfo/blfs-dev
>FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>Unsubscribe: See the above information page
This _should_ go away on its own eventually. You are supposed to specify the
major version. If a particular script doesn't, it is broken. Opening bugs for
these errors upstream is entirely appropriate.
--DJ
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-dev
wrote:
>On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote:
>>
>
>In LFS, we can make the symlink to p3. For p2 in BLFS, we will use
>'make altinstall'. Everything else would be for non-python packages
>that either use p2 or create a p2 module.
>
Ok, I'll go back and fix it that way locally then. I'm not too far. I have only
like 8 packages that have py2 optional deps listed.
So for BLFS, just do it and fix on the fly, or create a tracker bug and let the
devs run through it a time or two? I don't think it's going to be all that big
of a deal, but might be nice to avoid any interim breakage, do as one big
commit or a small series of commits to make it easier on people who are
upgrading.
>> As to gimp (mentioned earlier in this thread), is excising python2 a
>> goal of the 3.0 release? It is about the only *major* consumer left.
>> There are only 22 bugs remaining that are not labeled "feature"
>> currently targeted for the 3.0 milestone. Many of those are old as
>well.
>>
>https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_title=3.0[label_name][]=1.%20Feature
>
>
>I did a git clone (very slow) and looked.
>
>configure.ac:m4_define([python3_required_version], [3.6.0])
>meson.build:is_git_repository = run_command('python3', '-c',
>
>Also in NEWS:
>
> The API is GObject Introspected into 2 modules: Gimp and GimpUi.
> This means plug-ins can be written in various non-C languages. So
> far the following languages have been tested and work well: Python
> 3, Lua, Javascript and Vala.
> (Note: Python 2 is also still working, but considering that this
> language is end-of-life since 2020, we don't really care).
>
>So it does look like it will be p3.
>
Nice, that makes things easier, eventually. The gimp team isn't exactly known
to rush releases - It'll be ready when it's ready - and while it can be
frustrating at times, that's ultimately a good thing.
-- DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On 10/21/2020 7:12 PM, Kevin Buckley via blfs-dev wrote: On Thu, 22 Oct 2020 at 00:26, Bruce Dubbs via blfs-dev wrote: Currently we have /usr/bin/python -> python2. Is it time to change that to python3? Probably a bit too drastic a view, but should we even be propagating the need to have a bare python? Interesting point. I appreciate it can be a convenience when 2 and 3 co-exist but the price for that convenience across the version change has been high. My preference would be to not use the bare "python" anywhere, so that scripts have to be explicit about which major version they want. It will make things a lot easy when python4 comes along! As to the convenience link in /usr/bin, I'd look to remove it and tell people that they can alias the bare "python" if they really, really need to, but that they have to make the choice to do so: the system won't be doing it for them. I've effectively already done this being that I'm deliberately avoiding Python2, but IIRC, that means removing the symlink after it's installed (the Python-2.x installation does it automatically) - or a sed to keep it from being created I guess. I'm going to proceed with this approach. As to gimp (mentioned earlier in this thread), is excising python2 a goal of the 3.0 release? It is about the only *major* consumer left. There are only 22 bugs remaining that are not labeled "feature" currently targeted for the 3.0 milestone. Many of those are old as well. https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_title=3.0[label_name][]=1.%20Feature --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xorg-applications
mkfontdir is no longer needed (probably hasn't been in a long time). It is a shell script and both it and the manpage are included with makefontscale. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Reinstallation of packages
On September 27, 2020 4:45:40 PM CDT, Joe Locash via blfs-dev wrote: >Isn't this the same as >http://lists.linuxfromscratch.org/pipermail/blfs-dev/2020-September/037633.html > > >On Sun, Sep 27, 2020 at 3:32 PM DJ Lucas via blfs-dev < >blfs-dev@lists.linuxfromscratch.org> wrote: > >> Do we have a policy about reinstalls? If elogind is installed, both >> make-ca and Linux-PAM create a /usr/lib/systemd directory (and >> services). I intend to fix make-ca in a different way, but should >> instructions be added to prevent this or remove them? >> >> --DJ >> >> >> -- >> http://lists.linuxfromscratch.org/listinfo/blfs-dev >> FAQ: http://www.linuxfromscratch.org/blfs/faq.html >> Unsubscribe: See the above information page >> It was, and I missed it. That said, at this time I am also unsure whether GDM now needs the new PAM module, and if so, whether we need a bootscript (or policy) to start the module helper. Probably not. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Reinstallation of packages
On 9/27/2020 2:56 PM, DJ Lucas via blfs-dev wrote: On 9/27/2020 2:40 PM, Bruce Dubbs via blfs-dev wrote: On 9/27/20 2:32 PM, DJ Lucas via blfs-dev wrote: Do we have a policy about reinstalls? If elogind is installed, both make-ca and Linux-PAM create a /usr/lib/systemd directory (and services). I intend to fix make-ca in a different way, but should instructions be added to prevent this or remove them? It would be better to have a simple way to prevent unneeded files from being installed. Existing configuration files should not be changed without a --force option or equivalent. -- Bruce Okay, so it turns out this is for pam_namespace, which is not necessary on SysV. I'll kick it out. The systemd files are already covered for the book, I just missed the change. I'm still looking to see if the module is useful for SysV and if we need to start the helper. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Reinstallation of packages
On 9/27/2020 2:40 PM, Bruce Dubbs via blfs-dev wrote: On 9/27/20 2:32 PM, DJ Lucas via blfs-dev wrote: Do we have a policy about reinstalls? If elogind is installed, both make-ca and Linux-PAM create a /usr/lib/systemd directory (and services). I intend to fix make-ca in a different way, but should instructions be added to prevent this or remove them? It would be better to have a simple way to prevent unneeded files from being installed. Existing configuration files should not be changed without a --force option or equivalent. -- Bruce Okay, so it turns out this is for pam_namespace, which is not necessary on SysV. I'll kick it out. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Reinstallation of packages
Do we have a policy about reinstalls? If elogind is installed, both make-ca and Linux-PAM create a /usr/lib/systemd directory (and services). I intend to fix make-ca in a different way, but should instructions be added to prevent this or remove them? --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Permission to upgrade LSB-Tools post tagging
A fix to the issue mentioned on support is included as well as dropping the sed. Also, not as important, but new bootscript releases in both books to get the failsafe for $syslog in place (it's unlikely to ever get triggered, but JIC). --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] The xc directory
On 3/22/2020 5:21 PM, Pierre Labastie via blfs-dev wrote: Le 22/03/2020 à 22:59, Bruce Dubbs via blfs-dev a écrit : On 3/22/20 4:47 PM, Ken Moffat via blfs-dev wrote: (Bcc to DJ in case he is not following everything on this list) Prompted by noticing yesterday that someone had a problem while trying to build mozjs60 and happened to be building that in the xc directory - In 'Introduction to Xorg-7' we say: First, you'll need to create a working directory: mkdir xc && cd xc But we never actually go out of those directories anywhere in the book. I have not created an xc/ directory for building in _many_ years. From memory, DJ introduced this directory in the days when Xorg was transitioning from the old monolithic "everything in one tarball" to the current "many separate packages" approach, perhaps releases 6.8 (old-style) and 6.9 (new-style). The purpose was to ensure that nothing which was compiled in the old approach had been omitted from the new approach. I think the time to remove the xc directory is long overdue. But as always, I might be missing something. comments welcome, particularly from DJ. I do have my sources in an xc directory, but that only has other directories within it. For me it's a convenience, but it is certainly not needed in the book. I'm OK with removing it. Ok too. Since xc is only mentioned in the Introduction, and not in the packages pages, an automated builder such as jhalfs does not use it. Pierre Your memory is correct. xc was the working directory in the monolithic tarball. There really is no purpose for it now days, other than maybe a convenient separation of the Xorg packages, and in the not too distant future, that probably won't be all that many packages anyway. I'll probably continue to use it out of habit, but it serves no real purpose for the book (and honestly, never really did). --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LSB-Tools: symlink creation no longer needed
On 2/16/2020 12:04 PM, Bruce Dubbs via blfs-dev wrote: On 2/16/20 11:31 AM, Douglas R. Reno via blfs-dev wrote: On 2/16/20 5:21 AM, Bruce Dubbs via blfs-dev wrote: On 2/16/20 12:01 AM, Douglas R. Reno via blfs-dev wrote: Hi folks, I know that we're in a semi-package freeze right now, so I wanted to ask a question about a package that's already been tagged. root [ /sources/LSB-Tools-0.6 ]# ln -sv /usr/lib/lsb/install_initd /usr/sbin ln: failed to create symbolic link '/usr/sbin/install_initd': File exists This is after running "python3 setup.py install --optimize=1" I don't think that the ln commands to create the symlink are needed anymore: ln -sv /usr/lib/lsb/install_initd /usr/sbin && ln -sv /usr/lib/lsb/remove_initd /usr/sbin Are there any objections to me removing them? I think the links are still needed for a first install. My log shows them being created. we could add -f to the ln command to avoid the error message if reinstalling. -- Bruce This was a first install though, on my new system. I think it might be better to do "sfv" though - do you have that in your script? I do. I'll update next commit. -- Bruce No, I fixed that in the installation. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Dependency problem with firewalld
On 2/13/2020 12:16 PM, Pierre Labastie via blfs-dev wrote: There is something weird in the ebtables repository: https://git.netfilter.org/ebtables/commit/?id=6218f812d894fdd733d95c3c86b385f6f223a36a --- The original ebtables tool is now the legacy version, let's rename it. A more uptodate client of the ebtables tool is provided in the iptables tarball (ebtables-nft). The new tool was formerly known as ebtables-compat. --- So I understand that ebtables-nft should be installed by iptables. But I do not see it... Ah, we have --disable-nftables in iptables. ebtables would be installed if we removed this switch. Guys, I'm sorry I haven't been able to get to any of this yet. I will as soon as I'm able. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Testing without python2 : dead halt at JS60.
On 12/22/2019 4:20 AM, DJ Lucas via blfs-dev wrote: It's trying to use 2.7 with 3.x syntax. `sed 's@2\.7@3.8@g' -i ../js/src/configure` will get us past that. It builds to completion, and installs to DESTDIR, but I haven't used it yet. I didn't look at it, it doesn't install any python modules, just for the build system, so seems to be fine. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Testing without python2 : dead halt at JS60.
On 12/21/2019 11:35 AM, Xi Ruoyao via blfs-dev wrote:
On 2019-12-16 00:53 +, Ken Moffat via blfs-dev wrote:
Indeed. The "patch" I found was 9800 lines. I haven't counted how
many lines are in my first attempt to update it. I have a severe
dislike of python, as is probably already apparent (the whitespace
issue) and I mostly find the error messages unuseful - if it fails
to find a specific thing, I would hope to get a more-specific
message.
I uploaded a mozjs-60 tarball which can be built with /usr/bin/python ->
python3：
http://www.linuxfromscratch.org/~xry111/mozjs-60.8.0-py3-src.tar.xz
“Patching" won't work here. Inside the source code tree there is a file n
amed pip-8.1.2-py2.py3-none-any.whl. It's actually a zip file containing some
python code. One .py file in the whl file have to be updated. "Patching" can't
modify a zip file.
So...I started down this path on my most recent build.
I started with the (apparently incorrect) assumption that Mozilla
projects will require Python-2.7.
I have /usr/bin/python -> python3.8, /usr/bin/python-config ->
python3.8-config, and /usr/bin/pip -> pip3.8.
I did the following with the original source (which worked for dependents):
===
# Fix incorrect interpreters
for file in `grep -Rl "#\!/usr/bin/env python" *`
do
sed 's@/usr/bin/env python@/usr/bin/env python2@' -i $file
done
# Undo damage from fist step
for file in `grep -Rl "/usr/bin/env python23" *`
do
sed 's@python23@python3@g' -i $file
done
===
Using your tarball with the above setup, I get an error:
dj@lfsdt1 [ /sources/mozjs-60.8.0-py3-src/mozjs-build ]$
../js/src/configure --prefix=/usr --with-intl-api --with-system-zlib
--with-system-icu --disable-jemalloc
--enable-readline && make File
"../js/src/../../configure.py", line 66
print("Creating config.status", file=sys.stderr)
^
SyntaxError: invalid syntax
It's trying to use 2.7 with 3.x syntax. `sed 's@2\.7@3.8@g' -i
../js/src/configure` will get us past that. It builds to completion, and
installs to DESTDIR, but I haven't used it yet.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] gdm does not start on recent Sysv builds
On 12/17/2019 10:17 AM, Pierre Labastie via blfs-dev wrote: Le 16/12/2019 à 21:26, Douglas R. Reno via blfs-dev a écrit : On 12/16/19 2:18 PM, Pierre Labastie via blfs-dev wrote: Le 16 déc. 2019 16:47, Xi Ruoyao via blfs-dev a écrit : On 2019-12-16 09:11 -0600, Douglas R. Reno via blfs-dev wrote: On 12/16/19 3:19 AM, Pierre Labastie via blfs-dev wrote: Hi, I had 3 working BLFS builds of Gnome desktop over Sysv, but somewhere between one week ago and now, gdm got broken and does not start anymore (begins stating, but stops with a message "Oh no ! something has gone wrong, contact a system administrator" (how helpful !). I have not been able to get useful messages from /var/log/gdm, but what I see now in the logs is that there are messages from the X server, which weren't one week ago (I think gdm was starting directly on wayland). Maybe it has something to do with this message from the log file: gnome-session-binary[1370]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files. I have no time to investigate more, because I have to leave for a few days. I'm around two days out on my SysV system. I should be able to look into it a couple days from now. I think it may be related to one of the updates I did recently. One suspect could be gnome-desktop. I don't think I updated GDM recently, but it could also be gnome-session or gnome-control-center. If I trust the message, it comes from "gnome-session-binary". I remember once I upgraded gnome-desktop then seen "Oh no" from GDM. Then I fixed that by rebuilding GDM. I've tried that, and even built a fresh system, but nothing worked. Note that I can start gnome from command line, with startx and "exec gnome-session" in .xinitrc. Hi Pierre, I've traced it down to a problem in elogind, and have begun working on a fix. elogind is only setup to read one line from the session data in /run/systemd/sessions. GNOME was using the improper behavior previously, and was fixed as part of gnome-session-3.34.2. elogind has to be adapted to read more than the first line of that file: "# This is private data. Do not parse." Won't result in a valid UID after all :-) Sure :) Thanks for investigating this. Actually, there is a PR at elogind: https://github.com/elogind/elogind/pull/142/commits/2b08527c0c939aebfd0ecd04a639cb6435c3f8ef I guess a sed should do. Note also that 241.4 is out. Looks like the currency script does not take it. Ready to address this in build tonight so...Ugh. I'm sure there is probably something shorter: sed -e '/^#include "dirent-util.h"/a#include "env-file.h"' \ -e 's/read_one_line_file(p, \&/parse_env_file(NULL, p, "UID", \&/' \ -i src/basic/cgroup-util.c :-) And I just saw the replies in book. Oh well, I went exactly literal. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Testing without python2 : dead halt at JS60.
On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev
wrote:
>On Fri, Dec 13, 2019 at 08:57:09AM +0000, DJ Lucas via blfs-dev wrote:
>> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> wrote:
>>
>> >
>> >Going forward, perhaps we need to install python3 as both python3
>> >and python, and find a way to stop python2, if it is installed,
>> >installing as python ?
>> >
>> >Maybe as simple as:
>> >
>> >1. in LFS ln -sv python3 /usr/bin/python
>> >
>> >2. in BLFS, if installign python2 :
>> > rm /usr/bin/python
>> > ln -sv python3 /usr/bin/python
>> >
>> > ??
>> >
>> >Yes, I know that upstream python has claimed that python should
>> >still be python2, but I think we're fast going to reach the point
>> >where that causes more trouble than it is worth.
>>
>> That's not exactly correct. We are at the point where the majority
>use python3. We need to get rid of python2 build instructions for
>remaining modules that are not dependencies for something else using
>python2, sed/patch the remaining packages to explicitly use
>'/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant
>with the PEP (84 IIRC) with a python->python3 symlink. The big thing is
>the "majority" of packages, though it was worded differently IIRC. Arch
>can really help here.
>>
>> >
>> >For the moment, I'm giving up on this slithering mess.
>> >
>> >Maybe I'll try creating the python symlink, or maybe it would be
>> >easier to just start banging my head agaisnt a brick wall.
>> >
>>
>> --DJ
>>
>So, I looked at Arch and they are still using python2 for JS60.
>
>Fedora's build uses raw firefoxi68, I'm reluctant to try that.
>As I said in my original post: There is an issue for
>spidermonkey68 at gnome:
> https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
>apparently waiting for firefox 68.4.0 before it is ready. That
>version of firefox should be released at the start of January.
>
>I suspect that when the new spidermonkey appears it _will_ need
>the python -> python3 symlink.
>
>In the meantime I found a patch at
>https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
>from Adelie linux, originally against 52.4. A very strange patch, I
>could not get it to apply at all, so in the end I've spent some time
>manually running seds for some obvious things (e.g. remove from
>__future__) and then attempting to manually apply the other changes.
>Of course, some of the code has changed, and I'm sure not everything
>is right.
>
>What is most odd about the patch is that the first part has (original)
>and (refactored) marks for old and new files, but much later many
>other more conventional diffs have been appended, often several for
>the same file.
>
>But when I gave it a first go, with python symlinked to python3, the
>configure immediately failed:
>
>ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
>--prefix=/usr \
>> --with-intl-api \
>> --with-system-zlib \
>> --with-system-icu \
>> --disable-jemalloc \
>> --enable-readline
> File "../js/src/../../configure.py", line 65
>print("Creating config.status", file=sys.stderr)
>^
>SyntaxError: invalid syntax
>
>A quick look at https://docs.python.org/3/whatsnew/3.0.html suggests
>that the syntax is correct. So I'm giving up on this attempt to
>find out which parts of my normal desktop still need python2.
>
I'm sorry, I didn't mean to suggest that we can completely scrub it just yet.
Mozilla specifically, has a lot of work to do yet. We could go python->python3
at this point, but it requires changes in the remaining python2 packages.
--DJ
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Testing without python2 : dead halt at JS60.
On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev
wrote:
>On Fri, Dec 13, 2019 at 08:57:09AM +0000, DJ Lucas via blfs-dev wrote:
>> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> wrote:
>>
>> >
>> >Going forward, perhaps we need to install python3 as both python3
>> >and python, and find a way to stop python2, if it is installed,
>> >installing as python ?
>> >
>> >Maybe as simple as:
>> >
>> >1. in LFS ln -sv python3 /usr/bin/python
>> >
>> >2. in BLFS, if installign python2 :
>> > rm /usr/bin/python
>> > ln -sv python3 /usr/bin/python
>> >
>> > ??
>> >
>> >Yes, I know that upstream python has claimed that python should
>> >still be python2, but I think we're fast going to reach the point
>> >where that causes more trouble than it is worth.
>>
>> That's not exactly correct. We are at the point where the majority
>use python3. We need to get rid of python2 build instructions for
>remaining modules that are not dependencies for something else using
>python2, sed/patch the remaining packages to explicitly use
>'/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant
>with the PEP (84 IIRC) with a python->python3 symlink. The big thing is
>the "majority" of packages, though it was worded differently IIRC. Arch
>can really help here.
>>
>> >
>> >For the moment, I'm giving up on this slithering mess.
>> >
>> >Maybe I'll try creating the python symlink, or maybe it would be
>> >easier to just start banging my head agaisnt a brick wall.
>> >
>>
>> --DJ
>>
>So, I looked at Arch and they are still using python2 for JS60.
>
>Fedora's build uses raw firefoxi68, I'm reluctant to try that.
>As I said in my original post: There is an issue for
>spidermonkey68 at gnome:
> https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
>apparently waiting for firefox 68.4.0 before it is ready. That
>version of firefox should be released at the start of January.
>
>I suspect that when the new spidermonkey appears it _will_ need
>the python -> python3 symlink.
>
>In the meantime I found a patch at
>https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
>from Adelie linux, originally against 52.4. A very strange patch, I
>could not get it to apply at all, so in the end I've spent some time
>manually running seds for some obvious things (e.g. remove from
>__future__) and then attempting to manually apply the other changes.
>Of course, some of the code has changed, and I'm sure not everything
>is right.
>
>What is most odd about the patch is that the first part has (original)
>and (refactored) marks for old and new files, but much later many
>other more conventional diffs have been appended, often several for
>the same file.
>
>But when I gave it a first go, with python symlinked to python3, the
>configure immediately failed:
>
>ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
>--prefix=/usr \
>> --with-intl-api \
>> --with-system-zlib \
>> --with-system-icu \
>> --disable-jemalloc \
>> --enable-readline
> File "../js/src/../../configure.py", line 65
>print("Creating config.status", file=sys.stderr)
Sorry, I missed this. Yes this is python3 syntax so something is calling
python2 explicitly.
--DJ
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Testing without python2 : dead halt at JS60.
On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev wrote: > >Going forward, perhaps we need to install python3 as both python3 >and python, and find a way to stop python2, if it is installed, >installing as python ? > >Maybe as simple as: > >1. in LFS ln -sv python3 /usr/bin/python > >2. in BLFS, if installign python2 : > rm /usr/bin/python > ln -sv python3 /usr/bin/python > > ?? > >Yes, I know that upstream python has claimed that python should >still be python2, but I think we're fast going to reach the point >where that causes more trouble than it is worth. That's not exactly correct. We are at the point where the majority use python3. We need to get rid of python2 build instructions for remaining modules that are not dependencies for something else using python2, sed/patch the remaining packages to explicitly use '/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant with the PEP (84 IIRC) with a python->python3 symlink. The big thing is the "majority" of packages, though it was worded differently IIRC. Arch can really help here. > >For the moment, I'm giving up on this slithering mess. > >Maybe I'll try creating the python symlink, or maybe it would be >easier to just start banging my head agaisnt a brick wall. > --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] blocaled-0.1 is released
On 12/8/2019 4:06 PM, Pierre Labastie via blfs-dev wrote: Hi, It is the first (beta?) release of blocaled. See https://github.com/pierre-labastie/blocaled/releases/tag/v0.1 I have also a patch for the book to use blocaled, but do not know what to do with it: - commit it: it should not hurt, I think - upload the patch to some place where it can be tried. - attach it to a mail I have been able to set up a French keyboard layout for gdm, and I have a "login screen" button in settings/locale submenu. I had a small issue I am not sure how to investigate: /var/lib/gdm/.local had been created with root owner, so that gdm (which runs as user gdm) was unable to open it. Not a big deal, since this directory is empty, except that it seemed to prevent it from displaying the French keyboard layout on screen... I had to manually change the owner to gdm, and all is fine now. Excellent news! --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] mutter broken with meson-0.52+
On 12/8/2019 2:29 PM, DJ Lucas via blfs-dev wrote: in the event that they wind up using os.path.realpath in the future Actually, it'd increase runtime slightly, but it would be better if they use realpath in the test and just excluded /proc/self/fd. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] mutter broken with meson-0.52+
On 12/8/2019 2:06 PM, Pierre Labastie via blfs-dev wrote: Le 08/12/2019 à 21:04, DJ Lucas via blfs-dev a écrit : So question, is it just "/dev/std.*"? If so, just put the test case back in meson as a regex and your should be good. meson upstream are working on it, it seems. Wait and see... They are taking it further than that. They will exclude "/dev/" according to the discussion in the bug, probably overkill, but I can't see that it matters. At any rate, fairly simple fix hopefully. Sounds like they want to cleanup the whole thing at some point. If that's the case, they may want to also exclude /proc/self/fd in the event that they wind up using os.path.realpath in the future - if for nothing else, to give a clue to whoever does wind up cleaning it up in the future. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] mutter broken with meson-0.52+
On December 8, 2019 11:52:11 AM CST, Bruce Dubbs via blfs-dev wrote: >On 12/8/19 7:33 AM, Pierre Labastie via blfs-dev wrote: > >> I did the bisection, and found that the commit which changed the >behavior in >> meson is 3db6dcb3b85. >> >> I Filed an issue[1] with meson, but they may as well tell that mutter >devs >> should change their meson.build files. >> >> For now, I suggest disabling the cogl_tests, or maybe issue this sed: >> >> sed -e 's@[./]*dev/stdout @@' \ >> -e 's@meson-private/coredata.dat @@' \ >> -i build.ninja >> >> after running meson and before running ninja. coredata.dat must also >be >> removed, because it appears to be posterior to build.ninja, so that >meson is >> run again when ninja starts, and the effect of the sed is lost... >> >> Pierre >> [1]: https://github.com/mesonbuild/meson/issues/6315 > >It is interesting that the type of redirection matters. If I do: > > meson --prefix=/usr -Dprofiler=false .. > file.log > >then stdout shows up in build.ninja. If I do: > > meson --prefix=/usr -Dprofiler=false .. 2>&1 | tee file.log > >stdout is not found in build.ninja. I guess I never saw the problem >since my scripts use tee. > >To me, the problem is definitely in meson. The output should never >change for something that bash does. > > -- Bruce > >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page So question, is it just "/dev/std.*"? If so, just put the test case back in meson as a regex and your should be good. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Firewall section changes
On 10/17/2019 11:35 AM, Bruce Dubbs via blfs-dev wrote: On 10/16/19 9:14 PM, DJ Lucas via blfs-dev wrote: So, here is draft2. Been a bit busy lately, but I finally got some time tonight to address the surrounding text. My eyes are starting to glaze over. Of note, I've separated the firewall description page from Iptables, added nftables (and its required libraries libmnl and libnftnl), and added firewalld as a frontend for both (along with the required python modules decorator and slip). I'd appreciate any feedback on the changes, especially the text changes. The only known issues off the top of my head are the generic (and likely wrong) descriptions for the utilities with firewalld - which I'll fix later as I simply forgot about them until I was reading the rendered book just now - and I'll need to add specific nf_contrack kernel configuration notes for firewalld. Rendered copies of the books are at: http://www.linuxfromscratch.org/~dj/blfs-book/ and http://www.linuxfromscratch.org/~dj/blfs-systemd/ The diff is also available if you'd like to look at it that way at: http://www.linuxfromscratch.org/~dj/firewall-changes.svnstash Also of note is the bootscript for sysv, and the patch (should be the same as the one for 0.7.1 and is priority bug upstream with a waiting PR): http://www.linuxfromscratch.org/~dj/firewalld http://www.linuxfromscratch.org/~dj/firewalld-0.7.2-builtin-1.patch I think we need to explicitly say somewhere that iptables and nftables are mutually exclusive. It may seem obvious to us, but for those new to firewalls, it may not be. Actually, they aren't. They can work in tandem. I can't think of a reason somebody would want to do that, and I cringe at the complexity of such a setup, but it is possible (note the circular dependency). They both still ultimately control netfilter in the kernel, but, I follow - for the purposes of the book, they probably should be. And, I kind of did mention this in firewalling.xml, but I can make it more prominent. Also, I would like to see package title headers use the title case of the tarball. That is firewalld, not Firewalld. I know we do this in a lot of places and are quite inconsistent. I don't know if it worthwhile going through the entire book and changing though. It wouldn't be all that difficult to do, over time, section by section seems reasonable. However, the previous rule was however the developer uses it on public websites or in documentation. For example, the title of the web page for systemd at FDO is "systemd System and Service Manager" so should be lower case. Looking at firewalld, it too should be all lowercase. Same thing for iptables and nftables. GNU Coreutils uses a capital "C." "System V Init" is an odd one that doesn't match the tarball name at all, though a lot of sites use "SysVinit." There really is no consistency upstream, so I think it is up to us. The name of the tarball is one method, always capitalizing titles is another, and using the developer's choice is a third, among others. The first of those is probably most consistent but the TOC won't be a pretty. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Firewall section changes
So, here is draft2. Been a bit busy lately, but I finally got some time tonight to address the surrounding text. My eyes are starting to glaze over. Of note, I've separated the firewall description page from Iptables, added nftables (and its required libraries libmnl and libnftnl), and added firewalld as a frontend for both (along with the required python modules decorator and slip). I'd appreciate any feedback on the changes, especially the text changes. The only known issues off the top of my head are the generic (and likely wrong) descriptions for the utilities with firewalld - which I'll fix later as I simply forgot about them until I was reading the rendered book just now - and I'll need to add specific nf_contrack kernel configuration notes for firewalld. Rendered copies of the books are at: http://www.linuxfromscratch.org/~dj/blfs-book/ and http://www.linuxfromscratch.org/~dj/blfs-systemd/ The diff is also available if you'd like to look at it that way at: http://www.linuxfromscratch.org/~dj/firewall-changes.svnstash Also of note is the bootscript for sysv, and the patch (should be the same as the one for 0.7.1 and is priority bug upstream with a waiting PR): http://www.linuxfromscratch.org/~dj/firewalld http://www.linuxfromscratch.org/~dj/firewalld-0.7.2-builtin-1.patch Thanks. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind X build order
On October 2, 2019 3:41:05 PM CDT, Ken Moffat via blfs-dev wrote: > >[37.281] (II) AMDGPU: Driver for AMD Radeon: >All GPUs supported by the amdgpu kernel driver >[37.281] (II) modesetting: Driver for Modesetting Kernel Drivers: >kms >[37.281] (++) using VT number 1 > >[37.281] (II) AMDGPU(0): [KMS] Kernel modesetting enabled. >[37.282] (WW) Falling back to old probe method for modesetting >[37.282] (WW) VGA arbiter: cannot open kernel arbiter, no >multi-card support >[37.282] (II) AMDGPU(0): Creating default Display subsection in >Screen section >"Default Screen Section" for depth/fbbpp 24/32 >[37.282] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32 >[37.282] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes >(32 bpp pixmaps) >[37.282] (==) AMDGPU(0): Default visual is TrueColor >[37.282] (==) AMDGPU(0): RGB weight 888 >[37.282] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC) >[37.282] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID >= 0x15d8) Is this an add-on card, or Mobo? Searching for that ID have best guess as an RX570. >[37.282] (II) Loading sub module "fb" >[37.282] (II) LoadModule: "fb" >[37.282] (II) Loading /usr/lib/xorg/modules/libfb.so >[37.283] (II) Module fb: vendor="X.Org Foundation" >[37.283]compiled for 1.20.5, module version = 1.0.0 >[37.283]ABI class: X.Org ANSI C Emulation, version 0.4 >[37.283] (II) Loading sub module "dri2" >[37.283] (II) LoadModule: "dri2" >[37.283] (II) Module "dri2" already built-in >[37.438] (II) Loading sub module "glamoregl" >[37.438] (II) LoadModule: "glamoregl" >[37.438] (II) Loading /usr/lib/xorg/modules/libglamoregl.so >[37.443] (II) Module glamoregl: vendor="X.Org Foundation" >[37.443]compiled for 1.20.5, module version = 1.0.1 >[37.443]ABI class: X.Org ANSI C Emulation, version 0.4 >[37.468] (II) AMDGPU(0): glamor X acceleration enabled on AMD RAVEN >(DRM 3.33.0, 5.3.1, LLVM 8.0.1) >[37.468] (II) AMDGPU(0): glamor detected, initialising EGL layer. >[37.468] (==) AMDGPU(0): TearFree property default: auto >[37.468] (==) AMDGPU(0): VariableRefresh: disabled >[37.468] (II) AMDGPU(0): KMS Pageflipping: enabled >[37.468] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section >[37.468] (II) AMDGPU(0): Output DVI-D-0 has no monitor section >[37.468] (II) AMDGPU(0): Output DisplayPort-0 has no monitor >section >[37.483] (II) AMDGPU(0): EDID for output HDMI-A-0 >[37.483] (II) AMDGPU(0): Manufacturer: ACR Model: 42e Serial#: >2215641880 >[37.483] (II) AMDGPU(0): Year: 2018 Week: 41 >[37.483] (II) AMDGPU(0): EDID Version: 1.3 >[37.483] (II) AMDGPU(0): Digital Display Input >[37.483] (II) AMDGPU(0): DFP 1.x compatible TMDS >[37.483] (II) AMDGPU(0): Max Image Size [cm]: horiz.: 52 vert.: 29 >[37.483] (II) AMDGPU(0): Gamma: 2.20 >[37.483] (II) AMDGPU(0): DPMS capabilities: Off >[37.483] (II) AMDGPU(0): Supported color encodings: RGB 4:4:4 YCrCb >4:4:4 >[37.483] (II) AMDGPU(0): First detailed timing is preferred mode >[37.483] (II) AMDGPU(0): redX: 0.633 redY: 0.340 greenX: 0.314 >greenY: 0.632 >[37.483] (II) AMDGPU(0): blueX: 0.159 blueY: 0.060 whiteX: 0.313 >whiteY: 0.329 >[37.483] (II) AMDGPU(0): Supported established timings: >[37.483] (II) AMDGPU(0): 720x400@70Hz > >(snip 'established' timings) > >[37.483] (II) AMDGPU(0): 1280x1024@75Hz >[37.483] (II) AMDGPU(0): Manufacturer's mask: 0 >[37.483] (II) AMDGPU(0): Supported standard timings: >[37.483] (II) AMDGPU(0): #0: hsize: 1920 vsize 1080 refresh: 60 >vid: 49361 >[37.483] (II) AMDGPU(0): #1: hsize: 1680 vsize 1050 refresh: 60 >vid: 179 >[37.483] (II) AMDGPU(0): #2: hsize: 1440 vsize 900 refresh: 60 >vid: 149 >[37.483] (II) AMDGPU(0): #3: hsize: 1280 vsize 1024 refresh: 60 >vid: 32897 >[37.483] (II) AMDGPU(0): #4: hsize: 1280 vsize 960 refresh: 60 >vid: 16513 >[37.483] (II) AMDGPU(0): #5: hsize: 1280 vsize 720 refresh: 60 >vid: 49281 >[37.483] (II) AMDGPU(0): Supported detailed timing: >[37.483] (II) AMDGPU(0): clock: 148.5 MHz Image Size: 509 x 286 >mm >[37.483] (II) AMDGPU(0): h_active: 1920 h_sync: 2008 h_sync_end >2052 h_blank_end 2200 h_border: 0 >[37.483] (II) AMDGPU(0): v_active: 1080 v_sync: 1084 v_sync_end >1089 v_blanking: 1125 v_border: 0 >[37.483] (II) AMDGPU(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 >H max: 83 kHz, PixClock max 175 MHz >[37.483] (II) AMDGPU(0): Serial No: T2JEE0094209 >[37.483] (II) AMDGPU(0): Monitor name: Acer K242HQL >[37.483] (II) AMDGPU(0): Supported detailed timing: >[37.483] (II) AMDGPU(0): clock: 148.5 MHz Image Size: 509 x 286 >mm >[37.483] (II) AMDGPU(0): h_active: 1920 h_sync: 2008 h_sync_end >2052 h_blank_end 2200 h_border: 0 >[37.483] (II) AMDGPU(0): v_active: 1080 v_sync: 1084
Re: [blfs-dev] xreflabel no longer working in title tags
On 9/14/2019 9:46 AM, Pierre Labastie via blfs-dev wrote: On 14/09/2019 09:25, Pierre Labastie via blfs-dev wrote: On 14/09/2019 02:32, Bruce Dubbs via blfs-dev wrote: On 9/13/19 5:52 PM, DJ Lucas via blfs-dev wrote: Subject says it all. It changed sometime between 6.2.0 and 6.3, but nobody noticed the issue on the firewall page. It read well enough I guess, though it's painfully obvious that it is wrong now. Other examples in the book work as expected. Fortunately, this is the only page in the book where this syntax was used. That's interesting. Checking, what we have is valid docbook xml. It must be something in our stylesheets. Will have a look. I've been studying those stylesheets recently... Fixed (only for sect3 titles) at revision 22141. Thank you Pierre. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xreflabel no longer working in title tags
On 9/14/2019 11:00 AM, Pierre Labastie via blfs-dev wrote: I may also have to become upstream for a fork of localed from systemd, but still waiting for a definite answer from upstream elogind). Yeah, I kind of put that on the back burner until the v243 changes are in, see if they can at least provide the needed functions in libelogind for downstream dependents. I also think we should create an LFS organization at github or gitlab to house these small software projects (make-ca, LSB-Tools, and elocaled). I personally like github, but that may only be that I'm already there and have been using it for years. I looked into it a bit back, but never went anywhere with it. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xreflabel no longer working in title tags
On 9/14/2019 10:03 AM, Bruce Dubbs via blfs-dev wrote: On 9/14/19 12:46 AM, DJ Lucas via blfs-dev wrote: On 9/13/2019 7:32 PM, Bruce Dubbs via blfs-dev wrote: On 9/13/19 5:52 PM, DJ Lucas via blfs-dev wrote: Subject says it all. It changed sometime between 6.2.0 and 6.3, but nobody noticed the issue on the firewall page. It read well enough I guess, though it's painfully obvious that it is wrong now. Other examples in the book work as expected. Fortunately, this is the only page in the book where this syntax was used. That's interesting. Checking, what we have is valid docbook xml. It must be something in our stylesheets. I'm planning on overhauling this page soon anyway, just providing an introduction and pointing to the iptables and nftables pages where the actual configuration is done and supplying the sect3 title. That would be good. Thanks. Here is a *very* preliminary patch of that work. I'd appreciate any feedback and suggestions for text/configurations. I haven't tested the changes (the additions are incomplete for the masquerading example for iptables). If anybody has done the other two examples for nftables, or has used firewalld, please post simple samples. http://www.linuxfromscratch.org/~dj/blfs-book/ http://www.linuxfromscratch.org/~dj/blfs-systemd/ http://www.linuxfromscratch.org/~dj/add-nftables.svnstash It's been a *very* long time since I looked at the firewall rules. Why are we using ppp for the interface parameters? That seems to be last century. Shouldn't it be eth+ or similar? Yeah, I thought about throwing in a udev rule for WAN/LAN ifnames but decided against it. Not that I do it all the time, but for my two dedicated firewalls, I rename the interfaces so that the configuration is explicit. That said, we don't cover it in BLFS anymore, but people do still use rp-pppoe for DSL connections. I suppose we should use eth0 and eth1, or maybe better, enforce it as strictly an example by using WAN and LAN (or similar) without any udev rule in sight. I actually like how it's done in the BusyBox example, piece by piece the best, but showing it as a script is important too. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xreflabel no longer working in title tags
On 9/13/2019 7:32 PM, Bruce Dubbs via blfs-dev wrote: On 9/13/19 5:52 PM, DJ Lucas via blfs-dev wrote: Subject says it all. It changed sometime between 6.2.0 and 6.3, but nobody noticed the issue on the firewall page. It read well enough I guess, though it's painfully obvious that it is wrong now. Other examples in the book work as expected. Fortunately, this is the only page in the book where this syntax was used. That's interesting. Checking, what we have is valid docbook xml. It must be something in our stylesheets. I'm planning on overhauling this page soon anyway, just providing an introduction and pointing to the iptables and nftables pages where the actual configuration is done and supplying the sect3 title. That would be good. Thanks. Here is a *very* preliminary patch of that work. I'd appreciate any feedback and suggestions for text/configurations. I haven't tested the changes (the additions are incomplete for the masquerading example for iptables). If anybody has done the other two examples for nftables, or has used firewalld, please post simple samples. http://www.linuxfromscratch.org/~dj/blfs-book/ http://www.linuxfromscratch.org/~dj/blfs-systemd/ http://www.linuxfromscratch.org/~dj/add-nftables.svnstash Thanks. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xreflabel no longer working in title tags
Subject says it all. It changed sometime between 6.2.0 and 6.3, but nobody noticed the issue on the firewall page. It read well enough I guess, though it's painfully obvious that it is wrong now. Other examples in the book work as expected. Fortunately, this is the only page in the book where this syntax was used. I'm planning on overhauling this page soon anyway, just providing an introduction and pointing to the iptables and nftables pages where the actual configuration is done and supplying the sect3 title. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] lsb-tools and initd-tools
On September 10, 2019 12:36:00 PM CDT, Tim Tassonis via blfs-dev wrote: >Hi all > >I noticed that initd-tools is gone from BLFS and seems to have been >replaced by lsb-tools. I also noticed that BLFS bootscripts have been >updated with tons of fixes for dependency information, so thanks for >all >the work on that! > >However, I noticed that lsb-tools is implemented in python3, which of >course is no problem for the book, as python3 is needed for meson/ninja > >in lfs already. > >My own personal problem is that my lfs/blfs-based distro does contain >initd-tools in the minimal install I use for my routers, but not >python3, and I'd like to keep it that way, for size and security >reasons >(less software means less bugs). > >So, what I wanted to ask: > >In what functional way do the new python-based install_initd and >remove_initd differ from the old, c-based ones? > >Will the old ones not be able to correctly manage the new BLFS init >scrips due to missing functionality? > >And if not, what is missing from the old ones? I would then try to add >this to initd-tools, so I can still use those. > > >Bye >Tim > >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page I added was $first and $last facilities, specifically for our use of bootscripts instead of inittab for display manager. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] remote /usr (not currently possible)
As I'm going through the BLFS-Bootscript dependencies, there are many scripts which should've have a Should-Start dependency on $remote_fs because they live in the /usr hierarchy. Things like sysstat can't exist in sysinit, no network manager because it needs dbus and dbus needs networking, etc. This used to be explicitly required in earlier variants of the FHS. While the document pays homage to the idea with static vs variable filesystems (even using /usr as an example in a chart as a static filesystem that can be remotely mounted), there is no requirement in current FHS-3.0 (it would have been exceptionally difficult to make dbus, systemd, or elogind FHS compliant under FHS-2.3). Since this requirement is no longer present, does LFS want to explicitly disallow a remote /usr mount? That is actually where we are currently, as well as almost every other distro out there -- /usr must be a local filesystem -- but it is not explicitly stated (should a note be added to LFS to this effect?). I'm reasonably certain that I already know the answer, and am proceeding locally as if I do, but I'm throwing it out there so that it was at least discussed. FYI, while LFS is fine on SysV, several changes are required to BLFS to make a remote /usr supportable again (and this is almost impossible as noted above for desktop systems, and really difficult on systemd - though I do have some ideas about netbooting lab PCs with no local HDD at all as this is actually easier for this old use case... ;-) ). --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Add localed to elogind
On 9/3/2019 2:58 PM, Pierre Labastie via blfs-dev wrote: On 03/09/2019 20:21, DJ Lucas via blfs-dev wrote: Actually, this is very easy to break systemd into individual components if you accept to have a systemd daemon as PID 1. I don't. I consider this _the_ design flaw in systemd. I actually like most of the individual components. I even have grown to like the journal which I am now forced to do without. Maybe there was a its inception, but I can't (today) see a technical reason for the current library grouping - at least not one that is inseparable as evidenced by how clean it has been to separate the needed components in eudev and elogind, and now localed - note that I did not say _easy_, but it really should've been, had it been a design goal of the project from the beginning (as was stated over and over again). There would be no purpose for eudev and elogind and it might have stopped some of the complaints in the beginning (and even a majority that linger today). There are a lot of places where this daemon is accessed through dbus (I had to remove a couple of such calls in localed, and elogind has to do much more to get rid of them, because just removing them removes too much functionality). So I think any request to have standalone daemons is doomed to failure... Anyway, on first glance, it looks great. I've done enough fresh raspbian to pretend it is UK without getting too lost. :-) I'd be a bit happier if somebody who actually needs this would be able to test as well, however. If not, I'll get a different keyboard. BTW, I haven't asked explicitly, but would it be possible that somebody else test this patch? I do think it should be split it into it's own package, or at least, make it build standalone. IOW, get the needed libsystemd parts imported back into libelogind and change from local includes to system includes (can just ifdef the includes to avoid extending meson), but we should try to avoid another reciprocal dependency if possible. May be a bit of work, I can do that part if you like, but it should be doable. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Add localed to elogind
On September 3, 2019 11:45:06 AM CDT, Pierre Labastie via blfs-dev wrote: >On 02/09/2019 23:05, Pierre Labastie via blfs-dev wrote: >> Hi, >> I'm coming back to "how to fix gdm". What we have now is a hack, that >allows >> setting the keyboard layout for gdm at compile time, but prevents >being able >> to set it and other properties of gdm in gnome-control-center (no >"login >> screen" button). >> >> Gnome-shell, gnome-control-center, and gnome-setting-daemons insist >on having >> the localed daemon to do the job, so it might be a better idea to >install it. >> >> localed is a small daemon, and there is not much to add (to port from >the >> systemd source, exactly) to elogind to have this daemon on our >system. > > >I've made a patch and uploaded it to >http://www.linuxfromscratch.org/~pierre/elogind-241.3-add_localed-2.patch > >Apply it to elogind-241.3. Build elogind with instructions as in the >book. > >Then (re)build gnome-shell without the "sed", and gdm without the >"cat", >otherwise as per the book instructions. > >You may have to ensure that dbus is running (it was on my machine), >then issue: >localectl set-x11-keymap fr >(this will create or amend /etc/X11/xorg.conf.d/00-keyboard.conf) > >Obviously, you have to change the "fr" part to something else for >another >keyboard layout, (for example gb or de) > >then restart in runlevel 5: >- the keyboard in gdm is "fr" >- there is a "login screen" in gnome settings "region and language", >and it >can be clicked (it asks then for "root" password), and you can change >the >login screen settings (not only the keyboard). > >The patch is not finished yet, because it does not install the man >pages for >localectl and localed. But the executables seem to be ok. > >I wonder whether this should be sent to upstream elogind, or made as an >independent project. > >Actually, I wonder whether it couldn't be good to group eudev, elogind, >and >localed into one package (datetimed could be useful too). But I do not >know of >a proper place to discuss that... I may start at elogind. > Nice! That would be the right people to bring it to. Realistically, I'd like to see systemd folks take it all back and see build of individual components in the original tree, but suppose that's a dream for now. Honestly, I don't know that anybody has approached them with it. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On September 1, 2019 3:09:29 AM CDT, Pierre Labastie via blfs-dev wrote: >On 31/08/2019 21:12, DJ Lucas via blfs-dev wrote: >> >> >> On 8/31/2019 12:25 PM, Pierre Labastie via blfs-dev wrote: >>> On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: >>>> I failed. Either I misused jhalfs or it has a bug. I got some >"Error 2" from >>>> make and was able to "fix" some of them. But at last I can't >continue >>>> anymore. >>>> >>> At which stage did it fail? make in the jhalfs dir or make in >packages? >>> I'm sorry about the doc. I do not work much on it. Roger Koehler >gave the >>> necessary bits. I do not know what to add without knowing where it >failed. >>> >>> Pierre > >It is very important for me to get some feedback, so thanks for >sharing: > >> I have the same issues (I think just not breaking it up into parts). >The sgml >> stuff all fails when adding catalogs, these must be edited prior to >running, >> killing off the destdir catalogs, otherwise you will need to edit >> /etc/sgml/catalog.cat before proceeding. Another thing is that binary >texlive >> probably needs to be installed to avoid editing files that depend on >it >> because we do not have a concept of dependencies for command blocks >in the >> book. I've taken to install texlive manually. That said, blfs-tool >has come a >> long long way. Looking good. In addition to the list you posted >above, I have >> the following: >> >> GTK2 and GTK3: the commands to update the iconcache and db should be >removed >> from the DESTDIR install >> QT5: set QT5PREFIX and required configuration changes if you want to >install >> into /usr >> Postfix: this was mentioned, but to be a bit more clear, make sure >you have >> your link and C args in there for rebuilding the makefile >> >> Even with this number of issues, I have to congratulate you on the >work you've >> done. A very large portion of the book can be built using it. Yes, >there are >> some issues, some of these could be addressed in the book source >while staying >> on db4.5, but the tools have come a long, long way. > >Thanks a lot. I'm amazed you keep talking about destdir installs in >blfs >tools: there is no possibility for that, is there? Oh, I see, you use >the >packInstall.sh for dpkg or pacman, don't you? I've never tested that, I >use >porg. I even believed there was no way to use destdir installs in blfs >tools, >because some directories have to be created before some instructions >are run. > >Concerning texlive, the binary build could be added if you request it, >but for >texlive, the build time is not very long compared to the download time >anyway, >so I always install texlive from source. > >Normally, now, all commands that depend on texlive or doxygen are >commented >out as being remap='doc' instructions, so there are no circular >dependencies >for those. Scripts need to be edited to use doxygen and/or texlive >instead >(uncomment the corresponding instructions). > >Pierre >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Then I am doing something wrong. I'll go back and check it out and report back. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Texlive extension to extrapaths.sh
Is there a reason to use extrapaths.sh instead of its own texlive.sh? --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 8/31/2019 12:25 PM, Pierre Labastie via blfs-dev wrote: On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote: On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? -- Bruce It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use jhalfs correctly and my 16-core workstation will work fine. But I can't guarantee any success. If you need anything, please tell me. I think a full blfs can be built by editing at most 30 scripts, most notably: I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" from make and was able to "fix" some of them. But at last I can't continue anymore. At which stage did it fail? make in the jhalfs dir or make in packages? I'm sorry about the doc. I do not work much on it. Roger Koehler gave the necessary bits. I do not know what to add without knowing where it failed. Pierre I have the same issues (I think just not breaking it up into parts). The sgml stuff all fails when adding catalogs, these must be edited prior to running, killing off the destdir catalogs, otherwise you will need to edit /etc/sgml/catalog.cat before proceeding. Another thing is that binary texlive probably needs to be installed to avoid editing files that depend on it because we do not have a concept of dependencies for command blocks in the book. I've taken to install texlive manually. That said, blfs-tool has come a long long way. Looking good. In addition to the list you posted above, I have the following: GTK2 and GTK3: the commands to update the iconcache and db should be removed from the DESTDIR install QT5: set QT5PREFIX and required configuration changes if you want to install into /usr Postfix: this was mentioned, but to be a bit more clear, make sure you have your link and C args in there for rebuilding the makefile Even with this number of issues, I have to congratulate you on the work you've done. A very large portion of the book can be built using it. Yes, there are some issues, some of these could be addressed in the book source while staying on db4.5, but the tools have come a long, long way. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Where are we with respect to keyboard settings in gdm (elogind book)
On 8/29/2019 3:51 PM, Pierre Labastie via blfs-dev wrote: Just about the FHS (3.0): localtime is not even mentioned in the files belonging to /etc, and all the mentioned files may be symlinks. SO I do not think there is any violation here. Logging is more of a concern. Thank you for looking. I was actually referring to depending on something in /usr before /usr is available. But that's not actually true. I didn't think about it until after I sent that message. Only userspace tools depend on the symlink, the logged time for the first two bootscripts might be off by $UTC_OFFSET hours, but this doesn't affect communication to the hardware clock, and again, I had accounted for that. If it's not there currently, I have stiill have my original rc from before the bootscript rewrite if we need to figure it out how to handle the sysinit log again, but I'm reasonably sure it's there already. It's good, no note required. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Where are we with respect to keyboard settings in gdm (elogind book)
On 8/29/2019 12:30 PM, Bruce Dubbs via blfs-dev wrote: I'm going to change /etc/localtime to a symlink. The reason we wanted the time correct without /usr mounted was to have the timestamp in the logs correct. I'm not certain that was the only reason, but I don't have time right now to look. Please consider FHS as well. If /usr is a separate mount, even if a local filesystem, then it is always mounted after the $time facility is started (udev) and the symlink is to /usr. I'm not sure it matters, as it's not dependent, it's just an offset, but wanted to drop a note quick to make sure it is considered. I actually thought I had accounted for that in the logging code way back in 2012 but I might be mistaken. I think it probably is fine, but I am unable to verify right this second. If nothing else, just a note about it in LFS. Maybe just my opinion, but I've always viewed LFS as the teaching book and, hence, far more important to be accurate WRT specs than in BLFS where, while still important, we have some leeway WRT functionality (as much as all other distros do anyway). We've still got a couple of days to add a note if needs be. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Any minimal working .xinitrc for rootless X on elogind ?
On 8/27/2019 2:41 PM, Ken Moffat via blfs-dev wrote: However, I've apparently built all the infrastructure for what is currently in the book (except that I want to run fluxbox rather than twm, which I did not build). So, beforeI rip elogind out of my builds, can anyone please offer .xinitrc scripts (hopefully, minimal: mine are anything but) which work with rootless X using elogind, plus a note of which video driver (and I suppose input, i.e. full libinput or just evdev) is being used ? On both a Radeon 5400 and GeForce 210 (218), I was starting with only defaults, no .xinitrc. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Any minimal working .xinitrc for rootless X on elogind ?
On 8/27/2019 6:17 PM, Ken Moffat via blfs-dev wrote: _XSERVTransmkdir: ERROR: euid != 0,directory/tmp/.X11-unix will not be created. Does this directory exist? It should be in createfiles configuration. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , knowledge, explanations and solution
On 8/26/2019 7:22 PM, Jean-Marc Pigeon via blfs-dev wrote: The solution, is to "hardcode" the fact glibc is gnu hash compatible by inserting "Provides: rtld(GNU_HASH)" within glibc spec file (a simple marker). Not exactly. I think you've misunderstood my suggestion here. Let me try to explain the two parts separately. The 'solution' above was RedHat's (and later SUSE's) solution to account for a change in glibc packages after the new hash functionality became available. I'm a bit fuzzy on this part, but I believe it was binutils-2.17 that provided the necessary changes in the linker to use the new functionality in glibc (I believe it was Ken who unearthed that bit). Ultimately, RH could not place an unneeded dependency on a particular version of binutils when you really need files from glibc that were built against that version of binutils, (why they didn't just increment the build number is beyond me, maybe it was a split package at the time or they were dependent on the soname rather than a particular package) so the provides was added in RH/SUSE specs to make the requirements in downstream packages explicitly require this functionality if needed (which probably should be gone so many years later). Your packages never had that split so likely shouldn't add that provides workaround (unless you aim to be able to use RH/SUSE specs without modification, but then why write your own specs?). My suggestion for you to add the above was provided strictly as a workaround to _avoid_ rebuilding LO and keep your existing package (since it takes forever to build). The problem here was always in LO. If you are already going through the trouble of rebuilding LO to account for the other downloads, then you should probably leave the glibc spec alone and remove the rtld requirement from your LO spec(s) so that it uses just your package names and versions (no need to litter the RPM DB with additional provides data). I might be oversimplifying things a bit here, I haven't seen your spec for LO, and it could be some automated thing that I'm unaware of, but that's what I was trying to guide you to discover on your own in my earlier message - precisely why I told you to "provide it" rather than the above verbatim for that matter - which I actually wound up removing from my first message as I though it too much hand-holding. Make you work for it, just a little, and you'll remember for life. :-) Does that make more sense? And that's not to say that what you've done will not work. In fact, it should have made your existing LO rpm installable without any rebuild or need to force it to install, and will clearly meet the requirements for your new rpm if you've still not modified the dependencies. All that said, LFS and BLFS is about learning, but only to a certain point (it has to be usable as well). There is nothing inherently wrong with the above workaround other than it most likely being unnecessary (and a bit unclean IMO) -- clearly RedHat and SUSE, who should be the experts, think it's fine -- but I wanted to take the time to make sure that you understand that the original error was not in your decision to omit the provides in your glibc spec file, but the depends lines in LO's spec. BTW, would you mind sharing both? It might be helpful for somebody else later on and will most definitely answer my remaining question about "some automated thing" above. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On August 26, 2019 7:31:54 AM CDT, Jean-Marc Pigeon via blfs-dev wrote: >Hello guys (Ken, DJ and Pierre), > >Thanks to have bring your "pint of brain juice". > >On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: >> On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: >>> Hello guys (and girls). >>> >>> I need your wisdom... Let's share a pint of brain juice. >>> Here's the drill. >>> >>> context: >>> - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) >>> - I am able to build libreoffice-6.3.0.4 with all >>>bells and whistles >>> (lets assume I didn't really goofed with the book directives). >>> >>> I am using zypper + rpm as my own packages management toolkit >>> and rpm say: >>> >>> Error: Failed dependencies: >>> rtld(GNU_HASH) is needed by >libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 >>> >> >> rtld is the run time linker of glibc (the loader of .so libraries). >It is >> certainly installed on your system, otherwise nothing could run >(unless you >> have built everything statically). So, for some reason, it seems that >glibc, >> or part of glibc, is not known to rpm (I do not know much about rpm) >on your >> system. But in that case, it is amazing that you haven't seen that >before. >> Could it be that you have taken an rpm spec file from some distro, >and that >> you have omitted to remove some dep when editing it? > >About the drill, keep in mind, >- the all smash (the >800 packages, glibc included) are > recompiled every time. > this means discrepancies between glibc and compiled binaries > seems to me hardly plausible. >- The book directives are used within the "specs file" (build and > install sequences), trying my best not to diverge from book directives > (using book patches, configure paramaters, etc.) Please see the > rpm specs file as MY shell/tool to build LFS+BLFS again and again. >- In the building sequences the only package with this rtld report > is libreoffice. >- libreoffice (as fare I can say) components, once installed, are > nicely working. >- I am not building statically and not using libtools. > >- May be I was not specific enough in my original email, RTLD detection > show up in the RPM last building phase (the summary phase, saying, > here is the list of libraries needed when you will install packages) > and (obviously) it become a problem when RPM is used to install > the libroffice package > > >My worry (Hoping to be paranoiac) and this concern the book: > >- When rpm is assembling all files (binaries, scripts, conf, > scripts) to do packaging, it scan all added files tracking > what is needed (ex: python, shell (zsh,...), shared libraries, etc.) > and report it in the summary. > This means RPM is detecting something "unexpected". > Possibly, it it is configured to find a separate rtld instead of a glibc package. Doesn't really change the answer above. >- Libreoffice Book directives are such, that 77 components are > added/downloaded within external/tarballs directory, this > between the configure phase and the build phase. > (please could you confirm this fact from your side). > We (the book) have no real control/say about those components > (version, contents, function). > >- It can not be excluded, there a real binary (trojan, virus,...) > included within the downloaded files. And this binary show > up on RPM scanning phase. Obviously libreoffice, in such case, > is fully functional. > >- That why, I am trying to track down the origin of the RTLD, >because if we have an embedded binary "expecting" a >usual/common/old glibc to be fully operational, then >RPM would have this behaviour. That provides is in current Suse glibc rpms. I didn't check others (though should've I suppose). > > - Please correct me if wrong, but current book directives >have no provision to detect such situation. > > - So fare, I am not successful to track down the issue to >a single file, even worth, the "trouble" seems to be in every >libreoffice program. > >Do we agree?, libreoffice is the perfect candidate to be >"adjusted" to carry nasty functionality? > >So guys, please tell me the rtld problem is an obvious/plain one >and I am just a crazy paranoid. It didn't just magically show up, something requested it. I suspect that this is a shipped spec, however. Again, this doesn't change the necessary fix. Grep through the entire source tree after the build, see if you can find that string. If so, create a patch and a patch with the patch in it for the LO source (and commands to apply during the build). --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/25/2019 7:41 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. Goodnight. Thanks for the assistance. I think ultimately we go back to setuid Xorg for now. We'll see what happens from there. Well, I won't oppose that, although I do not like it: on this system, apart from the keyboard issue with gdm, I have all DE's working (not tested thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. For the permissions: as soon a logind is started it adds some ACL's to /dev/dri/card0 for the logged in user (even if logged in on the console, I think): for example: $ getfacl /dev/dri/card0 # file: dev/dri/card0 # owner: root # group: video user::rw- user:pierre:rw- group::rw- mask::rw- other::--- So no need to belong to the video group. Note that the ACL is not changed if you do 'su - new-user'. OTOH, for the /dev/input/* files, their permissions do not seem to be changed. But I can tell you that I have functional keyboard and mouse, without belonging to the input group. Yes, the input devices get associated with the seat. I'm in the same boat. It has and does work perfectly for a regular user with only primary group membership. I am unable to figure out why the polkit mechanism is not working for some. My point is that we've always had Xorg suid in the SysV book. While I am reluctant to do so, we haven't been successful in finding whatever it is that I've missed in elogind's introduction to the book, and I just don't think this issue should put any more strain on the release, as it is not a regression. There is a less desirable method for handling suid bit for the Xorg bin. We could add a note with instructions for the suid bit in the event that there is a problem on your particular build. For the book, I lean towards just putting back the suid bit as it was, as I place a higher value on the consistency between different builds, but that is strictly my opinion. While I don't particularly like either suggestion, I suppose all are worth consideration. OTOH, dropping the elogind and mountcgroupfs bootscripts absolutely should happen before release. The PAM configuration works just fine in both user sessions and DM sessions (regardless of the seat association); the scripts just add needless complexity. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/25/2019 11:26 AM, Ken Moffat via blfs-dev wrote: My _current_ understanding is that with the whole elogind stack, polkit provides the authorization for /dev/input/ but only for admin users, and an admin user appears to mean anybody in the wheel group. To expand on Pierre's answer a bit, ultimately, the needed input devices get tied to the user's "seat" and that is how an unprivileged user can access the device. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. Goodnight. Thanks for the assistance. I think ultimately we go back to setuid Xorg for now. We'll see what happens from there. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 8:14 PM, Ken Moffat via blfs-dev wrote: On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy ĸen But I do think we might be getting someplace. Did you log your elogind build? If so, what was the meson summary output? Here is what I had: Message: elogind 241.3 split /usr:true split bin-sbin:true prefix directory: /usr rootprefix directory: / sysconf directory: /etc include directory: /usr/include lib directory: /usr/lib rootlib directory: /lib rootexeclib dir: /lib/elogind PAM modules directory: /lib/security PAM configuration directory: /etc/pam.d modprobe.d directory: /lib/modprobe.d D-Bus policy directory:/etc/dbus-1/system.d D-Bus session directory: /usr/share/dbus-1/services D-Bus system directory:/usr/share/dbus-1/system-services bash completions directory: /usr/share/bash-completion/completions zsh completions directory: /usr/share/zsh/site-functions TTY GID: 5 maximum system UID:999 maximum system GID:999 /dev/kvm access mode: 0666 render group access mode: 0666 nobody user name: nobody nobody group name: nobody default KillUserProcesses setting: true enabled features: PAM, SMACK, ACL, polkit, dbus, man pages, utmp disabled features: AUDIT, SELinux, legacy pkla, glib, html pages, man page indices, debug elogind, debug hashmap, debug mmap cache, debug siphash, valgrind, trace logging -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 8:14 PM, Ken Moffat via blfs-dev wrote: On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy ĸen Okay, so that file should be installed by elogind: dj@lfsdt2 [ /sources/elogind-241.3/build ]$ ls Dest/usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 4:38 PM, Ken Moffat via blfs-dev wrote: Assuming that the reply to my earlier post (should I be in the input group?) is 'no', can somebody please spare some time to explain how authorisation via polkit (which I think is the intended route to gaining access to /dev/input/event*) is supposed to work ? I've built polkit with the patch for elogind. Both dbus and elogind have been started. First question: should polkitd be running (i.e. visible in ps aux) or does it only fire up to respond to dbus, and then shut down again ? Second question: how is the user who started xorg authenticated by polkitd ? Looking at the man pages, all rules files in /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d are processed in lexical order (in the event of a tie, the file in /etc is processed first). But on this completed system I only have three files in those two directories: /etc/polkit/rules.d/50-default-rules which seems to be checking if admin users are in the wheel group, and in /usr/share/polkit-1/rules.d I have org.freedesktop.NetworkManager.rules and org.gtk.vfs.file-operations.rules from building those packages at a later stage. I don't see anything that would cause polkitd to grant access to me via elogind. At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/18/2019 12:05 AM, DJ Lucas via blfs-dev wrote: On 8/17/2019 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: I ran into a bit of a problem when starting Xorg. It came up but I had no mouse or keyboard input. There was also a problem finding Xorg.0.log to see what was happening. It is in ~/.local/share/xorg/Xorg.0.log. That is documented in the Testing and Configuration section for systemd. I will change it so it is reflected in both books now that we are using elogind. I had not started dbus or elogind. After starting those, the xorg input still did not work. I then rebooted and the mouse and keyboard worked fine. I think a logout and login may have been sufficient, but I'm not sure. I'm not sure how to address this. It would only be a one-time issue. Should we recommend a reboot before starting xorg for the first time? logout/in? That's usually when I reboot from chroot for the first time. I'm unsure yet whether we can rid ourselves of mountcgroupfs and elogind bootscripts. Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Cool! That's second confirmation. I won't comment on whether we should rid ourselves of them this close to release. Sorry I wasn't able to get back to it earlier. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. This would hold true for me as well. I build through Xorg in chroot, then reboot and use a text mode browser to continue, and my results are as yours. Alternatively, the problem might be with non-kms video displays such as nvidia. I was thinking that since your last message. I got fixated on the bootscripts and went off on a tangent that I simply couldn't let go of. I do that sometimes, a lot actually. I've managed to put it aside, but I'm still itching to get back to it (I didn't trap a couple of unforeseen errors and it will require some minor refactoring to truly be distro agnostic). That's why I like the long goals of the project. I know I said I'd do this last week, but I'm going to acquire a lower level nVidia card tomorrow and see if I fare the same as Bruce. I know we are functional now, thanks to everyone's attention on this, and that we can proceed now. I feel better about that, but I want to put these lingering questions (Xorg log) to bed before release. --DJ So this was also a non-starter for me. It just worked out of the box with Nouveau driver on an older build. For reference, console output is from an SSH session for simplicity (as dlcuas is not my regular user): dlucas@lfsdt2 [ ~ ]$ groups dlucas dlucas@lfsdt2 [ ~ ]$ ls -l /var/log/Xorg.0.log -rw-r--r-- 1 root dlucas 34375 Aug 24 16:36 /var/log/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ grep EE /var/log/Xorg.0.log [ 115.703] Current Operating System: Linux lfsdt2 5.1.3 #1 SMP PREEMPT Tue May 21 19:34:09 CDT 2019 x86_64 (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 115.712] (EE) Failed to load module "nv" (module does not exist, 0) [ 115.713] (EE) Failed to load module "vesa" (module does not exist, 0) [ 115.716] (EE) [drm] Failed to open DRM device for (null): -22 [ 115.803] (II) Initializing extension MIT-SCREEN-SAVER dlucas@lfsdt2 [ ~ ]$ grep nouveau /var/log/Xorg.0.log [ 115.712] (==) Matched nouveau as autoconfigured driver 0 [ 115.712] (II) LoadModule: "nouveau" [ 115.712] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [ 115.712] (II) Module nouveau: vendor="X.Org Foundation" [ 115.715] (II) [drm] nouveau interface version: 1.3.1 [ 115.802] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau [ 115.802] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau [ 115.830] (II) AIGLX: Loaded and initialized nouveau The full log is at: http://www.linuxfromscratch.org/~dj/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ ls -l /usr/bin/Xorg -rwxr-xr-x 1 root root 273 Jun 1 09:43 /usr/bin/Xorg dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg.wrap -rwsr-xr-x 1 root root 30696 Jun 1 09:43 /usr/libexec/Xorg.wrap dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg -rwxr-xr-x 1 root root 18121256 Jun 1 09:43 /usr/libexec/Xorg root [ /home/dj ]# lspci | grep -i nvidia 07:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 07:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) So, at at this point, I'm ready to throw my hands up. Failing somebody else digging though everything that's been posted thus far, I'm good with jus
Re: [blfs-dev] More data on elogind
On August 19, 2019 7:13:45 PM CDT, Ken Moffat via blfs-dev wrote: >On Tue, Aug 20, 2019 at 12:54:07AM +0100, Ken Moffat via blfs-dev >wrote: >> On Tue, Aug 20, 2019 at 12:49:48AM +0100, Ken Moffat via blfs-dev >wrote: >> > So it appears that I have two problems with elogind: >> > >> > I. Somethng apparently specific to me (perhaps running the build as >> >root) where despite NOT having the setuid install enabled, it >> >still installed as mode 4755. To be investigated later. >> > > >Indeed, it is building as root which causes suid. I've just run, as >root, > >./configure --prefix=/opt/X11 --with-xkb-output=/var/lib/xkb >--enable-glamor --enable-suid-wrapper --disable-systemd-logind && >make -j8 && make install > >which gave me > >-rwsr-xr-x 1 root root 18120152 Aug 20 00:57 Xorg >-rwsr-xr-x 1 root root29432 Aug 20 00:57 Xorg.wrap > >Repeated, using >./configure --prefix=/opt/X11 --with-xkb-output=/var/lib/xkb \ > --enable-glamor --disable-install-setuid --enable-suid-wrapper \ > --disable-systemd-logind > >and I got the result I had originally wanted: > >-rwxr-xr-x 1 root root 18120168 Aug 20 01:01 Xorg >-rwsr-xr-x 1 root root29432 Aug 20 01:01 Xorg.wrap > >Unfortunately, since I don't seem to be able to to run it without >setuid, I'm not a lot further forward. > >ĸen >-- >Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. >I can do the rite of k'zakra, I know the secrets of h'ragna, I can >ha'lk my g'rakha correctly ... I am a dwarf > Captain Carrot Ironfoundersson (in The Fifth Elephant) >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page I've got my hands on both a laptop with Intel and was graciously offered to borrow a 1070 today. I'll see if my existing build works with the 1070 first and start on the laptop. Any idea what firmware is needed for nouvou? --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On August 18, 2019 12:20:37 PM CDT, Ken Moffat via blfs-dev wrote: >On Sun, Aug 18, 2019 at 05:28:01AM +0000, DJ Lucas via blfs-dev wrote: >> >> >> On 8/17/2019 11:48 PM, Bruce Dubbs via blfs-dev wrote: >> > I don't know how you can write to /var/log without >> > $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned >by >> > root. Are you logging in as root? >> It's policykit, but I haven't figured out just how/where yet. The log >file >> with my test user is /var/log/Xorg.0.log root:dlucas 0644. >> >> --DJ >> >Mine is root:users i.e. my main group. > >ĸen >-- >Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. >I can do the rite of k'zakra, I know the secrets of h'ragna, I can >ha'lk my g'rakha correctly ... I am a dwarf > Captain Carrot Ironfoundersson (in The Fifth Elephant) >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Yes, that's consistent then. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/2019 11:48 PM, Bruce Dubbs via blfs-dev wrote: I don't know how you can write to /var/log without $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned by root. Are you logging in as root? It's policykit, but I haven't figured out just how/where yet. The log file with my test user is /var/log/Xorg.0.log root:dlucas 0644. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/2019 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: I ran into a bit of a problem when starting Xorg. It came up but I had no mouse or keyboard input. There was also a problem finding Xorg.0.log to see what was happening. It is in ~/.local/share/xorg/Xorg.0.log. That is documented in the Testing and Configuration section for systemd. I will change it so it is reflected in both books now that we are using elogind. I had not started dbus or elogind. After starting those, the xorg input still did not work. I then rebooted and the mouse and keyboard worked fine. I think a logout and login may have been sufficient, but I'm not sure. I'm not sure how to address this. It would only be a one-time issue. Should we recommend a reboot before starting xorg for the first time? logout/in? That's usually when I reboot from chroot for the first time. I'm unsure yet whether we can rid ourselves of mountcgroupfs and elogind bootscripts. Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Cool! That's second confirmation. I won't comment on whether we should rid ourselves of them this close to release. Sorry I wasn't able to get back to it earlier. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. This would hold true for me as well. I build through Xorg in chroot, then reboot and use a text mode browser to continue, and my results are as yours. Alternatively, the problem might be with non-kms video displays such as nvidia. I was thinking that since your last message. I got fixated on the bootscripts and went off on a tangent that I simply couldn't let go of. I do that sometimes, a lot actually. I've managed to put it aside, but I'm still itching to get back to it (I didn't trap a couple of unforeseen errors and it will require some minor refactoring to truly be distro agnostic). That's why I like the long goals of the project. I know I said I'd do this last week, but I'm going to acquire a lower level nVidia card tomorrow and see if I fare the same as Bruce. I know we are functional now, thanks to everyone's attention on this, and that we can proceed now. I feel better about that, but I want to put these lingering questions (Xorg log) to bed before release. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: >I've just completed xorg on a new blfs-9.0 SysV build. Here are some >observations. > >I used Pierre's build order that he posted some time ago. I've listed >that below with some modifications. The asterisks indicate that the >package was installed, the dash indicates it was skipped. The indented > >entries show packages I installed that were not in the jhalfs list. > >Overall I liked the generated list as it made the order much easier to >follow. > >I ran into a bit of a problem when starting Xorg. It came up but I had > >no mouse or keyboard input. There was also a problem finding >Xorg.0.log >to see what was happening. It is in ~/.local/share/xorg/Xorg.0.log. >That is documented in the Testing and Configuration section for >systemd. > I will change it so it is reflected in both books now that we are >using elogind. > >I had not started dbus or elogind. After starting those, the xorg >input >still did not work. I then rebooted and the mouse and keyboard worked >fine. I think a logout and login may have been sufficient, but I'm not > >sure. I'm not sure how to address this. It would only be a one-time >issue. Should we recommend a reboot before starting xorg for the first > >time? logout/in? That's usually when I reboot from chroot for the first time. I'm unsure yet whether we can rid ourselves of mountcgroupfs and elogind bootscripts. I got busy and then off on my little tangent and forgot about it. Pierre said it is possible. ISTR, that if PAM was right, and cgroups are already mounted by the kernel, then a simple logout should have worked. I'll try to get to a build this weekend and reboot before installing elogind and see if this holds true. I'm also curious about the location of the log file. Is this true in your build after elogind is running? > >We probably need to adjust some dependencies. shadow really should >have >cracklib. pam should probably have a shadow as a recommended runtime >dependency. > I agree, but not quite as I understand the above. Shadow shouldn't have a dependency on cracklib directly, unless PAM is not being used, but runtime might not be sufficient because of how/when we do the PAM config. I'm not sure if blfs-tool takes into account runtime dependencies when choosing order for later deps. >The xcb-util-* files are only needed for qt, but it's easy to do them >in >the book order. I thought something used them before QT, but I've no idea what. Only libxcb is required for Xorg itself AFAIK. > >libva has a circular dependency with mesa. > >make-ca probably should have wget as a recommended runtime dependency. make-ca hasn't used wget for a long time. As soon as OpenSSL was in LFS, I used 'openssl sconnect' specifically to avoid any circular dependency there. As Douglas mentioned, getting the tarball at that point is the issue. The example configuration for the additional certs is just that, an example. I thought I had made it clear enough in the book. Suggestions for better presentation would be much appreciated. That said, I'd still like to see both of those moved into LFS. That would make LFS have zero dependency on the host system (that'd make the 'self hosted' claim really complete in my mind) -- as in, dump a backup to bare metal, you could boot immediately and begin working towards a final system (or even a rebuild) without a 'host system' in sight. Wget would still have to make an appearance in BLFS, however, for the additional deps. I'd like to revisit that after release. > >I do not know of a way to get jhalfs to add in drivers. Perhaps an >output line to tell the user to install the appropriate drivers for the > >system HW would be sufficient. Personally, I just build them all, but I don't know how blfs-tool could handle it (as in, I do not understand it's capabilities, and I'm afraid that asking for another special case is a really big ask). A simple message to the user might be best. Of note, I'd like to add qxl at some point to handle qemu/kvm video -- again, after release. > >I'd like to get some additional opinions about these issues. > Hope those are at least somewhat useful. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Version 2019-08-09 ImageMagick-7.0.8-27 -> 0.8-59
On August 10, 2019 8:03:22 AM CDT, Jean-Marc Pigeon via blfs-dev wrote: >Hello, > >Trying to have all my BLFS up to date ready for the nextfreeze. > >Notice ImageMagick-7.0.8-27 can not be downloaded anymore... > >According >https://www.imagemagick.org/download/releases/ >directory contents. > >the last release is 0.8-59 > >0.8-27 just vanished... Yeah, that's typical of IM. Lots of issues that package. There is a note on the page to use the BLFS mirrors or try the latest. We usually just update right before release. Not much can be done with IM. It's in the PCC on book though, so it doesn't get forgotten. Did you use 59? --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Kernel configuration for elogind
On 8/4/2019 9:26 AM, Pierre Labastie via blfs-dev wrote: t would be useful. Concerning cgroup v2, "man cgroups" tells: "Note that on many modern systems, systemd(1) automatically mounts the cgroup2 filesystem at /sys/fs/cgroup/unified during the boot process". According to what I see, elogind does that too. Well, that is definitely new functionality from when I first started on it then. One of the first questions was if this and that exist in the paths mentioned when troubleshooting. If both cgroups mounts are handled automatically, then let's drop mountcgroupfs. I'll be able to reboot in an hour or two on a completed system and do the secondary confirmation for you, plus it'll give me a quick test of new scripts. What do you think about the elogind scirpt? Drop it? I do not know if the cgroup fallback is true for elogind, but would expect so since it's from the same codebase (have to test with a kernel that is not prepared for cgroups, but even so, I suspect the only lost functionality is the quick cleanup of user processes). --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Kernel configuration for elogind
On 8/2/2019 3:12 PM, Pierre Labastie via blfs-dev wrote: On 02/08/2019 17:23, Ken Moffat via blfs-dev wrote: On Fri, Aug 02, 2019 at 11:05:02AM +0200, Pierre Labastie via blfs-dev wrote: On 02/08/2019 04:54, Ken Moffat via blfs-dev wrote: However, I had a bit of fun and games getting mountcgroupfs to I'd got CONFIG_CGROUPS CONFIG_INOTIFY_USER and CONFIG_FHANDLE [...] CONFIG_MEMCFG=Y CONFIG_CGROUP_RDMA=Y CONFIG_CGROUP_DEVICE=y Rebooted, and that was good enough. The question is, do I actually _need_ all of these ? From my investigations, no... And the whole mountcgroupfs bootscript can be omitted, because elogind takes care of mounting those. OTOH, my investigations are limited to using startx with the default xinit clients... I mentioned this error (with less details) in the "xorg failure" thread. If no CONFIG_CGROUP_XXX is selected, the command for mounting the v1 cgroup fs returns an error, and the command for creating the "unified" dir fails too, because the fs is not mounted. Actually, from man cgroups(7), it is said that: "Note that on many systems, the v1 controllers are automatically mounted under /sys/fs/cgroup; in particular, systemd(1) automatically creates such mount points." Now, the question is whether elogind does those mounts too. But one thing is sure: without the mountcgroupfs script, whether or not some CONFIG_CGROUP_XXX is defined, Xorg runs. Pierre Hmm, I thought it was all getting clearer, and that when I could find time to rebuild the kernel a few times I would find out how many of those are necessary. But running a DM is not something I've done for ages (although I recall that sddm shutdowns were always messy because the messages were on a different tty). I guess I might as well check which options are necessary for the mountcgroupfs script. I think we'd better check whether mountcgroupfs is needed at all. elogind seems to do most of what is in this script. Had time to look at this tonight. Suppose v1 cgroups will work alone (I was not aware that they were mounted automatically - haven't actually verified this yet, but will take your word for it). This was not the case at 238 at least. First question when asking for help was whether cgroups were mounted correctly, following a couple of examples to test that. Unfortunately, the only thing I see in the changes lists is from 235: "Starting elogind will no longer crash if the underlying system uses legacy or hybrid cgroups." -- which was after I started testing with it. I ensured that both are mounted correctly. Technically, even the elogind script isn't necessary anymore if PAM files are setup correctly, a user login will trigger elogind to start, but obviously, login will take a few cycles longer. I elected to keep it at that time. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On 8/1/2019 10:49 AM, Pierre Labastie via blfs-dev wrote: OK, I've found the error On the Xinit page, we have: --- sed -e '/$serverargs $vtarg/ s/serverargs/: #&/' \ -i startx.cpp --- for the Sysv/elogind book, while we do not have this for the systemd book. Removing the ": #" allows startx to run the server and the usual clients. I think even the suid-wrapper is not needed! (it drops privilege anyway if /dev/dri/card0 is KMS compatible). This can be tested by moving /usr/libexec/Xorg.wrap to /usr/libexec/Xorg.wrap.nouse, and trying again: startx still works. So we can: remove the sed on the Xinit page remove any enable-xxx-suid switch for xorg-server (well, maybe some drivers do need the wrapper, this has to be tested, but I do not have the hardware (intel driver works fine without the wrapper)). Pierre PS: I've spend almost 24 h running the server, xinit, with gdb, playing with xauth files, etc, before finding this stupid bug! Must be old hardware for me then. I still work with the sed, but if removing it fixes for everyone else, then excellet! From two working builds: if [ "$have_vtarg" = "no" ]; then : #serverargs="$serverargs $vtarg" fi Looking at it further, it probably always worked with libsystemd aware dm (that if never would have evaluated to true unless started from the command line). Still slightly confused, but happier. :-) --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On August 1, 2019 3:11:05 PM CDT, Ken Moffat via blfs-dev wrote: >On Thu, Aug 01, 2019 at 02:25:36PM -0500, Bruce Dubbs via blfs-dev >wrote: >> >> Please take a look at the xinit instructions from commit 21892. >> >> http://www.linuxfromscratch.org/blfs/view/svn/x/xinit.html >> >> Feedback welcome. >> >> -- Bruce > >The xinit part of that commit looks and sounds reasonable (I haven't >booted my new build yet, so I'm at best some hours from trying to >startx), but the xorg-server changes (only to explanations) look odd. > >./configure $XORG_CONFIG\ >--enable-glamor \ >--enable-install-setuid \ >--enable-suid-wrapper \ >--with-xkb-output=/var/lib/xkb > > i.e. the suid install and the wrapper are still built. > >I read this as implying that for xinit the sed should not be used >when compiling, but if desired the Xorg program can be chmodded to >suid and the installed startx script altered so it will use vt7. > >But: the server is compiled as suid, so the optional chmod should >have no effect. > >ĸen >-- >One pill makes you larger, And one pill makes you small. >And the ones that mother gives you, Don't do anything at all. >Go ask Alice, When she's ten feet tall. > -- Jefferson Airplane, White Rabbit >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Correct. Bruce's mockup was only for the xinit page. The suid binary will go. I still don't know about the wrapper. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On 8/1/19 11:40 AM, Bruce Dubbs via blfs-dev wrote: On 8/1/19 10:49 AM, Pierre Labastie via blfs-dev wrote: On 31/07/2019 00:44, DJ Lucas via blfs-dev wrote: On July 30, 2019 3:54:34 PM CDT, Pierre Labastie via blfs-dev wrote: IIUC above, this is because we do not have elogind in LFS, so our first build of dbus does not link to libsystemd (unlike in LFS-systemd). The lack of dbus support is inconsequential in that configuration because we are going to rebuild systemd later in BLFS. There is also another thing, which bothers me: instructions for the xorg server are the same in both books (sysv/elogind and systemd). So, when we add --enable-install-setuid to xorg-server, we add it in both books. But I believed it was not needed in the systemd book... That would be my doing as I had believed that they would be the same (and still believe they should be, but my attempts to find the reason for the differences have failed me thus far), so the two variants got merged down. In fact, I think I am the only one who has demonstrated that a rootless Xorg is even possible with elogind in our group. Five consecutive builds, all slightly different, but logical (apparently only to me), build orders. I'd gotten frustrated trying to track it down, I was simply spinning my wheels, so I put it on the back burner (knowing that a viable workaround exists). I'll be testing noveau on an existing build next week to possibly eliminate hardware/drivers. I want to also say that I've built entirely in chroot already, but I'm not 100% certain on that. HTH OK, I've found the error On the Xinit page, we have: --- sed -e '/$serverargs $vtarg/ s/serverargs/: #&/' \ -i startx.cpp --- for the Sysv/elogind book, while we do not have this for the systemd book. Removing the ": #" allows startx to run the server and the usual clients. I think even the suid-wrapper is not needed! (it drops privilege anyway if /dev/dri/card0 is KMS compatible). This can be tested by moving /usr/libexec/Xorg.wrap to /usr/libexec/Xorg.wrap.nouse, and trying again: startx still works. So we can: remove the sed on the Xinit page remove any enable-xxx-suid switch for xorg-server (well, maybe some drivers do need the wrapper, this has to be tested, but I do not have the hardware (intel driver works fine without the wrapper)). Pierre PS: I've spend almost 24 h running the server, xinit, with gdb, playing with xauth files, etc, before finding this stupid bug! I appreciate your hard work in finding the discrepancy. We added that sed on purpose so Xorg will come up on vt7 instead of vt. For most users it probably does not make a difference, but it is convenient to be able to switch between vt1 and vt7 when debugging. My preference is to leave the sed and the suid alone in the sysv book, but as an alternative we could just document the technique in a note. Apologies if this comes through twice, my work laptop had an old configuration, the first will probably get blocked. I don't think this is correct, but might be a clue. My build script for xinit has this sed, and it works. http://www.linuxfromscratch.org/~dj/mkbuild.sh/sources/buildscripts/xinit.sh The proposed sed also does nothing from what I can see (this from Arch, where it would not have been applied, but I can't get to my workstation from here): [dj@DJ-ARCH-02 ~]$ head -n 137 /usr/bin/startx | tail -n 3 if [ "$have_vtarg" = "no" ]; then serverargs="$serverargs $vtarg" fi [dj@DJ-ARCH-02 ~]$ sed -e '/$serverargs $vtarg/ s/serverargs/&/' /usr/bin/startx | head -n 137 | tail -n 3 if [ "$have_vtarg" = "no" ]; then serverargs="$serverargs $vtarg" fi If this is actually the issue, I must have successfully done something wrong multiple times (but I wouldn't put it past me at this point), but then my preference is for opposite Bruce's suggestion. IOW: put the commands on the xinit page to add the suid bit for Xorg along with the sed and put them inside of nodump tags.Like Bruce said, the majority of users won't care one way or the other, but avoiding a suid bit wherever possible is a good thing. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On 8/1/19 11:40 AM, Bruce Dubbs via blfs-dev wrote: On 8/1/19 10:49 AM, Pierre Labastie via blfs-dev wrote: On 31/07/2019 00:44, DJ Lucas via blfs-dev wrote: On July 30, 2019 3:54:34 PM CDT, Pierre Labastie via blfs-dev wrote: IIUC above, this is because we do not have elogind in LFS, so our first build of dbus does not link to libsystemd (unlike in LFS-systemd). The lack of dbus support is inconsequential in that configuration because we are going to rebuild systemd later in BLFS. There is also another thing, which bothers me: instructions for the xorg server are the same in both books (sysv/elogind and systemd). So, when we add --enable-install-setuid to xorg-server, we add it in both books. But I believed it was not needed in the systemd book... That would be my doing as I had believed that they would be the same (and still believe they should be, but my attempts to find the reason for the differences have failed me thus far), so the two variants got merged down. In fact, I think I am the only one who has demonstrated that a rootless Xorg is even possible with elogind in our group. Five consecutive builds, all slightly different, but logical (apparently only to me), build orders. I'd gotten frustrated trying to track it down, I was simply spinning my wheels, so I put it on the back burner (knowing that a viable workaround exists). I'll be testing noveau on an existing build next week to possibly eliminate hardware/drivers. I want to also say that I've built entirely in chroot already, but I'm not 100% certain on that. HTH OK, I've found the error On the Xinit page, we have: --- sed -e '/$serverargs $vtarg/ s/serverargs/: #&/' \ -i startx.cpp --- for the Sysv/elogind book, while we do not have this for the systemd book. Removing the ": #" allows startx to run the server and the usual clients. I think even the suid-wrapper is not needed! (it drops privilege anyway if /dev/dri/card0 is KMS compatible). This can be tested by moving /usr/libexec/Xorg.wrap to /usr/libexec/Xorg.wrap.nouse, and trying again: startx still works. So we can: remove the sed on the Xinit page remove any enable-xxx-suid switch for xorg-server (well, maybe some drivers do need the wrapper, this has to be tested, but I do not have the hardware (intel driver works fine without the wrapper)). Pierre PS: I've spend almost 24 h running the server, xinit, with gdb, playing with xauth files, etc, before finding this stupid bug! I appreciate your hard work in finding the discrepancy. We added that sed on purpose so Xorg will come up on vt7 instead of vt. For most users it probably does not make a difference, but it is convenient to be able to switch between vt1 and vt7 when debugging. My preference is to leave the sed and the suid alone in the sysv book, but as an alternative we could just document the technique in a note. I don't think this is correct, but might be a clue. My build script for xinit has this sed, and it works. http://www.linuxfromscratch.org/~dj/mkbuild.sh/sources/buildscripts/xinit.sh The proposed sed also does nothing from what I can see (this from Arch, where it would not have been applied, but I can't get to my workstation from here): [dj@DJ-ARCH-02 ~]$ head -n 137 /usr/bin/startx | tail -n 3 if [ "$have_vtarg" = "no" ]; then serverargs="$serverargs $vtarg" fi [dj@DJ-ARCH-02 ~]$ sed -e '/$serverargs $vtarg/ s/serverargs/&/' /usr/bin/startx | head -n 137 | tail -n 3 if [ "$have_vtarg" = "no" ]; then serverargs="$serverargs $vtarg" fi If this is actually the issue, I must have successfully done something wrong multiple times (but I wouldn't put it past me at this point), but then my preference is for opposite Bruce's suggestion. IOW: put the commands on the xinit page to add the suid bit for Xorg along with the sed and put them inside of nodump tags.Like Bruce said, the majority of users won't care one way or the other, but avoiding a suid bit wherever possible is a good thing. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On July 30, 2019 3:54:34 PM CDT, Pierre Labastie via blfs-dev wrote: >On 30/07/2019 18:50, Bruce Dubbs via blfs-dev wrote: >> On 7/30/19 5:40 AM, Pierre Labastie via blfs-dev wrote: >>> On 29/07/2019 21:15, Pierre Labastie via blfs-dev wrote: On 29/07/2019 18:32, Bruce Dubbs via blfs-dev wrote: >> >> [snip] >> >>> nspr >>> js60 >>> polkit >>> libepoxy >>> xorg-server >>> xkeyboard-config >>> Xorg Legacy >>> twm >>> xclock >>> xterm2 >>> xorg-intel-driver >>> libevdev >>> mtdev >>> libinput >>> xorg-libinput-driver >>> --->8--- >>> I've not rebooted the computer during the build, so that neither >elogind nor >>> dbus was running (I rebooted only after building the X drivers, >before running >>> startx). Do they need to run at some point? >> >> I do think the system needs to be rebooted and both dbus and elogind >> bootscripts (among others) started. Then log in and try startx. >> >> Also I'm not sure how jhalfs handles configuration. There are a >couple of >> places where pam needs to be configured and there may be a couple of >other >> packages. >> > >Normally, if the configuration instructions are in the "Configuring >blah" >paragraph, jhalfs should be able to run them. > >I'm bothered by this order, because, for systemd book, we first build >shadow, >then systemd, then dbus (in the LFS book), then linux-pam, shadow >again, then >systemd again, but not dbus again (at least for using xinit). It seems >to me >that the order with elogind is slightly different. > IIUC above, this is because we do not have elogind in LFS, so our first build of dbus does not link to libsystemd (unlike in LFS-systemd). The lack of dbus support is inconsequential in that configuration because we are going to rebuild systemd later in BLFS. >There is also another thing, which bothers me: instructions for the >xorg >server are the same in both books (sysv/elogind and systemd). So, when >we add >--enable-install-setuid to xorg-server, we add it in both books. But I >believed it was not needed in the systemd book... > That would be my doing as I had believed that they would be the same (and still believe they should be, but my attempts to find the reason for the differences have failed me thus far), so the two variants got merged down. In fact, I think I am the only one who has demonstrated that a rootless Xorg is even possible with elogind in our group. Five consecutive builds, all slightly different, but logical (apparently only to me), build orders. I'd gotten frustrated trying to track it down, I was simply spinning my wheels, so I put it on the back burner (knowing that a viable workaround exists). I'll be testing noveau on an existing build next week to possibly eliminate hardware/drivers. I want to also say that I've built entirely in chroot already, but I'm not 100% certain on that. HTH --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] svn-2019-07-29 libreoffice + JDK, autgen.sh error?
On July 30, 2019 3:22:24 PM CDT, Ken Moffat via blfs-dev wrote: >On Tue, Jul 30, 2019 at 08:01:18PM +0000, DJ Lucas via blfs-dev wrote: >> Maybe this helps: It is not _required_ to have Java to build LO, it >will build just fine with an in-tree binary (or even without now days, >IIRC, but loses severe functionality), but Java is needed to use the >instructions that BLFS has _recommended_ for minimum expected >functionality. >> >From memory, there was a complaint (about non-working database, I >think) when we didn't include the java deps. For my own builds >(most recent was 6.2.3.2) I only need the work processor and >spreadsheey, so I omit java and the --without-java build was fien >for my needs. Yes, HSQLDB was the DB engine (written in Java), functions like mail merge require it as well. At one time, the help and video wizards did too, but I'm hopelessly out of date WRT LO. I think it was still OpenOffice last time I touched the page, but I had significant patchsets from go-oo in there (go-oo code base later became what is LO). -- DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] svn-2019-07-29 libreoffice + JDK, autgen.sh error?
On July 30, 2019 3:01:18 PM CDT, DJ Lucas via blfs-dev wrote: >On July 30, 2019 2:21:49 PM CDT, Jean-Marc Pigeon via blfs-dev > wrote: >>Hello Bruce, >> >>On 07/30/2019 02:50 PM, Bruce Dubbs via blfs-dev wrote: >>> On 7/30/19 1:37 PM, Jean-Marc Pigeon via blfs-dev wrote: >>>> On 07/30/2019 01:55 PM, Bruce Dubbs via blfs-dev wrote: >>>>> On 7/30/19 12:39 PM, Jean-Marc Pigeon via blfs-dev wrote: >>>>>> Hello, >>>>>> >>>>>> Trying to compile libreoffice on 8.5 and get an autogen.sh error >>>>>> >>>>>> ; >>>>>> ... >>>>>> checking whether g++ supports -fno-default-inline... yes >>>>>> checking whether g++ supports -fno-enforce-eh-specs... yes >>>>>> checking for posix_fallocate... yes >>>>>> checking whether to add custom build version... no >>>>>> checking for java... no >>>>>> checking the installed JDK... configure: error: Java not found. >>You >>>>>> need at least jdk-1.6 >>>>>> Error running configure at ./autogen.sh line 296 >>>>>> ;- >>>>>> >>>>>> According my understanding, only >>>>>> Archive-Zip-1.64, UnZip-6.0, Wget-1.20.3, Which-2.21, and Zip-3.0 >>>>>> are required to build libreoffice. >>>>>> >>>>>> Furthermore, I see no reference to java/jdk with recommended or >>>>>> optional list. >>>>>> >>>>>> Seems there is no --without-jdk option.. >>>>>> >>>>>> Puzzled... >>>>>> What is the detail I am overlooking? >>>>>> >>>>>> Any hint will be welcome >>>>>> >>>>>> Should "Java" added to the "required" dependencies within book >>chapter >>>>>> 39? >>>>> >>>>> Did you add --without-java to the ./autogen.sh options? I'll note >>that >>>>> if you installed the recommended apache-ant, then java was >required >>for >>>>> that. >>>>> >>>>>-- Bruce >>>>> >>>> before my original post: Tried --without-jdk, no luck >>>> your suggestion is a good one, --without-java allow me to go >>further. >>>> >>>> My understanding of "required" seems not to be the good one. >>>> To me required means, installing a system with the bare minimum (a >>>> compiler), PLUS the required packages. The compilation will go on >>and >>>> the package will be working (may be without all bell and whistle, >>but >>>> working) . >>>> >>>> I didn't install apache-ant (on purpose). >>>> According my (new) understanding of the libreoffice BLFS page, >>>> build will integrate an "old version" of apache-ant, >>>> which must have java. >>>> (such Java become mandatory, and autogen.sh is complaining >>>> To be consistent with itself, libreoffice should include and old >>>> version of java too). >>>> >>>> May I suggest, to change a little bit the libreoffice page >>>> and merge "Recommended" to "required". >>>> Such the build could be run on a real and effective dependencies >>list. >>>> (a validated common ground) >>>> >>>> In the mid time, I will try to define the minimal libreoffice >>>> dependencies >>> >>> >>http://www.linuxfromscratch.org/blfs/view/stable/introduction/notes-on-building.html >>> >>> >>> "Recommended means that BLFS strongly suggests this package is >>installed >>> first for a clean and trouble-free build, that won't have issues >>either >>> during the build process, or at run-time. The instructions in the >>book >>> assume these packages are installed. Some changes or workarounds may >>be >>> required if these packages are not installed. " >>> >> >>I read again notes-on-building.html page and BLFS is not complying >>with its own rule. >>with only the required package >>Archive-Zip-1.64, UnZip-6.0, Wget-1.20.3, Which-2.21, and Zip-3.0 >>the java build defect shouldn't show up, but it is, this means >>the r
Re: [blfs-dev] svn-2019-07-29 libreoffice + JDK, autgen.sh error?
On July 30, 2019 2:21:49 PM CDT, Jean-Marc Pigeon via blfs-dev wrote: >Hello Bruce, > >On 07/30/2019 02:50 PM, Bruce Dubbs via blfs-dev wrote: >> On 7/30/19 1:37 PM, Jean-Marc Pigeon via blfs-dev wrote: >>> On 07/30/2019 01:55 PM, Bruce Dubbs via blfs-dev wrote: On 7/30/19 12:39 PM, Jean-Marc Pigeon via blfs-dev wrote: > Hello, > > Trying to compile libreoffice on 8.5 and get an autogen.sh error > > ; > ... > checking whether g++ supports -fno-default-inline... yes > checking whether g++ supports -fno-enforce-eh-specs... yes > checking for posix_fallocate... yes > checking whether to add custom build version... no > checking for java... no > checking the installed JDK... configure: error: Java not found. >You > need at least jdk-1.6 > Error running configure at ./autogen.sh line 296 > ;- > > According my understanding, only > Archive-Zip-1.64, UnZip-6.0, Wget-1.20.3, Which-2.21, and Zip-3.0 > are required to build libreoffice. > > Furthermore, I see no reference to java/jdk with recommended or > optional list. > > Seems there is no --without-jdk option.. > > Puzzled... > What is the detail I am overlooking? > > Any hint will be welcome > > Should "Java" added to the "required" dependencies within book >chapter > 39? Did you add --without-java to the ./autogen.sh options? I'll note >that if you installed the recommended apache-ant, then java was required >for that. -- Bruce >>> before my original post: Tried --without-jdk, no luck >>> your suggestion is a good one, --without-java allow me to go >further. >>> >>> My understanding of "required" seems not to be the good one. >>> To me required means, installing a system with the bare minimum (a >>> compiler), PLUS the required packages. The compilation will go on >and >>> the package will be working (may be without all bell and whistle, >but >>> working) . >>> >>> I didn't install apache-ant (on purpose). >>> According my (new) understanding of the libreoffice BLFS page, >>> build will integrate an "old version" of apache-ant, >>> which must have java. >>> (such Java become mandatory, and autogen.sh is complaining >>> To be consistent with itself, libreoffice should include and old >>> version of java too). >>> >>> May I suggest, to change a little bit the libreoffice page >>> and merge "Recommended" to "required". >>> Such the build could be run on a real and effective dependencies >list. >>> (a validated common ground) >>> >>> In the mid time, I will try to define the minimal libreoffice >>> dependencies >> >> >http://www.linuxfromscratch.org/blfs/view/stable/introduction/notes-on-building.html >> >> >> "Recommended means that BLFS strongly suggests this package is >installed >> first for a clean and trouble-free build, that won't have issues >either >> during the build process, or at run-time. The instructions in the >book >> assume these packages are installed. Some changes or workarounds may >be >> required if these packages are not installed. " >> > >I read again notes-on-building.html page and BLFS is not complying >with its own rule. >with only the required package >Archive-Zip-1.64, UnZip-6.0, Wget-1.20.3, Which-2.21, and Zip-3.0 >the java build defect shouldn't show up, but it is, this means >the required list is not "up to date" :; > >Lets go a little bit further. >The libreoffice autogen.sh include package as boost, harfbuzz, etc. >It is BLFS team privilege to say: >"To have a really working libreoffice, build need to have >with-system-harfbuzz with-system-boost, etc." > From the team stand point, those packages are "required". > >My way I would say (from BLSF prospective). >If a package is implied by the proposed build context (autogen.sh or >configure arguments), then the said package is mandatory/required. > >If the reader do not want some proposed build context and "mess" with >book directives he is on its own. >The book mantra is "If you follow given instructions, you should have >our same result". No to all above. I believe you are trying to look at it from a functional perspective, where the book only looks at technical requirements. Maybe this helps: It is not _required_ to have Java to build LO, it will build just fine with an in-tree binary (or even without now days, IIRC, but loses severe functionality), but Java is needed to use the instructions that BLFS has _recommended_ for minimum expected functionality. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On 7/25/2019 12:26 PM, Ken Moffat via blfs-dev wrote: The gentoo thread (from last year) which I was reading suggested that startx, but also DEs (depending on the driver, intel was ok, modesetting was not) were broken at that time. Possibly https://forums.gentoo.org/viewtopic-t-1092792-start-0.html or https://forums.gentoo.org/viewtopic-t-1088682-start-50.html ? But apparently some people have been using recent versions of the book on desktops without this problem. Yes, I'm one of those people. :-) I believe the above might be outdated. I am using an older ATI card (I don't game, so $25-30 bargain buy for all of mine, though I just realized that I still have the kernel parameter amdgpu.si_support=1, though I now forget exactly why it was put in there): 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] Having never experienced the issue, I am not fully versed in the topic, but in X log I have (forgive the root prompt, I'm currently chrooted): root@lfsdt1 [ /sources/temp ]# grep modesetting /var/log/Xorg.0.log [ 196.493] (==) Matched modesetting as autoconfigured driver 2 [ 196.513] (II) LoadModule: "modesetting" [ 196.513] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 196.526] (II) Module modesetting: vendor="X.Org Foundation" [ 196.528] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 196.532] (II) [KMS] Kernel modesetting enabled. [ 196.532] (WW) Falling back to old probe method for modesetting This is from RL3 with a newly created user who has no group membership and no suid X binary (I do have the suid wrapper). I just can't figure out what is different for me. Bruce's proposed build order (elsewhere in the thread) looks a lot more similar to mine than his previous ones, but even looking at his previous build order, I couldn't see anything (after fixing my previous elogind dependency for xtrans). I mean, we've been building without suid binary on systemd for some time, and never had issues AFAIK. So for the moment, I'm just at a loss as to why it works for some but not all. I'll plan on buying some different hardware in the second week of August and revisiting it at that time. For now, I'm working on the bootscripts. Some changes are required in the standard boot order from the Makefile. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xorg failure
On July 25, 2019 11:36:27 AM CDT, Bruce Dubbs via blfs-dev wrote: >On 7/25/19 11:08 AM, Ken Moffat via blfs-dev wrote: >> On Thu, Jul 25, 2019 at 06:59:10AM -0600, Roger Koehler via blfs-dev >wrote: >>> The latest LFS/BLFS doesn't work on my Libreboot X200 Tablet: >>> >>> Fatal server error: >>> [ 14887.874] (EE) parse_vt_settings: Cannot open /dev/tty0 >(Permission >>> denied) >>> >>> See attached log file. >> >> [ mostly snipped, except to note this is from the systemd book >> although that is probably not the root cause of this ] >>> [ 14887.842] (II) systemd-logind: took control of session >/org/freedesktop/login1/session/_31 >>> [ 14887.842] (II) xfree86: Adding drm device (/dev/dri/card0) >> >> I don't have a systemd system, and my builds are now somewhat old, >> but to attempt to get a little closer towards someone with systemd >> identifying where the problem lies: What are the ownership and perms >> of /dev/tty0 ? >> >> On this (8.4, sysv) machine where I'm writing this, it is owned by >> root:tty with perms of 640. >> >> Googling, this sounds like a non-suid Xorg with startx. i.e. the >> switch --enable-install-setuid has been omitted. Ah, I think that >> might have been briefly removed after the elogind merge (not sure), >> but it is certainly in the current book for both sysv and systemd. >> >> From one of my google results, with some video drivers (including >> your intel, but not modesetting!) non-suid X works in destop >> environments but not with startx. > >--enable-install-setuid was removed again, but I cannot confirm that it > >works. We still need to sort that out. For now the easy way is to > >sudo -E chmod u+s $XORG_PREFIX/libexec/Xorg > > -- Bruce >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page It really shouldn't be necessary with any of the drivers in BLFS, but I've made a mistake someplace and, thus far, I have been unable to locate it. Let's just put it back in by default for now until that ah ha moment comes of it's own accord. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Re：Re: Re：_Question_about_xinit_and_other_sugg estions
On June 27, 2019 7:38:17 PM CDT, hykwok1--- via blfs-dev wrote: > >I found another setting issus if KF5 is installed in "/opt": > >Similar to DBus case, we have to add the following line for "Polkit" >during "Pre-installation Configuration" stage: > >ln -sfv /usr/share/polkit-1 $KF5_PREFIX/share Good catch. One issue, however. The point of installing into /opt, which I don't particularly like but others find valuable, is to separate it from the rest of the system for easy updates. I think a far better way to handle this is already in the book on the polkit page, but the specific configuration should be given in the KF5 section. I believe there is a similar mechanism for D-Bus as well, but it escapes me ATM. Thoughts? --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Question about xinit and other suggestions
On June 26, 2019 8:59:35 PM CDT, hykwok1--- via blfs-dev wrote: >1. Xinit 1.4.1 > >Can anyone expain why we have to use the parameter >"--with-xinitdir=/etc/X11/app-defaults" for Xinit? > Not sure what happened to my earlier response, but this dates back to 2007. Once upon a time, XFree86, and later Xorg, were distributed as a single package. When that one package became ~250, I tried to mimic the layout of the monolithic build as closely as possible. This is one of those that had hung around. >That's because I find that the folder "/etc/X11/app-defaults/xinitrc.d" >is not created while some applications will install thier "sh" files to >"/etc/X11/xinit/xinitrc.d". As a result, those "sh" files will not be >read by Xinit program. > To be honest, this is the first time I'd heard of an app-defaults.d directory. I generally lean toward using .d directories when possible, so probably a good idea, but how are the files sourced? Is this a function of xinit, or do we need to source them manually from the default xinitrc (and personal ones?)? Additionally, I don't particularly like the unnecessary change for xinit subdirectory. The directory, as in the book should probably stay - as mentioned above, this is somewhat of a staple, at least for longtime users. The packages that aren't pulling from pkg-config should be fixed upstream, and patched or configured locally until those patches land in a release. >2. Qt > >The instruction "cat >> /etc/ld.so.conf << EOF" can be changed to "cat >> /etc/ld.so.conf.d/qt5.conf". > Not as the book is now. ld.so.conf.d is optional, so it can't be a direct dependency in the book. In general, .d directories are cleaner especially in the context of slowly building a system, so I'm on board with making it not optional, but there might be some resistance. Anybody else want to chime in? >3. KDE Frameworks 5 Pre-installation Configuration > >In the section "Installing in /opt", I think the follow lines are >missing for the file "/etc/profile.d/qt5.sh": > >pathappend /usr/lib/qt5/pluginsQT_PLUGIN_PATH >pathappend /usr/lib/qt5/qmlQML2_IMPORT_PATH > >Also, it is better to add the following line in the "sh" file: > >pathappend $QT5DIR/plugins/kcmsQT_PLUGIN_PATH > >That's because KDE application "sytemsetting5" will report "the plugin >kcm_xx was not found" if the above setting is not set. Not seen this, but Gnone is my primary environment. -- DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg authorization problem with elogind
On June 26, 2019 2:22:03 AM CDT, Pierre Labastie via blfs-dev wrote: >On 26/06/2019 05:55, Bruce Dubbs via blfs-dev wrote: >> On 6/25/19 9:54 PM, DJ Lucas via blfs-dev wrote: >>> >>> >>> On 6/25/2019 9:19 PM, Bruce Dubbs via blfs-dev wrote: >>>> On 6/25/19 9:08 PM, DJ Lucas via blfs-dev wrote: >>>>> >>>>> >>>>> On 6/25/2019 2:55 PM, Pierre Labastie via blfs-dev wrote: >>>>>> Hi, >>>>>> >>>>>> I've not gone that far with my elogind testing: >>>>>> - >>>>>> pierre [ ~ ]$ startx >>>>>> xauth: file /home/pierre/.serverauth.2289 does not exist >>>>>> >>>>>> >>>>>> X.Org X Server 1.20.4 >>>>>> X Protocol Version 11, Revision 0 >>>>>> Build Operating System: Linux 5.1.14-lfs-1 x86_64 >>>>>> Current Operating System: Linux turbolivirt 5.1.14-lfs-1 #1 SMP >Tue Jun 25 >>>>>> 18:58:17 CEST 2019 x86_64 >>>>>> Kernel command line: BOOT_IMAGE=/vmlinuz-5.1.14-lfs-SVN-20190618 >>>>>> root=/dev/sda2 ro quiet >>>>>> Build Date: 24 June 2019 11:57:25AM >>>>>> >>>>>> Current version of pixman: 0.38.4 >>>>>> Before reporting problems, check http://wiki.x.org >>>>>> to make sure that you have the latest version. >>>>>> Markers: (--) probed, (**) from config file, (==) default >setting, >>>>>> (++) from command line, (!!) notice, (II) informational, >>>>>> (WW) warning, (EE) error, (NI) not implemented, (??) >unknown. >>>>>> (==) Log file: "/home/pierre/.local/share/xorg/Xorg.0.log", Time: >Tue Jun 25 >>>>>> 21:44:33 2019 >>>>>> (==) Using system config directory "/usr/share/X11/xorg.conf.d" >>>>>> (EE) >>>>>> Fatal server error: >>>>>> (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) >>>>>> (EE) >>>>>> (EE) >>>>>> Please consult the The X.Org Foundation support >>>>>> at http://wiki.x.org >>>>>> for help. >>>>>> (EE) Please also check the log file at >>>>>> "/home/pierre/.local/share/xorg/Xorg.0.log" for additional >information. >>>>>> (EE) >>>>>> (EE) Server terminated with error (1). Closing log file. >>>>>> xinit: giving up >>>>>> xinit: unable to connect to X server: Connection refused >>>>>> xinit: server error >>>>>> --- >>>>>> >>>>>> Two unusual things for me: >>>>>> - it seems xorg-server runs as user, or at least not as root >>>>>> - the log file is not the usual /var/log/Xorg.0.log (maybe >because of the >>>>>> authorization problem... >>>>>> >>>>>> I've checked the pam files, nothing obvious (I use pwquality for >passwords, >>>>>> but I guess it has nothing to do with what is seen here. >>>>>> >>>>>> Do I need to add myself to a special group (wheel for example)? >>>>> >>>>> Wait! Check the build order. Was xorg protocol headers installed >before >>>>> elogind? >>>> >>>> For me, yes. >>>> >>>> Fri 07 Jun 2019 06:00:59 PM CDT >>>> /usr/src/xc/prot-headers/xorgproto-2018.4.tar.bz2 >>>> Sun 09 Jun 2019 11:16:29 AM CDT >/usr/src/elogind/elogind-241.3.tar.gz >>>> >>>> -- Bruce >>> Nope, sorry, it's not the headers, it's xtrans, so xorg-libs page. >If xtrans >>> isn't built with sd-daemon.h present, then the tty selection will be >messed. >>> It won't look to dbus (and polkit) for it's authorizations. So just >rebuild >>> xtrans, and then xorg-server without suid, just the wrapper. >> >> Did that, I do have /usr/include/elogind/systemd/sd-daemon.h >> I did 'make clean' and then rebuilt/installed xtrans and xorg-server >using the >> elogind instructions. I still get a message that permission is >denied when >> trying to open virtual console 7. I just checked twm since it is the >simplest. >> >> When I pulled the patches after 241.1 was released with the >>> journal->syslog compatibility stuff, I just copied th
Re: [blfs-dev] Xorg authorization problem with elogind
On 6/25/2019 9:19 PM, Bruce Dubbs via blfs-dev wrote: On 6/25/19 9:08 PM, DJ Lucas via blfs-dev wrote: On 6/25/2019 2:55 PM, Pierre Labastie via blfs-dev wrote: Hi, I've not gone that far with my elogind testing: - pierre [ ~ ]$ startx xauth: file /home/pierre/.serverauth.2289 does not exist X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 Build Operating System: Linux 5.1.14-lfs-1 x86_64 Current Operating System: Linux turbolivirt 5.1.14-lfs-1 #1 SMP Tue Jun 25 18:58:17 CEST 2019 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-5.1.14-lfs-SVN-20190618 root=/dev/sda2 ro quiet Build Date: 24 June 2019 11:57:25AM Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/pierre/.local/share/xorg/Xorg.0.log", Time: Tue Jun 25 21:44:33 2019 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/pierre/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error --- Two unusual things for me: - it seems xorg-server runs as user, or at least not as root - the log file is not the usual /var/log/Xorg.0.log (maybe because of the authorization problem... I've checked the pam files, nothing obvious (I use pwquality for passwords, but I guess it has nothing to do with what is seen here. Do I need to add myself to a special group (wheel for example)? Wait! Check the build order. Was xorg protocol headers installed before elogind? For me, yes. Fri 07 Jun 2019 06:00:59 PM CDT /usr/src/xc/prot-headers/xorgproto-2018.4.tar.bz2 Sun 09 Jun 2019 11:16:29 AM CDT /usr/src/elogind/elogind-241.3.tar.gz -- Bruce Nope, sorry, it's not the headers, it's xtrans, so xorg-libs page. If xtrans isn't built with sd-daemon.h present, then the tty selection will be messed. It won't look to dbus (and polkit) for it's authorizations. So just rebuild xtrans, and then xorg-server without suid, just the wrapper. When I pulled the patches after 241.1 was released with the journal->syslog compatibility stuff, I just copied the original page and forgot about the dependency. This will fix it, but I totally ruined Pierre's test run for the deps I think. Dang it! Pierre, can you run just blfs-tool without actually running the build to see how badly I messed up the ordering. Looking at Bruce's build, it looks like they were two days apart, but Bruce, correct me if I'm wrong, was running a manually scripted build. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg authorization problem with elogind
On 6/25/2019 2:55 PM, Pierre Labastie via blfs-dev wrote: Hi, I've not gone that far with my elogind testing: - pierre [ ~ ]$ startx xauth: file /home/pierre/.serverauth.2289 does not exist X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 Build Operating System: Linux 5.1.14-lfs-1 x86_64 Current Operating System: Linux turbolivirt 5.1.14-lfs-1 #1 SMP Tue Jun 25 18:58:17 CEST 2019 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-5.1.14-lfs-SVN-20190618 root=/dev/sda2 ro quiet Build Date: 24 June 2019 11:57:25AM Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/pierre/.local/share/xorg/Xorg.0.log", Time: Tue Jun 25 21:44:33 2019 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/pierre/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error --- Two unusual things for me: - it seems xorg-server runs as user, or at least not as root - the log file is not the usual /var/log/Xorg.0.log (maybe because of the authorization problem... I've checked the pam files, nothing obvious (I use pwquality for passwords, but I guess it has nothing to do with what is seen here. Do I need to add myself to a special group (wheel for example)? Wait! Check the build order. Was xorg protocol headers installed before elogind? I just realized that I missed that dependency. The proto headers are not correct for systemd/elogind if that's the case. The good news is that I suspect that only the headers and xorg-server need to be reinstalled if that's the case. I don't think anything else is dependent on it. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg authorization problem with elogind
On 6/25/2019 2:55 PM, Pierre Labastie via blfs-dev wrote: Hi, I've not gone that far with my elogind testing: - pierre [ ~ ]$ startx xauth: file /home/pierre/.serverauth.2289 does not exist X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 Build Operating System: Linux 5.1.14-lfs-1 x86_64 Current Operating System: Linux turbolivirt 5.1.14-lfs-1 #1 SMP Tue Jun 25 18:58:17 CEST 2019 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-5.1.14-lfs-SVN-20190618 root=/dev/sda2 ro quiet Build Date: 24 June 2019 11:57:25AM Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/pierre/.local/share/xorg/Xorg.0.log", Time: Tue Jun 25 21:44:33 2019 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) Looks like both the sed to make it open the next available tty and the suid wrapper are missing. Did I do something incorrectly in the book here? I think Bruce had the same issue. I have not seen it locally. Also, make sure the createfiles is updated (also note that I am using Xorg-server-1.20.5 (same instructions). /tmp/.ICE-unix dir 1777 root root /tmp/.X11-unix dir 1777 root root (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/pierre/.local/share/xorg/Xorg.0.log" for additional information. (EE) Again, the SUID wrapper should handle this. (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error --- Two unusual things for me: - it seems xorg-server runs as user, or at least not as root - the log file is not the usual /var/log/Xorg.0.log (maybe because of the authorization problem... I've checked the pam files, nothing obvious (I use pwquality for passwords, but I guess it has nothing to do with what is seen here. Do I need to add myself to a special group (wheel for example)? --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Since changes are coming...
On 6/25/2019 6:21 PM, Joe Locash via blfs-dev wrote: Seriously? Ok, so missed a couple of packages. Maybe I shouldn't contribute to the goal of the project. My bad. Joe, your frustration is noted. Perhaps you wouldn't be if, as editors, we communicated better. Please allow me a moment to alleviate the confusion of why it's a huge difference in effort and provide some unrealized context. As a user, you can probably get this installed and working in just a couple of hours (as can I or any of the other editors here, and most long time users). For editors, however, it's a bit different, and I'm sure this is probably somewhat obvious to you, but the required amount of time invested is probably not what you'd picture without having inquired. For starters, you need to figure roughly four hours of time to add a new package to the book correctly. This varies depending on complexity of said package, and interactions with other packages, but four hours is the average. This includes the following tasks: 1. Find multiple official download locations if available 2. Verify developer signatures if available 3. Verify documented sums and document locally 4. Examine configure, meson.build, or cmake.lists manually to verify that there are no missing dependencies that are excluded from output when other dependencies are present 5. Document all dependencies 6. Determining which dependencies are required 7. Determine which dependencies are optional 8. Determine the recommended dependencies based on the subjective best guess of what is common usage 9. Document all of the above and remove nested dependencies (dependencies that are covered by another dependency in BLFS or that are in LFS) 10. Determine appropriate configure/meson/cmake flags as well as any CFLAGS required, or other tweaks that need to be made 11. Verify that most common builds work as expected, these being: a. required b. recommended c. everything and the kitchen sink d. multiple random assortments of common optional libs to ensure that there are no odd combinations that break 12. Author a standard set of instructions 13. Do multiple 'standard' builds to verify and document timing and build size, both at -j1 and -j4 14. Document every file that is installed, and where (DESTDIR and tree help) 15. Find descriptions for each executable and library installed (which more often than not, means having to read the source code for libraries that are installed alongside executables for which the package is named) 16. Work through test suites, identifying and documenting any failures 17. Author introductory text and surrounding text for instructions, explaining the steps if necessary 18. Put all of the above into an arcane XML format that is suitable for both human consumption after rendering, and machine consumption for automated builds (note: all of the steps above, and this very last step is the largest time sink and largest bar to entry for new editors and contributors). Doug was onboard and interested with the initial estimate of 3 packages. Assuming four to six hours of free time per day for the average working adult in the states, you asked for two or three days of his free time, which, again, he was on board with. When that ballooned into six, seven, or eight days (or giving up an entire weekend), it became more of an endeavor, so yes, missing a few packages is actually a big deal when you put it on those scales. Your input is appreciated, and us asking for you (or any other user) to provide a proof of concept acts as kind of a gateway to inclusion. This is the work you are asking to have done. You do the first tenth of it to prove that it's viable. Obviously, if you were to go for the real source, it'd be so very much more appreciated, but having done this myself for the better part of the past 20 years that I've been working with LFS, I find it really difficult to point a user to the book source on first suggestion for a POC. I'd rather you not invest that much time into something that may or may not become a reality, hence the request for a rough outline and sequence of packages. And finally, being Gnome packages, they often are on the easier side, but I think you can still appreciate that it's far more than the two or three hours to get it right off the cusp. I hope that gives you a more realistic understanding of what is involved with moves, adds, and changes in the books and might serve to ease the frustration exhibited above. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] building the elogind branch
On June 25, 2019 11:02:08 AM CDT, Pierre Labastie via blfs-dev
wrote:
>On 25/06/2019 17:20, DJ Lucas via blfs-dev wrote:
>> On June 25, 2019 7:44:54 AM CDT, Pierre Labastie via blfs-dev
> wrote:
>>> I've been building a full BLFS using the elogind branch for the last
>>> few days.
>>> Almost everything built OK. The first issue came with the ~840th
>>> package:
>>> smartmontools-7.0. During configure:
>>>
>>> [...]
>>> checking for cap-ng.h... no
>>> checking systemd/sd-daemon.h usability... yes
>>> checking systemd/sd-daemon.h presence... yes
>>> checking for systemd/sd-daemon.h... yes
>>> checking for sd_notify in -lsystemd... no
>>> configure: error: libsystemd headers found but library is missing
>>>
>>> Indeed, there is no libsystemd in either /lib or /usr/lib. But there
>is
>>> a
>>> /usr/lib/pkgconfig/libsystemd.pc, pointing to "-lelogind". the
>>> configure
>>> script does not use libsystemd.pc, but I have been able to build the
>>> package with:
>>> sed -e 's/\[systemd\]/[elogind]/' \
>>>-e 's/-lsystemd/-lelogind/' \
>>>-i configure.ac &&
>>> autoreconf -fiv &&
>>> ./configure ...
>>>
>>> I'm new to elogind, so there is maybe a better alternative.
>>
>> Bruce covered the easier way, but optionally, we could create a
>symlink for libsystemd. A couple of distros do exactly that, but I was
>really trying to avoid it (of course, I'd have preferred to avoid the
>PC symlink as well, but that brought too many patches). Really the test
>should be fixed, I'll look into upstreaming a test case for elogind at
>some point, but not sure about timeframe for it to get into a release,
>same for Xorg (though the PC symlink works for it).
>>
>>>
>>> Otherwise, there is a bunch of files installed in
>>> /usr/lib/systemd/user:
>>> ---
>>> at-spi-dbus-bus.service
>>> emacs.service
>>> evolution-addressbook-factory.service
>>> evolution-calendar-factory.service
>>> evolution-source-registry.service
>>> evolution-user-prompter.service
>>> gnome-shell.service
>>> gnome-shell-wayland.target
>>> gnome-shell-x11.target
>>> thunar.service
>>> xfce4-notifyd.service
>>> ---
>>> I guess those are missing some --with-systemduserunitdir switch or
>so.
>>
>> Yes, that is the correct fix (with =no).
>>
>> --DJ
>>
>
>The build is finished now. No other issues during build. But I have not
>run
>tests (jhalfs does not do a good job at running them), I've found some
>issues
>with docs, which I am almost sure have nothing to do with elogind, and
>I'll
>have to test that everything runs... I have a question though. I've
>seen that
>consolekit is still in the elogind branch. Is it needed? If not, I
>suggest
>removing/archiving it (I've not built it).
>
>For the run tests, I'm not sure what to test. I may launch lightdm and
>try to
>run DE's from it, but even the systemd book has issues with some DE's,
>so I
>expect this one to have issues too (and also the present sysv book).
>
>Pierre
>
>--
>http://lists.linuxfromscratch.org/listinfo/blfs-dev
>FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>Unsubscribe: See the above information page
Holy cow, that is awesome! So fast! I haven't tried XFCE yet. But if that can
build without CK, and just use dbus-launch for without {g,l,ss,x}dm case, then
should be good to drop CK. Reasonably sure that the others have checked out,
but a second and third looks sure don't hurt (especially being I screwed the
pooch on lxde momentarily). I'm interested in the shutdown/suspend
functionality from the various DMs and DEs as well. I've really only tested
with gdm. Can kdm make a return now, or is that just dead?
--DJ
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] building the elogind branch
On June 25, 2019 7:44:54 AM CDT, Pierre Labastie via blfs-dev wrote: >I've been building a full BLFS using the elogind branch for the last >few days. >Almost everything built OK. The first issue came with the ~840th >package: >smartmontools-7.0. During configure: > >[...] >checking for cap-ng.h... no >checking systemd/sd-daemon.h usability... yes >checking systemd/sd-daemon.h presence... yes >checking for systemd/sd-daemon.h... yes >checking for sd_notify in -lsystemd... no >configure: error: libsystemd headers found but library is missing > >Indeed, there is no libsystemd in either /lib or /usr/lib. But there is >a >/usr/lib/pkgconfig/libsystemd.pc, pointing to "-lelogind". the >configure >script does not use libsystemd.pc, but I have been able to build the >package with: >sed -e 's/\[systemd\]/[elogind]/' \ >-e 's/-lsystemd/-lelogind/' \ >-i configure.ac && >autoreconf -fiv && >./configure ... > >I'm new to elogind, so there is maybe a better alternative. Bruce covered the easier way, but optionally, we could create a symlink for libsystemd. A couple of distros do exactly that, but I was really trying to avoid it (of course, I'd have preferred to avoid the PC symlink as well, but that brought too many patches). Really the test should be fixed, I'll look into upstreaming a test case for elogind at some point, but not sure about timeframe for it to get into a release, same for Xorg (though the PC symlink works for it). > >Otherwise, there is a bunch of files installed in >/usr/lib/systemd/user: >--- >at-spi-dbus-bus.service >emacs.service >evolution-addressbook-factory.service >evolution-calendar-factory.service >evolution-source-registry.service >evolution-user-prompter.service >gnome-shell.service >gnome-shell-wayland.target >gnome-shell-x11.target >thunar.service >xfce4-notifyd.service >--- >I guess those are missing some --with-systemduserunitdir switch or so. Yes, that is the correct fix (with =no). --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Since changes are coming...
On June 23, 2019 4:55:23 PM CDT, Joe Locash via blfs-dev wrote: >Is there any interest in adding MATE to BLFS? I have it working, just >tweaking the minor issues out. I don't know if there is enough demand for the book, but I would suggest putting it into the wiki to start. As Bruce mentioned, another DE is a bit much for current editors to maintain, and maintaining a patch set for the book, long term, is undesirable for many reasons. Take a look at the qemu wiki entry for an example format if interested. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Major changes to System V BLFS are coming
On 6/22/2019 11:05 AM, Pierre Labastie via blfs-dev wrote: Am I understanding correctly that the tarball will appear on anduin next night or so? Pierre No. Can you not just copy to /sources? If not, Bruce, what's the harm in pushing the bootscript changes now? The headers are next on my list anyway, so the version string will be changing soon regardless. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Major changes to System V BLFS are coming
On 6/21/2019 6:38 PM, DJ Lucas via blfs-dev wrote: On 6/21/2019 9:54 AM, Bruce Dubbs via blfs-dev wrote: One of the problems is that BLFS/trunk/BOOK is a moving target. DJ has been merging trunk into elogind periodically and it needs to be done again. Up to date as of now. I know a couple of security updates are coming shortly though. Whelp, in diffing I found a couple of missing commits. *Now* it's up to date. Sorry for the mishap. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] (peer review?) lfs-bootscripts-20190524, /sbin/ifup + bridge -> bug ?
On 6/10/2019 7:39 AM, Jean-Marc Pigeon via blfs-dev wrote: Let me comments on this, trying not to be mean but rather constructive. (after all, the whole LFS project purpose is to learn). Lets be blunt and summarize your previous statement as I understand it. "previous script incarnation are messy, I have problems with message cosmetic entries, such lets add a a variable (VIRTINT) to configuration STANDARD to help me write code). Then in the 20190524 iteration, ifup code become such: # If interface ISNOT virtual then configure interface # prepare interface # if interface IS virtual then configure interface. May I suggest (as it was previously) # prepare interface # configure interface If I'm correctly understanding your comments above, you've misinterpreted the first if block in the original script (lending credit to my assertion of needless complexity). Please try and single step through it once for a virtual interface and take note of the unneeded call to up(). The logic you applied to the new script is ultimately exactly how the old worked as well, and this is how it needs to be. You can't set up an interface if it doesn't yet exist. The method of determining if it is a virtual interface has changed to explicitly stating so, avoiding that unnecessary call to up(), and the expensive test that also leads to unnecessary redirection and several unnecessary 'echo \n' invocations that made the downstream scripts more complex than they needed to be. I could simply end the output (accurately stating that the interface was set UP, and so I did. There is still room for improvement in that regard, I could probably kill a few of the 'echo -n' as well, and it was only reduced by a couple of empty messages anyway, but it's better than it was, and presentation is now consistent with the rest of the scripts (the original reason that I looked at it). From above, I am unable to determine if you are still having a problem after you've set VIRTINT to yes as requested. If there is still a problem after correcting your configuration for the new script, then I do need to address that error. Additionally, if you can suggest a better way to test (preferably a test that we don't have to dump the result and do the echo \n thing again), I could reconsider the additional variable if it's really a big deal, but please understand that I view this as static data, something that does belong in the configuration rather than being tucked away in difficult to read logic. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] lfs-bootscripts-20190524, /sbin/ifup + bridge -> bug ?
On 6/9/2019 3:45 PM, Jean-Marc Pigeon via blfs-dev wrote:
Hello,
/sbin/ifup was changed between lfs-bootscripts-20180820
and fs-bootscripts-20190524
Sequence
;---
# Bring up the interface
if [ "$VIRTINT" != "yes" ]; then
up ${IFACE}
fi
for S in ${SERVICE}; do
;---
This cause trouble in case you have defined a bridge interface.
(a bridge interface is now a virtual one?),
as the bridge can NOT be UP before service bridge define it.
There is a kind of discrepancy between
line 99:
if [ "$VIRTINT" != "yes" ]; then
up ${IFACE}
and line 122:
if [ "${VIRTINT}" == "yes" ]; then
up ${IFACE}
Comments??
This was answered in a private thread, but repeating here in case it
comes up again. For any virtual interfaces, you need to add
"VIRTINT=yes" to the configuration. This is to avoid a couple of
problems with the earlier incarnations of this script (and Beyond BLFS
scripts). The order of operations has changed a bit to avoid the
unnecessary boot_mesg*2 cosmetic entries and disposing of the bad return
value, as well as bringing up a virtual interface before it is
configured by the service (and to fix a couple of other odd corner cases).
HTH
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Replace PyCrypto with PyCryptodome
Mostly so that I don't forget... PyCryptodome is a fork of the bitrot that is PyCrypto. It installs in $PYTHONDISTROPATH/Crypto (or optionally Cryptodome if both are desired for some odd reason, just grab v3.8.2x.tar.gz instead). https://github.com/Legrandin/pycryptodome/archive/v3.8.2.tar.gz Note that you may need to update requirements.txt to use it instead of PyCrypto (append 'dome'). --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libcap instruction
On 5/30/2019 2:56 AM, Thomas Trepl via blfs-dev wrote: Hi all, shouldn't the very last instruction in libcap read as tail -n +3 /etc/pam.d/system-auth.bak >> /etc/pam.d/system-auth instead of tail -n +3 /etc/pam.d/system-auth.bak << /etc/pam.d/system-auth (I can fix it, just want to be sure that its correct) Whoops. Fixed in r21637. Sorry about that and thanks for the catch. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Modification for /etc/profile and /etc/bashrc
Something I've been carrying for a long time to make it obvious that I'm using a remote or screen session. Anyone think this would be a useful addition to the book? # Setup different prompt colors for local/remote and root/non-root users NORMAL="\[\e[0m\]" RED="\[\e[1;31m\]" GREEN="\[\e[1;32m\]" YELLOW="\[\e[1;33m\]" MAGENTA="\[\e[1;35m\]" CYAN="\[\e[1;36m\]" # Set local prompt color if [[ $EUID == 0 ]] ; then if [[ $TERM == "screen" ]] ; then PS1="$RED\u [ $NORMAL\w$RED ] (screen)# $NORMAL" else PS1="$RED\u [ $NORMAL\w$RED ]# $NORMAL" fi else if [[ $TERM == "screen" ]] ; then PS1="$YELLOW\w [ $NORMAL\w$YELLOW] (screen)\$ $NORMAL" else PS1="$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL" fi fi # Set remote prompt if [[ "$SSH_CLIENT" != "" ]] ; then if [[ $EUID == 0 ]] ; then if [[ $TERM == "screen" ]] ; then PS1="$MAGENTA\u@\h [ $NORMAL\w$MAGENTA ] (screen)# $NORMAL" else PS1="$MAGENTA\u@\h [ $NORMAL\w$MAGENTA ]# $NORMAL" fi else if [[ $TERM == "screen" ]] ; then PS1="$CYAN\u@\h [ $NORMAL\w$CYAN ] (screen)\$ $NORMAL" else PS1="$CYAN\u@\h [ $NORMAL\w$CYAN ]\$ $NORMAL" fi fi fi -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind branch update
On May 19, 2019 11:01:08 AM CDT, Bruce Dubbs via blfs-dev wrote: >On 5/19/19 12:00 AM, DJ Lucas via blfs-dev wrote: >> I had stepped away for some time and the branch had become stale. The > >> diff is now considerably smaller, and Gnome and GDM are working with >> elogind in both X11 and Wayland environments. I do plan to continue >down >> this path, but it is still slow going. I have yet to get the policy >> stuff done for power management (can't shutdown or suspend from the >> GUI), but it seems to be mostly functional at this point. The one >> outstanding issue is Gnome policy agent looking for CK, but I expect >> this is an artifact of the prior build method (possibly in >> account-service rather than the pk agent itself). Though the branch >has >> been updated, if anybody is still interested in just the changes, >> updated patch sets (since the changes are much smaller now) are >located at: >> >> http://www.linuxfromscratch.org/~dj/BLFS-elogind-20190519.diff >> and >> http://www.linuxfromscratch.org/~dj/bootscripts-elogind-20190519.diff >> >> No changes are required to the base LFS build, but please keep in >mind >> that I have not yet tested with latest SVN - I was working from a >late >> February build - but I don't foresee any major issues with the >changes >> that have gone in since. > >Thanks for that DJ. I built the elogind version of the book and have a > >couple of questions. > >There are still a few packages that refer to consolekit: lxdm, >xfce4-session, lxsession, lxde-common, and gparted. Does elogind and >consolekit conflict? > No they are not conflicting, but should be able to do without CK for them at some point. >In xorg-server, why is elogind recommended? Isn't it only needed if >you >want to build gnome? Same question for polkit and network-manager and >pulseaudio and dbus. > Exactly. But as above, ultimately it'll negate the need for CK by putting the power features on the bus. Perhaps optional, but required for Gnome is more appropriate. Still fuzzy at this point because I didn't touch the other DEs yet. Just wanted to make sure it doesn't get lost since I'm slow. >Also, there are several package updates needed for LFS and I will be >doing all those later today except dbus and systemd. I do not think >that any of those will affect elogind. Shouldn't, I started a new automated build last night, but haven't been able to check on it yet. -- DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] elogind branch update
I had stepped away for some time and the branch had become stale. The diff is now considerably smaller, and Gnome and GDM are working with elogind in both X11 and Wayland environments. I do plan to continue down this path, but it is still slow going. I have yet to get the policy stuff done for power management (can't shutdown or suspend from the GUI), but it seems to be mostly functional at this point. The one outstanding issue is Gnome policy agent looking for CK, but I expect this is an artifact of the prior build method (possibly in account-service rather than the pk agent itself). Though the branch has been updated, if anybody is still interested in just the changes, updated patch sets (since the changes are much smaller now) are located at: http://www.linuxfromscratch.org/~dj/BLFS-elogind-20190519.diff and http://www.linuxfromscratch.org/~dj/bootscripts-elogind-20190519.diff No changes are required to the base LFS build, but please keep in mind that I have not yet tested with latest SVN - I was working from a late February build - but I don't foresee any major issues with the changes that have gone in since. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Update mozjs-60 version (?)
On 5/11/2019 1:29 AM, Xi Ruoyao via blfs-dev wrote: Hi folks, Now BLFS is using mozjs-60 package from ftp.gnome.org. But it's the "original" mozjs-60.1.0 without any update. Arch is now using latest mozjs-60.6.3, even Ubuntu is using a newer mozjs-60.2.3. I downloaded Firefox ESR 60.6.3 code and removed everything unrelated to JS engine I could find. Then I built and installed mozjs-60.6.3 into my system. I found my GNOME was broken but I could rebuild Gjs to fix it. The extracted mozjs-60.6.3 tarball (it's just a Firefox tarball with many directories removed) has been uploaded to: http://www.linuxfromscratch.org/~xry111/mozjs-60.6.3.tar.xz Now, is it worthy to update mozjs-60 version in BLFS book, following Firefox ESR 60? Yes. Undoubtedly. It should likely be pulled from Mercurial and packaged by BLFS (or just reuse the ESR tarball). If you want to pull from hg, I believe this is the correct repo: https://hg.mozilla.org/releases/mozilla-esr60 As to Doug's concern that users will have to rebuild GJS... IMO, it really should not be a concern. Add a warning and remove it at release time. If it is not read, then it isn't read. The information is presented, and can easily be recalled on support lists. The users are using an unreleased book and know that they take that risk. It simply teaches a valuable lesson, one that I often need a reminder of (as I suspect others do as well). :-) OT: "remove it at release" - We should consider creating a profile to automate release things for the release manager. Build the bootscripts and udev tarballs, correct links to svn, exclude notes like above, etc. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21576 - trunk/BOOK/networking/netlibs
On 5/11/2019 8:36 AM, Xi Ruoyao via blfs-dev wrote: Yes it is needed. Nobody wants to remove it from the book. But if a package *can* be built with autotools or meson, why should we build it with cmake and introduce a hard dependency? This deserves a bit more consideration. What are the devs doing with this package? ISTR that the devs made a conscious choice to move to cmake. I do not know whether that means that autotools support is going away (admittedly, many times it does). OTOH, as long as autotools support is still current, then why not reduce the dependencies?IMO, the change, or more importantly, the reason for the change, is sound - the only issue here is that it likely should have been discussed before hand to avoid the initial reaction that prompted this thread. Generally speaking, you should prefer to use the newer build tools, if possible, as they are likely the more supported/current variant, but this is the outlier. A comment in the source with rationale is a good idea here. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [systemd] Add a warning about /run/nologin in shadow (Was: [blfs-book] r21579 - trunk/BOOK/postlfs/security)
On 5/11/2019 1:48 AM, xry111--- via blfs-book wrote: Modified: trunk/BOOK/postlfs/security/shadow.xml == --- trunk/BOOK/postlfs/security/shadow.xml Fri May 10 13:25:39 2019 (r21578) +++ trunk/BOOK/postlfs/security/shadow.xml Fri May 10 23:48:04 2019 (r21579) @@ -477,6 +477,19 @@ rm -f /run/nologin + + +If you are building Shadow with Linux-PAM, +you should install before rebooting. +Or the old systemd installed in LFS will +create /run/nologin at next boot and stop you +from login into the system. If you really need to reboot before +installing systemd, the configuration +line containing pam_nologin.so +must be removed from /etc/pam.d/login. + + + At this point, you should do a simple test to see if I had worked around this in LFS a long time ago. I created /lib/systemd/systemd-user-sessions with nothing more than 'rm -f /run/nologin' as it will be replaced when systemd is reinstalled in BLFS. Is this no longer working? If not, the note certainly does not hurt, in fact, it is helpful to explain this behavior, but I think that the issue should also be corrected here, possibly even move the addition in LFS to here. We need to tell the system that user sessions are ready (in this minimal configuration, they actually are despite systemd not being aware of this - we have to make it aware by removing the file). I understand that this needs to have a caveat of "Do not do this if you've already reinstalled systemd." Note that the root user can always login, regardless of /run/nologin. Thoughts? --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Is initd-tools supposed to be in the systemd book?
On 5/3/2019 11:55 PM, Tim Tassonis via blfs-dev wrote: So, as you say, the scripts should be adjusted to move every occurrence of $remote_fs from Required-Start: to Should-Start: ? Only having recently started to look at SysV again, I haven't had a whole lot of time to look at BLFS bootscripts just yet. I've got some outstanding changes for LFS that I need to bring up, but haven't had the time just yet. But to answer your question, exactly. $remote_fs should only appear in the Should-Start array. I suspect that the $network facility was the intend entry for Required-Start on those scripts, but no guarantee, as I have not looked in detail. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Is initd-tools supposed to be in the systemd book?
On May 1, 2019 5:30:13 PM CDT, Tim Tassonis via blfs-dev wrote: >On 5/1/19 10:52 PM, Pierre Labastie via blfs-dev wrote: Well, I didn't know that systemd could use sysv bootscripts... So >my question is irrelevant. OTOH, this package needs LSB conform bootscripts, >which ours in the SysV book are not... Did they change something in LSB that made them incompatible? That was the entire point of the rewrite - well that and fixing some stuff in early rc (early boot logging, interactive boot, etc.). >and nm has: > ># Provides: networkmanager ># Required-Start:dbus udev ># Required-Stop: dbus ># Default-Start: 3 4 5 ># Default-Stop: 0 1 6 Runlevel 2 is multiuser without networking, nm should stop in rl2, and $remote_fs does not make sense here, but to be compliant, the install prefix for nm should be /, not /usr/ -- remote /usr is an almost impossible goal nowadays, but I believe this is still not FHS compliant for that reason, unless they've relaxed that requirement as well with the merged /usr stuff. > > >after my edits... > >It originally has: > ># Provides: networkmanager ># Required-Start:$remote_fs dbus udev ># Required-Stop: $remote_fs dbus udev ># Default-Start: 2 3 4 5 ># Default-Stop: 0 1 6 > > >In my scripts, I took out all level 2 references and all $remote_fs >stuff, as I don't have nfs installed on all systems and $remote_fs >should really not be a hard dependency for any package. > No, never required, but it should almost always be a soft dep where BLFS is concerned (see below). >This is not the fault of init-tools, but no service should rely per >default on a running nfs-client service. No idea how that got in. $remote_fs != nfs nfs provides nfs, netfs provides $remote_fs, that's how it got in, and is correct for everything that is not pre network available in BLFS. Should-start: $remote_fs should appear in *every* script that starts a daemon that is installed in /usr to allow for the possibility of a shared /usr. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] vsftpd: hard-coded absolute path to PAM module?
On 3/26/2019 1:46 PM, Xi Ruoyao via blfs-dev wrote: Hi all, In r17441 DJ added PAM support to vsftpd. But when I was installing it I found a hard-coded absolute path to PAM module: auth required /lib/security/pam_listfile.so item=user sense=deny \ file=/etc/ftpusers \ onerr=succeed But OTOH pam_shells.so doesn't have an absolute path: auth required pam_shells.so So is this absolute path intentional or an oversight? It's an oversight. I probably copied it directly from the included example and forgot to kill the path. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-support] Make-ca errors
On 2/23/2019 3:54 AM, Ken Moffat wrote: > On Sat, Feb 23, 2019 at 09:32:18AM +, DJ Lucas via blfs-support wrote: >> On 2/23/2019 3:14 AM, Ken Moffat via blfs-support wrote: >>> I had a reply off-list suggesting that I try without the local cert >>> directory. So I renamed that, and retried. Running make-ca -g >>> succeeded but told me that the certs were up to date. Running make-ca >>> -f succeeded, the final output was: Certificate: Global Chambersign >>> Root - 2008 Keyhash: 0c4c9b6c Added to p11-kit anchor directory with >>> trust 'C,C,'. Extracting OpenSSL certificates to >>> /etc/ssl/certs...Done! Extracting GNUTLS server auth certificates to >>> /etc/pki/tls/certs/ca-bundle.crt...Done! Extracting GNUTLS S-Mime >>> certificates to /etc/pki/tls/certs/email-ca-bundle.crt...Done! >>> Extracting GNUTLS code signing certificates to >>> /etc/pki/tls/certs/objsign-ca-bundle.crt...Done! Extracting Java >>> cacerts (JKS) to /etc/pki/tls/java/cacerts...Done! And running links >>> to an https: site from chroot now works. I'll keep this around for a >>> bit in case you are replying to my earlier reply, but I need to sort >>> out some food, then I'll probably go shopping and then wind down and >>> go to bed. >> Bad cert in the /etc/ssl/local directory caused that to cascade like >> that? I can't see how, but I'll have to figure it out. If you still have >> it around and it's not too much trouble (and nothing private in >> /etc/ssl/local), could you tar up the contents and send, or is it just >> the example cacert.org certs? >> --DJ >> > I don't have any current use for local certs, I was just trying to > follow the book. Maybe something in what I thought I had copied > from the book is wrong. So here is the commented-out part. KM_LOG > points to my log for this package, and apologies if I've mis-pasted > or failed to update this and wasted your time. > > > #install -vdm755 /etc/ssl/local >$KM_LOG 2>&1 > #wget http://www.cacert.org/certs/root.crt >>$KM_LOG 2>&1 > #wget http://www.cacert.org/certs/class3.crt >>$KM_LOG 2>&1 > #openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" > \ > #-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning > \ > #> /etc/ssl/local/CAcert_Class_1_root.pem >>$KM_LOG 2>&1 > #openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 > root" \ > #-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning > \ > #> /etc/ssl/local/CAcert_Class_3_root.pem >>$KM_LOG 2>&1 > > But, looking at the contents: clearly wget has failed. > > -rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_1_root.pem > -rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_3_root.pem > Is there something more pertinent out there? In addition to those, I install the US military CAs and intermediates, but that's a mess of 111 certificates and a nasty script in and of itself (I just cleaned it up and pushed it to http://www.linuxfromscratch.org/~dj/get-us-gov-certs.sh if anybody needs them). I think we should just drop the example all together, and leave the instructions in the man page. I figure for better than 99% of our users, the Mozilla CAs are sufficient. Only a handful of users would want to do overrides or append for local use cases. Even Windows domains (if named properly) can use LE certs. Any objections? --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
