Bug#1027779: ITP: receptor -- Link controllers with executors across a mesh of nodes
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: receptor Version : 1.3.0 Upstream Contact: https://github.com/ansible/receptor/issues * URL : https://github.com/ansible/receptor * License : Apache-2.0 Programming Lang: golang Description : Link controllers with executors across a mesh of nodes Receptor is an overlay network intended to ease the distribution of work across a large and dispersed collection of workers. Receptor nodes establish peer-to-peer connections with each other via existing networks. Receptor comes as daemon and a python client. This package provides the daemon. It is a crucial part of ansible/awx, see also https://bugs.debian.org/908763 Current packaging work is available at https://salsa.debian.org/go-team/packages/receptor.git
Bug#1027770: ITP: python-hatch-requirements-txt -- Read dependencies from requirements-txt
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-hatch-requirements-txt Version : 0.3.0 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/repo-helper/hatch-requirements-txt * License : MIT/expat Programming Lang: Python Description : Read dependencies from requirements-txt This module required for packing python-apeye-core: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027765 Where python-apeye-core dependency is needed to package python-apeye https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027764 Where the python-apeye dependency is needed for packaging: python-shippinglabel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763 Which in turn is a required dependency for the package. python-coincidence: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481 Note: python-coincidence is needed to run all tests in these packages: * python-dom-toml * python-consolekitm * python-dist-meta * python-shippinglabel * python-apeye * python-apeye-core * domdf-python-tools * python-shippinglabel All under ITPs.
Re: setting sysctl net.ipv4.ping_group_range
On Jan 03, Adam Borowski wrote: > Debian's default sysctl settings should reside in procps (as it owns > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated > package. Nowadays systemd is a source of common sysctl settings among different distributions. -- ciao, Marco signature.asc Description: PGP signature
Bug#1027765: ITP: python-apeye-core -- Main function of apeye library
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-apeye-core Version : 1.1.0 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/domdfcoding/apeye-core * License : BSD 3-Clause Programming Lang: Python Description : Main function of apeye library module needed to package python-apeye https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027764 Where python-apeye is required dependency for packaging: python-shippinglabel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763 Which in turn is a required dependency for the package. python-coincidence: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481
Bug#1027764: ITP: python-apeye -- Handy tools for working with URLs and APIs
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-apeye Version : 1.3.0 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/domdfcoding/apeye * License : LGPL-3+ Programming Lang: Python Description : Handy tools for working with URLs and APIs module needed to package python-shippinglabel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763 Which in turn python-shippinglabel is needed for packaging: python-coincidence: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481
Bug#1027763: ITP: python-shippinglabel -- Utilities for handling packages
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-shippinglabel Version : 1.4.1 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/domdfcoding/shippinglabel * License : MIT/expat Programming Lang: Python Description : Utilities for handling packages module needed to package python-coincidence https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481
Re: setting sysctl net.ipv4.ping_group_range
On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote: > On Jan 02, Noah Meyerhans wrote: > > I'm entirely happy to reassign this request to systemd and have the > > setting applied more broadly. > Some options: > - conflict with systemd < version_with_the_new_default > - wait for a full release and then just drop it > - when sysctl in postinst reports the new default > - a mix of the last two options Debian's default sysctl settings should reside in procps (as it owns /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated package. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Noah Meyerhans wrote: > I'm entirely happy to reassign this request to systemd and have the > setting applied more broadly. The question that arises then is what to > do about the file-level capabilities on the ping binary. Ideally we > drop them entirely (including the setuid fallback), but when? Some options: - conflict with systemd < version_with_the_new_default - wait for a full release and then just drop it - when sysctl in postinst reports the new default - a mix of the last two options I suggest that you improve the ping error message to also mention the sysctl (or maybe an appropriate writeup in README.Debian?). -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 10:09:44PM +0100, Marco d'Itri wrote: > > With that in place, unprivileged users are able to excute ping for both > > IPv4 and IPv6 targets without cap_net_raw (currently set as either a > > file-based attribute on the ping binary or acquired via setuid). But > > since that applies system-wide, not just to the ping binary, there may > > be objections. > I do not think that the submitter made clear why this would be > preferable, so I had to research it myself. See: > > https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange > https://github.com/systemd/systemd/pull/13141 > > Since this is one of the systemd sysctl defaults (of which I think that > we should adopt more, especially the network-related ones!) I agree with > changing this. > I would just do it in the systemd package package to allow all packages > to benefit from it without having to care if ping is installed. I'm entirely happy to reassign this request to systemd and have the setting applied more broadly. The question that arises then is what to do about the file-level capabilities on the ping binary. Ideally we drop them entirely (including the setuid fallback), but when? I could leave things completely decoupled, and simply wait until systemd makes the change and then upload iputils and assume that anybody upgrading iputils is also upgrading systemd. That seems to be what Fedora did, according to the fedoraproject.org wiki cited above. Alternatives would seem to involve some level of versioned dependency, which doesn't feel right. noah
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 10:11:38PM +0100, Marco d'Itri wrote: > On Jan 02, Peter Pentchev wrote: > > > I personally would prefer giving the administrator a way to change that. > > Maybe add a low priority debconf question with a "ping is not setuid" > > default, then mention that debconf setting in a comment in the file that > > the package installs in the sysctl.d/ directory. > Please don't. There are already way too many debconf questions and this > one would be totally pointless: anybody who cares to change the default > can just locally override the /usr/lib/sysctl.d/ file with a drop-in in > /etc/sysctl.d/ . +1. I don't have any desire to add debconf to iputils-ping. I'd suggest the /etc/sysctl.d/ approach for admin overrides as well. noah
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Noah Meyerhans wrote: > With that in place, unprivileged users are able to excute ping for both > IPv4 and IPv6 targets without cap_net_raw (currently set as either a > file-based attribute on the ping binary or acquired via setuid). But > since that applies system-wide, not just to the ping binary, there may > be objections. I do not think that the submitter made clear why this would be preferable, so I had to research it myself. See: https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange https://github.com/systemd/systemd/pull/13141 Since this is one of the systemd sysctl defaults (of which I think that we should adopt more, especially the network-related ones!) I agree with changing this. I would just do it in the systemd package package to allow all packages to benefit from it without having to care if ping is installed. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Peter Pentchev wrote: > I personally would prefer giving the administrator a way to change that. > Maybe add a low priority debconf question with a "ping is not setuid" > default, then mention that debconf setting in a comment in the file that > the package installs in the sysctl.d/ directory. Please don't. There are already way too many debconf questions and this one would be totally pointless: anybody who cares to change the default can just locally override the /usr/lib/sysctl.d/ file with a drop-in in /etc/sysctl.d/ . > Other than that, I think making ping not setuid is a great idea. ping is (generally) not setuid. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote: > There are several examples of packages installing files to > /usr/lib/sysctl.d, but I haven't found any specific guidance on policies > about what's appropriate for them. Since sysctl variables change the > system behavior in a way that's not limited to the package changing the > setting, and since the package in question (iputils-ping) is Priority: > important and part of the default install, I won't want to make any > changes without consulting here first. [snip] > After applying this change, I believe it'd be appropriate to drop ping's > setcap/setuid settings from postinst altogether, though I'd be open to > other options. [2] I personally would prefer giving the administrator a way to change that. Maybe add a low priority debconf question with a "ping is not setuid" default, then mention that debconf setting in a comment in the file that the package installs in the sysctl.d/ directory. Other than that, I think making ping not setuid is a great idea. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
setting sysctl net.ipv4.ping_group_range
There are several examples of packages installing files to /usr/lib/sysctl.d, but I haven't found any specific guidance on policies about what's appropriate for them. Since sysctl variables change the system behavior in a way that's not limited to the package changing the setting, and since the package in question (iputils-ping) is Priority: important and part of the default install, I won't want to make any changes without consulting here first. See bug #1008281 for context. [1] The proposal is to install /usr/lib/sysctl.d/iputils-ping.conf with the following content: net.ipv4.ping_group_range="0 2147483647" With that in place, unprivileged users are able to excute ping for both IPv4 and IPv6 targets without cap_net_raw (currently set as either a file-based attribute on the ping binary or acquired via setuid). But since that applies system-wide, not just to the ping binary, there may be objections. After applying this change, I believe it'd be appropriate to drop ping's setcap/setuid settings from postinst altogether, though I'd be open to other options. [2] noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008281 2. https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst
Re: Help setting dbconfig-common for MariaDB, not MySQL
On Mon 02/Jan/2023 16:31:17 +0100 Paul Gevers wrote: Hi Alessandro, Hi, thanks for replying. On 02-01-2023 14:21, Alessandro Vesely wrote: please pardon my ignorance about Debian install. I'm distributing a software which could use various DBMS'es by setting a number of parameters. Example parameters are only given for MariaDB. I distribute a debian/ directory that Debian users can use to prepare a package instead of configure, make, make install. However, the debian/postinst supports MariaDB only. Do I understand you correctly that you don't want to support MySQL? Yes, it'd be too much work to create, test, and debug the settings for an alternative DBMS. A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must? (It's an example after all?) Well the reference example started using INET6 a few years ago, to store both IPv4 and IPv6 addresses. It simplified settings somewhat. Reverting to the previous state is too bad. A user needing to work with MySQL can replace INET6 with a suitable BLOB, and change all the related queries and configs accordingly. The existing debian/postinst won't work in that case. It could be easily adapted, IF the relevant queries and configs were given... Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the Debian clause in debian/control. I think that's wrong. At least it would fail to install dbconfig-common in case there is a mariadb-client installed. Also, I wonder about the mariadb-server part. mariadb-server depends on the versioned mariadb-server-* package which depends on the versioned mariadb-client-* package. So in case mariadb-client wouldn't be able to be fulfilled, mariadb-server as the second alternative isn't going to help. And in my opinion you should not depend on the server part. As with most databases, the server part can live on a different host and package should really not force the server to be on the same host. Would "mariadb-client | dbconfig-no-thanks" work? But see below. I'm not clear how I could add an (optional) Conflicts mysql-something, also because I see no mysql-server in the package cache. mysql-server is available in unstable, but we don't want to support both MySQL and MariaDB in Debian stable at the same time, so currently MySQL is blocked from migration. However, derivatives choose differently (Ubuntu supports MySQL in their releases). Indeed, the user who complained was on Ubuntu 22.04 and MySQL version 8.0.23. He asked me to add MariaDB to the list of requirements. Perhaps he can install requirements according to what I write in debian/control Depend. If I only require mariadb-client and then the server is MySQL, it won't run. Is there a way to fail if a user chooses to install the DB but MariaDB is missing? Or is the above enough? I don't think you can do it with dependencies. If you really want to go this route, you have to detect it during run time. Yeah, not very nice, but still better to discover it at runtime. The database creation with INET6 types will fail on Ubuntu. Than
Re: Help setting dbconfig-common for MariaDB, not MySQL
Hi Marc, On 02-01-2023 16:58, Marc Haber wrote: On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers wrote: On 02-01-2023 14:21, Alessandro Vesely wrote: A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must? (It's an example after all?) It is. We need to stop having "disable IPv6" as measure 1 if something doesn't work right. It's the default IP protocol for a decade. Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 type" in the context of MariaDB is a MariaDB specific implementation of something? (Sorry, I didn't investigate and assumed the latter). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Help setting dbconfig-common for MariaDB, not MySQL
On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers wrote: >On 02-01-2023 14:21, Alessandro Vesely wrote: >> A user complained that MySQL doesn't work, because it misses the INET6 >> type that the example settings use. > >And is this an absolute must? (It's an example after all?) It is. We need to stop having "disable IPv6" as measure 1 if something doesn't work right. It's the default IP protocol for a decade. 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: Help setting dbconfig-common for MariaDB, not MySQL
Hi Alessandro, On 02-01-2023 14:21, Alessandro Vesely wrote: please pardon my ignorance about Debian install. I'm distributing a software which could use various DBMS'es by setting a number of parameters. Example parameters are only given for MariaDB. I distribute a debian/ directory that Debian users can use to prepare a package instead of configure, make, make install. However, the debian/postinst supports MariaDB only. Do I understand you correctly that you don't want to support MySQL? Or that you don't know how to support both at the same time? Most packages in Debian that are using MariaDB or MySQL can easily support both (hence we have the default-mysql-client and virtual-mysql-client packages), and indeed dbconfig-common treats them as equal. A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must? (It's an example after all?) Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the Debian clause in debian/control. I think that's wrong. At least it would fail to install dbconfig-common in case there is a mariadb-client installed. Also, I wonder about the mariadb-server part. mariadb-server depends on the versioned mariadb-server-* package which depends on the versioned mariadb-client-* package. So in case mariadb-client wouldn't be able to be fulfilled, mariadb-server as the second alternative isn't going to help. And in my opinion you should not depend on the server part. As with most databases, the server part can live on a different host and package should really not force the server to be on the same host. I'm not clear how I could add an (optional) Conflicts mysql-something, also because I see no mysql-server in the package cache. mysql-server is available in unstable, but we don't want to support both MySQL and MariaDB in Debian stable at the same time, so currently MySQL is blocked from migration. However, derivatives choose differently (Ubuntu supports MySQL in their releases). As mentioned above, the server part can be on a different host, but ependencies are not able to describe incompatibility with what runs on the other host. Is there a way to fail if a user chooses to install the DB but MariaDB is missing? Or is the above enough? I don't think you can do it with dependencies. If you really want to go this route, you have to detect it during run time. Paul OpenPGP_signature Description: OpenPGP digital signature
Help setting dbconfig-common for MariaDB, not MySQL
Hi, please pardon my ignorance about Debian install. I'm distributing a software which could use various DBMS'es by setting a number of parameters. Example parameters are only given for MariaDB. I distribute a debian/ directory that Debian users can use to prepare a package instead of configure, make, make install. However, the debian/postinst supports MariaDB only. A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the Debian clause in debian/control. I'm not clear how I could add an (optional) Conflicts mysql-something, also because I see no mysql-server in the package cache. Is there a way to fail if a user chooses to install the DB but MariaDB is missing? Or is the above enough? Thanks in advance for any hint Ale --
Belle année de la part de l'équipe 12H07
Bonjour, Le spécialiste du marketing opération pour les marchés IT et RH, vous souhaite un bon cru pour cette nouvelle années 2023. Vous retrouverez sur notre site, la totalité de nos offres en bases de données btob (avec actuellement une remise), nos webinaires commerciaux et emailing pour vendre vos offres IT. Bien cordialement Le service Marketing SAS 12H07 2162, route du Plateau - 47200 Marcellus Poste direct :09 80 88 02 24/GSM: 06 20 59 35 92 - https://12h07.fr Notre site Web -- This email was sent by e...@12h07.fr to debian-devel@lists.debian.org Not interested? Unsubscribe - https://ekol-zcmp.maillist-manage.eu/ua/optout?od=3z0f066ec254711dca8ea69c8e19b4d628&rd=11ab52eea7d8c5e5&sd=11ab52eea7d768d5&n=11699e4c31394ee Update profile - https://ekol-zcmp.maillist-manage.eu/ua/upc?upd=11ab52eea7c72c97&r=11ab52eea7d8c5e5&n=11699e4c31394ee&od=3z0f066ec254711dca8ea69c8e19b4d628&r=11ab52eea7d8c5e5&n=11699e4c31394ee&od=3z0f066ec254711dca8ea69c8e19b4d628 Digital Events Europe | 59, Bld Meyniel 47200 Marmande France Our Privacy Policy [ ] and Terms of Use. [ ]
