Re: Too many Recommends (in particular on mail-transport-agent)
On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote: > AFAIK, mdadm's default (and maybe only supported, without some custom > scripting) way to report a degraded array is email. Can't it report this via the system log? (syslog, systemd-journald) > OTOH, seems weird for Dracut to recommend mdadm. Surely a system > booting from RAID would already have it installed? dracut defaults to creating a general-purpose initramfs that is not meant to hard-code anything and can be used to boot "most" hardware (it gets the root device from the kernel command-line, mounts the root, and reads the rest of its configuration from there). If the necessary binaries for modules like mdadm are not present, then they can't be included in the generated initramfs, leaving it less general-purpose than it is intended to be. S
Re: Too many Recommends (in particular on mail-transport-agent)
Ben Caradoc-Davies writes: > Trust is not transitive. If trust is not transitive, then what for trust network exists?
Re: Too many Recommends (in particular on mail-transport-agent)
On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote: > Trust is not transitive. Perhaps Recommends should not be either? Recommends are for the relationship "wanting foo but not bar is unusual". If A Recommends B and B Recommends C, and if we assume for example that "unusual" means 10% of users of A do not need B and 10% of users of B do not need C, then installing Recommends means somewhere between 0% and 20% of users of A get C unnecessarily. (The real figure depends on whether not wanting B and not wanting C are positively or negatively correlated, or independent.) That still seems like it qualifies as "unusual" to me, so I think Recommends are effectively transitive. More practically, apt does not keep track of whether a package was installed as a result of a recommendation, a hard dependency or user request (the closest it gets is "automatically installed", but that could be anywhere between Depends and Suggests), so non-transitive Recommends are not currently implementable: when apt is upgrading B and there is a new Recommends on C, apt does not know whether B was installed due to a hard dependency or user request (in which case you would say its Recommends on C should be respected), or whether it was only installed because it was recommended by A (in which case you would say the transitive Recommends on C should be ignored). S
Bug#863799: ITP: redtick -- tiny pomodoro timer for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: redtick Version : 00.01.02+git20170220.e6d2e9b Upstream Author : F. Febles * URL : https://github.com/ferfebles/redtick * License : public domain Programming Lang: Emacs Lisp Description : tiny pomodoro timer for Emacs I intend to maintain this as part of the pkg-emacsen team. -- Sean Whitton signature.asc Description: PGP signature
Bug#863825: ITP: ayatana-indicator-session -- Ayatana Indicator showing session management, status and user switching
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-indicator-session Version : 0.4.0 Upstream Author : Mike Gabriel Charles Kerr * URL : https://github.com/ArcticaProject/ayatana-indicator-session * License : GPL Programming Lang: C++ Description : Ayatana Indicator showing session management, status and user switching This Ayatana Indicator is designed to be placed on the right side of a panel and give the user easy control for changing their instant message status. Switching to another user. Starting a guest session. Or controlling the status of their own session. . It requires some way to be hosted into a panel. For the MATE Panel the appropriate package is mate-indicator-applet. For the XFCE Panel the appropriate package is xfce4-indicator-plugin.
Bug#863721: python-ncclient-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/python-ncclient/html/_sources/api.txt
On Tuedd, May 30, 2017 at 02:43:10PM (+0200), Andreas Beckmann wrote: > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. tags 863721 + pending thanks Hi, Thanks Andreas! I should not be awake when uploading the 0.5.3-2 version… ❯ apt show python-ncclient-doc Package: python-ncclient-doc Version: 0.5.3-2 […] Breaks: foo (<< 0.4.7-1) Replaces: foo (<< 0.4.7-1) Just corrected in the 0.5.3-3 version… Thanks again! Seb signature.asc Description: PGP signature
Re: Too many Recommends (in particular on mail-transport-agent)
On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote: > On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote: > > Trust is not transitive. Perhaps Recommends should not be either? > > Recommends are for the relationship "wanting foo but not bar is unusual". > If A Recommends B and B Recommends C, and if we assume for example > that "unusual" means 10% of users of A do not need B and 10% of users > of B do not need C, then installing Recommends means somewhere > between 0% and 20% of users of A get C unnecessarily. (The real figure > depends on whether not wanting B and not wanting C are positively or > negatively correlated, or independent.) That's true. I'd say the biggest problem is maintainers having an emotional attachment to their packages and thus overestimating their importance. A random example (not meant to single out its maintainer): libuuid1 (transitively essential) Recommends: uuid-runtime. The latter is, as far as I understand, needed only if you generate a massive number of uuids per seconds. Packages that actually need so (like ceph) actually Depend: uuid-runtime already. The rest -- those which need a single uuid per mkfs or so, are perfectly fine without that daemon. Thus, axing this dependency or degrading it to Suggests would be probably a good idea. And there's hundreds if not thousands of Recommends of this kind that need to be looked at -- this example is just more prominent as it affects every Debian system. (I'm not filing bugs yet as it's better to have a consensus first before mass-filing.) Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.
Re: Too many Recommends (in particular on mail-transport-agent)
On Wed, 31 May 2017, Adam Borowski wrote: > Thus, axing this dependency or degrading it to Suggests would be probably a > good idea. And there's hundreds if not thousands of Recommends of this kind > that need to be looked at -- this example is just more prominent as it > affects every Debian system. > > (I'm not filing bugs yet as it's better to have a consensus first before > mass-filing.) It is being done on a per-case basis, isn't it? Like you described the libuid versus uuid-runtime? So, it is not a mass-filing, and it is OK. Just file the bugs one by one, with your reasoning, and tag them with usertags if you want to control them as an unit or something. A mass-filing for this (the exact oposite of studying each recommends in a case-by-case basis) _IS_ going to cause imense pushback. I recommend against it ;-) -- Henrique Holschuh
Re: Too many Recommends (in particular on mail-transport-agent)
On 30 May 2017 at 07:57, Ansgar Burchardt wrote: > Hi, > > my impression is that too many packages use Recommends that should > really be Suggests. As a random example: installing dracut as a > initramfs provider will pull in exim4... (dracut-core Recommends: mdadm > which Recommends: default-mta | mail-transport-agent). This seems > really not ideal. > > As a result many people seem to disable installing recommended packages > by default. I believe we should be much more agressive in downgrading > dependencies to Suggests. > > For example, very few packages should Depend/Recommend a MTA: if you > just send notifications (like mdadm), you would need a properly > configured MTA anyway or they just end up in a file nobody will ever > look at (I don't see local mail to root as very useful). > > I suggest that only very few packages should Recommend a MTA: packages > that mainly deal with mail on servers in some way or another (for > user-facing applications, speaking SMTP to a remote SMTP server is > common enough that these shouldn't Recommend a MTA usually either). Maybe exim should easily provide or default to authenticated smarthost (satellite) configuration and /etc/aliases should be configured to forward system mail somewhere else (eg: the sysadmin's work email, in case of SMART or md errors)? Alternatively, if a real MTA is too heavy, why not install msmtp-mta by default? It (including msmtp) is only ~336K, and it's easy to set up for authenticated SMTP. Exim4-daemon-light is ~1292KB. Maybe these aren't easy enough to configure? Does the following need to be revisited?: https://wiki.debian.org/Debate/DefaultMTA Are there people who wouldn't appreciate an email from smartd or md warning them a hard drive is about to fail or that there is something wrong with their array? For desktops, it's way too easy to miss a notification popup, assuming a notification system is installed...and not all desktops have integrated smart monitoring, and not all users install gsmartcontrol. All users should receive notification of hardware failure, no? As I see it the issue is if an admin receives uncountable apt-listchanges emails for something like when a great many containers are upgraded, and it should be possible to skip configuration (and disable) any provider of mail-transport-agent for VMs and containers. Cheers, Nicholas
Re: Too many Recommends (in particular on mail-transport-agent)
On 31 May 2017 at 13:53, Adam Borowski wrote: > On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote: >> On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote: >> > Trust is not transitive. Perhaps Recommends should not be either? >> >> Recommends are for the relationship "wanting foo but not bar is unusual". >> If A Recommends B and B Recommends C, and if we assume for example >> that "unusual" means 10% of users of A do not need B and 10% of users >> of B do not need C, then installing Recommends means somewhere >> between 0% and 20% of users of A get C unnecessarily. (The real figure >> depends on whether not wanting B and not wanting C are positively or >> negatively correlated, or independent.) > > That's true. > > I'd say the biggest problem is maintainers having an emotional attachment to > their packages and thus overestimating their importance. > > A random example (not meant to single out its maintainer): > libuuid1 (transitively essential) Recommends: uuid-runtime. > The latter is, as far as I understand, needed only if you generate a massive > number of uuids per seconds. Packages that actually need so (like ceph) > actually Depend: uuid-runtime already. The rest -- those which need a > single uuid per mkfs or so, are perfectly fine without that daemon. > > Thus, axing this dependency or degrading it to Suggests would be probably a > good idea. And there's hundreds if not thousands of Recommends of this kind > that need to be looked at -- this example is just more prominent as it > affects every Debian system. > > (I'm not filing bugs yet as it's better to have a consensus first before > mass-filing.) > With the exception of maintaining Recommends for mail-transport-agent for packages where emailed warnings are highly desirable (there might be others besides smartd and mdadm), I agree that there are many cases were Recommends can be downgraded to Suggests. My pet peeve is unnecessary Recommends on texlive packages, but it's easy enough to type "NO" and then install with --no-install-recommends...but if you mass-file "please degrade Recommends to Suggests" I hope it will be for a few of those :-) Cheers, Nicholas
Re: Too many Recommends (in particular on mail-transport-agent)
On Wed, May 31, 2017 at 03:17:27PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 31 May 2017, Adam Borowski wrote: > > (I'm not filing bugs yet as it's better to have a consensus first before > > mass-filing.) > > It is being done on a per-case basis, isn't it? Like you described the > libuid versus uuid-runtime? > > So, it is not a mass-filing, and it is OK. Just file the bugs one by > one, with your reasoning, and tag them with usertags if you want to > control them as an unit or something. > > A mass-filing for this (the exact oposite of studying each recommends in > a case-by-case basis) _IS_ going to cause imense pushback. I recommend > against it ;-) I'd specifically want a kind of mass-filing: let's make a long list and discuss it in a d-devel flamewar all at once, so we'd have some consistency. Let's do it after Jun 18, though -- a bug filed today can't be acted on immediately thus it'd be forgotten even if it's a single word change. Applying an usertag would be useful, yeah, thanks for the reminder. Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.
Re: Too many Recommends (in particular on mail-transport-agent)
Hi there, On Tue, 30 May 2017 13:57:03 +0200, Ansgar Burchardt wrote: > For example, very few packages should Depend/Recommend a MTA: if you > just send notifications (like mdadm), you would need a properly > configured MTA anyway or they just end up in a file nobody will ever > look at (I don't see local mail to root as very useful). AFAIK by default root is an alias for the first local user set up during installation. This at least was/is on the oldest Debian installation upgraded and still running I have (and the same on jessie on my current laptop) : = mantissa:/etc# git log -p 5deed858 aliases commit 5deed8583b1a65e9f80a9426496c2e707ce6c860 Author: Luca Capello Date: Thu Dec 31 15:11:07 2009 +0100 initial commit diff --git a/aliases b/aliases new file mode 100644 index 000..ba553bc --- /dev/null +++ b/aliases @@ -0,0 +1,14 @@ [...] +root: luca mantissa:/etc# = Given that local users are notified of new mail at a console login, providing such notification at DE login would be a first step. Thx, bye, Gismo / Luca signature.asc Description: Digital signature
Re: Bug#863799: ITP: redtick -- tiny pomodoro timer for Emacs
On Wed, May 31, 2017 at 04:40:56PM +0200, Carsten Leonhardt wrote: > I'm curious to see the long description, as I don't see the > relationship between tomatoes and timers. Sure! Description: tiny pomodoro timer for Emacs This package provides a little pomodoro timer in the mode-line. . After importing into your Emacs configuration, redtick shows a little red tick (✓) in the mode-line. When you click on this tick, redtick starts a pomodoro timer. . The Pomodoro Technique involves working in 25 minute intervals, separated by 5 minute breaks, with a longer break after every four intervals. https://en.wikipedia.org/wiki/Pomodoro_Technique -- Sean Whitton signature.asc Description: PGP signature
Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
On Fri, May 19, 2017 at 06:43:13PM +0200, Matthias Klumpp wrote: > 2017-05-18 19:52 GMT+02:00 Sean Whitton : > > Hello Matthias, > > > > On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote: > >> Looking at what other languages with the same problem have done, there > >> are basically two ways to deal with the issue: > >> > >> 1) Rebuild every reverse-dependency of the languages' compiler every > >> time the compiler is updated. This is done by Haskell and OCaml and > >> resulted in permanent transition trackers for the libraries. > >> > >> 2) Ship source code instead of libraries in packages, and compile it > >> directly into the target binaries. That way, the maintenance overhead > >> of the languages' packages is greatly reduced, but code is statically > >> linked (boo!) and a lot of code needs to be rebuilt for every > >> dependency (meaning more work for the autobuilders). This is done by > >> Go, and apparently also the plan to do for Rust. > > > > Note that Haskell is statically linked, too. We rebuild every > > reverse-dependency of every library that changes, not just the compiler. > > > > Are you saying that with D, it's only changes to the compiler that are > > problematic? > > No. D can also build shared libraries even. The problem is that you > can only combine libraries and binaries built with the same D compiler > and the same D compiler version. > This results in problems: > If I have an application A that depends on (shared or static) library > B, and we update the D compiler that was used to build both components > initially, and then do an upload of application A, we will get linker > errors. Since A is now built with the newer compiler and B still has > the ABI used with the old D compiler, a mismatch happens. > > So, if a new D compiler is made available in the archive, we would > need to ensure all D stuff gets rebuilt in order. > If source code is shipped, the code is only compiled once, so we > wouldn't run in that issue (but doing that is maybe no so nice?). You already wrote in this thread that there is hope that long-term there might be a stable ABI. With a dozen libraries it would be easiest to just declare one compiler the default D compiler for buster that has to be used when using any of the D libraries shipped in buster. All libraries should automatically get a dependency when built, and through their shlibs generate at all rdeps. libphobos2-ldc71 seems to be for ldc? Every ABI-changing version of the default compiler will then be a small library transition that should be executed via the normal transition process. IMHO this would be a better solution than any kind of "ship source code instead of libraries" hacks. > Cheers, > Matthias cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Too many Recommends (in particular on mail-transport-agent)
Le 31/05/2017 à 09:51, Simon McVittie a écrit : > On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote: >> AFAIK, mdadm's default (and maybe only supported, without some custom >> scripting) way to report a degraded array is email. > > Can't it report this via the system log? (syslog, systemd-journald) mdadm reported events are usually critical ones. If I remember correctly, these events also appear in system log. But, even if I use logcheck, it too easy to miss such events in system logs (or logcheck reports) : there are too many events (or too many false positives for logcheck). mails from mdadm are really an very important feature for me. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
