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]

e 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 klaxon saying that's what's going to happen.

debvm for autopkgtests with multiple host?

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

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 > - apt-ma

Re: Multi-host networking software, autopkgtests

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 opinions are my own. Pronouns: the

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

d 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. -- Ian Jackson

Re: Multi-host networking software, autopkgtests

" 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: the

Multi-host networking software, autopkgtests

ges 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 emailed you from

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

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

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

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

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 opinions are my own. Pronouns:

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

o 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. Pronouns: they/he.

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

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 > > causi

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

ally 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-rooted, and not simply a lack of volunteers. Ian. -- Ian Jackso

Re: Half the world being removed

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

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

rch 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 JacksonThese

Re: secnet_0.6.2_multi.changes REJECTED

ch 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/~ianmdlvl/git?p=secnet.git;a=blob;f=argparse

Re: proposed MBF: packages still using source format 1.0

use 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

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

n 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 their targets, and changes to their targets.

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 ACCEPTed now.

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

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

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

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

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

Accepted dgit-test-dummy 1.30 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 13 Jan 2020 11:38:21 + Source: dgit-test-dummy Binary: dgit-test-dummy Architecture: source Version: 1.30 Distribution: experimental Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: dgit-test

Re: [debian] git depency on git-man

g the 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 negotiating

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 is a

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

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

Accepted pm-utils 1.4.1-19 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 14 Nov 2019 15:08:18 + Source: pm-utils Binary: pm-utils Architecture: source Version: 1.4.1-19 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: pm-utils - utilities

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 > > w

Re: Integration with systemd

pts, 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 is ma

Re: [RFC] Proposal for new source format

tem 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

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. Please keep

Re: [RFC] Proposal for new source format

ing 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)

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)

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 monorepo in its history, in a discoverable way, so doesn't have this i

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

oad 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)

ead 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

g 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 JacksonThese opinio

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]

amely --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 woul

Accepted dgit-test-dummy 1.29 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 15 Sep 2019 21:38:20 +0100 Source: dgit-test-dummy Binary: dgit-test-dummy Architecture: source Version: 1.29 Distribution: experimental Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: dgit-test

Accepted dgit 9.9 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Sep 2019 21:34:13 +0100 Source: dgit Binary: dgit git-debrebase git-debpush dgit-infrastructure Architecture: source Version: 9.9 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson

Accepted dgit-test-dummy 1.28 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Sep 2019 19:57:08 +0100 Source: dgit-test-dummy Binary: dgit-test-dummy Architecture: source Version: 1.28 Distribution: experimental Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: dgit-test

Accepted dgit-test-dummy 1.27 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Sep 2019 19:50:07 +0100 Source: dgit-test-dummy Binary: dgit-test-dummy Architecture: source Version: 1.27 Distribution: experimental Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: dgit-test

Accepted dgit-test-dummy 1.26 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Sep 2019 19:45:36 +0100 Source: dgit-test-dummy Binary: dgit-test-dummy Architecture: source Version: 1.26 Distribution: experimental Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: dgit-test

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 [wron

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 ?

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

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 a GR

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

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

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 opinions are my

Re: Git Packaging Round 2: When to Salsa

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.

Accepted dgit 9.8 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 06 Sep 2019 23:42:15 +0100 Source: dgit Binary: dgit git-debrebase git-debpush dgit-infrastructure Architecture: source Version: 9.8 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson

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

range 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 emailed you from an addr

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

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

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

dpackage. 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?) Ian. -- Ian JacksonThese op

Re: Git Packaging: Native source formats

ource 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]

g 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 my own. If I emailed you

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 don't ever do

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

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

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

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 address @fyvzl.net

Re: Git Packaging: Native source formats

t 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

tream'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 file bug(s). Thanks, Ian. -- Ian JacksonT

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

e 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

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

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 results of those conv

Re: tag2upload service architecture and risk assessment - draft v2

mportant. I have thought about these matters a lot and it is true that I am by now convinced that this cannot be achieved other than with something roughly like my approach. And I don't think it can be achieved without raising the same concerns as we see here. > I think I don't have a lot more

Re: tag2upload service architecture and risk assessment - draft v2

rticular .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 JacksonThese opinions are

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

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 traceability. Ian. -- Ian JacksonThese opinions are my own. If I email

Re: tag2upload service architecture and risk assessment - draft v2

n'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 out and then shouting at me. :-(. Ian. -- Ian Jackso

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 is an

Re: tag2upload service architecture and risk assessment - draft v2

atch 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

lows 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]

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, and will continue to argue, that there are good reasons to

Accepted vacation 3.3.3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Aug 2019 11:47:49 +0100 Source: vacation Binary: vacation Architecture: source Version: 3.3.3 Distribution: unstable Urgency: medium Maintainer: Phil Brooke Changed-By: Ian Jackson Description: vacation - email

tag2upload service architecture and risk assessment - draft v2

and 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?

g 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 Dublin so not got t

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 had occur

  1   2   3   4   5   6   7   8   9   10   >