slackbuilds.net - Slackware

This is a discussion on slackbuilds.net - Slackware ; > > You say that gnome minimal fail to build? Have you see this in the > > build script? > > > > > > # *MODIFY THIS VARIABLE!* Normal user account (eg /home/your-user/) > > USER=hitek > > ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 46

Thread: slackbuilds.net

  1. Re: slackbuilds.net

    > > You say that gnome minimal fail to build? Have you see this in the
    > > build script?
    > >
    > >
    > > # *MODIFY THIS VARIABLE!* Normal user account (eg /home/your-user/)
    > > USER=hitek

    >
    > Yeah, sure, I saw it. But when I tried it (maybe 2 months ago), some
    > of the source directories were badly symlinked, and I just didn't
    > have the heart to correct all that manually. Maybe it's been
    > corrected since.


    hi Niki,

    you use svn depot, and svn is a devellopement branch. I try it, it failed. I
    talk about it in the forum, and 2 days laters all works fine. Did you do it ?


    PS : is my message, responding to this thread, where I talk about sb.net too is
    passed ? The one where I begin by : "I can, I see it born and I use it daily.
    On SBn all scripts are also
    packaged in /usr, and man pages are gzip, binaries and some libraries are ..." ?
    My nntp server seems to have matter. thx


  2. Re: slackbuilds.net

    > > You say that gnome minimal fail to build? Have you see this in the
    > > build script?
    > >
    > >
    > > # *MODIFY THIS VARIABLE!* Normal user account (eg /home/your-user/)
    > > USER=hitek

    >
    > Yeah, sure, I saw it. But when I tried it (maybe 2 months ago), some
    > of the source directories were badly symlinked, and I just didn't
    > have the heart to correct all that manually. Maybe it's been
    > corrected since.


    hi Niki,

    you use svn depot, and svn is a devellopement branch. I try it, it
    failed. I talk about it in the forum, and 2 days laters all works fine.
    Did you do it ?


    PS : is my message, responding to this thread, where I talk about
    sb.net too is passed ? The one where I begin by : "I can, I see it
    born and I use it daily. On SBn all scripts are also
    packaged in /usr, and man pages are gzip, binaries and some libraries
    are ..." ? My nntp server seems to have matter. thx


  3. Re: slackbuilds.net

    Manuel Reimer wrote:
    > If a script fails to execute with fakeroot, then you may fix it and post
    > the fix to the mailing list. I'm sure the fix will be added.


    The fix is to accept that you are wrong and that you should do what
    slackbuild.net does.
    Only chown and makepkg are done with fakeroot:

    PACKAGING="
    chown root:root . -R
    /sbin/makepkg -l y -c n $OUT/$NAMETGZ-$VERSION-$ARCH-$BUILD.tgz
    rm -rf $PKG
    rm -rf $TMP/$NAME
    "
    if type -p fakeroot ; then
    echo "$PACKAGING" | fakeroot
    else
    su -c "$PACKAGING"
    fi


    see http://wiki.slackbuilds.net/exemple

  4. Re: slackbuilds.net

    Jérôme PRIOR wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    >>> You say that gnome minimal fail to build? Have you see this in the
    >>> build script?
    >>>
    >>>
    >>> # *MODIFY THIS VARIABLE!* Normal user account (eg /home/your-user/)
    >>> USER=hitek

    >> Yeah, sure, I saw it. But when I tried it (maybe 2 months ago), some
    >> of the source directories were badly symlinked, and I just didn't
    >> have the heart to correct all that manually. Maybe it's been
    >> corrected since.

    >
    > hi Niki,
    >
    > you use svn depot, and svn is a devellopement branch. I try it, it failed. I
    > talk about it in the forum, and 2 days laters all works fine. Did you do it ?
    >


    But I read on http://www.slackbuilds.net/AutoIndex/index.php that the
    FTP access is simply a snapshot of the SVN made of a regular basis and
    not a release. The explanations suggests that the svn branch is no more
    stable that the FTP access. Do I miss something?

    Olive

  5. Re: slackbuilds.net

    Le Mon, 03 Dec 2007 14:37:18 +0100, Olive a écritÂ*:
    >
    > Instead of dual booting; you can use chroot. You type chroot /newroot
    > and you are in the other installation. I often do that to chroot in
    > another distribution. Correctly configured (you have to take care of the
    > /proc /dev /sys as well as some permissions); you can launch about
    > anything in the chroot including 3D apps. This approach is much more
    > convenient than to dual boot. But this is a little of this thread; we
    > can start a new thread on this subject if someone is interested.


    Again, thanks for the advice. But it's a bit missing the point.

    1) The Sandbox is what it should be: a sandbox. An environment to try out
    things, especially those liable to create havoc on my system.

    2) The Buildbox is what it should be: a buildbox. A clean install of
    Slackware, only serving one single purpose: build my own set of packages
    cleanly, in order to distribute them on a series of production machines
    here. No more, no less.

    It's like in real life: there's no sense mixing a playground and a
    parking area for military vehicles D

    >
    > I do not consider P.V. as a "King". He is the maintainer of Slackware
    > not a divinity. This approach to build as root is something that I do
    > not like but as a whole I still prefer Slackware to other distributions
    > especially because there is no tons of patches making the software
    > unstable and because I can just configure and tweak my systems without
    > having take care of a Debian/Ubuntu/Gentoo/Whatever-way. But if someone
    > point me another distribution satisfying these two conditions; i would
    > definitively give it a try.


    In that case, I'd recommend Greg Shafer's DIY Linux (http://www.diy-
    linux.org/) and Jaguar Linux (http://www.jaguarlinux.com/). A
    perfectionist's heaven and hell D

    cheers,

    Niki

  6. Re: slackbuilds.net

    Le Mon, 03 Dec 2007 19:15:30 +0100, ciol a écritÂ*:
    >
    > The fix is to accept that you are wrong and that you should do what
    > slackbuild.net does.


    This should pretty much answer the question stated above, pondering the
    existence of no less than two distinct sites dedicated to SlackBuilds.
    The slackbuilds.org folks got all wrong, so we're gonna count ourselves
    lucky to have slackbuilds.net around.



  7. Re: slackbuilds.net

    On 2007-12-03, ciol wrote:
    >
    > Tom N wrote:
    >> On 2007-12-03, Manuel Reimer wrote:
    >>> ciol wrote:

    >> ....
    >>
    >>> /usr/local not always works. At least for libraries, this may cause
    >>> trouble.

    >>
    >> I have had many problems with libs in /usr/local/lib when building apps
    >> from source. Even though that path is in my /etc/ld.so.conf and this
    >> is where they were put during the process of building the libs from
    >> source with just ./configure, make, make install.
    >>
    >> I've ended up having to copy them to /usr/lib.
    >>
    >> (this was not in a fakeroot environment)
    >>
    >> Tom
    >>


    > man ldconfig


    -p
    Print the lists of directories and candidate libraries stored in the current cache.

    Hi ciol. I found the manpage on the web. Ran ldconfig -p and the libs in
    /usr/local/lib show up. So now I am even more confused. :-)

    But it is good to have the manpage. Thanks.

    Tom

    --
    simpleman.s43
    That would be at gee male


  8. Re: slackbuilds.net

    ciol wrote:
    >What if you have package X from slackbuild, not in slackware 12, but
    >that will be in slackware 13?


    Then won't package X be removed from /usr/local and slack 13's package
    installed in /usr when I upgradepkg?

    I'm not sure how that's different than if package X was in /usr.

    -Beej


  9. Re: slackbuilds.net

    On 2007-12-02, ciol wrote:
    > Olive wrote:
    >> I wonder why two projects are needed.

    >
    > Because slackbuilds.org does not support fakeroot (or you have to
    > execute all the script with fakeroot, which sometimes fails).



    Here's my take on that:
    http://lists.slackbuilds.org/piperma...ay/000450.html


    > Both disregard an important point though: they install in /usr by
    > default, whereas they *should* install in /usr/local (that's why PV set
    > $PATH as /usr/local:...)



    ....and I'll post this one again since it's mentioned here too:
    http://lists.slackbuilds.org/piperma...ry/000286.html

    -RW

  10. Re: slackbuilds.net

    On 2007-12-02, ciol wrote:
    > Helmut Hullen wrote:
    >> No - "/usr/local" is for my very private packets. Not for "world wide"
    >> packages close to the official packets.

    >
    > NO.
    > /usr/local is for _all_ packages which are not official.
    > What if you have package X from slackbuild, not in slackware 12, but
    > that will be in slackware 13?



    It's called upgradepkg(8)

    -RW

  11. Re: slackbuilds.net

    On 2007-12-03, ciol wrote:
    > Manuel Reimer wrote:
    >> If a script fails to execute with fakeroot, then you may fix it and post
    >> the fix to the mailing list. I'm sure the fix will be added.

    >
    > The fix is to accept that you are wrong and that you should do what
    > slackbuild.net does.
    > Only chown and makepkg are done with fakeroot:



    I have nothing against using someone using fakeroot if they
    desire, but the SlackBuilds.org project has no plans to support
    it in our builds. If that makes us "wrong" then I guess we'll
    just be "wrong" (along with official Slackware).

    It distills to a matter of trust - either one trusts the team
    to release tested scripts that don't do "Bad Things" or one does
    not. If one does not trust our team, then by all means, don't
    use our stuff - it's that simple.

    -RW

  12. Re: slackbuilds.net

    > I have nothing against using someone using fakeroot if they
    > desire, but the SlackBuilds.org project has no plans to support
    > it in our builds. If that makes us "wrong" then I guess we'll
    > just be "wrong" (along with official Slackware).


    Patrik Volkerding has probably his reasons which I do not know. But
    there is a tendency by some persons on this list to consider P.V. as a
    kind of divinity and simply answering "P.V do the same" is not a
    sufficient answer. I you do a choice; please have arguments. I am sure
    that P.V. does not take its decision simply because someone that he
    considers "perfect" do the same.

    >
    > It distills to a matter of trust - either one trusts the team
    > to release tested scripts that don't do "Bad Things" or one does
    > not. If one does not trust our team, then by all means, don't
    > use our stuff - it's that simple.


    I must say that although I valuate and use slackbuilds.org; I do not
    agree. I do not think you will intentionaly put damaging scripts on
    slackbuilds.org but what if a mistake. Quite often the upstream author
    recommends not building as root for this reason (as an example among
    other read the README in the Linux kernel source). Nobody can just say
    that he will never do a mistake; I would not even put such a trust in
    myself.

    Another problem is if someone want to modify a script. When I do that I
    would be much more comfortable with the fakeroot approach. Also using
    fakeroot is more comfortable for the person who write the scripts (I
    have written a few scrits).

    Olive

  13. Re: slackbuilds.net

    Le Tue, 04 Dec 2007 09:59:50 +0100, Olive a écritÂ*:

    >
    > Patrik Volkerding has probably his reasons which I do not know. But
    > there is a tendency by some persons on this list to consider P.V. as a
    > kind of divinity and simply answering "P.V do the same" is not a
    > sufficient answer.


    Speaking of divinity. I've been following the fakeroot vs. root debate
    for a while, and I can't help feeling that the whole discussion is being
    undermined by motivations of a more theological and/or psychological
    dimension.

    In short, shall I humbly savour the taste of my own insignificance (e. g.
    use fakeroot) or dwell pompously in God-like hybris (e. g. use root)?
    Discussions of that questions are developed with a zeal only equalled by
    that of medieval byzantine theologists.

    Let's just pray to the Goddess of Simplicity, shall we?

    Niki

  14. Re: slackbuilds.net

    ciol wrote:

    > Manuel Reimer wrote:
    >> If a script fails to execute with fakeroot, then you may fix it and
    >> post the fix to the mailing list. I'm sure the fix will be added.


    > The fix is to accept that you are wrong and that you should do what
    > slackbuild.net does.
    > Only chown and makepkg are done with fakeroot:


    Why? All the checks in ./configure will do well with fakeroot, as
    fakeroot just spoofs file owners to be root where they arent in real.
    This causes "tar" to create a valid tgz package.

    CU

    Manuel


  15. Re: slackbuilds.net

    On Tue, 04 Dec 2007 09:44:10 +0000, Niki Kovacs wrote:

    > Le Tue, 04 Dec 2007 09:59:50 +0100, Olive a écritÂ*:
    >
    >>
    >> Patrik Volkerding has probably his reasons which I do not know. But
    >> there is a tendency by some persons on this list to consider P.V. as a
    >> kind of divinity and simply answering "P.V do the same" is not a
    >> sufficient answer.

    >
    > Speaking of divinity. I've been following the fakeroot vs. root debate
    > for a while, and I can't help feeling that the whole discussion is being
    > undermined by motivations of a more theological and/or psychological
    > dimension.


    Could we agree on "philosophical dimension"?

    And probably not undermined, but the divisions appearing are along
    philosophical lines.

    > In short, shall I humbly savour the taste of my own insignificance (e.
    > g. use fakeroot) or dwell pompously in God-like hybris (e. g. use root)?
    > Discussions of that questions are developed with a zeal only equalled by
    > that of medieval byzantine theologists.


    The philosophical gap is exactly that: does one trust to power being used
    wisely and without error at all times, preferably unencumbered by
    timewasting restrictions, or does one believe that a task should be
    accomplished with the lowest possible privilege and therefore the lowest
    overall risk?

    Those concerned with security and stability and who believe in human
    fallibility will prefer the latter approach. Those who trust their skill
    and experience, and who never do development while tired or drunk will
    prefer the latter.

    > Let's just pray to the Goddess of Simplicity, shall we?


    She used to post here, didn't she? But I guess she finished college.

  16. Re: slackbuilds.net

    On Sun, 02 Dec 2007 13:56:18 +0100, Olive wrote:

    > I knew http://www.slackbuilds.org but I have found
    > http://www.slackbuilds.net. It is based on the same context (the
    > explanations are in French but you can easily get the build scripts;
    > click on "slackbuilds" and you will find a svn link). They have
    > apparently more packages (including a set of buildscript for Gnome).
    > Anyone knew that? I wonder why two projects are needed.


    Maybe not only two. I just had this link pop up in the feed from
    linux.com:

    http://www.linux.com/feature/121499

    Has anybody here used src2pkg? It may have been mentioned but if it was I
    missed it. If anyone has used it, whaddyathink?

  17. Re: slackbuilds.net

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2007-12-03, Olive wrote:
    > I have a small script that automatically
    > download the slackbuilds.org packages (you just type downslack in the
    > directory in which the .SlackBuild file resides. Here it is
    >
    > ---------------------------
    > #! /bin/sh
    >
    > set -e
    > eval $( cat *.info | grep DOWNLOAD= )
    > wget -T 20 -c $DOWNLOAD
    > ----------------------------


    Please note that at this time, this is very bad form and could result
    in some crazy behavior. The problem is a simple one, and one we should
    have solved soon. The variable values in the info files are not
    quoted, so it's possible to see something like:

    DOWNLOAD=http://www.foo.bar/foo-1.tar.gz&rm\ -fr\ \/

    Obviously such an obvious problem wouldn't make it past the admin team,
    but there are many HTTP links that use the ampersand. Anything after
    that would be interpreted as a command to execute. Most likely you'll
    just end up with a lot of "file not found" bash errors and the like,
    and wget will fail to locate the proper file.

    Plans are in the works to double quote the values of all variables in
    the .info files to avoid this issue. Then, something like the
    following should work.

    wget -T 20 $(grep DOWNLOAD *.info | cut -f 2- -d '=' )

    Please note I've not tested this at all. :^)

    - --
    It is better to hear the rebuke of the wise,
    Than for a man to hear the song of fools.
    Ecclesiastes 7:5
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHVYOErZS6hX/gvjoRAkP5AJsGkNykC6fnrd5slpJIP6gPiGpJfgCggQCy
    KeJuwrvHO8uXH6caB6b0Hu0=
    =PmuA
    -----END PGP SIGNATURE-----

  18. Re: slackbuilds.net

    Manuel Reimer wrote:
    > Why? All the checks in ./configure will do well with fakeroot


    Obviously you have never tried it.

  19. Re: slackbuilds.net

    Robby Workman wrote:

    >Remember: simple is good!


    Simplicity is to be sure that when you create the package, it will not
    do something weird in {/*}\$HOME, by only adding very few lines.

    I don't care. Man are stupid: they are too proud to change what they
    have done for long.


  20. Re: slackbuilds.net

    Le Tue, 04 Dec 2007 18:34:20 +0100, ciol a écritÂ*:

    >
    > I don't care. Man are stupid: they are too proud to change what they
    > have done for long.


    In case someone wondered: ciol is the resident Slackware troll from
    France. Let's leave it at that for the introduction. Update your
    killfiles, folks.

    cheers, er, *plonk*

    Niki


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast