Re: Software Management call for RFEs

2013-05-28 Thread Miroslav Suchý

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

2013-05-28 Thread Miroslav Suchý

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

2013-05-28 Thread Alek Paunov

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

2013-05-28 Thread Petr Pisar
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

2013-05-28 Thread Paolo Bonzini
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

2013-05-28 Thread 李瑞彬
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

2013-05-28 Thread Florian Weimer

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

2013-05-28 Thread Jan Zelený
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

2013-05-28 Thread 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.


  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

2013-05-28 Thread Miroslav Suchý

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

2013-05-28 Thread Mathieu Bridon
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

2013-05-28 Thread Ales Kozumplik

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

2013-05-28 Thread Petr Pisar
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

2013-05-28 Thread bugzilla
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

2013-05-28 Thread bugzilla
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

2013-05-28 Thread Alek Paunov

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

2013-05-28 Thread Michael Ekstrand
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

2013-05-28 Thread Reindl Harald


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

2013-05-28 Thread Fedora Rawhide Report
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

2013-05-28 Thread Fedora Branched Report
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

2013-05-28 Thread Ales Kozumplik

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

2013-05-28 Thread Fernando Nasser
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.

2013-05-28 Thread Dennis Gilmore
-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

2013-05-28 Thread Ales Kozumplik

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

2013-05-28 Thread Ales Kozumplik

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)

2013-05-28 Thread Stanislav Ochotnicky
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

2013-05-28 Thread seth vidal
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

2013-05-28 Thread Fabian Deutsch
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

2013-05-28 Thread James Antill
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)

2013-05-28 Thread Panu Matilainen

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

2013-05-28 Thread bugzilla
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!

2013-05-28 Thread Paul Whalen


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

2013-05-28 Thread Rahul Sundaram
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

2013-05-28 Thread Alek Paunov

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

2013-05-28 Thread Kevin Fenzi
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

2013-05-28 Thread Adam Williamson
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

2013-05-28 Thread seth vidal
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

2013-05-28 Thread Jan Zeleny
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

2013-05-28 Thread Jan Zeleny
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

2013-05-28 Thread Jan Zeleny
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

2013-05-28 Thread Jan Zeleny
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?

2013-05-28 Thread Rahul Sundaram

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?

2013-05-28 Thread Pierre-Yves Chibon
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?

2013-05-28 Thread Kevin Fenzi
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?

2013-05-28 Thread Rahul Sundaram

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?

2013-05-28 Thread Bruno Wolff III

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?

2013-05-28 Thread Rahul Sundaram

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

2013-05-28 Thread Alek Paunov

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

2013-05-28 Thread Tim Flink
# 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

2013-05-28 Thread Adam Williamson
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

2013-05-28 Thread Matthias Clasen

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

2013-05-28 Thread Colin Walters
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?

2013-05-28 Thread Adam Williamson
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?

2013-05-28 Thread Rahul Sundaram
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?

2013-05-28 Thread Adam Williamson
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