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&t
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
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 sig
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 updat
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
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 betwee
# 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!
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 downlo
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 har
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
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
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
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 ins
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 specif
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 lo
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 unintrusiv
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
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 upda
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
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 lea
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 t
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 upda
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
deve
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, wi
https://bugzilla.redhat.com/show_bug.cgi?id=966926
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from Fedora
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 necessar
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
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 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
> >
> > h
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 " sc
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/xmlrp
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
a
-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? ***
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
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.r
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
[d
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)
[good
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
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'
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 consid
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
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: u
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) clau
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
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.
--
Mathi
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 dn
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 "fo
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
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
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 ++---
so
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
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 pre
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
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.
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
55 matches
Mail list logo
