Le Fri, 05 Sep 2014 18:26:37 +0530, Ritesh Raj Sarraf <r...@researchut.com> a écrit :
> On Tuesday 02 September 2014 02:00 PM, Ritesh Raj Sarraf wrote: > > On Monday 01 September 2014 05:27 PM, Laurent Bigonville wrote: > >> I think this is actually a race condition between apport-notifyd > >> and /usr/share/apport/apport. > >> > >> Shouldn't apport-notifyd only respond to IN_CLOSE_WRITE inotify > >> events instead of IN_CREATE so we are sure the file is fully > >> written? > > > > Thanks Laurent. That should be the reason. I'll check and do a new > > upload soon. > > Did you play with the change you had proposed ? > > I tried it but now I do not get the apport popups. I'll look into it > sometime later but if you already did, please do share your results. > No I didn't really test it it was a wild guess, sorry. Looking at how ubuntu is doing this, it seems that everything is handled by update-notifier which calls /usr/share/apport/apport-checkreports twice. First time to see if there are reports for the user and then to see if there are reports from system service. In case there are system reports it call apport-gtk with pkexec to gain root privs. In case of user reports it just call apport-gtk (I guess we should detect the desktop environment here?). apport-gtk takes no arguments, so I guess it will take care of all the pending reports at once(?). All the code is in src/crash.c from update-notifier on ubuntu. I guess we could mimic the same behavior? As a first step, I would stop trying to launch apport-bug for .crash not owned by the user, this would fix the bug related to the permissions. I guess the rest could be improve over time? Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
