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
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 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
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
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
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
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
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/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 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 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/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
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
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
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
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
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'
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
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
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
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
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
-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? ***
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
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
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 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
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, 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=966926
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from Fedora
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
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
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
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 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 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
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
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 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 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
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
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 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 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, 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: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 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
# 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!
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
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
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
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
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 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
55 matches
Mail list logo
