Why opencv has experienced broken dependency at first step ?
I've miss the required announcement, and even if it was announced, it would
have be stroken by a denial from my side!
That kind of development is unappropriate in a stable release.
Nicolas (kwizart)
2010/3/1 Haïkel Guémar
Jesse Keating wrote:
You can put free text in a bodhi comment without giving positive or
negative karma. Seems we already have what you want to replace it with.
But his point (which I agree with, FWIW) is that those arbitrary numbers are
meaningless and thus it makes no sense to count them.
On Mon, 1 Mar 2010, Doug Ledford wrote:
One could argue that the current bodhi karma system is simply too
simplistic for real use cases. Maybe instead of just +1 -1, there
should be:
Fixes my problem
Works for me (someone testing that didn't necessarily have any of the
problem supposedly
Björn Persson wrote:
That sounds really good, although I would call the second one still works
for me to emphasize that it's for people for whom the previous release
also worked.
Right.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Tom spot Callaway wrote:
* Has ABI/API change (and is a Critical Path package)
Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of
the affected packages should be the criterion, critical path or not is
irrelevant. But this is basically covered by causes broken deps
On Tue, 2 Mar 2010, Kevin Kofler wrote:
Doug Ledford wrote:
Fixes my problem
Works for me (someone testing that didn't necessarily have any of the
problem supposedly fixed by this update just noting that their system
still works ok with the update)
Doesn't fix my problem (but doesn't
James Antill wrote:
So I did my proposal, which I think will motivate packagers to do the
right thing (giving lots of choice to the users and a reasonable number
of packages to test) and not removing the ability of packagers to do
what they want (and have the stable firehose):
Peter Jones wrote:
This is the plan that already isn't working.
Is it really not working? Or are we overblowing a minor incident which
didn't even cause all that much trouble and trying to swallow a cure which
is worse than the disease? I think it's really the latter.
Kevin Kofler
--
Peter Jones wrote:
When you're at the circus watching the clown ride a bicycle across a
high-wire, he's got a safety net. It's not because the circus thinks he's
an incompetent high-wire cyclist - it's because people occasionally make
mistakes, and the circus would rather have him around to do
Jesse Keating wrote:
We do pushes daily,
No we don't. There are usually no pushes on weekends.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
James Antill wrote:
It's still not really usable by normal users, but people on this list
can install yum-plugin-local ... which will make sure you can do
downgrades like this.
Isn't keepcache=yes sufficient? IMHO that should really be the default, I
really don't understand why we default to
Adam Jackson wrote:
If it's ready on Tuesday afternoon, what makes you think anyone's going
to have time to read it thoroughly enough to be able to vote on it? Are
you implying you're the only one on fesco that actually considers the
proposal they're asked to vote on?
Considering that this
Peter Jones wrote:
Other corner cases where your case was wrong include new packages that
Obsolete existing packages.
Nonsense. I wrote new package which doesn't replace anything. Obsoletes =
replacing.
Even if you fix all the fixable problems, testing will still not be a
silver bullet!
Jesse Keating wrote:
That's going to be pretty difficult to do with the way our push and sync
scripts work.
At most an update that is going from testing to stable should disappear
for only a few hours, that would be between the updates-testing push of
the day an the subsequent branched
LinkedIn
Henrique Castro requested to add you as a connection on LinkedIn:
--
Marco,
I'd like to add you to my professional network on LinkedIn.
- Henrique
Accept invitation from Henrique Castro
Till Maas wrote:
Which files do you mean here? Afaik, cvs needs to know the CVSROOT and
when I joined as a package maintainer, the wiki suggested to export the
CVSROOT variable in .bashrc. It would be this one for you:
export CVSROOT=:ext:tannhau...@cvs.fedoraproject.org:/cvs/pkgs
But I
On Tue, Mar 02, 2010 at 12:26:35 +0100,
Kevin Kofler kevin.kof...@chello.at wrote:
We could have the branched compose compose from dist-f13 + dist-f13-updates
and move everything which was part of its compose from dist-f13-updates to
dist-f13 on completion. That way dist-f13-updates would
On Tue, 2010-03-02 at 11:22 +0100, Kevin Kofler wrote:
James Antill wrote:
It's still not really usable by normal users, but people on this list
can install yum-plugin-local ... which will make sure you can do
downgrades like this.
Isn't keepcache=yes sufficient? IMHO that should really
Compose started at Tue Mar 2 08:15:16 UTC 2010
Broken deps for i386
--
R-hdf5-1.6.9-6.fc13.i686 requires hdf5 = 0:1.8.4
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
easystroke-0.5.2-1.fc13.i686 requires
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote:
I didn't bring up the fun argument. My point is that banning direct stable
pushes prevents us from fixing things for our users ASAP when needed. This
is all part of duty, not fun.
And it prevents us from breaking things, with no warning
On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote:
James Antill wrote:
So I did my proposal, which I think will motivate packagers to do the
right thing (giving lots of choice to the users and a reasonable number
of packages to test) and not removing the ability of packagers to do
On Tue, 2010-03-02 at 11:06 +0100, Kevin Kofler wrote:
Peter Jones wrote:
This is the plan that already isn't working.
Is it really not working? Or are we overblowing a minor incident which
didn't even cause all that much trouble and trying to swallow a cure which
is worse than the
A file has been added to the lookaside cache for perl-Locale-Maketext-Lexicon:
a880a00f4d10038498d6e0940476e69b Locale-Maketext-Lexicon-0.78.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Lexicon/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6373/F-11
Modified Files:
.cvsignore perl-Locale-Maketext-Lexicon.spec sources
Log Message:
* Tue Mar 02 2010 Ralf Corsépius corse...@fedoraproject.org -
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Lexicon/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6373/F-12
Modified Files:
.cvsignore perl-Locale-Maketext-Lexicon.spec sources
Log Message:
* Tue Mar 02 2010 Ralf Corsépius corse...@fedoraproject.org -
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
--
= Weekly KDE
+ missing bug ;-)
Wacom tablet does not work in Qt
* https://bugzilla.redhat.com/show_bug.cgi?id=569132
* wacom driver interface changed and broke Qt implementation
* than (with jreznik's help) is going to work on it
o LukasT offered his tablet to test it, KDE SIG lacks
Panu Matilainen pmati...@laiskiainen.org writes:
[...]
Oh yes. Even just a big red REGRESSION button that stops the update from
automatically entering stable no matter what the karma votes happen to be
would be a definite improvement. [...]
Just for completeness, please let's be cautious
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
James Antill ja...@fedoraproject.org writes:
https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29
Regarding this, I don't understand this part:
The idea behind this proposal is that a Fedora user
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote:
Yet, in practice, I still think a lot
more stuff gets backported in our updates repository than in those
backports repositories of other distros.
Probably true (though in the case of Mandriva, maybe less than you'd
expect; it's
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
Doesn't just not running random/unrestricted yum update exactly
encode that option?
If you're happy to live with unsecure software, certainly =)
you can try and cherry-pick security updates, but then you get the
problem where initial
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=520401
Marcela Mašláňová mmasl...@redhat.com 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=513596
Marcela Mašláňová mmasl...@redhat.com changed:
What|Removed |Added
James Antill ja...@fedoraproject.org writes:
[...]
...but they have almost no options if they are happy to stay with
the software that they have.
Doesn't just not running random/unrestricted yum update exactly
encode that option?
No, for two reasons:
1. The user is often informed,
2010/3/2 Adam Williamson awill...@redhat.com:
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
Doesn't just not running random/unrestricted yum update exactly
encode that option?
If you're happy to live with unsecure software, certainly =)
you can try and cherry-pick security
On Tue, 2010-03-02 at 11:17 +0100, Kevin Kofler wrote:
No we don't. There are usually no pushes on weekends.
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the
On 03/02/2010 04:25 AM, Panu Matilainen wrote:
On Tue, 2 Mar 2010, Kevin Kofler wrote:
Doug Ledford wrote:
Fixes my problem
Works for me (someone testing that didn't necessarily have any of the
problem supposedly fixed by this update just noting that their system
still works ok with the
On Tue, 2010-03-02 at 11:55 +0100, Kevin Kofler wrote:
My argument is actually: It doesn't matter how good our infrastructure for
testing fixes is, it'll still not catch everything. Therefore, some
regressions make it into stable anyway, and we want them to get fixed (in
the stable updates)
On Tue, 2 Mar 2010, Jesse Keating wrote:
This is the problem with arguing about a proposal that hasn't even been
written yet. You latch onto the one part you assume will be there that
is the most unreasonable, and use that as a tool to bash the entire
concept of the proposal (which hasn't
On Tue, 2010-03-02 at 06:59 -0600, Bruno Wolff III wrote:
probably could save some churn if the packages were signed with the
same key. (I am not sure if that is true yet; though my understanding is
that there will eventually be one key used to sign any official builds
coming out of koji.)
On Tue, 2010-03-02 at 18:08 +0100, Thomas Moschny wrote:
you can try and cherry-pick security updates, but then you get the
problem where initial release has Foobar 1.0, then Foobar 3.5 gets
shipped in updates, then a security problem emerges and Foobar 3.5-2
with the security fix gets
On Tue, 2010-03-02 at 07:46 +0100, Kevin Kofler wrote:
I just disagree with the claim that ALL updates are
susceptible of breaking things.
Until such time that every update goes through without any breakage, I'm
going to keep on assuming that all updates are susceptible to breaking
things,
So after having heard the nth discussion about tor, I decided to check it out.
I tried installing it on a stripped down f12 box that has no X, or other stuff
unnecessary for routing network packets.
What happened next has me lost for words.
Our dependency chains suck.
Dave
On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote:
James Antill ja...@fedoraproject.org writes:
[...]
...but they have almost no options if they are happy to stay with
the software that they have.
Doesn't just not running random/unrestricted yum update exactly
encode
On Tue, 2 Mar 2010, Jesse Keating wrote:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
tor-0.2.1.23-1200.fc12.i686
This is where things go to hell. Why in the hell is tor-lsb /required/
by tor? LSB isn't really
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
So after having heard the nth discussion about tor, I decided to check it out.
I tried installing it on a stripped down f12 box that has no X, or other stuff
unnecessary for routing network packets.
What happened next has me lost for
On Tue, Mar 02, 2010 at 12:59:52PM -0500, Seth Vidal wrote:
especially considering what it provides :(
repoquery -ql tor-lsb
/etc/rc.d/init.d/tor
/var/run/tor
Check out the post/preun scripts:
%post lsb
/usr/lib/lsb/install_initd %_initrddir/tor || {
cat EOF 2
y
On Tue, 2 Mar 2010, David Malcolm wrote:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
So after having heard the nth discussion about tor, I decided to check it
out.
I tried installing it on a stripped down f12 box that has no X, or other
stuff
unnecessary for routing network
Compose started at Tue Mar 2 09:15:13 UTC 2010
Broken deps for i386
--
anaconda-13.32-1.fc13.i686 requires python-urlgrabber = 0:3.9.1-5
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
doodle-0.6.7-5.fc12.i686
Le mardi 02 mars 2010 à 09:51 -0800, Jesse Keating a écrit :
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
tor-0.2.1.23-1200.fc12.i686
This is where things go to hell. Why in the hell is tor-lsb /required/
by tor?
On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
tor-0.2.1.23-1200.fc12.i686
This is where things go to hell. Why in the hell is tor-lsb /required/
On Tue, 2 Mar 2010, Dave Jones wrote:
On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
tor-0.2.1.23-1200.fc12.i686
This is where things go to hell.
Adam Williamson (awill...@redhat.com) said:
We should make a stand and drop it from Fedora until it's not made up of
bonghits and failure. (haha, yeah. thanks, here all week, etc)
I'm not quite sure why it needs separate lsb/upstart init scripts
anyway. Don't most of our packages just
On 03/02/2010 04:23 AM, Kevin Kofler wrote:
Tom spot Callaway wrote:
* Has ABI/API change (and is a Critical Path package)
Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of
the affected packages should be the criterion, critical path or not is
irrelevant. But
On Tue, 2010-03-02 at 13:25 -0500, Bill Nottingham wrote:
Adam Williamson (awill...@redhat.com) said:
We should make a stand and drop it from Fedora until it's not made up of
bonghits and failure. (haha, yeah. thanks, here all week, etc)
I'm not quite sure why it needs separate
On Tue, 2 Mar 2010, Bill Nottingham wrote:
Adam Williamson (awill...@redhat.com) said:
We should make a stand and drop it from Fedora until it's not made up of
bonghits and failure. (haha, yeah. thanks, here all week, etc)
I'm not quite sure why it needs separate lsb/upstart init scripts
Adam Williamson (awill...@redhat.com) said:
I'm not quite sure why it needs separate lsb/upstart init scripts
anyway. Don't most of our packages just include one initscript with both
bits in the headers?
No. A package could have either a SystemV init script or an upstart job
file.
Author: cweyl
Update of /cvs/extras/rpms/perl-Try-Tiny/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3369
Modified Files:
perl-Try-Tiny.spec
Log Message:
* Tue Mar 02 2010 Chris Weyl cw...@alumni.drew.edu 0.04-1
- update by Fedora::App::MaintainerTools 0.004
-
Author: cweyl
Update of /cvs/extras/rpms/perl-Mouse/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3969
Modified Files:
perl-Mouse.spec sources
Log Message:
* Sun Feb 28 2010 Chris Weyl cw...@alumni.drew.edu 0.50-1
- update by Fedora::App::MaintainerTools 0.004
-
On 03/02/2010 06:15 AM, Kevin Kofler wrote:
X11 is particularly dangerous for this kind of changes, given how low it
is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always scary stuff). The average leaf
package is much less propice to
Jesse Keating jkeat...@redhat.com writes:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
tor-0.2.1.23-1200.fc12.i686
This is where things go to hell. Why in the hell is tor-lsb /required/
by tor?
tor-lsb requires
On 03/02/2010 05:15 AM, Kevin Kofler wrote:
Peter Jones wrote:
When you're at the circus watching the clown ride a bicycle across a
high-wire, he's got a safety net. It's not because the circus thinks he's
an incompetent high-wire cyclist - it's because people occasionally make
mistakes, and
Dave Jones da...@redhat.com writes:
(12:24:07:r...@firewall:~)# yum install tor
fwiw; when you can not wait for a fixed redhat-lsb package, do
| yum install tor tor-upstart
Upstart does not have a good way yet to disable/enable service so you
have to edit /etc/init/tor.conf resp.
Adam Williamson awill...@redhat.com writes:
I'm not quite sure why it needs separate lsb/upstart init scripts
anyway.
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio,
On Tue, 2010-03-02 at 20:31 +0100, Enrico Scholz wrote:
Adam Williamson awill...@redhat.com writes:
I'm not quite sure why it needs separate lsb/upstart init scripts
anyway.
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora
Join us on irc.freenode.net #fedora-meeting for this important meeting.
This is Thursday, March 4, 2010 @ 01:00 UTC, which makes it *WEDNESDAY
EVENING* in North America: 20:00 EST, 17:00 PST.
Before each public release Development, QA, and Release Engineering
meet to determine if the release
On 03/02/2010 07:48 PM, Dave Jones wrote:
The tor package is at least fixable.
Over the dead body of the current package maintainer. That's the root of
the problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Dave Jones da...@redhat.com writes:
| yum install tor-core tor-upstart
still no good, because tor-upstart requires tor which requires tor-lsb
which...
thx for noticing this; this requirement is broken and has been fixed
now. I did not noticed it myself because I use yet another instance
===
#fedora-meeting: FESCO (2010-03-02)
===
Meeting started by nirik at 20:00:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-03-02/fesco.2010-03-02-20.00.log.html
Meeting summary
Enrico Scholz (enrico.sch...@informatik.tu-chemnitz.de) said:
I'm not quite sure why it needs separate lsb/upstart init scripts
anyway.
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still
Bill Nottingham (nott...@redhat.com) said:
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
although it does not log anything, does
Bill Nottingham nott...@redhat.com writes:
E.g. assuming I would use the vanilla fedora 'initscripts' package,
then tor would still require[1] syslog, cpio, e2fsprogs, ethtool,
mount, ... although it does not log anything, does not extract/pack
anything, does not format a filesystem, does
Bill Nottingham wrote:
Bill Nottingham (nott...@redhat.com) said:
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
although it does not
On Tue, 2 Mar 2010, Bill Nottingham wrote:
Enrico Scholz (enrico.sch...@informatik.tu-chemnitz.de) said:
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs,
On Tue, Mar 02, 2010 at 02:21:55PM -0500, Seth Vidal wrote:
On Tue, 2 Mar 2010, Enrico Scholz wrote:
Jesse Keating jkeat...@redhat.com writes:
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
-- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
Paul Wouters p...@xelerance.com writes:
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
although it does not log anything, does not
On Tue, 2 Mar 2010, Enrico Scholz wrote:
It does not log anything because Enrico broke logging in tor package.
Not that this was the reason, but it is the upstream setup to have
logging disabled. Your comment is unrelated to this discussion because
logging can be done into a file and does
2010/2/28 Thomas Spura spur...@students.uni-mainz.de:
Am Samstag, den 27.02.2010, 22:00 +0100 schrieb Michał Piotrowski:
W dniu 27 lutego 2010 21:51 użytkownik Michał Piotrowski
mkkp...@gmail.com napisał:
2010/2/27 Toshio Kuratomi a.bad...@gmail.com:
Could you please file a bug at
Frank Ch. Eigler wrote:
OK, but then we're not talking about the person who's happy to stay
with the software they have, but about a more typical person who is
not too risk-averse and is willing to consider unsolicited updates.
Those are different dudes.
The person who's not willing to do any
James Antill wrote:
...but it has the same problem. But IMNSHO this isn't a problem, you
are arguing that people specifically hit by problem X can goto the
updates-testing (or whatever it's called) repo. and get a fix for it.
Anyone not affected doesn't have to risk that update breaking
Adam Williamson wrote:
Oh, I see. You're inferring a cause where there's no reason to. I didn't
realize that.
What other reasons do you consider then? Pure chance? Doesn't look very
likely to me. It's much more likely the reason Mandriva provides fewer new
versions is because of the split
Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
I consider that a serious design flaw in KDE and a strong argument against
releasing any KDE updates to stable releases other than fixes for serious bugs.
The only practical way to keep up with the Fedora
Adam Williamson wrote:
you can try and cherry-pick security updates, but then you get the
problem where initial release has Foobar 1.0, then Foobar 3.5 gets
shipped in updates, then a security problem emerges and Foobar 3.5-2
with the security fix gets shipped in updates. You now have a choice
Mike McGrath wrote:
You can't assume that people are only using software we ship. If someone
is using software they've custom developed (think a webapp). We've now
forced them to do work. There's several use cases here, people building
and shipping appliances, webapps, etc. Why would
Peter Jones wrote:
It means we have to update even more software seems like a reason /not/
to ship an update that isn't a bugfix or security fix. Not a reason it
*should* be done.
1. Nowhere was it said the ABI change is NOT a bugfix or security fix. Even
security fixes can require ABI bumps,
Jesse Keating wrote:
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
I consider that a serious design flaw in KDE and a strong argument
against releasing any KDE updates to stable releases
James Antill wrote:
The one minor incident being where the project leader had to post to
the world that we'd screwed it up,
Well, I think he overblew it too. ;-) But he just wanted to get the message
out so people can fix it more easily. Still, I don't see how it's a major
issue. The vast
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
You and everyone else, please stop proposing Rawhide as the solution for me
and people who want the same update everything that doesn't break things
policy, it does NOT fit our usecase at all!
If you don't like rawhide for that use
Peter Jones wrote:
To categorize our analogies, mine is an analogy for Fedora, yours is an
analogy for your desktop machine. If you feel like running new untested
packages on your desktop machine, that's fine, we've got rawhide (and
updates-testing) for that. You can also feel free to
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the weekend off.
Well, I'm around on the weekends and the lack of update pushes for the whole
Peter Jones wrote:
On 03/02/2010 06:15 AM, Kevin Kofler wrote:
X11 is particularly dangerous for this kind of changes, given how low
it is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always scary stuff). The average
leaf package is
Jesse Keating wrote:
If you don't like rawhide for that use case, find another operating
system.
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
I'm tired of waiting for many many hours while we try to compose out
On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
But the problem is what to do if the testing ALREADY failed. Then the best
strategy is to fix the problem ASAP, bypassing testing this time, to get the
regression out of the way.
So testing failed, ergo the best way to fix it is to
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the weekend off.
Well, I'm around
Jesse Keating wrote:
No data in the bodhi ticket.
Rpm changelog says Upstream update
This sucks. While it's fine for the RPM changelog to say that, it'd need
something more useful in the update notes, at which point the maintainer
would also have noticed the futility of this particular
On Tue, Mar 02, 2010 at 05:19:03PM -0800, Jesse Keating wrote:
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
On the other hand, your usecase has a solution, it's called CentOS.
Wrong answer. Fedora can provide rapid adoption of new technology in
it's 6 month release cycle. It can
Eric Sandeen wrote:
Should be easy to fix (but too bad doing it that way results in such
punishment!)
As far as I can tell, the package is not compliant with our packaging
guidelines (see the guidelines for initscripts) and as such can be fixed by
any provenpackager.
Kevin Kofler
--
On Tue, 2 Mar 2010, Jesse Keating wrote:
Ok... removing deprecated uses is a questionable at best update, but
here is the kicker. The perl in F11 is perl-5.10.0-82.fc11. So these
functions aren't actually deprecated in F11. So... why is this update
going out? What possible benefit does
Paul Wouters wrote:
As noted before, the issue here is the Enrico is packging his tor
package, going against the desires of both Fedora guidelines and Tor
upstream.
It's really that Enrico is inventing his own baroque packaging system for
initscripts, with a bizarre mess of subpackages, when
On Tue, 2 Mar 2010, Matthew Woehlke wrote:
Jesse Keating wrote:
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
You and everyone else, please stop proposing Rawhide as the solution for me
and people who want the same update everything that doesn't break things
policy, it does NOT
1 - 100 of 165 matches
Mail list logo
