[Tails-dev] Release schedule 3.7

[bertagaz]

Hi,

I'm doing the 3.7 bugfix release, which is supposed to happen on
Wednesday.

Due to other matters, I did not send a release schedule, so here's a
late one:

* 2018-05-07:
  - All branches targeting Tails 3.7 *must* be merged into the
`stable` branch by 6:00 pm, CET. (contact me if some of your changes
needs an exception to that)
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 3.7 ISO image and IUKs.

* 2018-05-08
  - Hopefully start testing Tails 3.7 that was uploaded during the night.

* 2018-05-09:
  - Finish testing Tails 3.7 by the afternoon, CET.
  - **Release 3.7** (Firefox 52.8, bugfix release)

Usual testers, you'll receive the usual testing message later today,
sorry for the inconvenience of this late message.

Others that want to help are encouraged to email me privately (unless
you are fine with sharing your availability in public on this thread :).

Cheers!
___
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] Release schedule for Tails 3.6

[bertagaz]

Hi,

I'll be the release manager for Tails 3.6, which is a major release scheduled
on 2018-03-13. The list of tickets targeting Tails 3.6 can be found here:

https://labs.riseup.net/code/projects/tails/issues?query_id=277

Below you'll find the preliminary release schedule for Tails 3.6:

* 2018-03-01:
   - Feature Freeze: All feature branches targeting Tails 3.6 should
 be merged into the `devel` branch by noon, CET. I'm open to make
 exceptions if you can be online and responsive during that
 afternoon, but ask me first!
   - Build and upload Tails 3.6~rc1.
   - Start testing Tails 3.6~rc1 during late CET if building the image
 went smoothly.

* 2018-03-02:
   - Finish testing Tails 3.6~rc1 by the afternoon, CET.
   - Release Tails 3.6~rc1.

* 2018-03-12:
  - All branches targeting Tails 3.6 *must* be merged into the
`testing` branch by noon, CET.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 3.6 ISO image and IUKs.
  - Hopefully start testing Tails 3.6.

* 2018-03-13:
  - Finish testing Tails 3.6 by the afternoon, CET.
  - Release Tails 3.6 during late CET.

Testers, please let me know:

* if you are available on 2018-03-01, late afternoon CET

* if you are available on 2018-03-02, morning to afternoon, CET.

* if you are available on 2018-03-12, late afternoon CET.

* if you are available on 2018-03-13, morning to afternoon, CET.
___
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] Tails 3.1 release schedule

[bertagaz]

Hi,

As it sometimes happen, I'll be the 3.1 release manager. I've finally settled
on a schedule for it, here it is:

 * 2017-08-04, noon: all branches targeting Tails 3.1 must be merged
 
 * 2017-08-05: Import Tor Browser 7.0.2, build and upload Tails 3.1
 
 * 2017-08-06: Start testing Tails 3.1
 
 * 2017-08-08: Release 3.1 (Firefox 52.3)

Manual testers, please tell me (privately if you prefer) your availability to
test this release. Given it will be a summer release and people may not be that
available for testing, I'd appreciate to know in advance if none of the usual
testers will be able to take care of that so that I can organize.

bert.
___
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] Jenkins build/test failure notifications are back!

[bertagaz]

Hi,

You may remember we had to disable our CI notifications due to too many
false positives. That lead us realizing that most of the developers were
simply ignoring them all.

Since then we have made progress on our test suite to get it more
robust, as well as in our CI infra.

So we are putting notifications back on track but with some limitations:
only branches for which tickets are set "Ready for QA" in Redmine will
have notifications enabled, at least in a first step.

We will track closely how many notifications were sent, and how many of
them shouldn't have. We also count on you to tell us when you start
ignoring this notifications again. Feel free to communicate with us if
you have any question, doubt or concerns, at tails...@boum.org (OpenPGP
public key is available on keyservers).

bert.
___
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 build system update

[bertagaz]

Hi,

On Wed, May 10, 2017 at 01:06:27PM +0200, intrigeri wrote:
> bertagaz:
> > we strongly advise to have a look at the build documentation
> > [2] and adapt your usage.
> > [...]
> > [2] https://tails.boum.org/contribute/build
> 
> I see no recent change made to this page. Perhaps the doc update was
> merged only on other branches? If so, please ensure the doc on the
> master branch is up-to-date. Thanks!

I forgot to merge the related branches in master when releasing this
build system changes. I've fixed that since then, as branches based on
master were failing to build in Jenkins. The doc should now be
up-to-date.

bert.
___
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] Tails build system update

[bertagaz]

Hi,

In order to get Tails builds reproducible, we had to refactor the way we
use vagrant in our build system [1]. Under the hood, a lot of our build
scripts have changed, but for most use cases the transition should be
transparent.

We released today all this changes, so for developers that are building
Tails, we strongly advise to have a look at the build documentation
[2] and adapt your usage.

[1] see tickets #11972, #11979, #11980, #11981 or #12409
[2] https://tails.boum.org/contribute/build

bert.
___
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] Tor Browser 6.0.6 is ready for testing

[bertagaz]

Hi,

On Tue, Nov 15, 2016 at 08:18:00AM +, Georg Koppen wrote:
> FWIW: we are rebundling a final time to fix an issue with our donation
> banner affecting OS X users. Just that you don't get confused as soon as
> a -build8 shows up.

Thanks for the notice! Would have scared me otherwise. :)

bert.
___
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] Tor Browser 6.0.6 is ready for testing

[bertagaz]

Hi,

On Thu, Nov 10, 2016 at 05:50:00PM +, Georg Koppen wrote:
> 
> Tor Browser 6.0.6 is ready for testing. Bundles can be found on
> 
> https://people.torproject.org/~boklm/builds/6.0.6-build5

Thanks!

I see there's 6.0.6-build6 now, which seems to contain only minor
changes related to the donation campaign. Should we rather include this build
in Tails now?

bert.
___
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] [tor-project] Anything wrong with "March 22-28, Amsterdam"?

[bertagaz]

Hi,

On Wed, Oct 19, 2016 at 12:32:22PM -0400, intrigeri wrote:
> 
> Roger Dingledine:
> > We're considering to do our next big meeting March 22-28, 2017, in or
> > near Amsterdam.
> 
> These dates fit quite nicely with the in-person Stretch sprint we have
> scheduled on March 13-17, that could even be postponed a tiny bit to
> leave less spare days in between, and lower the total time spent
> traveling for those of us who will attend both events. E.g.
> our Stretch sprint could be moved to March 15-19.
> 
> Thoughts?

Why not, makes sense to try to find dates for our sprint that fit nicely
with the one from Tor.

bert.
___
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] Why Tails partition is non-deterministic?

[bertagaz]

Hi,

[ Ignoring some kind of private answer sent here although it doesn't
belong to this list. ]

On Mon, Aug 08, 2016 at 09:32:17PM +0200, Joanna Rutkowska wrote:
> Is there any special reason why the partition where Tails installs itself is
> non-deterministic? It is thanks to differing timestamps on the filesystem.
>
> This posses a problem for a prudent user who would like to be able to verify
> Tails integrity, e.g. by typing:
> 
> dd if=/dev/sda1 | sha1sum
>
> This might be especially useful if one uses the stick on various computers and
> would like to verify if her USB stick holding Tails installs hasn't been
> modified (e.g. by a malicious BIOS). Yes, I'm aware that the first sector of 
> the
> disk (/dev/sda) would still differ thanks to different partition sizes.

Good question. Did you try and found out that only timestamps were
different? If it is, good news, means it may not be so hard to fix.
Would be nice if you could post your data on our bug tracker
(https://labs.riseup.net/code/projects/tails).

So far we've been focusing on tails-verifier (ticket #7496, waiting for
review...) for people to check their install, so I don't remember if we
explored this.

Bert.
___
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] Our Torbirdy patches needs refreshing

[bertagaz]

On Fri, Aug 05, 2016 at 11:41:37AM +0200, intrigeri wrote:
> bertagaz:
> > Since the 2.5 release, it seems one of our Torbirdy patches are fuzzy, which
> > makes the build of devel (and any branch based on it) fail.
> 
> I suspect you mean "since torbirdy 0.2.0-1~bpo8+1 was accepted in
> jessie-backports" (because this is likely to cause exactly the problem
> you're describing, while the 2.5 release is very unlikely to produce
> it), but I did not check closely yet.
> 
> u & bertagaz: see commits 1a791ff141b76a79e66dfbe5e1899908fe616587 and
> da6ac8bba70b5c14fb9665a671b09c4b83a9aaa9 on feature/stretch.

Yes, I didn't look at the upstream repo at first, so didn't see our
patches were merged. Congrats to the Icedove team!

bert.
___
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] Our Torbirdy patches needs refreshing

[bertagaz]

Hi again,

On Fri, Aug 05, 2016 at 11:44:27AM +0200, intrigeri wrote:
> u:
> > Question 1: how urgent is this?
> 
> In general: keeping the Git tree building is high priority because
> otherwise any development based on the branch that fails to build
> is blocked.
> 
> Right now: I don't know who's working on branches based on devel this
> week. Personally, I guess I'll fix that next time I am blocked by it,
> just like I did on feature/stretch, so _for me_ it's not urgent.

I needed devel to build so I fixed it myself. It meant removing our two
Torbirdy patches. That I did by merging myself my own branch for #11619,
that's bold but given the tiny change I guess that's not too much. I've
tested the autoconfig wizarr and didn't find any regression compared to
2.5 or 2.4. If someone (u?) wants to check again just un case, that'd be
nice. That also meant merging the Tor 2.8 branch, as it has been
released some days ago and our apparmor patch in devel wasn't up-to-date
anymore. Ironically, that's why I wanted devel to build at the first
place.

bert.
___
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] Our Torbirdy patches needs refreshing

[bertagaz]

Hi,

Since the 2.5 release, it seems one of our Torbirdy patches are fuzzy, which
makes the build of devel (and any branch based on it) fail.

I have not really followed this part of Tails development, so I can't really
take care of that myself. Would be very nice if someone from the Icedove team
took care of that.

Here's the excerpt from the build logs:

P: Applying patch 
config/chroot_local-patches/torbirdy-0001-secure-autoconfig-compat.diff...
patching file usr/share/xul-ext/torbirdy/chrome/content/emailwizard.js
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 63.
Hunk #3 FAILED at 75.
Hunk #4 FAILED at 111.
Hunk #5 FAILED at 125.
5 out of 5 hunks FAILED -- saving rejects to file 
usr/share/xul-ext/torbirdy/chrome/content/emailwizard.js.rej
patching file usr/share/xul-ext/torbirdy/chrome/content/emailwizard.xul
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file 
usr/share/xul-ext/torbirdy/chrome/content/emailwizard.xul.rej
patching file usr/share/xul-ext/torbirdy/chrome/content/preferences.js
Hunk #1 FAILED at 37.
1 out of 1 hunk FAILED -- saving rejects to file 
usr/share/xul-ext/torbirdy/chrome/content/preferences.js.rej
patching file usr/share/xul-ext/torbirdy/components/torbirdy.js
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

Cheers

bert.
___
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] Firmware

[bertagaz]

Hi,

On Wed, Jan 13, 2016 at 05:38:58PM -, astro...@sigaint.org wrote:
> 
> I have Intel's Chipsec Linux Driver working for Tails 1.8.2.

Interesting!

> It's written as an open-source automatic installer that downloads all of
> the relevant files before building so that subsequent builds may be
> performed offline.
> 
> I'll be posting the code to github after some cleanup.
> 
> Is there an appropriate vector to share this work with the community?

My bet is that the best to get it included in Tails would be to package
it into Debian, but I don't know enough this software to get how this is
possible or not.

Keep us up to date anyway when you'll publish your code.

bert.
___
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

[bertagaz]

Hi,

On Wed, Nov 18, 2015 at 02:38:00PM +0100, intrigeri wrote:
> bertagaz wrote (18 Nov 2015 12:34:34 GMT) :
> > Intrigeri, what's on your opinion on [...]
> 
> Please give me an explicit deadline.

I probably won't be able to work on it before week 49 anyway, so no
rush, but an answer before would be cool.

> Thanks for asking!

Well, you express a strong blocking position, can't get a real consensus
without an update from you :)

Bert.
___
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

[bertagaz]

Hi,

Sorry for the late reply.

On Wed, Oct 28, 2015 at 04:52:31PM +, anonym wrote:
> sajolida:
> > anonym:
> >> sajolida:
> > From: intrigeri 
> > Date: Tue, 20 Oct 2015 13:08:31 +0200
> >
> > FTR I dislike the idea of blacklisting such branches based on their
> > name. I'm not going to debate it here [...]

Intrigeri, what's on your opinion on the proposed way to blacklist them
made in this thread by anonym and sajolida (see below)? It's not based
on their name anymore.

> >>> 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.

That seems to be the consensus here then, unless someone else raises.

> 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!

Agree, I like this way to encode it. Sounds at least like a nice baby
step to begin with, simple and effective.

This whole thread remembered me the discussion we had earlier about
feature branches, and made me think (again) we could as well use the
cucumber tag facility to lighten the number of tests: if building from a
feature|test branch, run with the --tag $branch_name, so developers can
choose which test they want their branch to be tested against. May be
useful for some branches were we know that it'll break some tests. But
we dropped this idea.

So if everyone agree on the proposal made here by anonym and sajolida, I
guess that's now a new "Code" ticket.

bert.
___
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] Tails test suite deployed in Jenkins

[bertagaz]

Hi,

Since a week or so, we had a preview of how the test suite would run on
the ISO built by Jenkins when there a re changes for the devel, stable
and experimental branches.

Tonight I've deployed this setup for all the active branches in our Git.

Contributors, beware, Jenkins is watching you: now for every commit you
push an ISO will be build and tested!

But be reassured, for now you won't get emails when it fails. We are now
evaluating how much of them Jenkins will send to be sure we won't spam
our dear contributors' INBOX. When the email flow will sound
reasonable, we'll unleash the notifications, and you will get noticed.

One thing you should do to help is to check if the branches you are
working on are up-to-date to their base branch if it is `devel`. If they
don't, you should update them, as there has been some changes related to
this that will help you to get less notifications in the future.
But please don't update all you branches at once, otherwise Jenkins may
have troubles to catch up with the load.

bert.
___
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 contributors meeting: Saturday October 03

[bertagaz]

Hi,

On Tue, Sep 15, 2015 at 12:00:01AM -0700, sajolida wrote:
> The next Tails contributors meeting is scheduled for:
> 
>   Saturday 03 October
>   #tails-dev on irc.oftc.net
>9 pm in Paris
>8 pm in London
>3 pm in New-York
>   12 pm in San Francisco

I won't be able to attend, sorry.

bert.
___
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] jenkins.t.b.o and nightly.t.b.o downtime

[bertagaz]

Hi,

On Mon, Sep 14, 2015 at 04:36:11PM +0200, intrigeri wrote:
> bertagaz wrote (05 Sep 2015 14:52:22 GMT) :
> 
> > Note to those who use it in a script, the link to the latest ISO of a
> > build has changed a bit from
> > http://nightly.tails.boum.org/$BUILD/latest.iso
> > to
> > http://nightly.tails.boum.org/$BUILD/lastSuccessful/archive/latest.iso
> 
> I'd appreciate it there were HTTP redirect rules added to keep
> compatibility with already published URLs.

Where can I get such a list of published URLs? FYI the people from
reproducible.d.n were contacted and updated their cronjob.

bert.
___
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] Sep. 2015 monthly meeting notes

[bertagaz]

Hi,

I just pushed our last meeting notes. For those who attended, please
review and correct.

Bert.
___
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] jenkins.t.b.o and nightly.t.b.o downtime

[bertagaz]

On Fri, Sep 04, 2015 at 03:44:30PM +0200, bertagaz wrote:
> On Fri, Sep 04, 2015 at 10:27:45AM +0200, bertagaz wrote:
> > Due to some infra change (#9597), jenkins.tails.boum.org and
> > nightly.tails.boum.org will be down for some (hopefully short) time
> > today.
> > 
> > Progress will be tracked on the ticket, if you're in need of one of
> > them, have a look there.
> 
> So at the moment jenkins.t.b.o is back online.

And now nightly.t.b.o is back online too.

Note to those who use it in a script, the link to the latest ISO of a
build has changed a bit from
http://nightly.tails.boum.org/$BUILD/latest.iso
to
http://nightly.tails.boum.org/$BUILD/lastSuccessful/archive/latest.iso

bert.
___
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] jenkins.t.b.o and nightly.t.b.o downtime

[bertagaz]

Hi,

Due to some infra change (#9597), jenkins.tails.boum.org and
nightly.tails.boum.org will be down for some (hopefully short) time
today.

Progress will be tracked on the ticket, if you're in need of one of
them, have a look there.

bert.
___
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] jenkins.t.b.o and nightly.t.b.o downtime

[bertagaz]

Hi again,

On Fri, Sep 04, 2015 at 10:27:45AM +0200, bertagaz wrote:
> Due to some infra change (#9597), jenkins.tails.boum.org and
> nightly.tails.boum.org will be down for some (hopefully short) time
> today.
> 
> Progress will be tracked on the ticket, if you're in need of one of
> them, have a look there.

So at the moment jenkins.t.b.o is back online.

I'm doing the first test to see if the infra change goes well.

I had to merge my 'feature/9597-jenkins-share-artifacts-between-jobs`
branch in stable and then in every branch that is being worked on since
the last release (that is eligible to the automated builds), as this
infra change brings some in the `vagrant/provision/assets/build-tails`
script that thus need to be merged everywhere.

So people, if you intend to push a new branch or refresh an old
one, please first merge back its base branch in it.

I met conflicts in two branches:
test/5847-fix-global-vs-class-variables-issue and
test/6094-improved-snapshots

I'm not very sure about the way I resolved them, so it the author of
this branch can have a look that'd be great. I hope I didn't break
anything!

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

On Wed, Sep 02, 2015 at 01:12:39PM +0200, intrigeri wrote:
> 
> I think that's not a blocker for the first iteration, though: if videos
> are added between Oct. 15 and Jan. 15, I'm happy :)
> 
> bertagaz, time to create tickets that sum this up, or do we need
> more discussion?

Done, in #10153 and subtickets. Dunno if this parent ticket makes sense,
but I think we'll need one of that kind at some point, and as this
tickets are not blocking for #5288, I preferred this solution. Shall I
add the right deliverable fiels too?

bert.
___
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 schedule for Tails 1.6

[bertagaz]

Hi,

On Fri, Aug 28, 2015 at 12:01:04PM +0200, intrigeri wrote:
> 
> anonym wrote (27 Aug 2015 14:59:02 GMT) :
> > Ideally I would like *everything* (including testing, most notably)
> > but the steps making the release public (announcements on our
> > website/IRC/twitter/Tor blog) to be done late on 2015-09-21.
> > If someone with Git commit rights would like to take over that part
> > (which should be only 5-10 minutes of mindless work, since I will
> > have prepared everything, + waiting for the Mozilla release
> > announcement) I would be very happy.
> 
> I suggest that someone who wanted to get started with RM work (that
> would be... tadam... bertagaz!) does it. I can assist them on IRC
> as needed.

Seems that we had the same idea. :)

I refrained a bit to reply, as to be honest my plate is already quite
loaded for this release cycle. So I may need some more information:
which steps of the release process are we talking about? Is that the "Go
wild!" one?

> > Testers, please let me know:
> 
> > * if you are available on 2015-09-21, and which times of that day.
> 
> I'm available from noon to 8pm CEST/CET.

Same here. Can probably try to be available sooner in the day if
necessary.

> > * if you are available on 2015-09-22, morning to afternoon, CEST.
> 
> I'm available from noon to 8pm CEST/CET.

Can be available in the morning I guess.

bert.
___
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 schedule for Tails 1.6

[bertagaz]

Hi,

On Thu, Sep 03, 2015 at 01:03:41PM +0200, anonym wrote:
> 
> Yes, the "Go wild!" section only. I will have prepared the body for the
> Tor Blog post an made sure to communicate it to you somehow. I (or
> BitingBird? :)) can do the "Bug tracker" section too. So, yeah, it
> should be about 10 minutes of work, really.

Ok, so let say that I'll do that then. I guess I can also take care of
this bug tracker stuffs with BitingBird if you wish.

bert.
___
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] Automated tests specification

[bertagaz]

On Tue, Sep 01, 2015 at 06:59:09PM +0200, anonym wrote:
> On 09/01/2015 12:23 PM, intrigeri wrote:
> > bertagaz wrote (26 Aug 2015 17:52:26 GMT) :
> >> On Wed, Aug 26, 2015 at 03:38:19PM +0200, anonym wrote:
> >>> The current proposal seems to be to only start the automated test run of
> >>> a feature branch when it is marked "Ready for QA". This has overloaded
> >>> the meaning of this status so it no longer alone means that the branch
> >>> is ready for review'n'merge; the reviewer also has to wait until the
> >>> automated tester posts the result to the ticket.
> >>>
> >>> We could get rid of this ambiguity by splitting "Ready for QA" into
> >>> "Ready for (automated) testing" (RFT) and "Ready for review" (RFR). 
> >>> Example:
> >>>
> >>> Let's say I have created a new feature branch and think I'm done. I
> >>> assign it to intrigeri (who I want to review it in the end) and mark it
> >>> RFT. And automated build is triggered, and then a full run of the test
> >>> suite. Let's say the test suite fails. Then it gets reassigned to me and
> >>> marked "Dev needed". I fix the issue (which probably was easier to spot
> >>> for me than it would be for intrigeri, since I did the implementation)
> >>> assign it to intrigeri and mark it RFT again. This time the test suite
> >>> passes, and then the ticket is marked RFR automatically. Also, if I run
> >>> the test suite myself and see it pass, then I can just mark it RFR 
> >>> directly.
> > 
> >> I've think about this issue too. My own conclusion was to add a new
> >> Custom fiels in redmine, that Jenkins would use, so something similar to
> >> yours. The dev mark the ticket as ReadyForQA, then Jenkins run the test
> >> suite on it and send its report modifying that field accordingly.
> > 
> > The way it's conceptualized in Gerrit (and presumably in other similar
> > tools) is that Jenkins is "just another reviewer", that can vote +1
> > or -1 on a merge request. I like this logic. To translate it into
> > Redmine, RfQA means that all reviewers (humans and robots) can start
> > looking at the branch, and Pass means that all reviewers are happy
> > with it.
> 
> Conceptually, I like this.
> 
> > I think it would be overly complicated to encode individual
> > reviews (e.g. the one done by Jenkins) in the QA Check field, and
> > conceptually I prefer to keep QA Check a bit more high level and not
> > give it a finer granularity.
> 
> I certainly agree that my proposal complicates things.
> 
> > So, adding dedicated custom fields seems to be the best option to
> > encode individual review results: "Jenkins OK" would be unset
> > initially, and set to true (= +1) upon successful testing. Upon failed
> > testing:
> > 
> >  * "QA Check" would be set back to "Dev Needed";
> >  * a negative vote from Jenkins is a blocker, so given QA Check has
> >been reset already, I'm not sure it's useful to also set "Jenkins
> >OK" to "false" (which we would have to revert after pushing a fix
> >and setting QA Check = RfQA).
> > 
> > ... and "Human reviewer OK" would work just the same.
> 
> Since pushing stuff into the branch after this field has been set to
> true invalidates the Jenkins' test suite run, would Jenkins monitor for
> this and unset the field, or is it up to the committer to unset it?

Jenkins should probably unset the "Jenkins OK" field by itself if the
test has failed.

> I realize this is not a problem unique to this solution. Any way,
> doing this manually gets hairy since we don't necessarily know which
> commit Jenkins has tested. I suppose it would help if Jenkins also
> posted a message about what commit it has successfully tested. Or
> maybe the field we want to add instead could contain the commit?

Yes, I think that when Jenkins reports the test result, it should also
add in a comment some informations. I think at least which commit it
tested and the link to the test result page.

But as the branch was RfQA, it shouldn't be too complicated to know
which commit was tested, as unless the test fails, this branch is not
really supposed to receive new commits.

> > But this doesn't address the problem anonym pointed to initially, that
> > is "the reviewer also has to wait until the automated tester posts the
> > result to the ticket".
> 
> And the corollary is that it neither solves the problem: reviewers may

Re: [Tails-dev] Automated tests specification

[bertagaz]

Hi,

On Tue, Sep 01, 2015 at 12:04:39PM +0200, intrigeri wrote:
> bertagaz wrote (28 Aug 2015 14:24:51 GMT) :
> >
> > But then, often the screen capture are enought to identify why
> > a step failed to run.
> 
> In my experience, sometimes, what would help understanding the problem
> has disappeared a while ago when we hit the timeout, fail, and take
> a screenshot. That's why I almost always turn on --capture when I'm
> doing TDD.

Ack. Got the point.

> So, I invite you to reconsider the option of storing videos of failed
> test suite runs. A first iteration could keep *all* videos for the
> entire test suite — presumably this should be just a glob to add to
> the list of artifacts we archive, right? If it's more work for you,
> let me know.

No, it shouldn't change much as you say.

> > I don't expect this last one to raise a lot of discussions, so let say that 
> > the
> > deadline for this thread is next Sunday 12pm CEST unless some points are 
> > still
> > not clear. I think the rest has already been discussed and drafted enough.
> 
> Sorry I wasn't available during these 48 hours.

My bad, I don't know why I've put such a deadline, but known OTOH that
you wouldn't be available on the week-end.

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

On Tue, Sep 01, 2015 at 06:57:05PM +0200, anonym wrote:
> On 09/01/2015 12:04 PM, intrigeri wrote:
> > bertagaz wrote (28 Aug 2015 14:24:51 GMT) :
> >> I've also added a new section about the result to keep:
> > 
> >> ## What kind of result shall be kept
> > 
> >> The test suite produces different kind of artifacts: logfiles, screen
> >> captures for failing steps, snapshots of the test VM, and also videos of
> >> the running test session.
> > 
> >> Videos may be a bit too much to keep, given they slow down the test
> >> suite
> > 
> > Do we have data about how much they slow down the test suite on our
> > current Jenkins slaves? See #10001 for partial data about how we could
> > make it less resources-hungry...
> 
> Speculation: Didn't we plan for an extra core for this? I suppose we'd
> need fours cores, for: video capture, sikuli, libvirt (USB emulation in
> particular), cucumber-and-other-stuff. Hmm, perhaps
> cucumber-and-other-stuff are happy with the left over from the other
> cores? So three cores?

We planned for 3 cores per isotester and to be honest I don't think we
have room to add more. We're currently using 43 of the 48 cores, so
reserving 4 more of them won't leave much for the host.

> > And by the way, perhaps having videos optionally split per-scenario
> > would help a lot making good use of such videos: faster download,
> > easier to jump to the failing part, less storage needs on our infra.
> > anonym and Kill Your TV, if you agree it would be useful and not
> > stupid an idea, I can file a non-blocking ticket about it.
> 
> Yes, per-scenario videos would be great (my plan was to do this when we
> have #8947, but whatever, nothing prevents us from having it now). They
> would be more useful than per-feature videos, and actually easier to
> implement AFAICT. Please file a ticket!

+1.

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

On Wed, Aug 26, 2015 at 07:46:17PM +0200, anonym wrote:
 On 08/26/2015 07:21 PM, bertagaz wrote:
  The rational behind my proposal was that it would at least raise the
  issue if there were some external changes that breaks the build of this
  feature branch (mostly, changes in APT/Debian).
 
 ... so this was the point I was gonna make, but apparently forgot. And I
 some how missed your mention of external changes in your response to
 intrigeri. Great, then we're on the exact same page! :)

Yep, that's nice! :)

 I expect things to quickly go out of hand if we do it on every push, but
 hey, my expectations are frequently wrong. I say we try it if it's easy
 to quickly switch to your suggested optimization if needed.

Well, in fact we already decided to use different strategies depending
on the ReadyForQA state of a branch. So it will be implemented at the
beginning. :)

  Yes, cucumber tags were the solution I was thinking about to implement
  this. But I get your do not miss stuffs argument and it sounds
  completely rational to me.
  
  Yet that could be an option we could combine with the previous one
  (test only ReadyForQA branches): we could test only specific features
  for all the dev life of a branch, and then once it is marked as
  ReadyForQA, run the whole test suite on it. That would pretty much looks
  like the way you describe the development of a branch.
 
 Ok, this sounds more acceptable.

I've updates the Future ideas section of the blueprint with this.

I've also added a new section about the result to keep:

## What kind of result shall be kept

The test suite produces different kind of artifacts: logfiles, screen
captures for failing steps, snapshots of the test VM, and also videos of
the running test session.

Videos may be a bit too much to keep, given they slow down the test
suite and might take quite a bit of disk space to store. If we want to
keep them, we may want to do so only for failing test suite runs. But 
then, often the screen capture are enought to identify why a step failed
to run. If we decide to still use them, then we probably have to wait
for [[!tails_ticket 10001]] too be resolved.

Proposal:

 * For green test suite runs: keep the test logs (Jenkins natively do
   that)
 * For red test suite runs: keep the screen captures and the logs.

The retention strategy should be the same than for the automatically
built ISOs.

I don't expect this last one to raise a lot of discussions, so let say that the
deadline for this thread is next Sunday 12pm CEST unless some points are still
not clear. I think the rest has already been discussed and drafted enough.

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

Many thanks for your deep review and opinion share. More below.

On Wed, Aug 26, 2015 at 02:00:25PM +0200, anonym wrote:
 On 07/01/2015 07:19 PM, intrigeri wrote:
  bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
  for feature branches, we could run the full test suite only on the
  daily builds, and either only the automated tests related to the
  branch on every git push, and/or a subset of the whole test suite.
  
  I'm not sure what's the benefit of testing a topic branch every day if
  no new work has been pushed to it. In the general case, as a developer
  I'd rather see them tested on Git push only, with some rate limiting
  per-day if needed.
 
 I would say that testing images built due to a Git push only is good
 enough, but not ideal. We have good reasons for building branches on
 Debian package uploads too, and retrying on builds triggered by that
 would be nice as well.

Yes, the APT upload use case is thought about but reserved for future
developments, it's not supposed to be taken care of in the current
milestone.

The rational behind my proposal was that it would at least raise the
issue if there were some external changes that breaks the build of this
feature branch (mostly, changes in APT/Debian).

  See below wrt. one specific case.
 
 I couldn't find what this refers to.
 
  We can also consider testing only the feature branch that are marked
  as ReadyforQA as a beginning, even if that doesn't cover Scenario
  2 (developers).
  
  Absolutely, I think that would be the top-priority thing to do for
  topic branches: let's ensure we don't merge crap.
 
 It would be great to also ensure that we don't review crap. :) I guess
 that is scenario 2, which we explicitly ignore with this proposal. I'll
 post some ideas about how to deal with that in a separate thread, but I
 guess this is a good start that will give us 95% of what we want.

Ok, so that looks like the way to cut down the number of automated tests
everyone agrees on so far.

Now I'm wondering if we should implement this at first, or just start
with testing all of them on eveyr push and see if we need to switch to
that solution if our infra can't cope with it.

  We can also maybe find more ways to split the automated test suite
  in faster subsets of feature depending on the context, define
  priorities for built ISO and/or tests.
  
  This feels ambituous and potentially quite complex. I say let's design
  something simple and then re-adjust.
 
 I'm not sure I like this idea in principle. With context I assume you
 (bertagaz) mean the context of the change implemented in the ISO to be
 tested, e.g. for an ISO that upgrades Tor, the context is tests that
 uses Tor. It's true that in that case we may only want to run some
 subset of tests that uses Tor, but not Tails USB installation/upgrades,
 for instance. This is in fact something we have done manually, and while
 it has worked quite well, I think we've already missed stuff. After
 all, these subsets would represent the obvious things to test that I as
 an implementer or reviewer probably would explicitly test before asking
 for a review. Hence, only running them wouldn't catch the non-obvious
 edge cases that would be found outside of the subsets.
 
 It should be noted, though, that defining such subsets actually isn't
 very complex. It can be implemented with cucumbers tags, e.g. we could
 have scenarios tagged @networking, @tor, @lan, @persistence,
 @usb_upgrade etc. even in combinations, and then run only scenarios that
 have at least one of the tags we're interested in.

Yes, cucumber tags were the solution I was thinking about to implement
this. But I get your do not miss stuffs argument and it sounds
completely rational to me.

Yet that could be an option we could combine with the previous one
(test only ReadyForQA branches): we could test only specific features
for all the dev life of a branch, and then once it is marked as
ReadyForQA, run the whole test suite on it. That would pretty much looks
like the way you describe the development of a branch.

Could be interesting, especially if a dev is using the test suite as a
TDD solution. But I guess in this case she doesn't need such an input
from Jenkins, she'd already have it by herself.

  The automated test suite MUST be able to run features in parallel
  for a single automated build ISO. This way, if more than one
  isotester are idle, it can use several of them to test an
  ISO faster.
  
  Wow! Not sure if/how this can work out, or actually optimize things
  much, with the upcoming new VM snapshots handling.
 
 I doubt we'll have this for a while and agree with downgrading it to a
 MAY. Or maybe even dropping it, see my answer to the next quite. The
 remainder of the answer under this quote will deal with the issues we'd
 face if we want to do this, for the interested:

Agree on the MAY, I've already updated the blueprint about that.

 The test suite wasn't written with this requirement considered, and
 cucumber

Re: [Tails-dev] Automated tests specification

[bertagaz]

Hi,

On Wed, Aug 26, 2015 at 03:38:19PM +0200, anonym wrote:
 On 06/25/2015 11:41 AM, bertagaz wrote:
 
 Looks great! For the record, I looked at the spec as of commit e70f8e7.

Thanks! I'm cheating, most of the work has already been done when we
designed the autobuilds. :D

  # Facts
 
  Running the full test suite on 1 isotester hosted on Lizard takes
  around 8 hours.
 
 FYI, with the test/6094-improved-snapshots branch (previously
 test/wip-improved-snapshots) a full run on lizard takes ~350 minutes, so
 a bit less than six hours. On my laptop it takes around half that, at
 180 minutes per full run. It seems

I've seen it going up to a bit more thant 400 minutes, depending on the
network.

  We intend to run 4 isotesters, so at the moment we would be able
  to run 12 full test suites per day.
 
 So with test/6094-improved-snapshots we can run 24/6 * 4 = 16 full runs
 per day! :)
 
 OTOH, we'll keep on adding more tests, so these figures will eventually
 becomes obsolete. Until the end of 2015 (when we probably get more
 hardware) I think we can assume that the run time of a full test suite
 will not increase by more than 33% due to new tests, but if we assume
 this worst case scenario, then with the test/6094-improved-snapshots
 branch we end up at your 12 runs per day number again.

I came up to the same conclusions. Let's hope we're right. And we WILL
have new hardware for that anyway. :)

  Scenario 1 : reviewer
 
 vs.
 
  Scenario 2 : developer
 
 The current proposal seems to be to only start the automated test run of
 a feature branch when it is marked Ready for QA. This has overloaded
 the meaning of this status so it no longer alone means that the branch
 is ready for review'n'merge; the reviewer also has to wait until the
 automated tester posts the result to the ticket.
 
 We could get rid of this ambiguity by splitting Ready for QA into
 Ready for (automated) testing (RFT) and Ready for review (RFR). Example:
 
 Let's say I have created a new feature branch and think I'm done. I
 assign it to intrigeri (who I want to review it in the end) and mark it
 RFT. And automated build is triggered, and then a full run of the test
 suite. Let's say the test suite fails. Then it gets reassigned to me and
 marked Dev needed. I fix the issue (which probably was easier to spot
 for me than it would be for intrigeri, since I did the implementation)
 assign it to intrigeri and mark it RFT again. This time the test suite
 passes, and then the ticket is marked RFR automatically. Also, if I run
 the test suite myself and see it pass, then I can just mark it RFR directly.

I've think about this issue too. My own conclusion was to add a new
Custom fiels in redmine, that Jenkins would use, so something similar to
yours. The dev mark the ticket as ReadyForQA, then Jenkins run the test
suite on it and send its report modifying that field accordingly.

But well, the redmine part, as for the automated builds, is a SHOULD, so
it will probably be worked later once the MUST are implemented, a bit
like #9614 (phase two) and children for automated builds (see #9719).

 I do not know if this complicates the current plans too much, so perhaps
 this could be a future improvement. Or perhaps the current plan will be
 good enough in practice. I suppose it's bad in itself to introduce yet
 another QA status, complicating things.
 
 Also a question:
 
And the developer who proposed the merge must be notified
And the ticket should be reassigned to the branch submitter
 
 Is deciding the developer who proposed the merge and the branch
 submitter actually easy? We do not automatically get a mapping between
 Git authors and Redmine users. And parsing the redmine ticket history
 (e.g. who marked the ticket a certain QA status last?) also seems
 hairy, but perhaps it's easy via some API (SQL?) that I'm unaware of?

Yes, the redmine - Jenkins interaction is not so clear yet. I'm
thinking about it and working on it as a procrastination right now, I
have other task to finish before.
For now the only idea we came up with was to host a file that would have
this commit author - redmine user binding.
But to be honest, on the first quick check I made, IIRC all of the devs
had a easy binding: the left part of their email address was
corresponding to their Redmine account.

bert.
___
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] Package Tor Monitor

[bertagaz]

Hi,

On Mon, Aug 24, 2015 at 10:53:43AM +, Alan wrote:
 
 After reading the documentation and the code of the build system
 extensions I use to support python desktop applications
 (python-distutils-extra), I came to the conclusion that your request is
 not supported. I looked for other similar build systems and fails to
 find one with similar functionalities. Not as easy as I though...
 
 I can whishlist this feature upstream, but that won't solve your short
 term problem.

I'm certainly not as knowledgeable as you regarding python and this
distutils-extra packaging thing, but I kinda remembered there are ways
to deactivate or customize some targets with a setup.cfg file.

Some use the [aliases] part of it to have the said used target do what
they want. That's a bit hackish though. You may want to look at
tahoe-lafs sources for that.

Reading http://www.glatzor.de/projects/python-distutils-extra/, it seems
you can configure distutils-extra to disable the build_l18n target with
such a setup.cfg. Not sure that it's the one responsible of your problem
though.

bert.
___
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] Automated tests specification

[bertagaz]

Hola,

On Wed, Aug 19, 2015 at 08:58:32PM +0200, bertagaz wrote:
 
 So please contributors, take some time reading and commenting on this
 blueprint. Most of it is a copy of the automated builds one, as it is
 the next step in the chain and the previous one defined already most of
 our design.
 
 Given it will be deployed in  2 monthes, it's quite the last moment to
 do so, and to make it clear, you won't be able to complain afterward. :)

Ping?

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

On Thu, Jul 09, 2015 at 04:52:12PM +0200, intrigeri wrote:
 
 bertagaz wrote (09 Jul 2015 13:28:23 GMT) :
  On Wed, Jul 01, 2015 at 07:19:04PM +0200, intrigeri wrote:
  bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
 
 Indeed I find it too vague so I've rephrased this paragraph (414e4f3),
 and added (414e4f3) another requirement:
 
  * if applicable, the commit at which the base branch was at, when it
was merged into the branch being built;

Great, fine with me.

 (because we need to run the test suite not from the commit on the
 topic branch, but on the result of merging its base branch into the
 topic branch at that commit)
 
 IIRC I've made it so the build log contains that information, and if
 the build scripts need adjustements to make it easier to retrieve from
 Jenkins (e.g. logging it in a machine-parsable format), let me know,
 I'll be happy to follow-up on this.

Noted. Another way to be sure to test the right {topic,base} branch HEAD
commits could also be to simply copy the workspace from the isobuilder
to the isotester. That's something Jenkins knows how to do.

 Now, it would be good to have feedback from other contributors, in
 particular those who will be directly affected. Let's schedule
 a session to look into this at the summit, shall we?

Yes, we had one but not so much concerned people attended.

So please contributors, take some time reading and commenting on this
blueprint. Most of it is a copy of the automated builds one, as it is
the next step in the chain and the previous one defined already most of
our design.

Given it will be deployed in  2 monthes, it's quite the last moment to
do so, and to make it clear, you won't be able to complain afterward. :)

bert.
___
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] Automated tests specification

[bertagaz]

Hi

Thanks for your answer!

On Wed, Jul 01, 2015 at 07:19:04PM +0200, intrigeri wrote:
 
 bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
  I've prepared a blueprint to start this discussion and take notes of the
  decisions:
  https://tails.boum.org/blueprint/automated_builds_and_tests/automated_tests_specs/
 
 Great work! I've pushed a few minor changes, and a more important one
 (21870e1), on top.

Haha, good catch!

  ## When to test the builds
 
  for base branches, we could envisage to run the full test suite on
  every automatically built ISO (every git push and daily builds) if
  we think that is relevant.
 
 This would be great. A possible optimization would be to do it
 (instead of all base branches, all the time) for:
 
  * the stable branch, so that we're always ready to put out an
emergency release;
  * the branch that next scheduled release will be based on (can be
either stable, or testing, or devel, depending on when in the
release cycle we are).

That sound like a good idea, and would probably cut quite a bit the
number of tests ran per day.

  for feature branches, we could run the full test suite only on the
  daily builds, and either only the automated tests related to the
  branch on every git push, and/or a subset of the whole test suite.
 
 I'm not sure what's the benefit of testing a topic branch every day if
 no new work has been pushed to it. In the general case, as a developer
 I'd rather see them tested on Git push only, with some rate limiting
 per-day if needed. See below wrt. one specific case.

Well, as for automated builds, it would give an idea if the tests do not
pass anymore because of an external change. But I agree that as we have
to cut the number of automated tests ran per day, we might not to bother
with that at the moment.

  We can also consider testing only the feature branch that are marked
  as ReadyforQA as a beginning, even if that doesn't cover Scenario
  2 (developers).
 
 Absolutely, I think that would be the top-priority thing to do for
 topic branches: let's ensure we don't merge crap.

Ok.

  We can also maybe find more ways to split the automated test suite
  in faster subsets of feature depending on the context, define
  priorities for built ISO and/or tests.
 
 This feels ambituous and potentially quite complex. I say let's design
 something simple and then re-adjust.

Agreed.

I've tried to sum this up in a 'current proposal' subsection.

  ## How to run the tests
 
  The automated test suite MUST have access to the artifacts of
  a given automated build corresponding to a given commit, as well as
  to the ISOs of the previous Tails releases.
 
 The ISO of the one last release should be enough, no?

Yes, I admit I wrote this with the tails-history gitannex repo in mind,
which gives access to all the previous releases. But that's
implementation details.

 It also needs to know what commit that ISO was built from, in order to
 run the test suite from the same commit. Surely we can dynamically get
 this information by inspecting the ISO (maybe even in the iso9660
 metadata), if passing through the info via Jenkins is too painful.
 Maybe that's worth a research ticket?

Yes, that's what the phrase means when it says a given automated build
corresponding to a given commit, but maybe that's too fuzzy?
With most of the solution out there in Jenkins to chain build and test
jobs, it doesn't seem complicated to pass a parameter to the test job
containing the value of the commit used in the previous (upstream in
Jenkins) build ISO job.

  The automated test suite MUST be run in a clean environment.
 
 I'm not sure what exactly you had in mind here, but in my experience,
 the test suite is now quite resistant to being run multiple times in
 a row, so don't bother too much about this -- just using
 a fresh --tmpdir should be enough in general. If we really need to
 e.g. reboot the isotesterN VMs between test suite runs, I've looked
 into it a few weeks ago and dumped results of my research somewhere
 (likely in some blueprint). It seemed to be doable, but adds quite
 some complexity that I'd happily skip.

I've seen your commits on this slave reboot between jobs idea and made
some research myself, and it sure looks quite scary. I've updated the
blueprint to detail a bit what a clean environment means and include
your comment.

  The automated test suite MUST be able to run features in parallel
  for a single automated build ISO. This way, if more than one
  isotester are idle, it can use several of them to test an
  ISO faster.
 
 Wow! Not sure if/how this can work out, or actually optimize things
 much, with the upcoming new VM snapshots handling.
 
 Anyway: I doubt we'll have the situation when we have idle
 isotesterN's -- we're rather trying to limit the workload to something
 they can handle -- so perhaps it's not worth putting too much time
 into this? My current feeling is that this is a MAY at best, but I can
 totally be missing something.

Hmm

Re: [Tails-dev] [review'n'merge:1.4.1] feature/9560-tor-0.2.6.9

[bertagaz]

On Sun, Jun 28, 2015 at 03:53:50PM +0200, intrigeri wrote:
 Hi,
 
 I'm very sorry to come up with this request this late in the cycle,
 but we should really upgrade Tor to its latest version. I had started
 doing it a couple weeks ago but my package lacked a patch (because the
 release doc hadn't been updated after we decided to include said
 patch, gah). I resumed work on this today and according to our test
 suite it works fine.
 
 Alan, bertagaz: any taker?
 Another pull request (for #9649) will follow later today.
 
 In any case, I'll have to merge this before building the 1.4.1 ISO.

I can do some reviews tomorrow morning, hopefully both, but happy to see
if Alan manage to do some too. :)

I'll build the ISOs tonight.

bert.
___
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] Automated tests specification

[bertagaz]

Hi,

As the automated builds are soon going to be put in production (yes, they
are), it's time to start the second round of discussion about the next
coming Tails CI feature: automated testing of these automated build ISOs.

Yay!

I've prepared a blueprint to start this discussion and take notes of the
decisions:
https://tails.boum.org/blueprint/automated_builds_and_tests/automated_tests_specs/

So please, sit down, take a breath, take whatever drug you like to focus
and think, and read it carefully. :)

There are a lot of blurry areas to determine.

We should probably start by thinking about the first question: when to
test these ISOs, it will help to refine second one regarding how to test
them.

Developers, members of the test suite team, your opinion is warmly
welcome!

bert.
___
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] Automated builds specification

[bertagaz]

On Wed, Jun 17, 2015 at 10:30:28AM +0200, anonym wrote:
 On 06/16/2015 02:41 PM, bertagaz wrote:
  On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
  anonym wrote (30 Mar 2015 07:48:28 GMT) :
  On 29/03/15 15:04, bertagaz wrote:
 
  Wild (possibly unrelated) idea: instead of only notifying the author of
  the last commit of a topic branch, what about notifying all authors of
  the topic branch since it deviated from the base branch?
 [...]
  Also, I guess we need to filter out authors that are not Tails core
  developers, so they do not get build failure notifications. This applies
  to both packages uploaded (when we upload a package built by a 3rd
  party), and Git (patches). Hmm.
 sure.
  Why?
  
  I think on the contrary it might be useful for people that are not core
  devs to get notifications on build failure.
 
 I'm not sure that contributors will appreciate these notifications.
 
 Any way, at least some core member *must* be notified too since they
 have the power to actually fix it so...

  This makes me think that we should perhaps look at Git committer
  name/email in Git instead of the author.
 
  Indeed, Git has separate committer and author metadata fields for
  each commit. But I don't understand what exactly you're suggesting we
  use them for -- may you please elaborate on this idea?
  
  I don't think it's that important. The only use case I see where it would
  change who gets the notification would be when one of us import a patch
  we received. Then, it is interesting still to use the author field, as it
  means that the notification would be sent to the one who actually wrote
  the patch, and not just to the one who merged it. Or maybe we want both of
  them to be notified?
 
 ... notifying both author and committer seems like a very nice idea.

Ok, as it's quite a change to our current specifications, and is a longer
discussion that might need to see live action going on to decide
something, I've tracked this discussion in a separate ticket:
https://labs.riseup.net/code/issues/9615

Thanks!

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

Just realized while searching for leftovers in this thread that this last
bit of the discussion was still not over.

On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
 
 [This is about builds triggered by uploads to our APT repository.]
 
 anonym wrote (30 Mar 2015 07:48:28 GMT) :
  On 29/03/15 15:04, bertagaz wrote:
  However, one point it raises (added to the blueprint) is determining who
  would be notified of this kind of build on failure.
 
 Given the way we've chosen to implement post-APT-upload builds for
 this first iteration, I have my doubts wrt. whether we can distinguish
 such builds from other ones. It may be that we simply can't, so
 perhaps it doesn't make much sense to discuss failure notification for
 this case in isolation from the general case... because we won't be
 able to implement a different behaviour (yet). Did I miss something?

Agree it doesn't make much sense.

 So, below I'll discuss the general case of build failure notification.
 
  Wild (possibly unrelated) idea: instead of only notifying the author of
  the last commit of a topic branch, what about notifying all authors of
  the topic branch since it deviated from the base branch? E.g.
 
  git log --pretty=format:%an %ae ${BASE_BRANCH}.. | sort -u
 
 Interesting. I seem to remember having seen something like that
 available as an option in Jenkins' Git plugin. I suggest we start by
 notifying the author of the last commit, and keep this alternate idea
 in mind if that's not enough. Thoughts?

Added it to the blueprint as a future possible enhancement if we feel it's
needed.

  Also, I guess we need to filter out authors that are not Tails core
  developers, so they do not get build failure notifications. This applies
  to both packages uploaded (when we upload a package built by a 3rd
  party), and Git (patches). Hmm.
 
 Why?

I think on the contrary it might be useful for people that are not core
devs to get notifications on build failure.

  This makes me think that we should perhaps look at Git committer
  name/email in Git instead of the author.
 
 Indeed, Git has separate committer and author metadata fields for
 each commit. But I don't understand what exactly you're suggesting we
 use them for -- may you please elaborate on this idea?

I don't think it's that important. The only use case I see where it would
change who gets the notification would be when one of us import a patch
we received. Then, it is interesting still to use the author field, as it
means that the notification would be sent to the one who actually wrote
the patch, and not just to the one who merged it. Or maybe we want both of
them to be notified?

bert.
___
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] Build failed in Jenkins: build_Tails_ISO_experimental #2313

[bertagaz]

Hi,

On Tue, Jun 09, 2015 at 07:36:14AM -0700, tails-sysadm...@boum.org wrote:
 + . /etc/jenkins/environment
 + ARTIFACTS_ROOT_DIR=/srv/www
 + /usr/local/bin/clean_old_jenkins_artifacts.rb -t 
 /srv/www/build_Tails_ISO_experimental
 [ArtifactDeployer] - Starting deployment from the post-action ...
 [ArtifactDeployer] - 0 file(s) have been copied from the 
 'https://jenkins.tails.boum.org/job/build_Tails_ISO_experimental/ws/' to 
 '/srv/www/build_Tails_ISO_experimental'.
 [ArtifactDeployer] - [ERROR] - Failed to deploy. Can't find any artifacts to 
 deploy with the following configuration 
 :[includes:tails-*,excludes:,basedir:https://jenkins.tails.boum.org/job/build_Tails_ISO_experimental/ws/,outPath:/srv/www/build_Tails_ISO_experimental]
 Build step '[ArtifactDeployer] - Deploy the artifacts from build workspace to 
 remote locations' changed build result to FAILURE
 Build step '[ArtifactDeployer] - Deploy the artifacts from build workspace to 
 remote locations' marked build as failure

Don't panic, I'm just playing with our Jenkins; I'll repair that.

bert.
___
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] Fw: schneier.com comments

[bertagaz]

Hi,

On Tue, Mar 31, 2015 at 06:27:43AM +, goupille wrote:
 
 Hi!
 
 a user send us that...
 
 cheers.
 
 Begin forwarded message:
 FYI from last 100 comments @ Schneier.com:

This is FUD someone is spreading since some time on the schneier website
comments. She didn't read the warning on top of the
tails-autotest-remote-shell script probably:

# ATTENTION: Yes, this can be used as a backdoor, but only for an
# adversary with access to you *physical* serial port, which means
# that you are screwed any way.

Whisperback send *encrypted* messages to us through hidden services. If someone
is able to change its behavior, is that she is root on your machine and thus
you have other problems.

The same apply for the do_not_ever_run_me script.

 I don't know what I'm speaking about, I've just read the script name.

 You are warned.

Would be a more correct quote rather. :)

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

Sorry, lagging a bit one my emails.

On Wed, Mar 25, 2015 at 04:44:32PM +0100, intrigeri wrote:
 Hi,
 
 anonym wrote (24 Mar 2015 16:50:06 GMT) :
  However, I think the reason I asked for this feature was to trigger
  rebuilds when the feature branch's APT suite has been updated. From
  reading the blueprint it only mentions Git, so I assume the watchdog
  won't look at the feature branch's APT suite state?

That's right, good catch. I tried to add in the blueprint that we want
builds triggered by uploads on APT suites.

However, one point it raises (added to the blueprint) is determining who
would be notified of this kind of build on failure.

Multiple options are maybe to consider:

 * Notify every core devs that has upload access on our reprepro.
 * Change our packaging habits and put our emails in the changelog.

 Short-term mitigation:
 
  1. if anyone really want to trigger an immediate rebuild, they can do
 it manually in the Jenkins interface (people who have upload
 rights to our APT repo also have powerful-enough access to Jenkins
 to trigger builds);
  2. the proposal says that all active branches are built daily, in
 addition to post-Git-push = worst case, the branch will be
 rebuilt within 24h;
  3. if in a hurry, or for whatever reason, you can still force
 a rebuild by pushing a dummy commit (ugly, but it works).
 
 Long-term: it seems quite clear to me that any upload to an APT suite
 should trigger a rebuild of the *directly* affected base branch.
 
 And also, more generally: at some point, whenever a base branch's
 current build is marked as outdated and needing to be rebuilt, be it
 because the base branch was updated in Git or via its APT suite, we'll
 want to trigger rebuilds of indirectly affected active branches as
 well (e.g. topic branches based on that base branch) somehow.
 Note that our resource estimates (and thus, our last round of hardware
 shopping) didn't take this cascade of triggered builds, so we simply
 can't implement that at the moment.
 
 BTW, I've read a bit about Zuul
 (http://ci.openstack.org/zuul/zuul.html) recently, and this made me
 aware of quite a few issues similar to the one you're raising here.
 Lots of food for thought, forwarded to bertagaz already.
 
 Now, let's put things back into perspective: what bertagaz and Jurre
 are working on so far is expending what we currently have to all
 active branches. Of course it doesn't cover everything that should
 ideally be done yet, simply because what we have so far itself
 doesn't. That's merely yet another step towards implementing the ideal
 CI system we need :)
 
 = bertagaz and Jurre, may you please capture this problem, and the
 long-term solution ideas we had, in the Future ideas section of
 the blueprint?

Done in scenarios 14 and 15, please review.

bert.
___
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] [review'n'merge: 1.3.2] feature/tor-browser-4.0.6

[bertagaz]

Hi,

On Sat, Mar 28, 2015 at 07:15:13PM +0100, intrigeri wrote:
 bertagaz wrote (28 Mar 2015 16:30:24 GMT) :
  Everything works fine, except that I can't connect to eepsites when
  testing i2p. It does seem to be the case with 1.3.1 too though, so that's
  not really a regression.
 
 It worked just fine for me when we manually tested 1.3.1, so I suspect
 you may trying it the wrong way.
 
  * Did you wait for I2P to get enough connections to its network?
(Hint: wait 5-10 minutes)

I didn't! Testing time are not really the moments when you let your Tails
sit around. Waiting a bit more, it works.

Starting the i2p browser in a non en-US Tails session, I get this
warning message from torbutton asking if I want to fake my locale on the
web. I'm told that's because we removed the torbutton settings in the i2P
browser. That's not a blocker I believe, so I've merged the branch into
devel and stable. 

bert.
___
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] [review'n'merge: 1.3.2] feature/tor-browser-4.0.6

[bertagaz]

Hi,

On Fri, Mar 27, 2015 at 07:55:28PM +0100, anonym wrote:
 Hi,
 
 Ticket: https://labs.riseup.net/code/issues/9121
 
 Please review and merge into stable and devel.

Build it and started to run the automated tests on it.
Will also do some of the manual ones concerned by this branch.

bert.
___
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] [review'n'merge: 1.3.2] feature/tor-browser-4.0.6

[bertagaz]

On Sat, Mar 28, 2015 at 01:00:24PM +0100, bertagaz wrote:
 Hi,
 
 Build it and started to run the automated tests on it.
 Will also do some of the manual ones concerned by this branch.

I've run successfully this tests from the automated suite:

checks.feature
i2p.feature
pidgin.feature
time_syncing.feature
tor_bridges.feature
tor_enforcement.feature
torified_browsing.feature
tor_stream_isolation.feature
unsafe_browser.feature
windows_camouflage.feature

I've also run most of the manual tests related to the browser.

Everything works fine, except that I can't connect to eepsites when
testing i2p. It does seem to be the case with 1.3.1 too though, so that's
not really a regression.

Shall I merge it then?

bert.
___
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] [review'n'merge: 1.3.2] bugfix/9011-fix-syndaemon-vs-florence

[bertagaz]

Hi,

On Tue, Mar 24, 2015 at 06:05:40PM +0100, anonym wrote:
 
 Please review and merge into stable and devel. Bonus points for also
 merging it into feature/jessie, and then:
 
 git revert 430709a8efad146d30980a2e3377a4e00be3e995
 
 and adding something like This was a Wheezy-specific workaround to the
 revert's commit message.

Merged, nice debuging and sorry to have missed the bonus. :)

bert.
___
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] [review'n'merge: 1.3.2] bugfix/8687-macchanger-return-status

[bertagaz]

Hi,

On Wed, Mar 25, 2015 at 01:26:50PM +0100, anonym wrote:
 
 Please review and merge into stable and devel.

Merged in stable, but forgot devel, thanks to have corrected this.

bert.
___
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] Fwd: [Mozilla Enterprise] Firefox ESR 31.5.2 release

[bertagaz]

On Sat, Mar 21, 2015 at 11:57:52AM +0100, intrigeri wrote:
 Hi,
 
 seems like we should start preparing an emergency point-release...
 what are you folks availability or lack thereof to prepare it, test
 it, and get it out of the door?

I can find time this week end and on Monday or Tuesday.

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

On Sun, Mar 01, 2015 at 12:49:35PM +0100, intrigeri wrote:
 bertagaz wrote (27 Feb 2015 10:07:03 GMT) :
  Does that sound better to you?
 
 At least it does sound better to me: the problem at hand is detecting
 the transition of a branch between inactive and active state.
 
 When coming back to a branch after not having worked on it since 6+
 weeks, the first thing I do is indeed to make the branch up-to-date
 wrt. changes that happened in the last 6+ weeks, then making sure it
 still builds locally, and after that I would push the branch and it
 will become active again (from Jenkins' perspective), as
 bertagaz explained.
 
 bertagaz, DrWhax: please explain this on the blueprint -- you now
 have two proposed wordings already so it should be easy :)

Done in e5d21e8.

bert.
___
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] Heads up! Git history has been rewritten, *you* have to do something [Was: Rewriting the Git repository]

[bertagaz]

On Wed, Feb 25, 2015 at 06:57:16PM +0100, intrigeri wrote:
 Hi,
 
 Non-Git-committers can skip what follows, but Git committers should
 probably read it.
 
 Note that Git hooks have been set up so that we should *not* be able
 to mistakenly push obsolete, deleted tags (jenkins-*..) nor any branch
 or other kind of ref that contains any commit from the old history.
 
 And while we were at it, the same hooks also prevent us from
 mistakenly pushing unannotated (unsigned) Git tags, since they're
 a real pain to deal with on the infra side of things (e.g. one cannot
 ensure they propagate correctly once rewritten, among other problems).
 
 If you have ideas of other fail-safe protections we could add there,
 cool, let's discuss that! (in a dedicated thread, though)

Also note that this might be the right time while reconfiguring your git
to remove the old common `user.name` and `user.email` git config we used, as
we decided recently to get rid of that. :)

bert.
___
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] Automated builds specification

[bertagaz]

On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
 On 11/01/15 20:07, Jurre van Bergen wrote:
  https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
 
 Sorry for joining in so late. All looks good, and I only have minor
 concerns.
 
  Developers should be able to trigger automatic builds for a branch
  whose build was dropped (eg. last commit too old) by pushing a dumb
  commit on a timestamp file in that branch.
 
 Can't we make builds trigger via signed email too? Polluting the Git
 repo like that seems ugly to me.

It surely isn't the best for the git history or commit point of view, but
OTOH it express in git's semantic the fact that a branch is active for
more people than Jenkins and the sender of the email. So for example the
release manager can also easily get that info and add the branch on his
radar.

Signed email could be an optional feature, like nice to have, but maybe
not a blocker to deploy the automated builds. It will surely be a bit more
tricky and might delay things a bit.

  How to build it
  [...]
  when building topic branch F, we need to build from branch F once
  merged into branch B. However, this merge must only be done locally, 
 at least because Jenkins doesn't have push access to our Git repo.
  [...]
  This locally-merge-before-building process requires ticket #8654 to
  be implemented [...]
 
 The thing with #8654 is that it's gonna introduce a lot of merge
 conflicts. They will be simple for a human to resolve, so I'm not
 worried about that, but since jenkins will bail out if there's any
 conflict in the ocally-merge-before-building process, this will be annoying.
 
 Here's an example of how the config/APT_suites may evolve for devel,
 feature/x and feature/y, which both have APT suite:

 [...]
 
 In other words, for all branches based on B that modifies
 config/APT_suites, whenever one of them is merged, it will reduce merge
 conflicts for all other branches based on B. This will get problematic,
 so we probably will need a custom git merge conflict handler. It could
 probably be quite simple, since most of the time branches will just be
 added (not removed, renamed) so they can be automatically resolved by
 removing the merge conflict tags.

It seems that this kind of easy merges could be resolved by configuring
.gitattributes to use the union merge for config/APT_suites.

https://code.google.com/p/endgame-singularity/source/browse/.gitattributes

I'm not sure how it handles corner cases though, it might deserve some
tests to see how it fits. Otherwise intrigeri was mentionning another
possibility in Git.

Thanks for the meaningful feedbacks!

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

On Fri, Feb 20, 2015 at 11:56:02AM +0100, intrigeri wrote:
 bertagaz wrote (19 Feb 2015 18:15:35 GMT) :
  On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
 
  I like this idea, simple and effective. :)
 
  So for the base branches, the RM would be the contact point for daily and
  on push build failure notifications. And for topic branches, that would be
  the last commiter.
 
 Agreed. It seems that the blueprint doesn't reflect that, though.

Yeah, I think I was confused because we had different conlusions about
this in the two different sub-threads of this discussion that talked about
it.

 It currently reads:
 
   For base branches:
 
   * When failing after a git push, notify the last commit author.
   * When failing after the daily trigger, notify the RM.
 
 I say let's just always the RM to start with.

I'm not sure about that still: if we proceed this way, we're not
implementing the reviewer scenario, because the RM will be notified when a
branch is merged and breaks the build, and not the one who did this merge.

So, shall we ignore this, and assume that having the reviewer building
locally on her hardware is enough, meaning the RM is the contact point for
all build failures on the base branches?

bert.


___
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] Automated builds specification

[bertagaz]

On Wed, Feb 18, 2015 at 09:51:48AM +, sajolida wrote:
  The Global build stats Jenkins plugin [1] seems interesting to display the
  stats once more logs are kept. Shall I install it?
 
 I would love to have stats about the number of branches and ISO built
 and tested each day to put in our reports to our funders.

Done, one that has access to our jenkins instance can go read some stats
there, and create new charts.

I've also updated the stat page in the blueprint section [1]

Yesterday, 40 ISOs were build on Jenkins...

bert.

[1] https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_stats/
___
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] Git branches to delete: review needed

[bertagaz]

Hi,

On Sat, Feb 21, 2015 at 05:24:51PM +0100, intrigeri wrote:
 Hi,
 
 Please have a look and shout if there's something in there that we
 should keep.

Can't find something that doesn't seem in its place for what I can tell.

 Also, if you're Alan, anonym, bertagaz or sajolida, look for your name
 on that blueprint: there are a few branches I need your opinion about
 = please move them to the appropriate section.

Done.

Awesome to see you tackle this.

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
 bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
  On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
 
  That's a logical awesome idea I'm ashamed not to have had sooner.
  Still, it seems that it comes too late, after some searching it appears
  that our Jenkins don't keep much stats.
 
 As discussed on IRC, we have about 10 days of logs on the filesystem
 currently, so you can still retrieve recent stats about it.
 The earlier, the better, as we're frozen and the more we wait, the
 less the numbers will be meaningful.

I've just pushed a new page in the blueprint section, that contains the
number of branches merged per release (as your script told us), and the
number of builds per day that happened since 2015-02-10.

https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_stats/

  The Global build stats Jenkins plugin [1] seems interesting to display the
  stats once more logs are kept. Shall I install it?
 
 Let's give it a try, yes.

I'll do that soon then.

* Scenario 3 : RM says I need to know when a branch FTBFS, but
  I see no notification mechanism planned, so... how is the RM
  supposed to know. Also, whenever stalled topic branches start
  failing, this can imply an avalanche of daily email to the RM, who
  will of course start ignoring all email from Jenkins and then
  we've lost. I'm particularly worried about this topic since anonym
  (our RM most of the time) didn't comment on this proposal yet, and
  has already expressed concerns about this kind of issues.
 
  I think anonym did comment on this proposal, he did a review of this
  blueprint already.
 
 OK. Let's keep in mind that he may not have thought of this potential
 problem yet.
 
 Now, I wonder if we could solve this quite simply by having the RM be
 notified for *base* branch build failure only. The RM doesn't care
 about topic branches that haven't been submitted for merging
 yet, right?

I like this idea, simple and effective. :)

So for the base branches, the RM would be the contact point for daily and
on push build failure notifications. And for topic branches, that would be
the last commiter.

  One thing that this question also raise is the fact that the RM is not
  always the same person, so I'm wondering how to have jenkins notifying the
  right email depending on who is the RM for the next release. First thing
  that come in top of my mind is... a schleuder address. :)
 
 Indeed, that's the kind of aliases the RMs can trivially update
 themselves, without asking the infra team to do anything.

Great, I'll add that to the specs and will open the corresponding tickets.

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote:
 bertagaz wrote (16 Feb 2015 12:03:12 GMT) :
  Ack, sounds reasonable. However from what I've seen, it sometimes means a
  lot of branches so I wonder if we scaled our infra enough for that, as we
  didn't include this branches in our maths since the beginning of the
  discussion.
 
 This seems like a serious bug in this discussion process. May you
 please then provide example numbers that match what the proposed
 algorithm would output, so that we can reason about it?

I've added to the statistic page the doc branches that have been merged.
Part of them were not in the output of the script because they often get
merged in master. It seems to add 4 to 6 branches per release, but their
development and integration flaw is a bit different.

So in the end, I'm not sure they'll add a lot more load, but we have to
count them in our maths.

bert.
___
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] Automated builds specification

[bertagaz]

On Tue, Feb 17, 2015 at 09:47:51PM +0100, intrigeri wrote:
 bertagaz wrote (16 Feb 2015 14:37:56 GMT) :
  On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote:
  Here's one more: the proposed notification mechanism makes sense to me
  for topic branches. But for base branches, it's more complicated:
 
  Thoughts?
 
  Agree with that as stated in my previous email.
 
 OK, good. Then I'll let you capture in the specification that problem,
 and our currently preferred solution.

Done.

 What follows is only interesting for Jenkins folks. I guess almost
 everyone but DrWhax and bertagaz can stop here.
 
  I think it is doable to differenciate them, by splitting the daily
  and on git push job definiton maybe.
 
 = I think this trick would make the overall thing hard to understand
 and draw conclusions from, for anyone not deeply involved in our
 Jenkins stuff.

That's my opinion too.

  Having a look at plugins might help, as well as how other projects
  do that (as you stated elsewhere).
 
 Yep. At least the obvious candidate (Email-ext plugin) doesn't seem
 able to email different recipients depending on what triggered the
 build out-of-the-box. But apparently, one can set up two 'Script -
 After Build' email triggers in the Email-ext configuration: one emails
 the culprit, the other emails the RM. And then, they do something or
 not depending on a variable we set during the build, based on what
 triggered the build. Likely the cleaner and simpler solution.
 
 Otherwise, we could have Jenkins email some pipe script that will
 forward to the right person depending on 1. whether it's a base
 branch; and 2. whether the build was triggered by a push or by
 something else. This should work if we can get the email notification
 to pass the needed info in it. E.g. the full console output currently
 has Started by timer or Started by an SCM change, but this is not
 part of the email notification. Could work, but a bit hackish and all
 kinds of things can go wrong.
 
 Also, I've seen lots of people documenting crazy similar things with
 some of these plugins: Run Condition, Conditional BuildStep,
 Flexible Publish and Any Build step. But then it gets too
 complicated for me to dive into it right now.

Yes, feel also quite lost in all this big Jenkins ecosystem sometimes. But
it's certainly doable. I'll spend time digging into this too.

 If you prefer, in the future I can dump such research results into the
 blueprint instead of here. Just tell me where it should go.

The blueprint/automated_builds_and_tests/jenkins page seems perfect for
that.

bert.
___
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] Automated builds specification

[bertagaz]

On Wed, Feb 11, 2015 at 11:29:45PM +0100, intrigeri wrote:
 Hi,
 
 bertagaz wrote (18 Jan 2015 16:39:28 GMT) :
  0. Do we think we might also need or want a mechanism to blacklist a branch,
  or we should just assume that our algos will only select the right ones
  and not hit any corner cases?
 
 I think this is a good question, that deserves more thought.
 
 Unfortunately I've not found any discussion about it on the blueprint
 nor on the list, not even an example use case for such a blacklist, so
 right now — sorry to be harsh — it looks like a technical idea that's
 looking for a problem it might help solving.

It's just that, something that did pop up in my head while writing the
blueprint, but I didn't find much corresponding branches while watching
the unmerged ones during the 1.3 release cycle.

 So, what would be the use cases? I can think of a few potential ones:
 
 1. A branch that satisfies the criteria for automatic builds, but
starts failing continuously, e.g. because its developer is on
vacation for 2 weeks.
 
= as far as I understood, only that branch's developer is nagged
by failure notifications, so... who cares if it fails to build for
2 weeks?
 
 2. Branches that modify only the doc or website
 
= indeed, at first glance it seems a bit sad to spend CPU cycles
on building and potentially testing such branches. OTOH, these
branches, like any other, must not break the build, otherwise
they're not fit for merging, so it makes sense to build an ISO
(yes, an ISO, not only the website: we have quite a few things in
the ISO build process that somewhat depend on the website, run `git
grep usr/share/doc/tails/website -- config' if unconvinced).
And they must not break functionality either, so IMO it makes sense
to run the automated test suite on it too (again, we have quite
a few runtime functionality that depends on the bundled static
website).

Ack, sounds reasonable. However from what I've seen, it sometimes means a
lot of branches so I wonder if we scaled our infra enough for that, as we
didn't include this branches in our maths since the beginning of the
discussion.

 bertagaz, any other use case you were thinking of?

Not really at the moment.

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

Thx for the extensive review!

On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
  We're already drafted some scenario's on:
  https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
 
 I have a few concerns, though:
 
   * Scenario 2 : developer doesn't make it clear if branch T is
 build *after being locally merged into branch B*, or not.
 Given that's what we're really interested in, and given
 Scenario 1 : reviewer is clearer (answer is: yes), I guess the
 answer is yes here too, but this should be clarified.

IIRC that was something Alan had troubles with, as not being the way she
usually work on a feature branch, which I think was more close to Work
work work on the branch, and then when the feature is ready, merge the base
branch in it. So she usually do not merge the base branch very often.

But I agree this is not the best way to go, so if Alan doesn't come up with
a block on this, I agree to add the clarification.

   * I see no statistics about how many ISOs we are *currently*
 building each day. So it's not clear to me if our current setup
 can support building N more branches, once a day each. It would be
 useful to have this number (e.g. raw number per day during the 1.3
 release cycle, and daily average). Of course we can fix that later
 (either by throwing more hardware at it, or by tweaking the branch
 selection algorithm a bit, or by decreasing the build frequency
 a bit for some branches based on some criteria), but if we can
 know *right now* that the designed plan cannot possibly work, then
 I would find it a bit sad to invest time into it.

That's a logical awesome idea I'm ashamed not to have had sooner.
Still, it seems that it comes too late, after some searching it appears
that our Jenkins don't keep much stats. I'll extend the jjb setting that
remove build logs after 1 day.

The Global build stats Jenkins plugin [1] seems interesting to display the
stats once more logs are kept. Shall I install it?

   * Scenario 3 : RM says I need to know when a branch FTBFS, but
 I see no notification mechanism planned, so... how is the RM
 supposed to know. Also, whenever stalled topic branches start
 failing, this can imply an avalanche of daily email to the RM, who
 will of course start ignoring all email from Jenkins and then
 we've lost. I'm particularly worried about this topic since anonym
 (our RM most of the time) didn't comment on this proposal yet, and
 has already expressed concerns about this kind of issues.

I think anonym did comment on this proposal, he did a review of this
blueprint already.

But I agree the RM notification part is not very clear.

We could make it so that the RM is emailed when a daily build job fails,
the build failed on git push one being sent to the commit author anyway,
according to our scenarios. Of course the commit author would also be
notified for the daily ones too.
If that's still too much from the RM point of view, we could have the RM
notified only the first time a daily job fails.

That seems to make sense to me: the RM gets a notification in the mailbox
once a day for failed jobs, and then he/she either fix it, or ask someone
to work on that. To have a developer claiming to Jenkins he/she is now
responsible of that branch (and thus is getting the next notifications),
he/she would just have to do a dumb commit on the branch.

One thing that this question also raise is the fact that the RM is not
always the same person, so I'm wondering how to have jenkins notifying the
right email depending on who is the RM for the next release. First thing
that come in top of my mind is... a schleuder address. :)

 I assume these concerns (except the 2nd one probably) are not blocking
 wrt. starting to implement stuff, so: Go!

Great!

 To end with, I find two things confusing in the rest of the document:
 
   * Scenario numbering is reset in the Future ideas section, so one
 cannot simply refer to scenario 2 unambiguously, without making
 it clear if they're speaking of scenario 2 in the Scenarios
 section, or of scenario 2 in the Future ideas section;
 I suggest you avoid assigning duplicated scenario identifiers.

Fixed.

   * The tag T notation (undefined) is somewhat conflicting with the
 branch T one that's defined earlier.

Fixed.

bert.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Global+Build+Stats+Plugin
___
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] review and merge feature/7752-keyringer

[bertagaz]

On Sun, Feb 01, 2015 at 11:49:40AM +, sajolida wrote:
 Emma Peel:
  sajolida sajol...@pimienta.org wrote:
  Ticket: https://labs.riseup.net/code/issues/7752
  Branch: feature/7752-keyringer into devel
  Milestone: 1.3
 
  At the end of the documentation it says:
  
  
  Make sure to update your *dotfiles* each time you use the
  **init**, **teardown**, **destroy**, or **preferences** command
  of *keyringer*.
  
  
  But I don't really understand from this phrase what is it I have to do
  to update. Do I have to run the previous command? If so, I would change
  it for 
  
  Make sure you do this to update your *dotfiles*
  each time you use the **init**, **teardown**, **destroy**, or
  **preferences** command of *keyringer*.
  
  (but English is not my language, maybe there is a nicer version)
 
 Thanks for the review! Does 726c821 solves your issue?

Merged in devel. Congrats!

bert.
___
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] Deadline [was: Re: Automated builds specification]

[bertagaz]

On Wed, Feb 04, 2015 at 12:25:14PM +0100, bertagaz wrote:
 
 Given we had inputs from most of the usual suspects in this discussion
 (sometimes in side channels), and the proposals have been made since a
 little while, I'd say we can put a deadline on:
 
 Sun, 08 Feb 2015 23:59:59 +
 
 So unless no one raises concerns by then, #8657 can be worked on.

Notice (and reminder): by request, this deadline has been extended to:

Wed, 11 Feb 2015 23:59:59 +

bert.
___
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] [review'n'merge:1.3] bugfix/quote-wrappers-arguments (#8830, #8603)

[bertagaz]

Hi,

On Mon, Feb 02, 2015 at 12:27:37PM +0100, intrigeri wrote:
 Hi,
 
 sajolida discovered a bug in the way some of our torifying wrappers
 handle passed-through arguments. This branch fixes that bug, and adds
 automated tests for some of it.
 
 Note that one of these wrappers (connect-socks) affects e.g.
 Git cloning over SSH, which should be tested when reviewing #8680 too,
 so I've assigned this new merge request to bertagaz (who took #8680
 a week ago) for review. bertagaz, if that's not OK with you, please
 de-assign yourself.

Tested by hand, wget and git works fine, so merged into devel. Congrats to
have found and fixed this.

bert.
___
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] [review'n'merge:1.3] feature/7999-Vietnamese-input

[bertagaz]

On Sun, Nov 30, 2014 at 11:07:31AM +0100, intrigeri wrote:

 this branch adds support for Vietnamese input via the IBus
 Unikey engine. Please review'n'merge into devel for 1.3.

I'm not much comfortable with the workaround of Debian bug #714932, I
think the patch lying in this bug report would deserve a NMU, but that's
out of this branch and review, so I merged it into devel after testing it.

bert.
___
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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile

[bertagaz]

On Wed, Feb 04, 2015 at 12:10:31PM +0100, anonym wrote:
 On 04/02/15 11:36, intrigeri wrote:
 [...]
  Good enough? Shall we try that and see? I've implemented #3 already,
  and can do #1 and #2 for Tails 1.3.1.
 
 I'm convinced and have nothing more to add than well done!. :)

I do too. That sounds more bullet-proof than the first iteration.

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

On Mon, Jan 19, 2015 at 08:14:55PM +0100, bertagaz wrote:
 
 On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote:
  bertagaz:
   0. We might also want a mechanism for devs to pro-actively state they 
   want to
   keep their branches being build even if the last commit was older than the
   last release. IIRC
  
  If I understand correctly, adding a dummy commit would bring back my
  branch in the set of branches that are automatically built. So maybe we
  don't need a dedicated mechanism handle those rare cases.
 
 That's the idea, having a timestamp file that would be use for this dummy
 commit. But it comes for free, sure. :)

I had Alan having a look at the blueprint too, she fixed some issues in
the scenario and added one for the future.

The blueprint has been updated with some proposalsi for each question. If
you want to consider them, or propose another one, please have a look.

bert.
___
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] AdBlock Plus in Tails' Tor Browser

[bertagaz]

Hi,

This answer might pop up late now that #8665 is in Ready for QA state,
still it might bring new questions. Sorry for that.

On Fri, Jan 23, 2015 at 12:49:10AM +0100, intrigeri wrote:
 mercedes508 wrote (22 Jan 2015 17:54:53 GMT) :
  And I'm wondering how important the fingerrint issue is, considering
  how easy it is to change it (e.g. by enlarging the browser window),
 
 I'm more concerned about behavioral differences (compared to the Tor
 Browser) that we ship by default (XXX: we haven't summed up what they
 were recently, by the way), than about bits of fingerprinting
 information that every Tor Browser user, be it upstream or within
 Tails, can individually choose to leak.
 
 I'm tempted to propose that on this topic, just like for resizing the
 browser:
 
  * we provide safer defaults;
  * we let users manually opt-in if they want to block ads and diverge
from the Tor Browser anonymity set.

 (Of course the current behaviour for resizing the window is not a good
 implementation of opting-in to diverge, as the security consequences
 of this action are completely non-obvious to the user. There are
 tickets in the right place about asking for a confirmation in this
 case, I think.)
 
 [And I'm starting to wonder if this wouldn't be better to put that
 in the upcoming Tor Browser's security slider. At first glance:

Then if we go for safer defaults, I agree Ad Block+ would be more close to
NoScript in term in UX and fingerprinting.

We could integrate Ad Block+ the same way: installed but disabled by
default.

That sure would be something to discuss further with the TorBrowser
people.

We could help them to upstream our Ad Block+ rules update process.

Shall we engage a discussion about this? That's
https://trac.torproject.org/projects/tor/ticket/9387

 block ads, not JS  block neither ads nor JS  block JS, not ads
   (default)
 
 but once you block JS, your fingerprint is so much different anyway
 that blocking ads on top don't make a big difference, so possibly this
 would be better, although awkward and then perhaps confusing for
 users:
 
 block ads, not JS  block neither ads nor JS  block JS and ads
 
 Food for thought.]

I'm not even sure we need to decouple both, but why not. It might be hard
to fit in the TorLauncher slider though if we want to push this forward.

Bert.
___
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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile

[bertagaz]

On Fri, Jan 23, 2015 at 08:50:28PM +0100, intrigeri wrote:
 
 I'm working on #5525 (Sandbox the web browser), and have an AppArmor
 profile that works locally for most basic use cases. Now, I'm
 wondering how to integrate it into Tails and I need your input.
 
 I think we have two solutions:
 
1. Download upstream profile and apply Tails-specific patch at
   ISO build time
 
2. Ship a forked profile in our Git repository
 
 = I'm in favor of #1.
 
 Thoughts, opinions, volunteers?

While I think I could help with maintaining this profile when it breaks
the build, I'm not much comfortable with this option from my CI hat point
of view. It means that every devs would be notified of this breakage if/when
automatic builds will be deployed. I can see the mailbombing coming, and
devs and contributors ranting on the list.

If #1 is chosen, we could maybe have a dedicated jenkins jobs to test if
our Tails specific patches don't apply.

Also, I'm running myself a Torbrowser contained by an apparmor profile
since something like 4 or 5 Torbrowser releases, and it did break for only
one of them, so this scenario might not happen so often.

Maybe we could also make this build time automatic merge being less
destructive for the build: if the merge doesn't work, the build goes on
but notify that the apparmor profile is out of sync, and that the
torbrowser is probably broken.

So I'm not firmly opposed to #1, and I dislike #2, but would prefer #1 to
be a bit more gentle.

bert.

___
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] Automated builds specification

[bertagaz]

Hi,

On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote:
 bertagaz:
  0. We might also want a mechanism for devs to pro-actively state they want 
  to
  keep their branches being build even if the last commit was older than the
  last release. IIRC
 
 If I understand correctly, adding a dummy commit would bring back my
 branch in the set of branches that are automatically built. So maybe we
 don't need a dedicated mechanism handle those rare cases.

That's the idea, having a timestamp file that would be use for this dummy
commit. But it comes for free, sure. :)

bert.
___
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] Automated builds specification

[bertagaz]

Hi,

Some thoughts and questions, raised in parts from past IRL discussions.
Consider it like a ping for this thread. :)

On Sun, Jan 11, 2015 at 08:07:13PM +0100, Jurre van Bergen wrote:
 Hi,
 
 For the first iteration, which is automatically build of interesting
 branches, we need to specify:
 
  * Which branches we want to build?

We might want to use several algorithms / tricks to select the branches to
be build automatically.

One of this algo could be:

0. Build all {feature,bugfix} branch that are not merged in
stable, devel and testing, and had new commits since the last release.

I have a script that does this roughly and it says that currently, that
means 11 branches. [1]

That would make sense, but might require to have some stats about how much
it has meant for the past releases. I'm not sure how to do that though.

0. We might also want a mechanism for devs to pro-actively state they want to
keep their branches being build even if the last commit was older than the
last release. IIRC

0. Do we think we might also need or want a mechanism to blacklist a branch,
or we should just assume that our algos will only select the right ones
and not hit any corner cases?

Thoughts, answers, ideas?

bert.

[1] bugfix/8680-git-without-polipo
bugfix/8714-tor-is-ready-robustness
feature/6297-save-packages-list
feature/6992-whisperback-email-address
feature/7450-openpgp-applet-exit
feature/7779-revisit-touchpad-settings
feature/8681-test-suite-ramdisk
feature/8719-mount-output-in-bug-reports
feature/jessie
feature/linux-3.18
feature/torbrowser-alpha

___
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] [review'n'merge:1.2.3] feature/8518-save-packages-list

[bertagaz]

On Sat, Jan 03, 2015 at 11:19:21AM +0100, intrigeri wrote:
 Hi,
 
 this is a very simple first step towards implementing #6297.
 The infrastructure (Puppet) bits have already been merged.
 
 The short-term goal is to have reproducible.debian.net track the
 status of the Debian packages we use (#8512) using current data,
 instead of a one-shot imported list as now:
 https://reproducible.debian.net/userContent/reproducible.html
 = I've merged this branch in feature/jessie already.
 
 For consistency, it would be nice to have it merged into stable and
 devel too. Should be safe for stable, given how minimal the changes
 that affect non-Jenkins-builds are.

Works! Merged into stable and devel.

bert.
___
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] idea: stop HDD by default?

[bertagaz]

Hi,

On Tue, Jan 06, 2015 at 04:53:28PM +, flapflap wrote:
 I was thinking whether it makes sense to by default spin-down the
 harddisks, e.g. via hdparm -y /dev/sdX or hdparm -Y /dev/sdX
 
 That would have the advantage of reduced power consumption, less noise
 (up to complete silence when the fan is not spinning), and proof to the
 user that Tails is not accessing the HDD.  Of course, the HDD need to
 spin-up again if the user mounts it.
 
 but what I cannot comment on is whether there may also be difficulties
 from spinning-down the HDD (hardware failure? ...)

We're doing so since 0.8, see https://labs.riseup.net/code/issues/6076

cheers,

bert.
___
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] Lizard services outage

[bertagaz]

Hi,

To prepare Lizard to host its new shiny hardware, it needs to get its
kernel upgraded to the Wheezy-backports one to support such new bones.

But the upgrade seems to raise troubles in the virtual network
firewalling, so expect outages of Lizard's services today while I'm trying
to debug it and get it back on the net.

bert.
___
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] Build failed in Jenkins: build_Tails_ISO_experimental #1457

[bertagaz]

Hi,

On Tue, Dec 23, 2014 at 06:29:31PM +, Alan wrote:
 These are the result of review and merges that built fine on my machine.
 I don't understand where is the problem...

Network troubles as I read it :

  Translation-en 404  Not Found Fetched 24.5 MB in 40min 47s (10.0
  kB/s) W: Failed to fetch
  http://ftp.us.debian.org/debian/dists/unstable/main/i18n/Translation-en
  404  Not Found
  
  W: Failed to fetch
  http://ftp.us.debian.org/debian/dists/unstable/non-free/i18n/Translation-en
  404  Not Found
  
  E: Some index files failed to download. They have been ignored, or
  old ones used instead. P: Begin unmounting filesystems...
  Command exited with non-zero status 100
___
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] [review'n'merge:1.3] bugfix/8082-remove-PulseAudio-warning

[bertagaz]

Hi,

On Mon, Oct 13, 2014 at 12:58:38PM +0200, intrigeri wrote:
 Hi,
 
 please merge bugfix/8082-remove-PulseAudio-warning into devel, for
 Tails 1.3.

Merged, congrats.

bert.
___
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] Please review'n'merge feature/dont_autostart_iceweasel + test/dont_autostart_iceweasel

[bertagaz]

On Thu, Jan 09, 2014 at 05:53:49PM +0100, berta...@ptitcanardnoir.org wrote:
 On Thu, Jan 09, 2014 at 11:52:20AM +0100, intrigeri wrote:
  Hi,
  
  intrigeri wrote (09 Jan 2014 10:26:11 GMT) :
   I patched it so it needs another review before merging. Sorry...
  
   I'll take care of it. Updated the ticket.
  
  Done and merged.
  
  Now, what about the test/dont_autostart_iceweasel branch?
 
 I'm on it now.

Finished, works like a chaem. Merged.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/dont_autostart_iceweasel + test/dont_autostart_iceweasel

[bertagaz]

On Thu, Jan 09, 2014 at 11:52:20AM +0100, intrigeri wrote:
 Hi,
 
 intrigeri wrote (09 Jan 2014 10:26:11 GMT) :
  I patched it so it needs another review before merging. Sorry...
 
  I'll take care of it. Updated the ticket.
 
 Done and merged.
 
 Now, what about the test/dont_autostart_iceweasel branch?

I'm on it now.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/torbutton-1.6.5.3 (#6566)

[bertagaz]

On Sat, Jan 04, 2014 at 01:46:23PM +0100, intrigeri wrote:
 Hi,
 
 the usual Torbutton upgrade before we freeze, brings only one code
 change (clean up the temporary NoScript permissions on New Identity)
 that does not affect us (we don't provide the New Identity feature),
 so that's just for the sake of easing bug reporting upstream etc.
 
 It passes the automated test suite (torified_browsing, unsafe_browser
 features).
 
 Candidate for 0.22.1 = please merge into stable and devel.
 No commits, only an APT merge to do. Assigned to bertagaz, but if e.g.
 Alan wants to do it, I'm sure bertagaz won't mind.

Done, merged in APT into devel and stable. Merged in git into devel, but
wasn't able to do so in stable, as the branch don't contain any changes.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Release schedule for Tails 0.22.1

[bertagaz]

On Sun, Dec 29, 2013 at 04:27:03PM +0100, intrigeri wrote:
 Hi,
 
 here's an update on the 0.22.1 release process. See the bottom part,
 that expects answers from core developers.
 
 intrigeri wrote (08 Dec 2013 17:19:51 GMT) :
  I'm prepared to make exceptions to our usual stable merge rules for
  some edge cases:
 
* upgrading Linux to 3.12, to fix security issues in 3.10; this is
  blocked by #6460 (memory wipe broken with 3.11+); this is high
  priority IMHO. Any taker?
 
 I've made some progress (more failed attempts to fix it), and the
 ticket has more ideas to be tried. It would be really great if someone
 took it over from here.

I understand that, but can't promise much myself on it at the moment.
My plate is already quite filled, but if I find some spare time, I'll have a
look, even if I feel like it's a quite over my capacities.

* enabling incremental upgrades by default, if testing is successful
  enough, and if fixing most important problems is possible with
  minor changes
 
 Looks like this will happen: I expect we can merge
 feature/incremental-upgrades-integration very early in January :)

Yay!

  Core developers: ASAP, please volunteer for the test days, or make it
  clear that you can't make it, so we can reschedule slightly
  if needed.
 
 Ping?

I'm good and should be available for the planned test days.

 Also, the freeze is coming soon, quite a few bugfix branches are
 pending for review'n'merge, and there are more to come soon (Torbutton
 and Iceweasel prefs updates).
 
 bertagaz said he would take care of these ones today:
 
   * #6496 (Drop sqlite3, nss and nspr backports from our APT repository)
   * #6477 (getTorbuttonUserAgent differs from browser user-agent)

I'll finish these tonight, already spend my afternoon testing your
test/rjb-migration branch enhancement.

 ... but those other ones need a reviewer:
 
   * #6478 (Keyboard shortcuts use QWERTY mapping instead of AZERTY on
 French keyboard)
   * #6536 (Windows camouflage script does not set the browser icon to
 IE's one anymore)

If there is no takers, I should be available to review them before the
merge, but I have to admit I'd be glad not to do so: I feel like spending
my time reviewing those times :)

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge test/rjb-migration

[bertagaz]

On Fri, Dec 27, 2013 at 07:36:15PM +0100, intrigeri wrote:
 berta...@ptitcanardnoir.org wrote (27 Dec 2013 09:36:32 GMT) :
  Just one word to sum up my feelings: hurray! :)
 
 :)
 
 The test suite is now entirely green for me, with the two known
 exceptions that are documented (git grep XXX -- features).
 
 Please review my changes and merge it into devel if it looks good!
 Tickets that will go away: #6314, #6399.

Done, merged into devel, haven't seen the test suite in such a good shape
since a long time, congrats!

 The parent ticket (#5731) is still blocked by #6400, as nobody
 commited to either upstream our stuff into the ruby-sikuli Gem, or to
 maintain our own adapter on the long term. I'm unsure what conclusion
 we should draw of it. Admitedly, the new setup is way less scary than
 the previous one, and our adapter is 85 lines long, but still, I'm
 concerned we might happily be replacing it with another kind of
 technical debt.
 
 Shall we just forget about it and close #6400 as rejected?
 Thoughts?

I've had a quick look at a way to implement that upstream. Using the
RUBY_ENGINE variable, it seems easy to have the gem selecting the right
handler depending on which interpreter is used.

Still there are some subtilities in our code that I'm not sure to
understand, this is quite low level, and I'm not sure to be able to handle
this upstreaming myself alone.

 In particular, I'd like to hear what anonym thinks of it.

Me too. :)

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1

[bertagaz]

On Mon, Dec 16, 2013 at 01:42:34PM +0100, intrigeri wrote:
 Hi,
 
 this is a follow-up, with a better fix, to the quick fix introduced by
 bugfix/use-our-own-sqlite.
 
 The details are on the ticket:
 https://labs.riseup.net/code/issues/6496
 
 When merging this branch, please drop the packages listed on the
 ticket from our APT repo. Then, we can 1. drop the corresponding
 temporary APT pinning rules since they won't be needed anymore; 2.
 take care of #6497 (I'm on it).
 
 Assigned to bertagaz for review, candidate for 0.22.1.

Done, branch merged in devel (git and APT repo), packages removed from the
APT repo, in the devel suite.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge bugfix/6536-IE-icon-in-Windows-camouflage-mode

[bertagaz]

On Mon, Dec 30, 2013 at 12:55:39AM +0100, intrigeri wrote:
 berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:37:53 GMT) :
  Candidate for 0.22.1 = please merge into stable and devel.
 
  While testing other branches, I tested this one too, so I merged it too.
 
 Cool! It seems you forgot to merge into stable.

Oh right, will do so.

  Nice catch!
 
 Our automated test suite catched it! :)  No idea why this was not
 detected when it was run for 0.22, but oh well, I guess some earlier
 step was broken, and we did not do the rest of the tests manually for
 some reason.

Yeah, I think I did the tests manually in the end, but didn't notice that
the icon wasn't the right one.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1

[bertagaz]

On Mon, Dec 30, 2013 at 12:53:30AM +0100, intrigeri wrote:
 Hi,
 
 berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:34:43 GMT) :
  Assigned to bertagaz for review, candidate for 0.22.1.
 
  Done, branch merged in devel (git and APT repo), packages removed from the
  APT repo, in the devel suite.
 
 Great!
 
 That's a candidate for 0.22.1, so please merge into stable too (and do
 the APT thing too). If you prefer, I can do it.

Done.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge test/rjb-migration

[bertagaz]

On Fri, Dec 27, 2013 at 01:16:05AM +0100, intrigeri wrote:
 intrigeri wrote (26 Dec 2013 18:17:21 GMT) :
  I don't want to merge this branch with so many failing tests, as one
  expected failure (e.g. due to a missing image update) may very well
  hide other issues that might be caused by the migration to RJB.
 
  So, I've started fixing every test case I could. Doing this in the
  test/rjb-migration branch too, even if it doesn't 100% belong here,
  because IMO this goes with merging this branch.
 
  In the state where I've brought test/rjb-migration today, all tests
  now pass but:
 
* the USB -related tests. Reported as #6537. I'm going to try and
  fix those now.
 
 I believe I've done what #6537 was about, but this feature still fails
 for me a bit later (#6539). I'll try re-running it entirely, but well,
 seeing the installer stuck at various stages of the process is no
 news, and that's why we have never removed these steps from the manual
 test suite yet. So IMO this is not a blocker.
 
* the Windows should appear like those in Microsoft Windows XP
  scenario: in 0.22, the browser's title bar displays the Iceweasel
  icon, instead of the IE one, so it looks like the Windows
  camouflage script misses an update for FF24. Reported as #6536,
  will try to fix in time for 0.22.1 as it's a regression.
 
 I'm testing a fix for this. Once I'm done with validating this part of
 the test suite, I'll ask bertagaz to review all the commits I've added
 on top of what he submitted, and to merge the branch.
 
 Stay tuned, we're getting close :)
 
 /me is very happy to be able to run this test suite in good
 conditions, finally!

I am too, and find it is running quicker than when using Jruby.

I intended to start to fix the outdated scenarios in another branch, as
when I asked for the merge, the rjb test suite was running as good (or
bad, depends how we see) as the previous Jruby implementation, failing at
the same places. So I thought there were no regressions, and the branch
was ok for a merge.

But you spend time doing it (and having fun hacking it seems), and it's
great. I'll reserve some time to test it when you'll send your
review'n'merge.

Just one word to sum up my feelings: hurray! :)

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge test/rjb-migration

[bertagaz]

On Wed, Dec 25, 2013 at 08:36:57PM +0100, intrigeri wrote:
 berta...@ptitcanardnoir.org wrote (24 Dec 2013 11:39:27 GMT) :
  and then run the test suite.
 
 I get the same error you had a week ago or so:
 
   Call to virDomainCreateWithFlags failed: unsupported
   configuration: ich9-usb-ehci1 not supported in this QEMU binary
   (Libvirt::Error)
 
 How did you fix this? If I'm the second one to hit it, perhaps this
 should be documented?

To be honest, it did get fixed almost by itself.

I just played a bit manually with virsh to create the VM while trying to
understand the issue, and at some point it did worked. As I didn't changed
anything really, in the host configuration nor in the VM one, I assumed I
did something wrong at first and there were in fact no issue at all. I
also did a search on Debian's BTS and qemu/libvirt sources to find reports
or changes that might be related, but found nothing.

Did you restart the computer/VM where you installed the test suite after
having done so? I remember I did, that might be why I had it to work.

If you get this issue too, sure it needs to be documented. But we have to
understand it first. :)

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Please review'n'merge test/rjb-migration

[bertagaz]

Hi,

Now that a more recent libvirt containing patches to support the removable
flag for USB devices has been uploaded to Wheezy-backports, I've updated
the test/rjb-migration feature branch so that installation now is easy for
anyone running Wheezy.

Test process of this branch should be to start from a fresh Wheezy
installation (on bare metal or in a VM), and install all the necessary
packages, following
https://tails.boum.org/contribute/release_process/test/setup, and then run
the test suite. Failures that might appear should be related to outdated
scenarios or steps rather than libvirt or rjb problems.

If happy with it, please merge it into devel and experimental.

Tickets to take care of should be #6399 and #6314.

Congrats goes to anonym, who did great work for this migration. I just
tested it works and updated the documentation.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/monkeysign

[bertagaz]

On Wed, Dec 18, 2013 at 12:26:32AM +0100, intrigeri wrote:
 berta...@ptitcanardnoir.org wrote (17 Dec 2013 22:29:20 GMT) :
  I've just reported this problem upstream.
 
  Being the one that raised the issue. I could have done that myself after
  our discussion. Credits, etc...
 
 I felt it was my responsibility to follow-up on the problems that go
 with a branch I've submitted. I'm sorry.

Ah, my bad, didn't think about it that way, and it makes sense. Nevermind
then.

 This confirms that we really need to get you a spare laptop for
 testing :p

Hmm, well, make it two then, as my computer actually don't have a camera.
:) I'll think about it, and if I don't find a way to test it, I'll ask for
someone else to take over.

bert.

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [

[bertagaz]

On Tue, Dec 17, 2013 at 08:36:29PM +0100, intrigeri wrote:
 Hi,
 
 berta...@ptitcanardnoir.org wrote (17 Dec 2013 18:10:18 GMT) :
  Congrats, I'm excited to see this coming in the wild!
 
 :)
 
 ... and I'm scared to discover the remaining bugs we've missed :]
 
  Next steps:
  
   * bertagaz reviews feature/incremental-upgrades-integration (but does
 not merge it yet) and hopefully ACK's it; ETA?
 
  I'll try to do that tomorrow if I have remaining time after the other
  review'n'merge I have planned to do, but that sounds unlikely, so if not I
  should be able to do that before the end of the week. I wanted to test
  this incremental upgrade feature since a while anyway.
 
 IMHO this review (without merge) is higher-priority than the other
 ones you have on your plate (namely: #6477 and #6496).

Ok, then I did test it the way you proposed, and it works great. So I've
marked the ticket QA-Pass, and assigned it to sajolida.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/monkeysign

[bertagaz]

On Tue, Dec 17, 2013 at 10:06:53AM +, sajol...@pimienta.org wrote:
 intrigeri:
  Merged
 
 I push a minor documentation fix with commit f0762cd. Shall I merge it
 myself?

That seems minor and relevant, I guess you can. :)

  even if this might need a bit of documentationi though, as
  monkeysign errors out with a backtrace if one don't use the --no-mail
  option, as there is no /usr/sbin/sendmail in Tails. But the signature is
  added to the key still.
  
  When using the --no-mail option, it outputs quite a lengthy mail, with
  mime headers and all, but that isn't really possible to use it in
  claws-mail, as you can't edit the email source. Best is probably to just
  paste the pgp public key bloc part of it into a new mail.
  
  Doesn't piping it to Mutt work?
  
  monkeysign currently being command-line only, I was thinking more of
  Mutt users than Claws Mail's ones when I thought we wanted this in
  Tails. Hopefully this will change at some point.

I've tried that, but couldn't find a way to have it working. That was a
short session though, I might have missed something.

 Note that monkeysign also includes and graphical tool for fingerprint
 scanning: monkeyscan; with QR codes and all :)

Which doesn't work in Tails, as we don't ship the recommends of monkeysign
(python-qrencode, python-gtk2, python-zbar, python-zbarpygtk). Not sure if
it is that usefull in Tails' usecase though (like, not running on a mobile
platform).

  Regarding the need for documentation, well, I don't think this would
  be a good use of our time. I expect that the kind of public that's
  addressed by a command-line only piece of software will know what to
  do with its output and manpage. Writing monkeysign documentation for
  newbies seems very hard a task to me, and I doubt more than a handful
  of people would benefit from it. If someone wants to make monkeysign
  better suited for other kinds of users, IMHO they should instead write
  a GUI for it, or (even better) integrate it into Seahorse,
  or something.
 
 Agreed. I admit it is sometimes a bit blurry but our position was to
 only document on our website things that were specific to Tails (see the
 Pidgin and OTR documentation for example). So writing a tutorial on
 using monkeysign is out of scope. I admin that some pieces of software
 are documented beyond this requirement already (for example KeepassX)
 but it is also much more advertised and a key feature than monkeysign
 ever will be.
 
 I tried to improve a bit on this by improving the visibility of the list
 of included software from the documentation index. That's commit e8a33f6
 in master.

Agreed. That sounds relevant regarding our actual documentation. Having
given it a bit of tries, I believe monkeysign at the moment is only for
power users, they should be able to get it by themselves. If we want it to
be usable for everyone, I think we'd have to work a bit with upstream so
that it integrates a bit better.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [Was: Please test incremental upgrades (from 0.22~rc1 to 0.22~rc2)]

[bertagaz]

On Tue, Dec 17, 2013 at 06:13:41PM +0100, intrigeri wrote:
 Hi,
 
 I've just released Tails-IUK 0.13, that fixes all coding tasks left
 for phase three. I'm giving it a manual testing session as we speak.
 Please use this version (or later) for any further testing,
 documentation work and comments.
 
 If you want to test the incremental upgrader itself, install Tails
 0.22~rc2, set an admin password, retrieve the latest tails-iuk package
 from our APT repo (http://deb.tails.boum.org/pool/main/t/tails-iuk/,
 or preferably by adding our feature-incremental-upgrades-integration
 suite to your APT sources), install it and run:
 
$ tails-upgrade-frontend-wrapper
 
 Given sajolida agreed and nobody objected, I'm now targetting to ship
 Tails 0.22.1 with incremental upgrades enabled by default (that's the
 stuff in feature/incremental-upgrades-integration), and I've flagged
 the remaining phase three tickets accordingly:
 
https://labs.riseup.net/code/issues/6014
 
 Yay.

Congrats, I'm excited to see this coming in the wild!

 Next steps:
 
  * bertagaz reviews feature/incremental-upgrades-integration (but does
not merge it yet) and hopefully ACK's it; ETA?

I'll try to do that tomorrow if I have remaining time after the other
review'n'merge I have planned to do, but that sounds unlikely, so if not I
should be able to do that before the end of the week. I wanted to test
this incremental upgrade feature since a while anyway.

 while, in parallel:
 
  1. sajolida writes doc (based on the
 feature/incremental-upgrades-integration branch!) and proposes
 various phrasing changes to the UI
  2. I update the code accordingly.
 
 And then, we merge feature/incremental-upgrades-integration, I'll tag
 a 0.22.1~beta1 or something, and I'll prepare a test IUK so that
 anyone can try the latest stuff in realistic settings.
 
 And hopefully the Transifex situation improves soon enough...
 
 Sounds good, did I miss anything?

You have a far better idea of the situation than me, so I'd say you're
probably right. :)

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/monkeysign

[bertagaz]

On Tue, Dec 17, 2013 at 08:27:57PM +0100, intrigeri wrote:
 Hi,
 
 berta...@ptitcanardnoir.org wrote (17 Dec 2013 11:44:11 GMT) :
   Doesn't piping it to Mutt work?
   
   monkeysign currently being command-line only, I was thinking more of
   Mutt users than Claws Mail's ones when I thought we wanted this in
   Tails. Hopefully this will change at some point.
 
  I've tried that, but couldn't find a way to have it working. That was a
  short session though, I might have missed something.
 
 Ah crap, so I've really had you merge something that is *far* from
 being usable out-of-the-box. Still, I think it makes sense to ship it,
 at least for a while, for the reasons I've given previously.

Yep, that's why I merged it.

 I've just reported this problem upstream.

Being the one that raised the issue. I could have done that myself after
our discussion. Credits, etc...

  Note that monkeysign also includes and graphical tool for fingerprint
  scanning: monkeyscan; with QR codes and all :)
 
  Which doesn't work in Tails, as we don't ship the recommends of monkeysign
  (python-qrencode, python-gtk2, python-zbar, python-zbarpygtk).
 
 My intent was to ship these packages in Tails, and it was a mistake
 from my part to act as if we installed Recommends by default: before
 I uploaded these packages to Debian backport, I've verified that each
 of these packages as available in Squeeze. I'll submit a branch that
 installs all that stuff, as it was part of what convinced me it was
 worth shipping monkeysign at all.

Ok, I'll stay tuned, but might not be able to test this fancy feature
*that* extensively (meaning I'll probably just check that the UI starts).

  Not sure if it is that usefull in Tails' usecase though (like, not
  running on a mobile platform).
 
 Most laptops have a camera these days. Making fingerprint verification
 easier is (part of) what makes monkeysign potentially more relevant
 than caff.

Yeah, sorry I have hard time thinking about people showing themselves
their laptop that way, but why not.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge bugfix/tor-0.2.4-is-stable [Was: Build broken, stay tuned (or try bugfix/tor-0.2.4-is-stable)]

[bertagaz]

On Fri, Dec 13, 2013 at 11:50:06PM +0100, intrigeri wrote:
 Hi,
 
 intrigeri wrote (13 Dec 2013 13:38:02 GMT) :
  all our branches currently fail to build since deb.tpo's
  tor-0.2.4.x-squeeze APT source was deprecated, as Tor 0.2.4.x was
  declared stable.
 
 = please review bugfix/tor-0.2.4-is-stable and merge it into stable
 and devel. No ticket.

This has been merged together with the bugfix/use-our-own-sqlite which
contained it.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge bugfix/use-our-own-sqlite

[bertagaz]

On Sun, Dec 15, 2013 at 04:31:17PM +0100, intrigeri wrote:
 Hi,
 
 Mike Homey has made his last Iceweasel package use some in-tree
 libraries instead of the system one, and hence has removed some of
 these libraries from mozilla.d.n's squeeze-backports repository.
 
 Too bad we need these libraries at ISO build time. So, I've imported
 the .deb's we need (sqlite, nss, nspr) into our own APT repository.
 This will be useless once we base our own Iceweasel on the last
 official one that was out today (WIP), but this fixes the Tails ISO
 build for the time being.
 
 Please review'n'merge bugfix/use-our-own-sqlite (sic) into stable,
 devel and experimental. I've not done a full build yet, but at least
 it goes further than the stage at which it used to fail.

You were right, with this branch the build works again. Merged in Git and
APT.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/torbutton-1.6.5.1

[bertagaz]

On Wed, Dec 11, 2013 at 03:13:45PM +0100, intrigeri wrote:
 Hi,
 
 feature/torbutton-1.6.5.1 brings the latest Torbutton in. It fixes
 a bug in the New Identity feature, that we lack, but I expect we'll
 need an even newer version anyway for 0.22.1 or something, so let's
 merge incrementally and detect issues ASAP.
 
 Please review'n'merge into devel (not testing, IMHO it's not worth
 it). bertagaz volunteered to take care of it.

Merged into APT, but git refused to merge it in devel, already up-to-date
it says, surprisingly. :)

Shall I merge into testing and experimental too, now that the release has
been done?

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge bugfix/unsafe-browser-vs.-FF24

[bertagaz]

On Wed, Dec 11, 2013 at 03:15:32PM +0100, intrigeri wrote:
 Hi,
 
 bugfix/unsafe-browser-vs.-FF24 fixes #6479 (Unsafe Browser cannot
 connect to the Internet) for me. Please review'n'merge into testing
 and devel. Depending on how we reschedule 0.22 or not, this will go
 into 0.22 or 0.22.1.
 
 bertagaz volunteered to take care of it.

Merged.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/monkeysign

[bertagaz]

On Fri, Dec 06, 2013 at 08:39:58PM +0100, intrigeri wrote:
 Hi,
 
 please review'n'merge feature/monkeysign into devel (candidate for
 0.23).
 
 Ticket: #6338

Merged even if this might need a bit of documentationi though, as
monkeysign errors out with a backtrace if one don't use the --no-mail
option, as there is no /usr/sbin/sendmail in Tails. But the signature is
added to the key still.

When using the --no-mail option, it outputs quite a lengthy mail, with
mime headers and all, but that isn't really possible to use it in
claws-mail, as you can't edit the email source. Best is probably to just
paste the pgp public key bloc part of it into a new mail.

It's an enhancement, as it automates the key retrieval and signing
process, but might need some more to be really usable by monkeys.

Bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge bugfix/back-to-linux-3.10 [Was: Fix sdmem on Intel graphic hardware, please review]

[bertagaz]

On Mon, Dec 02, 2013 at 02:43:21PM +0100, intrigeri wrote:
 Hi,
 
 intrigeri wrote (01 Dec 2013 19:19:51 GMT) :

Done. Didn't see issues when building and starting it. Plus it had lot of
tests lately. So merged into testing and devel, both in git and APT.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tor Browser branding in Tails?

[bertagaz]

On Mon, Dec 02, 2013 at 09:50:15AM +0100, intrigeri wrote:
 Hi,
 
 anonym wrote (01 Dec 2013 23:51:06 GMT) :
  I'm worried that this may fail several scenarios (and even complete
  features) in the automated test suite. Does the new branding also change
  the icon in the window title? Please see
  features/images/IceweaselRunning.png -- does that part of the new
  Iceweasel/Tor browser still look the same? (Sorry, I don't have time (or
  the bandwidth) to check this myself right now.)
 
 The window titlebar icon doesn't change so I hope it does not break
 the test suite. bertagaz will be running it today, so we'll soon know.

It doesn't. The unsafe browser feature/image does though.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Scripts for importing Transifex translations, please review

[bertagaz]

On Sat, Nov 30, 2013 at 04:08:35PM +0100, intrigeri wrote:
 Hi,
 
 winterfa...@riseup.net wrote (29 Nov 2013 14:14:46 GMT) :
  Please review and merge:
   - repo winterfairy/tails, branch import-translations (based on
 devel)
 
 Merged and pushed some refactoring commits on top. bertagaz should be
 reviewing my own changes soonish. Works fine, thanks!

That sounds good to me, so I think I won't merge it anywhere, since it's
already done. :)

Thanks winterfairy for your quality contributions!

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review'n'merge feature/incremental-upgrades

[bertagaz]

On Thu, Nov 28, 2013 at 06:26:51PM +0100, intrigeri wrote:
 Hi,
 
   1. Someone does the code review, makes sure the changes are
  self-contained enough not to break anything else, and merges into
  devel in time for the 0.22 freeze. No testing at this stage.
  (It's late, just as planned and announced previously.
  bertagaz volunteered to review'n'merge it already.)

Ok, didn't see any problems in there so I merged it, in git and APT. Updated
the tickets too. I hope my lame perl understanding didn't miss something
in iuk's code, but maybe this review wasn't needed.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev