[PATCH] dpkg-source: Export proxy settings

[Kazunori Kobayashi]

This sets proxy environment variables to be passed to schroot.

Signed-off-by: Kazunori Kobayashi <kazunori....@miraclelinux.com>
---
meta/classes/dpkg-source.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta/classes/dpkg-source.bbclass b/meta/classes/dpkg-source.bbclass
index 4877abd6..a16e5812 100644
--- a/meta/classes/dpkg-source.bbclass
+++ b/meta/classes/dpkg-source.bbclass
@@ -65,6 +65,8 @@ do_fetch_common_source() {
trap 'exit 1' INT HUP QUIT TERM ALRM USR1
trap 'schroot_cleanup' EXIT

+ E="${@ isar_export_proxies(d)}"
+
schroot -r -c ${session_id} -d / -u root -- \
apt-get update -o Dir::Etc::SourceList="sources.list.d/isar-apt.list" -o Dir::Etc::SourceParts="-" -o APT::Get::List-Cleanup="0"
schroot -r -c ${session_id} -d / -- \
--
2.39.5

[Florian Bezdeka]

On Tue, 2025-10-28 at 10:35 +0900, Kazunori Kobayashi wrote:
> This sets proxy environment variables to be passed to schroot.

I see, but could you please elaborate a bit more why this is actually
needed? What goes wrong at the moment? Why do you need networking
inside the schroot environment?

Best regards,
Florian

> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/isar-users/20251028013532.1388325-1-kazunori.kobayashi%40miraclelinux.com.

[Kazunori Kobayashi]

Hi,

On 10/28/25 20:59, Florian Bezdeka wrote:
> On Tue, 2025-10-28 at 10:35 +0900, Kazunori Kobayashi wrote:
>> This sets proxy environment variables to be passed to schroot.
> I see, but could you please elaborate a bit more why this is actually
> needed? What goes wrong at the moment? Why do you need networking
> inside the schroot environment?
>
> Best regards,
> Florian

I assume Isar considers networking via proxy in such as downloading
something in do_fetch, resolving dependencies in do_dpkg_build and
package installation on the target root filesystem in do_rootfs_install.
We can actually use it in such typical cases with no problem.

This change has effect on a very limited case, where a self-built
package fetching a source package via the apt:// scheme in SRC_URI is
specified as a native package (<package>-native) to IMAGE_INSTALL or
SDK_INSTALL. In this case, the source package is fetched via apt-get in
schroot in do_fetch_common_source but proxy environment variables are
not set in the executing shell function.

Isar would overlook this case compared to other fetching cases
considering proxy and this change is to improve it.

Regards,
Kazunori

>
>> Signed-off-by: Kazunori Kobayashi <kazunori....@miraclelinux.com>
>> ---
>> meta/classes/dpkg-source.bbclass | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/classes/dpkg-source.bbclass b/meta/classes/dpkg-source.bbclass
>> index 4877abd6..a16e5812 100644
>> --- a/meta/classes/dpkg-source.bbclass
>> +++ b/meta/classes/dpkg-source.bbclass
>> @@ -65,6 +65,8 @@ do_fetch_common_source() {
>> trap 'exit 1' INT HUP QUIT TERM ALRM USR1
>> trap 'schroot_cleanup' EXIT
>>
>> + E="${@ isar_export_proxies(d)}"
>> +
>> schroot -r -c ${session_id} -d / -u root -- \
>> apt-get update -o Dir::Etc::SourceList="sources.list.d/isar-apt.list" -o Dir::Etc::SourceParts="-" -o APT::Get::List-Cleanup="0"
>> schroot -r -c ${session_id} -d / -- \
>> --
>> 2.39.5
>>
>> --
>> You received this message because you are subscribed to the Google Groups "isar-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/isar-users/20251028013532.1388325-1-kazunori.kobayashi%40miraclelinux.com.

--
Kazunori Kobayashi
Cybertrust Japan Co., Ltd.
https://www.cybertrust.co.jp/

[Florian Bezdeka]

On Wed, 2025-10-29 at 10:43 +0900, Kazunori Kobayashi wrote:
> I assume Isar considers networking via proxy in such as downloading
> something in do_fetch, resolving dependencies in do_dpkg_build and
> package installation on the target root filesystem in do_rootfs_install.
> We can actually use it in such typical cases with no problem.
>
> This change has effect on a very limited case, where a self-built
> package fetching a source package via the apt:// scheme in SRC_URI is
> specified as a native package (<package>-native) to IMAGE_INSTALL or
> SDK_INSTALL. In this case, the source package is fetched via apt-get in
> schroot in do_fetch_common_source but proxy environment variables are
> not set in the executing shell function.

It seems that I missed that the apt:// fetcher is invoked quite late,
so already inside the schroot environment. That is done that way to use
the apt machinery of the target distribution already.

So yes, that seems correct.

Thanks for the additional information. You could (if you like) send a
v2 with that information part of the commit message. Will help the
maintainers as well.

Thanks for your contribution!

Best regards,
Florian

[Kazunori Kobayashi]

On 10/29/25 22:53, Florian Bezdeka wrote:
> On Wed, 2025-10-29 at 10:43 +0900, Kazunori Kobayashi wrote:
>> I assume Isar considers networking via proxy in such as downloading
>> something in do_fetch, resolving dependencies in do_dpkg_build and
>> package installation on the target root filesystem in do_rootfs_install.
>> We can actually use it in such typical cases with no problem.
>>
>> This change has effect on a very limited case, where a self-built
>> package fetching a source package via the apt:// scheme in SRC_URI is
>> specified as a native package (<package>-native) to IMAGE_INSTALL or
>> SDK_INSTALL. In this case, the source package is fetched via apt-get in
>> schroot in do_fetch_common_source but proxy environment variables are
>> not set in the executing shell function.
> It seems that I missed that the apt:// fetcher is invoked quite late,
> so already inside the schroot environment. That is done that way to use
> the apt machinery of the target distribution already.

Thank you for instructing me on the existing apt fetcher issue. If
possible, I would like to understand how to fix the issue properly.
Could you please roughly clarify it on the code base, if you don't mind?

I found a different apt fetcher code from do_fetch_common_source in the
following place and it seems to set proxy settings before fetching a apt
source package inside the schroot environment.

https://github.com/ilbers/isar/blob/master/meta/lib/aptsrc_fetcher.py

The apt fetcher code seems duplicate, but do you think invoking this one
at the appropriate moment is preferable?

Regards,
Kazunori

>
> So yes, that seems correct.
>
> Thanks for the additional information. You could (if you like) send a
> v2 with that information part of the commit message. Will help the
> maintainers as well.
>
> Thanks for your contribution!
>
> Best regards,
> Florian

[Kazunori Kobayashi]

I would be grateful if this patch is accepted just with the additional
message. I will send a v2 patch soon after this.

Please ignore the previous question if I mixed up something in it.

[Kazunori Kobayashi]

This change has effect on a very limited case, where a self-built
package fetching a source package via the apt:// scheme in SRC_URI is
specified as a native package (<package>-native) to IMAGE_INSTALL or
SDK_INSTALL. In this case, the source package is fetched via apt-get in
schroot in do_fetch_common_source but proxy environment variables are
not set in the executing shell function.

[Florian Bezdeka]

On Thu, 2025-10-30 at 11:36 +0900, Kazunori Kobayashi wrote:
> On 10/29/25 22:53, Florian Bezdeka wrote:
> > On Wed, 2025-10-29 at 10:43 +0900, Kazunori Kobayashi wrote:
> > > I assume Isar considers networking via proxy in such as downloading
> > > something in do_fetch, resolving dependencies in do_dpkg_build and
> > > package installation on the target root filesystem in do_rootfs_install.
> > > We can actually use it in such typical cases with no problem.
> > >
> > > This change has effect on a very limited case, where a self-built
> > > package fetching a source package via the apt:// scheme in SRC_URI is
> > > specified as a native package (<package>-native) to IMAGE_INSTALL or
> > > SDK_INSTALL. In this case, the source package is fetched via apt-get in
> > > schroot in do_fetch_common_source but proxy environment variables are
> > > not set in the executing shell function.
> > It seems that I missed that the apt:// fetcher is invoked quite late,
> > so already inside the schroot environment. That is done that way to use
> > the apt machinery of the target distribution already.
>
> Thank you for instructing me on the existing apt fetcher issue. If
> possible, I would like to understand how to fix the issue properly.
> Could you please roughly clarify it on the code base, if you don't mind?
>
> I found a different apt fetcher code from do_fetch_common_source in the
> following place and it seems to set proxy settings before fetching a apt
> source package inside the schroot environment.
>
> https://github.com/ilbers/isar/blob/master/meta/lib/aptsrc_fetcher.py

This one is the fetcher that gets involved when you have something like
apt:// in your SRC_URI.

>
> The apt fetcher code seems duplicate, but do you think invoking this one
> at the appropriate moment is preferable?

The task that you modified (correctly) is invoked when building a
package. It fetches the Debian source package from the (internal)
repository.

There are two apt-get commands here. The first one is local only, the
second one will talk to "upstream" / the network as well. This will
obviously fail if proxies are involved.

>
> Regards,
> Kazunori
> >
> > So yes, that seems correct.
> >
> > Thanks for the additional information. You could (if you like) send a
> > v2 with that information part of the commit message. Will help the
> > maintainers as well.
> >
> > Thanks for your contribution!
> >
> > Best regards,
> > Florian
>
>
> --
> Kazunori Kobayashi
> Cybertrust Japan Co., Ltd.
> https://www.cybertrust.co.jp/
>

> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/isar-users/a5d85c10-7dc7-40db-a9d7-4ded45925c3c%40miraclelinux.com.

[Kazunori Kobayashi]

I see. I mixed up the apt fetchers for SRC_URI and for being invoked
when building a package. Thank you.

I have already posted a v2 patch with the commit message modified. I
would be grateful if you could check it.

Regards,
Kazunori