Bug#768315: unblock: util-linux/2.25.2-3
Hi, Thanks Andreas for your work on util-linux, it’s really appreciated. Le 15/11/2014 17:57, Andreas Henriksson a écrit : I really don't understand why we're having this discussion now at all. Where where everyone before the freeze? The whole message seems unneededly harsh, but as a data point specific to this point, please don’t forget that the first maintainer upload (since before the previous wheezy freeze) that made it into testing was: [2014-10-20] util-linux 2.25.1-5 MIGRATED to testing (Britney) That’s about two weeks prior to the actual freeze. That doesn’t let much time to discuss or spot anything (and yes, I used the versions you uploaded to experimental before that, but I wouldn’t expect everyone to do it, I’m pretty sure d-i didn’t for example). Regards David signature.asc Description: OpenPGP digital signature
Bug#768315: unblock: util-linux/2.25.2-3
Hi Andreas, Martin Pitt wrote (10 Nov 2014 09:19:06 GMT) : I agree. In Ubuntu we've carried this for a while now: | $ cat /etc/cron.weekly/fstrim | #!/bin/sh | # trim all mounted file systems which support it | /sbin/fstrim --all || true This is init system agnostic, and with anacron it also works nicely on desktops. Of course, if in your view as a maintainer this functionality isn't ready for jessie or you don't want to support it, just backing out of the change also works. It also took us quite some time in Ubuntu to enable it by default, and we did extensive measurements to see which approach is best. But not trimming SSDs is really quite bad these days, so from my POV it would be quite prudent to include either the timer or the cron job in jessie. Agreed. I think we should ship the cronjob by default in Jessie. Andreas, what do you think? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85389kisva@boum.org
Bug#768315: unblock: util-linux/2.25.2-3
Hello intrigeri! On Sat, Nov 15, 2014 at 12:51:53PM +0100, intrigeri wrote: Hi Andreas, Agreed. I think we should ship the cronjob by default in Jessie. Andreas, what do you think? What I've seen so far is people suggesting to use a cron job /instead of/ the systemd units shipped by upstream. That is in my opinion pretty short-sighted. I see a cron job as a complement that caters to the niche which does not use the default init in Jessie. Saying that people who don't install cron don't get their SSDs trimmed is just stupid. Speciall since installing cron also pulls in a full MTA. Why would anyone want to connect having an MTA installed to having their SSD trimmed?! Atleast I'm not going to install that on a number of my systems. (Please keep in mind that it's not uncommon even for embedded system to ship with SATA or mSATA today and those are being used with SSD drives.) I've spent way to much time catering to niches that random people think are important but where they don't want to do the work themselves. I'm not going to do that anymore, unless people agree to paying my regular fee for buying hours of my life which is the way I'm making a living.. (fwiw, I'm also still pondering if I still want to be involved with Debian at all.) If someone wants to do the work it would be good if they could think about the consequenses themselves, but here are some pro bono advice: There will likely be a number of people having both systemd and cron installed on their systems. Whoever does the work on the cron side will probably want to make sure that these people don't end up with double trimming. Also see: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-contribute.txt I really don't understand why we're having this discussion now at all. Where where everyone before the freeze? Where where the advice when I asked for it and had to fight my way forward to get my changes into Debian. Right now I'm really regretting even getting involved with util-linux in Debian. I should have just kept on doing my own thing and never mentioned it to anyone. I've spent a huge amount of time cleaning up the mess left by others and catered to all kinds of niches that didn't want to do their work themselves (most time occupied by kfreebsd). This left me with alot of people thinking because I did that now I somehow owe them even more time and work which they can dictate how I should do. I guess I'm drifting way off topic here trying to focus again. If you don't want to pay me to do the work, then get pre-approval from the release team for your suggested changes - then, and not before then, feel free to talk to me about it. I'm not interested before that. Things that will interest people who actually want to work on a solution for keeping automatic trimming: 1/ #757891 see also: https://lists.debian.org/debian-devel/2014/11/msg00216.html 2/ #767429 3/ optionally create a proper cron-job. 4/ get r-t pre-approval. Right now I see a number of flawed suggestions floating around. It's probably less interesting that I can't really approve of any of them, then that it will probably be hard to get any of it past the release team now. My suggestion is thus still that I'm not seeing the above points not getting fixed I think the safest way is to just back out all trimming jobs and make another attempt after the ice-age has passed. (If 1 and 2 gets fixed in Jessie, then I'll close my pre-approval request to drop the units from the current util-linux package. If someone can also get 3 and 4 done, then good for the people who benefit from that!) HTH. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141115215750.ga25...@fatal.se
Bug#768315: unblock: util-linux/2.25.2-3
Andreas Henriksson andr...@fatal.se writes: I see a cron job as a complement that caters to the niche which does not use the default init in Jessie. Saying that people who don't install cron don't get their SSDs trimmed is just stupid. Speciall since installing cron also pulls in a full MTA. Why would anyone want to connect having an MTA installed to having their SSD trimmed?! cron is priority: important, so it's very rare for a system to not have it, and it does not pull in a full MTA. (That's a Recommends, not a Depends; if you're trying to maintain a minimal system, disable Recommends.) Many other packages in Debian assume that cron is available. If someone wants to do the work it would be good if they could think about the consequenses themselves, but here are some pro bono advice: There will likely be a number of people having both systemd and cron installed on their systems. Whoever does the work on the cron side will probably want to make sure that these people don't end up with double trimming. I truely believe that just using the cron job will be fine. I don't think you're going to find many systems without a cron implementation installed, and lots of other things in Debian already assume that. I really don't understand why we're having this discussion now at all. Where where everyone before the freeze? Where where the advice when I asked for it and had to fight my way forward to get my changes into Debian. Right now I'm really regretting even getting involved with util-linux in Debian. I'm sorry. :/ I hadn't seen anything about this issue until just now. If I had, I would have given advice on it earlier. Thank you so much for all the cleanup work you've done on util-linux. It's hugely important, and much appreciated. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fywx99q@hope.eyrie.org
Bug#768315: unblock: util-linux/2.25.2-3
Russ Allbery [2014-11-06 22:13 -0800]: The concern with the service unit is that it's only a service unit with no corresponding init script. If the behavior is a good idea, we should do it regardless of the init system, I would think I agree. In Ubuntu we've carried this for a while now: | $ cat /etc/cron.weekly/fstrim | #!/bin/sh | # trim all mounted file systems which support it | /sbin/fstrim --all || true This is init system agnostic, and with anacron it also works nicely on desktops. Of course, if in your view as a maintainer this functionality isn't ready for jessie or you don't want to support it, just backing out of the change also works. It also took us quite some time in Ubuntu to enable it by default, and we did extensive measurements to see which approach is best. But not trimming SSDs is really quite bad these days, so from my POV it would be quite prudent to include either the timer or the cron job in jessie. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#768315: unblock: util-linux/2.25.2-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I'm seeking pre-approval for a not-yet-uploaded version of util-linux. Justification: probably better to revert and postpone to Jessie+1. Bug number/severity: #767194 important Changelog entry: Ship fstrim timer/service units as examples only Full description and debdiff below Please (eventually) unblock package util-linux Explanation of changes: Martin Pitt reported fstrim taking a long time on his system and in combination with init-system-helpers (dh_systemd) starting the fstrim /service/ in postinst this will make the package upgrade take a long time. An improvement to dh_systemd_start has been suggested in #767429. Apart from that, others have expressed that we're apparently not yet mentally ready for shipping systemd units in Debian. Lets just ship the unit files as examples for now and let people continue to trim their SSDs manually (or manually set up their preferred method of having it done regularly for them). Closes: #767194 === debdiff diff -Nru util-linux-2.25.2/debian/changelog util-linux-2.25.2/debian/changelog --- util-linux-2.25.2/debian/changelog 2014-10-24 18:57:51.0 +0200 +++ util-linux-2.25.2/debian/changelog 2014-11-06 13:54:11.0 +0100 @@ -1,3 +1,9 @@ +util-linux (2.25.2-3) unstable; urgency=medium + + * Ship fstrim timer/service units as examples only (Closes: #767194) + + -- Andreas Henriksson andr...@fatal.se Thu, 06 Nov 2014 13:54:04 +0100 + util-linux (2.25.2-2) unstable; urgency=medium * Only ship fstrim service and timer on linux diff -Nru util-linux-2.25.2/debian/util-linux.install util-linux-2.25.2/debian/util-linux.install --- util-linux-2.25.2/debian/util-linux.install 2014-10-24 18:57:51.0 +0200 +++ util-linux-2.25.2/debian/util-linux.install 2014-11-06 13:54:11.0 +0100 @@ -10,8 +10,8 @@ [linux-any] sbin/mkswap [!linux-any] debian/tmp/sbin/mkswap = /sbin/mkswap.linux # weekly fstrim only available on linux -[linux-any] lib/systemd/system/fstrim.timer -[linux-any] lib/systemd/system/fstrim.service +[linux-any] lib/systemd/system/fstrim.timer = /usr/share/doc/util-linux/examples/fstrim.timer +[linux-any] lib/systemd/system/fstrim.service = /usr/share/doc/util-linux/examples/fstrim.service bin/more sbin/agetty sbin/blkid diff -Nru util-linux-2.25.2/debian/util-linux.preinst util-linux-2.25.2/debian/util-linux.preinst --- util-linux-2.25.2/debian/util-linux.preinst 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.25.2/debian/util-linux.preinst 2014-11-06 13:54:11.0 +0100 @@ -0,0 +1,13 @@ +#!/bin/sh +set -e + +# We once shipped fstrim.timer in 2.25.2-2. Undo the timer getting enabled +# and purge the helper state, if upgrading from that version. +if [ $1 = upgrade ] [ $2 = 2.25.2-2 ] \ + [ -x /usr/bin/deb-systemd-helper ] \ + deb-systemd-helper debian-installed fstrim.timer; then + deb-systemd-helper disable fstrim.timer + deb-systemd-helper purge fstrim.timer +fi + +#DEBHELPER# unblock util-linux/2.25.2-3 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106130351.26654.64629.report...@mbpah.endian.se
Bug#768315: unblock: util-linux/2.25.2-3
On Thu, Nov 6, 2014 at 14:13:01 +0100, Andreas Henriksson wrote: diff -Nru util-linux-2.25.2/debian/util-linux.preinst util-linux-2.25.2/debian/util-linux.preinst --- util-linux-2.25.2/debian/util-linux.preinst 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.25.2/debian/util-linux.preinst 2014-11-06 13:54:11.0 +0100 @@ -0,0 +1,13 @@ +#!/bin/sh +set -e + +# We once shipped fstrim.timer in 2.25.2-2. Undo the timer getting enabled +# and purge the helper state, if upgrading from that version. +if [ $1 = upgrade ] [ $2 = 2.25.2-2 ] \ + [ -x /usr/bin/deb-systemd-helper ] \ + deb-systemd-helper debian-installed fstrim.timer; then + deb-systemd-helper disable fstrim.timer + deb-systemd-helper purge fstrim.timer +fi + Why not do that in postinst when you know deb-systemd-helper is available? Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106160942.gb3...@coloquinte.cristau.org
Bug#768315: unblock: util-linux/2.25.2-3
On Thu, Nov 06, 2014 at 05:09:43PM +0100, Julien Cristau wrote: Why not do that in postinst when you know deb-systemd-helper is available? You mean switch from preinst upgrade to postinst configure... sure could do that. On the other hand, if we're upgrading from the given version then we already have everything needed in place so shouldn't matter either way, right? ie. this only affects up to date testing/sid. Noone else. Want me to post a new patch that does postinst configure instead? Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106170921.ga3...@fatal.se
Bug#768315: unblock: util-linux/2.25.2-3
On Thu, Nov 06, 2014 at 02:13:01PM +0100, Andreas Henriksson wrote: Explanation of changes: Martin Pitt reported fstrim taking a long time on his system and in combination with init-system-helpers (dh_systemd) starting the fstrim /service/ in postinst this will make the package upgrade take a long time. An improvement to dh_systemd_start has been suggested in #767429. Apart from that, others have expressed that we're apparently not yet mentally ready for shipping systemd units in Debian. Lets just ship the unit files as examples for now and let people continue to trim their SSDs manually (or manually set up their preferred method of having it done regularly for them). Hi, installing the unit files, which AFAICS entered jessie quite recently, also introduced a dependency on init-system-helpers and in turn on perl, making perl pseudo-essential (#757891). Can we revert this too? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106172604.14121.qm...@461541db25c981.315fe32.mid.smarden.org
Bug#768315: unblock: util-linux/2.25.2-3
On Thu, Nov 06, 2014 at 05:26:04PM +, Gerrit Pape wrote: Hi, installing the unit files, which AFAICS entered jessie quite recently, also introduced a dependency on init-system-helpers and in turn on perl, making perl pseudo-essential (#757891). Can we revert this too? This dependency automatically dissapears with the proposed change. (For the future you should not be holding your breath that I will be sentimental about reintroducing it though. A solution on the perl side is needed.) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106185536.ga3...@fatal.se
Bug#768315: unblock: util-linux/2.25.2-3
Gerrit Pape p...@dbnbgs.smarden.org writes: Hi, installing the unit files, which AFAICS entered jessie quite recently, also introduced a dependency on init-system-helpers and in turn on perl, making perl pseudo-essential (#757891). Can we revert this too? Any package shipping systemd units, which will certainly include other Priority: required packages in the future (although possibly not essential ones), will want to use init-system-helpers, since it provides a critical component of the support for multiple init systems. So while this is helpful, it's not going to resolve that issue, and dropping init-system-helpers isn't a good long-term solution. We'll instead need to figure out the best way to make sure that what that package is doing can be done correctly. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egtf35mc@hope.eyrie.org
Bug#768315: unblock: util-linux/2.25.2-3
Andreas Henriksson andr...@fatal.se writes: Apart from that, others have expressed that we're apparently not yet mentally ready for shipping systemd units in Debian. I wouldn't put it quite this way. Rather, I'd say that maintaining feature parity between sysvinit and systemd wherever possible for jessie is a good goal. The concern with the service unit is that it's only a service unit with no corresponding init script. If the behavior is a good idea, we should do it regardless of the init system, I would think (so another fix, if this is functionality we need for jessie, is to introduce an init script that would be naturally shadowed by the unit file if the system is running systemd). The concern with the timer file is similar; if this is functionality we should enable, we should (per Policy) do so with an /etc/cron.weekly script, which will work with any of the cron facilities in Debian. Of course, if in your view as a maintainer this functionality isn't ready for jessie or you don't want to support it, just backing out of the change also works. (And to be clear I'm not on the release team, and it's their opinion that matters.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fz735cs@hope.eyrie.org
