how did you build these and have the libboost problems been resolved?
when i try to make my debian packages, i get a problem "tools build
jam_src bin linuxx86 bjam". looks like there's a ticket (#1364) that you
created about how a script needs to be written to handle compilations
under different processors, and somebody suggested a patch. i think i've
been pulling code out of CVS, and just now realized that I should be
using SVN. Hopefully that will help.
Also, do we have an unoffical debian repository that we could add to
sources.list so that we can apt-get source and resolve dependencies for
building packages from source on debian systems?
ben
On Mon, 2005-09-12 at 12:09 +0200, Frans van Berckel wrote:
> If you want to test the powerpc livesupport build please checkout
>
> http://www.xs4all.nl/~fberckel/debian_build_powerpc/
>
> I have problems with libboost 3.1 vs 3.2
>
> Thanks,
>
> Frans van Berckel
>
but do we have a repository for apt-get source, so that we can apt-get
build-dep? its pretty annoying to go into the debian control file and
have to manually resolve the build dependencies.
On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
> how did you build these and have the libboost problems been resolved?
> when i try to make my debian packages, i get a problem "tools build
> jam_src bin linuxx86 bjam". looks like there's a ticket (#1364) that you
> created about how a script needs to be written to handle compilations
> under different processors, and somebody suggested a patch. i think i've
> been pulling code out of CVS, and just now realized that I should be
> using SVN. Hopefully that will help.
>
> Also, do we have an unoffical debian repository that we could add to
> sources.list so that we can apt-get source and resolve dependencies for
> building packages from source on debian systems?
>
> ben
>
> On Mon, 2005-09-12 at 12:09 +0200, Frans van Berckel wrote:
> > If you want to test the powerpc livesupport build please checkout
> >
> > http://www.xs4all.nl/~fberckel/debian_build_powerpc/
> >
> > I have problems with libboost 3.1 vs 3.2
> >
> > Thanks,
> >
> > Frans van Berckel
> >
>
Benjamin Racher wrote:
> oh and of course the answer is in that ticket.
>
> but do we have a repository for apt-get source, so that we can apt-get
> build-dep? its pretty annoying to go into the debian control file and
> have to manually resolve the build dependencies.
it seems you do have debian expertise... would you want to give us a
hand in this regard?
On Tue, 2005-09-27 at 20:17 -0500, Benjamin Racher wrote:
> oh and of course the answer is in that ticket.
>
> but do we have a repository for apt-get source, so that we can apt-get
> build-dep? its pretty annoying to go into the debian control file and
> have to manually resolve the build dependencies.
>
> On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
This is be my ubuntu apt soures.list. I use the "main" "restricted"
"universe" and "multiverse" repository's for hoary, hoary-updates,
hoary-security and hoary-backports. And got with this sources.list no
problems of availability of build dependencies.
#
deb cdrom:[Ubuntu 5.04 _Hoary Hedgehog_ - Release powerpc (20050407)]/
hoary main restricted
On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
> how did you build these and have the libboost problems been resolved?
The same you do, with the ppc patch. No i think Akos is still be busy
with package handling of installing library's. I get no response of my
question about libboost yet.
Frans van Berckel wrote:
> On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
>
>>how did you build these and have the libboost problems been resolved?
>
>
> The same you do, with the ppc patch. No i think Akos is still be busy
> with package handling of installing library's. I get no response of my
> question about libboost yet.
well, the way to go about packing is get rid of the monolithic
livesupport-libs package, and have appropriate packages for all the
dependencies of livesupport.
this means we need the following packages unaltered:
and we need the following special packages, which have to include
patches made by the livesupport staff:
cppunit 1.10.2
gstreamer 0.8.10
lcov 1.3
libodbc++ 0.2.3 (patched against CVS version of 2005-04-04)
taglib 1.3.1
xmlrpc++ (patched against CVS version of 2004-07-13)
for further info, see this post on the ubuntu mailing list:
yeah, i've got around most things (i'm trying to compile this on a
debian unstable with powerpc, i don't like ubuntu as much as plain old
debian), found a couple bugs here and there... but now I'm stuck at the
very end where its trying to seperate the libraries into
debian/livesupport-libs
mv
-f /home/ben/Desktop/livesupport/livesupport/debian/livesupport/opt/livesuppor
n/gst-* \
/home/ben/Desktop/livesupport/livesupport/debian/livesupport-libs/o
ivesupport/bin
mv: cannot stat
`/home/ben/Desktop/livesupport/livesupport/debian/livesupport/opt
esupport/bin/gst-*': No such file or directory
make: *** [install-arch] Error 1
argh... enough for me today. goodnight folks.
ben
On Wed, 2005-09-28 at 10:12 +0200, Frans van Berckel wrote:
> On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
> > how did you build these and have the libboost problems been resolved?
>
> The same you do, with the ppc patch. No i think Akos is still be busy
> with package handling of installing library's. I get no response of my
> question about libboost yet.
>
> Frans van Berckel
>
Benjamin Racher wrote:
> yeah, i've got around most things (i'm trying to compile this on a
> debian unstable with powerpc, i don't like ubuntu as much as plain old
> debian), found a couple bugs here and there... but now I'm stuck at the
but I guess there wouldn't be much of a difference between the debian
directory (control file, etc.) for 'old' Debian and Ubuntu...
> very end where its trying to seperate the libraries into
> debian/livesupport-libs
>
> mv
> -f /home/ben/Desktop/livesupport/livesupport/debian/livesupport/opt/livesuppor
> n/gst-* \
> /home/ben/Desktop/livesupport/livesupport/debian/livesupport-libs/o
> ivesupport/bin
> mv: cannot stat
> `/home/ben/Desktop/livesupport/livesupport/debian/livesupport/opt
> esupport/bin/gst-*': No such file or directory
> make: *** [install-arch] Error 1
this means that gstreamer wasn't compiled & installed correclty...
On Wed, 2005-09-28 at 09:59 +0200, Ákos Maróy wrote:
> Benjamin Racher wrote:
> > oh and of course the answer is in that ticket.
> >
> > but do we have a repository for apt-get source, so that we can apt-get
> > build-dep? its pretty annoying to go into the debian control file and
> > have to manually resolve the build dependencies.
>
> it seems you do have debian expertise... would you want to give us a
> hand in this regard?
>
Akos,
Lets clear the (ubuntu) responsity's, on what i have found out - there
are channels and repository's.
Most of the time there are four channels available, but not always.
The channels i have activated are "main" "restricted" "universe" and
"multiverse". Universe and multiverse got packages not official
supported. If you check (your? -the?) sources.list the main is be
activeted by default.
There are running on the repository's for hoary, hoary-updates,
hoary-security and hoary-backports
Withe the sources.list i have posted, i have 15861 packages in synaptic
available, and do not need to install any packages by hand.
I use www.artfiles.org/ ,but this is be just a backup-site near to me
and can be changed back if you want to.
Akos thanks, ill go for an install until PEAR with this versions.
> well, the way to go about packing is get rid of the monolithic
> livesupport-libs package, and have appropriate packages for all the
> dependencies of livesupport.
>
> this means we need the following packages unaltered:
>
> boost >= 1.31
> curl >= 7.12.3
> gtk+ >= 2.6.1 (with atk >= 1.9.0, glib >= 2.6.1, pango >= 1.8.0, tiff >=
> 3.7.1)
> gtkmm >= 2.5.5 (with glibmm >= 2.5.4, libsigc++ >= 2.0.6)
> icu >= 3.0
> libxml++ >= 2.8.1
> some PEAR components
>
>
> and we need the following special packages, which have to include
> patches made by the livesupport staff:
>
> cppunit 1.10.2
> gstreamer 0.8.10
> lcov 1.3
> libodbc++ 0.2.3 (patched against CVS version of 2005-04-04)
> taglib 1.3.1
> xmlrpc++ (patched against CVS version of 2004-07-13)
>
>
> for further info, see this post on the ubuntu mailing list:
>
> http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011048.html
>
>
> Akos
I'd love to help! Although, I must be honest and admit that I'm learning
a lot of this stuff for the first time just by trying to get these
binaries made. I just learned what classes are in C++ (in fact I have a
test on it today), so please understand that I'm still a newbie to the
whole development process. But I hope that by working on an actual
project, that I'll learn all of this much faster. So if you're willing
to bear with me on some of this stuff, I'd love to help.
So basically, my shot is to get some PPC Debian (non-ubuntu, because
ubuntu sources.list lines can do weird stuff to a debian install)
packages of LiveSupport made (since dual G4s are the best computers we
have down at our radio station).
Debian ideas: I'll read up on creating an unofficial debian archive and
see if I can't set one up. Additionally, we should try to get
LiveSupport submitted into the official Debian archive after we get a
solid round of packages made, wasn't sure if it depends on any non-free
LAME libs though, doesn't seem like it.
I was also wondering about all the libraries included in LiveSupport. Is
it typical for software to do this? I understand that it creates a
certain about of stability to not have libraries always changing, but
man... it sure does take a long time to compile. What I'm thinking, and
this may be just from the Debian perspective... couldn't we just write
the php/core stuff, and let the dependencies (gstreamer, gtk, all this
stuff that's already been compiled and is available through Debian and
other distros archives) do the work? Does this make sense or am I bogus?
> I was also wondering about all the libraries included in LiveSupport. Is
> it typical for software to do this? I understand that it creates a
> certain about of stability to not have libraries always changing, but
> man... it sure does take a long time to compile. What I'm thinking, and
> this may be just from the Debian perspective... couldn't we just write
> the php/core stuff, and let the dependencies (gstreamer, gtk, all this
> stuff that's already been compiled and is available through Debian and
> other distros archives) do the work? Does this make sense or am I bogus?
>
> ben
It seems like you guys are trying to make LiveSupport work out of the
box by including all these libraries (despite the fact that I can't get
it to compile because of bugs in the libraries). For the poeople who
want out of the box software (Debian, RedHat, Gentoo, who else???)
aren't most of these libraries available through their Distros? The
point that I'm trying to make is: is it necessary for us to have these
libraries included in LiveSupport?
2.1-2 > icu >= 3.0
2.10.0-0 > libxml++ >= 2.8.1
1.4.0 > some PEAR components
(all pear ones needed are done and up to date) ,,
Frans van Berckel
On Wed, 2005-09-28 at 10:24 +0200, Ákos Maróy wrote:
> Frans van Berckel wrote:
> > On Tue, 2005-09-27 at 19:01 -0500, Benjamin Racher wrote:
> >
> >>how did you build these and have the libboost problems been resolved?
> >
> >
> > The same you do, with the ppc patch. No i think Akos is still be busy
> > with package handling of installing library's. I get no response of my
> > question about libboost yet.
>
> well, the way to go about packing is get rid of the monolithic
> livesupport-libs package, and have appropriate packages for all the
> dependencies of livesupport.
>
> this means we need the following packages unaltered:
>
> boost >= 1.31
> curl >= 7.12.3
> gtk+ >= 2.6.1 (with atk >= 1.9.0, glib >= 2.6.1, pango >= 1.8.0, tiff >=
> 3.7.1)
> gtkmm >= 2.5.5 (with glibmm >= 2.5.4, libsigc++ >= 2.0.6)
> icu >= 3.0
> libxml++ >= 2.8.1
> some PEAR components
>
>
> and we need the following special packages, which have to include
> patches made by the livesupport staff:
>
> cppunit 1.10.2
> gstreamer 0.8.10
> lcov 1.3
> libodbc++ 0.2.3 (patched against CVS version of 2005-04-04)
> taglib 1.3.1
> xmlrpc++ (patched against CVS version of 2004-07-13)
>
>
> for further info, see this post on the ubuntu mailing list:
>
> http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011048.html
>
>
> Akos
>
Benjamin Racher wrote:
> It seems like you guys are trying to make LiveSupport work out of the
> box by including all these libraries (despite the fact that I can't get
> it to compile because of bugs in the libraries). For the poeople who
> want out of the box software (Debian, RedHat, Gentoo, who else???)
> aren't most of these libraries available through their Distros? The
> point that I'm trying to make is: is it necessary for us to have these
> libraries included in LiveSupport?
Before I made a Gentoo-cvs ebuild and for most of the libraries I could
use the system ones. But some special Akos White-Voodoo patches were
just need to run the program, fixing bugs. Most of the work (hopefully)
gets into their 'normal' versions too.
Maybe it is good to have a 'this works, do not complain'-tools
directory, on the other hand, I didn't use the normal Makefile ever so I
only compile what I want.
> Maybe it is good to have a 'this works, do not complain'-tools
> directory, on the other hand, I didn't use the normal Makefile ever so I
> only compile what I want.
>
>
> Stefan
ah... yes I could see how that would make sense, especially if there are
bugs in the packages that livesupport depends upon. hmm... is there a
way that i could get those Akos White-Voodoo patches?
> ah... yes I could see how that would make sense, especially if there are
> bugs in the packages that livesupport depends upon. hmm... is there a
> way that i could get those Akos White-Voodoo patches?
Benjamin Racher wrote:
> Debian ideas: I'll read up on creating an unofficial debian archive and
> see if I can't set one up. Additionally, we should try to get
> LiveSupport submitted into the official Debian archive after we get a
> solid round of packages made, wasn't sure if it depends on any non-free
good point...
> LAME libs though, doesn't seem like it.
but we don't use lame... we use mad for decoding mp3s...
> I was also wondering about all the libraries included in LiveSupport. Is
> it typical for software to do this? I understand that it creates a
no, this would be the point: to get rid of the monolithic
livesupport-libs package, and use the appropriate packages for all the
libraries we depend on.
> certain about of stability to not have libraries always changing, but
> man... it sure does take a long time to compile. What I'm thinking, and
> this may be just from the Debian perspective... couldn't we just write
> the php/core stuff, and let the dependencies (gstreamer, gtk, all this
> stuff that's already been compiled and is available through Debian and
> other distros archives) do the work? Does this make sense or am I bogus?
yes, you're dead on.
a bit of a trick is to make updated packages with our patches for
libraries we needed to patch..
Frans van Berckel wrote:
> Akos,
>
> If i take a look on the versions i can install from the repository, I've
> got a lower version of tiff and icu. Will this be a problem ?
for ICU - yes, we do need >= 3.0.
for tiff - I'm not sure, gtk+ depends on tiff, this is why we needed it..
Benjamin Racher wrote:
> ah... yes I could see how that would make sense, especially if there are
> bugs in the packages that livesupport depends upon. hmm... is there a
> way that i could get those Akos White-Voodoo patches?
sure
it's not that voodoo though, and all of the patches have been submitted
upstream to the original package maintainers.
for the patches, see in each of the tools directories, the etc directory
- if there are patches for a library, you'll see them there.
but here's a complete list, in the ubuntu-devel e-mail I posted earlier:
a simple repository would be a handful of deb files in a directory, but
the more complex ones will automatically decipher architecture type,
main, non-free stuff, etc...
and then after we get that all setup, we can publish the url on the
website, and submit the url to http://www.apt-get.org so that people can
easily add the line to their sources.list file
but, still gotta make the packages though, and i can't seem to get
through an entire compilation without having a number of problems, this
time its cause i ran out of space *#duh! i'm assuming getting rid of the
monolithic libraries would help in this area. so, can the patches that
akos has made be applied to libraries through the makefile or in a deb
package? cause that would be a pretty sweet trick
compiling deb packages for powerpc i get hung up at
-- 'tools build jam_src bin linuxx86 bjam' having to change x86-->ppc
rest of these are compilation problems only occur when using gcc
4.xomething
-- in libodbc++-0.2.3-20050404/include/odbc++/drivermanager.h have to
add class ErrorHandler
-- ../../gtk/gtkmm/radioaction.h:101: 'class Gtk::RadioButtonGroup
Gtk::RadioAction::Group' has a double declaration.
so yeah, a variety of bugs with other libraries that i'll report to
respective maintainers, not much of a problem with actual livesupport
software. way to write some clean code guys! just gotta do this whole
thing on a computer with some space and see what happens.
> and then after we get that all setup, we can publish the url on the
> website, and submit the url to http://www.apt-get.org so that people can
> easily add the line to their sources.list file
yep, sounds like a good idea!
> but, still gotta make the packages though, and i can't seem to get
> through an entire compilation without having a number of problems, this
> time its cause i ran out of space *#duh! i'm assuming getting rid of the
> monolithic libraries would help in this area. so, can the patches that
> akos has made be applied to libraries through the makefile or in a deb
> package? cause that would be a pretty sweet trick
sure, that's the idea.
I'd really suggest going through our specific dependencies, one by one.
first try the ones that don't need patching, but make sure there are
debian packages from them. these are:
for example, check what debian packages are available of boost.
searching packages.debian.org reveals to me that now
libbost-date-time1.32.0 is available in the stable branch, and also
libbost-dev 1.32.0-6. so this should be OK (just make sure to install it)
for curl, I also see 7.13.2 (make sur to get libcurl3 and libcurl3-dev)
for gtk+, I see libgtk2.0-0 as veresiion 2.6.4-3, which should also be OK
for gtkmm, I see libgtkmm-2.4-1c2 and libgtkmm-2.4-dev version 2.6.2-1.1
in unstable only, but at least it's there...
for ICU, I see libicu34, with version 3.4-2 in unstable
for libxml++ we're in trouble, I can only see libxml++-2.6 as version
2.6.1 for both stable, testing and unstable - thus we need to create
libxml++-2.6 with version 2.8.1 or later.
you can get the source package to see how the libxml++ 2.6.1 deb package
is created. probably the debian-specific part is quite simple (just look
into the debian directory) - and you'll be easily able to create a
package with 2.8.1 sources.
I suggest you try this one first, as it will give you an introduction on
how to create debian packages. for a brief overview of debian packaging,
see:
?kos Mar?y wrote:
> for example, check what debian packages are available of boost.
>
> searching packages.debian.org reveals to me that now
> libbost-date-time1.32.0 is available in the stable branch, and also
> libbost-dev 1.32.0-6. so this should be OK (just make sure to install it)
Debian package development is done against the unstable distribution -
versions should be checked in unstable. Backports of livesupport for
Debian stable can be made at a later date.
Who is working on the debian build? Whoever it is, give me a shout, I'd
be happy to work with you to get it released into debian once the
packages are compliant with the latest package standards.
I'll go ahead and announce to the developers list my intent to
package/release livesupport.
>?kos Mar?y wrote:
>
>
>>for example, check what debian packages are available of boost.
>>
>>searching packages.debian.org reveals to me that now
>>libbost-date-time1.32.0 is available in the stable branch, and also
>>libbost-dev 1.32.0-6. so this should be OK (just make sure to install it)
>>
>>
>
>
>Debian package development is done against the unstable distribution -
>versions should be checked in unstable. Backports of livesupport for
>Debian stable can be made at a later date.
>
>
>
> Who is working on the debian build? Whoever it is, give me a shout, I'd
> be happy to work with you to get it released into debian once the
> packages are compliant with the latest package standards.
cool. you've probably seen my corrsepondance with Benjamin on this
list... I'd be really glad if you could join in...
> I'll go ahead and announce to the developers list my intent to
> package/release livesupport.
You can also use the function "ini_set" within the php script.
For instance:
ini_set("memory_limit","25M");
ini_set("max_execution_time","3600");
2005/9/30, Bruno Devos :
> I suggest to use ".htaccess" files in given directories.
>
> 2005/9/30, Sebastian Goebel :
> > Does somebody know an easy and safe way to change php.ini from an shell/php
> > script?
> >
> > Sebastian
> >
> >
>
On Fri, 30 Sep 2005 14:44:27 +0200 Bruno Devos wrote:
> You can also use the function "ini_set" within the php script.
>
> For instance:
> ini_set("memory_limit","25M");
> ini_set("max_execution_time","3600");
>
Thanks for the hint, now I remember .htacces
It must be allowed in https.conf by directive
Allow Override All
but this seems to vaguely to setup this
The following lines in .htaccess satisfy the needs:
php_value upload_max_filesize 100M
php_value post_max_size 101M
This file (htmlUI/var/.htaccess) was created by Tomas, is in the repository,
but will not copyed during install to target dir. Do you use another source?
May the settings in .htaccess should all moved to
apache/90_php_livesupport.conf, because .htaccess can be disabled by "Aloow
Override None" in httpd.conf.
On Fri, 30 Sep 2005 20:52:26 +0200 Sebastian Goebel wrote:
> Thanks for the hint, now I remember .htacces
> It must be allowed in https.conf by directive
> Allow Override All
> but this seems to vaguely to setup this
>
> The following lines in .htaccess satisfy the needs:
>
> php_value upload_max_filesize 100M
> php_value post_max_size 101M
>
> This file (htmlUI/var/.htaccess) was created by Tomas, is in the repository,
> but will not copyed during install to target dir. Do you use another source?
>
> May the settings in .htaccess should all moved to
> apache/90_php_livesupport.conf, because .htaccess can be disabled by "Aloow
> Override None" in httpd.conf.
>
> Tomas, can you clean up this issue?
>
> Thanks,
> Sebastian
>
>
> P.S.
> Some setting cannot changed in .htacces, see
> http://www.php.net/manual/en/ini.php
> But I am surprised, memeroy limit should be possible.
>
OK
The .htaccess is now copied during install process too.
And 90_php_livesupport.conf have been updated to values in .htaccess.
Tomas Hlava wrote:
> There is etc/apache/90_php_livesupport.conf in livesupport source,
> and section "Configuring Apache" in bin/postInstallStation.sh
> tries to guess the right target location for it, intall it and restart apache.
do you need to restart apache in case of changing php.ini settings?
if so, this feature is basically not implementable...
Michael Schultheiss wrote:
> David M. Zendzian wrote:
>
>>I'll go ahead and announce to the developers list my intent to
>>package/release livesupport.
>
>
> I'd like to help with the package maintenance - maybe we could start an
> Alioth project to work on the packaging.
glad to hear that there are so many poeple willing to contribute to
debian packaging! it's really heart-warming
we may start a project on alioth.debian.org, but we can also track all
the packaging-related issues on the livesupport developer pages...