|
From: David G. <da...@co...> - 2010-05-17 10:22:16
|
> > not yet merged and/or to be discussed: > - r805 - debian/* - normes or GingerDog, can you merge this part, please? > I don't want to change stuff that I don't understand ;-) Just blindly merge it - I think only normes really understands it. > - r800, r806, r821 - Squirrelmail Plugin please do. > - r811, r812 - Squirrelmail Plugin / Zend - not sure if we really should > include the whole Zend framework in the tarball, it's laaaaaarge and > only useful for squirrelmail users. > I'd vote for a "Requires: Zend" in the documentation. This is tempting. At the moment it should be an svn:external - and perhaps we can view that as just being useful for development. > - r815: the change in users/index.php makes access to users/ too easy if > someone forgot to logout (security by obscurity, but still...) Don't understand this ^^^ comment, can you elabourate/ > - r817 - ADDITIONS/cyrus (config file path?) > - r819 - maildir path hook (BTW: the example function should be moved to > config.inc.php) Where is/was it - but I think I'd agree... it would make it more obvious to a sysadmin what's going on. Sorry for being relatively silent lately - life is busy. David. -- David Goodwin [ david at codepoets dot co dot uk ] [ http://www.codepoets.co.uk ] |
|
From: Christian B. <pos...@cb...> - 2010-06-22 22:49:54
|
Hello,
good news: we are near the 2.3.1 release [1] - at least that's what I
think ;-)
The code is not bug-free (probably it will never be), but all major bugs
should be fixed. (And of course there will always be someone saying that
his "favorite" bug is still unfixed ;-)
Missing parts:
- merge debian/* changes from r805 -> normes? hello? ;-)
- testing - I did not even test the code after the merge I commited some
minutes ago ;-)
Still very important:
> @everybody: Please checkout the 2.3 branch from SVN and check if
> everything works. Especially check if everything listed in the
> CHANGELOG.txt works ;-)
@GingerDog:
Notes regarding the release:
a) version an revision numbers in changelog and functions.inc.php need
to be updated
b) Please send me the tarball in advance so I can create a RPM package
_before uploading to SF_.
The reason for this request is the "latest files" section on SF,
which makes uploading the RPM later a no-go :-/ - we have to upload
everything at once.
Regards,
Christian Boltz
[1] if we manage to do the release before someone finds another major
bug *g*
--
> Was haltet ihr von Lindows??
Tonne auf, Lindows rein, Lindows 'Erfinder' dazustopfen, Tonne zu, mit
Stacheldraht umwickeln, in die Sonne schiessen. Problem gelöst..
[> Glenn Charpantier und Phillip Richdale in suse-linux]
|
|
From: Christian B. <pos...@cb...> - 2010-06-26 21:29:16
|
Hello,
Am Samstag, 26. Juni 2010 schrieb reg9009:
> we are planning to introduce some kind of Object Relational Mapper to
> manage the database stuff. I think there were some discussions about
> it earlier. Anyway, we wanted to give Doctrine Project a final try.
> This would theoretically extend the RDBMSs support without any
> further intervention (e.g. Oracle, etc.). Any thoughts on this?
Call me an enemy of frameworks, but I don't think Doctrine or any other
database abstraction framework would be useful for postfixadmin.
We have some code in functions.inc.php to compose queries and parts of
queries (db_insert, db_update, db_delete, db_get_boolean, ... - grep for
"function db_" to get the full list) and also do the abstraction
regarding PostgreSQL vs. MySQL where needed.
I'll take db_insert as an example - you just give it the (default) table
name, an array(
'field_1' => 'value_1',
'field_2' => 'value_2',
)
and optionally an array with timestamp fields that should be set to
NOW().
The function then converts the table name[1], generates an INSERT query
from the data array (including escaping the values) and the timestamp
fields and executes the query.
Add a condition that can be used for WHERE (address = 'fo...@do...d')
and you have the parameters for db_update.
As you can see, postfixadmin already has its own database abstraction.
The main problem is that the "old" code doesn't use the db_* functions,
but at least the newer code does. Needless to say that it would be a
good idea to make the "old" code using these functions also. [5]
If I get the Doctrine documentation right [2], it does basically the
same ($conn->insert) with more code - I didn't read the framework code,
but I'm quite sure db_insert with its 10 or 15 lines of code is shorter
than the code in the framework ;-)
And (of course) Doctrine doesn't handle some things that are specific to
postfixadmin:
- the timestamp fields that are set to NOW()
- the table name conversion [1]
- escaping of all fields (except the timestamps)
That means we would need to have a wrapper to handle those things.
"Just" the framework would be a step back.
A wrapper around a framework sounds interesting[tm] - KISS anyone? ;-)
Some questions my short look at the Doctrine documentation didn't
answer:
- how are boolean values handled? (PostgreSQL uses t/f, MySQL uses 1/0)
- how is LIMIT handled? PostgreSQL has a different syntax... [3]
My vote clearly goes to using the db_* functions everywhere instead of
introducing a framework with 90% code that we never use.
Of course you can change my opinion if you have some good arguments why
the framework is better than the db_* functions. However "$framework is
cool" or "Oracle support" [4] aren't real arguments for me ;-)
Regards,
Christian Boltz
[1] $CONF['database_prefix'] and $CONF['database_tables'], conversion
is done in the table_by_key($table) function
[2] http://www.doctrine-project.org/projects/dbal/2.0/docs/
reference/data-retrieval-and-manipulation/en
(as one line)
[3] MySQL: LIMIT $fDisplay, $page_size
PostgreSQL: LIMIT $page_size OFFSET $fDisplay
I have to admit that this is hardcoded in some places - I'll
probably have to write a small db_limit function or a function to
compose SELECT queries.
In short: Every code section that checks for $CONF['database_type']
outside the db_* functions should be called a bug IMHO.
And I just found in the MySQL documentation:
"For compatibility with PostgreSQL, MySQL also supports the
LIMIT row_count OFFSET offset syntax."
Good to know ;-)
[4] I doubt people will run Oracle for their mailserver, and AFAIK
postfix doesn't support Oracle at all ;-)
[5] This should also result in merging the "create" and "edit" pages -
the only differences are the database call (insert or update) and
that one field (typically the address) has to be read-only on edit.
fetchmail.php can serve as an example how it should like.
--
Und der erste, der mich darauf hinweist, ich könne das ja selbst
umkonfigurieren, ich müsse nur die 200KB-Doku lesen, den besuche
ich zu Hause und *singe*(!) ihm den Sourcecode vor, und DAS ist
WIRKLICH eine STRAFE. [Ratti in suse-linux]
|
|
From: Valkum <va...@go...> - 2010-06-27 08:34:38
|
Am 26.06.2010 23:29, schrieb Christian Boltz: > Hello, > > Am Samstag, 26. Juni 2010 schrieb reg9009: > >> we are planning to introduce some kind of Object Relational Mapper to >> manage the database stuff. I think there were some discussions about >> it earlier. Anyway, we wanted to give Doctrine Project a final try. >> This would theoretically extend the RDBMSs support without any >> further intervention (e.g. Oracle, etc.). Any thoughts on this? >> > Call me an enemy of frameworks, but I don't think Doctrine or any other > database abstraction framework would be useful for postfixadmin. > > We have some code in functions.inc.php to compose queries and parts of > queries (db_insert, db_update, db_delete, db_get_boolean, ... - grep for > "function db_" to get the full list) and also do the abstraction > regarding PostgreSQL vs. MySQL where needed. > > I'll take db_insert as an example - you just give it the (default) table > name, an array( > 'field_1' => 'value_1', > 'field_2' => 'value_2', > ) > and optionally an array with timestamp fields that should be set to > NOW(). > The function then converts the table name[1], generates an INSERT query > from the data array (including escaping the values) and the timestamp > fields and executes the query. > > Add a condition that can be used for WHERE (address = 'fo...@do...d') > and you have the parameters for db_update. > > As you can see, postfixadmin already has its own database abstraction. > The main problem is that the "old" code doesn't use the db_* functions, > but at least the newer code does. Needless to say that it would be a > good idea to make the "old" code using these functions also. [5] > > > If I get the Doctrine documentation right [2], it does basically the > same ($conn->insert) with more code - I didn't read the framework code, > but I'm quite sure db_insert with its 10 or 15 lines of code is shorter > than the code in the framework ;-) > > And (of course) Doctrine doesn't handle some things that are specific to > postfixadmin: > - the timestamp fields that are set to NOW() > - the table name conversion [1] > - escaping of all fields (except the timestamps) > > That means we would need to have a wrapper to handle those things. > "Just" the framework would be a step back. > > A wrapper around a framework sounds interesting[tm] - KISS anyone? ;-) > > > Some questions my short look at the Doctrine documentation didn't > answer: > - how are boolean values handled? (PostgreSQL uses t/f, MySQL uses 1/0) > - how is LIMIT handled? PostgreSQL has a different syntax... [3] > > > My vote clearly goes to using the db_* functions everywhere instead of > introducing a framework with 90% code that we never use. > Of course you can change my opinion if you have some good arguments why > the framework is better than the db_* functions. However "$framework is > cool" or "Oracle support" [4] aren't real arguments for me ;-) > > > Regards, > > Christian Boltz > > [1] $CONF['database_prefix'] and $CONF['database_tables'], conversion > is done in the table_by_key($table) function > > [2] http://www.doctrine-project.org/projects/dbal/2.0/docs/ > reference/data-retrieval-and-manipulation/en > (as one line) > > [3] MySQL: LIMIT $fDisplay, $page_size > PostgreSQL: LIMIT $page_size OFFSET $fDisplay > > I have to admit that this is hardcoded in some places - I'll > probably have to write a small db_limit function or a function to > compose SELECT queries. > In short: Every code section that checks for $CONF['database_type'] > outside the db_* functions should be called a bug IMHO. > > And I just found in the MySQL documentation: > "For compatibility with PostgreSQL, MySQL also supports the > LIMIT row_count OFFSET offset syntax." > Good to know ;-) > > [4] I doubt people will run Oracle for their mailserver, and AFAIK > postfix doesn't support Oracle at all ;-) > > [5] This should also result in merging the "create" and "edit" pages - > the only differences are the database call (insert or update) and > that one field (typically the address) has to be read-only on edit. > fetchmail.php can serve as an example how it should like. > > As i know Doctrine add NOW() to all cols which are called updated or timestamp or so on. If Doctrine is too unspeacial for PFA the way to fo to OOP is really useful in my eys. Writing our own DB Abstr. layer in OOP makes the Code cleaner and Development easier. The Way to seperate our DB Layer from UI is so quiet simple and required to add new technics.. |
|
From: reg9009 <re...@ya...> - 2010-06-26 09:10:47
|
Am 23.06.2010 00:49, schrieb Christian Boltz: > Hello, > > good news: we are near the 2.3.1 release [1] - at least that's what I > think ;-) > > The code is not bug-free (probably it will never be), but all major bugs > should be fixed. (And of course there will always be someone saying that > his "favorite" bug is still unfixed ;-) > > Missing parts: > - merge debian/* changes from r805 -> normes? hello? ;-) > - testing - I did not even test the code after the merge I commited some > minutes ago ;-) > > Still very important: >> @everybody: Please checkout the 2.3 branch from SVN and check if >> everything works. Especially check if everything listed in the >> CHANGELOG.txt works ;-) > > @GingerDog: > Notes regarding the release: > a) version an revision numbers in changelog and functions.inc.php need > to be updated > b) Please send me the tarball in advance so I can create a RPM package > _before uploading to SF_. > The reason for this request is the "latest files" section on SF, > which makes uploading the RPM later a no-go :-/ - we have to upload > everything at once. > > > Regards, > > Christian Boltz > > [1] if we manage to do the release before someone finds another major > bug *g* > Hi all, we are planning to introduce some kind of Object Relational Mapper to manage the database stuff. I think there were some discussions about it earlier. Anyway, we wanted to give Doctrine Project a final try. This would theoretically extend the RDBMSs support without any further intervention (e.g. Oracle, etc.). Any thoughts on this? Regards, Sebastian |
|
From: Valkum <va...@go...> - 2010-06-26 09:14:53
|
Am 26.06.2010 11:10, schrieb reg9009: > Am 23.06.2010 00:49, schrieb Christian Boltz: > >> Hello, >> >> good news: we are near the 2.3.1 release [1] - at least that's what I >> think ;-) >> >> The code is not bug-free (probably it will never be), but all major bugs >> should be fixed. (And of course there will always be someone saying that >> his "favorite" bug is still unfixed ;-) >> >> Missing parts: >> - merge debian/* changes from r805 -> normes? hello? ;-) >> - testing - I did not even test the code after the merge I commited some >> minutes ago ;-) >> >> Still very important: >> >>> @everybody: Please checkout the 2.3 branch from SVN and check if >>> everything works. Especially check if everything listed in the >>> CHANGELOG.txt works ;-) >>> >> @GingerDog: >> Notes regarding the release: >> a) version an revision numbers in changelog and functions.inc.php need >> to be updated >> b) Please send me the tarball in advance so I can create a RPM package >> _before uploading to SF_. >> The reason for this request is the "latest files" section on SF, >> which makes uploading the RPM later a no-go :-/ - we have to upload >> everything at once. >> >> >> Regards, >> >> Christian Boltz >> >> [1] if we manage to do the release before someone finds another major >> bug *g* >> >> > Hi all, > > we are planning to introduce some kind of Object Relational Mapper to > manage the database stuff. I think there were some discussions about it > earlier. Anyway, we wanted to give Doctrine Project a final try. This > would theoretically extend the RDBMSs support without any further > intervention (e.g. Oracle, etc.). Any thoughts on this? > > Regards, > Sebastian > I think this is a good idea. In this way we can build up a manage librarie and develop some frontends like the web front end and the console frontemd. So the web FE and the Lib should be fully standalone or so. greetz Rudi |
|
From: David G. <da...@co...> - 2010-06-26 18:16:11
|
>> > Hi all, > > we are planning to introduce some kind of Object Relational Mapper to > manage the database stuff. I think there were some discussions about it > earlier. Anyway, we wanted to give Doctrine Project a final try. This > would theoretically extend the RDBMSs support without any further > intervention (e.g. Oracle, etc.). Any thoughts on this? > Sure. I sort of wanted to do this with the model directory. But I don't have time / motivation. David |
|
From: reg9009 <re...@ya...> - 2010-06-27 10:40:19
|
Am 26.06.2010 23:29, schrieb Christian Boltz: > Hello, > > Am Samstag, 26. Juni 2010 schrieb reg9009: >> we are planning to introduce some kind of Object Relational Mapper to >> manage the database stuff. I think there were some discussions about >> it earlier. Anyway, we wanted to give Doctrine Project a final try. >> This would theoretically extend the RDBMSs support without any >> further intervention (e.g. Oracle, etc.). Any thoughts on this? > Call me an enemy of frameworks, but I don't think Doctrine or any other > database abstraction framework would be useful for postfixadmin. > > We have some code in functions.inc.php to compose queries and parts of > queries (db_insert, db_update, db_delete, db_get_boolean, ... - grep for > "function db_" to get the full list) and also do the abstraction > regarding PostgreSQL vs. MySQL where needed. > > I'll take db_insert as an example - you just give it the (default) table > name, an array( > 'field_1' => 'value_1', > 'field_2' => 'value_2', > ) > and optionally an array with timestamp fields that should be set to > NOW(). > The function then converts the table name[1], generates an INSERT query > from the data array (including escaping the values) and the timestamp > fields and executes the query. > > Add a condition that can be used for WHERE (address = 'fo...@do...d') > and you have the parameters for db_update. > > As you can see, postfixadmin already has its own database abstraction. > The main problem is that the "old" code doesn't use the db_* functions, > but at least the newer code does. Needless to say that it would be a > good idea to make the "old" code using these functions also. [5] > > > If I get the Doctrine documentation right [2], it does basically the > same ($conn->insert) with more code - I didn't read the framework code, > but I'm quite sure db_insert with its 10 or 15 lines of code is shorter > than the code in the framework ;-) > > And (of course) Doctrine doesn't handle some things that are specific to > postfixadmin: > - the timestamp fields that are set to NOW() > - the table name conversion [1] > - escaping of all fields (except the timestamps) > > That means we would need to have a wrapper to handle those things. > "Just" the framework would be a step back. > > A wrapper around a framework sounds interesting[tm] - KISS anyone? ;-) > > > Some questions my short look at the Doctrine documentation didn't > answer: > - how are boolean values handled? (PostgreSQL uses t/f, MySQL uses 1/0) > - how is LIMIT handled? PostgreSQL has a different syntax... [3] > > > My vote clearly goes to using the db_* functions everywhere instead of > introducing a framework with 90% code that we never use. > Of course you can change my opinion if you have some good arguments why > the framework is better than the db_* functions. However "$framework is > cool" or "Oracle support" [4] aren't real arguments for me ;-) > > > Regards, > > Christian Boltz > > [1] $CONF['database_prefix'] and $CONF['database_tables'], conversion > is done in the table_by_key($table) function > > [2] http://www.doctrine-project.org/projects/dbal/2.0/docs/ > reference/data-retrieval-and-manipulation/en > (as one line) > > [3] MySQL: LIMIT $fDisplay, $page_size > PostgreSQL: LIMIT $page_size OFFSET $fDisplay > > I have to admit that this is hardcoded in some places - I'll > probably have to write a small db_limit function or a function to > compose SELECT queries. > In short: Every code section that checks for $CONF['database_type'] > outside the db_* functions should be called a bug IMHO. > > And I just found in the MySQL documentation: > "For compatibility with PostgreSQL, MySQL also supports the > LIMIT row_count OFFSET offset syntax." > Good to know ;-) > > [4] I doubt people will run Oracle for their mailserver, and AFAIK > postfix doesn't support Oracle at all ;-) > > [5] This should also result in merging the "create" and "edit" pages - > the only differences are the database call (insert or update) and > that one field (typically the address) has to be read-only on edit. > fetchmail.php can serve as an example how it should like. > Well, basically it does the same. Of course, frameworks always carry a lot of functionality which isn't fully used across the projects using the framework. Nowadays, the overhead generated by frameworks is compensated by the computing power growing continously. I really like schema update stuff. The update mechanism of the database structure gets transparent regardless of the rdbms using it. Adding/removing/changing fields, indexes, etc. seems a lot easier for me (update.php). It's always a question of what to use and if some kind of framework would ease the use in general. Especially regarding data management I tend to go for frameworks nowadays. This also frees up some kind of ressources later to implement theme styles :) I would suggest we start and open a new branch and have a look... Oralce was a bad example, but e.g. sqlite. Regards, Sebastian |
|
From: Christian B. <pos...@cb...> - 2010-06-27 22:45:38
|
Hello,
Am Sonntag, 27. Juni 2010 schrieb reg9009:
> Well, basically it does the same. Of course, frameworks always carry
> a lot of functionality which isn't fully used across the projects
> using the framework.
> Nowadays, the overhead generated by frameworks
> is compensated by the computing power growing continously.
Well, that were two arguments from you against using a framework *g*
BTW: I prefer to use the growing computing power to make things faster
instead of just keeping the speed ;-)
> I really like schema update stuff. The update mechanism of the
> database structure gets transparent regardless of the rdbms using
> it. Adding/removing/changing fields, indexes, etc. seems a lot
> easier for me (update.php).
OK, that _might_ be an argument. But IIRC there's also something like a
standalone "database scheme updater" part in Doctrine, so this isn't a
argument to use Doctrine in the everyday code *g*
OTOH, upgrade.php already has some abstraction included - it's just that
it isn't always used ;-) (But yes, there are really things that are
different on PostgreSQL and MySQL.)
> It's always a question of what to use and if some kind of framework
> would ease the use in general. Especially regarding data management
> I tend to go for frameworks nowadays. This also frees up some kind
> of ressources later to implement theme styles :) I would suggest we
> start and open a new branch and have a look...
I have another proposal - do it in multiple steps directly in trunk.
* Step 1: convert INSERT, UPDATE and DELETE queries to db_* calls
Switching to a database framework requires lots of work on changing how
database calls are done - we have to change all INSERT, UPDATE and
DELETE queries to use db_insert(), db_update() and db_delete.
This is something that should be done in any case, and it would also be
the base for switching to a framework (aka "no time wasted").
Target: The code should be free of UPDATE, INSERT and DELETE queries
(except inside the db_* functions of course)
(Sidenote: Ideally do this only for the edit*.php scripts and merge them
with create*.php afterwards. See fetchmail.php for an example how to do
this. The advantage is that we have 50% less code to maintain in the
future ;-)
BTW: regarding the timestamp parameters: Maybe db_update and db_insert
should know the "usual" field names ("created" and "modified" are in
nearly every table) so that the calling code does not even need to
specify them...
* Step 2: remove usage of $CONF['database_type']
After step 1, we'll only have some SELECT queries left that are database
dependent.
We should wrap those parts in functions that create (parts of) a SELECT
query - for example the LIMIT clause.
Writing a general db_select function isn't that easy because SELECT
queries can become quite interesting[tm]. However such a function could
still be useful for the 90% "simple" queries.
My first look at the Doctrine documentation didn't show me functions to
build select queries, so this also isn't wasted time.
Target: The code (except the db_* functions) should not contain any
condition based on $CONF['database_type'].
* Step 3: check if we really need the framework
We should now (after step 1 and 2) already have
- lots of db_* calls in the code instead of "hardcoded" queries
- nearly no direct db_query calls (except some complex SELECT queries)
- all database specific stuff inside the db_* functions
That's already lots of abstraction and code cleanup.
We'll then see if this is enough or if we really want/need to introduce
a framework like Doctrine.
* final notes
IMHO even with the framework we have to keep the db_* functions to do
the postfixadmin-specific work (mapping table names, timestamps etc. -
see my previous mail for details).
Within the db_* functions, we can call the framework if we decide to go
this way.
The good thing about this 3-step-proposal is (IMHO) that it can be done
directly in trunk without breaking anything. No need to fiddle with
branch handling ;-) (I can tell you some stories about that regarding
the 2.3 branch...)
> Oralce was a bad example, but e.g. sqlite.
;-)
Regards,
Christian Boltz
--
Error: File not found -- search behind couch? (Y/N)
|
|
From: Tanstaafl <tan...@li...> - 2010-05-17 12:53:52
|
On 2010-05-17 6:03 AM, David Goodwin wrote: > Sorry for being relatively silent lately - life is busy. Glad you're still alive and well at least David... :) Any chance of a 2.3.1 release anytime soon? I think there have been lots of small bug fixes since 2.3 was released... Thanks! |
|
From: David G. <da...@co...> - 2010-05-17 13:13:48
|
On 17/05/10 13:53, Tanstaafl wrote: > On 2010-05-17 6:03 AM, David Goodwin wrote: >> Sorry for being relatively silent lately - life is busy. > > Glad you're still alive and well at least David... :) > > Any chance of a 2.3.1 release anytime soon? I think there have been lots > of small bug fixes since 2.3 was released... I think Christian is working towards it... David. -- David Goodwin [ david at codepoets dot co dot uk ] [ http://www.codepoets.co.uk ] |
|
From: Christian B. <pos...@cb...> - 2010-05-17 23:40:22
|
Hello,
Am Montag, 17. Mai 2010 schrieb David Goodwin:
> > not yet merged and/or to be discussed:
> > - r805 - debian/* - normes or GingerDog, can you merge this part,
> > please? I don't want to change stuff that I don't understand ;-)
>
> Just blindly merge it - I think only normes really understands it.
The best solution would be if normes does this part of the merge.
-> normes? ;-)
> > - r800, r806, r821 - Squirrelmail Plugin
>
> please do.
OK
> > - r811, r812 - Squirrelmail Plugin / Zend - not sure if we really
> > should include the whole Zend framework in the tarball, it's
> > laaaaaarge and only useful for squirrelmail users.
> > I'd vote for a "Requires: Zend" in the documentation.
>
> This is tempting. At the moment it should be an svn:external - and
> perhaps we can view that as just being useful for development.
OK, then I won't include Zend in the 2.3 branch.
I would even remove the svn:external from trunk - I don't see a real
advantage compared to having it in the PHP include_path or symlinked.
OTOH, the svn:external slows down several svn commands...
> > - r815: the change in users/index.php makes access to users/ too
> > easy if someone forgot to logout (security by obscurity, but
> > still...)
>
> Don't understand this ^^^ comment, can you elabourate/
old users/index.php:
header("Location: login.php")
new (r815) users/index.php:
header("Location: main.php")
Why I don't like this change: If someone forgot to logout and just went
to another site, the login cookie stays valid. Let's also assume he
leaves his computer and someone else wants to configure his mailbox
under users/.
Old behaviour: login form is shown
New behaviour: instant access to the (still logged in) mailbox
Therefore I'd prefer to revert to the old behaviour. I know that it's
somewhat security by obscurity (one can still directly go to
users/main.php), but that's very different from actively being pushed
into the foreign mailbox.
> > - r817 - ADDITIONS/cyrus (config file path?)
config file path changed to /etc/mail/postfixadmin/cyrus.conf + merged
to 2.3 branch
> > - r819 - maildir path hook (BTW: the example function should be
> > moved to config.inc.php)
>
> Where is/was it -
in functions.inc.php - I just moved it to config.inc.php.
> but I think I'd agree... it would make it more
> obvious to a sysadmin what's going on.
>
> Sorry for being relatively silent lately - life is busy.
You don't need to tell me that ;-)
The good news: If I get it right, merging (except the debian/ stuff)
should be complete - we are near the 2.3.1 release :-)
@everybody: Please checkout the 2.3 branch from SVN and check if
everything works. Especially check if everything listed in the
CHANGELOG.txt works ;-)
Regards,
Christian Boltz
--
<suseROCKs> henne: [...] Can you link me to any documentation [...]?
<henne> suseROCKs: brain://henne/hardware/touchsmart
<suseROCKs> Firefox: Oops! There appears to be no brain:// associated
with henne
[from #opensuse-project]
|
