View previous topic :: View next topic |
Author |
Message |
E-TARD Tux's lil' helper
Joined: 14 Feb 2006 Posts: 100 Location: Silicon Valley California
|
|
Back to top |
|
|
Perfect Gentleman Veteran
Joined: 18 May 2014 Posts: 1256
|
Posted: Fri May 29, 2015 9:01 am Post subject: |
|
|
they are development versions, 1.5 is older 1.4.2, 2.0 is not much fresher 1.4.2 |
|
Back to top |
|
|
E-TARD Tux's lil' helper
Joined: 14 Feb 2006 Posts: 100 Location: Silicon Valley California
|
|
Back to top |
|
|
E-TARD Tux's lil' helper
Joined: 14 Feb 2006 Posts: 100 Location: Silicon Valley California
|
Posted: Thu Aug 27, 2015 10:00 pm Post subject: |
|
|
So I take it no knows if it will ever be added????
On a side note does anyone know where I can find newer ebuilds for 1.5 & 2.0?
So far this is the only place https://github.com/longlene/clx/tree/master/www-servers/lighttpd for v1.5 made 3 years ago.
don't know how well it will work, I may have to compare lighttpd-1.5.0_p1857-r1.ebuild to lighttpd-1.4.35-r2 just more work
Some day I just need to move off this web service but at this point in time I just can't do that (way more work & no time to do it)
also can anyone say if v1.4.36 will be added???
you can find it here http://www.lighttpd.net/download/
v1.4.36 July 26, 2015
This release contains mostly bug fixes.
Important changes
•[ssl] disable SSL3.0 by default
•escape all strings for logging
•fix segfault when temp file for upload couldn’t be created (found by coverity)
•changes to the internal API for buffers, chunks and more; 3rd party plugins are likely to break _________________ https://twitter.com/etard_webcam |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Aug 27, 2015 10:29 pm Post subject: |
|
|
E-TARD wrote: | So I take it no knows if it will ever be added????
On a side note does anyone know where I can find newer ebuilds for 1.5 & 2.0?
..
also can anyone say if v1.4.36 will be added???
you can find it here http://www.lighttpd.net/download/ |
Jeez, just try copying the older version ebuild file to a new one, changing the version on the end, before '.ebuild'.
You'll get loads of help with that on here, and on IRC: chat.freenode.org #gentoo-dev-help.
eg: this was my first ebuild. |
|
Back to top |
|
|
E-TARD Tux's lil' helper
Joined: 14 Feb 2006 Posts: 100 Location: Silicon Valley California
|
Posted: Thu Aug 27, 2015 10:49 pm Post subject: |
|
|
steveL wrote: | E-TARD wrote: | So I take it no knows if it will ever be added????
On a side note does anyone know where I can find newer ebuilds for 1.5 & 2.0?
..
also can anyone say if v1.4.36 will be added???
you can find it here http://www.lighttpd.net/download/ |
Jeez, just try copying the older version ebuild file to a new one, changing the version on the end, before '.ebuild'.
You'll get loads of help with that on here, and on IRC: chat.freenode.org #gentoo-dev-help.
eg: this was my first ebuild. |
I have been using Gentoo for 14 almost 15 years & have never the needed to make an ebuild or go looking for one.
The package manager has always had what I needed.
yes there was one time where I had to edit a ebuild for (john the ripper) but that's it, I have not spent a lot of time with ebuild files.
Quote: | Jeez, just try copying the older version ebuild file to a new one, changing the version on the end, before '.ebuild'. |
I take it your taking about the v1.4.36 ebuild & not the 1.5 ebuild I found? or are you talking about both of them? _________________ https://twitter.com/etard_webcam |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Aug 28, 2015 12:40 pm Post subject: |
|
|
Quote: | Jeez, just try copying the older version ebuild file to a new one, changing the version on the end, before '.ebuild'. |
E-TARD wrote: | I take it your taking about the v1.4.36 ebuild & not the 1.5 ebuild I found? or are you talking about both of them? |
I'd start with the earlier one, since it's just a point increment, so the newly-versioned ebuild will hopefully "just work".
Even if it doesn't, you won't have to contend with major changes in the codebase, and can just get used to working on an ebuild itself.
Once you've got that going, it'll be a lot easier to deal with the major increment.
I'd advise you to build the software manually outside portage first, in both cases, and only then move on to automating the process, to keep conceptual separation.
Beware dodgy sources for bash on the internet (including Linux distro developers.) #bash is the best place to learn apart from: man bash. (Beware the pitfalls.)
ALL ebuilds are written in bash (and always will be: or it'd be another format), so you can't get away from it, if you want to tweak them to your satisfaction.
BASH can appear complex; it's always useful to understand POSIX sh, since bash (as other shells, ksh-derivatives in particular) extends it, and it is also what makefiles wrap.
##workingset if you want help with build-system tools, like autoconf and automake, collectively autotools: Code: | $ echo /usr/portage/eclass/autotools*
/usr/portage/eclass/autotools-multilib.eclass /usr/portage/eclass/autotools-utils.eclass /usr/portage/eclass/autotools.eclass | which are used in most FLOSS software; as well as toolchain, starting with make, and including compilers, linkers and loaders, and binutils like nm or objcopy.
Here is a gentler intro to bash, on a site belonging to TheBonsai, another #bash regular/professional admin; wooledge.org is greycat, who is a legend in the BASH scripting world.
Another person to pay deep attention to, is twkm, in ##workingset, #bash, ##c or ##posix
The latter two are for coding, though you need to grok StandardC from ##c before you try to take on POSIX, since it extends StdC. I also highly recommend #awk since it's a very useful build-util, as well as an awesomely clean language, and the awkbook is a classic of CS.
If that's an overload, don't worry about it; someone else may find the info useful.
Good luck with whatever you decide to do. |
|
Back to top |
|
|
E-TARD Tux's lil' helper
Joined: 14 Feb 2006 Posts: 100 Location: Silicon Valley California
|
Posted: Sun Aug 30, 2015 1:53 am Post subject: |
|
|
Ok I did not "build the software manually outside of portage"
because I could roll it back easy with out Fing any thing up.
So I took lighttpd-1.4.35-r2.ebuild & renamed it to lighttpd-1.4.36.ebuild
& changed SRC_URI="http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.36.tar.gz" & it works
I was confused about ${P} SRC_URI="http://download.lighttpd.net/lighttpd/releases-1.4.x/${P}.tar.bz2"
could not find anything about inside the ebuild file, so I gave up on it & just put in the full url.
look at 20 ebuild files SRC_URI= & did not see any ${P}
also Thanks for all the info & no it was not an "overload" I love to learn
and I will try to put some time into learning more about ebuild files. _________________ https://twitter.com/etard_webcam |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Aug 30, 2015 3:31 pm Post subject: |
|
|
E-TARD wrote: | I was confused :? about ${P} SRC_URI="http://download.lighttpd.net/lighttpd/releases-1.4.x/${P}.tar.bz2"
could not find anything about inside the ebuild file, so I gave up on it & just put in the full url.
look at 20 ebuild files SRC_URI= & did not see any ${P} :? |
That's because it's predefined for you.
The package name and version are taken from the filename of the ebuild; that's why renaming it to a differently-versioned filename works. :-)
Though you don't need the crufty "${P}" braces; "$P" works fine.
The most important thing to remember, is always to quote parameter expansions, to avoid field-splitting and globbing of chars in the string.
The rare times when you actually want field-splitting and wildcard-expansion of a parameter (the shell term for "variable") to happen are very exceptional cases, and should only ever be with variables you set in the script itself, preferably checked for validity in general subroutines (as opposed to say, a routine and its helper within the same few lines.)
As an example, the only time I can think of where I use an unquoted parameter for field-split, is with an optional switch like: Code: | local t
[[ $fubar = *foo* ]] && t=-t
..
cmdfunc $t "$foo" "${par[@]}" | where I've set it (or not) myself, ie: it's a local and I can be sure of its literal content.
IF you quote your expansions, you can deal with any filename (indeed any C string) as data, and you can then rely on those routines from higher-level functions.
If not, your script will be fragile, and prone to messing up end-users' systems, as well as useless for reuse.
The braces are primarily for manipulative parameter expansions, like: "${foo%.mp3}" or: "${0##*/}", and professional bash-scripters only use the redundant form, when it's required to avoid the next alpha-numeric or '_' character from being interpreted as part of the varname. (You'll realise this if you /autojoin #bash for a few months, as recommended.)
For most pathnames, this never comes up, and it only ever comes up when you're concatenating a parameter with a literal, eg: "${foo}str".
It's not needed in "$foo$bar" for example, nor in: "$P.tar.bz2" nor: "$dir/fname" so we save it for manipulations, where we need to open and close a bracketing-context (much like this.)
The very seldom concatenation doesn't jar, as it alerts us to the join.
So given the above link, to do the above more generically, we'd use: Code: | cmdfunc ${t:+"$t"} "$foo" "${par[@]}" | to be sure the parameter were quoted, and not passed at all if empty.
You don't usually want to get into that, ime, but it's good to know how to do it, as it applies to any POSIX-compliant sh; ie: every modern UNIX shell, including the minimal ones. (Arrays don't, mind; ksh93 and its derivatives, like bash and mksh have them.)
Quote: | also Thanks for all the info & no it was not an "overload" I love to learn |
Glad to hear it :-)
Here's some more info on parameter expansions (I wrote up the bit on arrays after floyd-n-milan told me the trick. ;)
Quote: | and I will try to put some time into learning more about ebuild files. 8) |
Great; don't forget #gentoo-dev-help; I got the link to the devmanual from their /topic. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|