Re: Fedora 18 laptop regression
On Mon, 2013-01-07 at 19:49 +, alex...@hushmail.com wrote: > On 07/01/2013 at 7:40 PM, "Matthias Clasen" wrote: > > > >- Original Message - > > > >> And is it possible to disable suspend on lid close but still have > >> GNOME lock the screen on lid close? No? Didn't think so... > > > >With the lid closed, your session will go idle, which will > >eventually cause the screen to lock. > >-- > > And is that the same as what I was asking? No? Didn't think so... > > It's little things like this that make GNOME a love-hate relationship. > Looks gorgeous and several things they've got really right, but in > many places it's still style over substance. We might even look at fixing your bug if you filed it upstream. No? Didn't think so ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for a freemind maintainer
On Tue, Dec 4, 2012 at 9:31 PM, Johannes Lips wrote: > > > > On Mon, Nov 26, 2012 at 12:40 PM, Kalpa Welivitigoda > wrote: > >> On Mon, Nov 26, 2012 at 3:55 PM, Caterpillar >> wrote: >> > Il 23/11/2012 15:33, Johannes Lips ha scritto: >> >> Hi all, >> >> >> >> I am looking for a new freemind maintainer. I've stated the reason for >> >> this in this mail to java-devel: >> >> >> http://lists.fedoraproject.org/pipermail/java-devel/2012-November/004561.html >> >> >> >> Perhaps someone would like to take over... >> >> >> >> I am a frequent freemind user and I would like to take over. >> >> >> Johannes >> >> >> >> >> > Hi, I often use freemind for my studies, but I have never mantained a >> > package. What level of knowledge does the freemind manteinance require? >> >> Perhaps you may join as a co-maintainer. >> >> > -- >> > devel mailing list >> > devel@lists.fedoraproject.org >> > https://admin.fedoraproject.org/mailman/listinfo/devel >> >> >> >> -- >> Best Regards, >> >> Kalpa Welivitigoda >> http://about.me/callkalpa >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > > Hi, > > sorry for the delay, but I've not had that much time recently. > The knowledge needed for maintaining the package is basically java > packaging, the ant buildsystem and you need to be familiar with the fedora > processes as well. > I would suggest that you, Kalpa, are applying for co-maintainership and I > will give you all the needed rights. Then you could take a look at how it > is packaged and see if you could make the new 1.0.0 release available. > Please bear in mind that this might need some additional reviews of > packages since upstream added some deps. > If all goes well, I will happily hand the package over to you completely! > > Best wishes, > > Johannes > > Due to lack of available free time I am not in a position to maintain the package. Hope Stanislav will take care of that. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best Regards, Kalpa Welivitigoda Junior Treasurer | Electrical Engineering Society Undergraduate | Department of Electrical Engineering University of Moratuwa Sri Lanka http://about.me/callkalpa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Mon, 2013-01-07 at 21:02 -0700, Kevin Fenzi wrote:
> On Tue, 8 Jan 2013 04:48:36 +0100
> Miloslav Trmač wrote:
>
> > On Tue, Jan 8, 2013 at 4:31 AM, Adam Williamson
> > wrote:
> > > On Tue, 2013-01-08 at 03:06 +, "Jóhann B. Guðmundsson" wrote:
> > >> So the remaining webapps that ship with the broken configuration
> > >> that we are about to release into the hands our our enduser base
> > >> and how they should be handled are not considered high-level
> > >> technical decision?
> > >
> > > What is the decision to be made? "Do we fix them"? Obviously yes.
> >
> > ("Obviously"? Per which release blocker criterion?)
>
> I think Adam was saying we should fix them, but they can be 0 day
> updates (or whenever they are fixed).
>
> > The way I understand Jóhann, the topic to escalate was a proposed
> > removal of currently unorphaned packages from the distribution, which
> > sounds like a quite reasonable topic for FESCo.
>
> Sure. Then we got sidetracked. ;)
Hmm, sorry, I think I somehow missed the proposal to remove packages - I
thought Johann was just referring to 'this issue' in general. If that
would indeed be a FESCo issue, then sorry, it was a reasonable
suggestion indeed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Tue, 8 Jan 2013 04:48:36 +0100
Miloslav Trmač wrote:
> On Tue, Jan 8, 2013 at 4:31 AM, Adam Williamson
> wrote:
> > On Tue, 2013-01-08 at 03:06 +, "Jóhann B. Guðmundsson" wrote:
> >> So the remaining webapps that ship with the broken configuration
> >> that we are about to release into the hands our our enduser base
> >> and how they should be handled are not considered high-level
> >> technical decision?
> >
> > What is the decision to be made? "Do we fix them"? Obviously yes.
>
> ("Obviously"? Per which release blocker criterion?)
I think Adam was saying we should fix them, but they can be 0 day
updates (or whenever they are fixed).
> The way I understand Jóhann, the topic to escalate was a proposed
> removal of currently unorphaned packages from the distribution, which
> sounds like a quite reasonable topic for FESCo.
Sure. Then we got sidetracked. ;)
> Such an escalation wouldn't fix F18, true.
>
> In retrospect, the update to httpd 2.4 should probably have been a
> feature; that would make this problem visible by beta freeze. FESCo
> already has "fixing features" on the agenda in a general sense, more
> thoughts on how to improve the process would definitely be welcome.
> Mirek
Agreed.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Tue, 08 Jan 2013 03:06:14 + "Jóhann B. Guðmundsson" wrote: > On 01/08/2013 02:10 AM, Adam Williamson wrote: ...snip... > > Well, I'm not sure that was a great precedent to set, if we're > > going to treat it as a precedent... > > What else is it? A single decision? I can't speak for others in FESCo, but If I had intended this to be some kind of general rule we would have agreed to that general rule. :) > The alternative is that fesco single out individual and forced him to > fix brokenness in other components which ironically already had been > broken? There were a number of things going on. It was late in the cycle, we wanted someone who understood the change to fix it, and the feature owner was pushing to avoid reverting their feature. Additionally this experiment didn't help anything get fixed faster sadly. I'd probably avoid these kinds of things moving forward unless the feature owner wanted to do so. > Which one do you prefer? I'd prefer to avoid this sidetrack and actually see what we can do to fix the issue of this thread. Can we get back on topic here and drop the confrontational stance? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Tue, Jan 8, 2013 at 4:31 AM, Adam Williamson wrote:
> On Tue, 2013-01-08 at 03:06 +, "Jóhann B. Guðmundsson" wrote:
>> So the remaining webapps that ship with the broken configuration that we
>> are about to release into the hands our our enduser base and how they
>> should be handled are not considered high-level technical decision?
>
> What is the decision to be made? "Do we fix them"? Obviously yes.
("Obviously"? Per which release blocker criterion?)
The way I understand Jóhann, the topic to escalate was a proposed
removal of currently unorphaned packages from the distribution, which
sounds like a quite reasonable topic for FESCo.
Such an escalation wouldn't fix F18, true.
In retrospect, the update to httpd 2.4 should probably have been a
feature; that would make this problem visible by beta freeze. FESCo
already has "fixing features" on the agenda in a general sense, more
thoughts on how to improve the process would definitely be welcome.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Tue, 2013-01-08 at 03:06 +, "Jóhann B. Guðmundsson" wrote: > On 01/08/2013 02:10 AM, Adam Williamson wrote: > > On Tue, 2013-01-08 at 01:56 +, "Jóhann B. Guðmundsson" wrote: > >> On 01/07/2013 10:19 PM, Adam Williamson wrote: > >>> Why? What can FESCo do about it? We don't need to kick every damn issue > >>> to FESCo, as seems to be a trend lately. > >> Ah I see but it's ok when you do... > > What have I escalated that was not a high-level technical decision? > > So the remaining webapps that ship with the broken configuration that we > are about to release into the hands our our enduser base and how they > should be handled are not considered high-level technical decision? What is the decision to be made? "Do we fix them"? Obviously yes. > What else is it? > > The alternative is that fesco single out individual and forced him to > fix brokenness in other components which ironically already had been broken? > > Which one do you prefer? > > David rewrote the part of polkit that makes the authorization decision > which resulted in this [1]. > > He was not forced to go through all the components and rewrite all the > polkit rules which still may be broken in some places so a simple > question why Kay but not others if not to set a precedent? > > What makes Kay so special he deserves the honor to be treated like this > and given the blessing of fixing those things up? I'm not debating, defending or attacking any particular decision FESCo has made. I'm just saying I can see nothing in particular they can decide in this case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On 01/08/2013 02:10 AM, Adam Williamson wrote: On Tue, 2013-01-08 at 01:56 +, "Jóhann B. Guðmundsson" wrote: On 01/07/2013 10:19 PM, Adam Williamson wrote: Why? What can FESCo do about it? We don't need to kick every damn issue to FESCo, as seems to be a trend lately. Ah I see but it's ok when you do... What have I escalated that was not a high-level technical decision? So the remaining webapps that ship with the broken configuration that we are about to release into the hands our our enduser base and how they should be handled are not considered high-level technical decision? There's no high-level technical decision to be made here. The bugs just need to get fixed. FESCo doesn't have magical resources to achieve this, it's a decision-making body. Fesco set an example here [1] "At today's FESCo meeting we agreed to: AGREED: Kay should make sure all the packages affected to use the new config files. Kay, can you please make sure all affected packages are fixed up asap? Thanks." I would expect they to be consistent in their action and request of the apache maintainer that he should fix up all the affected packages as well... Well, I'm not sure that was a great precedent to set, if we're going to treat it as a precedent... What else is it? The alternative is that fesco single out individual and forced him to fix brokenness in other components which ironically already had been broken? Which one do you prefer? David rewrote the part of polkit that makes the authorization decision which resulted in this [1]. He was not forced to go through all the components and rewrite all the polkit rules which still may be broken in some places so a simple question why Kay but not others if not to set a precedent? What makes Kay so special he deserves the honor to be treated like this and given the blessing of fixing those things up? JBG 1. http://goldmann.pl/blog/2012/12/03/configuring-polkit-in-fedora-18-to-access-virt-manager/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Tue, 2013-01-08 at 01:56 +, "Jóhann B. Guðmundsson" wrote: > On 01/07/2013 10:19 PM, Adam Williamson wrote: > > Why? What can FESCo do about it? We don't need to kick every damn issue > > to FESCo, as seems to be a trend lately. > > Ah I see but it's ok when you do... What have I escalated that was not a high-level technical decision? > > There's no high-level technical > > decision to be made here. The bugs just need to get fixed. FESCo doesn't > > have magical resources to achieve this, it's a decision-making body. > > Fesco set an example here [1] > > "At today's FESCo meeting we agreed to: > > AGREED: Kay should make sure all the packages affected to use the new > config files. > > Kay, can you please make sure all affected packages are fixed up asap? > Thanks." > > I would expect they to be consistent in their action and request of the > apache maintainer that he should fix up all the affected packages as well... Well, I'm not sure that was a great precedent to set, if we're going to treat it as a precedent... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On 01/07/2013 10:19 PM, Adam Williamson wrote: Why? What can FESCo do about it? We don't need to kick every damn issue to FESCo, as seems to be a trend lately. Ah I see but it's ok when you do... There's no high-level technical decision to be made here. The bugs just need to get fixed. FESCo doesn't have magical resources to achieve this, it's a decision-making body. Fesco set an example here [1] "At today's FESCo meeting we agreed to: AGREED: Kay should make sure all the packages affected to use the new config files. Kay, can you please make sure all affected packages are fixed up asap? Thanks." I would expect they to be consistent in their action and request of the apache maintainer that he should fix up all the affected packages as well... JBG https://fedorahosted.org/fesco/ticket/963#comment:14 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: syslinux as an official bootloader option?
On Mon, Jan 07, 2013 at 10:13:29PM +0100, Lennart Poettering wrote: > On Mon, 07.01.13 15:23, Matthew Miller (mat...@fedoraproject.org) wrote: > > Cool. Feature proposal: > > > > https://fedoraproject.org/wiki/Features/SyslinuxOption > > Might be cool to have somebody work on gummiboot integration into Fedora > as well... Why? syslinux fits a specific niche, but gummiboot doesn't seem to. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream release monitoring script gone awry?
On Mon, 2013-01-07 at 23:23 +0100, Till Maas wrote: > yes, there was an incomplete patch added unintentionally to the > script. > All faulty bugs should be closed and new bugs created if appropriate. > > Sorry for the trouble. No worries. Thank you for the quick fix :) -- Thanks, Warm regards, Ankur: "FranciscoD" Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ 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: Upstream release monitoring script gone awry?
Hi, On Mon, Jan 07, 2013 at 08:53:15PM +1100, Ankur Sinha wrote: > I've received new bugs in the form: > > "bibus-1...5...2 is available". There's already a bug for 1.5.2. Is > something faulty with the script? yes, there was an incomplete patch added unintentionally to the script. All faulty bugs should be closed and new bugs created if appropriate. Sorry for the trouble. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Mon, 2013-01-07 at 15:47 +, "Jóhann B. Guðmundsson" wrote: > On 01/07/2013 02:54 PM, Remi Collet wrote: > > 2 months ago I have open a bug tracker for all packages with an apache > > configuration file, which need to be fixed to work with httpd 2.4. > > > > The current situation, 1 week before release, don't seems really good, > > see > > https://bugzilla.redhat.com/showdependencytree.cgi?id=871373&hide_resolved=1 > > > > 16 packages are still "NEW", nott even acked by the maintainer > > (and I just pushed 10 fixed packages to updates) > > > > Some seems so broken, and unmaintained (ex zikula) that they should > > probably be removed from the distro. > > Escalate this issue to FESCO Why? What can FESCo do about it? We don't need to kick every damn issue to FESCo, as seems to be a trend lately. There's no high-level technical decision to be made here. The bugs just need to get fixed. FESCo doesn't have magical resources to achieve this, it's a decision-making body. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 892381] please pull perl-Sys-Syscall 0.25 into f18
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=892381 --- Comment #2 from Fedora Update System --- Package perl-Sys-Syscall-0.25-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Sys-Syscall-0.25-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0354/perl-Sys-Syscall-0.25-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ZUurW0tIts&a=cc_unsubscribe -- 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: syslinux as an official bootloader option?
On Mon, 07.01.13 15:23, Matthew Miller (mat...@fedoraproject.org) wrote: > On Sun, Jan 06, 2013 at 02:37:18AM +, Matthew Garrett wrote: > > > What about making this an optional bootloader in F19 (in kickstart and > > > via a > > > hidden option)? > > I don't think there'd be any objection to that - it makes sense for > > appliance-type scenarios. > > Cool. Feature proposal: > > https://fedoraproject.org/wiki/Features/SyslinuxOption Might be cool to have somebody work on gummiboot integration into Fedora as well... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: syslinux as an official bootloader option?
On Sun, Jan 06, 2013 at 02:37:18AM +, Matthew Garrett wrote: > > What about making this an optional bootloader in F19 (in kickstart and via a > > hidden option)? > I don't think there'd be any objection to that - it makes sense for > appliance-type scenarios. Cool. Feature proposal: https://fedoraproject.org/wiki/Features/SyslinuxOption -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 laptop regression
On 07/01/2013 at 7:40 PM, "Matthias Clasen" wrote: > >- Original Message - > >> And is it possible to disable suspend on lid close but still have >> GNOME lock the screen on lid close? No? Didn't think so... > >With the lid closed, your session will go idle, which will >eventually cause the screen to lock. >-- And is that the same as what I was asking? No? Didn't think so... It's little things like this that make GNOME a love-hate relationship. Looks gorgeous and several things they've got really right, but in many places it's still style over substance. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ExtUtils-Typemaps-Default/f17] Initial import (#876399)
Summary of changes: 30803ca... Initial import (#876399) (*) (*) This commit already existed in another branch; no separate mail sent -- 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-ExtUtils-Typemaps-Default/f18] Initial import (#876399)
Summary of changes: 30803ca... Initial import (#876399) (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Fedora 18 laptop regression
- Original Message - > And is it possible to disable suspend on lid close but still have > GNOME lock the screen on lid close? No? Didn't think so... With the lid closed, your session will go idle, which will eventually cause the screen to lock. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 laptop regression
On 07/01/2013 at 6:22 PM, "Matthias Clasen" wrote: >Quite a bit of misinformation in this discussion. Let me clarify >what GNOME 3.6 actually does: > >- We take inhibitors to block logind from handling >power/suspend/etc keys, since gnome-settings-daemon handles those > >- We don't take a lid close ihibitor by default, we let logind >handle it. Unless there is an external monitor, in which case we >do take an inihbitor. You can override that with the lid-close- >suspend-with-external-monitor setting that is available in gnome- >tweak-tool > >- We do take delay inhibitors to ensure we can lock the screen >before suspend And is it possible to disable suspend on lid close but still have GNOME lock the screen on lid close? No? Didn't think so... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 847128] epel6 build request
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=847128 --- Comment #3 from Bill Pemberton --- A little bump for this. perl(Convert::NLS_DATE_FORMAT) is in EPEL6 now. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6rUKwK88EO&a=cc_unsubscribe -- 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: Issues to build scala-2.10.0 on rawhide
Il 07/01/2013 18:46, gil ha scritto: Il 07/01/2013 17:14, Jochen Schmitt ha scritto: Hallo, Unfortunately, I have an issue to build scala-2.10.0 on rawhide. I have got the following error message from the buildsystem: artifact:dependencies] Diagnosis: [artifact:dependencies] [artifact:dependencies] Unable to resolve artifact: Missing: [artifact:dependencies] -- [artifact:dependencies] 1) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] Try downloading the file manually from the project website. [artifact:dependencies] [artifact:dependencies] Then, install it using the command: [artifact:dependencies] mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file [artifact:dependencies] [artifact:dependencies] Alternatively, if you host your own repository you can deploy the file there: [artifact:dependencies] mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [artifact:dependencies] [artifact:dependencies] Path to dependency: [artifact:dependencies] 1) org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] 2) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] -- [artifact:dependencies] 1 required artifact is missing. [artifact:dependencies] [artifact:dependencies] for artifact: [artifact:dependencies] org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] [artifact:dependencies] from the specified remote repositories: [artifact:dependencies] central (http://repo1.maven.org/maven2) [artifact:dependencies] [artifact:dependencies] BUILD FAILED /builddir/build/BUILD/scala-2.10.0-sources/build.xml:283: Unable to resolve artifact: Missing: -- 1) biz.aQute:bnd:jar:1.50.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) biz.aQute:bnd:jar:1.50.0 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) It may be nice, if anyone can get me a hint to solve this issue. Best Regards: Jochen Schmitt hi, should be disabled the maven-ant-tasks support with a patch... and add the system aqute-bnd library path where needed regards gil e.g. line 301 classpathref="extra.tasks.classpath" /> should be replaced by classpath="/usr/share/java/aqute-bnd.jar"/> use aqute-bnd.jar because aqute-bndlib.jar don't provides an ant bnd task p.s. attached a new build script for some scala component (includes jline) in the spec file should append these BR BuildRequires: jansi BuildRequires: jansi-native BuildRequires: junit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 laptop regression
- Original Message - > On Sat, 05.01.13 22:54, alex...@hushmail.com (alex...@hushmail.com) > wrote: > GNOME on F18 takes the lock and handles the lid switch on its own. > You > can verify that with "systemd-inhibit --list". > > > > > There is almost nothing you can configure with GUI in GNOME and > > gsettings isn't even adequate anymore. > > > > gnome-tweak-tool allows you to configure what happens when you close > the lid. > Quite a bit of misinformation in this discussion. Let me clarify what GNOME 3.6 actually does: - We take inhibitors to block logind from handling power/suspend/etc keys, since gnome-settings-daemon handles those - We don't take a lid close ihibitor by default, we let logind handle it. Unless there is an external monitor, in which case we do take an inihbitor. You can override that with the lid-close-suspend-with-external-monitor setting that is available in gnome-tweak-tool - We do take delay inhibitors to ensure we can lock the screen before suspend -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File ExtUtils-Typemaps-Default-1.01.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-ExtUtils-Typemaps-Default: fb1af6b88fe419e9a77d01642b4b2378 ExtUtils-Typemaps-Default-1.01.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: Issues to build scala-2.10.0 on rawhide
Il 07/01/2013 17:14, Jochen Schmitt ha scritto: Hallo, Unfortunately, I have an issue to build scala-2.10.0 on rawhide. I have got the following error message from the buildsystem: artifact:dependencies] Diagnosis: [artifact:dependencies] [artifact:dependencies] Unable to resolve artifact: Missing: [artifact:dependencies] -- [artifact:dependencies] 1) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] Try downloading the file manually from the project website. [artifact:dependencies] [artifact:dependencies] Then, install it using the command: [artifact:dependencies] mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file [artifact:dependencies] [artifact:dependencies] Alternatively, if you host your own repository you can deploy the file there: [artifact:dependencies] mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [artifact:dependencies] [artifact:dependencies] Path to dependency: [artifact:dependencies] 1) org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] 2) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] -- [artifact:dependencies] 1 required artifact is missing. [artifact:dependencies] [artifact:dependencies] for artifact: [artifact:dependencies] org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] [artifact:dependencies] from the specified remote repositories: [artifact:dependencies] central (http://repo1.maven.org/maven2) [artifact:dependencies] [artifact:dependencies] BUILD FAILED /builddir/build/BUILD/scala-2.10.0-sources/build.xml:283: Unable to resolve artifact: Missing: -- 1) biz.aQute:bnd:jar:1.50.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) biz.aQute:bnd:jar:1.50.0 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) It may be nice, if anyone can get me a hint to solve this issue. Best Regards: Jochen Schmitt hi, should be disabled the maven-ant-tasks support with a patch... and add the system aqute-bnd library path where needed regards gil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On 01/07/2013 04:50 PM, Petr Pisar wrote:
The pre-precessed code is:
for (i = 0; i <= LAST_FLAG; i++) {
((all_heap_codes *)(0x1000))->yap_flags_field[i] = 0;
}
I think the number of iterations (24) is one larger than the number of
array elements (23).
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Issues to build scala-2.10.0 on rawhide
Hallo, Unfortunately, I have an issue to build scala-2.10.0 on rawhide. I have got the following error message from the buildsystem: artifact:dependencies] Diagnosis: [artifact:dependencies] [artifact:dependencies] Unable to resolve artifact: Missing: [artifact:dependencies] -- [artifact:dependencies] 1) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] Try downloading the file manually from the project website. [artifact:dependencies] [artifact:dependencies] Then, install it using the command: [artifact:dependencies] mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file [artifact:dependencies] [artifact:dependencies] Alternatively, if you host your own repository you can deploy the file there: [artifact:dependencies] mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [artifact:dependencies] [artifact:dependencies] Path to dependency: [artifact:dependencies] 1) org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] 2) biz.aQute:bnd:jar:1.50.0 [artifact:dependencies] [artifact:dependencies] -- [artifact:dependencies] 1 required artifact is missing. [artifact:dependencies] [artifact:dependencies] for artifact: [artifact:dependencies] org.apache.maven:super-pom:jar:2.0 [artifact:dependencies] [artifact:dependencies] from the specified remote repositories: [artifact:dependencies] central (http://repo1.maven.org/maven2) [artifact:dependencies] [artifact:dependencies] BUILD FAILED /builddir/build/BUILD/scala-2.10.0-sources/build.xml:283: Unable to resolve artifact: Missing: -- 1) biz.aQute:bnd:jar:1.50.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=biz.aQute -DartifactId=bnd -Dversion=1.50.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) biz.aQute:bnd:jar:1.50.0 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) It may be nice, if anyone can get me a hint to solve this issue. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On Mon, 07 Jan 2013 15:54:23 +0100 Remi Collet wrote: > 2 months ago I have open a bug tracker for all packages with an apache > configuration file, which need to be fixed to work with httpd 2.4. > > The current situation, 1 week before release, don't seems really good, > see > https://bugzilla.redhat.com/showdependencytree.cgi?id=871373&hide_resolved=1 > > 16 packages are still "NEW", nott even acked by the maintainer > (and I just pushed 10 fixed packages to updates) :( > Some seems so broken, and unmaintained (ex zikula) that they should > probably be removed from the distro. It's a bit late to remove anything for f18. Perhaps we could divide up the last 16 and have some provenpackagers just push the majority of them. BTW, thanks for your work on this. :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Mon, Jan 07, 2013 at 03:50:01PM +, Petr Pisar wrote:
> > yap-6.2.2-4.fc18.src.rpm
> > similar to getdata bug:
> > LAST_FLAG = 23
> > ...
> > #define NUMBER_OF_YAP_FLAGS LAST_FLAG
> > ...
> > #define yap_flags Yap_heap_regs->yap_flags_field
> > ...
> > Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
> > ...
> > /* This must be done before initialising predicates */
> > for (i = 0; i <= LAST_FLAG; i++) {
> > yap_flags[i] = 0;
> > }
> >
> What's wrong with assigning 0 that fits into any intenger? C99 says:
>
> 6.3.1.3 Signed and unsigned integers
> 1 When a value with integer type is converted to another integer type
> other than _Bool, if the value can be represented by the new type,
> it is unchanged.
>
> The pre-precessed code is:
>
> for (i = 0; i <= LAST_FLAG; i++) {
> ((all_heap_codes *)(0x1000))->yap_flags_field[i] = 0;
> }
>
> Type of yap_flags_field is int[].
That's not correct, type of yap_flags_field is int[NUMBER_OF_YAP_FLAGS]
aka int[LAST_FLAG]. The undefined behavior happens in the last iteration,
where you do
((all_heap_codes *)(0x1000))->yap_flags_field[LAST_FLAG] = 0;
ISO C99 6.5.2.1 says that this is equivalent to:
(*all_heap_codes *)(0x1000))->yap_flags_field)+(LAST_FLAG))) = 0;
and then 6.5.6/8 (last sentence) applies:
"If the result points one past the last element of the array object, it
shall not be used as the operand of a unary * operator that is evaluated."
Note the array is in a middle of a structure, not at the end, where is the
only place where flexible array members could be present and as an extension
GCC allows even non-flexible arrays to be treated similarly to flexible
arrays (case where people use say struct S { ...; int a[1]; }; as some kind
of pre-C99 flexible array members).
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
Petr Pisar wrote, at 01/08/2013 12:50 AM +9:00:
On 2013-01-04, Jakub Jelinek wrote:
yap-6.2.2-4.fc18.src.rpm
similar to getdata bug:
LAST_FLAG = 23
...
#define NUMBER_OF_YAP_FLAGS LAST_FLAG
...
#define yap_flags Yap_heap_regs->yap_flags_field
...
Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
...
/* This must be done before initialising predicates */
for (i = 0; i <= LAST_FLAG; i++) {
yap_flags[i] = 0;
}
What's wrong with assigning 0 that fits into any intenger? C99 says:
This code is by one element buffer overflowing (not i "<" LAST_FLAG
but i "<=" LAST_FLAG)
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18: WebApp and httpd 2.4 configuration
On 01/07/2013 02:54 PM, Remi Collet wrote: 2 months ago I have open a bug tracker for all packages with an apache configuration file, which need to be fixed to work with httpd 2.4. The current situation, 1 week before release, don't seems really good, see https://bugzilla.redhat.com/showdependencytree.cgi?id=871373&hide_resolved=1 16 packages are still "NEW", nott even acked by the maintainer (and I just pushed 10 fixed packages to updates) Some seems so broken, and unmaintained (ex zikula) that they should probably be removed from the distro. Escalate this issue to FESCO JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On 2013-01-04, Jakub Jelinek wrote:
>
> getdata-0.7.3-3.fc18.src.rpm
> GCC is now more aggresive in turning loops that invoke undefined
> behavior into endless loops. In test/get_uint32.c there is:
> uint32_t data_data[128];
> int fd, n, error, r = 0;
> ...
> for (fd = 0; fd < 128; ++fd)
> data_data[fd] = fd * (0x0201);
> When fd is 64 or above, fd * 0x0201 overflows, which is invalid
> in C/C++ for signed types (int here). To fix use
> data_data[fd] = fd * 0x0201U;
> or
> data_data[fd] = (uint32_t) fd * 0x0201;
> etc. instead.
>
[...]
>
> yap-6.2.2-4.fc18.src.rpm
> similar to getdata bug:
> LAST_FLAG = 23
> ...
> #define NUMBER_OF_YAP_FLAGS LAST_FLAG
> ...
> #define yap_flags Yap_heap_regs->yap_flags_field
> ...
> Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
> ...
> /* This must be done before initialising predicates */
> for (i = 0; i <= LAST_FLAG; i++) {
> yap_flags[i] = 0;
> }
>
What's wrong with assigning 0 that fits into any intenger? C99 says:
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type,
it is unchanged.
The pre-precessed code is:
for (i = 0; i <= LAST_FLAG; i++) {
((all_heap_codes *)(0x1000))->yap_flags_field[i] = 0;
}
Type of yap_flags_field is int[].
Is it due to casting signed number to object pointer? But that's allowed:
6.3.2.3 Pointers
5 An integer may be converted to any pointer type. Except as previously
specified, the result is implementation-defined, might not be correctly
aligned, might not point to an entity of the referenced type, and might
be a trap representation.
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
poppler update in rawhide
Hi, I plan to rebase poppler in rawhide to poppler-0.22.0 at the beginning of next week. There are several API changes and 1 soname bump (libpoppler.so.26 to libpoppler.so.34). The API changes are mostly new functions but also some removals and moves of members between public and private sections. You can test your package against this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4845665 Regards Marek ___ 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
[perl-Rose-DB-Object/f17] Update to version 0.803
Summary of changes: e2a0096... Update to version 0.803 (*) (*) This commit already existed in another branch; no separate mail sent -- 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 891863] perl-Rose-DB-Object-0.803 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891863 --- Comment #2 from Fedora Update System --- perl-Rose-DB-Object-0.803-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Rose-DB-Object-0.803-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Hiz89u14F4&a=cc_unsubscribe -- 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
Fedora 18: WebApp and httpd 2.4 configuration
2 months ago I have open a bug tracker for all packages with an apache configuration file, which need to be fixed to work with httpd 2.4. The current situation, 1 week before release, don't seems really good, see https://bugzilla.redhat.com/showdependencytree.cgi?id=871373&hide_resolved=1 16 packages are still "NEW", nott even acked by the maintainer (and I just pushed 10 fixed packages to updates) Some seems so broken, and unmaintained (ex zikula) that they should probably be removed from the distro. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20130107 changes
Compose started at Mon Jan 7 09:17:34 UTC 2013 Removed package: gpxe-1.0.1-7.fc18 Summary: Added Packages: 0 Removed Packages: 1 Upgraded Packages: 0 Compose finished at Mon Jan 7 13:55:28 UTC 2013 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130107 changes
Compose started at Mon Jan 7 08:15:06 UTC 2013 Broken deps for x86_64 -- [bootconf] bootconf-1.4-6.fc18.noarch requires grub [dogtag-pki] dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme >= 0:10.0.0 [ember] ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [evolution-rss] 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libevolution-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemiscwidgets.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [freeipa] freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme [freewrl] freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdb-heap] gdb-heap-0.5-11.fc19.x86_64 requires glibc(x86-64) = 0:2.16.90 [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShttp-types-0.6.11-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShashable-1.1.2.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfast-logger-0.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdlist-0.5-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdirectory-1.1.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdeepseq-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdata-default-0.4.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScontainers-0.4.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSconduit-0.4.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScase-insensitive-0.4.0.1
abrt server report: 20130107
Hot problems: ID Components Count --- 186587 kernel 411 186872 kernel 350 185998 gnome-packagekit 212 187697 kernel 170 20085 gnome-terminal 162 20171 gnome-shell 127 83012 tracker 126 117748 gnome-packagekit 116 21780 control-center 110 165889 kernel 100 URL: https://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 186587 kernel 2546 186872 kernel 1381 185998 gnome-packagekit1366 19369 control-center 1294 83012 tracker 1166 20085 gnome-terminal 1083 117748 gnome-packagekit 917 187697 kernel 871 20171 gnome-shell 825 54879 tracker 723 URL: https://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kernel 116 ▁▁█▄▃▅▅ control-center49 ▁▁▂▄▃▄█ gnome-shell 38 ▂▁▃▄▃▆█ evolution 35 ▁▁▃▃▃▆█ evince27 ▁▁▂▁▁▂█ Most stabilized components: Component Jump Graph -- zenity -36 █▂▁ pulseaudio-2 ▃▆█▅▁▃▂ NetworkManager-4 ▆█▂▅▁▃▁ rhythmbox-13 █▁▆▁▆▇▁ simple-scan -3 ▆█▂▁▅▂▂ Server URL: https://retrace.fedoraproject.org/faf/ Report a bug: https://fedorahosted.org/abrt/newticket?component=faf Server sources: http://git.fedorahosted.org/cgit/faf.git/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream release monitoring script gone awry?
Hi folks, I've received new bugs in the form: "bibus-1...5...2 is available". There's already a bug for 1.5.2. Is something faulty with the script? -- Thanks, Warm regards, Ankur: "FranciscoD" Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
