and inconclusive, compared
to the value to be gained.
> So I think we can close the clone of this bug against Policy for now.
The bugs seem very confusing to me. A sprawling mass of
partially-duplicated stuff. See my comment above for a suggested
wording clarification.
Ian.
--
Ian Jac
l in the
right place.
So I think it would be best if lintian would warn about 1.0 format
native source packages with non-native versions, with a suitable
explantion which will encourage the maintainer to override the
warning if they did this on purpose.
Ian.
--
Ian JacksonThese opinions are m
ive
improvement over what was being done before its introduction. I can
quite see why it was designed the way it was.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
build time". It's true as far as it
goes but doesn't address the key problems, namely that the single
patch ends up inside the tree.
This could be solved by a new `3.0 (diff)' format perhaps. If and
when that is provided then this one scenario would perhaps be better
handled that w
] but permits (and eats) spaces inside the [ ].
I'm inclined to think that these questions show that my original
proposal was not brilliant and that your idea is better.
HTH.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, t
include `1' for pubkey-algo and `8' for hash-algo
then ?
Ian.
[1] Part of the output of
gpgv --status-fd=2 --keyring=/usr/share/keyrings/debian-keyring.gpg <
../bpd/dgit_9.4.dsc
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.o
Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
info in .dsc [and 1 more messages]"):
> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
> > Git-Tag-Info: fingerp
isting RFC-2822-style fields we
> have), which I think increases the chances that parsers will get this
> right.
Right. I already need and have code to turn a git-style
committer/author/tagger line into deb822 form.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you
Hi. I am consulting on the name and syntax of a new field I intend to
put in .dsc's.
This is for our tag-to-upload service[1], as described here:
https://spwhitton.name/blog/entry/tag2upload/
The tag2upload service will take a signed git tag, and verify it
against the Debian keyrings and dm.tx
also be added.
So the overall syntax is roughly
[ " -b " ] [ " " ]
[ " [" ( | "=" "; " )* "]" ]
We can say that it's if it has "=" before any "/". Then paths
containing = are expressable as ./fo
Russ Allbery writes ("Re: Bug#932696: Please document Haskell team style
Vcs-Git sytax [and 1 more messages]"):
> Sure, an extensible syntax sounds great. The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed support of the -b option), but
d dgit would probably have coped here.
(#932697 in devscripts and #932699 in dgit.)
Ia.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Package: debian-policy
Version: 4.4.0.1
Many packages' .dscs contain something like this:
Source: bustle
Version: 0.7.4-1
Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]
The semantics do not appearr to be documented in policy.
Ian.
--
Ian Jackson
r, an
post-promulgation objection is made which raises a substantial issue
that ought to be dealt with.
While vacillation is undesirable, making it easier and less socially
costly to handle mistakes, will make it easier to make changes.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
f the content of
those decisions.
Ian.
[1] I should say that I think the individual members of TC are and
have been people of generally very high caliber. IMO the failings are
emergent properties of the structure, context and framing.
[2] Much of this is, I think, ultimately my fault. I inve
change the process.
The process is a creation of the policy editors, not of the DPL nor of
the rest of the project.
Ian.
[1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html
[2] https://en.wikipedia.org/wiki/Ultra_vires
--
Ian JacksonThese opinions are my own.
If I ema
Ian Jackson writes ("Re: Bug#920692: Packages must not install files or
directories into /var/cache"):
> Josh Triplett writes ("Bug#920692: Packages must not install files or
> directories into /var/cache"):
> > It's well-established in Debian (but not do
Josh Triplett writes ("Bug#920692: Packages must not install files or
directories into /var/cache"):
> It's well-established in Debian (but not documented in Policy) that
> packages must not install files or directories under /var/cache.
I think `install' is a bit less clear than it should be. I
with some wording about
versions and orig component names, or the filenames implied thereby,
being globally unique.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
s on a weaker rule or a weaker normative status, than to
invoke the TC for this issue, IMO. IOW I don't think this is
important enough to escalate.
HTH.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
declare
that the untranslated policy is not necessarily all in English. It
might be a mixture of languages.
So we could have a policy subsection in Japanese perhaps, if expertise
in a particular area is mostly held by speakers of Japanese. There
would presumably have to be (non-normative) Engl
ck Ridge and Joliet is, I suspect, already
> > unsupported.
>
> Could you define what you mean by unsupported ?
I think, "already does not work". Bare ISO9660 only supports 8.3
filenames so couldn't possibly work.
Ian.
--
Ian JacksonThese opinions are my own.
If I ema
The condition (ii) would have to be clearly stated and
then implemented in dak and reprepro and launchpad (at least).
Does that make sense ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
?
Thanks,
Ian.
[1] Indeed dgit itself has both Debian/ and debian/ subdirectories.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Andrey Rahmatullin writes ("Re: Bug#918438: orig tarball components with
uppercase letters"):
> On Sun, Jan 06, 2019 at 12:34:30AM +, Ian Jackson wrote:
> > This allows the possibility of uppercase letters [1]. But of course
> > distinguishing case of letter
anyone would read that that was
intended and I am confident that dpkg-source would actually reject
those.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
The harm done by these kind of strategies is real but the
cost of educating everyone, let alone fighting over it, would be
disproportionate.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
re making rc-buggy here, but the fix is easy,
again: add a Build-Conflicts.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
on their merits.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
G. Branden Robinson writes ("Re: Shouldn't shipping broken symlinks be against
policy?"):
> At 2018-11-13T17:02:49+, Ian Jackson wrote:
> > I guess the maintainer will also think this is a bug.
>
> No; he closed it, and cited Policy's lack of a prohibiti
G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against
policy?"):
> Not reopening, but I have some questions for the Policy team.
...
> I could have sworn you were incorrect, but sure enough, I read §10.5
> carefully and grepped the rest of the policy manual and could find no
>
inst a user's config files and/or to prevent
> unwanted config files being created.
Having said all that, I don't know if it would be worth explicitly
mentioning this very general and useful technique for the benefit of
readers who haven't osmosed or reinvented it.
Thanks,
I
Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare
relationships"):
> On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote:
> > Or to put it another way:
> >
> > Package builds MAY be influenced by the presence in the buil
e behaviour permitted by my
(ii) is probably common. So we cannot forbid it with a MUST.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
s are installed MUST NOT
have any significant effect.
Any additional package which could reasonably form part of a default
install for a development workstation SHOULD NOT have any significant
effect.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.
level. So either the policy
shading (or whatever) needs to lag very substantially, or we need at
least two kinds of shading.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Russ Allbery writes ("Bug#911165: debian-policy: drop requirement to ship
sysvinit init script with same name"):
> This is not the sort of thing that we should be dropping on an ad hoc
> basis given the project decision to support multiple init systems, since
> if we give up this principle it will
would be a very very bad reason.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian Jackson writes ("Bug#776413: The priority of the ed package"):
> Bastian Blank writes ("Re: Bug#776413: The priority of the ed package"):
> > Serial lines have absolutely no problem with vim or similar stuff. ANSI
> > command sequences work on all
Ian Jackson writes ("Re: Bug#776413: The priority of the ed package"):
> I don't think ex is in the base system. Are you suggesting that an
> implementation of it should be added ? On my system here it seems to
> be provided by vim.tiny and /usr/bin/ex is 20x the size of
Bastian Blank writes ("Re: Bug#776413: The priority of the ed package"):
> On Tue, Oct 16, 2018 at 11:49:58AM +0100, Ian Jackson wrote:
> > This makes it sound theoretical, or a question of breaking people's
> > `finger macros'. That is indeed annoying. B
possible to manually `stty' to set the terminal,
being sure to get the numbers right, or rely on a program like
resize(1)). But then one must remember not to resize the window !
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Josh Triplett writes ("Bug#904248: Beginnings of a patch to add netbase to
build-essential"):
> On Mon, 15 Oct 2018 13:39:32 +0100 Ian Jackson
> wrote:
> > My proposed wording about "longstanding and conventionally available
> > service and protocol names and nu
" says that if the admin has
modified the file they need to make sure their modified version isn't
toally borked.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
idea, it's that it's
not comprehensive enough.
I suggest that instead of abandoning it, we should bump the lintian
message to a warning.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian Jackson writes ("Re: Bug#908933: debian-policy: typo in document in section
3.4 page no 15 line number 16 needs improvement."):
> However, I looked at
> /usr/share/doc/debian-policy/policy.pdf.gz
> from debian-policy_4.2.1.1_all.deb with mupdf on my stretch i386
>
nd it looks absolutely fine. See attached policy-ok.png.
I also looked at it in xpdf on stretch. I even looked in evince,
although I find it maddening. It all seems fine.
I notice that the screenshot is from Adobe Reader.
Ian.
--
Ian JacksonThese opinions are my own.
If I emaile
change to Policy about this.
Maybe adding a link or xref to policy 5.6.12.1 would be helpful.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
not able to
deal individually with every bug report, are "slacking" in their
"duty", quite objectionable, I'm afraid.
> Ian Jackson ,
> > What did you think of the text I proposed just over <- there, that
> > Moritz was happy with ?
>
> Just answering b
roviding
appropriate documentation, by (scaleable) outreach activities, and so
on.
What did you think of the text I proposed just over <- there, that
Moritz was happy with ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk
ing to do it ?
Or are you saying that maintainers should step down and orphan the
package instead ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers not
universally applied"):
> To me, the core message of the current text is that you should ensure
> that bug reports which are not Debian-specific end up with upstream,
> *somehow*, whether by the maintainers forwarding it
Thorsten Glaser writes ("Bug#908155: Coordination with upstream developers not
universally applied"):
> On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote:
> > That's not the current/best practice for a number of packages,
> > either because of the sheer volume of bug reports/size of the
> > package or
Sean Whitton writes ("[DRAFT] Bits from the Policy Team"):
> I'm thinking of sending out the following to d-d-a; reviews welcome.
...
> Thanks to work by Hideki Yamane , Ian Jackson and myself,
I don't feel the need to be credited, TBH, but if you do want to
credit m
ckages are.
(Of course a package foobar must not delete its /etc/foobar.d
directory completely, even on purge, because another package may have
put a dropping into it.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Simon McVittie writes ("Re: Bug#906949: Clarify documentation location in a
Python2-less distribution"):
> On Thu, 23 Aug 2018 at 15:43:06 +0100, Ian Jackson wrote:
> > There are two reasons for the standardised paths in /usr/share/doc:
> > 1. So that the user can fin
Norbert Preining writes ("Re: Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> Hi Ian,
> > This confusing user experience only occurs if someone prepends a
> > different perl to $PATH. Has anyone actually ever done this and got
> >
Stuart Prescott writes ("Bug#906949: Clarify documentation location in a
Python2-less distribution"):
> b) keep using /usr/share/doc/python-foo: do we stick with
> /usr/share/doc/python-foo as a version-independent path even though no such
> package exists once the Python 2 package is gone? (I t
stable ABI ? At least, old modules will work with new perl binaries ?
If I wanted to install my own Perl I would make sure to have
/usr/bin/perl point to it.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Jonathan Nieder writes ("Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> Dominic Hargreaves wrote:
> > On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
...
> In this thread, there are three possible rules proposed:
>
ages are not being prompted to make changes we may later ask them
to reverse. And it will remove the animus behind Norbert's setting of
this bug to `serious' - which I think is arguably justified.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an ad
ed to tedhnical
standards development regarding packaging technology, and certainly
less visible to the whole Debian ecosystem).
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton writes ("Bug#906139: debian-policy: versioned depends on
libjs-sphinxdoc unsatisfiable on stretch"):
> On Fri 17 Aug 2018 at 03:44PM +0100, Ian Jackson wrote:
> > This is a bug, surely. It should be in ${sphix:Depends} or something.
> > Then you could put i
Sean Whitton writes ("Re: Bug#906139: debian-policy: versioned depends on
libjs-sphinxdoc unsatisfiable on stretch"):
> On Fri 17 Aug 2018 at 11:37AM +0100, Ian Jackson wrote:
> > What happens, on the system where debian-policy.deb is installed, if
> > this Depends is v
of the content in is still
accessible ? If so, Vagrant's request to downgrade the dependency is
correct.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Jonathan Nieder writes ("Re: Next steps on "[GPL-3+]" proposal"):
> Ian Jackson wrote:
> > Changing the version would involve parser changes in all parsers.
>
> I don't follow. Why wouldn't a non-validating parser be able to simply
> ignore the
Sean Whitton writes ("Bug#904608: Support specifying upstream VCS location in
debian/control"):
> No-one needs to do that extra work anytime soon. Policy lags best
> practices. The fact that debian/upstream/metadata is already being used
> to store a URI to the upstream repository for a large nu
GPL-v2-only or
whatever, rather than (say) GPLv2+.
IMO in Debian we should not perpetuate this.
Ian.
[1] politically opposed to my own goals, probably deliberately so on
the part of the SPDX authors
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @
Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
> To be clear, I don't believe there's a way forward here that doesn't
> require at least some rewriting of parsers. Currently, copyright-format
> 1.0 requires either that every License stanza in a Files paragraph contain
> som
think even having a version number at all in the
machine-readable copyright format is quite possibly a mistake.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
nent notice that we have modified
> it. I am not a lawyer, but I believe this is enough for the letter and
> spirit of the license: it tells a user "if you are looking for an
> unmodified GNU Hello, this is not it".
I agree. So maybe my suggested text should read something li
Sean Whitton writes ("Bug#459427: Patch seeking seconds on changelog vs. NEWS
handling"):
> +If an upstream release notes file is available, containing a summary
> +of changes between upstream releases intended for end users of the
> +package and often called ``NEWS``, it should be accessible as
>
Jonathan Nieder writes ("Re: permit access to apt repositories during builds"):
> Ian Jackson wrote:
> > See
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813471#126
> > for a more extended rationale for permitting access to sources
> > as well as b
y if the service or protocol was not listed in these files
in the package's targeted Debian releases, an appropriate
versioned build-dependency is needed.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private
lt-Using `` must then be
+declared. It is permitted to download both binaries and/or sources.
+However, this facility should not normally be used.
+
The targets are as follows:
``build`` (required)
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @ev
ike the contentse of policyrcd-script-zg2.
We would then change invoke-rc.d and deb-systemd-* to run that script,
instead of /usr/sbin/policy-rc.d. As an additional bonus, the new
script can run policy-rc.d from $PATH which would be more compliant
with Debian policy.
Does that sound sensible ?
Ian.
ctive
then maybe the answer is just that the admin must configure this
differently depending on what init system they have.
I hope this analysis is helpful.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private ad
ing), that is
> completely dependent on the license of the source/binary being fetched.
> It is probably worth mentioning if we add the apt repo exception.
Right.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
to services that
>were started by the build process. Services started by the build
> process must be shut down after use.
LGTM.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton writes ("Bug#628515: Seeking seconds for patch to recommend
verbose logs and define DEB_BUILD_OPTIONS=terse"):
> I think that the use of 'maximally' is fine given that the previous
> sentence is now qualified with 'reasonably'.
Yes.
> Here is the revised patch; David and Andrey, hop
Sean Whitton writes ("Bug#628515: Seeking seconds for patch to recommend
verbose logs and define DEB_BUILD_OPTIONS=terse"):
> > +The package build should be as verbose as possible, except where the
Are you sure "as verbose as {+reasonably+} possible" would not be
better ?
Imagine a build that, o
dgit rpush ought to work fairly well for the stuations where debrsign
might be used, and does not have this ssh trust reversal problem.
(It still operates rather as a signing oracle but the signing oracle
is much more restricted.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed
s and shell scripts" to explicitly
> permit wrapper scripts §9.9 written by the maintainer?
I think shell scripts are programs.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton writes ("Bug#902612: Packages should not touch users' home
directories"):
> Do you think we could resolve this by adding "... except when that user
> was created by the package or a closely related package." ?
Maybe the concept of an "unrela
bout a "should" ? I think that most people won't ignore a
"should" unless they feel they understand why it's there.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ltation. In practice
there are not going to be big arguments about this.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
quot;, "something mostly 64-bit", "not freebsd") are not
expressable.
I think the result is surely going to be that people write "amd64"
because that "makes their thing work", and anyone who complains about
that will be asked by the maintainer to please suggest a better
option.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ready seconded by Holger).
SGTM. (Count this as a second if you like...)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton writes ("Re: Bug#901160: Updating the description of the
Standards-Version field"):
> ISTM that the status of the upgrading checklist is easier for package
> maintainers to understand if it continues to have no normative status at
> all. It's a pure convenience.
Fine; I don't really
each package should be/It is recommended that each
> package be/
>
> "Should" carries the weight of a bug of 'important' severity, but I
> don't think that was your intent (and I don't think it should have
> been).
Fine by me.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton writes ("Re: Bug#891216: Requre d-devel consultation for epoch
bump [and 2 more messages]"):
> On Fri, May 25 2018, Ian Jackson wrote:
> > When we get to tidying this up, the epoch-ignoring new file name
> > uniqueness section could probably do with a cro
ept separate from all the GUI machinery, but
> I'm sure life is short for upstream and they haven't had an obvious reason
> to bother with this.
So, err, anyway, thanks for the all the explanations and sorry for
what turns out to be a pretty useless bug report.
Regards,
Ian.
--
the invocations we are
using ? Or, indeed for most of its invocations ? ... looks at the
manpage ... oh it's primarily a gui program. *sigh*
> I kind of want to rewrite them in dot, which I personally much prefer, but
> eh.
Glerk. I'm not asking for that ...
Thanks,
Ian.
Ian Jackson writes ("Re: Bug#891216: Requre d-devel consultation for epoch bump
[and 2 more messages]"):
> Control: tags -1 + patch
>
> Thanks for the feedback. Please find attached a diff against current
> master.
The attachment seems to have got lost. Sorry, here it i
Control: tags -1 + patch
Thanks for the feedback. Please find attached a diff against current
master.
Mattia Rizzolo writes ("Bug#891216: Requre d-devel consultation for epoch
bump"):
> On Fri, Feb 23, 2018 at 01:26:01PM +, Ian Jackson wrote:
> > + Epochs should not u
used.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Simon McVittie writes ("Re: Bug#813471: network access to the loopback device
should be allowed"):
> On Thu, 10 May 2018 at 17:51:19 +0100, Ian Jackson wrote:
> > Yes, assuming that it uses gethostbyname() from the libc.
>
> When you say gethostbyname() I hope you&#
a build environment. I'm
a bit surprised that netbase isn't build-essential. Certainly IMO an
/etc/hosts with the entries you describe above should be implied by
build-essential, one way or another.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Simon McVittie writes ("Bug#850156: Please firmly deprecate vendor-specific
series files"):
> On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote:
> > On Wed, 4 Jan 2017 13:41:53 + Ian Jackson
> > wrote:
> > > But [vendor.series] is quite wro
積丹尼 Dan Jacobson writes ("Re: Bug#809383: mention explicitly double listing:
Depends, Recommends, Suggests"):
> Ian Jackson:
> > That doesn't seem to be an answer to Sean's question. Why do you want
> > the question of redundant dependencies dealt with i
1 - 100 of 458 matches
Mail list logo
