Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

On Wed, 18 Jan 2017 08:19:19 +0100 Dirkjan Ochtman wrote: > This sounds like a much better strategy to me. We're expecting people > to check things that should be easy to check for machines. Yes, some > people (like myself) will always use repoman to commit, but it would > be

Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

On 18/01/17 09:04, Kent Fredric wrote: > On Wed, 18 Jan 2017 08:19:19 +0100 > Dirkjan Ochtman wrote: > >> >> That makes sense. My other comment initially reading your email would >> be, send those emails to gentoo-core or -project or whatever. If >> others don't get to feel the

Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

On Wed, Jan 18, 2017 at 10:04 AM, Kent Fredric wrote: > That's not viable, mostly because the performance cost of doing so is > significantly > time consuming, that it would block `git push` for minutes at a time, and all > users > performing pushes would have to wait in a

[gentoo-dev] Last rites: x11-misc/ksuperkey

# Michael Palimaka (18 Jan 2017) # Obsolete - now a native feature in Plasma 5.8 # Masked for removal in 30 days x11-misc/ksuperkey

[gentoo-dev] Last rites: app-admin/filebeat-bin

# Michael Palimaka (18 Jan 2017) # Obsolete. Use app-admin/filebeat instead. app-admin/filebeat-bin

[gentoo-dev] Last rites: media-video/flumotion:

# Michael Palimaka (18 Jan 2017) # Relies on dead gstreamer:0.10. Dead upstream. # Masked for removal in 30 days. Bug #603270. media-video/flumotion

[gentoo-dev] Last rites: app-cdr/k9copy

# Michael Palimaka (18 Jan 2017) # Fails to build with ffmpeg-3. Dead upstream. # Masked for remvoal in 30 days. app-cdr/k9copy

[gentoo-dev] Last rites: dev-ml/ocamlgsl

# David Seifert (18 Jan 2017) # Dead upstream, spiritual successor is dev-ml/gsl-ocaml # Masked for removal in 30 days. Bug #574564, #593248, #601912. dev-ml/ocamlgsl

Re: [gentoo-portage-dev] [PATCH] emaint: exit with non-zero status code when module fails (bug 567478)

I've modified the patch as per Brian's suggestions: - the modules return True on success and False on failure. - TaskHandler.run_tasks() returns a list of all the module return codes, then emaint_main() exits. - the portage/pym/portage/tests/emerge/test_simple.py change wasn't present in the first

[gentoo-portage-dev] Re: [PATCH v2] emaint: exit with non-zero status code when module fails (bug 567478)

Module functions currently return a message to emaint after invocation. Emaint prints this message then exits normally (with a success return code) even if the module encountered an error. This patch aims to change this by having each module public function return a tuple of (returncode, message),

[gentoo-portage-dev] Re: [PATCH V2] emaint: exit with non-zero status code when module fails (bug 567478)

Module functions currently return a message to emaint after invocation. Emaint prints this message then exits normally (with a success return code) even if the module encountered an error. This patch aims to change this by having each module public function return a tuple of (returncode, message),

[gentoo-portage-dev] Re: [PATCH V3] emaint: exit with non-zero status code when module fails (bug 567478)

Module functions currently return a message to emaint after invocation. Emaint prints this message then exits normally (with a success return code) even if the module encountered an error. This patch aims to change this by having each module public function return a tuple of (returncode, message),

Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

On Wed, 18 Jan 2017 10:48:18 +0100 Dirkjan Ochtman wrote: > This doesn't ring intuitively true for me. Maybe you're talking about > running a "repoman full" for every committed package; I'm not. The > checks Doug describes are all package-local. What makes this process > so