Re: TC decision on ownership of top-level filesystem aliases - #1091995

* Helmut Grohne [250307 07:05]: > Hi Sean, > > On Thu, Mar 06, 2025 at 05:39:06PM +0800, Sean Whitton wrote: > > Just to note that the most recent release of Policy sort-of defines > > ownership of this, though it is not as explicit as the TC decision: > > > > Packages must not install files

Re: Change the expectation that emails should wrap at 80 characters

* Jeremy Stanley [250226 13:39]: > The only real hassle is > if I want to copy a very long URL out of a message, I either need to > piecemeal reassemble it from the lines that URL is spread across or > pipe the body into another tool that doesn't wrap anything. It's > likely there are config optio

Re: Request for collaborators: DEP-14 conversion script (Re: DEP-14: Default branch name 'debian/latest' objections?)

* Gioele Barabucci [250128 08:03]: > DEP-14 could have a stronger message, but the requirement for HEAD to point > to the development branch is there. My mistake. I was basing my reply on Colin's message: * Colin Watson [250126 15:35]: > Currently, there's only one place where DEP-14 talks abo

Re: Request for collaborators: DEP-14 conversion script (Re: DEP-14: Default branch name 'debian/latest' objections?)

* Otto Kekäläinen [250128 00:04]: > I wrote and rewrote this script a couple of times in past two months: > https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh > > It's not exactly ideal yet, but it does the job. The name is a bit > stupid, and it onl

Re: how to fix lintian error: library-not-linked-against-libc

* Russ Allbery [250126 12:47]: > In theory it would be possible to do better in Lintian by scanning the > symbol table to see if the libc dependency is really unneeded. But doing > that sounds at least a little annoying. Annoying to users of lintian or annoying to implement? How so? I thought o

Re: Removing manpages from libpam-modules to improve multi-arch

[Please don't CC me] * Sam Hartman [250115 14:45]: > Do you actually have a system on which you want these man pages and on > which the extra space of libpam-doc would be a problem? No. > Unless there's a compelling need, my answer is that I don't understand > why manpages should be separated f

Re: Removing manpages from libpam-modules to improve multi-arch

* Sam Hartman [250115 11:44]: > > TL;DR: I propose move man pages out of a multi-arch: same package into a > arch all package. Asking for any downsides and usrmerge review. > > My proposal is to move the man pages into libpam-doc. > I'm not actually convinced that normal Debian users need man pa

Re: signify and signify-openbsd names

* Simon Richter [241007 09:50]: > On 10/7/24 21:43, Marvin Renich wrote: > > > trixie: > >remove old src: signify > > yes. > > >single source upload: > > src: signify -> signify-mail > > binary: signify -> signify

Re: signify and signify-openbsd names

* Simon Richter [241007 04:32]: > The correct approach is one release with a transitional package, pulling the > new package in, and one release with the name unused (so the transitional > package is listed in Obsolete/Local). > > The release without the package also makes sure that any archive v

Re: proposal: Hybrid network stack for Trixie

* Lukas Märdian [240923 07:05]: > As described in the "Proposal" section and first answer of the FAQ, it's all > about consistency. > > There seems to be a tendency for moving towards a hybrid stack, using > sd-networkd and NetworkManager in different contexts/use-cases. But having > fragmented w

Re: what about Netplan?

* Lukas Märdian [240715 10:33]: > No. We're talking about the "netplan-generator" package, which comes without > any > Python dependencies. It's a part of the netplan.io source package and > everything > that would be required in the default installation. Thanks. I've filed wishlist Bug#107644

Re: what about Netplan?

* Lukas Märdian [240715 09:36]: > I don't want people to think too much in terms of "sd-networkd VS Netplan", > but rather in terms of "sd-networkd PLUS Netplan". I'm a little confused. Much earlier in this thread it was stated that ifupdown2 was out of the running simply because it brings in py

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

* Hakan Bayındır [240529 07:51]: > On 28.05.2024 ÖS 8:16, Andreas Metzler wrote: > > On 2024-05-28 Luca Boccassi > > wrote: > > [...] > > > - existing installations pre-trixie will get an orphaned tmpfiles.d in > > > /etc/ that keeps the existing behaviour unchanged (no cleanup of > > > /var/tmp

Re: How to create a custom Debian ISO

* Aditya Garg [240511 05:15]: > Hello > > I wanted to create a custom ISO of Debian, with the following customisations: > > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software packages to > support my hardware. > > I am no

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Early in this meta-thread it was suggested to separate /tmp-is-tmpfs from cleanup-of-{,/var}/tmp. I am really surprised that nobody has suggested the obvious separation of new installs from upgrades. Changing the local configuration for either feature is trivial either way. I think the proposed

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

* Michael Biebl [240506 07:15]: > Am 06.05.24 um 12:35 schrieb Simon Richter: > > Hi, > > > > On 5/6/24 17:40, Michael Biebl wrote: > > > > > If we go with a/, then I think d-i should be updated to no longer > > > create /tmp as a separate partition. > > > > I think if the admin explicitly conf

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

* Simon Richter [240506 06:51]: > Hi, > > On 5/6/24 17:40, Michael Biebl wrote: > > > If we go with a/, then I think d-i should be updated to no longer create > > /tmp as a separate partition. > > I think if the admin explicitly configures tmpfs as a separate file system, > then that should be

Re: Binary conflict between Midnight Commander and MinIO Client

* Simon McVittie [240422 05:02]: > On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote: > > Philip Hands writes: > > > 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-docume

Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

* José Luis González [240407 15:00]: > reopen 1068479 > thanks > > Hi all, > > Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a > look at my recent bug reports to libreoffice-writer and his replies. > > In this one: > > > Am 06.04.24 um 11:03 schrieb Rene Engelhard: > >

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

* Jonathan Kamens [231230 14:39]: > I think even "ssh-h3" is a confusing and frankly impudent name. The > creator of this new package appears to be intentionally trying to use > the ubiquity of the ssh "brand" to their benefit. This brand confusion > can only harm end users and I do not think Debi

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

* Simon Josefsson [231230 11:54]: > One alternative that was suggested was to call the package something > else in Debian. 'golang-ssh3'? 'go-ssh3'? Still somewhat problematic > as long as the 'ssh3' name is in there. There is no reason the package (source and binary) can't be named ssh-h3 eve

Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go

* Nilesh Patra [231026 06:43]: > On Thu, Oct 26, 2023 at 08:35:51AM +0200, Salvo Tomaselli wrote: > > > Go has the extremely nice feature that cross-compiling for other > > > architectures and OSs is very easy. I have, on a number of occasions > > > used Debian to cross-compile Go programs for Wi

Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go

* Nilesh Patra [231025 16:13]: > Hello, > > On Wed, Oct 25, 2023 at 05:13:10PM +0300, Ramūnas Keliuotis wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Ramunas Keliuotis > > > > * Package name: golang-github-microsoft-go-winio > > Version : 0.6.1-1 > > Upstream Author

Re: Control header sent with done email didn't do what I expected, should it have?

* Andrey Rakhmatullin [230925 15:13]: > On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote: > > The documentation you inked to does not specify a tag that can be used > > specifically to mark something as not actually a bug. > Yes, we just close those. The Debian BTS is not as rich as

Re: Control header sent with done email didn't do what I expected, should it have?

* Jonathan Kamens [230925 12:56]: > Closed bugs are available for direct search for 30 days after they're > closed. > > After that you can still search them by selecting either "Archived" or > "Archived and Unarchived" under "Misc Options" on the search page. Except that in the general case, thi

Re: Control header sent with done email didn't do what I expected, should it have?

* Russ Allbery [230925 12:43]: > Marvin Renich writes: > > > I've seen differing opinions about closing "wontfix" bugs, but as a > > I think it's a trade-off. Which is why I said there are differing opinions. This has come up on this list before. >

Re: Control header sent with done email didn't do what I expected, should it have?

* Jonathan Kamens [230925 07:17]: > Hi all, > > I recently tried to close a bug, explain why, and set a "wontfix" tag all at > once by sending my explanation to ###-d...@bugs.debian.org with "Control: > tags ### wontfix" as the first line of my message body. The bug was closed > but the tags comm

Re: Questionable Package Present in Debian: fortune-mod

* Dominik George [230818 17:52]: > Debian is not ..., it is an operating system. This is simply and blatantly incorrect. Debian is a distribution. It includes an operating system and many, many application packages that different people find useful or interesting. The vast majority of packages

Re: Bug#1050005: ITP: pdftopng -- Convert PDF to PNG

* Elena Grandi [230818 05:27]: > Package: wnpp > Severity: wishlist > Owner: Elena Grandi > > * Package name: pdftopng > Description : Convert PDF to PNG > > A command line tool and python library to convert PDFs to PNGs, based on > pdftoppm from poppler. > > This is a dependency of

Re: Fwd: Wayland and NVidia driver conflict

debian-user and debian-desktop are both good lists for this question. It is off-topic for debian-devel. Anyone who answers, please remove debian-devel from the replies. (Sorry, I don't have an answer for you.) Thanks...Marvin

Re: DEP 17: Improve support for directory aliasing in dpkg

* Helmut Grohne [230428 09:50]: > I think we have a misunderstanding here. As far as I understand it, the > core idea of Luca's approach is that we move all files to their > canonical locations and then - when nothing is left in directories such > as /bin or /lib - there is no aliasing anymore, wh

Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

* Marvin Renich [221115 12:57]: > TEMPDIR, on the other hand, is for _specific_ cases, and can have ^ et al Of course, that should be TMPDIR, not TEMPDIR. Apologies. ...Marvin

Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

* Robie Basak [221113 14:15]: > On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote: > > On Nov 13, Robie Basak wrote: > > > > > This seems inconsistent to me. Where is the expectation that TMPDIR must > > > be unset if dropping privileges coming from? Obviously for users of > > Where i

Re: Firmware GR result - what happens next?

* Paul Wise [221014 01:35]: > On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote: > > > I'd prefer if we could make things work vs making things fail, > > however loudly. > > There seem to be a few ways to deal with this transition: > > 2. Add some code somewhere to automatically modify th

Re: Automatic trimming of changelogs in binary packages

* Hakan Bayındır [220914 03:41]: > > > > On 14 Sep 2022, at 10:37, Wouter Verhelst wrote: > > > > On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote: > >> Yes, you’re right. However, my reservation is whether dpkg is more prone to > >> breaking in disaster recovery scenarios. Readi

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

* Dylan Aïssi [220914 05:57]: > Le mer. 14 sept. 2022 à 03:08, Felipe Sateler a écrit : > > > > Dylan, have you thought about how a transition plan would look like? > > Now, regarding the transition plan, I propose to switch right now to pipewire. > This give us 4 months until the "transition an

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

* Ansgar [220910 09:37]: > the transition to usrmerge as described in [1] is planned to start > around 2022-09-15 (next Thursday). [snip] > We will send an announcement to debian-devel-announce@ once the upload > to unstable happens. What is the point in waiting until after the upload to send to

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

* Jeremy Bicha [220714 10:06]: > On Thu, Jul 14, 2022 at 2:41 PM Roberto C. Sánchez wrote: > > > > On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote: > > > edw...@4angle.com wrote: > > > > > > >Package: wnpp > > > >Severity: wishlist > > > >Owner: Edward Betts > > > >X-Debbugs-Cc: d

Re: use of Recommends by vlc to force users to use pipewire

* Dylan Aïssi [220530 08:31]: > Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard a écrit : > > > > a) pipewire package enables pipewire service by default > > Indeed, but pipewire service doesn't take control of audio over > pulseaudio. Only pipewire-pulse does that. > So, if you don't want to use

Re: use of Recommends by vlc to force users to use pipewire

* Marvin Renich [220517 08:55]: > I do not fully understand the relationships between the different sound > servers, for example I think pulseaudio can use ALSA as one of its > backends, but do I think that they all need to be co-installable without I do > inte

Re: use of Recommends by vlc to force users to use pipewire

* Vincent Lefevre [220517 06:36]: > On 2022-05-16 16:14:02 +, Bill Allombert wrote: > > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote: > > > And for the record: you get pipewire installed because libpipewire-0.3-0 > > > recommends it. > > > > For a similar situation, I ad

Re: blocking UDP with UFW (bug?)

* Michael Lazin [220506 04:39]: > The UFW firewall package uses iptables at the backend, but it is lacking > syntax to block UDP ports and I think this would be useful. > > I ran the command "UFW default deny incoming UDP" and it wrote to the chain > successfully, but I ran nslookup afterwards an

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

* Eric Brown [220427 20:24]: > Thank you for the explanation, and thanks for the history and pointer > towards tftp. Looks like you remembered correctly > (https://lists.debian.org/debian-devel/2020/02/msg00197.html). I installed > tftpd-ahp. Interestingly, after all that discussion, it still does

Re: The future of src:ntp

* Richard Laager [220119 14:34]: > On 1/19/22 9:49 AM, Bernhard Schmidt wrote: > > AFAICT other than systemd-timesyncd being installed by default we don't > > have a "default" NTP daemon in Debian. > > I'm not sure how much more "default" it can be than installed by default. So > I'd say we do ha

Re: Not running tests because tests miss source code is not useful

* Pirate Praveen [211007 05:41]: > On 7 October 2021 3:02:55 am IST, Thomas Goirand wrote: > >On 10/6/21 6:53 PM, Pirate Praveen wrote: > >> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard > > >> wrote: > >>> Quoting Yadd (2021-10-06 11:43:40) >  On Lu, 04 oct 21, 16:40:

Re: Bug#993488: maybe reason for wontfix?

* Tomas Pospisek [210903 08:27]: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a > "wontfix + close" but no rationale. Which leaves the original reporter with > a large "?" I guess. > > I am guessing that the reason for the "wontfix" is "that's just how Unix > works unfor

Re: merged-/usr vs. partially-symlink-farmed-root

* Ansgar [210823 11:16]: > Hi Marvin, > > On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote: > > Yet they cannot be counted on to work on Debian now, nor will they on > > non- or partially-merged systems.  You are saying "the end result is > > thus, so the p

Re: merged-/usr vs. partially-symlink-farmed-root

* Ansgar [210822 17:29]: > Hi, > > On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote: > > * Ansgar [210822 05:08]: > > > To get a filesystem layout equivalent to merged-/usr via symlinks > > > farming *every* package shipping files in at least /usr/bin, >

Re: merged-/usr vs. partially-symlink-farmed-root

* Ansgar [210822 05:08]: > Hi Guillem, > > On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > > There was talk about the huge amount of symlinks required in a > > symlink farm setting, but that might have been true for a scenario > > where those symlinks would have been handled automatical

Re: Planning for libidn shared library version transition

* Marvin Renich [210527 13:41]: > packages use the same wording in the description, and searching for the > specific word "transitional" has a non-negligible chance of a false ^ or "dummy" ...Marvin

Re: Planning for libidn shared library version transition

* Andrey Rahmatullin [210527 10:38]: > On Thu, May 27, 2021 at 10:10:15AM -0400, Marvin Renich wrote: > > If transitional packages either had a debtag or a control file field > > that identified them, then tools like deborphan could easily be made to > > find and remove them

Re: Planning for libidn shared library version transition

* Simon McVittie [210527 06:19]: > The one non-cosmetic reason I can think of why transitional packages > are potentially bad is that they aren't removed automatically, so systems > that have been upgraded many times can end up with a lot of transitional > packages; If transitional packages eithe

Re: Proposal: plocate as standard for bookworm

* Steinar H. Gunderson [210209 14:27]: > On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote: > > And there are now also many non-technical Linux users who have never > > used a shell. > > Well, why do we include netcat, telnet or hdparm? lsof? pciutils? > traceroute? host? All of these a

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

* Jeremy Bicha [201013 18:09]: > On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich wrote: > > Describing a clear benefit to having both open and see would help > > immensely. Alternatively, convincing the mime-support authors that open > > should replace see would also work

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

* Noah Meyerhans [201013 00:54]: > "open" is a verb commonly used to describe the action of accessing a > file in Linux. You used it yourself above, and it's one of the most > prominent functions in the file API. It seems sensible to provide a > tool that matches the verb most commonly used to d

Re: Preferred form of modification for binary data used in unit testing?

* s...@debian.org [200717 17:51]: > On Fri, 17 Jul 2020 at 10:44:24 -0400, Marvin Renich wrote: > > The intended purpose is to ensure that the recipient has every > > reasonable opportunity to modify the software in any reasonable way the > > recipient desires. Th

Re: Preferred form of modification for binary data used in unit testing?

[This was just a convenient point in the thread to which to reply; it's not really a reply to Sean's specific message.] I think, instead of pedantically applying the wording of the DFSG, we should be pedantically applying the intended purpose of the DFSG. The legal profession has proven, time and

Re: Is an init required to obey policy-rc.d during boot ?

Reply-To debian-devel@lists.debian.org: In-Reply-To: * Michael Biebl [200422 19:43]: > Am 23.04.20 um 00:43 schrieb Thomas Goirand: > > On 4/22/20 4:11 PM, Sam Hartman wrote: > > >> And a native interface for a sysadmin overriding that (masking). > > > > Unless I'm mistaking, that's not useful

Re: documenting on how not starting a daemon upon installation

Thanks, Russ, Ansgar, and Marco for the explanations. So in summary: * For systems running systemd - systemctl mask works well to disable individual daemons until explicitly re-enabled, regardless of which mechanism the package uses (systemd service or init script) to start the daemon.

Re: documenting on how not starting a daemon upon installation

* Marco d'Itri [200310 11:23]: > The modern and simple solution is "systemctl mask", as long as you do > not need to care about the 0.6% of systems which do not use systemd. > If you are doing this for your own systems then you obviously know if > you can rely on systemd or not. I don't believe

Re: documenting on how not starting a daemon upon installation

* Simon Richter [200309 12:33]: > On Mon, Mar 09, 2020 at 04:02:52PM +0100, Tomas Pospisek wrote: > > In my logic, finding out how "not to start services on install" should > > be documented in `man dpkg` or referenced from that man page. As far as > > I could see there is absolutely no trace of a

Re: not starting a daemon upon installation

* jnq...@gmail.com [200308 10:58]: > On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote: > > The problem is that installing the package will automatically start > > the > > daemon cluster in a "default" configuration. > > > > [1] > > https://askubuntu.com/questions/74061/install-packages-wit

Re: Heads up: persistent journal has been enabled in systemd

* Matt Zagrabelny [200204 21:27]: > The contents of /var/log/journal will be binary files that journalctl > will read. IIRC. This is my objection to the systemd journal. Binary log files are absolutely _horrible_ for the general user, but they are terrific for large data centers. In a large dat

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

* Richard Laager [200129 19:05]: > On 1/29/20 8:28 AM, Marvin Renich wrote: > There are plenty of shades of > grey in this, and what counts as "minimal", "medium", or "massive" is > going to be at least somewhat subjective. Completely agree. > I&#x

Adding security features (was: Kernel parameters protecting fifos and regular files)

I have no opinion about this specific feature; at first glance it looks like it might be a reasonable thing to do. On the other hand, I strongly disagree with this statement as a general rule: > Unless massive breakage is expected, the default should > be the most secure option. This is the wron

Re: [RFC] Proposal for new source format

I think this discussion has conflated two separate needs that should be kept distinct. The current source package provides a record of how the binary packages were built from source. This includes signatures and verifiability of source, and, more recently, reproducibility. It provides the abilit

Re: When acting as a service admin, it's official, no really.

* Alexander Wirt [191009 08:45]: > If we want to announce something, we announce it. Until we do something like > this: of course there can be a (temporary) veto. You can't expect us to allow > things that will break the service for everybody without stepping in. That > doesn't mean that such thin

Re: ML-Policy and tesseract-ocr

[Debian list policy is to reply to list without CC to individuals, except where the individual has asked for a CC.] For the rest of your reply, I agree with Sam's response (i.e. no Suggests is necessary). ...Marvin * Mo Zhou [190812 20:29]: > > The source package would need to Build-Depend on t

Re: ML-Policy and tesseract-ocr

* Mo Zhou [190812 10:31]: > To this end, I wrote the policy #5 [3]: > >A package that includes a machine learning model, must also include >the corresponding training program, or depend on the package that > provides >the corresponding training program. > > Does that make sense? If i

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

* Simon McVittie [190808 18:37]: > On Thu, 08 Aug 2019 at 15:20:28 -0400, Marvin Renich wrote: > > The man page for machine-id says: > > > > This ID uniquely identifies the host. It should be considered > > "confidential", and must not be

[OT] /etc/machine-id "must not be exposed in untrusted environments"

This is related to the thread Generating new IDs for cloning, but is probably OT for this list. I guess this is really a question for systemd maintainers? Should I file a bug? The man page for machine-id says: This ID uniquely identifies the host. It should be considered "confidential", and

Re: Generating new IDs for cloning

* Michael Stone [190808 12:34]: > I guess I need you to say what's confusing. It's an ID that doesn't change. > You can look up gethostid to get a little more background. If you need an ID First, let me say that I am not trying to be intentionally obtuse. I am really interested to know what prog

Re: Generating new IDs for cloning

* Michael Stone [190808 08:42]: > On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote: > > Does anyone know what applications use this file for what purpose? Is > > this a systemd-ism? > > man machine-id The man page says what it is (a unique, random ID for th

Re: Generating new IDs for cloning

* Bernhard Schmidt [190808 07:48]: > Am 08.08.19 um 13:39 schrieb Marc Haber: > > How do I generate a new one? > > I followed > https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id > last time which means Hmm. The advice in that link doesn't match what man machine-i

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

* The Wanderer [190807 09:28]: > Cloning isn't the only example of a case where some machine-specific > configuration detail may need to be updated, without that being obvious > in advance. > > I've begun to wonder whether it might be worth the overhead to set up > some type of mechanism to let p

Re: Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

* patrick.dre...@gmx.net [190714 14:24]: > Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and > 32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field > 32-bit i386 for Adobe Reader ftp.adobe.com All of your recent posts to this list (debian-devel@lists.debian.

Re: Bug: Opera 12.16 disappears

* patrick.dre...@gmx.net [190623 17:27]: > Bug: Opera 12.16 disappears. > He can't see in Desktop of Debian in Search. > How i can resolve this? Opera has not been in Debian for quite some time. A quick look at www.opera.com seems to indicate that it is no longer open source software, and thus c

Re: Bug: can't install Mozilla Firefox

* patrick.dre...@gmx.net [190623 17:24]: > Fear Woman and Man! > > In the system is the ESR version. I will have the Release version. > Bug: can't install Mozilla Firefox. > apt remove firefox* > apt purge firefox* > apt install firefox > How can resolve this? > > With kind Greetings! > I thin

Re: Proposition: Simlify the Installation

* patrick.dre...@gmx.net [190623 17:27]: > Proposition: Simlify the Installation. Dosn't have 2 Installation options. > ..., Graphical Installation. You may file a bug with severity "wishlist" against the package "debian-installer". However, I think many people like having the choice of text vs

Re: Debian Bugs: LXDE Desktop is missing

* patrick.dre...@gmx.net [190623 17:24]: > Dear Woman and Man! > > Debian Bugs: LXDE Desktop is missing. > Terminal Comands not functions. > apt-get install lxde-core > apt-get install lxde > apt-get install task-lxde-desktop > How can resolve this? > > With kind Greetings! These packages are s

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

* Vincent Bernat [190409 01:26]: > ❦ 9 avril 2019 08:41 +10, Ben Finney : > > >> >> yes, it can be done, but it is a lot more work for individual > >> >> packagers. > >> > > >> > Sure. And, on the other hand, providing an APT repository for arbitrary > >> > packages of unknown copyright status

Re: no{thing} build profiles

* Holger Levsen [181026 10:45]: > On Fri, Oct 26, 2018 at 09:24:17AM -0400, Marvin Renich wrote: > > Using Depends instead of Recommends actually _prevents_ the admin from > > being able to choose. > > you know about the equivs package, do you? Sure. But that requires

Re: no{thing} build profiles

* The Wanderer [181026 08:38]: > On 2018-10-26 at 00:51, Russ Allbery wrote: > > You choose the strongest relationship that is applicable. > > I'm not sure that's clear from the given definitions, nor that it should > necessarily hold. Is there any statement which would make that explicit? > I ha

Re: no{thing} build profiles

* Russ Allbery [181026 00:52]: > I don't know why you would expect otherwise? That seems entirely natural > and expected given that Depends is a stronger relationship than > Recommends, and therefore is naturally a subset of the things that would > qualify as Recommends. [As The Wanderer said, I

Re: no{thing} build profiles

* Wouter Verhelst [181025 08:26]: > On Tue, Oct 23, 2018 at 05:04:11PM +0200, Vincent Lefevre wrote: > > But a Depends or Recommends on gnupg > > will annoy 99.9% of the users; > > Err, no. > > That number makes the assumption that all users who have something > installed that they don't end up

Re: no{thing} build profiles

[I'm subscribed; please do not CC me.] * Matthias Klumpp [181022 14:18]: > Because having a real dependency eliminates another source of bugs. > The library will throw weird (for unexperienced end-users) errors and > they have to hunt down a solution for why something isn't working as > they expe

Re: no{thing} build profiles

* Russ Allbery [181022 16:23]: > Minimal installation size is *not* the only goal here. Ease of use and > lack of surprise is important to. Then don't disable Recommends in apt preferences. > Personally, I think people in this thread are too worried about trying to > remove as many packages fro

Re: no{thing} build profiles

* Matthias Klumpp [181021 14:04]: > libgpgme is communicating with gnupg in the background - having > libgpgme without gnupg itself will render the library completely > unusable and break existing users of the library. This keeps getting repeated in this thread in spite of the fact that multiple

Re: Bug#911539: tinysshd: Use Recommends: systemd rather than Depends

* Jan Mojzis [181021 13:45]: > fixed here: > https://salsa.debian.org/debian/tinyssh/commit/64ab1d6729ecf5e0a7115bffa634beb8dbb5b3e6 > > Wow! Thanks very much for the extremely rapid fix. ...Marvin

Re: no{thing} build profiles

* Andrey Rahmatullin [181021 13:20]: > On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote: > > Semantically, Depends: declares that the package has to be > > installed to proceed. It doesn’t specify whether the package > > has to actually be used. Which kind of invalidates

Re: no{thing} build profiles

* Andrey Rahmatullin [181021 13:16]: > On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote: > > The proper fix is to convince upstream to dynamically link at runtime > > and disable some features if libgpgme is not available. > dlopening a dependency is bad: for e

tinysshd: Use Recommends: systemd rather than Depends

Package: tinysshd Version: 20180201-1 [Jan Mojžíš: this is a reply to a thread on debian-devel; some of the statements below are directed toward that thread, not to you personally.] * Vincent Bernat [181021 11:29]: > ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov : > > > >>> tinysshd only ships a

Re: no{thing} build profiles

* Sune Vuorela [181021 06:05]: > On 2018-10-21, Jonas Smedegaard wrote: > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: > > As a library it cannot possibly declare how tight a relationship to > > declare - instead, all _consumers_ of the library must declare whether

Re: wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

* Kamil Jońca [181017 01:27]: > > Recently I tried to upgrade my freeradius package to 3.0.16+dfsg-4.1+b1 > And after that my laptop with wpa_supplicant stops authenticate: > > with version 3.0.16+dfsg-3+b1 everything works ok. > Any hints what to check in logs? Please ask user questions on deb

Re: Should the weboob package stay in Debian?

* Stephan Seitz [180724 09:49]: > On Di, Jul 24, 2018 at 01:19:35 +0100, Matthew Vernon wrote: > > Stephan Seitz writes: > > > He certainly should NOT rename any parts of the package without > > > upstream consent. > > Why not? I can see an argument about not confusing users (though > > transitio

Re: Should the weboob package stay in Debian?

* Stephan Seitz [180724 07:25]: > He certainly should NOT rename any parts of the package without upstream > consent. If upstream doesn’t approve (and it seems that these names are part > of upstream’s working culture), then the other choices are removing to > package or keeping it as it is. Or,

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

* Emilio Pozuelo Monfort [180420 11:00]: > On 20/04/18 16:46, Marvin Renich wrote: > > I would also like /etc/debian_version to contain both number and name, > > but I suspect there is some resistance to this on the grounds that > > scripts may be using $(cat /etc/debian_ver

Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

Package: base-files Version: 10.1 Severity: wishlist * Stephan Seitz [180420 07:38]: > On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: > > But being human I prefer names over numbers, even if it's just for > > aesthetic reason - "buster" is just more comfortable than "debian10". >

Re: interpretation of wontfix

* Andreas Tille [180328 07:51]: > On Wed, Mar 28, 2018 at 12:01:19PM +0100, Simon McVittie wrote: > > On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote: > > > I think "wontfix" is exactly the feature of the BTS that was invented to > > > solve the problem I described. The bug is not clos

Re: [apparmor] Let's enable AppArmor by default (why not?)

[added d-dev back] * intrigeri [180319 07:40]: > Marvin Renich: > > Actually, a short beginner's guide as a text file in > > /usr/share/doc/apparmor, which has more than just "how to disable a > > profile" would be extremely helpful. I don't have the a

  1   2   3   >