Re: Software Management call for RFEs
On 27. 5. 2013 at 10:31:29, Reindl Harald wrote: Am 27.05.2013 09:32, schrieb Jan Zelený: 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 what does keep old versions or not change besides you need to do apt-get update if you want to find apt-get upgrade to find new packages? Something like that, yes. If you don't update your metadata you won't get updates but installation will still work, even if the installed version is not the latest available. the real problem is that the metadata are *way too fat* in Fedora That's not the real problem. It's just one of the problems which in combination cause this pain. after a yum clean metadata yum update on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are updated in reality hey on my 100 Mbit all is nice and fine but on a machine behind DSL with around 100 KB/Second it is way too slow and large and i refuse to imagine how this feels on a 56kbit modem I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/22/2013 05:47 PM, Paulo César Pereira de Andrade wrote: As a packager, some way to transparently handle an upgrade when a directory changes to a symlink or vice-versa. +1 -- Miroslav Suchy Red Hat Systems Management Engineering -- 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: 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. Actually we can do something. Have diffs on metadata. Let imagine that yesterday I done full upgrade. Today PackageKit is saying that I have one package for upgrade. Avarage package has 800kB. Because of those few kB I have to download all those metadata again. On my machine it is 28 MB (!). But the diff on those metadata is actually just few kB. We have presto plugin for diffing rpm packages, but I would actually save more time and more bandwidth if we would have diff on metadatas. -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
quota license corrected
Hello, while reviewing quota sources, I found the (BSD and GPLv2+) license declared in RPM package is not sufficient. There are source files with different licenses making resulting package (BSD and LGPLv2+ and GPLv2 and GPLv2+). Thus some binary files are effectively GPLv2-only in contrast to previous RPM license tag. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
Il 27/05/2013 23:11, Adam Williamson ha scritto: 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. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Hash-MultiValue] Update to 0.14
commit 078048fe9155d9d5a0fe8525983fd6c1e3a356a3
Author: Robin Lee cheese...@fedoraproject.org
Date: Tue May 28 17:30:47 2013 +0800
Update to 0.14
- Use Build.PL
- BR: perl(Test::Pod), perl(Module::Build::Tiny)
.gitignore|1 +
perl-Hash-MultiValue.spec | 21 ++---
sources |2 +-
3 files changed, 16 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 972d8a4..49efeba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Hash-MultiValue-0.08.tar.gz
/Hash-MultiValue-0.10.tar.gz
/Hash-MultiValue-0.12.tar.gz
/Hash-MultiValue-0.13.tar.gz
+/Hash-MultiValue-0.14.tar.gz
diff --git a/perl-Hash-MultiValue.spec b/perl-Hash-MultiValue.spec
index b1bc3f8..54adbce 100644
--- a/perl-Hash-MultiValue.spec
+++ b/perl-Hash-MultiValue.spec
@@ -1,7 +1,7 @@
Name: perl-Hash-MultiValue
Summary:Store multiple values per key
-Version:0.13
-Release:2%{?dist}
+Version:0.14
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/Hash-MultiValue-%{version}.tar.gz
@@ -10,9 +10,11 @@ BuildRoot:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl = 1:5.8.1
+BuildRequires: perl(Module::Build::Tiny) = 0.019
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod) = 1.41
BuildRequires: perl(UNIVERSAL::ref)
@@ -27,20 +29,20 @@ contain multiple values per key.
%setup -q -n Hash-MultiValue-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
+perl Build.PL --installdirs vendor
+./Build
%install
rm -rf %{buildroot}
-make pure_install DESTDIR=%{buildroot}
+./Build install --destdir %{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
-make test
+./Build test
%clean
@@ -53,6 +55,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Tue May 28 2013 Robin Lee cheese...@fedoraproject.org - 0.14-1
+- Update to 0.14
+- Use Build.PL
+- BR: perl(Test::Pod), perl(Module::Build::Tiny)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.13-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 43eb64f..5598cec 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f8c7ade4955374ad52e5a743f0812724 Hash-MultiValue-0.13.tar.gz
+38e63bcdc224ee25a098085190ccc291 Hash-MultiValue-0.14.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: git rebase master
On 05/28/2013 11:30 AM, Paolo Bonzini wrote: Il 27/05/2013 23:11, Adam Williamson ha scritto: 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. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). That's because there's little support in VCS for backporting. The VCS doesn't know if the new development in master is part of the fix, or unrelated new development. The only system I've ever used which had some support for this was darcs, but more often than not, I had unintentional patch dependencies on new development I didn't want to backport, so it didn't work out that well. The forward-porting approach has the risk that it stops before reaching master, so users will encounter regressions when updating. And both approaches do not really mix that well because merging from the stable branch with cherry-picked and massages backports tends to conflict a lot. Better tool support for backporting and the more general issue of patch stacks (like we have in RPM and Debian packages) is very desirable, but it's a really difficult problem. -- 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 28. 5. 2013 at 11:39:35, Alek Paunov wrote: On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... Perhaps it's just that I don't fully understand your vision but I'm not sure that's a feasible solution. How exactly would you solve the fact that users have different repos enabled on their machines? Or did you mean merging them on the client side? That would not solve the issue of data download. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. I.e. If you run yum install foo and it will install packages bar and bra for dependencies. Then when I remove package foo, those two packages will be left on my system. dnf autoremove should tell me that packages bar and bra were installed as dependencies for package, which is no more present on disk (and no other package requires them) and can be removed. -- Miroslav Suchy Red Hat Systems Management Engineering -- 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 03:24 PM, Ales Kozumplik wrote: Hi, There's a new build of DNF for Fedora rawhide and F19's updates-testing[1] today. 0.3.6 is almost only a bugfix release, but note that F19 users didn't get 0.3.5 so there's more changes happening there. Also see the release notes[2]. In past dnf had problem upgrading kernel, so I always upgraded kernel using yum and rest of system using dnf. I know that recently you fixed two bugs related to upgrading kernel. But is it all? Can I now trust dnf even for kernel upgrades? Or there is still some work to be done? -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. That's what yum-plugin-remove-with-leaves does. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dnf] dnf-0.3.6-1
On 05/28/2013 01:19 PM, Miroslav Suchý wrote: In past dnf had problem upgrading kernel, so I always upgraded kernel using yum and rest of system using dnf. I know that recently you fixed two bugs related to upgrading kernel. But is it all? Can I now trust dnf even for kernel upgrades? Or there is still some work to be done? I fixed a bug where 'dnf upgrade' didn't do anything to the kernels, even if new ones were available [1]. This works fine now, upgrading all packages finds and installs the latest available kernel while keeping your running kernel intact. Then there's respecting the total number of all kernels installed [2], which still needs work in both libsolv and DNF, but that should be happening soon. Lastly the distro-sync command doesn't apparently do the right thing [3]. No estimates there. Ales [1] https://bugzilla.redhat.com/show_bug.cgi?id=905209 [2] https://bugzilla.redhat.com/show_bug.cgi?id=880524 [3] https://bugzilla.redhat.com/show_bug.cgi?id=912165 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sharutils license correction
I've corrected license declaration at sharutils package: - GPLv3+ and LGPLv2+ and Public Domain + GPLv3+ and LGPLv3+ and (LGPLv3+ or BSD) and LGPLv2+ and Public Domain and GFDL The only effective difference is the texinfo documentation is covered by GFDL instead of GPL. The (LGPLv3+ or BSD) clause is because of bundled libopts that I will try to unbundle or negotitate with FPC. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 967825] New: perl-Module-Pluggable-4.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967825 Bug ID: 967825 Summary: perl-Module-Pluggable-4.8 is available Product: Fedora Version: rawhide Component: perl-Module-Pluggable Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 4.8 Current version in Fedora Rawhide: 4.7 URL: http://search.cpan.org/dist/Module-Pluggable/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=GlyXhNJls4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 967828] New: perl-POE-Component-IRC-6.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967828 Bug ID: 967828 Summary: perl-POE-Component-IRC-6.83 is available Product: Fedora Version: rawhide Component: perl-POE-Component-IRC Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 6.83 Current version in Fedora Rawhide: 6.82 URL: http://search.cpan.org/dist/POE-Component-IRC/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=f9BwHVYOUSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Software Management call for RFEs
On 28.05.2013 13:54, Jan Zelený wrote: On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... Perhaps it's just that I don't fully understand your vision but I'm not sure that's a feasible solution. How exactly would you solve the fact that users have different repos enabled on their machines? Or did you mean merging them on the client side? That would not solve the issue of data download. Oh sorry. On the client side of course - these which are under the /var/cache/yum tree. My question was more targeted on the complains about 1) metadata local size, 2) speed and 3) capabilities of the local yum queries. [Furthermore you currently reformulating Package Management as Software Lifecycle Management, so it would be normal for me to expect that the data backend will have to be enhanced accordingly. Or will libsolv stores be enough for all?] Regarding the metadata download speedup, I completely agree with Florian and others on the thread, that current bulk downloads should be replaced with XML only downloads and incremental update of the local DB as a first step and introducing *optional* metadata services (just XML git or something smarter) for the mirrors which are willing to upgrade. Thank you, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/28/2013 06:25 AM, Mathieu Bridon wrote: On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. That's what yum-plugin-remove-with-leaves does. Almost, but not quite (it must be done when you remove the package, can't be done after). The clean_requirements_on_remove=1 setting is also helpful, like 'autoremove' after each 'remove'. Still can't be done after-the-fact, but is nice (and more accurate, AFAIK, since it uses the yumdb 'reason' tag). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Am 28.05.2013 13:14, schrieb Miroslav Suchý: On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. I.e. If you run yum install foo and it will install packages bar and bra for dependencies. Then when I remove package foo, those two packages will be left on my system not on mine, the only big question is why it is not default cat /etc/yum.conf | grep clean clean_requirements_on_remove=1 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130528 changes
Compose started at Tue May 28 08:15:02 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 [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 [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] 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]
F-19 Branched report: 20130528 changes
Compose started at Tue May 28 09:15:02 UTC 2013 Broken deps for x86_64 -- [bochs] bochs-2.6.1-1.fc19.x86_64 requires vgabios [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.x86_64 requires libvirt-qmf [gcc-python-plugin] gcc-python2-debug-plugin-0.12-1.fc19.x86_64 requires gcc = 0:4.8.0-2.fc19 gcc-python2-plugin-0.12-1.fc19.x86_64 requires gcc = 0:4.8.0-2.fc19 gcc-python3-debug-plugin-0.12-1.fc19.x86_64 requires gcc = 0:4.8.0-2.fc19 gcc-python3-plugin-0.12-1.fc19.x86_64 requires gcc = 0:4.8.0-2.fc19 [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.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [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-docs] python-docs-2.7.4-1.fc19.noarch requires python = 0:2.7.4 [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) [zarafa] 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 Broken deps for i386 -- [bochs] bochs-2.6.1-1.fc19.i686 requires vgabios [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.i686 requires libvirt-qmf [gcc-python-plugin] gcc-python2-debug-plugin-0.12-1.fc19.i686 requires gcc = 0:4.8.0-2.fc19 gcc-python2-plugin-0.12-1.fc19.i686 requires gcc = 0:4.8.0-2.fc19 gcc-python3-debug-plugin-0.12-1.fc19.i686 requires gcc = 0:4.8.0-2.fc19 gcc-python3-plugin-0.12-1.fc19.i686 requires gcc = 0:4.8.0-2.fc19 [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.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-kolab-0.4.1-3.fc19.i686 requires php(api) = 0:20100412-x86-32 [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-docs] python-docs-2.7.4-1.fc19.noarch requires python = 0:2.7.4 [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) [zarafa] php-mapi-7.0.13-1.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-mapi-7.0.13-1.fc19.i686 requires php(api) = 0:20100412-x86-32 New package: aggregate-1.6-3.fc19 IPv4 CIDR prefix aggregator New package: brise-0.22-2.fc19 The official Rime schema repository New
Re: Software Management call for RFEs
On 05/28/2013 01:14 PM, Miroslav Suchý wrote: dnf autoremove should tell me that packages bar and bra were installed as dependencies for package, which is no more present on disk (and no other package requires them) and can be removed. There's an RFE for this already: https://bugzilla.redhat.com/show_bug.cgi?id=963345 Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
This is basically the major impediment to the uninstall of a product that consists of several packages. Some of these packages may be, at time of uninstall, also required by other packages, so the and no other package requires them part is essential. --Fernando - Original Message - From: Ales Kozumplik akozu...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, May 28, 2013 9:27:23 AM Subject: Re: Software Management call for RFEs On 05/28/2013 01:14 PM, Miroslav Suchý wrote: dnf autoremove should tell me that packages bar and bra were installed as dependencies for package, which is no more present on disk (and no other package requires them) and can be removed. There's an RFE for this already: https://bugzilla.redhat.com/show_bug.cgi?id=963345 Ales -- 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
Announcing the release of Fedora 19 Beta.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've opened the box for the Fedora 19 Schrödinger's Cat beta release and confirmed it's alive! Ready to purr at the latest free and open source technology? Download it now: http://fedoraproject.org/get-prerelease What is the Beta release? The Beta release is the last important milestone before the release of Fedora 19. Only critical bug fixes will be pushed as updates, leading up to the general release of Fedora 19. Join us in making Fedora 19 a solid release by downloading, testing, and providing your valuable feedback. Of course, this is a beta release, meaning that some problems may still be lurking. A list of the problems we already know about is found at the Common F19 bugs page, seen here: http://fedoraproject.org/wiki/Common_F19_bugs Fedora 19 Beta's default configuration allows applications and users with administrative privileges to install signed packages from the official Fedora repositories (but no other packages) without authentication or confirmation. This was inherited from PackageKit upstream, is not Fedora's intended behavior, and will not be the case for the Fedora 19 final release. More details on this issue and the planned behavior for the final release can be found at https://fedorahosted.org/fesco/ticket/1115 . Features Fedora 19 continues our long tradition of bringing the latest technologies to open source software users. No matter what you do with open source, Fedora 19 has the tools you need to help you get things done. A complete list with details of each new feature is available here: http://fedoraproject.org/wiki/Releases/19/FeatureList === Make new things === Would you like to play? Whether you're a developer, maker, or just starting to learn about open source development, we have what you need to bring your ideas to reality. Here's a peek at some of our new tools: * 3D modelling and printing are enabled through a variety of tools, including OpenSCAD, Skeinforge, SFACT, Printrun, and RepetierHost. By bringing 3D printing tools into Fedora, you can get started with what's ready-to-go in the repositories without having to download binary blobs or run Python code from git. * OpenShift Origin makes it easy for you to build your own Platform-as-a-Service (PaaS) infrastructure, allowing you to enable others to easily develop and deploy software. * node.js is a popular Javascript-based platform for those building scalable network applications or real-time apps across distributed devices. Also included is the npm package manager, providing access to over 20,000 programs and libraries available under free and open source licenses. * Ruby 2.0.0, just released in February, comes to Fedora while maintaining source-level backwards compatibility with your Ruby 1.9.3 software. Also included: a custom Ruby loader for easy switching of interpreters. * MariaDB, a community-developed fork of MySQL, is the default implementation of MySQL in Fedora 19, offering users a truly open MySQL implementation. === Get things done === * Federated VOIP means Fedora users can make calls using a user@domain address with the same convenience as email. * CUPS has been updated to the latest upstream release, using PDF rather than PostScript as the baseline document format. === Learn === * Developer's Assistant is great for those new to development or even new to Linux, this tool helps you to get started on a code project with templates, samples, and toolchains for the languages of your choice. Bonus: It lets you publish directly to GitHub. === Deploy, Monitor, and Manage === Make your machines work for you--not the other way around. Whether you have one or one too many machines, Fedora 19 helps you boot manage your systems and enables you to be proactive with tools for diagnosis, monitoring, and logging. * Syslinux optional boot tool integration brings you optional, simplified booting of Fedora. We have added support for using syslinux instead of GRUB via kickstart and plan to add a hidden option in Anaconda installer as well. syslinux is especially ideal for images used in cloud environments and virt appliances where the advanced features of GRUB are not needed. * Among other systemd enhancements in this release, systemd Resource Control lets you modify your service settings without a reboot by dynamically querying and modifying resource control parameters at runtime. * Kerberos administrators will enjoy an easier experience, thanks to Fedora 19 removing the need for Kerberos clients to sync their clocks or to have reverse DNS records carefully setup for services. In addition, it provies Kerberos-enabled, LDAP replicated, two-factor authentication for FreeIPA. * OpenLMI is a common infrastructure for the management of Linux systems that makes remote management of machines much simpler. Desktop Environments and Spins === GNOME 3.8
Re: Software Management call for RFEs
On 05/24/2013 09:20 PM, 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/ Rahul The one weird bug (dnf remove wants to install new packages) mentioned by the article just got fixed: https://bugzilla.redhat.com/show_bug.cgi?id=916662 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 09:14 PM, Rahul Sundaram wrote: Might use python-bugzilla to extend it, I guess The speed of bugzilla.redhat.com is prohibiting, the following takes 3 seconds on my machine: #! /usr/bin/python2.7 import bugzilla rhbz = bugzilla.RHBugzilla(url=https://bugzilla.redhat.com/xmlrpc.cgi;) q = rhbz.build_query(bug_id=880524) b = rhbz.query(q)[0] print(b.summary) That would slow the build down by 5 minutes for 100 bugs and go up with each release. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing folders with symlinks (pre vs pretrans)
Quoting Panu Matilainen (2012-09-21 10:17:27)
A directory (empty or not) can't be automatically replaced by anything
else (symlink or otherwise) in the existing rpm versions. If absolutely
necessary, it can be accomplished by doing the necessary renames and
symlinks in %pretrans -p lua scriptlet, but that should be only seen
as the last resort as its not exactly a safe operation.
This used to work in %pre scriptlet as well. It seems like RPM is now doing some
additional checks and it will not even get to the point of %pre scriptlet. As
far as I can see for F17/F18 %pre scriptlet will work, but F19+ %pretrans has to
be used, correct?
Since I *knew* we used %pre for this exact problem before, I have used it and
it broke upgrade paths[1]. I assume just rewriting %pre[2] into following
%pretrans will work:
for key, dir in pairs({boot, conf}) do
path = %{_datadir}/%{name}/ .. dir
if posix.readlink(path) then
os.remove(path)
end
end:
It certainly seemed to work now, but I wonder if I am just missing something
else.
[1] https://admin.fedoraproject.org/updates/FEDORA-2013-9207/xmvn-0.5.0-2.fc19
[2] http://pkgs.fedoraproject.org/cgit/xmvn.git/tree/xmvn.spec#n117
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený jzel...@redhat.com wrote: after a yum clean metadata yum update on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are updated in reality hey on my 100 Mbit all is nice and fine but on a machine behind DSL with around 100 KB/Second it is way too slow and large and i refuse to imagine how this feels on a 56kbit modem I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Jan, the above is not correct. Files in *bin/* are in the primary metadata - not in the filelists. That was specifically designed to handle the 90% of file-deps which are *bin/* or /etc/*. It's not accidental. so if you nuked filelists entirely you'd only lose people who have filedeps on something outside of those wildcards above. I've spent HERCULEAN amounts of effort to whittle down the set of filedeps outside of that area. I filed hundreds of bugs on the subject in years passed. I simply got tired of tilting at that particular windmill when confronted with some particularly egregious cases (see libguestfs sometime). But it is absolutely NOT TRUE that removing filelists will cause 'yum install /usr/bin/vim' to not work. If you have further questions about how the metadata works or was designed please feel free to ask me, directly. I believe I and Adrian Likins are the only current Red Hat Employees or Fedora Contributors who were present/involved in its original 'design'. Such as it was. It might prove helpful to know that background to avoid walking down blindalleys in DNF. Thanks! -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taskbot and Automation
Am Dienstag, den 28.05.2013, 07:49 -0600 schrieb Tim Flink: - do some investigation to be somewhat sure that we're not ignoring existing tools (autotest is first on my list, beaker is probably worth exploring a bit) This comparison will not be easy, the tools are large with lots of features. It might be beneficial to include their developers (e.g. lmr from autotest) in the discussions what we need and what the tools can offer. We have a lot of experience with autotest, but I somewhat expect that there are many more features that we haven't even tried to discover. Yeah, I have no illusions that the comparison will be straight forward. The systems have very little in common outside of being written in python and the fact that from a high level, they both execute jobs. I suspect that a lot of it is going to come down to how much we want flexibility. Autotest is by far more featureful than buildbot from a test execution perspective - it already has a test running system, it already has concepts of more complicated results and supports jobs on remote and multiple remote systems (probably more, those are the ones that come to mind right away). At the moment, I think buildbot is a better fit for the idea of a loosely coupled system of components joined by json and rest but creating such a system will likely require more initial work to fill some gaps in functionality. Hey, I'm Fabian and writing to this list for the first time! I'm currently working on oVirt (Node) (sub-)project which is a slimmed down Fedora (or CentOS). Part of my $dayjob is to bring some test automation to oVirt Node. After this short introduction let me drop my two words. First I'd say that the clean separation between the different actors is future proof. I also agree on the roles of actors themselves and how they interact. But as said elsewhere - the devil is in the details. Now the last paragraph and tools. In the oVirt Node we are using gerrit, jenkins and igor [0]. Igor is the component which picks up an ISO and assigns it to some machine (real or virtual, freshly created or existing one). Igor is then offering a testsuite to client which can pull it and performing a number of steps (testcases) on the host and reports them back to Igor. That's the basic procedure [1]. Igor was designed to work in par with Jenkins, that means - like in your idea - it is designed to push the results of the runs to some remote result-bin. I'm just mentioning Igor here because I believe that it solves some of the problems that you'll be facing (in particular setting up and preparing a real machine and running a number of steps on it) - so - IIUIC - best matching the role of an Executor. But I suppose a new thread - as you suggested - is the best place to discuss the tools. Greetings fabian [0] https://gitorious.org/ovirt/igord [1] http://dummdida.tumblr.com/post/51492048387/testing-ovirt-node-in-4min-video ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Software Management call for RFEs
On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. Try yum autoremove in F19. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing folders with symlinks (pre vs pretrans)
On 05/28/2013 06:50 PM, Stanislav Ochotnicky wrote:
Quoting Panu Matilainen (2012-09-21 10:17:27)
A directory (empty or not) can't be automatically replaced by anything
else (symlink or otherwise) in the existing rpm versions. If absolutely
necessary, it can be accomplished by doing the necessary renames and
symlinks in %pretrans -p lua scriptlet, but that should be only seen
as the last resort as its not exactly a safe operation.
This used to work in %pre scriptlet as well. It seems like RPM is now doing some
additional checks and it will not even get to the point of %pre scriptlet. As
far as I can see for F17/F18 %pre scriptlet will work, but F19+ %pretrans has to
be used, correct?
%pre was never correct for the task because it means rpm wont know about
the change, which can cause side-effects like files from the new package
removed on cleanup of the older package, junk left behind etc. What
exactly happens depends on the details.
And yes, rpm = 4.11 enforces use of %pretrans for the purpose as it
detects the issue early on, whereas older versions just merrily go ahead
and likely ends up making a mess during the transaction.
Since I *knew* we used %pre for this exact problem before, I have used it and
it broke upgrade paths[1]. I assume just rewriting %pre[2] into following
%pretrans will work:
for key, dir in pairs({boot, conf}) do
path = %{_datadir}/%{name}/ .. dir
if posix.readlink(path) then
os.remove(path)
end
end:
It certainly seemed to work now, but I wonder if I am just missing something
else.
Yup, something like that.
- Panu -
[1] https://admin.fedoraproject.org/updates/FEDORA-2013-9207/xmvn-0.5.0-2.fc19
[2] http://pkgs.fedoraproject.org/cgit/xmvn.git/tree/xmvn.spec#n117
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 966926] perl-Plack-Middleware-Deflater-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=966926 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Plack-Middleware-Deflater-0.09-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Plack-Middleware-Deflater-0.09-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9483/perl-Plack-Middleware-Deflater-0.09-1.fc19 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BZAviMMsk9a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora 19 Beta for ARM Available Now!
The Fedora ARM team is pleased to announce the Fedora 19 Beta for ARM is now available for download from: https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/19-Beta/Images/armhfp/ This marks the last significant milestone before reaching the final release of Fedora 19 for ARM, with only critical bug fixes being added as updates to make this our most solid release to date. This marks the first time the Fedora ARM team will be releasing the F19 Beta alongside Primary Architectures. The Fedora 19 Beta for ARM includes two pre-built images - one for use with the Pandaboard and Pandaboard ES which require special partitioning, the second will support the Trimslice and Versatile Express(QEMU). The Beta for ARM also includes an installation tree in the yum repository which may be used to PXE-boot a kickstart-based installation on systems that support this option, such as the Calxeda EnergyCore (HighBank). For additional information including detailed installation instructions, please visit the Fedora 19 Beta for ARM page: http://fedoraproject.org/wiki/Architectures/ARM/F19/Beta Join us on the IRC in #fedora-arm on Freenode or send feedback and comments to the ARM mailing list. On behalf of the Fedora ARM team, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dnf] dnf-0.3.6-1
Hi On Tue, May 28, 2013 at 11:42 AM, Ales Kozumplik wrote: That would slow the build down by 5 minutes for 100 bugs and go up with each release. If you store the results, you would only need to get the details of the bugs fixed from the last release. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 18:51, seth vidal wrote: On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený jzel...@redhat.com wrote: after a yum clean metadata yum update on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are updated in reality hey on my 100 Mbit all is nice and fine but on a machine behind DSL with around 100 KB/Second it is way too slow and large and i refuse to imagine how this feels on a 56kbit modem I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Jan, the above is not correct. Files in *bin/* are in the primary metadata - not in the filelists. That was specifically designed to handle the 90% of file-deps which are *bin/* or /etc/*. It's not accidental. so if you nuked filelists entirely you'd only lose people who have filedeps on something outside of those wildcards above. I've spent HERCULEAN amounts of effort to whittle down the set of filedeps outside of that area. I filed hundreds of bugs on the subject in years passed. I simply got tired of tilting at that particular windmill when confronted with some particularly egregious cases (see libguestfs sometime). I just tested on a F18 box the following: yum erase -y datalog yum clean all yum install sqlite-datalog #3 non-existing package yum install -y /usr/bin/datalog In the above sequence, yum do not downloaded the filelists at all. yum erase -y datalog yum clean all yum install sqlite-datalog #3 non-existing package yum install -y /usr/share/lua/5.1/datalog.lua #4 In the second sequence, yum started the filelists downloading at #4. So, it seems that yum already have the filelists on demand optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? If you have further questions about how the metadata works or was designed please feel free to ask me, directly. I believe I and Adrian Likins are the only current Red Hat Employees or Fedora Contributors who were present/involved in its original 'design'. Such as it was. I have a few questions: * What is the reasoning behind the splitting of the database across many .sqlite files? * Why the sql schema is so denormalized (IMO, leads to both bandwidth and disk overspending without speed benefits)?. For example: Why provides and requires tables do not use the common domain table? * Why the incremental update mechanism (eg. applying xml diffs to the sqlite database) was not been considered from the very beginning? Thanks! Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Mon, 27 May 2013 20:41:08 +0100 Sérgio Basto ser...@serjux.com wrote: 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 ? Done. Note that you should next time request this by filing a ticket in releng trac. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Tue, 2013-05-28 at 11:30 +0200, Paolo Bonzini wrote: Il 27/05/2013 23:11, Adam Williamson ha scritto: 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. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). Indeed, AFAICT though, merging down from master is the most common workflow in Fedora packaging git (and more in line with how the Fedora dev process is 'supposed' to work). -- 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
On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov a...@declera.com wrote: So, it seems that yum already have the filelists on demand optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? I'm not. But when you download the filelists - it is A LOT of data. I'd rather not have filedeps so it doesn't get pulled in for other things in depsolving. I have a few questions: * What is the reasoning behind the splitting of the database across many .sqlite files? many? it's 3 afaik. primary, filelists, other. how do you mean 'many? * Why the sql schema is so denormalized (IMO, leads to both bandwidth and disk overspending without speed benefits)?. For example: Why provides and requires tables do not use the common domain table? B/c it was designed 8yrs ago and we were going for compressable space and making it as quick as possible to search? * Why the incremental update mechanism (eg. applying xml diffs to the sqlite database) was not been considered from the very beginning? It wasn't necessary? There was a massively smaller number of pkgs to consider. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Dne Út 28. května 2013 10:11:55, Miroslav Suchý napsal(a): On 05/27/2013 09:32 AM, Jan Zelený wrote: 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. Actually we can do something. Have diffs on metadata. Let imagine that yesterday I done full upgrade. Today PackageKit is saying that I have one package for upgrade. Avarage package has 800kB. Because of those few kB I have to download all those metadata again. On my machine it is 28 MB (!). But the diff on those metadata is actually just few kB. We have presto plugin for diffing rpm packages, but I would actually save more time and more bandwidth if we would have diff on metadatas. We have been working on this for some time now. However there are some other consequent problems that we need to figure out first. There are already some proposals that came up from our last week meeting with Richard Hughes. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Dne Út 28. května 2013 09:33:11, Fernando Nasser napsal(a): This is basically the major impediment to the uninstall of a product that consists of several packages. Some of these packages may be, at time of uninstall, also required by other packages, so the and no other package requires them part is essential. yum repo-pkgs should handle the other situation (other packages require them) as well. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Dne Út 28. května 2013 14:59:20, Alek Paunov napsal(a): On 28.05.2013 13:54, Jan Zelený wrote: On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... Perhaps it's just that I don't fully understand your vision but I'm not sure that's a feasible solution. How exactly would you solve the fact that users have different repos enabled on their machines? Or did you mean merging them on the client side? That would not solve the issue of data download. Oh sorry. On the client side of course - these which are under the /var/cache/yum tree. My question was more targeted on the complains about 1) metadata local size, 2) speed and 3) capabilities of the local yum queries. I'm not sure merging database would help in any of these areas. But then again I can be wrong. If you plan to do the testing, I am very curious about the results. [Furthermore you currently reformulating Package Management as Software Lifecycle Management, so it would be normal for me to expect that the data backend will have to be enhanced accordingly. Or will libsolv stores be enough for all?] This has to be discussed along the way, at this point it is too early to say what will happen to metadata. Regarding the metadata download speedup, I completely agree with Florian and others on the thread, that current bulk downloads should be replaced with XML only downloads and incremental update of the local DB as a first step and introducing *optional* metadata services (just XML git or something smarter) for the mirrors which are willing to upgrade. We are performing some tests and so far it seems that for yum this is not the way to go, as the speed gain would be compensated by the local yum db rebuild. We will continue to work on this but so far it seems that dnf is the way to go so the optimization will most likely happen there. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Dne Út 28. května 2013 11:51:21, seth vidal napsal(a): On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený jzel...@redhat.com wrote: after a yum clean metadata yum update on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are updated in reality hey on my 100 Mbit all is nice and fine but on a machine behind DSL with around 100 KB/Second it is way too slow and large and i refuse to imagine how this feels on a 56kbit modem I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like yum install /usr/bin/vim would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Jan, the above is not correct. Files in *bin/* are in the primary metadata - not in the filelists. That was specifically designed to handle the 90% of file-deps which are *bin/* or /etc/*. It's not accidental. so if you nuked filelists entirely you'd only lose people who have filedeps on something outside of those wildcards above. I've spent HERCULEAN amounts of effort to whittle down the set of filedeps outside of that area. I filed hundreds of bugs on the subject in years passed. I simply got tired of tilting at that particular windmill when confronted with some particularly egregious cases (see libguestfs sometime). But it is absolutely NOT TRUE that removing filelists will cause 'yum install /usr/bin/vim' to not work. If you have further questions about how the metadata works or was designed please feel free to ask me, directly. I believe I and Adrian Likins are the only current Red Hat Employees or Fedora Contributors who were present/involved in its original 'design'. Such as it was. It might prove helpful to know that background to avoid walking down blindalleys in DNF. I knew there were some optimizations in the filelist case, I just wasn't completely sure what exactly would cause downloads of the filelist. Anyway, thanks for the explanation Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On 05/15/2013 02:12 PM, Stanislav Ochotnicky wrote: To play the devil's advocate a bit, if we automate it without requiring announce we end up without any additional info about reasons why package was orphaned. This is a easily solvable problem. pkgdb can just require the maintainer to specify the reason for orphaning and the report can collect that info and post it here There are lots of things we could improve by just making reports more widely available automatically and some requires more tooling and we are doing a fairly poor job currently. 1) review reports - was absent for a long time and is now being done manually 2) e-v-r problems - sporadic reports 3) reports on source url which don't work - havent been done in a llong time afaik and needs to be automated and way to silence them in known cases in a per package way (by checking in a file into the git repo for that package for instance) 4) rpmlint reports could be collected in a central location and per package way to silence irrelevant warnings/errors could be added. refer to debian lintian site for some examples 5) update to new upstream versions in Rawhide - a tool could do bump the spec, do scratch builds automatically of newer versions, if that works ask the maintainer to apply a diff after reviewing the changes. 6) abi bumps could trigger rebuilds as needed automatically by the buildsystem. Several distributions including Mageia, Mandriva, openSUSE has been doing this for ages already 7) spec file changelog vs git changelog could be automated and has been discussed multiple times here and again done by multiple distributions 8) koji web ui needs to be improved significantly or dropped/replaced with something that provides more functionality 9) reports highlighting unfixed security issues 10) https://fedoraproject.org/wiki/Upstream_release_monitoring should ideally be done for *all* packages and maintainers should be able to opt in for notification or see it in a web UI as per their choice 11) automatic period rebuilds in rawhide to highlight FTBFS issues aren't done as often anymore 12) file dependencies can be checked to make sure they are sane I could go on but you get the general idea Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Tue, 2013-05-28 at 14:58 -0400, Rahul Sundaram wrote: 3) reports on source url which don't work - havent been done in a llong time afaik and needs to be automated and way to silence them in known cases in a per package way (by checking in a file into the git repo for that package for instance) I wonder if we could use fedmsg there, and trigger the check on each spec update of the rawhide branch or something like that. [...\ 6) abi bumps could trigger rebuilds as needed automatically by the buildsystem. Several distributions including Mageia, Mandriva, openSUSE has been doing this for ages already Any tooling from them we could use for this? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Tue, 28 May 2013 14:58:35 -0400 Rahul Sundaram methe...@gmail.com wrote: This is a easily solvable problem. pkgdb can just require the maintainer to specify the reason for orphaning and the report can collect that info and post it here There are lots of things we could improve by just making reports more widely available automatically and some requires more tooling and we are doing a fairly poor job currently. 1) review reports - was absent for a long time and is now being done manually This can/will be added as a cron job. 2) e-v-r problems - sporadic reports Should also add this, although, it actually could be a check done in the new wonderful QA setup. 3) reports on source url which don't work - havent been done in a llong time afaik and needs to be automated and way to silence them in known cases in a per package way (by checking in a file into the git repo for that package for instance) I've not done these in a long time yeah... again this could be something for a QA check when a spec file changes. 4) rpmlint reports could be collected in a central location and per package way to silence irrelevant warnings/errors could be added. refer to debian lintian site for some examples QA check on spec change. 5) update to new upstream versions in Rawhide - a tool could do bump the spec, do scratch builds automatically of newer versions, if that works ask the maintainer to apply a diff after reviewing the changes. I suppose. It doesn't seem like it's that hard for a maintainer to notice this and do that if thats all thats involved. 6) abi bumps could trigger rebuilds as needed automatically by the buildsystem. Several distributions including Mageia, Mandriva, openSUSE has been doing this for ages already This would take some work as it needs to have ability to do official builds and checkins and such. 7) spec file changelog vs git changelog could be automated and has been discussed multiple times here and again done by multiple distributions Sure, I don't think it's really a big deal either way personally. 8) koji web ui needs to be improved significantly or dropped/replaced with something that provides more functionality Feel free to help koji upstream out. What items do you see needing in the web ui? 9) reports highlighting unfixed security issues This is a good one, we should do now if there are interested folks. Generate a list of all unfixed CVE bugs. 10) https://fedoraproject.org/wiki/Upstream_release_monitoring should ideally be done for *all* packages and maintainers should be able to opt in for notification or see it in a web UI as per their choice Sure, although it won't work for those places that no longer offer release downloads (github, etc) 11) automatic period rebuilds in rawhide to highlight FTBFS issues aren't done as often anymore Can you expand on this? Not sure what you mean? 12) file dependencies can be checked to make sure they are sane You mean, just that the file exists in repodata? Or? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On 05/28/2013 03:10 PM, Pierre-Yves Chibon wrote: I wonder if we could use fedmsg there, and trigger the check on each spec update of the rawhide branch or something like that. Sure. 6) abi bumps could trigger rebuilds as needed automatically by the buildsystem. Several distributions including Mageia, Mandriva, openSUSE has been doing this for ages already Any tooling from them we could use for this? Most of the distributions have their own custom buildsystem and don't really separate out tooling in this way but they are typically open source Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Tue, May 28, 2013 at 13:17:44 -0600, Kevin Fenzi ke...@scrye.com wrote: On Tue, 28 May 2013 14:58:35 -0400 Rahul Sundaram methe...@gmail.com wrote: 11) automatic period rebuilds in rawhide to highlight FTBFS issues aren't done as often anymore Can you expand on this? Not sure what you mean? This would just be a check to see that packages are still buildable. Rather than do big one shots maybe once a release, it could happen spread out in time. And could skip packages that had been built recently. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On 05/28/2013 03:17 PM, Kevin Fenzi wrote: 5) update to new upstream versions in Rawhide - a tool could do bump the spec, do scratch builds automatically of newer versions, if that works ask the maintainer to apply a diff after reviewing the changes. I suppose. It doesn't seem like it's that hard for a maintainer to notice this and do that if thats all thats involved. It quickly adds up if you are (co-) maintaining dozens of packages which is not atypical in Fedora and it is fairly boring work that could be mostly automated freeing up time to fix bugs or whatever else that is more involved. What items do you see needing in the web ui? I found a number of features in the old Fedora community UI really useful and the only reason I didn't continue using it because of the very slow UI. List of open bugs in all of the packages I maintain, the ability to see which package version is in which release across packages etc (ie) all the package maintainer specific views as opposed to package specific views that is in https://apps.fedoraproject.org/packages/. All of these could be done without the web UI but it is far more convenient to have a single location to get all the info necessary to maintain packages. 11) automatic period rebuilds in rawhide to highlight FTBFS issues aren't done as often anymore Can you expand on this? Not sure what you mean? What Matt Domsch was doing for https://fedoraproject.org/wiki/Fails_to_build_from_source You mean, just that the file exists in repodata? Or? Make sure we are not abusing file dependencies when we could be depending on the packages directly. Essentially a way to ensure we are following https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#File_Dependencies Oh and one more thing, some process to keep track of un-upstreamed patches and making sure we do that on a regular basis will be useful. I have seen several packages in Fedora git which have unapplied patches still in the repo and that could be automatically checked and removed as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 21:18, seth vidal wrote: On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov a...@declera.com wrote: So, it seems that yum already have the filelists on demand optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? I'm not. But when you download the filelists - it is A LOT of data. It is of course :-). It is big and slow now, but it implements one more distinguishing and convenient Fedora feature ... and under careful schema and encoding, can be scaled down several times in both space and query time. Actually, every positive (install, update) yum operation implies access to the repos. Repos contain everything. If our software was perfectly optimized, not only filelists but all other parts of the database (including primary.files, which you have cited initially) should be lazily synced, right? I'd rather not have filedeps so it doesn't get pulled in for other things in depsolving. Sorry, I do not know how this amount of data will impact libsolv in the future. IMO, for yum (I mean in the sqlite based solution) it is a matter of optimizations. I have a few questions: * What is the reasoning behind the splitting of the database across many .sqlite files? many? it's 3 afaik. primary, filelists, other. how do you mean 'many? Multiplied by the number of the repos. That is what I am trying to understand - Why not just single .sqlite file for the whole yum database? * Why the sql schema is so denormalized (IMO, leads to both bandwidth and disk overspending without speed benefits)?. For example: Why provides and requires tables do not use the common domain table? B/c it was designed 8yrs ago and we were going for compressable space and making it as quick as possible to search? In the provides and requires example, we do not have any space/speed benefits achieved by the missing common domain (dependency + dependency_evr tables). In the current situation we have fat and slow text duplication and indexes instead of integer references to the domain subnodes (dependencies is the biggest domain in the primary). Yes, in bunch of cases a little denormalization is inevitable when we fight for speed, but IMO, this and few other space flaws are with negative impact on the speed too. * Why the incremental update mechanism (eg. applying xml diffs to the sqlite database) was not been considered from the very beginning? It wasn't necessary? There was a massively smaller number of pkgs to consider. Indeed. Also, 8 years ago the possibilities and the number of ideas to reuse were definitely different :-) Thank you, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-05-29@ 16:00 UTC - F19 Final Blocker Bug Review #1
# F19 Final Blocker Review meeting #1 # Date: 2013-05-29 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net The proposed blocker list for F19 final already has quite a few bugs on it already so we're getting an early start on the blocker review parties! We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ 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
Anaconda 'frozen' for F19, nominate bugs that should be fixed as Freeze Exceptions
Hey, folks. Just a heads-up: in recent releases the anaconda team have started a policy of more or less 'freezing' anaconda for the whole post-Beta period. Apart from some specific planned developments, they intend to mostly take only fixes for Freeze Exception and Blocker bugs into anaconda between Beta and Final, starting right now (not starting from the official, project-wide freeze on June 16). So please, when testing and filing bugs, nominate bugs that you believe should be fixed in Fedora 19 Final as 'freeze exception' bugs. You can do this easily by using the blocker/FE nomination web page: https://qa.fedoraproject.org/blockerbugs/propose_bug or of course you can use the 'old-skool' process, which is just to mark the bug as blocking 'FinalFreezeException'. To avoid the load getting too large, if your bug is not of very critical impact, it might be best to nominate it only if you know the devs are actively working on a fix; it'd be a waste of people's time to review a bunch of bugs that the devs didn't have time to work on. If your bug seems pretty important, go ahead and nominate it straight away, as we'll probably want to have it on the radar. We were already planning to start doing blocker review meetings tomorrow, so we'll make sure to review proposed anaconda freeze exception bugs during review meetings from now on, and thereby make sure the appropriate fixes are 'approved' to go into f19 final. Thanks everyone! -- 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
Installed tests
Hi, in upstream GNOME, we're starting to convert the 'make check' style tests in many modules into installed tests that can be run against an installed system. We run these tests in our build system whenever a build completes. You can see this in action here: http://build.gnome.org/#gnome-ostree (the Integrationtest line). I think these tests can be useful for Fedora qa as well, which is why I am mentioning this here. I've just built the first glib2 release with installed tests in rawhide. For now, I've put the tests in a glib2-tests subpackage. The package contains the test binaries (in /usr/libexec/glib/installed-tests) and metadata describing the tests (in /usr/share/installed-tests/glib). I expect that we'll see some more GNOME packages grow -tests subpackages over the next months (gtk, gjs, libsoup, ...) To run the tests upstream, we use a simple test runner called gnome-desktop-testing-runner, which we could package as well. But the metadata is very simple keyfiles, so it should be easy to adapt some other test harness to use them, if desired. All of this is still up for discussion, and we can make changes to make the tests useful downstream as well as upstream. Let me know what you think. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installed tests
On Tue, 2013-05-28 at 20:13 -0400, Matthias Clasen wrote: Hi, in upstream GNOME, we're starting to convert the 'make check' style tests in many modules into installed tests The most important URL is this one: https://live.gnome.org/GnomeGoals/InstalledTests The most recent status update is here: https://mail.gnome.org/archives/desktop-devel-list/2013-May/msg00014.html But at a very high level, there are two ways in which the InstalledTests can be consumed by Fedora: 1) Human testers can perform manual reverse dependency testing Like I said on the wiki page, the GLib test suite covers a *lot* of lower level stuff (namely glibc and kernel) that we expect to work. It's possible for a human to update the kernel, and yum install glib2-tests, and run them to ensure they work. 2) As part of automated testing. The most important thing to understand here is that Type=session tests are most effectively run under an autologged-in VM. But it'd be mostly possible to run the current GNOME installed test corpus in a mock container with Xvfb + dbus-launch, but at least e.g. the clutter tests would have to be skipped in such an environment. We could probably teach clutter how to check for GLX before running its tests. I'd love to see InstalledTests propagate outside of GNOME of course. If anyone tries to do that, please let me know how it works out! For example, I suspect most projects don't need Type=session and maybe we should define a Type=headless. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Tue, 2013-05-28 at 13:17 -0600, Kevin Fenzi wrote: 2) e-v-r problems - sporadic reports Should also add this, although, it actually could be a check done in the new wonderful QA setup. We already in fact do an 'upgradepath' check in AutoQA. It frequently fails. Maintainers can sign themselves up for notifications of this test failing on their builds. http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcaseterms=upgradepath it tests that the build does not break the upgrade path from previous releases or to later releases. 3) reports on source url which don't work - havent been done in a llong time afaik and needs to be automated and way to silence them in known cases in a per package way (by checking in a file into the git repo for that package for instance) I've not done these in a long time yeah... again this could be something for a QA check when a spec file changes. You'd want to run it periodically even when the spec file doesn't change, because upstream sites die or change. 4) rpmlint reports could be collected in a central location and per package way to silence irrelevant warnings/errors could be added. refer to debian lintian site for some examples QA check on spec change. We already do it: http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcaseterms=rpmlint 5) update to new upstream versions in Rawhide - a tool could do bump the spec, do scratch builds automatically of newer versions, if that works ask the maintainer to apply a diff after reviewing the changes. I suppose. It doesn't seem like it's that hard for a maintainer to notice this and do that if thats all thats involved. We already have the upstream release monitoring system (mentioned below) for checking for new upstream versions and notifying maintainers; again you have to sign yourself up for this for your own packages. There are also helper scripts for doing a simple version bump and rebuild available and commonly used (though personally I always do it manually...I like to stay in touch with my specs :) 11) automatic period rebuilds in rawhide to highlight FTBFS issues aren't done as often anymore Can you expand on this? Not sure what you mean? IIRC, Matt Domsch used to run such tests semi-regularly. These days we usually do one mass rebuild per release. -- 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: Daily package ownership changes?
Hi On Tue, May 28, 2013 at 10:12 PM, Adam Williamson wrote: On Tue, 2013-05-28 at 13:17 -0600, Kevin Fenzi wrote: http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcaseterms=upgradepath it tests that the build does not break the upgrade path from previous releases or to later releases. Doesn't seem to have a way for me to sign up for reports for all packages I (co-) maintain and no way to tell the system, I am aware of these warnings and they are not applicable and would like to silence them, so I can focus on new warnings/errors if any. We already have the upstream release monitoring system (mentioned below) for checking for new upstream versions and notifying maintainers; again you have to sign yourself up for this for your own packages. In this case, I would like a global view of all the packages in a single web page ( similar to say the distrowatch package pages and not just bugzilla reports for the packages I maintain) Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Tue, 2013-05-28 at 22:36 -0400, Rahul Sundaram wrote: Hi On Tue, May 28, 2013 at 10:12 PM, Adam Williamson wrote: On Tue, 2013-05-28 at 13:17 -0600, Kevin Fenzi wrote: http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcaseterms=upgradepath it tests that the build does not break the upgrade path from previous releases or to later releases. Doesn't seem to have a way for me to sign up for reports for all packages I (co-) maintain and no way to tell the system, I am aware of these warnings and they are not applicable and would like to silence them, so I can focus on new warnings/errors if any. Tim or Kamil can remind me of the sign up mechanism I'm sure :) Indeed we could add some 'easier interaction' features for maintainers, so far what we have is a pretty minimal effort. We already have the upstream release monitoring system (mentioned below) for checking for new upstream versions and notifying maintainers; again you have to sign yourself up for this for your own packages. In this case, I would like a global view of all the packages in a single web page ( similar to say the distrowatch package pages and not just bugzilla reports for the packages I maintain) Yes, that would be nice. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 967719] Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
https://bugzilla.redhat.com/show_bug.cgi?id=967719 --- Comment #1 from Jan Synacek jsyna...@redhat.com --- Created attachment 753757 -- https://bugzilla.redhat.com/attachment.cgi?id=753757action=edit full backtrace during the crash Note that in the frame #3, the my_perl variable changes from a (probably valid) pointer to 0x0. -- 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=DKpfUwznfna=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 Hash-MultiValue-0.14.tar.gz uploaded to lookaside cache by cheeselee
A file has been added to the lookaside cache for perl-Hash-MultiValue: 38e63bcdc224ee25a098085190ccc291 Hash-MultiValue-0.14.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-Hash-MultiValue/f19] Update to 0.14
Summary of changes: 078048f... Update to 0.14 (*) (*) 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 967783] New: abi-compliance-checker-1.99 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967783 Bug ID: 967783 Summary: abi-compliance-checker-1.99 is available Product: Fedora Version: rawhide Component: abi-compliance-checker Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: hobbes1...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: hobbes1...@gmail.com, or...@cora.nwra.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.99 Current version in Fedora Rawhide: 1.98.8 URL: http://ispras.linuxbase.org/index.php/ABI_compliance_checker_Downloads Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=5OzmSj2qfFa=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 Module-Pluggable-4.8.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Pluggable: 28806a26002ef887db8430f14ba3f5cd Module-Pluggable-4.8.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
[Bug 967825] perl-Module-Pluggable-4.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967825 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This bug-fix release is suitable for F≥19. -- 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=ESMgDQXpu0a=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
[perl-Module-Pluggable] 4.8 bump
commit 4d71e0f5acac3b4a2c9c9c93b27e917e91d4fa55
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 14:13:49 2013 +0200
4.8 bump
.gitignore |1 +
perl-Module-Pluggable.spec | 13 -
sources|2 +-
3 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 556e141..f098636 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Module-Pluggable-3.6.tar.gz
/Module-Pluggable-4.6.tar.gz
/Module-Pluggable-4.7.tar.gz
+/Module-Pluggable-4.8.tar.gz
diff --git a/perl-Module-Pluggable.spec b/perl-Module-Pluggable.spec
index 0fca5d7..cf31f6b 100644
--- a/perl-Module-Pluggable.spec
+++ b/perl-Module-Pluggable.spec
@@ -1,7 +1,7 @@
Name: perl-Module-Pluggable
# Epoch to compete with perl.spec
Epoch: 1
-Version:4.7
+Version:4.8
Release:1%{?dist}
Summary:Automatically give your module the ability to have plugins
License:GPL+ or Artistic
@@ -12,14 +12,19 @@ BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(FindBin)
BuildRequires: perl(Module::Build)
+BuildRequires: perl(strict)
# Run-time:
BuildRequires: perl(base)
BuildRequires: perl(Carp)
+%if 0%(perl -e 'print $] 5.017')
+BuildRequires: perl(deprecate)
+%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec::Functions) = 3.00
BuildRequires: perl(if)
+BuildRequires: perl(vars)
# Tests:
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(lib)
@@ -27,6 +32,9 @@ BuildRequires: perl(Test::More) = 0.62
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(File::Basename)
Requires: perl(File::Spec::Functions) = 3.00
+%if 0%(perl -e 'print $] 5.017')
+Requires: perl(deprecate)
+%endif
# Filter under-specified dependencies
%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Spec::Functions\\)$
@@ -58,6 +66,9 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 1:4.8-1
+- 4.8 bump
+
* Thu Feb 28 2013 Petr Pisar ppi...@redhat.com - 1:4.7-1
- 4.7 bump
diff --git a/sources b/sources
index e89dabd..09cb7b2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bde569c825bae9fe4a1cf06a7475f741 Module-Pluggable-4.7.tar.gz
+28806a26002ef887db8430f14ba3f5cd Module-Pluggable-4.8.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-Module-Pluggable/f19] 4.8 bump
Summary of changes: 4d71e0f... 4.8 bump (*) (*) 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 967825] perl-Module-Pluggable-4.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967825 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Module-Pluggable-4.8-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Module-Pluggable-4.8-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=IQ50KuzYkqa=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
[perl-Text-Soundex] Correct typo in dependencies
commit 48a4f8bf97fca4ff92edd498c976ee625e3ede24
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 14:26:06 2013 +0200
Correct typo in dependencies
perl-Text-Soundex.spec | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
---
diff --git a/perl-Text-Soundex.spec b/perl-Text-Soundex.spec
index ead78c4..4e41a1d 100644
--- a/perl-Text-Soundex.spec
+++ b/perl-Text-Soundex.spec
@@ -1,6 +1,6 @@
Name: perl-Text-Soundex
Version:3.04
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Implementation of the soundex algorithm
License:Copyright only
Group: Development/Libraries
@@ -11,8 +11,8 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(strict)
# Run-time:
# Carp not needed for tests
-%if 0%(perl -e 'print $] 5.017')
-BuildRequires: perl(deprecated)
+%if 0%(perl -e 'print $] 5.016')
+BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(if)
@@ -20,8 +20,8 @@ BuildRequires: perl(if)
BuildRequires: perl(XSLoader)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Carp)
-%if 0%(perl -e 'print $] 5.017')
-Requires: perl(deprecated)
+%if 0%(perl -e 'print $] 5.016')
+Requires: perl(deprecate)
%endif
Requires: perl(Text::Unidecode)
@@ -56,6 +56,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 3.04-2
+- Correct typo in dependencies
+
* Mon Mar 04 2013 Petr Pisar ppi...@redhat.com - 3.04-1
- 3.04 bump
--
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-Text-Soundex/f19] Correct typo in dependencies
Summary of changes: 48a4f8b... Correct typo in dependencies (*) (*) 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
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
[perl-Term-UI] Correct typo in dependencies
commit d11fa67e5fd68722f3f3b730c4cbe96a297a6d8f
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 15:39:43 2013 +0200
Correct typo in dependencies
perl-Term-UI.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Term-UI.spec b/perl-Term-UI.spec
index bc4e58e..266afcd 100644
--- a/perl-Term-UI.spec
+++ b/perl-Term-UI.spec
@@ -1,6 +1,6 @@
Name: perl-Term-UI
Version:0.34
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Term::ReadLine user interface made easy
License:GPL+ or Artistic
Group: Development/Libraries
@@ -14,7 +14,7 @@ BuildRequires: perl(strict)
BuildRequires: perl(base)
BuildRequires: perl(Carp)
%if 0%(perl -e 'print $] 5.017')
-BuildRequires: perl(deprecated)
+BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(if)
@@ -30,7 +30,7 @@ BuildRequires: perl(lib)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%if 0%(perl -e 'print $] 5.017')
-Requires: perl(deprecated)
+Requires: perl(deprecate)
%endif
%description
@@ -59,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 0.34-2
+- Correct typo in dependencies
+
* Fri Jan 25 2013 Petr Pisar ppi...@redhat.com 0.34-1
- Specfile autogenerated by cpanspec 1.78.
- Require deprecated module if needed
--
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-File-CheckTree/f19] Correct typo in dependencies
Summary of changes: 4dc4825... Correct typo in dependencies (*) (*) 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
[perl-File-CheckTree] Correct typo in dependencies
commit 4dc4825241e5ec6e5606d3fcf4eb31192b8dbbf2
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 15:44:45 2013 +0200
Correct typo in dependencies
perl-File-CheckTree.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-File-CheckTree.spec b/perl-File-CheckTree.spec
index 849be92..958b497 100644
--- a/perl-File-CheckTree.spec
+++ b/perl-File-CheckTree.spec
@@ -1,6 +1,6 @@
Name: perl-File-CheckTree
Version:4.42
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Run many file-test checks on a tree
License:GPL+ or Artistic
Group: Development/Libraries
@@ -14,7 +14,7 @@ BuildRequires: perl(warnings)
# Run-time:
BuildRequires: perl(Cwd)
%if 0%(perl -e 'print $] 5.017')
-BuildRequires: perl(deprecated)
+BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Spec)
@@ -24,7 +24,7 @@ BuildRequires: perl(overload)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%if 0%(perl -e 'print $] 5.017')
-Requires: perl(deprecated)
+Requires: perl(deprecate)
%endif
%description
@@ -59,5 +59,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 4.42-2
+- Correct typo in dependencies
+
* Fri Feb 08 2013 Petr Pisar ppi...@redhat.com 4.42-1
- Specfile autogenerated by cpanspec 1.78.
--
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-Archive-Extract] Correct typo in dependencies
commit e3051fe18d0ceed650d7e09b3803e16e645ddb86
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 15:52:38 2013 +0200
Correct typo in dependencies
perl-Archive-Extract.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Archive-Extract.spec b/perl-Archive-Extract.spec
index b8ddce1..acc2362 100644
--- a/perl-Archive-Extract.spec
+++ b/perl-Archive-Extract.spec
@@ -2,7 +2,7 @@ Name: perl-Archive-Extract
# Epoch to compete with core module from perl.spec
Epoch: 1
Version:0.68
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Generic archive extracting mechanism
License:GPL+ or Artistic
Group: Development/Libraries
@@ -17,7 +17,7 @@ BuildRequires: perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(Cwd)
%if 0%(perl -e 'print $] 5.017')
-BuildRequires: perl(deprecated)
+BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Path)
@@ -38,7 +38,7 @@ BuildRequires: perl(Test::More)
# install what he needs.
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%if 0%(perl -e 'print $] 5.017')
-Requires: perl(deprecated)
+Requires: perl(deprecate)
%endif
Requires: perl(File::Spec) = 0.82
Requires: perl(IPC::Cmd) = 0.64
@@ -76,6 +76,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 1:0.68-2
+- Correct typo in dependencies
+
* Fri Mar 15 2013 Petr Pisar ppi...@redhat.com - 1:0.68-1
- 0.68 bump
--
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-Archive-Extract/f19] Correct typo in dependencies
Summary of changes: e3051fe... Correct typo in dependencies (*) (*) 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
[perl-B-Lint] Correct typo in dependencies
commit 76f2d787fcc0f12d188d6d259c475fe4a912e3cf
Author: Petr Písař ppi...@redhat.com
Date: Tue May 28 16:00:25 2013 +0200
Correct typo in dependencies
perl-B-Lint.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-B-Lint.spec b/perl-B-Lint.spec
index 219ab94..0cb22ca 100644
--- a/perl-B-Lint.spec
+++ b/perl-B-Lint.spec
@@ -1,6 +1,6 @@
Name: perl-B-Lint
Version:1.17
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl lint
License:GPL+ or Artistic
Group: Development/Libraries
@@ -14,7 +14,7 @@ BuildRequires: perl(B)
BuildRequires: perl(Carp)
BuildRequires: perl(constant)
%if 0%(perl -e 'print $] 5.017')
-BuildRequires: perl(deprecated)
+BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(if)
BuildRequires: perl(List::Util)
@@ -29,7 +29,7 @@ BuildRequires: perl(warnings)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(constant)
%if 0%(perl -e 'print $] 5.017')
-Requires: perl(deprecated)
+Requires: perl(deprecate)
%endif
%description
@@ -60,5 +60,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue May 28 2013 Petr Pisar ppi...@redhat.com - 1.17-2
+- Correct typo in dependencies
+
* Wed Jan 30 2013 Petr Pisar ppi...@redhat.com 1.17-1
- Specfile autogenerated by cpanspec 1.78.
--
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-B-Lint/f19] Correct typo in dependencies
Summary of changes: 76f2d78... Correct typo in dependencies (*) (*) 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 962126] perl-Regexp-Grammars-1.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962126 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Regexp-Grammars-1.028- |perl-Regexp-Grammars-1.028- |1.fc19 |1.el6 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-Regexp-Grammars-1.028-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- 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=hJo8hmceoma=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 967829] New: perl-Syntax-Highlight-Engine-Kate-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967829 Bug ID: 967829 Summary: perl-Syntax-Highlight-Engine-Kate-0.08 is available Product: Fedora Version: rawhide Component: perl-Syntax-Highlight-Engine-Kate Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.08 Current version in Fedora Rawhide: 0.07 URL: http://search.cpan.org/dist/Syntax-Highlight-Engine-Kate/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=Jmu1oMaGfEa=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
[abi-compliance-checker] Update to latest upstream release.
commit fcd38d505483e6a21f335d0e7db87a1fe6d344ee
Author: Richard M. Shaw hobbes1...@gmail.com
Date: Tue May 28 16:54:42 2013 -0500
Update to latest upstream release.
.gitignore |1 +
abi-compliance-checker.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 37b7c90..292608d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@
/abi-compliance-checker-1.98.6.tar.gz
/abi-compliance-checker-1.98.7.tar.gz
/abi-compliance-checker-1.98.8.tar.gz
+/abi-compliance-checker-1.99.tar.gz
diff --git a/abi-compliance-checker.spec b/abi-compliance-checker.spec
index 1ea26c1..a2b9fea 100644
--- a/abi-compliance-checker.spec
+++ b/abi-compliance-checker.spec
@@ -1,6 +1,6 @@
Name: abi-compliance-checker
-Version:1.98.8
-Release:2%{?dist}
+Version:1.99
+Release:1%{?dist}
Summary:An ABI Compliance Checker
License:GPL+ or LGPLv2+
@@ -42,6 +42,9 @@ perl Makefile.pl -install --prefix=%{_prefix}
--destdir=%{buildroot}
%changelog
+* Tue May 28 2013 Richard Shaw hobbes1...@gmail.com - 1.99-1
+- Update to latest upstream release.
+
* Fri May 03 2013 Richard Shaw hobbes1...@gmail.com - 1.98.8-2
- Add package requires for gcc-c++, ctags, ccache.
diff --git a/sources b/sources
index b814aa4..e5a4a42 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a8629a197654945567d37e471c19f2a2 abi-compliance-checker-1.98.8.tar.gz
+90e3d28dc6b2b7697f83f53ea2d6b2d9 abi-compliance-checker-1.99.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
[abi-compliance-checker/f17] Update to latest upstream release.
Summary of changes: fcd38d5... Update to latest upstream release. (*) (*) 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
[abi-compliance-checker/f18] Update to latest upstream release.
Summary of changes: fcd38d5... Update to latest upstream release. (*) (*) 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 967828] perl-POE-Component-IRC-6.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967828 Petr Šabata psab...@redhat.com changed: What|Removed |Added Depends On||967945 -- 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=ggWh3gRZZva=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 967830] New: perl-threads-lite-0.033 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967830 Bug ID: 967830 Summary: perl-threads-lite-0.033 is available Product: Fedora Version: rawhide Component: perl-threads-lite Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.033 Current version in Fedora Rawhide: 0.032 URL: http://search.cpan.org/dist/threads-lite/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=jBLHRaR7zda=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 967831] New: perl-Tk-804.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967831 Bug ID: 967831 Summary: perl-Tk-804.031 is available Product: Fedora Version: rawhide Component: perl-Tk Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: andreas.bierf...@lowlatency.de Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: andreas.bierf...@lowlatency.de, perl-devel@lists.fedoraproject.org Latest upstream release: 804.031 Current version in Fedora Rawhide: 804.030 URL: http://search.cpan.org/dist/Tk/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=NxPI8GTnSga=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 962318] perl-Hash-MultiValue-0.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962318 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Hash-MultiValue-0.14-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Hash-MultiValue-0.14-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9437/perl-Hash-MultiValue-0.14-1.fc19 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GJOoGQ4OXpa=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 962317] perl-Devel-Size-0.79 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962317 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Devel-Size-0.79-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Devel-Size-0.79-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9444/perl-Devel-Size-0.79-1.fc19 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WmTPqFcekAa=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 967719] New: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
https://bugzilla.redhat.com/show_bug.cgi?id=967719 Bug ID: 967719 Summary: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend Product: Fedora Version: 19 Component: perl Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: jsyna...@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 Created attachment 753756 -- https://bugzilla.redhat.com/attachment.cgi?id=753756action=edit Reproducer pack Description of problem: When trying to initialize back_perl, a segfault occurs deep in perl itself. Version-Release number of selected component (if applicable): perl-5.16.3-264.fc19.x86_64 openldap-2.4.35-4.fc19.x86_64 How reproducible: Almost always. Steps to Reproduce: 1. Install fresh F19 2. If you try the reproducer here, all goes well 3. yum install perl-A* (I have no idea why I needed to do this to get it to segfault) 4. Try reproducer 5. Observe the segfault 6. From now on, reproducer works *without* producing any segfaults. I had to reboot the machine to be able to reproduce the issue again. Note on how to use the reproducer: 1. Unpack 2. Run go.sh (warning: it will wipe your /var/lib/ldap/* and your /etc/openldap/*, so don't run if you use openldap in production) This will run slapd in debug mode, so you will need another console to run the rest. 3. Run try.sh 4. If you want to repeat, go to 2. You can modify go.sh to run slapd through a debugger. However, you will probably need to set LD_PRELOAD=/usr/lib64/perl5/CORE/libperl.so to be able to run try.sh. Actual results: Perl segfaults. Expected results: The back_perl gets initialized without any problems. Additional info: This also happens on my production F18, but it happens always. It looks like it might have something to do with Bug 960048. -- 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=BrMXYAmcGQa=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 967823] New: perl-Class-Unload-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967823 Bug ID: 967823 Summary: perl-Class-Unload-0.08 is available Product: Fedora Version: rawhide Component: perl-Class-Unload Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.08 Current version in Fedora Rawhide: 0.07 URL: http://search.cpan.org/dist/Class-Unload/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=9Ds62cAA5ba=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 967825] perl-Module-Pluggable-4.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967825 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Module-Pluggable-4.8-1 ||.fc20 -- 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=hXB6qQko6Va=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 962318] perl-Hash-MultiValue-0.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962318 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Hash-MultiValue-0.14-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Hash-MultiValue-0.14-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=ruXHLC4VdIa=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 967823] perl-Class-Unload-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967823 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com,| |ppi...@redhat.com | Assignee|mmasl...@redhat.com |ppi...@redhat.com -- 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=sWqvbo5rnca=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 967823] perl-Class-Unload-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=967823 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for all Fedoras. -- 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=EhJzepeZDYa=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
