[Bug 568172] libvirt does not block signals, causing virt-top to fail when getting sigwinch from a terminal resize
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Wayne Sun g...@redhat.com changed: What|Removed |Added Flag||needinfo?(berra...@redhat.c ||om) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Broadcom wifi drivers in F-14?
Hi, On 09/14/2010 01:31 PM, David Woodhouse wrote: On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: IIRC they require a firmware blob that has a license that we cannot distribute unlike say the Intel firmwares. I could be wrong though. That's still true of the b43 firmware for older (pre-802.11n) devices, but the firmware to go with their new driver is now in linux-firmware.git. Hmm, now that they are trying to be opensource friendly, can't we get them to license the old firmware under the same license as the new one? It would be great to be able to ship the old firmware and haver older broadcom cards work out of the box. David do you have a contact inside Broadcom to talk to about this, and could you ask? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 568172] virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 --- Comment #9 from Richard W.M. Jones rjo...@redhat.com 2010-09-15 02:27:10 EDT --- (In reply to comment #7) When resize the window from right side to left or reverse, while reach to the minimum size, the command will exit. But did not get error info in strace. So there still have problem, move to Assigned. Might be because the window is too small. I think there is a test for that which may cause it to exit. Thanks for looking at this, I'll need to investigate this further. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Broadcom wifi drivers in F-14?
Hans de Goede wrote on 15.09.2010 08:31: On 09/14/2010 01:31 PM, David Woodhouse wrote: On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: IIRC they require a firmware blob that has a license that we cannot distribute unlike say the Intel firmwares. I could be wrong though. That's still true of the b43 firmware for older (pre-802.11n) devices, but the firmware to go with their new driver is now in linux-firmware.git. Hmm, now that they are trying to be opensource friendly, can't we get them to license the old firmware under the same license as the new one? It would be great to be able to ship the old firmware and haver older broadcom cards work out of the box. David do you have a contact inside Broadcom to talk to about this, and could you ask? Just FYI, a question like that was already raised in public a few days ago, but remains unanswered as of now afaics: http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/8460/focus=55447 CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Anaconda TranslationKeyboard Test Day - Thursday 2010-09-16
Greetings Testers, Anaconda TranslationKeyboard Test Day is coming up tomorrow: https://fedoraproject.org/wiki/Test_Day:Current This day will mainly focus on the translation and keyboard in different languages during installation. Test cases have been well prepared on the wiki page with the help of l10n[1] and i18n[2] team, and the steps are clear for your reference. So if you used to install in your native language or know a second language besides English, this is an opportunity to try them out and help discover the issues in this area. F-14-beta-TC1 images are available for testing in this event, executing tests in virtual guest is also acceptable if you don't have extra space in bare metal. The Test Day will run all day in Freenode IRC #fedora-test-day. See you there!:) [1] https://fedoraproject.org/wiki/L10n [2] https://fedoraproject.org/wiki/I18N -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ 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: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Toshio Kuratomi wrote on 15.09.2010 04:54: On Tue, Sep 14, 2010 at 07:02:33PM -0600, Kevin Fenzi wrote: On Tue, 14 Sep 2010 20:48:13 -0400 Máirín Duffy du...@fedoraproject.org wrote: Only 5 of the 9 FESCo members voted on this issue. If all 9 had voted, even with the current 3 for / 2 against vote, systemd could easily have enough votes for inclusion in F14. I have a couple of questions for you, FESCo, since I honestly don't know and maybe would feel more comfortable knowing: ok. - Has there been any consideration for formalizing the acceptable of absentee votes? no, but perhaps there should be? Just a side note: That has problems of its own, as those votes might happen before new aspects come up in the IRC discussion that normally precedes the votes in IRC meetings... - How many members must be present at a meeting for a voting decision to be considered valid? My understanding: A quorum (ie, 5 of 9). Note, in the distant past, FESCo's rule was majority of the folks present with an attempt made at unanimity by the present members by resolving (as much as possible) their differences in opinion. This was actually stated in meetings but I don't think that it made it to the wiki -- thl might know as that was during his tenure as chair. However, I don't believe this rule has been followed in a *long* time so it might just be a historical footnote to this conversation. Yes, back then we afaics tried a whole lot harder to make everyone happy. That included even non-FESCo members that tried to raise options on a particular topic on the list or in IRC meeting; we even let those non-FESCo-members share a (mostly unofficial) vote on IRC, as those votes often influenced how FESCo member voted (which IMHO was a good thing). Some of that obviously would be much harder to do these days, as FESCo has lot more to deal with and Fedora has way more contributors. But that doesn't mean part of it could be tried again. CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 3:52 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Sep 15, 2010 at 01:05:34AM +0200, Lennart Poettering wrote: So, we closed all blocker bugs, we worked through the vast majority of other bugs. I dealt with almost all issues raised in Bill's list, only few small issues left. While there are some bugs open, we did our homework. I was kept in the impression during the last week that these are the criteria to get systemd into F14. But what happens? Out of nowhere completely new criteria are created, and used to bring this project down. The criteria primarily flowed from Notting's discussion of systemd acceptance criteria. Was that well communicated beforehand? No. Did all of those criteria get translated into appropriate bugzilla entries? No. Should we have handled this case better? Absolutely yes. I think the main point here wasn't there are bugs #X, #Y and #Z that can't be fixed in time so we should revert but a we have a bad feeling / are nervous so lets revert ... the later isn't really a technical decision basis and can (and here it did) piss of the one working on said feature. (I know it wasn't *that* simple but that was mostly it). The acceptance criteria should have been present from day one (i.e the day the feature was accepted) not shortly before beta (which pretty much limits the time to work to met them). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 629229] new version available and shipped version has disappeared
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=629229 Mark Chappell trem...@tremble.org.uk changed: What|Removed |Added CC||trem...@tremble.org.uk Status Whiteboard||UpdatePackage --- Comment #1 from Mark Chappell trem...@tremble.org.uk 2010-09-15 03:37:00 EDT --- http://koji.fedoraproject.org/koji/taskinfo?taskID=2468796 Looks like this should be an easy rebase... rawhide spec builds fine. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F12/ Cannot update
On Tue, Sep 14, 2010 at 11:50 PM, Michael Cronenworth m...@cchtml.com wrote: Andrea Musuruane wrote: Why xulrunner has been built against this and pushed to stable? Because Firefox/Thunderbird maintainers have the ability to Push-To-Stable regardless of what the Fedora package policies say. Harrumph. I have previously complained of this fact before when these packages broke things but my complaints fell on deaf ears. What is the correct course of action to stop this nonsense? File a ticket with FESCo. We should have *all* packages go trough updates-testing, regardless of who's the maintainer or what's the reason of an update. If FESCo finds out that this is a bug (some packages can be pushed to stable directly) in Bodhi, fix it, ASAP. rant My security fix build was rejected going to stable directly, because it could break anything (freeciv game), so i expect critical packages for end users have to go trough as well. /rant -- Best regards Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On 14 September 2010 23:01, Kevin Fenzi ke...@scrye.com wrote: 21:33:35 nirik The other 2 items I had were: 21:33:56 nirik application installer issues 21:33:57 nirik https://bugzilla.redhat.com/show_bug.cgi?id=488968 21:34:04 nirik and 21:34:05 nirik BuildIdBuild infrastructure 21:34:06 nirik https://fedorahosted.org/fedora-infrastructure/ticket/2387 21:34:57 mclasen that needs more time, I'd say 21:35:08 nirik ok, will close out if no one has anything further... Well, that was enlightening. Do you think someone from FESCo could write something about https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and make a decision please. Until then, all gnome-packagekit, app-install and kpackagekit work will be halted. I don't want to be in the same situation as Lennart where I've done loads of work and then a few influential people in Fedora just to turn around and say no. On 15 September 2010 00:05, Lennart Poettering mzerq...@0pointer.de wrote: Everybody has a different idea of what Fedora should be, but mine is definitely not one where people with negative energy make the rules and then win by them. My sentiments exactly. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Twitter support broken in Pino
2010/9/10 Bill Nottingham nott...@redhat.com: Bill Nottingham (nott...@redhat.com) said: The other option would be to switch to gwibber (which has been un-desktop-couched in Fedora 14, so it theoretically won't bring in nearly as much to the live image. So, actual testing - building a livecd with gwibber instead of pino brings in the following packages: PyXML 4185378 python-sexy 61194 python-oauth 50819 python-imaging 1381510 python-distutils-extra 133515 mx 6599955 libsexy 102616 gwibber 2367779 Resulting live image was 704MB. Note that not all of these appear to *actually* be required by gwibber - bug 632621 filed. Bill -- Hi all, I'll update pino to the latest snapshot for F14+ soon which already add support for oauth. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F12/ Cannot update
On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen thom...@fedoraproject.org wrote: rant My security fix build was rejected going to stable directly, because it could break anything (freeciv game), so i expect critical packages for end users have to go trough as well. /rant The web browser is the attack surface #1 in desktop systems so maybe just maybe a security fix there is considered more important than one in a game? ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F12/ Cannot update
On Wed, Sep 15, 2010 at 11:05 AM, drago01 drag...@gmail.com wrote: On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen thom...@fedoraproject.org wrote: rant My security fix build was rejected going to stable directly, because it could break anything (freeciv game), so i expect critical packages for end users have to go trough as well. /rant The web browser is the attack surface #1 in desktop systems so maybe just maybe a security fix there is considered more important than one in a game? ;) I agree with you there. Though, if it breaks something the uproar is even bigger. We have proventesters (myself is one of them, just ping me in IRC or per mail) to handle a be-quick-out-the-door-to-stable-updates :) -- Best regards Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F12/ Cannot update
On Wed, Sep 15, 2010 at 11:01 AM, Andrea Musuruane musur...@gmail.com wrote: On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen thom...@fedoraproject.org wrote: File a ticket with FESCo. We should have *all* packages go trough updates-testing, regardless of who's the maintainer or what's the reason of an update. If FESCo finds out that this is a bug (some packages can be pushed to stable directly) in Bodhi, fix it, ASAP. Opened ticket 466: https://fedorahosted.org/fesco/ticket/466 Thank you. -- Best regards Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Wed, 2010-09-15 at 08:31 +0200, Hans de Goede wrote: Hi, On 09/14/2010 01:31 PM, David Woodhouse wrote: On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: IIRC they require a firmware blob that has a license that we cannot distribute unlike say the Intel firmwares. I could be wrong though. That's still true of the b43 firmware for older (pre-802.11n) devices, but the firmware to go with their new driver is now in linux-firmware.git. Hmm, now that they are trying to be opensource friendly, can't we get them to license the old firmware under the same license as the new one? It would be great to be able to ship the old firmware and haver older broadcom cards work out of the box. David do you have a contact inside Broadcom to talk to about this, and could you ask? I've asked, but they're scared of it. They seem to think that they could be prosecuted even for *enabling* people to use the open source b43 driver, because you have the possibility of hacking that driver not to conform to the regulatory requirements. Shipping the binary-only firmware with a licence which permits us to distribute it as part of a Linux distribution could be seen as 'enabling' the use of the b43 driver, so they're reluctant to do so. Even if their licence doesn't mention Linux at all, but just allows you to distribute it for use with their hardware in general. The whole thing seems completely nonsensical to me -- it's well known that people reverse-engineer and hack up binary drivers too, so there's nothing stopping those users from breaking the regulations either. There are hacks out there which let you boost the TX power with the binary drivers, for example. If the Broadcom lawyers really do suffer from such paranoid delusions, they should never have shipped hardware which requires *any* software assistance to conform to the law. In the meantime, people are quite happily shipping the 'offending' b43 driver in all parts of the world without hearing *anything* from the authorities. And yet the Broadcom lawyers still seem to cling to their fantasy that a hackable Open Source driver somehow puts them at more risk than a just-as-hackable closed-source driver. Fixing bugs and making other improvements in the closed source driver is much harder than it is in the open driver, of course -- but if all you want to do is remove restrictions on available channels and tweak things like TX power, that's actually fairly easy with the binary drivers. That's why I say 'just as hackable'. It's also much *easier* to distribute such hacks for the binary drivers; it's often just a case of 'zero the byte at 0x5d3 with a hex editor', which is easier for most users than actually patching source code and rebuilding a driver properly. The Broadcom position seems to be entirely crack-inspired, if it's based on the notion that a binary driver cannot be modified to break the regulations. That assumption is demonstrably false. -- dwmw2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 15 Sep 2010, drago01 wrote: I think the main point here wasn't there are bugs #X, #Y and #Z that can't be fixed in time so we should revert but a we have a bad feeling / are nervous so lets revert ... the later isn't really a technical decision basis and can (and here it did) piss of the one working on said feature. In this case the bad feeling is justified, because there were too many problems too late in the release cycle. It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. The acceptance criteria should have been present from day one (i.e the day the feature was accepted) not shortly before beta (which pretty much limits the time to work to met them). I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 15 or rawhide?
On Tue, 2010-09-14 at 17:13 -0700, John Poelstra wrote: Shouldn't ABRT be looking to a file like /etc/fedora-release to determine the release version? r...@rawhide:~ cat /etc/fedora-release Fedora release 15 (Finian) What you say ;-)? 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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 12:27 PM, M A Young m.a.yo...@durham.ac.uk wrote: On Wed, 15 Sep 2010, drago01 wrote: I think the main point here wasn't there are bugs #X, #Y and #Z that can't be fixed in time so we should revert but a we have a bad feeling / are nervous so lets revert ... the later isn't really a technical decision basis and can (and here it did) piss of the one working on said feature. In this case the bad feeling is justified, because there were too many problems too late in the release cycle. I didn't comment on whether it was justified or not. Just that it is a bad practice to decide on subjective matters. Pointing out the too many problems and base the decision on them would be fine (and problems that are already fixed do not count). The only real issues pointed out where lack of documentation and system-config-service integration for native services. Neither that we have with upstart so not really a regression and thus warrant a reject. Anyway the point I am trying to make is that technical decisions (and that is what FESCo is for after all) should be based on *objective* rather than *subjective* matters. It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. There is no way to know that ... based on this we should not add anything new because we can't be sure that they aren't any unknown critical bugs. It should be rather have we found bugs in our testing that can't be fixed in time .. yes - punt to next release; no - ship it Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. We already have that its called Feature freeze. The acceptance criteria should have been present from day one (i.e the day the feature was accepted) not shortly before beta (which pretty much limits the time to work to met them). I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. IIRC systemd wasn't even written back then. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On 09/15/2010 04:29 PM, Michał Piotrowski wrote: It is still necessary to take into account users who think that Gnome-Shell is something like KDE4 :) In what specific way? They can just continue using GNOME Panel. GNOME Shell is also different from systemd in the sense that it affects every single user of Fedora and deserves a closer scrutiny. Ouh, but Gnome shell would affect 50% of Fedora users. We don't really have any reliable stats for DE usage. FWIW, I think GNOME Shell deserves extensive testing before made as default as well. FESCo's handling of systemd feature as a process has gaps that needs to be fixed as well. Nevertheless, I would like to thank Lennart for his extensive work on getting systemd where it is now in such a short period and Matthew Miller for playing the role of a very constructive critic and following up on bugs methodologically. I agree that SystemD should be in reasonable stable state for making it default init. Also very constructive criticism has helped this project. But I feel that: - may be too early to cut it as default init from the release - I see no problem if would have been given another month to Lennart for fixing latest critical documentation issues - problems that you point out in the email to test@ IMHO do not have any major significance You are confusing me. There aren't any critical documentation issues. My list is a specific one. What you have is a subjective feeling. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
The only real issues pointed out where lack of documentation and system-config-service integration for native services. Neither that we have with upstart so not really a regression and thus warrant a reject. That depends on whether we want to raise the bar for features as crucial as a init system. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 01:05 +0200, Lennart Poettering wrote: Nice move. So, we closed all blocker bugs, we worked through the vast majority of other bugs. I dealt with almost all issues raised in Bill's list, only few small issues left. While there are some bugs open, we did our homework. I was kept in the impression during the last week that these are the criteria to get systemd into F14. But what happens? Out of nowhere completely new criteria are created, and used to bring this project down. Why do we have the blocker bugs scheme if it apparently is irrelevant for final decisions? I can't talk about how FESCo makes decisions, but I can talk about the blocker bug process. It's important to note that the blocker bug process and the feature process are separate. Blocker bugs are a QA thing and they arise out of the release criteria: we take the code that's in the repositories as of right now, build images out of it, test those, see if they comply with the release criteria, and if they don't, we file bugs which become blocker bugs (or we mark bugs filed by other testers as blocker bugs). The feature process, including the acceptance or rejection of features by FESCo, is a *separate* process, it is not part of the release validation / blocker bug process, and it's not really integrated with it. There isn't some direct relationship between having open blockers against a feature (or not) and that feature being rejected (or accepted): FESCo makes its decision on grounds which I expect are described in the feature process, somewhere, which may be wider (or narrower...) than just whether the feature causes problems with the release criteria at any moment in time. This is a really unfriendly move: I cannot win a game where the moment the game nears it ends completely new rules are created. Quite frankly, this is a recipe to piss people off, not to make people love developing for Fedora. Yes, I am very disappointed, Fedora. I don't think it helps anyone to personalize this decision or talk about it as a 'game' you have to 'win'. Whether or not you think FESCo made the right decision, I don't see any indication in the meeting logs that they treated it as a game or as some kind of personal conflict. Their job was simply to decide if it would be best for the project to accept the feature into F14, or delay it to F15. They decided (quite narrowly) that it'd be safer to delay it to F15. They didn't do anything to indicate any kind of personal animosity, they didn't say it was a bad feature or badly coded, or anything like that. They just looked at the whole situation and decided that overall it would be a bit safer to wait until F15 before going with systemd. It's also nice to not even bother to ping me for the FESCO discussion. This all reads like a page from the book How to piss people off and scare them away in 7 days. You make up new rules, and then don't bother to invite the folks mostky affected when you apply them. Oh, and next time, if you guys plan a move like that, then please do it a couple of weeks earlier, so that I can find funnier things to do then make you folks happy, since that's apparently not possible. Again it's not great to personalize this, but FWIW I agree with both points: it was a mistake not to contact you directly to see if you wanted to attend the meeting, and I definitely agree that it would have been better to take the decision earlier. FESCo's been discussing it without much urgency since last week, and that discussion always gave us (QA) the vague impression they were going to approve it, and we actually told them that it'd be quite hard to revert to upstart after Beta TC1 went out and just about impossible to do it after Beta RC1 went out, but they still decided to go ahead and require a reversion two days before the deadline for Beta RC1 to be rolled, which *really* isn't optimal and leaves us scrambling to make sure the reversion will be done well enough to not leave the RC1 DOA. It would definitely have been much better to decide this last week. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Tue, 14 Sep 2010 21:07:50 +0100, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 8:31 PM, Rahul Sundaram methe...@gmail.com wrote: On 09/15/2010 12:49 AM, Matthew Miller wrote: On Tue, Sep 14, 2010 at 12:04:04PM -0700, Jesse Keating wrote: Which OEMs care enough about Linux support to use a more expensive part? Seriously. I will go buy their stuff right now. I read that HP was doing this but haven't verified. From supporting Sugar related deployments using the Fedora Sugar on a Stick with HP laptops I've not exactly seen that but I'm not sure if its pertaining to particular models. I know Dell in the past has offered their re branded Broadcom wifi with an option of Intel wifi for a £5 premium. No idea if HP does similar. Dell no longer offer a WiFi card choice, at least in Europe and even in the US for their netbook lines. Sony does ship Atheros WiFi cards by default, though, even on their budget lines (I have the EB 15 and the W netbook). The memory card on the netbook does not work, but that's a minor issue. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 00:06 +, Jóhann B. Guðmundsson wrote: On 09/15/2010 12:01 AM, Jeff Spaleta wrote: On Tue, Sep 14, 2010 at 3:56 PM, James Laskajla...@redhat.com wrote: Much like we introduced and communicated btrfs support in F-11, should we communicate systemd as a technology preview in Fedora 14? I would agree with this. I certainly plan to run F14 with systemd in anticipation of seeing it become the default at some point. Should gnome-shell and every other feature fall under technology preview and stay like that for sometime as well before becoming the default or does this just applied to certain features maintained by certain people. . . I'm not sure if you know this, but GNOME 3 (including GNOME Shell) has also been delayed from F14 to F15. GNOME Shell won't be the default UI for F14. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Tue, 2010-09-14 at 20:48 -0400, Máirín Duffy wrote: Is anyone else feeling a little uncomfortable about the voting process, irregardless of its conclusion? 'regardless'. 'irregardless' would mean 'not regardless'. =) Yes, I agree, and I'd like to point up another procedural issue here. During the meeting it was generally assumed that this was just a usual 'do we approve this feature' vote, in which case the 'default' would be 'no', and the onus would be on the 'yes' side to get five votes to have the feature approved. It was essentially rejected by default - it was rejected because there weren't five people voting in favour, not because there were five people voting against. I think this is an erroneous interpretation, because this wasn't a normal 'do we approve this feature' vote. systemd had in fact already been voted on as a feature at an earlier fesco meeting and had been *provisionally accepted* - that is, it was accepted, with the proviso that if fesco was particularly worried about something, it could reverse that acceptance any time prior to beta release. Given the previous provisional acceptance of systemd, I would argue that the situation at the meeting should actually have been that *accepting* systemd would be the default case, and it should have taken five 'no' votes (or five 'yes' votes to the proposal 'do we reverse our earlier decision and reject systemd?') to reject it - it shouldn't have been rejected just because five yes votes couldn't be found on the day. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 11:27 +0100, M A Young wrote: In this case the bad feeling is justified, because there were too many problems too late in the release cycle. It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. This would need to be carefully handled, because all components are not equal in terms of blocker bugs. systemd shares the position of anaconda in being disproportionately subject to them, because *everyone* in the distro uses it, and bugs in it are much more likely to be showstoppers due to the role it performs. We probably had just as many blocker bugs in anaconda for F14 as we did for systemd, or more; it's just the nature of those particular beasts. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Text-SpellChecker] Update to 0.06
commit 4f01da23674a097bc370e4469256bb5ecdcce5d5
Author: Paul Howarth p...@city-fan.org
Date: Wed Sep 15 13:17:45 2010 +0100
Update to 0.06
.gitignore |2 +-
perl-Text-SpellChecker.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bf61cc9..13321ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Text-SpellChecker-0.05.tar.gz
+/Text-SpellChecker-0.06.tar.gz
diff --git a/perl-Text-SpellChecker.spec b/perl-Text-SpellChecker.spec
index e6fe4ee..8cde830 100644
--- a/perl-Text-SpellChecker.spec
+++ b/perl-Text-SpellChecker.spec
@@ -1,7 +1,7 @@
Summary: OO interface for spell-checking a block of text
Name: perl-Text-SpellChecker
-Version: 0.05
-Release: 5%{?dist}
+Version: 0.06
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Url: http://search.cpan.org/dist/Text-SpellChecker/
@@ -32,8 +32,8 @@ left off), and highlighting the current misspelled word
within the text.
%{__rm} -rf %{buildroot}
%{__make} pure_install PERL_INSTALL_ROOT=%{buildroot}
/usr/bin/find %{buildroot} -type f -name .packlist -exec %{__rm} -f {} ';'
-/usr/bin/find %{buildroot} -depth -type d -exec /bin/rmdir {} 2/dev/null ';'
-%{__chmod} -R u+w %{buildroot}/*
+/usr/bin/find %{buildroot} -depth -type d -exec /bin/rmdir {} ';' 2/dev/null
+%{__chmod} -R u+w %{buildroot}
%clean
%{__rm} -rf %{buildroot}
@@ -45,6 +45,9 @@ left off), and highlighting the current misspelled word
within the text.
%{_mandir}/man3/Text::SpellChecker.3pm*
%changelog
+* Wed Sep 15 2010 Paul Howarth p...@city-fan.org - 0.06-1
+- Update to 0.06
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-5
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index fc2475a..ba7766d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3a6be263bb08e82cb7a975ca799063a7 Text-SpellChecker-0.05.tar.gz
+aec95f851f490616c9b5f53857cfa074 Text-SpellChecker-0.06.tar.gz
--
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: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 15 Sep 2010, drago01 wrote: On Wed, Sep 15, 2010 at 12:27 PM, M A Young wrote: It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. There is no way to know that ... based on this we should not add anything new because we can't be sure that they aren't any unknown critical bugs. But you can base it on what bugs were raised or still open during the alpha phase. If there were a lot of issues during the alpha phase then that is likely to continue in the beta phase. That was why I was suggesting you count all blocker bugs, not just those that are still open. It doesn't guarantee that there will or won't be be any critical bugs but it does give an objective measure of how stable and well tested the code is. Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. We already have that its called Feature freeze. I don't think that is enough, as the features can stay the same but the code used to achieve this can potentially change completely. My impression is that systemd has changed a great deal during the alpha phase even though I imagine the features it aims to provide have stayed the same. I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. IIRC systemd wasn't even written back then. And that is precisely the problem - the code isn't really stable enough yet for Fedora because it has been developed very quickly and so hasn't had a chance to stablize yet. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Wed, 2010-09-15 at 11:05 +0100, David Woodhouse wrote: The Broadcom position seems to be entirely crack-inspired, if it's based on the notion that a binary driver cannot be modified to break the regulations. That assumption is demonstrably false. In the lawyers' defense, lots of things happen in courtrooms which apear crack-inspired to those of us who aren't part of the legal process (and, frequently, also to those who are). I could certainly see a creative lawyer trying to argue that a driver under an open source license implicitly encourages modification of the relevant code, while a driver under a closed source license implicitly discourages it or even explicitly prohibits it (I haven't checked, but the closed source drivers may be shipped with a license which claims to prohibit end-user modification). And I could see a crack-inspired judge agreeing. This is the kind of crap lawyers have to think of. (I agree that it would have been an awful lot simpler to just limit the hardware, but then they'd have to make variants of the hardware for all different markets, since the range of allowed/required frequencies differs around the world). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100915 changes
Compose started at Wed Sep 15 08:15:32 UTC 2010 Broken deps for x86_64 -- ale-0.9.0.3-2.fc14.x86_64 requires libMagickCore.so.3()(64bit) almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 autotrace-0.31.1-24.fc14.i686 requires libMagickCore.so.3 autotrace-0.31.1-24.fc14.x86_64 requires libMagickCore.so.3()(64bit) calibre-0.7.18-2.fc15.x86_64 requires libMagickWand.so.3()(64bit) calibre-0.7.18-2.fc15.x86_64 requires libMagickCore.so.3()(64bit) claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0 clutter-gtkmm-0.9.5-1.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 dmapd-0.0.25-3.fc15.i686 requires libMagickWand.so.3 dmapd-0.0.25-3.fc15.i686 requires libMagickCore.so.3 dmapd-0.0.25-3.fc15.x86_64 requires libMagickWand.so.3()(64bit) dmapd-0.0.25-3.fc15.x86_64 requires libMagickCore.so.3()(64bit) drawtiming-0.7.1-1.1.fc14.x86_64 requires libMagickCore.so.3()(64bit) drawtiming-0.7.1-1.1.fc14.x86_64 requires libMagick++.so.3()(64bit) dx-4.4.4-16.fc14.x86_64 requires libMagickCore.so.3()(64bit) dx-libs-4.4.4-16.fc14.i686 requires libMagickCore.so.3 dx-libs-4.4.4-16.fc14.x86_64 requires libMagickCore.so.3()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) entangle-0.1.0-7.fc14.x86_64 requires libmozjs.so()(64bit) ethos-0.2.2-7.fc15.i686 requires libmozjs.so ethos-0.2.2-7.fc15.x86_64 requires libmozjs.so()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gdl-0.9-1.fc15.x86_64 requires libMagickCore.so.3()(64bit) gdl-0.9-1.fc15.x86_64 requires libMagick++.so.3()(64bit) gdl-python-0.9-1.fc15.x86_64 requires libMagickCore.so.3()(64bit) gdl-python-0.9-1.fc15.x86_64 requires libMagick++.so.3()(64bit) gjs-0.7.1-3.fc14.i686 requires libmozjs.so gjs-0.7.1-3.fc14.x86_64 requires libmozjs.so()(64bit) 1:gnome-bluetooth-2.90.0-5.fc15.x86_64 requires libgnome-control-center.so.1()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-media-2.31.5-5.fc15.x86_64 requires libgnome-control-center.so.1()(64bit) gnome-panel-2.31.90-1.fc15.x86_64 requires libedataserverui-1.2.so.10()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-totem-2.31.1-5.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-shell-2.31.5-5.fc14.x86_64 requires libmozjs.so()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) gstreamer-plugins-bad-free-extras-0.10.20-1.fc15.i686 requires libWildMidi.so.0 gstreamer-plugins-bad-free-extras-0.10.20-1.fc15.x86_64 requires libWildMidi.so.0()(64bit) gxine-0.5.905-3.fc13.x86_64 requires libmozjs.so()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) imageinfo-0.05-10.fc14.x86_64 requires libMagickCore.so.3()(64bit) inkscape-0.48.0-1.fc15.x86_64 requires libMagickCore.so.3()(64bit) inkscape-0.48.0-1.fc15.x86_64 requires libMagick++.so.3()(64bit) inkscape-view-0.48.0-1.fc15.x86_64 requires libMagickCore.so.3()(64bit) inkscape-view-0.48.0-1.fc15.x86_64 requires
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 13:18 +0100, M A Young wrote: But you can base it on what bugs were raised or still open during the alpha phase. If there were a lot of issues during the alpha phase then that is likely to continue in the beta phase. That was why I was suggesting you count all blocker bugs, not just those that are still open. It doesn't guarantee that there will or won't be be any critical bugs but it does give an objective measure of how stable and well tested the code is. Not entirely: see my reply to your previous. Not all packages are equal from the point of view of 'susceptibility to blocker bugs'. anaconda wouldn't do well on a measure of 'how many blocker bugs are opened against this component in alpha' either, but it doesn't mean anaconda sucks and should be removed =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 01:18:44PM +0100, M A Young wrote: I don't think that is enough, as the features can stay the same but the code used to achieve this can potentially change completely. My impression is that systemd has changed a great deal during the alpha phase even though I imagine the features it aims to provide have stayed the same. I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. IIRC systemd wasn't even written back then. And that is precisely the problem - the code isn't really stable enough yet for Fedora because it has been developed very quickly and so hasn't had a chance to stablize yet. Really, systemd core changes during alpha were really minor. Some renaming, some unit fixes (which count mainly as configuration details), implementing feedback from -devel list and bugreports. The core of systemd wasn't rewritten. Bear in mind that first commits to systemd are from November 2009, code is almost a year old. Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. pgpwGFuJiT0R8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 11:27:07 +0100, M A Young m.a.yo...@durham.ac.uk wrote: I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. This is pretty much my feeling on this too. There really isn't that much time left before final freeze and there are still some backwards compatibility quirks that need to be dealt with (by prominent documentation or elimination) or we are going to cause pain for sysadmin type users. I think things will go a lot smoother having an F15 release. And we can still get the followon improvements originbally planned for F15, as that development doesn't need to wait just because the basic support was slipped to F15. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 14:27 +0200, Tomasz Torcz wrote: Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. There's no reason it should. Remember, F15 is open *now*, Rawhide is F15. All this work can be done right now, if there's the will to do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 634133] perl-DBD-SQLite-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=634133 Petr Sabata psab...@redhat.com changed: What|Removed |Added CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broadcom wifi drivers in F-14?
On Wed, Sep 15, 2010 at 2:20 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-09-15 at 11:05 +0100, David Woodhouse wrote: The Broadcom position seems to be entirely crack-inspired, if it's based on the notion that a binary driver cannot be modified to break the regulations. That assumption is demonstrably false. In the lawyers' defense, lots of things happen in courtrooms which apear crack-inspired to those of us who aren't part of the legal process (and, frequently, also to those who are). I could certainly see a creative lawyer trying to argue that a driver under an open source license implicitly encourages modification of the relevant code, while a driver under a closed source license implicitly discourages it or even explicitly prohibits it (I haven't checked, but the closed source drivers may be shipped with a license which claims to prohibit end-user modification). And I could see a crack-inspired judge agreeing. This is the kind of crap lawyers have to think of. (I agree that it would have been an awful lot simpler to just limit the hardware, but then they'd have to make variants of the hardware for all different markets, since the range of allowed/required frequencies differs around the world). But where do you draw the line? A crack-inspired judge might argue that the fact that regulation is done in software is a problem regardless of the drivers license / nature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F12/ Cannot update
On Wed, Sep 15, 2010 at 11:01:04 +0200, Andrea Musuruane musur...@gmail.com wrote: On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen thom...@fedoraproject.org wrote: File a ticket with FESCo. We should have *all* packages go trough updates-testing, regardless of who's the maintainer or what's the reason of an update. If FESCo finds out that this is a bug (some packages can be pushed to stable directly) in Bodhi, fix it, ASAP. Opened ticket 466: https://fedorahosted.org/fesco/ticket/466 In the recent Thunderbird case, it may have gotten some positive karma, but no one tried out sunbird as it was completely broken by a typo in the shell script. That push should have never made it to updates. (This was in F14, but still ...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Tue, Sep 14, 2010 at 06:39:48PM -0400, Ric Wheeler wrote: On 09/14/2010 10:13 AM, John W. Linville wrote: On Tue, Sep 14, 2010 at 12:31:44PM +0100, David Woodhouse wrote: On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: IIRC they require a firmware blob that has a license that we cannot distribute unlike say the Intel firmwares. I could be wrong though. That's still true of the b43 firmware for older (pre-802.11n) devices, but the firmware to go with their new driver is now in linux-firmware.git. Their *original* offering of that new firmware had a stupid licence -- you could only distribute it if you promised to indemnify and defend Broadcom from all related third-party lawsuits. They fixed that though, and I merged it. Nevertheless, everyone I know that has reviewed the newly released driver code is being treated for eye cancer. I wouldn't expect to see it in F-14. John Can we use the firmware that they have for the existing broadcom wireless driver? AIUI, they main technical reason that they were finally willing to open-up was that they were able to add some regulatory enforcement code in their firmware. The added firmware functionality required more firmware resources, and only the newer devices explicictly supported by Broadcom's newly-released driver have enough firmware resources to run it. That said, I don't know if some future version of b43 might be able to use this new firmware to support this new hardware or not. But the current version of b43 will not support it anyway. So I guess the above is a long way of saying 'no, sorry'... :-( John -- John W. LinvilleThe truth will set you free, but first it will linvi...@redhat.com make you miserable. -- James A. Garfield -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On 09/15/2010 01:48 PM, Adam Williamson wrote: On Tue, 2010-09-14 at 20:48 -0400, Máirín Duffy wrote: Is anyone else feeling a little uncomfortable about the voting process, irregardless of its conclusion? 'regardless'. 'irregardless' would mean 'not regardless'. =) Yes, I agree, and I'd like to point up another procedural issue here. During the meeting it was generally assumed that this was just a usual 'do we approve this feature' vote, in which case the 'default' would be 'no', and the onus would be on the 'yes' side to get five votes to have the feature approved. It was essentially rejected by default - it was rejected because there weren't five people voting in favour, not because there were five people voting against. I think this is an erroneous interpretation, because this wasn't a normal 'do we approve this feature' vote. systemd had in fact already been voted on as a feature at an earlier fesco meeting and had been *provisionally accepted* - that is, it was accepted, with the proviso that if fesco was particularly worried about something, it could reverse that acceptance any time prior to beta release. Given the previous provisional acceptance of systemd, I would argue that the situation at the meeting should actually have been that *accepting* systemd would be the default case, and it should have taken five 'no' votes (or five 'yes' votes to the proposal 'do we reverse our earlier decision and reject systemd?') to reject it - it shouldn't have been rejected just because five yes votes couldn't be found on the day. From my point of view all this situation is clearly wrong. I understand that Lennard is pissed off, he followed the tight schedule and tried to fix as many bugs as possible to deliver working init system in time. I understand why systemd was postponed as default init system foro F15, but this discussion/decision should come much much sooner, with clear criteria for accepting/rejecting it. It should be stated at the beginning of process that systemd should be accepted when ... yada yada. In case it does not meet these criteria it should be rejected. But the terms for acceptance were IMO drastically changed at the end. Kind regards sHINOBI -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File File-Find-Rule-VCS-1.07.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-File-Find-Rule-VCS: d695c3529109ed69ded833163c2a4f43 File-Find-Rule-VCS-1.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 568172] virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Denise Dumas ddu...@redhat.com changed: What|Removed |Added CC||ddu...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 633726] perl-File-ShareDir-1.02 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633726 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC|mmasl...@redhat.com |ppi...@redhat.com AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File File-ShareDir-1.02.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-File-ShareDir: edb4b9d418a03bf9b0cf6d0fa9585c3f File-ShareDir-1.02.tar.gz -- 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: Revisor and live_ram
On Wed, 2010-09-15 at 01:25 -0400, Trever Fischer wrote: Excuse me if this is the wrong place to send this. As my fedora ambassador duties, I tend to show other students the neat things you can do with Fedora with my trusty USB drive I always keep on my keychain. More often than not, I'm booting up Fedora into some laptop or university desktop with copious quantities of ram (more than 2G, commonly 4 or more). Also more often than not, I've edited the boot options when it starts up to add the 'live_ram' flag which copies the image into RAM and permits me to unplug the USB drive so I'm not late for class while they explore. I've longed for an option in the stock boot menu to expose this seemingly hidden magic to the general public, so I wrote a tiny patch for python-imgcreate (which is used by revisor). It adds one new option to the isolinux boot menu, labeled Boot and run from RAM. I've tested it by re-spinning the KDE spin and the custom one I use for day-to-day use on my usb drive. Flawless victory. You'll probably need to re-diff this against the recent changes to add a 'basic graphics driver' entry to the same boot menu - http://koji.fedoraproject.org/koji/buildinfo?buildID=195368 is the latest build (or check git). I already did, actually. This patch puts the code immediately before the Basic Video option, and can be cleanly applied to 6f79b742. -- Trever Fischer (tdfischer) Fedora Ambassador, KDE Hacker http://wm161.net GPG: C40F2998 hkp://wwwkeys.pgp.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Wed, Sep 15, 2010 at 09:09:58 -0400, John W. Linville linvi...@redhat.com wrote: AIUI, they main technical reason that they were finally willing to open-up was that they were able to add some regulatory enforcement code in their firmware. The added firmware functionality required more firmware resources, and only the newer devices explicictly supported by Broadcom's newly-released driver have enough firmware resources to run it. How does the firmware know where you are? Do you need different firmware for different markets? I hope the guys that reverse engineered the firmware that can be used as an alternative with the b43 driver keep working on it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Tue, Sep 14, 2010 at 04:01:03PM -0600, Kevin Fenzi wrote: * pjones and ajax are traveling today, will not be able to attend. (nirik, 19:30:30) Sorry, I thought I had mentioned this on IRC before, but I have a conflict with the current scheduling for the next four months due to a class at the university. (I thought I could cope and get on irc this meeting, but the wireless access in the lecture theater was non-existant.) I think given this conflict, and the resulting discontent, I should probably stand aside and allow someone whose schedule can cope to be elected in my stead. (As I recall, when we determined the meeting time, this was basically the only time people were all 'available' for.) regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 12:48:26PM +0100, Adam Williamson wrote: On Tue, 2010-09-14 at 20:48 -0400, Máirín Duffy wrote: Is anyone else feeling a little uncomfortable about the voting process, irregardless of its conclusion? 'regardless'. 'irregardless' would mean 'not regardless'. =) The OED disagrees. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Wed, Sep 15, 2010 at 08:49:46AM -0500, Bruno Wolff III wrote: On Wed, Sep 15, 2010 at 09:09:58 -0400, John W. Linville linvi...@redhat.com wrote: AIUI, they main technical reason that they were finally willing to open-up was that they were able to add some regulatory enforcement code in their firmware. The added firmware functionality required more firmware resources, and only the newer devices explicictly supported by Broadcom's newly-released driver have enough firmware resources to run it. How does the firmware know where you are? Do you need different firmware for different markets? Beats me...more likely, there is some sort of SKU-equivalent info available to the firmware and a table of predefined regulatory rules mapped to those SKUs. This, of course, does nothing to prevent situations where one is using values that are OK in your country of origin but not in your current host country. But I suppose that is more of an import/export problem...? Whatever. I hope the guys that reverse engineered the firmware that can be used as an alternative with the b43 driver keep working on it. Me too. If/when I find a way to alter time or speed-up the harvest (or teleport me off this rock) I think I would enjoy working on that! In the meantime, I hope someone else with applicable skills and interests takes that opportunity. John -- John W. LinvilleThe truth will set you free, but first it will linvi...@redhat.com make you miserable. -- James A. Garfield -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 14:57 +0100, Matthew Garrett wrote: On Wed, Sep 15, 2010 at 12:48:26PM +0100, Adam Williamson wrote: On Tue, 2010-09-14 at 20:48 -0400, Máirín Duffy wrote: Is anyone else feeling a little uncomfortable about the voting process, irregardless of its conclusion? 'regardless'. 'irregardless' would mean 'not regardless'. =) The OED disagrees. Not really. It lists 'irregardless' as 'colloquial', IIRC (I don't have my login handy right now, my library card is in Canada...), which is the OED equivalent of a ten-poot barge pole. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 568172] virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Daniel Berrange berra...@redhat.com changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #11 from Daniel Berrange berra...@redhat.com 2010-09-15 10:04:00 EDT --- This bug was tracking the original problem which is that libvirt didn't mask signals correctly. The problem Wayne Sun reports in comment #8 sounds like a different problem, which just happens to have the same user visible results. Since virt-top is a separate component, it will need a separate BZ filed, since this BZ is for libvirt. Thus I'm putting this bug back to ON_QA. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 568172] libvirt does not block signals, causing virt-top to fail when getting sigwinch from a terminal resize
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Daniel Berrange berra...@redhat.com changed: What|Removed |Added Summary|virt-top exits sometimes|libvirt does not block |when the window is resized |signals, causing virt-top ||to fail when getting ||sigwinch from a terminal ||resize -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 03:04:31PM +0100, Adam Williamson wrote: On Wed, 2010-09-15 at 14:57 +0100, Matthew Garrett wrote: On Wed, Sep 15, 2010 at 12:48:26PM +0100, Adam Williamson wrote: 'regardless'. 'irregardless' would mean 'not regardless'. =) The OED disagrees. Not really. It lists 'irregardless' as 'colloquial', IIRC (I don't have my login handy right now, my library card is in Canada...), which is the OED equivalent of a ten-poot barge pole. :) You can argue over whether it's accepted as correct English, but it has a well-defined meaning even if that meaning is contrary to what normal word construction rules would lead you to accept. In any case, quibbling about language usage generally serves to belittle the person you're criticising - it doesn't encourage an attitude of mutual respect and does nothing to foster an atmosphere in which we can have a civilised and productive discussion. Let's be more excellent and less prescriptive? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 09:03 +0100, Richard Hughes wrote: On 14 September 2010 23:01, Kevin Fenzi ke...@scrye.com wrote: 21:33:35 nirik The other 2 items I had were: 21:33:56 nirik application installer issues 21:33:57 nirik https://bugzilla.redhat.com/show_bug.cgi?id=488968 21:34:04 nirik and 21:34:05 nirik BuildIdBuild infrastructure 21:34:06 nirik https://fedorahosted.org/fedora-infrastructure/ticket/2387 21:34:57 mclasen that needs more time, I'd say 21:35:08 nirik ok, will close out if no one has anything further... Well, that was enlightening. Do you think someone from FESCo could write something about https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and make a decision please. Until then, all gnome-packagekit, app-install and kpackagekit work will be halted. I don't want to be in the same situation as Lennart where I've done loads of work and then a few influential people in Fedora just to turn around and say no. Just to avoid misunderstandings here: my comment 'that needs more time' was in reference to the fact that the meeting was over 2 hours at that point and we only had a few minutes left to bring up quick topics. It was not a comment on the feature itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 15 Sep 2010, Adam Williamson wrote: On Wed, 2010-09-15 at 14:27 +0200, Tomasz Torcz wrote: Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. There's no reason it should. Remember, F15 is open *now*, Rawhide is F15. All this work can be done right now, if there's the will to do it. For people wanting to make big changes to F15.. Do it *now*! F15 is in its infancy. It's taking shape. If you want your feature to be a defining feature of F15. Get it in *now*. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Format-Human-Bytes-0.06.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Format-Human-Bytes: 709e90c62599def49071735e842632c8 Format-Human-Bytes-0.06.tar.gz -- 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
[perl-Format-Human-Bytes] New sources for 0.06
commit b1ee707c871291591973d62dbe13e2bc5f6699db Author: Petr Sabata psab...@redhat.com Date: Wed Sep 15 16:16:11 2010 +0200 New sources for 0.06 .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index ff321f7..25f3e8e 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ Format-Human-Bytes-0.04.tar.gz +/Format-Human-Bytes-0.06.tar.gz diff --git a/sources b/sources index 97e6b31..ea1fc15 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -d29701e4f1ac0914d11fb10bfbb5350a Format-Human-Bytes-0.04.tar.gz +709e90c62599def49071735e842632c8 Format-Human-Bytes-0.06.tar.gz -- 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
[perl-File-Find-Rule-VCS] 1.07 bump
commit b33cb75d50ec3b694394945f5f2286fd4cf40cc9
Author: Petr Písař ppi...@redhat.com
Date: Wed Sep 15 15:34:50 2010 +0200
1.07 bump
.gitignore |1 +
perl-File-Find-Rule-VCS.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ebe4bc0..4d4ec43 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
File-Find-Rule-VCS-1.05.tar.gz
+/File-Find-Rule-VCS-1.07.tar.gz
diff --git a/perl-File-Find-Rule-VCS.spec b/perl-File-Find-Rule-VCS.spec
index 9fb2693..107760c 100644
--- a/perl-File-Find-Rule-VCS.spec
+++ b/perl-File-Find-Rule-VCS.spec
@@ -1,6 +1,6 @@
Name: perl-File-Find-Rule-VCS
-Version:1.05
-Release:5%{?dist}
+Version:1.07
+Release:1%{?dist}
Summary:Exclude files/directories for Version Control Systems
License:GPL+ or Artistic
Group: Development/Libraries
@@ -12,7 +12,7 @@ BuildRequires: perl = 0:5.005
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Find::Rule) = 0.20
BuildRequires: perl(Test::More) = 0.47
-Requires: perl(File::Find::Rule) = 0.20
+BuildRequires: perl(Text::Glob) = 0.08
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -49,6 +49,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Sep 15 2010 Petr Pisar ppi...@redhat.com - 1.07-1
+- 1.07 bump
+- Remove duplicate perl(File::Find::Rule) Requires
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.05-5
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 2db0dd3..14b6951 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-58526cd2ec430d24e2feb9ebdfe58398 File-Find-Rule-VCS-1.05.tar.gz
+d695c3529109ed69ded833163c2a4f43 File-Find-Rule-VCS-1.07.tar.gz
--
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: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Mike McGrath said the following on 09/15/2010 07:14 AM Pacific Time: On Wed, 15 Sep 2010, Adam Williamson wrote: On Wed, 2010-09-15 at 14:27 +0200, Tomasz Torcz wrote: Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. There's no reason it should. Remember, F15 is open *now*, Rawhide is F15. All this work can be done right now, if there's the will to do it. For people wanting to make big changes to F15.. Do it *now*! F15 is in its infancy. It's taking shape. If you want your feature to be a defining feature of F15. Get it in *now*. -Mike And we are already reviewing and accepting features for Fedora 15. The process never stops. https://fedoraproject.org/wiki/Features/Policy John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 633725] perl-File-Find-Rule-VCS-1.07 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633725 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-File-Find-Rule-VCS-1.0 ||7-1.fc15 Resolution||NEXTRELEASE Last Closed||2010-09-15 10:22:20 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 07:20:30 -0700, John Poelstra poels...@redhat.com wrote: And we are already reviewing and accepting features for Fedora 15. The process never stops. https://fedoraproject.org/wiki/Features/Policy Thanks for the reminder; I'll put LZMA back in for F15 and hope the kernel changes make it in by then. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 633729] perl-HTML-FormatText-WithLinks-0.11 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633729 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC|mmasl...@redhat.com |ppi...@redhat.com AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
refining the feature process
On Wed, Sep 15, 2010 at 09:14:24AM -0500, Mike McGrath wrote: For people wanting to make big changes to F15.. Do it *now*! F15 is in its infancy. It's taking shape. If you want your feature to be a defining feature of F15. Get it in *now*. This seems like a completely sensible idea. However, it's not the current feature process. The Feature Freeze is currently immediately before the Branch Freeze, shortly before the Alpha Release. Currently, we don't have F15 schedule at all, but following the previous example, the Feature Freeze would be about two months from F14's release -- January 2011. There is a major change since development of the features process which makes it reasonable to revisit this -- in fact, a feature itself: No Frozen Rawhide. This should enable more early, active feature development. So, I'd like to suggest moving the Feature Freeze to be earlier: generally, one month after the previous release, and maybe sooner for changes affecting critical-path components. Then, the main decision for default/not-default could be at the point of the alpha release, with a second re-check before beta release. Features should not be reverted after beta. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTML-FormatText-WithLinks] 0.11 bump
commit 69e0bc83d7c1bd83b80e732b372686032e10d296
Author: Petr Písař ppi...@redhat.com
Date: Wed Sep 15 16:33:29 2010 +0200
0.11 bump
.gitignore |1 +
perl-HTML-FormatText-WithLinks.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cba7868..3d0da65 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
HTML-FormatText-WithLinks-0.09.tar.gz
+/HTML-FormatText-WithLinks-0.11.tar.gz
diff --git a/perl-HTML-FormatText-WithLinks.spec
b/perl-HTML-FormatText-WithLinks.spec
index bbd6285..8ef4686 100644
--- a/perl-HTML-FormatText-WithLinks.spec
+++ b/perl-HTML-FormatText-WithLinks.spec
@@ -1,6 +1,6 @@
Name: perl-HTML-FormatText-WithLinks
-Version:0.09
-Release:8%{?dist}
+Version:0.11
+Release:1%{?dist}
Summary:HTML to text conversion with links as footnotes
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Sep 15 2010 Petr Pisar ppi...@redhat.com - 0.11-1
+- 0.11 bump
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-8
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 5e33e4d..f9d26e2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3d48f2bae0aa3068de6a31dea4043127 HTML-FormatText-WithLinks-0.09.tar.gz
+980d382b277b22c487fef95a8e3d61cd HTML-FormatText-WithLinks-0.11.tar.gz
--
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: python3 rpm macros not available without python3-devel installed
I suspect I haven't had enough coffee yet, but I don't see the problem
here. Why not simply add python3-devel as a build requirement as
Ignacio says?
If a build requirement isn't installed, it's acceptable for a build to
fail: it's a violation of a precondition.
On Wed, 2010-09-15 at 19:35 +0800, Robin Lee wrote:
You should build this package in a clean root like a mock environment.
If you have python3-devel already installed and then run rpmbuild
--rebuild, you will not see the issue.
On Wed, Sep 15, 2010 at 7:25 PM, Robin Lee robinlee.s...@gmail.com
wrote:
For a more concrete example:
https://bugzilla.redhat.com/show_bug.cgi?id=567348
I want to set the python(abi) requirement of the subpackage at
buildtime. So, I want to set it like this:
Requires: python(abi) = %{py3_ver}
But when build it, it will fail with the following output:
$ rpmbuild -bp dreampie.spec
Building target platforms: i686
Building for target i686
sh: python3: command not found
sh: python3: command not found
sh: python3: command not found
error: line 46: Version required: Requires: python(abi) =
Even though python3-devel has been added as BR.
On Wed, Sep 15, 2010 at 7:06 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
On Wed, 2010-09-15 at 18:22 +0800, Robin Lee wrote:
python3 rpm macros not available without
python3-devel installed.
'rpmbuild --viewrc' will show you.
So if you use the python3 macros to define another
macro and you have
no python3-devel installed, you must fail.
So, how to define, for example, a %py3_ver macro for
the major version
of Python3? Must yum be used?
Robin
Adding a BuildRequires: python3-devel should be
enough to pull them
in.
--
Ignacio Vazquez-Abrams ivazquez...@gmail.com
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 09:14 -0500, Mike McGrath wrote: On Wed, 15 Sep 2010, Adam Williamson wrote: On Wed, 2010-09-15 at 14:27 +0200, Tomasz Torcz wrote: Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. There's no reason it should. Remember, F15 is open *now*, Rawhide is F15. All this work can be done right now, if there's the will to do it. For people wanting to make big changes to F15.. Do it *now*! F15 is in its infancy. It's taking shape. If you want your feature to be a defining feature of F15. Get it in *now*. Yes. But please make those changes responsibly. We are starting to work on GNOME3 for F15 in rawhide now, and we cannot afford weeks of broken rawhide this cycle. If we all pay a little attention, we can keep rawhide continuously inhabitably. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: refining the feature process
On Wed, 2010-09-15 at 10:32 -0400, Matthew Miller wrote: On Wed, Sep 15, 2010 at 09:14:24AM -0500, Mike McGrath wrote: For people wanting to make big changes to F15.. Do it *now*! F15 is in its infancy. It's taking shape. If you want your feature to be a defining feature of F15. Get it in *now*. This seems like a completely sensible idea. However, it's not the current feature process. The Feature Freeze is currently immediately before the Branch Freeze, shortly before the Alpha Release. I'm a bit confused. You spend the rest of the mail talking about when the feature freeze is for F15, but I'm not sure why. As long as F15 is open and it's not frozen (which it obviously isn't, yet) you can start doing development in it. As John P said, we've already started approving features for F15. So right now you can submit a feature for F15, have it approved, and start committing it. What is it that makes you say it's 'not the current feature process'? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
While showing the user applications instead of packages might be a good idea for several use cases I think this approach misses the point here. The questions for redesigning the Updater dialog should be: What's the user supposed to decide and what information does he need to do so? The answer in 99.9% of the cases is either Run the update now or Run the update later. Deselecting any packages for update is a rare corner case. If it would be an important case yum - or may be even rpm would/should/must support version pinning to ignore updates of given packages for ever (it's getting off topic here). So there are two things for the user to weight up: The cost of the update and how urgent it is. To decide how urgent the updates are it is probably sufficient to tell the use the most urgent level (bugfix, security fix, enhancement). Giving the number of updates and download size per level allows more fine grained decisions and whether further looking into the details might be worth. The cost is basically the time, CPU, IO and bandwidth used. It is hard to give a good estimation about that, but just giving the download size (as a sum) should be good enough for us. Additionally the connectivity is important but not so easy to find out automatically. May be the user knows how he hooked up his computer - may be we remember the connectivity we had while downloading the meta data. Another important cost is interruption of service. So you should state whether a reboot or new login is required or which (currently running) applications will require a restart. So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 633728] perl-Format-Human-Bytes-0.06 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633728 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Format-Human-Bytes-0.0 ||6-1.fc15 Resolution||RAWHIDE Last Closed||2010-09-15 10:38:03 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: refining the feature process
On Wed, Sep 15, 2010 at 03:37:55PM +0100, Adam Williamson wrote: I'm a bit confused. You spend the rest of the mail talking about when the feature freeze is for F15, but I'm not sure why. As long as F15 is open and it's not frozen (which it obviously isn't, yet) you can start doing development in it. As John P said, we've already started approving features for F15. So right now you can submit a feature for F15, have it approved, and start committing it. What is it that makes you say it's 'not the current feature process'? The current process says you *can* start now, but the Feature Submission Deadline isn't until two weeks before Feature Freeze, which is in turn right before the Alpha. One *can* start developing features at any time, but there's nothing in the process that says one *should* do it earlier, and in fact, the late deadlines imply a defacto standard last-minute approach. This isn't helped by the description of the Feature Submission Deadline as not being really a deadline at all: FESCo will consider features proposed after this deadline on an exception basis. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-15 at 16:38 +0200, FlorianFesti wrote: So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. FWIW the Mac OS X update dialog looks almost exactly like this, and shows running applications you should close before running the update. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. I've asked for this feature before too, it's actually already there but hidden in the right click menu (at least for doing security only updates). Of course it's currently broken due to the fact I have: % sudo yum updateinfo Loaded plugins: aliases, keys, noop, presto, ps, security Updates Information Summary: available 4 Security notice(s) 105 Bugfix notice(s) 23 Enhancement notice(s) ...but PK refuses to do anything but update it's own 6 packages for a minor specfile change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python3 rpm macros not available without python3-devel installed
The main issue is failing to use a macro defined with %__python3 to specify
the version of a requirement.
The recipe is sth like this:
%global py3_ver %(echo `%{__python3} -c import sys;
sys.stdout.write(sys.version[:3])`)
...
Requires: python(abi) = %{py3_ver}
On Wed, Sep 15, 2010 at 10:32 PM, David Malcolm dmalc...@redhat.com wrote:
I suspect I haven't had enough coffee yet, but I don't see the problem
here. Why not simply add python3-devel as a build requirement as
Ignacio says?
If a build requirement isn't installed, it's acceptable for a build to
fail: it's a violation of a precondition.
On Wed, 2010-09-15 at 19:35 +0800, Robin Lee wrote:
You should build this package in a clean root like a mock environment.
If you have python3-devel already installed and then run rpmbuild
--rebuild, you will not see the issue.
On Wed, Sep 15, 2010 at 7:25 PM, Robin Lee robinlee.s...@gmail.com
wrote:
For a more concrete example:
https://bugzilla.redhat.com/show_bug.cgi?id=567348
I want to set the python(abi) requirement of the subpackage at
buildtime. So, I want to set it like this:
Requires: python(abi) = %{py3_ver}
But when build it, it will fail with the following output:
$ rpmbuild -bp dreampie.spec
Building target platforms: i686
Building for target i686
sh: python3: command not found
sh: python3: command not found
sh: python3: command not found
error: line 46: Version required: Requires: python(abi) =
Even though python3-devel has been added as BR.
On Wed, Sep 15, 2010 at 7:06 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
On Wed, 2010-09-15 at 18:22 +0800, Robin Lee wrote:
python3 rpm macros not available without
python3-devel installed.
'rpmbuild --viewrc' will show you.
So if you use the python3 macros to define another
macro and you have
no python3-devel installed, you must fail.
So, how to define, for example, a %py3_ver macro for
the major version
of Python3? Must yum be used?
Robin
Adding a BuildRequires: python3-devel should be
enough to pull them
in.
--
Ignacio Vazquez-Abrams ivazquez...@gmail.com
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 4:25 PM, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 15, 2010 at 07:20:30 -0700, John Poelstra poels...@redhat.com wrote: And we are already reviewing and accepting features for Fedora 15. The process never stops. https://fedoraproject.org/wiki/Features/Policy Thanks for the reminder; I'll put LZMA back in for F15 and hope the kernel changes make it in by then. That doesn't work ... someone has to be activly pushing the patches upstream .. instead of just waiting and hoping that they magically make it in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 15, 2010 at 4:38 PM, FlorianFesti ffe...@redhat.com wrote: While showing the user applications instead of packages might be a good idea for several use cases I think this approach misses the point here. The questions for redesigning the Updater dialog should be: It is not only about the updater but about browsing for available applications / installing them. (The rest of the mail makes sense to me but it doesn't conflict with what Richard is trying to achieve). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 17:11:03 +0200, drago01 drag...@gmail.com wrote: That doesn't work ... someone has to be activly pushing the patches upstream .. instead of just waiting and hoping that they magically make it in. It's somewhere on Lougher's to do list. We can still be ready to take advantage of it if it gets completed without being especially active in their development. Just knowing their is a distro waiting to use the stuff when it gets upstream might (or might not) provide additional motivation for getting it done. That said, if someone is willing and able to help Lougher out, I'm all for it. But it is out of scope for my job, which I see as Fedora integration. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100915 changes
Compose started at Wed Sep 15 13:15:11 UTC 2010 Broken deps for x86_64 -- RackTables-0.18.3-1.fc14.noarch requires /usr/local/bin/php RackTables-0.18.3-1.fc14.noarch requires perl(File::FnMatch) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) empathy-2.31.90-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-9.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gnome-python2-evolution-2.31.1-5.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Gtk2-MozEmbed-0.08-6.fc14.15.x86_64 requires gecko-libs = 0:1.9.2.4 plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) python-polybori-0.5-8.fc14.i686 requires libboost_python.so.1.41.0 python-polybori-0.5-8.fc14.x86_64 requires libboost_python.so.1.41.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- RackTables-0.18.3-1.fc14.noarch requires /usr/local/bin/php RackTables-0.18.3-1.fc14.noarch requires perl(File::FnMatch) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cyphesis-0.5.21-2.fc13.i686 requires libpython2.6.so.1.0 empathy-2.31.90-1.fc14.i686 requires libcamel-1.2.so.19 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 evolution-sharp-0.21.1-9.fc14.i686 requires libcamel-1.2.so.19 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gnome-python2-evolution-2.31.1-5.fc14.i686 requires libcamel-1.2.so.19 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 5:15 PM, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 15, 2010 at 17:11:03 +0200, drago01 drag...@gmail.com wrote: That doesn't work ... someone has to be activly pushing the patches upstream .. instead of just waiting and hoping that they magically make it in. It's somewhere on Lougher's to do list. We can still be ready to take advantage of it if it gets completed without being especially active in their development. Just knowing their is a distro waiting to use the stuff when it gets upstream might (or might not) provide additional motivation for getting it done. That said, if someone is willing and able to help Lougher out, I'm all for it. But it is out of scope for my job, which I see as Fedora integration. I said _someone_ not _you_ ;) ... if Lougher is working on it fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problem while building mono-2.8
Hi, I've not come across this (mainly as I've not been that active due to a mix of work problems and hardware problems which meant a big re-install). Most of mono is built, but I've just hit this error *** ERROR: No build ID note found in /home/paul/rpmbuild/BUILDROOT/mono-2.8-1.fc15.i386/usr/lib/mono/2.0/mscorlib.dll.so googling suggests that there has been a change and that I need to add LDFLAGS += --build-id in the build and install parts. I've not had to do this before, so am I missing something and if I include it, will it then fail to build on koji? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
drago01 (drag...@gmail.com) said: The only real issues pointed out where lack of documentation and system-config-service integration for native services. Neither that we have with upstart so not really a regression and thus warrant a reject. system services have not been migrated to upstart. They have/had been migrated to systemd, which makes this not an apples-to-apples comparison. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problem with 2.6.35.4-12.fc14.x86_64
Hi,
Does anyone know something about this issue?
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz stepping 0a
lockdep: fixing up alternatives.
===
[ INFO: suspicious rcu_dereference_check() usage. ]
---
kernel/sched.c:616 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
3 locks held by swapper/1:
#0: (cpu_add_remove_lock){+.+.+.}, at: [81052b87]
cpu_maps_update_begin+0x17/0x19
#1: (cpu_hotplug.lock){+.+.+.}, at: [81052a9a]
cpu_hotplug_begin+0x2c/0x53
#2: (rq-lock){-.-...}, at: [81495b4c] init_idle+0x30/0x131
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-12.fc14.x86_64 #1
Call Trace:
[8107bd3a] lockdep_rcu_dereference+0xaa/0xb3
[8103fdc5] task_group+0x80/0x8f
[8103fdeb] set_task_rq+0x17/0x73
[81495c06] init_idle+0xea/0x131
[81495fd6] fork_idle+0x92/0xa3
[8107e820] ? mark_held_locks+0x50/0x72
[81493a77] do_fork_idle+0x1c/0x2d
[81493bbf] do_boot_cpu+0x137/0x9b1
[81493a5b] ? do_fork_idle+0x0/0x2d
[81494c5d] native_cpu_up+0x100/0x1c2
[814960af] _cpu_up+0x9d/0xf9
[814961de] cpu_up+0xd3/0xe5
[81d78d86] kernel_init+0x105/0x2c9
[8100aae4] kernel_thread_helper+0x4/0x10
[8149d390] ? restore_args+0x0/0x30
[81d78c81] ? kernel_init+0x0/0x2c9
[8100aae0] ? kernel_thread_helper+0x0/0x10
Booting Node 0, Processors #1
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#2
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#3
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#4
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#5
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#6
mce: CPU supports 0 MCE banks
lockdep: fixing up alternatives.
#7 Ok.
mce: CPU supports 0 MCE banks
Skipped synchronization checks as TSC is reliable.
Brought up 8 CPUs
Total of 8 processors activated (47880.46 BogoMIPS).
x86 PAT enabled: cpu 6, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 4, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 2, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 1, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 7, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 3, old 0x0, new 0x7010600070106
x86 PAT enabled: cpu 5, old 0x0, new 0x7010600070106
Best regards,
Morten
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Richard Hughes (hughsi...@gmail.com) said: On 14 September 2010 23:01, Kevin Fenzi ke...@scrye.com wrote: 21:33:35 nirik The other 2 items I had were: 21:33:56 nirik application installer issues 21:33:57 nirik https://bugzilla.redhat.com/show_bug.cgi?id=488968 21:34:04 nirik and 21:34:05 nirik BuildIdBuild infrastructure 21:34:06 nirik https://fedorahosted.org/fedora-infrastructure/ticket/2387 21:34:57 mclasen that needs more time, I'd say 21:35:08 nirik ok, will close out if no one has anything further... Well, that was enlightening. Do you think someone from FESCo could write something about https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and make a decision please. Discussion on this was postponed due to a lack of time, nothing more. Please, come to next week's meeting. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
If I have to wait for the next release of Fedora (14 for example) to get KDE 4.5 then it's looking like the stable updates vision has made Fedora incompatible with what I need. I will need to consider another distribution (OpenSUSE most likely, their GCC 4.5 also doesn't suck; LTO = enabled). After waiting 6 months for an upstream release, its a real bother to wait another 4-6 months for a Fedora release to incorporate it. Fedora used to be known for having the freshest software. F14 leaves much to be desired. I'm probably not the only one who will leave for greener pastures. On Wed, Sep 15, 2010 at 11:45 AM, Bill Nottingham nott...@redhat.com wrote: Richard Hughes (hughsi...@gmail.com) said: On 14 September 2010 23:01, Kevin Fenzi ke...@scrye.com wrote: 21:33:35 nirik The other 2 items I had were: 21:33:56 nirik application installer issues 21:33:57 nirik https://bugzilla.redhat.com/show_bug.cgi?id=488968 21:34:04 nirik and 21:34:05 nirik BuildIdBuild infrastructure 21:34:06 nirik https://fedorahosted.org/fedora-infrastructure/ticket/2387 21:34:57 mclasen that needs more time, I'd say 21:35:08 nirik ok, will close out if no one has anything further... Well, that was enlightening. Do you think someone from FESCo could write something about https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and make a decision please. Discussion on this was postponed due to a lack of time, nothing more. Please, come to next week's meeting. Bill -- 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: python3 rpm macros not available without python3-devel installed
Oh, sorry. I may have chosen a bad email subject.
This failed scratch build shows what was happening:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2468876
On Wed, Sep 15, 2010 at 11:07 PM, Robin Lee robinlee.s...@gmail.com wrote:
The main issue is failing to use a macro defined with %__python3 to specify
the version of a requirement.
The recipe is sth like this:
%global py3_ver %(echo `%{__python3} -c import sys;
sys.stdout.write(sys.version[:3])`)
...
Requires: python(abi) = %{py3_ver}
On Wed, Sep 15, 2010 at 10:32 PM, David Malcolm dmalc...@redhat.comwrote:
I suspect I haven't had enough coffee yet, but I don't see the problem
here. Why not simply add python3-devel as a build requirement as
Ignacio says?
If a build requirement isn't installed, it's acceptable for a build to
fail: it's a violation of a precondition.
On Wed, 2010-09-15 at 19:35 +0800, Robin Lee wrote:
You should build this package in a clean root like a mock environment.
If you have python3-devel already installed and then run rpmbuild
--rebuild, you will not see the issue.
On Wed, Sep 15, 2010 at 7:25 PM, Robin Lee robinlee.s...@gmail.com
wrote:
For a more concrete example:
https://bugzilla.redhat.com/show_bug.cgi?id=567348
I want to set the python(abi) requirement of the subpackage at
buildtime. So, I want to set it like this:
Requires: python(abi) = %{py3_ver}
But when build it, it will fail with the following output:
$ rpmbuild -bp dreampie.spec
Building target platforms: i686
Building for target i686
sh: python3: command not found
sh: python3: command not found
sh: python3: command not found
error: line 46: Version required: Requires: python(abi) =
Even though python3-devel has been added as BR.
On Wed, Sep 15, 2010 at 7:06 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
On Wed, 2010-09-15 at 18:22 +0800, Robin Lee wrote:
python3 rpm macros not available without
python3-devel installed.
'rpmbuild --viewrc' will show you.
So if you use the python3 macros to define another
macro and you have
no python3-devel installed, you must fail.
So, how to define, for example, a %py3_ver macro for
the major version
of Python3? Must yum be used?
Robin
Adding a BuildRequires: python3-devel should be
enough to pull them
in.
--
Ignacio Vazquez-Abrams ivazquez...@gmail.com
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
[389-devel] Please Review: (630097) fix coverity Defect Type: Null pointer dereferences issues
https://bugzilla.redhat.com/show_bug.cgi?id=630097 https://bugzilla.redhat.com/attachment.cgi?id=446995action=edit https://bugzilla.redhat.com/attachment.cgi?id=447038action=edit https://bugzilla.redhat.com/attachment.cgi?id=447061action=edit https://bugzilla.redhat.com/attachment.cgi?id=447062action=edit https://bugzilla.redhat.com/attachment.cgi?id=447067action=edit https://bugzilla.redhat.com/attachment.cgi?id=447250action=edit https://bugzilla.redhat.com/attachment.cgi?id=447259action=edit https://bugzilla.redhat.com/attachment.cgi?id=447279action=edit https://bugzilla.redhat.com/attachment.cgi?id=447293action=edit https://bugzilla.redhat.com/attachment.cgi?id=447297action=edit https://bugzilla.redhat.com/attachment.cgi?id=447299action=edit https://bugzilla.redhat.com/attachment.cgi?id=447300action=edit https://bugzilla.redhat.com/attachment.cgi?id=447321action=edit https://bugzilla.redhat.com/attachment.cgi?id=447336action=edit https://bugzilla.redhat.com/attachment.cgi?id=447351action=edit https://bugzilla.redhat.com/attachment.cgi?id=447503action=edit https://bugzilla.redhat.com/attachment.cgi?id=447508action=edit https://bugzilla.redhat.com/attachment.cgi?id=447509action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 634133] perl-DBD-SQLite-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=634133 Petr Sabata psab...@redhat.com changed: What|Removed |Added URL||https://rt.cpan.org/Public/ ||Bug/Display.html?id=61361 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 634133] perl-DBD-SQLite-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=634133 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||p...@city-fan.org --- Comment #1 from Paul Howarth p...@city-fan.org 2010-09-15 12:04:19 EDT --- I have documented some issues I had building DBD::SQLite with the system SQLite at https://rt.cpan.org/Public/Bug/Display.html?id=61361 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
-static packages
Hi, I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? Cheers, Rob signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 634133] perl-DBD-SQLite-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=634133 --- Comment #2 from Petr Sabata psab...@redhat.com 2010-09-15 12:07:34 EDT --- Thanks Paul. I've been playing with the failing tests for a while now. I'd disable the SQLITE_ENABLE_FTS3_PARENTHESIS completely (and skip the tests using it) for now. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 11:53:51AM -0400, Brandon Lozza wrote: If I have to wait for the next release of Fedora (14 for example) to get KDE 4.5 then it's looking like the stable updates vision has made If you need the absolute latest of everything without waiting three months for the release, take a look at running Rawhide. I do on my primary desktop machine at work, and it's great. That said, I think the process for update this component to a new point release must necessarily be different from the one for replacing a core component with a completely new design. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On Wed, Sep 15, 2010 at 05:06:20PM +0100, Robert Spanton wrote: I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? Better yet is not to link statically. http://www.akkadia.org/drepper/no_static_linking.html Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On 09/15/2010 05:06 PM, Robert Spanton wrote: Hi, I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? You might find the Fedora packaging guidelines for packaging static libraries helps explain the rationale a bit more: http://tinyurl.com/kz4rp [fedoraproject.org] There have also been several discussions of this on the fedora lists over the years, e.g.: http://www.spinics.net/lists/fedora-devel/msg48361.html Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 17:20:22 +0200, drago01 drag...@gmail.com wrote: I said _someone_ not _you_ ;) ... if Lougher is working on it fine. It's on his to do list, which isn't really the same thing. Lately he has been doing more getting the extended attributes feature cleaned up and a bit with the lzo stuff (which is in the kernel and seems to just be entering the 4.1 dev version of squashfs-tools now). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Today is the LAST DAY to fix bugs for the Fedora 14 Beta
The Fedora 14 Beta RC compose is scheduled for tomorrow.
ALL open bugs on Fedora 14 Blocker list (http://bit.ly/cZKo9K) MUST BE
FIXED TODAY or we risk delaying the release. In other words we are very
short on time to address the remaining bugs.
Here is the current state of things based on the comments in each bug:
629719 :: NEW :: anaconda :: Anaconda Maintenance Team ::
FormatCreateError: ('invalid device specification', '/dev/md127p3') ::
https://bugzilla.redhat.com/show_bug.cgi?id=629719
Need to make a decision as to whether this bug should remain a blocker
based on testing feedback
634205 :: NEW :: bluez :: Bastien Nocera :: Bluetooth always disabled on
startup. :: https://bugzilla.redhat.com/show_bug.cgi?id=634205
New bug. Need assessment and a fix (if applicable) from maintainer ASAP
628239 :: NEW :: anaconda :: Brian C. Lane :: Fedora 14 Alpha reduced
graphics creates vesa-using xorg.conf but doesn't blacklist nouveau ::
https://bugzilla.redhat.com/show_bug.cgi?id=628239
Need additional confirmation that this bug still exists, but most likely
will be dropped.
633234 :: NEW :: anaconda :: Brian C. Lane :: Previous grub entry is not
overwritten after upgrade with creating new bootloader ::
https://bugzilla.redhat.com/show_bug.cgi?id=633234
Being researched by anacconda team. Could someone from the anaconda
team add a current status to the comments of the bug?
633315 :: NEW :: NetworkManager :: Dan Williams :: Connections not
editable in nm-c-e in anaconda ::
https://bugzilla.redhat.com/show_bug.cgi?id=633315
New bug. Need assessment and a fix (if applicable) from maintainer ASAP
632510 :: MODIFIED :: anaconda :: Chris Lumens :: Installer exited
abnormally when starting network in rescue mode ::
https://bugzilla.redhat.com/show_bug.cgi?id=632510
Need update submitted to Bodhi ASAP so this bug can change to ON_QA
632489 :: MODIFIED :: anaconda :: Radek Vykydal :: Fail to read package
metadata after specifying repo= ::
https://bugzilla.redhat.com/show_bug.cgi?id=632489
Need update submitted to Bodhi ASAP so this bug can change to ON_QA
___
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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 01:31:50PM +0100, Adam Williamson wrote: On Wed, 2010-09-15 at 14:27 +0200, Tomasz Torcz wrote: Personally, I'm very sad because of deferring systemd to F15. It may cause slipping of SysV-free Fedora to F16, full year wait from now. And integration as session daemon in DEs even further. There's no reason it should. Remember, F15 is open *now*, Rawhide is F15. All this work can be done right now, if there's the will to do it. Actually, iiuc, tomasz is talking about migrating sysv-init scripts to systemd unit files. There is a blocker to doing that in F15 which is that lennart, notting, and walters (that I remember) are against doing a mass migration to unit files until after systemd has been running for at least one release. This allows best practices for writing unit files to emerge and get codified in a packaging guideline. Without information on how to write unit files well, we're not going to be porting scripts over. -Toshio pgpOMDRzhK8zT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On Wed, 2010-09-15 at 17:06 +0100, Robert Spanton wrote: I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? I think the answer is no: Fedora wishes to discourage static linking. You can continue to build your own -static packages, or you can install the libraries you need manually in your home directory (which probabably isn't any easier, but gives you the other benefits of dynamic linking), or you could set up a QEMU or User Mode Linux VM and install whatever you like. Ideally, we would have a packaging tool that works for per-user software collections as well as the system. That's something I plan to work on in the next few years. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Voting Process [WAS: FESCo decision on systemd]
On Wed, 15 Sep 2010, Jon Masters wrote: On Tue, 2010-09-14 at 21:26 -0400, Máirín Duffy wrote: On Tue, 2010-09-14 at 19:02 -0600, Kevin Fenzi wrote: I'm happy to look for ways to make the other fesco voices heard. Any ideas? I could try making the tickets have some more descriptive subject like HEY VOTE ON THIS PLEASE BEFORE NEXT MEETING: or something. Hmm. Here's a couple ideas I could think of: - If you don't place a vote by $DATE, your vote will be assumed to be $POSITION can be scarily motivating. I think that's unfortunate. No elected body operates in this way because there are always reasons why people can't attend a meeting every time. - Nag emails sent out by trac daily until you click on the email's yes no links to vote! (some of the ticket reminder trac hacks might work to provide this) An equivalent to the Serjeant-at-Arms might be a good idea. But rather than legal authority to hound down members and compel them under penalty of Federal imprisonment, I suggest simply a requirement that they be required to vote within a specific period of time for certain issues, with someone appointed to ensure that this is happening as needed. You might also require members to maintain a certain percentage of attendance, or less than a specific deviation from the average attendance of other members (perhaps the latter) in order to be an active member of the body. Gregdek mentioned voter fatigue on FAB a while back. I know exactly what he's talking about though I'm not quite sure how to fix it. I suppose meeting fatigue isn't much different. -Mike-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
I've not come across this (mainly as I've not been that active due to a mix of work problems and hardware problems which meant a big re-install). Most of mono is built, but I've just hit this error *** ERROR: No build ID note found in /home/paul/rpmbuild/BUILDROOT/mono-2.8-1.fc15.i386/usr/lib/mono/2.0/mscorlib.dll.so googling suggests that there has been a change and that I need to add LDFLAGS += --build-id in the build and install parts. I've not had to do this before, so am I missing something and if I include it, will it then fail to build on koji? That is not usually the ideal solution. And that the problem is new (some time after F8) suggests there may be something more strange going on. I'll help you figure it out if I can see the build. If it's otherwise readyish, you might as well just commit it to git for rawhide (or make another branch in git if you like), as the easy way for me to get and try it. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Voting Process [WAS: FESCo decision on systemd]
On Wed, Sep 15, 2010 at 12:36:40PM -0500, Mike McGrath wrote: Gregdek mentioned voter fatigue on FAB a while back. I know exactly what he's talking about though I'm not quite sure how to fix it. I suppose meeting fatigue isn't much different. http://www.public-software-group.org/liquid_feedback maybe? -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with 2.6.35.4-12.fc14.x86_64
On Wed, 15 Sep 2010 17:44:47 +0200 Morten P.D. Stevens wrote: Does anyone know something about this issue? [...] === [ INFO: suspicious rcu_dereference_check() usage. ] --- kernel/sched.c:616 invoked rcu_dereference_check() without protection! Try kernel = 2.6.35.4-21 from Koji. It has this change * Mon Sep 06 2010 Kyle McMartin k...@redhat.com - Patch from paulmck to fix rcu_dereference_check warning (http://lkml.org/lkml/2010/8/16/258) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Thorsten Leemhuis said the following on 09/15/2010 12:09 AM Pacific Time: Toshio Kuratomi wrote on 15.09.2010 04:54: On Tue, Sep 14, 2010 at 07:02:33PM -0600, Kevin Fenzi wrote: On Tue, 14 Sep 2010 20:48:13 -0400 Máirín Duffydu...@fedoraproject.org wrote: Only 5 of the 9 FESCo members voted on this issue. If all 9 had voted, even with the current 3 for / 2 against vote, systemd could easily have enough votes for inclusion in F14. I have a couple of questions for you, FESCo, since I honestly don't know and maybe would feel more comfortable knowing: ok. - Has there been any consideration for formalizing the acceptable of absentee votes? no, but perhaps there should be? Just a side note: That has problems of its own, as those votes might happen before new aspects come up in the IRC discussion that normally precedes the votes in IRC meetings... - How many members must be present at a meeting for a voting decision to be considered valid? My understanding: A quorum (ie, 5 of 9). Note, in the distant past, FESCo's rule was majority of the folks present with an attempt made at unanimity by the present members by resolving (as much as possible) their differences in opinion. This was actually stated in meetings but I don't think that it made it to the wiki -- thl might know as that was during his tenure as chair. However, I don't believe this rule has been followed in a *long* time so it might just be a historical footnote to this conversation. Yes, back then we afaics tried a whole lot harder to make everyone happy. That included even non-FESCo members that tried to raise options on a particular topic on the list or in IRC meeting; we even let those non-FESCo-members share a (mostly unofficial) vote on IRC, as those votes often influenced how FESCo member voted (which IMHO was a good thing). Maybe I'm reading more than you intended into what you said. I don't believe it is part of FESCo's charter or any other Fedora leadership group to make everyone happy. That is an impossible job. My expectation of the leadership bodies in Fedora is that they oversee the current work and future direction of Fedora and do what is best for Fedora's success and future--even if there isn't unanimous happiness or agreement in the community. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with 2.6.35.4-12.fc14.x86_64
2010/9/15 Michal Schmidt mschm...@redhat.com: On Wed, 15 Sep 2010 17:44:47 +0200 Morten P.D. Stevens wrote: Does anyone know something about this issue? [...] === [ INFO: suspicious rcu_dereference_check() usage. ] --- kernel/sched.c:616 invoked rcu_dereference_check() without protection! Try kernel = 2.6.35.4-21 from Koji. It has this change * Mon Sep 06 2010 Kyle McMartin k...@redhat.com - Patch from paulmck to fix rcu_dereference_check warning (http://lkml.org/lkml/2010/8/16/258) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel One problem fixed, introduced another === [ INFO: suspicious rcu_dereference_check() usage. ] --- include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection! At least on my Atom 330 with 2.6.35.4-25.fc13.x86_64. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: refining the feature process
Matthew Miller said the following on 09/15/2010 07:57 AM Pacific Time: On Wed, Sep 15, 2010 at 03:37:55PM +0100, Adam Williamson wrote: I'm a bit confused. You spend the rest of the mail talking about when the feature freeze is for F15, but I'm not sure why. As long as F15 is open and it's not frozen (which it obviously isn't, yet) you can start doing development in it. As John P said, we've already started approving features for F15. So right now you can submit a feature for F15, have it approved, and start committing it. What is it that makes you say it's 'not the current feature process'? The current process says you *can* start now, but the Feature Submission Deadline isn't until two weeks before Feature Freeze, which is in turn right before the Alpha. I don't recall any situation where someone submitted a feature at the deadline without having done anything and then scrambling for two weeks to finish by feature freeze. One *can* start developing features at any time, but there's nothing in the process that says one *should* do it earlier, and in fact, the late deadlines imply a defacto standard last-minute approach. This isn't helped by the description of the Feature Submission Deadline as not being really a deadline at all: FESCo will consider features proposed after this deadline on an exception basis. Exceptions have been few and far between, and only granted, to my knowledge, for features that were 100% complete. Those deadlines are set in such a way as to put as much development time as possible into a release schedule. From a release engineering perspective (the team proposing the schedules for approval by FESCo) it was determined that this was the highest value. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
