Dear Maintainer,

Whilst golang-github-fluent-fluent-logger-golang builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.000000 IP 8cd59013b451.40759 > dnscache.uct.ac.za.domain: 15437+ AAAA? foobarhost.uct.ac.za. (38)
  00:00:00.000050 IP 8cd59013b451.58876 > dnscache.uct.ac.za.domain: 44982+ A? foobarhost.uct.ac.za. (38)
  00:00:00.003746 IP dnscache.uct.ac.za.domain > 8cd59013b451.40759: 15437 NXDomain* 0/1/0 (92)
  00:00:00.004865 IP dnscache.uct.ac.za.domain > 8cd59013b451.58876: 44982 NXDomain* 0/1/0 (92)
  00:00:00.005034 IP 8cd59013b451.60462 > dnscache.uct.ac.za.domain: 42162+ AAAA? foobarhost.chris-lamb.co.uk. (45)
  00:00:00.005038 IP 8cd59013b451.55094 > dnscache.uct.ac.za.domain: 37100+ A? foobarhost.chris-lamb.co.uk. (45)

  [..]

The full build log (including tcpdump output) is attached.


Regards,

Hi Chris,

Thank you for submitting those bugs. I agree that it is a legitimate problem
that needs addressing. However I strongly disagree with severity of those
bugs. Obviously packages should not download anything during build for
security and reproducibility reasons. But here post-build tests attempt to
access internet which is relatively harmless in this context. Indeed tests
trying to access internet from offline environment is hardly a "serious"
problem regardless of what policy says.
Thanks to your bug reports we will eventually address and fix those problems.
In the mean time this should not block testing migrations so I'm lowering
severity of those bugs and I recommend submitting similar bugs with severity
not higher than "important".

---

The most fatal blow to progress is slavery of the intellect. The most
sacred right of humanity is the right to think, and next to the right to
think is the right to express that thought without fear.
        -- Helen H. Gardner, "Men, Women and Gods"

Dmitry wrote:

I guess our differences on this issue are three-fold:

Firstly, network access is not harmless in that it, at the very least, it
leaks the privacy of the developer building something failing some variation
of the DFSG "dissident" test.

(Furthermore, network access can naturally lead to vulnerabilities, although
I'm not claiming that any of the CC'd packages are doing so, am speaking
only to the principle.)

Secondly, retaining such tests provide little value as checks of the
correct functioning of the package given that the package does not FTBFS if
network access is restricted entirely.

In this sense, they engender a false sense of security about the correct
working of the package which is, again, not harmless from a quality assurance
point of view.

Lastly, they aren't really "post-build" as you suggest - they are surely an
integral part of build.

I really don't like to be a stickler for quoting Policy (and using that as a
blunt and inflexible instrument of change/agenda), but I guess that redefining
tests as "post-build" does have the sneaky advantage in that they aren't simple
obvious violations of the paragraph in question. :)


Regards,

I thought the only difference is issues' severity....

No disagreement here. Yet I had to remind that build environment is offline
hence this is only a little problem.

Noted. I'm not against fixing the problem but there are more important issues
to prioritise.

Correct. However removing those tests is an effort that can be done without
rush.
tests that try to access network from offline environment. I certainly prefer
the latter until I can find time to selectively disable tests. I certainly do
not want issues with inflated severity in my queue...

Yes, _optional_ part of the build. ;)  We don't have to run 'em but we want
to.
"prisoners should not attempt to leave locked cells" while reality is that
they can _try_ but attempt would be futile.

I recognise the problems and I agree to fix them but I am not convinced that
those issues should be treated with highest priority. This way or another
practical implications are mild. I hope it makes sense...
---

Men can only be happy when they do not assume that the object of life is
happiness.
        -- George Orwell

Dmitry,

I think this is not a valid argument. Chris is right that the packages
are not following policy, and that they should be fixed. Packaging all
the world software does not serve our users if we are not following our
procedures.

I have seen already a few instances of packages you prepared where you
just skip the tests, or skip failures, instead of fixing the real
problems these are covering. This is not good for Debian and it is
definitely not good for the team.

Please, reconsider your attitude.

Dmitry wrote:

This was not my intention and I have already gone out of my way to avoid such
an impression so I apologise if I could have made this clearer.

I would believe these bugs to be serious, even if Policy was silent on this
issue.

You say "yes", but then you directly counter my point - they are an integral
part of the build and upstream. Whilst you can disable the running of tests,
that's something one must go out of the way to do so.

Quality is not something "we kinda want" in Debian and nor should we conflate
the orthogonal ideas of severity and priority - using words like "rush" make
me more than a little nervous.
[..]

I don't follow what you mean by "build environment is offline", and your
analogy does not seem to apply as the attempts are not futile..


Regards,

No that's all right, you have nothing to apologize for. :)

I'd say they are serious-ish (in a technical sense) and surely worth fixing
yet I still see them as less serious than build failures. I recognize
importance of fixing 'em but I can't treat 'em as a matter of urgency like
severity "serious" suggests.

I was merely trying to provide some context.

Personally I feel uncomfortable when I receive bug that user submits with
higher severity than necessary. Everybody wants their bugs fixed ASAP and
surely from submitter prospective it is important to prioritize their bugs
because they are affected.
Who is the victim here? Build system? Maintainer? It is hard to say who
suffers the most from those bugs that you reported. Whist I strive for
perfection I also need to make the job done. Those bugs will be fixed as soon
as I can (unless team will do it before me) but not sooner than I intend to
address bugs that holding someone from doing something...
IMHO bug's severity should help maintainer to prioritise properly.

I was under impression that build servers do not allow internet access.
If build scripts can access WWW from buildd servers then it would be a much
more serious bug.

Surely there is corner case of "dpkg-buildpackage" that can be vulnerable to
network access during build but even "pbuilder" successfully prevent attempts
to access network.

Even build logs suggest that packages attempt to access network but fail.

I would be much more concerned about the issue if I knew that build
environment allows internet access.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
        -- Winston Churchill

Hi Dimitry,

I feel like we are talking at cross-purposes and have come to an
impasse to the point that we are going in circles.

You're free to prioritise your packaging efforts as you feel
suitable, I am not asking you to do drop everything to fix these.

Filing a bug--of any severity--is not a comment on the maintainer
and so you shouldn't feel "uncomfortable".

They generally do.


Regards,

That certainly makes those bugs more important but also reveals a more
serious problem. Is there anything you can do to restrict or limit internet
access on buildd servers?

We should not trust build script not to access internet. Even pbuilder limits
network access and build servers should do it as well.

Besides I've just disabled networking test in "franela-goreq" and it was not
even trying to access internet -- the particular test in question was
accessing unrouteable 10.255.255.1 from private subnet to test timeout --
IMHO not much of a threat even on unrestricted build servers to justify
severity "serious" unless we follow the policy to the letter...

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
        -- George Orwell

I think you are confused about these bugs. They are being filed against
packages that attempt network connectiviity but do not FTBFS if those
requests fail, so disabling internet access on buildds is an related but
actually different issue altogether.

Furthermore, keeping packages as-is would still leak the privacy of
end-users, deriviates, etc. who are rebuilding packages.


Regards,

Makes sense. Thank you.

Absolutely.

---

He who cannot obey himself will be commanded. That is the nature of living
creatures.
        -- Friedrich Nietzsche

Dear Dmitry,

Gentle ping on this?


Regards,

About what?

---

Moral courage is the most valuable and usually the most absent
characteristic in men.
        -- George S. Patton

Hello,

Bug #830673 in golang-github-fluent-fluent-logger-golang reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-fluent-fluent-logger-golang/-/commit/5520a77308f428ebb64c5cbc27e8abc974502396

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/830673

We believe that the bug you reported is fixed in the latest version of
golang-github-fluent-fluent-logger-golang, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 830673@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon Josefsson <simon@josefsson.org> (supplier of updated golang-github-fluent-fluent-logger-golang package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 08 Aug 2026 17:16:16 +0200
Source: golang-github-fluent-fluent-logger-golang
Architecture: source
Version: 1.10.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed-By: Simon Josefsson <simon@josefsson.org>
Closes: 830673
Changes:
 golang-github-fluent-fluent-logger-golang (1.10.1-1) unstable; urgency=medium
 .
   * Team upload
   * Use Standards-Version: 4.7.4
   * Drop Priority: optional
   * Drop Rules-Requires-Root: no
   * Use watch v5
   * Use gbp sign-tags
   * Use gbp upstream-vcs-tag
   * Bump compat to 14
   * Bump debian/* copyright years
   * Drop unnecessary B-D on golang-github-bmizerany-assert-dev
   * Avoid network access during build (Closes: #830673)
   * Use DEP14 layout
Checksums-Sha1:
 c2444d7afc542170f20f84405fb97cfa33485785 2788 golang-github-fluent-fluent-logger-golang_1.10.1-1.dsc
 da3b7d1ba740881982d3fa4cffec4a205c0d1d72 22676 golang-github-fluent-fluent-logger-golang_1.10.1.orig.tar.xz
 70e78ba6e0364b69af9653d6e7eca1469853afbd 3220 golang-github-fluent-fluent-logger-golang_1.10.1-1.debian.tar.xz
 53b498ca13b3453d86ea3c962810769ee11c40ec 73276 golang-github-fluent-fluent-logger-golang_1.10.1-1.git.tar.xz
 0ddca517f16a8aec4457eacba9bd72c9a3a7157d 17692 golang-github-fluent-fluent-logger-golang_1.10.1-1_source.buildinfo
Checksums-Sha256:
 b88d62109cc00c9d04682d828f9b7ee5b6ff305ab445505b5abf65665f4b754f 2788 golang-github-fluent-fluent-logger-golang_1.10.1-1.dsc
 a9a295994573e5e9bb711ff2c00e132b020038feb9bd1d0131c5a45eba111482 22676 golang-github-fluent-fluent-logger-golang_1.10.1.orig.tar.xz
 65a77de58009786f764ecf713ba83a14d85bf0efc31eb8cc73cc79b93d1ce7a8 3220 golang-github-fluent-fluent-logger-golang_1.10.1-1.debian.tar.xz
 ecaf95ed71ea346f8352b595148ce171016bac54b34613efa2718b604affb51b 73276 golang-github-fluent-fluent-logger-golang_1.10.1-1.git.tar.xz
 dae7df7ace611f12d214fce72fba367f1c75c2f6af29b32a97bf328b1aa1d1b7 17692 golang-github-fluent-fluent-logger-golang_1.10.1-1_source.buildinfo
Files:
 58d779b91bf308577b8af53c543b6663 2788 golang optional golang-github-fluent-fluent-logger-golang_1.10.1-1.dsc
 b6ef97cac97de550d2ba9d3b50be5b05 22676 golang optional golang-github-fluent-fluent-logger-golang_1.10.1.orig.tar.xz
 a4d23bc806faf8b51df15962c857ecf6 3220 golang optional golang-github-fluent-fluent-logger-golang_1.10.1-1.debian.tar.xz
 2e004116594f8a169282b7a0794441f0 73276 golang None golang-github-fluent-fluent-logger-golang_1.10.1-1.git.tar.xz
 8626ad1d2889828e86066253866b35f4 17692 golang optional golang-github-fluent-fluent-logger-golang_1.10.1-1_source.buildinfo
Git-Tag-Info: tag=334137b7d083364c296fd50019bb7e2e9064541a fp=a3cc9c870b9d310abad4cf2f51722b08fe4745a2
Git-Tag-Tagger: Simon Josefsson <simon@josefsson.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmp3T0QACgkQYG0ITkaD
wHmqFw/9HL/MnFW9vqPriRU4Ez3bmS4mEJ7GZX8Ge9sfO1vdO0qruYfUynZuws3e
cv9rIA7rR8At4HX+0+7ygAkBTPljj5RURr0lJ0AZGwaOL+Cx24hfg2OUvP+MGnA2
GgZ/JhzvFRRUCbNW8B+k/vPYj6/Xgn7ORQSYU3WVoMoIphCFSfxhW9eSS+B392vZ
EiTvDIa2w4lMFiizgzzGIgUk5tyBNi0U5y/cpiNMfMdymVh9mbFDDk0cbSD1dc5x
QTrNVHZgZ4HW7J9jt3hkOxRobxawopiqZWdCdLqrCOzGByzud8MsARycvBqJeC8R
QpPoTY7yn92eLne3P9iJ7fCrnxTbwYMkzG/Ed8Ma+gbO2jaTSFdtmSWDXVPuzTYm
kJhk1nqWIqax3AdfABvGNfW2ZomUEDxT+UR0mPhqNShX5IoVKt72Bi+stzFufc2J
uH0Laern0ryBPoo3gY0G6XbXK6KpnfUvp3pOZ9PKcZKXGlMNzxC7WMO6nvDd6duB
M1pUedUqEhuP7HXMBqEtLxVAObNYfTnR16vIazldhtUAyeGMv5divx344vw0nRI5
zU9ei2uvvP6XC+NrTDKft/0CU1/TeA1B/W9TjHEFdhTrBIO7aU53tWX5xTBofUmM
tHUwKWh1Hv8ECqnrFPLfOM8NvhtpaK9DlaBCM2JUdw3WbQHS6nA=
=YtZU
-----END PGP SIGNATURE-----