Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 05:42 AM, Kevin Kofler wrote: > FWIW, what the tomcat6 maintainers did is that they just ignored the > guideline which says that you cannot migrate to systemd in an update and > pushed this update: > https://admin.fedoraproject.org/updates/FEDORA-2011-13456 > (which is already in the stable updates). Unless FESCO granted them exception this update might be pulled back atleast that was the case with mdadm [1] if I can recall correctly. "* Mon Jul 18 2011 Doug Ledford - 3.2.2-6 - Back out systemd changes from rawhide" JBG 1. http://koji.fedoraproject.org/koji/buildinfo?buildID=253381 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Sun, 2011-10-23 at 23:43 -0700, Adam Williamson wrote: > On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote: > > > The fact that a glibc with showstoppers of this kind got pushed to stable > > shows that the karma system does not work at all. It just hinders getting > > legitimate fixes out and does nothing to stop regressions. glibc is even > > critpath, yet broken crap still goes out. > > Except...12.999 got pushed out precisely *because* it fixed the most > critical breakage in 12. I'm sure you've previously argued that > 'legitimate fixes' should go out even if they break something else, so > why are you complaining when it happens? Oh - and remember, the goal of the critpath process is to ensure we don't send out updates that break people's systems. It worked fine in this case: no glibc update which breaks systems was approved. All the ones which caused major runtime breakage got rejected. The only breakage in one which was approved was to do with compiling things - which, sure, is a pain in the ass, but it's not the kind of problem critpath was introduced to deal with in the first place. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 03:52 AM, Tom Lane wrote: > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. Which failure is that supposed to be? The "systemd guys" are not the ones that came up with any kind update/upgrade/packaging policy so you are probably speaking of FPC/FESCO here. I think the general idea was that maintainer(s) open a ticket with FESCO where they asked them to grant exception to the general rule and be allowed to push unit files to the GA release should the need arise but feel free to correct me if I'm wrong. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Sun, 2011-10-23 at 17:04 -0500, Rex Dieter wrote: > The fail(*), imo, was with 12.999 going stable containing known-regressions. > So, any suggestions, if any, to prevent any similar series of events? We have lots of suggestions. As I've said at least fifty times, it's pointless going too far with the slapping of band-aids on the current karma system, because it's fundamentally too simplistic: it's never going to be perfect and there is a definite point of diminishing returns if we keep screwing with it. What we need is the non-numeric karma system which Bodhi 2.0 is supposed to be bringing in. No amount of tweaking with the rules of Bodhi 1.0 is going to Magically Solve Everything, because '1, 0, -1' is simply too limited a vocabulary to express everything we need to express about updates. While we're fiddling, though, I do think negative karma should have more value than it currently does. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Mon, 2011-10-24 at 02:47 +0200, Henrik Nordström wrote: > Don't automatically push to stable until at least X days (3?) have > passed, enabling sufficient time for regressions to be detected. Package > maintainer can initiate push earlier by "Push to stable" if needed and > confident there is no regressions. This would cause significant problems around crunch times. We would wind up having to have releng super-push far more updates because we simply don't always *have* three days to wait to hit deadlines. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote: > The fact that a glibc with showstoppers of this kind got pushed to stable > shows that the karma system does not work at all. It just hinders getting > legitimate fixes out and does nothing to stop regressions. glibc is even > critpath, yet broken crap still goes out. Except...12.999 got pushed out precisely *because* it fixed the most critical breakage in 12. I'm sure you've previously argued that 'legitimate fixes' should go out even if they break something else, so why are you complaining when it happens? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rwhide: Last Kernel not booting in vmware
On 23 Oct 2011 00:18, "Reindl Harald" wrote: > > Linux rawhide.vmware.local 3.1.0-0.rc9.git0.0.fc17.x86_64 #1 SMP Wed Oct 5 14:37:47 > > this is the last kernel booting in vmware for me > all following see screenshot It seems that the initramfs does not find any drives. Can you check if the drivers for your disk are included in the initramfs.img? Comparing available .ko files from a working initramfs and the new one is likely the easiest. Good luck! > > -- > > Mit besten Grüßen, Reindl Harald > the lounge interactive design GmbH > A-1060 Vienna, Hofmühlgasse 17 > CTO / software-development / cms-solutions > p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 > icq: 154546673, http://www.thelounge.net/ > > http://www.thelounge.net/signature.asc.what.htm > > -- > 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: BEWARE: a problematic glibc made it to stable (F16)
On 10/23/2011 07:47 PM, Henrik Nordström wrote: > Disable automatic push to stable when there is any negative karma, > requiring the package maintainer to initiate the push even if karma > kriteria have been met. This idea has been suggested: https://fedorahosted.org/bodhi/ticket/618 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-10-24 @ 15:00 UTC - Fedora QA Meeting
WHAT: Fedora QA Meeting WHEN: 15:00 UTC (11:00 EDT, 08:00 PDT) WHERE: #fedora-meeting It's meeting time again! This one will likely turn into a blocker review meeting, as we have the F16 RC due on Tuesday. If anyone has anything to add to the agenda, please reply to this mail, and whoever ends up running the meeting will add it. Thanks! Proposed agenda: * Previous meeting follow-up [1] * Final preparation and blocker review * Proven tester / AutoQA updates (if any) * Upcoming QA Events * Open discussion If you have any suggested topics, feel free to respond to this email or bring them up during open discussion. [1] http://meetbot.fedoraproject.org/fedora-meeting/2011-10-17/fedora-qa.2011-10-17-15.00.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Tom Lane wrote: > The current packaging guidelines require packages that update from sysv > init scripts to systemd scripts to provide conversion triggers that are > fired on the basis of an NVR comparison: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript > > That is, we assume that we know that all releases with NVR < some-cutoff > use initscripts and all releases with NVR >= same-cutoff use systemd. > The comments in the above-linked page acknowledge that this means it's > impossible to upgrade the package to a newer upstream release in > pre-systemd Fedora branches. (You can't just move the cutoff value > forward, because then an upgrade in F16 or later will mistakenly re-fire > the update trigger.) > > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. > > The idea I have at the moment is to ignore the advice to check package > version, and instead have the triggerun script check to see whether the > mysql sysv initscript file is present. I wonder whether anyone else has > dealt with this and has working scriptlets? FWIW, what the tomcat6 maintainers did is that they just ignored the guideline which says that you cannot migrate to systemd in an update and pushed this update: https://admin.fedoraproject.org/updates/FEDORA-2011-13456 (which is already in the stable updates). I'm starting to wonder whether that wouldn't be the best solution here. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
Camilo Mesias mesias.co.uk> writes: > > Hi, > > I tried some of these changes and they seemed to work reasonably well > apart from the grub2 infrastructure is still a bit immature at running > without initrd... specifically > ... > I'm not sure where to report this? Bugs against grub2 or something > else? Is there a specific forum for initrdless working? > > -Cam > ... With regard to initrdless boots: https://bugzilla.redhat.com/show_bug.cgi?id=734274 JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rwhide: Last Kernel not booting in vmware
Linux rawhide.vmware.local 3.1.0-0.rc9.git0.0.fc17.x86_64 #1 SMP Wed Oct 5 14:37:47 this is the last kernel booting in vmware for me all following see screenshot -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm <> signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Systemd conversion versus updates in back Fedora branches
The current packaging guidelines require packages that update from sysv init scripts to systemd scripts to provide conversion triggers that are fired on the basis of an NVR comparison: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript That is, we assume that we know that all releases with NVR < some-cutoff use initscripts and all releases with NVR >= same-cutoff use systemd. The comments in the above-linked page acknowledge that this means it's impossible to upgrade the package to a newer upstream release in pre-systemd Fedora branches. (You can't just move the cutoff value forward, because then an upgrade in F16 or later will mistakenly re-fire the update trigger.) I'm really getting to the point where that's a completely unacceptable restriction. I've already blown off one mysql bug-fix release in F15 because of this restriction, and I see they just released another one that I'll be unable to ship in F15 because the systemd guys failed to do their homework, and there are likely to be several more before F15 dies. The idea I have at the moment is to ignore the advice to check package version, and instead have the triggerun script check to see whether the mysql sysv initscript file is present. I wonder whether anyone else has dealt with this and has working scriptlets? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Zif and SOS projects on Fedora Upstream
Hi. There is a project named SOS in Fedora collection on Transifex. I'd like to know if there is anyone maintaining it, because it seems like it needs to be translated, but there is no maintainer assigned in Tx and no translation team creation request has been fulfilled in 7 months. The latest change to code in Github is 6 months old. We tried to contact Adam Stokes mentioned in the source readme on Github, but no reply yet. Any help with getting response is much appreciated. -- Best regards, Misha Shnurapet, Fedora Project Contributor Email: shnurapet AT fedoraproject.org, IRC: misha on freenode https://fedoraproject.org/wiki/shnurapet, GPG: 00217306 Пересылаемое сообщение 21.10.2011, 20:42, "Daniel Cabrera" : On Wed, 2011-10-19 at 00:13 +0900, Misha Shnurapet wrote: > Zif: I would send a message to Jorge González (aloriel at gmail.com), also > nudge him in Transifex. > Sos: I would contact the maintainer Adam Stokes (ajs AT redhat.com) or file > a report in Github [1] where the code has moved. Also [2]. > > [1] https://github.com/sosreport/sosreport > [2] https://github.com/sosreport/sosreport/blob/master/README > > -- > Best regards, > Misha Shnurapet, Fedora Project Contributor > Email: shnurapet AT fedoraproject.org, IRC: misha on freenode > https://fedoraproject.org/wiki/shnurapet, GPG: 00217306 > -- Misha, Unfortunately until today I did not get any response to the emails I sent to Adam Stokes. Best regards, Daniel Cabrera (es) -- trans mailing list tr...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans Завершение пересылаемого сообщения -- trans mailing list tr...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter: > The fail(*), imo, was with 12.999 going stable containing known-regressions. > So, any suggestions, if any, to prevent any similar series of events? My suggestions: Disable automatic push to stable when there is any negative karma, requiring the package maintainer to initiate the push even if karma kriteria have been met. Don't automatically push to stable until at least X days (3?) have passed, enabling sufficient time for regressions to be detected. Package maintainer can initiate push earlier by "Push to stable" if needed and confident there is no regressions. Make "push to stable" require extra confirmation when there is negative karma, making sure that whoever is initiating the push have actually looked at why there is negative karma. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
Kevin Kofler wrote: > Jim Meyering wrote: >> glibc-2.14.90-12.999, which has just made it to stable provokes a >> hard-to-diagnose (for me at least) problem. >> >> While most things work, and it fixed two problems that affected me, >> it caused me some frustration: >> >> https//bugzilla.redhat.com/747377 > > glibc-2.14.90-12.999 also breaks the build of ANY C++ code using fenv.h, > which affects at least Qt (but likely also several other C++ packages, > particularly mathematical ones, but not only, as can be seen from Qt). > Thankfully, that showstopper is fixed in -13 which is already in stable by > now (because it was aggressively up-karma'd by the KDE SIG). > > The fact that a glibc with showstoppers of this kind got pushed to stable > shows that the karma system does not work at all. It worked in a way, but was an interesting case. As I see it, the general series of events went something like this: -10 was *generally* ok -11 fixed a few bugs, but introduced the nasty "breaks grokking of /etc/groups", down karma'd -12 fixed some other bug, down-karma'd for not fixing -11 -12.999 got massive up-karma for fixing -11 problem, *but* introduced a new problem/regression. Got pushed stable. -13 was, of course, damage control from the fall-out from 12.999... Now, I'd argue the process worked up to -12.999, regressions were kept out of stable updates. The fail(*), imo, was with 12.999 going stable containing known-regressions. So, any suggestions, if any, to prevent any similar series of events? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unresponsive Package Maintainer - Gary T. Giesen
I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Does anyone know how to contact Gary T. Giesen? I've sent him an email (also CCed on this one) a few months ago requesting co-maintainer status for daemonize without a response. Gary has two open bugs without a response: https://bugzilla.redhat.com/show_bug.cgi?id=701383 https://bugzilla.redhat.com/show_bug.cgi?id=746783 His last koji build was in July 2009 - 27 months ago. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Testers needed on short notice for 389DS, FreeIPA and SSSD update in F16
Please review the critical path update=20 https://admin.fedoraproject.org/updates/FEDORA-2011-14614 We're right up against the last minute to get these fixes in to ensure that all of these features work properly from the install DVD. We very desperately need testers (including one proventester, due to the selinux-policy update) to review these packages before the end of the day tomorrow (Monday Oct. 24) so that they can be pushed to stable in time for the release candidate build. 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: [ACTION REQUIRED v2] Retiring packages in F-16
Hello, I am replying to let you know that I succeeded in building gwaei. It took a fair bit of effort to get it going, because apparently the configure script that comes with gWaei doesn't properly pick up on 64-bit libraries (or Fedora's or the maintainer's gtk+-3 pkgconfig wasn't sane, or *something*). But in the end, it is now working nicely with a Gnome 3-like interface on my computer. Not only that, but the version of gWaei that was included in Fedora 15 was apparently *really* old (which might explain why it was broken). Some details on how to get it to compile are here: https://sourceforge.net/tracker/index.php?func=detail&aid=3427591&group_id=244762&atid=1126810# If there is no package maintainer, I'm willing to try and be one, since I'm a bit of a fan of the software. (Though I'll have to study up on package maintaining.) Yours, - Vincent Beers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Device Audio codec hwC0D0: Realtek and Device Audio codec hwC0D3: Intel on HDA Intel sound
Ok, as long as my sound "onboard" I disabled it, rebooted and enabled it again. So now I got in /sys/devices/pci:00/:00:1b.0/label only: Realtek High Definition Audio Device Where is my Intel HDA ? lspci: 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20111023 changes
Compose started at Sun Oct 23 08:15:43 UTC 2011 Broken deps for x86_64 -- aeolus-all-0.4.0-1.fc16.noarch requires rubygem(aeolus-cli) aeolus-conductor-0.4.0-1.fc16.noarch requires rubygem(oauth) aeolus-conductor-devel-0.4.0-1.fc16.noarch requires rubygem(webmock) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-tks-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-ra-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-kra-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-tps-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-console-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-ocsp-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-common-theme >= 0:9.0.9 dogtag-pki-9.0.0-7.fc16.noarch requires dogtag-pki-ca-theme >= 0:9.0.9 emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_core.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_calib3d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_calib3d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-firevision-0.4.2-4.f
Re: BEWARE: a problematic glibc made it to stable (F16)
Am 23.10.2011 04:14, schrieb Kevin Kofler: > Jim Meyering wrote: >> glibc-2.14.90-12.999, which has just made it to stable provokes >> a hard-to-diagnose (for me at least) problem. >> >> While most things work, and it fixed two problems that affected >> me, it caused me some frustration: >> >> https//bugzilla.redhat.com/747377 > > glibc-2.14.90-12.999 also breaks the build of ANY C++ code using > fenv.h, which affects at least Qt (but likely also several other > C++ packages, particularly mathematical ones, but not only, as can > be seen from Qt). Thankfully, that showstopper is fixed in -13 > which is already in stable by now (because it was aggressively > up-karma'd by the KDE SIG). > > The fact that a glibc with showstoppers of this kind got pushed to > stable shows that the karma system does not work at all. It just > hinders getting legitimate fixes out and does nothing to stop > regressions. glibc is even critpath, yet broken crap still goes > out. > Since a few days I've got the problem that lazarus and applications written with lazarus are running into an exception on closing them. Originaly I thought that this is a problem of that latest gtk2 update but could it be that glibc also affects lazarus, even if is pascal? Regards Heiko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Device Audio codec hwC0D0: Realtek and Device Audio codec hwC0D3: Intel on HDA Intel sound
Dear All. Recently I checked powertop and the first lines are: 100.0% Device Audio codec hwC0D0: Realtek 100.0% Device Audio codec hwC0D3: Intel I remember that it was only Intel codec. Do I really need - Audio codec hwC0D0: Realtek ? lspci: 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) ... Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel uname: Linux 3.1.0-0.rc10.git0.1.fc16.x86_64 #1 SMP Wed Oct 19 05:02:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Thanks in advance. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
