Bug#828761: hours_since should not update flag file after an error
On Tue, 2019-11-12 at 09:54 +0100, Marc Haber wrote: > Check hours_since > Do command, bail out if unsuccessful > update flag file Hmm, I suppose that could work, but right now there is no way for hours_since to communicate to the parent mr process that the flag file should be updated and which flag file to update. The stdout channel is already used so that would mean opening a pipe from the child to the parent and telling hours_since which file descriptor to write to using an environment variable. I'm not proficient enough with file descriptors and Perl to be able to implement this but I could add it to the myrepos codebase if I were to get an example of how to do this. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#828761: hours_since should not update flag file after an error
On Tue, Nov 12, 2019 at 03:12:34PM +0800, Paul Wise wrote: > On Mon, 27 Jun 2016 16:46:03 +0200 Marc Haber wrote: > > The flag should not be touched if there was an error so that one can > > immediately retry the operation. > > There doesn't appear to be any way to fix this, because the skip > command that runs hours_since which touches the flag file runs before > the update commands. Check hours_since Do command, bail out if unsuccessful update flag file > You can immediately retry the operation using the force option, which > will ignore the skip command where the hours_since flag was run. > >$ mr --force update I know, but that's not pretty. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#828761: hours_since should not update flag file after an error
On Mon, 27 Jun 2016 16:46:03 +0200 Marc Haber wrote: > The flag should not be touched if there was an error so that one can > immediately retry the operation. There doesn't appear to be any way to fix this, because the skip command that runs hours_since which touches the flag file runs before the update commands. You can immediately retry the operation using the force option, which will ignore the skip command where the hours_since flag was run. $ mr --force update -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#828761: hours_since should not update flag file after an error
Package: myrepos Version: 1.20160123 Severity: normal Hi, if hours_since is used, and an mr command fails with an error, the flag is still touched, so a retry will not try again: $ mr update mr update: /home/e13itfe/.config/vcsh/repo.d/repo.git mr update: command failed mr update: finished (1 failed; 5 skipped) [5/502]e13itfe@atln71628:~$ mr update mr update: finished (6 skipped) [6/502]e13itfe@atln71628:~$ The flag should not be touched if there was an error so that one can immediately retry the operation. Greetings Marc -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.2-zgws1 (SMP w/4 CPU cores) Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) myrepos depends on no packages. Versions of packages myrepos recommends: ii libhtml-parser-perl 3.72-1 pn libio-pty-easy-perl ii libwww-perl 6.15-1 ii perl 5.22.2-1 Versions of packages myrepos suggests: pn ack-grep pn bzr ii curl 7.47.0-1 ii cvs 2:1.12.13+real-15 pn darcs pn fossil ii git [git-core]1:2.8.1-1 pn kdesdk-scripts ii liburi-perl 1.71-1 pn mercurial ii subversion1.9.4-1 ii subversion-tools 1.9.4-1 ii vcsh 1.20151229-1 -- no debconf information -- debsums errors found: debsums: changed file /usr/bin/mr (from myrepos package)
