Bug#905401: permit access to apt repositories during builds

Hi, Ian Jackson wrote: > Apropos of discussion in #813471: > > Paul writes: >> In addition, d-i relies on access to the apt repo for the system. >> I can imagine other uses of that, so I added a carve-out for that. > > In general I think this should be done by saying that packages may > access

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

Hi, Simon McVittie wrote: > On Wed, 01 Aug 2018 at 19:23:09 -0700, Jonathan Nieder wrote: >> Simon McVittie wrote: >>> ( ) the full text of the license, *and* the license grant >>> (unless the license *is* the license grant, like BSD-style licenses) >>

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi, Markus Koschany wrote: > I personally dislike the trend in Debian to create more and more > complexity in our source packages. I find the Standards-Version field > unnecessary, VCS fields should not be part of a debian/control file, all > DFSG licenses approved by our ftp-team should be

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Sean Whitton wrote: > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: >> "as verbose as reasonably possible" seems incompatible with "maximally >> verbose >> output", at least in some cases (golang packages come to mind). >> >> Would it be possible to clarify this ? > > Yes. Let's

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Sean Whitton wrote: > On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote: >> Thanks for reporting. My understanding from >> https://bugs.debian.org/628515 is that the intention is >> >> - print out compiler driver command lines, so that compiler error

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Clément Hermann wrote: > 4.9 states: > The package build should be as verbose as reasonably possible. > This means that ``debian/rules`` should pass to the commands it > invokes options that cause them to produce maximally verbose > output. > > "as verbose as reasonably

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

Hi, Markus Koschany wrote: > FYI: Here is what one of the ftp-masters, Jörg Jaspert, wrote in > response to my proposal to reduce boilerplate in debian/copyright. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883950#80 > > I believe it shows the generally tendency that they are in favor

Bug#904248: Add netbase to build-essential

Hi, Sean Whitton wrote: > On Wed 25 Jul 2018 at 09:14PM -0700, Jonathan Nieder wrote: >> Looks okay to me. As an alternative, we could encourage packages to >> add an explicit Build-Depends on netbase if they need this >> functionality. >> >> I think in the lo

Bug#904248: Add netbase to build-essential

Hi, Sean Whitton wrote: > 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,

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

Sean Whitton wrote: > On Wed 25 Jul 2018 at 07:01PM -0700, Jonathan Nieder wrote: >> I share gregor's discomfort: I don't think we've thought this through. > > I too want Policy to be as correct as possible, but this bug has been > open for ten years and one thing upon which

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

Hi, Sean Whitton wrote: > On Mon 23 Jul 2018 at 01:40PM +0200, gregor herrmann wrote: >> Let me see if I got this right, and apply it to the typical pkg-perl >> package: >> >> CPAN distributions usually contain no NEWS file, and do contain a >> Changes/ChangeLog/... file which is "an upstream

Bug#904608: Support specifying upstream VCS location in debian/control

Hi, Sean Whitton wrote: > On Wed 25 Jul 2018 at 05:14PM +0100, Iain Lane wrote: >> Some tools, like git-buildpackage, can support merging an upstream's >> version history into Debian packaging repositories. This enables more >> rich usage of (D)VCS when packaging - for example `git blame' works

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

Sean Whitton wrote: > On Sun 22 Jul 2018 at 11:12PM -0700, Jonathan Nieder wrote: > > > That would mean Recommends is effectively Depends. Is it really what you > > intend? > > I don't follow. > > My patch says that /some/ functionality might not work without the

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

Sean Whitton wrote: Seeking seconds: > > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 1eaa422..03f5918 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -228,6 +228,10 @@ The meaning of the five dependency fields is as > follows:

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

Hi, Chris Lamb wrote: > Sean Whitton wrote: >> Either Policy should mandate this field, or it should not be a Lintian >> error when it is not present. > > Any update on this? It is somewhat tempting to re-assign this to Policy > alone until there is a resolution there. What say you? :)

Bug#515856: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Mon, Jul 02 2018, Jonathan Nieder wrote: >> I'm a bit confused: wasn't it already specified pretty precisely? > > Please take a look through the bug's discussion. It's explained why the > wording was not thought to be good enough. Thanks. This lo

Bug#515856: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Wed, Apr 11 2018, Russ Allbery wrote: >> I'm pretty reluctant to specify this sort of optional target that >> works differently in every package that uses it back in Policy because >> it's really not standardized, nor do I think it's possible to >> standardize. If

Bug#901900: dgit in stretch-backports

Hi Sean, Sean Whitton wrote: > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Is there somewhere I can read more about that policy? Not that I'm >> complaining :) > > https://backports.debian.org/Contribute/ > > "... you have to ... update your backport whe

Bug#901897: closed by Jonathan Nieder (Bug#901897: fixed in git 1:2.18.0~rc2-2)

Hi, Ian Jackson wrote: > Paul Gevers writes ("Re: Bug#901897 closed by Jonathan Nieder > (Bug#901897: fixed in git 1:2.18.0~rc2-2)"): >> And I just helped the test for git a bit as due to bug 896023 in >> autopkgtest it didn't use the right autopkgtest from dgit. T

Bug#901900: dgit in stretch-backports

s the situation we're in. > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Is there somewhere I can read more about that policy? Not that I'm >> complaining :) > > https://backports.debian.org/Contribute/ > > "... you have to ... update your backport when a new versi

Bug#901900: dgit in stretch-backports

Hi Sean, Sean Whitton wrote: > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Do you plan to update dgit in backports once it hits testing? > > Yes. Excellent, thank you. [...] >> Is there anything I can do to help? For example, should I prepare an >> upload fo

Bug#901900: dgit in stretch-backports

Ian Jackson wrote: > Jonathan Nieder writes ("Bug#901900: dgit in stretch-backports"): >> Once git 2.18.0 is in testing, I want to update the git package in >> stable-backports. This would require updating dgit as well to a >> version that supports the working-tr

Bug#901900: dgit in stretch-backports

Hi Sean et al, Once git 2.18.0 is in testing, I want to update the git package in stable-backports. This would require updating dgit as well to a version supports the working-tree-encoding attribute (https://bugs.debian.org/901900). Do you plan to update dgit in backports once it hits testing?

Bug#902060: pcre2: please use versioned symbols

Package: libpcre2-8-0 Version: 10.31-1 Severity: wishlist Tags: upstream Using a symbol version script brings a few advantages to a library: 1. simplifies library transitions, since multiple versions of the library with different ABI can share a process image without producing disaster.

Bug#901900: git introduces new hazardous working-tree-encoding attribute

Ian Jackson wrote: > 5.1 is ready and has passed all its tests. It works fine with the git > in sid. I am not able to upload it right now, but this will happen > later today. Thanks. $ git ls-remote git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git fatal: Could not read from remote

Bug#901897: git introduces new hazardous working-tree-encoding attribute

severity 851679 wishlist tags 851679 + upstream clone 901897 -1 retitle -1 dgit fails autopkgtest: true/false are no valid working-tree-encodings reassign -1 dgit 5.0 retitle 901897 git needs Breaks against dgit versions without working-tree-encoding support block 901897 by -1 quit Hi Ian, Ian

Bug#901805: want option to git-rebase

severity 901805 wishlist tags 901805 + upstream retitle 901805 git rebase: allow calling scripts to customize reflog action forwarded 901805 https://public-inbox.org/git/20180619010655.ga173...@aiede.svl.corp.google.com/ quit Hi, Ian Jackson wrote: > git-rebase leaves entries like this in the

Bug#901185: Checkbashisms

Hi, 積丹尼 wrote: Be sure the package passes Checkbashisms! > Which package? Is there a particular bashism you noticed? Please keep in mind that these reports appear as emails in a crowded inbox, where a little context in the subject line can go a long way. Thanks, Jonathan >

Bug#900393: runit 2.1.2-14 breaks git-daemon-run

Package: runit Version: 2.1.2-14 Severity: serious Justification: breaks upgrades The changelog to runit 2.1.2-14 explains: * Do not install `update-service' script. but it doesn't give any more context than that. This breaks the git-daemon-run package, as noticed e.g. by piuparts:

Bug#900377: git: Debian git package can now include git-p4 Perforce proxy

forcemerge 715534 900377 quit Hi, Luke Diamand wrote: > Originally the Debian git package included this tool, but it was removed > in 2014 because - at the time - the Perforce command-line tool was non-free: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10 To be clear, what the

Bug#898226: git: please transition from asciidoc to asciidoctor

tags 898226 + upstream # asciidoc is not gone yet :) severity 898226 wishlist quit Hi, Nicholas D Steeves wrote: > https://lists.debian.org/debian-backports/2018/05/msg00063.html > > src:git/1:2.17.0-1 Build-Depends on asciidoc (>= 8.6.10); however, > in asciidoc/NEWS.Debian the following is

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

reassign 895446 libfontconfig1 2.13.0-2 severity 895470 serious retitle 895470 fontconfig-2.13.0 globally sets the locale from the environment forcemerge 895470 895446 affects 895470 + gitk tags 895470 + patch fixed-upstream quit Jonathan Nieder wrote: > Michael Biebl wrote: >> gitk

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

tags 895446 + moreinfo quit Hi Michael, Michael Biebl wrote: > gitk no longer successfully starts here. When I run it from a terminal, > I get > > $ gitk > Error in startup script: bad screen distance "4.5" > while executing > "$canv conf -scrollregion [list 0 0 $canvxmax $ymax]" >

Bug#878800: jgit-cli: IllegalStateException: Cannot set value to a final field 'org.eclipse.jgit.pgm.Daemon.enable'

# renders package unusable severity 878800 grave quit Jonathan Nieder wrote: > git clone https://kernel.googlesource.com/pub/scm/git/git > cd git > make -j8 > cd t > ./t5512-ls-remote.sh -v -i It turns out that this affects the package more deeply than that. For example: $

Bug#893734: git-el: smooth automatic migration to elpa-magit (Re: Maintainer scripts for el file removal)

Source: git Version: 1:2.17~rc0+next.20180315-1 Severity: wishlist X-Debbugs-Cc: Nicholas D Steeves , debian-emac...@lists.debian.org Nicholas D Steeves wrote[*]: > speaking for myself--if I > wasn't already a magit user I would

Bug#892488: pcre2: FTBFS on mips* - test failures

severity 892488 serious tags 892488 + upstream pending quit Matthew Vernon wrote: > Hi, > >> This is blocking git updates from migrating to testing >> (https://qa.debian.org/excuses.php?package=git), so my preference >> would be removing "mips mipsel mips64el" from the list of JIT arches >> for

Bug#892488: pcre2: FTBFS on mips* - test failures

Hi, Matthew Vernon wrote: > On 09/03/18 15:20, James Cowgill wrote: >> Source: pcre2 >> Version: 10.31-1 >> Severity: serious [...] >> pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me >> like the JIT is bust. >> >> I forwarded the log upstream to the above address. I'll try

Bug#892142: debian-policy: update example to use default-mta instead of exim

onded: Holger Levsen <hol...@layer-acht.org> @@ -29,6 +30,10 @@ debian-policy (4.1.4.0) UNRELEASED; urgency=medium * Fix indentation of description of the clean target (Closes: #889960). Thanks Ferenc Wágner for the report. + [ Jonathan Nieder ] + * Use default-mta instead of exim in d

Bug#890601: firmware-free: Source Package Doesn't Contain Source

retitle 890601 firmware-linux-free uses prebuilt blobs instead of building from source severity 890601 wishlist quit Jason Self wrote: > Jonathan Nieder <jrnie...@gmail.com> wrote .. >> Can you be more specific? Which file have you found in the source >> packa

Bug#890601: firmware-free: Source Package Doesn't Contain Source

Hi Jason, Jason Self wrote: > It appears that the source package for firmware-linux-free contains the > firmware binaries downloaded from linux-firmware.git. Shouldn't a source > package contain, you know, the source code? Especially as some of the > firmwares are GPL-licensed, and Debian is

Bug#889680: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

+cc: upstream Hi, Salvatore Bonaccorso wrote[1]: > the following vulnerability was published for git. > > CVE-2018-121[0]: > |client prints server sent ANSI escape codes to the terminal, allowing > |for unverified messages to potentially execute arbitrary commands > > Creating this bug to

Bug#873424: git: handling HTTPS proxy w/ password inappropriately

Hi, Yangfl wrote[1]: > not affected any more Can you say a little more about this? Do you mean that newer versions of Git are working better for you or that your proxy setup changed? This looks similar to

Bug#886061: git-buildpackage: import-orig doesn't sign anymore commits on non-master branches

Hi, Guido Günther wrote: > The option is called commit.gpgsign not commit.pgpsign (according to > "man git-config")… [...] > …and it doesn't affect git-commit-tree, that's why "gbp import-orig" is > unaffected since it doesn't use "git commit" but git-commit-tree. So > from gbp's point of view

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Jonathan Nieder wrote: > Markus Koschany wrote: >> freeorion: [1] >> >> Rather sophisticated game GPL-2 licensed but with various contributions >> / incorporations under different licenses. So I can't just write Files: >> * -> GPL-2. I have to list a

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > freeorion: [1] > > Rather sophisticated game GPL-2 licensed but with various contributions > / incorporations under different licenses. So I can't just write Files: > * -> GPL-2. I have to list all licenses with separate paragraphs and > there is no way to change that

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Hi, Markus Koschany wrote: > I still have to quote license texts verbatim. The only > "advantage" of the old format is that I can format d/copyright more > freely but the same information must be present anyway. It is simply not > feasible to educate all upstreams in existence to

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > Am 28.12.2017 um 11:21 schrieb Bill Allombert: >> On Wed, Dec 27, 2017 at 01:56:44PM -0800, Russ Allbery wrote: >>> Jonathan Nieder <jrnie...@gmail.com> writes: >>>> Seconded. >>> >>> license-count says this makes sens

Bug#885166: instability with 4.14 regarding KVM virtualization

Marc Haber wrote: > On Mon, Dec 25, 2017 at 10:02:48PM +, Ben Hutchings wrote: >> Given that commit fb1522e099f0 was merged after -rc7 I assume it's an >> important fix, though the commit message doesn't spell that out. So I >> think that whenever bisect asks you to test a version that

Bug#885219: /lib64 provision added in 9.1.1 prohibits multilib libc

Russ Allbery wrote: > Allow libc to install files in /lib64 > > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 7d9e20a..d7c4956 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -35,7 +35,8 @@ Debian Policy. The following exceptions to the FHS apply:

Bug#688251: Built-Using description too aggressive

Hi, Sean Whitton wrote: > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst @@ -598,17 +598,26 @@ earlier for > binary packages) in order to invoke the targets in > Additional source packages used to build the binary - ``Built-Using`` >

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

Hi Markus, Markus Koschany wrote: > Am 16.12.2017 um 15:55 schrieb Sean Whitton: >> On Wed, Dec 13 2017, Markus Koschany wrote: >>> If the Policy editors cannot make a decision with regards to >>> debian/copyright then we should ask the DPL to seek legal advice and >>> when necessary start a GR

Bug#884038: [git] 2.15.x fails to fetch remote repository

# regression but not reproducible severity 884038 important tags 884038 + upstream unreproducible quit Hi, mirq-debo...@rere.qmqm.pl wrote: > git 2.15.x from testing can't properly fetch from remote repository: > > $ git fetch --all > Fetching origin > remote: Counting objects: 752, done. >

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Hi again, Markus Koschany wrote: > Let me try to explain it this way: Take src:ufoai-data or src:netbeans > for example. Both packages ship approximately a dozen different > licenses. I can't simply copy the upstream license because I have > to format it to make it copyright format 1.0

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Hi, Markus Koschany wrote: > I would like to argue that disk space is no longer an issue in 2017 and > people with special needs (embedded systems) will most likely remove > /usr/share/common-licenses anyway. I agree: space on installation media and network transfer time are more important than

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

Hi, Markus Koschany wrote: > Am 13.12.2017 um 19:10 schrieb Jonathan Nieder: >> Markus Koschany wrote: >>> License: AGPL-3.0 >>> Source: https://www.gnu.org/licenses/agpl-3.0.de.html >>> Example packages: >>> https://wiki.debian.org/DFSGLicenses#G

Bug#884227: debian-policy: please add zlib to common licenses

Markus Koschany wrote: > License: zlib > Source: https://opensource.org/licenses/Zlib > Example packages: > https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29 Hm. The license says 3. This notice may not be removed or altered from any source distribution. And part of

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: OFL-1.1 > Source: https://opensource.org/licenses/OFL-1.1 > Example

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: EPL-1.0 > Source: https://www.eclipse.org/legal/epl-v10.html > Example

Bug#884224: ebian-policy: please add CC-BY-3.0 to common licenses

Hi, Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: CC-BY-3.0 > Source: https://creativecommons.org/licenses/by/3.0/ >

Bug#884225: debian-policy: please add CC-BY-4.0 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: CC-BY-4.0 > Source: https://creativecommons.org/licenses/by/4.0/ > Example

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

Hi, Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: AGPL-3.0 > Source: https://www.gnu.org/licenses/agpl-3.0.de.html >

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

Hi, Sean Whitton wrote: > On Thu, Nov 30 2017, Simon McVittie wrote: >> Other than that, seconded. I'm not sure whether this is necessarily >> how the autobuilders *should* work, but there's value in documenting >> how the autobuilders *do* work. > > Thank you for reviewing this bug. > > Since

Bug#459427: changelog vs. NEWS handling

Josh Triplett wrote: > On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert wrote: >> The fact that some upstream do not bother to ship useful changelog does >> not mean that all changelog are useless, and by removing them we >> discourage upstream of producing useful changelog.

Bug#883179: dash: compiles in signals from build architecture when cross-compiled

Control: tags 883179 + upstream Hi, James Cowgill wrote: > When cross-compiled, dash compiles in a list of signal names used for > various purposes (eg kill -NAME). Unfortunately the signal names are > generated by using the *build* compiler instead of the *host* compiler > so the signals are

Bug#459427: changelog vs. NEWS handling

Hi, gregor herrmann wrote: > From the Perl world, looking at roughly ~3400 packages I have locally > cloned: > > 28 have a NEWS file (most of them with a Gnome/GTK background), 1 > News, 1 news. > > 3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other > variations like

Bug#683495: Mandating use of /usr/bin/perl in Policy

Bill Allombert wrote: > On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote: >> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote: >>> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]: I am seeking seconds for the following patch to close this bug, which I

Bug#882389: Error in /etc/Muttrc.d/notmuch.rc

forcemerge 882320 882389 quit Hi, 積丹尼 Dan Jacobson wrote: > Package: mutt > Version: 1.9.1-1 > > $ mutt > Error in /etc/Muttrc.d/notmuch.rc, line 6: change-vfolder: no such function > in map > Error in /etc/Muttrc.d/notmuch.rc, line 9: entire-thread: no such function in > map > Error in

Bug#882351: 'no such function in map' from /etc/Muttrc.d/notmuch.rc

Package: mutt Version: 1.9.1-1 Today I updated mutt to 1.9.1-1 (thanks!). I expect this to be more familiar to me since I used the mutt package instead of mutt-patched in the past. Now when I start mutt I am getting the following messages: $ mutt Press any key to continue...ch.rc, line 6:

Bug#880992: debian-policy should not recommend running editor using absolute path

Hi, Sean Whitton wrote: > On Mon, Nov 06 2017, Jonathan Nieder wrote: >> Thus, every program that launches an editor or pager must use >> the EDITOR or PAGER environment variable to determine the editor >> or pager the user wishes to use. If these

Bug#880992: debian-policy should not recommend running editor using absolute path

Package: debian-policy Version: 4.1.0.0 Policy 11.4 sayeth: 11.4. Editors and pagers Some programs have the ability to launch an editor or pager program to edit or display a text document. Since there are lots of different editors and pagers available in the

Bug#878905: debian-policy: Document installability recommendations for dependency alternatives

Hi, Julian Andres Klode wrote: > APT's solver is greedy and sometimes has a hard time to recover from paths > that > don't work out in the end. We see this with opencv failing to build on > !linux-any > because: > > (1) dconf-service depends default-dbus-session-bus | dbus-session-bus > (2)

Bug#878800: jgit-cli: IllegalStateException: Cannot set value to a final field 'org.eclipse.jgit.pgm.Daemon.enable'

Package: jgit-cli Version: 3.7.1-4 Tags: upstream patch fixed-upstream Severity: important Justification: renders feature unusable Steps to reproduce: git clone https://kernel.googlesource.com/pub/scm/git/git cd git make -j8 cd t ./t5512-ls-remote.sh -v -i Expected result: test passes

Bug#878189: please drop transitional package git-core

tags 878189 + pending quit Hi, Holger Levsen wrote: > Please drop obsolete transitional package git-core for Buster, as it > has been released with Wheezy already. Good call. Done for the next upload. Thanks, Jonathan

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

Toni Mueller wrote: > Hi Jonathan, >> Have you read https://bugs.debian.org/613892#10? Would you be >> interested in working on a patch for upstream Git to do that? We can >> make the error message printed when manpages are missing a value set >> at compile time (see the Makefile for existing

Bug#877688: libdpkg-perl: dpkg-source requires git to use 3.0 (git) format

Hi, Nicholas Brown wrote: > /usr/share/perl5/Dpkg/Source/Package/V3/Git.pm regularly calls out to git > using > "system('git'," yet libdpkg-perl does not Require or even Recommend that > Git is installed. > > This makes using dpkg-source with the 3.0 (git) format fail, for example in a >

Bug#877697: ebian-policy: discourage using all 4 digits numbers in Standards-Version

Hi, Mattia Rizzolo wrote: > Policy § 5.6.11, after describing the meaning of the digits in the > policy version, reads: > > | Thus only the first three components of the policy version are > | significant in the Standards-Version control field, and so either > | these three components or all

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

Hi, Toni Mueller wrote: > I can only agree with Nelson. These days, a lot of git installations are > non-interactive to begin with, as part of some service or so. Nobody is > ever going to read the manual pages in such use cases. It's just a waste > - and if the packages are being generated

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> C. You have transport-level integrity protection, e.g. by using a >> protocol like https:// or ssh:// with proper PKI. > > I think it's worth being honest with ourselves here that the prop

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> Russ Allbery wrote: >>> (That said, my understanding is that you don't get any meaningful >>> integrity protection for Git from using https over http.) >> >> As discussed elsewhe

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Jonathan Nieder wrote: > Russ Allbery wrote: >>> On Wed, Aug 23 2017, Russ Allbery wrote: >>>> --- a/policy/ch-controlfields.rst >>>> +++ b/policy/ch-controlfields.rst >>>> @@ -962,6 +962,10 @@ repository where the Debian source package is >>

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Sean Whitton writes: >> On Wed, Aug 23 2017, Russ Allbery wrote: >>> --- a/policy/ch-controlfields.rst >>> +++ b/policy/ch-controlfields.rst >>> @@ -962,6 +962,10 @@ repository where the Debian source package is >>> developed. >>> >>> More

Bug#873424: git handling HTTPS proxy w/ password inappropriately

(cc-ing the git mailing list and some proxy specialists there) yang wrote[1]: > Version: 1:2.14.1-2 [...] > When I tried to > > $ HTTPS_PROXY=http://username:password@proxy:80 git clone > https://github.com/linuxdeepin/deepin-deb-installer.git > > I got > > 正克隆到 'deepin-deb-installer'... > fatal:

Bug#682347: mark 'editor' virtual package name as obsolete

Hi, Russ Allbery wrote: > +++ b/policy/ch-customized-programs.rst > @@ -93,19 +93,21 @@ page. [...] > -It is not required for a package to depend on ``editor`` and ``pager``, > -nor is it required for a package to provide such virtual > -packages. [#]_ > +Packages may assume that

Bug#872956: [debian-policy] warn about danger of pipe in shell snippet of makefile

Hi, Bastien ROUCARIÈS wrote: > set -e is not suffisant to detect error in pipe context > > cat nonexistant | sed s/some//g will hapilly return 0 and do not fail > > exec 3>&1; s=$(exec 4>&1 >&3; { cat nonexistant ; echo $? >&4; } | sed > s/some//g ) && exit $s > > this could be simplified by

Bug#872895: debian-policy: Split html for policy lost

Hi, Sean Whitton wrote: > On Tue, Aug 22 2017, Guillem Jover wrote: >> This version has lost the distinction between a single policy html and >> the one with different files per chapter. This will break links. > > This was intentional. The single page output is much more useful to > casual

Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7

Sean Whitton wrote: > On Wed, Aug 01, 2012 at 08:07:01AM +0900, Charles Plessy wrote: >> Otherwise, how about something along these lines: [...] > > Commenting on Charles' patch, I think that it would be clearer to have > the 'should' and 'must' requirements in separate sentences. > > Thus I am

Bug#872808: [debian-policy] nocheck DEB_BUILD_OPTIONS DEB_BUILD_PROFILES

Hi Bastien, Bastien ROUCARIÈS wrote: > I think the following patch is needed even if profiles are not fully > specified. > Maybe an example about nodoc and help2man will also help. The nocheck should > check both BUILD_OPTIONS and BUILD_PROFILES. It will help when implementing as > policy

Bug#872829: git: package "smart http" server configuration

Source: git Version: 1:2.14.1-2 Severity: wishlist The git-http-backend(1) manpage explains how to set up "smart HTTP" server in Apache or Lighttpd but Git's maintainer scripts are not set up for that. This bug is a request to create a package similar to the gitweb package that sets up a smart

Bug#871950: git: Please keep packaging git archimport

; For tla, my hope is that the tla deb from debian stretch or ubuntu > xenial, zesty or artful can remain installable for a long time in > future distros, since its dependencies seem to be rather minimal. [...] > Jonathan Nieder wrote: >> If you would use it to recover tla data from backups,

Bug#872277: patched version needed to avoid fatal: Out of memory, getdelim failed crash

retitle 872277 git: spurious "fatal: Out of memory, getdelim failed" forwarded 872277 https://public-inbox.org/git/20170809173928.h2ylvg5tp2p5i...@hopa.kiewit.dartmouth.edu/#r # bug introduced in v2.5.0-rc0~24^2~4 (strbuf_getwholeline: use getdelim # if it is available, 2015-04-16) found 872277

Bug#871950: git: Please keep packaging git archimport

Hi Sergio, Sergio wrote: > please reconsider the decision in #866059 to stop packaging git-archimport. > > It makes it unnecessary cumbersome to recover tla data from backups > and deprives git from one of the components that its upstream > maintainers consider worthwhile distributing. > > Even

Bug#871823: unblock: git/1:2.14.1-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package git. This update fixes CVE-2017-1000117 (arbitrary code execution issues via URLs, https://public-inbox.org/git/xmqqh8xf482j@gitster.mtv.corp.google.com/T/#u).

Bug#871570: git FTBFS on i386: t7006-pager.sh test failure

found 871570 git/1:2.13.2-3 tags 871570 + upstream quit Hi, Adrian Bunk wrote: > https://buildd.debian.org/status/fetch.php?pkg=git=i386=1%3A2.14.0-1=1502132890=0 > > ... > expecting success: > ( > sane_unset LESS LV && > PAGER="env >pager-env.out; wc" && >

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

Hi, Russ Allbery wrote: > How does this look to everyone? Seconded, with or without the tweaks dkg suggested in https://bugs.debian.org/732445#68 Thanks, Jonathan > --- a/policy.xml > +++ b/policy.xml > @@ -2556,11 +2556,28 @@ endif > > > This is an optional, recommended

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

Hi, Ansgar Burchardt wrote: > as a more radical change one could also ask the question where to > maintain the maintainer information. Currently we handle this in the > source package via the Maintainer and Uploaders field, and via team > memberships. > > This has several limitations: for

Bug#868738: git FTBFS on several architectures: not ok 134 - --dump-aliases must be used alone

Hi, Adrian Bunk wrote: > https://buildd.debian.org/status/package.php?p=git=sid > > expecting success: > test_must_fail git send-email --dump-aliases --to=jan...@example.com -1 > refs/heads/accounting > > --dump-aliases incompatible with other options > test_must_fail: command not found:

Bug#569945: hercules: high pitched whine on old laptop drives

Hi Philipp, Philipp Kern wrote: > This bug report from 2010 feels pretty much obsolete. Even assuming that > Hercules might cause a lot of random I/O the machine this was reported > for was likely too small to run Debian on s390 meaningfully in it. Plus > we have SSDs now. Agreed. If I end up

Bug#860774: openldap on armhf and armel needs bootstrapping

Ryan Tandy wrote: > Debian Bug Tracking System wrote: >> Bug #860774 [libldap-2.4-2] relax dependency on libldap-common >> Added indication that 860774 affects src:git, src:heimdal, and src:subversion > > It will be a few more hours before I can get to an upload, so if > this is blocking others'

Bug#866059: Please remove the git-arch package

severity 866059 important tags 866059 + pending quit Hi Adrian, Adrian Bunk wrote: > Severity: serious Why? > Already for a couple of years, the only realistic usecase > for the tla package in Debian was to allow git-arch to > migrate repositories to git. > > The final release of GNU Arch was

Bug#865863: dgit clone dies with "setup_git_env called without repository"

Version: 1:2.13.2 severity 865863 serious quit Hi Ian, Ian Jackson wrote: > Control: clone -1 -2 > Control: reassign -2 git > Control: severity -2 serious > Control: retitle -2 git config --local in non-repo now bombs out > Control: retitle -1 dgit 3.10 and earlier not compatible with git

<    1   2   3   4   5   6   7   8   9   10   >