Created attachment 585580 [details] Patch to build ddate into separate package Description of problem: Since util-linux 2.20.1, ddate is not built by default any more. Fedora started this trend and, thus, follows it. This creates a backward incompatibility with basically any other major linux distribution out there (most decided to build util-linux with ddate). I created and attached a patch for the util-linux.spec file to build ddate into a separate package, as this seems to be the preferred solution for fedora (according to mailing list[1]). Version-Release number of selected component (if applicable): 2.20.1 and above [1]: <https://lists.fedoraproject.org/pipermail/devel/2011-August/156165.html>
Created attachment 585581 [details] Fix wrong license statement ddate is actually Public Domain according to manpage.
If you love ddate so much... what about to fork it from util-linux to a separate ddate upstream package? You can start a new ddate repository somewhere on github, regulary release ddate tarball and add the package to Fedora and another distributiuons.
ddates upstream is beyond the scope of fedora and thus, this bug report. I indeed think that removing ddate from the default configuration was a kind of short-circuit reaction motivated by who-knows-what. The major distributions besides fedora thus decided to build util-linux with ddate[1][2] or at least provide a separate package[3]. I fail to understand why you're so desperate to remove ddate from the linux world (which didn't work out anyway, since most distributions re-included it), especially because, no offense, but, you have made very few rational arguments in all the discussion. Apart from the religious one, it feels for me like the only point from your side was “because I want to”, implicitly brought across via “package it yourself if you want it” or “crazy tool”[4] statements. As for the religious argument, there has been some discussion on the mailing list, namely the reference to religious texts in the man page of ddate[5]. There was a quote from the Packaging Guidelines: > Some examples of content which are not permissable: > > Comic book art files > Religious texts > ... However, this quote was dragged out of context. In the original source[6], its in a section called “Code vs. Content”. ddate itself, however, is cleary code. Its manpage belongs to ddate as documentation how to use it. If this all is really just about the link in the ddate manpage[7], fedora should reconsider its motto for “content freedom” it states on the main page. I can also not see how ddate is a burden to maintain. It's not like it was a setuid binary or had a whole bunch of bugs in the last year. How many issues were there with ddate in the whole lifetime of this bugtracker? Run a search, you will (probably) find a whole number of 8 when including closed bugs for a search for “ddate”. One is this one, another is #801659, with a similar request. One is a bug requesting the remove of ddate with the same “rational” arguments as in the mailing list. Two are unrelated bugs where ddate happens to occur in the title/text. Three are actually related: #9601, #666901 and (more or lessly) #637026 (for fun, compare the amount of relevant bugs for fortune. On a first glance, there are at least five). So I ask to reintroduce ddate into fedora, be it at util-linux or in a separate package (the first one would actually be preferred). For the sake of completeness within the linux traditions, for the sake of compatibility with other distributions including older fedora versions and to show that fedora is not governed by the arbitary decisions of upstream package maintainers. [1]: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650321> [2]: <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/988925> [3]: <https://bugs.archlinux.org/task/25826> [4]: <https://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=4a8962f3a7cb970b28add7d770528edebbe03635> [5]: <https://lists.fedoraproject.org/pipermail/devel/2011-August/156168.html> [6]: <https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content> [7]: <http://manpages.ubuntu.com/manpages/gutsy/man1/ddate.1.html>
I don't see why it should be necessary to fork ddate when there's already a package that contains it. It would be much cleaner to provide ddate from the util-linux source, either as a default or as a seperate package. Besides, the tool being delivered with linux is nice little reminder for the historic roots of linux/unix that had some healthy nerdy humour, which sadly seems outdated today...
Addendum: From: <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/988925/comments/9> > And I really don't see what harm it does when built by default. It is really > not heavy on resources, it is invisible for most users, and very useful to > some. > I totally agree with the Debian folks, and totally disagree with Karel Zak > from upstream. It is much crazier to force users to compile util-linux > manually, just because they are discordians, than it is to build it by > default. Craziness is to assume that somebody is able to do it by just being > discordian. And preventing access to such a tool is a violation of some basic > human rights.
It seems there is a new ddate(1) upstream: https://github.com/bo0ts/ddate I think you can follow Arch friends and use this new upstream for completely new ddate package. It's also portunity to improve ddate code.
*** Bug 832819 has been marked as a duplicate of this bug. ***
Obviously and as expected, there are more requests for ddate, which is, I think, a reason to repoen this bugreport. Further sources of surprise and rejection of the change to remove ddate: • <https://lwn.net/Articles/499184/> • bug 832819 While more people start to disagree, we still did not hear any rational reason for the removal of ddate, while a rational reason _not_ to remove ddate is obviously that it broke regression. I mean, the main point I have is, that you, Karel Zak, just removed ddate without a giving friggin reason. All I've read is completely irrational and without any logic. I just want to _understand_ what's going on in your mind. What is the reason for you to remove that tool from util-linux? The only “reward” you gain is dislike from the community who uses it and ignorance from those who do not. On the mailing list there were indeed a few people (three, four?) who stood up and said, hey, we ddate do not like ddate. But hell, I do not like KDE either and I know a few others who do not either. Still, KDE is in the Fedora repositories, if I want or not. Okay, you may object that KDE isn't installed by default, but it at least has its own official _spin_ of fedora images. I'll just quote the guy from lwn who also gave a good point on that: > It's "pointless junk" like this that makes me believe the Linux world > really is different from other places. In the midst of of grey-faced > corporate seriousness it's nice to know that you can still find ddate > and sometimes even sl. "Was that a train?" -- surprised colleague. For me it just looks like you made a kneejerk reaction to satisfy a few users and do something you always wanted to do but never had a reason to back you. The few users who agreed with you gave you that “reason”, and now you found that actually, that reason is no reason which can hold against rational discussion, but you're too much of a coward to revert.
Karel Zak, please help me to understand your decision making process. One user fat-fingered the date command and didn't like the result, so your solution is to break util-linux for users who rely on the ddate command? Why did you not simply advise this user to take a look at the screen before he hits the enter key and make sure that the command he wishes to run is the command he actually typed? Please reconsider your decision to not fix the problem that you have introduced. Thank you.
This is my last reply. - util-linux upstream is hardly working for years on code and utils consolidation and clean up... - ddate(1) is disabled by default in upstream tree since Aug 2011 - all relevant util-linux upstream contributors and collaborating down-stream maintainers (Suse, Arch, Fedora, ...) agree that ddate(1) should be removed from util-linux. - the decision about Fedora ddate(1) has been publicly discussed at fedora-devel list one year ago - there is new ddate(1) upstream at https://github.com/bo0ts/ddate and it seems that the code is maintained by someone who is able to follow Discordian's humor/religion - Fedora is open for new packages, all you need is to follow http://fedoraproject.org/wiki/Packaging:Guidelines to create ddate.rpm Personally, I don't want to maintain any code that I don't understand and which is completely unnecessary from my point of view. It's my time, my project, my responsibility and my freedom to make decisions. If you don't like this nature of the open source world, then install any commercial Linux distributions and ask for help at paid support. Fortunately we're talking about open source code, so you can fork the code (already done at github) and create and maintain the package in Fedora. Stop trolling, go ahead and invest *your* time to ddate.rpm.
Expressing a legitimate grievance is not trolling. You are the one who broke util-linux for users who use ddate. Does this mean that any utility that you don't use personally is potentially on the chopping block? Is it advisable to rely on the existence of any utility in util-linux?
(In reply to comment #11) > Expressing a legitimate grievance is not trolling. You are the one who > broke util-linux for users who use ddate. You know what? I would not call your behaviour trolling either. I would call it whining. You are trying to force Karel to do something for you that you are not willing to do yourself. The utility is still there, with a new upstream. If you really wanted it so bad, you would just write a new spec and post a RPM for review; I doubt it would take more time that it took you to write the responses here. And since there is evidently (or, better to say, by your evidence) so many people who cannot live without it, it surely would be reviewed in no time. > > Does this mean that any utility that you don't use personally is potentially > on the chopping block? Is it advisable to rely on the existence of any > utility in util-linux? Now you are trolling. And since I do not like trolls, I can only answer: yes, any utility from util-linux is on the chopping block. The (secret) ultimate plan is to remove everything. So you should go and fork util-linux till there is still time. I wish you luck maintaining your fork!
Point taken. I apologize to both you and Karel for being snarky. I'm sorry. It's not my intention to try and create more work for Karel and force to him create and maintain a new package. The bug that I filed (832819), which Karel closed as a duplicate of this one, only asked him to revert the change he made to disable this utility. ddate has been part of util-linux for around fifteen years or so and has never been a problem. Karel created this issue by disabling this utility with no regard for the people who use it. If he had just left it alone, then everything would be fine. I'm reading the packaging guidelines that Karel linked earlier so I can learn how to create packages. If no one else is already doing this and this is the only way to get this bug fixed, then I'll do it. It just seems to me that reverting a commit on github would be a much simpler solution.
(In reply to comment #13) > I'm reading the packaging guidelines that Karel linked earlier so I can > learn how to create packages. If no one else is already doing this and this > is the only way to get this bug fixed, then I'll do it. It just seems to me > that reverting a commit on github would be a much simpler solution. Well, I'm also looking at the fork on github Karel mentioned, and it would not be my first rpm specfile, but the first I'd intend to submit. The build works fine, I just have to verify it against the packaging guidelines.
(In reply to comment #14) > The build works fine, I just have to verify it against the packaging > guidelines. I am not a sponsor (if you need, you have to ask somebody else), but when you have the package ready for submission and when you need a packaging review, let me know. As a Christian I always want to help other religious minorities in the open source, no matter how nonsensical they seem to be ;).
*** Bug 833254 has been marked as a duplicate of this bug. ***
Just stumbled into this bug as well, fighting with some our our newly upgraded development boxes that would not run as expected anymore. ddate has been in util-linux for a very long time, probably much much longer than the person who decided to drop it can call himself a software developer (the oldest version I found dates back to 1994, but thats probably not the oldest version). Removing core utilities from one of the real core packages in linux without giving at least an installable, ready to use alternative is an annoying thing. And the given explanation says it all: > I don't want to maintain any code that I don't understand and which is > completely unnecessary from my point of view. And then yelling to the users to build their own version of a package is more than ignorant. Open source is exactly not about following a single person's "point of view".
Karel Zak, gobble gobble gobble Gobble Gobble GOBBLE GOBBLE GOBBLE!