Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
Hi, On 09/02/2011 05:37 PM, Bastien Nocera wrote: If we wanted to do things properly, we'd use the specs so that the transition between HID and HCI was invisible to the user. Except that we don't have the specs (or it would be fixed already, it's one of my major gripes for a number of years, and I've nagged Dell, Logitech and Broadcom a number of times for access to those). Hans, we need to make the switching opt-in. If you don't have time to work on it, I'd rather you reverted your last patch for now. Hmm, may I point out that making the switching opt-in would be deviating from our default behavior from F-12 onwards, as documented here: http://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions With that said, you're the Fedora bluetooth maintainer, so you are the boss. The easiest way to make this opt-in, and I think also a good one, is to just move the udev-rules and the hid2hci binary to their own bluez-hid2hci sub-package. People who want to have their hid proxying adapters to actually show up as HCI instead of HID can then do yum install bluez-hid2hci We could even have a %post script doing a udevadm trigger subsys=to-be-figured-out To avoid people needing to reboot / unplug the adapter after installing the package. If you think this is a good plan, let me know and I'll implement it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Fri, Sep 02, 2011 at 10:28:19PM +0200, Jakub Jelinek wrote: On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote: Is there a specific reason glibc does this? Yes. Can it not have a set of patches, one per change, as is usual practice? Fedora glibc sources are from git, and the bit diff is just generated diff between the upstream snapshot and corresponding Fedora snapshot, sans a few Fedora-only directories (which are packaged as extra tarball). That's not a reason. Why not keep the Fedora branch in git and make patches from it: https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ This method is quite probably simpler than the one you're using now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
Dne 2.9.2011 22:54, Adam Williamson napsal(a): Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. If we had upstream’s UNCONFIRMED we wouldn't have to play with the Triaged keyword (although the meaning is subtly different). Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
Dne 3.9.2011 00:33, Matt McCutchen napsal(a): bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases. I use it routinely as a polite version of WONTFIX for Xorg bugs with nvidia binary driver. But yes, that's not a big deal. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
Dne 3.9.2011 10:38, Richard W.M. Jones napsal(a): https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ This method is quite probably simpler than the one you're using now. I am in the process of pushing our less interesting Xorg patches upstream, and I had a great experience with quilt and managing patches as patches. Not sure how it scales to the size glibc/gdb/guestfs patches but it worked great for me. (and of course, I wish Fedora left all the silly patch business and used git only as $DEITY intended). Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote: Fedora glibc sources are from git, and the bit diff is just generated diff between the upstream snapshot and corresponding Fedora snapshot, sans a few Fedora-only directories (which are packaged as extra tarball). That's not a reason. Why not keep the Fedora branch in git and make patches from it: https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ This method is quite probably simpler than the one you're using now. glibc is doing it that way for many years, even when it was diffing upstream CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era would result in something reasonable with your tricks, but moreover what glibc does now is fully scripted in the Makefiles and it would be extra work to change it to something different. I'd say it is up to the Fedora glibc maintainer to do it the way he prefers to (which is not me for a couple of years now). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110903 changes
Compose started at Sat Sep 3 08:15:02 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) caribou-0.3.5-1.fc16.i686 requires libgee.so.2 caribou-0.3.5-1.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-libs-3.0.2-2.fc16.i686 requires libgee.so.2 1:cheese-libs-3.0.2-2.fc16.x86_64 requires libgee.so.2()(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 ease-0.4-7.fc17.i686 requires libgee.so.2 ease-0.4-7.fc17.x86_64 requires libgee.so.2()(64bit) ease-devel-0.4-7.fc17.i686 requires pkgconfig(gee-1.0) ease-devel-0.4-7.fc17.x86_64 requires pkgconfig(gee-1.0) 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) empathy-3.1.90.1-2.fc17.x86_64 requires libgee.so.2()(64bit) 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
Re: Yum/Bugzilla feature requests
Regarding bugzilla, you can close your bug report and mark it as a duplicate of the earlier bug report (you provide the number). This will also add a note to the the original bug report about the duplicate. Hth. On Sep 2, 2011 11:19 AM, Barry Fishman barry_fish...@acm.org wrote: Recently while running Fedora 16, my attempt at: yum update --skip-broken failed with: warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 069c8460: NOKEY Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 The GPG keys listed for the Fedora 16 - x86_64 repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Looking at bug #735037, It seems that there was a problem with package btrfs-progs. Couldn't yum refers to 'this package' but does not say which package was the problems. If it at least said which package was involved, I could have uninstalled that package and updated everything else. Better yet 'yum --skip-broken' could have removed that package from consideration, redid the dependencies and updated the remaining packages. As a side note, I checked bugzilla for problems with yum and finding none submitted bug #735235. It takes a while for bug reports to show up in the bugzilla search, so a day or so later when I got a confirmation I found the earlier bug report. I found no way in bugzilla to close my bug report by merging it into the earlier bug report. I think such an ability by the original submitter would help the people working on fixing bug, (and bug submitters,) by prefiltering the individual bug reports to which they needed to look at. -- Barry Fishman -- 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
Re: floppy support
I have submitted a review request for floppy-support: https://bugzilla.redhat.com/show_bug.cgi?id=735554 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum/Bugzilla feature requests
On 2011-09-03 09:35:21 EDT, Jorge Gallegos wrote: On Sep 2, 2011 11:19 AM, Barry Fishman barry_fish...@acm.org wrote: I found no way in bugzilla to close my bug report by merging it into the earlier bug report. I think such an ability by the original submitter would help the people working on fixing bug, (and bug submitters,) by prefiltering the individual bug reports to which they needed to look at. Regarding bugzilla, you can close your bug report and mark it as a duplicate of the earlier bug report (you provide the number). This will also add a note to the the original bug report about the duplicate. Thanks. Just what I wanted. Is there some primer or FAQ for bugzilla that I should have read? -- Barry Fishman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110903 changes
Compose started at Sat Sep 3 13:15:17 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) airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36 airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36 airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit) airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit) 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
http://fedoraproject.org/wiki/Features/SysVtoSystemd
the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd is at 0% - why will F16 released WITHOUT making the system clean which should have been done for F15 How many releases will this dirty mix of systemd/sysvinit(lsb in the distribution exist until the OS can be called as clean like before F15? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On Sat, Sep 3, 2011 at 07:46, Reindl Harald h.rei...@thelounge.net wrote: the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd is at 0% - why will F16 released WITHOUT making the system clean which should have been done for F15 How many releases will this dirty mix of systemd/sysvinit(lsb in the distribution exist until the OS can be called as clean like before F15? As many as it takes to get it done. -- 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: Notice of intent: patching glibc
On Sat, 2011-09-03 at 13:43 +0200, Jakub Jelinek wrote: On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote: Fedora glibc sources are from git, and the bit diff is just generated diff between the upstream snapshot and corresponding Fedora snapshot, sans a few Fedora-only directories (which are packaged as extra tarball). That's not a reason. Why not keep the Fedora branch in git and make patches from it: https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ This method is quite probably simpler than the one you're using now. glibc is doing it that way for many years, even when it was diffing upstream CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era would result in something reasonable with your tricks, but moreover what glibc does now is fully scripted in the Makefiles and it would be extra work to change it to something different. I'd say it is up to the Fedora glibc maintainer to do it the way he prefers to (which is not me for a couple of years now). Well, not entirely. There are the packaging guidelines. I took a look, and interestingly I can't find anything in there specific about how to format patches: seems that 'one-patch-for-one-change' is just a convention, albeit a very deeply-embedded one with most packagers. However, there's this, on sources: There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:. There is no indication in the glibc spec of what the Fedora 'source' is or where it comes from; anyone coming to the spec without prior knowledge will be confused, as I was, as to the nature of this tarball. Its nature and method of generation should be documented in the spec. I'm not sure if the 'Makefiles' used to generate glibc.spec are part of upstream glibc source - if so, a simple comment which says 'look at foo/bar/Makefile in source0 for details' would be fine, if not, the Makefile should probably be included as another Source, as suggested in the guideline. There's also this, for patches: All patches in Fedora spec files SHOULD have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. This is a SHOULD not a MUST, but really, it's pretty basic - I'd say it's more important in this case as the glibc patch is not a typical one, and I think would leave most readers of the spec file confused. Its nature and source really should be indicated by a comment. Too, there's no indication of the 'upstream status' of the Fedora changes; once you know they form a git branch, you could go upstream and look at the git commit logs to discover the *nature* of the change, I suppose, but not necessarily its *upstream status* - i.e. whether a change made in the Fedora branch of git is Fedora specific, or is planned to be merged into master, or what. To look at things at a higher level: it's clearly the goal of the guidelines that any interested party (with sufficient basic knowledge) who comes along and checks a Fedora package out of git should be able to _understand it_, and this includes finding out where all the stuff that goes to make up the package actually comes from. glibc spec clearly doesn't achieve this goal; the casual browser is left looking at a gigantic patch and a mystery tarball and wondering where they came from and what they do, as I was. This makes glibc not at all raptor-proof, and not very amenable to outside review or improvements, which is rather against the spirit of an open source, community project. -- 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
Bundle question
Hello. I'm review jreen library and there found [1] very interesting issue - psi and kdenetwork bundle iris, jdns [2] and simplesasl. For example: $ find kdenetwork-4.6.5 psi-0.14 -iname simplesasl\* kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.h kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.cpp psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.h psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.cpp Should I fill bugs about it against both? iris (simplesasl its part) is psi [3] library, and as I understand released in it. So I think it may contain it. But how deal with kdenetwork? 1 https://bugzilla.redhat.com/show_bug.cgi?id=731456#c8 2 http://delta.affinix.com/jdns/ 3 http://psi-im.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/03/2011 07:31 PM, Adam Williamson wrote: To look at things at a higher level: it's clearly the goal of the guidelines that any interested party (with sufficient basic knowledge) who comes along and checks a Fedora package out of git should be able to _understand it_, and this includes finding out where all the stuff that goes to make up the package actually comes from. glibc spec clearly doesn't achieve this goal; the casual browser is left looking at a gigantic patch and a mystery tarball and wondering where they came from and what they do, as I was. This makes glibc not at all raptor-proof, and not very amenable to outside review or improvements, which is rather against the spirit of an open source, community project. And the mind goes to a recent case of obfuscation by merging patches. http://lwn.net/Articles/432012/ In that case RedHat acknowledged that a single giant patch is more difficult to understand and it confirmed that this was considered a feature (for commercial reasons); someone even started to debate if that could be considered a GPL violation, on the source in preferred form criteria. Regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
Nils Philippsen wrote: Legal question: is it better to put this in its own subpackage to be able to specify this individual license, or would GIMP better have GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3) as its license? Not an actual answer to your question, but wouldn't the license of the PDF plugin be GPLv3 only rather than (GPLv2 or GPLv3), considering that GIMP is GPLv3+? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Kevin Kofler kevin.kof...@chello.at writes: Stephen John Smoogen wrote: On Sat, Sep 3, 2011 at 07:46, Reindl Harald h.rei...@thelounge.net wrote: How many releases will this dirty mix of systemd/sysvinit(lsb in the distribution exist until the OS can be called as clean like before F15? As many as it takes to get it done. We need to get a provenpackager to just poke through all the packages and fix them instead of waiting for the maintainers. That doesn't seem to me to be a very good idea. Having recently worked on the systemd migrations for mysql and postgresql, I know that there are frequently package-specific considerations that are not obvious to the casual onlooker. Having somebody who thinks he knows what he's doing hack all the unfixed services is likely to make things worse not better. We should also remove this stupid cannot migrate to a native systemd unit in an update rule. If a native systemd unit file gets written, it should be pushed out to F16 and F15 immediately. That policy annoyed me at first but I've seen the wisdom of it. Doing something like that will very likely break users' customizations of their service setups, which is not something you want to have happen after a routine yum update. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Software-License-0.103002.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Software-License: 26497d9e8c41d1e1883f5b266933e44a Software-License-0.103002.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-Software-License: 6/7] Pseudo-merge for dist-git setup
commit a38830df009327215794791d7a957dcd5652042b Merge: 4136c1d 7316a4d Author: Iain Arnell iarn...@gmail.com Date: Sat Sep 3 11:13:06 2011 +0200 Pseudo-merge for dist-git setup el6 branch should really be tracking master --- -- 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-Software-License: 7/7] update to 0.103002
commit 66984865f346cc73d0a15f6ef6dcb727f6e2594a
Author: Iain Arnell iarn...@gmail.com
Date: Sat Sep 3 11:14:13 2011 +0200
update to 0.103002
perl-Software-License.spec |7 +--
sources|2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Software-License.spec b/perl-Software-License.spec
index 4028c72..4442f0f 100644
--- a/perl-Software-License.spec
+++ b/perl-Software-License.spec
@@ -1,6 +1,6 @@
Name: perl-Software-License
-Version:0.102341
-Release:4%{?dist}
+Version:0.103002
+Release:1%{?dist}
Summary:Package that provides templated software licenses
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sat Sep 03 2011 Iain Arnell iarn...@gmail.com 0.103002-1
+- update to latest upstream version
+
* Wed Jun 29 2011 Marcela Mašláňová mmasl...@redhat.com - 0.102341-4
- Perl mass rebuild
diff --git a/sources b/sources
index 61091e2..de226d4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8e2a4347bc8e22a2d577a77b05beea93 Software-License-0.102341.tar.gz
+26497d9e8c41d1e1883f5b266933e44a Software-License-0.103002.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-Software-License/f15] (8 commits) ...update to 0.103002
Summary of changes: fbb3e30... Fix typo that causes a failure to update the common directo (*) 1eecc47... - update to 0.101410 release (*) 20e16f9... fix release number (*) 58c8839... Initialize branch EL-6 for perl-Software-License (*) 7316a4d... dist-git conversion (*) 4136c1d... Perl mass rebuild (*) a38830d... Pseudo-merge for dist-git setup (*) 6698486... update to 0.103002 (*) (*) 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
[perl-Software-License/f14] (11 commits) ...update to 0.103002
Summary of changes: fbb3e30... Fix typo that causes a failure to update the common directo (*) 1eecc47... - update to 0.101410 release (*) 20e16f9... fix release number (*) 58c8839... Initialize branch EL-6 for perl-Software-License (*) 7316a4d... dist-git conversion (*) 66f1970... Update to 0.102341 release (*) e9dba33... - 661697 rebuild for fixing problems with vendorach/lib (*) dc51f92... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 4136c1d... Perl mass rebuild (*) a38830d... Pseudo-merge for dist-git setup (*) 6698486... update to 0.103002 (*) (*) 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
[perl-Software-License/el6] (11 commits) ...update to 0.103002
Summary of changes: 31efebb... Fix typo that causes a failure to update the common directo (*) f65e5d0... - rebuild against perl 5.10.1 (*) 4920c67... - Mass rebuild with perl-5.12.0 (*) 1d5e8ee... - update to 0.101410 release (*) b8bbdd4... dist-git conversion (*) 66f1970... Update to 0.102341 release (*) e9dba33... - 661697 rebuild for fixing problems with vendorach/lib (*) dc51f92... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 4136c1d... Perl mass rebuild (*) a38830d... Pseudo-merge for dist-git setup (*) 6698486... update to 0.103002 (*) (*) 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
File HTML-FillInForm-2.1.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-HTML-FillInForm: b4608cb3060b6b33fbec4679b56ebdc8 HTML-FillInForm-2.1.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-HTML-FillInForm] Update to 2.1 and clean-up specfile
commit ffaa79ac6ada56e382d64a2f8463d6458ec63414
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Sat Sep 3 12:16:44 2011 +0200
Update to 2.1 and clean-up specfile
.gitignore|1 +
perl-HTML-FillInForm.spec | 15 ++-
sources |2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8f2995d..058921a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
HTML-FillInForm-2.00.tar.gz
+/HTML-FillInForm-2.1.tar.gz
diff --git a/perl-HTML-FillInForm.spec b/perl-HTML-FillInForm.spec
index 943aa83..74ec0eb 100644
--- a/perl-HTML-FillInForm.spec
+++ b/perl-HTML-FillInForm.spec
@@ -1,12 +1,11 @@
Name: perl-HTML-FillInForm
-Version:2.00
-Release:7%{?dist}
+Version:2.1
+Release:1%{?dist}
Summary:Populates HTML Forms with data
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTML-FillInForm/
Source0:
http://www.cpan.org/authors/id/T/TJ/TJMATHER/HTML-FillInForm-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI)
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -29,8 +28,6 @@ allowing you to keep the HTML and Perl separate.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -41,16 +38,16 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Sat Sep 03 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 2.1-1
+- Update to 2.1
+- Spec clean-up
+
* Wed Jun 29 2011 Marcela Mašláňová mmasl...@redhat.com - 2.00-7
- Perl mass rebuild
diff --git a/sources b/sources
index fdc2697..026c444 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f2ab6814077e3a2d41a456f34ecb028f HTML-FillInForm-2.00.tar.gz
+b4608cb3060b6b33fbec4679b56ebdc8 HTML-FillInForm-2.1.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 735542] New: perl-Text-Table-1.124 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-Text-Table-1.124 is available https://bugzilla.redhat.com/show_bug.cgi?id=735542 Summary: perl-Text-Table-1.124 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Text-Table 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: 1.124 Current version in Fedora Rawhide: 1.123 URL: http://search.cpan.org/dist/Text-Table/ 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-Dist-Zilla] update to 4.300000
commit 7bb2939d115c975c94577cd95fdb3cd43e052412
Author: Iain Arnell iarn...@gmail.com
Date: Sat Sep 3 14:29:38 2011 +0200
update to 4.30
.gitignore |1 +
perl-Dist-Zilla.spec |7 ++-
sources |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 537c57e..3d915c6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Dist-Zilla-4.101900.tar.gz
/Dist-Zilla-4.28.tar.gz
/Dist-Zilla-4.200012.tar.gz
/Dist-Zilla-4.200017.tar.gz
+/Dist-Zilla-4.30.tar.gz
diff --git a/perl-Dist-Zilla.spec b/perl-Dist-Zilla.spec
index 484f58e..dec5cc1 100644
--- a/perl-Dist-Zilla.spec
+++ b/perl-Dist-Zilla.spec
@@ -1,5 +1,5 @@
Name: perl-Dist-Zilla
-Version:4.200017
+Version:4.30
Release:1%{?dist}
Summary:Distribution builder; installer not included!
License:GPL+ or Artistic
@@ -26,6 +26,7 @@ BuildRequires: perl(CPAN::Meta::Prereqs) = 2.101390
BuildRequires: perl(CPAN::Uploader) = 0.101550
BuildRequires: perl(Data::Section) = 0.004
BuildRequires: perl(DateTime) = 0.44
+BuildRequires: perl(Encode)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::Manifest) = 1.54
BuildRequires: perl(File::pushd)
@@ -62,6 +63,7 @@ BuildRequires: perl(Software::LicenseUtils)
BuildRequires: perl(String::Formatter) = 0.100680
BuildRequires: perl(String::RewritePrefix) = 0.005
BuildRequires: perl(Sub::Exporter)
+BuildRequires: perl(Sub::Exporter::ForMethods)
BuildRequires: perl(Sub::Exporter::Util)
BuildRequires: perl(Term::ReadKey)
BuildRequires: perl(Term::ReadLine)
@@ -128,6 +130,9 @@ make test
%{_sysconfdir}/bash_completion.d
%changelog
+* Sun Aug 28 2011 Iain Arnell iarn...@gmail.com 4.30-1
+- update to latest upstream version
+
* Thu Aug 18 2011 Iain Arnell iarn...@gmail.com 4.200017-1
- update to latest upstream version
diff --git a/sources b/sources
index 7ca505e..8a039ae 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6882aa1fb88b100a6d2636958b71bf4f Dist-Zilla-4.200017.tar.gz
+a984da5dcec520695f77bdf9834df2db Dist-Zilla-4.30.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
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.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
Broken dependencies: perl-Hash-FieldHash
perl-Hash-FieldHash has broken dependencies in the F-16 tree: On x86_64: perl-Hash-FieldHash-0.10-2.fc15.x86_64 requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Hash-FieldHash-0.10-2.fc15.i686 requires perl(:MODULE_COMPAT_5.12.4) 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
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 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
Broken dependencies in EPEL - 2011-09-04
Your following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-Authen-Simple-0.4-5.el6.noarch from fedora-epel-testing-6-ppc64 unresolved deps: perl(Crypt::PasswdMD5) -- 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
