Re: [Tails-dev] [tor-qa] Tor Browser 4.0.6 is ready for testing
Tor Browser 4.0.6 -- Mar 31 2015 ... works for us, and was merged into Tails stable branch. 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] patch to the known_issues list
Hi, goupille wrote (26 Mar 2015 12:45:14 GMT) : Two questions: * What do you mean with since 1.3? Did it work with an earlier version? the issue appeared with Tails 1.3, it worked with older versions. * What do you mean with made with Tails installer? Can these computers boot Tails if it's installed in another way? they both could boot manually (linux) installed Tails. the user suspect that the Bios of these laptop isn't happy with booting Tails from a secondary partition. Now I'm a bit lost, so: * just to be clear: did these machines boot from Tails 1.3 made with Tails Installer? * what's the exact behaviour the user sees when Tails 1.3.1 fails to boot? (I can't remember of any change, between 1.3 and 1.3.1, that would impact booting from a device created by Tails Installer, but not a device installed manually, so I suspect a user mistake somewhere here, or some unclarity in the report -- I would dislike adding wrong hardware that doesn't work information to our known issues page.) I'll make the changes and send another patch, thanks Thanks :) Cheers, -- intrigeri ___ 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
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] GUI for encrypted volumes from LUKS/TrueCrypt container files
Jasper wrote (22 Mar 2015 19:23:59 GMT) : aye, the disk utils code is were you traditionally look for specifications when it comes to new udisks dbus calls. [...] whether creating a new encrypted luks image with udisks is possible today remains a mistery until it eventually gets supported by gnome disks. I've found the UDisks documentation quite helpful (although sometimes lacking clarity or details) when porting stuff to UDisks2 recently: http://udisks.freedesktop.org/docs/latest/ The Format method from org.freedesktop.UDisks2.Block allows creating encrypted filesystems, and in theory it should work on loop devices as well. I've not tried this myself, though. ___ 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
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.
