[Tails-dev] [review'n'merge: 1.3.2] bugfix/8687-macchanger-return-status
Hi, Please review and merge into stable and devel. 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] Automated builds specification
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? 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? On a more general note, all this discussion and thinking convinces me more and more that we should really capture in Git everything that matters for a given branch/build, including the state of the custom source packages it needs. Lots of technical details (Git submodules, when/where packages shall be built, etc.) clearly need more thinking, but the general concept, once implemented, will make most of this discussion moot. Another thing that *just* struck me (and has a lot of consequences... sorry for coming with this at this late stage) is that updates to the base branch's APT suite will affect all feature branches based on it, so a rebuild for all of them would make sense immediately after such an update. I agree in principle, but we can't do the immediately part yet, as explained above in more general terms (since the same is true for Git changes in a base branch). OTOH, they may lack important Git state (since the base branch wasn't merged back) that otherwise will make the builds break. Luckily, if we have #8654 and never modify any base branch's APT suite directly but only add APT suites to the base branche's config file *in* *Git*, we should be fine since a Git merge into the feature branch is needed to make it aware of the APT changes. (In what follows, I'm assuming we will have #8654 soonish, since otherwise the rest of the extended autobuild system wouldn't be very useful.) I don't get what's the problem you're raising here. My understanding is that there are few potential problems: a) Changes made directly in the base branch' APT suite are not taken into account by a rebuild of a topic branch. b) Changes made directly in the base branch' APT suite don't trigger a rebuild of the affected topic branches. c) Changes made in the base branch' APT suites config file are not taken into account by a rebuild of a topic branch. d) Changes made in the base branch' APT suites config file don't trigger a rebuild of the affected topic branches. Triggering rebuilds (b and d) has been discussed above, and in short: we can't do that yet, too bad. I believe that (a) and (c) are non-issues once we have #8654. So, what's the remaining problem we should solve *now*? There's a similar case that also needs some consideration, and changes in how we work: imagine we have a feature branch F based on base branch B. We upload a package to F's APT suite, all looks good at the moment, and we merge F into B. Then a feature branch E has B merged into. All good so far. However, at this point we discover an issue with F and have to rebuild the package, or otherwise change F's APT suite. Then we cannot do anything with F's APT suite, because that would affect E without it merging B again. Hence, the
Re: [Tails-dev] [Tails-support] PGP MIME is insecure (for me)
On 10/03/15 16:32, sajolida wrote:
matsa:
On Thu, 05 Mar 2015 12:26:41 +
sajolida sajol...@pimienta.org wrote:
It has something to do with the fact that once you encrypt a
message for the receiving party, you may not be able to decrypt it
yourself. A message in the 'drafts' folder is incomplete by
definition and may need to be re-opened by the sender in plaintext
to make adjustments. So the message cannot be fully encrypted while
in the draft section.
A usual trick to prevent this is to encrypt messages for yourself as
well as for the receiver. Is there any option for that in Claws maybe?
Yes there is, in Configuration Preferences for current account
Privacy Encrypt sent messages ...
It works for *sent* messages, I didn't test for drafts.
I tested, and it does *not* encrypt drafts. I could find no way to make
Claws Mail do that automatically.
Do you want check if that could be added by default in accountrc.tmpl?
I checked it. I expected it to be as simple as adding
`encrypt_to_self=1` to accountrc.tmpl, but no. It still defaults to
`encrypt_to_self=1` for new accounts. I also tried the other
`*{encrypt,sign}*` options (from the privacy tab), and they're similarly
ignore in accountrc.tmpl.
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] Automated builds specification
On 25/03/15 16:44, 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? 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); Of course! Can't believe I forgot about this! [...] 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. I assume you didn't intend base to be there, right? I mean, whatever branch we're dealing with, feature or base, it should be rebuilt when its APT suite is modified. If that's what you meant, great! 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. Cool! [...] On a more general note, all this discussion and thinking convinces me more and more that we should really capture in Git everything that matters for a given branch/build, including the state of the custom source packages it needs. Lots of technical details (Git submodules, when/where packages shall be built, etc.) clearly need more thinking, but the general concept, once implemented, will make most of this discussion moot. Agreed. Another thing that *just* struck me (and has a lot of consequences... sorry for coming with this at this late stage) is that updates to the base branch's APT suite will affect all feature branches based on it, so a rebuild for all of them would make sense immediately after such an update. I agree in principle, but we can't do the immediately part yet, as explained above in more general terms (since the same is true for Git changes in a base branch). Right. Take my immediately:s with a grain of salt. OTOH, they may lack important Git state (since the base branch wasn't merged back) that otherwise will make the builds break. Luckily, if we have #8654 and never modify any base branch's APT suite directly but only add APT suites to the base branche's config file *in* *Git*, we should be fine since a Git merge into the feature branch is needed to make it aware of the APT changes. (In what follows, I'm assuming we will have #8654 soonish, since otherwise the rest of the extended autobuild system wouldn't be very useful.) For the record, everything I wrote was with the assumption that we have #8654. I don't get what's the problem you're raising here. My understanding is that there are few potential problems: a) Changes made directly in the base branch' APT suite are not taken into account by a rebuild of a topic branch. b) Changes made directly in the base branch' APT suite don't trigger a rebuild of the affected topic branches. c) Changes made in the base branch' APT suites config file are not taken into account by a rebuild of a topic branch. d) Changes made in the base branch' APT suites config file don't trigger a rebuild of the affected topic branches. Triggering rebuilds (b and d) has been discussed above, and in short: we can't do that yet, too bad. I believe that (a) and (c) are non-issues once we have #8654. Urgh. I had forgotten this part of the build specification: A topic branch may be lagging behind the base branch it's based upon. What we're interested in is generally not whether a (possibly outdated) topic branch builds fine, but whether it would build fine once merged into its base branch: This should fix all issues I came up with (except that already-merged branches should be frozen and not reused). Sorry for the noise. I had already written some answers below before realizing this, so I leave them, but you can just ignore them. There's a similar case that also needs some consideration, and changes in how we work: imagine we have a feature branch F based on base branch B. We upload a package to F's APT suite, all looks good at the moment, and we merge F into B. Then a feature branch E has B merged into. All good so far. However, at this point we discover an issue with F and have to rebuild the package, or otherwise change F's APT suite. Then we cannot do anything with F's APT suite, because that would affect E without it merging B again. Hence, the fixup for F has
