I sometimes have trouble to update subversion-based overlays from overlays.g.o: * Running... # /usr/bin/svn up /var/lib/layman/emacs hangs for a long time, so I interrupt it using Ctrl-C, in order to restart it. ^C* Interrupted manually * * Errors: * ------ * * Failed to sync overlay "emacs". * Error was: Syncing overlay "emacs" returned status 1! * The error is fine, but then, if I want to restart the sync, the svn repository is locked: # layman -s emacs * Running... # /usr/bin/svn up /var/lib/layman/emacs svn: Working copy '/var/lib/layman/emacs' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) (...) * Failed to sync overlay "emacs". So I have to manually run: # /usr/bin/svn cleanup /var/lib/layman/emacs then: # layman -s emacs * Running... # /usr/bin/svn up /var/lib/layman/emacs (...) Updated to revision 1665. (...) * Successfully synchronized overlay "emacs". So would it be possible for layman to automatically run svn cleanup when it is manually interrupted, or before calling layman --sync= on a subversion overlay?
added in commit acc9c9163a0ff4fe3e19e4cb49228b93f1c5999e this will be in layman-2.0.0_rc2 out very soon. Please emerge layman-9999 to test this thoroughly. My tests seemed to work correctly but as the svn overlay was up to date and it ran very quick, my ^C's had to be very well timed.
(In reply to comment #1) > added in commit acc9c9163a0ff4fe3e19e4cb49228b93f1c5999e > > this will be in layman-2.0.0_rc2 out very soon. > > Please emerge layman-9999 to test this thoroughly. My tests seemed to work > correctly but as the svn overlay was up to date and it ran very quick, my ^C's > had to be very well timed. It seems to work here too, but I get the error message twice: * Running Subversion... # /usr/bin/svn up /var/lib/layman/sunrise ^C * Interrupted manually * Checking for cleanup actions to perform * SVN: preparing to run cleanup() * Running svn cleanup... # /usr/bin/svn cleanup /var/lib/layman/sunrise * Failure result returned from Subversion * * Succeeded: * ------ * Successfully synchronized overlay "emacs". * Successfully synchronized overlay "lisp". * Successfully synchronized overlay "mozilla". * * * Errors: * ------ * Failed to sync overlay "sunrise". * Error was: Syncing overlay "sunrise" returned status 1! * db.sync() * * CLI: Errors occured processing action sync_all * * Errors: * ------ * Failed to sync overlay "sunrise". * Error was: Syncing overlay "sunrise" returned status 1! * db.sync() * and I can re-run layman -S or layman -s sunrise without having to manually cleaning the repo :-) Thanks
Layman-2.0 has a new high level api. This api will record errors that occured while running the actions given. The new command-line interface will output those errors after all actions are performed. This is much the same as emerge repeating messages after an emerge run. Layman has the ability to perform many tasks from the same command line invocation. Like actions are grouped together and then run. eg: layman -a gentoo-guis -a x11 -d kde -s sunrise -a gnome -l much like emerge runs, those errors may have scrolled past and not seen. It does not/can not keep a count of how many lines have been printed to the terminal to know if the original errors are still visible. It is identified with: * CLI: Errors occured processing action ... This feature of the api is also so that any application can re-direct normal output to anywhere, or even hide the output, but still make the errors available to be reported, quite possible in a different window, terminal, popup dialog box, etc.. If enough people don't like this feature, I may add configuration option to disable it. Also this change is included in the rc2 release which should be in the main tree very soon (later today probably).
(In reply to comment #3) > much like emerge runs, those errors may have scrolled past and not seen. It > does not/can not keep a count of how many lines have been printed to the > terminal to know if the original errors are still visible. I get the rationale, thanks for the explanation. > If enough people don't like this feature, I may add configuration option to > disable it. It is not that I don't like it, I was just wondering if this behavior was expected, as it is a live version. I'll quiet now, we're getting out of this bug topic :)
Fixed and released in >=layman-2.0.0_rc2.