Hi,
Corcodel Marian wrote:
> On struct boot_params not have only type 16 or 8 bits and become unusable on
> real mode.
Forgive my ignorance: I'm not understanding what you mean to say here.
Do you mean that Linux fails to build, or that it's failing to boot, or
that some operation you run after
Hi,
Russ Allbery wrote:
> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.
I agree about this (modulo the bits discussed elsewhere in
Hi Salvatore,
Salvatore Bonaccorso wrote:
> On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:
>> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
>> uploaded it to DELAYED/2. Please feel free to tell me if I
>> should delay it longer.
>
> I noted that the last
Hi Helmut,
Helmut Grohne wrote:
> At present, /bin/sh is always diverted. The diversion takes one of three
> forms:
>
> A. diverted by package dash, pointing to dash
> B. diverted by package bash (but performed by dash.postinst), pointing
> to bash
> C. local diversion
>
> The local
Hi Helmut,
Helmut Grohne wrote:
> I am re-closing the bug as the original submitter.
>
> On Fri, Jun 06, 2014 at 03:57:48PM -0700, Jonathan Nieder wrote:
>> Thanks for looking into it. Reopening, lowering severity. (I'm aware
>> of at least one user that was relying
Hi,
Jonas Smedegaard wrote:
> I agree that this is unlikely a bug in Ghostscript.
>
> The test PDF provided by Jonathan Nieder _is_ searchable with Evince
> 3.38.2-1.
>
> If same file was not searchable with Evince available in January 2011,
> then the issue might be the en
forcemerge 985416 985634
quit
Hi,
Thorsten Glaser wrote:
> I imagine *many* other third-party addons do the same.
Do you have examples? How do they approach being portable between
installations that set different gitexecdir directories at build time?
The directories being installed to are
Hi,
>> On Wed, 21 Apr 2021 10:12:03 + Damyan Ivanov wrote:
>>> Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.
Why sigh?
Directories such as /usr/lib/git-core and /usr/libexec/git-core are
internal to git. Other packages should not install to either
directory.
clone 985351 -1
retitle -1 changing gitexecdir breaks packages that install commands there
severity -1 serious
quit
Hi,
Sven Joachim wrote:
> It also breaks various add-on packages installing files into
> /usr/lib/git-core, as seen in the gitbrute autopkgtest[1]:
>
> ,
> | git: 'brute' is
Hi!
Guillem Jover wrote:
> The latest version in sid, breaks user code sourcing the git-sh-prompt
> shell library as it moved from /usr/lib/ to /usr/libexec, even though
> I see the comment there says to copy it, but that means no automatic
> upgrades. :/
>
> Could you perhaps add a backwards
Package: git
Version: 1:2.20.1-2+deb10u3
Severity: important
Justification: security issue
Tags: upstream security
Salvatore Bonaccorso wrote:
> On Wed, Mar 10, 2021 at 02:21:05AM +, Debian FTP Masters wrote:
>>* new upstream point release (see RelNotes/2.30.2.txt).
>
> This adresses
Antoine Beaupré wrote:
> On 2017-09-28 12:37:38, Jack Bates wrote:
>> I think the following will resolve this, by running the diff-highlight
>> Makefile when the package is built (following the pattern in
>> debian/rules for other contrib things):
>>
>>> diff --git a/debian/rules b/debian/rules
Hi,
Sean Whitton wrote:
> On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote:
> > On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:
>>> Could I ask you to explain your wanting to reduce the Essential set for
>>> the sake of small installation size in more detail, including some
>>>
tags 972871 + patch pending
quit
Jonathan Nieder wrote:
> Thanks for reporting.
>
> Strangely, debian-emacs-policy doesn't appear to be in the
> emacsen-common package any more. Fortunately, it's in
> https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.
>
>
Hi,
Zack Weinberg wrote:
> While updating my emacs configuration for 27.1 (now in unstable)
> I noticed that /etc/emacs/site-start.d/50git-core.el prints
>
> git removed but not purged, skipping setup
>
> and does not autoload either git.el or git-blame.el. This appears to
> be because
Javier Serrano Polo wrote:
> On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder
> wrote:
>> Even so, some *rough* consensus on the plan is very useful for
>> helping people evaluate that first step.
>
> Here is a rough plan:
>
>1. Policy: Packages should declar
Josh Triplett wrote:
> Jonathan Nieder wrote:
>> Josh Triplett wrote:
>>> This change does not propose eliminating the concept of Essential, nor
>>> does it propose that any specific package become non-Essential.
>>
>> I think I'd be more support
tags 969443 + upstream fixed-upstream
severity 969443 wishlist
retitle 969443 arm64: please backport stolen time support to buster kernel
quit
Hi,
Noah Meyerhans wrote:
> Subject: src:linux: none
It looks like you forgot to include a subject line?
> When used in virtual machine environments,
Source: kgb-bot
Version: 1.56-1
Tags: upstream
Severity: serious
Justification: tests fail with up-to-date Git
Affects: src:git
>From
>https://ci.debian.net/data/autopkgtest/testing/amd64/k/kgb-bot/6323993/log.gz:
| not ok 71
|
| # Failed test at t/52-client-git.t line 393.
| # got:
Hi,
Sam Hartman wrote:
> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision
reassign 961702 python3-git 3.1.1-1
affects 961702 git
quit
Hi,
Hans-Christoph Steiner wrote:
> I can't find any possible reference in fdroidserver, or in python3-git
> for that matter. My guess is that the issue is caused by python3-git
> failing to parse something that was added in the most
Herbert Xu wrote:
>> Tim Connors wrote:
>>> Because of bug #642922 (archived, but has some interesting discussion),
>>> this patch for this bug ended up being backed out.
[...]
> I gather that the ocamlbuild bug has been fixed so can this be
> reinstated please?
Curious: the ocamlbuild bug
severity 958929 important
tags 958929 + upstream
forwarded 958929 https://lore.kernel.org/git/20200428052510.ga201...@google.com/
quit
Stefan Tauner wrote:
> the vulnerability in CVE-2020-11008 is related to the handling
> of credential helpers in git. In Buster this has been fixed in
>
reassign 860015 tk 8.6.0+9
found 860015 tk/8.6.9+1
retitle 860015 tk: missing /usr/bin/wish symlink after upgrade
quit
Frederic wrote:
> After an upgrade from jessie -> stretch, I got this error message
>
> /usr/bin/gitk: 3: exec: wish: not found
Anders Boström wrote:
> I got this problem
Source: xonsh
Version: 0.9.15+dfsg-1
Severity: important
Justification: blocking git security fix from migrating to testing
The xonsh autopkgtest is failing on arm64:
https://ci.debian.net/data/autopkgtest/testing/arm64/x/xonsh/4989133/log.gz
xonsh test: test_indir
Hi,
Ian Jackson wrote[1]:
> [ some git-debrebase invocation etc. ]
> + git reflog
> + egrep 'debrebase new-upstream.*checkout'
> + rc=1
>
> I have looked at the log and repro'd the bug.
>
> git-debrebase (which lives in src:dgit but does not depend on dgit)
> must invoke git-rebase. It sets
Package: libctf-nobfd0
Version: 2.33.50.20200115-2
Severity: serious
Rationale: breaks upgrades
libctf-nobfd0 takes over the file libctf-nobfd.so.0.0.0 from libbinutils
but is missing a Breaks + Replaces declaring so:
Unpacking libctf-nobfd0:amd64 (2.33.50.20200115-2) ...
dpkg: error
Niels Thykier wrote:
> debhelper cannot see "inside" the upstream build system. If you modify
> a .c file, debhelper won't notice and will currently just skip the
> entire build. Alternatively, debhelper will have to invoke the build
> system and rely on it to not be flawed.
Yes, I think that
Niels Thykier wrote:
> In
> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
> we find the following example:
>
> """
> Examples of valid use of the gain root command:
>
> # sh-syntax (assumes set -e semantics for error handling)
> $DEB_GAIN_ROOT_CMD some-cmd
Hi!
Niels Thykier wrote:
> I would like to propose that we drop or replace the following
> recommendation in Policy:
>
> """
> When a package has a configuration and build routine which takes a
> long time, or when the makefiles are poorly designed, or when build
> needs to run clean first, it
retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
reassign 948041 libbpf-dev
merge 942903 948041
quit
Hi,
Julia Kartseva wrote:
> On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank wrote:
>> Why should we? If the upstream developers decide to maintain it
>>
Hi Paul,
Paul Anzel wrote:
> Would you please add the testing version of Git (2.24.1) as a
> backport to Debian Buster?
>
> I'd like to have the new Git command functionality from 2.23 (git
> switch/restore)
Happy to. Will do, some time this week or next week.
> and I've seen
John Paul Adrian Glaubitz wrote:
> On 1/7/20 1:03 AM, Jonathan Nieder wrote:
>> Using Recommends to mean "Depends, except on
>> buildds" would produce bad results for end users that use
>> --no-recommends.
>
> I disagree. Anyone who uses "--no-rec
reassign 948151 git 1:2.25.0~rc1-1
forcemerge 613892 948151
tags 613892 + upstream
quit
Hi,
Anatoly Pugachev wrote:
> clone of #613892 ?
Indeed it is! Thanks for digging that up.
See that bug for details on what is needed to get this done (an
upstream patch teaching "git help" to cope with
Hi Stephen,
Stephen Kitt wrote:
> We still need to figure out how to handle the triplet. There are multiple
> goals, from end users’ perspectives, some conflicting:
>
> * provide a Windows cross-compiler with a good selection of libraries, within
> Debian, so that it’s easy to build Windows
Josh Triplett wrote:
> I would love to see git-credential-libsecret packaged.
>
> This patch would ship git-credential-libsecret in the git package, which
> would add libsecret and its dependencies to the dependencies of git.
> Since many people use the git package on servers, that might not be
>
forcemerge 878599 946879
quit
Hi,
brian m. carlson wrote:
> It would be great if the libsecret credential helper could be built in
> its own package so that folks could easily use it.
Thanks! I agree.
Hi,
Josh Triplett wrote:
> I would love to see git-credential-libsecret packaged.
>
> This patch would ship git-credential-libsecret in the git package, which
> would add libsecret and its dependencies to the dependencies of git.
> Since many people use the git package on servers, that might not
Hi,
Sebastian Andrzej Siewior wrote:
> I don't know what changed but I think it is debhelper. We have now:
>
> |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act
> | debian/rules install
> | dh_installdeb
> | dh_gencontrol
> | dh_md5sums
> | dh_builddeb
>
> and that
Package: python-evtx
Version: 0.6.1-1
Severity: serious
Justification: missing dependency
$ evtx_dump.py
Traceback (most recent call last):
File "/usr/bin/evtx_dump.py", line 20, in
import Evtx.Evtx as evtx
File "/usr/local/buildtools/current/sitecustomize/sitecustomize.py", line
152,
Russ Allbery wrote:
> If you want to do what vcswatch is doing (analyze the current code
> repository for Debian packaging for commits that haven't been uploaded),
> and the team is, like Haskell, using a single repository for all the
> packages, you need to be able to find that specific package
Hi,
Ian Jackson wrote:
> Russ Allbery writes:
>> So, maybe something like:
>>
>> -b [; = ...]
>>
>> to build off of what we already have? (With, obviously, a bunch of that
>> syntax marked as optional.) If we ban "=" in , we can allow for
>> to be optional but some other key/value pair
tags 926738 + upstream patch
forwarded 926738
https://public-inbox.org/git/20190409192733.10173-1-xypron.g...@gmx.de/
quit
Hi,
Heinrich Schuchardt wrote:
> The value of the sendmail.transferencoding configuration item is ignored.
>
> A patch has been submitted as
>
Hi,
Vincent Lefevre wrote:
> On 2010-11-03 02:49:47 -0500, Jonathan Nieder wrote:
>> Thomas Dickey wrote:
>>> (e)links(2) is using a different mechanism: it's turned on xterm's
>>> any-event mouse reporting mode (which gnome-terminal happens to
>>> implemen
Hi again,
On 25 January 2019, Jonathan McCrohan wrote:
> I am happy to work on fixing up the FTBFS, but
> because I am not a DD, I would need a sponsor to upload for me.
I'm happy to sponsor an upload, especially if this is a first step
toward team maintenance with Jonas (who I can speak from
Uwe Kleine-König wrote:
> sparse (0.6.0-1) unstable; urgency=medium
> .
>* New upstream version (Closes: #920776)
Wonderful. Thanks for your quick work.
Jonathan
bian/changelog b/debian/changelog
index 5facc36..431b3e7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-runit (2.8.4) UNRELEASED; urgency=medium
+
+ * Copy-edit dh_runit(1) documentation.
+
+ -- Jonathan Nieder Wed, 30 Jan 2019 15:44:58 -0800
+
dh-runit (2.8.3) unstable;
Hi Uwe,
Uwe Kleine-König wrote:
> On 1/29/19 2:38 AM, Jonathan Nieder wrote:
>> Thoughts of all kinds welcome, as always. If you'd prefer this in the
>> form of a "git pull"-able repository, a push to salsa, or an NMU, just
>> ask.
>
> I didn't follow
of a "git pull"-able repository, a push to salsa, or an NMU, just
ask.
Thanks,
Jonathan
>From daad6363969dc9260f87c26b419c88f00db661de Mon Sep 17 00:00:00 2001
From: Jonathan Nieder
Date: Mon, 28 Jan 2019 17:37:19 -0800
Subject: [PATCH 1/3] [debian] document new upstream version in d
Package: sparse
Version: 0.5.2-2
Severity: wishlist
https://public-inbox.org/git/a6b689da-b002-0aa2-e9d6-755d004bc...@ramsayjones.plus.com/
reminded me that sparse has had a few updates that are not included yet
in Debian. Please consider updating.
I'll send the patches in reply to this bug,
(5.2.2-1.4) unstable; urgency=low
+
+ * liblzma:
+* Remove compatibility tricks that permit sharing a process with
+ liblzma.so.2. This means liblzma.a no longer depends on libdl
+ at run time.
+ Closes: #919950. Thanks to Josh Triplett.
+* Breaks: liblzma2 versions without sym
Hi Jonas,
Jonas Smedegaard wrote:
> I can do yet another NMU to fix this, but am hesitating as I worry if
> that will masquerade a lack of responsive maintenance.
>
> Please tell if it is sensible that I take over maintenance of this
> package, or join as co-maintainer, or however is
Dmitry Bogatov wrote:
>> Jonathan Nieder wrote:
>>> + * git-daemon-run: pre-create supervise directory so that postinst
>>> +can start the service (thx Celejar and Dmitry Bogatov; closes:
>>> +#919296).
[...]
> Wierd. It should work. /etc/sv/
errmann; closes:
+ #879165).
* debian/control: use https in Vcs-Browser URL.
-- Jonathan Nieder Mon, 21 Jan 2019 19:36:25 -0800
diff --git i/debian/control w/debian/control
index 12450b1af3..965b8c6b36 100644
--- i/debian/control
+++ w/debian/control
@@ -8,7 +8,7 @@ Build-Depends: libz-dev
Hi Frederic,
In April, 2017, Frederic wrote:
> Package: gitk
> Version: 1:2.11.0-2
> Severity: important
>
> Dear Maintainer,
>
> After an upgrade from jessie -> stretch, I got this error message
>
> /usr/bin/gitk: 3: exec: wish: not found
Sorry for the long silence. That's certainly
reassign 771170 libcurl3-gnutls 7.38.0-3
affects 771170 + git
quit
Hi,
In November, 2014, Peter Palfrader wrote:
> I recently started to move parts of debian.org's infrastructure to jessie. I
> noticed a regression with software using curl to do https with certificate
> verification.
>
> On
tags 919296 - patch pending
quit
Jonathan Nieder wrote:
> For "buster", I prefer a minimal fix within the framework of the
> current packages, along the lines you suggested upthread:
>
> diff --git i/debian/changelog w/debian/changelog
> index ef513b2e1d..fb996c9
on (thx Jens
Reyer; closes: #707790).
+ * git-daemon-run: pre-create supervise directory so that postinst
+can start the service (thx Celejar and Dmitry Bogatov; closes:
+#919296).
-- Jonathan Nieder Mon, 21 Jan 2019 19:36:25 -0800
diff --git i/debian/git-daemon-run.dirs w/deb
# missing Depends
severity 919296 serious
quit
Celejar wrote:
>> Celejar wrote:
>>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
>>> README.debian) fails with:
>>>
>>> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> ii runit
Hi again,
Celejar wrote:
> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> Versions of packages git-daemon-run depends on:
> ii adduser 3.118
>
Hi,
Celejar wrote:
> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
>
> I see that there's an old, archived bug about this:
>
>
Hi,
Helmut Grohne wrote:
> I find myself repeating a mapping from Debian architectures to the
> typical output of uname -m (and occasionally -s) in various packages.
> Copying such code is going to be a maintenance nightmare, so it should
> live somewhere central. I propose
Hi,
Marc Haber wrote:
> On Wed, Jan 02, 2019 at 12:29:50PM +0900, Ansgar Burchardt wrote:
>> I hereby propose to drop section 1.6 Translations and the following
>> sentence: "When translations of this document into languages other
>> than English disagree with the English text, the English text
Adam Borowski wrote:
> logind: an org.freedesktop.login1 D-Bus API implementation
> default-logind: distribution's default logind provider
Seconded.
I like this description because it doesn't make assumptions about how
many logind implementions there are or which is the current default,
which
forwarded 741883 https://public-inbox.org/git/20181216232429.gj75...@google.com/
quit
Hi,
In March, 2014, Robert Luberda wrote:
> The following setting in gitweb.conf
> $feature{'javascript-actions'}{'default'} = [1];
> breaks the gitweb's blame page: clicking on line numbers displayed in
>
Hi,
In February, 2014, martin f krafft wrote:
> $HOME seems unset when git-daemon starts, which causes
>
> remote: warning: unable to access '/root/.config/git/attributes':
> Permission denied
>
> to be printed on cloning.
>
> exporting $HOME e.g. to gitdaemon's home directory, or
>
Hi Helmut,
In April, 2013, Helmut Grohne wrote:
> I verified that the attached patch solves this particular issue.
>
> Helmut
> Description: Avoid reading /tmp/.gitattributes
> Author: Helmut Grohne
> Last-Update: 2013-04-03
> Bug-Debian: http://bugs.debian.org/704005
>
> git-cvsimport invokes
severity 915644 wishlist
tags 915644 + patch
quit
HJ wrote:
> On Wed, 5 Dec 2018 at 19:11, Jonathan Nieder wrote:
>> Hm. Git already depends on libcurl3-gnutls, which recommends
>> ca-certificates. Can you say more about your setup where this
>> happened?
>
> I
reassign 915632 gitweb 1:2.19.2-1
found 915632 git/1:2.11.0-3+deb9u4
tags 915632 + upstream
quit
Hi,
Martin Mares wrote:
> After upgrade to Stretch, gitweb no longer finds the configuration file
> "gitweb_config.perl" in the current directory. However, "man gitweb" still
> mentions this as one
severity 915644 normal
quit
Hi,
HJ wrote:
> please add ca-certificates as a recommeded or suggested package,
> otherwise checkouts will fail with:
>
> "
> ssf@TinyBOX:~$ git clone https://gitlab.com/foo.git
> Cloning into 'foo'...
> fatal: unable to access 'https://gitlab.com/foo.git/': server
Paul Gevers wrote:
> https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-remote-hg/1428119/log.gz
>
> not ok 32 - pull tags
The package ought to run "make TEST_OPTS=-v" to produce a more useful
log[*].
Bisects to the following Git change:
e198b3a740409fabe5ba774c5f1255b55fdd21c1 is the
Hi Jeremy,
Jeremy Bicha wrote:
> Did you see https://bugs.debian.org/911997 ?
No, I didn't. I wonder if there was a mail delivery outage from the BTS
or something.
> I believe you were interested before in getting the Debian and Ubuntu
> packaging for git in sync so that Ubuntu would
Hi Jonas,
Jonas Smedegaard wrote:
> I've prepared an NMU for git-remote-hg (versioned as 0.4-0.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.
>
> I also pushed my changes to g...@salsa.debian.org:debian/git-remote-hg.git
Not sure why I didn't get
Hi Ian,
Ian Jackson wrote:
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/1382882/log.gz
[...]
> Looking at the test log did not immediately suggest a cause to me.
> But it is probably much easier for me to (at least initially)
> investigate this, since I will hopefully
Jelmer Vernooij wrote:
> Add patch 01_sigterm_handler: don't install broken sigterm handler.
> Closes: #903854, #914488
Thanks! That was fast.
Andreas Henriksson wrote:
> It seems obvious to me that the above policy snippet was written in a
> time when the universe revolved around sysvinit. In current day and age
> sysvinit itself would be an "Alternate init system". We could update the
> snippet to say that any package providing
Hi,
Emilio Pozuelo Monfort wrote:
Michael Gilbert wrote:
> Major updates to chromium in stable have so far been contingent on it
> being a leaf package, where there is no chance for it to break
> anything else. Adding CEF as a reverse dependency would change that.
^^
> On
Hi,
spuggy...@gmail.com wrote:
> When run under dash, systemd-detect-virt returns "none" in a systemd-nspawn
> chroot'd environment when it should not; same command under bash works
> as expected.
Do you have more details? What test does systemd-detect-virt use, and
why is it failing on dash?
Hi,
Guillem Jover wrote:
> So, first, thanks for the constructive proposals! But I'd rather not
> revert this change. I'm happy to implement anything sane people might
> find useful to cope with such change. This includes the following
> changes which I've started coding:
>
> * DPKG_PAGER
Package: git-review
Version: 1.26.0-1
Severity: wishlist
git-review 1.27 has been released[1]. Most notably, it uses the recommended
refs/for/ syntax[2] instead of refs/publish/ to push changes
for review[3].
I tried importing the new version using gbp-import-orig and building and it
seems to
Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 5:57 PM Jonathan Nieder wrote:
>>> There is no reason this functionality cannot be offered in Debian. We
>>> got complaints when we supported other browsers but not Google Chrome.
>>
>> Since Google Chrome
Hi,
Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila wrote:
>> What I said is that no sane package in Debian/main should need to put
>> files directly in /etc/opt. That's an oddity, a very unorthodox thing,
>> it would be like a Debian package in main putting stuff directly
Hi,
Jelmer Vernooij wrote[1]:
> Git's http-backend has become slightly stricter about the content
> of the CONTENT_LENGTH variable. Previously, Dulwich would leave this
> variable empty but git now expects it to be set to 0 for GET requests
> without a body.
>
> I'm uploading a fixed version of
severity 907449 important
quit
Hi,
Antonio wrote:
> in a program I tested the lzma library for compress with multithread
> function lzma_stream_encoder_mt, with the following results:
>
> - if I link with dynamic library everything is fine
> - if I link with static library, are returned these
Hi Russ,
Russ Allbery wrote:
> I'm looking for seconds for this patch to relax the current requirement
> back to a should.
[...]
> --- a/perl-policy.xml
> +++ b/perl-policy.xml
> @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall"
>Script Magic
>
>
> -All packaged perl
Hi,
Arnaud Rebillout wrote:
> During all this time when I was questioning myself on the reason to
> un-bundle, the only official documentation I found was the short
> paragraph in the Debian Policy [1], which is quite thin. Only now,
> through the thread in debian-devel, I discover that there is
Hi,
Sean Whitton wrote:
> On Thu 23 Aug 2018 at 12:27PM +0200, Alec Leamas wrote:
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries
>
> Thank you for sharing this link -- it seems like Fedora have thought
> harder about this than we have, at
Hi,
Dominic Hargreaves wrote:
> On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
>> I do feel like allowing either based on the whim of the packager is just
>> kind of bad. It produces inconsistent behavior to no real benefit for
>> anyone. If you install a Perl earlier in your
Hi,
Ian Jackson wrote:
> Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
>> Currently, copyright-format
>> 1.0 requires either that every License stanza in a Files paragraph contain
>> some "license text" in the copyright-format
> presumably the right file to refer to.
$ ls -ld /usr/share/doc/git/html
lrwxrwxrwx 1 root root 10 May 30 2017 /usr/share/doc/git/html -> ../git-doc
Is it configured differently on your machine? This setup is from
commit 894cf6b9c9cd7d9e783637a1033169a546c78276
Author: Jonathan Nieder
Hi,
Clément Hermann wrote:
> On 03/08/2018 04:23, 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).
>>>
Debian Bug Tracking System wrote:
> Version: 1.10.1-2
> Closes: 905551
\o/ Thanks for the quick turnaround.
Hi,
Sean Whitton wrote:
> On Thu 02 Aug 2018 at 07:29PM -0700, Jonathan Nieder wrote:
>> Thanks. Unfortunately, that wouldn't address Clément's concern about
>> maximal verbosity (1) not being consistent with reasonableness and (2)
>> not being concrete enough to easily
Jonathan Nieder wrote:
> I'll send a debdiff in a separate message.
Patch attached. Thoughts of all kinds welcome.
>From 31e72e18b9a9c97d67b685bbbe5b1278f5381835 Mon Sep 17 00:00:00 2001
From: Jonathan Nieder
Date: Sun, 5 Aug 2018 17:32:40 -0700
Subject: Apply Brandon Long's oauth
Package: mutt
Version: 1.10.1-1
Severity: wishlist
Tags: upstream patch fixed-upstream
Hi,
As described in
http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180611/000121.html,
Gmail supports RFC 7628 for oauth as a way of avoiding password based
auth. Applying three upstream patches gets
Hi Elana,
Elana Hashman wrote:
> NEWS.Debian files are listed in the "unofficial policy"[1] but not in
> the official policy.
>
> It seems this was proposed in 2002[2], but in 2003, folks were
> hesitant to "[get] this into policy until enough stuff uses it that we
> can tell it works well".
>
>
Josh Triplett wrote:
> Why don't we make a specific exception for d-i in the short term, in the
> hopes that in the long term we'll have a way to handle dependencies on
> sources
Thanks, that makes a lot of sense to me.
I retract my second in message #13, but I'd be happy to review a patch
that
Ian Jackson wrote:
> Jonathan Nieder writes ("Re: permit access to apt repositories during
> builds"):
>> My feeling is that this should be an outside-policy carveout, since it
>> makes many applications (e.g., analyzing the build graph, especially
>> when n
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
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)
>>
1 - 100 of 6968 matches
Mail list logo
