On Thu, Dec 1, 2016 at 5:34 AM, Christian Seiler wrote:
> Ah, and I ran my strace earlier with -e open,access, but after
> rechecking it, it does in fact check for the file's existence
> via stat(). I should remember to use -e open,access,stat when
> checking for file access with strace. [1]
...
>
On Wed, Nov 30, 2016 at 10:34:11PM +0100, Christian Seiler wrote:
> Ah, and I ran my strace earlier with -e open,access, but after
> rechecking it, it does in fact check for the file's existence
> via stat(). I should remember to use -e open,access,stat when
> checking for file access with strace
On 11/30/2016 10:12 PM, Peter Eckersley wrote:
> On Wed, Nov 30, 2016 at 04:19:40PM +0100, Christian Seiler wrote:
>> On 11/30/2016 02:33 PM, Virgo Pärna wrote:
>>> On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler
>>> wrote:
is not an issue (it works fine), but I had modified the cr
On Wed, Nov 30, 2016 at 04:19:40PM +0100, Christian Seiler wrote:
> On 11/30/2016 02:33 PM, Virgo Pärna wrote:
> > On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler
> > wrote:
> >>
> >> is not an issue (it works fine), but I had modified the cron job to
> >> pass --renew-hook and --post-hook t
On Tue, Nov 29, 2016 at 09:59:06AM +0100, Daniel Pocock wrote:
> This would probably mean making sure the client is checking the network
> API version and giving the user helpful, distro-specific instructions if
> there is a mismatch, e.g. a Debian user would see a message "The Let's
> Encrypt AP
On 11/30/2016 02:33 PM, Virgo Pärna wrote:
> On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler
> wrote:
>>
>> is not an issue (it works fine), but I had modified the cron job to
>> pass --renew-hook and --post-hook to certbot. (As far as I can tell,
>> there's no way of setting these in a conf
On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler wrote:
>
> is not an issue (it works fine), but I had modified the cron job to
> pass --renew-hook and --post-hook to certbot. (As far as I can tell,
> there's no way of setting these in a configuration file.) The only
I think that /etc
On 28/11/16 18:13, Peter Eckersley wrote:
> On Fri, Nov 25, 2016 at 12:48:35PM +0100, Christian Seiler wrote:
>
>> Note that per backports rules, $RELEASE_N-backports must track
>> $RELEASE_N_PLUS_1, so if you remove certbot from Stretch, you'll
>> also have to remove it from jessie-backports.
On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> Peter, there's one more question embedded within what you have already
> asked:
>
> - would new versions of python-certbot and python-acme require new python
> libraries? If yes (or maybe), then the answer would be: go with
> stretch-
On Thu, Nov 24, 2016 at 05:37:05PM +0200, Adrian Bunk wrote:
> On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> > On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
> > > So if you, as an upstream maintainer, have a change that is needed for
> > > compatibility with changes in networ
On Fri, Nov 25, 2016 at 12:48:35PM +0100, Christian Seiler wrote:
> Note that per backports rules, $RELEASE_N-backports must track
> $RELEASE_N_PLUS_1, so if you remove certbot from Stretch, you'll
> also have to remove it from jessie-backports.
Thank you for pointing this out Christian. This po
On Sat, Nov 26, 2016 at 09:35:46AM +0800, Paul Wise wrote:
> On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote:
>
> > currently working with an ACME backwards compatibilty window of 6-12 months,
> > but probably not longer than that.
>
> I note that letsencrypt 0.4.1-1 (before the rename to
Just to be clear, my only point was, if using backports, to make certain
ahead of time that whenever any changes to the packaging, including new
or changed dependencies or the like, occur to always be able atomically
to get the new version into backports.
If conflicts are avoided then backports is
On Thu, Nov 24, 2016 at 07:08:33PM +0100, Daniel Pocock wrote:
>
>
> On 24/11/16 17:39, Adrian Bunk wrote:
> > On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote:
> >> ...
> >> For networked services, it is different.
> >>
> >> Debian has already been carrying updated versions of Firef
> "HL" == Harlan Lieberman-Berg writes:
HL> The fix we put in place took about ten days to hit. It shouldn't have
HL> been broken longer than that; we didn't close the bug immediately,
HL> because we wanted the dependency to fix their versioning.
I do recall a long wait before an upload was
On November 25, 2016 4:05:30 PM EST, James Cloos wrote:
>It may have been; in any case it took *weeks* for the bug I saw to get
>fixed. And it doesn't matter where the bug was, it still made it
>impossible to apt-get install the certbot package. Which still defines
>the certbot in jessie-backpor
> "HL" == Harlan Lieberman-Berg writes:
HL> In fact, letsencrypt was never in jessie either. Both certbot and
HL> letsencrypt have only ever been in stable-bpo, stretch, and sid.
Ok. That must have been before I was forced to switch my openvz systems
from sid to jessie-backports. (The gli
James Cloos writes:
> HL> Certbot has never been in jessie, so I imagine it wouldn't have been
> usable.
>
> Certbot, letsencrypt, python-acme, et cetera; the package name doesn't
> matter for this purpose.
In fact, letsencrypt was never in jessie either. Both certbot and
letsencrypt have only e
> "HL" == Harlan Lieberman-Berg writes:
HL> Certbot has never been in jessie, so I imagine it wouldn't have been
usable.
Certbot, letsencrypt, python-acme, et cetera; the package name doesn't
matter for this purpose.
HL> I'm also haven't gotten any tickets about it being unusable. Can you
H
On 11/25/2016 12:45 PM, Christian Seiler wrote:
> On 11/25/2016 10:34 AM, Thijs Kinkhorst wrote:
>> On Thu, November 24, 2016 22:28, Harlan Lieberman-Berg wrote:
>>> On November 24, 2016 11:59:46 AM EST, James Cloos
>>> wrote:
The jessie and jessie-backports releases of certbot have not, in
>
On Fr, Nov 25, 2016 at 10:34:32 +0100, Thijs Kinkhorst wrote:
FWIW certbot from jessie-backports has been working fine for me in
several contexts.
Yes, here as well.
The only problem was the renaming from letsencrypt to certbot.
Many greetings,
Stephan
--
| Stephan Seitz E-M
On 11/25/2016 10:34 AM, Thijs Kinkhorst wrote:
> On Thu, November 24, 2016 22:28, Harlan Lieberman-Berg wrote:
>> On November 24, 2016 11:59:46 AM EST, James Cloos
>> wrote:
>>> The jessie and jessie-backports releases of certbot have not, in
>>> general, been usable. There have been usable windo
On Thu, November 24, 2016 22:28, Harlan Lieberman-Berg wrote:
> On November 24, 2016 11:59:46 AM EST, James Cloos
> wrote:
>>The jessie and jessie-backports releases of certbot have not, in
>>general, been usable. There have been usable windows, but it has not
>>been continuous.
>
> Certbot has n
On November 24, 2016 11:59:46 AM EST, James Cloos wrote:
>The jessie and jessie-backports releases of certbot have not, in
>general, been usable. There have been usable windows, but it has not
>been continuous.
Certbot has never been in jessie, so I imagine it wouldn't have been usable.
I'm als
On 24/11/16 17:39, Adrian Bunk wrote:
> On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote:
>> ...
>> For networked services, it is different.
>>
>> Debian has already been carrying updated versions of Firefox and
>> Chromium in stable including bundled dependencies too. Maybe we need
On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote:
>...
> For networked services, it is different.
>
> Debian has already been carrying updated versions of Firefox and
> Chromium in stable including bundled dependencies too. Maybe we need to
> have an objective way of deciding which o
On 24/11/16 16:37, Adrian Bunk wrote:
> On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
>> On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
>>> So if you, as an upstream maintainer, have a change that is needed for
>>> compatibility with changes in network APIs and the change is r
On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
> > So if you, as an upstream maintainer, have a change that is needed for
> > compatibility with changes in network APIs and the change is reviewable
> > by humans, a stable update co
On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
> So if you, as an upstream maintainer, have a change that is needed for
> compatibility with changes in network APIs and the change is reviewable
> by humans, a stable update could be possible. It's still on a
> case-by-case basis, so you would n
On 24.11.2016 09:27, Daniel Pocock wrote:
> Personally, I haven't seen a strong response to this challenge in any
> previous discussions like this. It has been raised before.
>
> The rational for the freeze is that we don't want things to break after
> a release is declared stable.
>
> For those
On 24/11/16 00:06, Peter Eckersley wrote:
> So Let's Encrypt definitely wants to get to a place where we have some very
> stable APIs for other people to code against. We're trying to do that with the
> Certbot command line itself, working hard to ensure that if people upgrade, it
> doesn't brea
On Wed, Nov 23, 2016 at 09:57:19AM +0100, Thijs Kinkhorst wrote:
> I'm a bit surprised by this policy. To my knowledge, concepts like automation
> and "hassle-free" are central to the Let's Encrypt concept. Obviously are
> online for more than a year, so installing Let's Encrypt certificates on t
32 matches
Mail list logo
