Gallery

hehe. Indeed, sarcasm often isn't the most effective approach with some
people. I've also been trying to help him, and while he didn't call me an
"ASS" :) he's clearly pretty frustrated. I'm pretty sure he's confusing the
concept of a filesystem root and his webserver document root, but I'm having
a hard time getting him to understant that (or to demonstrate that this is
not the issue).

We'll see what happens,
chris

----- Original Message -----
From: "Markus Illenseer" <markus@...>
To: <gallery-devel@...>
Sent: Thursday, December 20, 2001 7:02 AM
Subject: [Gallery-devel] Blast! (Was: Re: [Gallery-users] can someone post
the paths...)


>
>  So much for my try to help a hero user. Richard asked for some help and I
> tried do so (outside this list, which probably was a mistake).
>
> > I have much more important things to do than converse
> > with someone that can't even use good english !
> >  thanks for NOTHING you ASS!
>
>  Well, that sums up to at least 2 errors in a single english sentence.
> I'd like to see him write a single sentence in other languages though.
>
>  I did excuse myself for harsh, sarcastic words. I did try to help. He
> twice failed to summarize his configuration and his history of
> installation and then started to insult me. He accused me for being
> unhelpful and pointless. *sigh* And heroed himself for having installed "a
> hundreds of scripts" and that "Gallery is by far the worst script I ever
> saw, you f*ck!". He didnt even realized that I am no developer...
>
>  Reminds me on the URL I only read yesterday:
> http://www.linuxworld.com/site-stories/2001/1214.mplayer.html
>
>
>  I volunteer to write a "helpme.php" to give the user more hints and
> figuring out his environment. This task's more for G2, though. What do you
> think?
>
>  *grmbl*
>
> Markus Illenseer
>
>
>
> _______________________________________________
> list: Gallery-devel@...
> info: https://lists.sourceforge.net/lists/listinfo/gallery-devel
> archive: http://marc.theaimsgroup.com/?l=gallery-devel
>

Mediratta, Bharat (bharat@...) said:
> This means that you'll stick with 1.2.4?  (that's fine, just
> clarifying).

Yep, it'll give me a day or two headstart on getting it into the distro.

> > In the future, would you prefer that I keep the -debian 
> > extraversion if I modify the gallery distribution at all?
> 
> I haven't thought it through in a lot of detail, but I think
> this is a good idea .. it'll let us identify where the version
> came from.

Yes, I agree.

> >     . modified standalone_style.css.default so that the background is
> >       white by default (sorry, personal preference ;)
> 
> This is a more questionable change since you're actually changing
> the look of the product, as opposed to change in the configuration
> process.  I'm not particularly bothered by it, though.

I assumed it wouldn't be a huge deal, luckily I was right :)

> I imagine that the end goal is that we can establish a relatively
> automated process whereby you take the latest Gallery code, apply
> your patch and wind up with a version that's slightly tweaked for
> Debian.  What we want to avoid is the situation where the Debian
> version introduces bugs that the core product doesn't have, since
> I don't run Debian (and I'm not sure who might, on the team) so we'd 
> have problems fixing them.  

Yep, I'd like to avoid introducing bugs, or really anything more than
minor tweaks as well.

Speaking of bugs, I'll explain a bit about Debian's bug tracking system
(assuming you're not familiar as you don't run Debian) and how bug
reporting on the gallery Debian package may work.

When a Debian user finds a bug in a piece of software that is packaged,
most times they report the bug to Debian. This will send a bug report to
the bug tracking system at http://bugs.debian.org, and will send me an
email.

I'll take a look at the bug, if it's a packaging problem I'll deal with
it. If it's a bug in gallery, we should come up with a plan. I could
forward it to the sourceforge bug tracking system (and mark it forwarded
in the debian bts). Or would you rather I forward it to a mailing list
(-users? -devel?) ?

> Either way, I'm happy that this is moving forward.  Let me know 
> when you submit it for woody.

I submitted an initial version to unstable/sid today. It'll be within a
week to get the new package added (it has to be done by hand). Then, if
it goes 2 weeks without getting a Release Critical bug filed on it, it
will get copied into testing/woody.

Woody is currently gearing up for release, and a freeze on new packages
is coming, so I'm trying to get the package in asap so it can go through
the 2 week period and hopefully be a part of the next stable release.

If the above doesn't make any sense, I'm probably not giving enough
details :) Feel free to ask questions, or checkout http://debian.org/.

-- 
Adam Lazur, Cluster Monkey

Adam,
It might be a good idea to also include documentation of the changes
you've made relative to the canonical Gallery source, so that a user
contemplating an upgrade to the latest version directly from sourceforge
can understand what's different.  Perhaps appended to the README,
or in a separate README.Debian?

-- Jamie Gray (Bharat's colleague, de-lurking)

Jamison Gray (jamison@...) said:
> It might be a good idea to also include documentation of the changes
> you've made relative to the canonical Gallery source, so that a user
> contemplating an upgrade to the latest version directly from sourceforge
> can understand what's different.  Perhaps appended to the README,
> or in a separate README.Debian?

Already done (well, mostly :)

The following test is currently at the end of README.Debian:

DEBIAN CHANGES
--------------

Changes made to gallery for the Debian package:
    . change default css to have a white background
    . changes to setup.sh and configure.sh to work with debian layout
    . tiny change in configure instructions to exclude extra instructions for
      Windows users

-- 
Adam Lazur, Cluster Monkey

Mediratta, Bharat (bharat@...) said:
> I think the patch you submitted is problematic, though.
> One of the goals of the platform files (fs_unix, fs_win32)
> is to reproduce the functionality of the target call as 
> closely as possible.  In this case, you're changing the way 
> that the fs_file_exists() function works which means that 
> you may cause other functionality to break in the future.
> As such, I can't accept it into the source tree.
> 
> I think that a better patch would be to add fs_is_link() and 
> fs_filetype() methods to both the fs_unix and fs_win32 platform 
> files and then modify the code in util to have your extended 
> logic in it.  This would be portable and reliable, and I'd
> be able to get it in for 1.2.5 (or whatever comes next).

Ah that makes sense. I opted for the aproach that I did as is_link
doesn't work on windows systems. Or at least, that's what the php docs
say.

Attached is a patch that adds the functions fs_is_link and broken_link.
broken_link isolates the logic of the is_link and is_file tests. (After
a little testing, I also found out that using filetype doesn't work
reliably to find a broken link, but a combination of is_link and is_file
does.)

I'm not sure how the windows counterpart of fs_is_link will behave...
but if it does strange things it would probably be okay to make it
always return false.

> A simpler solution would be to leave config.php in the
> /usr/share/gallery directory and make the file in /etc a 
> symlink to it (instead of the other way around).  That would 
> require no code changes, although I don't know how that sits 
> with the Debian packaging conventions.

Unfortunately that won't work as Debian specifies that _all_
configuration files must be in /etc, so I'm symlinking config.php and
.htaccess to their /etc/gallery counterparts.

-- 
Adam Lazur, Cluster Monkey

I've only just been converted to the One True Distro a monthish ago 
(woah, so much better than RH! apt rocks!)--thanks for doing this.

There's only a few things I would pipe into to say:

* NetPBM's version (at least in the testing/woody area) has been 
broken before - deb accepted 2.19 which had some JFIF-related bug. 
And before that, gallery required a higher version than what was in 
stable. v2's config wizard will be unit testing the image toolkit, so 
it'll hork up a complaint during configuration. 2.20 (in testing now) 
is fine currently, though.

* Just as a heads-up, G2 will be able to use either ImageMagick or 
NetPBM - ImageMagick being the favored library (as it can do lossless 
jpeg translations, like image rotation, and maintain EXIF headers)... 
The big woop is that you might need to change the depends come 
Feb-ish.

* The squirrelmail package nicely burps at the end of setup

"Run /etc/squirrelmail/conf.pl to update configuration"

You may want to invoke configure.sh and let that echo to the console 
"please point a user agent at http://.....gallery/setup/"

* Where were you going to stuff gallery in the htdoc hierarchy? Heck, 
given that we know that the apache config is (we can check for both 
/etc/apache and /etc/apache-ssl for httpd.conf) we might be able to 
guess the URL to tell the user now.

As I'm working on G2's config wizard, I'll see what wwwconfig-common 
gives us to see if that can help this process.

Again, thanks for the effort!

-- 
Matthew

Everyone wants results, but no one is willing to do what it takes to 
get them.
		-- Dirty Harry

<present company excluded, of course... ;)>

Matthew McEachen (mceachen@...) said:
> I've only just been converted to the One True Distro a monthish ago 
> (woah, so much better than RH! apt rocks!)--thanks for doing this.
> 
> There's only a few things I would pipe into to say:
> 
> * NetPBM's version (at least in the testing/woody area) has been 
> broken before - deb accepted 2.19 which had some JFIF-related bug. 
> And before that, gallery required a higher version than what was in 
> stable. v2's config wizard will be unit testing the image toolkit, so 
> it'll hork up a complaint during configuration. 2.20 (in testing now) 
> is fine currently, though.

I'll add a versioned dependency so nobody gets bitten by 2.19 just in
case.

> * Just as a heads-up, G2 will be able to use either ImageMagick or 
> NetPBM - ImageMagick being the favored library (as it can do lossless 
> jpeg translations, like image rotation, and maintain EXIF headers)... 
> The big woop is that you might need to change the depends come 
> Feb-ish.

Yeah, I saw that. The EXIF integration will be nice to have. It's
unfortunate that imagemagick in debian depends on xlibs (I try to keep
that kind of stuff off of my headless server box).

> * The squirrelmail package nicely burps at the end of setup
> 
> "Run /etc/squirrelmail/conf.pl to update configuration"
> 
> You may want to invoke configure.sh and let that echo to the console 
> "please point a user agent at http://.....gallery/setup/"

I considered putting gallery into config mode on install, but decided
against it as it's a potential security can of worms.

Adding http://${automagically_guessed_server_name}/gallery/setup/ to the
output of configure.sh would be nice though.

I'll also take a look at echoing "You'll probably want to run
/usr/share/gallery/configure.sh to start the configuration process" in
the postinst, though I'm not sure if this is debconf territory or not.

I also plan on adding debconf notes for upgrades when an album rebuild
is required.

> * Where were you going to stuff gallery in the htdoc hierarchy? Heck, 
> given that we know that the apache config is (we can check for both 
> /etc/apache and /etc/apache-ssl for httpd.conf) we might be able to 
> guess the URL to tell the user now.

Right now it defaults to adding "Alias /gallery /usr/share/gallery" to
apache. This is a conffile though, so the user is free to change it as
they see fit (and it'll persist on upgrades).

> As I'm working on G2's config wizard, I'll see what wwwconfig-common 
> gives us to see if that can help this process.

Nice. I'm using some of the scripts from wwconfig-common in the
post{inst,rm}, but it's mostly stuff I borrowed from squirrelmail.

I'd like to get the package into debian proper soon so that it'll have
time to filter into woody before the freeze for release.

-- 
Adam Lazur, Cluster Monkey

> Attached is a patch that adds the functions fs_is_link and 
> broken_link.

Good work.  I've rolled your patch into the trunk.  The only
slight tweak I made was to unroll the ternary operation in
util:broken_link() for clarity.

You have some choices now.  
o You can ship v1.2.4 + your patches into Debian with my 
  blessing

o You can get the latest code from CVS (v1.2.5-cvs-b1) and 
  ship that instead.

o You can test 1.2.5-cvs-b1 and let me know that it passes so
  that I can ship 1.2.5 officially tomorrow night, or Thursday
  night.

If you use 1.2.5-cvs-b1, or 1.2.4 + your patch, please please
tweak the version number so that we can identify your slightly
forked release from the rest of them.  I'd suggest something
like 1.2.4-debian-1, 1.2.5-b1-debian-1 to identify it as the
debian release, patchlevel 1.  If you ship v1.2.5 without making
any changes then I guess there's no need to change the version
number.

Thanks!  Please let me know if you have any problems, requests.
-Bharat

Mediratta, Bharat (bharat@...) said:
> You have some choices now.  
> o You can ship v1.2.4 + your patches into Debian with my 
>   blessing
> 
> o You can get the latest code from CVS (v1.2.5-cvs-b1) and 
>   ship that instead.
> 
> o You can test 1.2.5-cvs-b1 and let me know that it passes so
>   that I can ship 1.2.5 officially tomorrow night, or Thursday
>   night.
> 
> If you use 1.2.5-cvs-b1, or 1.2.4 + your patch, please please
> tweak the version number so that we can identify your slightly
> forked release from the rest of them.  I'd suggest something
> like 1.2.4-debian-1, 1.2.5-b1-debian-1 to identify it as the
> debian release, patchlevel 1.  If you ship v1.2.5 without making
> any changes then I guess there's no need to change the version
> number.

The above guidelines are a good thing to know.

I'll probably include the -debian version for now, and get it uploaded.

In the future, would you prefer that I keep the -debian extraversion if
I modify the gallery distribution at all?

For example, disregarding the symlink patch, the changes I have made
are:

    . modified secure.sh & configure.sh to work with config.php and
      htaccess in /etc (and symlinked to).

    . modified errors/configure_instructions.php to remove instructions
      for Windows and Unix FTP users (we can assume you're root with a
      unix shell on Debian, as that's how you installed the package in
      the first place)

    . modified standalone_style.css.default so that the background is
      white by default (sorry, personal preference ;)

The full diff (including the extra debian dir with packaging info)
against gallery-1.2.4 can be found at
http://clustermonkey.org/~laz/debian/gallery/gallery_1.2.4-1.diff.gz

-- 
Adam Lazur, Cluster Monkey