# Lighttpd v1.5.0 or Lighttpd v2.0.0 Where are they??

## E-TARD

I look here > https://packages.gentoo.org/package/www-servers/lighttpd

and don't see lighttpd v1.5.0 or lighttpd v2.0.0

Will they ever be added??

http://download.lighttpd.net/lighttpd/snapshots-1.5/

http://download.lighttpd.net/lighttpd/snapshots-2.0.x/

1.5 would be nice maybe list it as unstable in Gentoo

I know someone is going to reply with  :Rolling Eyes:  "Move to Nginx"  :Rolling Eyes:  well to do that would take time, time I do not have

and from what I have seen from others nginx can be a pain in the but so if I was to move to something I would go back to apache.

----------

## Perfect Gentleman

they are development versions, 1.5 is older 1.4.2, 2.0 is not much fresher 1.4.2

----------

## E-TARD

 *Perfect Gentleman wrote:*   

> they are development versions, 1.5 is older 1.4.2, 2.0 is not much fresher 1.4.2

 

Yes but 1.5 does things that 1.4 does not do,

so in many ways 1.5 is better because it has newer settings that can not be used in 1.4 & I have been w8ing for someone to make an ebuild file for 1.5

also I'm not saying to list it as stable in Gentoo packages it could be listed as unstable.

many website running lighty are running 1.5 & not 1.4

Also they have patched this for 1.5

http://www.securityfocus.com/bid/38036

http://download.lighttpd.net/lighttpd/security/lighttpd-1.5_fix_slow_request_dos.patch

http://download.lighttpd.net/lighttpd/security/lighttpd_sa_2010_01.txt

p.s. also looks like there will be a 1.4.36 sooner or later   :Very Happy:  may want to add that

http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2989/entry/branches/lighttpd-1.4.x/NEWS

----------

## E-TARD

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  :Rolling Eyes: 

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

----------

## steveL

 *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?
> 
> ..
> ...

 

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.

----------

## E-TARD

 *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?
> 
> ..
> ...

 

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?

----------

## steveL

 *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: 

```
$ 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.

----------

## E-TARD

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   :Very Happy: 

I was confused  :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}   :Confused: 

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.   :Cool: 

----------

## steveL

 *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: 

```
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: 

```
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.

----------

