Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, Oct 22, 2009 at 14:18:23 -0700, Adam Williamson awill...@redhat.com wrote: Two, it makes testing things a bit more complex. Those of us who like to test upcoming stuff in real use - i.e. on our main machines - will have to choose whether to test rawhide, in which case we'll have more pain to deal with ourselves and won't be contributing as much to testing of the next stable release, or test the next stable release, in which case we aren't helping maintainers by making sure the stuff they're putting in rawhide isn't totally broken. The impression I got (which might be wrong), is that it was expected that people would test specific packages from rawhide and not be expected to be running it all at once. Porbably the best equvialent to current rawhide would be enabling updates-testing for the pending release. People that needed some that wouldn't break unexpectedly, but still wanted to try out the new stuff could run the pending release without updates-testing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
Dne 23.10.2009 02:18, Adam Miller napsal(a): I think this is an awesome idea, and yes I think this version of the verbage is more clear. Kudos to Jesse (and all those involved in the development of the idea of the split rawhide) and I hope to see this come to fruition. Just wanted to add my +1 and this is as good place as any other. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Experience is what you get when you don't get what you want. -- Dan Stanford -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Dne 22.10.2009 19:28, King InuYasha napsal(a): I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries Wandering minds ask what is it good for? I hoped that with Snow Leopard being intel-only Apple Universal Binaries will finally wither to bad memories of past (somewhere around the Berlin Wall and Third Reich :)), and that whole concept of multilib will follow in due course after them. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Pain is inevitable, but misery is optional. We cannot avoid pain, but we can avoid joy. -- Tim Hansel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
Dne 23.10.2009 01:19, Jesse Keating napsal(a): Many people aren't willing to jump through the hoops necessary to manage that separation. And there is surely nothing wrong with giving a little bit of PR to our dear employer :). Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC This conversation can serve no purpose anymore. Good bye. -- HAL9000 in 2001: Space Odyssea -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 22 Oct 2009 14:20:13 -0700, Jesse Keating jkeat...@redhat.com wrote: I wonder where your confusion comes from. With this rewording of the proposal, the proposal doesn't change. [] So you can continue to run rawhide all you want. Your entry point to rawhide may change slightly, you may have to start with the current Fedora release or the current testing release for the next Fedora, and then upgrade to the rawhide package set, but once you've done that you just stick on rawhide and never look back. That works for me, thanks a lot. -- Pete -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
Hi, On Fri, 2009-10-23 at 09:32 +0200, Matěj Cepl wrote: Dne 23.10.2009 01:19, Jesse Keating napsal(a): Many people aren't willing to jump through the hoops necessary to manage that separation. And there is surely nothing wrong with giving a little bit of PR to our dear employer :). Matěj Indeed, I think thats a good plan. Also, as a suggestion of a suitable way to deal with this issue, the simplest solution would be to have a word with someone in HC and ask them to add to their standard list of questions for those leaving the company. They can then pass on the information regarding who wants to continue or give up their fedora maintainerships at that point in time. It would also serve as a reminder to those involved to change the email address to which their FAS account is attached before they lose the ability to access it. Does that sound like a reasonable solution? Steve. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
Hi Jiri, On Thu, Oct 22, 2009 at 08:46:29PM +0200, Jiri Cerny wrote: Hi Jindrich, (sorry for not replaying to the original message, I was reading the list through archives) I was using TeXLive 2009 repository before, without any problem. After seeing your message, I followed the instruction In case you have an older TL2009 installed on your system from the testing repository, please consider removing it and installing again. and after 'yum install texlive' I get a lot of missing dependencies. This is likely caused by the not up-to-date yum cache, please clean it with yum clean all and try again. Installing texlive requires dvipdfm from the F12/rawhide repository, which requires kpathsea from the same repository and which in turn requires texlive-2007. Will it be fixed with texlive-2007-45 build? Yes, it is fixed since texlive-2007-45 and on. Just upgrading the kpathsea library itself to 2007-45 should suffice in most cases. You can use packages from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=137908 directly or by installing the new kpathsea via yum from updates-testing. (You needn't to install the main TL2007 packages) Another, probably related issue: Why there is not a xdvi (and also dvipdfm) binary in the Texlive 2009 repository. Should one use the one from F12? This seems strange to me to have such mixture of 2007 and 2009 versions. It is intentional, because you can now use old applications (not yet rebuilt against new kpathsea) together with TL2009. Up to now you needed to remove all applications dependent on kpathsea because of its dependency on TL2007 which is removed now. Jiri Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091023 changes
Compose started at Fri Oct 23 06:15:16 UTC 2009 Broken deps for i386 -- openscada-visStation-0.6.4-3.fc12.i686 requires openscada-Special-FlibSYS Broken deps for x86_64 -- openscada-visStation-0.6.4-3.fc12.x86_64 requires openscada-Special-FlibSYS Broken deps for ppc64 -- python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot New package cvc3 Validity checker of many-sorted first-order formulas with theories New package django-flash A Django extension to provide support for Rails-like flash New package django-typepad A helper Django app for making TypePad applications New package evolution-couchdb An evolution backend to CouchDBs for PIM information New package mingw32-freeglut Fedora MinGW alternative to the OpenGL Utility Toolkit (GLUT) New package python-batchhttp Parallel fetching of HTTP resources through MIME multipart New package python-oauth Library for OAuth version 1.0a New package python-remoteobjects An Object RESTational Model New package python-tg-devtools Development tools and templates for TurboGears2 New package python-typepad Connectivity to the TypePad API through remote objects New package typepad-motion A microblogging application for building online communities Updated Packages: blazeblogger-1.0.0-1.fc12 - * Wed Oct 21 2009 Sebastian Dziallas sebast...@when.com 1.0.0-1 - update to new upstream release evince-2.28.1-3.fc12 * Thu Oct 22 2009 Matthias Clasen mcla...@redhat.com - 2.28.1-2 - Provide some hint if search is not available * Thu Oct 22 2009 Marek Kasik mka...@redhat.com - 2.28.1-3 - Add evince-thumbnail-allocation.patch (checks whether - GdkPixbuf was allocated correctly) f-spot-0.6.1.3-1.fc12 - * Sun Oct 04 2009 Christian Krause c...@fedoraproject.org - 0.6.1.3-1 - Update to 0.6.1.3 (BZ 526217) - Remove two upstreamed patches - Use a slightly different fix for the cairo-devel dependency (suggested by upstream) * Wed Sep 30 2009 Christian Krause c...@fedoraproject.org - 0.6.1.2-3 - Add patch to fix f-spot crash when using soft focus and cairo-devel was not installed (BZ 526563) - Minor spec file beautification febootstrap-2.5-2.fc12 -- * Thu Oct 22 2009 Richard Jones rjo...@redhat.com - 2.5-2 - New upstream release 2.5. - Remove BR upx (not needed by upstream). - Two more scripts / manpages. gstreamer-plugins-flumpegdemux-0.10.15-8.fc12 - * Thu Oct 22 2009 Bastien Nocera bnoc...@redhat.com 0.10.15-8 - Update code from gst-plugins-bad gstreamer-plugins-good-0.10.16-5.fc12 - * Thu Oct 22 2009 Bastien Nocera bnoc...@redhat.com 0.10.16-5 - Update farsight plugins from -bad - Drop copy/pasted rtpmanager plugin, it's now in -good gtk2-2.18.3-8.fc12 -- * Thu Oct 22 2009 Peter Hutterer peter.hutte...@redhat.com - 2.18.3-8 - compose-sequences.patch: update compose sequences to what's currently in libX11 git. kdelibs-4.3.2-4.fc12 * Mon Oct 12 2009 Lukáš Tinkl lti...@redhat.com - 4.3.2-4 - khtml kpart crasher nr. 2 (rev.1033984) parole-0.1.90-3.fc12 python-tw-forms-0.9.8-1.fc12 * Thu Oct 01 2009 Luke Macken lmac...@redhat.com - 0.9.8-1 - 0.9.8 * Wed Aug 12 2009 Luke Macken lmac...@redhat.com - 0.9.7.2-1 - 0.9.7.2 roundcubemail-0.3-2.fc12 * Thu Oct 22 2009 Jon Ciesla l...@jcomserv.net = 0.3-2 - Macro fix, BZ530037. smolt-1.4-4.fc12 * Tue Oct 13 2009 Mike McGrath mmcgr...@redhat.com 1.4-4 - Fixing firstboot for F-12 sugar-0.86.3-1.fc12 --- * Wed Oct 21 2009 Sebastian Dziallas sebast...@when.com - 0.86.3-1 - Sporadic freezes while scrolling journal #1506 - Suppress race condition with Journal appearing on sugar startup #1373 - Alt+Space not working to show/hide the tray #1476 sugar-toolkit-0.86.2-1.fc12 --- * Wed Oct 21 2009 Sebastian Dziallas sebast...@when.com - 0.86.2-1 - Do not stop processing motion-notify-event #1507 telepathy-gabble-0.8.7-1.fc12 - * Wed Oct 14 2009 Brian Pepple bpep...@fedoraproject.org - 0.8.7-1 - Update to 0.8.7. * Fri Oct 09 2009 Brian Pepple bpep...@fedoraproject.org - 0.8.6-1 - Update to 0.8.6. virtaal-0.4.1-1.fc12 * Fri Oct 16 2009 Dwayne Bailey dwa...@translate.org.za - 0.4.1-1 - Update to 0.4.1 - New translations: Turkish, Finnish, Vietnamese - Updated translations: Russian, Dutch and Zulu - More complete handling of recent files (bug 1120) - Better alignment with the GNOME human interface guidelines (bug 1095) - More reliable
Re: Fedora 12 Beta
On 10/21/2009 11:49 PM, Michał Piotrowski wrote: 2009/10/21 Adam Williamsonawill...@redhat.com: On Wed, 2009-10-21 at 12:31 +0200, Michał Piotrowski wrote: I guess this is a plymouth bug. I disabled it in grub conf and system works correctly. Is there any chance to completely remove plymouth from the system? (even from initrd) From a quick look, we don't have a bug filed for the fact that entering the root password at this point doesn't work with Plymouth. Could you please file one with a full description, and mark it as blocking F12Blocker? Thanks. Here is a bug report https://bugzilla.redhat.com/show_bug.cgi?id=530224 I don't know how to mark it as a blocker. 4 - F12 boots really slow on my laptop http://www.stardust.webpages.pl/files/tmp/bootchart.png something wrong is happening while udev loading Please file a bug for this, on 'udev' component for now, and CC Harald Hoyer (hhoyer at redhat). Thanks! Note that on my Thinkpad R52 Laptop F11 started doing this after a udev RPM update. It turned out to be the fact that there was no floppy drive in my system but the BIOS was configured with one enabled. I suspect this is default in some laptops so that docking stations etc work ?? I think this bug is in Bugzilla, but I suspect it has not been fixed ... Done https://bugzilla.redhat.com/show_bug.cgi?id=530226 5 - default gnome sound scheme is terrible This is a pretty subjective topic. Yes, I know :) Regards, Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Action Tags concept for Fedora PkgDB
Hi, I am working on online application database which is becoming part of Fedora PkgDB. Online Application Database was separate project called Amber in the past, but as there had been similar features developed in the Fedora PkgDB, we decided to merge our efforts. In Amber definition there is suggested different concept of apps organization. I like the rasoning there and would like to implement it in pkgdb. I'd like to know your opinion on this. In Online Application Database definition, there are defined two primary use cases I am trying to address: 1/ I want to do 'X' with my computer. Where 'X' might be quite complex task like 'Import videos from my camera and put them on YouTube' 2/ I can already do 'X' with my computer, but maybe I can do it better with different software. There are also some suggestions how to achieve this there. For more information look at Amber definition - https://fedorahosted.org/amber/wiki/Definition. I followed some of the suggestions and this is how I would like to implement it in Fedora PkgDB: Task - - Task is container that will allow us to break complex task into more 'atomic' parts. This should allow us to create toolsets needed for completition of complex tasks. - Task consits of one or more Actions. - Actions shall be added by creating new Action or by choosing from the list of the existing ones. - Task shall be defined by pkgdb users . Example: Task: Import videos from my camera and put them on YouTube Actions: [Capture video, Edit video, Encode video, Upload video to YouTube] Action - Action is atomic task - Action shall be defined by PkgDB user either as part of Task definition process or as standalone entity. - Actions should be used instead of current tags. (I believe replacing current tags would help to avoid confusion from two kinds of tags.) Application tagging --- There is not much difference against current tagging system. Users shall be tempted to input verbs instead of nouns: I use this application to and give it * stars. Input box shall feature AJAX search for existing actions to reduce duplication. User ratings (http://mbacovsk.fedorapeople.org/Amber/mockups/Fedora_app_page.png) shall be updated accordingly. Note: I am thinking of keeping categories imported from .desktop file as read only information Search - Both Tasks and Actions shall be included among other targets for search (app names, descriptions, comments, etc) Does it make sense? Do you think it would be acceptable/ understandable for common users?. Any comments and ideas will be appreciated. Regards, Martin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
On F11 I get: kpathsea-2007-42.fc11.x86_64 from installed has depsolving problems -- Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) Error: Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
On Fri, 2009-10-23 at 10:31 -0400, Neal Becker wrote: On F11 I get: kpathsea-2007-42.fc11.x86_64 from installed has depsolving problems -- Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) Error: Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) First, you need to enable enable the updates-testing repository. Then, you need to wait until the new kpathsea package hits the updates-testing repository: https://admin.fedoraproject.org/updates/texlive-2007-46.fc11 Or, you can fetch the new build of kpathsea manually from http://koji.fedoraproject.org/koji/buildinfo?buildID=137909 -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
orphaning (eol) gtk-qt-engine
This is to announce my intentions to orphan (and hopefully eol) gtk-qt- engine in fedora. For F-12+, my plan is to allow the new kcm-gtk package to Obsoletes it. It will provide a systemsettings/kcm module to configure gtk theming, but without the problematic Qt gtk engine. See also: https://bugzilla.redhat.com/show_bug.cgi?id=kcm-gtk -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Survey - May 2009
Rahul Sundaram wrote: On 10/23/2009 09:19 AM, Gerry Reno wrote: Did eucalyptus ever get packaged for F12 ? I didn't find anything in rawhide today when I checked it. Nobody volunteered yet. Rahul I see on the eucalyptus site that they now have rpms available for CentOS 5.3. Maybe that would make it easier now to create packages for Fedora. http://open.eucalyptus.com/downloads -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Action Tags concept
On Fri, Oct 23, 2009 at 04:46:36PM +0200, Martin Bacovsky wrote: On Thursday 22 October 2009 16:33:06 you wrote: I like this concept. How does it relate to tagging? * As a replacement for tagging * As a separate feature from tagging * In addition to tagging where some output utilizes both tags and actions I was thinking of replacing current tags, because I'm affraid users will be confused by two kinds of tags. On the other hand I would keep categories imported from .desktop files (readonly/searchonly). So I think we might be committed to having freeform tags for its use as a comps replacement and grouping mechanism. I'm not 100% sure though. There is overlap:: python-openssl tags: python, module, ssl, encryption, hashing, binding, MIT Tasks: Use this to write programs in python that can communicate with network services over SSL Use this to write python programs that encrypt, decrypt, and hash data. Actions: python programming, network programming, encryption programming?, decryption programming? hash programming? So there's some things that aren't captured (for instance that this is licensed MIT (which may not be an issue, we can grab that from the license tag) and that this is a binding (which I don't see how to capture in an action). There's also some things that I wonder about a bit -- hash programming and encryption progamming are awkward phrases -- makes me wonder if that's trying to shoehorn a concept into the wrong tool. How will user's know to find the action encryption programming, hash programming, python programming? How will we compose the actions into tasks? Also, how do we get the users to only enter actions(verbs) and not nouns when supplying new actions for a package? -Toshio pgpvtwXv63Ht2.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Survey - May 2009
Gerry Reno wrote: Rahul Sundaram wrote: On 10/23/2009 09:19 AM, Gerry Reno wrote: Did eucalyptus ever get packaged for F12 ? I didn't find anything in rawhide today when I checked it. Nobody volunteered yet. Rahul I see on the eucalyptus site that they now have rpms available for CentOS 5.3. Maybe that would make it easier now to create packages for Fedora. http://open.eucalyptus.com/downloads Oops. I take that back. There are rpms in the download lists for other Linux versions but looks like only .tar.gz for CentOS. Anyway, I trying to install eucalyptus on Fedora 11 and here is what I think the prerequisites are when installing all controllers on one node: yum install java-1.6.0-openjdk-devel ant ant-nodeps libvirt libvirt-devel curl libcurl-devel httpd httpd-devel apr apr-devel openssl openssl-devel dhcp m2crypto I'll see if I can get it installed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Survey - May 2009
On 10/23/2009 10:08 AM, Gerry Reno wrote: Oops. I take that back. There are rpms in the download lists for other Linux versions but looks like only .tar.gz for CentOS. Anyway, I trying to install eucalyptus on Fedora 11 and here is what I think the prerequisites are when installing all controllers on one node: yum install java-1.6.0-openjdk-devel ant ant-nodeps libvirt libvirt-devel curl libcurl-devel httpd httpd-devel apr apr-devel openssl openssl-devel dhcp m2crypto I'll see if I can get it installed. Looks like building from source may use customized versions of axis2/c rampart/c and libvirt. Doesn't look like axis2/c or rampart/c are in Fedora. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the mass rebuild and i586 rpms?
On 22.10.2009 03:39, Kevin Kofler wrote: Milos Jakubicek wrote: Most probably those are the packages which failed during the mass rebuild...there are still plenty of them: http://mjakubicek.fedorapeople.org/need-rebuild.html That list is out of date. I fixed clutter-gtkmm to build a while ago because it had broken dependencies, and the fixed build got tagged into dist-f12 already (and dist-f13 inherits it from there too). Strange, I added dist-f12-updates-candidate (instead of dist-f12-openssl) to the list and the package got off the list... Milos -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, 22 Oct 2009 19:28:36 +0200, King InuYasha wrote:
I just saw this article about an effort to create Universal binary style ELF
binaries for Linux, and I thought that this would be something to watch, so
that Fedora could integrate both x86-32 and x86-64 into single DVD sets.
While I do not find useful fat-elf I did post an implementation of auto-biarch
Fedora LiveDVD but it was ignored. Still keep it around personally myself.
Attached the post, former followups to it at:
https://www.redhat.com/archives/fedora-livecd-list/2009-June/msg00018.html
Regards,
Jan
---BeginMessage---
Hi,
finally created a LiveDVD ISO automatically booting x86_64 OS on x86_64
(and i686 otherwise). Regular users will not notice there exists any new arch
while they will benefit from the full performance of their PC:
http://people.redhat.com/jkratoch/x86bilive-2009062000.tar.gz (71KB)
It uses live_dir=LiveOS-x86_64 vs. live_dir=LiveOS-i686 to boot the image.
The syslinux patch provides default-{x86_64,i386} keywords in isolinux.cfg.
livecd-iso-to-disk is not patched/compatible with such image.
livecd-creator should create such ISO on a single run, not by merging the
output of two livecd-creator runs by a 3rd party app.
Regards,
Jan
Reasons:
* I still did not understand why I have to carry with me two media - both
x86_64 and i386 - when all the data perfectly fit on a single media.
* Why I have to try to boot x86_64 first to find out if the specific machine
is x86_64? Even common programmers do not know it, Windows XP works here.
* The OS must just work, it must be fun and easy. Requiring a special
technical decision before even starting the OS download is a showstopper.
* Checked that a regular user will on http://fedoraproject.org/get-fedora
still download terrible performance degradation of 32-bit OS although her
hadware is in 70%-95%(?) of cases x86_64. x86_64 is here for 6 years now.
* Arguing x86 may be faster than x86_64... I did not find any such case,
x86_64 is a more modern arch (more registers, PIC for free, better ABI).
We already hit the 2GB address space limitations. x86_64 is the future.
* All the friends of mine have 8Mbit+ ADSL and TB disks downloading many DVD
disks so some several more hundreds of MB are not something to notice.
mkisofs -f -J -r -hide-rr-moved -hide-joliet-trans-tbl -V Fedora-11-x86bi-Live
-o ../x86bilive.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot
-boot-info-table -boot-load-size 4 .
mount -r -o loop Fedora-11-x86_64-Live.iso x86_64/
mount -r -o loop Fedora-11-i686-Live.iso i686/
x86bilive:
total 4
lrwxrwxrwx 1 root root 13 2009-06-18 21:10 GPL - ../x86_64/GPL
lrwxrwxrwx 1 root root 14 2009-06-18 21:11 LiveOS-i686 - ../i686/LiveOS/
lrwxrwxrwx 1 root root 16 2009-06-18 21:10 LiveOS-x86_64 - ../x86_64/LiveOS/
lrwxrwxrwx 1 root root 16 2009-06-18 21:10 README - ../x86_64/README
drwxr-xr-x 2 root root 4096 2009-06-20 21:44 isolinux/
x86bilive/isolinux:
total 184
lrwxrwxrwx 1 root root 30 2009-06-18 21:13 boot.cat -
../../x86_64/isolinux/boot.cat
lrwxrwxrwx 1 root root 31 2009-06-18 21:17 ii686 -
../../i686/isolinux/initrd0.img
-rw-r--r-- 1 root root 14336 2009-06-20 21:45 isolinux.bin
-r--r--r-- 1 root root 1411 2009-06-20 21:44 isolinux.cfg
lrwxrwxrwx 1 root root 33 2009-06-18 21:13 ix8664 -
../../x86_64/isolinux/initrd0.img
lrwxrwxrwx 1 root root 28 2009-06-18 21:17 ki686 -
../../i686/isolinux/vmlinuz0
lrwxrwxrwx 1 root root 30 2009-06-18 21:13 kx8664 -
../../x86_64/isolinux/vmlinuz0
lrwxrwxrwx 1 root root 29 2009-06-18 21:13 memtest -
../../x86_64/isolinux/memtest
lrwxrwxrwx 1 root root 32 2009-06-18 21:13 splash.jpg -
../../x86_64/isolinux/splash.jpg
-r--r--r-- 1 root root 159888 2009-06-20 20:48 vesamenu.c32
isolinux.cfg:
default vesamenu.c32
timeout 100
menu background splash.jpg
menu title Welcome to Fedora-11-x86bi-Live!
menu color border 0 # #
menu color sel 7 # #ff00
menu color title 0 # #
menu color tabmsg 0 # #
menu color unsel 0 # #
menu color hotsel 0 #ff00 #
menu color hotkey 7 # #ff00
menu color timeout_msg 0 # #
menu color timeout 0 # #
menu color cmdline 0 # #
menu hidden
menu hiddenrow 5
label linux0
menu label x86_64 Boot
kernel kx8664
append initrd=ix8664 root=CDLABEL=Fedora-11-x86bi-Live rootfstype=auto
live_dir=LiveOS-x86_64 ro liveimg quiet rhgb
menu default-x86_64
label check0
menu label x86_64 Verify and Boot
kernel kx8664
append initrd=ix8664 root=CDLABEL=Fedora-11-x86bi-Live rootfstype=auto
live_dir=LiveOS-x86_64 ro liveimg quiet rhgb check
label linux1
menu label i686 Boot
kernel ki686
append initrd=ii686 root=CDLABEL=Fedora-11-x86bi-Live rootfstype=auto
live_dir=LiveOS-i686 ro liveimg quiet rhgb
menu default-i386
label check1
menu label i686 Verify and Boot
kernel
Re: Packaging Survey - May 2009
Orion Poplawski wrote: On 10/23/2009 10:08 AM, Gerry Reno wrote: Oops. I take that back. There are rpms in the download lists for other Linux versions but looks like only .tar.gz for CentOS. Anyway, I trying to install eucalyptus on Fedora 11 and here is what I think the prerequisites are when installing all controllers on one node: yum install java-1.6.0-openjdk-devel ant ant-nodeps libvirt libvirt-devel curl libcurl-devel httpd httpd-devel apr apr-devel openssl openssl-devel dhcp m2crypto I'll see if I can get it installed. Looks like building from source may use customized versions of axis2/c rampart/c and libvirt. Doesn't look like axis2/c or rampart/c are in Fedora. Ok, there are rpms for CentOS 5.3. They packaged them inside the .tar.gz download file. In the deps directory there are rpms for axis2 and rampart. I don't see any srpms yet. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Rex Dieter wrote: For F-12+, my plan is to allow the new kcm-gtk package to... provide a systemsettings/kcm module to configure gtk theming When will it be available, even as a testing rpm? I looked in koji and it is not there and yum knows nothing about it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 20091023
=== #fedora-meeting: FESCo meeting 20091023 === Meeting started by jds2001 at 17:00:33 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-10-23/fedora-meeting.2009-10-23-17.00.log.html . Meeting summary --- * Documentation (jds2001, 17:03:23) * AGREED: when a policy decision is made not applicable to FPC, then the meeting chair will change the keyword of the ticket from meeting to writeup, and assign it to a specific person (jds2001, 17:13:17) * open floor (jds2001, 17:13:32) * there's a beta. it has blocker bugs. fesco encourages people to fix them. (jds2001, 17:14:58) * AGREED: non-trivial wallpaper changes after Tuesday will be rejected. The KDE SIG will work with that schedule (jds2001, 18:46:31) Meeting ended at 18:47:22 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mizmo (110) * Kevin_Kofler (97) * jds2001 (72) * skvidal (44) * notting (44) * mccann (24) * dgilmore (15) * halfline (14) * stickster (11) * j-rod (10) * Oxf13 (10) * sharkcz (6) * rdieter (5) * zodbot (4) * Southern_Gentlem (2) * drago01 (2) * nirik (0) * dwmw2 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Petrus de Calguarium wrote: Rex Dieter wrote: For F-12+, my plan is to allow the new kcm-gtk package to... provide a systemsettings/kcm module to configure gtk theming When will it be available, even as a testing rpm? I looked in koji and it is not there and yum knows nothing about it. pending cvsadmin processing, will get it imported and built properly, asap. In the meantime, there's a scratch build: (from the review): http://koji.fedoraproject.org/koji/taskinfo?taskID=1762877 -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Rex Dieter wrote: there's a scratch build Vielen Dank!!! I will give it a try. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating jkeat...@redhat.com wrote: Rawhide as we know it, /pub/fedora/linux/releases/development/ will remain rawhide. We may even change the path to say rawhide, just to catch things up and well I like keeping mirrors on their toes. Rawhide will be a repository of developmental and experimental packages. Things being worked on for the future. It will /not/ be an installable tree, rather it will just be a repository of packages, to be added on to an already stable base, eg you'd install F12, and enable rawhide to test rawhide. This will significantly lower the complaints that rawhide isn't installable. So as I understand it there are a number of reasons why rawhide might not be installable, but broadly they fall into two major categories: * Anaconda * Critpath packages - Dependency/rebuild issues - Bugs in %posts (like the user/group one we ran into with dbus) - Core bugs (graphics drivers) It seems like we're basically just skipping Anaconda, since you won't be able to yum if there are depsolving issues (ok, modulo --skip-broken), and for the latter two you don't end up with a working system. Let me do a counter-proposal: We simply do not let showstopper regressions in the critpath stay in rawhide. If something in critpath has a showstopper, it halts all further commits to the entire critpath until it's resolved (either fixed, or reverted). The definition of showstopper might be AutoQA fails. And since AutoQA will have been doing some basic smoketesting of the installer, we have to be producing installer images as a side effect. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Fri, 2009-10-23 at 20:56 +, Colin Walters wrote: On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating jkeat...@redhat.com wrote: Rawhide as we know it, /pub/fedora/linux/releases/development/ will remain rawhide. We may even change the path to say rawhide, just to catch things up and well I like keeping mirrors on their toes. Rawhide will be a repository of developmental and experimental packages. Things being worked on for the future. It will /not/ be an installable tree, rather it will just be a repository of packages, to be added on to an already stable base, eg you'd install F12, and enable rawhide to test rawhide. This will significantly lower the complaints that rawhide isn't installable. So as I understand it there are a number of reasons why rawhide might not be installable, but broadly they fall into two major categories: * Anaconda * Critpath packages - Dependency/rebuild issues - Bugs in %posts (like the user/group one we ran into with dbus) - Core bugs (graphics drivers) It seems like we're basically just skipping Anaconda, since you won't be able to yum if there are depsolving issues (ok, modulo --skip-broken), and for the latter two you don't end up with a working system. Let me do a counter-proposal: We simply do not let showstopper regressions in the critpath stay in rawhide. If something in critpath has a showstopper, it halts all further commits to the entire critpath until it's resolved (either fixed, or reverted). The definition of showstopper might be AutoQA fails. And since AutoQA will have been doing some basic smoketesting of the installer, we have to be producing installer images as a side effect. I... don't see how this helps, other than piss off the rest of the crit-path maintainers while one thing is broken. AutoQA will be running at some point, and it can be doing the qa /before/ things get tagged for rawhide, so if you break deps with your build, it doesn't get in, unless you force it and then you face the wrath of releng/qa. To catch core bugs, we'll need a bit more advanced autoqa, doing more than just repo level testing but doing actual package testing. That will grow over time and again can be done pre-tag. Your counter proposal also does nothing to help the dual or sometimes triple role we try to put on rawhide the path. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Fri, 2009-10-23 at 21:15 +, Colin Walters wrote: Oh, I didn't realize there would be a distinction between built in koji and rawhide now. If that's the case, than this sounds fine to me! The point is basically that we need some sort of stable, defined baseline for what you get when you try to install rawhide. Testing before tagging sounds good. Yeah, there are multiple prongs to our attack to make Fedora development better. In this thread I was mostly talking about what types of changes go into the repos and which repos get produced each night. Autoqa has other plans to help, one of which being testing before tagging. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the mass rebuild and i586 rpms?
OK, I took the 3 hours today and went through the packages which have not been submitted at all for building: On 22.10.2009 19:29, Quentin Armitage wrote: Not submitted for rebuild (65) == I've successfully rebuilt (and requested tagging for dist-f12): - at first try: Perlbal PyAmanith PyKDE PyQuante PySBIG PySolFC PySolFC-cardsets - after some torturing (some packages had quite damaged F-12 and devel branches due to some weird errors during the mass rebuild, spec files and/or sources were not copied and/or not cvsadded and/or not tagged + trivial build failures): eclipse-setools eqntott icoutils olpc-kbdshim python-psyco snake unetbootin Rebuilt recently by sb else: OpenEXR_CTL OpenEXR_Viewers PerceptualDiff Pixie Pound django-typepad Newpackage (some of them even for months!): ccss education-bookmarks gdata-sharp gnome-globalmenu luci netplug perl-Tk-ProgressBar-Mac pyhton-utmp python-decorator3 python-typepad rubygem-extlib rubygem-mixlib-cli rubygem-mixlib-config rubygem-mixlib-log rubygem-systemu sblim-cim-client2 tomcatjss trac-tickettemplate-plugin vanessa_logger volpack x11vnc yum-plugin-download-order zikula-module-filterutil Alpha-only: aboot IA64-only: elilo prctl s390-only: libica openssl-ibmca sparc-only: piggyback prtconf silo xorg-x11-drv-sunbw2 xorg-x11-drv-suncg14 xorg-x11-drv-suncg3 xorg-x11-drv-suncg6 xorg-x11-drv-sunffb xorg-x11-drv-sunleo xorg-x11-drv-suntcx Failing: fonts-hebrew-fancy (https://fedorahosted.org/rel-eng/ticket/2680) libgtk-java (seems like skasal forgot to cvsadd his patch) perl-Perl-Critic (waiting for tagging perl-PPI) ssmtp (don't know why it is on the list, need to consult) Milos -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Petrus de Calguarium wrote: I will give it a try. After a few hours of testing, I see that the font selection works well, but the widget style does not work. I know this is a new program and this is the very first step. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Petrus de Calguarium wrote: Petrus de Calguarium wrote: I will give it a try. After a few hours of testing, I see that the font selection works well, but the widget style does not work. I know this is a new program and this is the very first step. Works for me (though you'll have to uninstall gtk-qt-engine first, if that's in stalled, it will override things set here). Alternatively, manually remove ~/.kde/env/gtk-qt-engine.sh and logout/login -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Rex Dieter wrote: Petrus de Calguarium wrote: Petrus de Calguarium wrote: I will give it a try. After a few hours of testing, I see that the font selection works well, but the widget style does not work. I know this is a new program and this is the very first step. Works for me Oh, and make sure to have at least gtk2-2.18.3-9.fc12 (if on f12/rawhide) -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
Bruno Wolff III wrote: The impression I got (which might be wrong), is that it was expected that people would test specific packages from rawhide and not be expected to be running it all at once. That just doesn't work. The network of dependencies and reverse dependencies generally ends up dragging in half of the distro after the first core library soname bump (e.g. OpenSSL, OpenLDAP or the like). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Jan Kratochvil wrote: While I do not find useful fat-elf I did post an implementation of auto-biarch Fedora LiveDVD but it was ignored. It was (mostly) ignored because it doubles the download size and makes the image no longer fit on a CD, for little benefit. Again, the right solution is to point people to the 64-bit version by default. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Rex Dieter wrote: manually remove ~/.kde/env/gtk-qt-engine.sh I uninstalled gtk-qt-engine first, but the script was still there. Gone now. I have gtk2-2.18.3-8.fc12.x86_64, which is the most recent to be released for rawhide. I guess 2.18.3-9 is on koji? I will try without first, hoping that the manual removal of the gtk-qt script did it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Rex Dieter wrote: make sure to have at least gtk2-2.18.3-9.fc12 Ok. I guess removing the script wasn't enough. I will look for 2.18.3-9 on koji. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Petrus de Calguarium wrote: 2.18.3-9 Well, I got 2.18.3-11. Now, I do get the nodoka theme, but the colours are not carried over. I think another logout/login should cure that. Looks pretty good. Nice that themes will start working for gtk :-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Beta
On Fri, 2009-10-23 at 14:08 +0100, Terry Barnaby wrote: 4 - F12 boots really slow on my laptop http://www.stardust.webpages.pl/files/tmp/bootchart.png something wrong is happening while udev loading Please file a bug for this, on 'udev' component for now, and CC Harald Hoyer (hhoyer at redhat). Thanks! Note that on my Thinkpad R52 Laptop F11 started doing this after a udev RPM update. It turned out to be the fact that there was no floppy drive in my system but the BIOS was configured with one enabled. I suspect this is default in some laptops so that docking stations etc work ?? I think this bug is in Bugzilla, but I suspect it has not been fixed ... That one's known, but is different from what the OP was seeing. With the floppy-enabled thing, the system pauses entirely for pretty much exactly a minute. The OP's case is different as bootchart shows. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Petrus de Calguarium wrote: Now, I do get the nodoka theme, but the colours are not carried over. I think another logout/login should cure that. It turns out... It didn't! I have nodoka and my kde fonts, but not the colour scheme. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-CGI-Application-Plugin-DevPopup/devel .cvsignore, 1.2, 1.3 perl-CGI-Application-Plugin-DevPopup.spec, 1.2, 1.3 sources, 1.2, 1.3
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DevPopup/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1342
Modified Files:
.cvsignore perl-CGI-Application-Plugin-DevPopup.spec sources
Log Message:
Update to 1.03
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DevPopup/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 21 Jun 2009 13:55:11 - 1.2
+++ .cvsignore 23 Oct 2009 07:51:11 - 1.3
@@ -1 +1 @@
-CGI-Application-Plugin-DevPopup-1.01.tar.gz
+CGI-Application-Plugin-DevPopup-1.03.tar.gz
Index: perl-CGI-Application-Plugin-DevPopup.spec
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DevPopup/devel/perl-CGI-Application-Plugin-DevPopup.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-CGI-Application-Plugin-DevPopup.spec 26 Jul 2009 03:55:06 -
1.2
+++ perl-CGI-Application-Plugin-DevPopup.spec 23 Oct 2009 07:51:12 -
1.3
@@ -1,6 +1,6 @@
Name: perl-CGI-Application-Plugin-DevPopup
-Version:1.01
-Release:2%{?dist}
+Version:1.03
+Release:1%{?dist}
Summary:Runtime cgiapp info in a popup window
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Oct 23 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 1.03-1
+- Update to 1.03
+
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.01-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DevPopup/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 21 Jun 2009 13:55:11 - 1.2
+++ sources 23 Oct 2009 07:51:12 - 1.3
@@ -1 +1 @@
-3e49c9a8d865a7a1af76761edfd8 CGI-Application-Plugin-DevPopup-1.01.tar.gz
+323d298c84adf799eb206b0042e28908 CGI-Application-Plugin-DevPopup-1.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 530137] Fedora::Bugzilla - $bug-blocks_bug() fail
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=530137
--- Comment #8 from Jiri Pirko jpi...@redhat.com 2009-10-23 03:48:25 EDT ---
Right, so I figured out what's wrong. In bztest3.pl script I'm using
blocks_bug() in a wrong way.
To get a list of dependent bugs and blocks bugs I'm using successfully
following:
print all_dependent_bug_ids\n;
@dependent_bugs = $bug-all_dependent_bug_ids;
foreach (@dependent_bugs){
print $_\n;
}
print all_blocked_bug_ids\n;
@blocked_bugs = $bug-all_blocked_bug_ids;
foreach (@blocked_bugs){
print $_\n;
}
I would suggest you to add test for these 2 to t/09.depends-blocks.t
Thanks.
--
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
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 464964] FTBFS perl-RRD-Simple-1.43-3.fc9
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=464964 --- Comment #14 from Paul Howarth p...@city-fan.org 2009-10-23 04:15:32 EDT --- Well it's Chris' package, not mine so it's up to him. I think I must have been confusing it with rrdtool when I thought there were other packages needing it. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
