Re: [Tails-dev] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread anonym
Arnaud:
> 
> 
> On 04/04/2017 12:45 PM, anonym wrote:
>> I don't know what you mean with "Tor download" -- the build system itself 
>> doesn't run or use tor.
> 
> I was talking about the tor browser that is downloaded in
> `config/chroot_local-hooks/10-tbb`, through a series of `curl` commands.
> This part takes forever to complete. I didn't notice that it was cached
> as well.
> 
>> Any way, the "offline" option is supposed to enable a true offline building 
>> mode, and if a build fails due to lack of Internet access, that is a bug. It 
>> relies on all interactions with the Internet being done with applications 
>> that respect the http_proxy environment variable (which points to 
>> apt-cacher-ng, which is configured to allow downloading and caching more 
>> than just .deb:s). Specifically, `wget` respects http_proxy, and apparently 
>> so do all the various mechanisms used to fetch firmwares and other files in 
>> the post-install scripts of all .deb:s Tails uses.
> 
> Ok, I guess I just have to try it, I'll see how it goes and will let you
> know if anything bad happens.
> 
>> If you know C, perhaps you'd want to look into implementing (optional) 
>> download retrying in apt-cacher-ng? That would, of course, be the best 
>> solution.
> 
> I'm comfortable with C, but not comfortable at all with these network
> and proxy things ;) But it's nice that you point me in the right
> direction. At least I know where to look next.

[Sorry, it's apparently C++!]

An additional pointer would be to look at `source/dlconn.cc` and the logic 
around the `MAX_RETRY` constant and `nLostConTolerance` variable. I doubt being 
able to increase that value of `MAX_RETRY` is what we want, since it seems to 
be about global failures and not per file, but I think the code around it will 
give some insights on how to get per-file retries. But I might be way off, I 
barely looked at the logic, just variable names. :)

(OTOH I guess it'd be an interesting experiment, as a first step, for you to 
compile apt-cacher-ng with `MAX_RETRY` set to some crazy high value like 1000 
or something, and see if that improves reliability for you.)

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread Arnaud


On 04/04/2017 12:45 PM, anonym wrote:
> I don't know what you mean with "Tor download" -- the build system itself 
> doesn't run or use tor.

I was talking about the tor browser that is downloaded in
`config/chroot_local-hooks/10-tbb`, through a series of `curl` commands.
This part takes forever to complete. I didn't notice that it was cached
as well.

> Any way, the "offline" option is supposed to enable a true offline building 
> mode, and if a build fails due to lack of Internet access, that is a bug. It 
> relies on all interactions with the Internet being done with applications 
> that respect the http_proxy environment variable (which points to 
> apt-cacher-ng, which is configured to allow downloading and caching more than 
> just .deb:s). Specifically, `wget` respects http_proxy, and apparently so do 
> all the various mechanisms used to fetch firmwares and other files in the 
> post-install scripts of all .deb:s Tails uses.

Ok, I guess I just have to try it, I'll see how it goes and will let you
know if anything bad happens.

> If you know C, perhaps you'd want to look into implementing (optional) 
> download retrying in apt-cacher-ng? That would, of course, be the best 
> solution.

I'm comfortable with C, but not comfortable at all with these network
and proxy things ;) But it's nice that you point me in the right
direction. At least I know where to look next.

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread anonym
Arnaud:
> On 04/04/2017 11:49 AM, anonym wrote:
>>> So at the moment, I'm still in this situation where build fails, and I
>>> retry and retry until at some point it succeeds. I didn't have much time
>>> to work on that yet. I'll come back to you when I workaround this issue,
>>> one way or another.
>> A simple workaround for when you have cached everything needed for the build 
>> (i.e. after your have successfully built *once*) is to add "offline" to the 
>> TAILS_BUILD_OPTIONS environment variable. Of course, getting to the point 
>> when you have everything cached will be painful, but at least you will be 
>> able to rebuild as much as you like without risk of network issues.
> 
> Good idea, didn't try this option yet. I guess that it will avoid any
> `apt` request, however what about the Tor download that is done with
> `wget` ? This is not cached I think, and it's quite a long download, one
> that fails

I don't know what you mean with "Tor download" -- the build system itself 
doesn't run or use tor.

Any way, the "offline" option is supposed to enable a true offline building 
mode, and if a build fails due to lack of Internet access, that is a bug. It 
relies on all interactions with the Internet being done with applications that 
respect the http_proxy environment variable (which points to apt-cacher-ng, 
which is configured to allow downloading and caching more than just .deb:s). 
Specifically, `wget` respects http_proxy, and apparently so do all the various 
mechanisms used to fetch firmwares and other files in the post-install scripts 
of all .deb:s Tails uses.

>> Here's a crazier idea to explore:
>>
>> * run apt-cacher-ng on the host (base your configuration on 
>> vagrant/provision/assets/acng.conf)
>> * add "extproxy" to TAILS_BUILD_OPTIONS
>> * set the http_proxy environment variable to point to the host's 
>> apt-cacher-ng instance
>> * the "offline" option doesn't work with external proxies, but you can set 
>> Offline mode in apt-cacher-ng's configuration instead
>> * sadly apt-cacher-ng lacks an option for retrying failed downloads, but if 
>> you can find any other HTTP proxy that can, set that up as well and then 
>> configure apt-cacher-ng to use it as a parent proxy itself (see the `Proxy` 
>> option).
> 
> One the same line: did you guys consider having apt-cacher in another VM
> ? As a beginner, I'm still at the point where I modify the VM here and
> there, and at some point I'm not sure anymore what I modified, and in
> the end destroy the VM to start again from scratch. In these situations,
> having another VM for apt-cacher would be a real delight.
> 
>> Happy hacking! Let us know if you find out something about the last point 
>> (parent proxy that retries). If it improves your situation without using 
>> much resources we probably want to add it to the VM's default apt-cacher-ng 
>> setup.
> 
> Yep I'll tell you as soon as something interesting happens on my side ;)

If you know C, perhaps you'd want to look into implementing (optional) download 
retrying in apt-cacher-ng? That would, of course, be the best solution.

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread Arnaud


On 04/04/2017 11:49 AM, anonym wrote:
>> So at the moment, I'm still in this situation where build fails, and I
>> retry and retry until at some point it succeeds. I didn't have much time
>> to work on that yet. I'll come back to you when I workaround this issue,
>> one way or another.
> A simple workaround for when you have cached everything needed for the build 
> (i.e. after your have successfully built *once*) is to add "offline" to the 
> TAILS_BUILD_OPTIONS environment variable. Of course, getting to the point 
> when you have everything cached will be painful, but at least you will be 
> able to rebuild as much as you like without risk of network issues.

Good idea, didn't try this option yet. I guess that it will avoid any
`apt` request, however what about the Tor download that is done with
`wget` ? This is not cached I think, and it's quite a long download, one
that fails


> Here's a crazier idea to explore:
>
> * run apt-cacher-ng on the host (base your configuration on 
> vagrant/provision/assets/acng.conf)
> * add "extproxy" to TAILS_BUILD_OPTIONS
> * set the http_proxy environment variable to point to the host's 
> apt-cacher-ng instance
> * the "offline" option doesn't work with external proxies, but you can set 
> Offline mode in apt-cacher-ng's configuration instead
> * sadly apt-cacher-ng lacks an option for retrying failed downloads, but if 
> you can find any other HTTP proxy that can, set that up as well and then 
> configure apt-cacher-ng to use it as a parent proxy itself (see the `Proxy` 
> option).

One the same line: did you guys consider having apt-cacher in another VM
? As a beginner, I'm still at the point where I modify the VM here and
there, and at some point I'm not sure anymore what I modified, and in
the end destroy the VM to start again from scratch. In these situations,
having another VM for apt-cacher would be a real delight.

> Happy hacking! Let us know if you find out something about the last point 
> (parent proxy that retries). If it improves your situation without using much 
> resources we probably want to add it to the VM's default apt-cacher-ng setup.

Yep I'll tell you as soon as something interesting happens on my side ;)

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread anonym
Arnaud:
> While these patches don't hurt, I can tell you now that they solve
> nothing. And I don't want to be responsible for cluttering the build
> system with useless stuff like that ;)

Thanks! :)

> So at the moment, I'm still in this situation where build fails, and I
> retry and retry until at some point it succeeds. I didn't have much time
> to work on that yet. I'll come back to you when I workaround this issue,
> one way or another.

A simple workaround for when you have cached everything needed for the build 
(i.e. after your have successfully built *once*) is to add "offline" to the 
TAILS_BUILD_OPTIONS environment variable. Of course, getting to the point when 
you have everything cached will be painful, but at least you will be able to 
rebuild as much as you like without risk of network issues.

Here's a crazier idea to explore:

* run apt-cacher-ng on the host (base your configuration on 
vagrant/provision/assets/acng.conf)
* add "extproxy" to TAILS_BUILD_OPTIONS
* set the http_proxy environment variable to point to the host's apt-cacher-ng 
instance
* the "offline" option doesn't work with external proxies, but you can set 
Offline mode in apt-cacher-ng's configuration instead
* sadly apt-cacher-ng lacks an option for retrying failed downloads, but if you 
can find any other HTTP proxy that can, set that up as well and then configure 
apt-cacher-ng to use it as a parent proxy itself (see the `Proxy` option).

Happy hacking! Let us know if you find out something about the last point 
(parent proxy that retries). If it improves your situation without using much 
resources we probably want to add it to the VM's default apt-cacher-ng setup.

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread Arnaud
Hi intrigeri, thanks for the feedback.

On 04/04/2017 08:42 AM, intrigeri wrote:
>
> This seems to have fallen through the cracks. TBH we're not very good
> at tracking patches sent over email, so in the future, I recommend
> filing Redmine tickets, assigned to the current release manager
> (https://tails.boum.org/contribute/calendar/), and with a patch
> attached (or better: a pointer to a branch).

No worries. Actually I didn't talk anymore about that because, well,
this patch solves nothing.

Having a build system that succeeds on a flaky network seems to be much
more than just adding a retry option to apt. You can forget about this
change, and also about the two other changes that I sent in this mail a
few weeks ago:

https://mailman.boum.org/pipermail/tails-dev/2017-March/011280.html

While these patches don't hurt, I can tell you now that they solve
nothing. And I don't want to be responsible for cluttering the build
system with useless stuff like that ;)

So at the moment, I'm still in this situation where build fails, and I
retry and retry until at some point it succeeds. I didn't have much time
to work on that yet. I'll come back to you when I workaround this issue,
one way or another. In the meantime, don't bother with that.

I'll follow your recommendation for the next issues I face.

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-04-04 Thread intrigeri
Hi Arnaud,

Arnaud:
> On 03/11/2017 08:41 PM, anonym wrote:
>> Arnaud:
>>> --- a/vagrant/provision/setup-tails-builder
>>> +++ b/vagrant/provision/setup-tails-builder
>> [...]
>>> +# Configure apt to retry
>>> +echo 'APT::Acquire::Retries "20";' > /etc/apt/apt.conf.d/99retries
>> This will only affect provisioning, not any usage of APT during the build, 
>> right? Or will it propagate into the chroot somehow?

> Indeed, it is not effective in the chroot.

> One way to set this setting in the chroot is to pass an option
> explicitly when running `lb config` (patch attached).

This seems to have fallen through the cracks. TBH we're not very good
at tracking patches sent over email, so in the future, I recommend
filing Redmine tickets, assigned to the current release manager
(https://tails.boum.org/contribute/calendar/), and with a patch
attached (or better: a pointer to a branch).

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-12 Thread Arnaud
On 03/11/2017 08:41 PM, anonym wrote:
> Arnaud:
>> --- a/vagrant/provision/setup-tails-builder
>> +++ b/vagrant/provision/setup-tails-builder
> [...]
>> +# Configure apt to retry
>> +echo 'APT::Acquire::Retries "20";' > /etc/apt/apt.conf.d/99retries
> This will only affect provisioning, not any usage of APT during the build, 
> right? Or will it propagate into the chroot somehow?

Indeed, it is not effective in the chroot.

One way to set this setting in the chroot is to pass an option
explicitly when running `lb config` (patch attached). Another way would
be to add a file into the `config` directory, but I'm not sure exactly
which file. According to today's live-build doc, creating a file
`config/apt/apt.conf` should work. But it doesn't seem to match the
existing layout, Tails already has a directory `config/chroot_apt`,
maybe it's better to drop a file there, however I didn't try.

Anyway.

The fact is that it doesn't help me much, because apt-get **will not**
retry when it's run along `apt-cacher-ng`. I strongly suspect that it's
because apt-cacher-ng returns an error code 503 "Service Unavailable" on
failure, instead of forwarding the original error code. I got in touch
with apt-cacher-ng and let you know when I know more about that.

Cheers

---
 auto/config | 1 +
 1 file changed, 1 insertion(+)

diff --git a/auto/config b/auto/config
index 236ac0f1b9..d0b9c1a2e3 100755
--- a/auto/config
+++ b/auto/config
@@ -58,6 +58,7 @@ perl -pi \
 # set Amnesia's general options
 $RUN_LB_CONFIG \
--verbose \
+   --apt-options "--yes -oAcquire::Retries=20" \
--apt-recommends false \
--architecture amd64 \
--backports false \
-- 
2.11.0


___
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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-11 Thread Arnaud
Hi,
>> +# Configure apt to retry +echo 'APT::Acquire::Retries "20";' >
>> /etc/apt/apt.conf.d/99retries 
> This will only affect provisioning, not any usage of APT during the
> build, right? Or will it propagate into the chroot somehow?

I'm not sure about that, actually I don't fully understand this part
yet. I didn't think about the chroot, plus I don't know how
apt-cacher-ng interact with all of that.

After applying this patch, my build succeeded, but I didn't really
witness an apt-get command failing and retrying yet. I need to do more
test. I'll check that and let you know.

> We have ticket #9430 where we considered adding this configuration
> during the build as well, but we thought that "#5926 [1] will
> magically solve 99% of this problem, so IMO I should not waste time
> trying to fix it differently here" so we didn't in the end. Apparently
> the "1%" of this problem that we ignored is to enable Tails to be
> built in regions with worse connectivity to our servers than us.
> Admittedly that ticket seemed to have a focus on these issues vs our
> infra, which indeed was solved, but now we have another reason.

Thanks for the reference, I'll take care to comment on these tickets if
needed.

Cheers !

Arnaud

___
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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-11 Thread anonym
Arnaud:
> --- a/vagrant/provision/setup-tails-builder
> +++ b/vagrant/provision/setup-tails-builder
[...]
> +# Configure apt to retry
> +echo 'APT::Acquire::Retries "20";' > /etc/apt/apt.conf.d/99retries

This will only affect provisioning, not any usage of APT during the build, 
right? Or will it propagate into the chroot somehow?

We have ticket #9430 where we considered adding this configuration during the 
build as well, but we thought that "#5926 [1] will magically solve 99% of this 
problem, so IMO I should not waste time trying to fix it differently here" so 
we didn't in the end. Apparently the "1%" of this problem that we ignored is to 
enable Tails to be built in regions with worse connectivity to our servers than 
us. Admittedly that ticket seemed to have a focus on these issues vs our infra, 
which indeed was solved, but now we have another reason.

Cheers!

[0] https://labs.riseup.net/code/issues/9430
[1] https://labs.riseup.net/code/issues/5926

___
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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-11 Thread intrigeri
Arnaud:
> I managed to build Tails, finally ! So let me share here the little
> patch I ended up with, in case it can help someone. This patch deals
> with the transient network problems I experienced.

Thanks, applied!
___
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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-11 Thread Arnaud
Hi !

I managed to build Tails, finally ! So let me share here the little
patch I ended up with, in case it can help someone. This patch deals
with the transient network problems I experienced.

Additionally, I increased the RAM of the VM to 1024M, just to be on the
safe side. I've experienced an oomkiller once (clearly seen in the logs)
during my several attempts to build Tails.

Cheers.

---
 config/chroot_local-hooks/10-tbb  | 2 +-
 vagrant/provision/setup-tails-builder | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/config/chroot_local-hooks/10-tbb
b/config/chroot_local-hooks/10-tbb
index 54e77e63be..8bf5d5c0b2 100755
--- a/config/chroot_local-hooks/10-tbb
+++ b/config/chroot_local-hooks/10-tbb
@@ -35,7 +35,7 @@ download_and_verify_files() {
 (
 cd "${destination}"
 echo "Fetching ${base_url}/${tarball} ..."
-curl --remote-name "${base_url}/${tarball}"
+curl --retry 20 --remote-name "${base_url}/${tarball}"
 )
 actual_sha256="$(sha256sum "${destination}/${tarball}" | cut
-d' ' -f1)"
 if [ "${actual_sha256}" != "${expected_sha256}" ]; then
diff --git a/vagrant/provision/setup-tails-builder
b/vagrant/provision/setup-tails-builder
index 9c6b044d49..75f84ffd87 100755
--- a/vagrant/provision/setup-tails-builder
+++ b/vagrant/provision/setup-tails-builder
@@ -18,6 +18,9 @@ fi

 rm -f /etc/apt/preferences.d/* /etc/apt/sources.list.d/*

+# Configure apt to retry
+echo 'APT::Acquire::Retries "20";' > /etc/apt/apt.conf.d/99retries
+
 # Add our builder-jessie repository for live-build, and pin it low
 echo 'deb http://deb.tails.boum.org/ builder-jessie main' >
/etc/apt/sources.list.d/tails.list
 sed -e 's/^[[:blank:]]*//' > /etc/apt/preferences.d/tails 

Re: [Tails-dev] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-10 Thread intrigeri
Hi,

Arnaud:
> thanks for your support !

:)

> However, after a lot of investigation (mostly in the wrong direction),
> I'm pretty sure to know what's wrong. It's not Tails, it's not the VM,
> it's not my config. It seems to be the network here in Vietnam.

OK :(

> From my understanding, I can change the Debian mirror used for
> provisioning the VM. But when it comes to build the Tails iso, I have no
> choice but to download the packages from the Tails mirror, right ? Same
> goes for TorBrowser ?

Exactly.

> Right now I'm working on tweaking the build system, and adding retries
> here and there, so that the build keeps going and doesn't give up so
> easily. I think that `apt-cacher-ng` should help me to mitigate the
> problem, but up to now I destroyed the VM too often to take advantage of
> it ;)

Sounds great!

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-10 Thread Arnaud
Hi all,

thanks for your support !

I updated to Tails 3.0-beta2, destroyed the VM, started again, failed
again !

My build config is very 'vanilla', I didn't touch anything. So it means
that the build happens within the VM, with apt-cacher-ng enabled. The VM
has the default settings: 512M of RAM, and enough storage (I didn't find
where that one is defined btw).

However, after a lot of investigation (mostly in the wrong direction),
I'm pretty sure to know what's wrong. It's not Tails, it's not the VM,
it's not my config. It seems to be the network here in Vietnam.

So yep, I'm living in Vietnam. Overall, the network is not that bad
here, however they have a problem with the underwater cable AAG (Asia
America Gateway). Basically, from time to time the AAG stops working,
and the AAG is the main cable that connects Vietnam to the rest of the
world. What happens then is a bit unclear to me, to say the least.

Well, from a user point of view, what happens is very clear. The web
becomes a bit unreliable. Sometimes, websites are very slow to load, or
become completely unavailable for a few minutes. Amazingly, google
searches are still fast (more on that later). I've seen `apt-get update`
on my machine starting very fast, then slowing down and down, then
stalled. So I opened my `sources.list`, got rid of the
`httpredir.debian.org` url, replaced by `debian.xtdv.net` (the only
Vietnamese Debian mirror that I know) to ensure my traffic remains in
Vietnam, and now it works like a charm.

From a technical point of view, what happens is quite unclear. I played
a bit with `nmap --traceroute --script traceroute-geolocation`, and this
is a great tool ! I can see that requests to
time-based.snapshots.deb.tails.boum.org go a long way through Europe.
Requests to www.vagrantup.com go through Japan, which seems a bit more
direct. Amazingly, requests to google go directly from Vietnam to the
States. Which explains why they are still fast when everything else is
slow, and which makes me wonder if google has private undersea cables.

Anyway, I'm no expert, and I'm not sure how to interpret these results.
I have no idea how it will look like when I run the same traceroute
tomorrow. So let's get back to Tails.

The build process involves downloading a lot of data. Most of it from
Tails server, and I think the problem here is just that the connectivity
in Vietnam right now is way too bad to handle that. Somehow it always
fails sooner or later, it timeouts or something.

From my understanding, I can change the Debian mirror used for
provisioning the VM. But when it comes to build the Tails iso, I have no
choice but to download the packages from the Tails mirror, right ? Same
goes for TorBrowser ?

Right now I'm working on tweaking the build system, and adding retries
here and there, so that the build keeps going and doesn't give up so
easily. I think that `apt-cacher-ng` should help me to mitigate the
problem, but up to now I destroyed the VM too often to take advantage of
it ;)

I'll keep trying and let you know how it goes.

Cheers !



If you were interested in all this conversation (a bit off-topic), you
might find the following links interesting:

http://www.submarinecablemap.com

https://www.citypassguide.com/en/travel/ho-chi-minh-city/daily/news/neverending-story-vietnam-and-the-undersea-internet-cable-ruptures





___
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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-10 Thread anonym
segfault:
> Arnaud:
>> The failure doesn't always happen at the same point of the build. At
>> first, I thought it was related to `apt`, but I also experienced in
>> failure on a `curl` command (when downloading Tor Browser, in
>> `config/chroot_local-hooks/10-tbb`). I don't have the log anymore, but
>> it was also a name resolution failure.
> 
> I too experienced build failures during
> `config/chroot_local-hooks/10-tbb`. It turned out to be caused by
> insufficient memory, of which I had 8 GB RAM (some took by the gnome
> session and system services) plus 8 GB swap. I could build successfully
> after increasing swap to 16 GB.

Interesting! We try to make sure that RAM builds can start only if enough RAM 
is available, but I guess there could be edge cases when close to the minimal 
amount.

Arnaud, how much RAM does your host system have, and which TAILS_BUILD_OPTIONS 
do you use? Also, please try adding `noram` to TAILS_BUILD_OPTIONS (but first 
make sure the VM is shut down, e.b. `rake vm:halt`).

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-10 Thread segfault
Arnaud:
> The failure doesn't always happen at the same point of the build. At
> first, I thought it was related to `apt`, but I also experienced in
> failure on a `curl` command (when downloading Tor Browser, in
> `config/chroot_local-hooks/10-tbb`). I don't have the log anymore, but
> it was also a name resolution failure.

I too experienced build failures during
`config/chroot_local-hooks/10-tbb`. It turned out to be caused by
insufficient memory, of which I had 8 GB RAM (some took by the gnome
session and system services) plus 8 GB swap. I could build successfully
after increasing swap to 16 GB.

Hope this helps.

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] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-09 Thread intrigeri
Hi Arnaud,

Arnaud:
> I've been trying to build a Tails image an didn't succeed yet. My
> machine is running Debian 9.

> As for Tails, I checked out the tag '3.0-beta1', and that's what I'm
> trying to build at the moment.

> So far, the build always fails sooner or later because of network
> failure, and most precisely name resolution failure. A typical log looks
> like that:

> Err http://time-based.snapshots.deb.tails.boum.org sid Release.gpg
> Could not resolve 'time-based.snapshots.deb.tails.boum.org'

Please share the full build log and the exact commands you're running,
so we can investigate. 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.

[Tails-dev] Debian 9: Build fails consistently, name resolution fails sooner or later

2017-03-08 Thread Arnaud
Dear Tails,

first, let me quickly introduce myself, I'm Arnaud, part of the
SilentKeys team. Please refer to this mail to remember about SilentKeys
(it was quite a while ago):
https://mailman.boum.org/pipermail/tails-project/2016-April/000488.html

I've been trying to build a Tails image an didn't succeed yet. My
machine is running Debian 9.

As for Tails, I checked out the tag '3.0-beta1', and that's what I'm
trying to build at the moment.

So far, the build always fails sooner or later because of network
failure, and most precisely name resolution failure. A typical log looks
like that:

Err http://time-based.snapshots.deb.tails.boum.org sid Release.gpg
Could not resolve 'time-based.snapshots.deb.tails.boum.org'

The failure doesn't always happen at the same point of the build. At
first, I thought it was related to `apt`, but I also experienced in
failure on a `curl` command (when downloading Tor Browser, in
`config/chroot_local-hooks/10-tbb`). I don't have the log anymore, but
it was also a name resolution failure.

I also experienced another problem at provisionning: sometimes the call
`/usr/lib/apt-cacher-ng/expire-caller.pl` (from `setup-tails-builder`)
hangs. It might be related or not, I'm not sure.

I don't think the problem is my internet connectivity. I have a good
connection and never experience this kind of problem in my daily use. I
tried a little test like that in the VM for a while.

while true; do wget -O /dev/null -nv
time-based.snapshots.deb.tails.boum.org; sleep 5; done

I didn't see any failure.

I had some doubt about `apt-cacher-ng`, so I ran a build without proxy.

TAILS_BUILD_OPTIONS=noproxy rake build

It failed all the same.

Now I'm a bit stuck. I'm wondering if I should dig on the `libvirt`
side, but I don't find anything related on the net. I'm wondering if I'm
missing something obvious.

If anyone already experienced this kind of error, or have any advice,
that would be great.

Cheers,
Arnaud
___
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.