Robert J. Chassell | 1 Jan 01:19 2010
Picon

Re: bazaar: "unable to obtain lock"

    I wrote:

        Next I am going to bootstrap it with the
        changes I got with a `bzr pull'.

        How do I avoid a shell and do it all in Emacs?

Karl Fogel <kfogel <at> red-bean.com> wrote:

    Oops, I'm not quite sure what the question is -- what's the "it" here?
    Compile Emacs?  Update your local sources using bzr?  

Both, using Emacs scripts such as these two (for the emacs/trunk/
directory):

    (progn
      (cd "/usr/local/src/emacs/trunk")
      (compile
       "time make -k -C lisp autoloads \
        EMACS=/usr/local/src/emacs/trunk/src/emacs && \
        cd lisp && \
        time make EMACS=/usr/local/src/emacs/trunk/src/emacs && \
        cd /usr/local/src/emacs/trunk && \
        time make info html"))

;; and

    (progn
      (cd "/usr/local/src/emacs/trunk/")
      (compile "time make -k"))
(Continue reading)

Phil Hagelberg | 1 Jan 01:40 2010

Re: Autoload from a web page?

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> The package manager should support multiple package repositories.
> [...]
>> 3. The FSF repository
>
>> This would contain only packages that are of could quality and
>> generally useful AND for which copyright assignments have been
>> filled out.
>
> For political reasons, we only want to support repositories where
> the copyright is owned by the FSF.  We also may want to support or
> notion of package quality, tho.  Also I find it important that multiple
> versions of a package can coexist at the same time (within reasonable
> feasability constraints: we don't need to handle multiple versions in
> a single Emacs sessions).

I am fine (but not thrilled) with Emacs only including an FSF-owned
repository or repositories out of the box. But I'd like to make sure
that this *doesn't* mean making it difficult for the user to add
third-party repositories for other software they may be interested
in. I'm sure this kind of antifeature wouldn't make it in to Emacs
anyway; I just thought it would be good to make that clear.

-Phil

Eric Lilja | 1 Jan 01:45 2010
Picon

Re: Emacs 23.1.91 pretest

On 2009-12-31 17:01, Drew Adams wrote:
>> From: Chong Yidong Sent: Wednesday, December 30, 2009 6:54 PM
>> Emacs pretest 23.1.91 is now available for download via FTP...
>>
>> This is the second pretest for what will be the Emacs 23.2 release.
>
>
>
> I never got a response to this question for the first pretest, so I'll try
> again:
>
>> From: Drew Adams Sent: Thursday, December 17, 2009 9:28 PM
>> To: 'Chong Yidong'; emacs-devel <at> gnu.org
>>
>> Will a Windows binary be posted for the pretest?
>> Or has it been posted already? I looked here, but don't see one:
>> http://alpha.gnu.org/gnu/emacs/pretest/windows/
>
> Previously, Windows binaries were available for pretests, and available via
> HTTP.
> And the README in that directory lists binaries that it says are contained
> there.
>
>
>
>

Jason Rumney used to build those, did he not? Where is he now? I miss 
you. :(

(Continue reading)

Richard Stallman | 1 Jan 03:54 2010
Picon
Picon

Re: Workflow to accumulate individual changes?

    I've never used 'bzr rebase', and have no competency to evaluate the
    arguments either way here, but... wouldn't something would smell fishy
    if rebase were part of our regular workflow?  That somehow seems wrong.

Are you saying that hackers who rebase can get addicted? ;-).

Richard Stallman | 1 Jan 03:55 2010
Picon
Picon

Re: Potential copyright problem in EIEIO improvement

    Thank you for your opinion on this. Regarding the "if" part, there are
    two parts: the canonical Dylan linearization, upon which the paper
    (mentioned in my original message) is improving and the actual
    improvement. The code above corresponds to the improvement. My patch
    also has parts derived from the unchanged parts of the canonical
    implementation.

You have lost me; I can't follow the scenario.

What I can say is that, in general, we do not want to incorporate
code into Emacs without a copyright assignment.

Richard Stallman | 1 Jan 03:55 2010
Picon
Picon

Re: Workflow to accumulate individual changes?

    A major problem with generating the ChangeLog from the commit messages
    is that you cannot fix a incorrect entry.

Is there no way to fix an error in a commit message?

Chong Yidong | 1 Jan 04:05 2010

Re: Bug tracker server problem

Chong Yidong <cyd <at> stupidchicken.com> writes:

> I just made a mistake while working on the bug tracker, resulting in the
> deletion of bug entries (ironically, this was while trying to set up a
> backup system).  I have restored the database from a partial backup made
> a couple of weeks ago, and am currently working to recover some
> additional data.
>
> Very sorry for the inconvenience.

OK, I've cleaned up my mistake.  There should be no data loss, but if
you come across any glitches in the system, please let me know.

Also: happy new year, everyone.

Lennart Borgman | 1 Jan 04:27 2010
Picon

Re: Bug tracker server problem

On Fri, Jan 1, 2010 at 4:05 AM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Chong Yidong <cyd <at> stupidchicken.com> writes:
>
>> I just made a mistake while working on the bug tracker, resulting in the
>> deletion of bug entries (ironically, this was while trying to set up a
>> backup system).  I have restored the database from a partial backup made
>> a couple of weeks ago, and am currently working to recover some
>> additional data.
>>
>> Very sorry for the inconvenience.
>
> OK, I've cleaned up my mistake.  There should be no data loss, but if
> you come across any glitches in the system, please let me know.
>
> Also: happy new year, everyone.

A happy new year to you too.

And thanks for doing the terrible work of restoring the bug database ;-)

Óscar Fuentes | 1 Jan 05:03 2010
Picon

Re: Workflow to accumulate individual changes?

Richard Stallman <rms <at> gnu.org> writes:

> Is there no way to fix an error in a commit message?

You can undo a commit with `bzr uncommit'. However, this only makes
sense if you are committing to some of your local branches. Once you
send your change upstream, pretending to alter the revision is like
asking for the removal of a message you published on a mailing list,
because the history is replicated everywhere.

Because of this and other more tehcnical reasons, NEVER use `bzr
uncommit' against an upstream branch. You would only cause lots of
misery.

--

-- 
Óscar

Stephen J. Turnbull | 1 Jan 09:41 2010
Picon

Re: GNU Emacs is on Bazaar now.

Miles Bader writes:

 > "Stephen J. Turnbull" <stephen <at> xemacs.org> writes:
 > > [1]  I know that multi-file features for vc are in progress, but it
 > > won't be as easy as "C-x v v C-x b ... until done", and the UI is
 > > likely to be more or less clumsy and unstable for several months at
 > > least.
 > 
 > Eh?  It might have bugs (dunno) but it's worked pretty well for typical
 > usage for quite a while, and it's essentially the same interface people
 > have used for a long time with pcvs...

OK, if so, then I retract my statement and recommend to Ken'ichi that
he try the other interface.

(I don't use it and I see a lot of traffic regarding UI issues with
vc-dir.  The "half-full" way to look at that is "people like it and
are recommending even better ways to use it", I guess. :-)


Gmane