On Mon, May 28, 2012 at 8:36 PM, Daniel Baumann <[email protected]> wrote: > On 05/28/2012 09:12 PM, Rui Miguel P. Bernardo wrote: >> Yes, we need to use those variables you have set in lb_config in >> lb_bootstrap_debootstrap and lb_binary_debian-installer. With the vars >> set by lb_config I suppose that's the next step? > > they are in the environment now and should be used by default, without > any modification in the other lb_* stuff (that was the whole point of > putting them into the environment in the first place). wget, > cdebootstrap/debootstrap should just pick it up automatically.
I've installed squid proxy here and tested the latest lb_config changes again. Indeed, it works out-of-the-box with squid, IIF you have http_proxy set in the environment. If you don't have http_proxy in your environment, squid is not used for debootstrap nor debian-installer, only in chroot. That's what was happening when I've tested with apt-cacher-ng 2 days ago. I don't use http_proxy variable in my system, just apt-cacher-ng with LB_APT_HTTP_PROXY option. I remember having troubles with chroot hooks downloads, and also with sudo (which doesn't preserve user env vars), when I tested http_proxy variable with apt-cacher-ng, so I don't use it. I've tested again today, now just with the latest changes in lb_config, with apt-cacher-ng and with export http_proxy="http://localhost:3142"; before running "lb config". It works IIF the http_proxy is preserved in sudo or exported into root environment. Some results: 1. Without having any http_proxy variable set anywhere and just setting LB_APT_HTTP_PROXY, debootstrap and debian-installer stages will NOT use neither squid nor apt-cacher-ng proxy. Just chroot stage will use it. 2. If I export http_proxy it will work with both squid and apt-cacher-ng, but apt-cacher breaks chroot hooks if they download things from the network (apt-cacher doesn't cache anything but debian files). 3. It works with both squid and apt-cacher-ng even if I don't export http_proxy anywhere in the environment and add the following code in the beginning of lb_bootstrap_debootstrap and lb_binary_debian-installer scripts: if [ -n "${http_proxy}" ] then export http_proxy fi Since http_proxy is usually set in the envronment for squid users, I think it's fine to also export http_proxy in lb_bootstrap_debootstrap and lb_binary_debian-installer. At least it would safer, in the sense that apt-cacher users could use LB_APT_HTTP_PROXY without setting http_proxy and without breaking binary and chroot hooks with it. http_proxy would be only set in those live-build scripts and would not interfere with chroot or binary hooks. And it would work for both squid and apt-cacher users and also for sudo users, since the http_proxy variable would not need to be preserved. Ofcourse, that's what I find here. I can be wrong. I still didn't tested if this would break (with apt-cacher) with hooks that make downloads, but it shouldn't. The only problem I see is in lb_binary_debian-installer, with sparch architecture, which downloads a mini.iso file, and that would only happen with apt-cacher. What do you guys think about this? Is this doable this way? With export in the scripts? (/me ducks). BTW, for a standard debian live-build lb config -d squeeze -a i386 --linux-flavours 486 \ --archive-areas "main contrib non-free" \ --debian-installer live the time saved was about 3 minutes with a fast mirror. With 2 linux-flavours (486 and 686) it should be more depending on the mirror (didn't test it). -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cap1yx5xwyhyi0vz5b7ucrcogoax6au2rk+am_mp0uebdhyc...@mail.gmail.com
