Bug#976368: override: python2.7 and python-defaults binaries should be optional, not standard
control: tag -1 + moreinfo Hello, On Fri 04 Dec 2020 at 08:35AM +01, Matthias Klose wrote: > Package: ftp.debian.org > > python2.7 and python-defaults binaries should be optional, not standard. Just to be sure, do you mean all the binaries produced by these two source packages? -- Sean Whitton signature.asc Description: PGP signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
Hello, On Wed 16 Dec 2020 at 10:02AM -05, David Steele wrote: > Imagine that tdtcleanup is a pre/post hook in todo.txt-base. An > implementation of todo.txt is needed > to make use of it. Okay, and you expect every implementation of todo.txt to have tdtcleanup? I think we probably want to specify that as one of the (or the only?) requirements of the virtual package. -- Sean Whitton signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote: > Sean and Simon, > > On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote: >> > In the cases where the regression was accidental, ideally, the answer >> > would be someone calmly and politely offering a tested patch, but it >> > sadly seems equally likely to result in hostility, and I think it's >> > reasonable for a maintainer to try to avoid that preemptively by making >> > it clear that the LSB init script is someone else's responsibility. >> > Our volunteers are not automata, and I think maintainers need to be able >> > to set boundaries for their responsibilities to protect their mental state. >> > >> > Similarly, in the case where the dependency is deliberate, I don't >> > think we want the responsibilities of a Debian maintainer to include >> > interceding between angry sysvinit users and upstream. >> >> Okay, great, I now see a clearer argument in favour of dropping the init >> script: enabling the maintainer to preemptively avoid dealing with bugs >> which are likely to generate hostility, rather than just the idea that >> there could be bugs which would generate a lot of technical work for the >> maintainer in which the maintainer does not see much value. > > I am afraid I don't agree with this. > > Hostility is never justified or justifiable and none of us should ever have > to be > subject to it or tolerate it. However, using the avoidance of putative poor > behaviour by others in the future as a justification for a current or past > action > seems a weak argument to me. IMO, the best way to promote the ideals of > tolerance, courtesy, humility and openness is by espousing them in one's > actions > and by doing the right thing. It would not be good to assume that there are never circumstances in which preemptively avoiding hostility by refusing to engage with certain technical options is a reasonable thing for a maintainer to do, but whether it is something the project can accept in this particular case is still in question. -- Sean Whitton signature.asc Description: PGP signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
Hello, On Mon 14 Dec 2020 at 05:29PM -05, David Steele wrote: > On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton > wrote: > >> >> >> Putting aside the use of the alternatives system, why is a virtual >> package wanted? When would it be useful to be able to declare a >> dependency and have it satisfied by one of these implementations? >> >> > As an example, a future rev of an integrated todo.txt-gtd[1] would depend > on that virtual package. Why would that be useful? -- Sean Whitton signature.asc Description: PGP signature
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hello, On Tue 15 Dec 2020 at 06:02PM +01, Oxan van Leeuwen wrote: > Hi, > > On 14-12-2020 22:43, Sean Whitton wrote: >> On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: >>> 'not fail' here means that the script terminates with return code 0. >> >> This is how I would read it too. Would a patch to add "(i.e. exit with >> return code 0)" resolve the original submitter's concerns? > > Though I'm still not convinced it's a sensible requirement, that > clarification would resolve my main concern (i.e. having to fix init > scripts to work with an absent defaults file). By the way, there's an > identical requirement a few paragraphs before, so it might be good to > insert the same clarification there as well. Okay, cool. Patches welcome! -- Sean Whitton signature.asc Description: PGP signature
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
Hello Ansgar, On Tue 24 Nov 2020 at 01:37PM +01, Ansgar wrote: > Package: debian-policy > Version: 4.5.1.0 > Severity: normal > > After a discussion in #-devel today I reviewed packages using other > choices of "Rules-Requires-Root" than "no" and "binary-targets". The > query [1] found two uses: > > - wfrench 1.2.6-1. This could just use "no"; a bug was filed[2]. > > - libcap2 1:2.44-1. Uses it for running tests as root, but doesn't support > fakeroot anyway. Rules-Requires-Root can't however communicate this so > additional knowledge is needed. > > The complexity to support arbitrary additional keywords as choices of > R³ seems overkill given there is just one real user (libcap2) and the > current R³ specification doesn't handle that usecase fully either. > > Therefore I suggest to deprecate using R³ values other than "no" and > "binary-targets" within Debian. > > (Unrelated: R³: no should probably be recommended.) We would definitely need input from the designers of the R³ system before removing anything (to my knowledge, the design was led by Niels and Guillem). They were designing for the very long term, so I don't think we can safely infer much from the present contents of the archive. I'm also not really convinced by your arguments that having these other possible values adds much of a burden. This is not about code which has to be updated, just text. We do not expect newcomers to imbibe everything in Policy. -- Sean Whitton signature.asc Description: PGP signature
Bug#975250: clarify gathering together of copyright information
Hello Sam, On Tue 01 Dec 2020 at 08:07AM -05, Sam Hartman wrote: > * Sean would prefer that you not be able to collapse years. He hasn't > said whether his objection is strong enough to try and block > consensus. My initial comments were motivated by the very same concerns as Russ: On Sat 21 Nov 2020 at 12:30PM -08, Russ Allbery wrote: > In reality, this only matters because we have licenses that say it > matters. For example, the BSD license saying: > > 1. Redistributions of source code must retain the above copyright >notice, this list of conditions and the following disclaimer. > > We're already arguably not *quite* following that rule by allowing > coalescing of notices. I think that's fine because (at least in US law) > the copyright notice is soemthing with a legal definition and the > coalesced form is legally equivalent, so we're preserving the notice in > the way that matters. But in order to rely on that argument, it feels > like we should keep the notice legally equivalent, which would mean not > adding years. If there is a consensus within the FTP Team that collapsing years does not violate this sort of condition in the text of licenses, then (qua Policy Editor) I would be happy to permit collapsing years. I have made some enquiries to try to determine whether the FTP Team has a consensus view on this. If the FTP Team is not really sure whether this sort of thing is okay, we could permit collapsing years just when the license does not have a copyright notice reproduction requirement (see the changes in #955005 for another example of making Policy copyright notice requirements conditional on particular licenses). -- Sean Whitton signature.asc Description: PGP signature
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hello, On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: > On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote: >> Source: debian-policy >> Version: 4.5.1.0 >> Severity: normal >> >> Currently Policy requires that init.d scripts, and only init.d scripts, don't >> fail if the corresponding /etc/default is removed (section 9.3.2, >> second-to-last >> paragraph). >> >> Personally I interpret "not fail" as "succeed to function", i.e. it has to >> actually start the daemon. I don't think that's a particularly sensible >> requirement. > > 'not fail' here means that the script terminates with return code 0. This is how I would read it too. Would a patch to add "(i.e. exit with return code 0)" resolve the original submitter's concerns? -- Sean Whitton signature.asc Description: PGP signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
Hello, On Mon 14 Dec 2020 at 09:35AM -05, Dave Steele wrote: > Update. No todo, and suggest the following for todo.txt text: > > command-line task management utility compatible with todo.txt CLI ( > http://todotxt.org) Could you provide an actual patch against policy.git, please, for seconding? See README.md in policy.git for more info. -- Sean Whitton signature.asc Description: PGP signature
Bug#922744: don't compress debug sections by default
Hello Matthias, On Wed 20 Feb 2019 at 09:34AM +01, Matthias Klose wrote: > Package: debhelper > Version: 12.1 > Severity: important > Tags: sid buster > > afaics this change was made in > > debhelper (9.20150811) unstable; urgency=medium > > * dh_strip: Always compress debug sections of debug symbols > in ddebs. > > What was the reason for enabling this? The only savings I can see is some > on-disk space savings when doing the debugging. The packages itself are > compressed anyway. Otoh there are still tools outside which cannot handle > compressed debug sections, and Debian seems to be the only distro turning on > these compressions by default. Just stumbled about that when looking at a > binutils issue which fixes the alignment for compressed debug sections (PR > binutils/23919. Could you substantiate the concern about tooling issues, please? On the other side of this dispute, in #631985, there is a concrete example of how someone's life is made easier by having the compression turned on, but on the other side things are less substantiated. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
control: tag -1 + moreinfo Hello David, On Fri 04 Dec 2020 at 12:15PM -05, David Steele wrote: > I'd like to propose adding the virtual packages "todo" and "todo.txt" to > the authoritative list of virtual package names. I'm submitting this per > Policy section 3.6 and the preamble to the [authoritative list]. > > [Todo.txt] describes an ecosystem of task management tools that revolve > around a standard for a freeform-text tasking file. > > The reference cli has been packaged for some time, as "todotxt-cli". It > provides the executable "todo-txt". > > An alternative cli provider, "topydo", has been recently added, adding > an executable by the same name. > > I propose uniting this packages using the name "todo" - the common name > for the utility. Since not all todo list packages that may want to share > that name conform to the todo.txt standards, I also propose "todo.txt", > a strict subset of "todo", for packages which conform. Putting aside the use of the alternatives system, why is a virtual package wanted? When would it be useful to be able to declare a dependency and have it satisfied by one of these implementations? So far this does not seem anything like, e.g., wanting to declare a dependency on having the ability to programmatically send e-mail. -- Sean Whitton signature.asc Description: PGP signature
Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
Hello Niels, On Sat 05 Dec 2020 at 01:12PM +01, Niels Thykier wrote: > The underlying arguments for and against --compress-debug-section appear > to be "download size" vs. "installed disk usage" vs. "Tooling support". > Though I ask you to please read the bugs #631985 and #922744 for the > details of the arguments by both proponents. Just had a look a these, thank you. ISTM that the arguments in favour of compressing are more concrete right now: in #631985 there is the example of debugging KDE requiring more than 10G of disc space. (Nine years later perhaps it is more.) On the other hand, in #922744, there is only an unsubstantiated reference to tooling support. I'm going to write to the submitter of #922744 asking for more info. > Why punt it to you? > === > > [...] I think the reasons you give are all reasonable. -- Sean Whitton signature.asc Description: PGP signature
Bug#975381: Subject: libinih: drop Debian's custom vendorisation
control: tag -1 + moreinfo Dear Stephan, On Sat 21 Nov 2020 at 12:20PM GMT, Stephan Lachnit wrote: > Currently the package libinih uses some heavy patches, which aren't upstream > and aren't used by any other distro. I'm in favor of dropping this, but the > current maintainer disagrees and we weren't able to make any progess in the > discussion, so I want to put this here. Parts of the discussion can be found > on > this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2 > > To understand this, one has to look a bit at the history behind inih. Upstream > was designed as a static library for embedded devices, and therefore has a lot > of compile time options. At this point, the current maintainer created a patch > to make all compile time option available on runtime. > > When gamemode started using inih, I wanted to get rid of shipped inih code and > upstreamed a build system to inih for a shared library, that any distro can > use. This was done in version 48. Due to the popularity of gamemode, inih is > now found in most major distros (all without Debian's patches): > https://repology.org/project/inih/versions > > There is a notable "exception": inih is not in Ubuntu's main repository. This > is a bit weird because gamemode is in main, but with the shipped inih source > which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm > not sure why, but I suspect the heavy patches make it harder to be included in > main. > > Because the library was designed for embedded use cases where every little bit > of performance matters, the runtime patch was refused upstream. Dropping the > runtime patch from Debian actually isn't problem, no reverse dependency of > libinih uses compile time options anyway. However, due to the history of inih > in Debian is has the soversion 1, while upstream is soversion 0. > > I want to drop the vendorisation of Debian and start a transition to soversion > 0 (which is also a reason I contact the Technical Committee, as it's not clear > how this would be done). A transition is needed anyway since dropping the > patch > is a breaking change anyway. If the Technical Committee agrees to this, I > would > also gladly help to maintain this package since it is 2 version behind > upstream > since almost half a year and I maintain gamemode, which is directly affected > by > this. Your message it not clear enough for TC members not familiar with the packages in question to understand what the dispute is. We cannot wade through discussions on salsa -- we need a summary. Please make another attempt at summarising the dispute. Please also indicate which of the TC's powers (as granted by the constitution) you are asking us to make use of. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote: > On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote: > >> Participants in the thread who have argued on that side of the >> discussion seem to implicitly rely on the idea that a package maintainer >> is responsible for applying an equally high level of quality assurance >> to every file or feature in their package, as that which they would >> apply to its most basic or flagship features. > > Ordinarily, perhaps yes. However, for whatever reason, people are > particularly emotionally attached to particular init systems (or perhaps > to the absence of systemd). We can see this here already: I don't think a > dependency on a particular httpd or email server would have been brought > to the technical committee asking for a maintainer to be overruled, > and it seems unlikely to have had participants describing a maintainer > declining an NMU as an outrage. > > If NM's LSB init script was present, but stopped working - perhaps > because upstream deliberately made more use of systemd facilities, or > because upstream accidentally relied on systemd facilities due to none of > the upstream developers using anything else, or because the command-line > syntax changed and the upstream-provided systemd unit was updated but the > downstream init script wasn't - what do we expect to happen? > > In the cases where the regression was accidental, ideally, the answer > would be someone calmly and politely offering a tested patch, but it > sadly seems equally likely to result in hostility, and I think it's > reasonable for a maintainer to try to avoid that preemptively by making > it clear that the LSB init script is someone else's responsibility. > Our volunteers are not automata, and I think maintainers need to be able > to set boundaries for their responsibilities to protect their mental state. > > Similarly, in the case where the dependency is deliberate, I don't > think we want the responsibilities of a Debian maintainer to include > interceding between angry sysvinit users and upstream. Okay, great, I now see a clearer argument in favour of dropping the init script: enabling the maintainer to preemptively avoid dealing with bugs which are likely to generate hostility, rather than just the idea that there could be bugs which would generate a lot of technical work for the maintainer in which the maintainer does not see much value. It is difficult to think further about this without input from the maintainer as to how much this was a part of his motivation, and what experiences he has had led him to think in that way. >> We want maintainers to >> perform testing which is adequate to ensure that the core features of a >> package won't regress if they upload a new version, but we do not take >> maintainers to be responsible for testing every optional feature and we >> accept that such things might be temporarily broken until someone other >> than the maintainer can provide a patch. > > I think perhaps you have higher expectations of bug reporters than I do > - perhaps because I'm involved in triaging/maintenance for user-facing > desktop packages. Bug reports are not always accompanied by patches, > and somewhat frequently come with the implication (or even an explicit > demand) that the maintainer must stop whatever it is they are doing and > fix the bug immediately. Let me clarify the things I've said about the expectations we have of maintainers on this point. I don't think we do or should expect anything at all of maintainers with regard to bugs that do not come with patches, or that come with patches for which there is little indication that much thought or testing has gone into them. > In the case of init system integration, it isn't completely clear what > the severity of "NM doesn't work with sysvinit" would be, and proponents > of sysvinit might argue for critical because losing network connectivity > effectively breaks the whole system in some cases, or serious because > the package should be able to work without its non-mandatory dependencies. > RC bugs are one of the few places where the project puts specific > expectations on maintainers. > > Conversely, there's also a reasonable argument for important, normal > or wishlist, because sysvinit is one of multiple options - but getting > into an argument over bug severity is still getting into an argument, > and for developers who don't enjoy conflict, takes significant "spoons" > to deal with. Good point. Poor quality bug reports can be pretty easily ignored, but we don't have a comparable approach for maintainers to take with regard to severity wars. >> We do not expect maintainers to maintain >> an environment to test their package on
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello Simon and others, On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote: > If we are unable to use particular system services (in this case NM) with > a particular non-default init system without putting extra responsibility > on the maintainers of those system services, then I think that's a > limitation of that init system that its maintainers could usefully > address, and addressing that limitation would certainly be within the > scope of exploring alternatives to systemd. This is a good way to understand the notion of "exploring alternatives to" systemd. Thank you for explaining it. I have not yet seen an argument which convinced me that asking the NM maintainer to keep the init script in the package would actually be putting extra responsibility on that maintainer, and this concerns me. Participants in the thread who have argued on that side of the discussion seem to implicitly rely on the idea that a package maintainer is responsible for applying an equally high level of quality assurance to every file or feature in their package, as that which they would apply to its most basic or flagship features. For example, it's been suggested that requiring the NM maintainer to keep the file in the package would mean that the NM maintainer would need to keep a sysvinit system around to test that the init script still works before they could upload a new version of NM. I don't see why there would be any such need. Indeed, I don't think this is how we typically think of the responsibilities of Debian package maintainers. We want maintainers to perform testing which is adequate to ensure that the core features of a package won't regress if they upload a new version, but we do not take maintainers to be responsible for testing every optional feature and we accept that such things might be temporarily broken until someone other than the maintainer can provide a patch. In this case, I don't see how keeping the init script in the package creates any expectations on the NM maintainer beyond applying patches to the init script from those who have the relevant specialised knowledge. A good analogy would be ports. We do not expect maintainers to maintain an environment to test their package on ports architectures before uploading, but we do expect them to apply patches provided by porters who discover regressions. Why would our expectations be any greater in this case? Of course, if the script became seriously broken and was getting in the way of a release or something like that, we would typically see it as within the maintainer's prerogative to remove it. Just as we would accept a maintainer breaking compatibility with a port by reverting a porter's patch if that was the only feasible way to meet a freeze deadline, say. But as has been pointed out, that's not the case we are dealing with here. I would like to see arguments that we would be imposing any extra responsibility on the NM maintainer which do not rely on the idea that a package maintainer is equally responsible for regressions anywhere in their package, or, of course, an argument that I'm misunderstanding what's being implicitly assumed. The dependency issue is more challenging. -- Sean Whitton signature.asc Description: PGP signature
Bug#975250: clarify gathering together of copyright information
Hello, Thanks for the patch. On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote: > +Copyright field. It is ok to have years > +covered that are not listed in the original notices. I don't think we can assume it is okay to do this. You can combine 2009--2015 and 2020 into just 2009--2015, but I don't think we should encourage combining 2009--2011 and 2013 into 2009--2013. -- Sean Whitton signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > First, as a point of order (for which some authoritative guidance from > the Secretary, CCed, would potentially prove useful): while the > technical committee is empowered to handle various types of disputes (up > to and including overruling an individual developer if necessary), I do > not believe it falls within the scope of the technical committee to > override a decision already decided by a project-wide GR, or to > "interpret" the text of a GR issuing a nontechnical policy document in > ways that may undermine the decision made in that GR and document. Any > interpretation of the text of the GR would need to be based on the text > and intent of the GR. (Intent could include discussion at the time, but > would notably include the text of other options that did not prevail, as > well as the status quo at the time that motivated a GR to change.) > Changing that intent would require either another GR, or (per specific > provisions included in the winning GR option) consensus among the > project, not a TC ruling. > > Concretely, the GR explicitly acted by "Using its power under > Constitution section 4.1 (5)", which is the power to "Issue, supersede > and withdraw nontechnical policy documents and statements.". The > Technical Committee does not have such "nontechnical policy documents > and statements" within its ambit. Any interpretation of 'what it means > to "support the efforts of developers" working on support for > alternative init systems' would thus be an interpretation of such a > nontechnical policy document. > > Thus, I would suggest that the technical committee should decline to > rule on any matters already decided by the GR. This does not preclude > the TC from offering advice, or potentially facilitating dispute > resolution if asked to do so, or even as a *last resort* overruling a > developer on a specific technical matter (if doing so does not go > against the GR), but I don't believe it's within the scope of the TC to > relitigate the GR to mandate support for alternative init systems. Any > potential ruling here would need to avoid attempting to supersede the > GR. I have been thinking about this procedural issue and in the end I think that it is moot. Let me explain how things seem to me. In our dispute resolution role, the TC is empowered to decide upon the two things about the contents of the network-manager package that we have been asked to decide upon, as a matter of last resort. No-one disputes that we can do this. We have also been invited to rule that "Similar init-compatibility changes should not be blocked by package maintainers unless they are defective on their own merits". Essentially we are being invited to generalise the decision that we make about the network-manager package to say that it would apply to similar cases. We might decide that the reasons we have for whatever decision we make about the network-manager package do not generalise, and so we may decline the invitation to make any more general ruling. But if we do think the reasons generalise, then we can generalise our ruling without stepping outside of our dispute resolution role. For example, we might say "if another CTTE bug was filed about the contents of a package which was similar to this one in the following respects ... then we would expect to issue the same ruling as we have here, because we believe that our reasons for this ruling would apply to all packages which are similar in the previously stated respects." Clearly we would not want to say anything which we thought contravened the GR. However, I do not think there is any reason to think that resolving this dispute would necessarily involve the TC interacting with the GR in a way that the constitution does not permit. We are being asked to decide about one package, and being invited to generalise in a way that falls within the scope of our dispute resolution role. -- Sean Whitton
Bug#975250: clarify gathering together of copyright information
Hello, On Thu 19 Nov 2020 at 05:07PM +01, Marc Haber wrote: > /usr/share/doc/debian-policy/copyright-format-1.0.txt.gz says > > |The Copyright field collects all relevant copyright notices for the files > |of this paragraph. Not all copyright notices may apply to every > individual > |file, and years of publication for one copyright holder may be gathered > |together. For example, if file A has: > | > | Copyright 2008 John Smith > | Copyright 2009 Angela Watts > | > |and file B has: > | > | Copyright 2010 Angela Watts > | > |a single paragraph may still be used for both files. The Copyright field > |for that paragraph would contain: > | > | Copyright 2008 John Smith > | Copyright 2009, 2010 Angela Watts > > But what if file A says > > | Copyright 2008 John Smith > | Copyright 2005-2015 Angela Watts > > and file B has: > > | Copyright 2010 Angela Watts > > Can this be gathered together to: > > | Copyright 2008 John Smith > | Copyright 2005-2015 Angela Watts > > or does it have to be > > | Copyright 2008 John Smith > | Copyright 2009, 2005-2015 Angela Watts > > ? The former. If you'd like to propose a patch making this clearer we could get it applied. -- Sean Whitton
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > I'd also like to address one other issue here. It would be easy to > hypothesize, at this point, that some additional communication (or more > verbose communication) from the maintainer might have helped here. > However, I would express doubt that any more verbose version of "no" > (e.g. a long-form explanation about undesired additional maintenance > burden) would have led to any less escalation. I think the situation > would still have ended up here, no matter how much time or energy was > expended in writing responses. > > That seems particularly likely given the adversarial NMU directly > attempting to override an active package maintainer's decision, which > escalated the situation further. (Such adversarial NMUs have occurred in > regard to alternative init support in the past, as well.) And I don't > think anyone can reasonably suggest that they thought the change was > made unintentionally (given that it was explicitly mentioned in the > changelog), which makes the NMU a rather hostile escalation. > > I would ask anyone on the TC who feels that more verbose answers were > desirable whether they think a more verbose answer would have had any > effect on the outcome or subsequent escalations. Assuming for a moment that the TC does not decline to rule, it is going to be very hard for us to make a good decision if we lack more detailed input from the package maintainer. We can speculate as to whether the dispute would have proceeded better or worse with more verbose messages from Michael before now, but it would be beside the point. -- Sean Whitton
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > I'd also like to address one other issue here. It would be easy to > hypothesize, at this point, that some additional communication (or more > verbose communication) from the maintainer might have helped here. > However, I would express doubt that any more verbose version of "no" > (e.g. a long-form explanation about undesired additional maintenance > burden) would have led to any less escalation. I think the situation > would still have ended up here, no matter how much time or energy was > expended in writing responses. > > That seems particularly likely given the adversarial NMU directly > attempting to override an active package maintainer's decision, which > escalated the situation further. (Such adversarial NMUs have occurred in > regard to alternative init support in the past, as well.) And I don't > think anyone can reasonably suggest that they thought the change was > made unintentionally (given that it was explicitly mentioned in the > changelog), which makes the NMU a rather hostile escalation. > > I would ask anyone on the TC who feels that more verbose answers were > desirable whether they think a more verbose answer would have had any > effect on the outcome or subsequent escalations. Assuming for a moment that the TC does not decline to rule, it is going to be very hard for us to make a good decision if we lack more detailed input from the package maintainer. We can speculate as to whether the dispute would have proceeded better or worse with more verbose messages from Michael before now, but it would be beside the point. -- Sean Whitton signature.asc Description: PGP signature
Bug#971515: Status as of last tech-ctte meeting
Hello all, On Wed 18 Nov 2020 at 11:36AM -06, Gunnar Wolf wrote: > So... It's not like we reached a conclusion, but I do feel the meeting > was interesting and the discussion very much worthy. Yes, this will > surely end up in reinforcing the notion that the Technical Committee > is a slow and bureaucratic beast :-) But... well, I'll stop > apologizing. Only some minutes to go before the meeting, and I want to > give the rest of the Committee the opportunity to check if I didn't > misrepresent them or skip too much of their opinion. Thank you for this summary. At today's meeting one point which we thought was missing from this summary was that no-one on the committee has any appetite for overruling the package maintainer, so it is very unlikely that will be the outcome of this bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#954794: New packages must not declare themselves Essential
Hello, On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote: > On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote: >> Could I ask you to explain your wanting to reduce the Essential set for >> the sake of small installation size in more detail, including some >> numbers, please? It would be good to get to the bottom of Bill's worry >> about this change, but in addition, I would like to see a stronger >> positive case. > > I'm not sure about Josh, but I think the main reasons for wanting to > reduce the essential set are: > > - Making chroots/containers slimmer, which can have a substantial > impact when needing lots of them, where even few MiB can make a > difference. > - Making bootstrapping (build and installation) in general easier, > even though for the former these packages also need to then > be ideally removed from the build-essential set too. Thank you for this, but I was hoping for some more specifics. For example, what are some examples of large Essential: yes packages that might actually, in practice, be removable? -- Sean Whitton signature.asc Description: PGP signature
Bug#971023: Version field (5.6.12) and colons
control: tag -1 + pending Hello, On Mon 09 Nov 2020 at 12:12PM +01, Mattia Rizzolo wrote: > On Sat, Nov 07, 2020 at 01:01:28PM -0700, Sean Whitton wrote: >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >> index 0d7a3e9..a21a510 100644 >> --- a/policy/ch-controlfields.rst >> +++ b/policy/ch-controlfields.rst >> @@ -552,8 +552,7 @@ The three components here are: >> >> ``epoch`` >> This is a single (generally small) unsigned integer. It may be >> -omitted, in which case zero is assumed. If it is omitted then the >> -``upstream_version`` may not contain any colons. >> +omitted, in which case zero is assumed. >> >> Epochs can help when the upstream version numbering scheme >> changes, but they must be used with care. You should not change > > I don't consider this a normative change tbh (after the previous change > already forbidding multiple colons). > If it's really needed, consider it seconded by me. I see what you mean, but typically we ask for seconds for clarifications to previous normative changes, just in case someone has a different normative interpretation of the clarification. Anyway, thanks for reviewing. -- Sean Whitton signature.asc Description: PGP signature
Bug#973881: Result of 'git debrebase make-patches' with 'diff.noprefix' git config confuses dgit
Hello, On Fri 06 Nov 2020 at 03:19PM +01, Didier 'OdyX' Raboud wrote: > Package: git-debrebase > Version: 9.12 > Severity: normal > > Hello there, > > after toggling a git diff option globally with: > git config --global diff.noprefix true > > I noticed that dgit (at least build-source, but others too) started to fail > comparing patches-applied with patches-unapplied trees. > > I'm reporting this against git debrebase, because it seems to me that git > debrebase ought to always format patches in a known-to-work format, no matter > what the user has configured for his personal git usage. Could you provide steps to reproduce, please? If you could give us a particular commit hash to check out of a repository somewhere to start with, that would be good. -- Sean Whitton signature.asc Description: PGP signature
Bug#954794: New packages must not declare themselves Essential
control: retitle -1 Permit packages to declare dependencies on Essential packages Hello Josh, On Sat 17 Oct 2020 at 04:49PM -07, Josh Triplett wrote: > On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote: >> >> More specifically, it's the right first three steps. >> >> https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies >> currently says >> >> Packages are not required to declare any dependencies they >> have on other packages which are marked Essential (see below), >> and should not do so unless they depend on a particular >> version of that package.[4] >> >> [4] [...] If packages add unnecessary dependencies on packages >> in this set, the chances that there will be an unresolvable >> dependency loop caused by forcing these Essential packages to >> be configured first before they need to be is greatly >> increased. >> >> I'd propose that as a first step we change that to >> >> Packages are not required to declare any dependencies they >> have on other packages which are marked Essential (see below), >> but are permitted to do so even if they do not depend on a >> particular version of that package.[4] >> >> [4] Functionality is rarely ever removed from the Essential >> set, but packages have been removed from the Essential set >> when the functionality moved to a different package. So when >> depending on these packages for such functionality, it is >> recommended to depend on an appropriate virtual package >> instead. >> >> Future versions of Debian policy may encourage and then >> require including explicit dependencies even for essential >> functionality. This is helpful to users putting together >> ultra-minimal systems (though Debian does not support omitting >> Essential functionality out of the box), and it means less >> work is required in case the moment comes to remove some >> functionality from the Essential set in the future. >> >> (The next two steps would be to change that from "are permitted" to >> "should", and then to "must".) >> >> What do you think? > > That sounds great to me. This would mean that there'd be no policy > violation involved if someone wanted to send out patches working towards > making a package non-Essential. It's a good incremental step. Could I ask you to explain your wanting to reduce the Essential set for the sake of small installation size in more detail, including some numbers, please? It would be good to get to the bottom of Bill's worry about this change, but in addition, I would like to see a stronger positive case. As someone who is not concerned about small installation size, I rather enjoy how the functionality of the Essential set isn't likely to be reduced any time soon. As an example, I understand that RedHat systems aren't guaranteed to have Perl on them anymore; I appreciate how when I'm working with Debian systems, I know I'm not going to have to spend time improving my knowledge of awk, and anyway having to use a tool which I think is worse. I don't mean to suggest that this usecase of mine is decisive, but it illustrates that the benefits of keeping Essential as it is are clear, whereas the benefits of reducing Essential are, currently, vague. Could we actually decrease installation size in a way that actually benefits actually existing usecases if we were to start trying to reduce Essential? I would like to see evidence of that. -- Sean Whitton signature.asc Description: PGP signature
Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package
Hello Michael,
On Wed 07 Oct 2020 at 09:53PM +02, Michael Biebl wrote:
> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> `
> option('standalone-binaries', type : 'boolean', value : 'false',
>description : 'also build standalone versions of supported binaries')
> `
>
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
>
> Fedora decided to ship those binaries in separate binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
> conflict with the main systemd package, i.e. the main systemd package
> will continue to ship systemd-tmpfiles and systemd-sysusers linking
> against libsystemd-shared.
>
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
>
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
>
> We could debate whether systemd-standalone-tmpfiles and
> systemd-standalone-sysusers should be provided by a single binary
> package, but since Fedora has already done this split this way, I would
> simply follow here and use the same binary package names.
> The relevant Fedora PR is
> https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
>
> Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
> build variant (as with the udeb flavour), so build times shouldn't go up.
>
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd
From an ftpteam perspective it would probably be preferable to have a
single systemd-standalone binary package which could, if you wanted,
have Provides: systemd-standalone-sysusers and systemd-standalone-tmpfiles.
Otherwise, LGTM.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#971023: Version field (5.6.12) and colons
control: tag -1 + patch Hello, On Wed 30 Sep 2020 at 11:23AM +02, Christian Kastner wrote: > On 2020-09-29 02:22, Sean Whitton wrote: >> Technically superfluous but I think helpful to the reader, so I suggest >> we just keep it. > > To be honest, as a reader, I found that to be the opposite. The "If > [epoch] is omitted" makes it sound as if there were an alternative > handling if it's not omitted. > > So the text > > If it is omitted then the upstream_version may not contain any colons > > actually means > > The upstream_version may not contain any colons > > > It gets slightly more confusing when one considers dashes: > upstream_revision may have a dash if a revision exists. > > But upstream_revision may not have a colon regardless of whether an > epoch is present or not; so the "If [epoch] is omitted" seems really odd. > > Anyway, just my thoughts. Perhaps I read too much into it. No, that's reasonable. Thank you to both Mattia and Guillem too for feedback. I am seeking seconds for the following patch: diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 0d7a3e9..a21a510 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -552,8 +552,7 @@ The three components here are: ``epoch`` This is a single (generally small) unsigned integer. It may be -omitted, in which case zero is assumed. If it is omitted then the -``upstream_version`` may not contain any colons. +omitted, in which case zero is assumed. Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change -- Sean Whitton signature.asc Description: PGP signature
Bug#973634: mpich: d/copyright does not mention vis.js
Source: mpich Version: 3.4~a2+really3.3.2-2 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, d/copyright does not mention debian/missing-sources/vis.js, which has a different license and copyright. Same goes for the minified copies of vis.js in the source. -- Sean Whitton signature.asc Description: PGP signature
Bug#973507: libsis-jhdf5-java: incorrect license text for source/c/jni/
Source: libsis-jhdf5-java Version: 19.04.0+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, The file source/c/jni/COPYING is a different HDF license to that which applies to source/java/hdf/hdf5lib. The version in NEW has the same problem as what's currently in the archive. -- Sean Whitton signature.asc Description: PGP signature
Bug#973393: truncate less of the backtrace during failing ert tests
Hello, On Thu 29 Oct 2020 at 03:42PM -04, Nicholas D. Steeves wrote: > Thomas Koch added a nice workaround for truncated backtraces at: > > https://wiki.debian.org/Teams/DebianEmacsenTeam/Tips > > that workaround is d/elpa-test: > > ert_eval = (setq ert-batch-backtrace-right-margin 500) > > and I wonder if it should be activated by default, in the spirit of > Policy §4.9 "The package build should be as verbose as reasonably > possible". Speaking for myself, I would find it helpful, especially > for the rare corner cases where only noninteractive --batch ert tests > will trigger a failure. Also, I've been asked for untruncated > backtraces by various upstreams. > > The only potential issue I can think of is that the reproducible and > DebCI build logs will have then have long lines, but I feel like the > benefit outweighs this consideration. A possible, though not ideal, > solution to this potential issue might be to word-wrap the backtrace, > but that functionality should probably be enabled in upstream Emacs. > > Let's consider setting `ert-batch-backtrace-right-margin` to a large > value in the meantime. I think this is a good idea. Patches welcome. -- Sean Whitton signature.asc Description: PGP signature
Bug#973396: ITP: volume-el -- tweak your sound card volume from Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: volume-el Version : 1.0+git.20201002.afb75a5 Upstream Author : Daniel Brockman * URL : https://github.com/dbrock/volume.el * License : GPL-2+ Programming Lang: Emacs Lisp Description : tweak your sound card volume from Emacs Companion to bongo, another ITP of mine. I intend to maintain under pkg-emacsen. -- Sean Whitton signature.asc Description: PGP signature
Bug#973383: ITP: bongo -- buffer-based music player for GNU Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: bongo Version : 1.1 Upstream Author : Daniel Brockman * URL : https://github.com/dbrock/bongo * License : GPL-2+ Programming Lang: Emacs Lisp Description : buffer-based music player for GNU Emacs This is a nice music player for Emacs. I intend to maintain this under the pkg-emacsen team. -- Sean Whitton signature.asc Description: PGP signature
Bug#965098: migrated to guile 2.2
Hello, On Mon 26 Oct 2020 at 04:58AM +01, Kai-Martin Knaak wrote: > Just a heads-up: > Upstream pushed a few patches to the git repository to make the package > compatible with guile 2.2. > > This removes the road block that triggered this removal request. Is > there anything else that prevents geda-gaf from staying in the Debian > repos? Well, someone needs to update the version of the package in Debian. Can you? -- Sean Whitton signature.asc Description: PGP signature
Bug#972995: dh-elpa: fails to read project.el's Package-Requires
Package: dh-elpa Version: 2.0.4 Control: affects -1 elpa-project For some reason dh-elpa is failing to generate a dependency on elpa-xref. -- Sean Whitton signature.asc Description: PGP signature
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hello, On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote: > Is this truly the case that all that's needed is a new patch? Can we get > an official ACK from one of the policy editors? I'd be happy to re-write > the original patch to apply against HEAD if that's all that is required. Well, it would need seconding, but otherwise, ACK. Thank you for your interest. -- Sean Whitton signature.asc Description: PGP signature
Bug#968204: Removal of packges which depend on GTK2
Hello, On Mon 26 Oct 2020 at 08:59PM +01, Pál Tamás Ács wrote: >> >> Can you please take your conspiracy theories, mis-information and >> top-posting elsewhere, like /dev/null? Thanks. > > > I'm not sure where exactly my statements were conspiracy theories or > mis-information. Or you just don't like my opinion because it's kind of > different from the mainstream that you're used to? > > Please point out one or more of my statements that you think is false. I don't think this removal bug report is really an appropriate place for a wide-ranging discussion like this. In the interests of efficiency, I'd be grateful if both of you could take it elsewhere. Thank you! -- Sean Whitton signature.asc Description: PGP signature
Bug#968204: Removal of packges which depend on GTK2
Hello, On Sun 25 Oct 2020 at 11:43AM GMT, Simon McVittie wrote: > On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote: >> Hello GNOME team, > > Note that pkg-gnome-maintainers receives bugmail etc. for the entire > GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that > particular fire hose (we get bug mail for packages of interest, or for > all GNOME packages, via tracker.debian.org instead). Our discussion list > is debian-gtk-gnome; I only saw this because I happened to follow the > link on a removal notification for one of the GTK2 mass-bug-filing mails. Ah sorry about that. Thank you for a useful reply. -- Sean Whitton signature.asc Description: PGP signature
Bug#972954: notmuch-slurp-this-debbug should detect subscription emails
Hello, On Mon 26 Oct 2020 at 11:06AM -04, Antoine Beaupre wrote: > I still use "bts subscribe #12345" to subscribe to BTS bugs, which > works great in my workflow. Sometimes -- but not always! -- I also > like to have a copy of those emails in my inbox. So then I naturally > head for the confirmation email, which looks something like: > > From: 942853-subh...@bugs.debian.org > Subject: Please confirm subscription to 942...@bugs.debian.org (ITP: > [...]) > > and type: > > M-x notmuch-slurp-this-debbug > > ... but nothing happens. I would have expected that function to detect > the bug number in the confirmation email and download the bug report, > as if I would have ran `(notmuch-slurp-debbug #942853)`. > > This is the reverse of #928435. Yes, I think this would be a good idea. Patches welcome. -- Sean Whitton signature.asc Description: PGP signature
Bug#972172: Removed package(s) from unstable
Hello, On Mon 19 Oct 2020 at 11:43pm +02, Markus Koschany wrote: > Hello, > > Am 19.10.20 um 23:33 schrieb Debian FTP Masters: >> We believe that the bug you reported is now fixed; the following >> package(s) have been removed from unstable: >> >> libnb-absolutelayout-java | 12.1-1 | all >> libnb-apisupport3-java | 10.0-3 | all >> libnb-ide14-java | 10.0-3 | all >> libnb-java5-java | 10.0-3 | all >> netbeans | 10.0-3 | source, all >> netbeans | 12.1-1 | source >> >> --- Reason --- >> NBS; no longer viable to maintain in Debian >> -- > > I only requested that the obsolete binary packages got removed from > unstable because libnb-absolutelayout-java, the only remaining binary > package, did not migrate to testing. It appears you just removed the > complete source package src:netbeans. How can we fix this? Ooops. We can fast track it through NEW. -- Sean Whitton
Bug#971515: Request for security team input on kubernetes TC bug
Hello security team, The TC are being asked about src:kubernetes, and it would be good to hear from you about whether and how security support is a relevant consideration in determining whether the level of vendoring in that package is acceptable. Could you take a look at #971515 and perhaps give us some input, please? Thanks. -- Sean Whitton
Bug#971515: kubernetes: excessive vendoring (private libraries)
Hello, On Tue 20 Oct 2020 at 06:52pm -07, Felix Lechner wrote: > I think our response to the vendoring explosion is at odds with the > trends in many languages. > > It's time to retool. At the two ends of the solution spectrum, I see > > 1. Fully vendored source packages; or > 2. A packaging system that allows different vendor versions to co-exist. > > Either one allows dependent sources to consume whichever versions they > require, but in my view solution (2) is otherwise superior---provided > that the packaging process is automated. (A language's build system > also has to distinguish the installed versions.) For each language so > affected, could we make (2) our goal, and allow (1) until then? This is a very general (but of course interesting) topic. Could I ask that it be kept out of this TC bug, please? We have to figure out what to do about this package given our present tooling. -- Sean Whitton
Bug#971515: kubernetes: excessive vendoring (private libraries)
Hello Dmitry, On Wed 21 Oct 2020 at 11:21am +11, Dmitry Smirnov wrote: > On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote: >> I think that my message [1] is what makes you think that the package >> would not have got through NEW? > > It was not your message but my own experience with introducing of 100+ > packages through NEW, especially those ones with large burden of vendored > libraries, including Kubernetes. The main hassle usually is to convince FTP- > masters when some vendoring is _necessary_ (case by case) and the usual > request is to package all vendored libraries separately. With rare exceptions > some (few) vendored libraries are allowed like when a library is a fork, > customised for the particular project and therefore not re-usable by other > software. Another example is when vendored library is an obsolete software > phasing out in future releases. Few micro-libraries might be tolerated when > vendored, especially when they are not widely used. Also vendoring might be > acceptable when software components with mutual/circular dependencies are > shipped in one or several name spaces - in other words when a software code > base is not from one name space but from several. None of those cases applies > to Kubernetes. > > A specific example (libpod/podman) is mentioned in > > https://lists.debian.org/debian-devel/2020/03/msg00441.html > > "Podman was rejected due to "many embedded packages in vendor/" with only > 6 or 7 private libs versus 120 libraries removed in favour of packaged > ones." Fair enough, but again, this is about NEW as a review by experienced packagers rather than NEW as a blocker for inclusion. > If your concern is about security support then IMHO Kubernetes can not be > meaningfully supported from security prospective, with or without vendored > dependencies. Fair enough. In the -devel thread the security team indicated that they thought they could do security support in the case where there is vendoring. It would be good to get more input from them in this bug. > If Debian only cared about maintainers' convenience or reducing maintainers > efforts then Debian would not be what it is now. We favour technical elegance > often in expense of maintainers' comfort. I don't think maintainers' comfort is part of Janos' motivation -- it's the issue of not having recent Kubernetes in Debian at all. >> Are there issues the TC should think about which do not fall under this >> way of looking at things? I.e., weighing the impact on people other >> than Janos who want to work on the package, vs. the impact on people who >> want recent kubernetes to be part in the archive at all? > > Is Debian ecosystem of packaged reusable libraries worth caring about? > > If so then why grant exception to one particular package? We have several (or > more) sophisticated Golang packages using hundreds of packaged libraries. > > In the early days of packaging Kubernetes we did not even have most > components packaged and I've been spending most effort on packaging, > introducing and stabilising dependency libraries. > These days the major work has already been done and the argument for > monolithic vendoring is much weaker. > > [...] I think that we can all agree with everything you've written about the reasons why packaging components separately is better. The problem is that in this case the choice seems to be between not having recent Kubernetes in Debian at all, or giving up on some of those advantages. -- Sean Whitton
Bug#971515: kubernetes: excessive vendoring (private libraries)
e Debian better and more useful, so perhaps we can focus on that point of commonality. [1] https://lists.debian.org/debian-devel/2020/03/msg00363.html -- Sean Whitton
Bug#972408: Don't call packages New Debian packages if not yet on Debian
Hello, On Sun 18 Oct 2020 at 08:25am +08, 積丹尼 Dan Jacobson wrote: > X-Debbugs-Cc: Sudip Mukherjee > Package: ftp.debian.org > > When reading e.g., > https://ftp-master.debian.org/new/getmail6_6.7-1.html > the user sees > Debian NEW package overview for getmail6 > > Therefore the user assumes it is a new debian package. > > However it is not yet a new debian package. Yes it may be a > debian-formated package, but it is not yet on Debian as seen in > https://packages.debian.org/ . > > So call them something different. This terminology is baked in all over the place and it would be impractical to change it. We could, however, add a note to those HTML pages saying that the package is not yet available. Perhaps just the text that gets sent to uploaders when their package lands in NEW. Patches welcome, I think. -- Sean Whitton
Bug#971851: RM: hhsuite [s390x] -- ROM; Not supported by upstream
control: tag -1 + moreinfo Hello, Which dependency? Thanks. -- Sean Whitton
Bug#971850: RM: proteinortho [mips64el] -- ROM; Not supported by dependency
control: tag -1 + moreinfo Hello, Which dependency? Thanks. -- Sean Whitton
Bug#971709: greenbone-security-assistant needs updating
control: tag -1 + moreinfo Hello, Looks like greenbone-security-assistant depends on this package, so it needs updating before we can remove. Please remove the moreinfo tag at that point. -- Sean Whitton
Bug#971539: RM: zshdb -- ROM; low popcon; no interest in adopting
control: tag -1 + moreinfo Hello, On Thu 01 Oct 2020 at 03:04pm +01, Iain R. Learmonth wrote: > There has been no interest from the ZSH team in adopting this package, > and it has low popcon, so it's probably best to just remove it rather > than let it rot in the archives. Is there any reason to think it doesn't work? It might be useful to someone to be able to install it from the archive. -- Sean Whitton
Bug#970846: ftp.debian.org: RM: upnp-router-control -- RoQA; unmaintained; RC-buggy
Hello, On Thu 24 Sep 2020 at 11:03am +02, Daniele Napolitano wrote: > Hi, I'm the maintainer of upnp-router-control. I'm so sorry about the > situation, I've updated the package on development git that compiles with > the new GSSDP and GUPNP libraries. > > I should only find the time to make the release and the Debian package. It's been more than two weeks. Any progress here? -- Sean Whitton
Bug#970489: RM: iwyu [armel] -- ROM; No longer build on this platform
control: tag -1 + moreinfo Hello, On Sat 11 Apr 2020 at 01:40pm +02, Sylvestre Ledru wrote: > I am no longer building iwyu on armel. I don't think it ever had > any users. > The fact that there is still the old binary blocks the migration. Typically Debian doesn't have good information to make inferences about whether or not a package is being used on an arch. Is there a fundamental fact about this software that makes it unsuitable/never likely to work on armel? Has it ever worked on armel? Thanks. -- Sean Whitton
Bug#970479: RM: syncthing [armel armhf i386 mipsel] -- ANAIS; package is not built on these architectures
control: tag -1 + moreinfo Hello, On Wed 07 Oct 2020 at 02:04pm +02, Simon Frei wrote: > Badger for Syncthing is just an experiment (need to set an env var to > use it), and it's more or less a failed one at this point. I opened an > MR with a patch to remove it. It's large, but given it just removes code > shouldn't be that much of a burden to carry: > https://salsa.debian.org/go-team/packages/syncthing/-/merge_requests/2 Is this a good alternative to removal, Alexandre? It sounds like the package does fundamentally work on these archs and it's been in stable releases, so it would be good not to remove. -- Sean Whitton
Bug#970432: RM: python-py2bit [s390x hppa powerpc ppc64 sparc64] -- ROM; some architectures are not supported
control: tag -1 + moreinfo Hello, On Wed 16 Sep 2020 at 11:55am +02, Andreas Tille wrote: > a new upload excluded those architectures that are failing the build > time test of this package. Please remove these architectures to enable > testing migration. Is this a regression or has it never worked on those archs? And may I ask whether you have asked upstrem about this? -- Sean Whitton
Bug#970403: RM: linpsk -- ROM; dead upstream; alternatives in debian
control: tag -1 + moreinfo Hello, On Tue 15 Sep 2020 at 07:14pm +01, Iain R. Learmonth wrote: > Please remove linpsk from unstable. The upstream is gone since 2013 and > we have alternatives in Debian already, e.g. fldigi. It has a popcon of 95 and it's been around for a while; people might be using it successfully. Is there any reason to think it doesn't work? -- Sean Whitton
Bug#970364: RM: libfap -- ROM; no rdepends, no popcon
control: tag -1 + moreinfo Hello, On Tue 15 Sep 2020 at 09:32am +01, Iain R. Learmonth wrote: > This library was never used by any reverse dependencies, hasn't been > touched in long enough that it's probably good to remove it. Can always > be reintroduced in the future if needed. Is there any reason to think it doesn't work? Since NEW is slow, it is probably better to leave it orphaned. It's been in several stable releases after all. -- Sean Whitton
Bug#970292: RM: vagrant-digitalocean -- ROM; very old, low popcon
control: tag -1 + moreinfo Hello, On Mon 14 Sep 2020 at 12:23pm +01, Iain R. Learmonth wrote: > I've not used this in a long time, it probably doesn't work anymore, > low popcon too so best to remove it. Someone could reintroduce in the > future if they want. Would it be possible for you to confirm it doesn't work? Just a quick test. Since NEW is slow, reintroduction is more of a barrier to new maintainers than it should be. -- Sean Whitton
Bug#968204: Removal of packges which depend on GTK2
Hello GNOME team, The FTP Team are starting to see removal requests for packages which use GTK2 and are unlikely to be ported to GTK3, but are not RC-buggy. Examples are #968204 and #968283. I read your bug report against one of those two packages and smcv writes GTK 2 is used by some important productivity applications like GIMP, and has also historically been a popular UI toolkit for proprietary software that we can't change, so perhaps removing GTK 2 from Debian will never be feasible. However, it has reached the point where a dependency on it is a bug - not a release-critical bug, and not a bug that can necessarily be fixed quickly, but a piece of technical debt that maintainers should be aware of. My interpretation of this is that use of GTK2 is not really grounds for removal by itself, because there is no removal of GTK2 planned for the time being. So maintainers who don't want to deal with a package which is not likely to be updated for newer versions of GTK (which is fair enough) should orphan rather than request removal. I wanted to ask whether you agree with me about this. -- Sean Whitton
Bug#969473: RM: enchant -- RoQA; Superceded by v2.x series; Unmaintained
control: tag -1 + moreinfo Hello, On Thu 03 Sep 2020 at 11:43am -04, Boyuan Yang wrote: > I am working to finish the transition from enchant(1) to enchant-2 [1] > and the removal of enchant(1) is the last step. According to [1] and > the transition management bug [2], the Enchant library is now provided > by src:enchant-2 and we need to remove the old src:enchant. > > As seem in [1], the only reverse (build-)dependency to src:enchant is > src:xneur. I have just talked with the maintainer of src:xneur and the > maintainer agreed to look into the problem later and have enchant > removed first. > > As a result, it looks like we can now go ahead. Please remove the old > src:enchant [4] library in Sid. We'd really prefer to wait for xneur. Making things unbuildable is bad! -- Sean Whitton
Bug#954794: New packages must not declare themselves Essential
Hello, On Wed 07 Oct 2020 at 06:43pm -04, Sam Hartman wrote: > Josh, my current reading is that there is not support for even the > first step. I believe Guillem and I have disagreed, and I haven't > noticed support from anyone other than you. Speaking as Policy Editor, I agree. I don't see any sort of consensus that we should deprive ourselves of the ability to declare packages Essential. > C) I'd support non-normative documentation that we don't expect to > approve new essential packages in the future in policy. This sounds like a good idea to me too. -- Sean Whitton
Bug#970261: RM: mrd6 -- ROM; No longer maintained
control: tag -1 + moreinfo Hello, On Sun 13 Sep 2020 at 10:41pm +01, Thomas Preud'homme wrote: > Please remove mrd6 from the unstable distribution as it is no longer > maintained since 2013. Quoting its README file [1]: > > "[note from the author, 2013: mrd6 is unsupported software. Since > 2005 native multicast forwarding support has been added to Linux > and pim6sd can be used to manage it. mrd6's codebase is kept > around for historical reasons, it should still work in current > kernels and still allows you to do funky things with routing. > Feel free to fork. -hugo]" > > [1] https://github.com/hugosantos/mrd6/blob/master/README > > It currently has a popcon of 13. Is there any evidence that it doesn't work? Otherwise, I suggest just orphaning it. -- Sean Whitton
Bug#969118: RM: liblightify -- ROM; RoM
control: tag -1 + moreinfo Hello, On Thu 27 Aug 2020 at 10:03pm +02, Tobias Frost wrote: > OSRAM discontinues Lightify soon and I have not really time anymore > for (upstream) development, so lets drop it from Debian. Hmm, the cloud services are turning off, but might people not want to use this library to control their existing light bulbs rather than having to throw them away? -- Sean Whitton
Bug#969173: RM: openvas openvas-libraries openvas-cli openvas-manager -- ROM; replaced by gvm
control: tag -1 + moreinfo Hello, On Fri 28 Aug 2020 at 05:14pm +02, Raphaël Hertzog wrote: > GVM is replacing OpenVAS and a bunch of source packages have been > renamed or are obsolete. > > Please remove the following source packages from unstable: > * openvas(replaced by gvm) > * openvas-libraries (replaced by gvm-libs) > * openvas-cli(obsolete) > * openvas-manager(replaced by gvmd) We need one bug per source package for the sake of our scripts, please. -- Sean Whitton
Bug#969095: RM: mysql-5.7 -- ROM; superseded by mysql-8.0
control: tag -1 + moreinfo Hello, On Thu 27 Aug 2020 at 05:48pm +01, Robie Basak wrote: > Binary movements: > > libmysqld-dev is gone in src:mysql-8.0 - this feature is no longer > supported upstream. The other binary packages have direct replacements: > > libmysqlclient20 -> libmysqlclient21 > s/5.7/8.0/ > > There's also a new binary package mysql-router. Looks like there is still a rdep on pytest-services. -- Sean Whitton
Bug#969082: RM: austin [armhf mipsel] -- RoM; ANAIS
control: tag -1 + moreinfo Hello, On Thu 27 Aug 2020 at 09:49am +01, Gabriele wrote: > May I kindly ask you to remove the austin binaries for architectures > armhf and mipsel for the time being, in order to fix the issue > > Bug#968309: src:austin: fails to migrate to testing for too long: > FTBFS on armhf and mipsel > > These binaries will not be requested again in future revisions > until I can manage to fix the actual underlying issue with Austin. > Unfortunately, I don't see a quicker way of dealing with this matter > at the moment, as I don't have the time and resources to debug on the > mentioned architectures. Have you asked upstream about this? Typically it is better to confirm that the bug is not a trivial fix before resorting to removal. -- Sean Whitton
Bug#970903: RM: dms/oldstable -- ROM; removing until have time to revamp it
Hello, On Wed 23 Sep 2020 at 10:37am +12, Matthew Grant wrote: > Could you please remove the package from unstable as I honetly don't have the > time at the moment to revamp the package for modern Debian. > > I am about to take it our ot use probably for myself, as I am focusing on > Samba > server development and IPv6 for my current employer. > > Some time in the future when I have spare time I may start work on this > project > again, but I am officially putting it on hold for now. I'm removing because it's RC-buggy; otherwise, I think orphaning the package would have been more appropriate. -- Sean Whitton
Bug#968345: RM: golang-github-mendersoftware-scopestack-dev -- ROM; deprecated and unused
control: tag -1 - moreinfo On Sat 22 Aug 2020 at 08:27am -07, Sean Whitton wrote: > On Thu 13 Aug 2020 at 01:08PM +02, lluis.cam...@northern.tech wrote: > >> This dependency is also deprecated after removing >> golang-github-mendersoftware-log (see #960398) >> >> Unused both in testing and unstable, so please remove: >> >> golang-github-mendersoftware-scopestack-dev > > Could the maintainer confirm this, please? Done in #968343. -- Sean Whitton
Bug#963924: libdc1394-22 -- RoQA; Superseeded by libdc1394
control: tag -1 + moreinfo Hello, On Thu 24 Sep 2020 at 08:28am +02, Gianfranco Costamagna wrote: > looks like the new libdc1394 took over the libdc1394-22-dev as transitional > packages, and rebuilds have been performed > for reverse-dependencies to move to the new version. > > Can you please just remove the old one from the archive? Hmm, are you sure everything is up to date? Checking reverse dependencies... # Broken Depends: opencv: libopencv-videoio3.2 libopencv-videoio4.1 Dependency problem found. -- Sean Whitton
Bug#960761: RM:node-babel-preset-react -- ROM; obsolete, no reverse dependencies
control: tag -1 + moreinfo Hello, On Sat 16 May 2020 at 05:23pm +0530, Pirate Praveen wrote: > Package: ftp.debian.org > Severity: normal > Control: block -1 by 960433 > > As part of removing babel version 6 (replaced by babel 7)[1] from the > archive, please remove this package. Its only reverse dependency > (node-babel-preset-airbnb) is also marked for removal. Looks like this is a binary package, not a source package? Typically you'd upload a version of the source package which does not build it and then it'd be removed (automatically or manually). -- Sean Whitton
Bug#969975: RM: openjfx tuxguitar libjogl2-java [armel armhf i386 mipsel] -- RoQA; NBS
On Wed 09 Sep 2020 at 05:53pm +02, Gianfranco Costamagna wrote: > Package: ftp.debian.org > Severity: normal > > Hello, ftpmasters, > > as explained in #962915, the removal of libswt-gtk-4-java on 32bit (armel > armhf i386 mipsel), made some packages unbuildable there. > > I think we should remove them too, since 32bit are not supported anymore. > > the list of libswt-gtk-4-java reverse-dependencies is: > - openjfx > - libjogl2-java > - tuxguitar > > please remove them, as well as their dependencies. > (I would like to provide a full list, but my dak rm is not that good) Could we have separate RM bugs please? Our scripts assume that so this is currently much more effortful to process. -- Sean Whitton
Bug#971023: Version field (5.6.12) and colons
Hello, On Sat 26 Sep 2020 at 02:48pm +02, Christian Kastner wrote: > with regards to colons in version numbers, 5.6.12 states on the "epoch" > fragment: > > "If it is omitted then the upstream_version may not contain any colons." > > > However, this seems superfluous, as it states on the "upstream_version" > fragment: > > "The upstream_version may contain only alphanumerics and the characters > . + - ~ (full stop, plus, hyphen, tilde)" Technically superfluous but I think helpful to the reader, so I suggest we just keep it. -- Sean Whitton
Bug#969621: propellor: Propellor fails to find location of built propellor binary
Hello, On Sat 05 Sep 2020 at 09:22PM -07, Diane Trout wrote: > I tried to just build 5.11, but export CABAL=./Setup breaks the build, the > makefile assumes ./Setup sdist -o - will output a compressed stream, but the > Setup file built in an unstable schroot doesn't support that feature. Just uploaded a version which should be fixed to sid; would be grateful if you could test. -- Sean Whitton signature.asc Description: PGP signature
Bug#969925: dgit: limited support for multiple source packages in a repo
Package: dgit Version: 9.12 Severity: wishlist src:emacs and src:emacs-non-dfsg are maintained as separate branches in the same git repo. dgit could support this with a mode which - implicit sets --no-dep14tag - doesn't save the archive/ tag to the local repo, only pushing it to dgit-repos. The reason for both of these is that these two tags created by dgit are not qualified by source package name. -- Sean Whitton
Bug#969103: [Pkg-emacsen-addons] Bug#969103: seq.el: requesting an update to the version in GNU ELPA
Hello, On Fri 04 Sep 2020 at 11:57AM GMT, Stefan Kangas wrote: > Lev Lamberov writes: > >> I've applied your patch to seq from the ELPA git repository and tested >> it both in GNU Emacs 24 and GNU Emacs 25 from the Debian archive >> (stretch release). Here is the output: > > Thanks for testing! > > I've now pushed the patch to the GNU ELPA repository. Please allow for > at least 24 hours for the new package to get automatically uploaded on > elpa.gnu.org. Thanks for your help with this. Debian has been updated. -- Sean Whitton signature.asc Description: PGP signature
Bug#969103: [Pkg-emacsen-addons] Bug#969103: elpa-flycheck: causes leak in GNU Emacs 27.1
Hello Lev, Thanks for the report and testing. New version uploaded. -- Sean Whitton signature.asc Description: PGP signature
Bug#968033: closed by Debian FTP Masters (Bug#968033: Removed package(s) from unstable)
Hello, On Mon 24 Aug 2020 at 06:11PM +02, Axel Beckert wrote: > Hi, > > Debian Bug Tracking System wrote: >> We try to close bugs which have been reported against this package >> automatically. > > That unfortunately was very counterproductive since the package is > still in Debian Experimental and I now need to reopen all these bug > reports. > > Could you please refrain from doing so if the packages removed from > Unstable are still in Debian Experimental? (Please tell if there's > package, maybe a pseudo-package against which I can file a bug report > for this issue.) Ah, sorry about this. Will try to avoid next time. -- Sean Whitton signature.asc Description: PGP signature
Bug#968204: RM: gkrellmoon -- ROM; outdated, uses outdated libs, not used any more
control: tag -1 + moreinfo Hello Martin, On Mon 10 Aug 2020 at 07:03PM +02, Martin Zobel-Helas wrote: > Package: ftp.debian.org > Severity: normal > > Please remove gkrellmoon. Hmm, it doesn't seem to be RC-buggy; what exactly do you mean by "uses outdated libs" and "not used anymore"? -- Sean Whitton signature.asc Description: PGP signature
Bug#968345: RM: golang-github-mendersoftware-scopestack-dev -- ROM; deprecated and unused
control: tag -1 + moreinfo Hello, On Thu 13 Aug 2020 at 01:08PM +02, lluis.cam...@northern.tech wrote: > This dependency is also deprecated after removing > golang-github-mendersoftware-log (see #960398) > > Unused both in testing and unstable, so please remove: > > golang-github-mendersoftware-scopestack-dev Could the maintainer confirm this, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#968343: RM: golang-github-mendersoftware-mendertesting-dev -- ROM; deprecated and unused
control: tag -1 + moreinfo Hello, On Thu 13 Aug 2020 at 01:02PM +02, lluis.cam...@northern.tech wrote: > This dependency is now deprecated after latest update of packages > mender-cli and golang-github-mendersoftware-mender-artifact following > upstream Mender project release. > > Unused both in testing and unstable, so please remove: > > golang-github-mendersoftware-mendertesting-dev > > See also #960398 for related previously RM bug report. Could the maintainer confirm this, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#968084: RM: haskell-cborg [armhf] -- ROM; unbuildable
Hello, On Sat 08 Aug 2020 at 11:32AM +03, Ilias Tsitsimpis wrote: > The latest version of haskell-cborg FTBFS on armhf (tests fail with > SIGBUS, probably due to unaligned memory access). Could you confirm that it's unlikely upstream will fix this? > Please remove haskell-cborg and haskell-cborg-json (rev-dependency) > from armhf. We need separate bugs for the sake of our scripts, please. -- Sean Whitton signature.asc Description: PGP signature
Bug#968758: lintian: Explore Emacs integration (lintian-mode)
control: noowner -1 Hello, On Thu 20 Aug 2020 at 05:56PM -07, Felix Lechner wrote: > Package: lintian > Severity: normal > Owner: Sean Whitton I do not intend to implement this, so unsetting owner metadata. -- Sean Whitton signature.asc Description: PGP signature
Bug#968731: netgen: copyright and licensing issues
Source: netgen Version: 6.2.2006+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, During review in NEW I discovered the following problems with this package's copyright file: cmake\cmake_modules\FindMETIS.cmake is BSD licensed. Also the autogen files do not have their licenses given in d/copyright. libsrc/core/concurrentqueue.h has a different license, not in d/copyright. Looks like general/mystring.*pp might have a different copyright holder. libsrc/general/gzstream.* and libsrc/occ have different copyright holders and maybe licenses; situation is unclear. mkinstalldirs missing copyright & license. ng/fonts.hpp -- is this really the source code for the font? ng/ngappinit.cpp says it's a modification from a different package; what is its copyright and license? -- Sean Whitton signature.asc Description: PGP signature
Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
Hello Gunnar, others, On Wed 19 Aug 2020 at 12:31PM -05, Gunnar Wolf wrote: > Maybe we could improve on the problem putting it upside down: What if > systemd stated "Provides:" for their main interfaces? While not every > provided binary would qualify as a "main interface", I think a line > such as: > > Provides: journalctl, loginctl, systemctl > > would make sense for systemd. Other scripts could depend on the > specific functionality they make use of. > > Probably, the systemctl package would require a rename to > 'docker-systemctl' or something like that (the upstream name is > 'docker systemctl replacement'). > > What is the systemd maintainers view of this idea? And the > systemctl's? If this solution was thought acceptable I think we'd want to register these new virtual packages in Policy, since they wouldn't be used purely among a "co-operating group of packages". -- Sean Whitton signature.asc Description: PGP signature
Bug#968635: dgit-mirror-ssh-wrapper broke (again) due to rsync update
Hello, On Wed 19 Aug 2020 at 11:16AM +01, Ian Jackson wrote: > I think Sean has been under the impression that the meaning of the > flags that follow --server can be found by reading the manual. > Certainly I was under that impression. > >> Now, it's interesting to note that the 'u' here does not reflect the >> client's '-u' option. > > This is the key thing I was missing. Er, yes, me too. >> I don't know how the inclusion of "uid/gid 0 in the id map" can break >> things, but maybe I'm overlooking something. However, if we indeed >> agree that things can break here, then it seems to me that a new bug >> should be filed against rsync, IMO. > > Sean was probably thinking -u here meant "skip files that are newer on > the receiver". That's what I was thinking. > > I think we can have two general approaches to these undocumented > command line options: > > (1) UTSL to find out what each flag means, and decide if we like it. > I certainly didn't do that right at the beginning. If we do this we > should really review all the existing ones. > > (2) Trust rsync upstream not to get this wrong, and assume that if > the rsync client contrives to pass these options as part of --server, > that they aren't dangerous. > > I'm in favour of (2), which would imply immediately applying Sergio's > patch. Sean, what do you think ? Agreed. -- Sean Whitton signature.asc Description: PGP signature
Bug#968635: dgit-mirror-ssh-wrapper broke (again) due to rsync update
Hello,
On Tue 18 Aug 2020 at 04:51PM -04, Sergio Durigan Junior wrote:
> diff -Nru dgit-9.11/infra/dgit-mirror-ssh-wrap
> dgit-9.12~/infra/dgit-mirror-ssh-wrap
> --- dgit-9.11/infra/dgit-mirror-ssh-wrap 2020-06-22 14:09:17.0
> -0400
> +++ dgit-9.12~/infra/dgit-mirror-ssh-wrap 2020-08-18 16:19:08.0
> -0400
> @@ -29,6 +29,8 @@
> m{^rsync --server -lHtre\.iLsfxC --timeout=\d+ --delete --safe-links \. $d$}
> ||
> m{^rsync --server -lHtre\.iLsfxCIv --timeout=\d+ --delete --safe-links \.
> $d$}
> +||
> +m{^rsync --server -lHtre\.iLsfxCIvu --timeout=\d+ --delete --safe-links \.
> $d$}
>
> # To add a new command pattern, add || m{^ ... $} above.
> # The pattern should contain $d where the per-package destination
Hmm, unlike the -I and -v options, the -u option seems like it could
break things. Could you explain why you think it won't, please?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#968510: ITP: xref-el -- Library for cross-referencing commands in Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: xref-el Version : 1.0.2 Upstream Author : FSF * URL : https://www.example.org/ * License : GPL-3+ Programming Lang: Emacs Lisp Description : Library for cross-referencing commands in Emacs This is a newer version of xref.el than the one included with Emacs 27. I am packaging it as a dependency for the latest version of my package project-el. This is similar to seq-el and org-mode, which are also bundled with Emacs, but where we have more recent versions available as a separate package. -- Sean Whitton signature.asc Description: PGP signature
Bug#966416: RM: argyll -- ROM; RC-buggy; abandoned upstream
Hello Jörg, On Fri 07 Aug 2020 at 12:21PM +02, Jörg Frings-Fürst wrote: > the Upstream Release 2.1.2 has the same errors. Buildlog is attached. Thanks for confirming. Please remove the 'moreinfo' tag once there are no more reverse dependencies. -- Sean Whitton signature.asc Description: PGP signature
Bug#967053: RM: pynifti -- RoQA; Replaced by nibabel, Python 2
Hello, On Mon 03 Aug 2020 at 07:07PM +02, Moritz Muehlenhoff wrote: > Package: ftp.debian.org > Severity: normal > > Please remove pynifti. It depends on Python 2 and has been replaced > by nibabel. Acked by the maintainers in #937490. Looks like I already removed it last month! -- Sean Whitton signature.asc Description: PGP signature
Bug#966598: RM: sgabios -- RoQA; swallowed by the only user (qemu)
control: tag -1 + moreinfo Hello, On Fri 31 Jul 2020 at 11:34AM +03, Michael Tokarev wrote: > Package: ftp.debian.org > Severity: normal > > Package sgabios provides a variant of x86 BIOS/firmware. It was > only used by qemu system emulation in Debian. The upstream development > stopped many years ago, and now it is maintained within the only its > user, qemu, and is built from qemu sources too (qemu-system-data > package, /usr/share/qemu/sgabios.bin). Package sgabios is not useful > by its own. > > While it does not really hurt, I guess, to keep this package in the > archive, I also don't see a reason for that. > > sgabios has rather high numbers on the popcon data. This is because > it's been suggested by qemu for quite some time. > > Also this package is in Depends: of libguestfs0. This is okay, since > qemu-system-data provides sgabios (and conflicts with it), so the > dependency is satisfied by qemu-system-data which is a required > dependency of qemu-system-x86 anyway. I filed a bugreport for > libguestfs0 to remove the explicit dependency on sgabios, which > is #966596 , but it is completely optional due to this Provides. Please remove the moreinfo tag when this rdep is gone. -- Sean Whitton signature.asc Description: PGP signature
Bug#966519: RM: pysal -- ROM; Unmaintained
control: tag -1 + moreinfo Hello, On Thu 30 Jul 2020 at 05:51AM +02, Bas Couwenberg wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org > > Please remove pysal from the archive, > it is unmaintained and has a low popcon score. popcon is not low and there are no open bugs? -- Sean Whitton signature.asc Description: PGP signature
Bug#966416: RM: argyll -- ROM; RC-buggy; abandoned upstream
control: tag -1 + moreinfo Hello Jörg, On Tue 28 Jul 2020 at 12:10PM +02, Jörg Frings-Fürst wrote: > argyll is RC-buggy with no responce from upstream since > more then 6 month. Would you mind confirming that the latest upstream release, which isn't packaged, doesn't build with gcc-10 either? -- Sean Whitton signature.asc Description: PGP signature
Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
Hello, On Tue 04 Aug 2020 at 08:04AM -04, Nicholas D Steeves wrote: > By the way, I concede that choosing not to censure the > human element of my changelog entry makes it appear that the decision > was possibly an "emotional" rather than "rational" one. Given the > prevalence of negative and degrading changelog entries (eg: "useless", > "good for nothing", "garbage", etc) there is precedent for > rational+emotional in Debian culture, and I think we can agree that > rational+positive_emotion entries are more congruent with the project's > ideals. I don't think this was what happened. It was simply that you did not make reference to our shared definition of the fields you were modifying. > I understand this is a qualitative and philosophical thing, and probably > outside the scope of Policy, but if I interpret what you've written > correctly, would it be this: Perfect documentation would be 100% > comprehensive, but most users won't read it, and were they to spend the > time reading it this would count as discovery? ...albeit probably not > joyful, because I've never heard anyone describe the process of reading > docs as such (except An Introduction to Programming in Emacs LISP. That > one is a joy!) Otherwise, the quick-start guide might ideally omit > certain details not only in the interests of brevity, but also to allow > for the joy of discovery? I've had plenty of enjoyable experiences with the Emacs manuals :) A quick start guide is not a manual however. So it could omit stuff in the way that you describe. >> Hard for me to say, to be honest, as I don't use smex or ivy or >> counsel. >> > > On this topic, would you like me to adopt smex? I've noticed that it's > your package and is in need of some work. If so, please grant me DM for > it. That would be great, thank you. Please remove me from Uploaders:. -- Sean Whitton signature.asc Description: PGP signature
Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
Package: emacs-ivy Version: 0.13.0-1 Hello, On Fri 24 Jul 2020 at 11:49PM GMT, Debian FTP Masters wrote: > Changes: > emacs-ivy (0.13.0-1) unstable; urgency=medium > . >[...] >* Add elpa-smex to elpa-counsel's Recommends. The way it presents one's > recently and most frequently used commands at the top of the > candidates list is a wonderful productivity-enhancing feature. See > the docs to learn how to use Counsel to enable this for the M-x > interface. Based on your description here, should probably be Suggests: not Recommends:, given that Recommends: is for packages where it would be highly unusual not to use ivy with them. -- Sean Whitton signature.asc Description: PGP signature
Bug#966284: ITP: project-el -- Emacs library for operations on the current project
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: project-el Version : 0.5.0 Upstream Author : The GNU Project * URL : http://elpa.gnu.org/packages/project.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs library for operations on the current project This Emacs Lisp library is the new generic API for operations on the current project which will be included in Emacs 27 (hence the otherwise unacceptably generic name). I am packaging this separately because project.el is developing quickly, and we will want to have newer versions available in Debian than the one which will be included in the as-yet-unreleased Emacs 27 -- which is already out-of-date. We have separate packaging like this for several other things which are bundled with Emacs, such as Org-mode and seq.el. -- Sean Whitton signature.asc Description: PGP signature
Bug#966068: RFA: emacs-helm-ag -- Silver Searcher integration with Emacs Helm
Package: wnpp Severity: normal Hello, I request an adoptor for the emacs-helm-ag package. I haven't been using it myself for a while. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package description is: This library provides an interface to the Silver Searcher for Emacs Helm. . Other programs, such as the platinum searcher ack, may also be used with this library. -- Sean Whitton signature.asc Description: PGP signature
Bug#965989: ITP: ox-texinfo-plus-el -- extensions for Org-mode's Texinfo exporter
Package: wnpp Severity: wishlist Owner: Sean Whitton Control: block 963831 by -1 * Package name: ox-texinfo-plus-el Version : 2.2.4 Upstream Author : Jonas Bernoulli * URL : https://github.com/tarsius/ox-texinfo-plus * License : GPL-3+ Programming Lang: Emacs Lisp Description : extensions for Org-mode's Texinfo exporter This is needed to build the docs for Org-roam, another ITP of mine. -- Sean Whitton signature.asc Description: PGP signature
Bug#962872: ocrmypdf: new major upstream version available
Hello James, On Sun 19 Jul 2020 at 08:00AM -07, James R Barlow wrote: > I updated debian/copyright in both projects at the HEAD revision (not a > tagged release). These files should reflect the current status. Great. I see you merged in my d/copyright. Previously I'd not wanted to bother you with that, but going forward, if I update d/copyright, would you like PRs from me, or would you prefer to just merge in my changes before making your own updates? > I believe this means the updates shouldn't be too difficult, and also > that the -dfsg version tag could be dropped from both > packages. (pikepdf is now powerful enough that I can usually > synthesize problematic constructs instead of adding another test > resource.) Thank you for the details here -- I will look into verifying whether it can be dropped. -- Sean Whitton signature.asc Description: PGP signature
Bug#962872: ocrmypdf: new major upstream version available
Hello Rogério, On Mon 15 Jun 2020 at 09:13AM -03, Rogério Brito wrote: > A new major upstream version (10.0.1) of ocrmypdf was released a few days > ago and it is *so much faster* than the previous versions 8.x, 9.x, > especially during the (painful) initial step of "Scanning". > > I installed it via pip in a virtual environment and it works very well and > many hours of users will be saved if this new version is made available for > users of Debian in general. Thank you for letting me know about the speed improvements. The main thing blocking updating both pikepdf and ocrmypdf -- which I try to do together since upstream is the same -- is updating d/copyright for all the new test resources which are included. This often requires looking up licenses on commons.wikimedia.org, and adding new files to Files-Excluded:. Perhaps you would be interested in helping out? What you would need to do is something like `git diff --name-status --diff-filter=ADR v1.13.0..v1.17.2` (versions are for pikepdf) and then work on a patch to d/copyright. All the other parts of the packaging, including actually applying Files-Excluded:, I can deal with easily myself. -- Sean Whitton signature.asc Description: PGP signature
Bug#965098: please remove geda-gaf from the archive
control: tag -1 + moreinfo Hello Bdale, On Wed 15 Jul 2020 at 11:08PM -06, Bdale Garbee wrote: > Package: ftp.debian.org > > I'm a member of the Debian Electronics team, and have been one of the > maintainers of Debian's geda-gaf package for the last few years. > > The geda-gaf package is holding back guile-2.0 removal, and I see little > chance that upstream will care about this any time soon. There's a > newer upstream release than what's in Debian, and it still hard depends > on guile-2.0. Please retitle this bug according to the "About removals in Debian" section of https://ftp-master.debian.org/removals.html -- our removal scripts depend on this. > There are two reverse dependencies on geda-gaf, gspiceui, and > contrib/easyspice. Both appear to be maintained by Gudjon > I. Gudjonsson, who I will CC. Please remove the moreinfo tag from this bug once these packages have been removed or updated such that there are no more rdeps. -- Sean Whitton signature.asc Description: PGP signature
Bug#963750: RM: chef -- ROM; trademark issues
Hello Antonio, Stefano, On Wed 15 Jul 2020 at 10:57AM -07, Stefano Rivera wrote: > I think your analysis is correct. The source is Apache-2.0 licensed, but > with a renaming requirement. There is a collaborative effort to maintain > a renamed source, cinc, which we've been shipping, but we haven't > followed through on a complete renaming. > > This is an RoM request, the maintainers have lost interest in working > with an upstream that imposes rules like this. Normally a maintainer losing interest in this way would mean orphaning, not removal, which makes things easier for someone who wants to pick it up. In this case, however, it seems the package would have to go through NEW anyway so that the packages could be renamed -- even if the arguments posted to the Ubuntu bug by Steve Langasek are valid, and we don't change binary paths, we would surely want to rename the source packages. So I'm going ahead with removal. This action by one member of the FTP Team should not be interpreted as any sort of Debian project opinion, or even FTP Team opinion, about the acceptability of the versions of the packages I'm removing. -- Sean Whitton signature.asc Description: PGP signature
Bug#965080: Resignation + Call for votes for new Chair
Hello, On Wed 15 Jul 2020 at 09:05PM +02, Margarita Manterola wrote: > I am calling for the election of a new Chair of Debian Technical > Committee by announcing my resignation as chair effective one week from > now. In accordance with Section 6.1.7 of the Debian Constitution, the > vote runs until all members have voted, or until my resignation takes > effect. > > The ballot is the following: > > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Philip Hands > B : Margarita Manterola > C : David Bremner > D : Niko Tyni > E : Gunnar Wolf > F : Simon McVittie > G : Sean Whitton > H : Elana Hashman > > ===END=== I vote: B > C > A = D = E = F > G = H -- Sean Whitton signature.asc Description: PGP signature
Bug#952645: Please clarify the status of ublock-origin in NEW
Hello, On Wed 15 Jul 2020 at 05:19PM +02, Markus Koschany wrote: > Thanks for your reply. I'm glad that ublock-origin hasn't been simply > forgotten. However I'd like to suggest to implement a strict FIFO queue > because now it is more like FILO. This would automatically reduce > support requests like this one to a minimum because everyone would be > able to watch the progress. We're all volunteers, and generally I think this sort of thing would make NEW processing feel like drudgery. More specifically, not sure this could work well because the amount of time packages take to process varies considerably, so if we only have time for some small packages, we want to be able to get those through, and not be stopped just because of a rule that we have to process the oldest item in the queue. > I also recommend to prioritize binary-new packages because they should > require less work than completely new ones since the check for DFSG > compliance has already happened once before. The focus should really > be more on conflicting package names or binaries and I'm sure this > could be automated. My experience shows that they often take *more* time, unfortunately. -- Sean Whitton signature.asc Description: PGP signature
