Hi Harm,
> my talk would be probably of some interest for you.
It absolutely is. =)
> Alas, it will be in german, so I can't imagine how helpful it would be for
> you.
Ja, es ist so lange her, dass ich Deutsch gesprochen habe, dass ich fast alles
vergessen habe!! Doch ich werde da sein.
>
Dan Eble writes:
> I recently started using a git GUI, GitUp, which sometimes infers that
> I might want to delete origin/staging, and offers to do it for me.
> Needless to say, I don't want that; and I've suggested in the GitUp
> issue tracker that even prompting me is a defect, in the light of
Am Mo., 13. Jan. 2020 um 22:00 Uhr schrieb Urs Liska :
>
> Am Montag, den 13.01.2020, 15:42 -0500 schrieb Kieren MacMillan:
> > Hello future Salzburg-ers!
> >
> > Knowing the way my life works, and the fact that I’ll be in Salzburg
> > for four days without the normal distractions (family, etc.),
I recently started using a git GUI, GitUp, which sometimes infers that I might
want to delete origin/staging, and offers to do it for me. Needless to say, I
don't want that; and I've suggested in the GitUp issue tracker that even
prompting me is a defect, in the light of this project's
Il giorno mar 14 gen 2020 alle 18:21, Peter Toye
ha scritto:
I'm trying to work out how to run LilyDev in VirtualBox on a Windows
system., but the information in section 2.1 of the CG seems to be
inaccurate, and I suspect it's a bit out of date.
Under "Installing LilyDev in VirtualBox"
On 2020/01/14 18:21:32, hahnjo wrote:
Dan, if you don't want to run autogen.sh with a writable
~/lilypond-src, maybe
you can instead copy all files from that directory to a fresh one in
the
container?
If this expands to "rsync the latest changes to the build directory
before you build; and
Let me try to recount all the factors that did or do contribute to my
liking a read-only source directory. This is mainly to help me decide
whether to concede this feature, not to elicit any response from you.
Unstable virtualization. Linux in VirtualBox (which I no longer use) on
macOS did
On 2020/01/14 17:43:19, Dan Eble wrote:
On 2020/01/14 13:12:54, Dan Eble wrote:
> Harm,
> Do you want more time to consider this change, or are you now
comfortable with
> my pushing it?
Since your primary concern was that modifying Global in a \layout
block should
still work, and my
I'm trying to work out how to run LilyDev in VirtualBox on a Windows system.,
but the information in section 2.1 of the CG seems to be inaccurate, and I
suspect it's a bit out of date.
Under "Installing LilyDev in VirtualBox" the filename is given as
lilydev-vm-fedora-VERSION.raw but the
On 2020/01/14 15:54:28, dak wrote:
Well, how about
diff --git a/autogen.sh b/autogen.sh
index 1ca0fc0c0f..c638993f34 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -18,7 +18,7 @@ else
configure=./configure
conf_flags="--srcdir $srcdir $conf_flags"
echo "Running autoconf for read-only
On 2020/01/14 13:12:54, Dan Eble wrote:
Harm,
Do you want more time to consider this change, or are you now
comfortable with
my pushing it?
Since your primary concern was that modifying Global in a \layout block
should still work, and my testing shows that it does, I'm going to push
this.
On 2020/01/14 16:35:50, Dan Eble wrote:
On 2020/01/14 15:54:28, dak wrote:
> +AC_INIT([LilyPond],
> +[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo
I was about to test it, but the main patch no longer applies to
master. I'll
try against an older version.
I do wonder whether someone
On 2020/01/14 16:35:50, Dan Eble wrote:
On 2020/01/14 15:54:28, dak wrote:
> +AC_INIT([LilyPond],
> +[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo
I was about to test it, but the main patch no longer applies to
master. I'll
try against an older version.
I do wonder whether someone
On 2020/01/14 15:54:28, dak wrote:
+AC_INIT([LilyPond],
+[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo
I was about to test it, but the main patch no longer applies to master.
I'll try against an older version.
I do wonder whether someone might see ${SRCDIR} here and use it
elsewhere in the
On 2020/01/14 15:19:09, dak wrote:
On 2020/01/14 15:07:48, dak wrote:
> On 2020/01/14 14:48:44, Dan Eble wrote:
> > On 2020/01/14 14:43:34, hahnjo wrote:
> > > On 2020/01/14 14:29:38, Dan Eble wrote:
> > > > On 2020/01/14 13:59:43, dak wrote:
> > > > > On 2020/01/14 13:52:02, hahnjo wrote:
> > >
On 2020/01/14 15:07:48, dak wrote:
On 2020/01/14 14:48:44, Dan Eble wrote:
> On 2020/01/14 14:43:34, hahnjo wrote:
> > On 2020/01/14 14:29:38, Dan Eble wrote:
> > > On 2020/01/14 13:59:43, dak wrote:
> > > > On 2020/01/14 13:52:02, hahnjo wrote:
> > > > I am not overly happy that it makes for
Jonas,
If you want to push this in a form where the only thing lacking is to
copy VERSION to the build directory, I am willing to test and submit a
patch to autogen.sh.
https://codereview.appspot.com/549350043/
On 2020/01/14 14:48:44, Dan Eble wrote:
On 2020/01/14 14:43:34, hahnjo wrote:
> On 2020/01/14 14:29:38, Dan Eble wrote:
> > On 2020/01/14 13:59:43, dak wrote:
> > > On 2020/01/14 13:52:02, hahnjo wrote:
> > > I am not overly happy that it makes for inoperative code in the
case of a
> > >
On 2020/01/14 14:43:34, hahnjo wrote:
On 2020/01/14 14:29:38, Dan Eble wrote:
> On 2020/01/14 13:59:43, dak wrote:
> > On 2020/01/14 13:52:02, hahnjo wrote:
> > I am not overly happy that it makes for inoperative code in the
case of a
> > read-only repository that autogen.sh tries catering
On 2020/01/14 14:29:38, Dan Eble wrote:
On 2020/01/14 13:59:43, dak wrote:
> On 2020/01/14 13:52:02, hahnjo wrote:
> I am not overly happy that it makes for inoperative code in the case
of a
> read-only repository that autogen.sh tries catering for.
Thank you for calling this out, for I was
On 2020/01/14 14:12:47, hahnjo wrote:
On 2020/01/14 13:59:43, dak wrote:
> On 2020/01/14 13:52:02, hahnjo wrote:
> > Is this ok to push in its current revision?
>
> I am not overly happy that it makes for inoperative code in the case
of a
> read-only repository that autogen.sh tries catering
On 2020/01/14 13:59:43, dak wrote:
On 2020/01/14 13:52:02, hahnjo wrote:
I am not overly happy that it makes for inoperative code in the case
of a
read-only repository that autogen.sh tries catering for.
Thank you for calling this out, for I was not paying attention. I am
currently using a
On 2020/01/14 13:59:43, dak wrote:
On 2020/01/14 13:52:02, hahnjo wrote:
> Is this ok to push in its current revision?
I am not overly happy that it makes for inoperative code in the case
of a
read-only repository that autogen.sh tries catering for. Can/should
autogen.sh
pass some sort
On 2020/01/14 13:52:02, hahnjo wrote:
Is this ok to push in its current revision?
I am not overly happy that it makes for inoperative code in the case of
a read-only repository that autogen.sh tries catering for. Can/should
autogen.sh pass some sort of environment variable that this can be
Is this ok to push in its current revision?
https://codereview.appspot.com/549350043/
Harm,
Do you want more time to consider this change, or are you now
comfortable with my pushing it?
--
Dan
https://codereview.appspot.com/567050043/
Hello,
Here is the current patch countdown list. The next countdown will be on
January 16th.
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/ [1]
PUSH:
5657 Remove vestiges of support for systems without -
27 matches
Mail list logo
