Bruno Wolff III br...@wolff.to writes:
Tom Lane t...@redhat.com wrote:
Yeah. I have done test packaging of 9.1rc1 already, so it's pretty much
ready to go on my end. I would be prepared to push 9.1 into f16 on
Monday if there were enough people willing to test and up-karma it
before the
WHAT: Fedora QA Meeting
WHEN: 15:00 UTC (11:00 EDT, 08:00 PDT)
WHERE: #fedora-meeting
It's meeting time again! We missed last week, so a double dose of
meeting-y...excitement...this week. Same bat time, same bat channel.
If anyone has anything to add to the agenda, please reply to this mail,
and
On Mon, Sep 12, 2011 at 12:11:50AM +0200, Kevin Kofler wrote:
Frank Murphy wrote:
Is not rawhide the sanity check,
Yes.
even if used productively by many?
That's the problem then. Rawhide is explicitly labeled as NOT being intended
nor suitable for any sort of production use.
This
On Sun, 2011-09-11 at 12:18 +0200, Jim Meyering wrote:
I was thinking of something more like make check (that would
run a test suite), or maintainer gives it a spin before releasing.
But maybe something about the maintainer's set-up was different
enough that those tests would all pass.
Few
On Mon, 2011-09-12 at 08:56 +0100, Richard W.M. Jones wrote:
I thought AutoQA was going to do this, but it's been disappointing.
AutoQA is under active development, still. It's a complex project.
Especially being able to automate this kind of high level functionality
testing is tricky:
Dne 11.9.2011 00:35, Pavel Alexeev (aka Pahan-Hubbitus) napsal(a):
Obviously you have not read my question. It is not jreen. It is about
psi and kopete. And there NO system versions of mentioned libs in Fedora
yet.
I believe the correct answer is that those libraries should be still
unbundled
Dne 10.9.2011 17:23, Rahul Sundaram napsal(a):
I agree with that. If Spot is going to maintain it anyway, it might as
well as be in the repository and more accessible to end users with
better security
Well, we could do a little salami tactic ... e.g., use system v8 which
is packaged and
I have caused this affair. Sorry about that. Openssh version 5.9 I tested and I
do not understand why the test passed.
And my opinion of defective packages in rawhide?
I used to regularly downgrade sensitive packages when they are in unstable
versions and I consider it a feature rawhide.
Jan
Dne 12.9.2011 11:26, Alex Hudson napsal(a):
I view this as entirely equivalent to having a rule about not breaking
trunk in version control: I don't know anyone who seriously argues that
breaking a project compile is a good thing. Breaking the OS should be
culturally identical - that it's a
On 09/12/2011 03:28 PM, Jan F. Chadima wrote:
I have caused this affair. Sorry about that. Openssh version 5.9 I tested and
I do not understand why the test passed.
And my opinion of defective packages in rawhide?
I used to regularly downgrade sensitive packages when they are in unstable
Dne 12.9.2011 12:03, Rahul Sundaram napsal(a):
If you maintain any of the critical path packages, it would be very useful
to test them more instead of just a mad version number chase.
Take a deep breath, count to ten, and then repeat to yourself “S..t
happens.” Don’t throw around accusations
On 09/12/2011 03:39 PM, Matej Cepl wrote:
Dne 12.9.2011 12:03, Rahul Sundaram napsal(a):
If you maintain any of the critical path packages, it would be very useful
to test them more instead of just a mad version number chase.
Take a deep breath, count to ten, and then repeat to yourself “S..t
On Mon, Sep 12, 2011 at 01:02:26AM -0700, Adam Williamson wrote:
On Mon, 2011-09-12 at 08:56 +0100, Richard W.M. Jones wrote:
I thought AutoQA was going to do this, but it's been disappointing.
AutoQA is under active development, still. It's a complex project.
I hope I can make a
On Mon, 2011-09-12 at 12:01 +0200, Matej Cepl wrote:
Dne 12.9.2011 11:26, Alex Hudson napsal(a):
I view this as entirely equivalent to having a rule about not breaking
trunk in version control: I don't know anyone who seriously argues that
breaking a project compile is a good thing.
On Sep 12, 2011, at 12:03 PM, Rahul Sundaram wrote:
On 09/12/2011 03:28 PM, Jan F. Chadima wrote:
I have caused this affair. Sorry about that. Openssh version 5.9 I tested
and I do not understand why the test passed.
And my opinion of defective packages in rawhide?
I used to regularly
On Mon, Sep 12, 2011 at 01:02:26AM -0700, Adam Williamson wrote:
On Mon, 2011-09-12 at 08:56 +0100, Richard W.M. Jones wrote:
I thought AutoQA was going to do this, but it's been
disappointing.
I haven't read the whole thread, but I also feel the rate of AutoQA development
is slow.
On 09/12/2011 04:03 PM, Kamil Paral wrote:
I haven't read the whole thread, but I also feel the rate of AutoQA
development is slow. Unfortunately I don't know how to improve that, since
there are just a few people working on it and they are also participating in
release validation testing,
On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org wrote:
perl-MooseX-Role-Matcher has broken dependencies in the F-16 tree:
On x86_64:
perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires
perl(:MODULE_COMPAT_5.12.4)
On i386:
* Andy Shevchenko [12/09/2011 13:18] :
Hmm... I couldn't build the package - the error from fedpkg build like
already built.
You need to bump the release number up a notch if you want to rebuild a
package.
Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
Dne 12.9.2011 12:21, Alex Hudson napsal(a):
I find it interesting that you can jump from don't break the OS to
too much QA.
Yes, because IMHO any (non-automatic) QA on Rawhide is too much.
Same for the pre-release branch. Breaking F16 should be serious
business. Right now, it really isn't.
On Mon, Sep 12, 2011 at 2:22 PM, Emmanuel Seyman
emmanuel.sey...@club-internet.fr wrote:
Hmm... I couldn't build the package - the error from fedpkg build like
already built.
You need to bump the release number up a notch if you want to rebuild a
package.
The problem is there is a _new_
Compose started at Mon Sep 12 08:15:36 UTC 2011
Broken deps for x86_64
--
FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit)
Rahul Sundaram wrote:
If you continue to consider it a feature, it justifies (in your mind)
pushing broken packages into the repository but it does affect release
versions as well because we have to catch and fix bugs much later. If
you maintain any of the critical path packages, it would
Clyde E. Kunkel wrote:
Didn't say like, said similar. Don't you test your changes somehow? Or
do you just toss the mods over the wall and hope for the best? I don't
think so. Share your test cases for those packages that should just
work--not all packages. Forget that the changes are for
Alex Hudson wrote:
I view this as entirely equivalent to having a rule about not breaking
trunk in version control: I don't know anyone who seriously argues that
breaking a project compile is a good thing. Breaking the OS should be
culturally identical - that it's a development branch or
On Mon, Sep 12, 2011 at 1:17 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org wrote:
perl-MooseX-Role-Matcher has broken dependencies in the F-16 tree:
On x86_64:
perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires
On Mon, Sep 12, 2011 at 2:51 PM, Iain Arnell iarn...@gmail.com wrote:
On Mon, Sep 12, 2011 at 1:17 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org wrote:
perl-MooseX-Role-Matcher has broken dependencies in the F-16 tree:
On
On Mon, 2011-09-12 at 13:43 +0200, Kevin Kofler wrote:
If something fails to COMPILE, this actually hinders development. In fact,
I'm one of the first ones to yell if package builds in Rawhide are broken
(due to some dependency breakage or whatever). Something failing to RUN is a
wholely
On Mon, Sep 12, 2011 at 1:55 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Mon, Sep 12, 2011 at 2:51 PM, Iain Arnell iarn...@gmail.com wrote:
On Mon, Sep 12, 2011 at 1:17 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org
* Andy Shevchenko [12/09/2011 14:04] :
On Mon, Sep 12, 2011 at 2:51 PM, Iain Arnell iarn...@gmail.com wrote:
Looks like you just need to submit the f16 build to bodhi.
I thought so, but there is no f16 build available in bodhi.
The build is tagged trashcan so I'm not sure you can still do
Compose started at Mon Sep 12 08:15:06 UTC 2011
Broken deps for x86_64
--
389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46
389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46
389-admin-1.1.23-1.fc17.i686
Someone pointed out an interesting Ruby gem [1] to me recently that I
thought about packaging for Fedora. The gem has a dependency tree that
includes several other gems that aren't in Fedora as well [2], so I'd
love it if a few people could pitch in to help out with maintaining (or
co-maintaining
On Mon, 2011-09-12 at 09:22 -0400, Darryl L. Pierce wrote:
Someone pointed out an interesting Ruby gem [1] to me recently that I
thought about packaging for Fedora. The gem has a dependency tree that
includes several other gems that aren't in Fedora as well [2], so I'd
love it if a few people
On Mon, Sep 12, 2011 at 03:26:12PM +0200, Pierre-Yves Chibon wrote:
This license is part of the
https://fedoraproject.org/wiki/Licensing#Software_License_List and is
acceptable for inclusion in Fedora:
Do What The F*ck You Want To Public License WTFPL Yes Yes Yes
On Mon, 2011-09-12 at 13:39 +0200, Kevin Kofler wrote:
Clyde E. Kunkel wrote:
Didn't say like, said similar. Don't you test your changes somehow? Or
do you just toss the mods over the wall and hope for the best? I don't
think so. Share your test cases for those packages that should just
On 09/12/2011 07:39 AM, Kevin Kofler wrote:
Clyde E. Kunkel wrote:
Didn't say like, said similar. Don't you test your changes somehow? Or
do you just toss the mods over the wall and hope for the best? I don't
think so. Share your test cases for those packages that should just
work--not
On 09/12/2011 06:01 AM, Matej Cepl wrote:
Too much QA (or any external QA) imposed on the development make it
slower. Compare Linux v. OpenSolaris kernel development. Fedora tries to
be very fast developing distro, thus less QA in the development version.
Ah yes, the ol' QA conundrum.
On Mon, Sep 12, 2011 at 10:05:05AM -0400, Clyde E. Kunkel wrote:
On 09/12/2011 06:01 AM, Matej Cepl wrote:
Too much QA (or any external QA) imposed on the development make it
slower. Compare Linux v. OpenSolaris kernel development. Fedora tries to
be very fast developing distro, thus less
Following is the list of topics that will be discussed in the FESCo
meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on
irc.freenode.net.
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic ticket #663 Late F16 Feature Java7
.fesco
On Mon, 2011-09-12 at 13:37 +0200, Kevin Kofler wrote:
Rahul Sundaram wrote:
If you continue to consider it a feature, it justifies (in your mind)
pushing broken packages into the repository but it does affect release
versions as well because we have to catch and fix bugs much later. If
On 09/12/2011 10:17 AM, Jakub Jelinek wrote:
Sure, we need QA, but for rawhide the development shouldn't be totally
stalled as it is already in F16 right now, where updates for critpath
packages, even when they have several hundred thousands of tests
performed already during package building,
On Mon, Sep 12, 2011 at 11:26 AM, Alex Hudson fed...@alexhudson.com wrote:
I view this as entirely equivalent to having a rule about not breaking
trunk in version control: I don't know anyone who seriously argues that
breaking a project compile is a good thing. Breaking the OS should be
On Fri, 2011-09-09 at 07:06 -0400, Josh Boyer wrote:
On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen n...@redhat.com wrote:
On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote:
I don't think a maintainer can realistically replace wide-spread user
based testing in a variety of environments.
I've just pushed release candidate of PCRE 8.20 into F17. The main
feature is voluntary just-in-time compilation of state automaton used to
match regular expression.
Application needs to enable JIT on compiled pattern by passing
PCRE_STUDY_JIT_COMPILE option to pcre_study() function before
On Fri, 2011-09-09 at 12:22 +0200, Vít Ondruch wrote:
Sorry, you are mixing two things:
1) One is testing environment and it can be probably well defined,
clean, etc.
And thus incomparable to real-life environments. Mind, I'm not arguing
against some testing (e.g. automated regression
In reading the long trash each other fest that accompanies pre-release
jitters, could we start on a cleaner plate? What do the people who are
using rawhide day-in/day-out expect out of the channel? What level of
pain does someone like Jonathan Corbet expect and how can we better
serve them? [And
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/11/2011 01:01 AM +9:00:
Now I change it on:
%if %( php -r echo (version_compare(PHP_VERSION, '5.3.0', '=') ? 1 : 0);
/dev/null || echo 0 )
but on make srpm got error:
error: /home/pasha/SOFT/git/php-pecl-runkit/master/php-pecl-runkit.spec:74:
Nils Philippsen wrote:
We shouldn't revert to untagging broken packages in Rawhide just to make
it less consequential for people to break stuff. We should revert to
untagging broken packages because bumping epoch is costlier in the long
run as epoch is often disregarded. People using Rawhide
On Mon, Sep 12, 2011 at 08:57, Stephen John Smoogen smo...@gmail.comwrote:
In reading the long trash each other fest that accompanies pre-release
jitters, could we start on a cleaner plate? What do the people who are
using rawhide day-in/day-out expect out of the channel? What level of
pain
On Mon, Sep 12, 2011 at 09:57:34 -0600,
Stephen John Smoogen smo...@gmail.com wrote:
In reading the long trash each other fest that accompanies pre-release
jitters, could we start on a cleaner plate? What do the people who are
using rawhide day-in/day-out expect out of the channel? What level
I run rawhide full time on a test machine here.
rawhide-test.scrye.com, see:
http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
Usually I use it to test my packages and confirm/fix bugs that are
reported. It's a vm, but vncserver works for testing a lot. I do notice
when
On 09/12/2011 11:57 AM, Stephen John Smoogen wrote:
In reading the long trash each other fest that accompanies pre-release
jitters, could we start on a cleaner plate? What do the people who are
using rawhide day-in/day-out expect out of the channel? What level of
pain does someone like
On Mon, Sep 12, 2011 at 7:57 AM, Stephen John Smoogen smo...@gmail.comwrote:
In some cases, expectations may be off which means we need to market
our deliverables better. In other cases, they may be looking for a
better way to get attention to rawhide issues when everyone else is
focused on
On Mon, 2011-09-12 at 09:57 -0600, Stephen John Smoogen wrote:
What do the people who are using rawhide day-in/day-out expect out of
the channel?
My expectation is something that basically works. Like others have said,
I expect occasional breakage, but my rawhide criterion is latest
version
Hi,
I'm following
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
It seems gouldwp is non-responsive.
User: gouldwp,
Name: None,
email: w...@gouldfamily.org,
Creation: 2008-01-19,
Status: active
Approved Groups: cla_fpca cla_fedora fedorabugs cla_done packager
* Bug
Hi all,
I've recently joined Red Hat's OpenOffice.org/LibreOffice team, so I'll
probably want to get my hands dirty with the corresponding Fedora
packages in the future.
My background: I've been a core member of OpenOffice.org development
for 14 years. I'm mostly taking care of the lower
12.09.2011 12:37, Matej Cepl wrote:
Dne 11.9.2011 00:35, Pavel Alexeev (aka Pahan-Hubbitus) napsal(a):
Obviously you have not read my question. It is not jreen. It is about
psi and kopete. And there NO system versions of mentioned libs in Fedora
yet.
I believe the correct answer is that those
12.09.2011 19:57, TASAKA Mamoru wrote:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/11/2011 01:01 AM +9:00:
Now I change it on:
%if %( php -r echo (version_compare(PHP_VERSION, '5.3.0', '=') ? 1
: 0); /dev/null || echo 0 )
but on make srpm got error:
error:
Le lundi 12 septembre 2011 à 09:57 -0600, Stephen John Smoogen a écrit :
In reading the long trash each other fest that accompanies pre-release
jitters, could we start on a cleaner plate? What do the people who are
using rawhide day-in/day-out expect out of the channel? What level of
pain does
On Mon, 2011-09-12 at 11:17 +0100, Richard W.M. Jones wrote:
On Mon, Sep 12, 2011 at 01:02:26AM -0700, Adam Williamson wrote:
On Mon, 2011-09-12 at 08:56 +0100, Richard W.M. Jones wrote:
I thought AutoQA was going to do this, but it's been disappointing.
AutoQA is under active
On Mon, 2011-09-12 at 11:48 -0700, Adam Williamson wrote:
AutoQA is under active development, still. It's a complex project.
I hope I can make a suggestion:
Can we have it so that packagers can commit a file into Fedora git
(eg. autoqa.sh), and have that picked up by AutoQA and run
On Mon, Sep 12, 2011 at 6:38 PM, Iain Arnell iarn...@gmail.com wrote:
Looks like you just need to submit the f16 build to bodhi.
I thought so, but there is no f16 build available in bodhi.
The build is tagged trashcan so I'm not sure you can still do that.
Can you untrash it with koji tag-pkg
Greetings.
The current maintainer of mod_gnutls is unable to work on the package
right now and would like to find some co-maintainers. There's an
upstream update pending currently.
Any takers? If so, please apply in pkgdb and ping me and I can approve
your access.
thanks!
kevin
On Sat, 2011-09-10 at 20:53 +0530, Rahul Sundaram wrote:
On 09/10/2011 12:15 PM, drago01 wrote:
Well it seems upstream isn't really interested in fixing this so if we
want chromium in fedora we'd have to ask FESCo for an exception.
I agree with that. If Spot is going to maintain it
On Mon, 2011-09-12 at 16:07 +0530, Rahul Sundaram wrote:
On 09/12/2011 04:03 PM, Kamil Paral wrote:
I haven't read the whole thread, but I also feel the rate of AutoQA
development is slow. Unfortunately I don't know how to improve that, since
there are just a few people working on it and
On Mon, Sep 12, 2011 at 02:41:36PM -0700, Adam Williamson wrote:
Given that it's not a particularly vital package, since we have the
somewhat more 'correct' Firefox, I don't think it's necessary to suspend
our packaging standards to accept this kind of crappy code into Fedora.
Well, I
On Mon, 2011-09-12 at 17:56 +0200, Nils Philippsen wrote:
If there is
not enough karma for his package to bring it into the stable, then there
is probably time to ask somebody (probably on fedora-devel), to test
this package.
We have a default of +3 karma for automatic pushes to
On Mon, 2011-09-12 at 13:01 -0400, Clyde E. Kunkel wrote:
I use rawhide daily, primarily for mail, web and document creation. I
also enjoy trying new software in rawhide which leads to some
interesting situations. I like to test the packages in updates-testing
as a proven packager, but
On Mon, Sep 12, 2011 at 03:16:47 -0400,
Tom Lane t...@redhat.com wrote:
OK, it's built and filed at
https://admin.fedoraproject.org/updates/postgresql-9.1.0-1.fc16
One thing I noticed is that service postgresql initdb and
service postgresql help no longer work. I was hoping they'd redirect
Bruno Wolff III br...@wolff.to writes:
On Mon, Sep 12, 2011 at 03:16:47 -0400,
Tom Lane t...@redhat.com wrote:
OK, it's built and filed at
https://admin.fedoraproject.org/updates/postgresql-9.1.0-1.fc16
One thing I noticed is that service postgresql initdb and
service postgresql help no
On Mon, Sep 12, 2011 at 8:54 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Mon, Sep 12, 2011 at 6:38 PM, Iain Arnell iarn...@gmail.com wrote:
Looks like you just need to submit the f16 build to bodhi.
I thought so, but there is no f16 build available in bodhi.
The build is tagged
Le 07/09/2011 09:14, Pavel Alexeev (aka Pahan-Hubbitus) a écrit :
%if 0%{?php_zend_api:1} if you want to use (guessing php_zend_api
is not defined as 0 even on EPEL)
Just for interest - is there change of minimal buildroot happened since
F15? Why it was worked before? Was it announced and I
A file has been added to the lookaside cache for perl-threads-shared:
b903f685b6a1175013a263feed6fdf8b threads-shared-1.40.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit 3c7d0bc7aa3386658ea5548bf082dcd3fb8df02e
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 12 10:29:11 2011 +0200
1.40 bump
.gitignore |1 +
perl-threads-shared.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=737249
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
perl-HTML-FormatText-WithLinks-AndTables has broken dependencies in the F-16
tree:
On x86_64:
perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires
perl(:MODULE_COMPAT_5.12.4)
On i386:
perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree:
On x86_64:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=737320
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=735062
--- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-09-13
01:51:09 EDT ---
perl-Date-Manip-6.25-1.fc15 has
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=735062
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
82 matches
Mail list logo
