Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 21:54 -0500, inode0 wrote: > On Wed, Sep 15, 2010 at 9:46 PM, Jon Masters wrote: > > btw, I think Kyle said earlier he's standing aside. So does that mean > > there now is a new FESCo election? > > No, FESCo has policies in place to deal with this situation described here > > http://fedoraproject.org/wiki/FESCo_election_policy Ok. I failed to check to see there was a process. Shame on me. Ok, so I assume they'll discuss it in their next regular meeting. Jon. -- 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 9:46 PM, Jon Masters wrote: > On Wed, 2010-09-15 at 18:09 -0400, Máirín Duffy wrote: >> That's a good point, but I would hope that someone elected to serve on a >> body in Fedora would actually *want* to vote, and the measures above are >> just ideas meant to be motivation/reminder than "forcing." > > Right. I'm not saying Jarod should issue Fedora Arrest Warrants (FAWs?) > for the members of FESCo (or the Board), but there should be an official > means by which votes can be counted in absentia, and in some cases it > may be required that everyone has to vote, and that's a good thing. > > btw, I think Kyle said earlier he's standing aside. So does that mean > there now is a new FESCo election? No, FESCo has policies in place to deal with this situation described here http://fedoraproject.org/wiki/FESCo_election_policy John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 15 or rawhide?
On Wed, 2010-09-15 at 14:04 -0700, John Poelstra wrote: > Nils Philippsen said the following on 09/15/2010 03:28 AM Pacific Time: > > 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 > > I guess I'd say, there's a bug in /etc/fedora-release :-) Can we get a word from Jesse on this? For context, Jesse, this is my point that things like ABRT are looking for "15" as the version of Fedora to file bugs against, based on the release info. But 15 is rawhide until it branches. So some kind of change is required. Either the release package is changed, things like ABRT are, or we decide stuff present pre-branch counts enough toward the final and make the BZ "15". Jon. -- 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 18:09 -0400, Máirín Duffy wrote: > On Wed, 2010-09-15 at 22:33 +0200, Nicolas Mailhot wrote: > > I really don't see the point. A forced vote is not better than no vote > > (can easily be worse). As far as I know in most countries actual laws > > are passed by whoever is present in Parliament (baring very specific > > exceptions). If there are few people it's not a problem, it just shows > > the issue is either not very important, or the consensus has already > > been achieved. As I alluded to previously, many government bodies have the power to legally compel members to turn up for a vote. The Sergeant at Arms in the US example can literally hound down a member via a Congressional arrest warrant and physically ensure they turn up to a vote, and this has been done in the past if there is lack of a voting quorum (51 in the case of the US Senate when it was last actually done). I also noted that Fedora doesn't have this kind of power, but it's not unreasonable to require that elected representatives turn up to vote on your behalf. > That's a good point, but I would hope that someone elected to serve on a > body in Fedora would actually *want* to vote, and the measures above are > just ideas meant to be motivation/reminder than "forcing." Right. I'm not saying Jarod should issue Fedora Arrest Warrants (FAWs?) for the members of FESCo (or the Board), but there should be an official means by which votes can be counted in absentia, and in some cases it may be required that everyone has to vote, and that's a good thing. btw, I think Kyle said earlier he's standing aside. So does that mean there now is a new FESCo election? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Beta Change Deadline Reached 2010-09-14
As a reminder, we have reached the Beta Change Deadline for Fedora 14. "At the change deadlines for Alpha and Beta, pushes to the branched development repository (e.g. /pub/fedora/linux/development/14), are suspended until the Release Candidate has been successfully tested and staging has started to the mirrors." More details are located here: https://fedoraproject.org/wiki/Change_deadlines John ___ 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
We have reached Fedora 14 Feature Complete
Thank you to all the feature owners and developers for all their hard work to make Fedora 14 the best Fedora release yet. We are almost to the end! As a follow-up to last week's reminder http://lists.fedoraproject.org/pipermail/devel-announce/2010-September/000676.html ALL feature pages are now expected to be at 100% completion. The following features are not listed at 100% complete and are being sent to FESCo (https://fedorahosted.org/fesco/ticket/468) for re-evaluation for inclusion in the Fedora 14 feature list if they remain incomplete: https://fedoraproject.org/wiki/Features/D_Programming (yes, a mere technicality at 99% done) https://fedoraproject.org/wiki/Features/GdbIndex https://fedoraproject.org/wiki/Features/GNUstep https://fedoraproject.org/wiki/Features/MemoryDebuggingTools https://fedoraproject.org/wiki/Features/Python_2.7 https://fedoraproject.org/wiki/Features/Spice Thank you, John p.s. Individual feature owners have been cc'd on this message. ___ 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, 2010-09-15 at 22:33 +0200, Nicolas Mailhot wrote: > Le mardi 14 septembre 2010 à 21:26 -0400, Máirín Duffy a écrit : > > 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. > > > > - 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) > > I really don't see the point. A forced vote is not better than no vote > (can easily be worse). As far as I know in most countries actual laws > are passed by whoever is present in Parliament (baring very specific > exceptions). If there are few people it's not a problem, it just shows > the issue is either not very important, or the consensus has already > been achieved. That's a good point, but I would hope that someone elected to serve on a body in Fedora would actually *want* to vote, and the measures above are just ideas meant to be motivation/reminder than "forcing." Honestly, I'm not sure they are great ideas but certainly throwing something out there means more brain food to help generate an actually good idea. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
On Wednesday, September 15, 2010 03:56:39 pm Paul F. Johnson wrote: > Hi Dennis, > > > Mono has had alot of issues building on x86_64 recently. it would be > > great if you worked with upstream to track down and resolve the 64 bit > > issues. > > > >From what I've seen, 2.8 fixes quite a lot of the issues with 64 bit > > systems. Are there any specifics I should look at? > > TTFN > > Paul I dont know of any specifics. just that there has been issues getting it built. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with 2.6.35.4-12.fc14.x86_64
On Wed, Sep 15, 2010 at 11:11:52PM +0200, Morten P.D. Stevens wrote: > > > -Original Message- > > From: devel-boun...@lists.fedoraproject.org [mailto:devel- > > boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt > > Sent: Wednesday, September 15, 2010 8:03 PM > > To: devel@lists.fedoraproject.org > > Subject: 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 > > The same problem with the newest 2.6.35.4-28.fc14.x86_64 kernel. > > === > [ INFO: suspicious rcu_dereference_check() usage. ] > --- > include/linux/cgroup.h:542 invoked rcu_dereference_check() without > protection! This is the 2nd variant that I just fixed. No builds yet. Dave -- 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
> -Original Message-
> From: devel-boun...@lists.fedoraproject.org [mailto:devel-
> boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt
> Sent: Wednesday, September 15, 2010 8:03 PM
> To: devel@lists.fedoraproject.org
> Subject: 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
Hi Michael,
The same problem with the newest 2.6.35.4-28.fc14.x86_64 kernel.
===
[ INFO: suspicious rcu_dereference_check() usage. ]
---
include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/1:
#0: (net_mutex){+.+.+.}, at: []
register_pernet_subsys+0x1f/0x47
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1
Call Trace:
[] lockdep_rcu_dereference+0xaa/0xb3
[] sock_update_classid+0x7c/0xa2
[] sk_alloc+0x6b/0x77
[] __netlink_create+0x37/0xab
[] ? rtnetlink_rcv+0x0/0x2d
[] netlink_kernel_create+0x74/0x19d
[] ? __mutex_lock_common+0x339/0x35b
[] rtnetlink_net_init+0x2e/0x48
[] ops_init+0xe9/0xff
[] register_pernet_operations+0xab/0x130
[] register_pernet_subsys+0x2e/0x47
[] rtnetlink_init+0x53/0x102
[] netlink_proto_init+0x126/0x143
[] ? netlink_proto_init+0x0/0x143
[] do_one_initcall+0x72/0x186
[] kernel_init+0x23b/0x2c9
[] kernel_thread_helper+0x4/0x10
[] ? restore_args+0x0/0x30
[] ? kernel_init+0x0/0x2c9
[] ? kernel_thread_helper+0x0/0x10
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)
On Wed, 15 Sep 2010 11:53:51 -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 > Fedora incompatible with what I need. KDE 4.5 has not been released to updates because it has known unsolved regressions. See the tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.5 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 15 or rawhide?
Nils Philippsen said the following on 09/15/2010 03:28 AM Pacific Time: > 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 I guess I'd say, there's a bug in /etc/fedora-release :-) John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
> I can email you over the throwback from the build (or the spec file with > altered patches), but as it dies on on the missing build ID (even with > the LDFLAGS thing added), there is no build. The log might help. I meant, the source, so I can attempt the build. Use git. It's your friend. Just push some changes, to another branch if you're timid. > I'm assuming that make LDFLAGS+=--build-id is correct and that I don't > need to export it or add anything else.. That's not a good assumption. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
Hi, > > 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. I can email you over the throwback from the build (or the spec file with altered patches), but as it dies on on the missing build ID (even with the LDFLAGS thing added), there is no build. I'm assuming that make LDFLAGS+=--build-id is correct and that I don't need to export it or add anything else.. TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
Hi Dennis, > Mono has had alot of issues building on x86_64 recently. it would be great > if > you worked with upstream to track down and resolve the 64 bit issues. >From what I've seen, 2.8 fixes quite a lot of the issues with 64 bit systems. Are there any specifics I should look at? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/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=447549&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447566&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Le mardi 14 septembre 2010 à 21:26 -0400, Máirín Duffy a écrit : > 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. > > - 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) I really don't see the point. A forced vote is not better than no vote (can easily be worse). As far as I know in most countries actual laws are passed by whoever is present in Parliament (baring very specific exceptions). If there are few people it's not a problem, it just shows the issue is either not very important, or the consensus has already been achieved. -- Nicolas Mailhot -- 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 Dave Jones : > On Wed, Sep 15, 2010 at 08:11:47PM +0200, Michał Piotrowski wrote: > > > 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. > > Just committed a fix for this. Thanks! Will try it later when packages appear in koji. > > Dave > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- 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)
Le mercredi 15 septembre 2010 à 12:40 +0200, drago01 a écrit : > On Wed, Sep 15, 2010 at 12:27 PM, M A Young wrote: > > On Wed, 15 Sep 2010, drago01 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. > > IIRC systemd wasn't even written back then. While I like systemd and will continue to try to identify bugs and report them so they get fixed before the next evaluation phase, I've always felt that it was quite unreasonable to try to push it in F14 given when it was published. I would have taken a small miracle for it to be integrated properly in such a short time. Core invasive features need to be pushed in devel at branch time and mature a full cycle. The cycle starts when the previous release is branched and rawhide is freed, not when the target release is branched from rawhide. The time between two branchings is not lost eats-babies no-one-cares-about period it's there for people who need heavy/complex/thorough testing post-branch phase can no provide (it's way too short). Here the problem is not F14 branch time but rather unreasonable expectations (try to force feed a major change on the eve of branching and alpha composing; if you're late you're late, just target the next release). Also, I would like to thank all the other Fedora packagers that kept quiet and tried to give systemd its chance. Because systemd has mobilized a lot of testing energy early in F14 cycle, and cannibalized resources other components could have reasonably expected to have a bigger share of. Thanks all for your support of Lennart in time of need. -- Nicolas Mailhot -- 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, Sep 15, 2010 at 08:11:47PM +0200, Michał Piotrowski wrote: > 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. Just committed a fix for this. Dave -- 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 Morten P.D. Stevens : >> -Original Message- >> From: devel-boun...@lists.fedoraproject.org [mailto:devel- >> boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt >> Sent: Wednesday, September 15, 2010 8:03 PM >> To: devel@lists.fedoraproject.org >> Subject: 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 > > Hi Michael, > > Where to get 2.6.35.4-21? http://koji.fedoraproject.org/koji/packageinfo?packageID=8 > > Best regards, > > Morten > -- > 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: Problem with 2.6.35.4-12.fc14.x86_64
> -Original Message- > From: devel-boun...@lists.fedoraproject.org [mailto:devel- > boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt > Sent: Wednesday, September 15, 2010 8:03 PM > To: devel@lists.fedoraproject.org > Subject: 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 Hi Michael, Where to get 2.6.35.4-21? 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)
Toshio Kuratomi (a.bad...@gmail.com) said: > 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. My opinion is that we'd want some best practices, but that is more tied to time and testing, not a specific number of releases. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
On Wednesday, September 15, 2010 10:41:26 am Paul F. Johnson wrote: > 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/mscorl > ib.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 Mono has had alot of issues building on x86_64 recently. it would be great if you worked with upstream to track down and resolve the 64 bit issues. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gobject-introspection 0.9.5 rebuilds coming to rawhide
Just a quick heads up that I'm going to be updating introspection to (at least) 0.9.5 in rawhide. For libraries, this is generally a simple rebuild with no impact on primary functionality. However if you are a library maintainer, do see http://mail.gnome.org/archives/gnome-announce-list/2010-September/msg00019.html And particularly please try the new --warn-all flag. For apps: Many more functions require annotations, as the scanner does less (incorrect) guessing. We are working on adding annotations for the GNOME 3 (F15ish cycle). -- 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: > > 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? Providing static libraries for user needs like yours is acceptable in Fedora and some packages ship static libraries, especially when the maintainer faces the issue himself (heterogenous build/run environments, reproducible builds, lasting functional binaries). However, the majority of Fedora developpers are opposed to providing static libraries, even when users ask for them, and the guidelines themselves strongly discourage shipping static libraries. So, you can try to ask maintainers to ship static libraries, but don't expect to have many of them understand your needs. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: refining the feature process
On Wed, Sep 15, 2010 at 11:28:46AM -0700, John Poelstra wrote: > 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. I'm looking at the current situation. If we had hard, earlier deadlines, there wouldn't be the situation of scrambling to revert at the last minute, and Lennart wouldn't have felt led-on and could now be happily working on F15 integration. > > 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. I'm not opposed to allowing exceptions per se, and I trust FESCO to make reasonable decisions. But in the documentation, the deadline is basically defined as "a thing to which exceptions are considered". I'm suggesting moving the Feature Submission and Feature Freeze deadlines forward, so that decisions can be made before the alpha release. But another suggestion is simply to put in more "should" wording, encouraging early developement of features in Rawhide targeting $NEXTRELEASE, rather than aiming for $PENDINGRELEASE. Features with minimal potential for disruption could still target $PENDINGRELEASE. > 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. But that was before No Frozen Rawhide, and the parameters have changed. I think it's worth reexamining them, to make better use of the new process. -- Matthew Miller 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: Voting Process [WAS: FESCo decision on systemd]
On Wed, Sep 15, 2010 at 19:59, Sven Lankes wrote: > 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? > I have been reading and hearing about liquid feedback too and it sounds perfect (from my point of view) for Fedora. I often have the feeling that my opinion is not worth much and does just voting for someone to be on some board is not enough. There are some issues which I would like to vote on directly and others where I trust other people to represent me. That is pretty much what liquid feedback is for. Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 625363] Upgrade to new upstream version
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=625363 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.0-1. |perl-Directory-Queue-1.0-1. |el4 |el5 -- 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 625363] Upgrade to new upstream version
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=625363 --- Comment #11 from Fedora Update System 2010-09-15 14:29:26 EDT --- perl-Directory-Queue-1.0-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- 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 625363] Upgrade to new upstream version
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=625363 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.0-1. |perl-Directory-Queue-1.0-1. |fc14|el4 -- 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 625363] Upgrade to new upstream version
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=625363 --- Comment #10 from Fedora Update System 2010-09-15 14:28:26 EDT --- perl-Directory-Queue-1.0-1.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. -- 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
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
Re: Problem with 2.6.35.4-12.fc14.x86_64
2010/9/15 Michal Schmidt : > 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 - 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: 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 Duffy 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
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 - 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: 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 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, 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: -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: 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
"Bryn M. Reeves" writes: > On 09/15/2010 05:06 PM, Robert Spanton wrote: >> 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: The important point here is that there is a distro policy against static libraries (with only very narrow exceptions). Trying to get individual package maintainers to go against the policy isn't a helpful way to proceed. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Voting Process [WAS: FESCo decision on systemd]
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. Jon. -- 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 17:20:22 +0200, drago01 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
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: -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: 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 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
[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 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
-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 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org --- Comment #1 from Paul Howarth 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
[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 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
[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=446995&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447038&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447061&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447062&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447067&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447250&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447259&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447279&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447293&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447297&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447299&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447300&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447321&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447336&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447351&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447503&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447508&action=edit https://bugzilla.redhat.com/attachment.cgi?id=447509&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-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 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 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
>> > 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
>> > 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
>>
>>
>>
>> ___
>> 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)
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 wrote: > Richard Hughes (hughsi...@gmail.com) said: >> On 14 September 2010 23:01, Kevin Fenzi wrote: >> > 21:33:35 The other 2 items I had were: >> > 21:33:56 application installer issues >> > 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968 >> > 21:34:04 and >> > 21:34:05 BuildIdBuild infrastructure >> > 21:34:06 https://fedorahosted.org/fedora-infrastructure/ticket/2387 >> > 21:34:57 that needs more time, I'd say >> > 21:35:08 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: 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 wrote: > > 21:33:35 The other 2 items I had were: > > 21:33:56 application installer issues > > 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968 > > 21:34:04 and > > 21:34:05 BuildIdBuild infrastructure > > 21:34:06 https://fedorahosted.org/fedora-infrastructure/ticket/2387 > > 21:34:57 that needs more time, I'd say > > 21:35:08 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
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: []
cpu_maps_update_begin+0x17/0x19
#1: (cpu_hotplug.lock){+.+.+.}, at: []
cpu_hotplug_begin+0x2c/0x53
#2: (&rq->lock){-.-...}, at: [] init_idle+0x30/0x131
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-12.fc14.x86_64 #1
Call Trace:
[] lockdep_rcu_dereference+0xaa/0xb3
[] task_group+0x80/0x8f
[] set_task_rq+0x17/0x73
[] init_idle+0xea/0x131
[] fork_idle+0x92/0xa3
[] ? mark_held_locks+0x50/0x72
[] do_fork_idle+0x1c/0x2d
[] do_boot_cpu+0x137/0x9b1
[] ? do_fork_idle+0x0/0x2d
[] native_cpu_up+0x100/0x1c2
[] _cpu_up+0x9d/0xf9
[] cpu_up+0xd3/0xe5
[] kernel_init+0x105/0x2c9
[] kernel_thread_helper+0x4/0x10
[] ? restore_args+0x0/0x30
[] ? kernel_init+0x0/0x2c9
[] ? 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)
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 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)
On Wed, Sep 15, 2010 at 5:15 PM, Bruno Wolff III wrote: > On Wed, Sep 15, 2010 at 17:11:03 +0200, > drago01 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
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 intellij-idea-9.0.
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 17:11:03 +0200, drago01 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
Re: Linux and application installing
On Wed, Sep 15, 2010 at 4:38 PM, FlorianFesti 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 4:25 PM, Bruno Wolff III wrote: > On Wed, Sep 15, 2010 at 07:20:30 -0700, > John Poelstra 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: 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 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
> > 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
> > 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
>
>
>
> ___
> 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: 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: 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 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
[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 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: 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
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: 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: 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
> 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
> 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
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
[perl-HTML-FormatText-WithLinks] 0.11 bump
commit 69e0bc83d7c1bd83b80e732b372686032e10d296
Author: Petr Písař
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 - 0.11-1
+- 0.11 bump
+
* Sun May 02 2010 Marcela Maslanova - 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
File HTML-FormatText-WithLinks-0.11.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-HTML-FormatText-WithLinks: 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
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 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
[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 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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 07:20:30 -0700, John Poelstra 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 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 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)
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
[perl-File-Find-Rule-VCS] 1.07 bump
commit b33cb75d50ec3b694394945f5f2286fd4cf40cc9
Author: Petr Písař
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 - 1.07-1
+- 1.07 bump
+- Remove duplicate perl(File::Find::Rule) Requires
+
* Sat May 01 2010 Marcela Maslanova - 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
[perl-Format-Human-Bytes] New sources for 0.06
commit b1ee707c871291591973d62dbe13e2bc5f6699db Author: Petr Sabata 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
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
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
[perl-Format-Human-Bytes] New release, v0.06
commit 7c54128cdca81f038038baa330d571438e820b33
Author: Petr Sabata
Date: Wed Sep 15 16:12:32 2010 +0200
New release, v0.06
Format-Human-Bytes-no-autoinstall.patch | 10 ++
Format-Human-Bytes-switch_off.patch | 12
perl-Format-Human-Bytes.spec| 14 +-
3 files changed, 19 insertions(+), 17 deletions(-)
---
diff --git a/Format-Human-Bytes-no-autoinstall.patch
b/Format-Human-Bytes-no-autoinstall.patch
new file mode 100644
index 000..5562cc2
--- /dev/null
+++ b/Format-Human-Bytes-no-autoinstall.patch
@@ -0,0 +1,10 @@
+--- Format-Human-Bytes-0.06/Makefile.PL2010-09-14 13:58:36.0
+0200
Format-Human-Bytes-0.06/Makefile.PL.autoinstall2010-09-15
16:07:21.303195916 +0200
+@@ -7,7 +7,5 @@
+
+ test_requires 'Test::More';
+
+-auto_install;
+-
+ WriteAll;
+
diff --git a/perl-Format-Human-Bytes.spec b/perl-Format-Human-Bytes.spec
index db85442..0eba61a 100644
--- a/perl-Format-Human-Bytes.spec
+++ b/perl-Format-Human-Bytes.spec
@@ -1,13 +1,13 @@
Name: perl-Format-Human-Bytes
-Version:0.04
-Release:2%{?dist}
+Version:0.06
+Release:1%{?dist}
Summary:Format a bytecount and make it human readable
-License:GPL+
+License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Format-Human-Bytes/
Source0:
http://www.cpan.org/authors/id/S/SE/SEWI/Format-Human-Bytes-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Patch0: Format-Human-Bytes-switch_off.patch
+Patch0: Format-Human-Bytes-no-autoinstall.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Install)
@@ -20,7 +20,7 @@ a simple bytecount.
%prep
%setup -q -n Format-Human-Bytes-%{version}
-%patch0 -p1
+%patch0 -p1 -b .noautoinstall
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -49,6 +49,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Sep 15 2010 Petr Sabata - 0.06-1
+- New release, v0.06
+- License changed to Perl (GPL+ or Artistic)
+
* Sun May 02 2010 Marcela Maslanova - 0.04-2
- Mass rebuild with perl-5.12.0
--
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 03:04:31PM +0100, Adam Williamson 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. :) Okay everyone! I know we're all geeks and can barely resist a grammar discussion, but this thread is going to get long enough all its own. Let's take this discussion over to . Thanks! -- Matthew Miller 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: 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 wrote: > > 21:33:35 The other 2 items I had were: > > 21:33:56 application installer issues > > 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968 > > 21:34:04 and > > 21:34:05 BuildIdBuild infrastructure > > 21:34:06 https://fedorahosted.org/fedora-infrastructure/ticket/2387 > > 21:34:57 that needs more time, I'd say > > 21:35:08 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, 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
[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 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
[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 changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #11 from Daniel Berrange 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
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
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" 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, 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: 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: Broadcom wifi drivers in F-14?
On Wed, Sep 15, 2010 at 09:09:58 -0400, "John W. Linville" 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: 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
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
[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 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
[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 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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 01:05:34AM +0200, Lennart Poettering wrote: > There's something seriously wrong with the Fedora development > process, folks. And with you, FESCO. You excelled in erratic behaviour, > not in steering engineering. Lennart, I don't think you're being fair. I tried to alert you earlier to the fact that FESCO's initial decision was a very cautions "we'll try it", not the "full steam ahead and we'll back out if it goes really, really wrong" that you took it as. Go back and read the minutes of the initial FESCO decision to accept the feature. I do think someone should have alerted you to the fact that the final decision was being made at this meeting. That wasn't good. But I don't think the decision would have been different. Now, let's move ahead: an awesome, solidly-integrated systemd for F15, right? -- Matthew Miller 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
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
