Bug#862051: Allow nodejs to provide /usr/bin/node (draft resolution)

Tollef Fog Heen writes ("Bug#862051: Allow nodejs to provide /usr/bin/node (draft resolution)"): > 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed. > > This means Debian's normal policies and practices take over and the > nodejs package is free to provide /usr/bin/node. The

Bug#877024: modemmanager should ask before messing with serial ports

Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing with serial ports"): > This is part of the discussion we had in the MM mailing list for such > a solution: > https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html Thanks, this looks

Bug#877024: modemmanager should ask before messing with serial ports

Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing with serial ports"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > This has gone far enough. I would like to remind you of Constitution > > 6.3(5) > > H

Bug#877024: modemmanager should ask before messing with serial ports

e to use a Debian channel for this. But I really appreciate you taking an interest. > An easier thing would be to allow just "dpkg -R > modemmanager", there should be no other package depending on the > daemon itself. That's no help because someone might have (for example)

Bug#877024: modemmanager should ask before messing with serial ports

Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing with serial ports"): > [Ian Jackson:] > > Many such modems present as USB serial devices, eg ttyACM or ttyUSB. > > Consequently, modemmanager has the ability to open serial ports

Bug#877024: modemmanager should ask before messing with serial ports

o consider whether to backport any of the resulting changes, or include them in stable updates of some kind. Thanks for your attention. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is

Bug#877024: modemmanager should ask before messing with serial ports

Ansgar Burchardt writes ("Bug#877024: modemmanager should ask before messing with serial ports"): > It's not useless. At least not when using UMTS via USB dongles which I > would guess more people use than ham radio. (Some of these USB dongles > also emulate network cards and provide a DHCP

Bug#877024: modemmanager should ask before messing with serial ports

Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing with serial ports"): > Yeah, I was just thinking that it would be easier to stop installing > support for modems by default than to actually fix modemmanager to > behave itself. It's certainly how I work -- apt remove

Bug#877024: modemmanager should ask before messing with serial ports

Keith Packard writes ("Bug#877024: modemmanager should ask before messing with serial ports"): > That requires fixing the package instead of just getting it out of the > way, a significantly harder thing to manage. This has gone far enough. I would like to remind you of Constitution 6.3(5) |

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium"): > I guess that one could do something like moving the symlink into another > -legasy style package, and recomend that from the main package for one > release to keep upgrades happy. Then drop the

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium"): > Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs > until it's no longer needed - be it other debian packages or other user > scripts. Earlier you said only "other Debian packages":

Re: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

here. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These 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.

Bug#877024: modemmanager should ask before messing with serial ports

seful for me to upload such a thing to experimental so others can try it too ? Would the Debian modemmanager maintainers object to that ? I will do that upload: to DELAYED, picking some suitably cautious version number, unless I hear to the contrary. (And I'll wait at least a week for a reply to thi

Bug#877024: modemmanager should ask before messing with serial ports

hinking. For upstream: things in "experimental" are not automatically installed on user systems (well, unless the user has been exceptionally foolish), and do not automatically propagate to places where they might be so installed (let alone, be released). Ian. -- Ian Jackson <ijack..

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

ons of politics: they concern the balance of competing interests, and the location and scope of power and control. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These 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.

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

t;several packages now require just systemd-sysv". Can someone refer to some examples, please ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These 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.

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

nse of knowledge or ownership that would be appropriate for that. > On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote: > > One question I have is about this: "several packages now require just > > systemd-sysv". Can someone refer to some examples, please ? >

Bug#881339: let's find a solution

ns the single sentence | it is strange that the package Build-Depends: on itself!? Lots of language compilers build-depend on themselves so surely there is more to this. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an

Re: TC nomination procedure v0

Wouter Verhelst writes ("Re: TC nomination procedure v0"): > It's a vote that will have effect on the appointment of a person to the > TC. The constitution specifically wants appointment votes to be public. > Without wanting to comment on the letter, I think this is contrary to > the intent. > >

Bug#877024: Modemmanager probing of unknown Devices

Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"): > I wanted to make you aware of a status update. > The maintainer who has been doing most of the uploads on modemmanager > stepped down after receiving my query. Oh. > As a matter of process, it's not clear that

Re: Bug#877024: Modemmanager probing of unknown Devices

his, > and I think we need some outside help deciding which of us is right. > I'm going to give you a bit of time in less I've got it all wrong and > you're OK with this approach and then I'm going to ask for help." Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> The

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee"): > I am discussing how we handle conflict because I hope we can do a better > job of helping people feel valued even when we do not agree with their > technical positions. You've

Re: Next Meeting: Wednesday, May 16th 19:00 UTC (today) - Currently no topics

Wouter Verhelst writes ("Re: Next Meeting: Wednesday, May 16th 19:00 UTC (today) - Currently no topics"): > On Wed, May 16, 2018 at 08:59:35PM +0200, Margarita Manterola wrote: > > As David mentioned in IRC and I mentioned in person to the people in > > Hamburg, it is a bit worrying to not have

Bug#877024: Modemmanager probing of unknown Devices

mostly if there is an objection about the principle of the approach that modemmanager should take, or an objection to NMUs, that a TC decision might be needed. Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net

Bug#877024: Modemmanager probing of unknown Devices

that I intended to escalate this issue to the TC: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#77 I got no response, so I filed #877024. When I did so, the BTS sent this mail CC the maintainers: From: ow...@bugs.debian.org (Debian Bug Tracking System) To: Ia

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

e Haskell binaries in stretch is an undocumented chain of recompilations of packages from snapshot.d.o. If we let Haskell do that, why are we being so hard on JavaScript ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

where possible, but that should be done by looking at which of the alternative build dependencies is installer, or whatever, not by checking dpkg-vendor. 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.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

her approaches will be better still. It just means that vendor series are worse than changing the source package. -- 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: Bug#904302: Whether vendor-specific patch series should be permitted in the archive

it certainly falls under at least one of §6.1.1 and §6.1.3, and not > §6.1.4. Obviously I agree with this. Thanks, Ian. [1] I don't read the delegation that way, but for this purpose the wording of the delegation doesn't matter. -- Ian JacksonThese opinions are my own. If I email

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

) might be needed in some exceptional cases but normally there is a better way. 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.

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

Philip Hands : > You'll be pleased to note that the original bug in this case has now > been closed as a result of a newly uploaded package version: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#101 > > Thanks to all involved for bringing this to a successful

Bug#877024: modemmanager should ask before messing with serial ports

Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before messing with serial ports"): > Ian, any comment about this 1.8-rc1 version with the filter policies > implemented? Thanks for the ping. I haven't had a chance to test it, but if it behaves as described earlier here then

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

Tollef Fog Heen writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > Second draft: ... > The Committee recognises that there is a need for packages to behave > differently when built on different distributions, but this should be > done by using

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

Philip Hands writes ("Re: Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > IMO policy should recomend the use of separate source packages as the > prefered solution to the problem that vendor-specific patch series were > supposed to address. That would be

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

t someone would disingenuously argue that a series.ubuntu file, in a package in Debian, is not "use" of the feature. 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.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote: > > IMO policy should recomend the use of separate source packages as the > > prefered solution to the problem that

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

it is wrong for your downstreams and users. We should be discouraging such tradeoffs. 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.

Bug#904558: What should happen when maintscripts fail to restart a service

hly what they do right now. The support for configuration in something like policy-rc.d has a few design decisions to be made but doesn't seem really difficult. Also nothing blocks on it. The TC would simply be saying "this would be a good thing to have". Ian. -- Ian JacksonThese

Bug#904302: That's a free software issue!

Anonymous writes ("Bug#904302: That's a free software issue!"): > If Debian want patches it has to support this process with tools. The > attitude Debian owns all source packages is wrong. Sharing source > packages among different vendors is more efficient. Different patch > series may be the best

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote: > > The Committee therefore resolves that: > > > > 1. Any use of dpkg's vendor-specific patch series feature is a bug

Bug#904558: What should happen when maintscripts fail to restart a service

Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail to restart a service"): > Ian Jackson wrote: > > When I wrote that, it didn't occur to me that anyone would think that > > a failure by a postinst script to perform an intended operation

Bug#904558: What should happen when maintscripts fail to restart a service

Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail to restart a service"): > Ian Jackson: > > There may be good reasons not to treat daemon startup failure as a > > postinst failure, but the argument above is not one of them. > > I thin

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > Possibly also with something like this?: > > Post-Buster this should be implemented in Debian Policy by > declaring that a package MUST NOT contain a non-default series >

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

binary package name /usr/bin/dune other than the C++ library dune-common or its friends. * Declare that the ocaml build system should choose a new source package name and use it henceforth. I am about to file an RC bug against the `dune' package, blocked by this one. Ian. -- Ian Jacks

Bug#919951: Request about the /usr/bin/dune filename

that the other project, whose name is being appropriated, should suffer any inconvenience. 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.

Bug#914897: debating the wrong thing

Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"): > Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr > systems would no longer be supported. In this case someone would have > to write a unusrmerge program to convert systems with merged-/usr to > systems

Bug#914897: debating the wrong thing

lly nasty. The problem comes when a niche optional feature, with wide-ranging implications, is suddenly promoted to the default, without proper consultation and without a proper transition plan. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @ev

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default"): > On 11/28/18 2:49 PM, Ian Jackson wrote: > > This is a special case of a general problem: buster systems with > > merged-/usr sometimes build packages which are br

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

e can have a proper conversation about what the plan ought to be for buster and bullseye. 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.

Bug#904558: What should happen when maintscripts fail to restart a service

herwise, I don't see any benefit > from postinst (particularly postinst + configure) ever failing. Frankly I'm disturbed to be reading this, here. See above. If the postinst fails, then the user has the opportunity to fix the root cause and rerun dpkg-source --configure --pending. That will then

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

stream build system, or perhaps horrific rules file bodges. Thanks, Ian. [1] Implicitly, without using a chroot. [2] IIRC some people suggested this explicitly in the thread in d-devel. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

Ping ? Is the TC engaged in this issue or should I seek another approach ? 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.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

sufficient breadth. 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.

That merged-usr is mandatory is RC

cohesion. CCing the TC FYI (they have already been involved in merged-usr debates via #914897) and the release team, in case they have an opinion. FAOD I am not a maintainer of base-files but AFAICT the base-files maintainer has not expressed an opinion about severity. Ian. -- Ian Jackson

Re: That merged-usr is mandatory is RC

(sending this because I got the release team address wrong) Ian Jackson writes ("That merged-usr is mandatory is RC"): > Control: severity -1 serious > > In #923091, Guillem (with dpkg maintainer hat on) asks for a > base-installer option to allow installing bus

Re: Thinking about Delegating Decisions about Policy

Ian. [1] I should say that I think the individual members of TC are and have been people of generally very high caliber. IMO the failings are emergent properties of the structure, context and framing. [2] Much of this is, I think, ultimately my fault. I invented this setup. All I can say is

Re: Thinking about Delegating Decisions about Policy

process is a creation of the policy editors, not of the DPL nor of the rest of the project. Ian. [1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html [2] https://en.wikipedia.org/wiki/Ultra_vires -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net

Re: Thinking about Delegating Decisions about Policy

ection is made which raises a substantial issue that ought to be dealt with. While vacillation is undesirable, making it easier and less socially costly to handle mistakes, will make it easier to make changes. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#934948: Unnecessary dependencies vs multiple binary packages

tical dependencies of less-critical subcomponents. devscripts is perhaps the best example. > * When a user installs a library for one interpreter or environment, > in general, we don't want the package dependencies to require that > user to install an unrelated interpreter. I think this de

Bug#932795: Ethics of FTBFS bug reporting

Simon McVittie writes ("Bug#932795: Ethics of FTBFS bug reporting"): > For the specific question of whether a single CPU core is a "reasonable" > build environment, my answer at the moment is "I don't know". There are two issues here: 1. "Is a 1-cpu system `reasonable' or `supported'" (or

Bug#932795: Ethics of FTBFS bug reporting

is reasonable but not supported. etc. On the point at issue, do these packages build in a cheap single-vcpu vm from some kind of cloud vm service ? ISTM that this is a much better argument than the one you made, if the premise is true. Ian. -- Ian JacksonThese opinions are my own.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

loping and integrating alternatives to both systemd and sysvinit. 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.

Bug#971515: Status as of last tech-ctte meeting

uot; and "just download that shit from the internet" approach is hideously bad engineering practice.) -- 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.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

errule a maintainer decision. Furthermore, the TC can clearly make its opinion known. My view is that the behaviour seen in #921012 and #964139 is an outrage which ought to result in DAM action. It would be open to the TC to make a statement strongly criticising the maintainer's behaviour and suggest

Bug#1007717: Native source package format with non-native version

ures here. Mandating *more* use of patches-and-tarballs is a step backwards. The .dsc source format (which I first invented in 1992 is now obsolete). We must maintain it for compatibility for a very long time, but almost everyone is already treating git as primary. But our git setups are not official, not coherently discoverable or useable. 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.

Native source package format with non-native version

filed against 1.0 with diff packages, at least without some further filter. -- 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.

Bug#1007717: Native source package format with non-native version

with git-based workflows. 5. Consequently, declare that the recent MBF on this topic ought not to have been filed against 1.0 with diff packages, at least without some further filter. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net

Bug#1007717: Native source package format with non-native version

er 6.1.4. Let me requote myself with annotations: > On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote: > > Please: > > > > Part I - belss continued use of 1.0 native format, for now at least: > > > > 1. Declare explicitly that there is nothing wrong with a pack

Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]

On the burden of proof and the correctness of software: I'm afraid I see a pattern, where blanket statements are made which are only "mostly" or "roughly" or "generally" true. But the discrepancies and details matter. When we make computer systems, it's not good enough to if they're only

Bug#1050001: Unwinding directory aliasing

Also, one other thing I noticed: tl;dr: *no* version of usrmerge relieves us of the obligation of naming files correctly, via the proper name in /usr rather than /. Ian Jackson writes ("Bug#1050001: Unwinding directory aliasing"): > The current plan, as I understand it, is tha

Bug#1050001: Unwinding directory aliasing

> the symlink-farm state, but then got stuck without a way to get from the > symlink farm to the single symbolic link. Do you have a plan for how that > would be achieved without breaking upgrades or going behind dpkg's back? As I say above, I don't think we should ever go to the state with

Bug#1050001: Unwinding the directory aliasing mistake

cussions tend to go that means that others will have to carry much of the more interactive load. I'll write more about the more technical / practical aspects of your mail at a later point. Thanks, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.n

Bug#1050001: Unwinding the directory aliasing mistake

Package: tech-ctte Background and current status In 2019 the TC decided[1] that Debian would achieve the largely-agreed goal of having only one place to put most files, /usr, by using symlinks to alias from /bin etc. to e.g. /usr/bin. At the time, concerns were raised that package management

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"): > On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote: > > And, the approach being taken very seriously privileges Debian itself, > > and those well-staffed derivatives able to do the necessar

Bug#1007717: Draft resolution for "Native source package format with non-native version"

e maintaining because our git transition is stalled.) 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.

Bug#1007717: Draft resolution for "Native source package format with non-native version"

master workflow I think even Lucas's incremental tarball proposal would be a retrograde step for them. 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.

Bug#1007717: Updated draft resolution

Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"): > Simon looked at how other distributions approach patches and figured > that basically everyone else uses the patches-unapplied model. patches-unapplied is a good fit for distro experts in distros which are still using

Bug#1007717: Draft resolution for "Native source package format with non-native version"

behaviour wrt scanning your ".." for stuff. The *format* of 1.0-with-diff is quite reasonable, but it lacks support more kinds of delta. That could be done as an extension to 1.0-with-diff, but I doubt that would be a popular direction. Ian. -- Ian JacksonThese opinions

Bug#1007717: Draft resolution for "Native source package format with non-native version"

ere which would suffice. Right now, though, it's a bit hard to make progress without feedback on what general direction would be most well received. 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.

Bug#1007717: Draft resolution for "Native source package format with non-native version"

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""): > On 11/05/22 at 17:29 +0100, Ian Jackson wrote: > > But I think that might not meet ftpmaster's review needs. AIUI > > ftpmast

<    4   5   6   7   8   9