Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Ian Jackson writes: > Adrian Bunk writes: > > I thought this would would have been less offensive than the normal > > "This is a lie." > > You should never accuse someone of lying unless you are sure that they > know that what they are saying is wrong. For Adrian (since you acknowledged non-native English language status): Ian is pointing out the distinction between “That is a lie” (asserting the person knowingly intended to communicate a falsehood), versus alternatives like “That is false” or “That is not true” (which carries no implication of the person's intention or state of mind). > If you can prove that someone is deliberately saying untrue things on > Debian lists, that is abuse which should be reported and stopped. If you don't want to support a claim that someone is lying, you can avoid that implication: Just point out that the statement is not true (and then do as you (Adrian) did to show how you know it's not true). I hope that helps! -- \“Considering the current sad state of our computer programs, | `\ software development is clearly still a black art, and cannot | _o__) yet be called an engineering discipline.” —Bill Clinton | Ben Finney
Re: Limiting the size of installed changelogs
On Thu, 13 Sep 2018 11:22:37 +0100, Ben Hutchings wrote: >The src:linux package has a very big changelog (about 1700 kiB >uncompressed, 600 kiB gzipped). On my system the largest installed >changelogs, by some way, are all versions of this. (The next largest >changelogs come from src:glibc, at about 200 kiB gzipped.) A local admin could choose to tell dpkg to not install /usr/share/doc/*/*changelog* via the path-exclude option. Alas, I have not been able to get this to work when I last tried that two and a half years ago. The corresponding wishlist bug was a five-digit number bug from the last millennium. Has anybody gotten dpkg path-exclude to work? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Limiting the size of installed changelogs
On Fri, 14 Sep 2018, Marc Haber wrote: > Has anybody gotten dpkg path-exclude to work? Yes. It's been a long time that I have not used it but the main problem is that to be effective the option must be used right from the start (i.e. already at the debootstrap stage) otherwise you have to manually cleanup the excluded files (at the time when you put the option in dpkg's configuration file). (I don't remember if reinstalling all the packaes achieves the desired result too) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Limiting the size of installed changelogs
On Fri, 14 Sep 2018 13:58:40 +0200, Raphael Hertzog wrote: >On Fri, 14 Sep 2018, Marc Haber wrote: >> Has anybody gotten dpkg path-exclude to work? > >Yes. It's been a long time that I have not used it but the main problem >is that to be effective the option must be used right from the start (i.e. >already at the debootstrap stage) otherwise you have to manually cleanup >the excluded files (at the time when you put the option in dpkg's >configuration file). And even in debootstrap phase 1 when dpkg is not even used yet, right. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: [Delayed] Summary of the web team BoF at DC18
On Thu, Sep 13, 2018 at 04:02:15AM +0100, Steve McIntyre wrote: > * Build using GitLab CI? (this looks quite difficult! proposals welcome > :-)) No it's not :-) I'm willing to look into this. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#908825: ITP: shadowsocks-qt5 -- Cross-platform shadowsocks GUI client
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: shadowsocks-qt5 Version : 3.0.1 Upstream Author : Symeon Huang * URL : https://github.com/shadowsocks/shadowsocks-qt5 * License : LGPL-3+ Description : Cross-platform shadowsocks GUI client Shadowsocks-Qt5 is a native and cross-platform shadowsocks client with GUI, tray icon support and many advanced features. It can communicate with servers using shadowsocks protocol to bypass firewalls and encrypt data transmission. I intend to co-maintain this package inside Debian Bridges Team. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Adam Borowski wrote on 14/09/2018: > On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote: >>> For example, in the Rust team, we have been discussing about packaging >>> fd (a find alternative developed using rust [1]). We are planning to >>> install it in /usr/bin/fd .. but this conflicts with something >>> completely different, fdclone a clone of fd, a MS-DOS file browser... >> >> fdclone isn't a shell utility, you just start it once, then you use its >> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a >> problem at all > > It _already_ is a symlink pair between "fd" and "fdsh". For the executable, > "fd" is the master, "fdsh" the slave, the man page prefers "fdsh". I am the prospect maintainer of fd-find; thanks for spotting this. I will ask the current maintainer of fdclone if he's willing to drop the 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links). Shouldn't this be possible, I'll install the fd-find binary and man as: /usr/share/fd-find/bin/fd /usr/share/fd-find/man/man1/fd.1.gz and provide the convenience symlinks: /usr/bin/fdfind -> /usr/share/fd-find/bin/fd /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz Does this sound reasonable? Paride
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Paride Legovini writes: > Adam Borowski wrote on 14/09/2018: >> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote: For example, in the Rust team, we have been discussing about packaging fd (a find alternative developed using rust [1]). We are planning to install it in /usr/bin/fd .. but this conflicts with something completely different, fdclone a clone of fd, a MS-DOS file browser... >>> >>> fdclone isn't a shell utility, you just start it once, then you use its >>> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a >>> problem at all >> >> It _already_ is a symlink pair between "fd" and "fdsh". For the executable, >> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh". > > I am the prospect maintainer of fd-find; thanks for spotting this. I > will ask the current maintainer of fdclone if he's willing to drop the > 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links). > Shouldn't this be possible, I'll install the fd-find binary and man as: > > /usr/share/fd-find/bin/fd > /usr/share/fd-find/man/man1/fd.1.gz > > and provide the convenience symlinks: > > /usr/bin/fdfind -> /usr/share/fd-find/bin/fd > /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz > > Does this sound reasonable? It strikes me as rather presumptious to be trying to grab a new two letter command at this point in the history of *nix (particularly when it is already in use). Personally, I'll never willingly install a binary named that, because it seems very likely to tickle my dyslexia. I'd expect it to make me very grumpy if I ever have to maintain a script that includes references to both df and fd nearby one another. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#908837: ITP: python-grpc-tools -- Protobuf code generator for gRPC
Package: wnpp Severity: wishlist Owner: la...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-grpc-tools Version : 1.14.1-1 * URL : https://grpc.io/ * License : Apache-2.0 Programming Lang: Python/C++ Description : Protobuf code generator for gRPC (Python 3) gRPC is a modern open source high performance RPC framework. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checkin and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. This package installs the Protobuf code generator for Python 3. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Hello, On Fri 14 Sep 2018 at 07:13PM +0200, Paride Legovini wrote: > and provide the convenience symlinks: > > /usr/bin/fdfind -> /usr/share/fd-find/bin/fd > /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz > > Does this sound reasonable? Assuming this is a arch-dependent binary (since it's written in rust), /usr/lib rather than /usr/share. And ISTM it should be /usr/lib/fdfind not /usr/lib/fd-find but maybe I'm missing something. -- Sean Whitton signature.asc Description: PGP signature
Bug#908848: ITP: python-fleetspeak -- Framework for communicating with a fleet of machines
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: python-fleetspeak Version : 0.0.7 Upstream Author : Google * URL or Web page : https://pypi.org/project/fleetspeak/ * License : Apache-2.0 Description : Framework for communicating with a fleet of machines This package will be needed for a GRR upgrade.
