[Tails-dev] Next release: process, schedule and iceweasel backports
Hi, whoever is the Release Manager for the current release cycle: please announce the freeze / RC / etc. dates ASAP. If I'm not mistaken, and if we don't change the release schedule this time, we're supposed to freeze in *one* week. But well, this is subject to change. I think we're supposed to release on week 43, but... how do we deal, next time, with an unpredictable iceweasel backports schedule? I'm happy to focus on our APT repository for the next cycle, and it looks like bertagaz is making great progress on the build our own iceweasel front, but still, I'd rather not see us assume we'll be autonomous in this area in time for the current release cycle. So, for the current cycle, I suggest we patch our draft release schedule from the theoretical: / 3w\/ 2w /2|5d\ major freeze firefox release RC1 ESR | | | | | | RC2 release | | | | | ↓ ↓ ↓ ↓ ↓ ._._._._._._. 0 1 2 3 4 5 6 To the more realistic: / 3w\/ 2w /2|5d\ major freeze ESR release RC1 backport is available | | | | firefox | | ESR is out | | | | | | | RC2 release | | | | | ↓ ↓ ↓ ↓ ↓ ._._._._._._. 0 1 2 3 4 5 6 ?? (This implies releasing two weeks later than planned, that is week 45. Also, this assumes the backport is available two weeks after ESR is released. Yeah, that's way too late, but we'll soon be able to do better.) To end with, given the amount of nice stuff we're currently merging into devel, I'd be sad to see this wait until December before being shipped to users, and I'm starting to wonder if we should not make the next release a major one. That could be Tails 0.14. How crazy does that sound? 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
Re: [Tails-dev] Block/unblock wireless devices?
On Mon, Sep 24, 2012 at 10:42:51PM +0200, intrigeri wrote: at boot time, Liberté Linux now explicitly unblocks Wi-Fi, WWAN and WiMAX, and soft-blocks all other kind of wireless devices (Bluetooth, UWB, GPS, FM). This is implemented using rfkill. This may prevent some unwanted leaks through the wireless devices that are unlikely to be useful in the context of Tails, and at the same time, improve the user experience with wireless devices that come up in blocked state after boot. I think we should do this in Tails, and write a short documentation page about how to manually unblock a blocked (e.g. GPS) device when needed (e.g. sudo rfkill unblock gps). Thoughts? Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. AFAIU, that is one of the reason why most Bluetooth enabled systems will always powerup the radio during first stage of the boot process, so one with a Bluetooth keyboard can reach firmware settings. I was thinking something like yeah, we could have a checkbox in the greeter, but many laptops have an hardware kill switch these days. In any cases, blocking GPS by default sounds like a good plan. -- Ague pgptLmhPoFhEX.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Block/unblock wireless devices?
Hi, Ague Mill wrote (25 Sep 2012 07:53:02 GMT) : Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. OK. Let's keep Bluetooth enabled, then :( Just curious, are you thinking of desktop wireless keyboards and mice, or are hardware vendors crazy enough to implement such a thing for laptop input devices? I was thinking something like yeah, we could have a checkbox in the greeter, but many laptops have an hardware kill switch these days. Sorry, this sentence of yours is totally unclear to me. What would this checkbox do? The hardware kill switch generally toggles an airplane mode, which enables/disables *all* radio devices, so I don't think it has the same use as the proposed change. 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
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
On Mon, Sep 24, 2012 at 05:24:51PM +0100, Alessandro Grassi wrote: How far have you tested this patch? Does calling `iceweasel -CreateProfile` requires to have an X server running? I didn't test this. Turns out that it requires an X server! Thanks for asking! We need to work around this somehow. People usually use Xvfb when they need a 'fake' X server. See the 'xvfb' package in Debian, and the `xvfb-run` script it contains. Overall, I am still having a hard time convincing myself that generating an Iceweasel profile on build time is the way to go. That is why I have been researching how complicated it would be to create a dedicated extension... But I am happy to see you trying this approach. We will be able to see how far it goes! :) Also, it would be better if the hook would start with `set -e` in order to catch any errors that can happen in the process. How do I do that? I just put `set -e` before other commands? Yes, just put it at the start of the script. For what it does, let's quote dash(1): If not interactive, exit immediately if any untested command fails. The exit status of a com‐ mand is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an “” or “||” operator. -- Ague pgpYUyniA26sA.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Block/unblock wireless devices?
On Tue, Sep 25, 2012 at 9:53 AM, Ague Mill a...@mailoo.org wrote: Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. True, see, e.g., https://forum.dee.su/topic/wireless-mouse-french-keyboard. AFAIU, that is one of the reason why most Bluetooth enabled systems will always powerup the radio during first stage of the boot process, so one with a Bluetooth keyboard can reach firmware settings. Systems boot in all kinds of crazy states, some apparently relying on initialization by Windows drivers. The main reason I added rfkill calls during boot is that some systems turn wireless radio off on boot: https://forum.dee.su/topic/wireless-problem. I also think that having Bluetooth off by default is the optimal choice, but there are still problems with it, as you noted. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please merge feature/Tor_0.2.3
On Mon, Sep 24, 2012 at 05:31:26PM +0200, intrigeri wrote: please review and merge feature/Tor_0.2.3 It has been in experimental for a while, I've just sync'd it against current devel and re-tested, candidate for Tails 0.14. Reviewed, merged in devel. Maybe 0.2.3 will even be declared stable before 0.14 is out. Who knows? :) -- Ague pgpYKxGIGBMui.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
