Re: floppy support
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. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata mrma...@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 ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, 2011-08-30 at 08:40 +0200, drago01 wrote: On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata mrma...@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 -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned: vpnc
https://admin.fedoraproject.org/pkgdb/acls/name/vpnc vpnc is a VPN client compatible with Cisco EasyVPN. Although I use vpnc daily, I only need/use the old version in RHEL 5, and I don't have a machine on which I can conveniently study Fedora bug reports. Therefore I have released ownership of this package in Fedora 14-17. Judging by the volume of bug reports, this is a widely used VPN package. Upstream comes and goes. The latest upstream is probably: http://www.unix-ag.uni-kl.de/~massar/vpnc/ and the version in svn (not in a released tarball) is relatively recent. CC'd to tmraz: As I was orphaning the package, I noticed that you had requested commit access. I'm not sure why I didn't see any email about that, or perhaps I did get email but I overlooked it. In any case, I have granted this now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proventester karma needed for libtalloc-2.0.6-1.fc15 [CRITPATH]
https://admin.fedoraproject.org/updates/libtalloc-2.0.6-1.fc15 This CRITPATH package has been in update-testing for 20 days without any karma. The same package went to stable in F16 a week ago with karma automatism. If you use Samba, SSSD, openchange, certmonger, evolution-mapi or notmuch, please verify that these programs are not experiencing unexpected behaviors. Libtalloc is the memory allocator used for each of these applications, so bugs in libtalloc would result in highly-visible new bugs in the consumers. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 03:33:04 +0200, Kevin Kofler kevin.kof...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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.kof...@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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 13:41:57 +0100, Matthew Garrett mj...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110830 changes
Compose started at Tue Aug 30 08:15:06 UTC 2011 Broken deps for x86_64 -- FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74 SimGear-2.0.0-6.fc16.i686 requires libosg.so.74 SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11 SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.1-3.fc17.x86_64 requires libpt.so.2.10.1()(64bit) ekiga-3.3.1-3.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit)
Re: floppy support
Once upon a time, Michael Cronenworth m...@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. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 715745] FTBFS perl-NOCpulse-Gritch-1.27.9-1.fc16
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=715745 Bug 715745 depends on bug 716369, which changed state. Bug 716369 Summary: nocpulse-common-2.1.22 cannot be installed because of missing perl(RHN::DB) dependency https://bugzilla.redhat.com/show_bug.cgi?id=716369 What|Old Value |New Value Resolution||NEXTRELEASE Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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.kof...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mj...@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 mj...@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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:37:16 +0100, Matthew Garrett mj...@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 mj...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 14:50:10 +0100, Tom Hughes t...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:23, Bruno Wolff III br...@wolff.to wrote: On Tue, Aug 30, 2011 at 14:37:16 +0100, Matthew Garrett mj...@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 mj...@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. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 2011/08/30 08:40 (GMT+0200) drago01 composed: Felix Miata wrote: ...OM... CD/DVD ? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712886 --- Comment #9 from Fedora Update System upda...@fedoraproject.org 2011-08-30 10:41:44 EDT --- perl-Gtk2-1.224-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Gtk2-1.224-2.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712886 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2011-08-30 10:41:18 EDT --- perl-Gtk2-1.224-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Gtk2-1.224-2.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712886 --- Comment #8 from Fedora Update System upda...@fedoraproject.org 2011-08-30 10:41:32 EDT --- perl-Gtk2-1.224-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Gtk2-1.224-2.el6 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: floppy support
Matthew Garrett (mj...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote: Matthew Garrett (mj...@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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning javassist
I don't use this package, I only took it over in order to get another package in which has since become irrelevant and most importantly although i know plenty about java (and ant) i have no clue at all about maven so this package could really do with a better owner. The package currently has only one bug open against it [1] which i have already fixed in git. It does however have a maven related build failure in f16 (and presumably devel) [2]. [1] - https://bugzilla.redhat.com/show_bug.cgi?id=734255 [2] - http://koji.fedoraproject.org/koji/taskinfo?taskID=3311807 -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110830 changes
Compose started at Tue Aug 30 13:15:20 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.i686 requires libedataserver-1.2.so.14 1:anerley-0.3.0-1.fc16.i686 requires libebook-1.2.so.11 1:anerley-0.3.0-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libebook-1.2.so.11()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit)
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kof...@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
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 07:18:40PM +0200, Lennart Poettering wrote:
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kof...@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.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proventester karma needed for libtalloc-2.0.6-1.fc15 [CRITPATH]
On Tue, Aug 30, 2011 at 12:43 PM, Stephen Gallagher sgall...@redhat.com wrote: https://admin.fedoraproject.org/updates/libtalloc-2.0.6-1.fc15 This CRITPATH package has been in update-testing for 20 days without any karma. The same package went to stable in F16 a week ago with karma automatism. If you use Samba, SSSD, openchange, certmonger, evolution-mapi or notmuch, please verify that these programs are not experiencing unexpected behaviors. Libtalloc is the memory allocator used for each of these applications, so bugs in libtalloc would result in highly-visible new bugs in the consumers. It seems it has issues with samba4 updates, and hence is causing issues with openchange/evolution-mapi. [peter@localhost ~]$ sudo yum upgrade *talloc* Loaded plugins: refresh-packagekit Setting up Upgrade Process Resolving Dependencies -- Running transaction check --- Package libtalloc.x86_64 0:2.0.5-8.fc15 will be updated --- Package libtalloc.x86_64 0:2.0.6-1.fc16 will be an update --- Package libtalloc-devel.x86_64 0:2.0.5-8.fc15 will be updated --- Package libtalloc-devel.x86_64 0:2.0.6-1.fc16 will be an update --- Package pytalloc.x86_64 0:2.0.5-8.fc15 will be updated -- Processing Dependency: libpytalloc-util.so.2(PYTALLOC_UTIL_2.0.5)(64bit) for package: samba4-libs-4.0.0-34.alpha15GITa6a722b.fc16.1.x86_64 --- Package pytalloc.x86_64 0:2.0.6-1.fc16 will be an update -- Running transaction check --- Package samba4-libs.x86_64 0:4.0.0-34.alpha15GITa6a722b.fc16.1 will be updated -- Processing Dependency: libsamba-util-common.so()(64bit) for package: openchange-0.10.9-4.fc16.x86_64 -- Processing Dependency: libsamba-util-common.so(SAMBA_4.0.0ALPHA15_UNKNOWN)(64bit) for package: openchange-0.10.9-4.fc16.x86_64 --- Package samba4-libs.x86_64 0:4.0.0-36.alpha16.fc16.1 will be an update -- Processing Dependency: libpyldb-util.so.1()(64bit) for package: samba4-libs-4.0.0-36.alpha16.fc16.1.x86_64 -- Running transaction check --- Package pyldb.x86_64 0:1.1.0-1.fc16 will be installed -- Processing Dependency: python-tdb = 1.2.9 for package: pyldb-1.1.0-1.fc16.x86_64 --- Package samba4-libs.x86_64 0:4.0.0-34.alpha15GITa6a722b.fc16.1 will be updated -- Processing Dependency: libsamba-util-common.so()(64bit) for package: openchange-0.10.9-4.fc16.x86_64 -- Processing Dependency: libsamba-util-common.so(SAMBA_4.0.0ALPHA15_UNKNOWN)(64bit) for package: openchange-0.10.9-4.fc16.x86_64 -- Running transaction check --- Package python-tdb.x86_64 0:1.2.9-10.fc16 will be installed --- Package samba4-libs.x86_64 0:4.0.0-34.alpha15GITa6a722b.fc16.1 will be updated -- Processing Dependency: libsamba-util-common.so()(64bit) for package: openchange-0.10.9-4.fc16.x86_64 -- Processing Dependency: libsamba-util-common.so(SAMBA_4.0.0ALPHA15_UNKNOWN)(64bit) for package: openchange-0.10.9-4.fc16.x86_64 -- Finished Dependency Resolution Error: Package: openchange-0.10.9-4.fc16.x86_64 (@rawhide/15) Requires: libsamba-util-common.so()(64bit) Removing: samba4-libs-4.0.0-34.alpha15GITa6a722b.fc16.1.x86_64 (@rawhide) libsamba-util-common.so()(64bit) Updated By: samba4-libs-4.0.0-36.alpha16.fc16.1.x86_64 (updates-testing) Not found Error: Package: openchange-0.10.9-4.fc16.x86_64 (@rawhide/15) Requires: libsamba-util-common.so(SAMBA_4.0.0ALPHA15_UNKNOWN)(64bit) Removing: samba4-libs-4.0.0-34.alpha15GITa6a722b.fc16.1.x86_64 (@rawhide) libsamba-util-common.so(SAMBA_4.0.0ALPHA15_UNKNOWN)(64bit) Updated By: samba4-libs-4.0.0-36.alpha16.fc16.1.x86_64 (updates-testing) Not found You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proventester karma needed for libtalloc-2.0.6-1.fc15 [CRITPATH]
On Tue, 2011-08-30 at 18:31 +0100, Peter Robinson wrote: On Tue, Aug 30, 2011 at 12:43 PM, Stephen Gallagher sgall...@redhat.com wrote: https://admin.fedoraproject.org/updates/libtalloc-2.0.6-1.fc15 This CRITPATH package has been in update-testing for 20 days without any karma. The same package went to stable in F16 a week ago with karma automatism. If you use Samba, SSSD, openchange, certmonger, evolution-mapi or notmuch, please verify that these programs are not experiencing unexpected behaviors. Libtalloc is the memory allocator used for each of these applications, so bugs in libtalloc would result in highly-visible new bugs in the consumers. It seems it has issues with samba4 updates, and hence is causing issues with openchange/evolution-mapi. Yeah, I realized that when I rebuild samba4 yesterday I didn't have the new libtalloc in the buildroot. This will be fixed with samba4-4.0.0-25.alpha11.fc15.5 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Notice of intent: patching glibc
Hey, it's been a quiet week so far... I'm intending to update glibc for F16 using provenpackager privileges tomorrow to fix https://bugzilla.redhat.com/show_bug.cgi?id=730856 using the patch submitted upstream at http://sourceware.org/bugzilla/show_bug.cgi?id=13013 , if the glibc upstream developers and/or Fedora maintainers do not respond to the bug before then. I raised the issue on this list on 08-08 and filed the bug on 08-15. The patch was submitted upstream on 07-21. Andreas Schwab is very active on this list, so it seems unlikely that he would not be aware of the issue, yet there has been no response at all. It's downright absurd for there to be a known and understood crasher bug, affecting all users, in such a critical component for so long without any acknowledgement or response by upstream or the Fedora maintainers. This and the Flash audio corruption mess make it fairly clear that glibc maintenance is not what it should be for such a crucial package. Given that, the only sensible approach seems to be to go ahead and Just Fix It. Myself and Kevin Fenzi have been using the patch for a while, so it's not untested. glibc maintainers / developers, if you don't want me to do this, please start giving a crap about your bugs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Directory-Queue/el4] (3 commits) ...Merge branch 'master' into el4
Summary of changes: c5605de... Perl mass rebuild (*) 6bb0886... Update 1.2 rhbz#73941. (*) 9ec119e... Merge branch 'master' into el4 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/el4: 3/3] Merge branch 'master' into el4
commit 9ec119e20d39f6a40fcc4d00569589a01b97d19a Merge: ee2422e 6bb0886 Author: Steve Traylen steve.tray...@cern.ch Date: Tue Aug 30 20:18:49 2011 +0200 Merge branch 'master' into el4 .gitignore|1 + perl-Directory-Queue.spec |8 +++- sources |2 +- 3 files changed, 9 insertions(+), 2 deletions(-) --- diff --cc .gitignore index 064f58b,0eb7f48..b98d1a8 --- a/.gitignore +++ b/.gitignore @@@ -1,2 -1,4 +1,3 @@@ -Directory-Queue-0.5.tar.gz /Directory-Queue-1.0.tar.gz /Directory-Queue-1.1.tar.gz + /Directory-Queue-1.2.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Created tag perl-Directory-Queue-1.2-1.el4
The unsigned tag 'perl-Directory-Queue-1.2-1.el4' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Tue Aug 30 20:19:07 2011 +0200 Update 1.2 rhbz#73941. Changes since the last tag 'perl-Directory-Queue-1.1-1.el4': Marcela Mašláňová (1): Perl mass rebuild Steve Traylen (2): Update 1.2 rhbz#73941. Merge branch 'master' into el4 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski przemek.klosow...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 08/30/2011 03:18 PM, Jef Spaleta wrote: On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski przemek.klosow...@nist.gov mailto:przemek.klosow...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proventester karma needed for libtalloc-2.0.6-1.fc15 [CRITPATH]
On Tue, 2011-08-30 at 07:43 -0400, Stephen Gallagher wrote: https://admin.fedoraproject.org/updates/libtalloc-2.0.6-1.fc15 This CRITPATH package has been in update-testing for 20 days without any karma. The same package went to stable in F16 a week ago with karma automatism. If you use Samba, SSSD, openchange, certmonger, evolution-mapi or notmuch, please verify that these programs are not experiencing unexpected behaviors. Libtalloc is the memory allocator used for each of these applications, so bugs in libtalloc would result in highly-visible new bugs in the consumers. Is a simple CIFS mount exercising libtalloc? I wasn't sure about that, so I didn't file any karma yet. I have a CIFS share from my NAS box mounted on my F16 system and that's working fine, but I wasn't sure if that's enough of a use case to +1 the update. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski przemek.klosow...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proventester karma needed for libtalloc-2.0.6-1.fc15 [CRITPATH]
On Tue, 2011-08-30 at 12:20 -0700, Adam Williamson wrote: On Tue, 2011-08-30 at 07:43 -0400, Stephen Gallagher wrote: https://admin.fedoraproject.org/updates/libtalloc-2.0.6-1.fc15 This CRITPATH package has been in update-testing for 20 days without any karma. The same package went to stable in F16 a week ago with karma automatism. If you use Samba, SSSD, openchange, certmonger, evolution-mapi or notmuch, please verify that these programs are not experiencing unexpected behaviors. Libtalloc is the memory allocator used for each of these applications, so bugs in libtalloc would result in highly-visible new bugs in the consumers. Is a simple CIFS mount exercising libtalloc? I wasn't sure about that, so I didn't file any karma yet. I have a CIFS share from my NAS box mounted on my F16 system and that's working fine, but I wasn't sure if that's enough of a use case to +1 the update. Yes, everything in Samba uses talloc for memory allocation. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 08/30/2011 03:36 PM, Jef Spaleta wrote: On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski przemek.klosow...@nist.gov mailto:przemek.klosow...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Jef Spaleta jspal...@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. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce s...@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). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 14:55 -0500, Chris Adams wrote: Once upon a time, Simo Sorce s...@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. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce s...@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. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 15:12 -0500, Chris Adams wrote: Once upon a time, Simo Sorce s...@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. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce s...@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 cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 'bzzut bzzzut... bzzut...' when the floppy drive does a head seek during floppy controller init at boot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 'bzzut bzzzut... bzzut...' 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. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 21:12, Chris Adams cmad...@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. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (722292) Certain entries in DS are not updated properly when using WinSync API
https://bugzilla.redhat.com/show_bug.cgi?id=722292 https://bugzilla.redhat.com/attachment.cgi?id=520685action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Memory requirements
On Mon, Aug 29, 2011 at 3:37 PM, Felix Miata mrma...@earthlink.net wrote: On 2011/08/29 15:04 (GMT-0700) Jeremiah Summers composed: I just repatched Anaconda to use 512M Literally? If so, does that work on systems with 512M installed but with 8M allocated to an onboard video chip? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Yes Literally I did, but as Adam just pointed out running Live just dumps the squashfs image to the drive and slaps grud on it. I'm not sure about the install, however I have been tweaking initrd's for doing a netinstall, I may just find out soon. I wonder though is there a way to allow Anaconda to be semi smart and realize here I'm running livecd let's bump down that mem require. In that case it would allow those a install method with low mem. Kind Regards, Jeremiah -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712699 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-08-30 16:34:54 EDT --- Package perl-Data-FormValidator-4.66-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Data-FormValidator-4.66-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-Data-FormValidator-4.66-6.fc16 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Memory requirements
On Tue, Aug 30, 2011 at 13:33:06 -0700, Jeremiah Summers jmiah...@gmail.com wrote: Yes Literally I did, but as Adam just pointed out running Live just dumps the squashfs image to the drive and slaps grud on it. I'm not It actually dumps the ext4 image on the drive and then resizes it to fit the available space. The ext4 image is stored compressed inside of a squashfs file system on the live image. It would be nice to get rid of the embedded ext4 image now that squashfs supports special files and extended attributes (needed for selinuix labels), but there are some other roadblocks that will block that change for the near future. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Tue, Aug 30, 2011 at 14:36, Bruno Wolff III br...@wolff.to wrote: On Tue, Aug 30, 2011 at 13:33:06 -0700, Jeremiah Summers jmiah...@gmail.com wrote: Yes Literally I did, but as Adam just pointed out running Live just dumps the squashfs image to the drive and slaps grud on it. I'm not It actually dumps the ext4 image on the drive and then resizes it to fit the available space. The ext4 image is stored compressed inside of a squashfs file system on the live image. It would be nice to get rid of the embedded ext4 image now that squashfs supports special files and extended attributes (needed for selinuix labels), but there are some other roadblocks that will block that change for the near future. Heheh. If the majority of installs occur from live images.. would that make squashfs the new Fedora filesystem :). -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please Review: (722292) Certain entries in DS are not updated properly when using WinSync API
Here is a revised patch to address some review comments: https://bugzilla.redhat.com/attachment.cgi?id=520694action=edit On 08/30/2011 01:31 PM, Nathan Kinder wrote: https://bugzilla.redhat.com/show_bug.cgi?id=722292 https://bugzilla.redhat.com/attachment.cgi?id=520685action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Memory requirements
It would be nice to get rid of the embedded ext4 image now that squashfs supports special files and extended attributes (needed for selinuix labels), but there are some other roadblocks that will block that change for the near future. Where is this issue being tracked? -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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] linux.png-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Chris Jones chrisjo...@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. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 10:25 PM, Przemek Klosowski przemek.klosow...@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 'bzzut bzzzut... bzzut...' 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
2011/8/30 Miloslav Trmač m...@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. -jefNow if you wanted to suggest we finally drop support for the 8 inch floppy drives, than I would definitely support that.spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Wed, Aug 31, 2011 at 1:49 AM, Jef Spaleta jspal...@gmail.com wrote: 2011/8/30 Miloslav Trmač m...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
2011/8/30 Miloslav Trmač m...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned: vpnc
Hi, On 08/30/2011 01:42 PM, Richard W.M. Jones wrote: Although I use vpnc daily, I only need/use the old version in RHEL 5, and I don't have a machine on which I can conveniently study Fedora bug reports. Therefore I have released ownership of this package in Fedora 14-17. Since I have vpnc in nearly daily use on various Fedora installations, I'll help out here. Judging by the volume of bug reports, this is a widely used VPN package. Upstream comes and goes. The latest upstream is probably: http://www.unix-ag.uni-kl.de/~massar/vpnc/ and the version in svn (not in a released tarball) is relatively recent. I have looked at the list of open bugs for vpnc and it looks like that there are a couple of packaging issues, some problems with the vpnc-script and some other issues which may require some upstream help. CC'd to tmraz: As I was orphaning the package, I noticed that you had requested commit access. I'm not sure why I didn't see any email about that, or perhaps I did get email but I overlooked it. In any case, I have granted this now. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Tue, Aug 30, 2011 at 15:22:21 -0700, John Reiser jrei...@bitwagon.com wrote: It would be nice to get rid of the embedded ext4 image now that squashfs supports special files and extended attributes (needed for selinuix labels), but there are some other roadblocks that will block that change for the near future. Where is this issue being tracked? I had an RFE bug for it, but it was marked as deferred, as the issue was unlikely to be resolved any time soon. I didn't have time to work on it myself, so I am OK with that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Tue, Aug 30, 2011 at 15:22:21 -0700, John Reiser jrei...@bitwagon.com wrote: It would be nice to get rid of the embedded ext4 image now that squashfs supports special files and extended attributes (needed for selinuix labels), but there are some other roadblocks that will block that change for the near future. Where is this issue being tracked? Here is the closed bug: https://bugzilla.redhat.com/show_bug.cgi?id=623707 It doesn't go into much detail, but the issue seems to be that squashfs doesn't work with writeable overlays. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 br...@wolff.to 1.0-1
- Initial package creation
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
On Mon, Aug 29, 2011 at 9:15 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2011-08-29 at 22:02 +0200, drago01 wrote: On Mon, Aug 29, 2011 at 9:55 PM, Brian C. Lane b...@redhat.com wrote: On Sat, Aug 27, 2011 at 04:15:37PM -0700, a...@clueserver.org wrote: In both cases I had 2 gigs of ram. Should not be a memory issue. That is more than enough. Please file a bug(s) and include the logs from /tmp/*log Memory usage during install also depends on what the packages being installed do in their pre/post scripts. selinux is a big example of this, causing a large spike as it is installed. SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, [1] 1: http://danwalsh.livejournal.com/45414.html Yes. The reason why that work has been done is because everyone kicked up a stink about anaconda using too much memory, so the anaconda team looked closer into what was taking up so much memory, found out selinux policy installation caused quite a significant chunk of it, and told Dan about it. None of this is news to anyone actually involved in the relevant development teams =) this topic has really been done to death on this list and many others. anaconda team is aware of the memory use issue and is working on fixing it. this selinux change is one of the fixes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I would say thank you but the tone I'm getting in the email seems rather reluctant to try and be as memory efficient as possible, a little bit like we just did it to stop your whining. I'm sure that's not the tone you mean and even if so I'm sure you're not talking for the anaconda team. So regardless.. Thank You all who have beaten this thing to death and those who won't let it die until it's as efficient as possible with the hardware given. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
On Tue, 2011-08-30 at 21:11 -0700, Jeremiah Summers wrote: I would say thank you but the tone I'm getting in the email seems rather reluctant to try and be as memory efficient as possible, a little bit like we just did it to stop your whining. I'm sure that's not the tone you mean and even if so I'm sure you're not talking for the anaconda team. Yes, both of those are true. I just get a bit irked that the issue keeps getting raised as if it's some stunning new discovery and the anaconda team has been hideously lax in not caring about it, because it's well-known and they _do_ care about it. =) So regardless.. Thank You all who have beaten this thing to death and those who won't let it die until it's as efficient as possible with the hardware given. seconded! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)
Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues: * dojo/dijit - F/OSS, packaged * simplepie - F/OSS, packaged * CheckBoxTree.js - requires formal license, unpackaged - http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/comment-page-1/#comment-46 . not entirely sure whether this would count as a copylib. * htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged as php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045 * iui - F/OSS, unpackaged - https://code.google.com/p/iui/ * MiniTemplator - F/OSS, unpackaged - http://www.source-code.biz/MiniTemplator/ * phpmailer - F/OSS, packaged * position.js - comprises http://codesnippets.joyent.com/posts/show/835 and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs? * prototypejs - F/OSS, unpackaged, already embedded in many other packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277 * php-pubsubhubbub - F/OSS, unpackaged: https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream) * scriptaculous - F/OSS, mostly unpackaged, but part of http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it * sphinxapi.php - F/OSS, packaged (sphinx-php) * tmhoauth - F/OSS, unpackaged - https://github.com/themattharris/tmhOAuth * xsl_mop-up.js - public domain, unpackaged - http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating * no shared libraries are present: okay - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it. python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states + no headers or static libraries., which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something? If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)
Speaking about prototype and scriptaculous, I am sure that they are bundled also in Rails and if there are some Rails applications packaged, they will be included also in them. However I am not sure if they should be packaged separately or just copylibs. Vit Dne 31.8.2011 06:35, Adam Williamson napsal(a): Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues: * dojo/dijit - F/OSS, packaged * simplepie - F/OSS, packaged * CheckBoxTree.js - requires formal license, unpackaged - http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/comment-page-1/#comment-46 . not entirely sure whether this would count as a copylib. * htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged as php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045 * iui - F/OSS, unpackaged - https://code.google.com/p/iui/ * MiniTemplator - F/OSS, unpackaged - http://www.source-code.biz/MiniTemplator/ * phpmailer - F/OSS, packaged * position.js - comprises http://codesnippets.joyent.com/posts/show/835 and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs? * prototypejs - F/OSS, unpackaged, already embedded in many other packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277 * php-pubsubhubbub - F/OSS, unpackaged: https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream) * scriptaculous - F/OSS, mostly unpackaged, but part of http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it * sphinxapi.php - F/OSS, packaged (sphinx-php) * tmhoauth - F/OSS, unpackaged - https://github.com/themattharris/tmhOAuth * xsl_mop-up.js - public domain, unpackaged - http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating * no shared libraries are present: okay - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it. python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states + no headers or static libraries., which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something? If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future. This explain why so much .js libraries are bundled in so much wedapps. Remi. - Mail original - Speaking about prototype and scriptaculous, I am sure that they are bundled also in Rails and if there are some Rails applications packaged, they will be included also in them. However I am not sure if they should be packaged separately or just copylibs. Vit Dne 31.8.2011 06:35, Adam Williamson napsal(a): Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues: * dojo/dijit - F/OSS, packaged * simplepie - F/OSS, packaged * CheckBoxTree.js - requires formal license, unpackaged - http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/comment-page-1/#comment-46 . not entirely sure whether this would count as a copylib. * htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged as php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045 * iui - F/OSS, unpackaged - https://code.google.com/p/iui/ * MiniTemplator - F/OSS, unpackaged - http://www.source-code.biz/MiniTemplator/ * phpmailer - F/OSS, packaged * position.js - comprises http://codesnippets.joyent.com/posts/show/835 and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs? * prototypejs - F/OSS, unpackaged, already embedded in many other packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277 * php-pubsubhubbub - F/OSS, unpackaged: https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream) * scriptaculous - F/OSS, mostly unpackaged, but part of http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it * sphinxapi.php - F/OSS, packaged (sphinx-php) * tmhoauth - F/OSS, unpackaged - https://github.com/themattharris/tmhOAuth * xsl_mop-up.js - public domain, unpackaged - http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating * no shared libraries are present: okay - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it. python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states + no headers or static libraries., which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something? If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 734253] HTML::Template 2.10 versioning problem
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734253 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-08-30 02:29:01 EDT --- Change module version to and RPM provides to 2.91, RPM version to 2.10.1 until upstream bumps new version. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Padre] 0.90 bump
commit fd425b4d4bed7a317143518452928720686f8b1d
Author: Petr Písař ppi...@redhat.com
Date: Mon Aug 29 18:31:16 2011 +0200
0.90 bump
.gitignore |1 +
perl-Padre.spec | 141 +--
sources |2 +-
3 files changed, 56 insertions(+), 88 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9f44786..a6a10af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Padre-0.64.tar.gz
/Padre-0.82.tar.gz
/Padre-0.84.tar.gz
/Padre-0.86.tar.gz
+/Padre-0.90.tar.gz
diff --git a/perl-Padre.spec b/perl-Padre.spec
index 703e8cf..b0f65bb 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -1,8 +1,8 @@
%global use_x11_tests 1
Name: perl-Padre
-Version:0.86
-Release:5%{?dist}
+Version:0.90
+Release:1%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,7 +13,9 @@ BuildArch: noarch
BuildRequires: gettext
BuildRequires: desktop-file-utils
BuildRequires: perl(Alien::wxWidgets) = 0.46
+# perl(Capture::Tiny) at lib/Padre/Wx/Command.pm:160, version from META.yml
BuildRequires: perl(Capture::Tiny) = 0.06
+BuildRequires: perl(CGI) = 3.47
BuildRequires: perl(Class::Adapter) = 1.05
BuildRequires: perl(Class::Inspector) = 1.22
BuildRequires: perl(Class::Unload) = 0.03
@@ -29,7 +31,6 @@ BuildRequires: perl(Data::Dumper) = 2.101
BuildRequires: perl(Debug::Client) = 0.11
BuildRequires: perl(Devel::Dumpvar) = 0.04
BuildRequires: perl(Devel::Refactor) = 0.05
-BuildRequires: perl(Digest::MD5) = 2.38
BuildRequires: perl(Encode) = 2.26
# perl(Exporter) at lib/Padre/Current.pm:88
BuildRequires: perl(Exporter)
@@ -41,7 +42,7 @@ BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Copy::Recursive) = 0.37
BuildRequires: perl(File::Find::Rule) = 0.30
-BuildRequires: perl(File::Glob)
+# perl(File::Glob) is not used anywhere
BuildRequires: perl(File::HomeDir) = 0.91
BuildRequires: perl(File::Path) = 2.08
BuildRequires: perl(File::pushd) = 1.00
@@ -79,13 +80,10 @@ BuildRequires: perl(List::MoreUtils) = 0.22
BuildRequires: perl(List::Util) = 1.18
BuildRequires: perl(Locale::Msgfmt) = 0.15
BuildRequires: perl(LWP) = 5.815
-# perl(LWP::UserAgent) at lib/Padre/Sync.pm:27
-BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(LWP::UserAgent) = 5.815
BuildRequires: perl(Module::Build) = 0.3603
-BuildRequires: perl(Module::CoreList)
+BuildRequires: perl(Module::CoreList) = 2.22
BuildRequires: perl(Module::Manifest) = 0.07
-BuildRequires: perl(Module::Refresh) = 0.13
-BuildRequires: perl(Module::Starter) = 1.50
BuildRequires: perl(ORLite) = 1.48
BuildRequires: perl(Params::Util) = 0.33
BuildRequires: perl(Parse::ErrorString::Perl) = 0.14
@@ -113,7 +111,7 @@ BuildRequires: perl(PPIx::Regexp) = 0.005
BuildRequires: perl(Probe::Perl) = 0.01
# perl(Scalar::Util) at lib/Padre.pm
BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(Storable) = 2.15
+BuildRequires: perl(Storable) = 2.16
BuildRequires: perl(Template::Tiny) = 0.11
BuildRequires: perl(Test::Exception) = 0.27
BuildRequires: perl(Test::MockObject) = 1.09
@@ -169,12 +167,12 @@ Requires: perl(Class::Unload) = 0.03
Requires: perl(Class::XSAccessor::Array) = 1.02
# Real version perl(Cwd) = 3.2701 rounded
Requires: perl(Cwd) = 3.28
+Requires: perl(CGI) = 3.47
Requires: perl(DBD::SQLite) = 1.27
Requires: perl(Data::Dumper)
Requires: perl(Debug::Client) = 0.11
Requires: perl(Devel::Dumpvar) = 0.04
Requires: perl(Devel::Refactor) = 0.05
-Requires: perl(Digest::MD5) = 2.38
Requires: perl(Encode) = 2.26
Requires: perl(ExtUtils::MakeMaker) = 6.56
Requires: perl(ExtUtils::Manifest) = 1.56
@@ -206,11 +204,10 @@ Requires: perl(IPC::Run) = 0.83
Requires: perl(JSON::XS) = 2.29
Requires: perl(List::MoreUtils) = 0.22
Requires: perl(List::Util) = 1.18
+Requires: perl(LWP::UserAgent) = 5.815
Requires: perl(Module::Build) = 0.3603
-Requires: perl(Module::CoreList)
+Requires: perl(Module::CoreList) = 2.22
Requires: perl(Module::Manifest) = 0.07
-Requires: perl(Module::Refresh) = 0.13
-Requires: perl(Module::Starter) = 1.50
Requires: perl(POSIX)
Requires: perl(PPI) = 1.213
Requires: perl(PPIx::EditorTools) = 0.13
@@ -227,7 +224,7 @@ Requires: perl(Pod::Simple::XHTML) = 3.04
Requires: perl(POD2::Base) = 0.043
Requires: perl(Probe::Perl) = 0.01
Requires: perl(Readonly::XS) = 1.05
-Requires: perl(Storable) = 2.15
+Requires: perl(Storable) = 2.16
Requires: perl(Template::Tiny) = 0.11
Requires: perl(Term::ReadLine)
Requires: perl(Text::Balanced) = 2.01
@@ -244,81 +241,46 @@ Obsoletes: perl-Wx-Perl-Dialog 0.01
Provides:
[Bug 730275] perl-Padre-0.90 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=730275 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Padre-0.90-1.fc17 Resolution||RAWHIDE Last Closed||2011-08-30 02:54:29 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
perl-HTML-Template versioning issue in F-16+
FYI, perl-HTML-Template 2.10 in F-16+ has most likely broken at least the perl-HTML-Template-Expr and w3c-markup-validator packages in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=734253 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Locale-Codes-3.17.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Locale-Codes: f0181dd8bf625db584fddbd3f5e2143b Locale-Codes-3.17.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Codes] Import
commit ecfabf3fbec696537c717b66b527f77a104f3fb6
Author: Petr Písař ppi...@redhat.com
Date: Tue Aug 30 11:44:35 2011 +0200
Import
.gitignore |1 +
perl-Locale-Codes.spec | 57
sources|1 +
3 files changed, 59 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..e7c83fd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Locale-Codes-3.17.tar.gz
diff --git a/perl-Locale-Codes.spec b/perl-Locale-Codes.spec
new file mode 100644
index 000..4b83e97
--- /dev/null
+++ b/perl-Locale-Codes.spec
@@ -0,0 +1,57 @@
+Name: perl-Locale-Codes
+Version:3.17
+Release:1%{?dist}
+Summary:Distribution of modules to handle locale codes
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Locale-Codes/
+Source0:
http://www.cpan.org/authors/id/S/SB/SBECK/Locale-Codes-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Module::Build)
+# Tests
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Storable)
+BuildRequires: perl(Test::More)
+# Optional tests
+BuildRequires: perl(Test::Pod) = 1.00
+BuildRequires: perl(Test::Pod::Coverage) = 1.00
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(constant)
+
+# Inject not detected module version
+%{?filter_setup:
+%filter_from_provides s/^\(perl(Locale\[^)]*)\)[^=]*$/\1 = %{version}/
+%filter_setup
+}
+
+%description
+Locale-Codes is a distribution containing a set of modules. The modules
+each deal with different types of codes which identify parts of the locale
+including languages, countries, currency, etc.
+
+%prep
+%setup -q -n Locale-Codes-%{version}
+chmod -x examples/*
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc ChangeLog LICENSE README README.first examples
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Jun 30 2011 Petr Pisar ppi...@redhat.com 3.17-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot and defattr
diff --git a/sources b/sources
index e69de29..505b1f1 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+f0181dd8bf625db584fddbd3f5e2143b Locale-Codes-3.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734420] New: perl-DateTime-TimeZone-1.36 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-DateTime-TimeZone-1.36 is available https://bugzilla.redhat.com/show_bug.cgi?id=734420 Summary: perl-DateTime-TimeZone-1.36 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-DateTime-TimeZone AssignedTo: iarn...@gmail.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.36 Current version in Fedora Rawhide: 1.35 URL: http://search.cpan.org/dist/DateTime-TimeZone/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734419] New: perl-CPAN-Checksums-2.08 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-CPAN-Checksums-2.08 is available https://bugzilla.redhat.com/show_bug.cgi?id=734419 Summary: perl-CPAN-Checksums-2.08 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-CPAN-Checksums AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 2.08 Current version in Fedora Rawhide: 2.07 URL: http://search.cpan.org/dist/CPAN-Checksums/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Codes/f16] Import
Summary of changes: ecfabf3... Import (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734419] perl-CPAN-Checksums-2.08 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734419 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CPAN-Checksums-2.08-1. ||fc17 Resolution||RAWHIDE Last Closed||2011-08-30 07:02:40 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the rawhide tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734469] New: Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Upgrade to new upstream version https://bugzilla.redhat.com/show_bug.cgi?id=734469 Summary: Upgrade to new upstream version Product: Fedora EPEL Version: el6 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-Directory-Queue AssignedTo: steve.tray...@cern.ch ReportedBy: lionel.c...@cern.ch QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, steve.tray...@cern.ch Classification: Fedora Story Points: --- Type: --- The latest version of Directory::Queue on CPAN is now 1.2. This is the version to use everywhere. Please upgrade in EPEL. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
