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

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
>

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.

Frans van Berckel

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?

ben

On Wed, 2005-09-28 at 09:59 +0200,

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 ?

All the versions are ,, repository > livesupport

1.31.0-9 > boost >= 1.31
7.12.3-2 > curl >= 7.12.3

2.6.2-0 > gtk+ >= 2.6.1 (*with)
1.9.1 > atk >= 1.9.0,
2.6.3-1 > glib >= 2.6.1,
1.8.1 > pango >= 1.8.0,
3.6.1 > tiff >= 3.7.1

2.12-1 > gtkmm >= 2.5.5 (*with)
2.6.1 > glibmm >= 2.5.4,
2.0.6-1 > libsigc++ >= 2.0.6

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
>

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

ben

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


Akos

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:

http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011048.html

Benjamin,

> http://www.debian.org/doc/manuals/repository-howto/repository-howto.en.html
>
> 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...

I guess we can go for a simple one at first...

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


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


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.

so, this is a good test. in this page:

http://packages.debian.org/stable/libs/libxml++2.6

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:

http://www.debian.org/doc/manuals/maint-guide/index.en.html


for PEAR, I don't know how debian handles PEAR components...


Akos

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.

David
dmz@dmzs.com
dmz@debian.org

Michael Schultheiss wrote:

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

Does somebody know an easy and safe way to change php.ini from an shell/php
script?

Sebastian

On Fri, 30 Sep 2005 13:57:37 +0200

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

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.

Michael
livesupport@amellus.com
schultmc@debian.org

--
-------------------------------
Michael Schultheiss
E-mail: livesupport@amellus.com

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
th@red2head.com

Bruno Devos wrote:
> I suggest to use ".htaccess" files in given directories.

AFAIK that has no effect on PHP...

On Sat, 01 Oct 2005 11:58:47 +0200

> I think php module can be partly configured in .htaccess with
> php_value keyword.

Sure, it can. Not the settings PHP_INI_SYSTEM, but all we need:
http://www.php.net/manual/en/ini.php