Re: [Tails-dev] patch to FAQ
sajolida:
> BitingBird:
>> Added that MAC USB Installer is also not supported. Please merge :)
>
> StartPage doesn't know about "MAC USB Installer", which tool are you
> referring to? Please provide upstream URL so we're talking about the
> same thing.
>
Well, you wrote about it in https://labs.riseup.net/code/issues/6319
("Mention that "MAC USB Installer" and others are likely not to work
either."), so I googled it and got quite some results. Except... I
re-searched today, and they don't seem to really refer to a tool. So, do
you remember what you were thinking about when you write this? (I guess
not, given your question). If you confirm, this patch can probably be
forgotten.
Cheers,
BitingBird
___
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, On Mon, Apr 06, 2015 at 06:53:35PM +0200, intrigeri wrote: > bertagaz wrote (06 Apr 2015 16:44:30 GMT) : > > > Was there any other topics to discuss on this subject? I kinda remember > > this was the last review round, and we managed to answer to all the raised > > questions. > > No idea. I suggest quickly skimming over the thread again, looking for > anything that hasn't been captured in the blueprint. (We may have the > big picture in mind right now — wait, actually not apparently — but > who knows where we'll be in a year or so?) We should maybe call that landscapes. :) I already did a last skimming before anonym had his last crazy good ideas. I'll take another look at it quickly, maybe note the interesting msg-ids in the blueprint, but I was asking because to me we're quite done on this. 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.
[Tails-dev] Aspirant for Tor Summer of Privacy ( for Improving Tails)
Hi, I would like to participate to Tor Summer of Privacy by contributing to "Improve Tails by working on Debian". I have worked on Debian packaging and build systems and find this project a match for my technical skills. Kindly let me know how to go ahead with this. Regards, Saket Sinha ___ 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
bertagaz wrote (06 Apr 2015 16:44:30 GMT) : > How did you know I was confused? Long running threads are a bit hard to > follow, and I tend to have more and more troubles getting the full > picture. :) > Removed it. :) > Was there any other topics to discuss on this subject? I kinda remember > this was the last review round, and we managed to answer to all the raised > questions. No idea. I suggest quickly skimming over the thread again, looking for anything that hasn't been captured in the blueprint. (We may have the big picture in mind right now — wait, actually not apparently — but who knows where we'll be in a year or so?) ___ 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, On Mon, Mar 30, 2015 at 09:28:08PM +0200, intrigeri wrote: > > Scenario 15 looks good. > > I don't understand what scenario 14 is about, especially right after > the discussion we've had on this thread. How could base branches be > possibly affected by changes in topic branches? > > Did I miss anything, or were you a little bit confused? How did you know I was confused? Long running threads are a bit hard to follow, and I tend to have more and more troubles getting the full picture. :) Removed it. Was there any other topics to discuss on this subject? I kinda remember this was the last review round, and we managed to answer to all the raised questions. 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.
[Tails-dev] review and merge bugfix/9162-build-wiki-quoting
Ticket: https://labs.riseup.net/code/issues/9162 Branch: bugfix/9162-build-wiki-quoting into master Milestone: whenever as this doesn't affect the ISO image I'm not sure that intrigeri should be allowed to review and merge that branch since he's actually the one who wrote that code :) -- sajolida ___ 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
sajolida wrote (06 Apr 2015 14:06:27 GMT) : > Then I'll let you create tickets or send emails upstream accordingly, Done 1.5 year ago: https://labs.riseup.net/code/issues/6337 https://bugs.freedesktop.org/show_bug.cgi?id=70164 :) @the_one_of_us_who'll_attend_GUADEC: please add this to your mission file. ___ 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] underlay for UX or blueprints
Hi, sajolida wrote (06 Apr 2015 13:46:32 GMT) : > intrigeri: >> sajolida wrote (05 Apr 2015 19:46:22 GMT) : >>> intrigeri: Regarding blueprints.tails.b.o: do you plan to take care of the migration once root@b.o has set it up, or do you expect -sysadmins@ to do so? If the latter, please specify your ideal and worst case deadlines. >> >>> I would have to understand better what this implies. If this implies >>> manipulating Git history, I'm not sure I can do it without guidance but >>> I would be interested to learn. >> >>> What would imply rescuing what's currently in wiki/src/blueprint along >>> with its corresponding history? Do we want this folder to be at the root >>> of the new repo (moving Git files usually break their history)? >> >> It does involve creating a new Git repo that 1. only contains the >> blueprint directorie's content, and 2. inherits the current Git repo's >> history for that content, and nothing else. >> >> git-filter-branch(1) should get you started: [...] > I'll try to do this myself then. Great. >> Other than that: >> >> * if we want to manage the ACLs ourselves for that new blueprints >>repo: it requires a master copy of that new repo, somewhere, that's >>able to push to boum.org whenever it's updated; >> * otherwise, it can be setup just like our main repo at b.o. > I think this is getting quite beyond what I'm willing to learn a fits > better the knowledge and role of tails-sysadmins. What about having > tails-sysadmins do the Git infrastructure and ACLS and me do the Git > content and ikiwiki configuration (and learn new Git powers along the way)? Fine with me. Please create whatever tickets are necessary, and I'll see with bertagaz what kind of ETA we can aim for. >> * in any case, we'll need rewrite rules and rewriting links, but that >>should be all I think. > Rewrite rules to point https://tails.boum.org/blueprint to > https://blueprint.tails.boum.org? Anything else? Yes, same for actual blueprints, that is something like: ^/blueprint/(.*)$ -> https://blueprint.tails.boum.org/$1 (otherwise, links from Redmine, ML archives etc. will be broken in the end.) > Then staging.tails.b.o will be helpful to work on the real stuff, but > this can be set up in the second halt of April. Same question: who's going to make it happen (expect the parts only root@b.o can take care of)? >> >>> That sounds easier for me technically speaking: >> >>> - Have a copy of our main repo at immerda. >> >> Well, this only works if you find a way to have a hook in that repo >> that pushes to boum.org whenever it's updated. To the best of my >> knowledge, the Git hosting infrastructure immerda provides us is not >> ready to do that yet, but we can ask them if it's easy for them to set >> it up. Please Cc -sysadmins@ when you'll do that. >> >> Otherwise, we can surely host the master copy of that staging repo on >> lizard somewhere (this will require to set up some stuff, as right now >> our only Git hosting infra there isn't for this kind of things, so >> we'll need to move it or to set up another one). > The second option sounds easier, but I'll let tails-sysadmins decide. Works for me => same here, please create the tickets and we'll see when we think we can do that. >>> I can send them an email. >> >> Uh, no: we (-sysadmins@) are managing our repos and ACLs at immerda >> ourselves => no need to bother immerda folks with repo >> creation requests. > Same here, does that sound ok to let tails-sysadmins do the Git > infrastructure? It will probably be less work for both of parties in the > end... OK. >> - Add a banner to staging.t.b.o that makes it clear that its content >>MUST NOT be trusted. E.g. by replacing the logo, or something. > Ok, I'll take that but this will imply additional Git complexity I > guess. Another option would be to put that website behind a dummy > .htaccess password documented along with the new toy in our contributors > documentation. I like your KISS solution :) >> - Decide who's gonna get write access to the new toy via the web, and >>via Git. > Via 'web' and via 'Git'? I only thought about Git access, my use case > being tchou working on the web assistant. Let's go for Git access only, then. CGI-- :) Glad we basically have a solution + tasks sharing designed! 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] GUI for encrypted volumes from LUKS/TrueCrypt container files
intrigeri:
> sajolida wrote (01 Apr 2015 11:08:49 GMT) :
>> intrigeri:
>>> sajolida wrote (20 Mar 2015 12:34:35 GMT) :
I think that our long-term objective is to have people move out of
using TrueCrypt technologies in general (be it the software, the
volumes, or the containers).
>>>
>>> Now you make me curious: why do you think we should get rid of the
>>> TrueCrypt on-disk format?
>
>> I was saying this because I thought it was our vision when getting rid
>> of TrueCrypt,
>
> This doesn't match my memories, quite the contrary. There must have
> been a fair amount of misunderstanding along the way. See e.g.:
> https://mailman.boum.org/pipermail/tails-dev/2014-April/005596.html
>
> Now, I can very well imagine having contradicted myself somewhere
> else, or another thread having lead us collectively to the vision
> you're referring to, that I really can't remember.
Fair enough, thanks for updating my memory.
>>> The way I see it, we're stuck between a rock and a hard place:
>>>
>>> Ideally we'd like to be able to fully replace TrueCrypt volumes (I'm
>>> assuming that I'm missing information that makes you think we should)
>>> with something else, but nothing equivalent exists yet. Sadly, I'm not
>>> aware of any plan (let alone serious effort) towards making this
>>> a reality, when one takes into account the need for:
>>>
>>> - inter-operability (which I'm tempted to disregard as a dangerous
>>>way to share data with an untrusted OS, but then if we don't
>>>support TrueCrypt volumes at all, perhaps users who won't/can't
>>>fully give up proprietary software will just be forced to either
>>>store and share the very same data in cleartext, or to use
>>>something less safe than Tails)
>>>
>>> - "hidden" volumes (which may be a false promise in TrueCrypt, but
>>>still people want that and AFAIK there's nothing even approaching
>>>it, be it in terms of peer-review of existing production-quality
>>>implementations)
>
>> Thanks to Jasper we can add "containers" to that list.
>
>> All those are usability and interoperability issues that have real but
>> non-obvious security implications (not in terms of crypto but in terms
>> of user scenario). I'm not really convinced by containers and hidden
>> volumes as such in the context of a pure Tails setup, so we're left with
>> interoperability as the most interesting feature.
>
> Agreed.
>
>>> With this in mind, supporting the TrueCrypt on-disk format (even
>>> minimally) still makes sense for the time being IMO. I doubt we'll
>>> actively patch out the corresponding code from cryptsetup, so I take
>>> for granted that we'll keep this support in Tails as long as
>>> cryptsetup has it.
>
>> Agreed.
>
> :)
>
>>> We had good reasons to get rid of the TrueCrypt software itself, but
>>> no existing GUI for TrueCrypt volumes is satisfying right now, in the
>>> context of Tails.
>>>
>>> Now, of course a CLI-only interface isn't encouraging for Tails users
>>> to go on using TrueCrypt volumes. This has both advantages (as
>>> a long-term strategy, hopefully it'll encourage people to either fully
>>> replace TrueCrypt volumes with a better design), and drawbacks (until
>>> our fancy long-term plans are made real by $someone $some_day, Tails
>>> users have the choice between using something we claim we don't really
>>> support, with poor usability, and doing something even worse).
>>>
>>> So, the question I'm coming to is: assuming there *was* satisfying GUI
>>> support for the TrueCrypt on-disk format (in GNOME Disks, Nautilus,
>>> etc.), would we want to explicitly support that, or still depict it as
>>> a suboptimal feature, and call it unsupported because we think it
>>> should ideally be replaced by something else on the long term?
>
>> We have a long tradition of advertising only one tool for one job. So
>> what would we advertise TrueCrypt for? Exchanging encrypted data with
>> other operating systems? With big fat warnings? Maybe...
>
> I don't think that the "only one tool for one job" argument is very
> relevant here. First, because the scenario you're replying to is about
> adding support for the TrueCrypt on-disk format to existing tools
> (GNOME Disks and friends). Secondly, because GNOME Disks and friends
> support more than one filesystem, more than one partition table
> format, etc., so supporting another on-disk encryption format is no
> big deal as I see it. Third, because the same reason that led us to
> document keyringer (basically: it doesn't solve _exactly_ the same use
> case as KeePassX) applies just fine here too.
I agree with you. I overplayed the "only one tool for one job" argument.
I was mostly not seeing ourselves advertising TrueCrypt as an
alternative to LUKS for general disk encryption ("you can use LUKS or
use TrueCrypt").
> Now, regarding the "advertising" part: yes, I think it should be
> documented (if at all) only for interoperability purposes.
> I'm writting "if at all" becaus
Re: [Tails-dev] Tails contributors meeting: Friday April 03
sajolida wrote (06 Apr 2015 13:15:32 GMT) : > intrigeri: >> Perhaps we >> should instead set up the cronjob via /etc/cron.montly/ and install >> anacron, so that the reminder is sent at some point anyway? > I've never used anacron and just scanned the manpage. How would that fit > with sending two reminders, one on day 15 and another one on day 1? The reminder on day 15 can't be handled by anacron. But the one sent on day 1 can be. So in the worst case (downtime both on the 1st and on the 15th), at least one reminder will be sent if we use anacron, vs. none currently. 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] underlay for UX or blueprints
intrigeri: > sajolida wrote (05 Apr 2015 19:46:22 GMT) : >> intrigeri: >>> sajolida wrote (02 Apr 2015 19:39:16 GMT) : intrigeri: > Web prototypes should probably live in branches forked off master, > hosted in a non-official Git repo (to avoid .git growing too much) > until they're ready to be squashed and merged, no? >>> I'm not sure to understand what you mean by "squashed". Is that a special Git operation? >>> >>> It's not a Git command per-se. It means rewriting the history of >>> a branch before merging it, e.g. to get rid of testing of hypothesis >>> that lead nowhere, of debugging stuff added then removed, recompress >>> images properly, and sometimes even merging all its remaining new >>> commits together, depending on the Git workflow. >>> >>> I expect that such web prototypes branches may inject largish files, >>> replace and modify them along the way, which would bloat the repo >>> a lot, for no good reason, if they're not squashed before merging. > >> So this it something that I definitely don't know how to do and would >> need explanation or training to perform. > > That's actually: > > git rebase -i origin/$BASE_BRANCH > > with BASE_BRANCH = the branch into which the current topic branch is > meant to be merged. Ok, this should do in the documentation about staging.tails.boum.org. I'll give it a try. People working on the "staging" website would have to coordinate to deal with whatever is built by this ikiwiki. Would you recommend having a dedicated canonical branch, say "staging" or "website" to do that? >>> >>> I think it needs to be built from a dedicated clone of our repo, not >>> merely from a branch living in our official repo, so that we can 1. >>> deal with different ACLs more easily; 2. squash branches before >>> merging, or even cherry-pick stuff, or rewrite the history of the >>> staging repo whenever needed. > >> So that would be a clone that is not automatically synchronized from our >> main repo but only manually by people with push rights? > > We can have our main repo's master branch merged automatically into > that other repo e.g. daily, but then someone will have to receive the > notifications about merge conflicts, and act upon it. As you prefer. I think I prefer to merge the main repo into staging manually when needed. Otherwise stuff might break on staging by automatic pushes. >>> Regarding blueprints.tails.b.o: do you plan to take care of the >>> migration once root@b.o has set it up, or do you expect -sysadmins@ to >>> do so? If the latter, please specify your ideal and worst >>> case deadlines. > >> I would have to understand better what this implies. If this implies >> manipulating Git history, I'm not sure I can do it without guidance but >> I would be interested to learn. > >> What would imply rescuing what's currently in wiki/src/blueprint along >> with its corresponding history? Do we want this folder to be at the root >> of the new repo (moving Git files usually break their history)? > > It does involve creating a new Git repo that 1. only contains the > blueprint directorie's content, and 2. inherits the current Git repo's > history for that content, and nothing else. > > git-filter-branch(1) should get you started: > >To rewrite the repository to look as if foodir/ had been its project > root, >and discard all other history: > >git filter-branch --subdirectory-filter foodir -- --all > > Of course, we're not going to rewrite our main repo's history in this > process, though. A simple `git rm -r wiki/src/blueprint' will do there. I'll try to do this myself then. > Other than that: > > * if we want to manage the ACLs ourselves for that new blueprints >repo: it requires a master copy of that new repo, somewhere, that's >able to push to boum.org whenever it's updated; > * otherwise, it can be setup just like our main repo at b.o. I think this is getting quite beyond what I'm willing to learn a fits better the knowledge and role of tails-sysadmins. What about having tails-sysadmins do the Git infrastructure and ACLS and me do the Git content and ikiwiki configuration (and learn new Git powers along the way)? > * in any case, we'll need rewrite rules and rewriting links, but that >should be all I think. Rewrite rules to point https://tails.boum.org/blueprint to https://blueprint.tails.boum.org? Anything else? Then staging.tails.b.o will be helpful to work on the real stuff, but this can be set up in the second halt of April. >>> >>> Same question: who's going to make it happen (expect the parts only >>> root@b.o can take care of)? > >> That sounds easier for me technically speaking: > >> - Have a copy of our main repo at immerda. > > Well, this only works if you find a way to have a hook in that repo > that pushes to boum.org whenever it's updated. To the best of my > knowledge, the Git hosting infrastructure immerda provides us is not > read
Re: [Tails-dev] Tails contributors meeting: Friday April 03
intrigeri: > sajolida wrote (05 Apr 2015 19:55:32 GMT) : >> intrigeri: >>> sajolida: may you please have a look at the meeting reminder setup, >>> which seems buggy currently? > >> I tried to execute the same command that sends the reminder and it >> worked right now. So I don't really know what happened, unless something >> went wrong with the cron on that machine ([misc]), or there was a >> downtime on April 1st 00:00 am? > > Yes, there was a downtime between March 31 and April 1st. Perhaps we > should instead set up the cronjob via /etc/cron.montly/ and install > anacron, so that the reminder is sent at some point anyway? I've never used anacron and just scanned the manpage. How would that fit with sending two reminders, one on day 15 and another one on day 1? -- sajolida ___ 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 FAQ
BitingBird: > Added that MAC USB Installer is also not supported. Please merge :) StartPage doesn't know about "MAC USB Installer", which tool are you referring to? Please provide upstream URL so we're talking about the same thing. -- sajolida ___ 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
Hi, sajolida wrote (01 Apr 2015 11:08:49 GMT) : > intrigeri: >> sajolida wrote (20 Mar 2015 12:34:35 GMT) : >>> I think that our long-term objective is to have people move out of >>> using TrueCrypt technologies in general (be it the software, the >>> volumes, or the containers). >> >> Now you make me curious: why do you think we should get rid of the >> TrueCrypt on-disk format? > I was saying this because I thought it was our vision when getting rid > of TrueCrypt, This doesn't match my memories, quite the contrary. There must have been a fair amount of misunderstanding along the way. See e.g.: https://mailman.boum.org/pipermail/tails-dev/2014-April/005596.html Now, I can very well imagine having contradicted myself somewhere else, or another thread having lead us collectively to the vision you're referring to, that I really can't remember. > but I have no strong argument against TrueCrypt on-disk > format as such myself. Thanks for clarifying! >> The way I see it, we're stuck between a rock and a hard place: >> >> Ideally we'd like to be able to fully replace TrueCrypt volumes (I'm >> assuming that I'm missing information that makes you think we should) >> with something else, but nothing equivalent exists yet. Sadly, I'm not >> aware of any plan (let alone serious effort) towards making this >> a reality, when one takes into account the need for: >> >> - inter-operability (which I'm tempted to disregard as a dangerous >>way to share data with an untrusted OS, but then if we don't >>support TrueCrypt volumes at all, perhaps users who won't/can't >>fully give up proprietary software will just be forced to either >>store and share the very same data in cleartext, or to use >>something less safe than Tails) >> >> - "hidden" volumes (which may be a false promise in TrueCrypt, but >>still people want that and AFAIK there's nothing even approaching >>it, be it in terms of peer-review of existing production-quality >>implementations) > Thanks to Jasper we can add "containers" to that list. > All those are usability and interoperability issues that have real but > non-obvious security implications (not in terms of crypto but in terms > of user scenario). I'm not really convinced by containers and hidden > volumes as such in the context of a pure Tails setup, so we're left with > interoperability as the most interesting feature. Agreed. >> With this in mind, supporting the TrueCrypt on-disk format (even >> minimally) still makes sense for the time being IMO. I doubt we'll >> actively patch out the corresponding code from cryptsetup, so I take >> for granted that we'll keep this support in Tails as long as >> cryptsetup has it. > Agreed. :) >> We had good reasons to get rid of the TrueCrypt software itself, but >> no existing GUI for TrueCrypt volumes is satisfying right now, in the >> context of Tails. >> >> Now, of course a CLI-only interface isn't encouraging for Tails users >> to go on using TrueCrypt volumes. This has both advantages (as >> a long-term strategy, hopefully it'll encourage people to either fully >> replace TrueCrypt volumes with a better design), and drawbacks (until >> our fancy long-term plans are made real by $someone $some_day, Tails >> users have the choice between using something we claim we don't really >> support, with poor usability, and doing something even worse). >> >> So, the question I'm coming to is: assuming there *was* satisfying GUI >> support for the TrueCrypt on-disk format (in GNOME Disks, Nautilus, >> etc.), would we want to explicitly support that, or still depict it as >> a suboptimal feature, and call it unsupported because we think it >> should ideally be replaced by something else on the long term? > We have a long tradition of advertising only one tool for one job. So > what would we advertise TrueCrypt for? Exchanging encrypted data with > other operating systems? With big fat warnings? Maybe... I don't think that the "only one tool for one job" argument is very relevant here. First, because the scenario you're replying to is about adding support for the TrueCrypt on-disk format to existing tools (GNOME Disks and friends). Secondly, because GNOME Disks and friends support more than one filesystem, more than one partition table format, etc., so supporting another on-disk encryption format is no big deal as I see it. Third, because the same reason that led us to document keyringer (basically: it doesn't solve _exactly_ the same use case as KeePassX) applies just fine here too. Now, regarding the "advertising" part: yes, I think it should be documented (if at all) only for interoperability purposes. I'm writting "if at all" because people who want to use TrueCrypt volumes can create them on their other OS, and then all we need on our side is documenting how to unlock/open such volumes in Tails. The good news is that we already have a perfect place for that, which is doc/encryption_and_privacy/truecrypt :) >> In
Re: [Tails-dev] underlay for UX or blueprints
Hi, sajolida wrote (05 Apr 2015 19:46:22 GMT) : > intrigeri: >> sajolida wrote (02 Apr 2015 19:39:16 GMT) : >>> intrigeri: Web prototypes should probably live in branches forked off master, hosted in a non-official Git repo (to avoid .git growing too much) until they're ready to be squashed and merged, no? >> >>> I'm not sure to understand what you mean by "squashed". Is that a >>> special Git operation? >> >> It's not a Git command per-se. It means rewriting the history of >> a branch before merging it, e.g. to get rid of testing of hypothesis >> that lead nowhere, of debugging stuff added then removed, recompress >> images properly, and sometimes even merging all its remaining new >> commits together, depending on the Git workflow. >> >> I expect that such web prototypes branches may inject largish files, >> replace and modify them along the way, which would bloat the repo >> a lot, for no good reason, if they're not squashed before merging. > So this it something that I definitely don't know how to do and would > need explanation or training to perform. That's actually: git rebase -i origin/$BASE_BRANCH with BASE_BRANCH = the branch into which the current topic branch is meant to be merged. >>> People working on the "staging" website would have to coordinate to deal >>> with whatever is built by this ikiwiki. Would you recommend having a >>> dedicated canonical branch, say "staging" or "website" to do that? >> >> I think it needs to be built from a dedicated clone of our repo, not >> merely from a branch living in our official repo, so that we can 1. >> deal with different ACLs more easily; 2. squash branches before >> merging, or even cherry-pick stuff, or rewrite the history of the >> staging repo whenever needed. > So that would be a clone that is not automatically synchronized from our > main repo but only manually by people with push rights? We can have our main repo's master branch merged automatically into that other repo e.g. daily, but then someone will have to receive the notifications about merge conflicts, and act upon it. As you prefer. >> Once we have that, you can simply use the master branch on that clone. > Ok, make sense and sounds good. Cool. >> Regarding blueprints.tails.b.o: do you plan to take care of the >> migration once root@b.o has set it up, or do you expect -sysadmins@ to >> do so? If the latter, please specify your ideal and worst >> case deadlines. > I would have to understand better what this implies. If this implies > manipulating Git history, I'm not sure I can do it without guidance but > I would be interested to learn. > What would imply rescuing what's currently in wiki/src/blueprint along > with its corresponding history? Do we want this folder to be at the root > of the new repo (moving Git files usually break their history)? It does involve creating a new Git repo that 1. only contains the blueprint directorie's content, and 2. inherits the current Git repo's history for that content, and nothing else. git-filter-branch(1) should get you started: To rewrite the repository to look as if foodir/ had been its project root, and discard all other history: git filter-branch --subdirectory-filter foodir -- --all Of course, we're not going to rewrite our main repo's history in this process, though. A simple `git rm -r wiki/src/blueprint' will do there. Other than that: * if we want to manage the ACLs ourselves for that new blueprints repo: it requires a master copy of that new repo, somewhere, that's able to push to boum.org whenever it's updated; * otherwise, it can be setup just like our main repo at b.o. * in any case, we'll need rewrite rules and rewriting links, but that should be all I think. >>> Then staging.tails.b.o will be helpful to work on the real stuff, but >>> this can be set up in the second halt of April. >> >> Same question: who's going to make it happen (expect the parts only >> root@b.o can take care of)? > That sounds easier for me technically speaking: > - Have a copy of our main repo at immerda. Well, this only works if you find a way to have a hook in that repo that pushes to boum.org whenever it's updated. To the best of my knowledge, the Git hosting infrastructure immerda provides us is not ready to do that yet, but we can ask them if it's easy for them to set it up. Please Cc -sysadmins@ when you'll do that. Otherwise, we can surely host the master copy of that staging repo on lizard somewhere (this will require to set up some stuff, as right now our only Git hosting infra there isn't for this kind of things, so we'll need to move it or to set up another one). > I can send them an email. Uh, no: we (-sysadmins@) are managing our repos and ACLs at immerda ourselves => no need to bother immerda folks with repo creation requests. > - Set up a first set of ACL there. I think that's a responsibility > for tails-sysadmin. Right, once we have the list of user
Re: [Tails-dev] Tails contributors meeting: Friday April 03
sajolida wrote (05 Apr 2015 19:55:32 GMT) : > intrigeri: >> sajolida: may you please have a look at the meeting reminder setup, >> which seems buggy currently? > I tried to execute the same command that sends the reminder and it > worked right now. So I don't really know what happened, unless something > went wrong with the cron on that machine ([misc]), or there was a > downtime on April 1st 00:00 am? Yes, there was a downtime between March 31 and April 1st. Perhaps we should instead set up the cronjob via /etc/cron.montly/ and install anacron, so that the reminder is sent at some point anyway? 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.
