A file has been added to the lookaside cache for perl-HTTP-Body:
926414bd380f7e626ac72881fc537de1 HTTP-Body-1.07.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/l
On Wed, 2010-03-03 at 01:25 -0500, James Antill wrote:
> On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
> > 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
Jon Masters wrote:
> I just did a SPARC install (thanks to Dennis for the assistance too) and
> elected only for a very minimal install. I then decided to add GNOME
> bits just to see what worked for curiosity. I did an "yum install
> gnome-desktop", thinking this would pull in nautilus, etc.
>
>
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
> We've made a mess and as a member of fesco I'd expect you to be helping in
> cleaning up the mess, not making it worse b/c fesco HAS to be about the
> long term growth and sustainability of fedora.
I'm starting to think this thread needs a
On Wed, 2010-03-03 at 02:44 -0500, Jon Masters wrote:
> I just did a SPARC install (thanks to Dennis for the assistance too) and
> elected only for a very minimal install. I then decided to add GNOME
> bits just to see what worked for curiosity. I did an "yum install
> gnome-desktop", thinking thi
Jesse Keating wrote:
> This I believe to be the crux of the problem. When multiple updates go
> out that break large or important segments of our user base, many of us
> see a problem. You however seem to think it's "just fine". Many of us
> would rather put out a better operating system, and to
Folks,
I just did a SPARC install (thanks to Dennis for the assistance too) and
elected only for a very minimal install. I then decided to add GNOME
bits just to see what worked for curiosity. I did an "yum install
gnome-desktop", thinking this would pull in nautilus, etc.
I don't think this is a
On Tue, Mar 2, 2010 at 9:25 PM, Iain Arnell wrote:
> On Wed, Mar 3, 2010 at 5:53 AM, Kevin Kofler wrote:
>> If they require a minimum version which didn't actually change anything
>> instead of the actual minimum required version, they're broken and need to
>> be fixed.
Many CPAN authors are ver
On Wed, 2010-03-03 at 02:11 -0500, Orcan Ogetbil wrote:
> On Tue, Mar 2, 2010 at 8:29 PM, 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
On Tue, 2010-03-02 at 17:52 -0800, Jesse Keating wrote:
> 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
On 03/03/2010 07:28 AM, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Kevin Kofler wrote:
>
>> Seth Vidal wrote:
>>> At the risk of complicating the world would it make any sense for us to
>>> have (in increasing order of importance)
>>>
>>> updates-testing
>>> updates
>>> updates-important
>>>
>>> p
On Tue, Mar 2, 2010 at 8:29 PM, 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?
How do you know
On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> Why? Because you say so? We aren't doing that stuff now and things are
> working just fine, thank you very much! We don't HAVE to change anything at
> all!
>
This I believe to be the crux of the problem. When multiple updates go
out that
Seth Vidal wrote:
> And stages non-critical/important updates so our QA team can test and
> check them over more thoroughly and align testing goals and days to help
> foster and create a more active and involved testing infrastructure.
Congratulations for that sentence full of technical jargon des
James Antill wrote:
> This isn't a hard problem, 3.0 should then be marked as a security
> update.
But the case we're discussing is that 3.0 was pushed long before it was
known that it happens to fix a security vulnerability. We're not going to
arbitrarily push another update and call it "secur
James Antill wrote:
> On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
>> Well, I see where you're getting to now, but this is really not what
>> updates-testing is for! Updates-testing is for TESTING updates, not for
>> being used as production by some users, even those who want more update
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
>> At the risk of complicating the world would it make any sense for us to
>> have (in increasing order of importance)
>>
>> updates-testing
>> updates
>> updates-important
>>
>> packages that are security or critical go from updates-te
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
> 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
> >
Seth Vidal wrote:
> At the risk of complicating the world would it make any sense for us to
> have (in increasing order of importance)
>
> updates-testing
> updates
> updates-important
>
> packages that are security or critical go from updates-testing to
> updates-important - and that happens as
On Tue, 2 Mar 2010, Jesse Keating wrote:
> On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
>> The issue right now appears to be the same as when we have a critical
>> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
>> in updates-testing.
>
> I don't know if this will
On 03/03/2010 05:54 AM, Kevin Kofler wrote:
> Ralf Corsepius wrote:
>
>> On 03/03/2010 05:17 AM, Jesse Keating wrote:
>>> On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't
On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
> The issue right now appears to be the same as when we have a critical
> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
> in updates-testing.
I don't know if this will help. Once a release has gotten a number of
upd
On Tue, Mar 2, 2010 at 10:54 PM, Kevin Kofler wrote:
>
> Yet another perfect example of an update which should have been pushed
> directly to stable.
No, it's an example of an update that should have been pushed to
updates-testing sooner...
--
Jeff Ollie
--
devel mailing list
devel@lists.fedor
On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > Users don't get a constant firehose of updates they are basically
> > forced to install, a lot more packages should spend a lot more time in
> > testing (thus. the user can choose to get the updates or updates-testing
On Wed, Mar 3, 2010 at 5:53 AM, Kevin Kofler wrote:
> If they require a minimum version which didn't actually change anything
> instead of the actual minimum required version, they're broken and need to
> be fixed.
Maybe it doesn't change anything for you, but if I write an
application that uses
On Tue, 2 Mar 2010, Toshio Kuratomi wrote:
>> the suggestion I had made at fudcon went something like this:
>>
>> 1. all packages being put in as updates would need to be marked as per
>> the type of update. the default is 'trivial'. Options might include: new
>> pkg, trivial, feature, bugfix, s
On Tue, 2010-03-02 at 20:31 +0100, Enrico Scholz wrote:
> Adam Williamson 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' pack
Ralf Corsepius wrote:
> On 03/03/2010 05:17 AM, Jesse Keating wrote:
>> On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
>>> Where is the mock update?
>>>
>>> It's been nearly 2 weeks since you've promissed to do so, but this
>>> hasn't happened.
>>>
>>> There still are no mock configurati
Ralf Corsepius wrote:
> Cpan is being used to keep a perl-installation "current". Running it on
> Fedora (or other system which come with a vendor supplied perl),
> replaces all "non-current" perl-modules with those which are marked
> "current" in CPAN.
We don't support third-party packages, and e
Jesse Keating wrote:
> did a poor job in stating our goals for the operating system, and just
> hoped that our maintainers would see things the way we saw them.
Why should they see them that way rather than the right way? ;-)
> Unfortunately that doesn't seem to be the case, and the "anything goe
Mike McGrath wrote:
> I know they do. I'm saying they shouldn't. Yes, we'll fail sometimes.
> That's not to say it shouldn't be a goal. I updated KDE just today and it
> left my taskbar all messed up [1]
While definitely annoying, I don't think that's what's going to keep you
from doing your w
On 03/03/2010 05:17 AM, Jesse Keating wrote:
> On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
>> Where is the mock update?
>>
>> It's been nearly 2 weeks since you've promissed to do so, but this
>> hasn't happened.
>>
>> There still are no mock configurations providing setups for fedora-
On 03/03/2010 05:13 AM, R P Herrold wrote:
> On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>
>> Wait until you will want to address a "serious/critical" bugfix to a
>> perl-module which carries a dependency on a perl-module you haven't kept
>> in sync with CPAN => You'd have to resort to either "faste
On Wed, 2010-03-03 at 04:52 +0100, Kevin Kofler wrote:
> Sure it was, there were 2 models before the merge, and one resulting model,
> which happens to be close to the better one (the Extras one). The Core model
> wasn't lost entirely, its good points persisted, e.g. there's an updates-
> testing
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> 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
> > a
On 03/03/2010 05:04 AM, Chris Adams wrote:
> Once upon a time, Ralf Corsepius said:
>> Cpan is being used to keep a perl-installation "current".
>
> Trying to mix CPAN and RPM managed perl modules is a recipie for
> disaster already.
Right, but this doesn't invalidate trying to help keeping the im
On Tue, 2010-03-02 at 19:55 -0600, Matthew Woehlke wrote:
>
> Okay, I have to ask: why are you right and Kevin is wrong? What makes
> your vision of Fedora more worthy than his? (Especially when his is the
> apparent incumbent?)
Nothing actually and that's the point I'm making. Without guidan
On Wed, 2010-03-03 at 02:52 +0100, Kevin Kofler wrote:
> 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!
Your baby is my bathwater. I don't want the operating system you're
trying to build. If you feel that there is
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
> Where is the mock update?
>
> It's been nearly 2 weeks since you've promissed to do so, but this
> hasn't happened.
>
> There still are no mock configurations providing setups for fedora-13
> (/etc/mock/fedora-13-{i386,x86_64}.cfg)
mo
On Wed, 3 Mar 2010, Ralf Corsepius wrote:
> Wait until you will want to address a "serious/critical" bugfix to a
> perl-module which carries a dependency on a perl-module you haven't kept
> in sync with CPAN => You'd have to resort to either "fastestly" upgrade
> a series of perl-modules or resort
Doug Ledford wrote:
> That or we would have to go with another alternative entirely. People
> have (well, to be fair mainly James, but he's right I think) pointed
> Kevin at rawhide time and time again. And Kevin has pointed out (also
> rightly) that rawhide isn't really consumable. So, we fix t
Once upon a time, Ralf Corsepius said:
> Cpan is being used to keep a perl-installation "current".
Trying to mix CPAN and RPM managed perl modules is a recipie for
disaster already. That's not a good reason for a meaningless update.
> > I update when there's a bugfix that
> > affects my platfor
Once upon a time, Kevin Kofler said:
> What I said was "We're filling a niche" as in "Fedora is filling a niche".
> This is not saying who is behind that (I'd say it just de facto happened,
> without anybody in particular initiating the process) nor whose niche is
> being filled (which shouldn'
On Tue, Mar 02, 2010 at 09:07:29PM -0500, Seth Vidal wrote:
>
>
> 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 i
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
> Again, I fail to see that mess. To me we're actually doing a great job!
>
>> We've made a mess and as a member of fesco I'd expect you to be helping in
>> cleaning up the mess, not making it worse b/c fesco HAS to be about the
>> long
Seth Vidal wrote:
> Winning implies competition. That wasn't the case.
Sure it was, there were 2 models before the merge, and one resulting model,
which happens to be close to the better one (the Extras one). The Core model
wasn't lost entirely, its good points persisted, e.g. there's an updates
On 03/03/2010 04:24 AM, Chris Adams wrote:
> Once upon a time, Ralf Corsepius said:
>> On 03/03/2010 02:29 AM, Jesse Keating wrote:
>>> What possible benefit does the user get from this?
>> Keeping the rpms in sync with CPAN.
>
> What is the benefit to the user in keeping the RPMS in sync with CPA
Chris Adams wrote:
> Who is the "we"?
What I said was "We're filling a niche" as in "Fedora is filling a niche".
This is not saying who is behind that (I'd say it just de facto happened,
without anybody in particular initiating the process) nor whose niche is
being filled (which shouldn't matte
Seth Vidal wrote:
> 2. We would issue security updates whenever they happened. Issue bugfix
> updates once every 2 weeks. Everything else once a month.
And make regression fixes wait for 2 weeks? Very bad plan. (And no matter
how much testing you do, there will ALWAYS be regressions discovered in
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
>> I do not agree Kevin's view is incumbent. I think what's happened is we
>> exploded in size when extras came in and when we merged core and extras
>> and we lost control over the process and over assimilating what was the
>> CORE pro
Jesse Keating wrote:
> Except there aren't enough key people available on the weekend to clean
> up the crap if something goes wrong.
On the other hand, several of our volunteer packagers are more likely to be
around and have time to fix things on the weekend than during workdays. (I
was one of
On 03/02/2010 08:55 PM, 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,
Seth Vidal wrote:
> I do not agree Kevin's view is incumbent. I think what's happened is we
> exploded in size when extras came in and when we merged core and extras
> and we lost control over the process and over assimilating what was the
> CORE process onto extras.
But the Core process wasn't as
Once upon a time, Kevin Kofler said:
> Chris Adams wrote:
> > Who is this "we" you keep speaking of? When did huge dumps of updates
> > in supposedly stable releases become an official "selling point" of
> > Fedora?
>
> It just happened, de facto. Probably because it's filling a niche other
> d
Once upon a time, Ralf Corsepius said:
> On 03/03/2010 02:29 AM, Jesse Keating wrote:
> > What possible benefit does the user get from this?
> Keeping the rpms in sync with CPAN.
What is the benefit to the user in keeping the RPMS in sync with CPAN?
Nothing of consequence (at least according to t
Chris Adams wrote:
> Who is this "we" you keep speaking of? When did huge dumps of updates
> in supposedly stable releases become an official "selling point" of
> Fedora?
It just happened, de facto. Probably because it's filling a niche other
distros are ignoring.
Kevin Kofler
--
deve
On 03/03/2010 02:55 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> No data in the bodhi ticket.
>>
>> Rpm changelog says "Upstream update"
>
> This sucks.
Your bikeshed ...
> While it's fine for the RPM changelog to say that, it'd need
> something more useful in the update notes, at which point
I think redhat-lsb should be forbideen strictly to be used in official fedora
and rpmfusion package, it's can only be used by third-part sofiware develpers
and packagers who do not familiar with fedora and want their packagers to
support multiple linux platform.
redhat-lsb is an encumbrance for
On 03/02/2010 06:06 PM, Björn Persson wrote:
> 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
On Tue, Mar 2, 2010 at 5:29 PM, Jesse Keating wrote:
> It took me all of about 2 minutes to find a worthless pending update for
> Fedora 11.
Before we get into this, do we have any consensus on empirical
standards for determining what a "worthless" update is? Judging by
the vigorous commentary o
On 02/17/2010 03:16 PM, Jesse Keating wrote:
> On Wed, 2010-02-17 at 05:45 +0100, Ralf Corsepius wrote:
>> Am I correct in assuming, wcorresponding mock setups for and yum
>> mirrorlists reflecting this new setup will be in place in time when
>> these repos go on-line?
>>
>>
>
> yes. MirrorManager
On 03/03/2010 02:29 AM, Jesse Keating wrote:
> It took me all of about 2 minutes to find a worthless pending update for
> Fedora 11.
Hip shot ;)
> https://admin.fedoraproject.org/updates/perl-Locale-Maketext-Lexicon-0.78-1.fc11
>
> No data in the bodhi ticket.
>
> Rpm changelog says "Upstream upda
Once upon a time, Kevin Kofler said:
> 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!
Who is this "we" you keep speaking of? When did huge dumps of updates
in supposedly stable releases become an official "selling p
On Tue, Mar 2, 2010 at 6:52 PM, Kevin Kofler wrote:
> 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 t
Enrico Scholz wrote:
> Upstart does not have a good way yet to disable/enable service so you
> have to edit /etc/init/tor.conf resp. /etc/event.d/tor manually.
Which is one of the reasons why you aren't supposed to use native Upstarts
scripts yet!
We have packaging guidelines to follow for inits
I think redhat-lsb should be forbideen strictly to be used in official fedora
and rpmfusion package, it's can only be used by third-part sofiware develpers
and packagers who do not familiar with fedora and want their packagers to
support multiple linux platform.
redhat-lsb is an encumbrance for
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, i
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, w
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 doe
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, 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
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 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
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 fit our usecase at all!
>
> If you don't
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 byp
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
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
le
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:
> 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 parti
It took me all of about 2 minutes to find a worthless pending update for
Fedora 11.
https://admin.fedoraproject.org/updates/perl-Locale-Maketext-Lexicon-0.78-1.fc11
No data in the bodhi ticket.
Rpm changelog says "Upstream update"
If I google for upstream and look for a changelog, I come to thi
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 us
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
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 stab
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 bu
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 an
James Antill wrote:
> Users don't get a constant firehose of updates they are basically
> forced to install, a lot more packages should spend a lot more time in
> testing (thus. the user can choose to get the updates or updates-testing
> versions).
> How is that not more choice than "here's rawhi
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 other than fixes for
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 cho
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:
> 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 up
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
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
2010/2/28 Thomas Spura :
> Am Samstag, den 27.02.2010, 22:00 +0100 schrieb Michał Piotrowski:
>> W dniu 27 lutego 2010 21:51 użytkownik Michał Piotrowski
>> napisał:
>> > 2010/2/27 Toshio Kuratomi :
>> >> Could you please file a bug at bugzilla.redhat.com to make sure trhe
>> >> maintainer sees th
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 d
Paul Wouters 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 extract/pac
On Tue, Mar 02, 2010 at 02:21:55PM -0500, Seth Vidal wrote:
>
>
> On Tue, 2 Mar 2010, Enrico Scholz wrote:
>
> > Jesse Keating 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
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, e2fspro
Eric Sandeen (sand...@redhat.com) said:
> I'm guessing e2fsprogs may have been sucked in due to the various tools it
> has (had) in its junkbox. Lots of those which are not ext2-specific (blkid
> for example) have been split out or moved to util-linux-ng.
Sort of.
...
* Mon Oct 05 1998 Cristian
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
Bill Nottingham 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 not configure
1 - 100 of 189 matches
Mail list logo
