You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
no network -- most buildds will have no network access available. Your package build+test process must not attempt to use the network or assume that any network interface is available.
For packages in the main archive, required targets must not attempt network access, except, via the loopback interface,
to services on the build host that have been started by the build.
Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don’t themselves create (i.e., for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository.
It can be assumed that many other distributions have similar policies.
So what is the right way to package this? I don't know. For Debian, most likely, all build and runtime dependencies would need to be packages and uploaded to packages.debian.org separately. Ideally, apparmor.d would not require any dependencies unavailable from official distribution package repositories.
For Kicksecure, Whonix, the same policies have been inherited.
The text was updated successfully, but these errors were encountered:
I am well aware of this. However, there is a (heavily used) golang dependency that is not packaged in Debian (despite being on debian salsa): golang-github-arduino-go-paths-helper
I also need to ensure the go code is built with dh-golang and not manually as it is currently done. PR is welcome...
This is probably a blocker for
apparmor.d
be eligible to be added topackages.debian.org
.Quote https://wiki.debian.org/buildd
More references:
Ubuntu might inherit the same policy.
Fedora has a similar policy. Quote https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access
It can be assumed that many other distributions have similar policies.
Embedded code copies are also not permissible in Debian as per:
https://wiki.debian.org/EmbeddedCopies
So what is the right way to package this? I don't know. For Debian, most likely, all build and runtime dependencies would need to be packages and uploaded to
packages.debian.org
separately. Ideally, apparmor.d would not require any dependencies unavailable from official distribution package repositories.For Kicksecure, Whonix, the same policies have been inherited.
The text was updated successfully, but these errors were encountered: