Re: Gnome-shell-extension-weather woes
From: Steven Boswell II ulat...@yahoo.com Subject: Re: Gnome-shell-extension-weather woes Maybe it's because I'm running GNOME3 in fallback mode. I can't stand the new GNOME GUI. Heh...I see! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell-extension-weather woes
- Original Message - From: Rahul Sundaram methe...@gmail.com Subject: Re: Gnome-shell-extension-weather woes http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html. By default, in ~.local/share/gnome-shell/extensions Cool...thanks! :) --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand mich...@elehack.net wrote: Performance improvement: improve scaling to 5K+ installed packages. * Amen. This is particularly compounded by poor caching default behavior, so that a few yum commands in a row each wind up reaching out to downloading metadata again, and again, and again. I think this can be addressed by moving the metadata updates to a different function, and calling it *separately* only as needed. The Debian apt tool does this quite effectively. Unfortunately there is not much we can do about this. Debian has completely different repository policy - they keep all versions of packages in the repo so there is no need to update metadata on client machines every time. * Script parseable output without extraneous labeling. The output of yum list is cluttered with unnecessary headers, and whitespace handling that winds up trimming package names or inserting extraneous new lines. I'd fiind it invaluable if yum list --tsv gave a tab separated variables list of: nameversion release arch reponame And leave *OFF* the Installed Packages and Available Packages entries for such tab separated variable output. I loathe having to sort those out for scriptable operations. Interesting idea, might be worth looking into. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/27/2013 09:32 AM, Jan Zelený wrote: On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand mich...@elehack.net wrote: Performance improvement: improve scaling to 5K+ installed packages. * Amen. This is particularly compounded by poor caching default behavior, so that a few yum commands in a row each wind up reaching out to downloading metadata again, and again, and again. I think this can be addressed by moving the metadata updates to a different function, and calling it *separately* only as needed. The Debian apt tool does this quite effectively. Unfortunately there is not much we can do about this. Debian has completely different repository policy - they keep all versions of packages in the repo so there is no need to update metadata on client machines every time. I don't quite understand this comment. Debian repository policy varies quite a bit. Some repositories keep old versions, some don't. Mostly the latter, actually, because not all repository managers (there a couple of implementations) can deal with multiple versions for a single package/architecture combination. As far as I can tell, the main difference is that apt-get and apt-cache read very few, relatively large files at the beginning, so they don't block on disk reads early. dpkg, on the other hand, uses a database scatter across many small files on disk, so you get the delay only when you actually install or remove any packages. At the beginning, this is quite fast, but eventually, the files will be scattered quite badly, and there is a considerable delay at this step. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 24. 5. 2013 at 15:20:24, Rahul Sundaram wrote: On 05/23/2013 07:08 AM, Jan Zelený wrote: Have you tried using dnf instead of yum? It is much faster. To be perfectly honest we don't plan to invest much effort in developing new things for yum, it will more and more shift towards maintenance mode and the focus will be on dnf. What does the we stand for here? If this is Red Hat on the whole, a broader announcement of the plan would be helpful. I will note that while dnf is faster overall, it doesn't have many of the important features of yum and I still ran into bugs in some trivial tests from time to time. https://fedoranext.wordpress.com/2013/05/18/status-of-dnf-experimental-fork- of-yum/ The we means the Software management team. Obviously the dnf is still nowhere near the state of yum but it's continuously getting there. If we don't stop development of features in yum at some point, it will be impossible to replace yum with dnf in the future. If you feel that there are some important features missing, please let us know which ones. Although we won't automatically prioritize all of them, we will take your input into consideration. Note that everyone can have his own set of features that he considers to be important. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-05-27 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-05-27 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again today/tomorrow! Huge congratulations and thanks to everyone for the release of Fedora 19 Beta on time and at a high quality, great job on testing everyone. We'll be looking after the final details for Tuesday's Beta release, looking ahead to Final, and perhaps discussing tflink's 'Taskbot' idea. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130527 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 19 Beta review/wrap-up 3. Fedora 19 Final planning 4. Taskbot 5. Test Days 6. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 27. 5. 2013 at 09:43:15, Florian Weimer wrote: On 05/27/2013 09:32 AM, Jan Zelený wrote: On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand mich...@elehack.net wrote: Performance improvement: improve scaling to 5K+ installed packages. * Amen. This is particularly compounded by poor caching default behavior, so that a few yum commands in a row each wind up reaching out to downloading metadata again, and again, and again. I think this can be addressed by moving the metadata updates to a different function, and calling it *separately* only as needed. The Debian apt tool does this quite effectively. Unfortunately there is not much we can do about this. Debian has completely different repository policy - they keep all versions of packages in the repo so there is no need to update metadata on client machines every time. I don't quite understand this comment. Debian repository policy varies quite a bit. Some repositories keep old versions, some don't. Mostly the latter, actually, because not all repository managers (there a couple of implementations) can deal with multiple versions for a single package/architecture combination. I'm sorry but the Debian repositories say otherwise, see Iceweasel for instance: http://ftp.cz.debian.org/debian/pool/main/i/iceweasel/ Multiple old versions are kept in there. That's why they don't need to update their metadata every single time - the old ones are simply still valid. As far as I can tell, the main difference is that apt-get and apt-cache read very few, relatively large files at the beginning, so they don't block on disk reads early. dpkg, on the other hand, uses a database scatter across many small files on disk, so you get the delay only when you actually install or remove any packages. At the beginning, this is quite fast, but eventually, the files will be scattered quite badly, and there is a considerable delay at this step. This part is about disk read-write but that was not what I was writing about. From my experience users mostly complain about the metadata download which is explained above. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Le Dim 26 mai 2013 11:10, Lars Seipel a écrit : On Sat, May 25, 2013 at 09:34:32AM -0400, Nico Kadel-Garcia wrote: I think this can be addressed by moving the metadata updates to a different function, and calling it *separately* only as needed. The Debian apt tool does this quite effectively. You can kind of simulate that by forcing yum to run from cache only. Use the -C flag for that. But the basic reason stands: yum only handles well perfectly synced repos, and workarounds this by trying to get the freshest metadata all the time. If yum's error handling was better, it would not fail as soon as there is the slightest sync error, a semi-stale repo, a caching proxy, etc, etc -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
And there package diffs, which are ed-style diffs of the Packages file I mentioned above. This approach would work quite well for primary.xml because it doesn't contain cross-references between packages using non-natural keys. It doesn't work for the SQLite database, either in binary or SQL dump format, because of the reliance on artificial primary keys (such as package IDs). I've once tried this. With about 10k packages in fedora-updates, the delta over 2-3 days was +491 -479. Assuming deletions are cheap, the delta should ideally be 5%. As expected, binary bsddiff yields much bigger (~29%) delta. Very roughly, it's 5% that really describe new packages, plus an almost constant 24% overhead to fix up the inevitable changes in surrogate keys. Not as bad as I was afraid, but still not worth it (IMO). So, we need *.xml deltas. Yum can rebuild xml = .sqlite locally, but this needs quite a lot of memory and takes TENS of seconds. Add the time needed to patch the quite large uncompressed xml file, and suddenly the fact that you're downloading just 1/10th of data hardly pays off (ignoring very specific use cases, like mobile data for a moment) For DNF, it's different. It has to rebuild xml = .solv anyway, so this comes for free. However, for many users that follow unstable or testing, package diffs are currently slower than downloading the full Packages file because the diffs are incremental (i.e., they contain the changes from file version N to N+1, and you have to apply all of them to get to the current version) and apt-get can easily write 100 MB or more because the Packages file is rewritten locally multiple times. Yes, patch chaining should be avoided. I'd like to use N = 1 deltas, that could be applied to many recent snapshots. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Directory-Queue/el5] (2 commits) ...Merge branch 'master' into el5
Summary of changes: 9893c77... Rebuilding it. 6dda093... Merge branch 'master' into el5 -- 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
nodejs-graceful-fs incorrect license, now BSD
License change notification: Upstream specifies in package.json (metadata) that the license is BSD, but has actually been shipping a LICENSE file containing the MIT license. Upstream have now replaced it with the text of the BSD license. The license of the Fedora package has been changed from MIT to BSD accordingly, and contains a copy of the updated LICENSE. Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing OLPC OS 13.1.0
Hi Daniel, Would just like to note the wiki needs to be updated as is says 13.1.0 is the devel release upcoming. Peter On Mon, May 6, 2013 at 10:15 PM, Daniel Drake d...@laptop.org wrote: Hi, We're pleased to announce the release of OLPC OS 13.1.0 for XO-1, XO-1.5, XO-1.75 and XO-4. Details of new features, known issues, and how to download/install/upgrade can all be found in the release notes: http://wiki.laptop.org/go/Release_notes/13.1.0 Many thanks to all contributors, testers, upstreams, and those who have provided feedback of any kind. For those who were following the release candidate process in the last few months: candidate build 36 is released as final with no changes. Thanks! Daniel p.s. We're already knee-deep in development of the next release, 13.2.0. More info here: http://wiki.laptop.org/go/13.2.0 http://wiki.laptop.org/go/13.2.0/Release_plan ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GCC -fdiagnostics-color= default
Hi!
gcc 4.8.0-6.fc19 and later contains a backport of color diagnostics
support from gcc trunk. Right now it is disabled by default, unless GCC_COLORS
env var is set in the environment (to non-empty value), and
-fdiagnostics-color={never,auto,always} switch can be used to override this
(never is to never emit colors (same affect if GCC_COLORS in environment
is present and empty), auto is to emit colors when stderr is a tty,
always even if not a tty. Can people test this and report any issues with
it? Would users appreciate it being done by default (i.e. make
-fdiagnostics-color=auto the default)?
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/27/2013 11:48 AM, Zdenek Pavlas wrote: And there package diffs, which are ed-style diffs of the Packages file I mentioned above. This approach would work quite well for primary.xml because it doesn't contain cross-references between packages using non-natural keys. It doesn't work for the SQLite database, either in binary or SQL dump format, because of the reliance on artificial primary keys (such as package IDs). I've once tried this. With about 10k packages in fedora-updates, the delta over 2-3 days was +491 -479. Assuming deletions are cheap, the delta should ideally be 5%. As expected, binary bsddiff yields much bigger (~29%) delta. A line-wise diff is much smaller because dependencies and package descriptions mostly stay the same. (This assumes consistent sorting of the primary.xml file.) Can you point me to the primary.xml - SQLite translation in yum? I've got a fairly efficient primary.xml parser. It might be interesting to see if it's possible to reduce the latency introduced by the SQLite conversion to close to zero. (Decompression and INSERTs can be interleaved with downloading, and maybe the index creation improvements in SQLite are sufficient these days.) However, for many users that follow unstable or testing, package diffs are currently slower than downloading the full Packages file because the diffs are incremental (i.e., they contain the changes from file version N to N+1, and you have to apply all of them to get to the current version) and apt-get can easily write 100 MB or more because the Packages file is rewritten locally multiple times. Yes, patch chaining should be avoided. I'd like to use N = 1 deltas, that could be applied to many recent snapshots. The Debian package diffs could be combined efficiently in the client because it's possible to combine diffs for two adjacent versions without actually knowing what the old or new versions look like. But this hasn't been implemented in APT because ABI impact (which is a bit puzzling, but anyway). Instead, the diffs should soon be combined on the archive side. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build control-center in mock fail
On Sun, May 26, 2013 at 1:18 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Nico Kadel-Garcia wrote: On Sat, May 25, 2013 at 1:14 PM, Kevin Fenzi ke...@scrye.com wrote: I'm sure we could ask the FPC to add this to guidelines. I've filed such a ticket, please feel free to add comments: https://fedorahosted.org/fpc/ticket/295 It's reasonable, but is missing an important feature. All source materials for the RPM must also be contained in the new SRPM, preferably as source material. This creates a preference for source rather than .jar, .war, or .gem files, but I think that's really desirable. The requirement to build from source is already explicit: https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries Björn Persson Thanks for the pointer! Of course, that leaves out hte problem of rubygems, .jar files, and other published binary inclusions masquerading as source files in the SRPM. But it's a clearly written guideline, thank you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130527 changes
Compose started at Mon May 27 08:15:03 UTC 2013 Broken deps for x86_64 -- [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lua-logging] lua-logging-1.3.0-1.fc20.noarch requires lua = 0:5.2 [lua-rex] lua-rex-2.7.2-1.fc20.x86_64 requires lua = 0:5.2 [luadoc] luadoc-3.0.1-8.fc20.noarch requires lua = 0:5.2 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 lutok-devel-0.2-4.fc19.x86_64 requires lua-devel 0:5.2 [nodejs-request] nodejs-request-2.16.6-2.fc20.noarch requires npm(qs) 0:0.6 [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-cpp-server-xml-0.20-6.fc20.x86_64 requires libxqilla.so.5()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tex-simplecv] tex-simplecv-doc-1.6-12.fc19.noarch requires texlive-texmf-doc [texlive] 2:texlive-convbkmk-bin-svn30408.0-23.20130523_r30652.fc20.noarch requires tex-convbkmk 2:texlive-texdiff-bin-svn15506.0-23.20130523_r30652.fc20.noarch requires tex-texdiff [zarafa] libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0 libmapi-7.0.13-1.fc19.i686 requires libical.so.0 libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 zarafa-ical-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) zarafa-ical-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) Broken deps for i386 -- [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [ekiga] ekiga-4.0.1-1.fc19.i686 requires libedata-book-1.2.so.17 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lua-logging] lua-logging-1.3.0-1.fc20.noarch requires lua = 0:5.2 [lua-rex] lua-rex-2.7.2-1.fc20.i686 requires lua = 0:5.2 [luadoc] luadoc-3.0.1-8.fc20.noarch requires lua = 0:5.2 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 [nodejs-request] nodejs-request-2.16.6-2.fc20.noarch requires npm(qs) 0:0.6 [ooo2gd] ooo2gd-3.0.0-6.fc19.i686 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.i686 requires libgdmsimplegreeter.so.1 [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-cpp-server-xml-0.20-6.fc20.i686 requires libxqilla.so.5 [scala]
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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: Software Management call for RFEs
On Mon, May 27, 2013 at 6:17 AM, Florian Weimer fwei...@redhat.com wrote: On 05/27/2013 11:48 AM, Zdenek Pavlas wrote: And there package diffs, which are ed-style diffs of the Packages file I mentioned above. This approach would work quite well for primary.xml because it doesn't contain cross-references between packages using non-natural keys. It doesn't work for the SQLite database, either in binary or SQL dump format, because of the reliance on artificial primary keys (such as package IDs). I've once tried this. With about 10k packages in fedora-updates, the delta over 2-3 days was +491 -479. Assuming deletions are cheap, the delta should ideally be 5%. As expected, binary bsddiff yields much bigger (~29%) delta. A line-wise diff is much smaller because dependencies and package descriptions mostly stay the same. (This assumes consistent sorting of the primary.xml file.) The diffs are not the problem. The problem is hte excessively frequent downloads of the repodata, which are compressed binaries with checksums, not published as deltas or diffs. The result is a grossly inefficient and far-too-frequent download of upstream repository information. It's not the local SQLite database operations in the yum cache that are killing me, at least, it's the short metadata_expire in /etc/yum.conf. Very few of us really need our metadata expired between our first cup of coffee in the morning, and luncthtime. And very few of us need yum-updatesd and other auto-magic update tools grinding our host and our proxies bandwidth for several 20 Megabyte files every few hours, nor grinding our local disk with the uncompressed *80 Megabyte* file of primary.xml sitting in /var/cache/yum/. This is an inherent problem with the let's store more, and more, and more data in the database. The databases for yum have gotten bulky and cumbersome, and the automatic churn involved in updating them with fresh repodata has become quite large. Can you point me to the primary.xml - SQLite translation in yum? I've got a fairly efficient primary.xml parser. It might be interesting to see if it's possible to reduce the latency introduced by the SQLite conversion to close to zero. (Decompression and INSERTs can be interleaved with downloading, and maybe the index creation improvements in SQLite are sufficient these days.) Good luck with that! It's not what I, personally, was just looking for, but improving that would be nice. But the SQLite files are getting larger, and larger, and larger. At 80 Meg and counting for the Fedora primary.sqlie, it's getting out of hand. However, for many users that follow unstable or testing, package diffs are currently slower than downloading the full Packages file because the diffs are incremental (i.e., they contain the changes from file version N to N+1, and you have to apply all of them to get to the current version) and apt-get can easily write 100 MB or more because the Packages file is rewritten locally multiple times. Yes, patch chaining should be avoided. I'd like to use N = 1 deltas, that could be applied to many recent snapshots. And it has little to do with the yum issue I've raised, which is entirely about the metadata. My personal experience is that the use of deltarpms is a bandwidth and resource issue completely overshadowed by the constant grinding of disk and bandwidth for hte metadata. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What does this means?
https://apps.fedoraproject.org/packages/s/leechcaft https://admin.fedoraproject.org/updates/search/leechcraft -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does this means?
2013/5/27 Eugene Pivnev ti.eug...@gmail.com: https://apps.fedoraproject.org/packages/s/leechcaft https://admin.fedoraproject.org/updates/search/leechcraft This package was abandoned by its maintainer. Do you want to take it over? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does this means?
27.05.2013 17:26, Peter Lemenkov пишет: 2013/5/27 Eugene Pivnev ti.eug...@gmail.com: https://apps.fedoraproject.org/packages/s/leechcaft https://admin.fedoraproject.org/updates/search/leechcraft This package was abandoned by its maintainer. Do you want to take it over? Package exists in repo. It exists in bodhi (as Stable). It is not depricated. Why it is not in package db? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does this means?
On , Eugene Pivnev wrote: 27.05.2013 17:26, Peter Lemenkov пишет: 2013/5/27 Eugene Pivnev ti.eug...@gmail.com: https://apps.fedoraproject.org/packages/s/leechcaft You made a typo in the name here but that does not matter actually (see below) https://admin.fedoraproject.org/updates/search/leechcraft This package was abandoned by its maintainer. Do you want to take it over? Package exists in repo. It exists in bodhi (as Stable). It is not depricated. Why it is not in package db? This is what Peter said and the source of your question: https://admin.fedoraproject.org/pkgdb/acls/name/leechcraft Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap offer
Hi, i've a new package. mintmenu - Advanced Menu for the MATE Desktop An advanced slab style menu for Linux. MintMenu supports filtering, favorites, auto-session, and many other features. MintMenu can either be added to your mate-panel or launched in its own window. https://bugzilla.redhat.com/show_bug.cgi?id=967568 The package is writen in python. I'm glad to review another package in a review swap. cheers. Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Can you point me to the primary.xml - SQLite translation in yum? I've got a fairly efficient primary.xml parser. Just set mddownloadpolicy=xml in yum.conf. It should work, but since downloading sqlite.bz2 is much better, very few use this. Yum uses fairly efficient parser, written in C, using libxml2 (the yum-metadata-parser package). It's always bundled, because Yum has to support xml-only repositories anyway. Oh, there's a typo in yum.conf.5 .. fixed. It might be interesting to see if it's possible to reduce the latency introduced by the SQLite conversion to close to zero. (Decompression and INSERTs can be interleaved with downloading, and maybe the index creation improvements in SQLite are sufficient these days.) We have to checksum the downloaded data before processing, and this kills pipelining. Also, when updating primary_db with a bunch of INSERTs and DELETEs, your database differs from the one on server: - different *.sqlite checksum - different pkgId = PkgKey mapping - different order of packages from SELECTs For speed, Yum joins primary_db and filelists_db via pkgKey, so #2 breaks Yum, unless you always download/delta-update both- so this kills the win in we don't need filelists case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC -fdiagnostics-color= default
Jakub Jelinek wrote: Would users appreciate it being done by default (i.e. make -fdiagnostics-color=auto the default)? Could you give a little more information? * What is gcc diagnostic colors exactly? * Any pros/cons? -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-Compress] Update to 2.061
commit 178cbb2251cceb02edf771d81b7e3722e7131c51
Author: Paul Howarth p...@city-fan.org
Date: Mon May 27 16:21:28 2013 +0100
Update to 2.061
- New upstream release 2.061
- zipdetails (1.06)
- Get it to cope with Android 'zipalign' non-standard extra fields;
these
are used to make sure that a non-compressed member starts on a 4 byte
boundary
- unzip example with IO::Uncompress::Unzip (CPAN RT#84647)
perl-IO-Compress.spec | 12 ++--
sources |2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
---
diff --git a/perl-IO-Compress.spec b/perl-IO-Compress.spec
index 532033a..8d91b0c 100644
--- a/perl-IO-Compress.spec
+++ b/perl-IO-Compress.spec
@@ -2,8 +2,8 @@
%{?perl_default_filter}
Name: perl-IO-Compress
-Version:2.060
-Release:2%{?dist}
+Version:2.061
+Release:1%{?dist}
Summary:Read and write compressed data
License:GPL+ or Artistic
Group: Development/Libraries
@@ -108,6 +108,14 @@ make test %{?with_long_tests:COMPRESS_ZLIB_RUN_ALL=1}
%{_mandir}/man3/IO::Uncompress::*.3pm*
%changelog
+* Mon May 27 2013 Paul Howarth p...@city-fan.org - 2.061-1
+- Update to 2.061
+ - zipdetails (1.06)
+- Get it to cope with Android 'zipalign' non-standard extra fields; these
+ are used to make sure that a non-compressed member starts on a 4 byte
+ boundary
+ - unzip example with IO::Uncompress::Unzip (CPAN RT#84647)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.060-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 379d532..ecb99be 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-346a1c981930f7cab54a4973480b3c73 IO-Compress-2.060.tar.gz
+0dba831e748f03e549eaf288026ef099 IO-Compress-2.061.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: GCC -fdiagnostics-color= default
On Mon, May 27, 2013 at 10:29:56AM -0500, Rex Dieter wrote: Jakub Jelinek wrote: Would users appreciate it being done by default (i.e. make -fdiagnostics-color=auto the default)? Could you give a little more information? * What is gcc diagnostic colors exactly? Colorized output of gcc diagnostics, similar to how say grep or ls colorizes its output by default in Fedora, see http://gcc.gnu.org/gcc-4.9/changes.html (C family section). Best if anyone interested just tries it out. * Any pros/cons? Same thing as pros/cons of colorizing grep or ls output by default. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Module-Build-Tiny-0.021.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Build-Tiny: 8fcd9fa55ac2756e7208cc989cfd1a3d Module-Build-Tiny-0.021.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-Module-Build-Tiny] Update to 0.021
commit 638d8c6f4b8a249747e9be4f28a8aad942e806e0
Author: Paul Howarth p...@city-fan.org
Date: Mon May 27 16:38:54 2013 +0100
Update to 0.021
- New upstream release 0.021
- Add XS support
- Only manify if really installable
- BR:/R: perl(ExtUtils::CBuilder) and perl(ExtUtils::ParseXS)
- BR: perl(XSLoader) for the test suite
perl-Module-Build-Tiny.spec | 14 +-
sources |2 +-
2 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/perl-Module-Build-Tiny.spec b/perl-Module-Build-Tiny.spec
index adaa7dd..a70e872 100644
--- a/perl-Module-Build-Tiny.spec
+++ b/perl-Module-Build-Tiny.spec
@@ -1,6 +1,6 @@
Summary: A tiny replacement for Module::Build
Name: perl-Module-Build-Tiny
-Version: 0.020
+Version: 0.021
Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
@@ -10,10 +10,12 @@ BuildArch: noarch
# Module
BuildRequires: perl(CPAN::Meta)
BuildRequires: perl(Exporter) = 5.57
+BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::Config) = 0.003
BuildRequires: perl(ExtUtils::Helpers) = 0.020
BuildRequires: perl(ExtUtils::Install)
BuildRequires: perl(ExtUtils::InstallPaths) = 0.002
+BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(Getopt::Long)
@@ -30,8 +32,11 @@ BuildRequires: perl(File::Temp)
BuildRequires: perl(IO::File)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(XSLoader)
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(ExtUtils::CBuilder)
+Requires: perl(ExtUtils::ParseXS)
Requires: perl(Pod::Man)
Requires: perl(TAP::Harness) = 3.0
@@ -63,6 +68,13 @@ RELEASE_TESTING=1 ./Build test
%{_mandir}/man3/Module::Build::Tiny.3pm*
%changelog
+* Mon May 27 2013 Paul Howarth p...@city-fan.org - 0.021-1
+- Update to 0.021
+ - Add XS support
+ - Only manify if really installable
+- BR:/R: perl(ExtUtils::CBuilder) and perl(ExtUtils::ParseXS)
+- BR: perl(XSLoader) for the test suite
+
* Mon May 20 2013 Paul Howarth p...@city-fan.org - 0.020-1
- Update to 0.020
- Accept a --create_packlist argument
diff --git a/sources b/sources
index 666b407..3792e55 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-91f1503e1ec7fc84d75f7be8a7cf26bc Module-Build-Tiny-0.020.tar.gz
+8fcd9fa55ac2756e7208cc989cfd1a3d Module-Build-Tiny-0.021.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
[Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
Hey all, The Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th. Check out the test day landing page: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization If you're interested in trying out some new virt functionality, there's step by step instructions for: * Live migrate a VM without the need for shared storage * Virtio RNG, a paravirtual random number generator for VMs * PCI device assignment using VFIO Even if you aren't interested in testing new features, we still need you! The test day is the perfect time to make sure your virt workflow is working fine on Fedora 19, as there will be several developers on hand to answer any questions, help with debugging, provide patches, etc. No requirement to run through test cases on the wiki, just show up and let us know what works (or breaks). If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout! Thanks, Cole ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap offer
I'll do this review, Wolfgang This is my review https://bugzilla.redhat.com/show_bug.cgi?id=962029 2013/5/27 Rave it chat-to...@raveit.de Hi, i've a new package. mintmenu - Advanced Menu for the MATE Desktop An advanced slab style menu for Linux. MintMenu supports filtering, favorites, auto-session, and many other features. MintMenu can either be added to your mate-panel or launched in its own window. https://bugzilla.redhat.com/show_bug.cgi?id=967568 The package is writen in python. I'm glad to review another package in a review swap. cheers. Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Eduardo Echeverría Director Soluciones SAEF, C.A. J-29663216-2 0245-7666441 0414-4304448 soluciones.s...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Hey, On Wed, May 22, 2013 at 05:08:33PM -0400, Rahul Sundaram wrote: On Wed, May 22, 2013 at 9:43 AM, Jan Zelený wrote: We acknowledge the need for some changes in Software Management stack in Fedora but we don't want to make changes just by guessing what our users want. Therefore I call to you, consumers of our products (dnf, yum and rpm): what are the changes that you would like to see in the foreseeable future (say 2-3 years) and why would you like to see them (what would they help you with)? Thanks for taking on this effort. What I would like to see is solid git integration. Git has become the standard distributed vcs and github and google code etc have stopped hosting tarballs and/or discouraging it and GNOME is planning to do that as well. If Source URL could point directly to a git url with a hash or git tag, we would benefit. I'd add to that an optional GPG key to check the git tag against. Christophe pgpsvySRo_dBL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Build-Tiny] Created tag perl-Module-Build-Tiny-0.021-1.fc20
The lightweight tag 'perl-Module-Build-Tiny-0.021-1.fc20' was created pointing to: 638d8c6... Update to 0.021 -- 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: [dnf] dnf-0.3.6-1
I still cannot see each package's size, they all are 0. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
Hello All! 2013/5/27 Cole Robinson crobi...@redhat.com: Hey all, The Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th. Check out the test day landing page: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization Is it still possible to add a few more testcases? I suppose that OpenVZ fellows would like to test a recently added crtools and vzctl. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
On 05/27/2013 12:09 PM, Peter Lemenkov wrote: Hello All! 2013/5/27 Cole Robinson crobi...@redhat.com: Hey all, The Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th. Check out the test day landing page: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization Is it still possible to add a few more testcases? I suppose that OpenVZ fellows would like to test a recently added crtools and vzctl. Tests for openvz would be appreciated. But I wouldn't want to link them under the main battery of tests, which are KVM focused. Xen has their own page, but for a start just adding an OpenVZ section under 'Extra tests' would work: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization#Extra_tests Next Fedora cycle I'd like to try and coordinate all the virt testing efforts into the same week, so we can share promotion efforts and hopefully increase participation all around. - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
Hi,
ON: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization
Fedora 19 on a physical machine
The preferred testing platform is a fully updated Fedora 19 machine. You have
a few options for getting the Fedora 18 bits:
(there is a typo , since it says Fedora 18 bits, should it be 19?)
Install with CD/DVD.
Latest live CD builds ('desktop' is the default):
http://alt.fedoraproject.org/pub/alt/nightly-composes/
Latest 64 Bit DVD:
https://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC4/Fedora/x86_64/iso/
Is there a particular reason to use F19b TC4? Why not using F19b RC4?
Or just point to: https://dl.fedoraproject.org/pub/alt/stage/
and specify 'use latest' and optionally a minimum version aka do not
use an version older than F19b TC4.
Cheers.
On Mon, May 27, 2013 at 1:18 PM, Cole Robinson crobi...@redhat.com wrote:
On 05/27/2013 12:09 PM, Peter Lemenkov wrote:
Hello All!
2013/5/27 Cole Robinson crobi...@redhat.com:
Hey all,
The Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th. Check out the
test day landing page:
https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization
Is it still possible to add a few more testcases? I suppose that
OpenVZ fellows would like to test a recently added crtools and vzctl.
Tests for openvz would be appreciated. But I wouldn't want to link them under
the main battery of tests, which are KVM focused. Xen has their own page, but
for a start just adding an OpenVZ section under 'Extra tests' would work:
https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization#Extra_tests
Next Fedora cycle I'd like to try and coordinate all the virt testing efforts
into the same week, so we can share promotion efforts and hopefully increase
participation all around.
- Cole
--
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: [Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
On 05/27/2013 12:37 PM, Reartes Guillermo wrote:
Hi,
ON: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization
Fedora 19 on a physical machine
The preferred testing platform is a fully updated Fedora 19 machine. You
have a few options for getting the Fedora 18 bits:
(there is a typo , since it says Fedora 18 bits, should it be 19?)
Install with CD/DVD.
Latest live CD builds ('desktop' is the default):
http://alt.fedoraproject.org/pub/alt/nightly-composes/
Latest 64 Bit DVD:
https://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC4/Fedora/x86_64/iso/
Is there a particular reason to use F19b TC4? Why not using F19b RC4?
Or just point to: https://dl.fedoraproject.org/pub/alt/stage/
and specify 'use latest' and optionally a minimum version aka do not
use an version older than F19b TC4.
I was going to update that to the latest release tonight, just wanted to make
it explicit as possible. But it's just going to get stale as you've pointed
out, so I'll make the link generic as you suggest.
Thanks,
Cole
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Review Swap offer
Thanks, i've catched your review. Wolfgang Message: 14 Date: Mon, 27 May 2013 11:18:03 -0430 From: Eduardo Javier Echeverria Alvarado echevemas...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Review Swap offer Message-ID: caehqjwk_tlkrk9cwh5omyfdvyqucpsrmzg4zxqrcdcsp6f3...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I'll do this review, Wolfgang This is my review https://bugzilla.redhat.com/show_bug.cgi?id=962029 2013/5/27 Rave it chat-to...@raveit.de Hi, i've a new package. mintmenu - Advanced Menu for the MATE Desktop An advanced slab style menu for Linux. MintMenu supports filtering, favorites, auto-session, and many other features. MintMenu can either be added to your mate-panel or launched in its own window. https://bugzilla.redhat.com/show_bug.cgi?id=967568 The package is writen in python. I'm glad to review another package in a review swap. cheers. Wolfgang -- 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: GCC -fdiagnostics-color= default
gcc 4.8.0-6.fc19 and later contains a backport of color diagnostics
support from gcc trunk. ...
Would users appreciate it being done by default (i.e. make
-fdiagnostics-color=auto the default)?
* Any pros/cons?
Same thing as pros/cons of colorizing grep or ls output by default.
Let's make an explicit list. Here is a start:
0. Supposedly the colors provide faster visual communication, increased ease
of recognition and understanding, etc.: an enhancement.
1. Background color matters. The default colors are chosen for a black
background.
On a white background some of the default colors may be more difficult
to process visually. For example, on a white background I find it
much harder to recognize and process the green caret under the terminating
right brace of test.C:1:14: warning: no return statement in function
returning non-void [-Wreturn-type]
int foo () { } in http://gcc.gnu.org/gcc-4.9/changes.html (C family
section).
2. Changing the default colors is cumbersome. Remembering how to turn off
the colorization is another straw on the user's back.
3. Redirecting stderr to a non-terminal changes the error message.
(Configurable; but it is another straw.)
4. The bugs in colorized presentation of error messages may be different
than in non-colorized presentation.
5. No attention has been paid to how colorization affects persons
who have color blindness or other visual disabilities.
6. Colorization is not being presented as a plugin which uses the API
for gcc's warning subsystem. Is colorization such a plugin? Why not?
How does colorization interact with an existing use of the API for
gcc's warning subsystem?
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
git rebase master
Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC -fdiagnostics-color= default
On 05/27/2013 06:16 PM, John Reiser wrote:
gcc 4.8.0-6.fc19 and later contains a backport of color diagnostics
support from gcc trunk. ...
Would users appreciate it being done by default (i.e. make
-fdiagnostics-color=auto the default)?
* Any pros/cons?
Same thing as pros/cons of colorizing grep or ls output by default.
Let's make an explicit list. Here is a start:
0. Supposedly the colors provide faster visual communication, increased ease
of recognition and understanding, etc.: an enhancement.
1. Background color matters. The default colors are chosen for a black
background.
On a white background some of the default colors may be more difficult
to process visually. For example, on a white background I find it
much harder to recognize and process the green caret under the terminating
right brace of test.C:1:14: warning: no return statement in function
returning non-void [-Wreturn-type]
int foo () { } in http://gcc.gnu.org/gcc-4.9/changes.html (C family
section).
Note 256 colors are supported by default since Fedora 18
and give much more choice for colors that are appropriate
for light or dark backgrounds:
http://fedoraproject.org/wiki/Features/256_Color_Terminals
2. Changing the default colors is cumbersome. Remembering how to turn off
the colorization is another straw on the user's back.
3. Redirecting stderr to a non-terminal changes the error message.
(Configurable; but it is another straw.)
4. The bugs in colorized presentation of error messages may be different
than in non-colorized presentation.
5. No attention has been paid to how colorization affects persons
who have color blindness or other visual disabilities.
6. Colorization is not being presented as a plugin which uses the API
for gcc's warning subsystem. Is colorization such a plugin? Why not?
How does colorization interact with an existing use of the API for
gcc's warning subsystem?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC -fdiagnostics-color= default
On Mon, May 27, 2013 at 10:16:56AM -0700, John Reiser wrote:
Let's make an explicit list. Here is a start:
0. Supposedly the colors provide faster visual communication, increased ease
of recognition and understanding, etc.: an enhancement.
Yeah, that is the goal.
1. Background color matters. The default colors are chosen for a black
background.
On a white background some of the default colors may be more difficult
to process visually. For example, on a white background I find it
much harder to recognize and process the green caret under the terminating
right brace of test.C:1:14: warning: no return statement in function
returning non-void [-Wreturn-type]
int foo () { } in http://gcc.gnu.org/gcc-4.9/changes.html (C family
section).
You should test output from the compiler, the web page has the output of the
compiler transformed into HTML colors and bold. It has been tested with
both black and white backgrounds and uses the grep recommendations for
default color choosing.
2. Changing the default colors is cumbersome. Remembering how to turn off
the colorization is another straw on the user's back.
The info page as well as man page documents it, and the format is the same
to GREP_COLORS, just the color names are different.
GCC_COLORS= turns it off, invalid color names are ignored, valid change the
default. So, right now GCC_COLORS=' ' (invalid color name) or say
GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
e.g. makes it show colors in auto mode by default.
3. Redirecting stderr to a non-terminal changes the error message.
(Configurable; but it is another straw.)
ls and grep behave the same.
4. The bugs in colorized presentation of error messages may be different
than in non-colorized presentation.
No, the colors are always just visual highlight of some things, the actual
characters in the diagnostics don't change.
5. No attention has been paid to how colorization affects persons
who have color blindness or other visual disabilities.
It can be easily disabled, and how is this different from ls/grep default
behavior in Fedora?
6. Colorization is not being presented as a plugin which uses the API
for gcc's warning subsystem. Is colorization such a plugin? Why not?
Why it should be a plugin? The everything must be plugin mantra is
weird. It is fully customizable, the diagnostics isn't XML or anything
similar internally, so all a plugin could see in a hook would be the
resulting diagnostics which has info lost.
How does colorization interact with an existing use of the API for
gcc's warning subsystem?
One can request color start/end manually using %r/%R, plus %, % and %qXXX
color automatically.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dnf] dnf-0.3.6-1
On 05/27/2013 05:57 PM, Christopher Meng wrote: I still cannot see each package's size, they all are 0. What bug is this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dnf] dnf-0.3.6-1
On 05/27/2013 05:44 PM, Rahul Sundaram wrote: Would it be possible to put the bug report titles alongside the bug report themselves? Otherwise, one has to click through every bug report just to summarize what has changed. Thanks! If there's a sphinx plugin to do that let me know. I currently use this: https://github.com/akozumpl/dnf/blob/master/doc/rhbug.py and would have to extend it with bugzilla RPC or copy-paste each title manually. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dnf] dnf-0.3.6-1
On 05/27/2013 02:43 PM, Aleš Kozumplík wrote: If there's a sphinx plugin to do that let me know. I currently use this: https://github.com/akozumpl/dnf/blob/master/doc/rhbug.py and would have to extend it with bugzilla RPC or copy-paste each title manually. Might use python-bugzilla to extend it, I guess Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Seg, 2013-05-27 at 18:17 +0100, Sérgio Basto wrote: Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? I done it http://pkgs.fedoraproject.org/cgit/debconf.git/log/ but now [debconf] Created branch HEAD, we have a a branch called HEAD , can the git administrator of Fedora delete this branch ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On May 27, 2013 11:17 AM, Sérgio Basto ser...@serjux.com wrote: Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? Thanks, -- Sérgio M. B. -- I've been using git checkout $targetbranch; git checkout $sourcebranch -- relative/path/to/file to pull $file from $sourcebranch to $targetbranch. Globbing with * works, too. I have no idea if this is the best approach, but it works for my purposes. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Monday 27 May 2013 18:17:19 Sérgio Basto wrote: I try fedpkg switch-branch f19 git rebase master Git rule #1 -- NEVER rebase a public branch (use git merge) [because rebasing rewrites history] -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19
On Sun, 2013-05-26 at 12:36 -0400, Paul Wouters wrote: On Sun, 24 Feb 2013, Bill Nottingham wrote: Date: Sun, 24 Feb 2013 05:19:43 From: Bill Nottingham nott...@redhat.com To: devel@lists.fedoraproject.org Subject: [ACTION REQUIRED] Retiring packages for Fedora 19 Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. Package openswan (orphan) Removing: openswan NetworkManager-l2tp requires openswan = 2.6.38-11.fc19 NetworkManager-openswan requires openswan = 2.6.38-11.fc19 openswan is deprecated by libreswan in rawhide and Fedora 18. Due to some timing between migration, testing and CVE releases, I was not able to get the libreswan package in f19 before the freeze. But I can also no longer build openswan packages because it has been obsoleted: in rawhide/f18. I guess I should request releng/fesco for an exception to get it into f19 despite the freeze? The libreswan-3.3-1.fc19 build already exists. What freeze are you referring to? I believe the Beta freeze has now been lifted, and Final freeze will not hit until 06-18. I think you could happily submit libreswan-3.3-1.fc19 to updates-testing and eventually to stable right now with no special permissions or privileges. -- 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: [Test-Announce] Fedora 19 Virt Test Day is Tuesday May 28!
On Mon, 2013-05-27 at 12:39 -0400, Cole Robinson wrote:
On 05/27/2013 12:37 PM, Reartes Guillermo wrote:
Hi,
ON: https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization
Fedora 19 on a physical machine
The preferred testing platform is a fully updated Fedora 19 machine. You
have a few options for getting the Fedora 18 bits:
(there is a typo , since it says Fedora 18 bits, should it be 19?)
Install with CD/DVD.
Latest live CD builds ('desktop' is the default):
http://alt.fedoraproject.org/pub/alt/nightly-composes/
Latest 64 Bit DVD:
https://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC4/Fedora/x86_64/iso/
Is there a particular reason to use F19b TC4? Why not using F19b RC4?
Or just point to: https://dl.fedoraproject.org/pub/alt/stage/
and specify 'use latest' and optionally a minimum version aka do not
use an version older than F19b TC4.
I was going to update that to the latest release tonight, just wanted to make
it explicit as possible. But it's just going to get stale as you've pointed
out, so I'll make the link generic as you suggest.
It's unlikely to get 'stale' at this point as Beta RC4 will be released
as Beta, and Final TC1 will not happen for a couple of weeks. Beta
release date is tomorrow, so you could just point to where the Beta will
be - https://fedoraproject.org/get-prerelease - and you should be OK.
I wouldn't recommend using post-Beta nightlies at present, as they'll be
suffering from the root account being locked. I only just committed the
fix for that to spin-kickstarts.
--
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: git rebase master
On Mon, 2013-05-27 at 23:04 +0300, Oron Peled wrote: On Monday 27 May 2013 18:17:19 Sérgio Basto wrote: I try fedpkg switch-branch f19 git rebase master Git rule #1 -- NEVER rebase a public branch (use git merge) [because rebasing rewrites history] The ideal way to do it is to make your changes in 'master' and merge them down to any branches which have not yet diverged from 'master' at all: i.e. as long as your Rawhide and F19 builds are the same, you can just make changes in 'master' and merge them to 'f19'. As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is the actual _point_ of the commands you're using in the intended git workflow. Just because the *content* of two branches is identical does not mean changes can be merged from one to the other with no issues. Merging will only work without issues if the change history of each branch is the same. In practice, you want to look at 'git log' for the two branches and check the commit IDs. If the last few commit IDs differ - even if the content of the commits is the same - you are not going to be able to merge without issues. At any point, if you're not sure what the hell is happening and you're getting error messages, *don't* just whack it with a hammer until it seems to be right, push that, and hope nobody notices; *do* yell for help from someone who really understands git (note: not me) in #fedora-devel or on here. -- 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: Software Management call for RFEs
Well, another thought is that if some software has a lot of optional dependencies, how to handle them from the view of end-users? Should we list these optionals or add a option for install all with deps? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Locale-Maketext-Gettext] (3 commits) ...Patch properly this time
Summary of changes: cbffe79... Add patch to convert gettext %1 to maketext [_1] (*) 7aca8c2... Add patch to convert gettext %1 to maketext [_1] (*) ce1b54d... Patch properly this time (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken upgrade path(s) detected for: perl-Locale-Maketext-Gettext
On Sat, May 25, 2013 at 10:05:18PM +, build...@fedoraproject.org wrote: f19 f20 (perl-Locale-Maketext-Gettext-1.27-12.fc19 perl-Locale-Maketext-Gettext-1.27-10.fc19) Please fix the(se) issue(s) as soon as possible. Fixed. P pgp7tzMnOLKx0.pgp Description: PGP signature -- 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 ctstream-8 uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for ctstream: 75f8d6545be37d2b358be02e76657758 ctstream-8 -- 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
[ctstream/f18] Version 8 bump
commit 19a4432451b848485ccf73447099ee6aee7ff333
Author: Petr Písař ppi...@redhat.com
Date: Mon May 27 09:53:47 2013 +0200
Version 8 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 98dfc70..8c6b7ee 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/ctstream-6
/ctstream-7
+/ctstream-8
diff --git a/ctstream.spec b/ctstream.spec
index 0e07605..9f3693b 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:7
+Version:8
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Mon May 27 2013 Petr Pisar ppi...@redhat.com - 8-1
+- Version 8 bump
+
* Thu May 16 2013 Petr Pisar ppi...@redhat.com - 7-1
- Version 7 bump
diff --git a/sources b/sources
index 48fb367..a27e3dc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-526c02f0b453fd901c41c1293f435921 ctstream-7
+75f8d6545be37d2b358be02e76657758 ctstream-8
--
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
[ctstream/f17] Version 8 bump
commit d6b7863ba9ab5b7b73800b9d3f02c2c0a23fc81b
Author: Petr Písař ppi...@redhat.com
Date: Mon May 27 09:53:47 2013 +0200
Version 8 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 98dfc70..8c6b7ee 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/ctstream-6
/ctstream-7
+/ctstream-8
diff --git a/ctstream.spec b/ctstream.spec
index 0e07605..9f3693b 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:7
+Version:8
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Mon May 27 2013 Petr Pisar ppi...@redhat.com - 8-1
+- Version 8 bump
+
* Thu May 16 2013 Petr Pisar ppi...@redhat.com - 7-1
- Version 7 bump
diff --git a/sources b/sources
index 48fb367..a27e3dc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-526c02f0b453fd901c41c1293f435921 ctstream-7
+75f8d6545be37d2b358be02e76657758 ctstream-8
--
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 967455] New: Upgrade Graph-Easy to 0.73
https://bugzilla.redhat.com/show_bug.cgi?id=967455 Bug ID: 967455 Summary: Upgrade Graph-Easy to 0.73 Product: Fedora Version: rawhide Component: perl-Graph-Easy Severity: unspecified Priority: unspecified Assignee: iarn...@gmail.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org Hello, I'd like to ask you to upgrade perl-Graph-Easy at least to version 0.73 in rawhide because this version fixes tests to pass them with perl 5.18.0. -- 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=NPjtydhmH7a=cc_unsubscribe -- 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 965604] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=965604 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Directory-Queue-1.8-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.8-2.el5 -- 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=PWKEPfEnCka=cc_unsubscribe -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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 Compress-Raw-Bzip2-2.061.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Compress-Raw-Bzip2: 44648bb83e8ec7189afc531ba32143be Compress-Raw-Bzip2-2.061.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-Compress-Raw-Bzip2] Created tag perl-Compress-Raw-Bzip2-2.061-1.fc20
The lightweight tag 'perl-Compress-Raw-Bzip2-2.061-1.fc20' was created pointing to: 02dcd48... Update to 2.061 -- 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 Compress-Raw-Lzma-2.061.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Compress-Raw-Lzma: 1a8c411d2b949729b2bd63e1b812e0a0 Compress-Raw-Lzma-2.061.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-Compress-Raw-Lzma] Update to 2.061
commit 1fefe20b3bf2a5f757ef1f8fa847ab9139d09003
Author: Paul Howarth p...@city-fan.org
Date: Mon May 27 16:07:03 2013 +0100
Update to 2.061
- New upstream release 2.061
- Silence compiler warning by making 2nd parameter to DispStream a const
char*
perl-Compress-Raw-Lzma.spec |8 ++--
sources |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/perl-Compress-Raw-Lzma.spec b/perl-Compress-Raw-Lzma.spec
index ecc82bc..d4a23d8 100644
--- a/perl-Compress-Raw-Lzma.spec
+++ b/perl-Compress-Raw-Lzma.spec
@@ -1,6 +1,6 @@
Name: perl-Compress-Raw-Lzma
-Version: 2.060
-Release: 2%{?dist}
+Version: 2.061
+Release: 1%{?dist}
Summary: Low-level interface to lzma compression library
Group: Development/Libraries
License: GPL+ or Artistic
@@ -52,6 +52,10 @@ make test
%{_mandir}/man3/Compress::Raw::Lzma.3pm*
%changelog
+* Mon May 27 2013 Paul Howarth p...@city-fan.org - 2.061-1
+- Update to 2.061
+ - Silence compiler warning by making 2nd parameter to DispStream a const
char*
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.060-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 5bd3b89..f16fa55 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6348955bb7da43d2ac17f98d45a5338f Compress-Raw-Lzma-2.060.tar.gz
+1a8c411d2b949729b2bd63e1b812e0a0 Compress-Raw-Lzma-2.061.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-Compress-Raw-Zlib] Created tag perl-Compress-Raw-Zlib-2.061-1.fc20
The lightweight tag 'perl-Compress-Raw-Zlib-2.061-1.fc20' was created pointing to: dffc9bf... Update to 2.061 -- 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-Compress-Raw-Lzma] Created tag perl-Compress-Raw-Lzma-2.061-1.fc20
The lightweight tag 'perl-Compress-Raw-Lzma-2.061-1.fc20' was created pointing to: 1fefe20... Update to 2.061 -- 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 IO-Compress-Lzma-2.061.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Compress-Lzma: ee2a1021e12339c410dd6bf44de9ef58 IO-Compress-Lzma-2.061.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-IO-Compress] Created tag perl-IO-Compress-2.061-1.fc20
The lightweight tag 'perl-IO-Compress-2.061-1.fc20' was created pointing to: 178cbb2... Update to 2.061 -- 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-IO-Compress-Lzma] Update to 2.061
commit e7f0c6b2edcf28addf0dd8f56b66e1f05ca285e5
Author: Paul Howarth p...@city-fan.org
Date: Mon May 27 18:28:31 2013 +0100
Update to 2.061
- New upstream release 2.061
- Fix IO::Uncompress::UnXz v2.060 memLimit option bug (CPAN RT#84966)
perl-IO-Compress-Lzma.spec |8 ++--
sources|2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/perl-IO-Compress-Lzma.spec b/perl-IO-Compress-Lzma.spec
index d83c388..2757eb8 100644
--- a/perl-IO-Compress-Lzma.spec
+++ b/perl-IO-Compress-Lzma.spec
@@ -1,6 +1,6 @@
Name: perl-IO-Compress-Lzma
-Version: 2.060
-Release: 2%{?dist}
+Version: 2.061
+Release: 1%{?dist}
Summary: Read and write lzma compressed data
License: GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,10 @@ make test
%{_mandir}/man3/IO::Uncompress::UnXz.3pm*
%changelog
+* Mon May 27 2013 Paul Howarth p...@city-fan.org - 2.061-1
+- Update to 2.061
+ - Fix IO::Uncompress::UnXz v2.060 memLimit option bug (CPAN RT#84966)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.060-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index fc78d6a..8aa60d8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-91f47196da14c39e65799168cfe82532 IO-Compress-Lzma-2.060.tar.gz
+ee2a1021e12339c410dd6bf44de9ef58 IO-Compress-Lzma-2.061.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-IO-Compress-Lzma] Created tag perl-IO-Compress-Lzma-2.061-1.fc20
The lightweight tag 'perl-IO-Compress-Lzma-2.061-1.fc20' was created pointing to: e7f0c6b... Update to 2.061 -- 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 967463] New: perl-5.18: SvTRUE returns wrong value
https://bugzilla.redhat.com/show_bug.cgi?id=967463 Bug ID: 967463 Summary: perl-5.18: SvTRUE returns wrong value Product: Fedora Version: rawhide Component: perl Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rc040...@freenet.de, tcall...@redhat.com There is a regression in SvTRUE macro. Expected value is: $ perl -MScalar::Util=dualvar -le 'print $]; $a = dualvar 1, ; print $a ? true : false;' 5.016003 false This is broken in 5.18.0 and fixed with upstream commit: commit 762dbf22cb22645771fc27b5d197fd40cbbd9da8 Author: Father Chrysostomos spr...@cpan.org Date: Sat May 25 23:59:45 2013 -0700 [perl #118159] Make PVs take precedence in SvTRUE Commit 4bac9ae4 (probably inadvertently) changed SvTRUE to treat an SV with any of PVX, IVX or NVX having a true value as true. Traditionally, truth was based solely on stringification. The examina- tion of the SvIVX and SvNVX slots was for those cases where there was no string already and it could be deduced from IVX or NVX whether it would stringify as 0 or no (bugs with -0 aside). This changes things back to the way they have ‘always’ been. -- 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=bZ5qSdV9OFa=cc_unsubscribe -- 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 965604] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=965604 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Directory-Queue-1.8-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.8-2.fc19 -- 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=oCfDPGFAzGa=cc_unsubscribe -- 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 965604] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=965604 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Directory-Queue-1.8-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.8-2.fc17 -- 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=6ZsZ6riYhBa=cc_unsubscribe -- 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 Plack-Middleware-Deflater-0.09.tar.gz uploaded to lookaside cache by cheeselee
A file has been added to the lookaside cache for perl-Plack-Middleware-Deflater: 80fddf907354f311c6272484c4352a37 Plack-Middleware-Deflater-0.09.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-Plack-Middleware-Deflater] Update to 0.09
commit 95adb8b5bed7366d1a20bfb7945a6d977de3697c
Author: Robin Lee cheese...@fedoraproject.org
Date: Tue May 28 10:49:18 2013 +0800
Update to 0.09
.gitignore |1 +
perl-Plack-Middleware-Deflater.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2b5d016..b2d16e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Plack-Middleware-Deflater-0.08.tar.gz
+/Plack-Middleware-Deflater-0.09.tar.gz
diff --git a/perl-Plack-Middleware-Deflater.spec
b/perl-Plack-Middleware-Deflater.spec
index 8d85d01..4d35ec5 100644
--- a/perl-Plack-Middleware-Deflater.spec
+++ b/perl-Plack-Middleware-Deflater.spec
@@ -1,6 +1,6 @@
Name: perl-Plack-Middleware-Deflater
-Version:0.08
-Release:2%{?dist}
+Version:0.09
+Release:1%{?dist}
Summary:Compress response body with Gzip or Deflate
License:GPL+ or Artistic
Group: Development/Libraries
@@ -81,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Robin Lee cheese...@fedoraproject.org - 0.09-1
+- Update to 0.09
+
* Wed May 15 2013 Robin Lee cheese...@fedoraproject.org - 0.08-2
- BuildRequires more Perl modules: parent, Plack::Middleware, Plack::Util,
Plack::Util::Accessor, File::Spec, Spiffy, Test::Base::Filter,
diff --git a/sources b/sources
index e60b6a6..f40488e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-44855c8ea51fcc8bd776b2352765d4c2 Plack-Middleware-Deflater-0.08.tar.gz
+80fddf907354f311c6272484c4352a37 Plack-Middleware-Deflater-0.09.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-Devel-Size/f19] Update to 0.79
Summary of changes: d66b827... Update to 0.79 (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962317] perl-Devel-Size-0.79 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962317 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Devel-Size-0.79-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Devel-Size-0.79-1.fc19 -- 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=1hPpirK1DNa=cc_unsubscribe -- 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
