On 01/18/2010 12:58 AM, Tom Lane wrote:
Tony Nelsontonynel...@georgeanelson.com writes:
On 10-01-17 12:32:17, Mail Lists wrote:
Someone else asked this earlier - but why do users need the
debug-info packages - only the debugger looking at the tracebacks
needs this. So seems installing the
On Sun, 2010-01-17 at 13:02 +, Camilo Mesias wrote:
Having said that the things that can be done with a mere backtrace are
limited. I would almost always need to look at the corefile too, and
would be frustrated if it wasn't available. Perhaps the workflow that
starts with ABRT providing
On Mon, 2010-01-18 at 09:31 +0100, Alexander Larsson wrote:
On Sun, 2010-01-17 at 13:02 +, Camilo Mesias wrote:
Having said that the things that can be done with a mere backtrace
are
limited. I would almost always need to look at the corefile too, and
would be frustrated if it wasn't
On Mon, 18 Jan 2010 09:06:13 +0100, Jiri Moskovcak wrote:
On 01/17/2010 06:49 PM, Camilo Mesias wrote:
This is a good point, the users shouldn't really have to install
debuginfo for a one-off use. It would be better for a central server
or service to have access to all the debuginfo files
On Mon, 18 Jan 2010 09:18:11 +0100, Jiri Moskovcak wrote:
On 01/17/2010 05:57 PM, Christoph Wickert wrote:
5. Instead of hashes the missing debuginfo packages should be
listed with n-v-r, so people can install them manually.
This could be a problem. ABRT determines the required
On Sat, 2010-01-16 at 15:03 +, Daniel P. Berrange wrote:
On Sat, Jan 16, 2010 at 03:22:32PM +0100, Christoph H?ger wrote:
Hi,
I am currently playing with gobject to learn some of this boilerplate
stuff. For my small application I'd like to be able to write plugins
that are derived
On Mon, 18 Jan 2010 11:19:29 +0100, Jiri Moskovcak wrote:
On 01/18/2010 11:17 AM, Jan Kratochvil wrote:
Currently ABRT can at least run `rpm -qf MAIN_EXECUTABLE
ALL_GDB_INFO_SHARED_DISPLAYED LIBRARIES FILENAMES' and report these nvrs in
the Bugzilla bugreport before such build-id - nvr
Dne 16.1.2010 22:25, Ola Thoresen napsal(a):
Have a look at this bug for instance:
https://bugzilla.redhat.com/show_activity.cgi?id=531343
It was closed two months ago as WORKSFORME, still ABRT adds more and
more users to the Cc-list.
Obviously something is not working for someone, but ABRT
On Mon, Jan 18, 2010 at 11:11:25AM +0100, Radek Vokal wrote:
On Mon, Jan 18, 2010 at 10:13 AM, Caolán McNamara caol...@redhat.com wrote:
On Sat, 2010-01-16 at 16:01 +0100, Christoph Wickert wrote:
I know that APRT is still very young technology, but after 2 months it's
time for a interim
2010/1/18 Jiri Moskovcak jmosk...@redhat.com:
Plus abrt should run `rpm -V' on any rpm involved in the transaction (=if
user
does not have replaced the binary by some non-rpm make install).
ABRT used to do this (and still can, it's just disabled), but rpm -V uses
prelink to un-prelink the
On 01/18/2010 01:28 PM, Thomas Moschny wrote:
2010/1/18 Jiri Moskovcakjmosk...@redhat.com:
Plus abrt should run `rpm -V' on any rpm involved in the transaction (=if
user
does not have replaced the binary by some non-rpm make install).
ABRT used to do this (and still can, it's just disabled),
On Wed, Jan 13, 2010 at 04:07:24PM -0500, Tom Lane wrote:
Lennart Poettering mzerq...@0pointer.de writes:
There's something else that came to my mind: if libxml2 is loaded into
memory indirectly because some dlopen'ed module wanted it, and then
used, and then unloaded again because the
On Wed, Jan 13, 2010 at 04:54:34PM -0500, Simo Sorce wrote:
On Wed, 13 Jan 2010 22:39:43 +0100
The dilemma is in broken libraries that use global variables instead of
explicitly initialized memory contexts so that you can have multiple
completely independent instances and also happen to help
On 01/18/2010 02:18 PM, James Antill wrote:
On Mon, 2010-01-18 at 11:19 +0100, Jiri Moskovcak wrote:
Currently ABRT can at least run `rpm -qf MAIN_EXECUTABLE
ALL_GDB_INFO_SHARED_DISPLAYED LIBRARIES FILENAMES' and report these nvrs in
the Bugzilla bugreport before such build-id - nvr server is
On 01/18/2010 04:10 PM, Seth Vidal wrote:
On Mon, 18 Jan 2010, Farkas Levente wrote:
the real bottleneck is not the rpmbuild itself (with ccache it cab be
very fast), but the mock surroundings. suppose there is build which
takes about 2 minutes and in mock it takes about 5 minutes:-(
most
On Mon, 18 Jan 2010, Farkas Levente wrote:
the tar and gzip are mostly BUILDING the cache.
no tar and gzip used unpacking root cache.
How slow are your disks? You're not doing any of this to nfs are you?
but have to run yum each time for the package specific depsolve and yum
Farkas,
Don't email just to me offlist. Keep this onlist.
How much of this is network access and how much is disk? B/c I doubt
very much that you're cpu bound at all.
everything is on the local mirror server which is on a gigabit lan. is there
any way to banchmark mock and different
See
http://www.pclinuxos.com/forum/index.php?PHPSESSID=3t030sj3bgqk77dgetcvtueji1topic=66385.15
can it be packaged for Fedora?
Best
A. Mani
--
A. Mani
ASL, CLC, AMS, CMS
http://www.logicamani.co.cc
--
devel mailing list
devel@lists.fedoraproject.org
On Monday 18 January 2010, Seth Vidal wrote:
On Mon, 18 Jan 2010, Farkas Levente wrote:
the real bottleneck is not the rpmbuild itself (with ccache it cab be
very fast), but the mock surroundings. suppose there is build which
takes about 2 minutes and in mock it takes about 5 minutes:-(
On Mon, 18 Jan 2010, Seth Vidal wrote:
On Mon, 18 Jan 2010, Josephine Tannhäuser wrote:
should be possible, we have an (old but we have one) apt
unless I'm reading that forum thread wrong - it sure seems like apt-fast
requires axel's repo? If that's true then I think it nixes any chance
PySolFC and PySolFC-cardsets 2.0 were announced recently [1] and as of
this update the license has changed from GPLv2+ to GPLv3+. If nothing
comes up, I'll update to 2.0 on F-11, F-12 and devel in a few days.
Stewart
[1] http://pysolfc.sourceforge.net/
--
devel mailing list
Matt Domsch (matt_dom...@dell.com) said:
With nobody handling the incoming bugzilla tickets. With some bug
reports having been killed in an automated way at dist EOL. And
worse if it turns out that packages which do build are unmaintained
nevertheless, with the same symptoms in bugzilla
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the
common case where packages *are* maintained. Perhaps only do this
for packages that appear via some criteria (have not been built, have
not been committed to, have lots of bugs
On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the
common case where packages *are* maintained. Perhaps only do this
for packages that appear via some criteria
On Mon, 18 Jan 2010, Till Maas wrote:
On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the
common case where packages *are* maintained. Perhaps only do this
for
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2010-01-18/fedora-releng.2010-01-18-18.02.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2010-01-18/fedora-releng.2010-01-18-18.02.txt
Log:
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the
common case where packages *are* maintained. Perhaps only do this
for packages that appear via some criteria (have not
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be
fulfilled for the nagging bug to be created - the package was not
touched by the maintainer during recent x months and at least one bug is
opened not closed in the bugzilla on the
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be
fulfilled for the nagging bug to be created - the package was not
touched by the maintainer during recent x months and at
On 18.1.2010 13:17, Stephen Gallagher wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/17/2010 09:04 AM, Milos Jakubicek wrote:
Hi all,
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single
On Mon, 18 Jan 2010, Tomas Mraz wrote:
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be
fulfilled for the nagging bug to be created - the package was not
touched by the
On Mon, Jan 18, 2010 at 02:04:14PM -0500, Seth Vidal wrote:
I disagree about the bug being open. A lack of filed bugs could mean that
no one CARES about the pkg at all. And if we have pkgs which are not being
maintained AND no one cares enough to file a bug about then either they
are:
On Mon, Jan 18, 2010 at 02:32:10PM -0500, Seth Vidal wrote:
I have another radical idea - we could whitelist all sorts of things which
are unchanging and yet used. We could act like reasonable folks and
realize that one extra bug report A YEAR that you have to close as 'fixed'
is really
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is
unmaintained, because if it is maintained, the maintainer usually uses
it, otherwise he would just drop it. If
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is
unmaintained, because if it is maintained, the maintainer usually uses
it, otherwise he would just drop it. If
On Mon, Jan 18, 2010 at 02:55:36PM -0500, Seth Vidal wrote:
Yes, I believe the expression you're looking for is:
Perfect is the enemy of the good
What is being suggested is not perfect. It is, however, good.
Here we disagree. As I explained I see little use in it, since there are
other
On 10-01-18 11:34:44, Ville Skyttä wrote:
...
So instead of modifying specfiles, one can do something like this in
/etc/mock/site-defaults.cfg:
config_opts['macros']['%_smp_mflags'] = '-j3'
Unless `rpmbuild --showrc` shows a bad definition for _smp_mflags,
you're probably better off
On Mon, 18 Jan 2010, Till Maas wrote:
Often maintainers don't realize they have some of these packages, or the
maintainers have left the project.
Do maintainer really often forget, that they own a certain package?
Ok, maybe if they are forced to do this from Red Hat, I do not know. But
I
On Monday 18 January 2010, Tony Nelson wrote:
On 10-01-18 11:34:44, Ville Skyttä wrote:
...
So instead of modifying specfiles, one can do something like this in
/etc/mock/site-defaults.cfg:
config_opts['macros']['%_smp_mflags'] = '-j3'
Unless `rpmbuild --showrc` shows a bad
On Monday 18 January 2010 08:07:44 am Josephine Tannhäuser wrote:
should be possible, we have an (old but we have one) apt
I thought apt-rpm was broken since the rpm 4.7.x (or is that the right
version) changes?
Regards,
--
Conrad Meyer ceme...@u.washington.edu
--
devel mailing list
On Mon, 2010-01-18 at 16:22 -0500, Seth Vidal wrote:
I've not heard any other solutions which aren't oh just let it be.
It might have been missed in the passing but:
We have to reset our bugzilla password frequently
We have to renew our Koji cert once a year
We should be able to detect when
On Mon, 2010-01-18 at 15:08 -0500, Toshio Kuratomi wrote:
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is
unmaintained, because if it is maintained, the
On Mon, 2010-01-18 at 13:39 -0800, Jesse Keating wrote:
It might have been missed in the passing but:
We have to reset our bugzilla password frequently
We have to renew our Koji cert once a year
We should be able to detect when either of those goes wrong, probably
easiest to do the koji
On 1/18/2010 16:31, Manuel Wolfshant wrote:
On 01/19/2010 12:18 AM, Till Maas wrote:
now that F12+ is built for i686, can I expect that all Fedora x83
supported CPUs in F12+ support MMX? I have a package (john) that can
then be made simpler.
I'd say that you certainly can. Even Via Samuel is
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 20:00UTC (3pm EST) in #fedora-meeting on
irc.freenode.net.
Followups:
#298 Revoke Paul Johnsons pacakger access and put him on probation.
#291 Man pages Packaging Guideline
#302 libssh2 - non-responsive
On Sun, 2010-01-17 at 15:12 +0100, Christoph Wickert wrote:
I doubt this very much. Many people don't report the bugs when the app
crashes but later, many reports in a row. Most of my reports read I
have no idea what I was doing when foo crashed, even if they
submitted
it straight after the
On Sun, 2010-01-17 at 17:49 +, Camilo Mesias wrote:
Someone else asked this earlier - but why do users need the
debug-info
packages - only the debugger looking at the tracebacks needs this.
So
seems installing the debug files on every desktop/server that has a
problem is much less
On Mon, 2010-01-18 at 10:10 -0500, Seth Vidal wrote:
So the first time you run it makes a cache. You aren't clearing out
the
cache each time, are you? That would definitely eat up a lot of time.
Or running builds a long time apart, as the cache gets aged out. On my
system (an overclocked
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is
unmaintained, because if it is maintained, the maintainer usually
uses
it, otherwise he would just drop it. If
On Mon, 2010-01-18 at 15:30 -0500, Tony Nelson wrote:
On 10-01-18 11:34:44, Ville Skyttä wrote:
...
So instead of modifying specfiles, one can do something like this in
/etc/mock/site-defaults.cfg:
config_opts['macros']['%_smp_mflags'] = '-j3'
Unless `rpmbuild --showrc` shows a bad
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=508194
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=539150
Stepan Kasal ska...@redhat.com changed:
What|Removed |Added
52 matches
Mail list logo
