Build failure bzr trunk revno 103260

Build failure bzr trunk revno 103260

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

FYI the current emacs trunk fails to build with the following error

In toplevel form:
gnus/gnus-cite.el:33:1:Error: Cannot open load file: imap
make[3]: *** [/home/tcross/bzr/emacs/trunk/lisp/gnus/gnus-cite.elc] Error 1
make[3]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
make[2]: *** [compile-main] Error 2
make[2]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
make[1]: *** [lisp] Error 2
make[1]: Leaving directory `/home/tcross/bzr/emacs/trunk'
make: *** [bootstrap] Error 2

[-- Attachment #2: Type: text/html, Size: 646 bytes --]

Re: Build failure bzr trunk revno 103260

[Les Harris]

Tim Cross <theophilusx <at> gmail.com> writes:

> 
> 
> FYI the current emacs trunk fails to build with the following error
> 
> 
> In toplevel form:
> gnus/gnus-cite.el:33:1:Error: Cannot open load file: imap
> make[3]: *** [/home/tcross/bzr/emacs/trunk/lisp/gnus/gnus-cite.elc] Error 1
> make[3]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
> make[2]: *** [compile-main] Error 2
> make[2]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
> make[1]: *** [lisp] Error 2
> make[1]: Leaving directory `/home/tcross/bzr/emacs/trunk'
> make: *** [bootstrap] Error 2
> 

I came here to see if anyone else had this.  Seems like the following commit had 
some unforeseen consequences:

commit 2d456533aa8eb6f2b6d8156c0d4eb1971e4f052c
Author: Gnus developers <ding@gnus.org>
Date:   Sun Feb 13 13:44:06 2011 +0000

    net/imap.el: Remove file.  All the functionality is in nnimap.el.
    nnimap.el (nnimap-request-accept-article, nnimap-process-quirk): Fix Gcc 
processing on imap.

Re: Build failure bzr trunk revno 103260

[Ted Zlatanov]

On Mon, 14 Feb 2011 10:11:51 +1100 Tim Cross <theophilusx@gmail.com> wrote: 

TC> FYI the current emacs trunk fails to build with the following error
TC> In toplevel form:
TC> gnus/gnus-cite.el:33:1:Error: Cannot open load file: imap
TC> make[3]: *** [/home/tcross/bzr/emacs/trunk/lisp/gnus/gnus-cite.elc] Error 1
TC> make[3]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
TC> make[2]: *** [compile-main] Error 2
TC> make[2]: Leaving directory `/home/tcross/bzr/emacs/trunk/lisp'
TC> make[1]: *** [lisp] Error 2
TC> make[1]: Leaving directory `/home/tcross/bzr/emacs/trunk'
TC> make: *** [bootstrap] Error 2

Doh.  I had a left-over imap.el in /usr/local/share and missed that
mail-source.el requires it.  Sorry about that.  I brought it back in the
Gnus trunk and it should be back in Emacs as well soon.

Thanks
Ted

Re: Build failure bzr trunk revno 103260

[Glenn Morris]

Ted Zlatanov wrote:

> Doh.  I had a left-over imap.el in /usr/local/share and missed that
> mail-source.el requires it.  Sorry about that.  I brought it back in the
> Gnus trunk and it should be back in Emacs as well soon.

It's been brought back without its history. This has happened before. It
needs to have the same bzr file-id as it used to.

Also, don't files usually go to obsolete/ before being deleted
altogether?

Re: Build failure bzr trunk revno 103260

[Glenn Morris]

Glenn Morris wrote:

> It's been brought back without its history. This has happened before. It
> needs to have the same bzr file-id as it used to.

Hopefully, I have done this via

bzr revert -r 103256 imap.el

https://lists.ubuntu.com/archives/bazaar/2011q1/071548.html

> Also, don't files usually go to obsolete/ before being deleted
> altogether?

Re: Build failure bzr trunk revno 103260

[Ted Zlatanov]

On Sun, 13 Feb 2011 20:22:14 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Also, don't files usually go to obsolete/ before being deleted
GM> altogether?

I don't see the point, considering it's so trivial to bring them back.
Gnus, at least, doesn't have such a place.  But if it's helpful, I'll do
it from now on.

Ted

imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Glenn Morris]

Ted Zlatanov wrote:

> GM> Also, don't files usually go to obsolete/ before being deleted
> GM> altogether?
>
> I don't see the point, considering it's so trivial to bring them back.

It's for the benefit of people using foo.el in external packages, so
that libraries don't just disappear from one Emacs release to the next.

On a related note, if nnimap.el is supposed to replace imap.el (?), then
I think it is problem that the former has so many (Gnus) dependencies.
Loading imap.el loads 1 file. Loading nnimap.el loads 57.

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Sun, 13 Feb 2011 22:00:11 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
GM> Also, don't files usually go to obsolete/ before being deleted
GM> altogether?
>> 
>> I don't see the point, considering it's so trivial to bring them back.

GM> It's for the benefit of people using foo.el in external packages, so
GM> that libraries don't just disappear from one Emacs release to the next.

Are there special warning when you use obsolete things?  `make-obsolete'
is on a finer level, but it's safe to assume that if something is in an
obsolete/ directory then everything inside should be obsoleted as well.

GM> On a related note, if nnimap.el is supposed to replace imap.el (?), then
GM> I think it is problem that the former has so many (Gnus) dependencies.
GM> Loading imap.el loads 1 file. Loading nnimap.el loads 57.

Gnus itself needs imap.el only in one place (mail-source.el) so I
propose we move imap.el to Emacs and out of Gnus when and if that
dependency is removed.  It's a general-purpose library anyway.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Gnus itself needs imap.el only in one place (mail-source.el) so I
> propose we move imap.el to Emacs and out of Gnus when and if that
> dependency is removed.  It's a general-purpose library anyway.

I wonder whether it might make some sense to re-separate out some of the
more basic IMAP stuff from nnimap.el again.  nnimap.el slurped in all
the protocol-specific stuff from imap.el so that it could implement what
Gnus needed more efficiently, but there isn't really much reason why,
say, the login functions (and related) could be separated out again.

Then non-Gnus packages could just use this new stripped-down basic IMAP
library.  I think, basically, what most useful is the login functions
and a simple `imap-command' function, and the rest would be application
specific.

I've had a peek at the relevant nnimap and mail-source functions, and it
seems like it should be doable in a pretty clean fashion.

However, if the new basic IMAP library is called imap.el, then this
would still break third-party applications.

Thoughts?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thoughts?

(The current imap.el is 3K lines.  The proposed minimal new imap.el
would be about 2-300 lines, which would be refactored out from
nnimap.el.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Mon, 14 Feb 2011 11:45:24 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Gnus itself needs imap.el only in one place (mail-source.el) so I
>> propose we move imap.el to Emacs and out of Gnus when and if that
>> dependency is removed.  It's a general-purpose library anyway.

LI> I wonder whether it might make some sense to re-separate out some of the
LI> more basic IMAP stuff from nnimap.el again.  nnimap.el slurped in all
LI> the protocol-specific stuff from imap.el so that it could implement what
LI> Gnus needed more efficiently, but there isn't really much reason why,
LI> say, the login functions (and related) could be separated out again.

LI> Then non-Gnus packages could just use this new stripped-down basic IMAP
LI> library.  I think, basically, what most useful is the login functions
LI> and a simple `imap-command' function, and the rest would be application
LI> specific.

LI> I've had a peek at the relevant nnimap and mail-source functions, and it
LI> seems like it should be doable in a pretty clean fashion.

LI> However, if the new basic IMAP library is called imap.el, then this
LI> would still break third-party applications.

Considering the work that went into nnimap.el, I agree some of it should
be thrown back into imap.el.  I guess you can try to provide backwards
compatibility, but it's not unprecedented to break the API in order to
get better functionality.  We can fix the stuff in Emacs that uses
imap.el and I doubt there's much third-party code using imap.el.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> We can fix the stuff in Emacs that uses imap.el and I doubt there's
> much third-party code using imap.el.

Yeah, there may not be much, but perhaps stuff like Mew and VM uses it?
I don't know.

The built-in stuff that uses imap.el now is mail-source.el,
imap-hash.el and url-imap.el, according to Grep.  I'm not sure
url-imap.el is useful...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Mon, 14 Feb 2011 13:13:26 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> We can fix the stuff in Emacs that uses imap.el and I doubt there's
>> much third-party code using imap.el.

LI> Yeah, there may not be much, but perhaps stuff like Mew and VM uses it?
LI> I don't know.

LI> The built-in stuff that uses imap.el now is mail-source.el,
LI> imap-hash.el and url-imap.el, according to Grep.  I'm not sure
LI> url-imap.el is useful...

imap-hash.el is gone.  I think url-imap.el should be removed too, no one
is using it AFAIK.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> imap-hash.el is gone.  I think url-imap.el should be removed too, no one
> is using it AFAIK.

So the only in-tree user would be mail-source.el?  I think it might
still be worth separating out the bits needed (login/send-command) from
nnimap.el and put them in imap.el.

Unless anybody has any objections, I'll take a whack at doing so.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Chong Yidong]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> However, if the new basic IMAP library is called imap.el, then this
> would still break third-party applications.
>
> Thoughts?

I don't know how many third-party applications make use of nnimap, but
if they do it would not be very clean, since nnimap requires Gnus.
Merging general purpose libraries from gnus/ back into net/ is good, and
I support the move.  Also, now (i.e. for Emacs 24.1) is as good a time
as any for this kind of change.

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

>> However, if the new basic IMAP library is called imap.el, then this
>> would still break third-party applications.
>>
>> Thoughts?
>
> I don't know how many third-party applications make use of nnimap, but
> if they do it would not be very clean, since nnimap requires Gnus.

I was talking about imap.el only (which was designed to be non-Gnusey, I
think), not nnimap.el.

> Merging general purpose libraries from gnus/ back into net/ is good, and
> I support the move.  Also, now (i.e. for Emacs 24.1) is as good a time
> as any for this kind of change.

I think I'll take a whack at separating out the login/send-command basic
functions from nnimap.el and put them into a new, minimal imap.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el

[Glenn Morris]

Ted Zlatanov wrote:

> Are there special warning when you use obsolete things?

Yes, you get a warning when loading something from obsolete/.

> Gnus itself needs imap.el only in one place (mail-source.el) so I
> propose we move imap.el to Emacs and out of Gnus when and if that
> dependency is removed.  It's a general-purpose library anyway.

Sounds good to me. It's already in the net/ directory in Emacs, so from
the Emacs side there would be nothing to do. Just stop syncing it
to/from Gnus I guess.

Re: imap.el and nnimap.el

[Ted Zlatanov]

On Mon, 14 Feb 2011 15:17:22 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> Are there special warning when you use obsolete things?

GM> Yes, you get a warning when loading something from obsolete/.

Great, I had never used it :)

>> Gnus itself needs imap.el only in one place (mail-source.el) so I
>> propose we move imap.el to Emacs and out of Gnus when and if that
>> dependency is removed.  It's a general-purpose library anyway.

GM> Sounds good to me. It's already in the net/ directory in Emacs, so from
GM> the Emacs side there would be nothing to do. Just stop syncing it
GM> to/from Gnus I guess.

OK.  Thanks for your help.

Ted

Re: Build failure bzr trunk revno 103260

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

011/2/14 Ted Zlatanov <tzz@lifelogs.com>

> On Sun, 13 Feb 2011 20:22:14 -0500 Glenn Morris <rgm@gnu.org> wrote:
>
> GM> Also, don't files usually go to obsolete/ before being deleted
> GM> altogether?
>
> I don't see the point, considering it's so trivial to bring them back.
> Gnus, at least, doesn't have such a place.  But if it's helpful, I'll do
> it from now on.
>
> I've had this debate with our local developers on our projects.

I'm personally in favor of an obsolete or attic directory.  While it may be
trivial to get things back out of a version control system, you need to know
they are there in the first place. I cannot count the number of times I've
found that a new job I'm working on is  modification or a replacement for
something that use to exist and was removed long before my time on the
project. A quick scan of the obsolete directory is often much faster than
remembering VC system specific commands to find possible candidates or rely
on enough details being recorded in the log to identify removed files of
interest. For little space, the obsolete/attic directory can provide a
really useful resource..

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]