Jenkins build is back to normal : Aurora #1386

2016-02-08 Thread Apache Jenkins Server 
See

Re: [PROPOSAL] Disallow instance removal in job update

2016-02-08 Thread Maxim Khutornenko 
> Or without any persistence at all.  The client could refuse to adjust the
> instance count on a job unless there's additional command line argument.
> The same arguments of responsibility could be said here of users of old
> clients or custom clients.

Bill, are you suggesting 'aurora update start' client command call a
scheduler to acquire an update diff first and block startJobUpdate RPC
call unless a special command line flag is present?

> When updating a job, the scheduler would fill in the current instance count.
> However, when I want to change the number of instances, I could simply
> bind another value locally when triggering the update.

Stephan, this sounds like increasing instances would also require a
binding helper, which makes an update process less deterministic (i.e.
.aurora config file is no longer self-contained).

On Sun, Feb 7, 2016 at 3:02 PM, Erb, Stephan
 wrote:
> A related idea that recently crossed my mind was some kind of pystachio 
> variable / binding helper:  {{aurora.instances}}.
>
> When updating a job, the scheduler would fill in the current instance count. 
> However, when I want to change the number of instances, I could simply bind 
> another value locally when triggering the update.
> 
> From: Maxim Khutornenko 
> Sent: Saturday, February 6, 2016 00:07
> To: dev@aurora.apache.org
> Subject: Re: [PROPOSAL] Disallow instance removal in job update
>
> We have had attempts to safeguard client updater command with a
> "dangerous change" warning before but it did not get good feedback.
> Besides, automated tools/scripts just ignored it.
>
> An alternative could be what George suggest on the scaling API thread
> mentioned earlier: automatically bump up instance count to the job
> active task count. I'd say this could be an implementation to the
> proposal above rather than a safeguard as it accomplishes the exact
> same goal.
>
> Bill, do you have any ideas of what that safeguard could be?
>
> On Fri, Feb 5, 2016 at 2:56 PM, Bill Farner  wrote:
>>>
>>> the outdated instance count problem will only get worse as automated
>>> scaling tools will quickly render existing .aurora config value obsolete
>>
>>
>> This is not a compelling reason to remove functionality.  Sounds like a
>> safeguard is needed instead.
>>
>> On Fri, Feb 5, 2016 at 2:43 PM, Maxim Khutornenko  wrote:
>>
>>> This is mostly a survey rather than a proposal. How would people think
>>> about limiting updater to only adding/updating instances and let
>>> killTasks take care of instance removals?
>>>
>>> We have all heard stories (or happen to create some ourselves) when an
>>> outdated instance count value in .aurora config caused unexpected
>>> instance removals. Granted, there are plenty of other values in the
>>> config that can cause service-wide outage but instance count seems to
>>> be the worst in that sense.
>>>
>>> After the recent refactoring of addInstances and killTasks to act as
>>> scaleOut/scaleIn APIs [1], the outdated instance count problem will
>>> only get worse as automated scaling tools will quickly render existing
>>> .aurora config value obsolete. With that in mind, should we block
>>> instance removal in the updater and let an explicit killTasks call be
>>> the only acceptable action to reduce instance count? Is there any
>>> value (aside from arguable convenience factor) in having
>>> startJobUpdate ever killing instances?
>>>
>>> Thanks,
>>> Maxim
>>>
>>> [1] - http://markmail.org/message/2smaej5n5e54li3g
>>>

Re: Subject: [VOTE] Release Apache Aurora 0.12.0 RC4

2016-02-08 Thread Maxim Khutornenko 
+1

On Sat, Feb 6, 2016 at 2:12 PM, Erb, Stephan
 wrote:
> +1
>
> "./build-support/release/verify-release-candidate 0.12.0-rc4 " has passed 
> successfully for me.
>
> 
> From: Bill Farner 
> Sent: Saturday, February 6, 2016 00:22
> To: dev@aurora.apache.org; jsir...@apache.org
> Subject: Re: Subject: [VOTE] Release Apache Aurora 0.12.0 RC4
>
> +1
>
> Successfully ran ./build-support/release/verify-release-candidate
>  0.12.0-rc4
>
> On Fri, Feb 5, 2016 at 3:18 PM, John Sirois  wrote:
>
>> I'd like to kick-off voting with my own +1 (binding).
>> ./build-support/release/verify-release-candidate 0.12.0-rc4 is green for
>> me.
>>
>> On Fri, Feb 5, 2016 at 3:14 PM, John Sirois  wrote:
>>
>> > All,
>> >
>> > I propose that we accept the following release candidate as the official
>> > Apache Aurora 0.12.0 release.
>> >
>> > Aurora 0.12.0-rc4 includes the following:
>> > ---
>> > The NEWS for the release is available at:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc4
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc4
>> >
>> > The tag used to create the release candidate is:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.12.0-rc4
>> >
>> > The release candidate is available at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz
>> >
>> > The MD5 checksum of the release candidate can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz.md5
>> >
>> > The signature of the release candidate can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz.asc
>> >
>> > The GPG key used to sign the release are available at:
>> > https://dist.apache.org/repos/dist/dev/aurora/KEYS
>> >
>> > Please download, verify, and test.
>> >
>> > The vote will close on Mon Feb  8 15:12:45 MST 2016
>> >
>> > [ ] +1 Release this as Apache Aurora 0.12.0
>> > [ ] +0
>> > [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
>> > ---
>> >
>> > Reminder: you can verify the release candidate via:
>> >
>> >   ./build-support/release/verify-release-candidate 0.12.0-rc4
>> >
>> > If you can deploy the RC to a test cluster and evaluate it there, even
>> > better.
>> >
>>

Re: [PROPOSAL] Disallow instance removal in job update

2016-02-08 Thread Tony Dong 
Definitely +1 on the idea of a safeguard.
I didn't really have any proposals outside of the ones that have been
mentioned in this thread already.

W.R.T. automatic scaling up the instances via a binding helper (George
talked about it in the scaling API discussion).
Essentially we had a binding helper which talks to the scheduler and
figures out how many active task instances. Similar to what Stephan had
brought up.
However, we've still had incidents where an engineer has forgotten to or
accidentally did not use the binding helper.
I think to avoid operator error, I'd like whatever safeguard be
automatically activated, rather than requiring an explicit flag.


On Mon, Feb 8, 2016 at 9:42 AM, Maxim Khutornenko  wrote:

> > Or without any persistence at all.  The client could refuse to adjust the
> > instance count on a job unless there's additional command line argument.
> > The same arguments of responsibility could be said here of users of old
> > clients or custom clients.
>
> Bill, are you suggesting 'aurora update start' client command call a
> scheduler to acquire an update diff first and block startJobUpdate RPC
> call unless a special command line flag is present?
>
> > When updating a job, the scheduler would fill in the current instance
> count.
> > However, when I want to change the number of instances, I could simply
> > bind another value locally when triggering the update.
>
> Stephan, this sounds like increasing instances would also require a
> binding helper, which makes an update process less deterministic (i.e.
> .aurora config file is no longer self-contained).
>
> On Sun, Feb 7, 2016 at 3:02 PM, Erb, Stephan
>  wrote:
> > A related idea that recently crossed my mind was some kind of pystachio
> variable / binding helper:  {{aurora.instances}}.
> >
> > When updating a job, the scheduler would fill in the current instance
> count. However, when I want to change the number of instances, I could
> simply bind another value locally when triggering the update.
> > 
> > From: Maxim Khutornenko 
> > Sent: Saturday, February 6, 2016 00:07
> > To: dev@aurora.apache.org
> > Subject: Re: [PROPOSAL] Disallow instance removal in job update
> >
> > We have had attempts to safeguard client updater command with a
> > "dangerous change" warning before but it did not get good feedback.
> > Besides, automated tools/scripts just ignored it.
> >
> > An alternative could be what George suggest on the scaling API thread
> > mentioned earlier: automatically bump up instance count to the job
> > active task count. I'd say this could be an implementation to the
> > proposal above rather than a safeguard as it accomplishes the exact
> > same goal.
> >
> > Bill, do you have any ideas of what that safeguard could be?
> >
> > On Fri, Feb 5, 2016 at 2:56 PM, Bill Farner  wrote:
> >>>
> >>> the outdated instance count problem will only get worse as automated
> >>> scaling tools will quickly render existing .aurora config value
> obsolete
> >>
> >>
> >> This is not a compelling reason to remove functionality.  Sounds like a
> >> safeguard is needed instead.
> >>
> >> On Fri, Feb 5, 2016 at 2:43 PM, Maxim Khutornenko 
> wrote:
> >>
> >>> This is mostly a survey rather than a proposal. How would people think
> >>> about limiting updater to only adding/updating instances and let
> >>> killTasks take care of instance removals?
> >>>
> >>> We have all heard stories (or happen to create some ourselves) when an
> >>> outdated instance count value in .aurora config caused unexpected
> >>> instance removals. Granted, there are plenty of other values in the
> >>> config that can cause service-wide outage but instance count seems to
> >>> be the worst in that sense.
> >>>
> >>> After the recent refactoring of addInstances and killTasks to act as
> >>> scaleOut/scaleIn APIs [1], the outdated instance count problem will
> >>> only get worse as automated scaling tools will quickly render existing
> >>> .aurora config value obsolete. With that in mind, should we block
> >>> instance removal in the updater and let an explicit killTasks call be
> >>> the only acceptable action to reduce instance count? Is there any
> >>> value (aside from arguable convenience factor) in having
> >>> startJobUpdate ever killing instances?
> >>>
> >>> Thanks,
> >>> Maxim
> >>>
> >>> [1] - http://markmail.org/message/2smaej5n5e54li3g
> >>>
>

Re: [PROPOSAL] java gen: Uniform AsyncMethodCallback use in client and server

2016-02-08 Thread John Sirois 
Sorry folks - wrong list!  Please disregard.

On Mon, Feb 8, 2016 at 12:35 PM, John Sirois  wrote:

> I'd like to propose a breaking change in both the java generated service
> code and in supporting library code.  This change would change
> parametrization and use of clients to be symmetric with servers in the java
> async stack.
>
> Today the situation is as described in comments in
> https://issues.apache.org/jira/browse/THRIFT-3112.
> Although you might expect an async client call that returns an int to look
> like:
>   `client.add(int first, int second, new AsyncMethodCallback()
> {...});`
>
> It in fact looks like:
>   `client.add(int first, int second, new AsyncMethodCallback()
> {...});`
>
> Where `add_call` is a type with an `int getResult() throws ...` method the
> client must call in the `AsyncMethodCallback.onComplete` implementation to
> retrieve the result of the async call, or else its remote error.
>
> This has been the case since initial commit in 2010, but there are several
> shortcomings, chief among these being:
> 1. The parametrization is highly un-expected.  Its neither the expected
> return type (like the server parametrization) nor a type at the same
> abstraction level as the decalring AsyncIface - its a type encapsulated by
> the AsyncClient _implementation_.
> 2. Because of the coupling to implementation in 1, we are not as free to
> modify the library implementation or generated code as we might be in a
> world where the AsyncIface was composed purely of standard value types
> (structs, ints, etc).
>
> It seems to me it would be wonderful to take our pre 1.0.0 status to
> correct this confusing and leaky API.
>
> I'm interested in what folks think.
>



-- 
John Sirois
303-512-3301

[RESULT][VOTE] Release Apache Aurora 0.12.0 RC4

2016-02-08 Thread John Sirois 
All,
The vote to accept Apache Aurora 0.12.0 RC4
as the official Apache Aurora 0.12.0 release has passed.


+1 (Binding)
--
jsirois
wfarner
serb
maxim


+1 (Non-binding)
--


There were no 0 or -1 votes. Thank you to all who helped make this release.


Aurora 0.12.0 includes the following:
---
The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0

The tag used to create the release with is rel/0.12.0:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=rel/0.12.0

The release is available at:
https://dist.apache.org/repos/dist/release/aurora/0.12.0/apache-aurora-0.12.0.tar.gz

The MD5 checksum of the release can be found at:
https://dist.apache.org/repos/dist/release/aurora/0.12.0/apache-aurora-0.12.0.tar.gz.md5

The signature of the release can be found at:
https://dist.apache.org/repos/dist/release/aurora/0.12.0/apache-aurora-0.12.0.asc

The GPG key used to sign the release are available at:
https://dist.apache.org/repos/dist/release/aurora/KEYS


On Fri, Feb 5, 2016 at 3:14 PM, John Sirois  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.12.0 release.
>
> Aurora 0.12.0-rc4 includes the following:
> ---
> The NEWS for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc4
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc4
>
> The tag used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.12.0-rc4
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc4/apache-aurora-0.12.0-rc4.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Mon Feb  8 15:12:45 MST 2016
>
> [ ] +1 Release this as Apache Aurora 0.12.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
> ---
>
> Reminder: you can verify the release candidate via:
>
>   ./build-support/release/verify-release-candidate 0.12.0-rc4
>
> If you can deploy the RC to a test cluster and evaluate it there, even
> better.
>

Build failed in Jenkins: Aurora #1385

2016-02-08 Thread Apache Jenkins Server 
See 

Changes:

[jsirois] Fixup release script to tag HEAD of the release branch.

--
[...truncated 3464 lines...]
 
src/test/python/apache/aurora/client/api/test_instance_watcher.py::InstanceWatcherTest::test_successful_watch
 PASSED
 
src/test/python/apache/aurora/client/api/test_instance_watcher.py::InstanceWatcherTest::test_terminated_exits_immediately
 PASSED
 
src/test/python/apache/aurora/client/api/test_instance_watcher.py::InstanceWatcherTest::test_watch_period_failure
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::test_coverage
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_abortJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_acquireLock
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_addInstances
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_createJob
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_descheduleCronJob
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_getJobUpdateDetails
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_getJobUpdateSummaries
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_getJobs
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_getQuota
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_getTasksStatus
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_killTasks
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_pauseJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_populateJobConfig
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_pulseJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_raise_auth_error
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_releaseLock
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_replaceCronTemplate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_restartShards
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_resumeJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_scheduleCronJob
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_startCronJob
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyInjection::test_startJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyAdminInjection::test_abortJobUpdate
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyAdminInjection::test_acquireLock
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyAdminInjection::test_addInstances
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyAdminInjection::test_commitRecovery
 PASSED
 
src/test/python/apache/aurora/client/api/test_scheduler_client.py::TestSchedulerProxyAdminInjection::test_createJob
 PASSED

Build failed in Jenkins: aurora-packaging-nightly #188

2016-02-08 Thread Apache Jenkins Server 
See 

--
[...truncated 7686 lines...]
Get:66 http://httpredir.debian.org/debian/ jessie/main libglib2.0-0 amd64 
2.42.1-1 [2401 kB]
Get:67 http://httpredir.debian.org/debian/ jessie/main libcroco3 amd64 
0.6.8-3+b1 [135 kB]
Get:68 http://httpredir.debian.org/debian/ jessie/main librtmp1 amd64 
2.4+20150115.gita107cef-1 [59.8 kB]
Get:69 http://httpredir.debian.org/debian/ jessie/main libssh2-1 amd64 
1.4.3-4.1 [125 kB]
Get:70 http://httpredir.debian.org/debian/ jessie/main libdbus-1-3 amd64 
1.8.20-0+deb8u1 [170 kB]
Get:71 http://httpredir.debian.org/debian/ jessie/main libdbus-glib-1-2 amd64 
0.102-1 [201 kB]
Get:72 http://httpredir.debian.org/debian/ jessie/main libunistring0 amd64 
0.9.3-5.2+b1 [288 kB]
Get:73 http://httpredir.debian.org/debian/ jessie/main libgettextpo0 amd64 
0.19.3-2 [138 kB]
Get:74 http://httpredir.debian.org/debian/ jessie/main libgomp1 amd64 4.9.2-10 
[37.8 kB]
Get:75 http://httpredir.debian.org/debian/ jessie/main libitm1 amd64 4.9.2-10 
[29.2 kB]
Get:76 http://httpredir.debian.org/debian/ jessie/main liblsan0 amd64 4.9.2-10 
[92.8 kB]
Get:77 http://httpredir.debian.org/debian/ jessie/main libmpdec2 amd64 2.4.1-1 
[85.7 kB]
Get:78 http://httpredir.debian.org/debian/ jessie/main libmpfr4 amd64 3.1.2-2 
[527 kB]
Get:79 http://httpredir.debian.org/debian/ jessie/main libossp-uuid16 amd64 
1.6.2-1.5+b1 [38.0 kB]
Get:80 http://httpredir.debian.org/debian/ jessie/main libpython2.7 amd64 
2.7.9-2 [1080 kB]
Get:81 http://httpredir.debian.org/debian/ jessie/main libc-dev-bin amd64 
2.19-18+deb8u2 [237 kB]
Get:82 http://httpredir.debian.org/debian/ jessie/main libc6-dev amd64 
2.19-18+deb8u2 [2002 kB]
Get:83 http://httpredir.debian.org/debian/ jessie/main libexpat1-dev amd64 
2.1.0-6+deb8u1 [126 kB]
Get:84 http://httpredir.debian.org/debian/ jessie/main libpython2.7-dev amd64 
2.7.9-2 [18.6 MB]
Get:85 http://httpredir.debian.org/debian/ jessie/main libpython3.4-minimal 
amd64 3.4.2-1 [492 kB]
Get:86 http://httpredir.debian.org/debian/ jessie/main libpython3.4-stdlib 
amd64 3.4.2-1 [2088 kB]
Get:87 http://httpredir.debian.org/debian/ jessie/main libquadmath0 amd64 
4.9.2-10 [129 kB]
Get:88 http://httpredir.debian.org/debian/ jessie/main libsctp1 amd64 
1.0.16+dfsg-2 [27.6 kB]
Get:89 http://httpredir.debian.org/debian/ jessie/main libserf-1-1 amd64 
1.3.8-1 [52.8 kB]
Get:90 http://httpredir.debian.org/debian/ jessie/main libsigsegv2 amd64 
2.10-4+b1 [29.2 kB]
Get:91 http://httpredir.debian.org/debian/ jessie/main libsvn1 amd64 
1.8.10-6+deb8u2 [1077 kB]
Get:92 http://httpredir.debian.org/debian/ jessie/main libtsan0 amd64 4.9.2-10 
[212 kB]
Get:93 http://httpredir.debian.org/debian/ jessie/main libubsan0 amd64 4.9.2-10 
[82.4 kB]
Get:94 http://httpredir.debian.org/debian/ jessie/main libxau6 amd64 1:1.0.8-1 
[20.7 kB]
Get:95 http://httpredir.debian.org/debian/ jessie/main libxdmcp6 amd64 
1:1.1.1-1+b1 [24.9 kB]
Get:96 http://httpredir.debian.org/debian/ jessie/main libxcb1 amd64 1.10-3+b1 
[44.4 kB]
Get:97 http://httpredir.debian.org/debian/ jessie/main libx11-data all 
2:1.6.2-3 [126 kB]
Get:98 http://httpredir.debian.org/debian/ jessie/main libx11-6 amd64 2:1.6.2-3 
[729 kB]
Get:99 http://httpredir.debian.org/debian/ jessie/main libxext6 amd64 2:1.3.3-1 
[52.7 kB]
Get:100 http://httpredir.debian.org/debian/ jessie/main libxmuu1 amd64 
2:1.1.2-1 [23.3 kB]
Get:101 http://httpredir.debian.org/debian/ jessie/main python3.4-minimal amd64 
3.4.2-1 [1646 kB]
Get:102 http://httpredir.debian.org/debian/ jessie/main sgml-base all 1.26+nmu4 
[14.6 kB]
Get:103 http://httpredir.debian.org/debian/ jessie/main libmpc3 amd64 1.0.2-1 
[39.3 kB]
Get:104 http://httpredir.debian.org/debian/ jessie/main apt-utils amd64 
1.0.9.8.2 [368 kB]
Get:105 http://httpredir.debian.org/debian/ jessie/main less amd64 458-3 [124 
kB]
Get:106 http://httpredir.debian.org/debian/ jessie/main manpages all 3.74-1 
[997 kB]
Get:107 http://httpredir.debian.org/debian/ jessie/main at amd64 3.1.16-1 [45.4 
kB]
Get:108 http://httpredir.debian.org/debian/ jessie/main exim4-config all 
4.84-8+deb8u2 [500 kB]
Get:109 http://httpredir.debian.org/debian/ jessie/main exim4-base amd64 
4.84-8+deb8u2 [1047 kB]
Get:110 http://httpredir.debian.org/debian/ jessie/main exim4-daemon-light 
amd64 4.84-8+deb8u2 [630 kB]
Get:111 http://httpredir.debian.org/debian/ jessie/main bsd-mailx amd64 
8.1.2-0.20141216cvs-2 [81.7 kB]
Get:112 http://httpredir.debian.org/debian/ jessie/main bzip2 amd64 1.0.6-7+b3 
[46.9 kB]
Get:113 http://httpredir.debian.org/debian/ jessie/main dbus amd64 
1.8.20-0+deb8u1 [291 kB]
Get:114 http://httpredir.debian.org/debian/ jessie/main file amd64 
1:5.22+15-2+deb8u1 [60.4 kB]
Get:115 http://httpredir.debian.org/debian/ jessie/main gettext-base amd64 
0.19.3-2 [121 kB]
Get:116 http://httpredir.debian.org/debian/ jessie/main m4 amd64 1.4.17-4 [254 
kB]
Err http://httpredir.debian.org/debian/ jessie/main patch amd64 2.7.5-1

Seeking 0.13.0 release manager

2016-02-08 Thread John Sirois 
The main 0.12.0 release has just been made and docs/distributions will soon
follow.

Though we've barely begun work on it, I'd like to line up a release manager
for 0.13.0.
I'll be happy to help with pointers and advice.  I have a few document and
script edits still to come to help smooth out the problem areas I ran into,
so those should help as well.

Please speak up if you're interested!