Hi,
Alan wrote (02 May 2013 22:54:48 GMT) :
> This is an answer to blockers only. I belive they are all fixed.
All... but the one about the NM behavior on individual hook failure,
that you apparently have overlooked. See separate email.
Also, it's not clear to me that someone volunteered to fix the
[todo-later] stuff in time for 0.18.1. Alan, do you?
> On Tue, 30 Apr 2013 10:05:23 +0200 intrigeri <intrigeri@???> wrote:
>> [blocker]: verify this is needed; if yes, add a comment explaining why
>> (and possibly implement it in a better way); if not, remove it.
>>
>> > apt_get_env['LANG'] = "C"
>>
>> Why?
>>
> For logging in english, comment added in commit d5d8dd1.
OK. Slightly improved in 3cc2c28 to include the part about WhisperBack
you mentioned in a previous email.
>> > syslog.syslog("WARNING: [...]")
[...]
>>
> Fixed in commit f690185.
Great, thanks.
>> > syslog.syslog("WARNING: installation of %s failed" % "
>> > ".join(packages))
>>
>> In this case, as a user, I'd like to have access to the APT
>> stdout/stderr/returncode.
> Stdout/stderr was already logged. Returncode added in commit 89a7ed1.
Awesome.
>> > if os.path.isfile(ACTIVATION_FILE):
>> > return True
>> > else:
>> > return False
>>
>> Just curious, as a non-Python-programmer: wouldn't `return
>> os.path.isfile(ACTIVATION_FILE)' work just as fine, and be nicer?
> Fixed in commit be19887.
OK.
>> > + apt_get_returncode = _launch_apt_get(["apt-get",
>> > + "--quiet",
>> > + "update"])
>>
>> Adding `--yes' here too would be more consistent and future-proof,
>> wouldn't it?
> Done in commit 80cd937.
OK.
>> If we go this way, perhaps the args we always want to
>> pass to apt-get (`--yes' and `--quiet') could be stored in a variable
>> on top of the script, and transparently added by _launch_apt_get?
>>
> I prefer to do that later (it will change more code and might require
> more time/testing).
OK. Added to the "Improvements for a next version" list on the
ticket, then.
>> Also, what does happen in the following user story:
>>
>> 1. I boot Tails on January 1st
>> 2. I setup persistence for APT lists and packages, and I reboot.
>> 3. I activate persistence, I install a few packages, and I list them
>> in live-additional-software.conf. Shutdown.
>> 4. I boot Tails on February 1st
>> 5. I activate persistence
>> => The APT indices are expired and not valid anymore, so
>> `install_additional_packages' fails, right?
>> What's the APT indices expiration time exactly?
>>
> Each APT list contains a "Valid-Until:" field.
Sure. This field is what I was referring to with my "not valid
anymore" discussion. I'll go find the answer myself, then.
So apparently:
* security.d.o Release files are valid for 10 days
* Wheezy and sid indices are valid for 7 days
* Squeeze, deb.torproject.org and deb.tails.boum.org don't set
Valid-Until. My understanding of Max-ValidTime in apt.conf(5) is
that this means "forever valid".
>> At least understanding how Tails behaves in this case is a [blocker],
>> as is evaluating how good/bad this is. But probably we can ship the
>> whole thing as is right now, and keep further improvements in this
>> area for later.
>>
> Testing shows that when lists are expired, the initial install fails and
> I get the following output:
[...]
> Then, if there is network, the installation is successful after the
> update.
> This doesn't seem me that bad, even though I think that explaining to
> the user what's happening in that case would be a nice bonus.
With the additional information we now have about expiration time,
I agree. I've clarified this on the ticket.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
