Re: SWI Prolog is gone from F13 and F14
On 2010-11-09, Joel j...@cryregarder.com wrote: Is anyone interested in resurrecting SWI Prolog? I just noticed that it was dropped from F13 and F14. `pl' package? It's there. Actually I maintain the package in RHEL-6 and I have some spec file clean-ups that could be applied into Fedora. If nobody else want to become maintainer, I can do to that. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive maintainer - Chris Ricker
Hi, I was unsuccessful in all attempts to contact Chris Ricker (kaboom AT oobleck.net). He seems non-responsive for a long time, I did not receive any reply from him at least from February. Tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=554334 Previous attempt to contact through devel: http://lists.fedoraproject.org/pipermail/devel/2010-November/144873.html Personally I am interested in rrdtool (and I can take it), but there are also more packages with unresolved bugs Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote: On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor. Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpy039KJQTMB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 01:12 PM, Dennis Jacobfeuerborn wrote: X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. ... Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. The argument seems to be that toolkit libs like Qt and GTK+ will shield us from major rewriting of apps. However, this implies that toolkits at some point will switch from the X mode to Wayland mode, with the resulting sudden loss of network transparency. I suppose one could imagine toolkits offering a dual backend: native Wayland, and X that would be invoked by e..g. a commandline switch if remoting was required. This seems a little heavyweight and awkward in both deployment and maintenance. You seem to imply that there's an alternative design involving some sort of shim between Wayland and the kernel that could capture and remote the GUI inputs and outputs. Can you point to any discussion of how it'd work? Finally I found it ironic that Wayland was designed to decrease the number of layers and roundtrips in X, but at least initially in the important use case of user app-toolkit-X API-Wayland it actually increases the number of layers. All the same, it's probably the only workable approach, so my observation above is more of a cheap shot than a serious anti-Wayland argument, but still it is a little funny, reminding me of the observation that oftentimes when people try to heal a religious schism, they end up creating a third sect :) Of course if it turned out that remoting can be provided by a Wayland-Kernel shim, this would not be an issue. What's puzzling is why people are willing to form hardened opinions on things they apparently don't understand. It's baffling. Unfortunately this seems to be the popular attitude: c.f. attitudes in politics and other things like economy, climate science etc etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Wed, Nov 10, 2010 at 09:03:25AM -0500, Darryl L. Pierce wrote: On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote: On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor. Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver? xrandr / system-config-display. I use nouveau with two monitors all the time. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 16:59 -0500, Matthew Miller wrote: On Tue, Nov 09, 2010 at 04:35:33PM -0500, Adam Jackson wrote: What kind of attack are you trying to prevent, and how do you envision that interacting with the window system? The classic is a hostile remote binary which secretly maps a full-screen transparent window and captures everything you do in your other windows. It's a little tough to do that in wayland, period. In general apps don't get to know (or control) their screen position or the stacking order. That's the compositor's decision. Likewise (I think) for input event delivery, although I'm not as familiar with that bit. Still: that'd be a definition detail for whatever the remoting protocol ends up being. Things like RDP simply do not let you remote invisible input capture surfaces, it's just not there. It's hard though, because wayland surfaces can have an alpha channel, and the only way to look at a surface and know it's transparent is to inspect every fourth byte... bit expensive that. But you might like to be able to remote windows the size of the screen for the x-terminal kind of use case, but still want to be able to cut/paste between remote and local apps... so you need some IPC, but you probably don't want full input thunking. Not intractable, just subtle. - ajax 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: nouveau gnome-shell
Casey Dahlin cdah...@redhat.com wrote: xrandr / system-config-display. I use nouveau with two monitors all the time. I use xrandr myself (though usually intel or ATi drivers). I find it much less hassle to deal with versus any of the graphical tools that have been made. In addition, the options read very well. xrandr --output LVDS0 --primary --output LVDS1 --right-of LVDS0 as an example. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Wednesday 10 November 2010 09:21:24 Przemek Klosowski wrote: On 11/09/2010 01:12 PM, Dennis Jacobfeuerborn wrote: X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. ... Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. The argument seems to be that toolkit libs like Qt and GTK+ will shield us from major rewriting of apps. However, this implies that toolkits at some point will switch from the X mode to Wayland mode, with the resulting sudden loss of network transparency. This is precisely the situation we have when Qt/GTK+ programs are compiled for Windows: the programs work, they look right, but network transparency is lost. Of course, Windows was never really designed to support network transparency, so nobody is surprised by that. I suppose one could imagine toolkits offering a dual backend: native Wayland, and X that would be invoked by e..g. a commandline switch if remoting was required. This seems a little heavyweight and awkward in both deployment and maintenance. I do not think that a command line switch would even be necessary; the toolkit could just look for DISPLAY, and if that variable is set, it would automatically use X11. Of course, this means that we have to trust the toolkit developers to pay attention to both X11 and Wayland and provide equal levels of support for both, which is not something I really think would happen, at least not in the long run. -- Ben -- Message sent on: Wed Nov 10 10:24:25 EST 2010 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: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Wed, 2010-11-10 at 09:03 -0500, Darryl L. Pierce wrote: On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote: On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor. Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver? gnome-display-properties. nouveau fully supports RandR 1.2, which is a rather better interface than NVIDIA's. -- 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: Why should I ever bother filing another bug?
Michael Cronenworth wrote: Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 But... but... if one of these two is declared duplicate of the other, their CC lists will not be merged... :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnome-shell and panel applets
Is there a replacement in the gnome-shell world for panel applets? In particular I'm a heavy user of SSH Menu (for accessing network gear and Linux servers over SSH) and Remmina (for accessing Windows servers). Without something having something similar under gnome-shell I'm going to have to go back to metacity even though I like many of the new features of gnome-shell. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SWI Prolog is gone from F13 and F14
Petr Pisar ppisar at redhat.com writes: `pl' package? It's there. It may be there but it hasn't been rebuilt for over a year. Last time was for FC12: http://koji.fedoraproject.org/koji/packageinfo?packageID=3471 Actually I maintain the package in RHEL-6 and I have some spec file clean-ups that could be applied into Fedora. If nobody else want to become maintainer, I can do to that. That would be awesome! Joel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-shell and panel applets
On Wed, 2010-11-10 at 11:52 -0600, j...@ocjtech.us wrote: Is there a replacement in the gnome-shell world for panel applets? In particular I'm a heavy user of SSH Menu (for accessing network gear and Linux servers over SSH) and Remmina (for accessing Windows servers). Without something having something similar under gnome-shell I'm going to have to go back to metacity even though I like many of the new features of gnome-shell. Probably best to discuss that upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why does my mail client/web browser not appear in GNOME?
Or why is my dingus click not working? Your web browsers and mail clients need to handle x-scheme-handler/http[1] and x-scheme-handler/mailto respectively to be listed in the GNOME default applications in the new control-center. Once our default applications are setup, I'll make the necessary changes in shared-mime-info for the applications to be picked up. See: http://www.hadess.net/2010/10/new-control-center-and-you.html and http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#id2869854 for details. [1]: And probably x-scheme-handler/https -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does my mail client/web browser not appear in GNOME?
On Wed, 2010-11-10 at 19:21 +, Bastien Nocera wrote: Or why is my dingus click not working? Your web browsers and mail clients need to handle x-scheme-handler/http[1] and x-scheme-handler/mailto respectively to be listed in the GNOME default applications in the new control-center. Once our default applications are setup, I'll make the necessary changes in shared-mime-info for the applications to be picked up. See: http://www.hadess.net/2010/10/new-control-center-and-you.html and http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#id2869854 for details. [1]: And probably x-scheme-handler/https on the topic of the new control-center, any chance of making it work at all any time soon? :) http://bugzilla.redhat.com/show_bug.cgi?id=651510 -- 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
Summary/Minutes from today's FESCo meeting (2010-11-10)
=== #fedora-meeting: FESCO (2010-11-10) === Meeting started by nirik at 18:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-11-10/fesco.2010-11-10-18.30.log.html Meeting summary --- * init process (nirik, 18:30:01) * mjg59 is unable to attend today. (nirik, 18:31:16) * Updates policy / Vision implementation status (nirik, 18:33:59) * LINK: https://admin.fedoraproject.org/updates/critpath?release=F12untested=True (nirik, 18:43:34) * AGREED: : Call for more proventesters in general and f12 ones in particular for now. Accept proposals to adjust or change the policy for Oldest stable release/ideas on how to make it better. (nirik, 18:54:43) * ELECTIONS (nirik, 18:55:02) * LINK: https://fedoraproject.org/wiki/Elections (nirik, 19:02:40) * LINK: http://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominationsaction=history (cwickert, 19:05:07) * AGREED: extend nominations to 0:00UTC on 2010-11-13. (nirik, 19:13:00) NOTE: we are asking the Board to agree/disagree with this, as some folks voting are affected. * kylem is going to step up to coordinate fesco elections this time. (nirik, 19:19:13) * #485 Revisit Bundled Libraries process (nirik, 19:31:14) * LINK: https://fedorahosted.org/fesco/ticket/485 (nirik, 19:31:14) * AGREED: A with the addition of: If the rejection from FPC has some dissenting votes, it can be appealed to Fesco (nirik, 19:44:09) * #486 Plan Fedora 12 EOL (nirik, 19:44:24) * LINK: https://fedorahosted.org/fesco/ticket/486 (nirik, 19:44:24) * ACTION: nirik will send out f12 eol reminder. (nirik, 19:45:53) * #487 Approve Fedora 15 Schedule (nirik, 19:46:55) * LINK: https://fedorahosted.org/fesco/ticket/487 (nirik, 19:46:55) * AGREED: Schedule is approved (nirik, 19:55:10) * Open Floor (nirik, 19:55:38) * Voting (nirik, 19:56:43) * AGREED: voting must be majority of elected body (5) (nirik, 20:04:16) * ACTION: notting to clarify pages on wiki (nirik, 20:04:29) * Open Floor (nirik, 20:04:35) Meeting ended at 20:06:03 UTC. Action Items * nirik will send out f12 eol reminder. * notting to clarify pages on wiki Action Items, by person --- * nirik * nirik will send out f12 eol reminder. * notting * notting to clarify pages on wiki People Present (lines said) --- * nirik (152) * pjones (70) * cwickert (52) * kylem (51) * notting (41) * ajax (27) * mclasen_ (17) * abadger1999 (12) * Oxf13 (11) * zodbot (6) * jsmith (5) * thomasj (3) * poelcat (3) * rbergeron (2) * jlaska (2) * rdieter (1) * spot (1) * SMParrish (0) * mclasen (0) * mjg59 (0) -- 18:30:01 nirik #startmeeting FESCO (2010-11-10) 18:30:01 zodbot Meeting started Wed Nov 10 18:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:01 nirik #meetingname fesco 18:30:01 zodbot The meeting name has been set to 'fesco' 18:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 18:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 18:30:01 nirik #topic init process 18:30:23 pjones Oh, crap. 18:30:27 pjones woefully unprepared today. 18:31:14 kylem i call those 'mondays' 18:31:16 nirik #info mjg59 is unable to attend today. 18:32:23 * cwickert is here 18:32:28 * notting is here 18:32:42 ajax I think so, Brain, but this time you put the trousers on the chimp. 18:33:20 nirik well, thats 5 at least... so I guess we can get started. 18:33:26 pjones kylem: tbf, I call it I handle DST transitions very poorly 18:33:48 kylem i blame the bush congress for moving it around. 18:33:50 nirik DST is anoying. 18:33:59 nirik #topic Updates policy / Vision implementation status 18:33:59 nirik .fesco 351 18:33:59 nirik .fesco 382 18:34:01 zodbot nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 18:34:05 zodbot nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 18:34:15 nirik our bestest friend tickets. ;) 18:34:40 kylem goodie. :) 18:34:54 nirik Some folks have asked about the critical path as it applies to the oldest supported release. 18:35:03 nirik we have had trouble getting many testers for f12 of late. 18:35:11 nirik so, some updates are sitting around for a while. 18:35:33 notting well, logically if you're in the late stages of a release, you probably want to be even more vigilant about regressions 18:35:34 nirik Do we wish to revise/adjust the policy on older stable releases? 18:35:39 notting but that doesn't really help the resource issue 18:35:47 nirik yeah. 18:35:48 cwickert we have people giving faked karma, this is definitely
Reminder: Fedora 12 end of life on 2010-12-02
Greetings. This is a reminder email about the end of life process for Fedora 12. Fedora 12 will reach end of life on 2010-12-02, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 14, no new packages will be added to the Fedora 12 collection. Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading from Fedora 12 to a newer release. kevin signature.asc Description: PGP signature ___ 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: rawhide report: 20101110 changes
Am Mittwoch, den 10.11.2010, 10:34 + schrieb Rawhide Report: Compose started at Wed Nov 10 08:15:17 UTC 2010 Broken deps for x86_64 -- [...] gwget-1.0.4-4.fc14.x86_64 requires libnotify.so.1()(64bit) Fixed in GIT but cannot be built because of 1:epiphany-2.31.5-2.fc15.x86_64 requires libnotify.so.1()(64bit) I created a patch for the libnotify thing, but I epiphany FTBFS. lxmusic-0.4.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) Fixed in GIT but depends on xmms2-0.7-6.fc15.i686 requires libecore-ver-svn-06.so.0 xmms2-0.7-6.fc15.x86_64 requires libecore-ver-svn-06.so.0()(64bit) Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Passing ownership of mingetty
Hello Petr, I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package. Since you're clearly working on it, I think it would make sense to pass ownership to you. If you agree, I will orphan the package so you can take it over (there doesn't seem a way to do a direct transfer in pkgdb). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 626920] [abrt] crash in perl-Padre-0.32-2.fc12: wxStyledTextCtrl::SendMsg: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
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=626920 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||NEXTRELEASE Flag|needinfo?(mact...@webdragon | |.net), | |needinfo?(mact...@webdragon | |.net) | Last Closed||2010-11-10 04:45:18 --- Comment #8 from Marcela Mašláňová mmasl...@redhat.com 2010-11-10 04:45:18 EST --- This bug can't be reproduced in Fedora-14 (v0.64). In F-13 is v0.50, so hopefully it's fixed in both these releases. Update into F-12 is not possible because Padre has a lot of dependencies. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] New upstream release. MojoX is gone.
commit 2fbe4f0518ed310f1927b1f6526cf1436ac30e20
Author: Yanko Kaneti yan...@declera.com
Date: Wed Nov 10 14:32:00 2010 +0200
New upstream release. MojoX is gone.
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 12911a1..571838e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-0.29.tar.gz
/Mojolicious-0.35.tar.gz
/Mojolicious-0.36.tar.gz
+/Mojolicious-0.38.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 8a3f475..cb4cf7d 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:0.36
+Version:0.38
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 10 2010 Yanko Kaneti yan...@declera.com 0.38-1
+- New upstream release. MojoX is gone.
+
* Thu Nov 5 2010 Yanko Kaneti yan...@declera.com 0.36-1
- New upstream bugfix release.
diff --git a/sources b/sources
index 7d7a125..6d79e14 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ffe1a2b4a29441e4332f2c34547f904e Mojolicious-0.36.tar.gz
+85868110b225b1dcd0007f31ed841d53 Mojolicious-0.38.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mojolicious-0.999938.tar.gz uploaded to lookaside cache by yaneti
A file has been added to the lookaside cache for perl-Mojolicious: 85868110b225b1dcd0007f31ed841d53 Mojolicious-0.38.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] Created tag perl-Mojolicious-0.999938-1.fc15
The lightweight tag 'perl-Mojolicious-0.38-1.fc15' was created pointing to: 2fbe4f0... New upstream release. MojoX is gone. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 648598] perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
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=648598 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-11-10 16:40:14 EST --- perl-Term-ProgressBar-2.09-9.fc13 has been pushed to the Fedora 13 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 648598] perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
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=648598 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Term-ProgressBar-2.09- ||9.fc13 Resolution||ERRATA Last Closed||2010-11-10 16:40:19 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 648598] perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
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=648598 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2010-11-10 16:45:11 EST --- perl-Term-ProgressBar-2.09-9.fc14 has been pushed to the Fedora 14 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 648598] perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
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=648598 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Term-ProgressBar-2.09- |perl-Term-ProgressBar-2.09- |9.fc13 |9.fc14 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
