On Sun, 2010-02-28 at 07:44 +, Terry Barnaby wrote:
> Hi,
>
> In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12,
> that fixes an issue with lirc on 2.6.32 kernels that has been
> submitted to updates-testing.
> This package does not seem to exist there and the link to it
On 28/02/10 08:02, Adam Williamson wrote:
> On Sun, 2010-02-28 at 07:44 +, Terry Barnaby wrote:
>> Hi,
>>
>> In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12,
>> that fixes an issue with lirc on 2.6.32 kernels that has been
>> submitted to updates-testing.
>> This packag
On Sun, 28 Feb 2010 08:10:33 +, Terry wrote:
> On 28/02/10 08:02, Adam Williamson wrote:
> > On Sun, 2010-02-28 at 07:44 +, Terry Barnaby wrote:
> >> Hi,
> >>
> >> In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12,
> >> that fixes an issue with lirc on 2.6.32 kernels
On 27 February 2010 19:31, Jeroen van Meeuwen wrote:
> This sounds interesting, was this a plugin or configuration setting?
> Could this be something people can opt-in to at first?
in /etc/PackageKit/PackageKit.conf, the idea was to set
CheckTestingRepos to true. I'm not sure the code is actually
On Fri, 2010-02-26 at 09:41 -0500, Tom Lane wrote:
> > Some situations where I and others have used direct stable pushes in
> the
> > past and where I think they're really warranted and should be used:
>
> You forgot security fixes. The proposed policy is insane.
+1.
I almost always push my p
On 21.02.2010 02:15, Michael Schwendt wrote:
> Just for kicks, the current
>
> ==
> Broken packages in fedora-updates-12-x86_64:
>
> player-3.0.1-3.fc12.x86_64 requires libml.so.2()(64bit)
> player-3.0.1-3.fc12.x86_64
On Sun, 28 Feb 2010 11:16:27 +0100, Tim wrote:
> On 21.02.2010 02:15, Michael Schwendt wrote:
> > Just for kicks, the current
> >
> > ==
> > Broken packages in fedora-updates-12-x86_64:
> >
> > player-3.0.1-3.fc12.x86_64 re
Le vendredi 26 février 2010 à 21:17 +0100, Hans de Goede a écrit :
> When I started working for Red Hat everyone told me that the most important
> thing is that working for Red Hat should be fun, which I completely agree
> with.
>
> I seriously believe we should also make that an explicit goal f
On Sun, Feb 28, 2010 at 01:23:21AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Speaking as someone who is still on F11, I want the latest software as
> long
> as it doesn't break anything, because most often there are new useful features
> in it.
I think one of the problems is precisely that "
Compose started at Sun Feb 28 08:15:09 UTC 2010
Broken deps for i386
--
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5
efreet-0.5.0.050-5.fc12.
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 the request?
> >
> > Done
> > http
Hi, gentlemen,
For
some time the inclusion of the software Scilab [1] in our repos has been barred
by various dependencies, which were being resolved with time. Currently, the
biggest reason we do not have this
software in our repos is that it relies in a software called JOGL [2].
The
big question
Hi,
On 02/28/2010 03:39 PM, Henrique Junior wrote:
> Hi, gentlemen,
> For some time the inclusion of the software Scilab [1] in our repos has
> been barred by various dependencies, which were being resolved with
> time. Currently, the biggest reason we do not have this software in our
> repos is t
On Sun, 2010-02-28 at 11:43 +0100, Nicolas Mailhot wrote:
> There are things only packagers can fix. Everything else should be
> handled by tools so packagers can focus on the parts where they add real
> value. If a process change puts more burden on all packagers because
> it's easier to ask pack
Hi.
On Mon, 22 Feb 2010 04:40:38 +0100, Kevin Kofler wrote
> built against Qt 4.6 WILL NOT WORK AT ALL with Qt 4.5!!! (This is
> always the case, Qt is backwards- but not forwards- compatible.)
And sometimes not even that. I rather suspect this bug is caused
by the update from 4.5 to 4.6:
https
Compose started at Sun Feb 28 09:15:10 UTC 2010
Broken deps for i386
--
anaconda-13.32-1.fc13.i686 requires python-urlgrabber >= 0:3.9.1-5
balsa-2.4.6-3.fc13.i686 requires libgmime-2.4.so.2
blahtexml-0.6-5.fc12.i686 re
On Sat, 2010-02-27 at 15:21 +, Richard Hughes wrote:
> On 26 February 2010 22:54, Kevin Fenzi wrote:
> > - If stable pushes were more restricted, perhaps that would get us more
> > testing? If someone required a newer version and could easier
> > install/test from updates-testing and provide
On Tue, 2010-02-23 at 19:58 -0500, Jon Masters wrote:
> On Tue, 2010-02-23 at 07:51 +0100, Nicolas Mailhot wrote:
> > Le lundi 22 février 2010 à 19:05 -0800, John Reiser a écrit :
> > > On 02/22/2010 03:07 AM, Nicolas Mailhot wrote:
> > > > There is much worse - it does not let you set the keyboard
Hi,
I want to add to "Sound and Video" in comps.xml
some optional packages which I not own.
v4l2ucp in comps.xml for F11-F14,
ucview for F11-F14, EL5
and gtk-v4l for F13-F14.
Is there any objections to do this?
Alexey Kurov
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
>
> You clearly want to be able to push whatever, whenever (see massive KDE
> updates in supposedly "stable" releases). Others have shown that
> playing fast and loose with updates has consequence
drago01 wrote:
> There has been a draft a while ago which did not result into much
> discussion ..
>
> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>
> Which looks pretty sane to me.
It looks very insane to me:
* only critical bugfixes, security fixes and hardware enablemen
On 02/28/2010 06:25 PM, Kevin Kofler wrote:
> drago01 wrote:
>> There has been a draft a while ago which did not result into much
>> discussion ..
>>
>> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>>
>> Which looks pretty sane to me.
>
> It looks very insane to me:
> * only
Dominik 'Rathann' Mierzejewski wrote:
> I want the latest software as long as it doesn't break anything,
Right, that's exactly what stable releases should be like, and I don't see
why the previous stable release should not get the same treatment as the
current stable. It's still supported, so it
Mike McGrath wrote:
> Then lets fix that. Rolling updating everything isn't the answer to any
> problem.
1. I don't propose to rolling update "everything", but everything which
doesn't break or disrupt things. That's a subtle, but important distinction
(which you seem to be missing)!
2. You're
Mike McGrath wrote:
> Bingo, in this world we'd basically not have F-11 right now. And as soon
> as F13 comes out we'd no longer support F-12. We'd force users to upgrade
> immediately and not give them any options to plan for updates, etc, etc.
>
> I think the divide in this discussion is along
Michael Schwendt wrote:
> Where to start and where to stop with upgrade madness? What may be
> feasible for Gtk, would be a much bigger task for GNOME and other
> frameworks.
So what? We can pull it off for KDE, why would it not be possible for GNOME?
Kevin Kofler
--
devel mailing list
Till Maas wrote:
> No, because there are updates that, e.g. require manual intervention, or
> are more likely to break a lot of stuff. These would make the difference
> between the releases.
Right. (And thanks for your replies further up this subthread, you left me
nothing more to add. ;-) )
> E
Till Maas wrote:
> My proposal: If it passes all AutoQA tests and matches the criteria by
> Kevin Koffler[0], then the update is ok, except that critical path
> packages should be inspected more carefully.
>
> [0]
> [http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html
I think
Mike McGrath wrote:
> So when Fedora 12 came out, we allowed users 7 months to upgrade because
> the latest version of stuff is too unstable for them. At the same time
> we're also forcing them to upgrade to the latest versions of those
> packages in F-11 anyway? I hope you can at least acknowled
(Sorry, I reordered the replies a bit so I can reply to them without
referring back and forth.)
Frank Murphy wrote:
> On 02/27/2010 04:30 PM, Mail Lists wrote:
> an
>>
>> I do want updates. Kernel updates, for example, are very important -
>> they carry many improvements - not just drivers but
On Mon, Mar 01, 2010 at 12:25:01AM +0100, Kevin Kofler wrote:
>drago01 wrote:
>> There has been a draft a while ago which did not result into much
>> discussion ..
>>
>> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>>
>> Which looks pretty sane to me.
>
>It looks very insane
Adam Williamson wrote:
> It seems like extra work for packagers, but in the end it kinda takes the
> pressure off: you only *have* to ship the important fixes to /updates,
> /backports is optional,
That's already a bad thing, users can no longer expect anything, it depends
on the maintainer being
Adam Williamson wrote:
> Yeah, it's not perfect: there are cases where we have, say, a complex
> kernel update which works fine for most people but causes a significant
> regression for some particular bit of hardware. We wouldn't want to put
> that update out, but it's easy for it to get five +1s
- "Paul W. Frields" wrote:
> On Mon, Feb 22, 2010 at 10:06:09PM -0500, Jens Petersen wrote:
> > Perhaps I missed it but I didn't see any clear indication that
> > a Talking Point has to be a Feature. Is that the case?
>
> It doesn't. A Talking Point should be clearly advantageous to the
> l
Ville Skyttä wrote:
> Whether the "provided name" is existing or not is irrelevant, a dependency
> on it can spring to life any time, including at a time when it causes the
> package containing the name to be installed without being explicitly
> asked.
If the provided name did not exist before, no
Paul Frields wrote:
> Turns out my actual text was a bit less stark:
> https://bugzilla.redhat.com/show_bug.cgi?id=543278#c53
> "The sooner we receive feedback, the sooner we'll know whether we can
> release
> this update to the stable distribution. Thanks for participating."
Wow, so you alread
Ralf Corsepius wrote:
> * bugs being closed as "FIXED UPSTREAM/FIXED RAWHIDE" - This kind of
> "resolution" means a bug is not being fixed in the distro. It means the
> maintainer is refusing to fix a bug a reporter is facing. Reporters will
> learn their lessons and leave this kind of maintainers
Toshio Kuratomi wrote:
> On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
>> Once upon a time, Kevin Kofler said:
>>
>> You clearly want to be able to push whatever, whenever (see massive KDE
>> updates in supposedly "stable" releases). Others have shown that
>> playing fast and loos
On Sunday, 28 February 2010 at 11:44, Dodji Seketeli wrote:
> On Sun, Feb 28, 2010 at 01:23:21AM +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > Speaking as someone who is still on F11, I want the latest software
> > as long as it doesn't break anything, because most often there are
> > new use
Ralf Ertzinger wrote:
> On Mon, 22 Feb 2010 04:40:38 +0100, Kevin Kofler wrote
>
>> built against Qt 4.6 WILL NOT WORK AT ALL with Qt 4.5!!! (This is
>> always the case, Qt is backwards- but not forwards- compatible.)
>
> And sometimes not even that. I rather suspect this bug is caused
> by the u
Hans de Goede wrote:
> AFAIK we have had problems like this before with various bits of Xorg
> (iirc) needing the sources of other bits to build.
>
> The "usual" solution for this, is to give a package a -source subpackage,
> which contains the extracted sources (and installs them under
> /usr/src
Josh Boyer wrote:
> We do target daily pushes.
Then that's a good thing, and shouldn't be changed as that old proposed
policy would be trying to do. ;-)
> There are a lot of mitigating factors that sometimes prevent a push
> getting done in 24 hours, [etc.]
OK, got that. I'm not really complain
Mail Lists wrote:
> Kernel should follow mainline stable - as reasonably soon after
> release and our testing as possible.
>
> Core daemons - ditto.
But that's quite different from what that proposed policy mandates.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
I think we need some more experienced java packager to accelerate packaging
scilab, it can be a new feature for F14. Since scilab may be the best
opensource numerical computational software, is there someone interseted in
packaging scilab for fedora?
Regard,
Chen Lei
在2010-03-01?09:22:33，"K
> Still, this is a very evil workaround. Can JOGL really not be fixed to use
> an installed gluegen? Why does it need the source?
Well, the symbiotic relationship between JOGL and Gluegen is because
the Gluegen project is developed by the JOGL project, in principle,
to be used only by JOGL.
By W
2010/2/28 Chen Lei :
> I think we need some more experienced java packager to accelerate packaging
> scilab, it can be a new feature for F14. Since scilab may be the best
> opensource numerical computational software, is there someone interseted in
> packaging scilab for fedora?
>
> Regard,
> Chen
Henrique Junior wrote:
> Well, the symbiotic relationship between JOGL and Gluegen is because
> the Gluegen project is developed by the JOGL project, in principle,
> to be used only by JOGL.
>
> By Wikipedia:
> It was originally developed for JOGL, a Java OpenGL library, although
> the project ha
在2010-03-01?11:00:59，"Henrique?Junior"??写道：
>2010/2/28?Chen?Lei?:
>>?I?think?we?need?some?more?experienced?java?packager?to?accelerate?packaging
>>?scilab,?it?can?be?a?new?feature?for?F14.??Since?scilab?may?be?the?best
>>?opensource?numerical?computational?software,?is?there?someone?interseted?
> >Scilab?is,?in?fact,?in?advanced?packaging?stage,?waiting?for?JOGL.
>
> A lot of java packages need package from scratch or patch(this may be
> difficult if you are not provenpackager, since some package maintainers
> are non-responsive for a long while) for scliab5.2.1.
>
Please give us the f
Kevin Kofler said the following on 02/28/2010 03:41 PM Pacific Time:
> Till Maas wrote:
>> My proposal: If it passes all AutoQA tests and matches the criteria by
>> Kevin Koffler[0], then the update is ok, except that critical path
>> packages should be inspected more carefully.
>>
>> [0]
>> [http:
On Mon, 2010-03-01 at 00:58 +0100, Kevin Kofler wrote:
> Mike McGrath wrote:
> > So when Fedora 12 came out, we allowed users 7 months to upgrade because
> > the latest version of stuff is too unstable for them. At the same time
> > we're also forcing them to upgrade to the latest versions of thos
On 02/27/2010 05:27 PM, Adam Williamson wrote:
> On Sat, 2010-02-27 at 10:57 +0100, Ralf Corsepius wrote:
>
>>> Sorry, I was replying in haste. I should've made clear that I was
>>> talking more in general, and don't have any specific direct knowledge of
>>> the dnssec case. I know of multiple case
lör 2010-02-27 klockan 15:26 +0200 skrev Ville Skyttä:
> there are several ways new
> installed packages can break existing systems, the combined results is that
> it
> is very much possible for newly introduced packages to "automatically break
> existing systems".
It could install a file in
On Sun, 2010-02-28 at 21:30 -0800, John Poelstra wrote:
> Kevin Kofler said the following on 02/28/2010 03:41 PM Pacific Time:
> > Till Maas wrote:
> >> My proposal: If it passes all AutoQA tests and matches the criteria by
> >> Kevin Koffler[0], then the update is ok, except that critical path
> >
54 matches
Mail list logo
