Re: [Monotone-devel] No sponsored hardware :(
On 23.08.2010 19:35, Tero Koskinen wrote: If we end up buying a VPS for the project how we handle all the maintenance things? Do we need to care about the bus factor of the maintainer(s)? (What happens if you get hit by a bus, spend ten years in a coma, and we need to renew the VPS subscription?) The core developers should share all accounting information, maybe through a private section in the Wiki or by other means (snail mail is also a lot quicker than it used to be 30 years ago. I'm drifting here). For the payment there could be some online bank account which has all core developers registered as holders. There are lots of offers which don't come with an additional fee. Also the VPS hoster should know that there are several people in charge. We once had problems when we shared our dedicated server among a few people, the server support refused to speak to anybody except to the one who originally sealed the deal, which is not necessarily the person with the most available spare time, availability, whatever ;) (Side note: I wouldn't go as far as establishing some own NPO, that usually implies more problems than it solves) And how the collection of money happens? Wire transfers inside Europe are free (thanks to SEPA), but people outside Europe might prefer other ways. The Flattr-Project seems to work good for a few blogs and websites I regularly visit, and Paypal is planning a micropayment system, too. The other story is if one likes using those services, but it could be a start for people from outside of europe. Also there could be some nice Please donate buttons on the starting page. (Of course with their image files mirrored locally, for terms of privacy protection. At least Flattr explicitly allows that). On 23.08.2010 14:54, Thomas Keller wrote: If not, who is willing to throw in some money to buy a server? Count on me there :) Opinions and / or alternative offerings? I was shortly thinking about offering some place on my own VPS, which is quite bored most of the day. But it has very limited hardware compared to the offer on Netcup, also I don't have unlimited traffic. Are there some statistics about average memory usage (excluding Apache and MySQL, which are running either way) and monthly traffic? What about peak usage around the release dates? So far ... Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
1. Deal with the issue of oops, I forgot to specify a --branch option for this commit and now I have to start over which is now handled by being able to see and change the branch you're committing to while editing the commit message. Surprise, I didn't know this information was editable and furthermore would have an effect on the commit action. Should have read the NEWS more thoroughly :-) Anyway I do like it, because now I don't have to copypaste in my terminal, which would normally need another mtn call to get the branch string to copy from. Also I don't mind scrolling down a few lines. Could this be made switchable, maybe through the users' monotonerc? Folks who like the old template could then easily reactivate it. Another bunch of questions: isn't it dangerous to have the Date field editable, or are there checks done to guarantee the entered date is reasonable, and for example not temporally _before_ the last revision's date? What purpose is there anyway in having an editable Date field? Greetings, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release Of mtn-browse Version 0.70 and Monotone::AutomateStdio 0.08
On 31.05.2010 19:43, Anthony Edward Cooper wrote: I would like to announce the 0.70 release of mtn-browse: I tried to compile this one here, and it states Can't locate Glib.pm in @INC ... As I don't have the slightest clue about Perl, I can only guess that it is dev-perl/glib-perl (from http://gtk2-perl.sf.net) which is wanted here. At least the package is named so on Gentoo. Besides this one, are there any other dependencies which I would possibly have to resolve manually? And as I am trying to write an ebuild for it, could you please include the minimum required versions? Thanks, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usabilty of translations
On 29.05.2010 15:34, Zbigniew Zagórski wrote: I know that amongst developers (at least professional ones), there is strong movement to use english-only UI/termsinstead native ones - ad-hoc created terms create only confusion and thus are problematic (at least polish IT/CS terminology/vocabulary is week) . YYMV but in my experience- use only english terms. So then ... I this experience is similar to yours? Nearly all software on my boxes, either workstations or servers, is using the english language. Thanks to Gentoo, I removed the nls use flag and so every package compiles with english messages only. Monotone too, of course. First, most of the text ist shorter to read and uses less space in the UI. Second, no trouble with character sets. English text tends to stay in the 7bit ASCII range, so you can cleanly read the output, despite terminal settings. Third, and that's possibly the most important, if I encounter an error message, it's far more likely that I will get search results for the english error message, than for example for a german one, which would be my native language. off topic :-) For my opinion, much of the work which is put into translations today should be put into working with the actual code. Also many translators tend to translate *everything* and also often literally. In KDE set to english, two example icons are captioned with Paste and Fetch Feed. With german setting I would get Von Zwischenablage einfügen and Nachrichtenquelle abholen. That's kind of ridiculous. /offtopic To put it short: +1 for english messages, they're the only ones I need for the above stated reasons. My zwo Pfennig, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On 28.05.2010 10:23, CooSoft Support wrote: I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. Sure it's psychological and nowadays in the age of OSS, versioning schemes or rather the progress of their numbers are often not really expressive. Wine took 10 years to release 1.0 and noone really cared in the end, because it has been working for ages before. On the other hand I've seen software for example in a 5.x version and was hugely wondering what that thing did the four major versions before. People shouldn't look at the numbers of the version but rather on the feature list on the project's website. Maybe somewhere on that website there should be included a sentence like We use it all the time and no problems so far. Like Jack, I personally use Monotone for all my work stuff, source codes, server configs, etc. My lady is using Monotone for her thesis. No problems ever, so count that as +2 from here :-) One problem of a 1.0 or 1.0.0 release could be, that the more sophisticated users from bigger development groups, which then start to use monotone because of the major release, often stick to a version they chose in the beginning of a project. Of course they still want to have bugfix releases, but by no means they want breakage in the API or interface or whatever applies. I've seen this happen on another project I accompanied a while ago. As soon as they put out 1.0 there only came bugfix releases afterwards, although many requests for mostly the same improvements appeared on the mailing list and the excuse always was like No we don't do that, because then we would break with the big guys. Does Monotone have the power to support two branches, so that new and needed features don't get stalled? Just a few thoughts :-) Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUCE] monotone 0.47 has been released
Am 14.03.2010 22:53, schrieb Thomas Keller: You can grab it at the usual location - binaries are posted as they come in. Sources compile fast and without problems here on Gentoo/AMD64. Migration, workspace and sync are working just fine. Thanks to all people who made this possible! I'd like to join that statement :-) That's how a week should start! Ph. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit error (Possible LUA problem)
Philipp Gröschler schrieb:
Too bad the 0.44 ebuild has fallen out of Portage a while ago, otherwise
I could just re-emerge Monotone and the error would most probably go
away.
A short update on that story:
On my laptop I manually created a 0.44 ebuild and reinstalled that
version, no effect, the error is still there.
On my workstation I updated to 0.45 (because of 0.46 not yet being in
Portage tree and me being detered by the amount of severe bug reports
from the last two weeks) and, damn it, that exact same error is now
appearing here on a completely different branch.
Here's the message again:
mtn: beginning commit on branch '###'
mtn: warning: [string std hooks]:33: bad argument #1 to 'unpack' (table
expected, got nil)
mtn: misuse: edit of log message failed
In the meantime I reinstalled all dependencies, tried with a freshly
pulled database, no change. I traced all files opened by mtn during the
commit process, and the only existing LUA script which gets opened is
/etc/monotone/hooks.lua whose sole contents are:
include(get_confdir() .. /passphrase.lua)
When I delete this file, no change.
The trace before the error occurs is:
mtn: beginning commit on branch '##'
stat(_MTN/log, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat(_MTN/log, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(_MTN/log, O_RDONLY) = 4
open(/tmp/mtn.VGM90G, O_RDWR|O_CREAT|O_EXCL, 0600) = 4
open(/tmp/mtn.VGM90G, O_RDWR) = 4
--- SIGCHLD (Child exited) @ 0 (0) ---
mtn: warning: [string std hooks]:33: bad argument #1 to 'unpack' (table
expected, got nil)
mtn: misuse: edit of log message failed
Same situation as on the laptop, it crashes after opening the temporary
file which should be passed to vi for editing the commit message.
These are the versions of the installed dependencies:
dev-libs/libpcre-7.9-r1
dev-libs/botan-1.8.8
dev-db/sqlite-3.6.20-r1
dev-lang/lua-5.1.4-r4
net-dns/libidn-1.15
dev-libs/boost-1.35.0-r5
No more ideas here. And my workstation is also broken now, which is ...
not good.
Greetings,
Philipp
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit error (Possible LUA problem)
Ahh, we're getting closer. Let's see ...
Stephen Leake schrieb:
What are OS are you on, and what language settings?
Gentoo Linux on all machines, here on the workstation specifically:
Linux 2.6.31-gentoo-r6 #1 SMP PREEMPT x86_64
Language setting is german, but Monotone was compiled without NLS.
So it looks like the path to the executable is nil (should be 'vi', in
this case). That is in turn specified by the environment variables
VISUAL and EDITOR (see std_hooks edit_comment). If
those env variables are null, it searches PATH for executables named
'editor' and 'vi'.
EDITOR is set to /usr/bin/vim as it should be, but VISUAL does not exist.
Thomas Keller schrieb:
I can only guess here, but I'd propose you load a custom rc file which
contains the current std_hooks.lua contents and debug your way through
until you see the problem.
The strace should uncover those, right? I didn't create any custom hook
scripts, except our server, were everything works just fine. This is by
the way the only machine in our network which didn't get heavily updated
in the last month. As I stated before, I have been installing KDE4 and
my guess is, that this might have caused this situation.
I attached a text file with the (nearly complete) trace. (Only the
workspace files and some paths have been omitted)
Philipp, try to open lua from command line and enter
function foo(...) return unpack(arg) end
= foo(1,2,3)
Do you see
1 2 3
as output then? If yes, then its not a lua problem.
No, in fact I see this:
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
function foo(...) return unpack(arg) end
= foo(1,2,3)
stdin:1: bad argument #1 to 'unpack' (table expected, got nil)
stack traceback:
[C]: in function 'unpack'
stdin:1: in function stdin:1
(tail call): ?
[C]: ?
I guess we have some clue now :-)
execve(/usr/bin/mtn, [mtn, ci], [/* 69 vars */]) = 0
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
open(/lib/libpcre.so.0, O_RDONLY) = 3
open(/usr/lib/libbotan-1.8.2.so, O_RDONLY) = 3
open(/usr/lib/liblua.so.5, O_RDONLY) = 3
open(/usr/lib/libsqlite3.so.0, O_RDONLY) = 3
open(/usr/lib/libidn.so.11, O_RDONLY) = 3
open(/lib/libz.so.1, O_RDONLY)= 3
open(/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6, O_RDONLY) = 3
open(/lib/libm.so.6, O_RDONLY)= 3
open(/lib/libgcc_s.so.1, O_RDONLY)= 3
open(/lib/libc.so.6, O_RDONLY)= 3
open(/lib/libpthread.so.0, O_RDONLY) = 3
open(/lib/libbz2.so.1, O_RDONLY) = 3
open(/usr/lib/libcrypto.so.0.9.8, O_RDONLY) = 3
open(/lib/librt.so.1, O_RDONLY) = 3
open(/lib/libdl.so.2, O_RDONLY) = 3
open(/usr/lib64/locale/locale-archive, O_RDONLY) = 3
open(/usr/lib64/gconv/gconv-modules.cache, O_RDONLY) = 3
getcwd(/, 4096) = 59
stat(//_MTN, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
stat(//_MTN, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=696, ...}) = 0
chdir(/) = 0
stat(//.monotone/monotonerc, 0x7455c580) = -1 ENOENT (No such file or
directory)
stat(_MTN/monotonerc, 0x7455c580) = -1 ENOENT (No such file or directory)
stat(_MTN/format, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
stat(_MTN/format, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
open(_MTN/format, O_RDONLY) = 3
stat(_MTN/options, {st_mode=S_IFREG|0644, st_size=162, ...}) = 0
open(_MTN/options, O_RDONLY) = 3
stat(_MTN/options, {st_mode=S_IFREG|0644, st_size=162, ...}) = 0
stat(_MTN/options, {st_mode=S_IFREG|0644, st_size=162, ...}) = 0
open(_MTN/options, O_RDONLY) = 3
stat(//Develop/Test.mtn, {st_mode=S_IFREG|0644, st_size=573440, ...}) = 0
stat(//.monotone/keys, {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
stat(_MTN, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
stat(_MTN/options, {st_mode=S_IFREG|0644, st_size=162, ...}) = 0
stat(_MTN, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
open(_MTN/mt5z7qi7.tmp, O_RDWR|O_CREAT|O_EXCL, 0666) = 3
rename(_MTN/mt5z7qi7.tmp, _MTN/options) = 0
stat(_MTN/revision, {st_mode=S_IFREG|0644, st_size=133, ...}) = 0
open(_MTN/revision, O_RDONLY) = 3
stat(//Develop/Test.mtn, {st_mode=S_IFREG|0644, st_size=573440, ...}) = 0
stat(//Develop/Test.mtn, {st_mode=S_IFREG|0644, st_size=573440, ...}) = 0
open(//Develop/Test.mtn, O_RDWR|O_CREAT, 0644) = 3
access(//Develop/Test.mtn-journal, F_OK) = -1 ENOENT (No such file or
directory)
access(//Develop/Test.mtn-journal, F_OK) = -1 ENOENT (No such file or
directory)
access(//Develop/Test.mtn-journal, F_OK) = -1 ENOENT (No such file or
directory)
access(//Develop/Test.mtn-journal, F_OK) = -1 ENOENT (No such file or
directory)
Re: [Monotone-devel] Commit error (Possible LUA problem)
Thomas Keller schrieb: This line leads me to the execute() function, apparently it is called with no arguments in place from somewhere. Do you happen to have a custom, not working edit_comment hook lingering around anywhere? Not sure about that. I know that there is no custom LUA script in ~/.monotone, only the key directory. It could be that in the whole system upgrading process some shared LUA script (if there is any at all) was modified, though I doubt that. Too bad the 0.44 ebuild has fallen out of Portage a while ago, otherwise I could just re-emerge Monotone and the error would most probably go away. Seems to be time for an update, finally ;-) Anyway, thanks! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Commit error (Possible LUA problem)
Hello! Recently on my laptop Monotone startet throwing errors when trying to commit. They look like: mtn: beginning commit on branch '###' mtn: warning: [string std hooks]:33: bad argument #1 to 'unpack' (table expected, got nil) mtn: misuse: edit of log message failed No, that is not the real branch name. You might have guessed that already ;-) Version of Monotone ist still 0.44 throughout our network. I didn't have the nerve to upgrade yet, the first try bothered me with the demand of a lot of manual labour, so I repelled that for quite a while. Recent changes on that particular machine include an upgrade to KDE 4 and in course of that a recompilation or upgrade of many other packages. Other mtn commands like sync or status work perfectly. Any ideas? Thanks, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Timothy Brownawell: Before that, there's moving to SSL. This is case (2), so we could try to add negotiation now to support it. Or we could make it possible for one server to serve both SSL and non-SSL at the same time on different ports, and not risk mucking up the nice encryption properties. Would it be possible to serve both variations on the same network port? I don't know netsync and how it does handshaking (if at all). But as I learned not long ago, for example SMTP uses plain and also SSL encrypted connections over the same port. Both end points negotiate about their capabilities and at some point one of them says starttls and the encryption handshake begins. Could be that most of the connection handling code would have to be rewritten to offer this feature. But everytime I read let's use another port the word firewall comes to my mind. Just my little thoughts... Greetings, Philipp 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] [ANN] monotone 0.43 released
Jack Lloyd schrieb: I've submitted an ebuild for 0.43 at http://bugs.gentoo.org/show_bug.cgi?id=263626 It works for me, anyway. Perfect, thanks! Let's see when it will hit den official portage tree. I downloaded the ebuild file and will test it here during the next days. But previously I'll have to read all the Changelogs, the network here still is on 0.39. Which makes me wonder, but ... Two questions: - Why did you mark it unstable? - Who is currently maintaining the Monotone ebuilds on Gentoo and should we perhaps do this ourselves? It's unfortunately quite common in Gentoo that packages with a smaller user group have a very long delay between their updates and often lack a few versions. Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANN] monotone 0.43 released
Thomas Keller schrieb: A new version was released today with these changes: That's good news! I hope Gentoo's ebuild will catch up soon, we're still creeping on 0.40 here ... Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Documentation Texinfo XML to Wiki converter
Thomas Keller schrieb: The whole xslt thing is basically a test balloon how well we can convert the current texinfo source to wiki markup and if this works out well if we use this instead of plain HTML files for the website (or even switch completly to a wiki manual, if people agree). The reason for this step is because makeinfo is rather limited when it comes to HTML output, you cannot rearrange things or add certain needed header / footer parts easily to it, _but_ there is an XML output available which theoretically could be transformed to anything we want. And exactly this is Philipp's work. Thanks for clearing this out ;-) My last mail wasn't really what one would call creative or informational. Again, if there are questions, please first take a look at the README file in the branch I committed. There I tried to sum up my intentions. Well, at least the important ones. Zack Weinberg schrob: What is *your* vision for this thing? I don't really understand what you have in mind so it's hard for me to evaluate. I think we would prefer to keep the master copy of the manual as part of the main sources rather than opening it up to wiki-based editing, but that doesn't mean support for more different rendering formats is uninteresting -- far from it. My vision is to get involved in the project in a way that I can help within my limited spare time/abilities. The current state of the package is very experimental, just to show a way how it *could* be done. Besides the possibility of completely switching over from the Techinfo Manual to Wiki at some day, I rather thought of a continous one-way process. The documentation would still be maintained with Techinfo and new versions would be converted to Wiki format. The respective resulting parts of the Wiki should then be read only to prevent concurrent modifications which could not easily be brought back into the Techinfo part. But that is not my decision. I wanted to show a way how it could be done, and if there's reasonable demand then I will keep working on it. So much for the vision part ;-) Daniel Carosone schrieb: The great thing about this work is it (begins to) breaks the coupling between purpose and style, which means content can be used for multiple purposes regardless of style, in turn meaning that unification doesn't get confused with markup conversion. So, really, yay, and yay again. I carefully consider this as a positive response ;-) Yes, XSLT is a nice way to break the border between plain markup and presentation. I learned to use it about five years ago and I was astounded by its possibilities. For quite a while I used it for a self written XML-based servlet engine. But besides the magic one could do with XSLT there are also a lot of limitations. The way a stylesheet works and is processed could drive you easily into madness. At least it has done so a few times with me. And some things just do not work. Example: I wanted to give the user the possibility to choose the output format converter at runtime. The first intended way was to get a command line parameter into a XSLT variable, which then contains the complete file name of the converter stylesheet and then use this variable with an include instruction. So to speak, for dynamically chosing the included converter stylesheet. That one went wrong. XSLT stylesheets are first compiled completely and then interpreted. There's no way for such dynamic and runtime dependent behaviour without external programed logic. Ah, so much text. I think I should stop here. Greetings! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Documentation Texinfo XML to Wiki converter
Philipp Gröschler schrieb: In the course of the current Mini Summit I spent the afternoon hacking on a (yet still) small XSLT file whose purpose will be the conversion of Monotone's Texinfo Documentation to a set of multiple files which can be used for the Wiki. I just committed the first release of this thing, in a very *pre-alpha* state. But better than nothing ;-) For further informations please check out nvm.plasma.doc-wiki-xslt and have a look the documentation provided there. Please let me know your suggestions and if this thing could have a real purpose by someday. Just so that I can keep working on it - or not. Greetings, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: bug in monotone / January Mini Summit
Lapo Luchini schrieb: Just pull the branch net.venge.monotone.web and edit files under /wiki/, when you push the changes to monotone.ca, the wiki will automatically update. Anonymous write access? If noone objects then I could test the TechinfoML - Wiki converter this way. As long as these parts don't get linked from somewhere, nobody should find them I guess. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Documentation Texinfo XML to Wiki converter
In the course of the current Mini Summit I spent the afternoon hacking on a (yet still) small XSLT file whose purpose will be the conversion of Monotone's Texinfo Documentation to a set of multiple files which can be used for the Wiki. Unfortunately I have to use a rather new Java based version of Saxon [1] for the transformation process, because neither Gnome's libxml nor Apache Xalan where able to process a XSLT 2.0 template, which is needed for the file splitting and some regular expression stuff. XSLT 1.0 and 1.1 do not have these features AFAIK, or only as vendor specific extensions, which doesn't help either. The current state is that the XSLT searches the whole Texinfo XML file, collects the node hierarchy and therefrom builds up a directory structure with one file for each node (or rather: chapter). Next task would be to take each chapter's XML code and transform it to the desired output format. Currently I have the choice between HTML and the Wiki's own MDWN format, with the possibility to implement both and allow the user to chose between the two before the actual transformation. The number of target formats is not limited and is only depending on how many of them will be needed and, after all, how many complete and working style transformation templates will be created. So the question at the moment is: which output format would be the most useful? According to Thomas Keller there could be some formatting limitations in the Wiki format, but due to lacking experience with that format I can't affirm that. What I can say is that HTML can surely cope with almost everything, but would likely be more time consuming to implement. Also it could be more reasonable to directly create files for the Wiki, since HTML can already be created by makeinfo, though lacking Monotone's Wiki style. That's it for the moment! Greetings, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: January Mini Summit (Jan 17th and 18th)
Lapo Luchini schrieb: Method of meeting… IRC, I guess? Wiki says so. (if we're too few people Skype-conference might be easier, as it leaves hands free for writing code…) But IRC could be logged and sometimes people might want to leave their desk for a short time. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug in monotone / January Mini Summit
Markus Wanner schrieb: Let's at least say: we should try to improve the error message. Do we have some sort of TODO file or something? Or is this a summit'09 task: to organize todo items? With a little help from outside, I think I could at least try to do some work here. That weekend is already booked in my calendar. Therefore, two (possibly stupid) questions: - Is there some kind of search function in the new wiki? - How do I make changes? I already guessed that the wiki files are edited directly and then checked in, so, how do I sign up? And, of course: - Will hell also freeze over if the weather stays like this? Okay, the last one was indeed stupid. Sorry, it's the evening ;-) Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner schrieb: Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. I'm using these USE flags in /etc/make.conf: # manually prevent unneeded stuff USE=-kde -qt3 -qt4 -gtk -gnome -nls ... (as long as I don't manually give --disable-nls). So I'm guessing my glibc is still compiled with nls. How do I check? Gentoo's sys-libs/glibc is resistant to many use flags, I am still trying to guess where this could be overridden. Recently I tried to compile it with hardened use flag, which wouldn't suceed until setting the portage profile to a hardened one. Seems like the system is protecting the user from messing around with the core libraries and the toolchain. Another flag which seems to be overridden is nls so it could definitely be that your glibc build still includes that. Just try # emerge --info and take a look at the listing of active useflags somewhere at the bottom of the output. If you have app-portage/gentoolkit installed, try # equery uses sys-libs/glibc to see which use flags apply to your current glibc build. Greetings! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner schrieb: How do I build the glibc *without* it? Does the following help? # USE=-nls emerge glibc You can check with # USE=-nls emerge -av glibc so that portage prints out what it would do. If it accepts the use flag, the output should look like These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-libs/glibc-2.6.1 USE=gd (multilib) -debug (-hardened) -nls* (-selinux) Would you like to merge these packages? [Yes/No] Use flags in parentheses are overrided by the system profile. The asterisk behind -nls shows the difference to the currently installed version. My profile is default/linux/amd64/2008.0/desktop. If NLS still would be compiled in, try # eselect profile list and chose hardened/linux/x86 (or whatever architecture is appropriate). Not 100% sure if that helps, but on when I tried this on my virtual box a few days ago, NLS was disabled globally. Disabling it for only the glibc could get you into serious trouble, I guess. Sometimes Gentoo is a little bit goatish ;-) Good luck! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Thomas Moschny schrob: You could enhance/revive/polish/hack on the eclipse monotone plugin, if you like. That also was my idea back then. I had contact with a guy who wanted to cede his old codebase to me. In spite of some mails to him I never heard of him again. Let's see what the new year brings. Currently I would like to have 30 hours per day to get all my projects finished until christmas. It always appears so suprisingly, just like every year ... Great idea. I also think we need some kind of guide to monotone development (which we may already have). This guide would contain descriptions of the macros we use and the principles that monotone is developed by. Well, that would be very nice! ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Thomas Keller schrob: What I'd like to see even more than another list of wanted features are a couple of people who put their names here on the list or on this wiki page saying yes, I want to _work_ on this topic and I think I _can_ do it! As for the topics which I posted a few days ago, yes I would do some work on these topics if only I had a glimpse on C++ ;-) This is also the reason for which I didn't attend the Wuppertal summit this summer. I announced some kind of Java project on the mailing list and got a few messages on that, but no further responses on application. Concerning all other topics around C++ and Lua, I don't think I can be of any constructive help, unfortunately. Greetings, anyhow Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Matthew A. Nicholson wrote: Please add your ideas to this list. * Concurrent access to a single Monotone database This has been discussed a few times, I'm not sure if a solution has already come up. A few ideas on this topic have been floating around for a while. As far as I'm concerned, I'd like to have one database file to which I sync from my workstation or laptop, and have another process (viewmtn or a self written PHP equivalent) accessing that database at the same time. Maybe for this specific problem there could be other solutions (besides mtn automate) than concurrently accessing the repository on the database/sqlite level. * Integrating a 'branch rename' command Currently I have a shell script available which was posted on the Monotone Wiki some time ago. With future changes to monotone it maybe uncertain how long that script will keep working. Next point is, one does always need to have that script available, since renamings must happen on all affected locations. Therefore, and as I have to use branch renaming quite often, it would be nice if that function could be integrated into the mtn binary. Just my two ideas :-) Greetings, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn:// sync
Ulf Ochsenfahrt schrieb: I've just found out that the semicolon ';' is also an acceptable parameter separator, according to the HTML 4 spec. See here: http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2 The Semikolon also works as command separator on various unix shells. A URL would then have to be enclosed in quotation marks. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Markus Schiltknecht schrob: Hm.. I see. But.. looking at the command line only, we could use whatever URL we want. We wouldn't have to use a URL at all. From a CLI users point of view, I'd even favor the current syntax for netsync. So what do you want a mtn:// url at all? I just began to think alot about the feature when Timothy started the discussion on the mtn:// sync thread a few days ago. As it is with new features, they are likely to replace old behavior (though it is clear that the old syntax will be kept long enough to ensure backwards compatibility). Since I am rather new into actually using monotone (and not only following its development progress) I wanted to adopt the new possibilities correctly. The old syntax is working for me as well, but learning only one (newer) syntax to the full could save valuable brain capacity. Allright. So far. *cough* Being able to use the same URL for the web interface, for monotone and for clever as well as dumb servers seems much more important to me, than sticking to ? as a separator for no reason, except simplicity of coding it. Or put it another way: why should /branch/ not be a better and more descriptive separator? This is true of course, as long as there will always be only one specific /keyword/ between the host name and the rest of the path. And this even only for the argument of human readbility. When it comes to simplicity, I personally would prefer that in the matter of usability over coding complexity. Not every programmer has that attitude, which is why we have lots of ugly user interfaces out there. But if I got you right (at least this time) then we seem to share that opinion. But probably I'm just too focused on nuskool, having URLs like these in mind: http://www.xyz.org/revision/d558f906d0d597ac7ac01f891fe46f994dc0946c https://www.xyz.org/file/a5a5ce3a1ed7c9dead79c526e382237697d54c04 maybe even: ftp://www.xyz.org/branch/net.venge.monotone/botan/sha160.cpp Any kind of separator other than '/' would just be disturbing there. Or do you really expect people to remember where to put the '?', before or after the 'branch' or 'revision'. The more I look at this notation, the more I like it. Don't know what I had on mind when I started arguing for question marks and that other stuff. Let's forget about that! I full heartedly agree. But I fail to see how multiple separators and intuition fit together. ;-) Here again we're in the area of personal taste. As I do a lot of coding on web applications, I often think alot about how to hide the structure of a particular app. The common user really does not care much about how URLs look like, you're right, but some folks do. But that is going too far by now, and I don't want to earn the Offtopic Award in my first active week on the list ;-) To become more technical again: when in some distant future these URL features become available, would it then be possible for just any application to connect to a running 'mtn serve' process via network, issue one or more HTTP requests and get the relevant answers, without the need for this application to speak netsync? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Personal/Project/MtnSummit Introduction
Greetings! The subject is 'Introduction' and after crashing into the mailing list a few days ago I think that wouldn't hurt. **Personal** I have been following the list and the development of monotone for a few months now, and since the beginning of this year, me and a colleague are using monotone actively, mainly for concurrent development, storing source codes, project workspaces and the like. In the past I have been using CVS and was often disappointed at its missing features and circumstantial administration. After comparing a few version control systems and relatively early considering monotone, I was impressed by its ease of use, setup and the modern approaches. **Project** After not having even the slightest clue of Python and a very long night of unsuccessfully muddling around with Lighttpd, Apache and various plugins for getting ViewMTN running, I thought that a small viewing application based on PHP couldn't be that much of a problem. That thought lasted exactly to the point at which I had to understand the database structure of monotone, which I obviously didn't. The recent discussions on the new URL features have made it rather exciting for me to follow the further development, since that one would be of great help for reaching the goals of my little project rather early. And also without messing around directly with the database, thus avoiding problems like locking. Perhaps such a project isn't even desired because ViewMTN is considered to be enough of a web viewer. But if it is, maybe the work on this could be brought forward on the summit, which leads us to the next chapter: **MtnSummit** I had a little chat with Thomas Keller, wiping out my last doubts about the summit in Wuppertal, and now I am looking forward to meeting some of the people behind this great project and possibly learning more about it, mostly the advanced ranges of application. Maybe you have already seen my note in the Wiki. For your information: most of my time I am coding with Java or PHP, so the parts where I can help seem to be the Eclipse plugin, my own web viewer (if that one is welcome, see above) or the more general areas like documentation etc. Just to let you know in advance. That's about it! Now I could use a snack ;-) I am staying on IRC this evening, so if there are questions or suggestions, feel free to contact me. Last remark, since I am not a native speaker, it could take some time to get an answer from me. Now a snack, really! Best wishes, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Markus Schiltknecht: As another, minor point, IMO the second is also easier to read and understand. A good (but admittedly deprecated) example might be: http://venge.net/net.venge.monotone Looks quite confusing to me, where as: http://venge.net/branch/net.venge.monotone Makes the thing easier to understand. Especially for starters, I think. Timothy Brownawell: There needs to be a clear separation between the db path and any parameters. http://host/path/to/app/followed/by/parameters can work for web apps because all processing of the URL happens on the server, which already knows do discard /path/to/app when looking for parameters. We can't do that, because the netsync client also needs to know the parameters. Have it look like http://venge.net/branch?net.venge.monotone and the parsing on client side should be fine. To stay with the widely known URL scheme, a '' character would be needed for the addition of further parameters. As this would be a problem for CLI use, just encapsulate the URL in quotation marks. BASH and (T)CSH work fine with this, I just tested that. Try on your konsole if echo http://www.xyz.org?abcefg=1234; is working, while echo http://www.xyz.org?abc!efg; should result in error. I think the approach of only using slashes in the path of an URL is mostly used to obscur the structure of a web application. It makes it not very easy for the user to tell at which point there is code envolved (servlets, etc) or where there is a relative filesystem path, or whatever other resource you can guess of. But I am straying from the point. If I correctly understood the recent discussion, my example above would imply the use of 'exclude' and 'include' parameters rather than using special characters. Anyway, the resulting URL would therefore be much longer to type, but as the reasoning for 'beginners' has already come up, a longer and also more verbose URL would be much better to understand. There would be less irritation (Okay, I just want to do xyz, but how? Let's try if [] works. Hmm, doesn't) and the scheme would be easier to learn, because known practices (HTTP, ...) could be applied. Last week I had serious doubts in my senses, when some java RMI stuff I coded just wasn't getting to work. I tried a lot of examples, copied them 100% and followed each step accurately, but it didn't work. The reason was, the URL for the java.rmi.server.codebase was missing a trailing slash. Nowhere in any article I read was a single clue on this necessity. The enlightenment came late at night while reading some FAQ article which had been stuffed in the rearmost corner of the Sun website. So much for my story of beginners trouble with URLs. Please just don't let it happen with monotone ;-) I'm almost sure I forgot something to write down here, but the text is already sufficiently vast. Happy Easter! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtn:// sync
mtn sy monotone.ca nvm* --exclude nvm.experiment* would become mtn sy mtn://monotone.ca?nvm*!nvm.experiment* When will this change become available? Since I am currently only building monotone from the release source packages, I guess it will be in 0.40. Please correct me there. But I'd like to drop myself an note for remembering the new command syntax before blaming my machines in a few weeks, when 'suddenly' the old commands don't work anymore ;-) Another thing on this issue, are the documentations updated closely? Thanks, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
