On 01/18/2010 10:36 PM, Conrad Meyer wrote:
> 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?
It was broken for quite a while
On Mon, 2010-01-18 at 17:32 -0700, Kevin Fenzi wrote:
> #297 Please consider the idea of a security (privilege escalation)
> policy
I'm not likely to have the draft policy ready by meeting time, so there
may not be much to say about this one. Might be best to punt it to the
following week.
--
Ad
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`
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.
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote:
> If we do that check before the alpha release that should let us track
> down
> awol maintainers and unmaintained pkgs pretty easily, I think.
>
> thoughts?
There's trivial packages which simply don't really need touching. I just
updated con
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 Q
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 mu
On Sun, 2010-01-17 at 09:54 -0700, Linuxguy123 wrote:
> In case you aren't aware, people are still trying to get Navit ready
> for
> F12.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=485652
>
> Navit has a routing engine and it seems to run fine on other
> platforms.
> I think if I had to c
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 afte
On Sat, 2010-01-16 at 16:01 +0100, Christoph Wickert wrote:
> Con:
>
> * Unfortunately 3 out of ~ 40 reports is not a good percentage.
Approximately the same as manual reports, in my experience.
> * As already pointed out by Michael Schwendt some time ago,
> there
> were som
We have a few packages that need to build themselves from their sources
twice. For instance, vim builds three times (a minimal version for /bin/vi,
and two versions with more dependencies for /usr/bin/vim and
/usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll have
some more wi
So I say libdrm was going to be karma'ed into updates, and
I thought I'd disabled that but it all got confused a few days ago.
So I thought well I better push all the packages that depends on it
into updates as well, and they'll all end up in one signing pass
and everyone will be happy.
Now someh
On Monday 18 January 2010 08:30:46 pm Mike McGrath wrote:
> On Mon, 18 Jan 2010, John Poelstra wrote:
> > A friendly reminder that the deadline for *submitting new features and
> > spins* for inclusion in Fedora 13 is coming soon!
> >
> > >> Feature Submission: Tuesday, January 26, 2010 <<
> >
On Tue, Jan 19, 2010 at 12:31:11AM +0200, Manuel Wolfshant wrote:
> On 01/19/2010 12:18 AM, Till Maas wrote:
> > Hiyas,
> >
> > 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.
> >
>
On Mon, 18 Jan 2010, John Poelstra wrote:
> A friendly reminder that the deadline for *submitting new features and
> spins* for inclusion in Fedora 13 is coming soon!
>
> >> Feature Submission: Tuesday, January 26, 2010 <<
>
> >> Feature Freeze: Tuesday, February 9, 2010 <<
>
> "At Featu
Thanks to the help of a few people in Release Engineering and elsewhere
I've tuned up the wiki pages describing each of our freezes. The
policies remain the same, but the pages have been updated to hopefully
enhance the presentation and readability.
One of my goals for this release is to have
A friendly reminder that the deadline for *submitting new features and
spins* for inclusion in Fedora 13 is coming soon!
>> Feature Submission: Tuesday, January 26, 2010 <<
>> Feature Freeze: Tuesday, February 9, 2010 <<
"At Feature Freeze all new features for the release should be
sub
Hi, folks. It's about time we kicked the Fedora 13 Test Day cycle into
gear!
For those who haven't had experience yet with the Test Day concept,
here's an overview:
https://fedoraproject.org/wiki/QA/Test_Days
and here's the Fedora 12 Test Day schedule, so you can see what a
completed cycle looks
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 maint
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 S
On 01/19/2010 12:18 AM, Till Maas wrote:
> Hiyas,
>
> 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.
>
> Regards
> Till
>
I'd say that you certainly can. Even Via Samuel is MMX enabl
Just an FYI that I've refreshed the repos at
pkgs.stg.fedoraproject.org . I had picked up some tips on setting up
the repos a bit better and so I've done that. Anybody with existing
clones will have to remove them and re-clone.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http:/
Hiyas,
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.
Regards
Till
pgpVVgY0nqkQi.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedora
On Monday 18 January 2010 03:39:47 pm Jesse Keating wrote:
> 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
On Mon, Jan 18, 2010 at 01:59:27PM -0700, Stephen John Smoogen wrote:
> I just wanted to say thanks to the guys who integrated ABRT into F12.
> It has rough edges and I know it needs improvement, but I have filed
> more 'bugs' than in many past releases where instead I just let things
> slide. Most
On Mon, 2010-01-18 at 22:51 +0100, Michael Schwendt wrote:
> On Mon, 18 Jan 2010 20:01:23 +0100, Tomas 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 rece
2010/1/17 Michael Schwendt :
> On Sat, 16 Jan 2010 11:46:27 -0700, Kevin wrote:
>
>> Greetings.
>>
>> I'd like to find some folks interested in co-maintaining or just fully
>> maintaining gpsdrive. It's a nifty gps app that lets you download maps
>> and follow progress and publish your location.
>>
On Mon, 18 Jan 2010 20:01:23 +0100, Tomas 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 bugzil
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
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 maintain
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 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
--
devel mailing list
devel@lists.fedoraproject.org
ht
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
On Mon, 18 Jan 2010, Till Maas wrote:
> 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 ex
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.
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 let
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
I just wanted to say thanks to the guys who integrated ABRT into F12.
It has rough edges and I know it needs improvement, but I have filed
more 'bugs' than in many past releases where instead I just let things
slide. Most of the items I have run into have been fixed and I have
tried to help the eng
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
ot
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
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. I
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 upstream is dead but the
> maintainer fixes bugs, when they are f
On Mon, 18 Jan 2010, Till Maas wrote:
> First of all, that would be two bug reports per year, as we have a 6
> month development cycle. But it also will not be that useful, as we
> already have three things that have to be done by every maintainer once
> or twice a year, so they can be easily us
On Mon, 2010-01-18 at 20:24 +0100, Tomas Mraz wrote:
> So that means that for example for the openoffice.org-dict-cs_CZ package
> I'll get the nag bug report before each and every Fedora release?
>
> It is definitely not 4. however 1. and 2. apply to it. As this is just a
> czech spelling and hyph
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, 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:
>
>> I ran the test suite that covers these functionalities. So far, I haven't
>> seen any breakage. But I might be missing something important, so your
>> reviews would be greatly appreciated.
>
> I'm pretty sure the referential integrity plug-in will not work for
> modrdn operations with a new su
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
>>> touch
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.
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
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 th
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 (ha
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
Chris Weyl changed:
What|Removed |Added
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:
http://meetbot.fedoraproject.org/fedora-meeting/2010-01-18/fedora-releng.2010-
On Mon, Jan 18, 2010 at 04:05:05PM +0100, 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 of the time is in y
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 th
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 cri
Top three FAS account holders who have completed reviewing "Package
review" components on bugzilla for last 7 days ending 17th Jan were
Parag AN(पराग), Christoph Wickert and Michal Fojtik.
Parag AN(पराग) : 7
https://bugzilla.redhat.com/show_bug.cgi?id=552253
https://bugzilla.redha
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 bug
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 bug
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
devel@lists.fedorap
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 an
On Mon, 18 Jan 2010 18:34:44 +0200
Ville Skyttä wrote:
> On Monday 18 January 2010, Clark Williams wrote:
>
> > If package build times are your problem, you may want to modify the
> > make command used by the specfiles. Mock just does what the specfile
> > says to do (i.e. it just does an rpmbui
On Monday 18 January 2010, Clark Williams wrote:
> If package build times are your problem, you may want to modify the
> make command used by the specfiles. Mock just does what the specfile
> says to do (i.e. it just does an rpmbuild), so you might want to add a
> '-j16' to the make command line t
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 15:38:56 +0100
Farkas Levente wrote:
> hi,
> we use mock for local package build, but it's very slow. now we install
> a new host just for mock with 8core, ram disks etc. it seems it still
> slow. first of all most of the time mock use only one 1 core of the cpu.
> is there
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 of
the pkg getting into fedora.
-sv
--
should be possible, we have an (old but we have one) apt
2010/1/18, A. Mani :
> See
> http://www.pclinuxos.com/forum/index.php?PHPSESSID=3t030sj3bgqk77dgetcvtueji1&topic=66385.15
>
> can it be packaged for Fedora?
>
>
> Best
>
> A. Mani
>
>
> --
> A. Mani
> ASL, CLC, AMS, CMS
> http://www.logicam
See
http://www.pclinuxos.com/forum/index.php?PHPSESSID=3t030sj3bgqk77dgetcvtueji1&topic=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
https://admin.fedoraproject.org/mailma
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 dif
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
>
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:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/18/2010 10:05 AM, Farkas Levente wrote:
> On 01/18/2010 03:49 PM, Stephen Gallagher wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 01/18/2010 09:38 AM, Farkas Levente wrote:
>>> hi,
>>> we use mock for local package build, bu
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 of the time is in yum, python tar, gzip
On 01/18/2010 03:49 PM, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/18/2010 09:38 AM, Farkas Levente wrote:
>> hi,
>> we use mock for local package build, but it's very slow. now we install
>> a new host just for mock with 8core, ram disks etc. it seems it s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/18/2010 09:38 AM, Farkas Levente wrote:
> hi,
> we use mock for local package build, but it's very slow. now we install
> a new host just for mock with 8core, ram disks etc. it seems it still
> slow. first of all most of the time mock use only
hi,
we use mock for local package build, but it's very slow. now we install
a new host just for mock with 8core, ram disks etc. it seems it still
slow. first of all most of the time mock use only one 1 core of the cpu.
is there any way to speed up different part of the mock build process?
thanks
On Mon, Jan 18, 2010 at 02:45:33PM +0100, Jiri Moskovcak wrote:
> 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
On Wed, Jan 13, 2010 at 03:57:46PM -0600, Michael Cronenworth wrote:
> Daniel Veillard wrote:
> > The problem is that you can perfectly have application not relying on
> > libxml2 outside of their own code use libxml2 at different phases,
> > for example when parsing input, and when generating resu
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 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
On Wed, Jan 13, 2010 at 04:07:24PM -0500, Tom Lane wrote:
> Lennart Poettering 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 module got dlcose'
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 deployed.
This should use the yum
2010/1/18 Jiri Moskovcak :
> On 01/18/2010 01:28 PM, Thomas Moschny wrote:
>> 2010/1/18 Jiri Moskovcak:
>>> ABRT used to do this (and still can, it's just disabled), but rpm -V uses
>>> prelink to un-prelink the binaries to check the MD5 sum and security guys
>>> don't like it.
>>
>> Can you explai
On 01/18/2010 01:28 PM, Thomas Moschny wrote:
2010/1/18 Jiri Moskovcak:
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
pr
2010/1/18 Jiri Moskovcak :
>> 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 binaries to
-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 library (single soname) which can be
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 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 conclusion.
On 01/18/2010 11:38 AM, Jan Kratochvil wrote:
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
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,
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 ->
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 ar
On 01/18/2010 11:17 AM, Jan Kratochvil wrote:
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 co
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 re
On Mon, Jan 18, 2010 at 10:13 AM, Caolán McNamara 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 conclusion. For me the conclusions are:
>
> Abrt's getting a bit of a knocking in
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 f
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 conclusion. For me the conclusions are:
Abrt's getting a bit of a knocking in this thread, but I'm fairly happy
with it myself, it's doing its
On 01/18/2010 09:34 AM, Alexander Larsson wrote:
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 coref
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 i
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 providi
1 - 100 of 103 matches
Mail list logo
