SliTaz Forum
You are not logged in.
Pages: 1
Foreword
I continue to work on compiling Xorg. Step by step. Using BLFS book, SliTaz receipts and Xorg FTP mirror.
The order of compiling packages I take from the book. The latest versions of packages I find myself on the mirror. I find dependencies, analyzing files configure.ac and cook output. I take the descriptions from the files *.pc.
I do not know who came up with that in the receipt should be specified a license. It is easy to point out that the license of, say, GPL3. But! As part of Xorg there is no package with the "regular" license. Therefore, the license must include in the package. This is extra 1-20 kilobytes. I decided to put the license into the dev-packages if they are available.
In general, I lead a certain job. And as long as I like it.
Finally, a question on the topic.
The begin of typical Xorg package:
[c]________________________________________
# SliTaz package receipt.
PACKAGE="xorg-libXi"
VERSION="1.7.2"
CATEGORY="x-window"
SHORT_DESC="Xorg library for the X Input Extension."
MAINTAINER="pankso@slitaz.org"
SOURCE="libXi"
TARBALL="$SOURCE-$VERSION.tar.bz2"
WEB_SITE="http://www.x.org/"
WGET_URL="$XORG_MIRROR/lib/$TARBALL"
________________________________________[/c]
Why do I need an extra variable SOURCE?
I removed it by writing the following:
[c]________________________________________
PACKAGE="xorg-libXi"
. . .
TARBALL="${PACKAGE#xorg-}-$VERSION.tar.bz2"
________________________________________[/c]
I believe that this is an elegant and versatile solution!
But, please, someone tell me, what is it?? — http://hg.slitaz.org/wok/rev/5ddb4d29b420
Author of this commit is Christopher Rogers. I immediately wrote him a letter, but, unfortunately, did not get any response.
Any tips? My receipts compiled just fine without the variable SOURCE.
Maybe this is some outdated rule?
OK, lets see [c]cook[/c] script: http://hg.slitaz.org/cookutils/file/f66c5d0bbc67/cook
Search for "SOURCE".
[c]pkgsrc="${SOURCE:-$PACKAGE}-${KBASEVER:-$VERSION}"[/c]
We can use SOURCE or PACKAGE variables, and SOURCE have precedence.
[c]if [ "$SOURCE" ]; then
source_stuff=$WOK/$SOURCE/stuff
fi[/c]
And some next lines, where variable SOURCE used the same way as in the line 145 (so, we can use $SOURCE or we are free not to use it).
___________________
I would like to hear the answer from Christopher. But, as I will be glad to anyone who shed at least some light on this question.
Offline
$SOURCE was helpful with tazwok (up to SliTaz 3.0) to match the path into the $TARBALL file
see http://hg.slitaz.org/tazwok/file/184ca30503fe/tazwok#l334
Now cook extracts the $TARBALL in a temporary directory and move the tree in a normalized directory
see http://hg.slitaz.org/cookutils/file/f66c5d0bbc67/cook#l661
@Aleksej
I think that your first commit was correct. Asking questions, open discussion, searching into cook code is a good way to wok.
@Christopher
Not sure break other people work without explanation is a good idea.
Offline
Thank you, Pascal!
Its hard to me to understand second link. I know a bit about unpacking of some weird archives.
May I ask you one more question about Xorg?
I try. Package xorg-libXfont. File wok/xorg-libXfont/install/usr/lib/pkgconfig/xfont.pc
[c]________________________________________
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Xfont
Description: X font Library
Version: 1.4.5
Requires: xproto fontsproto
Requires.private: fontenc freetype2
Cflags: -I${includedir}
Libs: -L${libdir} -lXfont
Libs.private: -lz -lm
________________________________________[/c]
What mean last line?
I know -l is for libraries.
Maybe, -lz is for libz (package zlib-dev), and -lm is for libm (package glibc-dev)?
/usr/lib/libz.a
/usr/lib/libm.a
So, I add "zlib-dev glibc-dev" to the dependencies of "xorg-libXfont-dev" package. Am I right? (Not sure about glibc-dev.)
Offline
Continuing the theme, if anyone interested.
Aleksej Bobylev (June 2, 2013, 13:38):
Hi Christopher!
Tell me, please,
for what You need SOURCE variable in the xorg-bigreqsproto receipt?
It compiles greatly without this variable, do you saw cooking log before?
Waiting for Your explaination.
Christopher Rogers (June 3, 2013, 11:20):
$SOURCE : It may be that the Tazpkg package name differs from the name of the source package. Example for Xorg packages, the name of Tazpkg library X11 is 'xorg-libX11' and the name of the package source is libX11. $SOURCE allows you to use the variables $src and $install during the cooking of a package. It should be noted that in the case of libX11, the name of the source archive becomes $SOURCE-$VERSION.tar.gz.
Thats from the slitaz docs. This is also ment to keep receipts clean.
Aleksej Bobylev (June 3, 2013, 11:44)
Hi!
I think, SOURCE useful only in re-using of sources tarball, when two different packages used single sources. For example, PACKAGE="slim-pam"; SOURCE="slim"
In this case we not define TARBALL and WGET_URL and can use sourcestuff (name from my memory) variable.
In case of Xorg packages, both of our method are clear and only choice of taste.
Bye!
Then this commit: xorg: Use SOURCE Variable Aleksey. from Christopher Rogers, of course. I do not like this perseverance. My "hot" response:
Aleksej Bobylev (June 3, 2013, 12:41):
Do you want begin a war?
Stop to break my receipts!
Read forum before, and ask there.
Bye.
What are you gonna do with him?! 
It seems that he does not read our forum. And he does not like to respond to the letters. And, most of all, not at all understands the work of the cook...
Offline
1) I post that commit 4 hours before i email you if i remember correctly. The time on the commit supports that theory anyways saying its 6:58am on june 3. So that comment was there for a while.
2) The license was something i started in my slitaz-tank cookutils. Its only meant to be in receipt that way we can use pkgs.slitaz.org to search for licenses. Thats all that was meant for.
3) I'm having trouble seeing that i broke anything. I was checking the receipts in wok to see if SOURCE was borken in cookutils. I tested it with commit: http://hg.slitaz.org/wok/rev/7cd32b9b4e5a and found it was working fine with SOURCE variable. Thats when i made the big commit.
PS If you want to continue this you can talk with me on irc also. I don't check my email that often these days.
Offline
Hi godane,
Really glad to see you here!
I want you to know not only "letter" of cook, but it "spirit". Please, review cook sources - you'll see that we can not use SOURCE in our case.
If you use it, know next. Let's say, PACKAGE="xorg-libX11"; SOURCE="libX11". This mean that package "xorg-libX11" uses sources from package "libX11", but its wrong! We have no "libX11" package!
Plus simple rule for TARBALL name: drop "xorg-" from beginning of PACKAGE name. One simple universal rule for ALL Xorg packages.
Not, really you not broke any package's building. You just broke receipt itself, its clearness. You know that package receipt have some variable definitions. If you swap all these variables, then package still builds. But I think, this receipt some sort of "broken", "dirty" and "unclear" for human's reading.
Offline
Sorry, can't write long messages from smartphone.
About timestamps of my Hg commits. Sorry, its wrong. I have dual-booted netbook, RTC is set to local time. Plus, I have default /etc/TZ (UTC, eh?). So, my commits are always "in the future".
About licenses. Maybe, I'm first who begin to fill it in the receipts. Possibly, I use it wrong. I know that deb packages have licenses inside. But, why I need to clone GPL3 license for all some hundred packages? I just wrote in the receipt "GPL3". And I have file in /usr/share/licenses with text of GPL3 in it. But every Xorg package have its own "weird" or "proprietary?" license. Should I include its text into package? I do it. And, please, review cook source for licenses: we can have license in the $stuff folder.
Offline
We should normalize LICENSE content (and tags btw) : http://pkgs.slitaz.org/search.sh?tags=#license
@Aleksej: SOURCE has nothing to do with WANTED
Offline
@Bellard I think you mean SOURCE has noting to do with PACKAGE. WANTED is only found on your post.
@Aleksej I don't get how do $(PACKAGE#xorg-} is 'clean' by you. Its dirty to me cause SOURCE worked. It was not broken so there was no need to fix it. Also I use the slitaz-tank branch of cookutils so it may be picky about things. I don't want anything more on my end to break. I was hoping to merge my wok-tank fork with wok. But i see that not going to happen anyways with things like this.
So i decide to quit for now. I don't see the fun in doing this anymore if i have to keep fight just over basic syntex problems. Thank you Aleksej for me this so clear to me.
Offline
Hi godane,
I don't need a war. And I do not want to be your personal enemy. I give up.
Ok, I'll use SOURCE in Xorg packages.
Can you tell me more about differences in the "slitaz-tank branch of cookutils" and "wok" versions. Just curious.
Offline
2Bellard:
We should normalize LICENSE content
Long time ago I wrote receipt for "licenses" package. Now I push it to the wok here.
So, here are listed "main" licenses: GNU and Mozilla.
[*]GPL or GPL3 — is a latest GNU General Public License (version 3);
[*]LGPL or LGPL3 — is a latest GNU Lesser General Public License (version 3);
[*]LGPL2 — is a latest GNU Library General Public License (version 2.0);
[*]AGPL or AGPL3 — is a latest GNU Affero General Public License (version 3);
[*]FDL or FDL1.3 — is a latest GNU Free Documentation License (version 1.3);
Old versions:
[*]for GPL3: GPL2 and GPL1;
[*]for lesser LGPL3: LGPL2.1;
[*]for FDL1.3: FDL1.2 and FDL1.1.
Mozilla licenses: MPL2 and MPL1.1.
Here another popular licenses: Creative Commons license: CC-BY, CC-BY-SA, CC-BY-ND, CC-BY-NC, CC-BY-NC-SA and CC-BY-NC-ND.
_____________________________________
Examples of abbreviation use:
[*]on Sourceforge (GNU General Public License version 2.0 (GPLv2)) see here.
[*]on Launchpad (GNU GPL v3) see here.
_____________________________________
More about licenses on Wikipedia: http://en.wikipedia.org/wiki/Open-source_license http://ru.wikipedia.org/wiki/Лицензия_open_source
I am pleased to hear your opinion if this will be.
Offline
The wok-tank as i call is more up to date then current wok. But of course i have not been doing much update or compile as of lately. The cookutils slitaz-tank branch tries to be able to build a full slitaz distro like LFS. I also add stuff like library.list file into package so you know the .so files needed for packages to work.
You can check the source here: http://hg.slitaz.org/cookutils/shortlog/99372fa1d17e
The idea of this was to have something like LFS+BLFS but to have a live linux distro autobot all of it with package support. And this is meant to work offline when doing to compiling. Anyways I'm still calling it quits on slitaz. I just can't do it anymore on my own.
I'm part of ArchiveTeam now and i don't normally have time to look at my wok-tank or cookutils anymore.
Offline
2godane: I also made a few changes to the Cook. For example, "--cdeps" for defining of package's dependencies. It's useful only for local work, not for server.
My skill is too low to work with different Hg branches. I can do commits only to master branch.
I want to finish "cdeps" feature, and add auto-shrink of BUILD_DEPENDS...
But, please answer me, how can I do it now? Would not "my" version interfere with "your"?
Offline
Your not going to interfer with my code by adding stuff to default branch. If that was the case you would have broke it by now. Also if you want to look at the do hg update slitaz-tank. Want to go back to default branch do hg update default. This should help you explore it for now. Also do this in a clean repo without modified files. I just don't want to help how your code was delete by a 'hg update slitaz-tank'.
Anyways see you tommorrow.
Offline
Guys, sorry, I can't continue. I found depends loop and can't yet solve it. To build "xorg-libxkbfile" we need "xorg-libxkbfile".
[c]xorg-libxkbfile
└───xorg-libX11-dev
├───xorg-libX11
│ └───libxcb
│ ├───xorg-libXau
│ └───xorg-libXdmcp
├───xorg-xtrans
│ └───xorg-xproto
│ └───xorg-util-macros
├───libxcb-dev
│ ├───libxcb
│ │ ├───xorg-libXau
│ │ └───xorg-libXdmcp
│ ├───xorg-libXau-dev
│ │ ├───xorg-libXau
│ │ └───xorg-xproto
│ │ └───xorg-util-macros
│ └───xorg-libXdmcp-dev
│ ├───xorg-libXdmcp
│ └───xorg-xproto
│ └───xorg-util-macros
├───xorg-kbproto
│ ├───xorg-xproto
│ │ └───xorg-util-macros
│ └───xorg-libxkbfile-dev
│ └───█xorg-libxkbfile█
├───xorg-inputproto
│ └───xorg-xproto
│ └───xorg-util-macros
└───xorg-xextproto
└───xorg-util-macros[/c]
Offline
Christopher Rogers, commit:
xorg-kbproto: Fixed depends but making it only xorg-utils-macros. It builds without xorg-xproto and xorg-libxkbfile-dev so its not needed.
You're right. And now I can't define, why I added xorg-libxkbfile-dev to depends. Maybe, because I change many sub-depends on the way.
But you're not right when you say " It builds without *** so its not needed."
Please, separate DEPENDS and BUILD_DEPENDS.
BUILD_DEPENDS is a tools to build package (shell, Python, C compiler, PHP, etc.) plus headers (where defined references to some functions contained in the DEPENDS).
So, please, correct me in next sentences. My methods to find depends and build depends:
Build depends. Xorg maintainers used autotools. First, we can just run ./configure with empty BUILD_DEPENDS and read output — what we need to write to BUILD_DEPENDS. Second, we can analise ./configure script to check what it want. Third, we can analise ./configure.ac (I guess, Xorg maintainers use small configure.ac, then they use autotools to generate ./configure before source packaging). Ok, package builds. Now we can shrink long list of build depends.
Reading configure.ac for "xorg-libxkbfile" (see graph abowe) we found build depends: xorg-macros 1.8 or later; x11; kbproto. Translate pc-names to package names: xorg-util-macros, xorg-libX11-dev, xorg-kbproto. Shrinking leaves only xorg-libX11-dev.
Now I need to define DEPENDS. Now I just use my tool:
[c]cook xorg-libxkbfile --cdeps
glibc-base
libxcb
xorg-libX11
xorg-libXau
xorg-libXdmcp[/c]
It just uses ldd and find where (in which packages) it can found needed libs. Shrink this list: just xorg-libX11.
Now build *-dev package. It contains /usr/include/headers; /usr/lib/pkgconfig/file.pc; /usr/lib/file.la.
1. Headers files. Optional step. Check *.h files for includes:
/usr/include/XKMformat.h:
#include <X11/extensions/XKB.h>
#include <X11/extensions/XKBproto.h>
#include <X11/extensions/XKM.h>
Found files using pkgs.slitaz.org or custom tool.
First line: xorg-kbproto
Second line: xorg-kbproto
Third line: xorg-libxkbfile-dev (package itself).
So, depends for dev-package on this step is: xorg-kbproto.
2. *.pc file:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: xkbfile
Description: The xkbfile Library
Version: 1.0.8
Requires: kbproto
Requires.private: x11
Cflags: -I${includedir}
Libs: -L${libdir} -lxkbfile
Lines begin with "Requires": kbproto, x11.
So, depends for dev-package on this step is: xorg-kbproto and xorg-libX11-dev.
3. /usr/lib/libxkbfile.la:
# Libraries that this one depends upon.
dependency_libs=' /usr/lib/libX11.la /usr/lib/libxcb.la /usr/lib/libXau.la /usr/lib/libXdmcp.la -ldl'
Find files: xorg-libX11-dev, libxcb-dev, xorg-libXau-dev, xorg-libXdmcp-dev.
4. Summarize three steps above: xorg-kbproto xorg-libX11-dev libxcb-dev xorg-libXau-dev xorg-libXdmcp-dev. Shrink: just xorg-libX11-dev.
So, depends for xorg-libxkbfile-dev is "xorg-libxkbfile xorg-libX11-dev".
Offline
Pages: 1
[ Generated in 0.020 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]