Build question

[Jon Ciesla]

Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've run into a snag*, and I need some assistance.  The gallery-2.3-full.zip contains several prebuilt .jar files, which in turn contain prebuild .class files.  In fedora, we build from source, and so I am faced with either dropping gallery from Fedora (which I *really* don't want to do) or find a way to build from .java sources.

Is it documented anywhere either in the G2 wiki or in the tarball how to build the entire project from source?  I've done svn checkout of trunk, and I'm not sure which subdirectories need to be present at build or even how to do so. I'd like to not have to use the whole 600MB+ trunk checkout if I can avoid it.

I've found trunk/packaging/gallery2/build.php, which appears to do an svn checkout among other things, but I can't find where the .class files contained within the .jar files are build.

I should also point out, in Gallery bug 2585568, that the GPL stipulate that when binaries are shipped, the source must also be made available.  I'm sure it is, and I just haven't found it, but others might question the projects adherence to the GPL.

Any assistance would be greatly appreciated.

Thanks,

Jon

*https://bugzilla.redhat.com/show_bug.cgi?id=484566

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris Kelly-2]

Didn't you cover some of this in the bug thread?

https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130

"With some wrangling, I've been able to build the ImageTools jar"

And we agreed that you could pull out the db2 stuff.

It unfortunate that the Java things in Gallery 2 are such a mess, but
Gallery 3 is java-free and won't have this problem, and it wouldn't hurt
my feelings if G2 was not available in Fedora.  We're not putting any
more effort into Gallery 2.

And per Kevin's Comment #18:  My "100% sure" comment was guessing how
much time you'd want to put in. you could certainly look at timestamps
of releases to see what applets were in svn at that time, then look at
when those applets where checked in, then get the code that was in trunk
for them at that time, check out that code, look at the build scripts
for that time, build them, etc, but that would take some time.  Still
not sure how us not making it easy to build a few small components of G2
from source, when it is possible if you work on it, is a "blatant
disregard" of the GPL.

Just trying to figure out what more you're asking for. Thanks!

-Chris


Jon Ciesla wrote:

> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've run into a snag*, and I need some assistance.  The gallery-2.3-full.zip contains several prebuilt .jar files, which in turn contain prebuild .class files.  In fedora, we build from source, and so I am faced with either dropping gallery from Fedora (which I *really* don't want to do) or find a way to build from .java sources.
>
> Is it documented anywhere either in the G2 wiki or in the tarball how to build the entire project from source?  I've done svn checkout of trunk, and I'm not sure which subdirectories need to be present at build or even how to do so. I'd like to not have to use the whole 600MB+ trunk checkout if I can avoid it.
>
> I've found trunk/packaging/gallery2/build.php, which appears to do an svn checkout among other things, but I can't find where the .class files contained within the .jar files are build.
>
> I should also point out, in Gallery bug 2585568, that the GPL stipulate that when binaries are shipped, the source must also be made available.  I'm sure it is, and I just haven't found it, but others might question the projects adherence to the GPL.
>
> Any assistance would be greatly appreciated.
>
> Thanks,
>
> Jon
>
> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Some, yes, that bug was closed automatically, and I was asked not to
pursue such topics in the bug tracker in 2750571.

At any rate, I would agree that it seems like quite a lot of work to
build the java components.  I am a complete stranger to Java, and by
"build the ImageTools jar", I meant re-compose it from it's extracted
contents, which is not nearly as far as I need to be.

My point is not that you're disregarding the letter of the GPL, since
the source is publicly available, just that some might misinterpret the
effort required to obtain the full source as disregarding the spirit of
the GPL, since though available, it's not as if one can say "download
tarball X from URL Y".  I'd love to see the process documented
somewhere, but that's neither here nor there.

I understand that with G3 being imminent, G2 is effectively dead.  The
catch is, I don't know when G3 is coming, and G2 is already in Fedora
and has been for some time.  The packages currently available for
gallery in Fedora contain prebuilt jars.  Gallery should not have been
packaged this way in the first place, but that was done more than 3
years ago and is pretty much water under the bridge.

The situation I find myself in as the new maintainer is that the package
as it stands violates Fedora's legal guidelines, and has a large user
base.  This leaves me with the following choices:
   
    1. Drop G2 from Fedora and package G3 (which presumably will not
have this problem) at it's release.  This would be very disappointing.  
Perhaps (and understandably) not for you, but for Fedora's G2 users,
myself included.
    2. Push a version of G2 minus the .jar files.  This would almost
certainly break G2, correct?
    3. Build the java bits from source.  Laborious, as it turns out, and
possibly not worth the time if G3 is coming soon.

So, I guess, unless someone else knows of a simpler way to grab and
build the source, I'd like to know an ETA for G3, how the upgrade
process looks from G2 to G3, and if a jarless G2 would work at all.  G3
Alpha 3 is nearly a  month old, and based on the timing of Alpha 2, I'd
guess either Alpha 4, or a Beta of some type might be next, but that's
subject to my ignorance of your schedule. :)

Chris Kelly wrote:

> Didn't you cover some of this in the bug thread?
>
> https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130
>
> "With some wrangling, I've been able to build the ImageTools jar"
>
> And we agreed that you could pull out the db2 stuff.
>
> It unfortunate that the Java things in Gallery 2 are such a mess, but
> Gallery 3 is java-free and won't have this problem, and it wouldn't hurt
> my feelings if G2 was not available in Fedora.  We're not putting any
> more effort into Gallery 2.
>
> And per Kevin's Comment #18:  My "100% sure" comment was guessing how
> much time you'd want to put in. you could certainly look at timestamps
> of releases to see what applets were in svn at that time, then look at
> when those applets where checked in, then get the code that was in trunk
> for them at that time, check out that code, look at the build scripts
> for that time, build them, etc, but that would take some time.  Still
> not sure how us not making it easy to build a few small components of G2
> from source, when it is possible if you work on it, is a "blatant
> disregard" of the GPL.
>
> Just trying to figure out what more you're asking for. Thanks!
>
> -Chris
>
>
> Jon Ciesla wrote:
>  
>> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've run into a snag*, and I need some assistance.  The gallery-2.3-full.zip contains several prebuilt .jar files, which in turn contain prebuild .class files.  In fedora, we build from source, and so I am faced with either dropping gallery from Fedora (which I *really* don't want to do) or find a way to build from .java sources.
>>
>> Is it documented anywhere either in the G2 wiki or in the tarball how to build the entire project from source?  I've done svn checkout of trunk, and I'm not sure which subdirectories need to be present at build or even how to do so. I'd like to not have to use the whole 600MB+ trunk checkout if I can avoid it.
>>
>> I've found trunk/packaging/gallery2/build.php, which appears to do an svn checkout among other things, but I can't find where the .class files contained within the .jar files are build.
>>
>> I should also point out, in Gallery bug 2585568, that the GPL stipulate that when binaries are shipped, the source must also be made available.  I'm sure it is, and I just haven't found it, but others might question the projects adherence to the GPL.
>>
>> Any assistance would be greatly appreciated.
>>
>> Thanks,
>>
>> Jon
>>
>> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>>
>>    

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris Kelly-2]

My frustration derives from some of the comments in the fedora bug
tracker, so sorry about that!

The number of people that know the Java side of G2 is very small.
Perhaps one of them will chime in here, but to compare it to the way G2
is packaged in Fedora currently, most of the work on that was a long
time ago.

Per your options:

1. G2 is a PHP webapp so getting it from a vendor instead of through a
packaging system isn't too bad. I have bunches of Gentoo, CentOS, and
Debian systems all running PHP applications, and I've never liked using
the distro's package management system to install them.

2. G2 will work without the Java components, just the fancy
drag-and-drop uploader won't be there and it won't work with DB2.  There
are plenty of other upload methods available, so this shouldn't be that
big of a deal.

3.  I'd agree that it's not worth the time. Either of the above are a
much better idea.

G3 Beta 1 should be next and should be soon.  You can see what is left here:

http://apps.sourceforge.net/trac/gallery/roadmap

I think work is finishing up on the G2 importer which should be in Beta
1 in a functional form.  Albums/Images/Users should all transfer over,
but since the feature set of G3 is a lot smaller, there will be things
that don't transfer over (like all kinds of sizes for resizes,
permissions, etc)

-Chris

Jon Ciesla wrote:

> Some, yes, that bug was closed automatically, and I was asked not to
> pursue such topics in the bug tracker in 2750571.
>
> At any rate, I would agree that it seems like quite a lot of work to
> build the java components.  I am a complete stranger to Java, and by
> "build the ImageTools jar", I meant re-compose it from it's extracted
> contents, which is not nearly as far as I need to be.
>
> My point is not that you're disregarding the letter of the GPL, since
> the source is publicly available, just that some might misinterpret the
> effort required to obtain the full source as disregarding the spirit of
> the GPL, since though available, it's not as if one can say "download
> tarball X from URL Y".  I'd love to see the process documented
> somewhere, but that's neither here nor there.
>
> I understand that with G3 being imminent, G2 is effectively dead.  The
> catch is, I don't know when G3 is coming, and G2 is already in Fedora
> and has been for some time.  The packages currently available for
> gallery in Fedora contain prebuilt jars.  Gallery should not have been
> packaged this way in the first place, but that was done more than 3
> years ago and is pretty much water under the bridge.
>
> The situation I find myself in as the new maintainer is that the package
> as it stands violates Fedora's legal guidelines, and has a large user
> base.  This leaves me with the following choices:
>      1. Drop G2 from Fedora and package G3 (which presumably will not
> have this problem) at it's release.  This would be very disappointing.
> Perhaps (and understandably) not for you, but for Fedora's G2 users,
> myself included.
>    2. Push a version of G2 minus the .jar files.  This would almost
> certainly break G2, correct?
>    3. Build the java bits from source.  Laborious, as it turns out, and
> possibly not worth the time if G3 is coming soon.
>
> So, I guess, unless someone else knows of a simpler way to grab and
> build the source, I'd like to know an ETA for G3, how the upgrade
> process looks from G2 to G3, and if a jarless G2 would work at all.  G3
> Alpha 3 is nearly a  month old, and based on the timing of Alpha 2, I'd
> guess either Alpha 4, or a Beta of some type might be next, but that's
> subject to my ignorance of your schedule. :)
>
> Chris Kelly wrote:
>> Didn't you cover some of this in the bug thread?
>>
>> https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130
>>
>>
>> "With some wrangling, I've been able to build the ImageTools jar"
>>
>> And we agreed that you could pull out the db2 stuff.
>>
>> It unfortunate that the Java things in Gallery 2 are such a mess, but
>> Gallery 3 is java-free and won't have this problem, and it wouldn't hurt
>> my feelings if G2 was not available in Fedora.  We're not putting any
>> more effort into Gallery 2.
>>
>> And per Kevin's Comment #18:  My "100% sure" comment was guessing how
>> much time you'd want to put in. you could certainly look at timestamps
>> of releases to see what applets were in svn at that time, then look at
>> when those applets where checked in, then get the code that was in trunk
>> for them at that time, check out that code, look at the build scripts
>> for that time, build them, etc, but that would take some time.  Still
>> not sure how us not making it easy to build a few small components of G2
>> from source, when it is possible if you work on it, is a "blatant
>> disregard" of the GPL.
>>
>> Just trying to figure out what more you're asking for. Thanks!
>>
>> -Chris
>>
>>
>> Jon Ciesla wrote:
>>  
>>> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've
>>> run into a snag*, and I need some assistance.  The
>>> gallery-2.3-full.zip contains several prebuilt .jar files, which in
>>> turn contain prebuild .class files.  In fedora, we build from source,
>>> and so I am faced with either dropping gallery from Fedora (which I
>>> *really* don't want to do) or find a way to build from .java sources.
>>>
>>> Is it documented anywhere either in the G2 wiki or in the tarball how
>>> to build the entire project from source?  I've done svn checkout of
>>> trunk, and I'm not sure which subdirectories need to be present at
>>> build or even how to do so. I'd like to not have to use the whole
>>> 600MB+ trunk checkout if I can avoid it.
>>>
>>> I've found trunk/packaging/gallery2/build.php, which appears to do an
>>> svn checkout among other things, but I can't find where the .class
>>> files contained within the .jar files are build.
>>>
>>> I should also point out, in Gallery bug 2585568, that the GPL
>>> stipulate that when binaries are shipped, the source must also be
>>> made available.  I'm sure it is, and I just haven't found it, but
>>> others might question the projects adherence to the GPL.
>>>
>>> Any assistance would be greatly appreciated.
>>>
>>> Thanks,
>>> Jon
>>>
>>> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>>>
>>>    
>
>

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

I understand your frustration.  I'm one of the more uptight GNUites I
know, so I see it all the time. ;)

Hopefully one of the java folk will chime in.  In the meantime:

1. I used to do that as well, but find it easier to do mass deployments
with packages.  To each their own, and I like that distros that include
packages give admins the option.

2. I can live with that, under the circumstances.  I'll drop the remote,
slideshowapplet, and uploadapplet module subpackages, and all the .jar
files.  That will fix our legal issue.

3. See #2.

Re: the roadmap, am I missing something, or is there no 3.0 milestone?  
At any rate, it looks like late May/early June might be a reasonable
estimate for 3.0, no?

When G3 is out, I'll package it to replace G2.

Thanks for the information, and the assistance.

Chris Kelly wrote:

> My frustration derives from some of the comments in the fedora bug
> tracker, so sorry about that!
>
> The number of people that know the Java side of G2 is very small.
> Perhaps one of them will chime in here, but to compare it to the way G2
> is packaged in Fedora currently, most of the work on that was a long
> time ago.
>
> Per your options:
>
> 1. G2 is a PHP webapp so getting it from a vendor instead of through a
> packaging system isn't too bad. I have bunches of Gentoo, CentOS, and
> Debian systems all running PHP applications, and I've never liked using
> the distro's package management system to install them.
>
> 2. G2 will work without the Java components, just the fancy
> drag-and-drop uploader won't be there and it won't work with DB2.  There
> are plenty of other upload methods available, so this shouldn't be that
> big of a deal.
>
> 3.  I'd agree that it's not worth the time. Either of the above are a
> much better idea.
>
> G3 Beta 1 should be next and should be soon.  You can see what is left here:
>
> http://apps.sourceforge.net/trac/gallery/roadmap
>
> I think work is finishing up on the G2 importer which should be in Beta
> 1 in a functional form.  Albums/Images/Users should all transfer over,
> but since the feature set of G3 is a lot smaller, there will be things
> that don't transfer over (like all kinds of sizes for resizes,
> permissions, etc)
>
> -Chris
>
> Jon Ciesla wrote:
>  
>> Some, yes, that bug was closed automatically, and I was asked not to
>> pursue such topics in the bug tracker in 2750571.
>>
>> At any rate, I would agree that it seems like quite a lot of work to
>> build the java components.  I am a complete stranger to Java, and by
>> "build the ImageTools jar", I meant re-compose it from it's extracted
>> contents, which is not nearly as far as I need to be.
>>
>> My point is not that you're disregarding the letter of the GPL, since
>> the source is publicly available, just that some might misinterpret the
>> effort required to obtain the full source as disregarding the spirit of
>> the GPL, since though available, it's not as if one can say "download
>> tarball X from URL Y".  I'd love to see the process documented
>> somewhere, but that's neither here nor there.
>>
>> I understand that with G3 being imminent, G2 is effectively dead.  The
>> catch is, I don't know when G3 is coming, and G2 is already in Fedora
>> and has been for some time.  The packages currently available for
>> gallery in Fedora contain prebuilt jars.  Gallery should not have been
>> packaged this way in the first place, but that was done more than 3
>> years ago and is pretty much water under the bridge.
>>
>> The situation I find myself in as the new maintainer is that the package
>> as it stands violates Fedora's legal guidelines, and has a large user
>> base.  This leaves me with the following choices:
>>      1. Drop G2 from Fedora and package G3 (which presumably will not
>> have this problem) at it's release.  This would be very disappointing.
>> Perhaps (and understandably) not for you, but for Fedora's G2 users,
>> myself included.
>>    2. Push a version of G2 minus the .jar files.  This would almost
>> certainly break G2, correct?
>>    3. Build the java bits from source.  Laborious, as it turns out, and
>> possibly not worth the time if G3 is coming soon.
>>
>> So, I guess, unless someone else knows of a simpler way to grab and
>> build the source, I'd like to know an ETA for G3, how the upgrade
>> process looks from G2 to G3, and if a jarless G2 would work at all.  G3
>> Alpha 3 is nearly a  month old, and based on the timing of Alpha 2, I'd
>> guess either Alpha 4, or a Beta of some type might be next, but that's
>> subject to my ignorance of your schedule. :)
>>
>> Chris Kelly wrote:
>>    
>>> Didn't you cover some of this in the bug thread?
>>>
>>> https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130
>>>
>>>
>>> "With some wrangling, I've been able to build the ImageTools jar"
>>>
>>> And we agreed that you could pull out the db2 stuff.
>>>
>>> It unfortunate that the Java things in Gallery 2 are such a mess, but
>>> Gallery 3 is java-free and won't have this problem, and it wouldn't hurt
>>> my feelings if G2 was not available in Fedora.  We're not putting any
>>> more effort into Gallery 2.
>>>
>>> And per Kevin's Comment #18:  My "100% sure" comment was guessing how
>>> much time you'd want to put in. you could certainly look at timestamps
>>> of releases to see what applets were in svn at that time, then look at
>>> when those applets where checked in, then get the code that was in trunk
>>> for them at that time, check out that code, look at the build scripts
>>> for that time, build them, etc, but that would take some time.  Still
>>> not sure how us not making it easy to build a few small components of G2
>>> from source, when it is possible if you work on it, is a "blatant
>>> disregard" of the GPL.
>>>
>>> Just trying to figure out what more you're asking for. Thanks!
>>>
>>> -Chris
>>>
>>>
>>> Jon Ciesla wrote:
>>>  
>>>      
>>>> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've
>>>> run into a snag*, and I need some assistance.  The
>>>> gallery-2.3-full.zip contains several prebuilt .jar files, which in
>>>> turn contain prebuild .class files.  In fedora, we build from source,
>>>> and so I am faced with either dropping gallery from Fedora (which I
>>>> *really* don't want to do) or find a way to build from .java sources.
>>>>
>>>> Is it documented anywhere either in the G2 wiki or in the tarball how
>>>> to build the entire project from source?  I've done svn checkout of
>>>> trunk, and I'm not sure which subdirectories need to be present at
>>>> build or even how to do so. I'd like to not have to use the whole
>>>> 600MB+ trunk checkout if I can avoid it.
>>>>
>>>> I've found trunk/packaging/gallery2/build.php, which appears to do an
>>>> svn checkout among other things, but I can't find where the .class
>>>> files contained within the .jar files are build.
>>>>
>>>> I should also point out, in Gallery bug 2585568, that the GPL
>>>> stipulate that when binaries are shipped, the source must also be
>>>> made available.  I'm sure it is, and I just haven't found it, but
>>>> others might question the projects adherence to the GPL.
>>>>
>>>> Any assistance would be greatly appreciated.
>>>>
>>>> Thanks,
>>>> Jon
>>>>
>>>> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>>>>
>>>>    
>>>>        
>>    

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bob Friesenhahn]

On Thu, 16 Apr 2009, Jon Ciesla wrote:
>
> I should also point out, in Gallery bug 2585568, that the GPL
> stipulate that when binaries are shipped, the source must also be
> made available.  I'm sure it is, and I just haven't found it, but
> others might question the projects adherence to the GPL.

This topic is pretty disturbing.  I read some of the follow-up emails
to the extent that Gallery2 is on its way out and Gallery3 is the
future.  The problem is that that Gallery2 has quite a lot of existing
users and that it will take time before Gallery3 is ready for prime
time and users can transition to it.

GPL says that the project can only be redistributed if the source
files, build scripts, and install scripts, are provided in the same
preferred form as used by the developers.  Any GPL project *must* pay
attention to this if its developers have respect for the license used,
and in order to allow the package to be distributed without forcing
the redistributors to be GPL violators.  If Gallery2 is included in OS
distribution without proper provision of sources than a judge could
grant an injunction which blocks the entire OS from being distributed.

It seems wise for someone to take the time to produce a proper source
distribution for Gallery2.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Bob Friesenhahn wrote:

> On Thu, 16 Apr 2009, Jon Ciesla wrote:
>>
>> I should also point out, in Gallery bug 2585568, that the GPL
>> stipulate that when binaries are shipped, the source must also be
>> made available.  I'm sure it is, and I just haven't found it, but
>> others might question the projects adherence to the GPL.
>
> This topic is pretty disturbing.  I read some of the follow-up emails
> to the extent that Gallery2 is on its way out and Gallery3 is the
> future.  The problem is that that Gallery2 has quite a lot of existing
> users and that it will take time before Gallery3 is ready for prime
> time and users can transition to it.
>
> GPL says that the project can only be redistributed if the source
> files, build scripts, and install scripts, are provided in the same
> preferred form as used by the developers.  Any GPL project *must* pay
> attention to this if its developers have respect for the license used,
> and in order to allow the package to be distributed without forcing
> the redistributors to be GPL violators.  If Gallery2 is included in OS
> distribution without proper provision of sources than a judge could
> grant an injunction which blocks the entire OS from being distributed.
>
> It seems wise for someone to take the time to produce a proper source
> distribution for Gallery2.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen@...,
> http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

I would tend to agree.  The only reason my plan to drop features from G2
and move to G3 shortly after it's release is at all viable is that I'm
maintaining it for Fedora, which thrives on being bleeding-edge.

A proper source distribution would head off any legal issues, whereas
the current situation certainly poses some risk.

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bob Friesenhahn]

On Thu, 16 Apr 2009, Jon Ciesla wrote:
> I would tend to agree.  The only reason my plan to drop features from G2 and
> move to G3 shortly after it's release is at all viable is that I'm
> maintaining it for Fedora, which thrives on being bleeding-edge.
>
> A proper source distribution would head off any legal issues, whereas the
> current situation certainly poses some risk.

Note that the way the GPL is worded, if developers normally build
their software by manually typing compiler commands and without using
any makefile, ant script, or shell script, then it is just fine to
deliver bare source files without any automated built method.  If a
task only needs to be done once in a blue moon, some developers might
do that.  GPL does not require that the build method be easy to use,
or even be documented.  However, if a built product is included then
any sources required to build it need to be distributed.  If a special
tool (e.g. Java compiler) is needed, then there may need to be
provisions for how to obtain it.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Bob Friesenhahn wrote:

> GPL says that the project can only be redistributed if the source
> files, build scripts, and install scripts, are provided in the same
> preferred form as used by the developers.  Any GPL project *must* pay
> attention to this if its developers have respect for the license used,
> and in order to allow the package to be distributed without forcing
> the redistributors to be GPL violators.  If Gallery2 is included in OS
> distribution without proper provision of sources than a judge could
> grant an injunction which blocks the entire OS from being distributed.
>
> It seems wise for someone to take the time to produce a proper source
> distribution for Gallery2.

Let's start by establishing that we (Gallery team) are in no way
pedantic about the terms of the GPL.  We will happily figure out a way
to work with you on this.  However, we're trying to focus our energy on
G3 so G2 is going to get short shrift while we get G3 out the door.
Please don't put a huge onerous burden on us to support G2 forever.
We're a bunch of guys, writing software for free in our vanishing spare
time.  We're already putting heart and soul into this, any more is
trying to get blood from a stone.

Jon, I am the copyright holder and can specifically grant you whatever
latitude you require.

>From looking at the specific bug, the issues all lie in very specific
locations.  The simple and most expedient way to resolve this is to
simply drop those from the distribution.  This will cause no harm to the
product whatsoever since we offer a way *inside the app* for you to
point and click your way to reinstalling these modules directly.  No
harm done.  So I suggest that you follow this algorithm:

1) Get the latest code from SVN
2) Delete modules/{uploadapplet,slideshowapplet,remote,panorama}
3) Delete modules/core/classes/GalleryStorage/g2_db2.jar

In short, I complete agree with Jon's proposal #2.  For all practical
purposes this will satisfy the GPL requirement, have minimal impact on
our users and minimal impact on the development team.


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Bharat Mediratta wrote:

> Bob Friesenhahn wrote:
>  
>> GPL says that the project can only be redistributed if the source
>> files, build scripts, and install scripts, are provided in the same
>> preferred form as used by the developers.  Any GPL project *must* pay
>> attention to this if its developers have respect for the license used,
>> and in order to allow the package to be distributed without forcing
>> the redistributors to be GPL violators.  If Gallery2 is included in OS
>> distribution without proper provision of sources than a judge could
>> grant an injunction which blocks the entire OS from being distributed.
>>
>> It seems wise for someone to take the time to produce a proper source
>> distribution for Gallery2.
>>    
>
> Let's start by establishing that we (Gallery team) are in no way
> pedantic about the terms of the GPL.  We will happily figure out a way
> to work with you on this.  However, we're trying to focus our energy on
> G3 so G2 is going to get short shrift while we get G3 out the door.
> Please don't put a huge onerous burden on us to support G2 forever.
> We're a bunch of guys, writing software for free in our vanishing spare
> time.  We're already putting heart and soul into this, any more is
> trying to get blood from a stone.
>
> Jon, I am the copyright holder and can specifically grant you whatever
> latitude you require.
>
> >From looking at the specific bug, the issues all lie in very specific
> locations.  The simple and most expedient way to resolve this is to
> simply drop those from the distribution.  This will cause no harm to the
> product whatsoever since we offer a way *inside the app* for you to
> point and click your way to reinstalling these modules directly.  No
> harm done.  So I suggest that you follow this algorithm:
>
> 1) Get the latest code from SVN
> 2) Delete modules/{uploadapplet,slideshowapplet,remote,panorama}
> 3) Delete modules/core/classes/GalleryStorage/g2_db2.jar
>
> In short, I complete agree with Jon's proposal #2.  For all practical
> purposes this will satisfy the GPL requirement, have minimal impact on
> our users and minimal impact on the development team.
>  

Actually, that proposal was for my actions WRT what Fedora ships.  I
don't really need any specific latitude, as what Fedora will be
distributing will be a subset of the official G2 distribution. The build
I'm working on starts with the .zip distribution and goes from there.  
That will satisfy the GPL as far as Fedora is concerned.  If you want to
get all the Gallery Project ducks in a row from a GPL perspective, a
simpler method of access to the complete source would be the way to go,
but that's ultimately up to the Gallery project members yourselves.

I certainly appreciate that you have limited time for what is
essentially a volunteer effort.  My work in this space is that as well.

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Looks like pulling the .jars broke httpauth:

https://bugzilla.redhat.com/show_bug.cgi?id=498061

Am I interpreting this error correctly?

Chris Kelly wrote:

> 3.0 Milestone added!  Must have gotten removed or renamed at some point.
>
> Jon Ciesla wrote:
>  
>> I understand your frustration.  I'm one of the more uptight GNUites I
>> know, so I see it all the time. ;)
>>
>> Hopefully one of the java folk will chime in.  In the meantime:
>>
>> 1. I used to do that as well, but find it easier to do mass deployments
>> with packages.  To each their own, and I like that distros that include
>> packages give admins the option.
>>
>> 2. I can live with that, under the circumstances.  I'll drop the remote,
>> slideshowapplet, and uploadapplet module subpackages, and all the .jar
>> files.  That will fix our legal issue.
>>
>> 3. See #2.
>>
>> Re: the roadmap, am I missing something, or is there no 3.0 milestone?
>> At any rate, it looks like late May/early June might be a reasonable
>> estimate for 3.0, no?
>>
>> When G3 is out, I'll package it to replace G2.
>>
>> Thanks for the information, and the assistance.
>>
>> Chris Kelly wrote:
>>    
>>> My frustration derives from some of the comments in the fedora bug
>>> tracker, so sorry about that!
>>>
>>> The number of people that know the Java side of G2 is very small.
>>> Perhaps one of them will chime in here, but to compare it to the way G2
>>> is packaged in Fedora currently, most of the work on that was a long
>>> time ago.
>>>
>>> Per your options:
>>>
>>> 1. G2 is a PHP webapp so getting it from a vendor instead of through a
>>> packaging system isn't too bad. I have bunches of Gentoo, CentOS, and
>>> Debian systems all running PHP applications, and I've never liked using
>>> the distro's package management system to install them.
>>>
>>> 2. G2 will work without the Java components, just the fancy
>>> drag-and-drop uploader won't be there and it won't work with DB2.  There
>>> are plenty of other upload methods available, so this shouldn't be that
>>> big of a deal.
>>>
>>> 3.  I'd agree that it's not worth the time. Either of the above are a
>>> much better idea.
>>>
>>> G3 Beta 1 should be next and should be soon.  You can see what is left
>>> here:
>>>
>>> http://apps.sourceforge.net/trac/gallery/roadmap
>>>
>>> I think work is finishing up on the G2 importer which should be in Beta
>>> 1 in a functional form.  Albums/Images/Users should all transfer over,
>>> but since the feature set of G3 is a lot smaller, there will be things
>>> that don't transfer over (like all kinds of sizes for resizes,
>>> permissions, etc)
>>>
>>> -Chris
>>>
>>> Jon Ciesla wrote:
>>>  
>>>      
>>>> Some, yes, that bug was closed automatically, and I was asked not to
>>>> pursue such topics in the bug tracker in 2750571.
>>>>
>>>> At any rate, I would agree that it seems like quite a lot of work to
>>>> build the java components.  I am a complete stranger to Java, and by
>>>> "build the ImageTools jar", I meant re-compose it from it's extracted
>>>> contents, which is not nearly as far as I need to be.
>>>>
>>>> My point is not that you're disregarding the letter of the GPL, since
>>>> the source is publicly available, just that some might misinterpret the
>>>> effort required to obtain the full source as disregarding the spirit of
>>>> the GPL, since though available, it's not as if one can say "download
>>>> tarball X from URL Y".  I'd love to see the process documented
>>>> somewhere, but that's neither here nor there.
>>>>
>>>> I understand that with G3 being imminent, G2 is effectively dead.  The
>>>> catch is, I don't know when G3 is coming, and G2 is already in Fedora
>>>> and has been for some time.  The packages currently available for
>>>> gallery in Fedora contain prebuilt jars.  Gallery should not have been
>>>> packaged this way in the first place, but that was done more than 3
>>>> years ago and is pretty much water under the bridge.
>>>>
>>>> The situation I find myself in as the new maintainer is that the package
>>>> as it stands violates Fedora's legal guidelines, and has a large user
>>>> base.  This leaves me with the following choices:
>>>>      1. Drop G2 from Fedora and package G3 (which presumably will not
>>>> have this problem) at it's release.  This would be very
>>>> disappointing. Perhaps (and understandably) not for you, but for
>>>> Fedora's G2 users,
>>>> myself included.
>>>>    2. Push a version of G2 minus the .jar files.  This would almost
>>>> certainly break G2, correct?
>>>>    3. Build the java bits from source.  Laborious, as it turns out, and
>>>> possibly not worth the time if G3 is coming soon.
>>>>
>>>> So, I guess, unless someone else knows of a simpler way to grab and
>>>> build the source, I'd like to know an ETA for G3, how the upgrade
>>>> process looks from G2 to G3, and if a jarless G2 would work at all.  G3
>>>> Alpha 3 is nearly a  month old, and based on the timing of Alpha 2, I'd
>>>> guess either Alpha 4, or a Beta of some type might be next, but that's
>>>> subject to my ignorance of your schedule. :)
>>>>
>>>> Chris Kelly wrote:
>>>>    
>>>>        
>>>>> Didn't you cover some of this in the bug thread?
>>>>>
>>>>> https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130
>>>>>
>>>>>
>>>>>
>>>>> "With some wrangling, I've been able to build the ImageTools jar"
>>>>>
>>>>> And we agreed that you could pull out the db2 stuff.
>>>>>
>>>>> It unfortunate that the Java things in Gallery 2 are such a mess, but
>>>>> Gallery 3 is java-free and won't have this problem, and it wouldn't
>>>>> hurt
>>>>> my feelings if G2 was not available in Fedora.  We're not putting any
>>>>> more effort into Gallery 2.
>>>>>
>>>>> And per Kevin's Comment #18:  My "100% sure" comment was guessing how
>>>>> much time you'd want to put in. you could certainly look at timestamps
>>>>> of releases to see what applets were in svn at that time, then look at
>>>>> when those applets where checked in, then get the code that was in
>>>>> trunk
>>>>> for them at that time, check out that code, look at the build scripts
>>>>> for that time, build them, etc, but that would take some time.  Still
>>>>> not sure how us not making it easy to build a few small components
>>>>> of G2
>>>>> from source, when it is possible if you work on it, is a "blatant
>>>>> disregard" of the GPL.
>>>>>
>>>>> Just trying to figure out what more you're asking for. Thanks!
>>>>>
>>>>> -Chris
>>>>>
>>>>>
>>>>> Jon Ciesla wrote:
>>>>>  
>>>>>      
>>>>>          
>>>>>> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've
>>>>>> run into a snag*, and I need some assistance.  The
>>>>>> gallery-2.3-full.zip contains several prebuilt .jar files, which in
>>>>>> turn contain prebuild .class files.  In fedora, we build from source,
>>>>>> and so I am faced with either dropping gallery from Fedora (which I
>>>>>> *really* don't want to do) or find a way to build from .java sources.
>>>>>>
>>>>>> Is it documented anywhere either in the G2 wiki or in the tarball how
>>>>>> to build the entire project from source?  I've done svn checkout of
>>>>>> trunk, and I'm not sure which subdirectories need to be present at
>>>>>> build or even how to do so. I'd like to not have to use the whole
>>>>>> 600MB+ trunk checkout if I can avoid it.
>>>>>>
>>>>>> I've found trunk/packaging/gallery2/build.php, which appears to do an
>>>>>> svn checkout among other things, but I can't find where the .class
>>>>>> files contained within the .jar files are build.
>>>>>>
>>>>>> I should also point out, in Gallery bug 2585568, that the GPL
>>>>>> stipulate that when binaries are shipped, the source must also be
>>>>>> made available.  I'm sure it is, and I just haven't found it, but
>>>>>> others might question the projects adherence to the GPL.
>>>>>>
>>>>>> Any assistance would be greatly appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>> Jon
>>>>>>
>>>>>> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>>>>>>
>>>>>>            
>>>>>>            
>>>>    
>>>>        
>>    

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Jon Ciesla wrote:
> Looks like pulling the .jars broke httpauth:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>
> Am I interpreting this error correctly?


/usr/share/gallery2/modules/rewrite/module.inc is missing.  Did you pull
the rewrite module instead of the remote module?  I believe that the
rewrite module does not depend on any of the .jar files (and for your
own package deps, you might express a dep between the httpauth package
and the rewrite package in fedora).


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Bharat Mediratta wrote:

> Jon Ciesla wrote:
>  
>> Looks like pulling the .jars broke httpauth:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>>
>> Am I interpreting this error correctly?
>>    
>
>
> /usr/share/gallery2/modules/rewrite/module.inc is missing.  Did you pull
> the rewrite module instead of the remote module?  I believe that the
> rewrite module does not depend on any of the .jar files (and for your
> own package deps, you might express a dep between the httpauth package
> and the rewrite package in fedora).
>  

No, it's present.

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Jon Ciesla wrote:

> Bharat Mediratta wrote:
>> Jon Ciesla wrote:
>>  
>>> Looks like pulling the .jars broke httpauth:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>>>
>>> Am I interpreting this error correctly?
>>>    
>>
>>
>> /usr/share/gallery2/modules/rewrite/module.inc is missing.  Did you pull
>> the rewrite module instead of the remote module?  I believe that the
>> rewrite module does not depend on any of the .jar files (and for your
>> own package deps, you might express a dep between the httpauth package
>> and the rewrite package in fedora).
>>  
> No, it's present.

If by "it's" you mean the rewrite module, then we'd have to check to see
why /usr/share/gallery2/modules/rewrite/module.inc is inaccessible on
that system.

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Bharat Mediratta wrote:

> Jon Ciesla wrote:
>  
>> Bharat Mediratta wrote:
>>    
>>> Jon Ciesla wrote:
>>>  
>>>      
>>>> Looks like pulling the .jars broke httpauth:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>>>>
>>>> Am I interpreting this error correctly?
>>>>    
>>>>        
>>> /usr/share/gallery2/modules/rewrite/module.inc is missing.  Did you pull
>>> the rewrite module instead of the remote module?  I believe that the
>>> rewrite module does not depend on any of the .jar files (and for your
>>> own package deps, you might express a dep between the httpauth package
>>> and the rewrite package in fedora).
>>>  
>>>      
>> No, it's present.
>>    
>
> If by "it's" you mean the rewrite module, then we'd have to check to see
> why /usr/share/gallery2/modules/rewrite/module.inc is inaccessible on
> that system.
>  

It's root:root 644 on my vanilla install of the Fedora RPM.  Might this
be a user/installation specific issue?

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Jon Ciesla wrote:

> Bharat Mediratta wrote:
>  
>> Jon Ciesla wrote:
>>  
>>    
>>> Bharat Mediratta wrote:
>>>    
>>>      
>>>> Jon Ciesla wrote:
>>>>  
>>>>      
>>>>        
>>>>> Looks like pulling the .jars broke httpauth:
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>>>>>
>>>>> Am I interpreting this error correctly?
>>>>>    
>>>>>        
>>>>>          
>>>> /usr/share/gallery2/modules/rewrite/module.inc is missing.  Did you pull
>>>> the rewrite module instead of the remote module?  I believe that the
>>>> rewrite module does not depend on any of the .jar files (and for your
>>>> own package deps, you might express a dep between the httpauth package
>>>> and the rewrite package in fedora).
>>>>  
>>>>      
>>>>        
>>> No, it's present.
>>>    
>>>      
>> If by "it's" you mean the rewrite module, then we'd have to check to see
>> why /usr/share/gallery2/modules/rewrite/module.inc is inaccessible on
>> that system.
>>  
>>    
> It's root:root 644 on my vanilla install of the Fedora RPM.  Might this
> be a user/installation specific issue?
>
>  

Also, activating http works on my install.

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Jon Ciesla wrote:
...

>>> If by "it's" you mean the rewrite module, then we'd have to check to see
>>> why /usr/share/gallery2/modules/rewrite/module.inc is inaccessible on
>>> that system.
>>>      
>> It's root:root 644 on my vanilla install of the Fedora RPM.  Might
>> this be a user/installation specific issue?
>>
>>  
> Also, activating http works on my install.
>

I'm leaning towards this being a user/installation specific issue.  That
particular code is mature; if the file is there it should be accessible.
 If we can find out more about the user setup, I can help you sort it out.

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

Bharat Mediratta wrote:

> Jon Ciesla wrote:
> ...
>  
>>>> If by "it's" you mean the rewrite module, then we'd have to check to see
>>>> why /usr/share/gallery2/modules/rewrite/module.inc is inaccessible on
>>>> that system.
>>>>      
>>>>        
>>> It's root:root 644 on my vanilla install of the Fedora RPM.  Might
>>> this be a user/installation specific issue?
>>>
>>>  
>>>      
>> Also, activating http works on my install.
>>
>>    
>
> I'm leaning towards this being a user/installation specific issue.  That
> particular code is mature; if the file is there it should be accessible.
>  If we can find out more about the user setup, I can help you sort it out.
>  

After a bit of digging, we discovered that the gallery2-httpauth
subpackage should require the gallery2-rewrite subpackage.  Thanks for
your assistance!

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Jon Ciesla]

On a more serious note, pulling the .jars broke adding new items:

Error (ERROR_BAD_PATH) : Invalid path:
modules/uploadapplet/ItemAddUploadApplet.inc

    * *in*
      modules/core/classes/helpers/GalleryFactoryHelper_simple.class *at
      line* 171 (GalleryCoreApi::error)
    * *in*
      modules/core/classes/helpers/GalleryFactoryHelper_simple.class *at
      line* 201 (GalleryFactoryHelper_simple::newInstance)
    * *in* modules/core/classes/GalleryCoreApi.class *at line* 175
      (GalleryFactoryHelper_simple::newInstanceById)
    * *in* modules/core/ItemAdd.inc *at line* 601
      (GalleryCoreApi::newFactoryInstanceById)
    * *in* modules/core/ItemAdmin.inc *at line* 140
      (ItemAddView::loadTemplate)
    * *in* modules/core/classes/GalleryView.class *at line* 293
      (ItemAdminView::loadTemplate)
    * *in* main.php *at line* 465 (GalleryView::doLoadTemplate)
    * *in* main.php *at line* 104
    * *in* main.php *at line* 88

Is there a workaround?  I know all work is currently aimed at Gallery3,
but I can't upgrade all supported Fedora releases to alpha code.  Thanks
in advance for any suggestions.

-J


Jon Ciesla wrote:

> Looks like pulling the .jars broke httpauth:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=498061
>
> Am I interpreting this error correctly?
>
> Chris Kelly wrote:
>  
>> 3.0 Milestone added!  Must have gotten removed or renamed at some point.
>>
>> Jon Ciesla wrote:
>>  
>>    
>>> I understand your frustration.  I'm one of the more uptight GNUites I
>>> know, so I see it all the time. ;)
>>>
>>> Hopefully one of the java folk will chime in.  In the meantime:
>>>
>>> 1. I used to do that as well, but find it easier to do mass deployments
>>> with packages.  To each their own, and I like that distros that include
>>> packages give admins the option.
>>>
>>> 2. I can live with that, under the circumstances.  I'll drop the remote,
>>> slideshowapplet, and uploadapplet module subpackages, and all the .jar
>>> files.  That will fix our legal issue.
>>>
>>> 3. See #2.
>>>
>>> Re: the roadmap, am I missing something, or is there no 3.0 milestone?
>>> At any rate, it looks like late May/early June might be a reasonable
>>> estimate for 3.0, no?
>>>
>>> When G3 is out, I'll package it to replace G2.
>>>
>>> Thanks for the information, and the assistance.
>>>
>>> Chris Kelly wrote:
>>>    
>>>      
>>>> My frustration derives from some of the comments in the fedora bug
>>>> tracker, so sorry about that!
>>>>
>>>> The number of people that know the Java side of G2 is very small.
>>>> Perhaps one of them will chime in here, but to compare it to the way G2
>>>> is packaged in Fedora currently, most of the work on that was a long
>>>> time ago.
>>>>
>>>> Per your options:
>>>>
>>>> 1. G2 is a PHP webapp so getting it from a vendor instead of through a
>>>> packaging system isn't too bad. I have bunches of Gentoo, CentOS, and
>>>> Debian systems all running PHP applications, and I've never liked using
>>>> the distro's package management system to install them.
>>>>
>>>> 2. G2 will work without the Java components, just the fancy
>>>> drag-and-drop uploader won't be there and it won't work with DB2.  There
>>>> are plenty of other upload methods available, so this shouldn't be that
>>>> big of a deal.
>>>>
>>>> 3.  I'd agree that it's not worth the time. Either of the above are a
>>>> much better idea.
>>>>
>>>> G3 Beta 1 should be next and should be soon.  You can see what is left
>>>> here:
>>>>
>>>> http://apps.sourceforge.net/trac/gallery/roadmap
>>>>
>>>> I think work is finishing up on the G2 importer which should be in Beta
>>>> 1 in a functional form.  Albums/Images/Users should all transfer over,
>>>> but since the feature set of G3 is a lot smaller, there will be things
>>>> that don't transfer over (like all kinds of sizes for resizes,
>>>> permissions, etc)
>>>>
>>>> -Chris
>>>>
>>>> Jon Ciesla wrote:
>>>>  
>>>>      
>>>>        
>>>>> Some, yes, that bug was closed automatically, and I was asked not to
>>>>> pursue such topics in the bug tracker in 2750571.
>>>>>
>>>>> At any rate, I would agree that it seems like quite a lot of work to
>>>>> build the java components.  I am a complete stranger to Java, and by
>>>>> "build the ImageTools jar", I meant re-compose it from it's extracted
>>>>> contents, which is not nearly as far as I need to be.
>>>>>
>>>>> My point is not that you're disregarding the letter of the GPL, since
>>>>> the source is publicly available, just that some might misinterpret the
>>>>> effort required to obtain the full source as disregarding the spirit of
>>>>> the GPL, since though available, it's not as if one can say "download
>>>>> tarball X from URL Y".  I'd love to see the process documented
>>>>> somewhere, but that's neither here nor there.
>>>>>
>>>>> I understand that with G3 being imminent, G2 is effectively dead.  The
>>>>> catch is, I don't know when G3 is coming, and G2 is already in Fedora
>>>>> and has been for some time.  The packages currently available for
>>>>> gallery in Fedora contain prebuilt jars.  Gallery should not have been
>>>>> packaged this way in the first place, but that was done more than 3
>>>>> years ago and is pretty much water under the bridge.
>>>>>
>>>>> The situation I find myself in as the new maintainer is that the package
>>>>> as it stands violates Fedora's legal guidelines, and has a large user
>>>>> base.  This leaves me with the following choices:
>>>>>      1. Drop G2 from Fedora and package G3 (which presumably will not
>>>>> have this problem) at it's release.  This would be very
>>>>> disappointing. Perhaps (and understandably) not for you, but for
>>>>> Fedora's G2 users,
>>>>> myself included.
>>>>>    2. Push a version of G2 minus the .jar files.  This would almost
>>>>> certainly break G2, correct?
>>>>>    3. Build the java bits from source.  Laborious, as it turns out, and
>>>>> possibly not worth the time if G3 is coming soon.
>>>>>
>>>>> So, I guess, unless someone else knows of a simpler way to grab and
>>>>> build the source, I'd like to know an ETA for G3, how the upgrade
>>>>> process looks from G2 to G3, and if a jarless G2 would work at all.  G3
>>>>> Alpha 3 is nearly a  month old, and based on the timing of Alpha 2, I'd
>>>>> guess either Alpha 4, or a Beta of some type might be next, but that's
>>>>> subject to my ignorance of your schedule. :)
>>>>>
>>>>> Chris Kelly wrote:
>>>>>    
>>>>>        
>>>>>          
>>>>>> Didn't you cover some of this in the bug thread?
>>>>>>
>>>>>> https://sourceforge.net/tracker/?func=detail&aid=2585568&group_id=7130&atid=107130
>>>>>>
>>>>>>
>>>>>>
>>>>>> "With some wrangling, I've been able to build the ImageTools jar"
>>>>>>
>>>>>> And we agreed that you could pull out the db2 stuff.
>>>>>>
>>>>>> It unfortunate that the Java things in Gallery 2 are such a mess, but
>>>>>> Gallery 3 is java-free and won't have this problem, and it wouldn't
>>>>>> hurt
>>>>>> my feelings if G2 was not available in Fedora.  We're not putting any
>>>>>> more effort into Gallery 2.
>>>>>>
>>>>>> And per Kevin's Comment #18:  My "100% sure" comment was guessing how
>>>>>> much time you'd want to put in. you could certainly look at timestamps
>>>>>> of releases to see what applets were in svn at that time, then look at
>>>>>> when those applets where checked in, then get the code that was in
>>>>>> trunk
>>>>>> for them at that time, check out that code, look at the build scripts
>>>>>> for that time, build them, etc, but that would take some time.  Still
>>>>>> not sure how us not making it easy to build a few small components
>>>>>> of G2
>>>>>> from source, when it is possible if you work on it, is a "blatant
>>>>>> disregard" of the GPL.
>>>>>>
>>>>>> Just trying to figure out what more you're asking for. Thanks!
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>> Jon Ciesla wrote:
>>>>>>  
>>>>>>      
>>>>>>          
>>>>>>            
>>>>>>> Hi, Jon Ciesla, Fedora maintainer for the gallery2 package.  We've
>>>>>>> run into a snag*, and I need some assistance.  The
>>>>>>> gallery-2.3-full.zip contains several prebuilt .jar files, which in
>>>>>>> turn contain prebuild .class files.  In fedora, we build from source,
>>>>>>> and so I am faced with either dropping gallery from Fedora (which I
>>>>>>> *really* don't want to do) or find a way to build from .java sources.
>>>>>>>
>>>>>>> Is it documented anywhere either in the G2 wiki or in the tarball how
>>>>>>> to build the entire project from source?  I've done svn checkout of
>>>>>>> trunk, and I'm not sure which subdirectories need to be present at
>>>>>>> build or even how to do so. I'd like to not have to use the whole
>>>>>>> 600MB+ trunk checkout if I can avoid it.
>>>>>>>
>>>>>>> I've found trunk/packaging/gallery2/build.php, which appears to do an
>>>>>>> svn checkout among other things, but I can't find where the .class
>>>>>>> files contained within the .jar files are build.
>>>>>>>
>>>>>>> I should also point out, in Gallery bug 2585568, that the GPL
>>>>>>> stipulate that when binaries are shipped, the source must also be
>>>>>>> made available.  I'm sure it is, and I just haven't found it, but
>>>>>>> others might question the projects adherence to the GPL.
>>>>>>>
>>>>>>> Any assistance would be greatly appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jon
>>>>>>>
>>>>>>> *https://bugzilla.redhat.com/show_bug.cgi?id=484566
>>>>>>>
>>>>>>>            
>>>>>>>            
>>>>>>>              
>>>>>    
>>>>>        
>>>>>          
>>>    
>>>      
>
>
>  

--
in your fear, speak only peace
in your fear, seek only love

-d. bowie


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Jon Ciesla wrote:

> On a more serious note, pulling the .jars broke adding new items:
>
> Error (ERROR_BAD_PATH) : Invalid path:
> modules/uploadapplet/ItemAddUploadApplet.inc
>
>     * *in*
>       modules/core/classes/helpers/GalleryFactoryHelper_simple.class *at
>       line* 171 (GalleryCoreApi::error)
>     * *in*
>       modules/core/classes/helpers/GalleryFactoryHelper_simple.class *at
>       line* 201 (GalleryFactoryHelper_simple::newInstance)
>     * *in* modules/core/classes/GalleryCoreApi.class *at line* 175
>       (GalleryFactoryHelper_simple::newInstanceById)
>     * *in* modules/core/ItemAdd.inc *at line* 601
>       (GalleryCoreApi::newFactoryInstanceById)
>     * *in* modules/core/ItemAdmin.inc *at line* 140
>       (ItemAddView::loadTemplate)
>     * *in* modules/core/classes/GalleryView.class *at line* 293
>       (ItemAdminView::loadTemplate)
>     * *in* main.php *at line* 465 (GalleryView::doLoadTemplate)
>     * *in* main.php *at line* 104
>     * *in* main.php *at line* 88
>
> Is there a workaround?  I know all work is currently aimed at Gallery3,
> but I can't upgrade all supported Fedora releases to alpha code.  Thanks
> in advance for any suggestions.

I'm confused.. that code is referring to the uploadapplet module, which
was pulled.  So I don't understand how there could still be factory
mappings for it.  If you're doing a fresh install without that module,
those mappings couldn't exist.  If you're upgrading a G2 that had the
uploadapplet activated to one that no longer has the code for it, then
in upgrade/steps/UpgradeOtherModuleStep.class on line 351 we call
deactivate() on that plugin which in turn should call
GalleryModule::deactivate and in
modules/core/classes/GalleryModule.class on line 363 it should
unregister any factory mappings.

Can you tell me how you got to this error?  Which of the above scenarios
was it?

FYI, you can work around this problem by dropping any rows from
g2_FactoryMap where g_implModuleId='uploadapplet' (or any other module
which you've dealt with this way) and then deleting
g2data/cache/module/_all/0/0/* and g2data/cache/module/uploadapplet

-Bharat

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]