anonym wrote (09 May 2014 10:38:41 GMT) :
> Tails developers and contributors, are you available for testing the
> respective releases on:
> * RC testing on 2014-05-29 (preliminary)
Yes.
> * Final testing on 2014-06-09 afternoon and early 2014-06-09, CEST
You probably mean "2014-06-09 afternoon
Kill Your TV wrote (10 May 2014 17:19:40 GMT) :
> In any case, the diff looks sane and the results were good.
> I'd merge.
Thanks, merged. Triggered a Jenkins build to check that the changes to
vagrant/provision/assets/build-tails don't break it.
Cheers,
--
intrigeri
| GnuPG key @ https://ga
Sina S wrote (10 May 2014 16:36:33 GMT) :
> It's at least listening on 443, but unfortunately my torrent-foo is
> not strong enough to know how to test whether it actually will serve
> torrents. I tried to modify the .torrent file but it didn't work,
> looks like there is some binary data in the fi
On Fri, 9 May 2014 07:15:20 + (UTC)
intrigeri wrote:
> Kill Your TV wrote (08 May 2014 21:34:49 GMT) :
> > I updated the ticket with pretty much the same text as here.
>
> Great. Do you want to take care of the code review too?
>
> (I don't mind merging it eventually, but given my Vagrant-
On 11 May 2014 02:21, intrigeri wrote:
>
> Hi,
>
> Sina S wrote (10 May 2014 16:15:17 GMT) :
> > I just noticed the tails torrent tracker is using http.
>
> Nice catch. Care to try if the same tracker is listening HTTPS, and
> perhaps ask r...@gresille.org if unsure?
It's at least listening on 44
Hi,
Sina S wrote (10 May 2014 16:15:17 GMT) :
> I just noticed the tails torrent tracker is using http.
Nice catch. Care to try if the same tracker is listening HTTPS, and
perhaps ask r...@gresille.org if unsure?
> Doesn't this leave users of the tracker vulnerable to man in the
> middle attacks
Hi guys,
I just noticed the tails torrent tracker is using http. Doesn't this leave
users of the tracker vulnerable to man in the middle attacks? Obviously the
user can verify the sig once downloaded but if the torrent has been
attacked then the sig included in the download can't necessarily be tr
Hi,
tl;dr: none of the usecases that fail with the proposed branch work in
Tails 1.0 either, so I think this branch can be merged as-is — it only
brings the expected improvements, and nothing more.
anonym wrote (25 Apr 2014 14:04:44 GMT) :
> I tested it, and with the new shared-mime-info nautilus
Hi,
anonym wrote (08 May 2014 15:52:25 GMT) :
> intrigeri, please review and merge test/6559-adapt-test-suite-for-Wheezy
> into devel.
Here's my review. Test suite run in progress, I'll inspect results and
report back later (likely tomorrow).
Commit a767bfb ("Add I2P repo to the APT sources test
intrigeri wrote (10 May 2014 13:27:54 GMT) :
> 1. Go back to cirrus graphics, until we have time to sort out the
>issues I'm seeing with QXL (ticket++, please)
> 2. Use kvm64 as a basis (with match='minimum'), and add Westmere- and
>SandyBridge-specific features in "optional" mode, that is
intrigeri wrote (09 May 2014 16:27:14 GMT) :
> I think it raises the bar way to high in terms of hardware needed to
> run the test suite. I also tried:
> * Westmere: my CPU isn't good enough
Works for me on another (sid) host system.
> * Nehalem: fails to start X
Confirmed on another (sid)
anonym wrote (09 May 2014 14:24:40 GMT) :
> Because of all this I've finally concluded that I would prefer to keep
> on maintaining our "sikuli/rjb adapter" for the time being, and possibly
> return to this upstreaming process if Rukuli shows promise to at least
> stay maintained for the foreseeabl
12 matches
Mail list logo
