On Sat, Jul 10, 2010 at 12:29 PM, Carl Gaudreault
carl.gaudrea...@gmail.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=531464#c29
I appreciate the effort to be more explicit in your reasoning by
adding an additional comment in response to this out-of-ticket
dicussion.
That being said. I
On Fri, Jul 9, 2010 at 2:49 PM, Matt McCutchen m...@mattmccutchen.net wrote:
On Fri, 2010-07-09 at 23:27 +0200, Andreas Tunek wrote:
I get Empathy crashes all the time, duplicates of
https://bugzilla.redhat.com/show_bug.cgi?id=531464, but this bug is in
WONTFIX status. Anyone know why?
Look
On Fri, Jul 9, 2010 at 3:34 PM, Carl Gaudreault
carl.gaudrea...@gmail.com wrote:
So It seems Carl G. has been closing several bugs across multiple
components without comment recently. Hmm. Not cool.
-jef
I gave the reason why i closed it.
Are you saying that you comment in 27 requesting
On Thu, Jul 8, 2010 at 4:02 PM, David Malcolm dmalc...@redhat.com wrote:
Hope this is helpful
Dave
Is there any hints on expected gotchas that we can look out for.
Deprecations or API changes of significant merit?
-jef
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Jun 9, 2010 at 8:31 AM, Adam Miller
maxamill...@fedoraproject.org wrote:
Did we really need to
take some raw numbers that Luke was kind enough to put together and make it
into some sort of QA methods holy war?
The lesson here is that for data mining to make sense there must a
consensus
On Mon, Jun 7, 2010 at 4:18 PM, Michael Cronenworth m...@cchtml.com wrote:
Due to bug 493565[1], fuse needs to be updated. This bug has been around for
a very long time, and no one can seem to reach the fuse maintainer. I see
this bug daily on one system and I'm tired of it. Can anyone help?
On Wed, Jun 2, 2010 at 5:21 AM, Patrice Dumas pertu...@free.fr wrote:
That being said, it seems that the new init system, systemd is already in
the pipe. Doing a policy for an obsolete technology may be some time
lost. Maybe even better would be preparing a policy for systemd scripts
than
On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering mzerq...@0pointer.de wrote:
Handling this with systemd is very easy: you can just drop in a file in
/etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same
package. And then, if something that is not systemd is booted it will
only
On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth m...@cchtml.com wrote:
Lennart Poettering wrote:
If you can make everyone move away from sysv to something else, then by
all means I'll do my best to aid in patches, but I don't have much
confidence since everything that has been said about
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson awill...@redhat.com wrote:
Ah. It's a shame it wasn't put up for consideration as a release
blocker. Obviously the rather peremptory response from Jakub didn't help
with that...
Would the flag concept for blocker status that Jesse was championing
On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson awill...@redhat.com wrote:
It's a bit intangible and not entirely predicated on whether we're using
the keyword or flag setup, I think. Currently when we're considering
bugs we use a search that excludes closed bugs,
In either case, I would
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
Well, that depends on configuration.
In systemd you can choose individually for each unit whether you want to
allow it to continue run processes on shut down, whether you want the
main process killed, the process
On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
Please, judge systemd on technical grounds, don't judge it on political,
or emotional grounds.
I'll publish the numbers of a 100% socket-activated boot soon.
I would love to have the necessary data to have an
On Tue, May 25, 2010 at 9:09 AM, Jesse Keating jkeat...@redhat.com wrote:
Right now, it's not about speed. Speed is one thing, and somewhat
important. But doing it right is also important. Make it right, then
make it fast, because if you try to make it fast first, you'll often be
doing it
On Tue, May 18, 2010 at 3:00 PM, Rahul Sundaram methe...@gmail.com wrote:
While I understand the decision behind enabling updates-testing repo by
default, I think it should be turned off much earlier, perhaps during
the beta release phase. Due to the workflow I follow, one of the
problems
On Mon, May 10, 2010 at 10:14 PM, James Antill ja...@fedoraproject.org wrote:
6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm
12M hanazono-fonts-20100222-2.fc13.noarch.rpm
48M xmoto-0.5.3-1.fc13.x86_64.rpm
260M wesnoth-data-1.8.1-1.fc13.noarch.rpm
318M openarena-0.8.5-1.fc13.noarch.rpm
...the last
On Tue, May 11, 2010 at 8:46 AM, Kevin Fenzi ke...@scrye.com wrote:
It's unfortunate that these two big packages didn't make it into the
base repo, but such is life. ;(
As this is the first time we've done the early branching... I
certainly expect mistakes right around the time of the branch
On Tue, May 11, 2010 at 10:57 AM, Jon Ciesla l...@jcomserv.net wrote:
Well, no, not if there's an easy way to find the existing stuff. Is
there a way to extract this info from Bugzilla? I'd stick that query in
my bookmarks and peek at it every couple days.
Indeed. I'd like to use my proven
On Tue, May 11, 2010 at 1:47 AM, Chen Lei supercyp...@gmail.com wrote:
It seems a lot of trivial packages in fedora are unmaintained for a long
I dispute your claim that there are a lot.
Yes we are going to have things fall through the cracks. But I've seen
no analysis and no tools which would
On Tue, May 11, 2010 at 2:14 PM, Till Maas opensou...@till.name wrote:
I use the non-responsive process or active nagging quite a lot, since I
often stumble upon such packages (it already happend twice to youtube-dl
that the current maintainer did not have enough time). Thankfully the
start of
On Tue, May 11, 2010 at 3:10 PM, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
This probably means at least a rudimentary application testing rig
and a discipline that identifies and deals with distressed packages.
Does the ongoing work with AutoQA provide the solution you are looking
On Mon, May 10, 2010 at 2:48 AM, Adam Williamson awill...@redhat.com wrote:
That's the wrong argument. We all know why we _can't_ make it just work,
but that doesn't excuse us.
You are right. The answer is clearly to export US legal rules to the
rest of the world so we can have an equally
On Thu, May 6, 2010 at 3:01 PM, Rudolf Kastl che...@gmail.com wrote:
one of the questions raised in the meeting posted by mcepl was... why
dont those people leave if they are unhappy. simple... they put alot
sweat blood and tears into a project, and they have friends... with
the development
On Wed, May 5, 2010 at 9:28 AM, Eric Sandeen sand...@redhat.com wrote:
Agreed, I'm tired of (insert random benchmarking site) saying OH NOES!
Fedora got SLOWER AGAIN! when it's really a lot of debug going on.
Stating something like this clearly on login install would be nice,
not just for
On Wed, May 5, 2010 at 9:54 AM, Frank Ch. Eigler f...@redhat.com wrote:
Good point. Clearly though one can't delay the setting of the final
release behaviors too long, or else *those* won't get tested.
I'm not arguing about what that point should be. I'm just saying that
this glib debugging
On Wed, May 5, 2010 at 1:34 PM, Orcan Ogetbil oget.fed...@gmail.com wrote:
I understand. But please respect what others are thinking. I do see a
problem in abrt that it wastes my time.
It's not possible for you to simply ignore the abrt bugs? I filter
the [abrt] ticket email into a separate
On Wed, May 5, 2010 at 2:12 PM, Orcan Ogetbil oget.fed...@gmail.com wrote:
An anonymous database is easy to ignore by packagers. I fear that that
might turn to something as useless as pulseaudio.
The little jab at pulseaudio is extremely inappropriate and absolutely
non-constructive to the
On Tue, May 4, 2010 at 9:50 AM, Jesse Keating jkeat...@redhat.com wrote:
If the breakage was more of a functional break and not a dep break,
that's where automated testing comes in, and we grow the automated
functional testing of updates so that if an update comes along we can
detect the
On Mon, May 3, 2010 at 3:07 AM, Alex Hudson fed...@alexhudson.com wrote:
I think it's a bit disingenuous to talk about prevailing opinion of the
mailing list otherwise; to me a lot of the discussion looks an awful lot
like a vocal minority,
Be careful about meeting subjective opinion with
On Mon, May 3, 2010 at 10:00 AM, Chris Adams cmad...@hiwaay.net wrote:
Thanks a lot Kevin; you showed a lot of class trying to stir up the same
arguments that you stirred up before. Maybe the reason you lost votes
is that a lot of people just don't agree with you; pouting about that
won't
On Sun, May 2, 2010 at 7:25 AM, yersinia yersinia.spi...@gmail.com wrote:
Look interesting from a QA point of view.
How exactly is this interesting from a QA pov in Fedora? Smolt
profiles I can understand being useful for QA because it gives us some
ability to look for commonalities when
On Mon, May 3, 2010 at 12:03 PM, Thomas Janssen
thom...@fedoraproject.org wrote:
- Superb information for us packagers if and how much (of course not
the correct value) users use the software i package
It may or may not be superb information...but you haven't told me how
collecting this
On Mon, May 3, 2010 at 12:19 PM, yersinia yersinia.spi...@gmail.com wrote:
Sure, I can try. If one software is used many time from many user, directly
or indirectly, and it have not such many problems (e.g bug open on bugzilla
for example ), well this could guide to the decision of the
On Mon, May 3, 2010 at 1:06 PM, Thomas Janssen
thom...@fedoraproject.org wrote:
To make sense it should be on by default.
Good luck with that. I strongly suggest that any usage which only
makes sense with on by default is not a usage you can rely on as a
strawman.
The popularity application
On Thu, Apr 29, 2010 at 10:24 AM, Christopher Aillon cail...@redhat.com wrote:
But, I'll re-iterate what Jan told you earlier in the thread that we've
been working on it with upstream and have been for a while, and it's a
HUGE undertaking. We've already made significant progress and have
On Thu, Apr 29, 2010 at 9:58 AM, Christopher Aillon cail...@redhat.com wrote:
Anyway, it's unfortunate that this really isn't done more often. I
really think that as a project, we'd be doing a lot better if we
mandated upstream review before applying patches to any package if you
aren't an
On Mon, Apr 26, 2010 at 10:09 PM, Luming Yu luming...@gmail.com wrote:
God must have fixed the problem for us. :-)
or some mysterious things happened with the web site
offering the mysterious video, which sometimes working, sometimes
not working
It's most likely a connectivity problem
On Sun, Apr 25, 2010 at 5:41 PM, Luming Yu luming...@gmail.com wrote:
Hmm,... tried ff 3.6.4, not working...
Just fyi, the flash video in question works fine for me in a fully
updated 64bit F13 beta using the 64bit flash using the tarball from
the adobe website
On Thu, Apr 22, 2010 at 11:09 AM, Jim Meyering j...@meyering.net wrote:
I hope it's just me...
but I was very dismayed to find that today's F13 update (which pulled
in a lot of changes) hosed my laptop.
I have two 64bit F13 laptops... fully updated with updates-testing
except for
On Tue, Apr 20, 2010 at 9:18 AM, Mark Bidewell mbide...@gmail.com wrote:
I have been dealing with this issue in the context of Ubuntu Lucid,
however since it can be reproduced under F13 Beta I thought it would
be wise to raise it here. In some cases, gnome-games do not properly
fall back to
On Tue, Apr 20, 2010 at 9:32 AM, drago01 drag...@gmail.com wrote:
Clutter is not targeting mesa's software rastersizer ... so clutter
upstream do not really care if it works without any hardware support
or not.
Which is all fine for an optional component gnome-shell which
explicitly states it
On Tue, Apr 20, 2010 at 10:02 AM, drago01 drag...@gmail.com wrote:
It is just a game ...
Ever tried to run compiz on software? (hint: desktop effects will tell
you to come back once you are using a 3D driver).
Ah...see here's the thing... this application doesn't actually tell
you
I'm assuming everyone here has heard of Lernid, the little classroom
ui that Jono Bacon original put together.
I got lernid trunk up and running on Fedora 13. All the prerequisites
are in place. it connects to the Ubuntu events.
My understanding is that lernid just needs a hardcoded url from
On Wed, Apr 14, 2010 at 6:09 AM, Jon Ciesla l...@jcomserv.net wrote:
I agree, and thought Seth made his point well. I typically consider the
set of things in Fedora I need to worry about to be the set of bugs
assigned to me, plus the ones I've files, plus any FTFFS or broken deps
I'm aware
On Wed, Apr 14, 2010 at 11:53 AM, Karel Klic kk...@redhat.com wrote:
Please file a RFE in Bugzilla, and include the filename mask(s) marking
the files you want to exclude. I think it will be something like:
/usr/lib/python2.6/site-packages/scipy/*/examples/*.py
do you want that in Fedora
So I'm maintaining matplotlib and scipy.. which effectively allows
scientists to pretend they are programmers
So matplotlib includes a large selection of examples to read over as
documentation. Some of these example do some crazy complicated things
which make use of matplotlib and wont work out
Here's the notice that I'm taking ownership of orphaned inkscape in EPEL 4/5.
-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Apr 9, 2010 at 3:10 PM, Matt McCutchen m...@mattmccutchen.net wrote:
Thoughts? Am I missing something?
When someone is publishing updates and putting them into testing
specifically to address known bugs... and they get the fix wrong in
some way... I think its perfectly acceptable to
On Fri, Apr 9, 2010 at 3:57 PM, Matt McCutchen m...@mattmccutchen.net wrote:
The comparison to bugs is not valid. A bug is the same bug until it is
fixed. An update consisting of different packages is a different
update.
What? We don't tag testing-updates with an ID. Testing packages...are
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen m...@mattmccutchen.net wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=573510#c2
How hard is it to use Bodhi properly?
And then at the bottom of the bug report... there's newer
packages...and newer links.
There's no value in commenting on
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen m...@mattmccutchen.net wrote:
It confuses the people who put in the effort to test your packages. I
updated to NetworkManager-0.8.0-4.git20100325.fc12.x86_64 and hit bugs
576925 and 578141. I wanted to leave negative feedback on the update,
but
On Fri, Apr 9, 2010 at 4:09 PM, Matt McCutchen m...@mattmccutchen.net wrote:
Better comparison: Bugzilla does not allow the content of an attachment
to be edited once it is submitted. Instead, people submit a new
attachment and obsolete the old one.
Yes and koji keeps builds around to even
On Fri, Apr 9, 2010 at 4:20 PM, Matt McCutchen m...@mattmccutchen.net wrote:
There's another possible explanation for that policy: users who don't
participate in testing know that any update with an ID went to stable
and won't be distracted by references to IDs of testing updates in
various
On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski or...@cora.nwra.com wrote:
Looks like the geos update for F-12 bumped the soname:
python-basemap-0:0.99.2-6.fc12.i686
Sigh thanks for the heads up. I'll push a rebuild now.
-jefNot to be picky, but it sure would be nice if there was some way
On Tue, Apr 6, 2010 at 2:49 PM, Adam Williamson awill...@redhat.com wrote:
That seems strange, it should use dracut, not mkinitrd at all? Is this
an F13 system?
dracut package provides /sbin/mkinitrd
and you'll see that new-kernel-pkg gets called with --mkinitrd as well
as --dracut in the
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura
spur...@students.uni-mainz.de wrote:
Are you sure, packages like gnuplot-py *have* to get rebuild?
Your first programm that causes troubles 'python-basemap' is not noarch.
A compiled programm needs a rebuild, but a programm with just python
files
On Fri, Apr 2, 2010 at 7:54 AM, David Malcolm dmalc...@redhat.com wrote:
Doing so now and forcing a rebuild _might_ help isolate the change. I
don't know if that's a good idea at this stage for F-13, though.
Hope this is helpful; I haven't had enough coffee yet today so I may be
missing
Found this today with python-basemap. Numpy 1.4.0 introduced some ABI
changes. Anything that compiles against numpy and hasn't been rebuilt
since Numpy 1.40 was introduced in late January may need to be rebuilt
in F-13 and rawhide.
Just a friendly heads up.
I'm fixing python-basemap now and
On Wed, Mar 31, 2010 at 4:49 AM, Rahul Sundaram methe...@gmail.com wrote:
That's just your perception and I don't see any consensus on that. The
bug is fixed and fixed only in the development branch and this is a
fairly common thing to do for upstream projects as well as
distributions.
On Wed, Mar 31, 2010 at 8:15 AM, Juha Tuomala juha.tuom...@iki.fi wrote:
that's why there is 'clone' functionality. Use it.
Are you saying that we should all clone every report that we all would
normally close as fixed rawhide?
-jef
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Mar 31, 2010 at 8:29 AM, Juha Tuomala juha.tuom...@iki.fi wrote:
On Wed, 31 Mar 2010, Jeff Spaleta wrote:
Are you saying that we should all clone every report that we all would
normally close as fixed rawhide?
Are you saying, that everyone facing that bug, should search from every
On Wed, Mar 31, 2010 at 12:30 PM, Juha Tuomala juha.tuom...@iki.fi wrote:
Because it's a database of release's bugs, not a todo list?
Bugzilla has multiple uses. The upstream project goes to some length
describing it as a flexible tool. We in fact use it for multiple
purposes. We use it for
On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson awill...@redhat.com wrote:
I don't think there's ever an absolute answer to this question.
Sometimes it makes more sense for the original reporter to report
upstream - in which case the maintainer should politely ask them to;
sometimes it makes
101 - 163 of 163 matches
Mail list logo
