Re: CVE-2009-2904 - not patched F11 openssh?
On Saturday 27 March 2010 04:17:13 pm Michał Piotrowski wrote: > > So if you are on 5.2p1-6, you should be OK. > > This upgrade should be pushed to updates-testing and updates > > yum --enablerepo=updates-testing upgrade openssh > [..] > openssh x86_64 5.2p1-5.fc11 updates-testing > 265 k I'll see that this is pushed out as soon as we can. In the meantime, you can grab it here: http://koji.fedoraproject.org/koji/buildinfo?buildID=132898 -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maximum length of userid on Fedora Linux
Jochen Schmitt píše v So 27. 03. 2010 v 18:12 +0100: > I want to ask which is the maximum length of a userid on Fedora Linux. (UT_NAMESIZE - 1). UT_NAMESIZE is defined in > I think the maximum length of a userid should be 16 but I want to get > a confiration about this assumetion. What's special about "16"? Why not 8, 15, 17, 24, 32? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning DR17 and EFL
Am Dienstag, den 16.03.2010, 22:11 +0100 schrieb Thomas Janssen: > Hi, As-Salāmu `Alaykum > im orphaning: > > e_dbus > ecore > edje > eet > efreet > embryo > emotion > epeg > epsilon > evas > ewl > libeina and I will also orphan enlightenment. > Reason: > The problem started with my co-maintainer cassmodiah, building embryo > .063 release for F-13 without waiting for me to have the complete > chain built at least locally and having it tested. That's the way i do > my packaging stuff. Nothing terribly bad so far, he just wanted to > help me. Sorry for this, but this should be fixable. I haven't understand why you made such a trouble for this silly mistake I made...!? > While i was fiddling with some DSO problem i had some talk with > upstream. Upstream recommended to me to deprecate some packages since > they aren't supported anymore, but change the chain to their DR17 and > EFL release 1.0 that's soon coming up. > http://trac.enlightenment.org/e/wiki/Packaging > > I was waiting for that release to get it eventually into F-13. At some > point, a few days ago, i decided that i can't wait for it for F-13 and > was thinking about using epoch to downgrade embryo again. Thankfully, > cwickert made the point that i could ask rel-eng to get this build > untaged. I made a ticket for it with rel-eng and had another one to do > with FESCo since rel-eng couldn't do it on it's own. Both rel-eng and > FESCo did a perfect job there and decided the right thing for the > enduser to get it untaged. Thank you very much again. > > The real reason to get the packages orphaned is the continued > annoyance of cwickert on IRC (#fedora-de), trying to force me into the > role of the bad guy there, since he did not understand the problem, > even not in the FESCo Meeting from today. See the FESCo ticket to get > a hint of what was going on in #fedora-de. > https://fedorahosted.org/fesco/ticket/355 > Trying to force anybody into pushing an untested release into F-13. > You can see that even in the Meeting log. Instead of let me do my job > as package maintainer. So i'm really sick and tired and give it away. > > Coming back to that social problem mentioned. The rel-eng ticket was > clearly mentioned in #fedora-de and even to cassmodiah (if i have to > upload backlogs, cassmodiah == boelkmoeller3), not just by me, but as > well by cwickert. Everything was talked about, as well what i want to > do. > The only social problem here was an arrogant and stubborn cwickert. > Sorry, but i can't stand a liar. Sorry, but I don't understand this. Christoph is my best friend in the Fedora Project. He is sometimes a little bit stubborn and sometimes a arrogant guy, but he is always fair and he has a open ear for everyone and every problem and he always gives his best to deal justly. He's like a modern Salomo and if you have a problem with Christoph, you should discuss this with him directly, or add him to your ignore list for continueing a noisefree maintaining of your stuff. Imho the fact that you have a personal problem with anybody in the project isn't a good reason for orphaning packages. It's your decision and I don't want to disabuse you, but you turn down any help (Rudof Kastl known as Che and Christoph Wickert and Sven Lankes, knwown as killefiz offers you help) and you are not able to take crtism. Maybe this is the real reason for this problem?! Don't take anything (which is spoken to you) personally, it's just business. > If someone want to grab the packages, feel free. Nobody wants this packages? Sad! I can't maintain the whole enlightenment tree alone , because I haven't enough time and knowledge base to handle this, although some friends offers me help to fix this. I would take these packages again if there is a bunch of people who tried to help me permanently, but I'm pessimistic of this. :-( It's very sad, because enlightenment is a cool desktop and a real alternative to other windowmanagers like the ugly openbox. LXDE for example works with enlightenment and it's very cool to have a desktop that gives you such a style without being a fat bitch :-p (Sorry Christoph, but you already know my opinion) > -- > LG Thomas > > Dubium sapientiae initium -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
2010/3/27 Steve Grubb : > On Saturday 27 March 2010 09:17:55 am Steve Grubb wrote: >> On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: >> > Vulnerability described in CVE-2009-2904 >> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was >> > addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for >> > RHEL. Isn't F11 openssh version also vulnerable? >> >> RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that >> backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should >> not be vulnerable. > > More research...looks like this took care of it: > > * Mon Sep 21 2009 Jan F. Chadima - 5.2p1-6 > - remove homechroot patch > > So if you are on 5.2p1-6, you should be OK. > This upgrade should be pushed to updates-testing and updates yum --enablerepo=updates-testing upgrade openssh [..] openssh x86_64 5.2p1-5.fc11 updates-testing 265 k Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Saturday 27 March 2010 09:17:55 am Steve Grubb wrote: > On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: > > Vulnerability described in CVE-2009-2904 > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was > > addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for > > RHEL. Isn't F11 openssh version also vulnerable? > > RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that > backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should > not be vulnerable. More research...looks like this took care of it: * Mon Sep 21 2009 Jan F. Chadima - 5.2p1-6 - remove homechroot patch So if you are on 5.2p1-6, you should be OK. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Sat, 27 Mar 2010 10:57:34 -0500 Bruno Wolff III wrote: > On Sat, Mar 13, 2010 at 15:51:37 -0700, > Kevin Fenzi wrote: > > > > - If currently crashes due to poor coding: > > https://bugzilla.redhat.com/show_bug.cgi?id=562038 > > (basically trying to reload a saved game makes it crash). > > I found an off by one error (typical the last element of the array's > index is one less than the size of the array, not the size of the > array). It only crashes when compiled with fortify options. I don't > think the correct value was being saved in the first place. Cool. Good detective work. ;) > I expect to have test builds up shortly and will update the bug at > that time. excellent. Glad you could fix it up. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On 27/03/10 15:08, Matthias Clasen wrote: > On Sat, 2010-03-27 at 08:19 +, Terry Barnaby wrote: > >> >> I'm not sure if your usage policy covers changes to Bodhi, but how about >> the system emailing the upstream developers (direct and/or email lists) >> when a release is made available for testing/release and also on any >> problems found ? > > I would be _very_ careful with sending autogenerated spam to random > people that have not signed up for it. I would expect many people to > react negatively to it. > > Sending a small note along the lines of 'Hey, I'm packaging your > software for Fedora. How about you mention on the website that it is not > only available in Ubuntu but also in Fedora' is a quite different > thing, and should be done. > Yes, you are probably right. But how about an email text entry box to make it easy to send an email and to encourage this ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On Sat, 27 Mar 2010 12:27:45 -0500, Garrett Holmstrom wrote: > On 3/27/2010 12:19, xinglin wrote: >> The fact is Emulab does not have Fedora12 now. We just have Fedora8 and >> Fedora10. :( >> I will talk with the Emulab administrators about this. > > If the lab can't keep up with updates to Fedora releases it should > seriously try going with a distribution with longer term support, such > as CentOS. Fedora 8 lost support over a year ago, and RH 9 lost support > almost six years ago. Get it. Thanks for this information. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On 3/27/2010 12:19, xinglin wrote: > The fact is Emulab does not have Fedora12 now. We just have Fedora8 and > Fedora10. :( > I will talk with the Emulab administrators about this. If the lab can't keep up with updates to Fedora releases it should seriously try going with a distribution with longer term support, such as CentOS. Fedora 8 lost support over a year ago, and RH 9 lost support almost six years ago. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maximum length of userid on Fedora Linux
On Saturday 27 March 2010 10:12:32 am Jochen Schmitt wrote: > Hallo, > > I want to ask which is the maximum length of a userid on Fedora Linux. > > I think the maximum length of a userid should be 16 but I want to get > a confiration about this assumetion. $ sudo useradd a23456789012345678901234567890 $ ls /home/a23456789012345678901234567890/ ls: cannot open directory /home/a23456789012345678901234567890/: Permission denied I think there isn't a 16 char limit ;). Regards, -- Conrad Meyer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On Sat, 27 Mar 2010 17:45:01 +0100, Björn Persson wrote: > xinglin wrote: >> Hi, >> >> I am Xing, a PHD candidate in University of Utah. I am trying to compile >> and install an OpenVZ kernel in FEDORA8, but one error prevents me. The >> error is "No build ID note found in /var/tmp/kernel***". I have tried >> several ways to solve it but still failed. I introduced what I did to >> solve >> this problem and hope to get some help from you. > > Hello Xing! I know nothing about OpenVZ and only a little about compiling > Linux, OpenVZ is based on Linux Kernel. So, when the disk is partitioned suitably in the host OS, I think there is no big difference(Apply some patches and make config) when compiling OpenVZ kernel and Linux Kernel. > but I thought I'd point out that Fedora 8 was retired over a year > ago. > No bugs will get fixed in Fedora 8 anymore, so it's pretty much off-topic > on > this list. I would suggest trying with Fedora 12 instead. I think you're > more > likely to get replies if you can reproduce the problem on a current > version of > Fedora. The fact is Emulab does not have Fedora12 now. We just have Fedora8 and Fedora10. :( I will talk with the Emulab administrators about this. >> ~/openvz/ovzkernel-2.6.18-128.2.1.el5.028stab064.7.src.rpm > > I see "el5" in there. Have you tried compiling it on RHEL 5 or CentOS 5? Not yet. Actually, one of stuffs in our group succeeded to use rpmbuild to build OpenVZ kernel in Fedora8. But unfortunately, he forgot how he solved this. The reason I wanted to build a new openvz kernel based on his image(Fedora8 with OpenVZ supported) is I do not need to repartition the disk and install utilities. In OpenVZ user guide, it also uses Fedora core 4 as an example to show how to install the host OS. We do have Redhat 9.0 image in our testbed. I will try to compile on Redhat 9.0 or Fedora10 using rpmbuild. But I think I will try to compile in the traditional way first. Thanks very much. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Maximum length of userid on Fedora Linux
Hallo, I want to ask which is the maximum length of a userid on Fedora Linux. I think the maximum length of a userid should be 16 but I want to get a confiration about this assumetion. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100327 changes
Compose started at Sat Mar 27 09:15:06 UTC 2010 Broken deps for i386 -- gnome-web-photo-0.9-4.fc13.i686 requires gecko-libs = 0:1.9.2.1 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 libnodeupdown-backend-openib-1.9-5.fc13.i686 requires libosmcomp.so.3(OSMCOMP_2.3) libnodeupdown-backend-openib-1.9-5.fc13.i686 requires libosmcomp.so.3 moblin-app-installer-0.4.0-0.7.fc13.i686 requires libpackagekit-glib2.so.13 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 sepostgresql-8.4.2-2488.fc13.i686 requires postgresql-server = 0:8.4.2 totem-youtube-2.29.92-1.fc13.i686 requires libgdata.so.7 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- gnome-web-photo-0.9-4.fc13.x86_64 requires gecko-libs = 0:1.9.2.1 hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires libosmcomp.so.3(OSMCOMP_2.3)(64bit) libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires libosmcomp.so.3()(64bit) moblin-app-installer-0.4.0-0.7.fc13.x86_64 requires libpackagekit-glib2.so.13()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) sepostgresql-8.4.2-2488.fc13.x86_64 requires postgresql-server = 0:8.4.2 totem-youtube-2.29.92-1.fc13.x86_64 requires libgdata.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package bakefile A cross-platform, cross-compiler native makefiles generator New package cppi C preprocessor directive indenter New package perl-Net-STOMP-Client STOMP object oriented client module New package pidgin-birthday-reminder Birthday Reminder plugin for Pidgin New package python-empy A powerful and robust template system for Python New package skf Utility binary files in Simple Kanji Filter Updated Packages: PackageKit-0.6.3-0.1.20100322git.fc13 - * Tue Mar 23 2010 Richard Hughes - 0.6.3-0.1.20100322git - Add a pre-release snapshot to include all of the most recent fixes for the F13 beta release. - Remove preupgrade hard depends as it's not installed by default for gnome-desktop in comps. * Mon Mar 22 2010 Rex Dieter - 0.6.2-2 - -qt: add minimal qt4 runtime dependency (#573308) * Mon Mar 15 2010 Richard Hughes - 0.6.2-1 - New upstream release of 0.6.2. - Update to the latest version of the Fedora Packaging Guidelines - Do not Require: pkgconfig - Fix up a few file ownership issues - Remove the custom BuildRoot - Do not clean the buildroot before install anaconda-13.37-1.fc13 - * Thu Mar 25 2010 David Lehman - 13.37-1 - Unlock the CD tray door in isys.ejectcdrom() (#569377) (pjones) - Texts under storage/formats missing from the .pot file (#576082). (akozumpl) - Translate the Back button in glade (#576082) (akozumpl) - Add originalFormat handling to editLVMLogicalVolume. (#576529) (dlehman) - Fix a cut&paste error that caused a traceback (#574743) (dlehman) - yum requires the proxy settings to include a protocol (#576691). (clumens) - Only look for extended partitions on partitioned devices (#576628) (hdegoede) - Fix referring to disks by-label, by-uuid, etc (#575855). (clumens) - Fix syntax for passing a mapping to a translatable string (#576085). (clumens) - Catch NotImplementedError when scanning for disklabels (#566722) (hdegoede) - Filter UI do not start / stop BIOS RAID sets to get there size (#574587) (hdegoede) - Make filter UI honor nodmraid cmdline option (#574684) (hdegoede) - Properly align the first partition we create (#574220) (hdegoede) - Update filter for translation log entries. (dlehman) * Mon Mar 22 2010 David Lehman - 13.36-1 - Don't pass size=1 for autopart PVs. Use PartitionDevice's default size. (dlehman) - Make python start with correct default unicode encoding (#539904). (akozumpl) - Fixes bug #569373 - Change udev_trigger block calls to use change action (bcl) - Fix: execWithRedirect() unexpectedkeyword argument 'searchPath' (#572853) (hdegoede) - Do not crash on .autorelabel when using read only rescue mount (#568367) (msivak) - Do not crash when getDevices returns NULL (#567939) (msivak) gnome-packagekit-2.29.92-0.1.20100315git.fc13 - * Mon Mar 15 2010 Richard Hughes - 2.29.92-0.1.20100315git - New snapshot from the master branch - Rebuild against the latest PackageKit - Should fix the silent failure when the simulate depsolve fails - Ensure that there can only eve be one update icon running in a session. kdeutils-4.4.1-2.fc13 - * Wed Mar 24 2010 Kevin Kofler - 6:4.4.1-2 - -printer-applet: add support for automatic printer drive
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
xinglin wrote: > Hi, > > I am Xing, a PHD candidate in University of Utah. I am trying to compile > and install an OpenVZ kernel in FEDORA8, but one error prevents me. The > error is "No build ID note found in /var/tmp/kernel***". I have tried > several ways to solve it but still failed. I introduced what I did to solve > this problem and hope to get some help from you. Hello Xing! I know nothing about OpenVZ and only a little about compiling Linux, but I thought I'd point out that Fedora 8 was retired over a year ago. No bugs will get fixed in Fedora 8 anymore, so it's pretty much off-topic on this list. I would suggest trying with Fedora 12 instead. I think you're more likely to get replies if you can reproduce the problem on a current version of Fedora. > ~/openvz/ovzkernel-2.6.18-128.2.1.el5.028stab064.7.src.rpm I see "el5" in there. Have you tried compiling it on RHEL 5 or CentOS 5? 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: orphaning greyhounds package
On Sat, Mar 13, 2010 at 15:51:37 -0700, Kevin Fenzi wrote: > > - If currently crashes due to poor coding: > https://bugzilla.redhat.com/show_bug.cgi?id=562038 > (basically trying to reload a saved game makes it crash). I found an off by one error (typical the last element of the array's index is one less than the size of the array, not the size of the array). It only crashes when compiled with fortify options. I don't think the correct value was being saved in the first place. I expect to have test builds up shortly and will update the bug at that time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Fri, Mar 26, 2010 at 03:49:28PM -0700, Adam Williamson wrote: > 1. I have tried this update in my regular day-to-day use and seen no > regressions. > > 2. I have tried this update in my regular day-to-day use and seen a > regression: bug #XX. > > 3. (Where the update claims to fix bug #XX) I have tried this update > and found that it does fix bug #XX. > > 4. (Where the update claims to fix bug #XX) I have tried this update > and found that it does not fix bug #XX. > > 5. I have performed the following planned testing on the update: (link > to test case / test plan) and it passes. > > 6. I have performed the following planned testing on the update: (link > to test case / test plan) and it fails: bug #XX. I have some additions: 7. fixes bug X, but does not claim to fix it This can often happen with hardware related bugs, e.g. with the kernel where something starts to work again 8. The package updated sucessfully, but was not used intentionally. No breakage noticed. This shows, that at least on the test machine, there are no broken deps, conflicts or broken scriptlets. Also it would be nice to provide hardware testing feedback, e.g. for Xorg updates to say "Works with nouveau, Geforce XY, using VGA out and XV", which then shows that e.g. 3D support, DVI out or multi screen support was not tested. This is kind of related to testing with a test plan, but having this data available in a format that can be easily parsed, would be nice, too. Maybe this could be done with adding smolt information in the feedback and the tested features (XV, VGA, DVI, 3D, ...) and the update needs to have some meta data, which kind of devices are supported (e.g. only Geforce devices for the nouveau driver package). Regards Till pgpHcRSV60m0K.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 08:19 +, Terry Barnaby wrote: > > I'm not sure if your usage policy covers changes to Bodhi, but how about > the system emailing the upstream developers (direct and/or email lists) > when a release is made available for testing/release and also on any > problems found ? I would be _very_ careful with sending autogenerated spam to random people that have not signed up for it. I would expect many people to react negatively to it. Sending a small note along the lines of 'Hey, I'm packaging your software for Fedora. How about you mention on the website that it is not only available in Ubuntu but also in Fedora' is a quite different thing, and should be done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
Terry Barnaby writes: > I'm not sure if your usage policy covers changes to Bodhi, but how about > the system emailing the upstream developers (direct and/or email lists) > when a release is made available for testing/release and also on any > problems found ? As an upstream developer, I can hardly think of a quicker way to piss me off than if every distro were to start sending me such nagmail. I would not want such a thing turned on on *any* of my packages. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100327 changes
Compose started at Sat Mar 27 08:15:07 UTC 2010 Broken deps for i386 -- anaconda-14.2-1.fc14.i686 requires fcoe-utils >= 0:1.0.12-2.20100323git edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP = 0:4000.0.8 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network = 0:2.2.1.5 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck = 0:2.1.0.2 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-devel = 0:2.1.0.2 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi-devel = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-devel = 0:4000.0.8 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network-devel = 0:2.2.1.5 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-doc = 0:2.1.0.2 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-doc = 0:4000.0.8 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires
ruby-tcltk totally broken and obsolete since ages?
Hi, there have been serious bugs filled and ignored against this package for ages, see eg https://bugzilla.redhat.com/show_bug.cgi?id=483537 https://bugzilla.redhat.com/show_bug.cgi?id=560053 Perhaps the maintainers did not realise the severity of the bugs - it appears that any nontrivial example will inevitably crash. I have tried to debug with gdb & valgrind, all I can say it is non quite trivial, seems like some memory management & garbage collection issue. The last version that ever worked for me was in "Red Hat Linux release 8.0 (Psyche)", I have skipped a few intermediate releases before jumping on Fedora so no idea when exactly it stopped working. I have recompiled and installed the ruby and tcltk packages from this source. The finding is that programs that worked in RH 8 crash in F10 & F12 even when exact the same sources are used. Possibly ruby or tcltk relied on some assumptions that does not work with newer glibc. I hope that someone has an idea - otherwise I think it is safe to completely remove the package. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: > Vulnerability described in CVE-2009-2904 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was > addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for > RHEL. Isn't F11 openssh version also vulnerable? RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should not be vulnerable. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop Xorg Nv driver?
On Sat, Mar 27, 2010 at 05:36:29AM +0530, Rahul Sundaram wrote: > Hi, > > Nvidia has announced that they are deprecating it > > http://lists.freedesktop.org/archives/xorg/2010-March/049749.html > > They are recommending users to use Vesa instead as the replacement but > the real reason appears to be Nouveau which Fedora has supported for a > long time now. Has to be said that I've always had better luck with nv. Nouveau has "seemed" to be very unstable to me (although it's always been hard to pin down actual reproducible bugs). I never used and don't care about any 3D or advanced features though ... 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: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 08:19 +, Terry Barnaby wrote: > I'm not sure if your usage policy covers changes to Bodhi, but how about > the system emailing the upstream developers (direct and/or email lists) > when a release is made available for testing/release and also on any > problems found ? That's not really part of this proposal. It's a reasonable feature request for Bodhi, though. You could file it with the Bodhi developers (I think infrastructure trac - https://fedorahosted.org/fedora-infrastructure/ - is the appropriate venue). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On 27/03/10 04:12, Adam Williamson wrote: > On Sat, 2010-03-27 at 03:50 +0100, Kevin Kofler wrote: > >> So I don't think blocking an update outright for having received type 2 >> feedback is sane at all. > > Sigh. That was why I said not to sidetrack the discussion because it was > the least important bit of the post. It was just an example of how > easily the policy can be adapted. I'm really not interested in thrashing > out the tiny details of *that* in *this* thread, that is not what it's > for. I had a whole paragraph about the possibility of an override > mechanism for maintainers which I left out precisely in order to avoid > this kind of discussion, but apparently that wasn't enough... I'm not sure if your usage policy covers changes to Bodhi, but how about the system emailing the upstream developers (direct and/or email lists) when a release is made available for testing/release and also on any problems found ? Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
