Re: Binary conflict between Midnight Commander and MinIO Client
Hi, Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > Might I suggest that the link goes the other way, so that the symlink > lives in /usr/bin? That way the existence of the lib directory is > somewhat self-documenting. That's an interesting hint. In Debian Med we are using a common directories /usr/lib/debian-med/bin/ /usr/lib/debian-med/man/ where those binaries will be moved to and have some kind of a README.Debian template[1]. Changing this to have the real executable / manpage to /usr/lib/debian-med/* makes sense. We simply advise Debian Med users to set PATH to that dir and have all the name-clashed binaries inside Debian Med without additional interaction. Kind regards Andreas. [1] https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads -- https://fam-tille.de
Processed: reassigning bugreport to kernel
Processing commands for cont...@bugs.debian.org: > reassign 1069735 linux-image-6.6.15-amd64 Bug #1069735 [general] general: atlantic driver doesn't work on thinkpad Bug reassigned from package 'general' to 'linux-image-6.6.15-amd64'. Ignoring request to alter found versions of bug #1069735 to the same values previously set Ignoring request to alter fixed versions of bug #1069735 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 1069735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069735 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068778: marked as done (geoclue and gpsd are running by default (they aren't needed and could be used for location tracking))
Your message dated Wed, 24 Apr 2024 16:32:20 +0200 (CEST) with message-id <1ffdb551-a9e9-7361-b524-31847de3c...@sourcepole.ch> and subject line Re: geoclue and gpsd are running by default (they aren't needed and could be used for location tracking) has caused the Debian Bug report #1068778, regarding geoclue and gpsd are running by default (they aren't needed and could be used for location tracking) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1068778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068778 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general I wondered why Debian comes with geoclue-2.0 and gpsd running by default (which could be used for location tracking). Please do not install them by default or if you really must, please do not make them autostart. At most it could be useful for a few users if it was installed but not enabled and not running by default (so just an option one could enable in the configs or which could be enabled by the user through a prompt). If it's running by default this also means that after upgrades it could be running again. This is a privacy issue, an undesired bloat service that requires to spend time to remove it, and a larger attack surface even if there was a proper and vulnerability-free permissions-management for GPS-location-access. --- End Message --- --- Begin Message --- Hi mYnDstrEAm, mYnDstrEAm wrote on Wed, 10 Apr 2024 22:54:04 +: Package: general I wondered why Debian comes with geoclue-2.0 and gpsd running by default (which could be used for location tracking). Please do not install them by default or if you really must, please do not make them autostart. At most it could be useful for a few users if it was installed but not enabled and not running by default (so just an option one could enable in the configs or which could be enabled by the user through a prompt). If it's running by default this also means that after upgrades it could be running again. This is a privacy issue, an undesired bloat service that requires to spend time to remove it, and a larger attack surface even if there was a proper and vulnerability-free permissions-management for GPS-location-access. I'm closing this bugreport for the following reasons: 1. You write: "geoclue-2.0 and gpsd running by default". On my system: $ ps faux|grep gpsd|grep -v grep $ -> that means that gpsd is not running by default and we do not have fix that. 2. You write: "geoclue-2.0 and gpsd running by default". On my system: $ ps faux|grep geoclue|grep -v grep me 3089 0.0 0.0 234036 3100 ?Sl Apr20 0:00 \_ /usr/libexec/geoclue-2.0/demos/agent $ apt-cache rdepends geoclue-2.0 --installed geoclue-2.0 Reverse Depends: redshift libqt5positioning5 -> please check on your system, who depends on geoclue-2.0 and if you think it is necessary, create a wishlist bug report on those packages that you have installed that depend on geoclue-2.0. I might note, that the geoclue-2.0 dependency is not hard for the packages I have installed, but a recommendation, so that I can still deinstall geoclue-2.0 if I think I do not want it: $ ( dpkg -s redshift ; dpkg -s libqt5positioning5 ) | grep geoclue-2.0 Recommends: geoclue-2.0 Recommends: geoclue-2.0 3. I assume that packages depending on geoclue-2.0 will possibly be able to get some info on where you are. In the case of redshift that'll probably be used to adjust your display brightness/color. That isn't privacy invasive as far as I can see. So again no problem -> no bug. In the same vein you could argue "packages should not use the network, because that can invade your privacy, since they *can* send some info about you and your device to somewhere". So yes, of course they can, but the question is *do they*? If they don't then there's no breach of privacy. 4. When you assigning bug reports against "general" then it's very likely your bug report will be ignored, because nobody maintains a "general" package and thus nobody feels very much responsible for bugreports against the "general" pseudo package. Thanks, *t--- End Message ---
Re: Binary conflict between Midnight Commander and MinIO Client
On Wed, Apr 24, 2024 at 9:42 AM Andreas Tille wrote: > Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > > > Might I suggest that the link goes the other way, so that the symlink > > lives in /usr/bin? That way the existence of the lib directory is > > somewhat self-documenting. > > That's an interesting hint. In Debian Med we are using a common > directories > > /usr/lib/debian-med/bin/ > /usr/lib/debian-med/man/ > > where those binaries will be moved to and have some kind of a > README.Debian template[1]. Changing this to have the real executable / > manpage to /usr/lib/debian-med/* makes sense. I believe moving those binaries to a subdirectory of /usr/libexec/ would better comply with FHS 3.0. Maybe this could be done for the Trixie release? I guess a subdirectory of /usr/share/ would be appropriate for the extra manpages. Thank you, Jeremy Bícha
Re: Status of the t64 transition
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote: > If you wonder how you are able to help with the migration, here are > some things to do: > * Fix FTBFS bugs > * Check the status of autopkgtests [1] and report or fix any issues > related to failing tests. > * Check if source-only uploads for Arch: all packages are missing. What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on https://qa.debian.org/excuses.php?package=glib2.0? -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit : > Hi, > > On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: > > What to do with autopkgtests that fail in testing because of problems > with > > packages in testing that are fixed in unstable, e.g. the autopkgtest for > > speech-dispatcher/0.11.5-2 on > > Inform the Release Team and we can either schedule the combination > manually, add a hint or both. > Isn't it processed automatically ? What needs manual intervention and what doesn't ?
Re: Status of the t64 transition
Hi, On 24-04-2024 7:38 p.m., Paul Gevers wrote: On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Or in cases like this, wait a bit. The test regressed in testing, which the migration software figures out automatically. (If you want to see earlier, you can retry "migration-reference/0" runs, which I already did for speech-dispatcher). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:42 p.m., Jérémy Lal wrote: Inform the Release Team and we can either schedule the combination manually, add a hint or both. Isn't it processed automatically ? What needs manual intervention and what doesn't ? Well, the migration software *tries* to figure out combinations that need to go together. It's greedy, but not infinitely so (otherwise we'd just look at unstable). If a test fails, reference runs are used to compare it to. If the reference run doesn't fail a test is a regression. Regressions are retried (after a day). Reference runs for regressions are rescheduled once they are a week old. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069794: ITP: openbao -- Manage, store and distribute sensitive data.
Package: wnpp Severity: wishlist Owner: Nikos Tsipinakis X-Debbugs-Cc: debian-devel@lists.debian.org, ni...@tsipinakis.com * Package name: openbao Version : v2.0.0-alpha20240329 Upstream Contact: OpenBao Mailing List * URL : https://openbao.org/ * License : MPL-2.0 Programming Lang: Go Description : Manage, store and distribute sensitive data. Fork of Hashicorp Vault after it was relicensed to a non-free license. I intend to give it a shot to package it in the next few weeks in coordination (and hopefully with the guidance of) the Go team.
