Re: Provenpackager help needed to complete libpng/libtiff transition
Adam Williamson writes: > On Wed, 2012-08-01 at 01:53 -0400, Tom Lane wrote: >> There are still about half a dozen packages left that failed the recent >> mass rebuild because they contain source-code dependencies on obsolete >> versions of libpng and/or libtiff. I've filed patches to fix them, >> but don't have permissions to do it myself. If any provenpackagers >> have a bit of time to spare, could I pester you to look at these bugs? > Thanks for doing the patches! Have you tried to upstream them, or are > the upstreams for these dead? I have not; I supposed that the respective package maintainers would be in a better position than me to pester their upstreams. These bugs are the ones that I've not gotten a response on from the maintainer, so perhaps the correct question to be asking is whether the Fedora maintainer is asleep at the wheel ... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
redhat-lsb-desktop versus transition to current libpng
I have been working for the better part of a year on moving Fedora off
of libpng's obsolete 1.2.x release series and onto the current 1.5.x
series. We are practically there now, and I had hoped to drop libpng
1.2 from the distribution before the F18 branch. However, I find that
redhat-lsb-desktop still has a dependency on 1.2, and it's not even
because that package contains any PNG-using code; rather, there's a
manually inserted version-specific dependency in the specfile:
%ifarch %{ix86}
Requires: libpng12.so.0
%endif
%ifarch x86_64
Requires: libpng12.so.0()(64bit)
%endif
This is unlike that specfile's treatment of any other library
it requires. I have been told, at
https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
that the LSB standard requires libpng 1.2, but without any supporting
evidence. I looked at the underlying ISO documents and don't see any
requirement for libpng at all, let alone 1.2 in particular. I am
doubtful that every other Linux distro is maintaining this long-obsolete
libpng version, too.
I would like to know how to proceed here. "You should keep libpng 1.2
around indefinitely, on the basis of no evidence" is not an answer
I intend to accept.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provenpackager help needed to complete libpng/libtiff transition
On Wed, 2012-08-01 at 01:53 -0400, Tom Lane wrote: > There are still about half a dozen packages left that failed the recent > mass rebuild because they contain source-code dependencies on obsolete > versions of libpng and/or libtiff. I've filed patches to fix them, > but don't have permissions to do it myself. If any provenpackagers > have a bit of time to spare, could I pester you to look at these bugs? > > Pixie 843294 > dcmtk 819236 > fuse-emulator 843645 > grace 843647 > gshutdown 843648 > luakit843652 > pngnq 843655 > tucnak2 843658 I'll take care of some of these tomorrow, if no-one else beats me to it. Thanks for doing the patches! Have you tried to upstream them, or are the upstreams for these dead? -- 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
Provenpackager help needed to complete libpng/libtiff transition
There are still about half a dozen packages left that failed the recent mass rebuild because they contain source-code dependencies on obsolete versions of libpng and/or libtiff. I've filed patches to fix them, but don't have permissions to do it myself. If any provenpackagers have a bit of time to spare, could I pester you to look at these bugs? Pixie 843294 dcmtk 819236 fuse-emulator 843645 grace 843647 gshutdown 843648 luakit 843652 pngnq 843655 tucnak2 843658 Thanks! regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 01 Aug 2012 00:36:43 +0200 Kevin Kofler escribió: > I wrote: > > I'm looking into these: > > > > Bill Nottingham wrote: > >> Package komparator (fails to build) > >> Package krecipes (fails to build) > >> Package qalculate-kde (fails to build) > >> Package tesseract (fails to build) > > I fixed these 4 packages now. > > Note that krecipes and tesseract both have newer upstream versions > available: > * krecipes: > - current in Fedora: 1.0-beta2 (kdelibs3) > - current upstream: 2.0-beta2 (kdelibs4) > Note that this will need significant packaging changes, being a KDE > Platform 4 app now (whereas the current Fedora specfile is for the > old kdelibs3 version). > * tesseract: > - current in Fedora: 3.00 > - current upstream: 3.01 (new features, bugfixes etc.) > It looks like they both could use a new (co)maintainer. I've orphaned krecipes since i've not used it in years Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlAYdsgACgkQkSxm47BaWffQrgCgs2zPOb30iFmoAHPhtAsHTXZ4 5d4AoKzJSA6S5wtnAuZNIcTpBBscu0Ym =w+M1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
I wrote: > I'm looking into these: > > Bill Nottingham wrote: >> Package komparator (fails to build) >> Package krecipes (fails to build) >> Package qalculate-kde (fails to build) >> Package tesseract (fails to build) I fixed these 4 packages now. Note that krecipes and tesseract both have newer upstream versions available: * krecipes: - current in Fedora: 1.0-beta2 (kdelibs3) - current upstream: 2.0-beta2 (kdelibs4) Note that this will need significant packaging changes, being a KDE Platform 4 app now (whereas the current Fedora specfile is for the old kdelibs3 version). * tesseract: - current in Fedora: 3.00 - current upstream: 3.01 (new features, bugfixes etc.) It looks like they both could use a new (co)maintainer. For komparator and qalculate-kde, the respective kdelibs3-based versions currently in Fedora are the latest (last?) upstream versions though. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Danga-Socket/el6] fix dependency
commit 3d1aa7ef623dbe392792a290027d24b8f1e5c8bf
Author: Luis Bazan
Date: Tue Jul 31 17:29:13 2012 -0500
fix dependency
perl-Danga-Socket.spec |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
diff --git a/perl-Danga-Socket.spec b/perl-Danga-Socket.spec
index 6d8ed9d..530dc21 100644
--- a/perl-Danga-Socket.spec
+++ b/perl-Danga-Socket.spec
@@ -1,6 +1,6 @@
Name: perl-Danga-Socket
Version:1.61
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Event loop and event-driven async socket base class
License:GPL+ or Artistic
Group: Development/Libraries
@@ -41,6 +41,8 @@ make test
%{_mandir}/man3/Danga::Socket.*
%changelog
+* Tue Jul 31 2012 Luis Bazan - 1.61-2
+- Fix dependency
* Fri Jun 22 2012 Luis Bazan - 1.61-1
- Upstream released new version
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Tom Lane wrote: > The tesseract issue is documented at bz 843275. > > In general, I wish people would be closing out the relevant bugs when > they fix these packages ... Well, that bug was filed only a week ago, and neither the tracker nor the individual bugs were referenced in any way from the nagmail, so how was I expected to know about them? Anyway, I closed the 4 bugs for the FTBFS issues I fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
On Tue, Jul 31, 2012 at 5:58 PM, Josh Boyer wrote: > On Tue, Jul 31, 2012 at 5:52 PM, Dan Allen wrote: > > On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer wrote: > >> > >> On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen > wrote: > >> > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU > after > >> > resume (making VMs run painfully slow). This problem is documented > >> > thoroughly in this BZ: > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=714271 > >> > > >> > This problem is fixed in 3.4.7, which is currently waiting on karma in > >> > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with > -1 > >> > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of > >> > 3.5 > >> > so that we get it sooner? This is really a painful bug. > >> > >> No, but you don't need 3.4.7. The 3.5 update should already contain > >> the same patch that fixed the libvirt issue. Specifically: > >> > >> CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch > >> > >> which is definitely applied to the 3.5 F17 update. > > > > > > Oops, misunderstood your response the first time. > > > > Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3 > so > > that we can get the fix sooner since 3.5 seems to be stuck (due to a > problem > > with cinnamon, according to the CI report). > > That karma is essentially worthless. There's no bug report for the > issue. You're welcome to download the kernel from the update, install > it, and give it positive karma if it works for you. > Ah, gotcha. In fact, I just downloaded the kernel from koji and installed it between replies :) Everything is working great, including the preservation of the cpuset value after resume. Karma given. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
On Tue, Jul 31, 2012 at 5:52 PM, Dan Allen wrote: > On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer wrote: >> >> On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen wrote: >> > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after >> > resume (making VMs run painfully slow). This problem is documented >> > thoroughly in this BZ: >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=714271 >> > >> > This problem is fixed in 3.4.7, which is currently waiting on karma in >> > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 >> > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of >> > 3.5 >> > so that we get it sooner? This is really a painful bug. >> >> No, but you don't need 3.4.7. The 3.5 update should already contain >> the same patch that fixed the libvirt issue. Specifically: >> >> CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch >> >> which is definitely applied to the 3.5 F17 update. > > > Oops, misunderstood your response the first time. > > Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3 so > that we can get the fix sooner since 3.5 seems to be stuck (due to a problem > with cinnamon, according to the CI report). That karma is essentially worthless. There's no bug report for the issue. You're welcome to download the kernel from the update, install it, and give it positive karma if it works for you. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer wrote: > On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen wrote: > > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after > > resume (making VMs run painfully slow). This problem is documented > > thoroughly in this BZ: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=714271 > > > > This problem is fixed in 3.4.7, which is currently waiting on karma in > > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 > > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of > 3.5 > > so that we get it sooner? This is really a painful bug. > > No, but you don't need 3.4.7. The 3.5 update should already contain > the same patch that fixed the libvirt issue. Specifically: > > CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch > > which is definitely applied to the 3.5 F17 update. > Oops, misunderstood your response the first time. Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3 so that we can get the fix sooner since 3.5 seems to be stuck (due to a problem with cinnamon, according to the CI report). (I am still seeing the issue with 3.4.6-2, which is what we would expect). -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer wrote: > On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen wrote: > > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after > > resume (making VMs run painfully slow). This problem is documented > > thoroughly in this BZ: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=714271 > > > > This problem is fixed in 3.4.7, which is currently waiting on karma in > > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 > > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of > 3.5 > > so that we get it sooner? This is really a painful bug. > > No, but you don't need 3.4.7. The 3.5 update should already contain > the same patch that fixed the libvirt issue. Specifically: > > CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch > > which is definitely applied to the 3.5 F17 update. > Hmm. My cpusets are still being modified. I'll reboot and run through the steps to verify I can reproduce it, then I'll report back. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
On 07/31/2012 02:03 PM, Peter Robinson wrote: > On Tue, Jul 31, 2012 at 9:42 PM, Kevin Kofler wrote: >> Are those build.log files really so large that they cannot be kept for >> longer? :-( It's so annoying to see those build failures and to have no idea >> why the builds failed. > > There's 3 per build (src,i686,x64) and they do get pretty big, just > look at the size of a kernel, qt or libreoffice build. Are they at least stored compressed? As such logs are highly repetitive, they're ideal for compression. I tried a kernel build.log with bzip2, and it went from 3.9M to 211K. And qt is better, from 20M to 294k! Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Kevin Kofler writes: > I'm looking into these: > Bill Nottingham wrote: >> Package komparator (fails to build) >> Package krecipes (fails to build) >> Package qalculate-kde (fails to build) >> Package tesseract (fails to build) > but since the build.log files are no longer available, I need to run new > builds first, so it's going to take a while. :-( The tesseract issue is documented at bz 843275. In general, I wish people would be closing out the relevant bugs when they fix these packages ... > I also really dislike the way FTBFS are handled now. Agreed, this shouldn't be nearly so ad-hoc. See recent threads. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Tue, 2012-07-31 at 22:58 +0200, Kevin Kofler wrote: > Akira TAGOH wrote: > > Well, that's true for proprietary fonts, but not necessarily true for free > > fonts. > > Our default font set for most languages, DejaVu, ships carefully designed > hinting bytecode written specifically for FreeType's bytecode interpreter, > and its designers explicitly ask for it to be used rather than the > autohinter. (Some people dislike the font's look with the hinting, but it is > how the designers intended it to look.) It seems like we're really just debating between: * Default to autohinting and tweak specific fonts to use BCI * Default to BCI and tweak specific fonts to use autohinting I'm not sure it makes sense to worry about which approach is best for the _really commonly used core fonts_ in deciding, because whichever approach we take, clearly we'll wind up taking care to make sure those fonts look good. I think the appropriate criterion to use for the decision is which approach tends to work out best for J. Random Font - the large body of less-used fonts both within the distro and outside it. These are the fonts that are _not_ going to get special treatment and will most likely wind up using the default rendering path, so we should pick the default rendering path to work best for _those_ fonts, not for the 'showcase' fonts which we take special care of. -- 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: F17 PM Test day late :) recap
On Tue, 2012-07-31 at 15:35 -0500, Michael Cronenworth wrote: > Adam Williamson wrote: > [large snip] > I hate to snip such a large body, but it will save other eyes from > having to skip past it here. > > > Hope that made sense and made things a bit clearer :) > > I keep up with the test list (and occasionally enter QA meetings) so I > am familiar with what you are attempting to do with TCMS. My suggestion > was purely generic in nature. In the end I think you still need a wiki > extension to handle the data entry as mediawiki is limited in large > database-like data handling. > > For instance: instead of a client app it could be a web app that accepts > test case input from a user and stores it in a database for display on > the corresponding wiki page. The wiki page would have a link on it eg. > "input test data" that would link to the web app. > > In any case I'm sure the Smart Minds of RHQA will figure it out. :P A client app to input results into the existing Test Day and release validation processes might be an interesting place to start, for sure. There was some discussion back in 2009 of using a mediawiki extension called semantic to do this, for some test days. IIRC, the Sugar folks used it that way. See https://lists.fedoraproject.org/pipermail/test/2009-September/084628.html . Unfortunately the test implementation isn't there any more. -- 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: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Benny Amorsen wrote: > As far as I can tell subpixel rendering is disabled in these examples. You need freetype-freeworld for that. It's still patented. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Paul Wouters wrote: > Every single Fedora upgrade in the last few years (with perhaps F17 > the exception) surprised me with superior fonts over the previous > release. We might not have conveyed that, but I've been pretty happy > with what people have done with fonts so far. I did not look at the > latest feature proposal or there impact The latest feature proposal is to basically revert to how things had been up to Fedora 14, unless a font manually opts in to having the hinting information it carries actually used (through a fontconfig configuration file). :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Matthew Garrett wrote: > If it's clear to FESCo that the feature is going to have a significant > impact on packages outside of those directly affected by the change then > FESCo should take that into account when approving the feature. However, > if a feature is well-confined to the packages under the maintainer's > responsibility then second-guessing the maintainer's judgement is > dangerous. Any negative fallout should be dealt with by the maintainer, > and unless that fails I don't see any reason for FESCo to be involved. The feature definitely has a significant impact on freetype. And freetype- freeworld (which I own in RPM Fusion), though that's not in Fedora for obvious reasons. At the very least, you need to talk to Marek Kasik, the Fedora maintainer of freetype. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
On Tue, Jul 31, 2012 at 9:42 PM, Kevin Kofler wrote: > I'm looking into these: > > Bill Nottingham wrote: >> Package komparator (fails to build) >> Package krecipes (fails to build) >> Package qalculate-kde (fails to build) >> Package tesseract (fails to build) > > but since the build.log files are no longer available, I need to run new > builds first, so it's going to take a while. :-( > > Are those build.log files really so large that they cannot be kept for > longer? :-( It's so annoying to see those build failures and to have no idea > why the builds failed. There's 3 per build (src,i686,x64) and they do get pretty big, just look at the size of a kernel, qt or libreoffice build. > I also really dislike the way FTBFS are handled now. In the past, bugs were > filed for the build failures and they were all tracked on a tracking bug in > Bugzilla, so it was always possible to see what needed fixing, and it was > possible for provenpackagers to work on that in a coordinated fashion. These > days, we get surprised with the failures at the last moment when they have > actually been happening for 2 or 3 releases (depending on whether they would > have built on F16 had there been a mass rebuild there)! We really need to > track those failures in Bugzilla again. That's being worked on as discussed in one of these threads, previously it was done by Matt Domsch with access large amounts of enterprise HW, there was a request for someone to step up to expedite the process if you have time. That said every build gets failure emails sent out so you could setup some form of rules to highlight the problem or write a script to query koji on occasion for your failed builds to email you a list of current non builds. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen wrote: > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after > resume (making VMs run painfully slow). This problem is documented > thoroughly in this BZ: > > https://bugzilla.redhat.com/show_bug.cgi?id=714271 > > This problem is fixed in 3.4.7, which is currently waiting on karma in > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 > so that we get it sooner? This is really a painful bug. No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically: CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch which is definitely applied to the 3.5 F17 update. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Akira TAGOH wrote: > Well, that's true for proprietary fonts, but not necessarily true for free > fonts. Our default font set for most languages, DejaVu, ships carefully designed hinting bytecode written specifically for FreeType's bytecode interpreter, and its designers explicitly ask for it to be used rather than the autohinter. (Some people dislike the font's look with the hinting, but it is how the designers intended it to look.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
Actually, just getting 3.4.6-3 would be fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=4325884 -Dan On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen wrote: > Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after > resume (making VMs run painfully slow). This problem is documented > thoroughly in this BZ: > > https://bugzilla.redhat.com/show_bug.cgi?id=714271 > > This problem is fixed in 3.4.7, which is currently waiting on karma in > Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 > karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 > so that we get it sooner? This is really a painful bug. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
can we get kernel 3.4.7 for Fedora 17 to solve libvirt issue?
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=714271 This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
I'm looking into these: Bill Nottingham wrote: > Package komparator (fails to build) > Package krecipes (fails to build) > Package qalculate-kde (fails to build) > Package tesseract (fails to build) but since the build.log files are no longer available, I need to run new builds first, so it's going to take a while. :-( Are those build.log files really so large that they cannot be kept for longer? :-( It's so annoying to see those build failures and to have no idea why the builds failed. I also really dislike the way FTBFS are handled now. In the past, bugs were filed for the build failures and they were all tracked on a tracking bug in Bugzilla, so it was always possible to see what needed fixing, and it was possible for provenpackagers to work on that in a coordinated fashion. These days, we get surprised with the failures at the last moment when they have actually been happening for 2 or 3 releases (depending on whether they would have built on F16 had there been a mass rebuild there)! We really need to track those failures in Bugzilla again. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 PM Test day late :) recap
On 07/31/2012 01:30 PM, Jaroslav Skarvada wrote: During the event it proved that managing dozens of attendants become pain with the current test day infrastructure. For newcomers it was hard to understand how to fill results into wiki (or the concept of the wiki itself). It was even harder for remotees. Several times we received plain text reports and we had to transfer them into wiki ourself. In rush hours there were so many conflicting edits in the wiki that we had to utilize one people who worked only as a wiki corrector. I cannot imagine how to handle e.g. double number of participants with the current system. I think that some more robust and intuitive system is needed to attract/handle more participants. If designed the right way it could also simplify evaluation of results and could give answers to various queries like "what HW worked on which version of Fedora". At the time we looked at various testing system but all of them fell short one way or another thus we decide to settle on something reporters where familiar with as an short stop until we found or came up with something better and we had couple of ideas how that should look like which well let's say was quite different from the traditional tcms. In any case this discussion and how it can be improved belongs on the -test list where the QA community resides... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/25/2012 06:24 PM, Bill Nottingham wrote: > Package libharu (fails to build) Fixed it (libpng 1.5 issues), bumped it to 2.2.1. This required a rebuild of deps (perl-PDF-Haru, EMBOSS), which I also kicked off in rawhide. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 PM Test day late :) recap
Adam Williamson wrote: [large snip] I hate to snip such a large body, but it will save other eyes from having to skip past it here. > Hope that made sense and made things a bit clearer :) I keep up with the test list (and occasionally enter QA meetings) so I am familiar with what you are attempting to do with TCMS. My suggestion was purely generic in nature. In the end I think you still need a wiki extension to handle the data entry as mediawiki is limited in large database-like data handling. For instance: instead of a client app it could be a web app that accepts test case input from a user and stores it in a database for display on the corresponding wiki page. The wiki page would have a link on it eg. "input test data" that would link to the web app. In any case I'm sure the Smart Minds of RHQA will figure it out. :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Le 31/07/2012 19:11, Bill Nottingham a écrit : Package libgtksourceviewmm (fails to build) retired, since nobody claimed it. Package nvi (orphan) Package torque (orphan) Both taken and co-maintainers are very welcome ! best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minor change to with_python3 conditions in specfiles
On Tue, 2012-07-31 at 08:39 -0700, Toshio Kuratomi wrote:
> On Tue, Jul 31, 2012 at 11:29:02AM -0400, David Malcolm wrote:
> > For python packages that build python 2 and 3 subpackages from one
> > shared src.rpm, the current example on
> > http://fedoraproject.org/wiki/Packaging:Python#Example_spec_file
> > has this fragment:
> > %if 0%{?fedora} > 12 || 0%{?rhel} > 6
> > %global with_python3 1
> > ...snip...
> > which was written with the assumption that RHEL 7 onwards will have
> > Python 3 packaged in the same way as we do in Fedora.
> >
> > However, over the long lifetime of a RHEL release there will be multiple
> > upstream Python 3 releases, so RH is thinking of handling Python 3 in
> > RHEL 7 in a different way to how Fedora does it, to better support the
> > possibility of multiple Python 3 stacks - though exactly how it's to be
> > done in RHEL 7 isn't fleshed out yet.
> >
> > Coming back to Fedora, the above means that I'd like to change the above
> > to omit the "rhel" clause, so that it reads:
> >
> > %if 0%{?fedora} > 12
> > %global with_python3 1
> >
> > and to make equivalent changes throughout the specfiles in Fedora, so
> > that such dual src.rpms aren't dual src.rpms in the RHEL context, only
> > in Fedora.
> >
> Tentative +1 It'll need to go to the full FPC. I think that they will
> say that since it's RHEL/EPEL and not Fedora the change is fine. But they'd
> be a lot more comfortable (specifically with the changing of existing
> packages) if they knew what the RHEL method is going to look like.
Well, so would I :(
http://jnovy.fedorapeople.org/scl-utils/ is one possibility
In the meantime, I've opened:
https://fedorahosted.org/fpc/ticket/200
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: F17 PM Test day late :) recap
On Tue, 2012-07-31 at 14:14 -0500, Michael Cronenworth wrote: > Adam Williamson wrote: > > Still, I agree it's not an optimal system, and if anyone has any > > suggestions for alternatives we'd be glad to have them. > > Sounds like you need a client app that will talk to a Fedora infra > server and dump the data into a database. A wiki extension could be made > to connect to that database and display the data. > > I use something[1] like I described to display Bugzilla bugs into wiki > pages. > > [1] http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports I didn't really cover the problem space very well, sorry for that. It's one of those things that gets bigger each time you look at it. In traditional 'big grown-up QA' terms, what we're doing is using the Wiki as a TCMS - test case management system. Real big grown-up QA tends to base a lot of work around these, which are pretty complex projects that aim to handle both the creation and management of test cases, and tracking test results. Test Days are really just one application, is the thing - at least looking at things from the traditional perspective, it wouldn't make a lot of sense to write a small, Test Day-specific client/server system, because really Test Days are just events where we get lots of people together to iterate intensively over a specific set of test cases. In theory the test cases aren't 'special' - they can be run in other contexts besides Test Days, which might want different things from the results. TCMSes tend to wind up as big sophisticated beasts which can track results in lots of different ways. TCMSes unfortunately tend to be built with an assumption that they'll be used by a small group of trusted and relatively savvy users: they'll be used by a dedicated QA team in a 'closed' environment, essentially. So they don't go out of their way to be easy to use and often aren't architected in a way which would make them particularly easy to deploy in an environment like Fedora, where we want to be open to engagement by very casual testers and people who aren't necessarily trusted and experienced QA members. There are several open source TCMSes and similar systems that we could, in theory, use for Fedora QA; we've evaluated several of them in the past. The 'obvious' candidate for Fedora is Nitrate, which is Red Hat's TCMS - https://fedoraproject.org/wiki/Nitrate . Red Hat QE, which is a much more grown-up and 'proper' effort than Fedora QA (but also basically a closed shop within RH), bases all its work around Nitrate. Even Nitrate, though, has quite a lot of disadvantages compared to the Wiki when it comes to the unique context of Fedora testing - https://fedoraproject.org/wiki/Tcms_Comparison is an evaluation of nitrate against the various features of 'wiki as a TCMS' which we've found useful or which have become integrated into the way in which we do testing for Fedora. Other open source TCMSes all have similar issues, or more, in the context of Fedora QA. None of them would be a straightforward drop-in replacement for the way we currently order things, with clear advantages and only a few drawbacks - they'd all represent a significant trade-off in capability and would take a lot of engineering work and re-design of our processes. This doesn't mean we shouldn't do it, of course, but it's not a straightforward call. There are, of course, always other ways of looking at things. You could take the point of view that a lot of successful open source code resulted from someone starting out by doing something small in a simplistic, unsophisticated way, and building from there. Perhaps the fact that we've never found a drop-in TCMS that entirely makes sense for Fedora is an indication that we really ought to grow our own, and making a simple limited system specifically for Test Days, or some other specific use Fedora makes of test cases, wouldn't be such a bad way to start out: I'm certainly sympathetic to the view that sometimes it works out better to do a good job on a small task in a relatively short time with concrete results than to look at everything Fedora QA would ultimately want from a TCMS and try to knock it all off on the first try. So that's a very longwinded way of saying - 'yes, with reservations' :). I could certainly see value in an effort to write a relatively simple system for handling test cases and results for Fedora test days, tailored to the somewhat unusual requirements of collaborative testing for an open project like Fedora. But I think if anyone's going to do it, they should do it with all of the above in mind - bear in mind that they're not exactly breaking new ground, but approaching a relatively mature field from a slightly unique angle. Be aware that, ultimately, what we really want is a more complex and flexible system around which we could base all of Fedora's QA efforts; something that can _only_ ever work for the Test Day format would be a bit of a dead end. Hope that made sense and made things
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
On Tue, Jul 31, 2012 at 2:32 PM, Jon Ciesla wrote: > On Tue, Jul 31, 2012 at 12:11 PM, Bill Nottingham wrote: >> Before we branch for Fedora 18, as is custom, we will block currently >> orphaned packages and packages that have failed to build since Fedora 16. >> >> The following packages are currently orphaned, or fail to build. If >> you have a need for one of these packages, please pick them up. >> If no one claims any of these packages, they will be blocked before >> we branch for Fedora 18. We will block these packages on Monday, August 06. >> >> Note that if you're receiving this mail directly, it's because you are >> a co-maintainer of one of these packages. Please work with your >> comaintainers to take up maintenance. >> > >> Package freenx-client (fails to build) > > Fixed. > > >> Package pngcrush (fails to build) > > Fixed. > >> >> Package tritonus (orphan) > > Taken. > > -J Too many recipients. . . -J > -- > http://cecinestpasunefromage.wordpress.com/ > > in your fear, seek only peace > in your fear, seek only love > > -d. bowie -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote: > .. and it's stuck there. I need to press Reset button to continue. > It did read the CD for a while until it got frozen. Yeah, that's definitely a bug then. We'll see if we can reproduce it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 08:16:29PM +0100, Matthew Garrett wrote: > On Tue, Jul 31, 2012 at 09:41:48PM +0300, Pasi Kärkkäinen wrote: > > Secure boot not enabled > > error: failure reading sector 0x40 from `cd0Ž. > > Try changing the firmware from AHCI to IDE mode. We're pretty sure this > is a bug in Intel's AHCI driver, but we'll try to figure out a > workaround in grub. > Ok, I changed from AHCI to IDE mode, and now I get: - Booting `Fedora 17Ž Secure boot not enabled - .. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Richard Shaw (hobbes1...@gmail.com) said: > Whoops, sorry about the reply to all (dang gmail)... I'll repost just > to the devel mailing list (I canceled the original). > > On Tue, Jul 31, 2012 at 12:11 PM, Bill Nottingham wrote: > > Before we branch for Fedora 18, as is custom, we will block currently > > orphaned packages and packages that have failed to build since Fedora 16. > > > > The following packages are currently orphaned, or fail to build. If > > you have a need for one of these packages, please pick them up. > > If no one claims any of these packages, they will be blocked before > > we branch for Fedora 18. We will block these packages on Monday, August 06. > > Will the FTBFS packages be orphaned prior to being blocked? It would > seem a grace period would be a good idea so people can pick them up if > the current owner is non-responsive. Not directly. But if you have a fix and can get a proven packager to apply and build it, they won't be blocked. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
On Tue, Jul 31, 2012 at 11:11 AM, Bill Nottingham wrote: > Package gnofract4d (orphan) > comaintained by: firewing I have taken ownership of this one. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 09:41:48PM +0300, Pasi Kärkkäinen wrote: > Secure boot not enabled > error: failure reading sector 0x40 from `cd0Ž. Try changing the firmware from AHCI to IDE mode. We're pretty sure this is a bug in Intel's AHCI driver, but we'll try to figure out a workaround in grub. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 PM Test day late :) recap
Adam Williamson wrote: > Still, I agree it's not an optimal system, and if anyone has any > suggestions for alternatives we'd be glad to have them. Sounds like you need a client app that will talk to a Fedora infra server and dump the data into a database. A wiki extension could be made to connect to that database and display the data. I use something[1] like I described to display Bugzilla bugs into wiki pages. [1] http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Whoops, sorry about the reply to all (dang gmail)... I'll repost just to the devel mailing list (I canceled the original). On Tue, Jul 31, 2012 at 12:11 PM, Bill Nottingham wrote: > Before we branch for Fedora 18, as is custom, we will block currently > orphaned packages and packages that have failed to build since Fedora 16. > > The following packages are currently orphaned, or fail to build. If > you have a need for one of these packages, please pick them up. > If no one claims any of these packages, they will be blocked before > we branch for Fedora 18. We will block these packages on Monday, August 06. Will the FTBFS packages be orphaned prior to being blocked? It would seem a grace period would be a good idea so people can pick them up if the current owner is non-responsive. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. We will block these packages on Monday, August 06. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance. Package UnihanDb (fails to build) Package apache-commons-launcher (fails to build) Package archmage (orphan) Package autoarchive (fails to build) Package boolstuff (orphan) Package boolstuff (orphan) Package cmucl (orphan) comaintained by: green Package eboard (fails to build) Package eclipse-collabnet-merge (fails to build) Package eclipse-emf-query (fails to build) Package eclipse-emf-transaction (fails to build) Package eclipse-emf-validation (fails to build) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mdt-ocl (fails to build) Package eclipse-mdt-uml2 (fails to build) Package ext3grep (fails to build) Package ezmorph (fails to build) Package fillmore-lombard (fails to build) comaintained by: salimma Package freenx-client (fails to build) Package gant (fails to build) Package gconf-cleaner (fails to build) Package globalplatform (orphan) Package gnofract4d (orphan) comaintained by: firewing Package gnome-do-docklets (fails to build) Package gooddata-cl (fails to build) Package gpshell (orphan) Package gtkmm-utils (orphan) Package gtkmm-utils (orphan) Package hamster-applet (orphan) Package hartke-aurulent-sans-fonts (orphan) Package ibus-table-code (fails to build) Package ibus-table-others (fails to build) comaintained by: nkumar Package jpoker (fails to build) Package json (orphan) Package json-lib (fails to build) Package k12linux-quick-start-guide (orphan) Package kadu (fails to build) comaintained by: gajownik radekl Package komparator (fails to build) Package krecipes (fails to build) Package ksplice (fails to build) Package libcrystalhd (fails to build) comaintained by: kwizart Package libgdbus (fails to build) Package libgtkhotkey (orphan) Package libgtksourceviewmm (fails to build) Package libharu (fails to build) Package libhid (fails to build) Package libkml (fails to build) Package libqttracker (fails to build) comaintained by: jreznik Package libsoup22 (orphan) Package libsoup22 (orphan) Package man-pages-it (orphan) Package man-pages-ko (orphan) Package metapixel (fails to build) Package mimetic (fails to build) Package mingw-libp11 (orphan) comaintained by: rjones Package mingw-opensc (orphan) comaintained by: rjones Package mod_scgi (fails to build) Package munipack (fails to build) Package natus (fails to build) Package ntfs-config (fails to build) Package nvi (orphan) Package perl-Nagios-Plugin-Beanstalk (orphan) Package pfqueue (orphan) Package pianobooster (fails to build) Package pino (fails to build) Package pngcrush (fails to build) Package polyester (orphan) Package polyester3 (orphan) Package printoxx (fails to build) Package putty (fails to build) comaintained by: tremble Package pxe-kexec (fails to build) Package python-chm (orphan) Package python-modjkapi (fails to build) Package python-pywt (fails to build) Package python-remoteobjects (orphan) Package python-typepad (orphan) Package qalculate-kde (fails to build) Package ragel (fails to build) Package raul (fails to build) Package scite (fails to build) Package selenium-core (fails to build) Package selenium-remote-control (fails to build) Package sofsip-cli (fails to build) comaintained by: itamarjp Package specto (fails to build) Package subcommander (fails to build) Package svnkit (fails to build) Package tesseract (fails to build) Package torque (orphan) Package tritonus (orphan) comaintained by: bsjones Package typepad-motion (orphan) Package upstart (orphan) Package winwrangler (orphan) Package wmfire (fails to build) Package xaos (fails to build) Package xdrawchem (fails to build) Package xesam-glib (fails to build) List of deps left behind by packages which are orphaned or fail to build: Removing: freenx-client kdenetwork requires pkgconfig(nxcl) = 1.0 Removing: ksplice fedora-ksplice requires ksplice = 0.9.9-2.fc15 Removing: libgtkhotkey synapse requires libgtkhotkey.so.1 Removing: libharu EMBOSS requires libhpdf-2.1.0.so EMBOSS requires libharu-devel = 2.1.0-3.fc15 EMBOSS-libs requires libhpdf-2.1.0.so libeplplot requires libhpdf-2.1.0.so perl-PDF-Haru requires libhpdf-2.1.0.so perl-PDF-Haru requires libharu-devel = 2.1.0-3.fc15 Removing: libsoup22 libopensync-plugin-syncml requires libsoup22-devel = 2.2.105-9.fc15 libsyncml requires libsoup-2.2.so.8 libsyncml require
Re: F17 PM Test day late :) recap
On Tue, 2012-07-31 at 09:30 -0400, Jaroslav Skarvada wrote: > During the event it proved that managing dozens of attendants become > pain with the current test day infrastructure. For newcomers it was > hard to understand how to fill results into wiki (or the concept of > the wiki itself). It was even harder for remotees. Several times we > received plain text reports and we had to transfer them into wiki > ourself. In rush hours there were so many conflicting edits in the > wiki that we had to utilize one people who worked only as a wiki > corrector. I cannot imagine how to handle e.g. double number of > participants with the current system. I think that some more robust > and intuitive system is needed to attract/handle more participants. > If designed the right way it could also simplify evaluation of results > and could give answers to various queries like "what HW worked on > which version of Fedora". > > So again many thanks to all attendees and supporters and hope to see > you during F18 PM test day :) Thanks for the recap and the process feedback! Yeah, the wiki system certainly has limitations. The problem is that any replacement is likely to be significantly more complex on the infrastructure side and also for Test Day organizers than simply using the Wiki, so it's something of a trade-off; we've never found any kind of 'drop-in' system that does exactly what we want. At least as far as we've found so far, any replacement would make it somewhat more difficult to organize a Test Day. I've run X Test Weeks for several releases which can get upwards of 100 responses sometimes, and the Wiki has mostly held out to that. Still, I agree it's not an optimal system, and if anyone has any suggestions for alternatives we'd be glad to have them. -- 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: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 11:11:07AM -0400, Peter Jones wrote: > On Mon, 2012-07-30 at 21:23 +0300, Pasi Kärkkäinen wrote: > > On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote: > > > > > > > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be > > > > >able to > > > > >confirm that somehow.. > > > > > > > > Well, either the bootloader or the kernel (or something after that) is > > > > not > > > > succeeding If Windows works in UEFI mode on the machine, then we would > > > > still > > > > consider it to be a bug we should fix, even if the firmware fails to > > > > comply to > > > > precisely to our previous interpretation of the spec. > > > > > > > > > > I'll try installing Windows aswell. > > > > > > > I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. > > After installation I verified it had created GPT system partition, > > and also I used "bcdedit" to verify windows has booted using bootmgfw.efi > > and winload.efi. > > > > So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode. > > > > Should I open a fedora bugzilla ticket? > > Probably - but first, could you try booting the iso at > http://pjones.fedorapeople.org/sb/boot-sb4.iso ? It's using a boot > process that's a bit different (and more like what F18 will have), so > and the code is different enough that there's some chance any given > bug is incidentally fixed. > with that boot-sb4.iso I get first the grub 2.00 menu, and after choosing Fedora 17 entry: -- Booting `Fedora 17` Secure boot not enabled error: failure reading sector 0x40 from `cd0Ž. Press any key to continue... -- And it's stuck there.. pressing "any key" doesn't help, and ctrl+alt+del doesn't work either. I have to press Reset button. I tried burning the iso image twice to different cdr's.. didn't help. Any ideas? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket 413 - "Server is unwilling to perform" when running ldapmodify on nsds5ReplicaStripAttrs
https://fedorahosted.org/389//ticket/413/ https://fedorahosted.org/389/attachment/ticket/413/0001-Ticket-413-Server-is-unwilling-to-perform-when-runni.patch -- Mark Reynolds Senior Software Engineer Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F17 PM Test day late :) recap
On Tue, 2012-07-31 at 10:40 -0700, Adam Williamson wrote: > On Tue, 2012-07-31 at 09:30 -0400, Jaroslav Skarvada wrote: > > > During the event it proved that managing dozens of attendants become > > pain with the current test day infrastructure. For newcomers it was > > hard to understand how to fill results into wiki (or the concept of > > the wiki itself). It was even harder for remotees. Several times we > > received plain text reports and we had to transfer them into wiki > > ourself. In rush hours there were so many conflicting edits in the > > wiki that we had to utilize one people who worked only as a wiki > > corrector. I cannot imagine how to handle e.g. double number of > > participants with the current system. I think that some more robust > > and intuitive system is needed to attract/handle more participants. > > If designed the right way it could also simplify evaluation of results > > and could give answers to various queries like "what HW worked on > > which version of Fedora". > > > > So again many thanks to all attendees and supporters and hope to see > > you during F18 PM test day :) > > Thanks for the recap and the process feedback! > > Yeah, the wiki system certainly has limitations. The problem is that any > replacement is likely to be significantly more complex on the > infrastructure side and also for Test Day organizers than simply using > the Wiki, so it's something of a trade-off; we've never found any kind > of 'drop-in' system that does exactly what we want. At least as far as > we've found so far, any replacement would make it somewhat more > difficult to organize a Test Day. > > I've run X Test Weeks for several releases which can get upwards of 100 > responses sometimes, and the Wiki has mostly held out to that. > > Still, I agree it's not an optimal system, and if anyone has any > suggestions for alternatives we'd be glad to have them. Forgot to mention - please consider the Test Day SOP to be guidelines, not hard and fast rules - if you think of a way to adjust the process which you think would be beneficial for your Test Day, by all means go ahead and do it, no-one will be angry! So if you can think of any methods that you think might improve the ease of the feedback process, please do go ahead and try them for the f18 PM test day, and let us know how they go. -- 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: [ACTION REQUIRED v4] Retiring packages for F-18
On 12-07-30 4:46 PM, Jerry James wrote: I'm happy to take it, if you will orphan it in pkgdb. Great, done! Regards, Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, 2012-07-30 at 21:23 +0300, Pasi Kärkkäinen wrote: > On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote: > > > > > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be > > > >able to > > > >confirm that somehow.. > > > > > > Well, either the bootloader or the kernel (or something after that) is not > > > succeeding If Windows works in UEFI mode on the machine, then we would > > > still > > > consider it to be a bug we should fix, even if the firmware fails to > > > comply to > > > precisely to our previous interpretation of the spec. > > > > > > > I'll try installing Windows aswell. > > > > I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. > After installation I verified it had created GPT system partition, > and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and > winload.efi. > > So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode. > > Should I open a fedora bugzilla ticket? Probably - but first, could you try booting the iso at http://pjones.fedorapeople.org/sb/boot-sb4.iso ? It's using a boot process that's a bit different (and more like what F18 will have), so and the code is different enough that there's some chance any given bug is incidentally fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 Feature Freeze in one week - Tuesday Aug 07
REMINDER: Tuesday, August 07 is the Feature Freeze for Fedora 18, the Planning & Development phase ends. At this point, all accepted features should be substantially complete, and testable. Additionally, if a feature is to be enabled by default, it must be so enabled at Feature Freeze. Check [1] and [2]. Feature owners - please make sure to update the percentage of completion and the last updated date. If you're not sure to make the deadline, please let me know and update current status to reflect the issues you hit. It's going to help me a lot to understand what's going on with your feature. Features that do not make Feature Freeze in testeable state will be submitted to FESCo for re-review to assure we should promote them as Features. Currently we have 61 Features approved by FESCo and one still waiting for approval. In case of any questions etc., feel free to contact me - I'm still very friendly Feature Wrangler, especially to all Feature owners with 85%+ percentage of completion ;-) Jaroslav [1] https://fedoraproject.org/wiki/Feature_Freeze_Policy [2] https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze -- Jaroslav Řezník Your Feature Wrangler Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://www.redhat.com/ ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 PM Test day late :) recap
Hi, thanks all for attending F17 PM Test day, late :) recap follows. General results: Number of attendees: 39 Reports received: 52 Unique machines tested: 49 Bugs reported (all trackers counted): 21 Bugs closed so far: 13 Test cases (TC) results (in braces are F16 results): TC passed: 82.48 % (79 %) TC passed with warning: 3.62 % (7 %) TC failed: 13.90 % (14 %) Power consumption benchmark results (active idle test, data mostly taken from ACPI battery by provided script): Average power consumption (average from all machines): 23.36 W Average power savings with tuned enabled: 1.91 W List of bugs reported: FRD Bug 47965 - I can't modify brightness with nVidia 1000m Quadro Bug 713687 - [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 67s! [modprobe:499] in ath5k_pci_eeprom_read Bug 745202 - gnome-shell does not display correctly with NV3x adapters - multicolor corruption of panel, Shell-style menus and text [nvfx] Bug 783715 - Running bluetooth.service makes soft blocked wifi be hard blocked after resume from suspend Bug 784741 - [abrt] kernel: WARNING: at lib/list_debug.c:53 __list_del_entry+0xa1/0xd0() ( Bug 797559 - [abrt] kernel: WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xfa/0x100() Bug 807855 - Please add support for our new tuned 2.0 Bug 809294 - SELinux is preventing /usr/bin/python from using the 'signal' accesses on a process. I was running: systemctl start tuned.service Bug 809812 - No brigtness controls in gnome-control-center screen on lenovo x200 Bug 809832 - avc on tuned-adm profile powersave Bug 809836 - SELinux is preventing tuned from 'execute_no_trans' accesses on the file /usr/lib/tuned/balanced/script.sh. Bug 809837 - SELinux is preventing ls from 'getattr' accesses on the blk_file /dev/sdb. Bug 809838 - SELinux is preventing sysctl from 'getattr' accesses on the file /proc/sys/kernel/nmi_watchdog. Bug 810127 - Brightness level indicator is not shown when changing brightness Bug 810202 - [abrt] kernel: [809524.902004] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3415! Bug 810584 - "Brightness and Lock" window does not show settings for Brightness Bug 810616 - [HP Elitebook 8460p] Pressing Fn+Brightness control keys has no effect Bug 811018 - HP Elitebook 8560w can't suspend or hibernate Bug 813899 - [abrt] kernel: WARNING: at drivers/base/firmware_class.c:538 _request_firmware+0x488/0x4d0() Bug 813900 - [abrt] kernel: WARNING: at drivers/base/firmware_class.c:538 _request_firmware+0x488/0x4d0() Bug 813904 - SELinux is preventing /usr/libexec/gstreamer-0.10/gst-plugin-scanner from 'create' accesses on the directory .orc. 49 machines (mostly laptops) seems to be nice number to get us a little overview how good (or bad) we are doing. As you probably know we also held this event on-site in Red Hat Brno office. There was prepared meeting room with internet connection, various F17 test day live CDs/USBs, USB CD-ROMs, serial cables for catching kernel backtraces and calibrated Chroma 66202 wattmeter so attendees was able to precisely measure power consumption of their machines. We also focused on newcomers. We had there three spare laptops and newcomers without their own HW could play with Fedora there. They could also (virtually) attend test day with these machines to observe that it is really easy task (one of the goal of this event was to encourage them to attend future test days on their own). I can say that the event went well, but available capacity (space) was a bit underestimated - we did not expect such an interest :). During the event it proved that managing dozens of attendants become pain with the current test day infrastructure. For newcomers it was hard to understand how to fill results into wiki (or the concept of the wiki itself). It was even harder for remotees. Several times we received plain text reports and we had to transfer them into wiki ourself. In rush hours there were so many conflicting edits in the wiki that we had to utilize one people who worked only as a wiki corrector. I cannot imagine how to handle e.g. double number of participants with the current system. I think that some more robust and intuitive system is needed to attract/handle more participants. If designed the right way it could also simplify evaluation of results and could give answers to various queries like "what HW worked on which version of Fedora". So again many thanks to all attendees and supporters and hope to see you during F18 PM test day :) thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut-20-51 - Heads up
On Mon, 2012-07-09 at 09:44 +0200, Harald Hoyer wrote: > # for i in 10-console.rules 10-dm.rules 11-dm.rules 13-dm-disk.rules \ > 40-multipath.rules 50-firmware.rules 50-udev-default.rules 50-udev.rules \ > 59-persistent-storage.rules 60-cdrom_id.rules 60-pcmcia.rules \ > 60-persistent-storage.rules 61-dmraid-imsm.rules \ > 61-persistent-storage-edd.rules 61-persistent-storage.rules \ > 64-device-mapper.rules 64-lvm.rules 64-md-raid.rules \ > 65-md-incremental-imsm.rules 71-biosdevname.rules \ > 80-btrfs.rules 80-drivers.rules 95-dm-notify.rules 95-late.rules \ > 95-udev-late.rules ; do [[ -f $i ]] && rm -vf /etc/udev/rules.d/$i; done This should be "...; do [[ -f /etc/udev/rules.d/$i ]] && ...". Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
