[Bug 605836] RFE: show ksm stats in virt-top
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=605836 --- Comment #2 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 06:19:23 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 603230] ocaml-sqlite-devel doesn't work properly without sqlite-devel, but it's not a dependency
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=603230 --- Comment #1 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 07:10:52 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 710290] ocaml-findlib should require ocaml
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=710290 --- Comment #1 from Richard W.M. Jones rjo...@redhat.com 2011-06-02 18:16:11 EDT --- Orion, you're a trusted packager aren't you? If so just go ahead and add the dep. -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: orphaning cnetworkmanager
I'm not sure nmcli does everything cnetworkmanager did -- e.g. Can you create new (wireless) connection with nmcli? On Wed, 2011-06-01 at 08:51 -0600, Kevin Fenzi wrote: I've just orphaned cnetworkmanager. Upstream is pretty dead, and nmcli does everything cnetworkmanager did and more. Also, it may not work at all in f15+ due to NM changes. There's 2 open bugs on it: 709356Fedora new cnetworkmanager D-Bus error, ServiceName property 583043Fedora assignedUnicodeEncodeError in networkmanager/util.py line 125 If someone would like to take it and run with it, great. ;) kevin -- 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: What is the status of Features/YumLangpackPlugin?
José Matos wrote: 1) This feature will also allow firefox and thunderbird to earn langpacks as they deserve. Yes that was my hope but it needs acceptance from the fedora mozilla packagers... Support and encouragement is welcome. In F15 asking yum list *langpack* shows that only koffice libreoffice tesseract You're oversimplifying: the plugin does not search for langpack. :) eg kde-l10n is already supported since F13 I think. This seems an easy step, both to standardize the form of lang as well as to suggest a virtual provides to packages that already provide this, I am thinking in this case of packages like kde-i18n* or kde-i10n*. Yes I think meta Provides is probably the way to go. Concrete suggestions and design improvements are welcome - particularly in bugzilla. :-) I think Bill Nottingham also has some more ideas in this direction. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
- Original Message - On 06/01/2011 09:59 PM, Genes MailLists wrote: Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? This also means anyone using the memtest86+ from install (F15 or F14) will not be able to run it if they have Sandy Bridge - it just hangs. Probably worth noting that in the wiki somewhere too .. -- 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
HEADS UP : soname bump in libmemcached
libmemcached 0.49, in rawhide, now provides: libhashkit.so.1 libmemcached.so.7 libmemcachedprotocol.so.0 libmemcachedutil.so.2 You may also have to check new syntax for config, which could affect some clients: http://docs.libmemcached.org/libmemcached_examples.html Regards, Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
R: Re: Plan for tomorrow's FESCo meeting (2011-06-01)
Messaggio originale Da: Peter Robinson Inviato: 01/06/2011, 22:41 A: Development discussions related to Fedora Oggetto: Re: Plan for tomorrow's FESCo meeting (2011-06-01) On 1 Jun 2011 19:44, Josef Bacik jo...@toxicpanda.com wrote: On Wed, Jun 1, 2011 at 11:15 AM, Peter Robinson pbrobin...@gmail.com wrote: I will be unable to attend tomorrow but I have concerns of making btrfs default without a well tested fsck. I'm aware one is due soon but I don't believe 3-4 months is enough time to test it well enough. On 2.6.38.x I still get regular kernel abrt crashes on resume. Is it even marked stable in the upstream kernel yet? Have you filed bugs for these crashes? Yes. Well at least I've submitted them using abrt to wherever is sends the kernel crash dumps. Not done a manual separate bug though. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rsync for repos.fedoraproject.org?
Is there any way to rsync from repos.fedoraproject.org? I'd like to have a local mirror of spot's chromium repository, and wgetting it is pretty nasty. Jonathan 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: Intent to package GNOME Shell frippery
On Wed, Jun 1, 2011 at 7:59 PM, Michael Cronenworth m...@cchtml.com wrote: Ron Yorston wrote: I'd prefer them to be in one package: they are intended to work together. Except the Shut Down menu extension directly conflicts with the alternative-status-menu extension. Sub-packages are the safest bet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel +1 for sub packages too. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110602 changes
Compose started at Thu Jun 2 08:15:28 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.16-1.fc16.i686 requires libadmsslutil.so.1 389-admin-1.1.16-1.fc16.i686 requires libadminutil.so.1 389-admin-1.1.16-1.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-admin-1.1.16-1.fc16.x86_64 requires libadminutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadminutil.so.1()(64bit) CGSI-gSOAP-1.3.4.0-2.fc15.i686 requires libvomsapi.so.0 CGSI-gSOAP-1.3.4.0-2.fc15.x86_64 requires libvomsapi.so.0()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk.so.1.1()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk_gl.so.1.1()(64bit) SteGUI-0.0.1-17.fc15.x86_64 requires libfltk_images.so.1.1()(64bit) SteGUI-0.0.1-17.fc15.x86_64 requires libfltk.so.1.1()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) alsa-tools-1.0.24.1-2.fc15.x86_64 requires libfltk.so.1.1()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) coda-vcodacon-6.9.5-4.fc15.x86_64 requires libfltk.so.1.1()(64bit) condor-deltacloud-gahp-7.7.0-0.1.fc16.x86_64 requires libdeltacloud.so.5(LIBDCLOUDAPI_2.0.0)(64bit) condor-deltacloud-gahp-7.7.0-0.1.fc16.x86_64 requires libdeltacloud.so.5(LIBDCLOUDAPI_0.0.0)(64bit) condor-deltacloud-gahp-7.7.0-0.1.fc16.x86_64 requires libdeltacloud.so.5(LIBDCLOUDAPI_1.0.0)(64bit) condor-deltacloud-gahp-7.7.0-0.1.fc16.x86_64 requires libdeltacloud.so.5()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 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) dh-make-0.55-3.fc15.noarch requires debhelper ed2k_hash-gui-0.4.0-10.fc13.x86_64 requires libfltk.so.1.1()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.23()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(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 libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) 1:fife-0.3.2-4.r2.fc16.i686 requires libguichan_opengl-0.8.1.so.1 1:fife-0.3.2-4.r2.fc16.i686 requires libguichan_sdl-0.8.1.so.1 1:fife-0.3.2-4.r2.fc16.i686 requires libguichan-0.8.1.so.1 1:fife-0.3.2-4.r2.fc16.x86_64 requires libguichan-0.8.1.so.1()(64bit) 1:fife-0.3.2-4.r2.fc16.x86_64 requires libguichan_sdl-0.8.1.so.1()(64bit) 1:fife-0.3.2-4.r2.fc16.x86_64 requires libguichan_opengl-0.8.1.so.1()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.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) flpsed-0.5.2-2.fc15.x86_64 requires libfltk.so.1.1()(64bit) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk_images.so.1.1()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk.so.1.1()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet = 0:2.16 gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires
Re: memtest86+
On 06/02/2011 04:44 AM, Jaroslav Skarvada wrote: - Original Message - 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav Thanks - I did file a bug and see that you replied to the bug too - so thanks. (my bugzilla account name is a bit diffderent :-)) gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rubygems 1.8.5 hits rawhide with license change
Hello, all: Now rawhide buildtree sees rubygems 1.8.5. The license changed from (Ruby or GPL+) to (Ruby or MIT). If you see any issues with new rubygems please feel free to report them, thank you. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rsync for repos.fedoraproject.org?
On Thu, 2 Jun 2011, Jonathan Dieter wrote: Is there any way to rsync from repos.fedoraproject.org? I'd like to have a local mirror of spot's chromium repository, and wgetting it is pretty nasty. This should do it: rsync -az --progress -e ssh fedorapeople.org:/srv/repos/ /your/path You do need a fedorapeople account to do that though. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rsync for repos.fedoraproject.org?
On Thu, 2011-06-02 at 07:32 -0500, Mike McGrath wrote: On Thu, 2 Jun 2011, Jonathan Dieter wrote: Is there any way to rsync from repos.fedoraproject.org? I'd like to have a local mirror of spot's chromium repository, and wgetting it is pretty nasty. This should do it: rsync -az --progress -e ssh fedorapeople.org:/srv/repos/ /your/path You do need a fedorapeople account to do that though. That's great! I didn't realize they were sitting in /srv/repos. Thanks much! Jonathan 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: Installing bash-completion by default in F-16
On Wed, 2011-06-01 at 23:54 +0300, Ville Skyttä wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? Do it. - ajax 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: Installing bash-completion by default in F-16
On 06/01/2011 10:54 PM, Ville Skyttä wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? It doesn't belong into base. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Wed, Jun 01, 2011 at 11:54:05PM +0300, Ville Skyttä wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? Why would you include an optional functionality (a quote from Packaging guidelines) package in the default installation? I personally don't use bash as my interactive shell and don't really like the idea of having more bash-related stuff than necessary in my system. -- # Petr Sabata pgpVkkFXlUSao.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Am 01.06.2011 22:54, schrieb Ville Skyttä: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? PLEASE do not make a basic-install larger with something what maybe for someone nice, thats from a user which installs bash-completion on each machine after setup, there are people out there using other shells and the base-setup has to be as small as possible it hurts me that cross-dependencies and automatically installed services gettng larger and larger with every realease example: /dev/sdb1 ext4 6,0G 1,8G 4,2G 30% / this machine is only needed for netatalk, samba and gedit additionally to 3 admin-guis over X-Forwarding are installed system-config-users-1.2.107-1.fc14.noarch system-config-samba-1.2.90-1.fc14.noarch system-config-lvm-1.1.15-1.fc14.noarch 1.8 GB is really much for that usecase and it was a hard piece of work to get all away which is not needed somebody will come out now and telling me that disk-space is cheap these days without realizing that SAN-Storage is not cheap, having 20 virtual machines on a host muliplies the wasted space and the useless time for updates of packages never really used is forgotten too it's time to get a solution for soft-dependencies to get rid of packages with additional functionality possible not needed and the everything should work for everybody out of the box thoughts are making setups big with a small benefit for only some peopole while others are frustrated remember: every package/software/library which is not installed is not vulnerable! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Thu, Jun 2, 2011 at 4:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.06.2011 22:54, schrieb Ville Skyttä: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? PLEASE do not make a basic-install larger with something what maybe for someone nice, thats from a user which installs bash-completion on each machine after setup, there are people out there using other shells and the base-setup has to be as small as possible That wouldn't be a hard dep you can just uninstall it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On 1 Jun 2011 21:54, Ville Skyttä ville.sky...@iki.fi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? Things like bash completion have massive performance implications on network and other slower file systems esp if its used for home directories. It certainly shouldn't be in base. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Thu, 2011-06-02 at 15:04 +0100, Peter Robinson wrote: On 1 Jun 2011 21:54, Ville Skyttä ville.sky...@iki.fi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? Things like bash completion have massive performance implications on network and other slower file systems esp if its used for home directories. It certainly shouldn't be in base. +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Am 02.06.2011 16:04, schrieb drago01: On Thu, Jun 2, 2011 at 4:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.06.2011 22:54, schrieb Ville Skyttä: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? PLEASE do not make a basic-install larger with something what maybe for someone nice, thats from a user which installs bash-completion on each machine after setup, there are people out there using other shells and the base-setup has to be as small as possible That wouldn't be a hard dep you can just uninstall it so PLEASE install a new fedora and remove anything not needed for ssh, rsync, scp and tell me how long it takes to find all of them what you do with such a machine: decide what services you will install on this bare setup or using as it is as backup-host where rsync is enough much of them you can only find with trial and error by look what yum says to a yum remove because package-cleanup --leaves does not find most things without lib in the name and then tell why the count of unneeded base-packages should be increased remember: base is defined the absoloutly minimum to boot a system and log in as root! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Thu, 2011-06-02 at 16:11 +0200, Reindl Harald wrote: Am 02.06.2011 16:04, schrieb drago01: On Thu, Jun 2, 2011 at 4:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.06.2011 22:54, schrieb Ville Skyttä: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? PLEASE do not make a basic-install larger with something what maybe for someone nice, thats from a user which installs bash-completion on each machine after setup, there are people out there using other shells and the base-setup has to be as small as possible That wouldn't be a hard dep you can just uninstall it so PLEASE install a new fedora and remove anything not needed for ssh, rsync, scp and tell me how long it takes to find all of them what you do with such a machine: decide what services you will install on this bare setup or using as it is as backup-host where rsync is enough much of them you can only find with trial and error by look what yum says to a yum remove because package-cleanup --leaves does not find most things without lib in the name package-cleanup --leaves --all and then tell why the count of unneeded base-packages should be increased remember: base is defined the absoloutly minimum to boot a system and log in as root! no @core is - %packages --nobase -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Am 02.06.2011 16:15, schrieb seth vidal: so PLEASE install a new fedora and remove anything not needed for ssh, rsync, scp and tell me how long it takes to find all of them what you do with such a machine: decide what services you will install on this bare setup or using as it is as backup-host where rsync is enough much of them you can only find with trial and error by look what yum says to a yum remove because package-cleanup --leaves does not find most things without lib in the name package-cleanup --leaves --all is listing grub-0.97-66.fc14.x86_64 i hope you understand why i not trust this output :-) and then tell why the count of unneeded base-packages should be increased remember: base is defined the absoloutly minimum to boot a system and log in as root! no @core is - %packages --nobase please leave me in peace with discussins how a word is used and where i mean simply the ability to install a minimal-system without any optional software and this is getting harder every month signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On 06/02/2011 09:07 AM, seth vidal wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Thu, 2011-06-02 at 16:21 +0200, Reindl Harald wrote: package-cleanup --leaves --all is listing grub-0.97-66.fc14.x86_64 i hope you understand why i not trust this output :-) grub isn't required. and then tell why the count of unneeded base-packages should be increased remember: base is defined the absoloutly minimum to boot a system and log in as root! no @core is - %packages --nobase please leave me in peace with discussins how a word is used and where i mean simply the ability to install a minimal-system without any optional software and this is getting harder every month I don't disagree - but @base is not that group. @core is and @core is still pretty small. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Am 02.06.2011 16:36, schrieb seth vidal: please leave me in peace with discussins how a word is used and where i mean simply the ability to install a minimal-system without any optional software and this is getting harder every month I don't disagree - but @base is not that group. @core is and @core is still pretty small. i do not soo often install my systems new :-) but what i notice over years on the same setup that permanently new packages are required/installed and many of them obsoleted sooner or later and i tried to get the focus a little bit more to reduce dpendencies and automatic installed packages signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On 06/02/2011 10:32 AM, Michael Cronenworth wrote: On 06/02/2011 09:07 AM, seth vidal wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. +1 : Due to horrible performance issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Peter Robinson (pbrobin...@gmail.com) said: On 1 Jun 2011 21:54, Ville Skyttä ville.sky...@iki.fi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=709647 I'd like to have bash-completion included in F-16's default install. In my opinion it's in a good enough shape for that already now, and with my upstream hat on I expect things to further improve before F-16 is out. Why I'm writing here is that I'd like to hear opinions to which default-installed comps group should it be added (and set as default there) - in my opinion the serious candidates are admin-tools and base. admin-tools doesn't sound right because bash-completion is not really an admin tool (unless one considers interactive shell usage as admin activity in general), so I'm inclined to add it to base. Thoughts? Things like bash completion have massive performance implications on network and other slower file systems esp if its used for home directories. It certainly shouldn't be in base. Moving it to default in @system-tools seems fine to me as a first step. However, that's not in the 'default' install (but it would place it on the install media.) If it's wanted in the default install, the @base group is the best place for it (it doesn't belong in @core.) From a size perspective, it's not a huge deal - 500k with no deps that aren't already in @core. From a functionality perspective, it would be good to fix the issues it has with disconnected machines, etc. - I've always removed it personally because the times where it would annoy me would always weigh higher than the times where it helped. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
patch only if dependent version x? (rpm spec)
How can I apply a patch only if the version of a dependency is x? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
José Matos (jama...@fc.up.pt) said: My problem in a sense is that it is limited in scope. :-( http://fedoraproject.org/wiki/Features/YumLangpackPlugin was the feature page for when the feature was initially deployed. The purpose of this is post is to raise awareness for this feature and continue to have it implemented to have a better experience for our users (from where developers are a subset). 1) This feature will also allow firefox and thunderbird to earn langpacks as they deserve. It certainly allows for it - it requires that the packagers take advantage of it. ISTR discussions in the past that the mechanics of creating the langpacks in the spec file wasn't something they wanted to deal with at the time. yum-langpacks can't help with that part. 2) In the Optional/longer term ideas: 3. recommendation for Packaging Guideline for standard naming of langpacks (eg basename-langpack-lang) This seems an easy step, both to standardize the form of lang as well as to suggest a virtual provides to packages that already provide this, I am thinking in this case of packages like kde-i18n* or kde-i10n*. These virtual provides should be there for any langpack that exists. I suppose I should write an official packaging guideline for this. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: patch only if dependent version x? (rpm spec)
Neal Becker writes: How can I apply a patch only if the version of a dependency is x? You mean you want to specify the dependency's version in a macro, that you put into Requires:? If so, just use the macro in your build script, it'll be expanded, and you can test its value. Bare-bones shell isn't usually convenient for understanding most kinds of version number formats. You may need to do something fancy. pgpJ7aOIHjqVS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On Wed, Jun 01, 2011 at 08:22:25AM +0200, fkoo...@tuxed.net wrote: This [1] may be of some help as a high level overview of how to deploy IPv6 on a LAN and various operating system IPv6 compatibilities. Fedora is doing quite well! The document is not a configuration help, but it might make it clear how everything fits together and brush you up on your IPv6 :-) [...] [1] http://www.surfnet.nl/Documents/IPv6%20Deployment%20In%20Local%20Area%20Networks.pdf This document is a good introduction, but it appears to assume that I've got an IPv6 router and internet connection. I guess that's not going to apply to very many people. Is there an easy way I can set up IPv6 and a handful of machines on my LAN for testing, without requiring any IPv6 internet connection or an IPv6 assigned prefix? The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument (Note I have no idea at all what I'm doing here so it's probably some elementary error). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Wed, Jun 01, 2011 at 04:15:59PM +0100, Peter Robinson wrote: I will be unable to attend tomorrow but I have concerns of making btrfs default without a well tested fsck. I'm aware one is due soon but I don't believe 3-4 months is enough time to test it well enough. On 2.6.38.x I still get regular kernel abrt crashes on resume. Is it even marked stable in the upstream kernel yet? Another concern is whether btrfs is going to work well to store virtual machine disk images (ie. to replace LVM for that purpose, where LVM is known to work very efficiently). Last time I looked -- which I admit was a really long time ago -- it behaved fairly pathologically with these huge monolithic files that are rewritten in-place. (Edit: just noticed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=689127 ) 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
Re: Installing bash-completion by default in F-16
On Thu, Jun 02, 2011 at 09:32:21AM -0500, Michael Cronenworth wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. Yeah. Bash-completion could stand to be broken up into a few sub-packages. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: On Wed, Jun 01, 2011 at 08:22:25AM +0200, fkoo...@tuxed.net wrote: This [1] may be of some help as a high level overview of how to deploy IPv6 on a LAN and various operating system IPv6 compatibilities. Fedora is doing quite well! The document is not a configuration help, but it might make it clear how everything fits together and brush you up on your IPv6 :-) [...] [1] http://www.surfnet.nl/Documents/IPv6%20Deployment%20In%20Local%20Area%20Networks.pdf This document is a good introduction, but it appears to assume that I've got an IPv6 router and internet connection. I guess that's not going to apply to very many people. Is there an easy way I can set up IPv6 and a handful of machines on my LAN for testing, without requiring any IPv6 internet connection or an IPv6 assigned prefix? The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. The only thing that commonly uses the link local addresses is IPv6 autoconfig, at which point you get a real IPv6 address, which is globally unique that real applications can use. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: patch only if dependent version x? (rpm spec)
Sam Varshavchik wrote: Neal Becker writes: How can I apply a patch only if the version of a dependency is x? You mean you want to specify the dependency's version in a macro, that you put into Requires:? If so, just use the macro in your build script, it'll be expanded, and you can test its value. Bare-bones shell isn't usually convenient for understanding most kinds of version number formats. You may need to do something fancy. I mean, a patch is needed only if one of the BR versions is less than a.b. So I want to conditionally apply a patch, based on the version of the BR. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: Is there an easy way I can set up IPv6 and a handful of machines on my LAN for testing, without requiring any IPv6 internet connection or an IPv6 assigned prefix? Yes, every system automatically chooses a link-local address. The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever fe80:: are link local. The hint is scope link. but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument For using link local addresses, you need to specify the outgoing network interface, because the addresses are global to the host, not local to any one interface. Otherwise, it would have no way of knowing which interface to send the packets out of. Also, don't put the /nn, because that is the prefix length (equivalent to the IPv4 subnetwork mask). There are two ways typically to specify outgoing interface for link local: ping6 -I eth0 fe80::2e0:81ff:fe74:228 or: ping6 fe80::2e0:81ff:fe74:228%eth0 Some apps work with one vs. the other. Another tidbit: for IPv6 literals like above, some applications require you to put them in square brackets. For example, web browsers need this syntax: http://[fe80::2e0:81ff:fe74:228%eth0]/ Support for %iface or [] syntax may not be universal, unfortunately. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
Daniel P. Berrange wrote: On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. Ping6 has a way though: $ ping6 -I eth0 fe80::200:24ff:fec9:2e0c PING fe80::200:24ff:fec9:2e0c(fe80::200:24ff:fec9:2e0c) from fe80::21e:8cff:fecf:cde5 eth0: 56 data bytes 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=1 ttl=64 time=1.69 ms 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=2 ttl=64 time=0.263 ms 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: patch only if dependent version x? (rpm spec)
On Thu, Jun 02, 2011 at 11:48:35AM -0400, Neal Becker wrote:
Sam Varshavchik wrote:
Neal Becker writes:
How can I apply a patch only if the version of a dependency is x?
You mean you want to specify the dependency's version in a macro, that you
put into Requires:? If so, just use the macro in your build script, it'll be
expanded, and you can test its value. Bare-bones shell isn't usually
convenient for understanding most kinds of version number formats. You may
need to do something fancy.
I mean, a patch is needed only if one of the BR versions is less than a.b.
So I
want to conditionally apply a patch, based on the version of the BR.
How about this evil untested recursive invocation of rpm?
%prep
%configure
package=glibc
minversion=2.13.89
if [ $(
rpm -q --queryformat '%{version}\n' $package |
cat - (echo $minversion) |
sort -V |
head -1
) = $minversion ]; then
%patch0 -p1
fi
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: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 06:00:44PM +0200, Björn Persson wrote: Daniel P. Berrange wrote: On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. Ping6 has a way though: $ ping6 -I eth0 fe80::200:24ff:fec9:2e0c PING fe80::200:24ff:fec9:2e0c(fe80::200:24ff:fec9:2e0c) from fe80::21e:8cff:fecf:cde5 eth0: 56 data bytes 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=1 ttl=64 time=1.69 ms 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=2 ttl=64 time=0.263 ms But that's not so useful if no other programs can use these addresses. Is there a way to assign proper addresses? Just run radvd and configure it with a random prefix? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: patch only if dependent version x? (rpm spec)
On Thu, Jun 02, 2011 at 05:06:54PM +0100, Richard W.M. Jones wrote: ) = $minversion ]; then That test should be != instead of = 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
[Bug 574195] AMAVISD_DB_HOME in amavisd-agent has wrong default
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=574195 --- Comment #3 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 12:08:41 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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: patch only if dependent version x? (rpm spec)
On 06/02/2011 12:06 PM, Richard W.M. Jones wrote:
How about this evil untested recursive invocation of rpm?
%prep
%configure
package=glibc
minversion=2.13.89
if [ $(
rpm -q --queryformat '%{version}\n' $package |
cat - (echo $minversion) |
sort -V |
head -1
) = $minversion ]; then
%patch0 -p1
fi
Please don't do that. Ever. Even if in this very specific case, it is
probably safe, invoking rpm within the spec file sets a very poor
example for the thousands of other cases where it is very unsafe/unreliable.
A better way would be to leverage the .pc file for the component being
BuildRequired, although, the .pc files sometimes have the API version as
opposed to the actual version (GNOME, I'm looking at you).
Alternate ideas include:
* Checking for a versioned directory
* Looking for a version definition in a header file
* Invoking a binary from the BR that spits out version
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: patch only if dependent version x? (rpm spec)
Neal Becker writes:
Sam Varshavchik wrote:
Neal Becker writes:
How can I apply a patch only if the version of a dependency is x?
You mean you want to specify the dependency's version in a macro, that you
put into Requires:? If so, just use the macro in your build script, it'll
be
expanded, and you can test its value. Bare-bones shell isn't usually
convenient for understanding most kinds of version number formats. You may
need to do something fancy.
I mean, a patch is needed only if one of the BR versions is less than a.b.
So I
want to conditionally apply a patch, based on the version of the BR.
I see.
You're going to have to figure out what version of a dependency you're
building against. I suppose you can can rpm -q --queryformat '%{VERSION}'
$packagename, and get the version that way, then figure out if you want to
apply a patch. That approach feels wrong. I would look at your
dependency's files and see if its version can be retrieved from your
dependency's installations. If your dependency uses pkgconfig, it's as
simple as pkg-config --version $packagename.
Once you have the version, you can apply the patch.
if version test goes here
then
%patchX [options]
fi
pgpi7d2jHWKkb.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On Thu, 2 Jun 2011 17:07:47 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Jun 02, 2011 at 06:00:44PM +0200, Björn Persson wrote: Daniel P. Berrange wrote: On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. Ping6 has a way though: $ ping6 -I eth0 fe80::200:24ff:fec9:2e0c PING fe80::200:24ff:fec9:2e0c(fe80::200:24ff:fec9:2e0c) from fe80::21e:8cff:fecf:cde5 eth0: 56 data bytes 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=1 ttl=64 time=1.69 ms 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=2 ttl=64 time=0.263 ms But that's not so useful if no other programs can use these addresses. Is there a way to assign proper addresses? Just run radvd and configure it with a random prefix? Instead of random, you may want to use a Unique Local Address prefix, following http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-address-types Rich. -- Bernd Stramm bernd.str...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On Thu, Jun 2, 2011 at 5:47 PM, Matthew Miller mat...@mattdm.org wrote: On Thu, Jun 02, 2011 at 09:32:21AM -0500, Michael Cronenworth wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. Yeah. Bash-completion could stand to be broken up into a few sub-packages. To solve what kind of problem exactly? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 564798] FTBFS ocaml-camlimages-3.0.2-2.fc13
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=564798 --- Comment #10 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 12:33:45 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 555849] GTK+ and libsvg-cairo support missing from 1.2.0
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=555849 --- Comment #3 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 12:52:21 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 548098] Fix dependency generator usage in all OCaml packages
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=548098 --- Comment #5 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 13:06:26 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 548097] Fix OCaml packaging guidelines for new dependency generator
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=548097 --- Comment #4 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 13:06:34 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 12:16:13PM -0400, Bernd Stramm wrote: On Thu, 2 Jun 2011 17:07:47 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Jun 02, 2011 at 06:00:44PM +0200, Björn Persson wrote: Daniel P. Berrange wrote: On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. Ping6 has a way though: $ ping6 -I eth0 fe80::200:24ff:fec9:2e0c PING fe80::200:24ff:fec9:2e0c(fe80::200:24ff:fec9:2e0c) from fe80::21e:8cff:fecf:cde5 eth0: 56 data bytes 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=1 ttl=64 time=1.69 ms 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=2 ttl=64 time=0.263 ms But that's not so useful if no other programs can use these addresses. Is there a way to assign proper addresses? Just run radvd and configure it with a random prefix? Instead of random, you may want to use a Unique Local Address prefix, following http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-address-types It works :-) https://rwmj.wordpress.com/2011/06/02/ipv6-lan/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Thu, Jun 2, 2011 at 11:46 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 01, 2011 at 04:15:59PM +0100, Peter Robinson wrote: I will be unable to attend tomorrow but I have concerns of making btrfs default without a well tested fsck. I'm aware one is due soon but I don't believe 3-4 months is enough time to test it well enough. On 2.6.38.x I still get regular kernel abrt crashes on resume. Is it even marked stable in the upstream kernel yet? Another concern is whether btrfs is going to work well to store virtual machine disk images (ie. to replace LVM for that purpose, where LVM is known to work very efficiently). Last time I looked -- which I admit was a really long time ago -- it behaved fairly pathologically with these huge monolithic files that are rewritten in-place. (Edit: just noticed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=689127 ) These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 543660] Perl Archive::Zip fails writing to an unseekable file handle after calling desiredCompressionLevel()
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=543660 --- Comment #13 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 13:13:55 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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 541542] ocaml-cairo: cairo_ps_surface_set_dpi_REPLACED_BY_cairo_surface_set_fallback_resolution
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=541542 --- Comment #10 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 13:18:26 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 548098] Fix dependency generator usage in all OCaml packages
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=548098 Richard W.M. Jones rjo...@redhat.com changed: What|Removed |Added Version|13 |rawhide Flag|needinfo?(rjo...@redhat.com | |) | --- Comment #6 from Richard W.M. Jones rjo...@redhat.com 2011-06-02 13:25:06 EDT --- Bump up to Rawhide since there are a handful of packages still using the old code. -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 548097] Fix OCaml packaging guidelines for new dependency generator
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=548097 Richard W.M. Jones rjo...@redhat.com changed: What|Removed |Added Version|13 |rawhide Flag|needinfo?(rjo...@redhat.com | |) | --- Comment #5 from Richard W.M. Jones rjo...@redhat.com 2011-06-02 13:25:21 EDT --- Bump up to Rawhide. -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 529172] Fedora::Bugzilla - get_flag() doesn't work for all flags
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=529172 --- Comment #10 from Bug Zapper tri...@lists.fedoraproject.org 2011-06-02 13:36:35 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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: BTRFS concerns
On 06/02/2011 01:14 PM, Josef Bacik wrote: These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, Josef Wondering - Are all the pieces (user space included) in place for RAID 5 yet ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Request for removal of package from Fedora repositories: dasher.x86_64
Hello, dasher in Fedora has been broken for me since Fedora 12. The bug I entered has recently been automatically closed. dasher doesn't work in 64-bit and can be crashed by asking it to go fullscreen. What's the procedure to get the package removed? Thanks. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=538336 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for removal of package from Fedora repositories: dasher.x86_64
nodata wrote: Hello, dasher in Fedora has been broken for me since Fedora 12. The bug I entered has recently been automatically closed. dasher doesn't work in 64-bit and can be crashed by asking it to go fullscreen. What's the procedure to get the package removed? Thanks. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=538336 That's a bit premature. Have you tried contacting any of the other maintainers? https://admin.fedoraproject.org/pkgdb/acls/name/dasher If the primary maintainer isn't responding, you could try the following: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
Am Donnerstag, den 02.06.2011, 12:16 -0400 schrieb Bernd Stramm: On Thu, 2 Jun 2011 17:07:47 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Jun 02, 2011 at 06:00:44PM +0200, Björn Persson wrote: Daniel P. Berrange wrote: On Thu, Jun 02, 2011 at 04:40:10PM +0100, Richard W.M. Jones wrote: The Linux machines on my LAN appear to have acquired IPv6 addresses, eg: $ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:81:74:02:28 brd ff:ff:ff:ff:ff:ff inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0 inet6 fe80::2e0:81ff:fe74:228/64 scope link valid_lft forever preferred_lft forever but pinging them gives me strange errors: $ ping6 fe80::2e0:81ff:fe74:228/64 unknown host $ ping6 fe80::2e0:81ff:fe74:228 connect: Invalid argument $ ping6 fe80::2e0:81ff:fe74 connect: Invalid argument Anything with an fe80:: prefix is a link local address, which is only unique within the scope of a single LAN segment. Thus if you want to send traffic to such addresses, you need to specify the NIC to send the traffic out from. The vast majority of apps using sockets have no way to let you do this. Ping6 has a way though: $ ping6 -I eth0 fe80::200:24ff:fec9:2e0c PING fe80::200:24ff:fec9:2e0c(fe80::200:24ff:fec9:2e0c) from fe80::21e:8cff:fecf:cde5 eth0: 56 data bytes 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=1 ttl=64 time=1.69 ms 64 bytes from fe80::200:24ff:fec9:2e0c: icmp_seq=2 ttl=64 time=0.263 ms But that's not so useful if no other programs can use these addresses. Is there a way to assign proper addresses? Just run radvd and configure it with a random prefix? Instead of random, you may want to use a Unique Local Address prefix, following http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-address-types I brought this up some time ago: Assigning ULA instead of LL would be somewhat more user friendly: https://bugzilla.gnome.org/show_bug.cgi?id=615063 https://bugzilla.redhat.com/show_bug.cgi?id=581579 In my eyes just assigning a LL adress is not very user friendly. Rich. -- Bernd Stramm bernd.str...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for removal of package from Fedora repositories: dasher.x86_64
On Thu, Jun 2, 2011 at 3:00 PM, nodata l...@nodata.co.uk wrote: Hello, dasher in Fedora has been broken for me since Fedora 12. The bug I entered has recently been automatically closed. dasher doesn't work in 64-bit and can be crashed by asking it to go fullscreen. What's the procedure to get the package removed? Thanks. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=538336 Dasher works fine on a 64 bit system on F15 here. My version = dasher-4.10.1-2.fc12.x86_64 It looks like it hasn't been touched in some time though. There is a newer version out (4.11) available here: http://www.inference.phy.cam.ac.uk/dasher/Download.html Not sure if that will make the difference for you. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 705308] perlbrew-0.21 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=705308 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-06-02 15:00:15 EDT --- perlbrew-0.22-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. -- 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 692060] perl-Crypt-OpenSSL-X509-1.800.1 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=692060 --- Comment #19 from Fedora Update System upda...@fedoraproject.org 2011-06-02 15:04:08 EDT --- perl-Crypt-OpenSSL-X509-1.800.2-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- 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 692060] perl-Crypt-OpenSSL-X509-1.800.1 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=692060 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Crypt-OpenSSL-X509-1.8 |perl-Crypt-OpenSSL-X509-1.8 |00.2-1.fc14 |00.2-1.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
[Bug 709269] perl-SOAP-Lite provides bogus perl(LWP::Protocol)
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=709269 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-06-02 15:02:21 EDT --- Package perl-SOAP-Lite-0.712-5.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-SOAP-Lite-0.712-5.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-SOAP-Lite-0.712-5.fc14 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: Heads up: impending IPv6 Test Day
On Thu, Jun 2, 2011 at 5:40 PM, Richard W.M. Jones rjo...@redhat.com wrote: Is there an easy way I can set up IPv6 and a handful of machines on my LAN for testing, without requiring any IPv6 internet connection or an IPv6 assigned prefix? If you do want an assigned prefix, or real connectivity and not want to set up a (static) tunnel it may be possible to use 6to4 if your router is not behind NAT. See http://fedoraproject.org/wiki/IPv6Guide#Tunnel_Configuration. I did not test this myself (in Fedora), and 6to4 tends to be a bit flaky (in general) so ymmv. Regards, François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Thu, Jun 02, 2011 at 12:44:46PM -0500, Chris Adams wrote: Once upon a time, Josef Bacik jo...@toxicpanda.com said: These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, How does it compare to straight LVM for virtual images? I create a big LV and then only use part of it for the host OS VG; when I create VMs, I create a VG for each (or I can snapshot an existing base VG). It is my understanding that one goal for btrfs is to take LVM out of the picture for the common case; i.e. btrfs can do its own logical volume management. If that's the case, there needs to be something comparable to the VM-on-VG setup (in terms of ease-of-management and performance). Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. However the performance issue will be critical -- even 5% slower really matters for VMs. But I hope btrfs can close this gap because the filesystem design is really nice. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quick update PPC status
On Wednesday, June 01, 2011 12:48:36 PM David Woodhouse wrote: On Wed, 2011-06-01 at 18:53 +0200, Phil Knirsch wrote: We have tested them on a Power7 box as well as on an older Apple G5, but your mileage may vary. Especially on Power5 and Power6 the problem still exists that the unified initramfs of Anaconda is too large to fit into the initial RAM during bootup, so you'll need to revert to the method described in the next paragraph. Have we actually switched all userspace to 64-bit on 64-bit machines? That would exacerbate the initrd size issue quite a lot, wouldn't it? As well as being significantly less well-tested than the 32-bit support was. if so this is exactly the same as what rhel6 does Are the ExcludeArch trackers still up to date for ppc and ppc64? Is there an estimate of how many packages are not built for ppc64 that *are* built for ppc32? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomboy orphaned
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, It doesn't integrate into GNOME 3 any more, since it relies on a panel applet and GNOME 3 doesn't support those. It seems to work really well in Gnome 3. The applet sits down in the notification bar (like empathy) and is almost as convenient to use as it used to be. That's not actually applet, it's status icon, although they look the same. I'm going to change this behaviour by making Search All Notes window the main one. I plan to keep status icon available via setting, but not enabled by default. I just wish I could figure out how to get it to start that way using gnome-session-properties ... it only seems to include a persistent notification bar icon if you start it after logging in. Gnote gives status icon 2 seconds to appear and shows Search All Notes window as main, if that fails. If you somehow delay the gnote start (wrap to some script for example) until desktop components like tray are available, it should start in a tray. - -- Aurimas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN5+hXAAoJECtTeRAzEaLP4TsH/jqmXKxQBgiSwtKSMexzyac6 ytMEVvGT4OO+5uTmFBgQi9IBS06Ja75+PSIU1XsTdM5ycZc+Kzg732VZDaTbknu+ /2iC7TS3H4iBk6NDbMTDcOBG3++Y4PYSsAeVzb3OG0/sHLLilPsfRpLWguBxzAZN yUuedgaGgP/9ZRPoFtqL0ltRhN5n0lTTJ3b+umcUolVLoT3odskMu8uz+UZVSIt8 AbbjSjLaNEkfJ9cPyIFZeaF6tBmeGA4UnqI/iMcz5M9ghYvL/g5GAHuCH/chgWnQ ZMPAoX4y9UP9vFX826IjRvHbW91sObiA3/bEa1q0INw6TsMM8cDtib/lpwMgltI= =ZQA/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
Once upon a time, Richard W.M. Jones rjo...@redhat.com said: Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. However the performance issue will be critical -- even 5% slower really matters for VMs. But I hope btrfs can close this gap because the filesystem design is really nice. That was really my original point (that I didn't really state clearly I guess); btrfs performance with VM disk images should be compared against LVM VGs as well against ext4. -- 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
rawhide missed an implicit dependency for #!python
Hi, Our dtrace script in systemtap-sdt-devel starts #!/usr/bin/python. Usually this leads to an implicit Requires: /usr/bin/python, but for some reason our rawhide build did not get this. The F15, F14, and F13 builds from the same spec required python as expected. The rawhide build which missed the dependency: http://koji.fedoraproject.org/koji/buildinfo?buildID=244934 http://koji.fedoraproject.org/koji/rpminfo?rpmID=2556409 Compared to the F15 build which properly requires python: http://koji.fedoraproject.org/koji/buildinfo?buildID=244942 http://koji.fedoraproject.org/koji/rpminfo?rpmID=2556473 Is this a bug? Or must we now explicitly require python? Thanks, Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomboy orphaned
On Fri, Jun 3, 2011 at 1:15 AM, Aurimas Černius wrote: Gnote gives status icon 2 seconds to appear and shows Search All Notes window as main, if that fails. If you somehow delay the gnote start (wrap to some script for example) until desktop components like tray are available, it should start in a tray. When set to auto start on a session launch, users expect it to sit on the tray (without any wrappers needed) and not show the search all notes window. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide missed an implicit dependency for #!python
On Jun 2, 2011 9:26 PM, Josh Stone jist...@redhat.com wrote: Hi, Our dtrace script in systemtap-sdt-devel starts #!/usr/bin/python. Usually this leads to an implicit Requires: /usr/bin/python, but for some reason our rawhide build did not get this. The F15, F14, and F13 builds from the same spec required python as expected. The rawhide build which missed the dependency: http://koji.fedoraproject.org/koji/buildinfo?buildID=244934 http://koji.fedoraproject.org/koji/rpminfo?rpmID=2556409 Compared to the F15 build which properly requires python: http://koji.fedoraproject.org/koji/buildinfo?buildID=244942 http://koji.fedoraproject.org/koji/rpminfo?rpmID=2556473 Is this a bug? Or must we now explicitly require python? Is it set as executable? If not the department scan will ignore it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide missed an implicit dependency for #!python
On 06/02/2011 01:34 PM, Peter Robinson wrote: Is it set as executable? If not the department scan will ignore it. Yes, it is executable: http://koji.fedoraproject.org/koji/fileinfo?rpmID=2556409filename=/usr/bin/dtrace -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On 06/03/2011 12:47 AM, Bill Nottingham wrote: Moving it to default in @system-tools seems fine to me as a first step. However, that's not in the 'default' install (but it would place it on the install media.) If it's wanted in the default install, the @base group is the best place for it (it doesn't belong in @core.) systemd includes a bash-completion script for systmctl. Enabling bash completion by default would then benefit those making the transition to systemd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 09:11:47PM +0200, fkoo...@tuxed.net wrote: On Thu, Jun 2, 2011 at 5:40 PM, Richard W.M. Jones rjo...@redhat.com wrote: Is there an easy way I can set up IPv6 and a handful of machines on my LAN for testing, without requiring any IPv6 internet connection or an IPv6 assigned prefix? If you do want an assigned prefix, or real connectivity and not want to set up a (static) tunnel it may be possible to use 6to4 if your router is not behind NAT. See http://fedoraproject.org/wiki/IPv6Guide#Tunnel_Configuration. I did not test this myself (in Fedora), and 6to4 tends to be a bit flaky (in general) so ymmv. I was thinking about the lowest barrier to entry possible so that as many people can test Fedora IPv6 next week, even if they're only testing it on their LAN. Setting up 6to4 involves at least joining a service like sixxs, which even if free takes a certain amount of time and effort. I just turned on radvd, and now my Fedora machines are getting IPv6 addresses. By adding DNS entries for a few machines, it's choosing IPv6 protocol by default for many things including writing (if not sending) this email. 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
[Bug 541542] ocaml-cairo: cairo_ps_surface_set_dpi_REPLACED_BY_cairo_surface_set_fallback_resolution
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=541542 Orion Poplawski or...@cora.nwra.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||1:1.2.0-0.2.gita5c5ee9f.fc1 ||3 Resolution||CURRENTRELEASE Flag|needinfo?(rjo...@redhat.com | |) | Last Closed||2011-06-02 17:23:16 -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Installing bash-completion by default in F-16
On 2 Jun 2011 15:32, Michael Cronenworth m...@cchtml.com wrote: On 06/02/2011 09:07 AM, seth vidal wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. I believe it has to run stat or similar multiple times on every file. I can even notice it on my local hard disk with luks. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On 06/02/2011 04:11 PM, Richard W.M. Jones wrote: Setting up 6to4 involves at least joining a service like sixxs, which even if free takes a certain amount of time and effort. The method you quoted does not require an account with a tunnel provider. There is an RFC giving provisions for global IPv4 to IPv6 routers using the 2002 prefix. Sprint has some 6to4 routers spread around the USA. I'm using the 6to4 method (for several years now). The only requirement is that you must perform the setup on an Internet-connected router box, not on a workstation behind a router. The other method that you are thinking of hands out native IPv6 addresses. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 628655] perl segfaults when joining a thread and using perl-Tk
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=628655 rdv rdevries1...@gmail.com changed: What|Removed |Added Version|13 |14 Flag|needinfo?(rdevries1000@gmai | |l.com) | -- 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: Heads up: impending IPv6 Test Day
On Thu, Jun 02, 2011 at 04:53:25PM -0500, Michael Cronenworth wrote: On 06/02/2011 04:11 PM, Richard W.M. Jones wrote: Setting up 6to4 involves at least joining a service like sixxs, which even if free takes a certain amount of time and effort. The method you quoted does not require an account with a tunnel provider. There is an RFC giving provisions for global IPv4 to IPv6 routers using the 2002 prefix. Sprint has some 6to4 routers spread around the USA. I'm using the 6to4 method (for several years now). The only requirement is that you must perform the setup on an Internet-connected router box, not on a workstation behind a router. The other method that you are thinking of hands out native IPv6 addresses. Given that I mostly don't know about IPv6, what's the best way for people to test IPv6 next Wednesday, given what I think are the following common limitations: - they'll have one (or two if we're lucky) Fedora machines - they'll be using a private LAN behind a $40 router that doesn't know anything about IPv6 - they have very limited time and want to do the minimum work possible to set it up - they themselves know next to nothing about IPv6 ? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: patch only if dependent version x? (rpm spec)
Neal Becker wrote:
How can I apply a patch only if the version of a dependency is x?
I generally do something like:
%if 0%{?fedora} NN
%global have_foo_MMM 1
%endif
%if 0%{?have_foo_MMM}
BuildRequires: foo-devel = MMM
%else
BuildRequires: foo-devel MMM
%endif
…
%prep
%if 0%{?have_foo_MMM}
%patchPPP -p1 -b .fooMMM
%endif
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 710290] New: ocaml-findlib should require ocaml
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: ocaml-findlib should require ocaml https://bugzilla.redhat.com/show_bug.cgi?id=710290 Summary: ocaml-findlib should require ocaml Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: ocaml-findlib AssignedTo: rjo...@redhat.com ReportedBy: or...@cora.nwra.com QAContact: extras...@fedoraproject.org CC: rjo...@redhat.com, lxt...@gmail.com, fedora-ocaml-l...@redhat.com Classification: Fedora Story Points: --- Description of problem: # ocamlfind c -package cairo.lablgtk2 -linkpkg test_gtk.ml -o test_gtk ocamlfind: /usr/lib/ocaml/ld.conf: No such file or directory # repoquery --whatprovides /usr/lib/ocaml/ld.conf ocaml-0:3.12.0-5.fc15.i686 # rpm -q ocaml package ocaml is not installed Version-Release number of selected component (if applicable): ocaml-findlib-1.2.6-2.fc15.i686 -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Heads up: impending IPv6 Test Day
On 06/02/2011 05:02 PM, Richard W.M. Jones wrote: Given that I mostly don't know about IPv6, what's the best way for people to test IPv6 next Wednesday, given what I think are the following common limitations: - they'll have one (or two if we're lucky) Fedora machines They could connect their Internet modem directly to their Fedora machine. - they'll be using a private LAN behind a $40 router that doesn't know anything about IPv6 If they're lucky enough to have a DD-WRT (or OpenWRT) supported router, they could flash the firmware to those distributions and use the 6to4 method. DD-WRT has a web-based tool to do the configure work. - they have very limited time and want to do the minimum work possible to set it up Unfortunately, if their ISP doesn't provide IPv6, there is not an easy method in Fedora. You either setup a local 6to4 tunnel or create an account with a tunneling provider. - they themselves know next to nothing about IPv6 The 6to4 method is simple to implement. You just have to have the correct hardware configuration. No specific IPv6 knowledge is required beyond following some directions. There is another method for tunneling, which Microsoft Windows uses, that involves UPnP (to forward an IPv4 port on the local router). It is called Teredo[1]. Most dumb $40 routers support UPnP by default so Fedora could add Teredo support and provide easy-to-use (default?) IPv6 access. [1] http://en.wikipedia.org/wiki/Teredo_tunneling -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
I think we're talking at cross-purposes here. I want people to be able to test IPv6 *on their local LAN only* next Wednesday with the minimum amount of fuss. They can just test that it works between two machines, one Fedora, one might be Fedora or it might be something else like Windows acting as a client. This should be sufficient to test a variety of common services: HTTP, NFS, SMB, DNS and that sort of thing. I don't want to be guiding people through flashing their routers ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Guidance on hulahop epoch usage
Jeremy pinged me about an issue with the hulahop package (#574484). Disclaimer: I'm not the maintainer of the package but Simon has been a bit quiet on this bug. I was opened for F12 over a year ago. hulahop had it's Epoch bumped on the F-10 branch to hulahop-1:0.4.6-5.fc10 (commit 3c3f6d12edb) to undo 0.4.7 update. That epoch bump was limited to F-10, no other branches saw it afaict. So anyone who ever installed the F-10 package is stuck with it. Anyone else is still fine. Yum on my box claims the version available on f15 is indeed the 0.7.1 currently in the repos (I never had the F-10 package installed). What's the correct thing to do here? Just bump the Epoch again and get on with life? Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, 3 Jun 2011 08:51:55 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: hulahop had it's Epoch bumped on the F-10 branch to hulahop-1:0.4.6-5.fc10 (commit 3c3f6d12edb) to undo 0.4.7 update. That epoch bump was limited to F-10, no other branches saw it afaict. So anyone who ever installed the F-10 package is stuck with it. Anyone else is still fine. Yum on my box claims the version available on f15 is indeed the 0.7.1 currently in the repos (I never had the F-10 package installed). What's the correct thing to do here? Just bump the Epoch again and get on with life? Yes, the correct way to fix this would be to set Epoch: 1 in the current spec file. That way version 0.7.1 would be allowed to update the 0.4.7 with Epoch 1. However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, Jun 03, 2011 at 02:21:14AM +0300, Jussi Lehtola wrote: On Fri, 3 Jun 2011 08:51:55 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: hulahop had it's Epoch bumped on the F-10 branch to hulahop-1:0.4.6-5.fc10 (commit 3c3f6d12edb) to undo 0.4.7 update. That epoch bump was limited to F-10, no other branches saw it afaict. So anyone who ever installed the F-10 package is stuck with it. Anyone else is still fine. Yum on my box claims the version available on f15 is indeed the 0.7.1 currently in the repos (I never had the F-10 package installed). What's the correct thing to do here? Just bump the Epoch again and get on with life? Yes, the correct way to fix this would be to set Epoch: 1 in the current spec file. That way version 0.7.1 would be allowed to update the 0.4.7 with Epoch 1. However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. true, but anyone who would have had hulahop installed at F-10 time and did the (guaranteed) update to F11, F12, ... F15 at the right times would still have this issue now, right? tbh, it seems to be corner case enough to just say uninstall and re-install but nonetheless... Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, 3 Jun 2011 09:39:13 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Jun 03, 2011 at 02:21:14AM +0300, Jussi Lehtola wrote: However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. true, but anyone who would have had hulahop installed at F-10 time and did the (guaranteed) update to F11, F12, ... F15 at the right times would still have this issue now, right? tbh, it seems to be corner case enough to just say uninstall and re-install but nonetheless... Yes. It's just a bit hard to believe that there would be still a lot of systems suffering from this, since yum would have complained about the problem on every update, and you haven't had a single bug report about the issue in a time period of more than two years..? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
On 06/02/2011 05:29 PM, Richard W.M. Jones wrote: I think we're talking at cross-purposes here. I want people to be able to test IPv6*on their local LAN only* next Wednesday with the minimum amount of fuss. In that case: Since Fedora defaults to link-local, they would have to run radvd locally just like you had to, run a DHCPv6 server, or assign IPv6 addresses manually in NetworkManager. My suggestion would be to set IPs manually. (fd00:1:2:3::1, fd00:1:2:3::2, etc) I don't want to be guiding people through flashing their routers ... Aw, you're no fun. :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, Jun 03, 2011 at 03:12:39AM +0300, Jussi Lehtola wrote: On Fri, 3 Jun 2011 09:39:13 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Jun 03, 2011 at 02:21:14AM +0300, Jussi Lehtola wrote: However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. true, but anyone who would have had hulahop installed at F-10 time and did the (guaranteed) update to F11, F12, ... F15 at the right times would still have this issue now, right? tbh, it seems to be corner case enough to just say uninstall and re-install but nonetheless... Yes. It's just a bit hard to believe that there would be still a lot of systems suffering from this, since yum would have complained about the problem on every update, and you haven't had a single bug report about the issue in a time period of more than two years..? As stated in the first email, there is a bug: https://bugzilla.redhat.com/show_bug.cgi?id=574484 People (well, at least one person) first complained about it Mach 2010 - no one listened (or did anything about it). Anyway, I'll tell Jeremy he'll need to manually remove/update. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi there! Could someone please review these tickets? I'll be happy to review their tickets in return :) [1] FreeMedForms - An open Electronic Medical Record Manager https://bugzilla.redhat.com/show_bug.cgi?id=707002 [2] dcm4che - A DICOM implementation in Java https://bugzilla.redhat.com/show_bug.cgi?id=710212 This third package has a minor issue. It bundles quazip. Is there a qmake user here who could please tell me how to make the build process point to fedora's version of qmake instead of the bundled one? [3] freediams - Pharmaceutical Drugs Prescriptor https://bugzilla.redhat.com/show_bug.cgi?id=705104 These are packages related to the Fedora Medical SIG[4] http://fedoraproject.org/wiki/SIGs/FedoraMedical Thanks! Regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 613872] Request for support in EPEL
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=613872 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2011-06-02 02:47:28 EDT --- perl-Chart-2.4.2-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Chart-2.4.2-1.el5 -- 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 613872] Request for support in EPEL
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=613872 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-06-02 02:47:35 EDT --- perl-Chart-2.4.2-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Chart-2.4.2-3.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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 613872] Request for support in EPEL
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=613872 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||p...@city-fan.org Component|perl-Chart |perl-Chart Version|13 |el5 Product|Fedora |Fedora EPEL Flag|needinfo?(fulko.hew@gmail.c | |om) | -- 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 709697] Please upgrade to MailTools 2.08
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=709697 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MailTools-2.08-1.fc16 Resolution||RAWHIDE Last Closed||2011-06-02 02:52:26 -- 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
File ORLite-1.49.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-ORLite: 92ee3dc784d13a1b6d612b43b047c49e ORLite-1.49.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
