I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Karel
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
I'd like to remove: ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments?
Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.?
If it is maintained, and works then it should stay.
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
I'd like to remove: ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments?
Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.?
If it is maintained, and works then it should stay.
+1. I don't use vim or rythmbox or play tremulous, and their presence doesn't hurt me or my mirror. :)
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 29 Aug 2011 07:25:18 -0500, JC (Jon) wrote:
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
I'd like to remove: ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments?
Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.?
If it is maintained, and works then it should stay.
+1. I don't use vim or rythmbox or play tremulous, and their presence doesn't hurt me or my mirror. :)
$ rpm -qf /usr/bin/ddate util-linux-2.19.1-1.4.fc15.x86_64
As such it is part of every installation. It could be optional instead.
$ man ddate [...] |NOTE | After `X-Day' passed without incident, the Church of the SubGenius | declared that it had got the year upside down - X-Day is actually in | 8661 AD rather than 1998 AD. Thus, the True X-Day is Cfn 40, 9827. [...]
Strange humor to install something like that in a util-linux package.
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage.
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable: | | Comic book art files | Religious texts | ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable: | | Comic book art files | Religious texts | ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote:
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable: | | Comic book art files | Religious texts | ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate" also in "man date"?
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote:
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by
very
very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package.
If
someone actually misses the command, it can always be resurrected
later
in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps
that
person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion
(or
a joke religion) enters a grey area with regard to the packaging
policies:
| Some examples of content which are not permissable: | | Comic book art files | Religious texts | ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate" also in "man date"? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
-J
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great.
That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it...
If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
- it's joke rather than anything useful - it's installed on all systems, but almost nobody uses this crap
Karel
On 08/29/2011 05:00 PM, Karel Zak wrote:
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great.
That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it...
If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
- it's joke rather than anything useful
Then have upstream remove it from _their_ sources.
Ralf
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great.
That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it...
If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
- it's joke rather than anything useful
- it's installed on all systems, but almost nobody uses this crap
Really? How do you know that?
-J
Karel
-- Karel Zak kzak@redhat.com http://karelzak.blogspot.com
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote:
The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate" also in "man date"?
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
With that point of view, it's probably impossible to convince you. I won't try. I just encourage Karel to get rid of ddate somehow.
A "valid reason" IMO is to build a base distribution, a product -- our product -- which does not consist of "extremely silly code" and which does not advertise dubious religions. Not even with links as found in the manual. There are several scenarios where we divert from upstream due to various circumstances.
Whether it's harmful to distribute ddate, I don't know. Isn't it enough reason to not offer something because it's considered silly/crazy crap? Or if it doesn't make sense to ship it as part of a default OS environment?
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
| Most common Linux operating system-distributions have the command ddate | to show the current Discordian date.
Strange people these Linux people.
http://en.wikipedia.org/wiki/Discordian_calendar#Implementations
| ddate, a program that prints the current date in the Discordian calendar, | is part of the util-linux package of basic system utilities.[6] As such, | it is included in nearly all Linux distributions, despite some | resistance.[7] There are many other programs with similar functionality.
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote:
The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate"
also
in "man date"?
That may be (both are human constructs, it's like say "hey, that's made up word!", but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit.
With that point of view, it's probably impossible to convince you. I won't try. I just encourage Karel to get rid of ddate somehow.
A "valid reason" IMO is to build a base distribution, a product -- our product -- which does not consist of "extremely silly code" and which does not advertise dubious religions. Not even with links as found in the manual. There are several scenarios where we divert from upstream due to various circumstances.
Sure, for sufficient reasons.
Whether it's harmful to distribute ddate, I don't know. Isn't it enough reason to not offer something because it's considered silly/crazy crap? Or if it doesn't make sense to ship it as part of a default OS environment?
I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply "gosh, I don't sue that, so. . .". Otherwise we'll start dropping games.
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
| Most common Linux operating system-distributions have the command ddate | to show the current Discordian date.
Strange people these Linux people.
http://en.wikipedia.org/wiki/Discordian_calendar#Implementations
| ddate, a program that prints the current date in the Discordian calendar, | is part of the util-linux package of basic system utilities.[6] As such, | it is included in nearly all Linux distributions, despite some | resistance.[7] There are many other programs with similar functionality.
-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote:
I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply "gosh, I don't sue that, so. . .". Otherwise we'll start dropping games.
Sure (and not limited to games, which are in optional packages, however).
We do that all the time, if a package maintainer no longer considers a game (or package in general) worthwhile, and if nobody else volunteers to take over a package. Of course, you're free to adapt as many orphans as you like, whether actively maintained upstream or ancient.
Eventually, you'll be in the same situation, where you would like to drop something, be it a completely optional package or a plugin [*] you consider useless, close to useless, or just broken. [*] or a program with alternative user-interfaces
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote:
I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply "gosh, I don't sue that, so. . .". Otherwise we'll start dropping games.
Sure (and not limited to games, which are in optional packages, however).
We do that all the time, if a package maintainer no longer considers a game (or package in general) worthwhile, and if nobody else volunteers to take over a package. Of course, you're free to adapt as many orphans as you like, whether actively maintained upstream or ancient.
Eventually, you'll be in the same situation, where you would like to drop something, be it a completely optional package or a plugin [*] you consider useless, close to useless, or just broken. [*] or a program with alternative user-interfaces
Absolutely! I've been there. It's not the retirement of software I object to in this case, though I prefer to avoid that, it's the arbitrary deviation from upstream. If the deviation isn't arbitrary, I generally support it.
All that aside, I'd be sad to see ddate go, but that's totally beside the point. :)
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Aug 29, 2011 at 08:32:01AM -0500, Jon Ciesla wrote:
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable: | | Comic book art files | Religious texts | ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
OTOH including tiny programs that remind people that real religious belief is nonsense has to be a good thing.
Rich.
On Mon, Aug 29, 2011 at 11:06 AM, Richard W.M. Jones rjones@redhat.com wrote:
OTOH including tiny programs that remind people that real religious belief is nonsense has to be a good thing.
On the contrary, biting one's tongue instead of offering off-topic gratuitous insults to fellow Fedorans has to b a good thing.
Yes, it was a joke and off-topic for this list. (Not on my blog though ..)
Rich.
I was looking for stuff on your website and noticed that the Fedora OCaml project link is down:
http://www.cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Wed, Aug 31, 2011 at 01:17:44PM -0400, Przemek Klosowski wrote:
I was looking for stuff on your website and noticed that the Fedora OCaml project link is down:
http://www.cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Yes, this has unfortunately been broken for a while. It was running on an old Debian machine that needed an urgent update and at the same time I had to rebuild the wiki software, and TBH it was too much, I just took the whole thing down.
Shame really though. Is there a way to get a nice summary of what versions of package(s) are in Fedora, grouped by project (comps group)?
This is what it used to look like:
http://web.archive.org/web/20100424032649/http://cocan.org/getting_started_w...
Rich.
2011-08-31 16:32 keltezéssel, Jerry James írta:
On Mon, Aug 29, 2011 at 11:06 AM, Richard W.M. Jones rjones@redhat.com wrote:
OTOH including tiny programs that remind people that real religious belief is nonsense has to be a good thing.
On the contrary, biting one's tongue instead of offering off-topic gratuitous insults to fellow Fedorans has to b a good thing.
<sarcarm_mode> How about removing fortune-mod as well in one go? A lot of its quotes can be offending to some people. </sarcasm_mode>
Best regards, Zoltán Böszörményi
On 08/29/2011 05:24 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved?
Rahul
On 08/29/2011 05:24 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved?
Acceptable to me, but is the extra metadata for another RPM worth the space savings?
-J
Rahul
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Once upon a time, Jon Ciesla limb@jcomserv.net said:
On 08/29/2011 05:24 PM, Karel Zak wrote: IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved?
Acceptable to me, but is the extra metadata for another RPM worth the space savings?
Is that why this is being done? Space savings? On my F15 system, ddate, the README, and the manual pages account for 22k.
If space is the justification, there's lots of better places to start. Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? How many tools do we really need for partitioning disks and managing partitions (util-linux has fdisk, sfdisk, cfdisk, partx, blockdev, all with associated documentation)?
Note: I am NOT saying any of that should be removed. I'm just saying that "space savings" as justification of removing ddate is stupid.
Chris Adams wrote:
Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)?
Why does it have any floppy tools any more? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases.
Chris Adams wrote:
Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)?
Why does it have any floppy tools any more? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Because there are still people with floppy drives?
-J
On Mon, Aug 29, 2011 at 09:44:33AM -0500, Jon Ciesla wrote:
Because there are still people with floppy drives?
+1
It's ridiculous to think that older HW doesn't exist because systems with that HW are not sold anymore (I don't even know id the latter is true at all -- some special purpose systems might still have it).
We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore.
Don't let us all fall in the GNOME3 trap (assuming that all hardware now has accelerated graphics support, which is even more ridiculous, although GNOME3 has become useless for most people I know anyway).
Sorry, I couldn't resist...
Jos Vos wrote:
We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore.
No. You're making an apples to orange comparison. Just like Jon has done this whole thread.
This bike shedding as gone on long enough.
Remove ddate. Karel, you're upstream. Do it.
P.S. Your argument will be moot when the kernel drops the floppy module.
Jos Vos wrote:
We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore.
No. You're making an apples to orange comparison. Just like Jon has done this whole thread.
This bike shedding as gone on long enough.
Playing devil's advocate != bikeshedding. But, I agree that this discussion is aging rapidly.
Remove ddate. Karel, you're upstream. Do it.
Now *this* makes sense. I never advocated ddate being preserved in lucite forevermore. I just wanted a sane reason to deviate from upstream. if upstream drops it, the point is moot, and I think that's fine.
P.S. Your argument will be moot when the kernel drops the floppy module.
Is there actually a plan for this to happen? Curious, not arguing here.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2011-08-29 at 16:58 +0200, Jos Vos wrote:
Don't let us all fall in the GNOME3 trap (assuming that all hardware now has accelerated graphics support, which is even more ridiculous, although GNOME3 has become useless for most people I know anyway).
GNOME 3 does not do that. It has an entire alternative shell - the fallback mode - which exists expressly to support systems which cannot run Shell.
On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote:
Chris Adams wrote:
Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)?
Why does it have any floppy tools any more?
because we still support floppy devices?
The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases.
Does it mean that "modprobe floppy" does not work?
Karel
Karel Zak wrote:
On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote:
The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases.
Does it mean that "modprobe floppy" does not work?
No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG.
Similarily, analog joystick support (yes, those joysticks you plug on the MIDI ports of those old sound cards) also has to be modprobed manually.
And yes, I have all that stuff plugged on this machine. I barely ever use it, but that doesn't mean I don't want it to work…
Kevin Kofler
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG.
It is very irritating, since I only use floppies when I really need to, and usually I've upgraded the system (I typically do clean installs) since the last time. I always have to stop and manually configure the floppy drive again.
For a while, USB floppy drives got correctly configured when you plugged them in (a udev rule was added to get /dev/floppy links and ownership), but that was removed somewhere along the line. I own the package for formatting floppies in USB drives (ufiformat), and it is also irritating when I go test it for new releases. With changes over time, I don't know how to get the device nodes with the correct access for the desktop user anymore, and I figure if somebody went to the trouble of removing the udev rules, there's not much point in asking to have them added back.
On 08/29/2011 10:22 PM, Chris Adams wrote:
It is very irritating, since I only use floppies when I really need to,
Is this due to the need to boot into DOS to run a firmware utility or something similar? If so, you can create a bootable, DOS USB flash drive. I haven't had a need for a floppy disk in years.
On Tue, Aug 30, 2011 at 1:58 PM, Michael Cronenworth mike@cchtml.comwrote:
On 08/29/2011 10:22 PM, Chris Adams wrote:
It is very irritating, since I only use floppies when I really need to,
Is this due to the need to boot into DOS to run a firmware utility or something similar? If so, you can create a bootable, DOS USB flash drive. I haven't had a need for a floppy disk in years.
I can't see any reason for floppies these days considering their extreme price per data unit as opposed to usb memory.
I don't flash much these days. And for times when I feel the need to, I go about it by whatever other means is necessary to avoid anything to do with floppies.
That's not to say that the Linux kernel should not support floppy drives. That's an entirely different discussion really.
Regards
Chris Jones
[image: linux.png]
On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
I can't see any reason for floppies these days considering their extreme price per data unit as opposed to usb memory.
For some people the price of floppies is a sunk cost, or was never a cost at all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years ago, some at 0 price).
Unlike USB chips in most budgets, each floppy is cheap enough to be disposable after one use or dedicated to one small file.
Floppies have enough room on them to write down something legible about their content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz brand AMI BIOS; etc.) which won't interfere with insertion or removal from its reader.
Floppies are large enough to be much less likely than a USB stick to get lost between couch cushions or fit through a pocket hole.
Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
A rude installer might unset a bootable flag or fail to install boot code in the MBR of the only available internal storage, leaving the primary boot device unbootable, and a floppy the only available device to boot from without opening up the machine, if opening up is even any option at all.
IOW, poor as they are, floppies still have both advantages and uses.
On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
I can't see any reason for floppies these days considering their extreme price per data unit as opposed to usb memory.
For some people the price of floppies is a sunk cost, or was never a cost at all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years ago, some at 0 price).
Unlike USB chips in most budgets, each floppy is cheap enough to be disposable after one use or dedicated to one small file.
Floppies have enough room on them to write down something legible about their content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz brand AMI BIOS; etc.) which won't interfere with insertion or removal from its reader.
Floppies are large enough to be much less likely than a USB stick to get lost between couch cushions or fit through a pocket hole.
Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
A rude installer might unset a bootable flag or fail to install boot code in the MBR of the only available internal storage, leaving the primary boot device unbootable, and a floppy the only available device to boot from without opening up the machine, if opening up is even any option at all.
CD/DVD ?
On Tue, 2011-08-30 at 08:40 +0200, drago01 wrote:
On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
I can't see any reason for floppies these days considering their extreme price per data unit as opposed to usb memory.
For some people the price of floppies is a sunk cost, or was never a cost at all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years ago, some at 0 price).
Unlike USB chips in most budgets, each floppy is cheap enough to be disposable after one use or dedicated to one small file.
Floppies have enough room on them to write down something legible about their content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz brand AMI BIOS; etc.) which won't interfere with insertion or removal from its reader.
Floppies are large enough to be much less likely than a USB stick to get lost between couch cushions or fit through a pocket hole.
Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
A rude installer might unset a bootable flag or fail to install boot code in the MBR of the only available internal storage, leaving the primary boot device unbootable, and a floppy the only available device to boot from without opening up the machine, if opening up is even any option at all.
CD/DVD ?
"Write Once Read Many"? Wait... "Write Once Read Once" in this case. Not cheap enough for that.
Nils
On 2011/08/30 08:40 (GMT+0200) drago01 composed:
Felix Miata wrote:
...OM...
CD/DVD ?
Once upon a time, Michael Cronenworth mike@cchtml.com said:
On 08/29/2011 10:22 PM, Chris Adams wrote:
It is very irritating, since I only use floppies when I really need to,
Is this due to the need to boot into DOS to run a firmware utility or something similar? If so, you can create a bootable, DOS USB flash drive. I haven't had a need for a floppy disk in years.
That's nice that you haven't needed one, but I have. I try all kinds of alternatives first (up to PXE booting syslinux to load memdisk and a floppy image), but I have run into things that just really need an actual floppy.
It isn't why I use floppies under Linux, but my mother's very expensive computerized embroidery machine uses floppies to transfer patterns. There are still things in the real world that exclusively use floppy disks, and they aren't going away as rapidly as some seem to think.
On 08/30/2011 08:02 AM, Chris Adams wrote:
There are still things in the real world that exclusively use floppy disks, and they aren't going away as rapidly as some seem to think.
No need to tell me. I work everyday with SCO Unix machines that have no idea what a USB device is. I've just found alternatives.
On 08/30/2011 09:02 AM, Chris Adams wrote:
It isn't why I use floppies under Linux, but my mother's very expensive computerized embroidery machine uses floppies to transfer patterns. There are still things in the real world that exclusively use floppy disks, and they aren't going away as rapidly as some seem to think.
I feel your pain; a lot of perfectly good lab equipment has floppies too, but whenever practical, I'd recommend a USB floppy drive emulator from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or http://www.floppytousb.com/
On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski < przemek.klosowski@nist.gov> wrote:
I feel your pain; a lot of perfectly good lab equipment has floppies too, but whenever practical, I'd recommend a USB floppy drive emulator from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or http://www.floppytousb.com/
I take it those usb based external floppy readers are auto-detected like sane hardware should be?
-jef
On 08/30/2011 03:18 PM, Jef Spaleta wrote:
On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski <przemek.klosowski@nist.gov mailto:przemek.klosowski@nist.gov> wrote:
I feel your pain; a lot of perfectly good lab equipment has floppies too, but whenever practical, I'd recommend a USB floppy drive emulator from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or http://www.floppytousb.com/
I take it those usb based external floppy readers are auto-detected like sane hardware should be?
They connect to the floppy cable and look like a floppy drive.
On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski < przemek.klosowski@nist.gov> wrote:
They connect to the floppy cable and look like a floppy drive.
Bah, I'd think you'd want to go the other way if you could get an external usb based floppy reader which is autodetected on the usb bus. Anything that hangs off the onboard floppy controller is going to need some lovin.
-jef
On 08/30/2011 03:36 PM, Jef Spaleta wrote:
On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski <przemek.klosowski@nist.gov mailto:przemek.klosowski@nist.gov> wrote:
They connect to the floppy cable and look like a floppy drive.
Bah, I'd think you'd want to go the other way if you could get an external usb based floppy reader which is autodetected on the usb bus. Anything that hangs off the onboard floppy controller is going to need some lovin.
Problem with the old equipment is that it often does not have USB or indeed predates USB
Once upon a time, Jef Spaleta jspaleta@gmail.com said:
Bah, I'd think you'd want to go the other way if you could get an external usb based floppy reader which is autodetected on the usb bus. Anything that hangs off the onboard floppy controller is going to need some lovin.
These are for embedded systems that use a standard PC-style floppy controller. Replace the floppy drive with something else that still looks to the system like a regular floppy drive.
On Tue, Aug 30, 2011 at 03:33:04 +0200, Kevin Kofler kevin.kofler@chello.at wrote:
No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG.
There was significant discussion about this issue on the mailing lists and Kyle thought he had a good solution to having the floppy drive recognized when it was there and not adding long delays to the boot up for people with incorrectly configured (your supposed to disable the floppy drive in the bios when you don't have one) or broken bios. I am not sure what happened with the implementation of the solution.
Similarily, analog joystick support (yes, those joysticks you plug on the MIDI ports of those old sound cards) also has to be modprobed manually.
I also have a gamepad which is like a joystick and need to do modprobe analog to get it recognized.
On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 03:33:04 +0200, Kevin Kofler kevin.kofler@chello.at wrote:
No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG.
There was significant discussion about this issue on the mailing lists and Kyle thought he had a good solution to having the floppy drive recognized when it was there and not adding long delays to the boot up for people with incorrectly configured (your supposed to disable the floppy drive in the bios when you don't have one) or broken bios. I am not sure what happened with the implementation of the solution.
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
The "easiest" solution would be to fix the floppy driver to probe in the background but I suspect most people would prefer to empty biohazard containers full of used needles by hand than touch floppy.c.
Similarily, analog joystick support (yes, those joysticks you plug on the MIDI ports of those old sound cards) also has to be modprobed manually.
I also have a gamepad which is like a joystick and need to do modprobe analog to get it recognized.
There's no way to get any feedback from the gameport driver as to (a) whether there's anything plugged in, or (b) what is plugged in. We could have the gameport driver automatically pull in analog but that'd probably break people doing midi or using some more specialised input device. It's a hard problem that only impacts a pretty tiny set of people, so it's prioritised somewhere below the hard problems that impact a pretty large set of people.
On Tue, Aug 30, 2011 at 13:41:57 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
Thanks for the explanation.
There's no way to get any feedback from the gameport driver as to (a) whether there's anything plugged in, or (b) what is plugged in. We could have the gameport driver automatically pull in analog but that'd probably break people doing midi or using some more specialised input device. It's a hard problem that only impacts a pretty tiny set of people, so it's prioritised somewhere below the hard problems that impact a pretty large set of people.
Again thanks for the explanation. I had figured gameports might be hard to detect so I wasn't too worried about this. I did want to mention what you needed to include on the modprobe command to get the the driver loaded in case someone wandered accross the thread later.
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote:
On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 03:33:04 +0200, Kevin Kofler kevin.kofler@chello.at wrote:
No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG.
There was significant discussion about this issue on the mailing lists and Kyle thought he had a good solution to having the floppy drive recognized when it was there and not adding long delays to the boot up for people with incorrectly configured (your supposed to disable the floppy drive in the bios when you don't have one) or broken bios. I am not sure what happened with the implementation of the solution.
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
That seems like a clear opportunity to add a simple "configure legacy hardware" button to anaconda, that would do the modprobe floppy/gameport etc. stuff so it is loaded. Perhaps there could be switches: I have these legacy hardware: Floppy disk Analog joystick .... whatever
On Tue, Aug 30, 2011 at 03:20:22PM +0200, Tomas Mraz wrote:
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote:
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
That seems like a clear opportunity to add a simple "configure legacy hardware" button to anaconda, that would do the modprobe floppy/gameport etc. stuff so it is loaded. Perhaps there could be switches: I have these legacy hardware: Floppy disk Analog joystick .... whatever
Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them.
On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to perhaps put floppy.conf or joystick.conf in /etc/modprode.d? With a post install script to run modprobe manually?
Are pretty much all joysticks handled by analog or is that situation more complicated?
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to perhaps put floppy.conf or joystick.conf in /etc/modprode.d? With a post install script to run modprobe manually?
That seems like it'd work.
Are pretty much all joysticks handled by analog or is that situation more complicated?
Most are. There are some devices that need their own drivers, and as far as I know there's no defined PNP protocol for joysticks.
On Tue, Aug 30, 2011 at 14:37:16 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to perhaps put floppy.conf or joystick.conf in /etc/modprode.d? With a post install script to run modprobe manually?
That seems like it'd work.
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
I'll investigate that. Once I know the right thing to do, the packaging should be pretty easy.
On 30/08/11 14:23, Bruno Wolff III wrote:
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
Or modules-load.d if you want to force load a module.
tom
On Tue, Aug 30, 2011 at 14:50:10 +0100, Tom Hughes tom@compton.nu wrote:
On 30/08/11 14:23, Bruno Wolff III wrote:
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Thanks, that sounds better.
I'll add making packages to do this to my to do list. They should be pretty easy to do, so there's a good chance I'll get to it soon. I'll add a comment to the thread when I have something ready for review.
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
On 30/08/11 14:23, Bruno Wolff III wrote:
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Matthew Garrett (mjg59@srcf.ucam.org) said:
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
On 30/08/11 14:23, Bruno Wolff III wrote:
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Is there a reason that (at least for the one case) this wouldn't just go in the joystick package?
Bill
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote:
Matthew Garrett (mjg59@srcf.ucam.org) said:
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Is there a reason that (at least for the one case) this wouldn't just go in the joystick package?
Joystick seems to be part of the default install (it handles USB devices as well as legacy ones), and we probably wouldn't want this by default.
On Tue, 2011-08-30 at 17:11 +0100, Matthew Garrett wrote:
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote:
Matthew Garrett (mjg59@srcf.ucam.org) said:
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Is there a reason that (at least for the one case) this wouldn't just go in the joystick package?
Joystick seems to be part of the default install (it handles USB devices as well as legacy ones), and we probably wouldn't want this by default.
Yes, but it could be a subpackage of it. No need to create new source package for just this simple configuration file.
Tomáš Mráz
Below is a proposed specfile for the floppy case. (Analog joystick would be very similar.) I haven't tested the package for functionality yet, but did test it with rpmbuild and rpmlint. Is this what we want? Is this ready for a formal review?
Name: floppy-support Version: 1.0 Release: 1%{?dist} Summary: Load floppy driver at boot time Group: System Environment/Kernel
License: MIT # The package is built just using this specfile. #URL: #Source0:
Requires(post): module-init-tools
BuildArch: noarch
%description By default the floppy driver is not loaded at boot time. Installing this package will load the floppy driver as part of the install and will set things so that it will be loaded during future boots.
%prep #No setup, since no source outside the specfile.
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%files %{_libdir}/modules-load.d/floppy.conf
%post /sbin/modprobe floppy
%changelog * Tue Aug 30 2011 Bruno Wolff III bruno@wolff.to 1.0-1 - Initial package creation
Hi,
On 08/31/2011 05:41 AM, Bruno Wolff III wrote:
Below is a proposed specfile for the floppy case. (Analog joystick would be very similar.) I haven't tested the package for functionality yet, but did test it with rpmbuild and rpmlint. Is this what we want?
I don't know about others, but I love it. Actually a constructive solution to the problem being discussed, we could even put it in comps (as not enabled by default) :)
Is this ready for a formal review?
Putting it up for formal review gets my vote, but first lets see what other think for a bit.
As always many thanks for you excellent and constructive work on Fedora.
Regards,
Hans
Name: floppy-support Version: 1.0 Release: 1%{?dist} Summary: Load floppy driver at boot time Group: System Environment/Kernel
License: MIT # The package is built just using this specfile. #URL: #Source0:
Requires(post): module-init-tools
BuildArch: noarch
%description By default the floppy driver is not loaded at boot time. Installing this package will load the floppy driver as part of the install and will set things so that it will be loaded during future boots.
%prep #No setup, since no source outside the specfile.
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d echo floppy> $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%files %{_libdir}/modules-load.d/floppy.conf
%post /sbin/modprobe floppy
%changelog
- Tue Aug 30 2011 Bruno Wolff IIIbruno@wolff.to 1.0-1
- Initial package creation
On Tue, Aug 30, 2011 at 10:41:45PM -0500, Bruno Wolff III wrote:
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%{_sysconfdir} instead of %{_libdir} everywhere.
%files %{_libdir}/modules-load.d/floppy.conf
Jakub
On Wed, Aug 31, 2011 at 11:58:41 +0200, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Aug 30, 2011 at 10:41:45PM -0500, Bruno Wolff III wrote:
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%{_sysconfdir} instead of %{_libdir} everywhere.
%files %{_libdir}/modules-load.d/floppy.conf
I am willing to do that, but before going there I want to not this passage from the modules-load.d man page: Packages should install their configuration files in /usr/lib/, files in /etc/ are reserved for the local administration, which possibly decides to overwrite the configurations installed from packages.
Once upon a time, Bruno Wolff III bruno@wolff.to said:
Below is a proposed specfile for the floppy case. (Analog joystick would be very similar.) I haven't tested the package for functionality yet, but did test it with rpmbuild and rpmlint. Is this what we want? Is this ready for a formal review?
That loads the module, but what about configuring device access for desktop users? That's the more irritating part to me (that has changed over time and I no longer know how to fix it). Once loaded, the floppy device should be treated just like any other removable media device as far as user access is concerned.
On Tue, Aug 30, 2011 at 22:41:45 -0500, Bruno Wolff III bruno@wolff.to wrote:
Below is a proposed specfile for the floppy case. (Analog joystick would be very similar.) I haven't tested the package for functionality yet, but did test it with rpmbuild and rpmlint. Is this what we want? Is this ready for a formal review?
I tested this out and it seems to load the floppy module on install and on boot. It does not trigger creating the /dev/floppy sym link and I am not sure if anything affecting how the desktop treats floppies should also be included. (I would think checking for inserted floppies would be annoying in general and shouldn't be the default, but maybe there should be something done to make them mountable by users by default.)
While it is possible to expand the scope a bit later (e.g. include a udev rule in addition), I figured I'd check now to see if anyone had any suggestions about additions before I submit it for review.
I have submitted a review request for floppy-support: https://bugzilla.redhat.com/show_bug.cgi?id=735554
On Tue, Aug 30, 2011 at 14:23, Bruno Wolff III bruno@wolff.to wrote:
On Tue, Aug 30, 2011 at 14:37:16 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mjg59@srcf.ucam.org wrote:
Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to perhaps put floppy.conf or joystick.conf in /etc/modprode.d? With a post install script to run modprobe manually?
That seems like it'd work.
I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things.
I'll investigate that. Once I know the right thing to do, the packaging should be pretty easy.
"man modules-load.d" looks promising too.
Matthew Garrett wrote:
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
I think it's sad that we're sacrificing hardware support for boot times.
We should probe for everything by default. Users who don't have a floppy drive and want to save some boot time can blacklist the driver manually.
Kevin Kofler
On Tue, 2011-08-30 at 18:25 +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
ACPI turned out to be full of lies. The real problem is that machines will report a floppy controller even if they have no floppy drives attached, and the ACPI function that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive.
I think it's sad that we're sacrificing hardware support for boot times.
We should probe for everything by default. Users who don't have a floppy drive and want to save some boot time can blacklist the driver manually.
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
Simo.
Simo Sorce wrote:
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
This goes against the principle that Fedora should Just Work on any hardware it encounters if at all possible.
Kevin Kofler
On Tue, Aug 30, 2011 at 09:13:05PM +0200, Kevin Kofler wrote:
Simo Sorce wrote:
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
This goes against the principle that Fedora should Just Work on any hardware it encounters if at all possible.
There's plenty of hardware that Fedora could work on but doesn't because the maintainers aren't willing to make the tradeoffs.
On Tue, 2011-08-30 at 21:13 +0200, Kevin Kofler wrote:
Simo Sorce wrote:
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
This goes against the principle that Fedora should Just Work on any hardware it encounters if at all possible.
I guess you need to define 'Just Work', and 'if at all possible'.
Making boot hang for long periods can easily be seen as 'Not working properly' and therefore make default floppy support 'not possible'. At least this is the reasoning I see and agree with.
Simo.
Once upon a time, Simo Sorce simo@redhat.com said:
Making boot hang for long periods can easily be seen as 'Not working properly' and therefore make default floppy support 'not possible'. At least this is the reasoning I see and agree with.
How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message).
On Tue, 2011-08-30 at 14:55 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce simo@redhat.com said:
Making boot hang for long periods can easily be seen as 'Not working properly' and therefore make default floppy support 'not possible'. At least this is the reasoning I see and agree with.
How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message).
Don't put words in my mouth that I have never said please.
I said: A) 99.9% of users do not needed the floppy anymore B) I said hang for "long periods" and not "forever", where here "long" is of course relative to modern machine boot times.
A and B are not related of course, and that was clear from the context.
Simo.
Once upon a time, Simo Sorce simo@redhat.com said:
I said: A) 99.9% of users do not needed the floppy anymore B) I said hang for "long periods" and not "forever", where here "long" is of course relative to modern machine boot times.
You said:
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
http://lists.fedoraproject.org/pipermail/devel/2011-August/156261.html
To me, that reads as "99.9% of non-floppy owners have to wait forever".
In any case, instead of arguing semantics, can you answer my actual question? How many systems hang when floppy.ko is loaded? If it is a large number, it should be easy to point to lots of data.
On Tue, 2011-08-30 at 15:12 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce simo@redhat.com said:
I said: A) 99.9% of users do not needed the floppy anymore B) I said hang for "long periods" and not "forever", where here "long" is of course relative to modern machine boot times.
You said:
It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason.
http://lists.fedoraproject.org/pipermail/devel/2011-August/156261.html
To me, that reads as "99.9% of non-floppy owners have to wait forever".
Ok, reasonable misunderstanding, I didn't mean it that way, sorry.
In any case, instead of arguing semantics, can you answer my actual question? How many systems hang when floppy.ko is loaded? If it is a large number, it should be easy to point to lots of data.
They do not 'hang', they just take longer to boot, sometimes a lot longer. The point is that given most machines do not even ship with a floppy drive anymore it seem entirely reasonable to spare the wait to most users because they do not need that support anyway (and even most of those who have a floppy driver do not use it ever). While for those few that need it, then having to install a simple package to enable the support by default seem sensible and good enough.
I don't think I have anything more to add to that.
Simo.
Once upon a time, Simo Sorce simo@redhat.com said:
They do not 'hang', they just take longer to boot, sometimes a lot longer.
How much longer? How many such machines? Again, I've booted systems without floppy drives but with floppy support loaded, and I haven't seen any significant hang.
Leaving known-working hardware unusable at install is just rude and irritating when it is needed. There should be good justification, not just "a bunch of developers don't use it anymore, so we don't think anybody else needs it".
Chris Adams wrote:
Leaving known-working hardware unusable at install is just rude and irritating when it is needed. There should be good justification, not just "a bunch of developers don't use it anymore, so we don't think anybody else needs it".
+1
Kevin Kofler
Hi,
On 08/30/2011 10:22 PM, Chris Adams wrote:
Once upon a time, Simo Sorcesimo@redhat.com said:
They do not 'hang', they just take longer to boot, sometimes a lot longer.
How much longer?
Much much longer, when I was still on the anaconda team we had numerous bug reports about this (esp during RHEL-6 testing), in many cases people filed bugs with a description along the lines of: "Installation DVD does not boot", because it took so long they thought the install was just hanging forever.
How many such machines?
I've no hard numbers but enough to generate numerous bug reports during the non public testing phase of RHEL-6 alone.
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=565693 https://bugzilla.redhat.com/show_bug.cgi?id=587909 https://bugzilla.redhat.com/show_bug.cgi?id=682426
http://lists.fedoraproject.org/pipermail/kernel/2010-April/002394.html http://lists.fedoraproject.org/pipermail/kernel/2010-April/002420.html
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_... And search for "IBM ThinkPad T43 notebook"
Note this is in no way an exhaustive list of all bugs about this, just something a really really quick search turned up.
Again, I've booted systems without floppy drives but with floppy support loaded, and I haven't seen any significant hang.
Yes the hang is not guaranteed to be there, or to take very long, but often it is there, and sometimes it takes very long (which is the real problematic case). If you're really interested in seeing this fixed go talk to the kernel guys:
anaconda loads the floppy driver by default when booting of the install DVD, because of driverdisk support, thus the anaconda team has been getting its share of bug reports wrt this. But AFAIK there are no such issues in RHEL-5, where we auto-load the floppy driver too, so something has changed in the kernel causing the hang when no drive is attached to the controller. I could swear I filed a bug against the kernel about this regression, but I cannot find it.
Leaving known-working hardware unusable at install is just rude and irritating when it is needed. There should be good justification, not just "a bunch of developers don't use it anymore, so we don't think anybody else needs it".
Is it delays bootup by up to 10-30 minutes on various modern systems a good enough justification?
Regards,
Hans
Once upon a time, Hans de Goede hdegoede@redhat.com said:
anaconda loads the floppy driver by default when booting of the install DVD, because of driverdisk support, thus the anaconda team has been getting its share of bug reports wrt this. But AFAIK there are no such issues in RHEL-5, where we auto-load the floppy driver too, so something has changed in the kernel causing the hang when no drive is attached to the controller. I could swear I filed a bug against the kernel about this regression, but I cannot find it.
So, it sounds like it is a kernel bug, and the "fix" was to just ignore it and stop loading the module. <sigh>...
On Tue, Aug 30, 2011 at 21:12, Chris Adams cmadams@hiwaay.net wrote:
In any case, instead of arguing semantics, can you answer my actual question? How many systems hang when floppy.ko is loaded? If it is a large number, it should be easy to point to lots of data.
Ok, just some very approximate stats for a group of approximately 50 computers i used to run (this was about 2 years ago and with various linux distributions but i doubt floppy support varies much). The computers with floppy drives enabled in the BIOS even though there was no actual drive attached took mostly between 2 and 20 seconds longer to boot. 2 of them (probably very broken controllers) actually took 2 minutes longer to boot. These extra boot times are far from being the end of the world but certainly not worth inflicting on everyone to satisfy the rare use from a tiny proportion of users.
I may be way wide of the mark but if floppy drives were enabled either on demand or as a service in systemd could the module perhaps be loaded later on during boot and in parallel with the rest of the boot. That would make any potential hang completely irrelevant.
On 08/30/2011 03:55 PM, Chris Adams wrote:
How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember those sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the floppy drive does a head seek during floppy controller init at boot.
On Tue, Aug 30, 2011 at 04:25:18PM -0400, Przemek Klosowski wrote:
On 08/30/2011 03:55 PM, Chris Adams wrote:
How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember those sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the floppy drive does a head seek during floppy controller init at boot.
No, it really takes 30÷45 seconds before floppy module timeouts after access to /dev/fd0. Seems like eternity, especially if you have no other output on screen during this time.
The argument that some older hardware do not have USB support and require floppy support is moot.
I have 3 PCs in total. 2 desktops and 1 file server. The 2 desktops run Ubuntu/Linux and the server running BSD. The server is an old desktop system that has had various upgrades and various transformations throughout its life. But when I go back to its origins, it will be 10 years old now. And even in its early beginnings, it still had full usb support. And effectively having no 'real' use for floppies. Even though it did come with a floppy drive ootb.
I see it all the time. "Some older hardware still requires floppies..." It just seems like a generic defense statement for the fans of floppies and for those who insist on using them for god knows what reason. Any hardware that is true to that statement must be at least 15 years old surely! And for the cheap price of PCs these days, whether it is building your own or grabbing an oem system, just upgrade to something that does have full usb support.
USB sticks may be small and easy to lose, correct. But I don't know how many times I've put several of mine through the washing machine and they still continue to work. Try putting a floppy disk through the washing machine and then try reading the data and see what happens. And as far as losing them, they always turn up again. And for permanent loss, I really don't care as I encrypt all my data when using usb sticks anyway. And if I don't find it, for $10 I can easily get another 8GB anyway.
Regards
Chris Jones
[image: linux.png]
Once upon a time, Chris Jones chrisjones@comcen.com.au said:
I see it all the time. "Some older hardware still requires floppies..." It just seems like a generic defense statement for the fans of floppies and for those who insist on using them for god knows what reason.
Again, please stop trying to tell me what hardware to use. I have run into several situations where I _must_ use a floppy. I don't want to, and I've tried lots of other things first, but the floppy worked.
Any hardware that is true to that statement must be at least 15 years old surely!
Hardly. I have a 6 year old notebook that will not book from USB.
And for the cheap price of PCs these days, whether it is building your own or grabbing an oem system, just upgrade to something that does have full usb support.
Feel free to PayPal me money for a new notebook.
On 08/30/2011 06:40 PM, Chris Adams wrote:
Again, please stop trying to tell me what hardware to use.
Manufacturers will tell you what hardware to use. Very few manufacturers still produce drives and media. Sony has stopped[1] as of last year.
So, if it takes the death of your floppy drive to change your mind (and your mother's embroidery, wow, what a stretch there) then I hope death meets it soon.
[1] http://news.bbc.co.uk/2/hi/uk_news/magazine/8646699.stm
P.S. I think I'm done with the Internet for this week. I've made a bike-shedding thread instead a bike-shedding thread.
Michael Cronenworth wrote:
Manufacturers will tell you what hardware to use. Very few manufacturers still produce drives and media. Sony has stopped[1] as of last year.
Unless the EU bans them (like those standard incandescence lightbulbs), I don't think floppies will become completely unavailable all that soon. (And unlike for those old lightbulbs, I don't think there's any reason for politicians to ban floppies.)
Kevin Kofler
On 2011/08/31 09:30 (GMT+1000) Chris Jones composed:
And for the cheap price of PCs these days, whether it is building your own or grabbing an oem system, just upgrade to something that does have full usb support.
So old PCs should fill landfills instead of going to people with no money for upgrades, much less for any PC at all? It must be comforting to be oblivious to world ecology and have an unlimited money supply. Upgrading is simply no option for many users of FOSS.
On 08/30/2011 06:30 PM, Chris Jones wrote:
I see it all the time. "Some older hardware still requires floppies..." It just seems like a generic defense statement for the fans of floppies and for those who insist on using them for god knows what reason. Any hardware that is true to that statement must be at least 15 years old surely! And for the cheap price of PCs these days, whether it is building your own or grabbing an oem system, just upgrade to something that does have full usb support.
I am not defending floppies - I think the current approach of "ship the module, but don't load it by default" is quite sensible - but there is an additional use case: perhaps the machine itself does not need floppies, but being able use it to prepare floppies for another machine that does (e.g. some old piece of electronics that can save data to floppy, a dedicated-use computer for running scientific experiments, etc.).
- Michael
On Tue, Aug 30, 2011 at 10:25 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
On 08/30/2011 03:55 PM, Chris Adams wrote:
How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember those sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the floppy drive does a head seek during floppy controller init at boot.
I hope no software is still doing this - that was idiotic 10 years ago, let alone now. (The purpose of the seek is to detect drives that can support only "double density", i.e. 360K, 5.25" disks, not "high density", i.e. 1.2M disks. It doesn't do anything useful for 3.5" drives.) Mirek
2011/8/30 Miloslav Trmač mitr@volny.cz
I hope no software is still doing this - that was idiotic 10 years ago, let alone now. (The purpose of the seek is to detect drives that can support only "double density", i.e. 360K, 5.25" disks, not "high density", i.e. 1.2M disks. It doesn't do anything useful for 3.5" drives.)
bah you 3.5 inch floppy elitists!!!!!! I have an original wolfenstein 3-D on 5.25 '' floppy...its its original sleeve...that I still use. How dare you suggest that I give up my 5.25 inch floppy. Its actually "floppy" unlike those hard plastic 3.5 inch cases.
-jef"Now if you wanted to suggest we finally drop support for the 8 inch floppy drives, than I would definitely support that."spaleta
On Wed, Aug 31, 2011 at 1:49 AM, Jef Spaleta jspaleta@gmail.com wrote:
2011/8/30 Miloslav Trmač mitr@volny.cz
I hope no software is still doing this - that was idiotic 10 years ago, let alone now. (The purpose of the seek is to detect drives that can support only "double density", i.e. 360K, 5.25" disks, not "high density", i.e. 1.2M disks. It doesn't do anything useful for 3.5" drives.)
bah you 3.5 inch floppy elitists!!!!!! I have an original wolfenstein 3-D on 5.25 '' floppy...its its original sleeve...that I still use. How dare you suggest that I give up my 5.25 inch floppy. Its actually "floppy" unlike those hard plastic 3.5 inch cases.
I wouldn't dare to say anything against a Wolfenstein 3-D medium. That's fine, any 5.25" floppy _disk_ is fine.
The seek is there to detect the double-density _drive_ that was last shipped in PC XT: PC AT already had a high-density drive. Wikipedia tells me that the seek is there to detect hardware that became obsolete in 1984. Mirek
2011/8/30 Miloslav Trmač mitr@volny.cz
The seek is there to detect the double-density _drive_ that was last shipped in PC XT: PC AT already had a high-density drive. Wikipedia tells me that the seek is there to detect hardware that became obsolete in 1984.
you take the fun out of everything.
But now I'm going to hunt around and see if I can find one of those here at the U. that might still work.
-jef
Björn Persson wrote:
Kevin Kofler wrote:
Users who don't have a floppy drive and want to save some boot time can blacklist the driver manually.
s/Us/Hack/ to make that sentence true.
No. Users who want to tweak their system to the point of shaving a few seconds off their boot times should be able to RTFM!
On the other hand, users who just want the hardware in their computer to actually WORK shouldn't be expected to. (With the current setup, they are, which is why it is entirely backwards!)
Kevin Kofler
Matthew Garrett wrote:
There's no way to get any feedback from the gameport driver as to (a) whether there's anything plugged in, or (b) what is plugged in. We could have the gameport driver automatically pull in analog but that'd probably break people doing midi or using some more specialised input device. It's a hard problem that only impacts a pretty tiny set of people, so it's prioritised somewhere below the hard problems that impact a pretty large set of people.
An Arch Linux user once pointed out to me that Arch (at the time) probed for analog joysticks using this udev rule: SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" (They have since dropped that rule in their trunk.) I don't know whether it makes any sense though. I presume this is just testing for the presence of a gameport without caring about what is connected, right?
Kevin Kofler
On Tue, Aug 30, 2011 at 06:30:30PM +0200, Kevin Kofler wrote:
An Arch Linux user once pointed out to me that Arch (at the time) probed for analog joysticks using this udev rule: SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" (They have since dropped that rule in their trunk.) I don't know whether it makes any sense though. I presume this is just testing for the presence of a gameport without caring about what is connected, right?
Right.
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kofler@chello.at) wrote:
Matthew Garrett wrote:
There's no way to get any feedback from the gameport driver as to (a) whether there's anything plugged in, or (b) what is plugged in. We could have the gameport driver automatically pull in analog but that'd probably break people doing midi or using some more specialised input device. It's a hard problem that only impacts a pretty tiny set of people, so it's prioritised somewhere below the hard problems that impact a pretty large set of people.
An Arch Linux user once pointed out to me that Arch (at the time) probed for analog joysticks using this udev rule: SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" (They have since dropped that rule in their trunk.) I don't know whether it makes any sense though. I presume this is just testing for the presence of a gameport without caring about what is connected, right?
If the PNP device with the ID "PNPb02f" is an analog joystick port then instead of hacking userspace rules like this the analog.ko kernel module should just gain a modinfo alias for it like for example parport_pc has for its PNP device ids. See "modinfo parport_pc" as an example.
Lennart
On Tue, Aug 30, 2011 at 07:18:40PM +0200, Lennart Poettering wrote:
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kofler@chello.at) wrote:
An Arch Linux user once pointed out to me that Arch (at the time) probed for analog joysticks using this udev rule: SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" (They have since dropped that rule in their trunk.) I don't know whether it makes any sense though. I presume this is just testing for the presence of a gameport without caring about what is connected, right?
If the PNP device with the ID "PNPb02f" is an analog joystick port then instead of hacking userspace rules like this the analog.ko kernel module should just gain a modinfo alias for it like for example parport_pc has for its PNP device ids. See "modinfo parport_pc" as an example.
The id is already present in ns558, which is the driver for the typical PC game port. However, this is only the driver for the controller, not for the joystick itself. In theory we could have the driver probe for a connected device and request_module("analog") if it finds something, but (a) that'd only work at boot, and (b) it'd be less than ideal if there's something other than a standard analog joystick connected.
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram metherid@gmail.com wrote:
Otherwise, make ddate a sub package and don't install it by default. Solved?
As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip.
So I think Fedora shouldn't be more willing to strip ddate than it would be willing to patch out ddate functionality if it were embedded in 'hwclock'.
There is a reasonable argument that util-linux ought to go on a diet: Right now it appears to take up 6424k on disk.
(Though, most of that is localizations— and several of the various NEWS/readme files it includes are bigger than ddate, as is its copy of the GPL. This silly thread has probably taken up more disk space than ddate, or it soon will)
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram metherid@gmail.com wrote:
 Otherwise,  make ddate a sub package and don't install it by default.  Solved?
As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip.
So I think Fedora shouldn't be more willing to strip ddate than it would be willing to patch out ddate functionality if it were embedded in 'hwclock'.
There is a reasonable argument that util-linux ought to go on a diet: Right now it appears to take up 6424k on disk.
(Though, most of that is localizationsâ and several of the various NEWS/readme files it includes are bigger than ddate, as is its copy of the GPL. This silly thread has probably taken up more disk space than ddate, or it soon will)
I think it has. :)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 08/29/2011 07:46 PM, Gregory Maxwell wrote:
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram wrote:
Otherwise, make ddate a sub package and don't install it by default. Solved?
As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip.
That argument totally doesn't apply since the thread was started by the upstream maintainer. Besides, upstream cannot and should not try to control how packaging is done. Playing dirty tricks isn't the way to yield cooperation.
Rahul
On Mon, Aug 29, 2011 at 6:54 AM, Karel Zak kzak@redhat.com wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users.
Comments?
That would make me very sad. Instead please consider adding robotfindskitten to util-linux which would make me very happy.
John