Fabian == Fabian Fagerholm [EMAIL PROTECTED] writes:
Fabian On Wed, 2006-12-13 at 16:11 +0200, Fabian Fagerholm wrote:
I'm hoping to hear something from Sam with regard to the
Kerberos 4 package, but I'm going to upload a new version of
cyrus-sasl2 with a libsasl2-gssapi-mit
Russ == Russ Allbery [EMAIL PROTECTED] writes:
Russ Fabian Fagerholm [EMAIL PROTECTED] writes:
I made a small mistake in the current package -- I made it
provide libsasl2-gssapi-mit. I forgot that virtual packages
have to be agreed upon beforehand. So that Provides has to be
BTW I don't think you actually need a conflict with libsasl2-krb4-mit.
Disturbingly, it actually works against the new library at least in
practice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, Dec 11, 2006 at 11:37:05PM -0800, Russ Allbery wrote:
My guess is that it would be better for the new package to take care of
it, since otherwise we're carrying around an old source package as well
as a transitional binary package. That seems unnecessary.
The only thing that
On Wed, Dec 13, 2006 at 01:34:09AM -0800, Steve Langasek wrote:
Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
cyrus-sasl2 would be the best option. Is this in progress?
There is already a libsasl2-modules-gssapi-mit. Does the
libsasl2-gssapi-mit binary package need
On Wed, 2006-12-13 at 01:34 -0800, Steve Langasek wrote:
Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
cyrus-sasl2 would be the best option. Is this in progress?
Yes.
I'm hoping to hear something from Sam with regard to the Kerberos 4
package, but I'm going to upload a
Roberto C Sanchez [EMAIL PROTECTED] writes:
On Wed, Dec 13, 2006 at 01:34:09AM -0800, Steve Langasek wrote:
Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
cyrus-sasl2 would be the best option. Is this in progress?
There is already a libsasl2-modules-gssapi-mit. Does
On Wed, 2006-12-13 at 16:11 +0200, Fabian Fagerholm wrote:
I'm hoping to hear something from Sam with regard to the Kerberos 4
package, but I'm going to upload a new version of cyrus-sasl2 with a
libsasl2-gssapi-mit transition package and the neccessary
Depends/Conflicts/Replaces dance no
* Fabian Fagerholm ([EMAIL PROTECTED]) [061211 20:25]:
I made a small mistake in the current package -- I made it provide
libsasl2-gssapi-mit. I forgot that virtual packages have to be agreed
upon beforehand. So that Provides has to be removed. I'll take care of
it.
Oh, it's not as bad if
There is still a soource package for cyrus-sasl2-mit. This has been
superseded by the new version of cyrus-sasl2, which is in Etch. THe new
version of cyrus-sasl2 builds against MIT Kerberos, obviating the need
for the separate cyrus-sasl2-mit. What is the best way of going about
removing this
* Roberto C. Sanchez ([EMAIL PROTECTED]) [061211 15:04]:
There is still a soource package for cyrus-sasl2-mit. This has been
superseded by the new version of cyrus-sasl2, which is in Etch. THe new
version of cyrus-sasl2 builds against MIT Kerberos, obviating the need
for the separate
On Mon, Dec 11, 2006 at 03:07:27PM +0100, Andreas Barth wrote:
- File a serious bug against it to get it out of Etch
- File a bug against the ftp.d.o pseudopackage requesting complete
removal from Sid (since ftpmaster seems to be taking a while to
process removal requests I think we
* Roberto C. Sanchez ([EMAIL PROTECTED]) [061211 17:49]:
On Mon, Dec 11, 2006 at 03:07:27PM +0100, Andreas Barth wrote:
- File a serious bug against it to get it out of Etch
- File a bug against the ftp.d.o pseudopackage requesting complete
removal from Sid (since ftpmaster seems
Roberto C Sanchez [EMAIL PROTECTED] writes:
On Mon, Dec 11, 2006 at 05:51:10PM +0100, Andreas Barth wrote:
I can remove a package without any bug - the RC bug is required so that
the package doesn't return on its own. That is why pre-freeze an RC bug
is required - and we require the bug on
On Mon, Dec 11, 2006 at 10:49:50AM -0800, Russ Allbery wrote:
Wait, woah. You shouldn't just remove libsasl2-gssapi-mit from etch
without a transition package so that people who are upgrading from sarge
still have the MIT GSSAPI SASL module installed. That would break a bunch
of our
On Mon, 2006-12-11 at 10:49 -0800, Russ Allbery wrote:
Wait, woah. You shouldn't just remove libsasl2-gssapi-mit from etch
without a transition package so that people who are upgrading from sarge
still have the MIT GSSAPI SASL module installed. That would break a bunch
of our servers.
I
On Mon, Dec 11, 2006 at 11:06:25AM -0800, Russ Allbery wrote:
Please read my original message. The new cyrus-sasl2 packages are
linked against MIT Kerberos.
I did, and I understand that. You're not understanding the problem, I
think.
In fact, the new libsasl2-modules-gssapi-mit
Fabian Fagerholm [EMAIL PROTECTED] writes:
I made a small mistake in the current package -- I made it provide
libsasl2-gssapi-mit. I forgot that virtual packages have to be agreed
upon beforehand. So that Provides has to be removed. I'll take care of
it.
Oh, there's a provides. Okay. I
On Mon, 2006-12-11 at 12:45 -0800, Russ Allbery wrote:
Oh, there's a provides. Okay. I don't actually know how that works (I
should have checked that; sorry). I think a transitional package is still
better, but a provides *may* be enough for aptitude to figure it out. I'm
not sure.
I'm in
Fabian Fagerholm [EMAIL PROTECTED] writes:
On Mon, 2006-12-11 at 12:45 -0800, Russ Allbery wrote:
My guess is that it would be better for the new package to take care of
it, since otherwise we're carrying around an old source package as well
as a transitional binary package. That seems
20 matches
Mail list logo
