Re: [Monotone-devel] nvm.asio

[Zack Weinberg]

Yes, that's exactly what I had in mind.  There's the beginnings of it
in the library-build branch, but making autoconf do what we need is
not straightforward.

On 1/27/09, Matthew Nicholson  wrote:
> Zack Weinberg wrote:
>> (this was meant to go to the list yesterday)
>>
>> On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner  wrote:
>>> Hi,
>>>
>>> Zack Weinberg wrote:
 This has been proposed several times.
>>> Sorry for bringing this up again, then. But I don't remember any such
>>> discussion since using boost headers only.
>>
>> Hm, the last time I remember it coming up was at the face-to-face
>> conference back in 2007(?) and of course you weren't there.  Sorry.
>>
 There are technical reasons
 (having mostly to do with the complexity and abnormality of boost's
 build system) why it has never been done, but I do not think they are
 insurmountable.
>>> A build system? You don't need no build system for header files.
>>
>> I was going to say that we would at least need the logic to generate
>> boost/config.hpp but it turns out that's all done with #ifdefs when
>> the thing is used, which is not completely crazy as it means you can
>> use one installation with many compilers.  However, I don't want to
>> count on it staying that way.
>>
>>> Or put the other way around: what does using the system provided headers
>>> buy us here? It's not like distributors gain anything by building
>>> "against" system headers - unlike with libraries, where replacing the
>>> library could fix security issues in monotone (as well) or some such.
>>
>> If we use the system provided headers, then when there is a security
>> issue in boost, distributors only have to apply the patch to their
>> boost package and then recompile everything that depends on it, which
>> is highly automated.  If we bundle our own copy of boost headers, they
>> have to keep our package on a special list of additional places to
>> patch when there is a security issue in boost.
>>
>> Let me restate my position a different way:  I think there are
>> significant advantages to shipping *none* of the libraries we depend
>> on: we make life easier for Linux-style binary distributors, who only
>> have to carry one copy of any given piece of source; we make life
>> easier for ourselves, as we do not have to watch for new releases of
>> the libraries and do the integration work; we don't have to carry
>> around any pieces of the libraries' configuration scripts in our own,
>> and we don't lose performance because we left that piece of the
>> configuration out to save hassle (e.g. for Botan's assembly
>> optimizations).
>>
>> There are also different, significant advantages to shipping *all* of
>> the libraries we depend on (with the possible exception of zlib, which
>> is so stable and so ubiquitous that no one has ever had a problem to
>> date with our not shipping it): we control the exact version of each
>> library we use, so we're insulated from API churn; we can apply local
>> patches to fix problems that affect us, before new library versions
>> come out;  we make life easier for people building from source on
>> systems poor in libraries, e.g. windows.
>>
>> Any point in between those extremes gets the downsides of both and
>> only some of the advantages of either.  In particular, we don't make
>> it significantly easier for people building from source unless we ship
>> all the packages, and we don't make it significantly easier for
>> distributors - or ourselves - unless we ship none.
>>
>> I think there is a middle road, though.  Let .stripped become
>> mainline.  Then we revisit the .library-build branch, where we package
>> up exact copies of all the upstream libraries we depend upon, in
>> sibling directories to our own code.  We can then offer two tarballs -
>> the "thin" one with no upstream code, and the "fat" one that includes
>> everything and builds it all from source.
>
> I think this is a great idea.  I haven't looked at the library-build
> branch yet, but off the top of my head we could basically just use the
> build system of each library and make them install into a special
> staging dir, then build monotone against that statically linked.
>
> --
> Matthew Nicholson
> matt-land.com
>


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Matthew Nicholson]

Zack Weinberg wrote:

(this was meant to go to the list yesterday)

On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner  wrote:

Hi,

Zack Weinberg wrote:

This has been proposed several times.

Sorry for bringing this up again, then. But I don't remember any such
discussion since using boost headers only.


Hm, the last time I remember it coming up was at the face-to-face
conference back in 2007(?) and of course you weren't there.  Sorry.


There are technical reasons
(having mostly to do with the complexity and abnormality of boost's
build system) why it has never been done, but I do not think they are
insurmountable.

A build system? You don't need no build system for header files.


I was going to say that we would at least need the logic to generate
boost/config.hpp but it turns out that's all done with #ifdefs when
the thing is used, which is not completely crazy as it means you can
use one installation with many compilers.  However, I don't want to
count on it staying that way.


Or put the other way around: what does using the system provided headers
buy us here? It's not like distributors gain anything by building
"against" system headers - unlike with libraries, where replacing the
library could fix security issues in monotone (as well) or some such.


If we use the system provided headers, then when there is a security
issue in boost, distributors only have to apply the patch to their
boost package and then recompile everything that depends on it, which
is highly automated.  If we bundle our own copy of boost headers, they
have to keep our package on a special list of additional places to
patch when there is a security issue in boost.

Let me restate my position a different way:  I think there are
significant advantages to shipping *none* of the libraries we depend
on: we make life easier for Linux-style binary distributors, who only
have to carry one copy of any given piece of source; we make life
easier for ourselves, as we do not have to watch for new releases of
the libraries and do the integration work; we don't have to carry
around any pieces of the libraries' configuration scripts in our own,
and we don't lose performance because we left that piece of the
configuration out to save hassle (e.g. for Botan's assembly
optimizations).

There are also different, significant advantages to shipping *all* of
the libraries we depend on (with the possible exception of zlib, which
is so stable and so ubiquitous that no one has ever had a problem to
date with our not shipping it): we control the exact version of each
library we use, so we're insulated from API churn; we can apply local
patches to fix problems that affect us, before new library versions
come out;  we make life easier for people building from source on
systems poor in libraries, e.g. windows.

Any point in between those extremes gets the downsides of both and
only some of the advantages of either.  In particular, we don't make
it significantly easier for people building from source unless we ship
all the packages, and we don't make it significantly easier for
distributors - or ourselves - unless we ship none.

I think there is a middle road, though.  Let .stripped become
mainline.  Then we revisit the .library-build branch, where we package
up exact copies of all the upstream libraries we depend upon, in
sibling directories to our own code.  We can then offer two tarballs -
the "thin" one with no upstream code, and the "fat" one that includes
everything and builds it all from source.


I think this is a great idea.  I haven't looked at the library-build 
branch yet, but off the top of my head we could basically just use the 
build system of each library and make them install into a special 
staging dir, then build monotone against that statically linked.


--
Matthew Nicholson
matt-land.com


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: ViewMTN shows empty list of branches; error in log

[Lapo Luchini]

Ludovic Brenta wrote:
> Timothy Brownawell  writes:
>> NEWS says that "mtn suspend" and the --ignore-suspend-certs option
>> were added in 0.41.
> 
> OK, then I suggest that the INSTALL document mention that viewmtn
> requires monotone >= 0.41.

Mhhh, nah, that feature is much older than 0.41...

-
Revision: 47a1fb3d88e993ce13017e516dce83e55473398a
Ancestor: 23be2caecf7bdb7412054fafcf4c0f4b97e7ff16
Author: wi...@cse.unsw.edu.au
Date: 2007-08-11T08:12:06
Branch: net.venge.monotone
ChangeLog:
 * Change the --ignore_suspend_certs option to --ignore-suspend-certs.
-

That date is just a few days after 0.37 was released...

Oh, in fact the NEWS file says itself so:

  This feature was already added in monotone 0.37, but was
  forgotten to be mentioned in NEWS back then.

-- 
Lapo Luchini - http://lapo.it/

“There is nothing new to be discovered in physics now; All that remains
is more and more precise measurement.” (Lord Kelvin, 1900)



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] ViewMTN shows empty list of branches; error in log

[Ludovic Brenta]

Timothy Brownawell  writes:
> NEWS says that "mtn suspend" and the --ignore-suspend-certs option
> were added in 0.41.

OK, then I suggest that the INSTALL document mention that viewmtn
requires monotone >= 0.41.  Currently it says:

Monotone: http://monotone.ca/
A version which is descended from [62961c1dc..] is required.
This is post-0.30.

Thanks to your reply, I have patched viemtn minimally so it doesn't
pass --ignore-suspend-certs to monotone.  This way I have been able to
restore the ViewMTN service on www.ada-france.org:8081.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Zack Weinberg]

On Tue, Jan 27, 2009 at 8:45 AM, Ulf Ochsenfahrt  wrote:
> There is also the issue with compiling monotone on 'older' platforms.
> For example, I still provide packages for Ubuntu 8.04, which has an
> older version of pcre. Does stripped support pcre 7.4?

The configure script enforces pcre 7.6 because of security fixes in
that version (CVE-2008-2371) but if you know that your 7.4 is good,
you can patch m4/library.m4 to relax the constraint.

I'm seriously considering tightening up all of the library
dependencies in nvm.asio but that branch isn't intended to land
anytime soon.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: more .stripped work - please test installation & translation workflow

[Zack Weinberg]

On Tue, Jan 27, 2009 at 7:01 AM, Lapo Luchini  wrote:
> The (Italian) translator workflow used to be:
>
> $ make monotone.pot-update
>
> and then "import" new monotone.pot into it.po using poEdit directly.
>
> Any other command that updates monotone.pot can od, of course ;-)
> (`make monotone.pot-update` was never easy to remember)

It's just "make monotone.pot" now -- but the file will end up in the
build directory, not the source directory.  The only makefile target
that writes to srcdir/po/ anymore is "make .po-update".

I should also mention that you do all these commands from the top
level of the build tree now.  There isn't a po subdirectory of the
build tree anymore.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] more .stripped work - please test installation & translation workflow

[Zack Weinberg]

On Tue, Jan 27, 2009 at 1:24 AM, Thomas Keller  wrote:
> Zack Weinberg schrieb:
>> However, as ever when one messes with the Makefile, I may have broken
>> something.  I'm particularly concerned about installation (it
>> *appears* to put the .mo files in the right place, but ...) and the
>> translation workflow, with which I am not very familiar.  Please test.
>
> Yes, unfortunately you seem to have broken it ;)
>
> The usual (German) translator workflow is
>
> $ make monotone.pot-update && make de.po-update
>
> but the first one already fails because of the dropped POTFILES.in:
>
> make: *** No rule to make target `POTFILES.in', needed by `Makefile'.  Stop.
>
> This one now gets autogenerated, right?

Replaced with a big list in the Makefile.  I think that error means
you need to erase your build directory, re-run autoreconf -i in the
source directory, and reconfigure.

Also, "monotone.pot-update" is now spelled just "monotone.pot" and you
can skip straight to "make de.po-update" if you want.  Or "make
de.merged.po" will drop an updated .po file in the build directory so
you can compare it with the old one.  I probably should have said all
this in my original post.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Ulf Ochsenfahrt]

There is also the issue with compiling monotone on 'older' platforms.
For example, I still provide packages for Ubuntu 8.04, which has an
older version of pcre. Does stripped support pcre 7.4?

-- Ulf

On Tue, Jan 27, 2009 at 5:31 PM, Zack Weinberg  wrote:
> (this was meant to go to the list yesterday)
>
> On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner  wrote:
>> Hi,
>>
>> Zack Weinberg wrote:
>>> This has been proposed several times.
>>
>> Sorry for bringing this up again, then. But I don't remember any such
>> discussion since using boost headers only.
>
> Hm, the last time I remember it coming up was at the face-to-face
> conference back in 2007(?) and of course you weren't there.  Sorry.
>
>>> There are technical reasons
>>> (having mostly to do with the complexity and abnormality of boost's
>>> build system) why it has never been done, but I do not think they are
>>> insurmountable.
>>
>> A build system? You don't need no build system for header files.
>
> I was going to say that we would at least need the logic to generate
> boost/config.hpp but it turns out that's all done with #ifdefs when
> the thing is used, which is not completely crazy as it means you can
> use one installation with many compilers.  However, I don't want to
> count on it staying that way.
>
>> Or put the other way around: what does using the system provided headers
>> buy us here? It's not like distributors gain anything by building
>> "against" system headers - unlike with libraries, where replacing the
>> library could fix security issues in monotone (as well) or some such.
>
> If we use the system provided headers, then when there is a security
> issue in boost, distributors only have to apply the patch to their
> boost package and then recompile everything that depends on it, which
> is highly automated.  If we bundle our own copy of boost headers, they
> have to keep our package on a special list of additional places to
> patch when there is a security issue in boost.
>
> Let me restate my position a different way:  I think there are
> significant advantages to shipping *none* of the libraries we depend
> on: we make life easier for Linux-style binary distributors, who only
> have to carry one copy of any given piece of source; we make life
> easier for ourselves, as we do not have to watch for new releases of
> the libraries and do the integration work; we don't have to carry
> around any pieces of the libraries' configuration scripts in our own,
> and we don't lose performance because we left that piece of the
> configuration out to save hassle (e.g. for Botan's assembly
> optimizations).
>
> There are also different, significant advantages to shipping *all* of
> the libraries we depend on (with the possible exception of zlib, which
> is so stable and so ubiquitous that no one has ever had a problem to
> date with our not shipping it): we control the exact version of each
> library we use, so we're insulated from API churn; we can apply local
> patches to fix problems that affect us, before new library versions
> come out;  we make life easier for people building from source on
> systems poor in libraries, e.g. windows.
>
> Any point in between those extremes gets the downsides of both and
> only some of the advantages of either.  In particular, we don't make
> it significantly easier for people building from source unless we ship
> all the packages, and we don't make it significantly easier for
> distributors - or ourselves - unless we ship none.
>
> I think there is a middle road, though.  Let .stripped become
> mainline.  Then we revisit the .library-build branch, where we package
> up exact copies of all the upstream libraries we depend upon, in
> sibling directories to our own code.  We can then offer two tarballs -
> the "thin" one with no upstream code, and the "fat" one that includes
> everything and builds it all from source.
>
> zw
>
>
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Zack Weinberg]

(this was meant to go to the list yesterday)

On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner  wrote:
> Hi,
>
> Zack Weinberg wrote:
>> This has been proposed several times.
>
> Sorry for bringing this up again, then. But I don't remember any such
> discussion since using boost headers only.

Hm, the last time I remember it coming up was at the face-to-face
conference back in 2007(?) and of course you weren't there.  Sorry.

>> There are technical reasons
>> (having mostly to do with the complexity and abnormality of boost's
>> build system) why it has never been done, but I do not think they are
>> insurmountable.
>
> A build system? You don't need no build system for header files.

I was going to say that we would at least need the logic to generate
boost/config.hpp but it turns out that's all done with #ifdefs when
the thing is used, which is not completely crazy as it means you can
use one installation with many compilers.  However, I don't want to
count on it staying that way.

> Or put the other way around: what does using the system provided headers
> buy us here? It's not like distributors gain anything by building
> "against" system headers - unlike with libraries, where replacing the
> library could fix security issues in monotone (as well) or some such.

If we use the system provided headers, then when there is a security
issue in boost, distributors only have to apply the patch to their
boost package and then recompile everything that depends on it, which
is highly automated.  If we bundle our own copy of boost headers, they
have to keep our package on a special list of additional places to
patch when there is a security issue in boost.

Let me restate my position a different way:  I think there are
significant advantages to shipping *none* of the libraries we depend
on: we make life easier for Linux-style binary distributors, who only
have to carry one copy of any given piece of source; we make life
easier for ourselves, as we do not have to watch for new releases of
the libraries and do the integration work; we don't have to carry
around any pieces of the libraries' configuration scripts in our own,
and we don't lose performance because we left that piece of the
configuration out to save hassle (e.g. for Botan's assembly
optimizations).

There are also different, significant advantages to shipping *all* of
the libraries we depend on (with the possible exception of zlib, which
is so stable and so ubiquitous that no one has ever had a problem to
date with our not shipping it): we control the exact version of each
library we use, so we're insulated from API churn; we can apply local
patches to fix problems that affect us, before new library versions
come out;  we make life easier for people building from source on
systems poor in libraries, e.g. windows.

Any point in between those extremes gets the downsides of both and
only some of the advantages of either.  In particular, we don't make
it significantly easier for people building from source unless we ship
all the packages, and we don't make it significantly easier for
distributors - or ourselves - unless we ship none.

I think there is a middle road, though.  Let .stripped become
mainline.  Then we revisit the .library-build branch, where we package
up exact copies of all the upstream libraries we depend upon, in
sibling directories to our own code.  We can then offer two tarballs -
the "thin" one with no upstream code, and the "fat" one that includes
everything and builds it all from source.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: more .stripped work - please test installation & translation workflow

[Lapo Luchini]

Thomas Keller wrote:
>> However, as ever when one messes with the Makefile, I may have broken
>> something.  I'm particularly concerned about installation (it
>> *appears* to put the .mo files in the right place, but ...) and the
>> translation workflow, with which I am not very familiar.  Please test.
> 
> Yes, unfortunately you seem to have broken it ;)
> 
> The usual (German) translator workflow is
> 
> $ make monotone.pot-update && make de.po-update

The (Italian) translator workflow used to be:

$ make monotone.pot-update

and then "import" new monotone.pot into it.po using poEdit directly.

Any other command that updates monotone.pot can od, of course ;-)
(`make monotone.pot-update` was never easy to remember)

-- 
Lapo Luchini - http://lapo.it/

“Any sufficiently advanced technology is indistinguishable from magic.”
(Arthur C. Clarke)



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: more on commit without -b option

[Matthew Nicholson]

Derek Scherger wrote:
On Wed, Jan 21, 2009 at 12:52 PM, Derek Scherger > wrote:


When commit opens your editor to write a changelog maybe it should
load the buffer with something that looks a *lot* like a committed
revision as listed by log. Then, you not only get to see the
Ancestor, Author, Date and Branch values of your pending commit but
you could also *edit* them before saving the log and actually doing
the commit. This essentially changes the format of messages coming
back from the commit hook and requires them to have some structure.
After getting the message from the hook it would be parsed and the
various values would be used for their respective certs.


I've pushed a couple of revs to 
net.venge.monotone.experiment.changelog-editor that essentially 
implement this different style of changelog editing. Having used this 
new changelog editor to commit the two revs involved in its 
implementation, it seems quite nice to be able to "see" what the 
revision will look like and to edit the branch you're committing to in 
the process of writing or finalizing the changelog. The idea that status 
shows a rev you're working on, commit shows the same thing as you're 
committing it and log shows the same thing later seems good to me.


There are a few more changes I'd like to make before I'd call this 
branch finished but I'd like to get some feedback and see what people 
think first before spending time on them:


(1) We have two different forms of revision summary, one used by commit 
and status and another used by log. These should probably be unified, I 
prefer the one that status and commit use slightly. The log output 
contains "Ancestor:" lines that should probably be "Parent:" to be 
consistent with other tools and more correct.
(2) The revision_summary function in cmd_ws_commit.cc uses 
(F("...")).str() += "\n" which looks quite odd and I wonder if there's 
any real point or if it could use an ostringstream to good effect.
(3) The get_log_message_interactively function in cmd_ws_commit.cc 
claims "Lines beginning with `MTN:' are removed automatically." but 
doesn't do anything with them. They are instead handled by the lua 
edit_comment hook. It seems odd to separate these things but that may be 
unavoidable in the current arrangement. This new branch removes this 
stuff altogether.


I can see a few potential problems with this branch or objections to the 
change in general and I'm curious if they're real or if I'm imagining them:


(1) It's a sufficiently different way of editing a changelog that no 
other vcs that I know of currently does and may put people off or 
confuse them the first time they use it. People may just not like it 
because it's different.


As long as the user is not forced to do anything different than other 
vcs systems, I don't think this is a problem.


(2) It will break scripts or other tools that currently use the output 
from status or log or use commit in certain ways. These things are 
probably supposed to be using the automate interface but they may have 
no choice if the features they need are lacking. (monotone.el comes to 
mind as something to be checked; dvc.el as well presumably)


Hmm... as long as they are still easily human readable, I don't have a 
problem with it.


(3) The api changes to the edit_comment hook will break anyone who has a 
custom hook. Will a simple NEWS entry regarding this suffice?


This could be a problem, especially for people who don't read NEWS 
before an upgrade.  Breakages may just be something we have to deal with 
though.



Comments?


I think this is a good feature.  Being able to change information about 
the commit is useful from the commit message.  As long as these changes 
don't change things for users who are used to just editing the commit 
message, I don't have a problem with these new options.


--
Matthew Nicholson
matt-land.com


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Matthew Nicholson]

Markus Wanner wrote:

Hi,

Matthew Nicholson wrote:

From a packager's standpoint, using the system headers makes security
bugs more explicit.  If the packager's build system knows that monotone
has a build time dependency on a particular library (even if it is
header only) and a security bug is found in that library, then the
packager knows it needs to recompile that library.  If the library is
bundled in monotone, that information is lost.


Thank you for this feedback from a packager's point of view.

However, unlike you seem to assume, recompiling the library does *not*
help with this kind of dependency. You need to recompile and repackage
monotone. In this regard, header-only dependencies are rather different
from library dependencies.


Yeah.  That was supposed to say recompile monotone, but you get the idea.


But, yeah, I take the point that packagers like the information that
monotone is "build time dependent" on boost. That would get lost if we
drop the dependency and incorporate the headers.




--
Matthew Nicholson
matt-land.com


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.asio

[Markus Wanner]

Hi,

Matthew Nicholson wrote:
> From a packager's standpoint, using the system headers makes security
> bugs more explicit.  If the packager's build system knows that monotone
> has a build time dependency on a particular library (even if it is
> header only) and a security bug is found in that library, then the
> packager knows it needs to recompile that library.  If the library is
> bundled in monotone, that information is lost.

Thank you for this feedback from a packager's point of view.

However, unlike you seem to assume, recompiling the library does *not*
help with this kind of dependency. You need to recompile and repackage
monotone. In this regard, header-only dependencies are rather different
from library dependencies.

But, yeah, I take the point that packagers like the information that
monotone is "build time dependent" on boost. That would get lost if we
drop the dependency and incorporate the headers.

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] more .stripped work - please test installation & translation workflow

[Thomas Keller]

Zack Weinberg schrieb:
> I was going to mess with libasio today, but instead, on .stripped I
> tore out the awful, awful autoconf macros provided by the gettext
> developers and substituted custom logic.  This has several nice
> consequences:  the makefile is no longer at all recursive, we don't
> need horrible hacks to stop the po subdirectory Makefile from stomping
> on translations, the configure script no longer does a whole pile of
> unnecessary tests, and I think detection of libintl and libiconv may
> now actually be *correct* rather than mostly wrong.
> 
> However, as ever when one messes with the Makefile, I may have broken
> something.  I'm particularly concerned about installation (it
> *appears* to put the .mo files in the right place, but ...) and the
> translation workflow, with which I am not very familiar.  Please test.

Yes, unfortunately you seem to have broken it ;)

The usual (German) translator workflow is

$ make monotone.pot-update && make de.po-update

but the first one already fails because of the dropped POTFILES.in:

make: *** No rule to make target `POTFILES.in', needed by `Makefile'.  Stop.

This one now gets autogenerated, right?

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] ViewMTN shows empty list of branches; error in log

[Thomas Keller]

Timothy Brownawell schrieb:
> On Mon, 2009-01-26 at 09:47 +0100, Ludovic Brenta wrote:
>> Hi
>>
>> I'm trying to restore the viewmtn service on www.ada-france.org.
> 
>> In the home page of the web interface, the list of branches is empty.
>> The list of tags is OK; from a tag I can then navigate to a branch.
>> Whenever I reload the home page (which should contain the list of
>> branches), the console says:
>>
>> 'exception writing to child process; attempting restart: Traceback (most 
>> recent call last):\n  File 
>> "/var/lib/monotone/net.angrygoats.viewmtn/mtn.py", line 168, in __run\n
>> self.process.tochild.flush()\nIOError: [Errno 32] Broken pipe\n'
>> '[10396] stopping process: 10407'
>>
>> Did I do something wrong?  I looked at the "mtn log" of mtn.py but
>> could not find anything that would require a version of monotone more
>> recent than I have.
>>
>> Any help is appreciated.
>>
>> PS.
>> $ mtn status
>> Current branch: net.angrygoats.viewmtn
>> Changes against parent ff6f92608b076dabc1da2f37b4aa326f47a8a7eb
>>   no changes
>>
>> $ mtn --full-version
>> monotone 0.31 (base revision: 1bd1fe1e811dce82bee09b9f0effca3225bd1cee)
>> Running on  : Linux 2.6.24.2dedibox-r8-1-c7 #1 Mon Feb 11 17:41:33 
>> CET 2008 i686
>> C++ compiler: GNU C++ version 4.1.2 20061115 (prerelease) (Debian 
>> 4.1.1-21)
>> C++ standard library: GNU libstdc++ version 20061115
>> Boost version   : 1_33_1
>> Changes since base revision:
>> unknown
> 
> @@ 394,2 @@ mtn.py
>  def branches(self):
>  for line in (t.strip() for t in self.automate.run('branches',
> [], ignore_suspend_certs="")):
> 
> NEWS says that "mtn suspend" and the --ignore-suspend-certs option were
> added in 0.41.

You haven't read until the end:

  This feature was already added in monotone 0.37, but was
  forgotten to be mentioned in NEWS back then.

I've added this section in 0.41 so people get a chance to know about
this feature at all. Although, thanks for digging this out. His version
(0.31) is too old anyways.

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel