on, etc.) then we could implement that in our own
arrangements even if upstream haven't taken those patches yet.
Regards,
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, this is not an appropriate strategy for salsa.
I hope that you find this message useful, rather than just a statement
of things which are mostly obvious and/or irrelevant.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 11 Aug 2019 01:11:01 +0100
Source: dgit
Binary: dgit git-debrebase git-debpush dgit-infrastructure
Architecture: source
Version: 9.7
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
t
and drop privileges. And of course there is authbind.[1]
Ian.
[1] which I wrote and maintain, insofar as maintenance is needed.
--
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.
-default leaf packages.
For me, if I were doing (say) RC bugfixing and was considering asking
for a removal, even a moderate popcon figure would give me pause.
Conversely, a low popcon figure would encourage me to consult on
removing the package.
Ian.
--
Ian JacksonThese opinions are my own.
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team:
ride like the wind, Bullseye!"):
> No, what I have been perceiving (and pretty please note that this is my
> personal "feeling") is that maintainers, specially library maintainers, have
> even more and more "stuff to
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> We have already thrown sysvinit away.
No, we have not.
https://tracker.debian.org/pkg/sysvinit
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit#_2_4_5
running component that waits for the
> right time.
Right. And as you say it is therefore systemd-cron whose behaviour is
at issue, not systemd's.
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.
Philipp Kern writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On 2019-08-05 17:34, Ian Jackson wrote:
> > With current code the options are:
> >
> > A. Things run in series but with concatenated output and no individual
&g
nowledgeable people will not have too much trouble interpreting
combined output, and maybe have external monitoring arrangements
anyway. Conversely, heisenbugs and load spikes are still undesirable.
So they should also choose (A).
IOW reliability and proper operation is more important than sep
-to-source-package transformations.
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.
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> Ian Jackson writes:
> > This requirement can be met (as I mentioned before) by
> > including the tag object data as a file in the upload (listed
> > in .changes). The signat
ntioned before) by including the
tag object data as a file in the upload (listed in .changes). The
signature can be verified without any further data. A git bundle is
not needed.
I just need to know what filename I should give it.
--
Ian JacksonThese opinions are my own.
If I emailed you from
Johannes Schauer writes ("Re: B-D on src package? (was: Re: Challenge from
Julia's non-standard vendored openblas"64_""):
> We have to think about a good syntax for the Build-Depends field
> which is able to express a build dependency on source packages
> unpacked to /usr/src
Can I make a
se).
Perhaps I have misunderstood what you mean by "validate the PGP
signature".
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.
ient. So generating the
.dsc on the user's system defeats the object of the exercise.
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 object has a signature which is verifiable without
relying on the git object hash system. The tag text directly contains
the source package name, and version, and intended upload target.
> I don't know if any of this requires a new dpkg source format to
> implement properly.
I don't thi
e practical to make this tag other than with
git-debpush (or some other special utility with the same code).
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.
Steffen Möller writes ("And in 2019? Re: -flto to become more of a routine -
any change in opinion since 2011?"):
> We just had SuSE embracing LTO
> (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
> I am not sure about the
irectly helpful to you right now, but:
If we could build-depend on source packages, you could combine these
two ideas into something that might be less awful.
Anyway, good luck.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a p
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
> >I worry about additional concurrency. Unlike ordering bugs,
> >concurrency bugs are hard to find by testing. So
be a one-off change to a fairly new
interface.
Conversely, retaining the current default setting will cause needless
friction for all new projects forever (or, at least, so long as gitlab
and salsa exist).
Ian.
(maintainer of a package with an upstream .gitlab.yml which therefore
causes trouble in sal
git repositories on Salsa are most commonly
> used for Debian packaging where we try to minimize delta vs upstream
> source code:
Thanks for this lucid explanation of the technical reasons why we
should be using our own yml path for this.
Ian.
--
Ian JacksonThese opinions are my own.
bad idea.
The objective is to run them "at some point", not to get it done as
soon as possible. Running them in sequence will save electricity,
may save wear on components, and will reduce overall impact on other
uses of the same system.
Ian.
--
Ian JacksonThese opinions are my ow
action sounds like less work for
> me and result in less likelihood of me forgetting a step (either the
> push to salsa, or sometimes an upload).
Right. Thanks for your support.
> On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote:
> > Please see this blog post to lea
.orig if it is going to
be needed, and not otherwise. Ie dgit doesn't guess based on the
version number. (It will also spot if the .orig you have is not the
same as the one in the archive.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 25 Jul 2019 13:12:08 +0100
Source: dgit
Binary: dgit git-debrebase git-debpush dgit-infrastructure
Architecture: source
Version: 9.6
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
r signature verification, we are much more vulnerable to DoS. An
approved signer can get the service to do a lot of work. That is the
purpose of the service, indeed.
--
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 23 Jul 2019 21:12:59 +0100
Source: dgit-test-dummy
Binary: dgit-test-dummy
Architecture: source
Version: 1.25
Distribution: experimental
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
Description:
dgit-test
Package: dgit-infrastructure
Version: 9.4
Raphael Hertzog writes ("Re: git & Debian packaging sprint report"):
> On Sun, 21 Jul 2019, Ian Jackson wrote:
> > IME as a sponsor I get (AFAICT) no mails as a result of my sponsorship
> > signatures so I think ther
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 22 Jul 2019 01:24:42 +0100
Source: dgit-test-dummy
Binary: dgit-test-dummy
Architecture: source
Version: 1.24
Distribution: experimental
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
Description:
dgit-test
to use this
service right away.
Ie I think you would consider this a blocker for you to use it as a
sponsor. Do you consider this a blocker for deployment at all ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a pr
tectures and you
could depend on that. It would centralise the unsupported arch list
and could be generated easily by src:libseccomp-dev.
Can anyone see a problem with this idea ?
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.
o debian-python.
Empty directories are not representable in git. So I (and other git
users) would appreciate it if you would make your package not contain
them, or at least still build if they are removed.
I consider this a bug in git but my git Stockholm syndrome means I am
asking you to work
Russ Allbery writes ("Re: git & Debian packaging sprint report"):
> Ian Jackson writes:
> > I think in general those places are probably mistakes. But I'm not
> > aware of all of them. One way to look at this is that from the
> > archive's point of view this r
only" ?
Writing this I just thought of another chart which might be very
interesting. Last upload. (By Debian release intervals maybe, rather
than by years?)
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk,
ag2upload model of course preserves the original uploader's
identity in the form of the signature on the tag they make to instruct
the robot.
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 20 Jul 2019 16:26:32 +0100
Source: dgit
Binary: dgit git-debrebase git-debpush dgit-infrastructure
Architecture: source
Version: 9.4
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 18 Jul 2019 03:10:25 +0100
Source: dgit
Binary: dgit git-debrebase git-debpush dgit-infrastructure
Architecture: source
Version: 9.3
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
not sure where I should send this so that the next person with
your question finds it (other than just posting it to -devel when it
seems relevant).
I highly recommend the approach of writing a comment next to each
override etc., explaining what it's there for.
Ian.
--
Ian JacksonThese opin
Sean Whitton writes ("git & Debian packaging sprint report"):
> Main achievement
>
>
> We designed and implemented a system to make it possible for DDs to
> upload new versions of packages by simply pushing a specially formatted
> git tag to salsa.
>
> Please see this blog post
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 09 Jul 2019 22:01:25 +0100
Source: dgit
Binary: dgit git-debrebase git-debpush dgit-infrastructure
Architecture: source
Version: 9.2
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 07 Jul 2019 14:28:27 +0100
Binary: dgit dgit-infrastructure git-debpush git-debrebase
Source: dgit
Architecture: all source
Version: 9.1
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 06 Jul 2019 19:52:46 +0100
Source: dgit-test-dummy
Binary: dgit-test-dummy
Architecture: source
Version: 1.23
Distribution: experimental
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
Description:
dgit-test
Paul Wise writes ("Re: Survey results: git packaging practices / repository
format"):
> On Thu, 2019-07-04 at 12:19 +0100, Ian Jackson wrote:
> > What should another Debian contributor do, who wants to make a change
> > to the upstream source, but wants to do so
e as
requiring quilt.
Ian.
[1] Or convert the package to some other format for doing their
development work and testing, or base their actual development work
and testing on a dgit import, and then convert the result back to your
git branch at the end. Certainly that is what I would do.
--
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> > Anyway, I'm very happy to talk to you (or anyone) about your own
> > situation in
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 11:41:34AM +0100, Ian Jackson wrote:
> > People like you are precisely the intended users of "dgit push --gbp".
> >
&
tices / repository
format"):
> On Mon, Jul 01, 2019 at 12:49:05PM +0100, Ian Jackson wrote:
> > My table is supposed to be useable without knowing anything about
> > dgit.
>
> That's the case for me. I need to admit that I did not used dgit. The
> reason is that I'm
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote:
> > From https://perl-team.pages.debian.net/git.html#Patches it appears
> > the Perl team is using what the survey page has labelled as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 02 Jul 2019 16:55:15 +0100
Source: dgit
Binary: dgit git-debrebase dgit-infrastructure
Architecture: all source
Version: 9.0
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
Closes
ries of messages, is not very likely
to produce useful outcomes. And some off-thread-topic messages are to
be expected, but it is a problem if the thread gets derailed.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, th
> upstreamupstream/latest, upstream/2.32.x, etc.
> pristine-tar pristine-tar
... to discuss or even include 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.
Ian Jackson writes ("Re: Survey results: git packaging practices / repository
format"):
> What it doesn't say is how changes to the upstream files are
> represented. Can you explain ?
Also: I had hoped that the table's focus on particularly these
questions:
- represent
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > Thanks to everyone who responded. I (with some help from Sean and
> > some review from Sam) have worked the
Enrico Zini writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > I hope you all won't mind too much that Sean and I have privileged our
> > own point of view, in the columns which
Andrej Shadura writes ("Re: Survey results: git packaging practices /
repository format"):
> On Fri, 28 Jun 2019 at 16:42, Ian Jackson
> wrote:
> > [1] This does *not* include the one response from a Debian downstream.
> > The task of being a Debian do
Ian Jackson writes ("Survey: git packaging practices / repository format"):
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git
Simon McVittie writes ("Re: getting rid of "testing""):
> On Thu, 27 Jun 2019 at 12:04:39 +0100, Ian Jackson wrote:
> > [What is currently stable, etc.] is available via the ftpmaster API
> > service, and by reading symlinks
> > in archive mirrors. I
sn't mean we shouldn't have version aliases.
Stepping back a bit:
Can we have a comment from ftpmaster on their view of the rough
consensus here? I think a Last Call (time-bounded) would be good.
(I really liked the approach Sam took with the dh discussion.)
When an ftpmaster decision has been mad
about the sort order of these codenames.
I agree with the rest of Andreas's message.
> Please leave testing as a name
As I said, I see no reason why [[old]old]stable and unstable need to
be abolished as names. They will still be useful in conversation,
even if they were never very
his should not be done retrospectively to old suites, because
there is software outside the archive that wants to name things by a
single canonical name, and changing that name for an existing suite
will cause trouble.
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.
Theodore Ts'o writes ("Re: Survey: git packaging practices / repository
format"):
> On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote:
> > How do you update to a new upstream version while preserving your
> > delta queue ? Just git merge with an upstream see
Theodore Ts'o writes ("Re: Survey: git packaging practices / repository
format"):
> On Tue, May 28, 2019 at 04:51:10PM +0100, Ian Jackson wrote:
> >
> > Modified Direct changes git merge
> > upstream files,to upstream files (.
used with either of these kinds of
representations of the upstream.
The resulting workflows are indeed very different for "new upstream
version" (but not for other changes).
I'm not sure yet how to report this in my survey results, but I'm
leaning towards a separate table.
Ian.
--
I
of their maintainers are (as might be
expected) quite idiosyncratic, even insular. To get all such git
workflow tools to have some new behaviour would be a big task and
would require serious political backing. And a design predicated on
such a change will cause lossage when older tools are use
see who is using the program.
(This is the concern mentioned by Simon.)
So I think ZZZ should be patched to not download ads from the network.
It would be polite to have a conversation with upstream about this,
and we in Debian would always strive to be polite, but if ZZZ is free
software t
Ian Jackson writes ("Re: The Difference between debcheckout and dgit and what
they try to accomplish"):
> Hector: If it would be useful to you, I could tell you a set of dgit
> configuration settings to have it use the apt repository fetching
> method. That would rely, therefo
ory thing, after you `dgit clone`, `git fetch vcs-git` will
> get you the maintainer's history for browsing. That's about as easy as
> debcheckout.
It's not really what Helmut wants, though.
Ian.
[1] I don't appear to have saved a transcript of the conversation.
--
Ian JacksonThese opinions
ally generated files - eg d/control -
in the dgit/.dsc view. Edits to the dgit view which change
automatically generated files are not automatically back-convertable.
Indeed some such changes may not be representable at all in the
maintainer view...
--
Ian JacksonThese opinions are my own
cope.
Great.
I'll wait to see what you say to this "scoping" mail. Hopefully I can
then go back and read your initial mail again and try to discuss
technical details in a more useful way.
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.
dgit
fetch' except to incorporate NMUs.
Err, too many negatives. Let me try that again:
I don't expect a maintainer to necessarily use dgit clone. Nor do I
expect them to use debcheckout, either.
When (considering) joining a maintainer team, dgit clone followed by
`git fetch vcs-git' is probab
lar question again, after getting No.)
And those of us with gatekeeper roles should tolerate that, and when
we say No we should give reasons, state clearly any boundaries that
need reinforcing, and if possible make helpful alternative
suggestions.
Thanks,
Ian.
--
Ian JacksonThese opinions are my ow
nt* responsibility.
Our job as maintainer is not to do all the work. If we like to do the
work ourselves, great. If we don't and the work goes undone, well,
c'est la vie; maybe someone else will have the energy.
But our one un-shirkable responsibility is that of creating an
environment
the evidence of bad faith,
but also because Debian's overall attitude to GPL compliance issues
like this one is, as others have noted, very firm, and because of the
secondary status of contrib.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.
other legitimate private
mail domains.
Debian is in a better position than most to resist the hegemony of an
oligopoly of unaccountable email providers. We should use our
political power, such as it is.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.
rd what the most recent rebase is. Obviously I prefer
git-debrebase since I wrote it - using a different data model - even
after I knew about git-dpm and its data model. But maybe this isn't
the thread for that advocacy conversation.
Ian.
--
Ian JacksonThese opinions are my own.
If
Ian Jackson writes ("Re: Survey: git packaging practices / repository format"):
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
...
> > With unmodified upstream files in the main branch, plus debian/*, but
> > usu
e knows how to make patches itself so
you don't need git-debcherry then.)
--
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.
Ansgar writes ("Re: ZFS in Buster"):
> Ian Jackson writes:
> > I think this would be both unwise legally (without seeking additional
> > legal advice) and rather rude to the kernel upstream whose code is
> > then being reused without permission - indeed, contrary
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> On 28.05.19 22:08, Ian Jackson wrote:
> > Please can we leave aside discussion of the merits or otherwise of
> > each of these formats/workflows.
> >
> >
bothere with that .dsc stuff.
But my aim in this thread was to capture how people work *within*
Debian, where a maintainer is still required to produce a .dsc.
(Sorry that maybe I have wasted your time answering my questions.)
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed yo
sadvantages of various approaches and I can usually
see why people have done things, even things that I think are a bad
idea. So I don't need help with that.)
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.
npages.debian.org wasn't any help.
Did you mean dpkg-buildpackage ?
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.
?
I think this would be both unwise legally (without seeking additional
legal advice) and rather rude to the kernel upstream whose code is
then being reused without permission - indeed, contrary to their
explicitly stated intent.
We alread sought legal advice, with resulted in the halfway-house
am ?
The more I think about this the more puzzled I seem.
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: Survey: git packaging practices / repository
format"):
> On Tue, 28 May 2019 at 16:51:10 +0100, Ian Jackson wrote:
> > Unmodified debian/patches gbp, gbp pq
> > upstream files,(only)quilt
Ian Jackson writes ("Survey: git packaging practices / repository format"):
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git
Chris Lamb writes ("Re: Survey: git packaging practices / repository format"):
> Dear Ian,
> > Can you please look through the table below and see if I have covered
> > everything you do ?
> >
> > In particular:
> > - have I missed a git repository and history layout
> > - have I missed a
ackage-language-specific
One branch for specific subdirectory; monorepo tooling,
many packages.found in same branch
Tooling to makeBaseline upstream is
d/control etc. named by reference somehow
during build
Thanks,
Ian.
--
Ian J
them to do tests that make up
> for that experience gap. None of this changes any of that or asks
> maintainers to treat bugs about dh differently than other bugs.
My personal position is that I agree with your conclusions here.
I don't feel confident to say what the consensus was. I have
replaced by
>
> mkdir -p /var/lib/sgml-base
>
> which does the right thing silently when it is possible, and fails with
> a message otherwise.
I agree that that is probably what the author meant.
> Any thoughts? -Ralf.
I think you should send a patch.
Ian.
--
Ian Jackso
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 27 May 2019 00:20:58 +0100
Source: dgit
Binary: dgit git-debrebase dgit-infrastructure
Architecture: all source
Version: 8.5
Distribution: unstable
Urgency: medium
Maintainer: Ian Jackson
Changed-By: Ian Jackson
Closes
gt; Added. Thanks.
I expanded a bit on the "without my mistakes being visible" part. I
have heard similar questions from others.
Much Debian tooling is very easy to make public mistakes with. We
have tried quite hard with dgit to make that not the case. Instead,
dgit is easy to provoke in
r you into doing work on a
package you don't much care about any more. I don't feel converting
this package, even as an example to others, is a thing that I want to
spend my time on...
Regards,
Ian.
[1] https://xkcd.com/386/
--
Ian JacksonThese opinions are my own.
If I emailed you from
g build
> system would be an possible strategy for fixing bugs in an NMU.
This is a great idea. Obviously such a policy/process change would
have to come with a significant lead time so that everyone would have
a chance to do an upload with an appropriate README.source.
Ian.
--
Ian Jackson
Holger Levsen writes ("Re: Do we want to Require or Recommend DH"):
> On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> > This provides an excellent
> > opportunity to leave a comment next to each weird thing explaining why
> > it's there.
> > h
://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules
Wow. This is like night and day. My instinct is definitely that I
don't like cdbs but omg dh needs this feature.
I looked through the src:debhelper bugs and didn't see a request for
this.
Ian.
--
Ian JacksonThes
t.debian.org/xen.git/tree/debian/rules#n111
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.
dqy, when I needed
dpkg to handle each file in a tarball individually, I found a tar
parsing library under a rock somewhere. It wasn't a bad one but I'm
sure it could be improved...
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that i
101 - 200 of 2647 matches
Mail list logo
