2013/11/17 Richard Shann <[email protected]> > On Sun, 2013-11-17 at 14:38 +0100, Éloi Rivard wrote: > > Did you run ./autogen and ./configure ? > I was downloading and building from scratch (as a separate user, not > associated with development). In other words, I was playing the role of > a new user downloading and building the release (as best I could). > This is what Travis does, tag r1.1.0 seems ok here : https://travis-ci.org/denemo/denemo/builds/13463982
> There is no autogen.sh in these release tarballs, that step is already > done. > > Because menu.c is a file that has been created after the 1.1.0 tag, > > so it is normal it does not exist when you build it. > which means that the set of files in the tarball is inconsistent. Which > will be down to some misunderstanding about how to use tags. > > Ok that is what I did not understood, you try to build from the tarball and not the repository. That may mean that the tarball generation is inconstant, I will check that and add make it automatically checked in Travis. Why do you think it is related to tags ? > > > > Branches are supposed to use to bring fixes or features, and tags are > > supposed to mark releases. Git internally handle them differently. It > > is a bit easier to differentiate releases and feature code when you > > have a lot of branches (like me :) ). > > Well, as each release branch started with the name stable_ and then a > release number, this is not a strong argument. > > More seriously, this tag idea perhaps does not fit with how we make > releases. We decide that the master branch looks like it is a good state > (we used to freeze check-ins for a week or so, though as it was mostly > me doing the development, we haven't done that recently) and then make a > branch. Then we create a candidate release tarball and binaries for > testing and send the denemo.pot off to translationproject.org. During > the next few weeks we test (and hope others have picked up the binaries > and tried them). If all is well we apply the translations, generate a > tarball and binaries and check them for sanity and, all again being well > we sign and upload them to ftp.gnu.org and announce the release. > So there are always some changes to push to the release branch, and in > principle there could be fixes that just applied to a release, though we > are not at that level of sophistication and always just tell people to > get the latest release. > I don't know whether this fits the tag thing well, but there needs to be > something in return for learning new git concepts and new syntax (I am > hopeless at all that, but fortunately others have always helped with > this side of things). > > Richard > > This is a quite common workflow :), and this is why one can change the commit for which a tag stands for. If you want I can put some documentation on the website for how to use git for the Denemo workflow. > > > > > > > > 2013/11/16 Richard Shann <[email protected]> > > I downloaded this and tried to build and it failed at the make > > stage: > > > > denemo-user@DebianBox:~/denemo-1.1.0$ make && make install > > make all-recursive > > make[1]: Entering directory `/home/denemo-user/denemo-1.1.0' > > Making all in tools > > make[2]: Entering directory > > `/home/denemo-user/denemo-1.1.0/tools' > > gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -pthread > > -I/usr/include/guile/2.0 -I/usr/include/libxml2 -pthread > > -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo > > -I/usr/include/libpng12 -I/usr/include/pixman-1 > > -I/usr/include/freetype2 -pthread -lgthread-2.0 -lrt > > -lglib-2.0 -lsndfile -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread > > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 > > -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0 > > -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 > > -I/usr/include/freetype2 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread > > -I/usr/include/gtksourceview-3.0 -I/usr/include/libxml2 > > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 > > -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0 > > -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 > > -I/usr/include/freetype2 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread > > -I/usr/include/gtk-3.0 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > > -I/usr/include/atk-1.0 -I/usr/include/cairo > > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/freetype2 > > -I/usr/include/pixman-1 -I/usr/include/libpng12 > > -I/usr/include/evince/3.0 -DUSE_EVINCE -D_HAVE_FLUIDSYNTH_ > > -D_HAVE_RUBBERBAND_ -D_HAVE_PORTAUDIO_ -pthread > > -I/usr/include/aubio -D_HAVE_PORTMIDI_ -D_HAVE_X11_ -MT > > generate_source.o -MD -MP -MF .deps/generate_source.Tpo -c -o > > generate_source.o generate_source.c > > generate_source.c: In function ‘parse_menu_commands’: > > generate_source.c:102:20: fatal error: menu.c: No such file or > > directory > > compilation terminated. > > make[2]: *** [generate_source.o] Error 1 > > make[2]: Leaving directory > > `/home/denemo-user/denemo-1.1.0/tools' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/denemo-user/denemo-1.1.0' > > make: *** [all] Error 2 > > > > Would it make life simpler if we returned to using branches > > for releases? Is there some disadvantage? > > > > Richard > > > > > > > > On Fri, 2013-11-15 at 22:20 -0600, Jeremiah Benham wrote: > > > I have created a tarball for 1.1.0 testing now. I had to > > edit > > > configure.ac. For some reason I could not push the changes > > though. > > > Maybe I just don't know how to do it correctly. > > > > > > > > > Jeremiah > > > > > > > > > > > > On Tue, Nov 5, 2013 at 6:08 AM, Richard Shann > > > <[email protected]> wrote: > > > Jeremiah - can you create the release 1.1 tarball > > now for > > > sanity > > > checking before uploading to ftp.gnu.org? > > > The feature list for release 1.1 now looks like > > this: > > > > > > Palettes of commands > > > Customize content and shape > > > User created palettes > > > Movement Navigation Buttons > > > Buttons for quick change > > > Indication of current Movement > > > Raw LilyPond Output > > > For inclusion in user’s LilyPond template > > > Single keypress to update the output > > > Menu path to each command is shown > > > Tablature > > > Support for all instruments > > > > > > Upgrade Support > > > Keep custom shortcuts, palettes, etc on > > upgrading > > > Denemo > > > Command Center > > > Can stay open while working on score. > > > Replaces old Command Manager > > > Commands ordered by their labels > > > Incremental search for commands by label > > > Incremental search for strings within > > tooltips > > > Execute any command > > > Add any command to a palette > > > > > > Richard > > > > > > > > > > > > On Wed, 2013-10-23 at 20:53 +0100, Richard Shann > > wrote: > > > > I have just merged master into the stable-1.1.0 > > branch to > > > re-start the > > > > release with all the fixes. I built this version > > for windows > > > (in > > > > denemo.org/~rshann/uploads) and tested it. I have > > sent the > > > denemo.pot > > > > off to the translation project and so now we need > > to give > > > the > > > > translators time to work on the (only slightly) > > updated pot > > > file. > > > > > > > > Richard > > > > > > > > > > > > > > > > _______________________________________________ > > > > Denemo-devel mailing list > > > > [email protected] > > > > > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > > > > > > > > > _______________________________________________ > > > Denemo-devel mailing list > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > Denemo-devel mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > > > > > > > -- > > Éloi Rivard - [email protected] > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
