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
Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist
Hello Nicholas, On Mon 13 Jul 2020 at 10:23PM -07, Nicholas Breen wrote: > It does still work (modulo #936008, which requires rewriting one script > -- though the package is basically just two scripts). However, there's > nothing it does that other packages don't do equally well or better; it > could be orphaned and remain for another release or two, but I'm not > convinced it's helping anyone trying to decide between all the results > of "apt-cache search galler(y|ies)". Fair point, but the popcon is far from zero, and it would surely help existing users to keep it around. Going ahead and closing the bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#952645: Please clarify the status of ublock-origin in NEW
Hello, On Tue 14 Jul 2020 at 10:19AM +02, Markus Koschany wrote: > I am reaching out to you because the Firefox/Chromium addon > ublock-origin is still in the NEW queue despite being uploaded four > months ago. The package is not really new in Debian and it is quite > unusual that a binary-new package has been stuck in the queue for such a > long time. The problem is that ublock-origin should be updated in stable > releases as well and the new version in the queue is the solution for a > couple of problems which I cannot address in a more effective way > otherwise. > > Please clarify the status of ublock-origin and why it is still in the > NEW queue. Simply that we do not have enough active FTP team members. Just to note that being in binary-NEW makes no difference; it gets a full check as if it were a new source package. -- Sean Whitton signature.asc Description: PGP signature
Bug#964937: RM: dictdlib dict-bouvier dict-moby-thesaurus -- RoQA; dead upstrea (10+ years); python2-only; no extrenal deps outside of this set; extremely low popcon
Hello Sandro, I'm sorry for the inconvenience but we need three separate bugs for our scripts to generate the appropriate dak commands. -- Sean Whitton signature.asc Description: PGP signature
Bug#964921: RM: golang-x-text -- RoQA; Source package was renamed to golang-golang-x-text
control: tag -1 + moreinfo Hello, On Sun 12 Jul 2020 at 07:31PM +08, Shengjing Zhu wrote: > I will amend this RM bug, after cleaning up the above packages. > But I'm not sure if the dependency problem is blocker for RM. It is. Please remove tag when fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist
control: tag -1 + moreinfo Hello Nicholas, On Sat 11 Jul 2020 at 05:26PM -07, Nicholas Breen wrote: > Package: ftp.debian.org > Severity: normal > > Please remove jigl from the archive. It has not had any upstream > activity since 2006, and has the lowest popcon count of all remaining > similar tools: > > https://qa.debian.org/popcon-graph.php?packages=jigl%2C+llgal%2C+fgallery%2C+lazygal%2C+igal2%2C+imageindex&show_installed=on&want_legend=on&from_date=2010-01-01&to_date=&hlght_date=&date_fmt=%25Y&beenhere=1 Is there any reason to think the software no longer works? Otherwise, perhaps it would be better if you were simply to orphan it. -- Sean Whitton signature.asc Description: PGP signature
Bug#963750: RM: chef -- ROM; trademark issues
Hello Jason, On Sat 11 Jul 2020 at 09:29PM -07, Jason Self wrote: > Sean Whitton asked: >> On the other hand you say you think that we should remove the Chef >> package because there are not going to be future upstream releases >> which are free software. Could you provide me a reference, please? > > The problematic pieces appear to be contained within [0]. These two > points appear to eliminate freedom #2 [1] by making exact copies > impossible. DFSG#4 probably covers this case. -- Sean Whitton signature.asc Description: PGP signature
Bug#964983: New Upstream Version
Hello, On Mon 13 Jul 2020 at 10:58PM +01, Barak A. Pearlmutter wrote: > Sometimes I wonder if Debian needs some serious process analysis and > restructuring. Should a new library version that happens to cross a major > version boundary really good though the same extra vetting queue that a new > browser goes through? I think in this case Clint meant that haskell-binary-instances would need to go through NEW, not the new github library. -- Sean Whitton signature.asc Description: PGP signature
Bug#964939: ITP: emacs-orgalist -- Manage Org-like lists in non-Org Emacs buffers
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: emacs-orgalist Version : 1.12 Upstream Author : Nicolas Goaziou * URL : https://elpa.gnu.org/packages/orgalist.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : Manage Org-like lists in non-Org Emacs buffers Recent Org-mode doesn't include orgstruct-mode, and this is the replacement Org-mode upstream recommends. -- Sean Whitton signature.asc Description: PGP signature
Bug#963750: RM: chef -- ROM; trademark issues
Hello again Antonio, On Fri 26 Jun 2020 at 09:22AM -03, Antonio Terceiro wrote: > As per #959981, Chef packages in Debian have trademark issues > according to their upstream. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981 > > The claims are questionable, are argued by Steve Langasek in a > corresponding Ubuntu bug. > > https://bugs.launchpad.net/chef/+bug/1877462 > > However, Chef Inc. decided that Chef should no longer be free > software/open source. I no longer intend to use or maintain Chef, and > would like it to be removed from Debian. I'm a bit confused here. On the one hand you say that there's a copyright issue, but reading the Ubuntu bug it seems that Ubuntu's src:chef in fact contains cinc. I take it Debian's doesn't? In which case the copyright issue would seem not to be a relevant reason for removal? On the other hand you say you think that we should remove the Chef package because there are not going to be future upstream releases which are free software. Could you provide me a reference, please? All I can find online is that there is a new requirement to perform some renaming in the contents of the package, not that new releases will be DFSG-nonfree. -- Sean Whitton signature.asc Description: PGP signature
Bug#964560: RM: herbstluftwm [s390x] -- ROM; Never worked
control: tag -1 + moreinfo Hello Christoph, On Wed 08 Jul 2020 at 07:15PM +02, Christoph Egger wrote: > We recently enabled the testsuite for herbstluftwm. Unfortunately it > turns out it is far from run-able on s390x at the moment (and > probavbly never worked there). While I'm working with upstream on > fixing the issue (that also affects d-ports architectures) I'd like to > request removal from unstable for now especially as I guess window > managers are of limited use on s390x and the benefit of having the > fixes and tests in elsewhere is more important right now. If you haven't yet determined for sure that the test failures indicate the package is never going to work on s390x, why not just disable the tests on that architecture for now? Removal seems premature. -- Sean Whitton signature.asc Description: PGP signature
Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue
Hello Sebastiaan, On Sat 11 Jul 2020 at 08:37PM +02, Sebastiaan Couwenberg wrote: > The FTBFS on mips64el is persistent, and qgis is already removed on that > architecture via #953671. Ah right. >> Could you confirm this issue is not likely to get fixed anytime soon? > > 3.10.7+dfsg-1~exp1 FTBFS on eberlin, and 3.10.7+dfsg-1 FTBFS on > mipsel-manda-02, both had the same issue: "Error: branch out of range". > > 3.10.7+dfsg-1 was given back because it was part of the qt transition > and succeeded on mipsel-aql-01. > > I expect a subsequent binNMU or new upload to FTBFS again, so removing > qgis from mipsel is still a good idea in my opinion. > > If we're lucky mips* may not meet the architecture qualifications and be > removed for bullseye and this qgis not alway building successfully there > will become moot. So, you'd say that the successful build was a random success, and it *usually* fails? To be honest it seems odd to me remove something based on a random failure, but if it is much more often than not and you think the upstream issue is unlikely to get fixed soon, I will trust your judgement. -- Sean Whitton signature.asc Description: PGP signature
Bug#964486: RM: initz -- RoQA; orphaned; dead upstream; alternatives exist
control: tag -1 + moreinfo Hello, On Tue 07 Jul 2020 at 09:56PM +02, Chris Hofstaedtler wrote: > Package: ftp.debian.org > Severity: normal > > Dear ftpmasters, > > please remove initz, an init files helper for emacsen. > > - Orphaned for 8+ years, no interest in the O bug > - Last upstream release in 2003 > - There are other, more modern helpers for configuring emacs (at least > when I last used emacs a few years ago) > - popcon numbers say there are 6 total installs I had a look at the README for this package and I do not believe there is actually something more modern which does what this package does -- was there something in particular you had in mind? We still ship XEmacs in Debian, and given how much GNU Emacs and XEmacs have diverged, it seems plausible that someone might want to use this package to manage those differences. It is worth noting that we don't ship more than one version of GNU Emacs in the archive anymore, so if and when XEmacs leaves Debian, there would seem to be little reason to keep this. -- Sean Whitton signature.asc Description: PGP signature
Bug#964484: RM: aewm -- RoQA; orphaned; dead upstream; ftbfs with gcc-10; alternatives exist
control: tag -1 + moreinfo Hello Chris, On Tue 07 Jul 2020 at 09:46PM +02, Chris Hofstaedtler wrote: > Package: ftp.debian.org > Severity: normal > > Dear ftpmasters, > > please remove aewm: > - has been orphaned for 8+ years, with no interest in the O bug > - the previous Maintainer is also the upstream, homepage has disappeared > - currently ftbfs with the coming gcc-10 > - we have enough other options for minimalist window managers, some of > them might also work with wayland in the future. > - popcon tells me usage is virtually non-existent and never really was The FTBFS has been fixed and it has a popcon of ~40 which does not seem non-existent. Is there other reason to think it isn't usable? Have you tried it out? -- Sean Whitton signature.asc Description: PGP signature
Bug#964476: RM: autounit -- RoQA; orphaned; dead upstream; unused
control: tag -1 + moreinfo Hello, On Tue 07 Jul 2020 at 08:56PM +02, Chris Hofstaedtler wrote: > Package: ftp.debian.org > Severity: normal > > Dear ftpmasters, > > please remove autounit: > - it has been orphaned for 10 years, with no interest to pick it up > - last QA upload was 5 years ago > - its a development helper package, and nothing depends or build-depends > on it > - upstream has vanished > > Given this is a development tool, and nothing needs it in Debian, I > think it's safe to say this is an unused thing, and no new software will > start using it. We can save our QA energy for other packages. I'm not sure about this; the package is not getting in anyone's way, and someone might find it useful. May I ask whether you've written to autou...@packages.debian.org with notice of the removal? -- Sean Whitton signature.asc Description: PGP signature
Bug#964468: RM: libifp -- RoQA; unmaintained; dead upstream; obsolete hardware
control: tag -1 + moreinfo Hello Chris, On Tue 07 Jul 2020 at 08:04PM +02, Chris Hofstaedtler wrote: > Package: ftp.debian.org > Severity: normal > > Dear ftpmasters, > > please remove libifp: communicate with iRiver iFP audio devices. > > It has not seen an upload for 9+ years, and is a support library for > iRiver media players, which I haven't seen in years either. > > It does not seem to have any reverse dependencies. > > Looks like interest in support for the hardware is just gone. > There's an open bug to switch to current libusb API, but obviously > that's also not happening. Have you written to lib...@packages.debian.org with notice of this removal? I'd like to ask you to remove the moreinfo tag from this bug once two weeks have passed after writing to that address, so we can be sure no-one wants to maintain it. -- Sean Whitton signature.asc Description: PGP signature
Bug#964347: RM: biobambam2 [armel armhf i386] -- RoQA; build dependency libmaus2 is no longer available on 32bit
control: tag -1 + moreinfo Hello Adrian, On Sun 05 Jul 2020 at 11:30PM +03, Adrian Bunk wrote: > Package: ftp.debian.org > Severity: normal > > See #934619 for background. Seems like bcbio would be broken by this removal. Please remove the moreinfo tag when rdeps are fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#964051: RM: python-cjson -- ROM; python3 support missing, upstream MIA since a long time
Hello, There's some activity upstream but no progress on their bug report for python3 support, so I'll remove, but with a slightly amended removal reason. -- Sean Whitton signature.asc Description: PGP signature
Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps
Hello, On Thu 09 Jul 2020 at 05:14PM -04, Sandro Tosi wrote: > Hello FTP Masters, > > On Wed, Jun 24, 2020 at 11:57 PM Sandro Tosi wrote: >> >> Package: ftp.debian.org >> Severity: normal >> >> cython has just been removed, and the remaining rdeps are not in testing as >> RC >> for other reasons, so let's not wait on them > > can you please proceed with this removal? thanks! Just to explain the hold up, since there are rdeps, it needs an ftp team member with python2 transition-specific knowledge to process the removal. So it might take a bit longer. -- Sean Whitton signature.asc Description: PGP signature
Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue
control: tag -1 +moreinfo Hello Bas, On Thu 25 Jun 2020 at 06:00AM +02, Bas Couwenberg wrote: > Please remove qgis from mipsel where it FTBFS due to architecture specific > issues. It looks like it FTBFS on mipsel64el not mipsel? Could you confirm this issue is not likely to get fixed anytime soon? -- Sean Whitton signature.asc Description: PGP signature
Bug#963750: RM: chef -- ROM; trademark issues
control: tag -1 +moreinfo Hello, On Fri 26 Jun 2020 at 09:48AM -03, Antonio Terceiro wrote: > On Fri, Jun 26, 2020 at 09:22:09AM -0300, Antonio Terceiro wrote: >> ruby-knife-acl and ohai are part of the Chef ecosystem, and both have >> circular dependencies with chef. So, please remove the following source >> packages from unstable: >> >> - chef >> - ohai >> - ruby-knife-acl > > actually, please also remove chef-zero, ruby-cheffish, and > ruby-compat-resource. they are all part of the chef ecosystem and are > pointless without it. > > So the full list is: > > chef ohai ruby-knife-acl chef-zero ruby-cheffish ruby-compat-resource We need separate RM bugs for each of these, please. Please remove the moreinfo tag from this bug when there are no more rdeps for chef itself. -- Sean Whitton signature.asc Description: PGP signature
Bug#964288: override: debichem
Hello, On Sun 05 Jul 2020 at 01:14AM -04, Sandro Tosi wrote: > Package: ftp.debian.org > Severity: normal > > Hello, > could you please apply these changes: > > dak override debichem-cheminformatics metapackages # from 'debichem' > dak override debichem-visualisation metapackages # from 'debichem' > dak override debichem-view-edit-2d metapackages # from 'debichem' > dak override debichem-semiempirical metapackages # from 'debichem' > dak override debichem-modelling metapackages # from 'debichem' Done all except the last which seems not to exist. > (as requested in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# ) I got a bit confused here -- please put the old section, not the source package name, at the end of the lines. -- Sean Whitton signature.asc Description: PGP signature
Bug#964288: override: debichem
Hello Sandro, On Tue 07 Jul 2020 at 04:34PM -04, Sandro Tosi wrote: > they are indeed metapackages. This is what I wanted to know :) > Is there any specific reason for pushing back on this request? No. But if ftpteam members were just to always process override request without asking why they're needed, we might as well program dak to automatically update sections when the control file changes. -- Sean Whitton signature.asc Description: PGP signature
Bug#964288: override: debichem
Hello, On Tue 07 Jul 2020 at 01:11AM -04, Sandro Tosi wrote: > control: tag -1 - moreinfo > > On Tue, Jul 7, 2020 at 12:58 AM Sean Whitton wrote: >> >> control: tag -1 + moreinfo >> >> Hello, >> >> On Sun 05 Jul 2020 at 01:14AM -04, Sandro Tosi wrote: >> >> > Package: ftp.debian.org >> > Severity: normal >> > >> > Hello, >> > could you please apply these changes: >> > >> > dak override debichem-cheminformatics metapackages # from 'debichem' >> > dak override debichem-visualisation metapackages # from 'debichem' >> > dak override debichem-view-edit-2d metapackages # from 'debichem' >> > dak override debichem-semiempirical metapackages # from 'debichem' >> > dak override debichem-modelling metapackages # from 'debichem' >> > >> > (as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# >> > ) >> >> Sure, but could you briefly explain the reason? > > because that's what the package d/control file says: > https://salsa.debian.org/blends-team/debichem/-/blob/master/debian/control > > the actual effect of the overrides file having a different section > than `metapackages` is that the py2removal tracking program wont > ignore those packages (as removing a package that's a dep of a > metapackage is "okay") and thus we dont mark leaf packages as such. > > Please let me know if this clarification suffices and you can proceed. I wasn't completely clear. What I meant to ask for was justification for why the section in the control file was changed. -- Sean Whitton signature.asc Description: PGP signature
Bug#902901: FTBFS: Tests fail
Hello, On Tue 16 Jun 2020 at 07:53PM +03, Ilias Tsitsimpis wrote: > This package is still unbuildable after 2 years, with no response from > upstream. Since there are no rev dependencies for this package, I intend > to remove it from Debian. Please go ahead, since secret-sharing no longer depends on it. Thank you for your efforts! -- Sean Whitton signature.asc Description: PGP signature
Bug#964288: override: debichem
control: tag -1 + moreinfo Hello, On Sun 05 Jul 2020 at 01:14AM -04, Sandro Tosi wrote: > Package: ftp.debian.org > Severity: normal > > Hello, > could you please apply these changes: > > dak override debichem-cheminformatics metapackages # from 'debichem' > dak override debichem-visualisation metapackages # from 'debichem' > dak override debichem-view-edit-2d metapackages # from 'debichem' > dak override debichem-semiempirical metapackages # from 'debichem' > dak override debichem-modelling metapackages # from 'debichem' > > (as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# ) Sure, but could you briefly explain the reason? -- Sean Whitton signature.asc Description: PGP signature
Bug#963831: ITP: org-roam -- non-hierarchical note-taking with Emacs Org-mode
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: org-roam Version : 1.2.0 Upstream Author : Jethro Kuan and contributors * URL : https://github.com/org-roam/org-roam * License : GPL-3+ Programming Lang: Emacs Lisp Description : non-hierarchical note-taking with Emacs Org-mode Quoting from upstream's README: Org-roam is a Roam replica built on top of the all-powerful Org-mode. Org-roam is a solution for effortless non-hierarchical note-taking with Org-mode. With Org-roam, notes flow naturally, making note-taking fun and easy. Org-roam should also work as a plug-and-play solution for anyone already using Org-mode for their personal wiki. Org-roam aims to implement the core features of Roam, leveraging the mature ecosystem around Org-mode where possible. Eventually, we hope to further introduce features enabled by the Emacs ecosystem. -- Sean Whitton signature.asc Description: PGP signature
Bug#963830: ITP: emacsql-sqlite3 -- Yet another EmacSQL backend for SQLite
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: emacsql-sqlite3 Version : 1.0.0~git20200627.1.0d5b0cf4 Upstream Author : Zhu Zihao * URL : https://github.com/cireu/emacsql-sqlite3 * License : GPL-3+ Programming Lang: Emacs Lisp Description : Yet another EmacSQL backend for SQLite Dependency of Org-roam, which I also intend to package. I have consulted upstream about whether we could avoid packaging this for Debian and patch Org-roam to use emacsql-sqlite.el, but they believe there are or will be incompatibilities. -- Sean Whitton signature.asc Description: PGP signature
Bug#963489: dgit mirror ssh wrapper breaks due to rsync update
Hello, On Thu 25 Jun 2020 at 08:25PM +01, Samuel Henrique wrote: > It is odd indeed, but I'm aware of the issue already, what happened > was that I had introduced rsync-udeb on 3.1.3-9 but then it stayed > long enough in the NEW queue that a new release happened (3.2.0) and > with this new release it came new dependencies for which there is no > udeb, I decided to revert the udeb for now so 3.2.0-1 went directly to > unstable. Sorry, please ignore my other mail. Do you want me to REJECT it from NEW? -- Sean Whitton
Bug#963489: dgit mirror ssh wrapper breaks due to rsync update
Hello, On Wed 24 Jun 2020 at 11:10PM +01, Ian Jackson wrote: > BTW I looked at > https://tracker.debian.org/pkg/rsync > and it says under "versions" >NEW/unstable: 3.1.3-9 > which is rather odd. I thought you should be told. It just means that rsync is in binary-NEW. -- Sean Whitton
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Hello, On Tue 23 Jun 2020 at 01:47AM +02, Jonas Smedegaard wrote: > Quoting Sean Whitton (2020-06-22 23:26:37) >> Would someone want to use libjs-katex without nodejs installed? > > Yes: Pandoc can produce output which uses katex rendered with the > Javascript interpreter of web browsers, not on OS-bound Javascript > rendering like Node.js. > > Currently Pandoc suggests node-katex, but pulling in Node.js is unneeded > baggage. For some users it may even be bad: Node.js may not be covered > by security support for as long as Firefox (due to the extraordinary > treatment of Firefox in stable Debian). Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. -- Sean Whitton
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Hello Pirate,
On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:
> We usually use Provides instead of splitting when we can remove the Depends
> on the interpreter. For example node-clipboard provides libjs-clipboard.js.
> This works when the node package does not ship a user facing significant
> executable. User facing executable as separate binary was recognized as a
> valid reason by CTTE in the ruling I quoted in my first reply.
>
> In case of this particular package, katex binary also provide a command line
> interface via katex command. So we cannot drop the depends on nodejs (rc bug,
> nodejs is not an optional component but the interpreter needed to run the
> katex program). Avoiding unnecessary dependency on interpreters was achieved
> in all previous instances by removing the dependency on pure libraries. We
> expect whichever user facing program depending on the library to set Depends
> on the interpreter. For example gitlab depending on nodejs is enough for
> node-clipboard to satisfy dependency on nodejs. In this case katex itself is
> a user facing program not tied to nodejs development (it is used for maths
> typesetting). So we cannot reasonably expect a user wanting to use katex will
> have nodejs installed already.
Would someone want to use libjs-katex without nodejs installed?
> I thought the CTTE guideline on this specific case of user facing executable
> was enough. They could have just asked for an explanation before rejecting.
You should ensure it's visible in the source package, in
README.{source,Debian} and/or d/changelog.
--
Sean Whitton
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
[speaking as an FTP team member, not ctte member, though this is *not* an official statement made on behalf of the whole FTP team] Hello Jonas, On Sun 21 Jun 2020 at 10:48AM +02, Jonas Smedegaard wrote: > Could you please elaborate a bit on your opinion that the introduced > split into katex and libjs-katex is unnecessary? I have not looked at this particular package, but here is what I understand to be the team's consensus: the FTP team wants to see some technical purpose which is served by the binary package split, to justify taking up more space in the Packages file. We will also object if this technical purpose could be easily served by something other than a binary package split (e.g. by adding Provides: entries). So I would assume that the FTP team member who processed this upload couldn't see how a technical purpose was being served by the split. If Pirate could explain some technical purpose that was missed that would be helpful. I don't think that the bar is particularly high here. Even if an FTP team member wouldn't themselves solve the problem by introducing a binary package split, if it's clear that the maintainer has consciously chosen to use a binary package split to solve a problem and that's a reasonable way to go about solving the problem, we'll sign off on it. -- Sean Whitton
Bug#962973: haskell-readline: Removal notice: broken and unmaintained
Hello, On Wed 17 Jun 2020 at 05:17PM -04, Joey Hess wrote: > It could be converted to haskeline or raw IO, but gnu readline is the > kind of library I think it makes sense to have language bindings to, and > to use the bindings. > > This patch seems to fix the build problem: Gratefully applying this patch and marking the upload as closing this bug, but if Ilias thinks we should still consider dropping this library for the reason that it's unmaintained, he should reopen the bug. -- Sean Whitton
Bug#962973: haskell-readline: Removal notice: broken and unmaintained
Hello, On Tue 16 Jun 2020 at 07:55PM +03, Ilias Tsitsimpis wrote: > Source: haskell-readline > Version: 1.0.3.0-9 > Severity: grave > Justification: renders package unusable > > This package seems to be unmaintained (last upstream upload in 2013). > Does not build with GHC 8.8, is not part of Stackage and has no rev > dependencies. > > I intend to remove this package. keysafe, in experimental, depends on haskell-readline. CCing upstream: Joey, do you think it would be possible for keysafe to migrate to use something maintained? -- Sean Whitton
Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
control: tag -1 +pending
Hello Ian,
On Tue 16 Jun 2020 at 12:11PM +01, Ian Jackson wrote:
> I think "native package versions" refers to "versionn numbers which
> are supposed to be Debian-native", not "the version numbers of
> native-format packages".
>
> Can I suggest that this sentence might be clarified as follows
>
> remember that hyphen (-) cannot be used in
> native {-package versions-}{+version numbers+}
>
> ?
Thanks, applied this change.
--
Sean Whitton
Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
Hello,
On Wed 11 Mar 2020 at 12:30PM GMT, Ian Jackson wrote:
> Felix Lechner writes ("Re: Bug#953554: Please permit Debian revisions with
> 1.0 native packages [and 1 more messages]"):
>> On Wed, Mar 11, 2020 at 4:58 AM Ian Jackson
>> wrote:
>> >
>> > It works today. The only problem is the lintian warning.
>>
>> Doesn't policy stand in the way too?
> ...
>> Is it permitted now? Policy 3.2.1 states "hyphen (-) cannot be used in
>> native package versions."
I believe that the relevant sentence of Policy, added in policy.git
commit eee39aecef3a6a5f9927211b5c847e645e927cbd, was intended to be
informative, not normative. It does not use one of the Policy normative
magic words, is not in the subsection in which it would be natural to
place such a restriction, and occurs in a "hey, don't forget that ..."
clause.
Thus the only Policy issue here could be the addition of an explicit
permission to use Debian revisions with 1.0 native packages. As
discussion is ongoing in the context of Lintian, that seems premature,
however.
So I think we can close the clone of this bug against Policy for now.
--
Sean Whitton
Bug#962816: ITP: emacs-pg-el -- Emacs Lisp interface for PostgreSQL
Package: wnpp Severity: wishlist Owner: Sean Whitton Control: block 962688 by -1 * Package name: emacs-pg-el Version : 0.13~git.20130731.456516ec-1 Upstream Author : Eric Marsden * URL : https://github.com/cbbrowne/pg.el * License : GPL-2+ Programming Lang: Emacs Lisp Description : Emacs Lisp interface for PostgreSQL Packaging as a dependency of emacsql, another ITP of mine. -- Sean Whitton signature.asc Description: PGP signature
Bug#962688: ITP: emacsql -- high level SQL database frontend for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: emacsql Version : 3.0.0 Upstream Author : Christopher Wellons * URL : https://github.com/skeeto/emacsql * License : Unlicense Programming Lang: Emacs Lisp & C Description : high level SQL database frontend for Emacs I'm packaging this as a dependency for another Emacs addon I'm currently trialling. I won't upload this until I'm sure I want to use that other addon or someone asks me to. Copying mfv who started salsa:emacsen-team/emacsql-el some months ago. Unfortunately I'd got further than mfv in my own Debianisation before I discovered that repo (and mfv did not file an ITP), so I'm not going to reuse any of mfv's work and will not continue his git history, unless there are objections. -- Sean Whitton signature.asc Description: PGP signature
Bug#940965: apt: Fails to find a solution for libgtk-3-0 and sysvinit-core
Hello, On Sun 22 Sep 2019 at 08:04PM +02, Simon Richter wrote: > apt's resolver does not find a working solution for installing both > libgtk-3-0 and sysvinit-core, or for installing libgtk-3-0 when > systemd-sysv has a negative score in preferences. Aptitude resolves both of > these by favouring dbus-x11 over dbus-user-session. > > When presented manually with this solution, apt accepts it as valid. The problematic dependency chain is this: libgtk-3-0 -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service -> default-dbus-session-bus | dbus-session-bus dbus-x11 Provides: dbus-session-bus, but apt prefers to replace sysvinit-core with systemd rather than just install dbus-x11. One way to reproduce this problem, in buster or sid: 1) clean chroot 2) apt-get install sysvinit-core 3) apt-get install emacs If you install dbus-x11 right before attempting to install Emacs, apt will not attempt the init system replacement. -- Sean Whitton signature.asc Description: PGP signature
Bug#961682: Dgit::upstream_commitish_search(): should fail if more than one tag found
control: tag -1 + patch Hello, On Wed 27 May 2020 at 01:55PM -07, Sean Whitton wrote: > From 0b881dddb050a7f0833bc37842082934492d23c6 Mon Sep 17 00:00:00 2001 > From: Sean Whitton > Date: Wed, 27 May 2020 13:49:07 -0700 > Subject: [PATCH] Dgit::upstream_commitish_search: fail if more than one tag > exists > > We should not assume we know which the user wants to merge, as > git-deborig does not. > > Signed-off-by: Sean Whitton Reported-by: David Bremner -- Sean Whitton signature.asc Description: PGP signature
Bug#961683: dgit-maint-debrebase(7): Drop bad advice about upstream/ tag case
Package: dgit Version: 9.10 Tags: patch X-debbugs-cc: brem...@debian.org Importing the release % git debrebase new-upstream 1.2.3 replacing 1.2.3 with upstream/1.2.3 if you imported a tarball. The first argument to the new-upstream subcommand is a version number, not a tag name, so this instruction could never have been correct. -- Sean Whitton From 2527cd10d43a8eb0319584601a1e24f447ffe221 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Wed, 27 May 2020 13:57:47 -0700 Subject: [PATCH] dgit-maint-debrebase(7): Drop bad advice about upstream/ tag case The first argument to the new-upstream subcommand is a version number, not a tag name, so this instruction could never have been correct. The user should not need usually to pass both the upstream version number and the upstream/ tag name, either, because git-debrebase should find it for them. Reported-by: David Bremner Signed-off-by: Sean Whitton --- dgit-maint-debrebase.7.pod | 2 -- 1 file changed, 2 deletions(-) diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod index 373fb2f7..fdbf2e8d 100644 --- a/dgit-maint-debrebase.7.pod +++ b/dgit-maint-debrebase.7.pod @@ -394,8 +394,6 @@ or if you have a working watch file =back -replacing I<1.2.3> with I if you imported a tarball. - This invocation of git-debrebase(1) involves a git rebase. You may need to resolve conflicts if the Debian delta queue does not apply cleanly to the new upstream source. -- 2.26.2 signature.asc Description: PGP signature
Bug#961682: Dgit::upstream_commitish_search(): should fail if more than one tag found
Package: dgit
Version: 9.10
Severity: important
X-debbugs-cc: brem...@debian.org
Hello,
Dgit::upstream_commitish_search() should fail, as git-deborig does, if
there is more than one of the three kinds of tags is looks for with the
same upstream version number.
How this can cause trouble:
% git clone https://salsa.debian.org/debian/ledger.git
% cd ledger
% git remote add github https://github.com/ledger/ledger
% git fetch --tags github
% git checkout 722a502e82b95cc928468142895101af91e45e0b
% git debrebase new-upstream 3.2.1
Actual result: debrebase merges the v3.2.1 tag.
Expected result: complain that both v3.2.1 and upstream/3.2.1 tags
exist, and ask user to supply more arguments to new-upstream
subcommand to indicate which they want to use.
Attached is a minimal fix.
--
Sean Whitton
From 0b881dddb050a7f0833bc37842082934492d23c6 Mon Sep 17 00:00:00 2001
From: Sean Whitton
Date: Wed, 27 May 2020 13:49:07 -0700
Subject: [PATCH] Dgit::upstream_commitish_search: fail if more than one tag
exists
We should not assume we know which the user wants to merge, as
git-deborig does not.
Signed-off-by: Sean Whitton
---
Debian/Dgit.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Debian/Dgit.pm b/Debian/Dgit.pm
index 5d898ae5..4e196570 100644
--- a/Debian/Dgit.pm
+++ b/Debian/Dgit.pm
@@ -634,12 +634,14 @@ sub git_check_unmodified () {
sub upstream_commitish_search ($$) {
my ($upstream_version, $tried) = @_;
# todo: at some point maybe use git-deborig to do this
+my @found;
foreach my $tagpfx ('', 'v', 'upstream/') {
my $tag = $tagpfx.(dep14_version_mangle $upstream_version);
my $new_upstream = git_get_ref "refs/tags/$tag";
push @$tried, $tag;
- return $new_upstream if length $new_upstream;
+ push @found, $tag if $new_upstream;
}
+return $found[0] if @found == 1;
}
sub resolve_upstream_version ($$) {
--
2.26.2
signature.asc
Description: PGP signature
Bug#961435: ITP: ggtags -- improved Emacs interface to GNU GLOBAL
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: ggtags Version : 0.8.13 Upstream Author : Leo Liu * URL : https://github.com/leoliu/ggtags * License : GPL-3+ Programming Lang: Emacs Lisp Description : improved Emacs interface to GNU GLOBAL GNU GLOBAL comes with gtags.el, but ggtags.el is a fair bit easier to use. It can automatically invoke gtags(1) for you, and its default keybindings are more intuitive, at least for me. -- Sean Whitton signature.asc Description: PGP signature
Bug#959506: git-annex: `git annex add` sometimes treats non-dotfiles in dotdirs as dotfiles
control: tag -1 + upstream moreinfo Dear Marco, On Sat 09 May 2020 at 12:39AM +02, Marco Ricci wrote: > Granted. I did however submit to my distro's tracker first to eliminate > the case of this being Debian's fault due to a distro-specific patch, as > I know happens with some other packages. Sadly, I lack the technical > knowledge to verify by myself whether this is indeed the case. I also > assumed that if this turned out not to be a Debian-specific complaint, > then someone would forward to or request resubmission on git-annex's > tracker. I take it that I have permission (or encouragement, or > whatever) to do so now. The issue is not really actionable at the distro level -- we wouldn't add a patch to change this behaviour. So it sounds like the discussion should indeed be moved to the upstream bug tracker. -- Sean Whitton signature.asc Description: PGP signature
Bug#959909: debian-policy: complete implementation of ctte decision to forbid vendor-specific series files
Package: debian-policy Version: 4.5.0.2 Tags: patch Hello, Quoting from #904302: > The Committee therefore resolves that: > > 1. Any use of dpkg's vendor-specific patch series feature is a bug for >packages in the Debian archive (including contrib and non-free). > >This should be implemented in Debian Policy by declaring that a >package SHOULD NOT contain a non-default series file. > > 2. After Buster is released, use of the vendor-specific patch series >feature is forbidden in the Debian archive. > >This should be implemented in Debian Policy by declaring that a >package MUST NOT contain a non-default series file. Here is a patch to finish implementing this; I am seeking seconds: diff --git a/policy/ch-source.rst b/policy/ch-source.rst index 1a4e871..58da61e 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -811,8 +811,8 @@ Vendor-specific patch series Packages in the Debian archive using the 3.0 (quilt) source package -format should not contain a non-default series file. That is, there -should not exist a file ``debian/patches/foo.series`` for any ``foo``. +format must not contain a non-default series file. That is, there +must not exist a file ``debian/patches/foo.series`` for any ``foo``. .. [#] Rationale: diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst index 2a8cc99..cae05c7 100644 --- a/policy/upgrading-checklist.rst +++ b/policy/upgrading-checklist.rst @@ -39,6 +39,18 @@ The sections in this checklist match the values for the except in the two anomalous historical cases where normative requirements were changed in a minor patch release. +Version 4.5.1 +- + +Unreleased. + +4.17 +Packages must not contain a non-default series file. That is, +dpkg's vendor-specific patch series feature must not be used for +packages in the Debian archive. + +(previously a "should not") + Version 4.5.0 - -- Sean Whitton signature.asc Description: PGP signature
Bug#959759: dgit-maint-merge(7): Mention --allow-unrelated-histories
Hello, On Tue 05 May 2020 at 12:19PM +01, Ian Jackson wrote: > I think git has pretty much always wanted --allow-unrelated-histories > for this situation. The safety catch is there to stop you > accidentally making a frankenproject, but that doesn't apply here. Actually only since 2016 (git 2.9). > If the upstream directory had a debian/ directory I think this rune > will do something strange to the resulting debian/. In the general > case I think the merge algorithm with unrelated histories is not > correct for upstream files either; eg if you have made changes to > upstream files something might go wrong. > > My approach in these situations is: > 1. make a branch of the Debian package of the old upstream > (ie that has the contents corresponding to the Debian > package of the old upstream) but which has the right > upstream as an ancestor. > git merge -s ours --allow-unrelated-histories v0.14.0 > 2. git merge will now DTRT if we git merge v0.14.1 and do > a three-way merge Is this what you mean: % dgit clone libopencsd % cd libopencsd % # add and fetch upstream remote % git merge -s ours --allow-unrelated-histories v0.14.0 % git merge v0.14.1 This is better than my patch. If you could confirm, I can prepare a new patch. -- Sean Whitton signature.asc Description: PGP signature
Bug#959760: dgit-maint-{merge,rebase}(7): See also git-revisions(7)
Package: dgit
Version: 9.10
Hello,
For help understanding some of the advanced git commands presented.
--
Sean Whitton
From 9fa8141cf5e19f469c27c218c7378e9b3e87cf2e Mon Sep 17 00:00:00 2001
From: Sean Whitton
Date: Mon, 4 May 2020 17:27:01 -0700
Subject: [PATCH] dgit-maint-{merge,rebase}(7): See also git-revisions(7)
For help with some of the advanced git commands presented.
Signed-off-by: Sean Whitton
---
dgit-maint-debrebase.7.pod | 2 +-
dgit-maint-merge.7.pod | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 373fb2f7..67ef0870 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -781,7 +781,7 @@ See also "ILLEGAL OPERATIONS" in git-debrebase(5).
=head1 SEE ALSO
-dgit(1), dgit(7), git-debrebase(1), git-debrebase(5)
+dgit(1), dgit(7), git-debrebase(1), git-debrebase(5), git-revisions(7)
=head1 AUTHOR
diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index c3931ebe..d675a6dd 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -526,7 +526,7 @@ next push will then require I<--overwrite>.
=head1 SEE ALSO
-dgit(1), dgit(7)
+dgit(1), dgit(7), git-revisions(7)
=head1 AUTHOR
--
2.26.2
signature.asc
Description: PGP signature
