Re: monotone on windows
On 2022-03-18 15:57, Hendrik Boom wrote: What does one do to use monotone on windows? Personally, I use it under WSL nowadays (Windows Services for Linux). I have managed to create a working executable for Ubuntu 20, while I'm currently failing to do the same on Ubuntu 22. A lot of headers need to be moved around to avoid a conflict on a E() macro, as done in this Fedora port patches: https://src.fedoraproject.org/rpms/monotone/tree/main But I still fail with this error: In file included from src/database.cc:68: src/vocab_hash.hh:43:21: error: type/value mismatch at argument 1 in template parameter list for ‘template struct std::hash’ 43 | struct hash \ | ^ src/vocab_hash.hh:64:29: note: in expansion of macro ‘ATOMIC’ 64 | #define ATOMIC_NOVERIFY(ty) ATOMIC(ty) | ^~ src/vocab_terms.hh:19:1: note: in expansion of macro ‘ATOMIC_NOVERIFY’ 19 | ATOMIC_NOVERIFY(data);// meaningless blob | ^~~ src/vocab_hash.hh:43:21: note: expected a type, got ‘std::data’ 43 | struct hash \ | ^ -- Lapo Luchini l...@lapo.it
monotone on windows
What does one do to use monotone on windows? I'm on Linux and have been using monotone for ages. I am considering a colaborationwith a windows user. We'd like to be synchronising text files between us. She is not a computer programmer; I'd probably have to set it up on her machine for her, and *I* don't know how Windows works these days. The last time I used Windows as in the days of XP. -- hendrik
[Monotone-devel] bug report - running Monotone under Windows XP fails if user account path has non-ascii characters
Hello, I tried to run monotone (0.41 and 0.42) under a second Windows machine (my first had an English Windows XP install and everything worked). One of the bugs I found is already registered at the bug list, but I could not find a bug report for the other one. The first error message appears when I try to run mtn from the C: (root) and my userdir has non-ascii characters on the path (like C:\Documents and Settings\João\My Documents): --- C:\Windows\System32mtn mtn: error: failed to convert string from UTF-8 to ASCII: 'C:/Documents and Sett ings/JoÒo/Dados de aplicativos/monotone/dump' (note that the ã character appears as Ò here) --- Then I tried changing to other logical partition and running it again: --- C:\Windows\System32d: D:\mtn ?: fatal: std::logic_error: ../monotone-0.41/paths.cc:303: invariant 'I(!is_abso lute_here(inT))' violated ?: this is almost certainly a bug in monotone. ?: please send this error message, the output of '? version --full', ?: and a description of what you were doing to monotone-de...@nongnu.org. ?: discarding debug log, because I have nowhere to write it ?: (maybe you want --debug or --dump?) D:\mtn version --full ?: fatal: std::logic_error: ../monotone-0.41/paths.cc:303: invariant 'I(!is_abso lute_here(inT))' violated ?: this is almost certainly a bug in monotone. ?: please send this error message, the output of '? version --full', ?: and a description of what you were doing to monotone-de...@nongnu.org. ?: discarding debug log, because I have nowhere to write it ?: (maybe you want --debug or --dump?) --- The error messages running 0.42 are the same. If I try to use a username without special characters on it, everything works as expected. I am wishing to help debugging this issue. If any other information is needed, please ask me and I will submit it. -- João ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug report - running Monotone under Windows XP fails if user account path has non-ascii characters
On Wed, Feb 11, 2009 at 5:39 AM, João Felipe Santos joao@gmail.com wrote: C:\Windows\System32mtn mtn: error: failed to convert string from UTF-8 to ASCII: 'C:/Documents and Sett ings/JoÒo/Dados de aplicativos/monotone/dump' (note that the ã character appears as Ò here) This is a known and fairly well-understood bug that nobody has gotten around to fixing; if you have time to do it we would welcome patches. The problem is that monotone blindly assumes pathnames returned from various system functions (getcwd, FindFirst/FindNext, etc) are already in UTF-8, which is almost always wrong. If you were willing to patch this, what you would need to do is go through win32/fs.cc and change everything that talks to the system to use the Unicode-aware Win32 APIs (the *W functions) and then call the appropriate charset.hh functions to convert what you get from that into UTF-8. (You might also have to add the necessary conversion functions -- i'm not sure we currently have anything that understands WCHAR_T or whatever it is Windows calls the type of those strings.) (It's actually easier to get this right on Windows than on Unix because Windows enforces a consistent encoding for pathnames - we're just not paying attention. On Unix (other than Mac) pathnames are arbitrary byte vectors; one can *hope* that they are strings in the user's locale's encoding but one may very well be wrong.) D:\mtn version --full ?: fatal: std::logic_error: ../monotone-0.41/paths.cc:303: invariant 'I(!is_abso lute_here(inT))' violated ?: this is almost certainly a bug in monotone. ?: please send this error message, the output of '? version --full', ?: and a description of what you were doing to monotone-de...@nongnu.org. ?: discarding debug log, because I have nowhere to write it ?: (maybe you want --debug or --dump?) Now that's just bizarre. Could you try D:\mtn version --debug and post the *complete* output? thanks, zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug report - running Monotone under Windows XP fails if user account path has non-ascii characters
On Wed, Feb 11, 2009 at 2:48 PM, Zack Weinberg za...@panix.com wrote: On Wed, Feb 11, 2009 at 5:39 AM, João Felipe Santos joao@gmail.com wrote: This is a known and fairly well-understood bug that nobody has gotten around to fixing; if you have time to do it we would welcome patches. The problem is that monotone blindly assumes pathnames returned from various system functions (getcwd, FindFirst/FindNext, etc) are already in UTF-8, which is almost always wrong. [snip] D:\mtn version --full ?: fatal: std::logic_error: ../monotone-0.41/paths.cc:303: invariant 'I(!is_abso lute_here(inT))' violated ?: this is almost certainly a bug in monotone. ?: please send this error message, the output of '? version --full', ?: and a description of what you were doing to monotone-de...@nongnu.org. ?: discarding debug log, because I have nowhere to write it ?: (maybe you want --debug or --dump?) Now that's just bizarre. Could you try D:\mtn version --debug and post the *complete* output? thanks, zw I'll have a look at the code related to the first bug and see if I can figure something out to solve this trouble. About the second one, the complete output follows here [1]. I had to run it under C:\ because I got the same std::logic_error message on paths.cc:303 when tried to run under D:\. Do not know if it will have the debug info you need because of it. Hope it helps -- João [1] http://codepad.org/jWAETxlI ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug report - running Monotone under Windows XP fails if user account path has non-ascii characters
On Wed, Feb 11, 2009 at 9:03 AM, João Felipe Santos joao@gmail.com wrote: I'll have a look at the code related to the first bug and see if I can figure something out to solve this trouble. Much appreciated. The most relevant files are going to be win32/fs.cc, charset.cc, file_io.cc, and paths.cc. Please try to keep Windows-specific code in the win32 directory. About the second one, the complete output follows here [1]. I had to run it under C:\ because I got the same std::logic_error message on paths.cc:303 when tried to run under D:\. Do not know if it will have the debug info you need because of it. I actually wanted to see the --debug output when run under D:\. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug report - running Monotone under Windows XP fails if user account path has non-ascii characters
On Wed, Feb 11, 2009 at 3:48 PM, Zack Weinberg za...@panix.com wrote: Much appreciated. The most relevant files are going to be win32/fs.cc, charset.cc, file_io.cc, and paths.cc. Please try to keep Windows-specific code in the win32 directory. I actually wanted to see the --debug output when run under D:\. zw Just to clarify: the output when run under D:\ is: D:\mtn version --debug ?: fatal: std::logic_error: paths.cc:304: invariant 'I(!is_absolute_here(inT))' violated ?: this is almost certainly a bug in monotone. ?: please send this error message, the output of '? version --full', ?: and a description of what you were doing to monotone-de...@nongnu.org. ?: discarding debug log, because I have nowhere to write it ?: (maybe you want --debug or --dump?) The same thing that happens when I try to execute any command (or even just mtn) under D:\. Maybe it is a bug related with the normalize_path function, or maybe it has something to do with my non-ascii userdir. I'm familiarizing myself with the win32/ code and will try something later to check this other bug too. -- João ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [windows] locale problems
Le jeudi 14 février 2008 à 23:25 +0100, Thomas Keller a écrit : Benoît Dejean schrieb: Hello everyone, I experience some locale issues on windows with 0.38 (same problem for some times). Locale/encoding is wrong. Language is french, but the monotone messages show all accentuated characters wrong. It's weird because for example, (révision de base) is output as (rÚvision de base) where: - é is ISO8859-1 0xE9 or U+00E9 - Ú is ISO8859-1 0xDA or U+00DA I can't recall in which version this problem appeared. Which package do you use? The native binary or the cygwin package? Maybe one of the packager(s) knows whats wrong here... The native binary. Second issue, i can't import any file with non-ascii characters it, it fails with std::logic_error at paths.cc:411. And this makes me wonder: when i import non-ascii filenames, how are they stored ? if i checkout on a linux box with an UTF-8 locale, will the filenames be transcoded ? monotone uses an internal normalized utf8 format for paths, however the conversions from/to the various external character sets is what most likely make problems (and throws out the logic error above), just because its not really there (tm) yet. So you're safe if everything uses utf8 around you - otherwise you're pretty much on your own for now. I see the same problem when commiting. Notepad is started, but ci fails whenever i have entered non-ascii chars. Anyway, today i've quitted my current job, so i won't use windows anymore. But, I've been really happy with monotone on windows. I don't know if there are GUI tools for monotone on windows, but the CLI is simple enough. - the native version works fine, the installer is nice - windows behaves very badly with hundreds of files, so having everything packed in a one file DB was great. - netsync linux - windows works fine. -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [windows] locale problems
Benoît Dejean schrieb: Hello everyone, I experience some locale issues on windows with 0.38 (same problem for some times). Locale/encoding is wrong. Language is french, but the monotone messages show all accentuated characters wrong. It's weird because for example, (révision de base) is output as (rÚvision de base) where: - é is ISO8859-1 0xE9 or U+00E9 - Ú is ISO8859-1 0xDA or U+00DA I can't recall in which version this problem appeared. Which package do you use? The native binary or the cygwin package? Maybe one of the packager(s) knows whats wrong here... Second issue, i can't import any file with non-ascii characters it, it fails with std::logic_error at paths.cc:411. And this makes me wonder: when i import non-ascii filenames, how are they stored ? if i checkout on a linux box with an UTF-8 locale, will the filenames be transcoded ? monotone uses an internal normalized utf8 format for paths, however the conversions from/to the various external character sets is what most likely make problems (and throws out the logic error above), just because its not really there (tm) yet. So you're safe if everything uses utf8 around you - otherwise you're pretty much on your own for now. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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] Windows version 0.36
On Thu, Aug 23, 2007 at 02:03:07PM -0700, J Decker wrote: I recently updated to this. I occasionally serve my database so i can pull/push to my virtual machines on the same system. The current version (0.35 did not do this) ends up leaving the database locked after the client connects to sync.(I cannot just use the database anymore without closing the serving process) This is intentional; the behavior you want has never worked properly anyway. Maybe you would find it more convenient to just use mtn's ssh:// sync support? That would both avoid this problem and seem easier to do in general... -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Windows version 0.36
I recently updated to this. I occasionally serve my database so i can pull/push to my virtual machines on the same system. The current version ( 0.35 did not do this) ends up leaving the database locked after the client connects to sync.(I cannot just use the database anymore without closing the serving process) Jim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Windows build slaves desired
Richard Levitte [EMAIL PROTECTED] writes: Does that mean that the Windows crowd is uninterested in monotone? No! I'm planning on using monotone on Windows/MinGW as a replacement for CVS, for real work. I'd also like to port monotone to Lynx. I got it to compile, but the tests totally fail. It seems to be a compiler/OS bug; I'm waiting for the next Lynx major release to try again (Lynx is way behind the rest of the world in C++; it's great for real-time and Ada though, which is why I use it). I can run a build slave on a Windows box. Since others are also doing that, I'll wait until the wiki is updated. On the other hand, is there such a thing as too many slaves? On a slightly related topic, is there any way to pay for support for monotone? I'm aware of your plea for sponsorship, and I'll do that at some point, but an actual support contract would be better. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Windows build slaves desired
I'd be happy to setup a windows slave when I return to work. It'll be at least a week before that happens. I don't use monotone on Windows, but have access to the resources to run a slave on a spare workstation. Thanks -Ben On 7/12/07, Richard Levitte [EMAIL PROTECTED] wrote: Hello, Since I announced the buildbot on monotone.ca, there's been a few volunteers on the Unixly side of the industry that jumped in. However, not a word from any other major platform, such as Windows. Does that mean that the Windows crowd is uninterested in monotone? Shall we simply not care any more at all, making monotone a Unix- only piece of software? Personally, I'd find it quite sad if it went that way, there's been quite a bit of work done to make monotone work on Windows as well, and I'd hate to see that work just rot away. I do recall that there was at least one Windows build slave with the buildbot on venge.net. Who administrateed it? Are you still around? Are you willing to have monotone.ca as build master? Remember, a build slave helps a lot in making a release that works on your platform! Have I done enough guilt tripping? ;-) Anyway, I hope to see one or two Windows slaves, and if there are other major platforms (oh, how I would love to see VMS on the list, but alas, I know there's a lot of work to get monotone there), please step up! Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- --- Ben Walton [EMAIL PROTECTED] When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] compiling monotone on Windows.
I've successfully installed the MSYS tools, and I'd just like to say thank you to the maintainers of the Monotone Wiki, especially the BuildOnWindows page. It was a pleasure following such clear, detailed instructions. I have attempted to install MinGW before for other tools, but always failed; now I know why :). I did encounter two problems, and updated the Wiki to document the fixes. Which is only the second time I've updated a wiki; I'm finally getting with the Web age :). Thanks again, and I look forward to contributing to monotone. -- -- Stephe ___ Monotone-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] windows case sensitivity issues
Haven't seen anything in the archives about this specific issue. For a while, now on 0.26, we have some case sensitivity issues which causes monotone to report redundant changes. We are entirely using monotone on Windows. Here's sample output from mtn diff: # patch src/Data/Common/Person.cs # from [15ada2601e3517db164dd2e9eeaa67c798cdc760] #to [7a9412b945f51e961c7d1a51d75a4a745b5f551b] # # patch src/data/common/Person.cs # from [15ada2601e3517db164dd2e9eeaa67c798cdc760] #to [7a9412b945f51e961c7d1a51d75a4a745b5f551b] So mtn thinks the same change is being made to two different paths. Everything works fine, except that: 1) mtn log reports the same change twice 2) if a merge conflict occurs, you have to make the same merge twice If we merge and make different choices, I sort of assume that the latest choice will win, but I'm a little scared of what will happen. Or if one of the affected files gets renamed or deleted. This only happens to a small subset of our files. I don't know how this duplication got introduced in the first place. Can I fix this by dropping the files with the bad path casing? Ideas? Should I just try it out? thanks, shawn ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] windows case sensitivity issues
On 6/5/06, Shawn Samuel [EMAIL PROTECTED] wrote: Haven't seen anything in the archives about this specific issue. For a while, now on 0.26, we have some case sensitivity issues which causes monotone to report redundant changes. We are entirely using monotone on Windows. Here's sample output from mtn diff: # patch src/Data/Common/Person.cs # from [15ada2601e3517db164dd2e9eeaa67c798cdc760] #to [7a9412b945f51e961c7d1a51d75a4a745b5f551b] # # patch src/data/common/Person.cs # from [15ada2601e3517db164dd2e9eeaa67c798cdc760] #to [7a9412b945f51e961c7d1a51d75a4a745b5f551b] So mtn thinks the same change is being made to two different paths. Everything works fine, except that: 1) mtn log reports the same change twice 2) if a merge conflict occurs, you have to make the same merge twice If we merge and make different choices, I sort of assume that the latest choice will win, but I'm a little scared of what will happen. Or if one of the affected files gets renamed or deleted. This only happens to a small subset of our files. I don't know how this duplication got introduced in the first place. Can I fix this by dropping the files with the bad path casing? Ideas? Should I just try it out? My guess would be that someone used one case when adding the files and someone else used another case. Or perhaps that they were added with one case but the working copy has another case. I suggest to try dropping one of them and see if it fixes the problem, but do this on a copied DB just in case I'm completely wrong. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Windows Installer - path not modified
re: monotone-0.26-setup.exe This installer does not seem to modify PATH to include the location of the mtn.exe file and friends. Should it? Or should the docs include a note that PATH needs updating? I am trying this on a WinXP Pro SP2 machine on which I do notwork as Administrator by default. I have run monotone-0.26-setup.exe both as my normal user ID byusing Administrator via RunAs, and also by logging in as Adminstrator. In neither of these cases does the PATH environment variable get updated to reflect the mtn installation directory. Thanks for listening - DJ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] windows *cough* NT4 support?
I have the embarassing misfortune to need to use NT4 at certain sites, and would love to use monotone to avoid certain aspects of this pain as much as possible :) I tried a little while ago, and there was an issue with the windows installer for the prebuilt binaries. This was a known issue, and a new installer was made that now installs the binaries. Sadly the installed binary fails to run, with a popup gui error that says: The procedure entry point CreateToolhelp32Snapshot could not be located in the dynamic link library KERNEL32.dll. Anyone know how this might be resolved? I'm hoping its something simple, such as turning on some different flags when building. Any help appreciated. -- Dan. pgpktM1vN3Vl5.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] windows *cough* NT4 support?
At 2005-11-25T21:39:52+1100, Daniel Carosone wrote: I have the embarassing misfortune to need to use NT4 at certain sites, and would love to use monotone to avoid certain aspects of this pain as much as possible :) It'll be good to have someone testing monotone on older Windows versions--I only have very recent versions available to me. I've had one report that monotone ran on Windows 98 without problems, so I would've expected it to work fine on Windows NT 4 too... Sadly the installed binary fails to run, with a popup gui error that says: The procedure entry point CreateToolhelp32Snapshot could not be located in the dynamic link library KERNEL32.dll. This is being called in Botan's Win32 entropy collector--Win32_EntropySource::do_slow_poll() in es_win32.cpp. MSDN states that this API (and, er, the other API Botan uses for collecting entropy) is available on every version of Windows except NT 3.x and NT 4. Anyone know how this might be resolved? I'm hoping its something simple, such as turning on some different flags when building. You could try that. The two options that spring to mind immediately are: - rebuild without linking in es_win32.cpp (hack Makefile.am) -- this should work fine, as Botan also collects entropy via CryptoAPI on Windows. - improve Win32_EntropySource::do_slow_poll() to detect at runtime and use only those APIs available on the platform. OpenSSL's RAND_poll might be useful for ideas. Cheers, -mjg -- Matthew Gregan |/ /|[EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] windows *cough* NT4 support?
On 11/25/05, Matthew Gregan [EMAIL PROTECTED] wrote: At 2005-11-25T21:39:52+1100, Daniel Carosone wrote: I have the embarassing misfortune to need to use NT4 at certain sites, and would love to use monotone to avoid certain aspects of this pain as much as possible :) It'll be good to have someone testing monotone on older Windows versions--I only have very recent versions available to me. I've had one report that monotone ran on Windows 98 without problems, so I would've expected it to work fine on Windows NT 4 too... Heh. Windows 98 and Windows NT are about as far apart as you can get. I wouldn't be surprised at all if something which worked on one failed utterly on another. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
