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 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 - 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 - 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=GlyXhNJls4&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[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=f9BwHVYOUS&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: 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 p
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" > To: "Development discussions related to Fedora" > > 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 " 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 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ý 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 " 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 changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- 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=BZAviMMsk9&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora 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ý 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 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 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ý 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 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 wrote: On Tue, 28 May 2013 14:58:35 -0400 Rahul Sundaram 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 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=Testcase&terms=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=Testcase&terms=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=Testcase&terms=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=Testcase&terms=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