Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python3-mergedeep Version : 1.3.4 Upstream Author : Travis Clarke * URL : https://github.com/clarketm/mergedeep * License : MIT Programming Lang: Python Description : A deep merge function for Python Includes four merge strategies: ## Replace When destination and source keys are the same, replace the destination value with one from source (default). ## Additive When destination and source values are both the same additive collection type, extend destination by adding values from source. Additive collection types include: list, tuple, set, and Counter ## Typesafe replace When destination and source values are of different types, raise TypeError. Otherwise, perform a REPLACE merge. ## Typesafe additive When destination and source values are of different types, raise TypeError. Otherwise, perform a ADDITIVE merge. This is a dependency of the datasette tool by Simon Willison. I plan to maintain this package as part of the python modules team.
Re: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
Quoting Thomas Goirand (2022-02-26 00:08:47) > On 2/25/22 11:38, Philip Hands wrote: > > Having looked at how it was done, I applaud Andreas for doing a > > proper job. > > +1 > > Anyone complaining about this kind of contribution to Debian is a > moron and a barrier to progress. We really need to get rid of this > toxic mentality in Debian. I wonder who the fuck¹ you might be babbling about above - clearly not the kind of "toxic" person "complaining" like this: Quoting Jonas Smedegaard (2022-02-25 12:03:20) > In other words, I think what was done here was a "proper NMU" (just > not a simple one). > > > Thanks for the NMU, Andreas, > Jonas, I strongly disagree with using this type of example like you > just did in this thread. In many cases, switching from long-form dh to > short form is by the way a very nice improvement (if the result is > obviously very minimal, as opposed to a very verbosy-for-nothing long > form, for example). Though you've decided to take the extreme example > when one is strongly opposed to short-form dh, because of "packaging > style". So IMO, your reply is inappropriate, we should only give > encouragements to Andreas, and welcome progress. You seem to have totally missed my point. I am very sorry that I have failed at getting it across to you, so let me try once more... I agree that switching from long-form dh to short-form dh is in many (possibly all) cases a "very nice improvement". But that is missing the point! Point is if it is ok to remove packaging smell as part of an NMU. It does not matter if current maintainer is strongly opposed to or wildly in love with short-form dh. What matters is that an NMU is work done without coordination of the package maintainer. Purpose of an NMU is not to make "a very nice improvement" but to make as minimal as possible change to a package, because someone else is maintaining that package and should be *aided* in *their* maintenance, not coerced into doing things differently. When Andreas asks a question We certainly should not *only* give encouragement. We should *also* appreciate Andreas' work, but we should try answer his question. We should *not* welcome progress *IN AN NMU*. Because that's the wrong place for progress! - Jonas ¹ I apologize ahead to anyone feeling offended by my choice of words there - was a minimal way for me to to let out steam for whas I perceive as an unfounded personal attack unworthy of further elaboration but also unacceptable for me to silently ignore. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1006501: ITP: snpsift -- tool to annotate and manipulate genome variants
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: snpsift Version : 5.1 Upstream Author : Pablo Cingolani * URL : https://pcingola.github.io/SnpEff/ss_introduction/ * License : Expat Programming Lang: Java Description : tool to annotate and manipulate genome variants SnpSift is a toolbox that allows one to filter and manipulate annotated files. Once the genomic variants have been annotated, one needs to filter them out in order to find the "interesting / relevant variants". Given the large data files, this is not a trivial task (e.g. one cannot load all the variants into XLS spreadsheet). SnpSift helps to perform this VCF file manipulation and filtering required at this stage in data processing pipelines. The package will be team-maintained by Debian-med team.
Re: DD(s) to help DM land some long-overdue package updates?
On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > > Having just now got the new Debian packaging building without error, I > shall now follow the ITS procedure and see what happens! > I have waited 8 days since posting debdiffs, and had no response, so I've now filed an ITS bug: #1006481. -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
Le 26 février 2022 16:28:18 GMT+01:00, Reuben Thomas a écrit : >On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > >> >> Having just now got the new Debian packaging building without error, I >> shall now follow the ITS procedure and see what happens! >> > >I have waited 8 days since posting debdiffs, and had no response, so I've >now filed an ITS bug: #1006481. > >-- >https://rrt.sc3d.org ACK ! -- Pierre-Elliott Bécue From my phone
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, gh package maintainer Axel Beckert 於 2022年2月16日 週三 下午2:15寫道： > Package: gh,gitsome > Severity: serious > Control: found -1 gitsome/0.8.0+ds-6 > Control: found -1 gh/2.4.0+dfsg1-1 > > Hi, > > installing gh fails for me as follows: > > Unpacking gh (2.4.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-DkqFj5/24-gh_2.4.0+dfsg1-1_amd64.deb (--unpack): > trying to overwrite '/usr/bin/gh', which is also in package gitsome > 0.8.0+ds-6 > According to the Debian policy [1], "the two different packages must not install programs with different functionality but with the same filenames. ... If this case happens, one of the programs must be renamed." [1] https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries The "gitsome" has used "gh" since 2017, and thus would you mind renaming the "gh" in your package to avoid the conflict issue? I would appreciate it if you could consider my request, and feel free to let me know if you have another proposal. Regards, SZ > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (990, 'unstable'), (600, 'testing'), (500, > 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, > 'experimental-debug'), (1, 'buildd-experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled >
Bug#1006514: ITP: termpaint -- low level terminal access
X-Debbugs-Cc: debian-devel@lists.debian.org, textsh...@uchuujin.de Subject: ITP: termpaint -- low level terminal access Package: wnpp Owner: Christoph Hueffelmann Severity: wishlist * Package name: termpaint Version : 0.3.0 Upstream Author : Martin Hostettler * URL : https://github.com/termpaint/termpaint * License : BSL-1.0 Programming Lang: C, C++ Description : low level terminal access Termpaint is a low level terminal interface library for character-cell terminals in the tradition of VT1xx (like xterm, etc). It’s designed to be portable and flexible to integrate. It covers event handling and rendering.
Bug#1006521: ITP: ttyplot -- realtime plotting utility for text mode consoles and terminals
Package: wnpp Severity: wishlist Owner: Daniel Leidert X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ttyplot Version : 1.4 + git commits since then Upstream Author : Antoni Sawicki * URL : https://github.com/tenox7/ttyplot * License : Apache-2.0 Programming Lang: C Description : realtime plotting utility for text mode consoles and terminals ttyplot takes data from standard input or a unix pipeline and plots in text mode on a terminal in real time. It supports rate calculation for counters and up to two graphs on a single display using reverse video for the second line. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmIaaxIACgkQS80FZ8KW 0F1OgA//bAlGNJgjWrXdne+rtJfFHvL5naGYCkW/e7vStspw1kl81/gtJ4s/mMNe U2qEkTPy6+oUQk/9Khb0liH9tE3h+dIaMFak0u+FSWle4DMcau9CI0rsQOYi6mYz d6AZz02vbHezxMUR9oWKASqOIl6PyMF0fcdFzfanT900n4GfAyCzjlS4hAkxqd92 VDfQ6PcXUeOYTG7X/5FfQZtkfjFqW4OUIUaDAfJE4IoFy7LqVLKG1JsBXMGIzBqK UF3KzG1+p1G+l12sHM4ENPKB2/5v1g6tcDcs8aez+XF/LvGIkS+gd+g1n4l1esYj S8A7b5WspJXyLclu2RMsDta7R/Mp0WUfp5R5h7FYJgohGMiXtO87wzSkmquudL14 lxXifQj+mJjJ8D3/5GIMP4wMvYHEHoQ0I4rayJyIKPNvDpnnv1zV2o6nVNou+CCr GR3lCBspCdY1xuIpidmC+udhdZnyQ0lfoXAOUu/lAOcjt7fmQGE4Ht+cHkMU4sh1 FV6p19jkdIdScxvkbs58H0AYOpPTs/yci+Ol/RnbTGJfZerc+GpBenv75VGcWtXZ hGJwgSETXFd05+YN6tvLuLuxLHIpKknjec2DjqW3KCIUxOPK2ibLZRJ2BX3g2/RA GJ/OA45hiXlJTSlQygMmluq4N8PD6ijauWY1YpD8RCxkih/iV5o= =F4oI -END PGP SIGNATURE-
Re: MBF: valgrind-if-available
On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote: > On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote: > > On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski wrote: > > > The correct answer currently is: > > > [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] > > > but it keeps changing, and you don't want to track it by hand if I can do > > > that for you. > > > > > > Thus: please [b-]depend on valgrind-if-available. > > > Do you have any suggestions on how to handle this when the valgrind > > test is set by a configure flag? > > Is the configure flag required to enable valgrind tests? If not, the very > point of "configure" scripts is to auto-detect presence of tools. > > > The way I've been handling it is to just keep a hard-coded list of > > valgrind architectures in sync between my debian/control and > > debian/rules. > > if which valgrind >/dev/null; then This should use "command -v", not which, I think? Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > The "gitsome" has used "gh" since 2017, and thus would you mind renaming > the "gh" in your package to avoid the conflict issue? Since gh is the official GitHub client, probably it should retain "gh" and gitsome should move to "git some" or similar, as I have suggested in the above upstream issue. The only commentor there agreed with me. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: MBF: valgrind-if-available
On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote: > On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote: > > if which valgrind >/dev/null; then > > This should use "command -v", not which, I think? No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice. Among others, "command -v" * gets confused by aliases * it fails to check +x perm both in dash and bash. While this is something required by POSIX, neither shell in unstable checks that, reporting the command as executable if it's not. * built-ins get reported as available. And busybox has even "dpkg" built-in, with a pretty bad implementation. while the only reason to migrate was: * one less tool to maintain Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: MBF: valgrind-if-available
On Sun, Feb 27, 2022 at 03:40:09AM +0100, Adam Borowski wrote: > No, and the recent debacle revealed enough reasons that I'm pondering a MBF > to change that _back_ in packages which followed the bad advice. do you have a # as a starter? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Alles weird gut. signature.asc Description: PGP signature
Re: MBF: valgrind-if-available
On 2022-02-27 Adam Borowski wrote: > On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote: [...] >> This should use "command -v", not which, I think? > No, and the recent debacle revealed enough reasons that I'm pondering a MBF > to change that _back_ in packages which followed the bad advice. > Among others, "command -v" > * gets confused by aliases > * it fails to check +x perm both in dash and bash. While this is something > required by POSIX, neither shell in unstable checks that, reporting the > command as executable if it's not. > * built-ins get reported as available. And busybox has even "dpkg" > built-in, with a pretty bad implementation. [...] Hello, Is any of this relevant in the context Debian package building (especially by autobuilders)? The only thing I can see is if $developer had a nonexec ~/bin/somecommand and wondered why the local behavior differed from the autobuilders. Aliases are a non-issue. Built-ins (like command -v) actually are available, and when the respective command is called the builtin will be used. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
