Bug#813471: Seeking seconds for patch to permit some network access to localhost
control: tag -1 +patch Hello, Here is a patch, for which I am seeking seconds, that tries to capture the points raised by Osamu, Guillem and Paul without getting into legalese -- Bill has a point. In particular, I think we can trust package maintainers to interpret "started by the build" sensibly. Discussion by Ian and Simon cloned into a separate bug and continued there. Gunnar's discussion should be a separate bug, so setting it aside for now. > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 9e7d79c..34c90b3 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that > these targets > depend on must also be non-interactive. > > For packages in the main archive, no required targets may attempt > -network access. > +network access, except to services on the build host that have been > +started by the build, via the loopback interface. > > The targets are as follows: > -- Sean Whitton signature.asc Description: PGP signature
Bug#904248: Beginnings of a patch to add netbase to build-essential
Hello, Thank you for the discussion, Ian and Simon. Here is the beginnings of a patch: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 9e7d79c..f27226e 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -40,9 +40,15 @@ example, if building a package requires a certain > compiler, then the > compiler should be specified as a build-time dependency. > > It is not necessary to explicitly specify build-time relationships on a > -minimal set of packages that are always needed to compile, link and put > -in a Debian package a standard "Hello World!" program written in C or > -C++. The required packages are called *build-essential*, and an > +minimal set of packages that are always needed > + > +- to compile, link and put in a Debian package a standard "Hello > + World!" program written in C or C++; and > + > +- for the package build to resolve the system hostname to a > + fully-qualified domain name using the C standard library. [#]_ > + > +The required packages are called *build-essential*, and an > informational list can be found in > ``/usr/share/doc/build-essential/list`` (which is contained in the > ``build-essential`` package). [#]_ > @@ -757,6 +763,10 @@ according to this convention, the C source code of an > executable > ``debian/missing-sources/checksum/util.c``. > > .. [#] > + The functionality described in this last list item is provided by > + the "netbase" package at the time of writing. > + > +.. [#] > Rationale: > > - This allows maintaining the list separately from the policy Ian also thinks that package builds should be able to access the information normally contained in /etc/protocols and /etc/services by means of the C standard library. Could you say more about why this is needed, and provide wording for a third bullet point in the list in my patch, which describes the functionality of /etc/protocols and /etc/services, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#903977: ITP: sbws -- Simple Bandwidth Scanner
Hello! Philipp Kern: > On 18.07.2018 20:38, ju xor wrote: >> Philipp Kern: >>> On 2018-07-18 18:24, ju xor wrote: Philipp Kern: > Should this live in some kind of tor-* namespace? no >>> Without any rationale? :( >> i'm not sure what you mean, but in case it helps, here some arguments >> why sbws package is not called something like tor-sbws: >> - upstream is not using "tor-*" in the name >> - i don't think there's a Debian policy to name packages as "tor-*" [0] > > Of course there isn't. But if the package is incredibly specialized, it > might make sense to do that anyhow. Debian is not bound to reuse the > upstream name, although in many cases it makes sense (first and foremost > when scripts are concerned, but there are plenty of other reasons). While that would be a good idea, I believe that software using "tor" in their name needs to be acknowledged by the Torproject, see https://www.torproject.org/docs/trademark-faq.html We've however seen from previous experience that software not made by the the Torproject is kindly requested to be named differently, hence for example Tails' previously called tor-monitor software has been renamed to "onioncircuits". >> - nyx, is a tor monitor, and is not called "tor-*" > > Fair. Although, to note, it used to be called tor-arm according to the > package's description. And it feels like the possible target audience of > sbws is even less than the one of nyx. That said: Maybe include the > target audience (i.e. who is going to have an interest in running this > package) somewhere in your description. If this is of interest to all > relay operators rather than just the authorities, that's probably relevant. I don't know what this name change was motivated by. >> - there're several packages called "onion*", which is not "tor-*" > > Well, tor-* was a proposal to disambiguate a short name. I don't > particularly care what the prefix would be. See above. If anything, the package could use the `onion` prefix in Debian, but as this is not policy and IMO even adds more complexity, it could also simply use the upstream name as initially suggested by Ju. Cheers! Ulrike
Bug#895657: is qml-box2d library missing?
Hello, I can confirm that bug still exists in latest package version 0.91. When you download and unpack GCompris from official website (http:// gcompris.net/download/qt/linux/gcompris-qt-0.91-Linux64.sh ) one of the folders contains qml-box2d library which is not installed by Gcompris-qt dependencies. Could it be the missing bit? -- Kind regards, Rokas
Bug#873331: RM: llvm-toolchain-3.8 (and hence kfreebsd mesa)
Control: unblock -1 by 873408 Control: block 893401 by 873408 (julia has now moved to LLVM 4.0) beignet, and presumably mesa, use LLVM 3.8 on kfreebsd-* because there isn't anything newer available there. LLVM 3.9 to 6.0~svn315736 were attempted and FTBFS on kfreebsd-*; these bugs do not appear to have been formally reported. Later versions (including final 6.0) were never attempted due to the below cmake issue. All LLVM versions (and everything using cmake and debhelper) are now BD-Uninstallable on kfreebsd-* because debhelper Conflicts: cmake < 3.9 and newer cmake FTBFS (with a message that does _not_ look like #815231). LLVM <= 5.0 now also FTBFS on amd64 (and probably all architectures) due to GCC 8 (#897805 etc).
Bug#826558: ubuntu-archive-keyring: Adds ubuntu-archive-keyring.gpg to /etc/apt/trusted.gpg.d/ without my consent
Hi, Hideki Yamane: > Well, now I consider that not install ubuntu-archive-keyring as system > trusts key by default, but user can choose with debconf. Sounds good to me. > - Just mixing Debian & Ubuntu packages may harm for the system > - limited usage: >+ debootstrap doesn't need to add it to system keyring >+ chdist needs it as trusted keyring, but perhaps not used so much ACK. > Then I need its description for debconf and README.Debian, could you > consider to give it me, please? - debconf (boolean) value description: "Add the Ubuntu archive keys to the list of trusted keys used by apt to authenticate packages?" (default: no, IMO). - README.Debian: To add the Ubuntu archive keys to the list of trusted keys used by apt to authenticate packages, reconfigure the ubuntu-archive-keyring package: # dpkg-reconfigure --priority=low ubuntu-archive-keyring … and answer "Yes" to the "Add the Ubuntu archive keys to the list of trusted keys used by apt to authenticate packages?" question. Cheers, -- intrigeri
Bug#904247: pytest-sugar: FTBFS and test failure with pytest 3.6
Source: pytest-sugar Version: 0.9.1-2 Severity: serious Tags: ftbfs buster sid X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: needs-update Hi Maintainer Since the upload of pytest 3.6.2-2 to unstable, pytest-sugar's autopkgtests have been failing [1], with the following error: ― [doctest] test_doctest_lineno.foobar ― 002 003 >>> foobar() UNEXPECTED EXCEPTION: NotImplementedError() On 27 June 2018 at 23:05, Paul Gevers wrote: > With a recent upload of pytest the autopkgtest of diffoscope, doit, > pytest-httpbin and pytest-sugar started to fail in testing. > See: https://qa.debian.org/excuses.php?package=pytest and links therein. > > With a very quick look, it seems that pytest-httpbin and pytest-sugar > just need to adapt to the new behavior (deprecation of functionality). I > can't really judge diffoscope and doit without diving deeper (I am going > to bed now). > > Currently this regression is delaying the migration of pytest to testing > by 13 days. Could you please discuss what the best way forward is? > > More information about this email and the reason of it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul As can be seen on the reproducible builders [2], pytest-sugar now FTBFS with the same error in buster and unstable. Regards Graham [1] https://ci.debian.net/packages/p/pytest-sugar/unstable/amd64/ [2] https://tests.reproducible-builds.org/debian/history/amd64/pytest-sugar.html
Bug#904246: developers-reference: section 6.4 should recommend command -v, not which
Package: developers-reference Version: 3.4.20 Severity: minor Hello, Section 6.4 should perhaps recommend `command -v` not `which`, because Debian Policy 4.1.5.0 allows maintainer scripts to assume SUSv4, which requires support for `command -v`. Additionally see the discussion in #747320, where Jakub Wilk does point out that maintainer scripts may assume /usr is mounted, so I'm not sure about this. -- Sean Whitton signature.asc Description: PGP signature
Bug#904245: python-graphviz: autopkgtest regression: missing test depends python3-all
Source: python-graphviz Version: 0.5.2-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: needs-update Dear maintainers, Currently the python3.7 transition¹ is going on, which means that python3.7 is added to the supported python3 versions. However, since python3-defaults added python3.7 support, your autopkgtest has been failing. I copied the error below. Could you please investigate? I think you want to test depend on python3-all, or better yet, your test string seems to be inspired or copied from autodep8, maybe it would smarter to let autodep8 handle it. Paul ¹ https://release.debian.org/transitions/html/python3.7.html https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-graphviz/649006/log.gz autopkgtest [04:34:42]: test command1: [--- Testing with python3.7: bash: python3.7: command not found autopkgtest [04:34:43]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#891488: postgresql: Installing postgresql fails due to "error creating symbolic link '/usr/share/man/man1/psql.1.gz.dpkg-tmp': No such file or directory"
> No longer marked as found in versions postgresql-common/181+deb9u1. > Request was from Christoph Berg to > cont...@bugs.debian.org. (Mon, 26 Feb 2018 09:12:06 GMT) (full text, > mbox, link). The issue still occurs with postgresql-common/181+deb9u2. It seems to occur in the Docker image `debian:stretch-slim` only and not in `debian:stretch`. signature.asc Description: OpenPGP digital signature
Bug#897509: git-repair: diff for NMU version 1.20151215-1.2
Control: tags 897509 + patch
Control: tags 897509 + pending
Dear maintainer,
I've prepared an NMU for git-repair (versioned as 1.20151215-1.2) and
uploaded it to sid.
Regards.
--
Sean Whitton
diff -Nru git-repair-1.20151215/CHANGELOG git-repair-1.20151215/CHANGELOG
--- git-repair-1.20151215/CHANGELOG 2017-07-26 08:27:22.0 +0800
+++ git-repair-1.20151215/CHANGELOG 2018-07-22 14:33:24.0 +0800
@@ -1,3 +1,11 @@
+git-repair (1.20151215-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Patch duplicate Arbitrary instance of EpochTime out of
+Utility/QuickCheck.hs (Closes: #897509).
+
+ -- Sean Whitton Sun, 22 Jul 2018 14:33:24 +0800
+
git-repair (1.20151215-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru git-repair-1.20151215/debian/changelog git-repair-1.20151215/debian/changelog
--- git-repair-1.20151215/debian/changelog 2017-07-26 08:27:22.0 +0800
+++ git-repair-1.20151215/debian/changelog 2018-07-22 14:33:24.0 +0800
@@ -1,3 +1,11 @@
+git-repair (1.20151215-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Patch duplicate Arbitrary instance of EpochTime out of
+Utility/QuickCheck.hs (Closes: #897509).
+
+ -- Sean Whitton Sun, 22 Jul 2018 14:33:24 +0800
+
git-repair (1.20151215-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru git-repair-1.20151215/debian/patches/patch-duplicate-arbitrary-instance-out-o.patch git-repair-1.20151215/debian/patches/patch-duplicate-arbitrary-instance-out-o.patch
--- git-repair-1.20151215/debian/patches/patch-duplicate-arbitrary-instance-out-o.patch 1970-01-01 08:00:00.0 +0800
+++ git-repair-1.20151215/debian/patches/patch-duplicate-arbitrary-instance-out-o.patch 2018-07-22 14:33:24.0 +0800
@@ -0,0 +1,20 @@
+From: Sean Whitton
+Date: Sun, 22 Jul 2018 14:30:36 +0800
+X-Dgit-Generated: 1.20151215-1.2 5e47ead106bebfd076d950934fbe11d9f1ef552c
+Subject: patch duplicate Arbitrary instance out of Utility/QuickCheck.hs
+
+
+---
+
+--- git-repair-1.20151215.orig/Utility/QuickCheck.hs
git-repair-1.20151215/Utility/QuickCheck.hs
+@@ -33,9 +33,6 @@ instance (Arbitrary v, Eq v, Ord v) => A
+ instance Arbitrary POSIXTime where
+ arbitrary = fromInteger <$> nonNegative arbitrarySizedIntegral
+
+-instance Arbitrary EpochTime where
+- arbitrary = fromInteger <$> nonNegative arbitrarySizedIntegral
+-
+ {- Pids are never negative, or 0. -}
+ instance Arbitrary ProcessID where
+ arbitrary = arbitrarySizedBoundedIntegral `suchThat` (> 0)
diff -Nru git-repair-1.20151215/debian/patches/series git-repair-1.20151215/debian/patches/series
--- git-repair-1.20151215/debian/patches/series 2017-07-26 08:27:22.0 +0800
+++ git-repair-1.20151215/debian/patches/series 2018-07-22 14:33:24.0 +0800
@@ -1,3 +1,4 @@
fix-build-with-quickcheck-2.8.2.patch
split-out-module-to-work-around-badly-na.patch
patch-common.hs-to-avoid-duplicate-impor.patch
+patch-duplicate-arbitrary-instance-out-o.patch
signature.asc
Description: PGP signature
Bug#897856: https://salsa.debian.org/electronics-team/sdcc.git
Am 21. Juli 2018 19:44:33 MESZ schrieb Geert Stappers : > >There is now an empty git repository >at https://salsa.debian.org/electronics-team/sdcc.git >which is intended for Debian packaging of sdcc > > >Convenience links for the both bugreports in the To: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895345 > Title: sdcc recent git repository > >and > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897856 > Title: sdcc: ftbfs with GCC-8 > > >Explanation of the people in the Cc: > > - Gudjon, maintainer of sdcc > - Bdale, uploader of sdcc > - Tobias, wrote a patch that fixed a recent sdcc bug >( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894619#12 ) > - Adrian Bunk, did the upload of -2.1 > > >My hope is that they have content for sdcc packaging git repository. > > >Cheers >Geert Stappers >Who loves to see that sigrok stays in testing. sigrok depends on sdcc Hi Geert, just a quick follow-up from my side: I only ever did the quick fix with the patch, I'm not involved in the package maintaining. Therefore, I don't have any content for the git repository, unfortunately. If all else fails, you might need to resort to import the uploaded versions into the repository, e.g. with gbp import-dscs. Regards, Tobias
Bug#891488: postgresql: Installing postgresql fails due to "error creating symbolic link '/usr/share/man/man1/psql.1.gz.dpkg-tmp': No such file or directory"
On Mon, 26 Feb 2018 02:31:21 + Karl-Philipp Richter wrote: > Package: postgresql > Version: 9.6+181+deb9u1 > Severity: normal > > Dear Maintainer, > > Installing `postgresql` in the (quite empty) Docker image > `debian:stretch-slim` fails due to the `dpkg` error > > ``` > Setting up postgresql-client-9.6 (9.6.6-0+deb9u1) ... > update-alternatives: using /usr/share/postgresql/9.6/man/man1/psql.1.gz to > provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode > update-alternatives: error: error creating symbolic link > '/usr/share/man/man1/psql.1.gz.dpkg-tmp': No such file or directory > dpkg: error processing package postgresql-client-9.6 (--configure): > subprocess installed post-installation script returned error exit status 2 > ``` > > The failure is repeatable 100% of times. I attached the output of an example > run as `postgresql.log`. In case this is a user error (e.g. if it's > impossible to install postgresql in such a minimal environment) the feedback > should be improved. > > > -- System Information: > Debian Release: 9.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.13.0-21-generic (SMP w/8 CPU cores) > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C > (charmap=ANSI_X3.4-1968) > Shell: /bin/sh linked to /bin/dash > Init: unable to detect > > Versions of packages postgresql depends on: > iu postgresql-9.6 9.6.6-0+deb9u1 > > postgresql recommends no packages. > > Versions of packages postgresql suggests: > iu postgresql-doc 9.6+181+deb9u1 > > -- no debconf information I work around this issue with `mkdir -p /usr/share/man/man1/ /usr/share/man/man3/ /usr/share/man/man7/`. This issue seems to be hidden on system which have a basic set of manpages installed (and not having the directories which only occur in environments like minimal Docker images), however the situation should still be handled automatically. signature.asc Description: OpenPGP digital signature
Bug#904244: firewalld: New upstream 0.6.0 available, please consider packaging it.
Package: firewalld Version: 0.4.4.6-2 Severity: wishlist Dear Maintainers, experimenting with firewalld, I noticed that version 0.6.0 has been released by upstream lately (although the watch file reports -alpha as latest release). It would be great if the package could be updated for testing and finally go into buster. Thanks and best regards, Andi
