Re: [Tails-dev] Releasing automated tests

[intrigeri]

Hi,

[too bad it's too late to rename this thread, now that there have been
6 replies, to it.]

anonym wrote (21 Oct 2015 12:46:37 GMT) :

>> FTR I dislike the idea of blacklisting such branches based on their
>> name. I'm not going to debate it here [...]

> Please do it here, then! :) I guess it's related to that you want at
> least doc/ branches to be tested, since our automated test suite
> actually depend on the documentation (see two quotes below for more on
> this).

My concerns about skipping branches based on their name are
essentially the same as the ones I've just posted in another
sub-thread of this one
(https://mailman.boum.org/pipermail/tails-dev/2015-December/009836.html).

Besides, I think they are addressed by the content-based filtering (as
opposed to name-based filtering) that seems to be the most current
proposal in this thread, so no need for me to elaborate about it now.

> Ok, let's forget about this now and return to the "workaround", i.e.
> skipping tests depending on branch name:

>> Still, this idea is probably OK as a short-term workaround if we need
>> it for some reason, but then we need a clear description of the
>> problem,

> The problem, as I see it, is: we run the full automated test suite for
> doc/ and web/ branches, which wastes a lot of valuable isotester time
> given that all but a few tests are completely orthogonal to changes in
> the wiki sub directory of Tails Git sources.

About isotester time, I computed some stats in order to make my
opinion a bit better informed: in November, among 314 non-aborted ISO
test suite runs, 24% (75) were about branches whose name starts with
"doc" or "web". So yes, that's wasting a lot of resources. It will
probably be a problem, we'll see on #9264, so all the work put into
this thread is definitely useful :)

It seems that the proposed solution also addresses the problem that
was raised initially, which was rather about latency for testing
non-doc branches, so it sounds like we can avoid introducing clever
stuff like prioritization + quiet time for a bit longer (#9760 will
likely need it anyway, though). Yay!

>> [...] making sure that the workaround is not worst than the problem
>> it fixes

> The only effect should be that we won't get automated tests of the few
> scenarios that looks at the wiki shipped inside Tails. I think that
> currently is one scenario: The Report an Error launcher will open the
> support documentation in supported non-English locales.

> So, if some wiki
> change makes the 'the support documentation page opens in Tor Browser'
> step fail. The only way that can happen is if:
> [...]
> Only in the first case would our test suite find an actual error, the
> other two just implies that our test is now out of sync and must be
> updated. Clearly it's not worth wasting that much isotester time on this
> at the moment.

Thanks for gathering all the data I need to be convinced :)

I'll comment on this topic, about the actual proposed solution, later
on this thread if needed.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Releasing automated tests

[intrigeri]

Hi,

anonym wrote (28 Oct 2015 16:52:31 GMT) :
> Then I think we can combine the "..." operator with another fancy Git
> feature I recently found, namely Git pathspec "magic signatures". So we
> could do:

>BASE_BRANCH_DIFF="$(git diff $base_branch...$commit  -- \
>'*' \
>':!/wiki' \
>':!/ikiwiki.setup' \
>':!/ikiwiki-cgi.setup')"
>if [ -z "${BASE_BRANCH_DIFF}" ]; then
>CUCUMBER_ARGS="${CUCUMBER_ARGS} --tag @doc"
>fi

> where $commit is the commit we test, before merging the base branch
> locally. Interesting!

So, it seems that the current proposal is to skip the temporary
workaround (name-based filtering), and instead directly do
content-based filtering. Fine by me!

What's missing is:

 * the list of scenarios that shall be tagged @doc: at least the one
   anonym mentioned earlier in this thread; plus "check all PO files"
   I guess; the WhisperBack tests once they have been written; more?

 * some process to make sure we tag scenarios @doc whenever relevant;
   I think we'll forget from time to time, and it's fine, because
   we'll be adding such scenarios very rarely; so perhaps a yearly
   check by the RM (e.g. 1st release of the year) is good enough?

 * and finally, some Redmine tickets describing this decision and the
   timeline of its implementation.

bertagaz: once we have all that, please reassign #10492 to me for
review.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Releasing automated tests

[intrigeri]

Hi,

sajolida wrote (22 Oct 2015 12:19:04 GMT) :
>>> FTR I dislike the idea of blacklisting such branches based on their
>>> name. I'm not going to debate it here [...]

> The prefixes doc/ and web/ are used loosely to differentiate work on the
> "documentation" (/doc /support) and the "website" in general (structure,
> stuff not in /doc, etc.) but the difference is not strict.

Indeed. I've also seen the "contrib/", "about/" and "faq/" prefixes
being used. Branch naming is quite arbitrary, and sometimes creative,
so yay, instead of relying on a hard-coded list of prefixes:

> I also don't think they should be tested. Maybe you could exclude them
> from testing by their diff to their base branch. If all the diff is
> under wiki/src then don't test that branch.

I like the idea!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Installation Assistant (+ ISO Verification Extension + Tails Install in Debian): release schedule

[intrigeri]

sajolida wrote (01 Dec 2015 16:30:32 GMT) :
> I'll have to document how to check whether you are running
> testing or sid and that might be the funny part.

/etc/os-release and /etc/debian_version should help :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release versioning

[intrigeri]

Hi,

sajolida wrote (30 Nov 2015 16:39:04 GMT) :
> Sure, I didn't think about that. So I updated:

>   - master (841af4e)

Reviewed, OK!

>   - internal (90ad3ac)
>   - accounting (8750ec7)

Please push these so I can review them :)

> I also couldn't update the various reports that we already sent to
> sponsors mentioning 1.9 and others. So I gave then a conversion table in
> 1a753fb.

ACK

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] I would love Tails but...

[Daniel Kahn Gillmor]

On Tue 2015-12-01 20:06:01 +0200, Donncha O'Cearbhaill wrote:

> You can boot Tails fully into RAM which allows your to remove the USB
> stick. Press tab at boot to get into the boot options, the provide
> 'toram' as an option.

cool, thanks for the tip.

How much RAM is required on the host system to do this successfully?

Can this be combined with a persistence volume?

If this is done, and you need to shut the machine down in an hurry, is
there any  approach similar to yanking out the USB stick that will
trigger a shutdown and memory scrub reliably?

--dkg
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] I would love Tails but...

[intrigeri]

Hi,

Austin English wrote (01 Dec 2015 23:17:09 GMT) :
> That's not how persistence works (it uses encrypted storage on the
> Tails device).

As far as what we actively support (as in: document, test, try to keep
in good shape, and deal with user support request), and what our GUI
allows: this is totally correct.

Technically, however, the thing is a tiny bit more flexible: IIRC any
removable storage device with a GPT partition labeled "TailsData" that
contains a LUKS volume is a valid persistence partition that can be
unlocked in the Greeter. This can be useful e.g. for #5561.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] I would love Tails but...

[Daniel Kahn Gillmor]

On Wed 2015-12-02 01:11:51 +0200, Austin English wrote:
> On Tue, Dec 1, 2015 at 4:56 PM, Daniel Kahn Gillmor
>  wrote:
>> On Tue 2015-12-01 20:06:01 +0200, Donncha O'Cearbhaill wrote:
>>
>>> You can boot Tails fully into RAM which allows your to remove the USB
>>> stick. Press tab at boot to get into the boot options, the provide
>>> 'toram' as an option.
>>
>> cool, thanks for the tip.
>>
>> How much RAM is required on the host system to do this successfully?
>>
>> Can this be combined with a persistence volume?
>
> How could the files persist if you remove the storage device they
> would be written to?

you could write them elsewhere, not to a USB stick, no?  (or to a
different USB stick)

--dkg
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] I would love Tails but...

[hans . hack]

Dear Tails-Developer,tails is good but it would be much better when you could 
use Tails"without" USB-Stick. Before I used Tails I used Parted Magic. When 
Parted Magicis booted you can unmount the USB-Stick and boot the next Computer 
with this USB-stick.I hope you read this E-Mail and you will work at this.Best 
wishes from Germany,your "Hans Hack"
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] I would love Tails but...

[Donncha O'Cearbhaill]

Hi Hans,

You can boot Tails fully into RAM which allows your to remove the USB
stick. Press tab at boot to get into the boot options, the provide
'toram' as an option.

Regards,
Donncha

hans.h...@opentrash.com:
> Dear Tails-Developer,tails is good but it would be much better when you could 
> use Tails"without" USB-Stick. Before I used Tails I used Parted Magic. When 
> Parted Magicis booted you can unmount the USB-Stick and boot the next 
> Computer with this USB-stick.I hope you read this E-Mail and you will work at 
> this.Best wishes from Germany,your "Hans Hack"
> 
> 
> 
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to 
> tails-dev-unsubscr...@boum.org.
> 
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] encoding Jenkins testing settings in branches [Was: Releasing automated tests]

[intrigeri]

Hi,

[replying to the kinda off-topic part in a dedicated sub-thread]

anonym wrote (21 Oct 2015 12:46:37 GMT) :
> I wonder if we could have a configuration filem like
> config/jenkins_testing, which has settings controlling how the automated
> test suite is invoked on Jenkins. I imagine something like this:

> ENABLE = {true,false}

> Whether to run the test suite at all. Hence, when merging another base
> branch into master as part of the release process, we just make sure to
> set this to `false` and we're done. When merging master into a base
> branch, it must be set to `true`. So it's similar to config/base_branch,
> except that it includes master as a special case. Is this problematic?
> Won't merge conflicts save us?

> If we prefer it, we could implement my tagging idea with this:

> CUCUMBER_ARGUMENTS = 

> This makes Jenkins invoke run_test_suite with extra CUCUMBER_ARGUMENTS.
> And it could be used for the @web/@doc idea above if we have it set to
> `--tag @doc` or whatever in master. We could even test master then, in
> the same way. We just have to update the release process in the same way
> as for the ENABLE setting, but for CUCUMBER_ARGUMENTS.

> Since this affects how Jenkins will invoke a script, there's a security
> concern vs the shell that has to be considered. Also arbitrary paths can
> be given. Hence we probably may want to have this option *instead*:

> RUN_WITH_TAGS = 

> So if it's set to ["tag1", "~tag2,tag3"] it would be translated to these
> distinct arguments:

> ['--tag', 'tag1', '--tag', '~tag2,tag3']

> in the usual safe (i.e. shell-free) list syntax used for exec in many
> programming languages (python, ruby, perl...). This would also improve
> the situation for @fragile, and also be subject to the same release
> process update as ENABLE above.

> 

> Note that ENABLE gives an alternative implementation for the problem
> that #10389 wants to solve, i.e. "don't run tests for WIP branches". I
> think I prefer this approach, so we avoid excessive branch re-naming.

> Also note that with the flexibility from
> CUCUMBER_ARGUMENTS/CUCUMBER_TAGS we can remove `--tag ~@fragile` from
> the Jenkins wrapper script (#10288) by setting it in the config instead.

> Using CUCUMBER_ARGUMENTS/CUCUMBER_TAGS the true power users could even
> do "focus" testing of specific features/scenarios via a temporary tag
> and then making Jenkins only test that tag -- now the test suite will
> not waste time on other scenarios. FWIW. I don't think this will play
> nicely with our future ideas about Jenkins updating tickets in Redmine
> given the test results. That could be fixed if we added another option:

> JENKINS_REVIEW = {true,false}

> It would be true by default (I guess), and would then enable Jenkins
> "reviewing" (i.e. ticket updating). So when doing focus testing like
> described above, one could set it to false, temporarily. Alternatively
> this setting could be removed and its funcitonality implied by jenkins
> checking the CUCUMBER_ARGUMENTS, and only update tickets if it is the
> expected value(s), e.g. `--tag ~@fragile` (or `--tag @website` or whatever).

> Also, per our discussion on #10117 we may want:

> OLD_TAILS_ISO = 

> which sets the test suite's OLD_TAILS_ISO option (via run_test_suite's
> `--old-iso`, or features/config). As part of the release process, we
> could set this to the old release. In feature branches that we know
> there will be issues if the previous release is used could unset this.
> One would have to be careful about resetting it after merging such
> branches into a base branch, though. I guess we could add a @source test
> checks this (i.e. if a base branch is checked out, OLD_TAILS_ISO must be
> set, and we can perhaps even parse debian/changelog in some intelligent
> way).

> Speaking about Jenkins + Redmine, perhaps some additional settings here
> can help us with the issues we discussed in the specification thread? I
> don't have the context now to come up with something specific, but I
> recall something about the need of an extra field in Redmine, which
> perhaps would fit better in this config?

> We could also add an option for increasing the priority of the tests of
> that branch. In combination with "focus testing", this could be useful
> for those that cannot run the automated test suite on their own hardware.

> More crazy ideas?

> 

I see all the nice ad-hoc features we could get from encoding such
settings in Git branches.

Let me state some concerns I have (this is absolutely not a veto, all
these can be addressed). If we allow code to specify if/how it's going
to be tested, then:

* If we allow Git branches to specify such things, then "Scenario 1:
  reviewer" [1] becomes more complex: the reviewer has to ensure that
  no such setting was left by mistake in the branch, before they can
  consider an OK from Jenkins as valid. Similarly, the RM somehow has
  to make sure that no such setting goes into a release branch
  

[Tails-dev] [Tails - Feature #5991] Include BitTorrent software

[Spencer]

Hi,

Following up.



I'm in favor of documenting how to use Torrent over I2P



How should this move forward?  Reading the last message I think I 
assigned it to you without asking; my bad :)


I can figure out how to document this but I thought I should ask first: 
should I be the one to document this?


Wordlife,
Spencer

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Newsletters, dernière ligne droite pour réussir sa fin d’année

[l’équipe de Cibleweb]

Si vous ne visualisez pas correctement ce message, consultez-le en ligne 
http://www.graphbsn.com/nl/cib_leweb/2015_11_24/nl_bsn.htm.
Vous appr?ciez notre newsletter. Pour ?tre s?r(e) de ne pas la manquer, nous 
vous conseillons d'ajouter l'adresse de l'exp?diteur ? votre carnet d'adresses.
http://tinyurl.com/qboxjre
Pour fid?liser ou prospecter, l?email marketing est un levier polyvalent et 
performant. Toutefois, concevoir un email attractif en ad?quation avec les 
standards techniques et HTML des bo?tes de r?ception et permettant d?obtenir un 
bon taux de d?livrabilit? est tout un art.
Faites confiance ? des professionnels afin de mettre toutes les chances de 
r?ussite de votre c?t? !
Lire la suite http://tinyurl.com/qboxjre http://tinyurl.com/qboxjre

http://tinyurl.com/nbvxmbn http://tinyurl.com/nbvxmbn

BtoB, BtoC, Ecommerce, Institutionnels?
http://tinyurl.com/nbvxmbn

http://tinyurl.com/n9hxyof http://tinyurl.com/n9hxyof

Prix de la cr?ation graphique de votre newsletter ? partir de 159€...
http://tinyurl.com/n9hxyof
http://tinyurl.com/9x9h4ux

Si vous ne souhaitez plus recevoir d'informations de la part de CW par e-mail, 
d?sabonnez vous 
http://ks303932.kimsufi.com/~desabonn/generique/?adresse=tails-dev@boum.org=cw
Cet e-mail commercial est conforme ? la l?gislation en vigueur et aux 
d?lib?rations de la CNIL des 22 et 30 mars 2005 sur la prospection
par courrier ?lectronique dans le cadre professionnel. Conform?ment ? l?article 
34 de la loi 78-17 du 6 janvier 1978
relative ? l?informatique, aux fichiers et aux libert?s,vous disposez d?un 
droit d?acc?s, de rectification de donn?es nominative vous concernant.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release versioning

[sajolida]

intrigeri:
> sajolida wrote (30 Nov 2015 16:39:04 GMT) :
>> So I updated:
> 
>>   - master (841af4e)
>>   - internal (90ad3ac)
>>   - accounting (8750ec7)
> 
> Thanks! I'll check these one of these days.
> 
> I think fundraising also has some, no?

I checked and it had references only in the reports and budgets so I
didn't update them on purpose.

>> I didn't updated the UDFs as I didn't want to break anything. Can you do
>> it? For example:
> 
>>   - upgrade/v1/Tails/1.9/i386/alpha/upgrades.yml
> 
> I don't think there's anything to update there; if you think
> differently, please tell me what you think should be updated and why
> and then I or anonym can do it.

I don't know what this UDF is used for as 1.9 will never exist, but
maybe we should rename it into
upgrade/v1/Tails/2.0/i386/alpha/upgrades.yml or create another one for
2.0. But I might as well be mistaken and I don't know what UDF for
future versions are for.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails - Feature #5991] Include BitTorrent software

[sajolida]

Spencer:
>>> I'm in favor of documenting how to use Torrent over I2P
> 
> How should this move forward?  Reading the last message I think I
> assigned it to you without asking; my bad :)
> 
> I can figure out how to document this but I thought I should ask first:
> should I be the one to document this?

It's great if you want to work on this yourself. I think that to start
with, you could:

1. Test this yourself as I'm afraid nobody else has enough knowledge
about this to really help you.

2. Look for other documentation about this online. For example, is there
any documentation about that already written by I2P.

3. Write a step-by-step synopsis of the actions needed to download a
torrent in Tails, from booting it to accessing the downloaded file in
Nautilus for example.

4. While doing so, gather any relevant information that makes it special
to use BitTorrent in the context of Tails but might not be part of the
step-by-step synopsis nor of external reference documentation (if any).

Then you can send me all this information and I'll help you structure
the documentation.

You should also read our guidelines [0] and the GNOME Style Guide [1]
but this can come after gathering all this info.

[0]: https://tails.boum.org/contribute/how/documentation/guidelines/
[1]: http://developer.gnome.org/gdp-style-guide/2.32/
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release versioning

[intrigeri]

Hi,

apparently you are willing to understand better how this works
(otherwise you would not have bothered writing the message I'm
replying to), so here we go:

sajolida wrote (01 Dec 2015 12:44:46 GMT) :
> I don't know what this UDF is used for as 1.9 will never exist, but
> maybe we should rename it into
> upgrade/v1/Tails/2.0/i386/alpha/upgrades.yml

Until we merge feature/jessie into devel, all builds from the devel
branch believe that next major release is 1.9, and then running the
test suite on ISOs built from devel still need that UDF.

Note in passing: we cannot simply *rename* a UDF this way: its content
matters more than the URL, and is authenticated.

> or create another one for 2.0.

We always need a UDF for release N+1 immediately after N has been
released (in this case, N=1.8 and N+1=2.0), for the reason
I explained above.

The good news is that our release process guarantees this invariant,
and I don't think the current situation adds any specific requirement
of its own.

=> I still don't think there's anything to update :)

> But I might as well be mistaken and I don't know what UDF for
> future versions are for.

They're only used by ISOs built from development branches (unless I'm
forgetting another usage, which is entirely possible).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Installation Assistant (+ ISO Verification Extension + Tails Install in Debian): release schedule

[sajolida]

Giorgio Maone:
> On 30/11/2015 20:32, sajolida wrote:
>> Giorgio Maone:
>>> thank you for your time filing those tickets :)
>>>
>>> However, if you set some kind of priority on them, I'll start from the
>>> highest attempting to fix as much as possible, always aiming for the
>>> full package of course.
>>
>> Ok, so I set elevated prio on:
>>
>>   - #10686: Network disconnection shouldn't make download fail in DAVE
>>   - #10678: Prevent DAVE from reloading the page every 10s
>>
>> And lowered prio on:
>>
>>   - #10685: Change in IDF should reset DAVE (← needs a confirmation)
> 
> Confirmed, DAVE currently fetches the IDF (and therefore resets itself)
> every time either the browser starts, or the extension gets
> updated/installed/enabled after being disabled.

Ok, so let's stick to low priority for the beta then.

> Therefore this ticket is basically about forcing the IDF to be reloaded
> every time you load the UI page, or even more often (e.g. by setting a
> timer which reloads it every 3 minutes or so if the UI is currently
> shown), correct?

There might be some ambiguity on what you call "reloading the IDF", so
I'll elaborate just a bit.

The IDF should definitely be fetched again each time the user reloads
the page and the extension should check if the IDF changed. If the IDF
changed, then the state of the extension should be reset ("verified"
should go to "download"). Imagine people who don't close their browser
for days, they might download the ISO image one day, give up in the
middle of the installing instructions and reopen the page 5 days later.
We should ask them to download a fresh ISO in case the IDF changed.

But we shouldn't ask these same people to download again if they reload
the page but the IDF is still the same. During the UX tests, quite a few
people switched from one installation scenario to the another, and
having DAVE still marked as "downloaded and verified" even if you switch
scenario is definitely helpful: people don't have to download and verify
the ISO again to try another scenario.

Now, I'm not sure what should happen if the IDF changes *in the middle
of the download* (you close your tab and open it again) but that's a
corner case and I'm fine with having DAVE validate this download. These
people are unlucky anyway...

Regarding "setting a timer which reloads it every 3 minutes or so" that
would be helpful for people who might keep the tab open for days with an
ISO image already downloaded; as these people are not reloading the
page. But then, how we transmit this information to them might be
complicated. Changing the state of the verification without them
reloading the page feels wrong. I'd say this is a corner case as well,
and I'm fine with not modifying the validation we gave them already.

Ah, and for people who might open the page and not start the download
immediately, then maybe the IDF should be checked upon when actually
starting the download. I don't know when you're doing that exactly in
the process right now.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Installation Assistant (+ ISO Verification Extension + Tails Install in Debian): release schedule

[sajolida]

intrigeri:
> (I'm stealing parts of the "Tails Installer in Debian" work from
> u for the rest of the year.)
> 
> sajolida wrote (27 Nov 2015 15:37:56 GMT) :
>> So by December 15 we would need to have:
> 
>> - The Debian and Ubuntu packages ready in backports and PPA. So we can
>> do the beta with the final instructions for them.
>> [...]
>> Does that seems feasible to you?
> 
> For Debian: I re-uploaded the package yesterday to fix some issues
> (#8557), and it takes quite some time to go from the NEW queue to
> backports (for details, see the answer I wrote last time you asked).
> So best case we'll have the package in sid and maybe testing, but my
> advice is that you should really not count on it being accepted in
> jessie-backports by December 15.

So I guess we'll document that it's only available in testing and sid
for the beta. I'll have to document how to check whether you are running
testing or sid and that might be the funny part.

> In a PPA: yes (I'll let u double-check and commit to it herself
> though).

Cool!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.