So I "only" need to setup a VM, download a file from a personal PPA, add the source code and learn how to build a deb package... And every user need to do the same... Easy :)
On Wed, Apr 16, 2014 at 11:12 PM, Ramin K <ramin-l...@badapple.net> wrote: > It's easy to build your own packages with the files from the PPA > which is what we do. BTW, thanks Vincent for doing the groundwork. > > Simplest method might be: > - Decide which archs you need to target. Follow a how-to for setting up a > environment to build deb packages. I recommend dedicating a VM for each > arch though we only build for x86_64. > - Use the debian.tar.gz file from the PPA to populate the ./debian/ dir > - make a orig.tar.gz from dev22 or preferred revision > - probably take you 2-3 tries to get everything in the right place > - make the deb packages > - copy deb packages to your internal repo. > > Ramin > > > On 4/16/2014 12:07 PM, pablo platt wrote: > >> The Ubuntu PPA is great but it is not 'official' and I couldn't find >> Ubuntu 14.04 package. >> https://launchpad.net/~vbernat/+archive/haproxy-1.5 >> <https://launchpad.net/%7Evbernat/+archive/haproxy-1.5> >> >> >> Ubuntu 14.04 LTS will be out tomorrow which means that haproxy-1.5 will >> be included only in the next LTS release 2 years from now. >> That's why an official Ubuntu repo will be very useful. >> Nginx and MongoDB for example has one. >> >> Is there a script that we can use to build a deb package? >> >> >> On Wed, Apr 16, 2014 at 9:55 PM, Willy Tarreau <w...@1wt.eu >> <mailto:w...@1wt.eu>> wrote: >> >> Hi Apollon, >> >> On Wed, Apr 16, 2014 at 09:22:56PM +0300, Apollon Oikonomopoulos >> wrote: >> > (Cc'ing the Debian maintainers as well) >> > >> > Hi all, >> > >> > On 19:28 Wed 16 Apr , Willy Tarreau wrote: >> > > On Wed, Apr 16, 2014 at 07:14:31PM +0300, pablo platt wrote: >> > > > An official Ubuntu dev repo will also make testing easier. >> > > > It's much easier to use a apt-get than building from source >> and figuring >> > > > out command line options. >> > >> > Actually Vincent Bernat maintains a PPA with rebuilds of our Debian >> > packages from experimental, which should be handy for Ubuntu users: >> > >> > https://launchpad.net/~vbernat/+archive/haproxy-1.5 >> > >> > > >> > > I think we're getting close to a release so we should not >> harrass distro >> > > maintainers with that *now* (but we could have done years ago). >> That >> > > reminds me that I tend not to always realize how much time >> slips between >> > > versions, and to forget that sometimes a previous version has >> some >> > > bugs. >> > > >> > > What I'd expect from our users is to sometimes complain loudly >> and insist >> > > for having a new dev release when the latest snapshot has >> become more >> > > reliable than the last dev release if that makes their lifes >> easier. A >> > > new version doesn't cost much (1 hour to read the changelog, >> write a >> > > human-friendly summary in an announce e-mail and update the >> site). >> > >> > With my Debian hat on, I'd like to "complain" a bit about 1.5. Of >> course >> > we appreciate your dedication to making HAProxy rock-solid and >> > feature-complete and at this point as a user 1.5 has been pretty >> stable >> > for me (and the new features are definitely worth the wait). >> > >> > However, as Debian maintainers we probably will not replace 1.4 >> with 1.5 >> > in our main track (unstable -> testing -> wheezy-backports) until >> > 1.5-final is out; we would like to make sure that we will end up >> with a >> > proper 1.5 release in Debian Jessie (and not with a development >> snapshot >> > at any rate) that both, upstream and ourselves will be willing to >> > support. >> > >> > Unfortunately, this means that 1.5 currently gets less user >> exposure (at >> > least via Debian and Ubuntu), potentially slowing down the >> stabilization >> > process. So please, leave some features aside for 1.6 ;-) >> >> I know and the goal clearly is not to add new features to 1.5, but >> to fix >> what still remains to be fixed before the release otherwise we'd have >> to >> risk breaking some supposed stable setups later when backporting >> fixes : >> >> - fix the HTTP body parser to get rid of the mess it is when mixing >> redispatch with check_post, not to mention compression. >> >> - fix the compression to re-enable compression of chunked-encoded >> responses >> >> - adapt the check agent to the final API we agreed on the list a >> few >> weeks ago >> >> - fix the bind-process lameness. >> >> I'm still working on point #1 and making progress (I was even >> writing some >> architecture doc on it to engrave the changes so that we avoid >> breaking >> that soon again). #2 should follow shortly after that. #3 is >> apparently >> easy (I had a beginning of patch 2 months ago to start on it) but we >> noticed >> that the check agent touches many intimate parts of the checks and I >> expect >> a few surprizes again. However, I don't care much about minor bugs >> for the >> final release provided that the architecture is ready to accept fixes >> without putting users at risk. For #4, I think we can keep the users >> in a >> safe working area to prepare them for upgrades by simply emitting a >> few >> warnings in the configs leading to a corner case. >> >> I really think we're on the right track, we must just not stop >> efforts. >> And the fact that we get lots of bug reports is a good sign as well! >> >> Cheers, >> Willy >> >> >> >
