Thanks for sqv in apt

ements most of the remaining architectural changes requested in Russ's security review of tag2upload: https://salsa.debian.org/dgit-team/dgit/-/merge_requests/86 I now expect these tests to complete many hours sooner. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

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

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

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

debvm for autopkgtests with multiple host?

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

Re: Multi-host networking software, autopkgtests

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

Re: Multi-host networking software, autopkgtests

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

Re: propose: provide "docker" package as docker, not wmdocker

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

Re: Multi-host networking software, autopkgtests

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.

Multi-host networking software, autopkgtests

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

, 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.

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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.

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Half the world being removed

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

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

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

Re: Half the world being removed

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.

mailman2-python3

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.

LTO and ABI compatibility

research papers with titles like "Towards a formal semantics for C", or indeed the absolutely hilarious discovery that the specification forgot to define the meaning of assigments when the assignment target was written in parentheses, and that no-one noticed this for decades. -- Ian Jackso

Re: secnet_0.6.2_multi.changes REJECTED

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

Re: proposed MBF: packages still using source format 1.0

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.

Re: proposed MBF: packages still using source format 1.0

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.

Re: proposed MBF: packages still using source format 1.0

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 >

Re: proposed MBF: packages still using source format 1.0

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

Re: proposed MBF: packages still using source format 1.0

where something that is representable in git is not > representable using 3.0 (quilt) but is representable using 1.0. I don't > have those cases to hand; Ian, could you summarise, please? Currently, I think diff cannot represent changes to symlinks. git can store symlinks and represent

Re: ftpmaster review reply Re: Comments regarding chroma_1.18-1_multi.changes

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

ftpmaster review reply Re: Comments regarding chroma_1.18-1_multi.changes

ECTed). [2] I have doubled checked this with Simon, the upstream author. [3] Should we DFSG-launder the Windows support out of our compiler source packages ? That sounds like fun. -- 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.

Re: git-buildpackage to be autoremoved due to python2 transition

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.

git-buildpackage to be autoremoved due to python2 transition

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.

bootstrap.min.js in pydoctor

For -devel, context is that Anthony Fok just uploaded a new upstream version of pydoctor (a tool for extracting API docs for python modules) in order to fix a couple of upstream bugs. Anthony, thank you very much for your work to help fix one of our (mutual) indirect dependencies. Unfortunately t

Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020

'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.

Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020

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.

Re: [debian] git depency on git-man

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

Re: difficulty in understanding options in init-system-GR

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

Re: d/changelog and experimental

multiple distros with a single changelog entry and even a single signed .changes, unfortunately our various tools and services don't. But writing an additional changelog is easy. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that

Re: difficulty in understanding options in init-system-GR

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.

Re: [RFC] Proposal for new source format

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

Re: Integration with systemd

, 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

Re: [RFC] Proposal for new source format

s via the hosting system MR conversation instead, or maybe mirror the conversation. -- 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: [RFC] Proposal for new source format

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

Re: MBF: don't build against libatlas3-base if possible

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

Re: [RFC] Proposal for new source format

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

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

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.

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

n you couldn't reconstruct the whole monorepo given just the canonical view. (Arguably this means that the .dsc representation of a source package from a git monorepo is not a PFM. See arguments on -legal and -project, passim. But the canonical view dgit branch does contain the whole of the monor

Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

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.

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

push' instead of `git tag' + `git push' but this is a thin wrapper around `git tag' and does not involve downloads or indeed any network activity, etc. -- 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: [RFC] Proposal for new source format

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

Re: Debian and our frenemies of containers and userland repos

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 @

Re: Possible doc package side-effect from going source-only upload [and 1 more messages]

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.

Re: Possible doc package side-effect from going source-only upload [and 1 more messages]

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

Re: Possible doc package side-effect from going source-only upload [and 1 more messages]

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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

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

Re: should Debian add itself to https://python3statement.org ?

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:/

Re: should Debian add itself to https://python3statement.org ?

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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

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

Re: Git Packaging Round 2: When to Salsa

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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

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.

Common configuration of Debianish build etc. tools

sonal preferences, or machine-local setup. Not ones which are properties of the package and which must therefore be done the same way by all of a package's maintainers - that latter information must be elsewhere (in the source package, recorded in salsa, or something.) -- Ian JacksonThese opini

Re: Git Packaging Round 2: When to Salsa

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.

Re: On the Removal of src:tensorflow [and 1 more messages]

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

Re: On the Removal of src:tensorflow [and 1 more messages]

Jonas Smedegaard writes ("Re: On the Removal of src:tensorflow"): > Please beware that there's a huge difference between being able to > stumble upon your notes in a web search - and in the case of a wiki page > to add additional notes to it - and then to have an open invitation to > ask questio

Re: Proposed build profile: noinsttests

Simon McVittie writes ("Proposed build profile: noinsttests"): > I would like to propose this build profile for addition to > . I'll add it to the wiki if > there seems to be rough consensus. > > Name: noinsttests > Changes content of binary packages: No (

Re: Git Packaging: Native source formats

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.

Re: Git Packaging: Native source formats

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

Re: Git Packaging: Native source formats

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.

Re: Git Packaging: Native source formats [and 1 more messages]

> 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

Re: Git Packaging: Native source formats

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

Re: Git Packaging: Native source formats

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

Re: Git Packaging: Native source formats

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.

Re: Git Packaging: Native source formats

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

Re: dput problem: Ancient sha256sum? [and 1 more messages]

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

Re: Git Packaging: Native source formats

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.

Re: Git Packaging: Native source formats

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

Re: tag2upload service architecture and risk assessment - draft v2

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)

Re: tag2upload service architecture and risk assessment - draft v2

2upload yet, but the most common ones are. The biggest one which is missing is the monorepos. They present additional difficulties because the maintainer tag name must include the package name, so can't conform to standard gbp or DEP-14 practice. -- 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: tag2upload service architecture and risk assessment - draft v2

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.

Re: tag2upload service architecture and risk assessment - draft v2

n. The DPL campaign discussions made it look like the time might be right. I had lots and lots of positive conversations in Curitiba. Generally people were super keen and ready with encouragement, detailed critical review, etc., according to their nature. My current proposal includes the result

Re: tag2upload service architecture and risk assessment - draft v2

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

Re: tag2upload service architecture and risk assessment - draft v2

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

Re: tag2upload service architecture and risk assessment - draft v2

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

Re: tag2upload service architecture and risk assessment - draft v2

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

Re: tag2upload service architecture and risk assessment - draft v2

cation. > I expect technical concerns don't weigh heavily when > you're on a moral crusade. Maybe you could assume good faith ? For example you could assume that I had missed something, as I said I might have done, rather than implying that I am deliberately missing things o

Re: tag2upload service architecture and risk assessment - draft v2

Ian Jackson writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > [stuff] Argh. A bunch of people helped me refine this but I sent an early draft by mistake. I guess it's too late to hope people will read only the better version, but here it

Re: tag2upload service architecture and risk assessment - draft v2

ag2upload is not done by src:dgit itself. In particular, much of the git patch queue manipulation is done using tools from src:git-buildpackage. 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: Consensus Call: Git Packaging Round 1

e age". And please avoid describing workflows as obsolete when there are people making cogent arguments why those established workflows are (at least in some respects) better than newer ones. 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: tag2upload service architecture and risk assessment - draft v2

Ian Jackson writes ("tag2upload service architecture and risk assessment - draft v2"): > Thanks for all the comments on the draft service architecture I posted > in late July. [1] I have made a v2, incorporating the various helpful > suggestions, and the information from the t

Re: Consensus Call: Git Packaging Round 1 [and 1 more messages]

t's on my list for discussion in round 3. I have carefully avoided any discussion of the merits in my message, and am happy to wait. Ian. [1] Both `dgit push-source' and `git debpush' publish your actual git history on the dgit git server in a form useful for users, so I have argued,

tag2upload service architecture and risk assessment - draft v2

the subsequent thread: https://lists.debian.org/debian-devel/2019/07/msg00501.html -- 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: Bits from the Release Team: ride like the wind, Bullseye!

DO list, except not at the top). I already made grep-excuses print this information. It has been very helpful to me. Maybe we should make --autopkgtests 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.

Re: Building GTK programs without installing systemd-sysv?

d of issues involving dbus-user-session seem common enough that it would probably be worth doing this as a workaround, if it would be effective. (Which it seems like it probably would be.) Adam, have you tested this (on both systemd and sysvinit systems) ? Thanks, Ian. (at the Worldcon in

Re: salsa.debian.org partially down

gregor herrmann writes ("Re: salsa.debian.org partially down"): > Ack. And that's all I wanted to say: that I found Ian's term "foolish > user action" inappropriate in this case of an accidental DOS. Err, yes. I retract that comment. I had misunderstood what

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

tever combination, 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.

Re: salsa.debian.org partially down

nd also offer guest accounts, 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 ad

Re: Please stop hating on sysvinit

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.

Re: duplicate popularity-contest ID

t non-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

Re: Bits from the Release Team: ride like the wind, Bullseye!

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 care

Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

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 https://tracker.debian.org/pkg/in

Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

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.

Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

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

  1   2   3   4   5   6   7   8   9   10   >