A few gotchas with 13.1 (FWIW)
Mike Jones
Caution!
This post contains Rantinox! Not suitable for sentitive developers!
As 13.37 is in the tubes, it seems relevant to mention a few problems
I've had with 13.1.
The Midnight Commander in 13.1 seems to be a much more complex set of
apps with MC at the front end. Also, it has a screwy new way of saving
it's configs that has refused to save changes on my installs. Also, I've
been using a wrapper script for media files, and this screwed up in some
most perculiar ways with the new MC. I ripped the 13.1 MC out and
installed the 12.2 version and all was well once again.
The replacement for GQview, Geeqie, didn't have a working way to edit how
it calls GIMP, and I got tired of trying to find out how to make it give
me the full set of functions I'd had in GQview, so I uninstalled it,
grabbed the 13.0 GQview and installed that instead. Problem(s) solved.
The GIMP also seems to have function glitches as part of it's "continuing
improvement", and it wouldn't give me the edited filename in the window
topbar, so I ended up removing that and installing the version from 12.2
to get things working again.
Xfce has lost it's menu editor, and manually editing the configs is a
PITA as Xfce needs to be closed to edit them as it updates its /running/
configs on logout. I tripped over a blog (lost it now) where it seems as
if the Xfce dev-team couldn't get the menu editor to work with the new
"improvements", whatever they might be. IceWM is it then.
So here I am, running a stripped back 13.1 with some "new improved"
components downgraded back to versions that work.
One thing that kept popping up as I was digging around trying to fix
these "improvements" were references to "desktop.standards", which I'm
sensing is where these glitches are coming from, as dev-teams try to re-
write their apps to comply with these "desktop environment standards".
This would be progress, except its buggering up other options, and when
the old "works fine" gets messed up or even removed, then these
"improvements" are just "fixed what wasn't broken" SNAFUs IMO. Sounds
like "I can't believe its not Windows!" is becoming an ambition with some
dev-teams. (Sigh!)
Hopefully the next version of Slackware won't be as messed up with this
BETA software, and stuff will be checked for "WTF have they done with
XYZ?" before including it as Slackware standard installation stuff.
Fingers crossed. ;)
notbob
> the old "works fine" gets messed up or even removed, then these
> "improvements" are just "fixed what wasn't broken" SNAFUs IMO. Sounds
> like "I can't believe its not Windows!" is becoming an ambition with some
> dev-teams. (Sigh!)
Boy, howdy! I blanched at 13.1 and further downgraded 13 to KDE 3.5.
I see so much going nowhere it's becoming alarming. Changing only for
the sake of change is not necessarily an improvement. Unfortunately,
it seems to be part of the dev mindset. Gotta keep advancing, even
from the point of perfect when any advance becomes downhill.
I used ubuntu for the first time on my eee netbook. It was 10.04 and
worked great with the exception of the insanely long boot. Two whole
minutes! from a flash key. So, I waited for the next rev, 10.10.
Wow, only 50 secs boot time. Major upside. OTOH, the new desktop
environment of 10.10 was now such a catastophic clusterfsck, I'd rather
endure the 2 min boot of 10.04. One step forward, two steps back.
I'm looking forward for to the new Slack cuz I need some of it's newer
libs, but if it gets too silly, I may jes hafta switch to BSD.
nb
Mike Jones
> On 2011-03-10, Mike Jones <lu...@dasteem.invalid> wrote:
>
>> the old "works fine" gets messed up or even removed, then these
>> "improvements" are just "fixed what wasn't broken" SNAFUs IMO. Sounds
>> like "I can't believe its not Windows!" is becoming an ambition with
>> some dev-teams. (Sigh!)
>
> Boy, howdy! I blanched at 13.1 and further downgraded 13 to KDE 3.5.
>
I found it interesting that VectorLinux release a "KDE Classic" distro.
I'm pretty sure these new "desktop.standards" are part of this
"clusterfsck" you mentioned, and I'm not too happy so much effort is
being spent, wasted IMO, on trying to swing Linux, once the A-Team
workshop of OSs, into a Windows clone, including all the sandtraps,
glitches, restrictions, and strangulation of innovation that inevitably
comes with that kind of package deal.
Sure, lets show M$ how its done for real, and lets also establish some
standards that make sense over pouring dead money into M$'s coffers, but
lets not all go down the same road singing the same song!
If there is /any/ distro that should be independant of such funneling,
surely its Slackware? If Slack gets tied up with trying to be just
another semi-automated Windows clone, it'll die, as there are others way
ahead of that game who already "own that turf", like Fedora\Centos, and
even Zenwalk's slick reworkings of Slackware.
Slackware surely has to be about maintaining it's now classic "As you
like it, if you're prepared to do the work" ethos? If everybody else is
using an automated learn-nothing "doitall4U" clickibot app, then
shouldn't Slackware be the OS to feature the alternative tools for those
who don't want M$-free Windows?
The last distro I saw that did this was VectorLinux Lite, which features
some pretty cool alternatives to mainstream bloatware, and even a neat
sidestep to HAL for those of us who don't want a "desktop environment"
getting in the way and would rather use just a nailed down Window Manager
instead, like IceWM or JWM.
Slackware should, IMO, be about this kind of alternative inovation, not
sliding slowly toward compliance with some complex dependancy-hell
inducing corporately bloated idea of how things should work?
Vlad D. Markov
are the same in BSD as in Linux. The big difference is that many non-opensource
apps like flash and java just plain aren't available unless you run Linux
emulation. Like Slackware the packages are prepared by volunteers. The
readily available packages are different than Slackware but as in Slackware,
you are free to build anything you want.
I suppose if I could do on-line banking without proprietary apps unavailable
under NetBSD except with Linux emulation I never would have experienced
Slackware.
+Alan Hicks+
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-03-10, Vlad D. Markov <vl...@optonline.net> wrote:
> I just had to follow up. I recently came to Slackware from NetBSD. The apps
> are the same in BSD as in Linux. The big difference is that many non-opensource
> apps like flash and java just plain aren't available unless you run Linux
> emulation. Like Slackware the packages are prepared by volunteers.
This isn't true. All Slackware packages are prepared by Pat, though
users certainly do assist from time to time with some users being more
active than others. There are third-party package repositories and
third-party build script repositories[0] but none of these are at all
parts of Slackware. They're really just unofficial user contributions.
[0] The most famous and well-respected of these being
http://www.slackbuilds.org of course.
- - --
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.10 (GNU/Linux)
iEYEARECAAYFAk15qtcACgkQDyaEVbMHxsaEcwCgj+XZSuyrveK//Qav1kCZWrvK
KMkAoJivXdjNjmkZzbyUoRBRzha+1yNR
=oboV
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk15qukACgkQDyaEVbMHxsbBvQCff7Y9Fyo//24zPl1FbaNXCV8v
3EUAnjPcdqHzPLen2wCqF6SKk9mmSTjh
=bJg2
-----END PGP SIGNATURE-----
Mike Jones
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-03-10, Vlad D. Markov <vl...@optonline.net> wrote:
>> I just had to follow up. I recently came to Slackware from NetBSD. The
>> apps are the same in BSD as in Linux. The big difference is that many
>> non-opensource apps like flash and java just plain aren't available
>> unless you run Linux emulation. Like Slackware the packages are
>> prepared by volunteers.
>
> This isn't true. All Slackware packages are prepared by Pat, though
> users certainly do assist from time to time with some users being more
> active than others. There are third-party package repositories and
> third-party build script repositories[0] but none of these are at all
> parts of Slackware. They're really just unofficial user contributions.
>
> [0] The most famous and well-respected of these being
> http://www.slackbuilds.org of course.
>
Slackbuilds is one of the things I'd classify as advanced inovation.
Being able to hand hack relatively simple and consistant compilation
scripts and create your own installation packages is something I've not
seen any other distro come close to, and puts Slackware in a class of
it's own.
The one thing thats missing is an app for scanning the details from a
source package and taking some simple input from a user interface, and
then generating a bug-free syntax-correct custom build script. Mind you,
hand hacking an existing script isn't difficult.
Hats off to the SlackBuild team! :)
Sylvain Robitaille
> The one thing thats missing is an app for scanning the details from a
> source package and taking some simple input from a user interface, and
> then generating a bug-free syntax-correct custom build script.
This isn't exactly what you're suggesting, but have a look at
http://www.therockgarden.ca/software/slackware/template.SlackBuild
It's the template from which I build my own slackbuild scripts. With very
few exceptions, I edit only the version number, the URL where the source
should be obtained from if not already present, and the content in the
section clearly marked "EDIT HERE", although even that is currently
setup so that more often than not it just works by default.
("--docdir" is often not recognized by configure, but not always)
That script has been years in the making. It's the result, originally
of my working with Slackware's own build scripts while porting the
distribution to Alpha systems, and later with third-party scripts to
build packages not included in Slackware. Parts of it will no doubt
look familiar to some who have written and published slackbuild scripts
in a more official capacity. I've tried to give proper credit where due,
but if I missed anyone who should be named specifically, please let me
know and I will add appropriate mention.
Note that as I have it setup (although this is trivial to change),
my slackbuild scripts install packages under "/local" (think of it as
"/usr/local", one level up in the directory tree; in fact on my systems,
/usr/local symlinks to /local anyway). I still believe in keeping
"locally installed" software separate from that which ships with the OS,
but it's really nice to be able to manipulate that software using the
usual package management tools.
It's also setup such that it can be run as an unprivileged user (and
"chown" won't fail), either to test building a new package, or for sites
where locally installed software is usually maintained by an otherwise
unprivileged, non-root, software maintenance userid.
I hope this script is useful to others, and that perhaps it's fairly
close to what you were envisioning when you wrote the above. The
result, for me, is that all my slackbuild scripts are at least
consistent, and that's usually worthwhile.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
root
>
>
>
> Slackbuilds is one of the things I'd classify as advanced inovation.
> Being able to hand hack relatively simple and consistant compilation
> scripts and create your own installation packages is something I've not
> seen any other distro come close to, and puts Slackware in a class of
> it's own.
>
> The one thing thats missing is an app for scanning the details from a
> source package and taking some simple input from a user interface, and
> then generating a bug-free syntax-correct custom build script. Mind you,
> hand hacking an existing script isn't difficult.
>
> Hats off to the SlackBuild team! :)
>
[ I apologize for hijacking the original thread ]
What am I missing? Exactly what does Slack Builds offer? Take for example
the Calibre package for handling different Ebook formats. The Slack
Build script does nothing for handling the (many) dependencies required
by Calibre.
notbob
> Build script does nothing for handling the (many) dependencies required
> by Calibre.
That's your job. If you want someone to do it for you, use another
distro. Slack is for DIYs, not DIFYs.
nb
Michael Black
Neither does Slackware.
You can just compile from source, and then you have no notice of it
with the rest of the installed packages in /var/log. Making a "wrapper"
around the source makes it consistent.
Michael
Sylvain Robitaille
> What am I missing? Exactly what does Slack Builds offer?
A means by which to install and maintain software packages not available
with the distribution itself, that is consistent with how the
distribution supplied software is installed and maintained. The value
of that is something you'll appreciate more and more as you gain
experience, or perhaps as you start to manage larger numbers of systems.
> Take for example the Calibre package for handling different Ebook
> formats. The Slack Build script does nothing for handling the (many)
> dependencies required by Calibre.
Some would argue that this is a feature of how the Slackware package
management "model" functions. You're right: nothing is done to
automatically "handle" package dependancies. You're expected to read
the documentation associated with the new package and address any
dependancies yourself. Use more slackbuild scripts for any
dependancies, of course, and that will ensure consistency in your
installation, and make it very easy to maintain (ie. upgrade) locally
installed software.
Chick Tower
> under NetBSD except with Linux emulation I never would have experienced
> Slackware.
I assume by "on-line banking" you mean something other than logging into
the bank's website with a supported browser. What, pray tell, would
that be?
--
Chick Tower
For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
Mike Jones
root
I have been doing it myself since Slackware began. I
still wonder why anyone would use Slackbuild.
root
>
> You can just compile from source, and then you have no notice of it
> with the rest of the installed packages in /var/log. Making a "wrapper"
> around the source makes it consistent.
>
> Michael
>
I use checkinstall to make the final package(s).
Keith Keller
>
> I have been doing it myself since Slackware began. I
> still wonder why anyone would use Slackbuild.
Slackbuilds provides build scripts for software not available
in the official Slackware release.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Vlad D. Markov
> On 2011-03-10, Vlad D. Markov <vl...@optonline.net> wrote:
>> I suppose if I could do on-line banking without proprietary apps unavailable
>> under NetBSD except with Linux emulation I never would have experienced
>> Slackware.
>
> I assume by "on-line banking" you mean something other than logging into
> the bank's website with a supported browser. What, pray tell, would
> that be?
browser when I first ran into issues. I had been accessing their
site for years using Firefox on NetBSD. I followed instructions
and masqueraded as Firefox on a Windows XP box, but I still had
issues even though my identity looked good on a test page.
It failed when I was redirected from the bank's public site
to some site they contract with for on-line banking. An error
page would pop up telling me to call customer service. Yes,
this happened after they improved their web site.
An old laptop running Linux had no issues accessing the site so
instead of fighting the bank or whatever, I built a slackware box.
DWS-Scudder caused issues for me. Their initial page required
flash which drove me crazy. I figured out how to bypass it and life
improved.
I guess the small annoyances piled up on each other.
The NetBSD box is still in service though if anyone has any ideas.
I still like NetBSD very much.
Dan C
Parents used a lot of drugs, or you did?
Seriously, WTF don't you understand? What is so hard for you to grasp
about Slackbuilds?
If you don't want to use them, then don't.
Bugger off, dimwit.
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as his rectum exploded.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg
Chick Tower
Don't you have any concerns about this README in the checkinstall
subdirectory of extra (from Slackware 13.0)?
Due to an unfortunate incompatibility with the latest coreutils
that was not noticed until right before release, a working copy
of "checkinstall" was not available at the time of the Slackware
12.0 release. Stuart Winter was kind enough to upgrade
slacktrack (a similar tool) to work around the issue of
installwatch not working, but in order to do that every file on
the system has to be "touched" so that changed timestamps can be
used to find files that are new. Obviously, you will not want to
do that on a production system (but it is always best to have a
dedicated "build box" anyway).
A new and working checkinstall might also be availible by the
time you read this. The project's homepage is:
http://asic-linux.com.mx/~izto/checkinstall
Sorry for any inconvenience.
root
>
> Parents used a lot of drugs, or you did?
>
> Seriously, WTF don't you understand? What is so hard for you to grasp
> about Slackbuilds?
>
> If you don't want to use them, then don't.
>
> Bugger off, dimwit.
>
>
As clever as your response is, you still haven't made
it clear what Slackbuilds offers over ./configure,
make, checkinstall.
With Slackbuilds I have to download the build package
along with the tarball.
root
> Don't you have any concerns about this README in the checkinstall
> subdirectory of extra (from Slackware 13.0)?
>
> Due to an unfortunate incompatibility with the latest coreutils
> that was not noticed until right before release, a working copy
> of "checkinstall" was not available at the time of the Slackware
> 12.0 release. Stuart Winter was kind enough to upgrade
> slacktrack (a similar tool) to work around the issue of
> installwatch not working, but in order to do that every file on
> the system has to be "touched" so that changed timestamps can be
> used to find files that are new. Obviously, you will not want to
> do that on a production system (but it is always best to have a
> dedicated "build box" anyway).
>
> A new and working checkinstall might also be availible by the
> time you read this. The project's homepage is:
>
> http://asic-linux.com.mx/~izto/checkinstall
>
> Sorry for any inconvenience.
>
Now that you mention it I do remember this problem with
checkinstall. The version I have is checkinstall 1.5.3
and I don't remember that I have used it since Slack 13.
I never looked into how checkinstall did its magic.
The warning suggests that it touches a temp-file,
does a make install, then does find / -newer temp-file.
Grant
>Dan C <youmust...@lan.invalid> wrote:
>>
>> Parents used a lot of drugs, or you did?
>>
>> Seriously, WTF don't you understand? What is so hard for you to grasp
>> about Slackbuilds?
>>
>> If you don't want to use them, then don't.
>>
>> Bugger off, dimwit.
>>
>>
>
>As clever as your response is, you still haven't made
>it clear what Slackbuilds offers over ./configure,
>make, checkinstall.
Freedom, maybe Dan didn't think of the common (to some of us) method of
installing extra software to /usr/local via the default method you assume
everyone prefers.
Personally, I disagree with SBo's convention of installing extra packages
to /usr, I prefer to install non-distro additions and updates to /usr/local.
But that doesn't mean I have to knock SBo's work for those who prefer it's
convenience.
>
>With Slackbuilds I have to download the build package
>along with the tarball.
That's hardly a valid argument, at least you build a proper slackware
package that allows for updates and/or removal with a SlackBuild script.
There's no one true correct method, simply options to be considered. Use
what you like and ignore the rest -- but there's no pint telling people
they're wrong -- Linux -> freedom -> many ways to do things.
Grant.
Dan C
> Dan C <youmust...@lan.invalid> wrote:
>>
>> Parents used a lot of drugs, or you did?
>>
>> Seriously, WTF don't you understand? What is so hard for you to grasp
>> about Slackbuilds?
>>
>> If you don't want to use them, then don't.
>>
>> Bugger off, dimwit.
>>
>>
>>
> As clever as your response is, you still haven't made it clear what
> Slackbuilds offers over ./configure, make, checkinstall.
Ease of use, and the fact that that's what PV uses for official Slackware
packages are two things. There are others.
> With Slackbuilds I have to download the build package along with the
> tarball.
It's a tiny little script. Meaningless to "have to download".
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he backed into a squad car.
Mike Jones
[...]
> Personally, I disagree with SBo's convention of installing extra
> packages to /usr, I prefer to install non-distro additions and updates
> to /usr/local.
I tend to go in that direction too.
T'ain't but a moment to tweak the Slackbuild script.
The nice thing about a SlackBuild.txz is that it can be saved for use
when needed, and usually across a range of boxes.
Henrik Carlqvist
> Now that you mention it I do remember this problem with
> checkinstall. The version I have is checkinstall 1.5.3
> and I don't remember that I have used it since Slack 13.
I also have the experience that checkinstall 1.5.3 works best.
Unfortunately, the original 1.5.3 does no longer compile out of the box on
the latest versions of Slackware. I have put the original checkinstall
1.5.3 source together with patches and slackbuild script at
http://sourceforge.net/projects/makepack/files/tools/checkinstall%20source/
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
root
Well, I just ran a test and my old version of checkinstall
does *not* work. Neither does the latest version 1.6.2
or something, even after I fixed a scandir problem.
I do like to have the option to uninstall if needed
so I will take a longer look at Slackbuilds.
root
> root <NoE...@home.org> wrote:
>> Now that you mention it I do remember this problem with
>> checkinstall. The version I have is checkinstall 1.5.3
>> and I don't remember that I have used it since Slack 13.
>
> I also have the experience that checkinstall 1.5.3 works best.
> Unfortunately, the original 1.5.3 does no longer compile out of the box on
> the latest versions of Slackware. I have put the original checkinstall
> 1.5.3 source together with patches and slackbuild script at
> http://sourceforge.net/projects/makepack/files/tools/checkinstall%20source/
>
> regards Henrik
Thanks Henrik, I installed your improved version of 1.5.3 and
checkinstall works again.
I don't see any source files in either the makepack or
checkinstall packages at sourceforge.
Henrik Carlqvist
> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>> I have put the original checkinstall 1.5.3 source together with patches
>> and slackbuild script at
>> http://sourceforge.net/projects/makepack/files/tools/checkinstall%20source/
> Thanks Henrik, I installed your improved version of 1.5.3 and
> checkinstall works again.
> I don't see any source files in either the makepack or checkinstall
> packages at sourceforge.
The file checkinstall-1.5.3_src_slack13.tar at the URL above contains
build script, patches and the source archive checkinstall-1.5.3.tar.gz
However, checkinstall itself is not an executable binary but only a shell
script. This shellscript calls installwatch which also is a shellscript.
Installwatch adds the dynamic library installwatch.so to LD_PRELOAD and
the C source of installwatch.so is included in checkinstall-1.5.3.tar.gz
The makepack files does not contain any C source code. It is only a number
of gnu Makefiles which downloads, compiles and installs programs together
with their dependencies. As the installation is done with checkinstall you
will also get binary Slackware packages from the process which will be
optimized from your settings.
Jim Diamond
> root <NoE...@home.org> wrote:
>> Now that you mention it I do remember this problem with
>> checkinstall. The version I have is checkinstall 1.5.3
>> and I don't remember that I have used it since Slack 13.
>
> I also have the experience that checkinstall 1.5.3 works best.
> Unfortunately, the original 1.5.3 does no longer compile out of the box on
> the latest versions of Slackware. I have put the original checkinstall
> 1.5.3 source together with patches and slackbuild script at
> http://sourceforge.net/projects/makepack/files/tools/checkinstall%20source/
Those of you who miss the dearly departed checkinstall might be
interested in the fact that "trackinstall", part of the src2pkg
package, can be used instead of checkinstall.
I should note that trackinstall worked for me after checkinstall
stopped working, but I haven't used it lately (i.e., on 13.1) since I
use Slackbuilds for almost everything I compile now.
You can get src2pkg V 2.2 as follows:
cd /tmp
wget http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/src2pkg-2.2-noarch-3.tgz
sudo installpkg src2pkg-2.2-noarch-3.tgz
sudo src2pkg --setup
I see the current version is 2.4. I expect if you use
src2pkg-2.4-noarch-1.tgz
instead of
src2pkg-2.2-noarch-3.tgz
it might work, but you need to test that yourself.
Cheers.
Jim
Henrik Carlqvist
> Those of you who miss the dearly departed checkinstall might be
> interested in the fact that "trackinstall", part of the src2pkg
> package, can be used instead of checkinstall.
Thanks for the pointer! Src2pkg seems to be actively maintained as the 2.4
package is dated 2011-Jan-13. As my patched checkinstall still is working
I will not do any changes to my makepack right now, but I have added a
comment in the makepack file Settings.mk that trackinstall might be useful
the day that checkinstall needs to be replaced.
Bud
>
> Those of you who miss the dearly departed checkinstall might be
> interested in the fact that "trackinstall", part of the src2pkg
> package, can be used instead of checkinstall.
>
> I should note that trackinstall worked for me after checkinstall
> stopped working, but I haven't used it lately (i.e., on 13.1) since I
> use Slackbuilds for almost everything I compile now.
>
> You can get src2pkg V 2.2 as follows:
> cd /tmp
> wget http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/src2pkg-2.2-noarch-3.tgz
> sudo installpkg src2pkg-2.2-noarch-3.tgz
> sudo src2pkg --setup
>
> I see the current version is 2.4. I expect if you use
> src2pkg-2.4-noarch-1.tgz
> instead of
> src2pkg-2.2-noarch-3.tgz
> it might work, but you need to test that yourself.
>
> Cheers.
> Jim
404 not found. . .
--
Bud
root
I downloaded the 2.4 version as directed above. Did you
change both the 2.2 to 2.4 and noarch-3 to noarch-1?
The src2pkg seems very interesting. I have only tried
it on the simple Tutorial case for di-3.11-i486-1,
a simple disk utility.
Chick Tower
> The src2pkg seems very interesting. I have only tried
> it on the simple Tutorial case for di-3.11-i486-1,
> a simple disk utility.
I tried it on the new version of Fluxbox after installing the imlib2
dependency, but something didn't work right. I don't recall any
problems in the brief time I played with Fluxbox 1.3.1, but one of the
man pages (fluxbox-apps?) looked like Elvish. I'll try Henrik's updated
checkinstall.
There's also a -current package for Fluxbox 1.3.1. I haven't tried that
yet on my Slackware 13.0 installation.
Doug713705
alt.os.linux.slackware :
> On 2011-03-13, root <NoE...@home.org> wrote:
>> The src2pkg seems very interesting. I have only tried
>> it on the simple Tutorial case for di-3.11-i486-1,
>> a simple disk utility.
>
> I tried it on the new version of Fluxbox after installing the imlib2
> dependency, but something didn't work right. I don't recall any
> problems in the brief time I played with Fluxbox 1.3.1, but one of the
> man pages (fluxbox-apps?) looked like Elvish. I'll try Henrik's updated
> checkinstall.
Following this thread, I was wondering why people use external tools
while all the needed is already included in Slackware ?
To make a package from sources _and_ that suit your configuration
options (/usr/local prefix and so on) you can simply do something like
this :
./configure (add you options here as usual)
make
mkdir PKG
make install DESTDIR=$PWD/PKG
cd PKG
makepkg ../packagename.tgz
This will work for most projects (some rareprojects that do not
understand the DESTDIR variable will be problematic).
--
@+ Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.dougwise.org
http://newsportal.dougwise.org/
http://news.dougwise.org
Henrik Carlqvist
> ./configure (add you options here as usual)
> make
> mkdir PKG
> make install DESTDIR=$PWD/PKG
> cd PKG
> makepkg ../packagename.tgz
>
> This will work for most projects (some rareprojects that do not
> understand the DESTDIR variable will be problematic).
As you say, the above works for most projects, but it doesn't work for
all. Some projects does not support DESTDIR in their Makefile. Other
projects doesn't even have a Makefile.
Checkinstall, however will work for anything you install. You can even do
something like:
checkinstall cp -p my_custom_fstab /etc/fstab
To get a package containing a custom /etc/fstab without assuming that a
package has to be something built from sources.
Some statistics:
My tool makepack contains rules for 187 different packages.
38 (20%) of those rules require special install methods (something else
than the default "make install"). However, I don't think that the
Makefile of all of the remaining 80% packages supports DESTDIR.
Grant
>Le 14-03-2011, Chick Tower nous expliquait dans
>alt.os.linux.slackware :
>
>> On 2011-03-13, root <NoE...@home.org> wrote:
>>> The src2pkg seems very interesting. I have only tried
>>> it on the simple Tutorial case for di-3.11-i486-1,
>>> a simple disk utility.
>>
>> I tried it on the new version of Fluxbox after installing the imlib2
>> dependency, but something didn't work right. I don't recall any
>> problems in the brief time I played with Fluxbox 1.3.1, but one of the
>> man pages (fluxbox-apps?) looked like Elvish. I'll try Henrik's updated
>> checkinstall.
>
>Following this thread, I was wondering why people use external tools
>while all the needed is already included in Slackware ?
>
>To make a package from sources _and_ that suit your configuration
>options (/usr/local prefix and so on) you can simply do something like
>this :
>
>./configure (add you options here as usual)
Not all project use configure, some are make && make install (as root),
one must check the source tarball's top-level install directory for
variations to the common theme.
>make
>mkdir PKG
??
>make install DESTDIR=$PWD/PKG
>cd PKG
>makepkg ../packagename.tgz
>
>This will work for most projects (some rareprojects that do not
>understand the DESTDIR variable will be problematic).
It's the exceptions that create the need for SlackBuilds, they create a
common install experience for all users (or should aim to do so).
What you advocate has enough exceptions to throw the average user when
things don't work as expected.
Not everyone is an experience expert at installing packages.
Grant.
Doug713705
alt.os.linux.slackware :
>>
>>./configure (add you options here as usual)
>
> Not all project use configure, some are make && make install (as root),
> one must check the source tarball's top-level install directory for
> variations to the common theme.
Yes, you're right.
As my english is not perfect, I certainly misread most of this thread.
>>make
>>mkdir PKG
>
> ??
Creation of a directory to temporary install the compiled project before
using makepkg.
>>make install DESTDIR=$PWD/PKG
>>cd PKG
>>makepkg ../packagename.tgz
>>
>>This will work for most projects (some rareprojects that do not
>>understand the DESTDIR variable will be problematic).
>
> It's the exceptions that create the need for SlackBuilds, they create a
> common install experience for all users (or should aim to do so).
Sure, I use SlackBuilds myself when available and I think this is the
best way to build and install a package.
I even wrote an infamous horrible script to automate downloading,
building, installing or updating packages from SBo.
The only missing things in SBo is a list of required packages for
building.
Such a list in the .info file would greatly improve building automation.
Random example: 2ManDVD
http://slackbuild.org/repository/13.1/multimedia/2ManDVD/
The 2ManDVD.info could contain a line like the following
REQUIRE=webkit,ffmpeg,transcode,dvdauthor,mjpegtools,fmpegthumbnailer
Just a thought.
> What you advocate has enough exceptions to throw the average user when
> things don't work as expected.
>
> Not everyone is an experience expert at installing packages.
My guess was Slackware is merely used by experienced users or, at least,
by whom want to be one of them ;-)
I personnaly learned Linux with Slackware :-)
Sylvain Robitaille
> The only missing things in SBo is a list of required packages for
> building.
>
> Such a list in the .info file would greatly improve building automation.
>
> Random example: 2ManDVD
> http://slackbuild.org/repository/13.1/multimedia/2ManDVD/
>
> The 2ManDVD.info could contain a line like the following
> REQUIRE=webkit,ffmpeg,transcode,dvdauthor,mjpegtools,fmpegthumbnailer
Have a look at
http://slackbuild.org/slackbuilds/13.1/multimedia/2ManDVD/README
yes the *.info file could contain the "REQUIRE" information as you
suggest, but would that really be any more helpful than the same
information in the README file, given that it apparently gets missed in
a file whose name is "README".
I realize that my response is specific to your example, but from what
I've seen, it's also consistent with other slackbuild.org entries.
In my experience, the documentation provided at slackbuild.org, for
building various software packages has been quite short, but quite
complete (for its purpose). There really isn't any need to duplicate
that documentation, but as it is now it's short enough that there's also
no excuse for not reading it.
I hope this helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Doug713705
alt.os.linux.slackware :
>> REQUIRE=webkit,ffmpeg,transcode,dvdauthor,mjpegtools,fmpegthumbnailer
>
> Have a look at
> http://slackbuild.org/slackbuilds/13.1/multimedia/2ManDVD/README
>
> yes the *.info file could contain the "REQUIRE" information as you
> suggest, but would that really be any more helpful than the same
> information in the README file, given that it apparently gets missed in
> a file whose name is "README".
>
> I realize that my response is specific to your example, but from what
> I've seen, it's also consistent with other slackbuild.org entries.
>
> In my experience, the documentation provided at slackbuild.org, for
> building various software packages has been quite short, but quite
> complete (for its purpose). There really isn't any need to duplicate
> that documentation, but as it is now it's short enough that there's also
> no excuse for not reading it.
>
I know that required packages are notified in the README and is
really helpfull for human being but my suggestion was to add a
_standardized_ notification (whatever the file containing this
notification), something easily detectable by scripts for
automation purpose.
It was just a thought, nothing else.
Jim Diamond
> 404 not found. . .
I see that link is outdated; mea culpa.
In case there is anyone who uses Slackware and yet can't figure out
the URLs of interest from the hint above, the 2.4 version is found at
http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/src2pkg-2.4-noarch-1.tgz
and the 2.2 version is found at
http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/pasture/src2pkg-2.2/src2pkg-2.2-noarch-3.tgz
Cheers.
Jim
Jim Diamond
> Bud <B...@bud.invalid.msn.com> wrote:
>> On 2011-03-13, Jim Diamond wrote:
>>> Those of you who miss the dearly departed checkinstall might be
>>> interested in the fact that "trackinstall", part of the src2pkg
>>> package, can be used instead of checkinstall.
>>> I should note that trackinstall worked for me after checkinstall
>>> stopped working, but I haven't used it lately (i.e., on 13.1) since I
>>> use Slackbuilds for almost everything I compile now.
>>> You can get src2pkg V 2.2 as follows:
>>> cd /tmp
>>> wget http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/src2pkg-2.2-noarch-3.tgz
>>> sudo installpkg src2pkg-2.2-noarch-3.tgz
>>> sudo src2pkg --setup
>>> I see the current version is 2.4. I expect if you use
>>> src2pkg-2.4-noarch-1.tgz
>>> instead of
>>> src2pkg-2.2-noarch-3.tgz
>>> it might work, but you need to test that yourself.
> I downloaded the 2.4 version as directed above. Did you
> change both the 2.2 to 2.4 and noarch-3 to noarch-1?
I haven't compiled 2.4, since I haven't used trackinstall for so
long. But yes, noarch-1 is the current option for 2.4, give it a try
> The src2pkg seems very interesting. I have only tried it on the
> simple Tutorial case for di-3.11-i486-1, a simple disk utility.
I don't recall how I came to know about it, but given the issues with
checkinstall, it probably be more well known to slackware users.
Those of you not familiar with it may be interested in a sample usage.
The only thing I use src2pkg for (currently) is to make a package for
sam2p. Having downloaded sam2p-0.47.tar.gz into /tmp, I just needed
to execute the following commands as root
cd /tmp
src2pkg -e='--enable-lzw --enable-gif' sam2p-0.47.tar.gz
installpkg sam2p-0.47-x86_64-1.tgz
Cheers.
Jim
Jim Diamond
> On Tue, 15 Mar 2011 00:25:29 +0000 (UTC), Doug713705 wrote:
>
>> The only missing things in SBo is a list of required packages for
>> building.
>>
>> Such a list in the .info file would greatly improve building automation.
>>
>> Random example: 2ManDVD
>> http://slackbuild.org/repository/13.1/multimedia/2ManDVD/
>>
>> The 2ManDVD.info could contain a line like the following
>> REQUIRE=webkit,ffmpeg,transcode,dvdauthor,mjpegtools,fmpegthumbnailer
>
> Have a look at
> http://slackbuild.org/slackbuilds/13.1/multimedia/2ManDVD/README
>
> yes the *.info file could contain the "REQUIRE" information as you
> suggest, but would that really be any more helpful than the same
> information in the README file, given that it apparently gets missed in
> a file whose name is "README".
>
> I realize that my response is specific to your example, but from what
> I've seen, it's also consistent with other slackbuild.org entries.
>
> In my experience, the documentation provided at slackbuild.org, for
> building various software packages has been quite short, but quite
> complete (for its purpose). There really isn't any need to duplicate
> that documentation, but as it is now it's short enough that there's also
> no excuse for not reading it.
Sylvain,
Doug has already replied to your message, but in case his reply
doesn't spell it out completely for some reader, here is another kick
at the can.
I have a script called "slackbuild" which, when given a name of some
package at http://slackbuilds.org, goes out and downloads the files
there, downloads the source code, uses the slackbuild to create the
package, and then installs it. It does this automagically by parsing
the information from the package's web page.
While I agree that reading the README is always a good idea, having
the information about required dependencies in an easily-parsable
format would be beneficial for automating things.
Cheers.
Jim
Mike Jones
> Le 15-03-2011, Sylvain Robitaille nous expliquait dans
> alt.os.linux.slackware :
>
>>> REQUIRE=webkit,ffmpeg,transcode,dvdauthor,mjpegtools,fmpegthumbnailer
>>
>> Have a look at
>> http://slackbuild.org/slackbuilds/13.1/multimedia/2ManDVD/README
>>
>> yes the *.info file could contain the "REQUIRE" information as you
>> suggest, but would that really be any more helpful than the same
>> information in the README file, given that it apparently gets missed in
>> a file whose name is "README".
>>
>> I realize that my response is specific to your example, but from what
>> I've seen, it's also consistent with other slackbuild.org entries.
>>
>> In my experience, the documentation provided at slackbuild.org, for
>> building various software packages has been quite short, but quite
>> complete (for its purpose). There really isn't any need to duplicate
>> that documentation, but as it is now it's short enough that there's
>> also no excuse for not reading it.
>>
>>
> I know that required packages are notified in the README and is really
> helpfull for human being but my suggestion was to add a _standardized_
> notification (whatever the file containing this notification), something
> easily detectable by scripts for automation purpose.
>
> It was just a thought, nothing else.
It does seem like a good idea to me.
A Slackbuild process that checks for appropriate requirements and offers
a download-from-mirror-list option before compiling would be a nice
addition to the SBo system.
Having said that, there is a certain luxury about reading the "XYZ needs
this, that, other" notifications at slackbuilds.org, and being able to
navigate your own path through this stage as suits your individual
requirements and\or any current tweaks\workarounds.
Doug713705
alt.os.linux.slackware :
>
> Sylvain,
>
> Doug has already replied to your message, but in case his reply
> doesn't spell it out completely for some reader, here is another kick
> at the can.
>
> I have a script called "slackbuild" which, when given a name of some
> package at http://slackbuilds.org, goes out and downloads the files
> there, downloads the source code, uses the slackbuild to create the
> package, and then installs it. It does this automagically by parsing
> the information from the package's web page.
>
> While I agree that reading the README is always a good idea, having
> the information about required dependencies in an easily-parsable
> format would be beneficial for automating things.
You perfectly understood my thought.
Sylvain Robitaille
>> While I agree that reading the README is always a good idea, having
>> the information about required dependencies in an easily-parsable
>> format would be beneficial for automating things.
>
> You perfectly understood my thought.
... and I missed that the point of the proposal was to have it be
possible for automated parsing of the requirements. I have to admit
that for my own purposes it would make no difference, but that doesn't I
think it "shouldn't" be done. There will be the issue of optional
requirements, of course, and are you sure you just want to let a script
loose to automatically install software on your systems, but ultimately
the point, I suppose, is that it should be possible if you choose to do
this. I still think it's better to have a human read and address
requirements, but I don't think that what you're proposing would
negatively impact that process anyway.
This may be the point in the discussion where time spent creating and
submitting patches would further advance the cause than any other sort
of action could.
Jim Diamond
> On Tue, 15 Mar 2011 19:13:06 +0000 (UTC), Doug713705 wrote:
>
>>> While I agree that reading the README is always a good idea, having
>>> the information about required dependencies in an easily-parsable
>>> format would be beneficial for automating things.
>>
>> You perfectly understood my thought.
>
> ... and I missed that the point of the proposal was to have it be
> possible for automated parsing of the requirements. I have to admit
> that for my own purposes it would make no difference, but that doesn't I
> think it "shouldn't" be done. There will be the issue of optional
> requirements, of course, and are you sure you just want to let a script
> loose to automatically install software on your systems,
Good point. I would modify my script so that when I say
slackbuild xyz
it would go and see if there are any requirements I don't have
installed, and then it could tell me what I am missing, and ask me if
I want to go ahead and install them.
> I still think it's better to have a human read and address
> requirements,
I agree.
> but I don't think that what you're proposing would negatively impact
> that process anyway.
> This may be the point in the discussion where time spent creating and
> submitting patches would further advance the cause than any other sort
> of action could.
Yet another good point :-)
Thanks for offering to do that ;-)
Jim
Doug713705
alt.os.linux.slackware :
> On Tue, 15 Mar 2011 19:13:06 +0000 (UTC), Doug713705 wrote:
>
>>> While I agree that reading the README is always a good idea, having
>>> the information about required dependencies in an easily-parsable
>>> format would be beneficial for automating things.
>>
>> You perfectly understood my thought.
>
> ... and I missed that the point of the proposal was to have it be
> possible for automated parsing of the requirements. I have to admit
> that for my own purposes it would make no difference, but that doesn't I
> think it "shouldn't" be done. There will be the issue of optional
> requirements, of course, and are you sure you just want to let a script
> loose to automatically install software on your systems, but ultimately
> the point, I suppose, is that it should be possible if you choose to do
> this. I still think it's better to have a human read and address
> requirements, but I don't think that what you're proposing would
> negatively impact that process anyway.
IMO, using such an automated script, as I already do without
any dependency checking, does not mean exempting user of reading the
README.
Reading the README should always be the pre-requirement in any
installation process.
But once README(s) read and understood, calling a single script to
download, compile, install and archive the package would be a great
improvement of SBo and will not be an amazing work for mainteners (Noone
here is asking this to be done in the next few days, and this could wait
until the package's next revision).
> This may be the point in the discussion where time spent creating and
> submitting patches would further advance the cause than any other sort
> of action could.
I may have misunderstood, but how patching something in SBo ?
Asking for a "REQUIRE line in info file" should be a simple notice for
package maintainers, something like a recommendation, then things will
change slowly while packages are updated in SBo repository.
Sylvain Robitaille
> I may have misunderstood, but how patching something in SBo ?
We're talking about scripts and text files, after all.
> Asking for a "REQUIRE line in info file" should be a simple notice for
> package maintainers, something like a recommendation, then things will
> change slowly while packages are updated in SBo repository.
Yes, but you're asking for those package maintainers to make a "leap of
faith" from maintaining their scripts and documentation as they are now,
to maintaining them the way you propose. The easiest way to get anyone
to make that leap of faith is to show them that it works ...
Sylvain Robitaille
>> This may be the point in the discussion where time spent creating and
>> submitting patches would further advance the cause than any other sort
>> of action could.
> ...
> Thanks for offering to do that ;-)
Nice try ... since I generally don't use slackbuilds.org scripts myself
(though I do sometimes refer to them for my own build scripts), and
since I'm not particularly advocating for the proposed change, I
honestly can say this isn't one I'm going to pitch-in for. Recall that
when I did advocate for a specific change in slackbuilds.org scripts, I
*was* prepared to put in the effort (turns out my offer wasn't necessary
since the slackbuilds maintainers were already moving in the direction I
proposed, independent of my proposal). This time I'm off the hook. :-)
Doug713705
alt.os.linux.slackware :
>> Asking for a "REQUIRE line in info file" should be a simple notice for
>> package maintainers, something like a recommendation, then things will
>> change slowly while packages are updated in SBo repository.
>
> Yes, but you're asking for those package maintainers to make a "leap of
> faith" from maintaining their scripts and documentation as they are now,
> to maintaining them the way you propose. The easiest way to get anyone
> to make that leap of faith is to show them that it works ...
Good point.
It sounds like a challenge, I will review my horrible script before
posting it here.
+Alan Hicks+
Hash: SHA1
On 2011-03-12, Grant <o...@grrr.id.au> wrote:
> Personally, I disagree with SBo's convention of installing extra packages
> to /usr, I prefer to install non-distro additions and updates to /usr/local.
PREFIX=/usr/local ./foo.SlackBuild
- --
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.11 (GNU/Linux)
iEYEARECAAYFAk1/2sQACgkQDyaEVbMHxsaUPgCdGN3zD/YFd+2KmY39TRIjfquv
S40An1wZgc7yxvI21Uky4puuGRmUCI/6
=ayXW
-----END PGP SIGNATURE-----
Grant
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 2011-03-12, Grant <o...@grrr.id.au> wrote:
>> Personally, I disagree with SBo's convention of installing extra packages
>> to /usr, I prefer to install non-distro additions and updates to /usr/local.
>
>PREFIX=/usr/local ./foo.SlackBuild
Yes wonderful. Except I don't do this frequently enough to remember that
simple adjustment! ;)
Another problem I had was the couple of SBos that I tried failed to work properly
out of the box, and thus it was easier for me to chase the original source rather
than discover whether it was the packager or package issue. Apps to do with
running leafnode (?) news (nntp) caching or local server program.
That happened some time ago, I so rarely install software that I simply don't
seek out SlackBuilds. If there was some complex package, yes. But I'm working
at the command line, there's hardly any complexity there.
I'd like to try CAD applications for electronics schematic capture and PCB
layout, I've not checked of there's SBs for them, not downloaded the software
tarballs either. Still tossing up whether to use windoze freebie or limited
software, or go the Linux raw, unfinished but free in the other sense software.
Either way will cost me entrance fee in learning as I've not used that type of
software since the early '90s. Thus I have little bias, other than which
application seems the easiest to learn and perform the fairly easy tasks I
need.
Grant.
Grant
>On Tue, 15 Mar 2011 17:35:11 -0300, Jim Diamond wrote:
>
>>> This may be the point in the discussion where time spent creating and
>>> submitting patches would further advance the cause than any other sort
>>> of action could.
>> ...
>> Thanks for offering to do that ;-)
>
>Nice try ... since I generally don't use slackbuilds.org scripts myself
>(though I do sometimes refer to them for my own build scripts), and
>since I'm not particularly advocating for the proposed change, I
>honestly can say this isn't one I'm going to pitch-in for. Recall that
>when I did advocate for a specific change in slackbuilds.org scripts, I
>*was* prepared to put in the effort (turns out my offer wasn't necessary
>since the slackbuilds maintainers were already moving in the direction I
>proposed, independent of my proposal). This time I'm off the hook. :-)
And, after all, we scratch our own itch first, publish the result to see
if others want to try it.
Grant.