date:20140528

Hi,

intrigeri wrote (11 May 2014 19:45:19 GMT) :
> tl;dr:

>   * If you are maintaining your Tails build VM manually, please
> upgrade your Tails build VM to Wheezy, and install our custom
> live-build package as documented on
> https://tails.boum.org/contribute/build/#manual

I'm curious what's the status on this one. Can we start assuming
everyone is now building on Wheezy?

>   * Else, if you're using Vagrant, or care about it, please upgrade
> our Vagrant basebox (#7218). I *might* do it myself in a few weeks
> or months, as a way to make it easy to contribute to Tails with
> code, but you should absolutely *not* rely on it. Volunteers?

> Note that even if nobody wants to upgrade the basebox to Wheezy,
> given Squeeze's LTS support will likely be done in a different
> archive than the usual Debian one, the basebox will definitely
> need to be updated when Squeeze reaches EOL, that is in a few
> weeks. So, perhaps rebuilding it on Wheezy is not that much more
> work (yeah, I know, last time we had to update the basebox, I went
> with the easy way of updating it in-place, which might not be an
> option for the Wheezy upgrade; but maybe it is :)

Anyone interested?

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] Uwaga - zostały ostatnie 3 dni

2014-05-28 Thread Anna Nowak

Informujemy, że w dniach 27-30 maja 2014 r. odbędzie się
nabór na kurs języka angielskiego.

Jest to IV edycja projektu "Każdy Dorosły Polak Mówi po
angielsku"

Kod upoważniający do 61% zniżki na szkolenie: E1405

Liczba miejsc ograniczona, decyduje kolejnść zgłoszeń.

Zajęcia:

- Angielski dla początkujących (A1/A2),
- Angielski dla średnio-zaawansowanych (B1)

Zajęcia trwają 12 miesięcy.
Wszyscy studenci objęci są opieką metodyczną.

Szkoła Językowa Dobra Zuza jest placówką kształcenia
ustawicznego wpisaną
do ewidencji szkół i placówek niepublicznych prowadzonej
przez m. st. Warszawa
pod numerem 1052 K.

Zaświadczenia o ukończeniu kursu wydawane są na podstawie
§18 ust. 2
rozporządzenia Ministra Edukacji Narodowej z dnia 11
stycznia 2012 r. w sprawie
kształcenia ustawicznego w formach pozaszkolnych (Dz. U.
poz. 186,
z późniejszymi zmianami).

Na zajęcia można zapisywać się indywidualnie lub
grupowo.

Istnieje możliwość otrzymania faktury.

Szczegółowe informacje o naborze dostępne są na stronie:

http://www.internetowekursyjezykowe.co.pl

Dodatkowych informacji udziela sekretariat szkoły pod
numerem:

+48 22 379 65 67 (w godzinach od 8:00 do 17:00)

Jeżeli nie chcesz otrzymywać podobnych wiadomości, to
kliknij na poniższy link:
http://www.internetowekursyjezykowe.co.pl/mailing/unsubscribe.php?email=tails-dev@boum.org

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

Re: [Tails-dev] Postponing 1.1?

28/05/14 00:50, intrigeri wrote:
> anonym wrote (27 May 2014 22:34:53 GMT) :
>> In case I'll be RM for 1.1 (again :)),
> 
> Yes, please :)
>
>> it'd work for
>> me since I'll start travelling to the summit on July 4. I wouldn't
>> necessarily enjoy it, though, because I think I'd like a couple of days
>> off right before the summit. Still, it'd be better than "wasting" summit
>> time on the 1.1 release work.
> 
> Even freezing + RC a few days earlier would be fine, I think.
> It still leaves us a month to get our stuff together.

An even earlier freeze wouldn't work very well with me as RM -- the only
non-Tails plans I have so far for the summer happen during June 19-27,
which already complicates things. With the freeze on July 1 I'm left
with June 28-30 = 3 days of efficient near-freeze RM:ing. So, actually,
this is already quite problematic.

intrigeri, would it be possible to split the 1.1 RM work, at least for
the period when I have other plans? I won't be completely absent ~2 days
during 23-27 June, but I think it's clear that three days right before
the freeze won't be enough, so without some sharing I think this plan
won't work.

For the record, I hadn't planned my summer with me RM:ing for a July 22
*major* release in mind. As far as I know, the original plan was that
you were going to handle the July 22 release (right?). Of course, with
"my" 1.1 release being delayed to that time it only makes sense that I
should take care of it, but it comes with the above mentioned complications.

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.

Re: [Tails-dev] Heads up: update your build environment

Hi!
 
> >   * If you are maintaining your Tails build VM manually, please
> > upgrade your Tails build VM to Wheezy, and install our custom
> > live-build package as documented on
> > https://tails.boum.org/contribute/build/#manual
> 
> I'm curious what's the status on this one. Can we start assuming
> everyone is now building on Wheezy?
> 
I am. Works like a charm.

> >   * Else, if you're using Vagrant, or care about it, please upgrade
> > our Vagrant basebox (#7218). I *might* do it myself in a few
> > weeks or months, as a way to make it easy to contribute to Tails
> > with code, but you should absolutely *not* rely on it. Volunteers?
> 
> > Note that even if nobody wants to upgrade the basebox to Wheezy,
> > given Squeeze's LTS support will likely be done in a different
> > archive than the usual Debian one, the basebox will definitely
> > need to be updated when Squeeze reaches EOL, that is in a few
> > weeks. So, perhaps rebuilding it on Wheezy is not that much more
> > work (yeah, I know, last time we had to update the basebox, I
> > went with the easy way of updating it in-place, which might not be
> > an option for the Wheezy upgrade; but maybe it is :)
> 
> Anyone interested?
> 
Not me.

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.

Re: [Tails-dev] Please review and merge feature/5711-liferea-persistence-preset

Hi,

> intrigeri wrote (26 May 2014 15:32:17 GMT) :
> > * Feeds that I had already fetched, and read some articles from, are
> >   empty after a reboot. When updating it again, the articles I had
> >   read already now appeared as unread. I consider this to be
> >   a clear blocker.
> 
> I realize that the newly introduced preset is documented as persisting
> "subscriptions" only. I don't really see the point in proposing this
> only. Without persistence of the state of feed entries, persistent
> Liferea config is not much more useful than a pile of browser
> bookmarks + "Open all in tabs".
> 
> It looks like the *state* of subscribed feeds lives in
> ~/.local/share/liferea. Indeed, XDG compliance => we can't only
> persist ~/.config/liferea.
> 
I can take care of this feature lack + the bugs pointed in previous
email before the postponded 1.1 freeze. Is there already a way to have
one single preset making two persistence.conf entries?

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.

Re: [Tails-dev] Heads up: update your build environment

28/05/14 10:44, intrigeri wrote:
> Hi,
> 
> intrigeri wrote (11 May 2014 19:45:19 GMT) :
>> tl;dr:
> 
>>   * If you are maintaining your Tails build VM manually, please
>> upgrade your Tails build VM to Wheezy, and install our custom
>> live-build package as documented on
>> https://tails.boum.org/contribute/build/#manual
> 
> I'm curious what's the status on this one. Can we start assuming
> everyone is now building on Wheezy?

Well, I'm using Vagrant only, so no.

>>   * Else, if you're using Vagrant, or care about it, please upgrade
>> our Vagrant basebox (#7218). I *might* do it myself in a few weeks
>> or months, as a way to make it easy to contribute to Tails with
>> code, but you should absolutely *not* rely on it. Volunteers?
>>
>> Note that even if nobody wants to upgrade the basebox to Wheezy,
>> given Squeeze's LTS support will likely be done in a different
>> archive than the usual Debian one, the basebox will definitely
>> need to be updated when Squeeze reaches EOL, that is in a few
>> weeks. So, perhaps rebuilding it on Wheezy is not that much more
>> work (yeah, I know, last time we had to update the basebox, I went
>> with the easy way of updating it in-place, which might not be an
>> option for the Wheezy upgrade; but maybe it is :)
> 
> Anyone interested?

I volunteer to do it (I have other basebox changes on my plate any way),
but I won't give a hard ETA but my goal will be similar to yours, i. e.
to have it done "in a few weeks or months".

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.

Re: [Tails-dev] Please review and merge feature/5711-liferea-persistence-preset

Alan wrote (28 May 2014 12:40:10 GMT) :
> I can take care of this feature lack + the bugs pointed in previous
> email before the postponded 1.1 freeze.

Awesome :)

> Is there already a way to have one single preset making two
> persistence.conf entries?

No. We've guessed a while ago that it will be needed at some point,
but the code doesn't exist yet. I want to write it one of these days,
but definitely not with such a short notice, that late in a dev cycle.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] Postponing 1.1?

Hi,

anonym wrote (28 May 2014 10:28:29 GMT) :
> intrigeri, would it be possible to split the 1.1 RM work, at least for
> the period when I have other plans?

Unfortunately, my own plans don't play very well with yours.

What I can do is:

  * June 1-15: review'n'merge things quickly, as they arrive

  * Around June 16, *maybe* put out a 1.1~beta2, that has gone through
the automated test suite, but not the manual one. If we feel it's
useful, and depending on other Tails deliverables I have.

  * June 16 to June 25: review'n'merge things, fix a few small newly
discovered regressions, but with considerably less bandwidth and
reactivity; hopefully there's not much to do.

Then, you take over on June 28, merge what's left (likely: only my own
pull requests), put a RC out on July 1st, enjoy a few days off, and
join our northern-hemisphere summer gatherings.

To end with, I take over the RM hat on July 2, and keep it until 1.1
is out on July 22.

If we do that, developers should act as if the freeze was on June 15:
large changes have to be *merged* by then (so, they need to be "almost
ready" around June 10, to leave some room for additional round-trips
that may be needed). And the 2nd half of June would be dedicated to
fixing newly discovered regressions.

Would this work for you?

> For the record, I hadn't planned my summer with me RM:ing for a July 22
> *major* release in mind.

Actually, nobody had planned such a thing :)

> As far as I know, the original plan was that you were going to
> handle the July 22 release (right?).

Well, I wouldn't exactly call it the "plan", but that was indeed one
of the only surest things when we tried to tentatively split the RM
work for 2014 Q3 and Q4 three months ago, and as a result we got quite
a vague idea, with plenty of uncertainty and conflicting desires
and needs.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] Postponing 1.1?

28/05/14 16:28, intrigeri wrote:
> Hi,
> 
> anonym wrote (28 May 2014 10:28:29 GMT) :
>> intrigeri, would it be possible to split the 1.1 RM work, at least for
>> the period when I have other plans?
> 
> Unfortunately, my own plans don't play very well with yours.

Really? What you suggest below actually sounds pretty much perfect for
my plans. Or do you mean that it interferes with other plans you had for
June/July?

> What I can do is:
> 
>   * June 1-15: review'n'merge things quickly, as they arrive

I'll be around during this time as well, sharing the review'n'merge work
etc. I do plan to dedicate a few days to the Icedove integration (well,
the preliminaries of it) so something is ready in time for the summit,
as we've discussed before.

>   * Around June 16, *maybe* put out a 1.1~beta2, that has gone through
> the automated test suite, but not the manual one. If we feel it's
> useful, and depending on other Tails deliverables I have.

Since I'm still around at this time (until and including the 18th of
June) I'm also able to prepare a 1.1~beta2.

>   * June 16 to June 25: review'n'merge things, fix a few small newly
> discovered regressions, but with considerably less bandwidth and
> reactivity; hopefully there's not much to do.
> 
> Then, you take over on June 28, merge what's left (likely: only my own
> pull requests), put a RC out on July 1st, enjoy a few days off, and
> join our northern-hemisphere summer gatherings.

I won't promise anything, but it may be possible for me to take one
half-day from my hiatus for dealing with some review'n'merges of yours,
giving you more time to fix potential issues compared to if I only do so
in the last three days before the July 1st "real" freeze. If so, that
would likely be the 25th. Would this be helpful for you? If so I can try
to arrange it in the next couple of days so we'll know if it's possible
at all.

> To end with, I take over the RM hat on July 2, and keep it until 1.1
> is out on July 22.

FWIW, I'll be available again latest the 20th, since I'll be travelling
a bit after the summit. So I should at least be able to help with the
testing of the final 1.1 image.

> If we do that, developers should act as if the freeze was on June 15:
> large changes have to be *merged* by then (so, they need to be "almost
> ready" around June 10, to leave some room for additional round-trips
> that may be needed). And the 2nd half of June would be dedicated to
> fixing newly discovered regressions.
>
> Would this work for you?

Sounds great to me! I'll write a new combined release schedule for 1.0.1
and 1.1 tonight; now I need to focus on getting 1.1~beta1 ready.

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.

Re: [Tails-dev] Postponing 1.1?

anonym wrote (28 May 2014 16:40:02 GMT) :
> 28/05/14 16:28, intrigeri wrote:
>> Unfortunately, my own plans don't play very well with yours.

> Really? What you suggest below actually sounds pretty much perfect for
> my plans. Or do you mean that it interferes with other plans you had for
> June/July?

I mean that what I was suggesting was a compromise between my other
desires and commitments, and the need to have a RM for Tails 1.1.

>> What I can do is:
>> 
>>   * June 1-15: review'n'merge things quickly, as they arrive

> I'll be around during this time as well, sharing the review'n'merge work
> etc. I do plan to dedicate a few days to the Icedove integration (well,
> the preliminaries of it) so something is ready in time for the summit,
> as we've discussed before.

Good.

>>   * Around June 16, *maybe* put out a 1.1~beta2, that has gone through
>> the automated test suite, but not the manual one. If we feel it's
>> useful, and depending on other Tails deliverables I have.

> Since I'm still around at this time (until and including the 18th of
> June) I'm also able to prepare a 1.1~beta2.

Great.

>>   * June 16 to June 25: review'n'merge things, fix a few small newly
>> discovered regressions, but with considerably less bandwidth and
>> reactivity; hopefully there's not much to do.
>> 
>> Then, you take over on June 28, merge what's left (likely: only my own
>> pull requests), put a RC out on July 1st, enjoy a few days off, and
>> join our northern-hemisphere summer gatherings.

> I won't promise anything, but it may be possible for me to take one
> half-day from my hiatus for dealing with some review'n'merges of yours,
> giving you more time to fix potential issues compared to if I only do so
> in the last three days before the July 1st "real" freeze. If so, that
> would likely be the 25th. Would this be helpful for you?

The 25th is already a bit late for me, since I'll be at a conference
on the 27-29, enjoying the hallway track and presenting Tails.

But still, this would be awesome, and very much welcome.

> If so I can try
> to arrange it in the next couple of days so we'll know if it's possible
> at all.

OK.

>> To end with, I take over the RM hat on July 2, and keep it until 1.1
>> is out on July 22.

> FWIW, I'll be available again latest the 20th, since I'll be travelling
> a bit after the summit. So I should at least be able to help with the
> testing of the final 1.1 image.

If you think you can build the final 1.1 as well, don't hesitate
stealing it from me. I mean it.

Alternatively, we could share things a bit, e.g. I could prepare the
.deb's (including the web browser?), Changelog, release notes, and
leave you the rest.

> Sounds great to me! I'll write a new combined release schedule for 1.0.1
> and 1.1 tonight; now I need to focus on getting 1.1~beta1 ready.

Go, go, go :)

Cheers!
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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.1] #6559, #7062, #6275: test/6559-adapt-test-suite-for-Wheezy

Merged, thanks!
___
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 and merge feature/6342-update-camouflage-for-gnome3

Alan wrote (27 May 2014 17:36:04 GMT) :
> - gnome-theme-windows8 (@git.tails.boum.org)

If there's any Debian packaging in there, please assign the ticket
to me.

> - gnome-panel-applet-window-picker (@git.tails.boum.org). Please review
>   C code as I'm not knowledgable enough.

The package builds for me, and Lintian is happy. There are a few
problems, though, including some major ones => a bit more work is
needed. Sadly, most of it would have been avoid if things had been
done right from the beginning. But that's how one learns, I guess :)

This package was converted to a native one. I really don't get why,
and see no indication other than "Update packaging". I doubt we're now
upstream for this code. We don't want to release
window-picker-applet-$UPSTREAM_VERSION.tar.gz, with a different
content, but the same version, as upstream's tarball. Also, I assume
that we'll be happy if Debian or any derivative wants to base their
work on ours, so I think this really ought not to be a non-native one.
That's the top blocker to me.

The changelog entries until 0.5.8-2 (last version that was part of
Debian) were deleted. Same for Ubuntu's changelog entries for
0.5.10-*. Uh? Should be trivial to fix, especially considering that:

A Vcs-Git packaging repo is available in Debian, but apparently our
own one has no shared ancestor with it. I really don't get why. I see
the packaging was somehow inherited from there anyway, before Ubuntu
packaged 0.5.10, so it should be quite easy to get things right.
Reconciliating these histories is perhaps not a blocker for 1.1, *if*
someone commits to do it on their way to getting this package ready
for Debian. OTOH, *now* is probably the best time to rewrite the Git
history. Doing it later will be harder.

Please don't add "configure", or any such auto-generated autotools
files, to Git. That's a blocker.

The Homepage control field points to
https://launchpad.net/window-picker-applet, while you're packaging
a fork https://github.com/lanoxx/window-picker-applet.
That's a blocker.

I see the package build-depends on GTK2 stuff, while the GitHub fork
we're packaging says it's a port to GTK3. Upstream's README mentions
other build-deps, so it maybe something is wrong.

src/common.h is GPL-2+, and not mentionned in debian/copyright. Hint:
`licensecheck -r .' avoids to miss the most obvious problems of this
class. That's a blocker.

You know as well as I do why commit tickets and changelog entries like
"Update packaging" (4 files changed, 20 insertions(+), 104
deletions(-)) are to be avoided, so I won't state the obvious.
Too late for the commit message, but please fix debian/changelog.

And now, a few non-blockers (for 1.1).

The upstream tarball doesn't live in Git, so I had to go retrieve it
from the right suite in our APT repo. No big deal, but in the future
please prefer source format 3.0 (quilt) + git-buildpackage branches
layout, that is self-contained in Git, like we do for basically all of
our non-native packages (and that's also a very popular setup in
Debian as well). Consistency among packaging workflows makes it easier
for others to work on a package they've not touched before, makes the
RM's work easier, lowers the bar to contribution, and increases
chances we understand what we're doing when we type pseudo-random
lines in `$EDITOR debian/...'. Still, that's not a blocker, as long as
someone commits to do it while preparing the upload to Debian.

The obsolete debian/watch was dropped for some reason. It should be
updated instead, to point to the place where you're taking
releases from. Not a blocker, as long as [...].

You were concerned about the security of this code, so I suggest
building with all hardening flags, and not only the default ones, if
possible. Not a blocker, as long as [...].

I see that compat level was raised to 8. I'm curious why not use the
latest one, while you were at it?

Any particular reason why the Git repo isn't called neither the same
way as the source or binary package? If not, I'm happy to rename
it myself.

To end with, I've just documented in our Gitolite config's README how
to properly create a new repo. I've fixed the ones you created.

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.

Re: [Tails-dev] Please review and merge feature/6342-update-camouflage-for-gnome3

Hi,

u wrote (27 May 2014 20:33:43 GMT) :
> I'd be glad to work on it. Would just need a little more information

Awesome! I'll let Alan brief you.

> and also... some time :)

Who doesn't? :)

Cheers!
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] A humble suggestion ...

Hi,

Latuf Tak wrote (10 May 2014 03:32:18 GMT) :
> I was wondering if you've thought about getting Tails out to the general
> public ala "Chrome Cast"?  A hardware dongle with a keyboard or remote?

> Of course, there are plenty of competitors (Roku, etc.), but there's
> nothing out there touting/leveraging/with reputation like your platform on
> a Home Entertainment platform (HTPC).  With USB/HDMI integration in most of
> the new TVs, this seems like a logical step - and the next frontier.

I'm sorry we're replying this late.

I personally are not knowledgeable enough in such platforms and the
specific challenges and user experience it brings, so I have no idea.

Our resources are very limited. We have quite some work on our plate
to make our stuff maintainable, and the project sustainable.
Details can be found on the 2.0 and 3.0 milestone on our roadmap:

  https://labs.riseup.net/code/projects/tails/roadmap

So, to be honest, I doubt any existing core contributor has any time
on their plate right now, to put into developing a second flavour
of Tails.

Still, if people with the right skills and available time are
interested in working on this, I encourage them to go ahead, think
this through, get an idea of what the challenges are :)

Wrt. support, the best way one can help, right now, to make such
projects more plausible in the future, is to contribute to Tails in
some way:

  https://tails.boum.org/contribute/

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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: Re: Secure android headset integration

Hi,

>> Do you mean booting Tails on the phone itself, or using the phone as
>> a USB mass storage device for booting Tails on another computer?
>> 

> Booting from the USB Mass storage off the phone. 

OK, got it.

> Well, good news indeed. We can convert to bitcoin once some amount
> has been collected though :)

This is good too.

>>> The other thing that hit me in the face is to have a PXE boot app
> written
>>> for android that lets the users boot from the nework or tethering
> network
>>> and boot tails from there without burning dvds or using usb storage.
>> 
>> I don't know PXE much, and am unsure if the way it handles network
>> connections can be secured in a way that satisfies Tails design goals
>> and threat models. But if you research this any further, I would
>> personally be curious to read about your results :)

> I didn't have time the last days for this, but isn't the boot media
> supposed to be irrelevant with TAILS?

Yes and no. One of Tails' goals is to make it hard to use it the wrong
way. This makes me doubtful about making it easy for users to boot off
an image loaded over an untrusted network, and served from
a fileserver running some OS that may not have a suitable threat model
and security level. But I've not thought of it much, so I guess
anywore looking deeper into this topic could possibly come up with
a solution that's safe enough (e.g. via USB tethering, as you said).

> I mean no matter what the boot method
> is, it still loads a ramdisk from the supposed media.

Sure.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] Computrace

Hi,

J. S. wrote (26 May 2014 02:09:37 GMT) :
> I wanted to know whats your thoughts about the Computrace software ?

See "Is it safe to use Tails on a compromised system?" in the FAQ:

  https://tails.boum.org/support/faq/#index24h2

> Seems like it can be installed on some linux version,
> including Debian.

My understanding is that it can run on GNU/Linux, but it's not clear
if the BIOS-level component knows how to install it.

> So my question is : should we worry for it while we use Tails ?

Whatever the OS one uses, it's worth worrying about the hardware that
runs it.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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-launcher... without xulrunner

anonym wrote (15 May 2014 09:55:34 GMT) :
> Ticket updated. Turns out the migration will be easy (#7252).

Good news, congrats :)

Cheers!
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] hacking tails to autologin with winxp camouflage

Hi,

sajol...@pimienta.org wrote (24 May 2014 09:01:56 GMT) :
> In order to have the Windows camouflage enabled by default, I think the
> way forward would be to create a new persistence feature to remember
> that setting.

That's https://labs.riseup.net/code/issues/6639, by the way :)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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 and merge feature/5711-liferea-persistence-preset

Hi,

> > Is there already a way to have one single preset making two
> > persistence.conf entries?
> 
> No. We've guessed a while ago that it will be needed at some point,
> but the code doesn't exist yet. I want to write it one of these days,
> but definitely not with such a short notice, that late in a dev cycle.
> 
So should I add an other preset "Retried feed content" or something
like that and we suggest in the doc to activate both?

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.

Re: [Tails-dev] The future of GNOME Fallback in Tails [Was: [review'n'merge:1.1] bugfix/7248-bg-color-vs-display-settings-change]

Hi,

> The good news is that GNOME Classic (shell plugin) is getting very
> good in GNOME 3.8+. I've filed #7311 ("Investigate using GNOME Classic
> for Jessie") that I'd like to tackle early enough *before* the Jessie
> freeze. Help is welcome.
> 
I definitely think we shouldn't use gnome fallback in jessie. But why
not to consider using plain GNOME Shell? It now works with software 3D
too.

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.

Re: [Tails-dev] Please review and merge feature/6342-update-camouflage-for-gnome3

27/05/14 19:36, Alan wrote:
> Hi,
> 
> Ticket: https://labs.riseup.net/code/issues/6342
> 
> Please review and merge:
> 
> - tails:feature/6342-update-camouflage-for-gnome3
> - tails-greeter:feature/6342-update-camouflage-for-gnome3

These are now merged and in the 1.1~beta1 release.

> I assigned everything to anonym but I think they would welcome help!

I've looked at all these tickets, closed/updated them as necessary, and
created a few new ones. These tickets describe my vision of what the
theme should look like in 1.1:

#7316: Fix system tray icon size in camouflage mode
#7325: Fix application icons in "task list" in Windows 8 camouflage
#7326: Fix systray icons in Windows 8 camouflage
#7328: Make clock applet font white again in Windows 8 camouflage.

These four are just straight up coding tasks.

#7277: Port camouflage to Gnome 3 panel

This one I just don't understand. Please clarify, preferably on the ticket!

#7274: Decide if torbrowser camouflage is still needed

IMHO our decision should be "yes", but only some for the basics.
Low-hanging fruit.

#7312: Include window-picker-applet

For this one I created the following blocking ticket:

#7327: Remove launchers in Windows 8 camouflage?

And IMHO "yes we should", for the reasons stated on the ticket.

Assuming we can reach consensus on the decisions/discussion quickly, do
you think you'll be able to get most of this done by June 10, so any
remaining smaller issues from an initial review at that time can be
fixed until June 15?

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 1.0.1 and 1.1