10 a.m.
Subject: Fedora Core 2 Test Update: dovecot-0.99.10.6-1,FC2,1
---------------------------------------------------------------------
Fedora Test Update Notification
FEDORA-2004-201
2004-06-30
---------------------------------------------------------------------
Product : Fedora Core 2
Name : dovecot
Version : 0.99.10.6
Release : 1,FC2,1
Summary : Dovecot Secure imap server
Description :
Dovecot is an IMAP server for Linux/UNIX-like systems, written with
security
primarily in mind. It also contains a small POP3 server. It supports
mail
in either of maildir or mbox formats.
---------------------------------------------------------------------
Update Information:
- bring up to date with upstream,
recent change log comments from Timo Sirainen were:
SHA1 password support using OpenSSL crypto library
mail_extra_groups setting
maildir_stat_dirs setting
Added NAMESPACE capability and command
Autocreate missing maildirs (instead of crashing)
Fixed occational crash in maildir synchronization
Fixed occational assertion crash in ioloop.c
Fixed FreeBSD compiling issue
Fixed issues with 64bit Solaris binary
---------------------------------------------------------------------
* Wed Jun 30 2004 John Dennis <jdennis(a)redhat.com>
- bump rev for build
* Fri Jun 25 2004 John Dennis <jdennis(a)redhat.com> - 0.99.10.6-1
- bring up to date with upstream,
recent change log comments from Timo Sirainen were:
SHA1 password support using OpenSSL crypto library
mail_extra_groups setting
maildir_stat_dirs setting
Added NAMESPACE capability and command
Autocreate missing maildirs (instead of crashing)
Fixed occational crash in maildir synchronization
Fixed occational assertion crash in ioloop.c
Fixed FreeBSD compiling issue
Fixed issues with 64bit Solaris binary
* Tue Jun 15 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
---------------------------------------------------------------------
This update can be downloaded from:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/
749a821b0a6da99c28b2325fade72024
SRPMS/dovecot-0.99.10.6-1,FC2,1.src.rpm
3561cd5dfa250f26a67298c7bb5c840a
x86_64/dovecot-0.99.10.6-1,FC2,1.x86_64.rpm
d1ee606f3f126e71e83cfefc7fa19378
x86_64/debug/dovecot-debuginfo-0.99.10.6-1,FC2,1.x86_64.rpm
5af0bae46300fb9c1b6d34424ae9f5d7
i386/dovecot-0.99.10.6-1,FC2,1.i386.rpm
847d50fcf8648960058d33d270d73d4e
i386/debug/dovecot-debuginfo-0.99.10.6-1,FC2,1.i386.rpm
This update can also be installed with the Update Agent; you can
launch the Update Agent with the 'up2date' command. You may
need to edit your up2date channels configuration. Within
/etc/sysconfig/rhn/sources enable the following line:
yum updates-testing
http://fedora.redhat.com/updates/testing/fedora-core-2
---------------------------------------------------------------------
--
John Dennis <jdennis(a)redhat.com>
12:22 p.m.
On Thu, 2004-07-01 at 11:00 -0400, John Dennis wrote:
Subject: Fedora Core 2 Test Update: dovecot-0.99.10.6-1,FC2,1
---------------------------------------------------------------------
Fedora Test Update Notification
FEDORA-2004-201
2004-06-30
---------------------------------------------------------------------
Product : Fedora Core 2
Name : dovecot
Version : 0.99.10.6
Release : 1,FC2,1 <---- What is this??????????????
Summary : Dovecot Secure imap server
Description :
<SNIP>
Please don't continue using these Release strings, all it does it break
things...
-sb
--
John Dennis <jdennis(a)redhat.com>
1:23 p.m.
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
> Release : 1,FC2,1 <---- What is this??????????????
Please don't continue using these Release strings, all it does it
break
things...
We've been having an internal discussion recently about how to make the
release field meaningful. In the past it was typically an integer, which
had no meaning in the context of multiple simultaneous distributions. In
the last year or two some packages have started encoding strings into
the release such as AS, RHEL3, FC1, etc. Is it this practice you are
referring to in general or the specific case cited above? What
specifically is breaking?
No assumptions should be made about the format of the release string
other than it collate correctly when presented to rpmvercmp (the
comparison function in rpm which has specific well defined semantics).
For what its worth, it's been noted that it is a deficiency n-v-r does
not contain build information within a distribution. Using simple
integers as the release yields arbitrary mappings of integers to
distributions and builds(patches, errata) within a given distribution.
Unfortunately we are pretty much stuck with n-v-r for historical
reasons. However it is felt the r part of n-v-r can be encoded with more
information while preserving n-v-r format which many utilities have come
to expect.
Are you experiencing a problem with a utility that is expecting the r
part of n-v-r to be numeric or a utility that is not using rmpvercmp or
implementing the logic in rpmvercmp?
3:28 p.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
No assumptions should be made about the format of the release string
other than it collate correctly when presented to rpmvercmp (the
comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is
no interface which would make that available. Or this is one of
those undocumented mysteries of rpm?
Unfortunately we are pretty much stuck with n-v-r for historical
reasons.
This I can reliably pick apart using --queryformat but now what?
In case you wonder if I need that in shell scripts and similar then
the answer is that indeed I do (and many others too). A comparison
utility which would compare (or even collate but that I can do
myself) according to rpmvercmp would be really useful.
Michal
6:16 p.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
How you are using rpmvercmp, say, in a shell script? AFAIK there is
no interface which would make that available.
This is off-topic for this list, but I'll answer it here, further
discussion should be moved to the fedora list.
You can use the rpm python bindings, see attached script (rpmvercmp.py).
Please note, internally the algorithm is:
name is tested for equality
epoch is numerically compared
version is passed to rpmvercmp
release is passed to rpmvercmp
first definitive answer is returned
rpmvercmp splits the string into alphanumeric substrings, then pairwise
compares them, numerically if the leading char is a digit, lexically
otherwise, pairwise comparison ends on first definitive result.
Credit and thanks go to Jerry Katz who showed me the python bindings and
patiently explained many things to me.
Also attached is a tiny C program I wrote that will operate on strings
rather than reading the rpm header's. It's good for when you just want
to test rpm names as strings and don't have a full rpm, you can give it
a pair of n-v-r, in which case it calls rpmvercmp on version and then
release, or you can give it either just a pair of versions or a pair of
revisions and it will call rpmvercmp on just that component. It links
against rpm so it uses the actual rpmvercmp function.
--
John Dennis <jdennis(a)redhat.com>
7:56 p.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Thu, Jul 01, 2004 at 07:16:31PM -0400, John Dennis wrote:
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
> How you are using rpmvercmp, say, in a shell script? AFAIK there is
> no interface which would make that available.
You can use the rpm python bindings, see attached script (rpmvercmp.py).
Thanks. This will be useful.
Credit and thanks go to Jerry Katz who showed me the python bindings
and
patiently explained many things to me.
Right. Unfortunately JK does not come bundled in rpm, even in
rawhide, so this resource is not widely available. :-)
Michal
7:42 a.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Thu, 1 Jul 2004, John Dennis wrote:
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
> How you are using rpmvercmp, say, in a shell script? AFAIK there is
> no interface which would make that available.
This is off-topic for this list, but I'll answer it here, further
discussion should be moved to the fedora list.
Yack...thought this was the rpm list. That said my comment concerning
previous post of mine on this list should instead refer to the rpm list.
Cheers...james
11:04 p.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Jul 1, 2004, Michal Jaegermann <michal(a)harddata.com> wrote:
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
>
> No assumptions should be made about the format of the release string
> other than it collate correctly when presented to rpmvercmp (the
> comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is
no interface which would make that available. Or this is one of
those undocumented mysteries of rpm?
I wrote this years ago for a script that would automatically install
updates from a local mirror of the Red Hat Linux updates site. Except
that I just updated it to support commas as separators; I'd no idea
they could be used with the same meaning as dots before the internal
discussion :-)
Untested after the change to support commas. Hope this helps.
# Copyright 1999, 2000, 2001, 2002, 2004
# Alexandre Oliva <oliva(a)lsd.ic.unicamp.br>
# This script is Free Software, and it can be copied, distributed and
# modified as defined in the GNU General Public License. A copy of
# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
newer () {
test "x$1" != "x$2" &&
case "$1$2" in
*-*)
newer "`echo $1 | sed 's/-.*//'`" "`echo $2 | sed
's/-.*//'`" ||
{ test "`echo $1 | sed 's/-.*//'`" = "`echo $2 | sed
's/-.*//'`" &&
newer "`echo $1 | sed 's/[^-]*-*//'`" "`echo $2 | sed
's/[^-]*-*//'`"; }
;;
*[.,]*)
newer "`echo $1 | sed 's/[.,].*//'`" "`echo $2 | sed
's/[.,].*//'`" ||
{ test "`echo $1 | sed 's/[.,].*//'`" = "`echo $2 | sed
's/[.,].*//'`" &&
newer "`echo $1 | sed 's/[^.,]*\.*//'`" "`echo $2 | sed
's/[^.,]*\.*//'`"; }
;;
*)
result=false
if test -x $SORT; then
{ echo $2; echo $1; } |
$SORT -n -c > /dev/null 2>&1 && result=true
else
test $1 -gt $2 && result=true
fi
$result
;;
esac
}
# usage: if newer r1-v1 r2-v2; then echo r1-v1 is newer; fi
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
7:34 a.m.
New subject: rpmvercmp (was: dovecot imap available for testing, latest upstream release 0.99.10.6)
On Thu, 1 Jul 2004, Michal Jaegermann wrote:
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
>
> No assumptions should be made about the format of the release string
> other than it collate correctly when presented to rpmvercmp (the
> comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is
no interface which would make that available. Or this is one of
those undocumented mysteries of rpm?
Hi Michal, look back through the messages about a month and you will
see a message concerning rpm package versions that I answered that pretty
muchh answers your question. In short its pretty easy to use the python
bindings or perl (RPM2) bindings to librpm to access rpmvercmp(). In my
original post, I think I gave a short inline perl example (i.e. a tiny
script using perl -e option to pass the script from the command line).
I definately do this at my work in various shell scripts.
Cheers..james
> Unfortunately we are pretty much stuck with n-v-r for
historical
> reasons.
Yep and you cannot forget epoch.
This I can reliably pick apart using --queryformat but now what?
In case you wonder if I need that in shell scripts and similar then
the answer is that indeed I do (and many others too). A comparison
utility which would compare (or even collate but that I can do
myself) according to rpmvercmp would be really useful.
Again search back through the archives and you will see code to that
effect. Really what would be quite handy though for shell scripts is
a utility that could be called in the following ways:
rpmvercmp -v 1.1.1 -v 1.1.2
rpmvercmp -p x-1.1.1-2.0.i386.rpm -d
rpmvercmp -p x-1.1.1-2.0.i386.rpm -p x-1.1.2-1.1.i386.rpm
rpmvercmp -p x-1.1.1-2.0.i386.rpm -v 1.1.2
rpmvercmp -n x -v 1.1.2 -d
So basically, allow you to compare a:
- E:V-R string to an E:V-R string,
- package to the package in the db
- package to another package.
- package to an E:V-R string
- E:V:R string for a specific N to the database.
Would not be too hard to create such a script from RPM2 (and I suspect
easy to do so with the python bindings). Unfortunately, I am tied up in
non-rpm endevours at the moment, or I would gladly wip it up and send it
to the list. Maybe tonight I will have time, but no promises.
Cheers...james
Michal
5:15 a.m.
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
> > Release : 1,FC2,1 <---- What is this??????????????
> Please don't continue using these Release strings, all it does it break
> things...
We've been having an internal discussion recently about how to make the
release field meaningful. In the past it was typically an integer, which
had no meaning in the context of multiple simultaneous distributions. In
the last year or two some packages have started encoding strings into
the release such as AS, RHEL3, FC1, etc. Is it this practice you are
referring to in general or the specific case cited above? What
specifically is breaking?
Let me invent a statistic: 99% of all packages produced by everyone ever
use '.' as a component separator in release/version/etc fields - it is
an accepted convention.
The question is: why be inconsistent with all those packages, and start
using a comma? It makes no difference to rpmvercmp, it still treats the
field as three separate segments.
joe
7:58 a.m.
On Thu, 01 Jul 2004 14:23:53 -0400, John Dennis wrote:
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
> > Release : 1,FC2,1 <---- What is this??????????????
> Please don't continue using these Release strings, all it does it break
> things...
We've been having an internal discussion recently about how to make the
release field meaningful.
Why not a public discussion on fedora-devel-list?
8:27 a.m.
On Fri, Jul 02, 2004 at 02:58:20PM +0200, Michael Schwendt wrote:
> We've been having an internal discussion recently about how
to make the
> release field meaningful.
Why not a public discussion on fedora-devel-list?
Because most of it related to internal build systems, the enterprise
product and the like
7290
days inactive
7291
days old
12 comments
9 participants
participants (9)
-
Alan Cox -
Alexandre Oliva -
James Olin Oden -
Joe Orton -
John Dennis -
Michael Schwendt -
Michal Jaegermann -
seth vidal -
Stan Bubrouski