ad needed.
> No actual programming involved - unless you want to :-).
We now have two volunteers, which should be ample. Thanks to Xiyue
Deng and Matthias Urlichs.
Ian.
From: Ian Jackson
To: tag2upload beta programme enquirers:;
CC: Sean Whitton
Bcc: ...
Subject: tag2upload beta progra
fairly quickly,
to retain momentum, so availability relatively soon would be good.
We don't think this is a very difficult problem, but neither Sean or I
are sufficiently into Python that we're confident of our ground.
Hence the request for help.
Thanks,
Ian.
We'll be sending a ve
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com
* Package name: intel-lpmd
Version : v0.0.9
Upstream Contact: rui.zh...@intel.com
* URL : https://github.com/intel/intel-lpmd
* License
an be the capable but boring
operating system that just works, giving our users across the world a
system that serves *their* interests, and helps them get shit done.
Best wishes and a belated happy new year.
Ian.
[1] Currently, I'm doing final pre-merge tests on this 73-commit
MR which impl
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com
* Package name: qatengine
Version : 1.6.1
Upstream Contact: Yogaraj Alamenda
* URL : https://github.com/intel/QAT_Engine
* License : BSD
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com
* Package name: qatzip
Version : 1.2.0
Upstream Contact: xinghong.c...@intel.com
* URL : https://github.com/intel/QATzip
* License : BSD
Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and
1 more messages]"):
> Steve, could you please do this for *all* the time_t transition RC
> bugs?
IMO things are currently ON FIRE.
If no-one else has put this fire out by 24h from now, I will attem
rc:dpkg isn't migrating because of #1066952.
The logic of the autoremoval system is that as an affected maintainer
I ought to go and involve myself with #1066952.
And all of this is nonsense since surely we're not going to autorm
git-buildpackage, but right now we have a giant klaxo
s or
individual packages which you are interested in, which includes an
option for receiving BTS traffic.
Ian.
hanks,
Ian.
[1]
https://lists.debian.org/debian-devel/2023/01/msg00059.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908274
[2]
https://salsa.debian.org/helmutg/debvm/-/blob/main/debian/tests/control
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you
On Sun, 2023-08-13 at 22:59 +0200, Timo Röhling wrote:
> There's talk on #d-python if pybuild could/should deal with it; I'd
> give it a few days and see if that pans out.
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46
seems to be the one to watch.
Ian.
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com
* Package name: ipp-crypto
Version : 2021.8
Upstream Contact: Andrey Matyukov
* URL : https://github.com/intel/ipp-crypto
* License
Ian Jackson writes ("Re: Multi-host networking software, autopkgtests"):
> For now I'm working on an adhoc thing that uses
> - Restrictions: needs-root
> - overlayfs to make an editable clone of the fs provided by autopkgtest
> - chroot
> - ip netns
> - a
gtest
- chroot
- ip netns
- apt-mark and apt-autoremove to get rid of unwanted deps
It's not particularly pretty but it's not much code and I feel I'm
making progress. I'll report back here when I've succeeded - or
failed :-).
Thanks,
Ian.
--
Ian JacksonThese op
me and then upload the new package with dgit, it's necessary to ask
a dgit repo admin to do special by hand adjustments. etc.
This all seems like it could do with a checklist that we can at least
add things to each time we discover a brokenness we should have
avoided...
Ian.
--
I
al"
thing ought to be.
I think therefore that I need to pursue some kind of within-testbed
nesting, as an interim approach at the very least. I was hoping that
someone else had solved (part of) this problem already...
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he.
evant packages needed for any of
the two test nodes and the setup scripts; in each node, unshare the
namespaces enough that I can run apt; manually uninstall the
not-needed dependencies, and run apt autoremove.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I email
Thanks to everyone for the comments and review. I have written things
up on the wiki:
https://wiki.debian.org/BuildProfile/upstream-cargo
and added the entry here:
https://wiki.debian.org/BuildProfileSpec
Please comment here, if you think any of this doesn't make sense.
Thanks
Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> On Thu, Dec 15, 2022 at 11:44:34PM +, Ian Jackson wrote:
> > I'm not sure precisely how this feature could (or should) be made
> > available to *all* application pack
ependencies, it is a lot easier
to cause a build to run without the stated build deps being satisfied,
than it is to do violence to the package build system.
This could be made easier. Maybe tools like sbuild could have a
sepaarate option to disregard build deps matching a wildcard pattern,
or something.
I am hoping to leave these considerations for the future.
Ian.
--
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.
helpful for them
So for now I'm proposing to add just the cargo one. If someone
working with Node packages (say) tells me "we want this for npm too"
then great and we should do that right away. Otherwise we should
wait until ti's wanted.
Ian.
--
Ian JacksonThese opi
f a narrow one specific to cargo, compared to a more general
> "fetches-source-during-build" that would be suitable also for e.g.
> NodeJS fetching npm modules?
Wouter made the same point - I will reply there, to both the CC lists.
Ian.
--
Ian JacksonThese opinions are my own
ofile would be available in most Debian packages
containing Rust code, without package-specific work. Whether to
implement such a feature is a matter for the maintainers of dh_cargo
et al.; IMO the build profile registration is useful even ad-hoc,
without any general feature.
Ian.
--
Ian Jackson
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: accel-config
Version : 3.5.0
Upstream Author : Ramesh Thomas
* URL : https://github.com/intel/idxd-config
* License : LGPL-2.1
Programming
Paul Gevers writes ("Re: Half the world being removed"):
> On 02-09-2022 13:00, Ian Jackson wrote:
> > I wonder if it would be possible to detect a sudden large increase in
> > the number of autoremovals, and stop the autoremoval system instead of
> > causing blar
almost every developer.)
This has upsides: I'm personally strongly aligned with ftpmaster's
primary goals, and very supportive of most of their controversial
decisions (especially, the ones about what counts as source code).
But: the difficulties we have with ftpmaster are very deep-r
s, and stop the autoremoval system instead of
causing blaring klaxons for everyone in the project ?
That might make the failures less disruptive. (And would avoid having
everyone pile-on.)
Ian.
--
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.
table
for experimental.
Regards,
Ian.
--
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.
ss our codebase. If there are particular programs that
would benefit from it, by all means enable it in those cases.
Ian.
[1] Assuming that the enum type is used in a relevant way.
[2] If anyone doubts that the C specification is literally
incomprehensible, observe, for example, the existence of
ce it's build system software which
is designed to execute its input) - and that all only in the case
where a second package in Debian uses subdirmk.
It seemed me best to me to defer this work until subdirmk becomes more
widely used.
Thanks,
Ian.
[1]
https://www.chiark.greenend.org.uk/ucgi/~ian
ss, mostly because of symlinks. That would be
pareto-better than 1.0-with-diff.
Ian.
--
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.
ut of date
since the closure of alioth, or perhaps that there isn't one.
I hope thius clarifies.
Ian.
--
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.
Ian Jackson writes ("Re: proposed MBF: packages still using source format 1.0"):
> But I see now that the MBF has gone ahead anyway.
>
> I spent some time trying to help by setting out the factual
> background, but it seems that Debian is not interested in facts. I
>
Ian Jackson writes ("Re: proposed MBF: packages still using source format 1.0"):
> Sean Whitton writes ("Re: proposed MBF: packages still using source format
> 1.0"):
> > [questions]
...
>
> The situation here is complicated.
>
>
> The tl;dr is
urse. That is not an unalloyed benefit,
though, because it means that when diff/patch improve we can
accidentally generate source packages that earlier versions can't
extract - a compatibility hazard.
Changes not representable by diff is what Sean is talking about here:
> Ian has some cases
I think it is fine to accept to main indeed. However, I
> would like the opinion of a more experienced ftp team member. So I've
> removed the internal note I'd put on the package in NEW, so that someone
> else can more readily take a look.
Thanks. I see this has been ACC
est of your mail (let me know if I'm wrong and you'd like a
reply).
Cheers,
Ian
On Sat, 2021-02-27 at 11:21 -0500, Sergio Durigan Junior wrote:
> On Saturday, February 27 2021, Ian Campbell wrote:
> >
> > FWIW that would be my personal preference too (probably with some sort
> > of cache, maybe once per library or executable or some granularity like
hing like that myself
and it seems like a awful lot of quite complex work I wouldn't want to
try and insist (even if I had grounds too, which I'm sure I don't)
someone else does that amount of work, so long as it is opt-in at the
gross level.
Ian.
500, Sergio Durigan Junior wrote:
> so a possible mitigation to this issue would be to have a debconf
> question asking whether the user wants to enable system-wide
> debuginfod usage or not.
... this sounds like the bare minimum that would be acceptable.
Thanks,
Ian.
source packages which we in Debian don't use or ship. [3] They do
this for everyone's convenience and it causes no trouble. Until now :-/.
I hope my explanation is sufficient to get this package accepted.
Thanks,
Ian.
[1] I am replying here to ftpmaster comments on source packa
Frank's original reply didn't make it to the list for some reason and
has also gone missing on his end so resending on his request.
On Wed, 2021-02-24 at 15:23 -0500, Frank Ch. Eigler wrote:
---
Hi, Ian -
ijc wrote:
> [...]
> What are the security implications for users/clien
On Wed, 2021-02-24 at 16:58 +, Ian Campbell wrote:
Ugh, sorry, the quoting seems to have gone quite wrong there, let me
try again...
> On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
> Hello there,
>
> I would like to announce a new service that I have just conf
bling this transparently.
Thanks,
Ian.
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: cmake-format
Version : 0.6.10
Upstream Author : Josh Bialkowski
* URL : https://github.com/cheshirekow/cmake_format
* License : GPL-3
Programming Lang: Python
Description : source
hink are brought in by pydoctor...
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.
here.
Thanks to Anthony Fok for fixing pydoctor but the py2 rot seems wider
including in gbp itself.
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.
problem with epydoc should be easy if tedious to fix;
I don't understand why it wants epydoc which I thought was obsolete
but this is far from my field of expertise.)
Regards,
Ian.
pted. (I've never used it, just spotted the
reference from bts(1) when I went to check if it supported this sort of
thing).
Ian.
't feel the need to rebut it in detail in
this thread.
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.
reframes the debate
in such a way that only the status quo can even be expressed.
It was IMO completely appropriate for the Montreal team to make their
position, and their actual motives, clear.
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.
bugs "patch". That would increase the chances of
it appearing in the next upload.
If the maintainer is overworked, perhaps they would appreciate an NMU.
I haven't looked through the src:git bug list but perhaps there are
other bugs with patches that could be applied. I will leave
negotia
Ian Jackson writes ("Re: difficulty in understanding options in
init-system-GR"):
> Mo Zhou writes ("difficulty in understanding options in init-system-GR"):
> > I went through the options in the init-system-GR[1] but I feel difficult
> > to tell the subtle d
the appropriate mechanism for your usual build and upload tools.
Or you can just use dgit which gets this right automatically :-).
Ian.
[1] A workflow is possible where you use one git branch and just add a
new changelog entry for each upload. Although our data formats would
support uploads to a
n. If not, please let me
know...
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.
gregor herrmann writes ("Re: [RFC] Proposal for new source format"):
> On Thu, 31 Oct 2019 11:59:07 +, Ian Jackson wrote:
> > * tag2upload service, or some related service:
> > - determines that the maintainer is using a dgit-compatible git
> > workfl
, it is OK to work to make it
impossible to have this stuff in Debian, even if the software works" ?
And, are we going to continue to wear people down with awful threads
like this one, where a parade of doomsayers tell us we can't have what
we want *even though it already exists and
al-view-to-maintainer-MR gateway would already
be possible, and would work when the maintainer used dgit.)
Ian.
[1] IMO bugs are better for this because they provide a less bitty
conversational structure and are archived and published more usefully.
But it would be possible to handle thi
Russ Allbery writes ("Re: [RFC] Proposal for new source format"):
> Ian Jackson writes:
> > Of course this means that the resulting source packages are not the "3.0
> > (quilt)" patch queue source packages that many people (even some people
> > who like gi
g actually
looked at any affected source package.)
> @Andreas, can we add this point to science-team policy?
I will leave this to Andreas. But if Andreas and the science-team
agree with you, then this is clearly a candidate for a lintian
warning. You probably want to file a bug against lintian.
Pl
source packages are not the
"3.0 (quilt)" patch queue source packages that many people (even some
people who like git) say is important to them.
A key design goal for dgit and my tag2upload proposal, is that (when
used in the most usual way) it produces nice source packages like
everyo
ploader identify verification, even though from my point
of view that would be a redundant check. But it's simple to provide
the tag and there is some integrity improvement from doing so, so that
is what I am proposing.
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.
backwards-connection seems to be missing thus far, but I do find it
> important for the reasons above. Adding it would easily allow dak to
> validate the signature on the tag.
So, I'm not sure I understand what you think is missing.
Ian.
[1] I think with monorepo workflows the maint
ebpush and the tag2upload service
rather than by reinventing the rest of the machinery ?
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.
is done for you on the tag2upload
service, which of course has a fast network connection - and you don't
need to wait for it.
Ian.
[0] Currently, of course, this requirement is not achieved for
existing git based uploads. In practice, DDs use ad-hoc
git-buildpackage runes on their local mac
from ever being pushed again). The
server admin can also of course simply delete a package entirely.
So far this has not been necessary. I don't know how often a similar
situation has arisen with alioth and now salsa.
(I agree with everything else you wrote, too.)
Thanks,
Ian.
--
Ian Jac
really useable in the same way. I think the interface I designed and
which has subsequently been significantly improved, is a good one, and
we should continue to develop and enhance it.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @
all, namely --build=all ? (NB that does not
mean build all the things, it means build only "all" things.)
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.
Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
> On 19 September 2019 at 14:51, Ian Jackson wrote:
> | This would be a good idea. It is quite some effort but I think you
> | would be rewarded with
ules file would
> be a lot more readable if you'd dropped all the old commented out code
> in it.
I agree with this.
> (and then I think^wbelieve your arch-all problem could be solved by
> switching to dh style...)
This would be a good idea. It is quite some effort but I think you
Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> Ian Jackson writes:
>
> > Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or
> > MUSt NOT Github"):
> >> Unfortunately, I believe you are in the [wrong] w
Jim Popovitch writes ("Re: should Debian add itself to
https://python3statement.org ?"):
> On Thu, 2019-09-12 at 16:01 +0100, Ian Jackson wrote:
> > Drew Parsons writes ("should Debian add itself to
> > https://python3statement.org ?"):
> > > https:/
by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
thanks,
Ia
Enrico Zini writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote:
> > I think this does not demonstrate that I am wrong about project's
> > overall opinion about this. I am confident that
t the maintainer branch.
> (Using dgit to upload packages is sadly incompatible with best
> practices around packaging.)
Using dgit to upload packages is best practice.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a
tside our community, for example fields which refer to
upstream source management systems, may (in order to be accurate)
still need to refer to proprietary systems.
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.
uages
including, in particular, shell scripts. Any suggestions ?
Also there should be a registry document in some package somewhere,
which declares the format and lists the known config keys and their
semantics.
Thanks,
Ian.
PS Note that we are talking here about settings which relate to
per
unity is aware of them, but they do not rise to a level where
> they would challenge recommending Salsa.
>
> If you'd like to work on Salsa, including helping Salsa be more free,
> reach out to the Salsa admins and see if they can use your help.
I think that these objections do not rise to the level that we
shouldn't recommend Salsa to people who don't already have an opinion.
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.
ig.
If you could arrange to mirror your article on some Debian server that
would avoid possible future linkrot (although if you plan for your own
article to have a good longterm stable url then maybe that's not
needed).
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I
g to
this thread because of the principle of doing things in public.
Please be sure to CC me on the email. NB that do *not* intend to take
on the role of ongoing document editor and won't be incorporating
comments made in response to your mail.
Thanks,
Ian.
Changes content of binary packages: No ("C: N" on the wiki)
> Changes set of binary packages: Yes ("S: Y" on the wiki)
Your reasoning and conclusios make sense to me.
(FTAOD, I didn't reread the background materials but I found your
message admirably clear without needing to do that.)
Regards,
Ian.
upstreams expect us to do that work. (The same way we
expect our downstreams to file bugs, not expect us to guddle around in
their systems looking for stuff to take.)
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.
n git-buildpackage.
Oh, interesting. In that case Ted might find that using `dgit
push-source', `dgit sbuild' or `dgit pbuilder' work where `dgit
gbp-build' doesn't. That probably involves manually running
pristine-tar(1) (maybe origtargz would do it the right way?)
I
ng git workflow with a native source package format
should be universal, or even the default.
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.
> Are you planning to upload these?
Obviously not to Debian. I don't think that invalidates the point.
Users are supposed to be able to modify and build software on their
own systems without any expectation that the result will go to Debian.
Ian.
--
Ian JacksonThese opinions are m
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> > I think dgit ought to be compatible with the idea of shipping
> > upstream's .asc's about, but maybe there are bugs. I d
Ian Jackson writes ("Re: Git Packaging: Native source formats"):
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > Unlike 1.0 (non-native) vs. 3.0 (quilt), where some people prefer one and
> > some people prefer the other, I am not aware o
ts
reuse of version numbers, there is a corresponding exception for
packages which are still entirely in NEW.)
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: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> > If you already don't care about bit-identical upstream tarballs, then
> > dealing with these tarballs is a reasonably well-solved pro
has to have a -1 revision, or even that it must have a -1 or
-0.1 revision.
I think the practice of reusing version numbers for different packages
is confusing. It leads to mistakes, and should be deprecated.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an add
with this and it should
not be discouraged and doesn't merit a warning. (There is an
awkardness here in that you can sometimes unintentionally generate a
native format source package if your origs are missing...)
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.
the idea of shipping
upstream's .asc's about, but maybe there are bugs. I don't ever do
this so I don't know if it works and I doubt there are tests for it.
So, if you have a package where you want to use dgit push and you find
the upstream .asc is not being included, please fil
Holger Levsen writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> > In my proposal the source package is reproducible (in the
> > "reproducible builds" sense)
have to effectively have another
instance of the tag2upload infrastructure within it. Overall I don't
think this would make sense, even though it's possible.
I hope that clarifies things.
Thanks,
Ian.
[1] https://wiki.debian.org/GitPackagingSurvey
Not all of these are supported by tag
lds" sense) from the uploader's signed git tag. That
is admittedly less convenient to verify than the just checking the
.dsc 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.
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> I'm sure that Ian and Sean had been thinking about this before the
> DPL campaign. But I think in a very real sense, they took that
> discussion and tried to show us what it m
bout with tarballs etc.). Being able to do that would take
away large amounts of friction from many people's workflows.
That's one reason why I think this is important.
I have thought about these matters a lot and it is true that I am by
now convinced that this cannot be achieved other t
se some particular
.dsc; that's an output artefact. The uploader intends to release some
git commit.
So the .dsc should be traceable to that git commit. Currently it is
not. With my proposal the .dsc is traceable to the git history,
including the uploader's signed tag.
Ian.
--
Ian Jackson
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> Ian Jackson writes:
> > The mapping from git tag to .dsc is nontrivial. git tag to
> > .dsc construction (or verification) is complex and offers a
> > large attack surf
That private review resulted in
significant changes, notably the addition of privsep. (As a result,
that privsep is the substantial part which is not yet implemented.)
The review of my public v1 draft resulted in my proposals for
facilitating double checks by dak, and general improvements to
tra
1 - 100 of 2937 matches
Mail list logo
