5:28 a.m.
I've blogged about package management in Fedora (and how it sucks in
other distros too) and also discussed abstract per-system package
management over DBUS interfaces.
I would appreciate feedback on
http://hughsient.livejournal.com/31429.html either on the blog as
comments, personal email, or just cc'd to the list.
This is obviously not a F8 target, more an idea I discussed with some
other desktop hackers at GUADEC and FOSDEM earlier this year.
"Crack" would be a valid comment but obviously, I would prefer more in
depth and reasoned criticism :-)
Many thanks,
Richard Hughes
5:43 a.m.
Richard Hughes wrote:
I've blogged about package management in Fedora (and how it sucks
in
other distros too) and also discussed abstract per-system package
management over DBUS interfaces.
I would appreciate feedback on
http://hughsient.livejournal.com/31429.html
"Do we have to make the API
asynchronous?"
YES!!!
the best way to fix the progressbar hangs is multithreading.
let the gui draw its stuff, while a background thread does the real work.
yumex afaik works this way.
9:40 a.m.
On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote:
Richard Hughes wrote:
> I've blogged about package management in Fedora (and how it sucks in
> other distros too) and also discussed abstract per-system package
> management over DBUS interfaces.
>
> I would appreciate feedback on
> http://hughsient.livejournal.com/31429.html
"Do we have to make the API asynchronous?"
YES!!!
the best way to fix the progressbar hangs is multithreading.
let the gui draw its stuff, while a background thread does the real work.
yumex afaik works this way.
Unfortunately, introducing threading into an environment (rpm + sqlite)
which wasn't designed with threading in mind is a recipe for lots of ...
interesting problems.
Jeremy
4:55 p.m.
On Fri, 2007-07-27 at 10:40 -0400, Jeremy Katz wrote:
On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote:
> Richard Hughes wrote:
> > I've blogged about package management in Fedora (and how it sucks in
> > other distros too) and also discussed abstract per-system package
> > management over DBUS interfaces.
> >
> > I would appreciate feedback on
> > http://hughsient.livejournal.com/31429.html
> "Do we have to make the API asynchronous?"
> YES!!!
> the best way to fix the progressbar hangs is multithreading.
> let the gui draw its stuff, while a background thread does the real work.
> yumex afaik works this way.
Unfortunately, introducing threading into an environment (rpm + sqlite)
which wasn't designed with threading in mind is a recipe for lots of ...
interesting problems.
The proposal from Richard was to use IPC between the UI bits and the
actual mechanism (yum, apt, whatever) that carries out the work. So the
UI client would be a simple single-threaded process that just calls into
a D-Bus system service. Async calls doesn't mean multithreaded, it can
also means callback from a mainloop. Nothing new here.
David
1:13 a.m.
Jeremy Katz wrote:
On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote:
> Richard Hughes wrote:
>
>> I've blogged about package management in Fedora (and how it sucks in
>> other distros too) and also discussed abstract per-system package
>> management over DBUS interfaces.
>>
>> I would appreciate feedback on
>> http://hughsient.livejournal.com/31429.html
>>
> "Do we have to make the API asynchronous?"
> YES!!!
> the best way to fix the progressbar hangs is multithreading.
> let the gui draw its stuff, while a background thread does the real work.
> yumex afaik works this way.
>
Unfortunately, introducing threading into an environment (rpm + sqlite)
which wasn't designed with threading in mind is a recipe for lots of ...
interesting problems.
Jeremy
Yes, running yum actions in a background tread was a world of pain, so i
have reversed the process and running the yum actions in the foreground
and having a background thread refresh the gui.
Tim
7:14 a.m.
Richard Hughes <hughsient(a)gmail.com> writes:
I've blogged about package management in Fedora (and how it sucks
in
other distros too) and also discussed abstract per-system package
management over DBUS interfaces.
I would appreciate feedback on
http://hughsient.livejournal.com/31429.html either on the blog as
comments, personal email, or just cc'd to the list.
If you've got something to say and want feednack from thise reading this
list, why don't you just post what you've got to say here?
--
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.
10:07 a.m.
On Fri, 2007-07-27 at 14:14 +0200, Frank Schmitt wrote:
If you've got something to say and want feednack from thise
reading
this list, why don't you just post what you've got to say here?
Because it was a super-long post, and I didn't want to flood everyone
with 6 pages of rambling. Point taken tho, I could have added more of an
introduction.
Richard.
8:53 a.m.
Richard Hughes (hughsient(a)gmail.com) said:
I've blogged about package management in Fedora (and how it sucks
in
other distros too) and also discussed abstract per-system package
management over DBUS interfaces.
I would appreciate feedback on
http://hughsient.livejournal.com/31429.html either on the blog as
comments, personal email, or just cc'd to the list.
We've actually discussed this before. Basically, with the current
state of yum-updatesd:
1) we could make it dumber. Dead simple; doesn't have modes to install
updates, etc. All it does is check for new metadata - it's possible
that it doesn't even check it against what you have installed. Simple ==
predictable.
2) we could make it smarter. A full package management system - all tools
run unpriveleged and simply call into it. This is more along the lines
of what you suggested, albeit tied solely to RPM/yum.
Frankly, I don't care as much about it working with .deb, or Solaris
pkgadd, or whatever. Others may differ, but I wonder if the effort required
to coerce all of them to a common API would a) be sanely possible b)
leave you with enough of a common API to do anything useful.
Bill
9 a.m.
On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote:
Frankly, I don't care as much about it working with .deb, or
Solaris
pkgadd, or whatever. Others may differ, but I wonder if the effort required
to coerce all of them to a common API would a) be sanely possible b)
leave you with enough of a common API to do anything useful.
The big thing about this is to get package management tools out of the
distro tools ghetto and into shared upstream territory.
9:49 a.m.
On Fri, 2007-07-27 at 10:00 -0400, Matthias Clasen wrote:
On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote:
> Frankly, I don't care as much about it working with .deb, or Solaris
> pkgadd, or whatever. Others may differ, but I wonder if the effort required
> to coerce all of them to a common API would a) be sanely possible b)
> leave you with enough of a common API to do anything useful.
The big thing about this is to get package management tools out of the
distro tools ghetto and into shared upstream territory.
Sure. This is aimed at people who want to "install OpenOffice" rather
than query all the 64bit packages starting with the letter B.
Hardcore stuff is done on the command line with distro tools. Being
notified of a security update and clicking on a button "install in the
background" is all something that should "just work" and be the same for
all distros.
So far the feedback ratio I'm getting is roughly:
80%: I agree! - let's do it
20%: You are on crack, the existing tools work fine
Which is very interesting from a fedora point of view.
Richard.
9:57 a.m.
Richard Hughes (hughsient(a)gmail.com) said:
Sure. This is aimed at people who want to "install
OpenOffice" rather
than query all the 64bit packages starting with the letter B.
But for things like that, are you as interested in packages as you are
the mugshot-style distributed apps?
Bill
9:58 a.m.
On Fri, 2007-07-27 at 10:57 -0400, Bill Nottingham wrote:
But for things like that, are you as interested in packages as you are
the mugshot-style distributed apps?
Not sure. I figured Colin meant something like "Try Inkscape Now" type
link that would just DTRT and install inkscape.
Richard.
10:08 a.m.
On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote:
We've actually discussed this before. Basically, with the
current
state of yum-updatesd:
1) we could make it dumber. Dead simple; doesn't have modes to install
updates, etc. All it does is check for new metadata - it's possible
that it doesn't even check it against what you have installed. Simple ==
predictable.
2) we could make it smarter. A full package management system - all tools
run unpriveleged and simply call into it. This is more along the lines
of what you suggested, albeit tied solely to RPM/yum.
Frankly, I don't care as much about it working with .deb, or Solaris
pkgadd, or whatever. Others may differ, but I wonder if the effort required
to coerce all of them to a common API would a) be sanely possible b)
leave you with enough of a common API to do anything useful.
Given the work I did trying to corral the various pkging groups into a
single format for just the metadata - I can say that getting an API out
that group would be like pulling teeth.
When we talked about 2) before the biggest hurdles I recall were:
1. there's a lot of code b/t here and there. Is it worth it?
2. It complicates rescue mode, b/c now either the code has to know how
to talk to both the direct sources and the daemon or we have to use (and
maintain) different tools.
3. great ANOTHER daemon running, how lovely.
-sv
10:18 a.m.
On Fri, 2007-07-27 at 11:08 -0400, seth vidal wrote:
1. there's a lot of code b/t here and there. Is it worth it?
I think it's important problem to solve.
2. It complicates rescue mode, b/c now either the code has to know
how
to talk to both the direct sources and the daemon or we have to use (and
maintain) different tools.
No, I don't think that's valid. Distro tools like yum can still be run
by people who use a "command window" like normal and point and click
tools talk to the daemon which blocks until the power-user has finished
being geeky :-)
3. great ANOTHER daemon running, how lovely.
Nope, with system activation we only need to start this when a user is
trying to _do_ something, and then we can quit when there are no updates
scheduled or not in an installer.
Richard.
10:24 a.m.
Richard Hughes (hughsient(a)gmail.com) said:
> 3. great ANOTHER daemon running, how lovely.
Nope, with system activation we only need to start this when a user is
trying to _do_ something, and then we can quit when there are no updates
scheduled or not in an installer.
Is system activation really a good interface when the daemon has
to:
1) query metadata (download from internet)
2) query installed packages
This can introduce a not-insignifcant delay - how does system-activation
handle this in general?
Bill
10:23 a.m.
On Fri, 2007-07-27 at 11:24 -0400, Bill Nottingham wrote:
Richard Hughes (hughsient(a)gmail.com) said:
> > 3. great ANOTHER daemon running, how lovely.
>
> Nope, with system activation we only need to start this when a user is
> trying to _do_ something, and then we can quit when there are no updates
> scheduled or not in an installer.
Is system activation really a good interface when the daemon has
to:
1) query metadata (download from internet)
Starting a service takes a few ms.
2) query installed packages
If the metadata is already okay it should be really quick. Or do I
misunderstand your point?
Richard.
10:31 a.m.
Richard Hughes (hughsient(a)gmail.com) said:
> 1) query metadata (download from internet)
Starting a service takes a few ms.
To handle the 'start()' signal, sure. But it depends on the service
itself as to when it's ready. I'm mainly just wondering about system
activation as an appropriate API for any service that takes a non-trivial
amount of time to initialize.
> 2) query installed packages
If the metadata is already okay it should be really quick. Or do I
misunderstand your point?
... which would require some sort of daemon/automated task to make
sure it's up to date. But we're off in the weeds now.
Bill
10:38 a.m.
On Fri, 2007-07-27 at 11:31 -0400, Bill Nottingham wrote:
Richard Hughes (hughsient(a)gmail.com) said:
> > 1) query metadata (download from internet)
>
> Starting a service takes a few ms.
To handle the 'start()' signal, sure. But it depends on the service
itself as to when it's ready. I'm mainly just wondering about system
activation as an appropriate API for any service that takes a non-trivial
amount of time to initialize.
There has been some discussion with Havoc about the need for a 2-phase
protocol for taking bus names, to differentiate the use of bus names
for locking and for signaling readyness. I guess this is what we are
talking about here, on the one hand, the service needs to take the bus
name as early as possible to prevent other instances from taking it, on
the other hand, it should be ready for service when it takes the bus
name.
> > 2) query installed packages
>
> If the metadata is already okay it should be really quick. Or do I
> misunderstand your point?
... which would require some sort of daemon/automated task to make
sure it's up to date. But we're off in the weeds now.
How so ? Isn't that exactly what yum-updatesd is supposed to do ?
10:35 a.m.
On Fri, 2007-07-27 at 11:38 -0400, Matthias Clasen wrote:
On Fri, 2007-07-27 at 11:31 -0400, Bill Nottingham wrote:
> Richard Hughes (hughsient(a)gmail.com) said:
> > > 1) query metadata (download from internet)
> >
> > Starting a service takes a few ms.
>
> > > 2) query installed packages
> >
> > If the metadata is already okay it should be really quick. Or do I
> > misunderstand your point?
>
> ... which would require some sort of daemon/automated task to make
> sure it's up to date. But we're off in the weeds now.
How so ? Isn't that exactly what yum-updatesd is supposed to do ?
if you have a running daemon(yum-updatesd/yumd), why not just use it as
a persistent daemon rather than depending on dbus to start it each time?
Also - it lets us work with the portion of the market who run servers
and like the idea of a daemon they can query for pkg information, but
don't run dbus.
We turned dbus off everywhere we could - it just used ram and didn't do
anything for me running a webserver.
-sv
11:10 a.m.
On Fri, 2007-07-27 at 11:35 -0400, seth vidal wrote:
Also - it lets us work with the portion of the market who run
servers
and like the idea of a daemon they can query for pkg information, but
don't run dbus.
We turned dbus off everywhere we could - it just used ram and didn't do
anything for me running a webserver.
Moving forward, it makes a lot of sense to me to do development on the
OS assuming that we have a sane way for system components to communicate
with one another.
dbus-daemon doesn't even show up on the radar for RAM usage on my
system...
11:05 a.m.
On Fri, 2007-07-27 at 12:10 -0400, Colin Walters wrote:
On Fri, 2007-07-27 at 11:35 -0400, seth vidal wrote:
> Also - it lets us work with the portion of the market who run servers
> and like the idea of a daemon they can query for pkg information, but
> don't run dbus.
>
> We turned dbus off everywhere we could - it just used ram and didn't do
> anything for me running a webserver.
Moving forward, it makes a lot of sense to me to do development on the
OS assuming that we have a sane way for system components to communicate
with one another.
dbus-daemon doesn't even show up on the radar for RAM usage on my
system...
as a sysadmin I will say this:
1. if it ain't necessary it is off
2. if nothing deps on it, it gets removed.
- now things depend on dbus these days, and that's fine - but on a
server with a static ip- even served via dhcp we don't need it - it's
just one more thing that can go wrong.
-sv
5:02 p.m.
On Fri, 2007-07-27 at 12:05 -0400, seth vidal wrote:
as a sysadmin I will say this:
1. if it ain't necessary it is off
2. if nothing deps on it, it gets removed.
- now things depend on dbus these days, and that's fine - but on a
server with a static ip- even served via dhcp we don't need it - it's
just one more thing that can go wrong.
No-one would prevent you from not installing the bits that provide a
simple D-Bus interface for package management. I emphasize "simple", it
would be madness to export just half of what yum/apt/whatever is capable
of. The design of said interface would be driven by needs from (simple)
UI applications. The implementation of said software bits wouldn't even
need to come from yum, apt, whatever developers, it could be an
abstraction on top of this; of course for this to work in a social
context the relevant depsolver people would have to buy in and support
the project etc. etc. Which I'm skeptical about but I would loved to be
proved wrong.
As for you other comment, "yet another daemon", I concur we don't want
more daemons / services started than necessary. What Richard is
proposing would simply just be started via D-Bus system bus activation.
In fact, I think it's madness that there's a yum-updatesd in Fedora at
all, it should just be started when needed and kill itself when it's not
needed. If you need periodic checks, just use a cronjob and dbus-send(1)
to poke the daemon. Thing is, we need to start as little as possible
during boot.
David
11:09 a.m.
On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote:
2) we could make it smarter. A full package management system - all
tools
run unpriveleged and simply call into it. This is more along the lines
of what you suggested, albeit tied solely to RPM/yum.
Is this conceptually the same as red carpet daemon?
-Toshio
11:03 a.m.
On Fri, 2007-07-27 at 09:09 -0700, Toshio Kuratomi wrote:
On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote:
> 2) we could make it smarter. A full package management system - all tools
> run unpriveleged and simply call into it. This is more along the lines
> of what you suggested, albeit tied solely to RPM/yum.
>
Is this conceptually the same as red carpet daemon?
it's not completely off in left field from it, no.
-sv
9:55 a.m.
On Fri, 2007-07-27 at 11:28 +0100, Richard Hughes wrote:
I've blogged about package management in Fedora (and how it sucks
in
other distros too) and also discussed abstract per-system package
management over DBUS interfaces.
I would appreciate feedback on
http://hughsient.livejournal.com/31429.html either on the blog as
comments, personal email, or just cc'd to the list.
This is obviously not a F8 target, more an idea I discussed with some
other desktop hackers at GUADEC and FOSDEM earlier this year.
I think it's a fantastic idea. The Mugshot client has a bit of code a
while ago which implements the "Install Now" link on
http://mugshot.org/applications that could be used as a starting point:
http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-distribution.c
9:54 a.m.
On Fri, 2007-07-27 at 10:55 -0400, Colin Walters wrote:
I think it's a fantastic idea. The Mugshot client has a bit of
code a
while ago which implements the "Install Now" link on
http://mugshot.org/applications that could be used as a starting
point:
Yes, there's no reason why stuff like OpenOffice can't have "You want to
use clipart, but it is not installed - do you want to install it now?"
and then all fedora has to do is patch the name of the rpm package[1]
and it can just work.
Richard.
[1] because we'll never agree on names between distros...
10:31 a.m.
On Fri, 27 Jul 2007 15:54:00 +0100
Richard Hughes <hughsient(a)gmail.com> wrote:
and then all fedora has to do is patch the name of the rpm
package[1]
and it can just work.
Richard.
[1] because we'll never agree on names between distros...
Why? yum can understand being passed a file name. OO wants to use
that file, that file isn't installed, ask yum to install that file.
--
Jesse Keating
Release Engineer: Fedora
3:21 p.m.
fre 2007-07-27 klockan 11:31 -0400 skrev Jesse Keating:
OO wants to use that file, that file isn't installed, ask yum to
install that file.
Maybe this would be a good way to allow bug-buddy to try to get the
right debuginfo packages installed before generating the stack trace?
/abo
2:21 a.m.
On Sat, 2007-07-28 at 22:21 +0200, Alexander Boström wrote:
fre 2007-07-27 klockan 11:31 -0400 skrev Jesse Keating:
> OO wants to use that file, that file isn't installed, ask yum to
> install that file.
Maybe this would be a good way to allow bug-buddy to try to get the
right debuginfo packages installed before generating the stack trace?
FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to
download on a crash. And neither OOo or firefox are using bug-buddy. In
the case of OOo at least the crash info can be re-annotated offline back
to source lines, so we don't loose anything by having no debuginfo
installed. Though we don't get local variables etc with offline
annotation, but we don't have those with the current crash reporter
anyway.
C.
11:12 a.m.
On 7/29/07, Caolan McNamara <caolanm(a)redhat.com> wrote:
FWIW OOo debuginfo is about 450 megs, which is rather sucky to force
to
download on a crash. And neither OOo or firefox are using bug-buddy. In
the case of OOo at least the crash info can be re-annotated offline back
to source lines, so we don't loose anything by having no debuginfo
installed. Though we don't get local variables etc with offline
annotation, but we don't have those with the current crash reporter
anyway.
I think OOo illustrates that whatever toolized solution to help users
install debuginfo packages as needed, would need to be smart enough to
blacklist certain packages that are known not to benefit from the
debuginfo install.
-jef
4:27 p.m.
On Mon, 2007-07-30 at 08:12 -0800, Jeff Spaleta wrote:
On 7/29/07, Caolan McNamara <caolanm(a)redhat.com> wrote:
> FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to
> download on a crash. And neither OOo or firefox are using bug-buddy. In
> the case of OOo at least the crash info can be re-annotated offline back
> to source lines, so we don't loose anything by having no debuginfo
> installed. Though we don't get local variables etc with offline
> annotation, but we don't have those with the current crash reporter
> anyway.
I think OOo illustrates that whatever toolized solution to help users
install debuginfo packages as needed, would need to be smart enough to
blacklist certain packages that are known not to benefit from the
debuginfo install.
I think the use case of users who can cope with submitting a bug with
debuginfo are negligible compared to some other use cases. Plus most
stuff will need to pull in library debuginfo deps, even if it's just
glibc*debuginfo* to make sense of things.
Lets not get hung up on the details here but hammer out the use cases
rather than caught into a rathole of setting policy prematurely.
Paul
4:15 p.m.
On Tue, 2007-07-31 at 22:27 +0100, Paul Nasrat wrote:
On Mon, 2007-07-30 at 08:12 -0800, Jeff Spaleta wrote:
> On 7/29/07, Caolan McNamara <caolanm(a)redhat.com> wrote:
> > FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to
> > download on a crash. And neither OOo or firefox are using bug-buddy. In
> > the case of OOo at least the crash info can be re-annotated offline back
> > to source lines, so we don't loose anything by having no debuginfo
> > installed. Though we don't get local variables etc with offline
> > annotation, but we don't have those with the current crash reporter
> > anyway.
>
> I think OOo illustrates that whatever toolized solution to help users
> install debuginfo packages as needed, would need to be smart enough to
> blacklist certain packages that are known not to benefit from the
> debuginfo install.
I think the use case of users who can cope with submitting a bug with
debuginfo are negligible compared to some other use cases. Plus most
stuff will need to pull in library debuginfo deps, even if it's just
glibc*debuginfo* to make sense of things.
More to the point, asking the user to install debuginfo _ever_ is a
failure. You have the NEVRs of all packages involved in the crash.
Feed them to the bug machine, let the distro reconstruct the backtrace.
That way not only does the user not have to download $huge, but they
don't have to go hunt around in koji for the debuginfo that corresponds
to whatever outdated version of a given package they still have
installed.
- ajax
5:08 p.m.
More to the point, asking the user to install debuginfo _ever_ is a
failure. You have the NEVRs of all packages involved in the crash.
Feed them to the bug machine, let the distro reconstruct the backtrace.
In F8 with build IDs, having nothing but the core dump file will be enough
to easily determine (offline, later) all the packages that were involved.
2:27 a.m.
New subject: crash reporting
On Tue, 2007-07-31 at 15:08 -0700, Roland McGrath wrote:
> More to the point, asking the user to install debuginfo _ever_
is a
> failure. You have the NEVRs of all packages involved in the crash.
> Feed them to the bug machine, let the distro reconstruct the backtrace.
In F8 with build IDs, having nothing but the core dump file will be enough
to easily determine (offline, later) all the packages that were involved.
This sounds sort of tantalising, especially the F8 timeframe. What are
the details ? Is there e.g. an online core dump mapping service to be
made available ? And if so, a standardized desktop UI crash reporter to
submit the core somewhere on crash ?
Seeing as gnome apps intercept by default SEGV and launch bug-buddy
instead of creating a core dump and OOo does similar should we have a
pile of bugs to just remove this stuff and crash to core and let
something else take care of it.
C.
2:46 a.m.
New subject: crash reporting
On Wed, 01 Aug 2007 09:27:42 +0200, Caolan McNamara wrote:
On Tue, 2007-07-31 at 15:08 -0700, Roland McGrath wrote:
...
> In F8 with build IDs, having nothing but the core dump file will
be enough
> to easily determine (offline, later) all the packages that were involved.
This sounds sort of tantalising, especially the F8 timeframe. What are
the details ?
Roland's info:
http://fedoraproject.org/wiki/Releases/FeatureBuildId
There is going to be GDB with the support in F8 - it loads the right executable
+ libraries just being given the core file. One of the test builds was:
http://koji.fedoraproject.org/koji/taskinfo?taskID=76292
But it needs /usr/lib/debug/.build-id symlinks still not present in the current
F8test1/Rawhide, the symlinks should exist for F8test2 (test3?).
I see it should give there a warning if the symlink is missing to be able to:
yum install /usr/lib/debug/.build-id/c8/eba3e0886b625d58b803f6b924b4a76d3daeb2
# installs the executable/library
yum install /usr/lib/debug/.build-id/c8/eba3e0886b625d58b803f6b924b4a76d3daeb2.debug
# installs the associated -debuginfo package
Regards,
Jan
BEFORE:
$ gdb -c /tmp/buildmainlib/headers
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `../buildmain'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004005b6 in ?? ()
(gdb) bt
#0 0x00000000004005b6 in ?? ()
#1 0x0000000000000000 in ?? ()
(gdb) info sharedlibrary
No shared libraries loaded at this time.
(gdb) _
AFTER:
$ gdb -c /tmp/buildmainlib/headers
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `../buildmain'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /tmp/buildmain.debug-x...done.
warning: Can't read pathname for load map: Input/output error.
#0 0x00000000004005b6 in main () at buildmain.c:6
6 *(int *) 0 = 0;
(gdb) bt
#0 0x00000000004005b6 in main () at buildmain.c:6
#1 0x000000300041dab4 in __libc_start_main () from /lib64/libc.so.6
#2 0x00000000004004f9 in ?? ()
#3 0x00007fff1907c548 in ?? ()
#4 0x0000000000000000 in ?? ()
(gdb) info sharedlibrary
From To Syms Read Shared Object
Library
0x00002aaaaaaad460 0x00002aaaaaaad578 Yes /tmp/buildlib.so
# /tmp/buildlib.so would not be found due to no LD_LIBRARY_PATH without buildid
0x000000300041d8a0 0x00000030005068b8 Yes /lib64/libc.so.6
0x0000003000000a60 0x00000030000155d4 Yes /lib64/ld-linux-x86-64.so.2
(gdb) _
5:32 a.m.
New subject: crash reporting
Hi
On 8/1/07, Caolan McNamara <caolanm(a)redhat.com> wrote:
This sounds sort of tantalising, especially the F8 timeframe. What
are
the details ? Is there e.g. an online core dump mapping service to be
made available ? And if so, a standardized desktop UI crash reporter to
submit the core somewhere on crash ?
Seeing as gnome apps intercept by default SEGV and launch bug-buddy
instead of creating a core dump and OOo does similar should we have a
pile of bugs to just remove this stuff and crash to core and let
during last GUADEC we (GNOME guys) outlined a plan. Now bug-buddy
installs a seghandler as a GTK_MODULE. When a crash happens, if debug
symbols are present, we do it in the old way: bug-buddy invokes gdb
and gets a backtrace and send it to bugzilla.gnome.org. If no debug
symbols are present, the handler dumps a minidump file of the process
and invokes bug-buddy, which sends it to a debug server. This debug
server is currently under developent, but then plan is to have a
reference codebase (based on mozilla socorro) from which distros can
build their own debug server and feed it with their debuginfo
packages. We, as GNOME upstream, probably are going to offer a debug
server for those distros without the resources to set up their own.
How to forward a crash from the debug server to the upstream bugzilla
is not clear 100% yet.
Salu2
5:52 a.m.
New subject: crash reporting
On Wed, 2007-08-01 at 13:32 +0300, Fernando Herrera wrote:
Hi
On 8/1/07, Caolan McNamara <caolanm(a)redhat.com> wrote:
> This sounds sort of tantalising, especially the F8 timeframe. What are
> the details ? Is there e.g. an online core dump mapping service to be
> made available ? And if so, a standardized desktop UI crash reporter to
> submit the core somewhere on crash ?
>
> Seeing as gnome apps intercept by default SEGV and launch bug-buddy
> instead of creating a core dump and OOo does similar should we have a
> pile of bugs to just remove this stuff and crash to core and let
during last GUADEC we (GNOME guys) outlined a plan. Now bug-buddy
installs a seghandler as a GTK_MODULE.
If no debug symbols are present, the handler dumps a minidump file
of
the process and invokes bug-buddy, which sends it to a debug server.
This debug server is currently under developent
And we also have this wiki page:
http://fedoraproject.org/wiki/Releases/FeatureApport
It's like 4 buses came along at once :-), personally I don't actually care
what a given solution to what to do with crash stacktraces actually is,
but I would like there to be a single solution for our desktop apps and
start on connecting OOo up to it.
Sun doesn't take OOo distro stacktraces into their own infrastructure hence
the short-term quick and dirty paste me in dialog which has ended up being a
long-term hideous solution. I'd like to not quick suck so badly, so it's be
nice to have a common distro crashreporting infrastructure/policy.
Even if that policy is "fedora doesn't want to know about them, send them
directly
to the upstream project servers". that's be fine too and I could start on trying
to
cook up a custom OOo solution.
C.
10:42 a.m.
Le vendredi 27 juillet 2007 à 11:28 +0100, Richard Hughes a écrit :
"Crack" would be a valid comment but obviously, I would
prefer more in
depth and reasoned criticism :-)
I agree with most of your stuff except:
- removing password requirement to install/update is very very stupid
and dangerous (think script-kiddies, visiting kids that click
everywhere, etc)
- auditing tools must be built-in from the start up. The desktop team
likes to replace well-understood and easily verified scripts/CLI
commands with callback-heavy black magic no one understands (sometimes
several layers of black magic because you know it's so much easier to
add a layer than fix the one underneath), without comprehensive doc or
error reporting. This is somewhat acceptable for desktop toys but not
for core stuff like system updates.
- while a lot of the updating pain is at the GUI level, and no one will
mourn the current GUI update apps, you'll still need work at the yum
level so
* it does not barf at the slightest problem (on the CLI the sysadmin
papers over yum ; in GUI mode that's somewhat less easy)
* updates are done in batches of small transactions instead of a huge
brittle one (every time rawhide is frozen/unfrozen you get a huge 800+
package update transaction which is almost sure to fail halfway)
- you'll need a CLI async client too for some user populations and it
better be a real usable tool not a CamelCase-speaking monstruosity.
- if you go async client/server and allow an update client to remotely
control updates of a pool of systems, you'll make a killing in the
desktop enterprise space
--
Nicolas Mailhot
10:58 a.m.
I think we need a way to pass options to pirut that will limit what
packages it shows.
Use case: OpenOffice.org Language packs.
You want to install a new language package for ooo. You click "Install
new language pack" or something. This should launch pirut, but ONLY
show ooo language packs. (probably can be done as there is (or should
be) a naming convention for this type of thing)
The use of Pirut should stay exactly as it is now for this. No need to
give users or programs extra rights apart from launching Pirut as a
new process with the needed options. If the person has admin
priviledges (Pirut will ask for password), the packages can be
installed. If not, then they can't.
Use case 2: Yum plugins.
An option in say Pirut allows extra yum plugins to be downloaded and
installed (kmod handling, presto etc). The person is already using
pirut, so the person will have the authority to carry out the actions.
Click the "Extend Package manager" or similar link, and it will list
all plugin packages for yum (or only list packages with yum in the
name...).
Possible? Something I as a simple end user am overlooking? Should I file a RFE?
2:31 a.m.
On Sun, 2007-08-12 at 16:58 +0100, Naheem Zaffar wrote:
You want to install a new language package for ooo. You click
"Install
new language pack" or something. This should launch pirut, but ONLY
show ooo language packs. (probably can be done as there is (or should
be) a naming convention for this type of thing)
Nah, I think as soon as you select the german spellchecker then oo
should prompt to install the german language pack.
The use of Pirut should stay exactly as it is now for this. No need
to
give users or programs extra rights apart from launching Pirut as a
new process with the needed options. If the person has admin
priviledges (Pirut will ask for password), the packages can be
installed. If not, then they can't.
That's broken. My girlfriend writes in Polish on my system, I trust her,
yet she isn't an admin. I think it makes perfect sense to allow her to
install the polish dictionaries.
Richard.
2:28 a.m.
On Sun, 2007-08-12 at 17:42 +0200, Nicolas Mailhot wrote:
Le vendredi 27 juillet 2007 à 11:28 +0100, Richard Hughes a écrit :
> "Crack" would be a valid comment but obviously, I would prefer more in
> depth and reasoned criticism :-)
I agree with most of your stuff except:
- removing password requirement to install/update is very very stupid
and dangerous (think script-kiddies, visiting kids that click
everywhere, etc)
Well, my argument is that as soon as you give someone physical access to
the machine you've lost already. I'm betting that rm -rf ~/ would be a
bigger loss than installing an openoffice update in most people's cases.
- auditing tools must be built-in from the start up. The desktop
team
likes to replace well-understood and easily verified scripts/CLI
commands with callback-heavy black magic no one understands (sometimes
several layers of black magic because you know it's so much easier to
add a layer than fix the one underneath), without comprehensive doc or
error reporting. This is somewhat acceptable for desktop toys but not
for core stuff like system updates.
I'm guessing the machines that have to be audited just won't use
PackageKit. It really is designed to just do the action after checking a
few policy knobs rather than a whole new system like red carpet.
- while a lot of the updating pain is at the GUI level, and no one
will
mourn the current GUI update apps, you'll still need work at the yum
level so
* it does not barf at the slightest problem (on the CLI the sysadmin
papers over yum ; in GUI mode that's somewhat less easy)
Define barf?
* updates are done in batches of small transactions instead of a
huge
brittle one (every time rawhide is frozen/unfrozen you get a huge 800+
package update transaction which is almost sure to fail halfway)
Sure. I'm sure we could deal with this in a yum-plugin or something,
although rawhide unfreezing isn't my ideal use-case environment.
- you'll need a CLI async client too for some user populations
and it
better be a real usable tool not a CamelCase-speaking monstruosity.
Yes, I already have an async command line tool.
- if you go async client/server and allow an update client to
remotely
control updates of a pool of systems, you'll make a killing in the
desktop enterprise space
I don't care about enterprise at the moment, I'm working on the typical
home-use system. I don't know enough about enterprise systems, nor don't
have any such desire to "fix" things there. Sure PackageKit might help
the enterprise use case but I'm not actively trying to address that
need.
Thanks,
Richard.
6098
days inactive
6115
days old
40 comments
22 participants
participants (22)
-
Adam Jackson -
Alexander Boström -
Bill Nottingham -
Caolán McNamara -
Colin Walters -
David Zeuthen -
drago01 -
Fernando Herrera -
Frank Schmitt -
Jan Kratochvil -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Matthias Clasen -
Naheem Zaffar -
Nicolas Mailhot -
Paul Nasrat -
Richard Hughes -
Roland McGrath -
seth vidal -
Tim Lauridsen -
Toshio Kuratomi