Re: [Tails-dev] Heads up: update your build environment
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
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
Hi, As was decided during the last few days, Tails 1.1 will be postponed [1]. Ignore the old release schedule for Tails 1.1 [2]! Just to be clear, Tails 1.0.1 will be a point-release of 1.0 that's still based on Debian Squeeze, and all the different 1.1 releases will be based on Debian Wheezy. Here's the release schedule (unless I've misunderstood or made a mistake) for Tails 1.0.1 and 1.1: 2014-05-29 Test 1.1~beta1. 2014-05-30 Officially release 1.1~beta1. 2014-06-08 Firefox 24.6.0 ESR sources are available. Package and upload Firefox 24.6.0 ESR. Tag 1.0.1 in Git. Start building and uploading 1.0.1 ISO/IUKs... 2014-06-09 Finish building by 12:00 (CEST) Start testing Tails 1.0.1 at 12:00 (CEST)... 2014-06-10 ... and finish it by 12:00 (CEST) on the 10th. Officially release Tails 1.0.1. 2014-06-10 The remaining features aimed for 1.1 should be "almost done" at this point. This should leave some room for additional round-trips that may be needed to get them into a mergeable state. 2014-06-15 "Soft" feature freeze for 1.1; developers should act as if this is the actual feature freeze for 1.1. 2014-06-16 *Maybe* publish a 1.1~beta2 ISO without any testing beyond a run in the automated test suite. 2014-07-01 "Hard" feature freeze for 1.1. Tag 1.1~rc1 in Git. Build and upload 1.1~rc1 ISO. 2014-07-02 Testing Tails 1.1~rc1. 2014-07-03 Officially release Tails 1.1~rc1. 2014-07-20 Firefox 24.7.0 ESR sources are available. Package and upload Firefox 24.7.0 ESR. Tag 1.1 in Git. Build and upload 1.1 ISO. 2014-07-21 Testing Tails 1.1. 2014-07-22 Officially release Tails 1.1. Please let me know ASAP, intrigeri, if something in the above seems incorrect! If you ACK it, I'll update the calendar. Tails developers and contributors, are you available for testing on the following dates? * 2014-07-02 for 1.1~rc1 * 2014-07-21 for 1.1 Cheers! [1] https://mailman.boum.org/pipermail/tails-dev/2014-May/005901.html [2] https://mailman.boum.org/pipermail/tails-dev/2014-May/005692.html ___ 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.