Bug#452020: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC)
Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the mklibs package: #452020: Wrong library reduction performed when building debian-installer on PowerPC It has been closed by Bastian Blank [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Bastian Blank [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) Subject: Re: Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC From: Bastian Blank [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 12:15:30 +0100 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] On Mon, Nov 19, 2007 at 10:26:27PM +0100, Attilio Fiandrotti wrote: I noticed the mklibs performs uncorrectly when building the d-i on PowerPC [1]: as i'm not mklibs expert You use a broken version of slang. The linker call lacks the map file which maps the symbol versions. | $ dpkg -l libslang2-pic [...] | ii libslang2-pic 2.0.7-5The S-Lang programming library, shared libra | $ dpkg -L libslang2-pic | grep .map | /usr/lib/libslang_pic.map This usualy means you use an outdated or otherwise broken build environment. Please provide proper informations about the packages you use in the bugreport. This i what i got on the PowerPC machine where mklibs failed to operate on libslang2 [EMAIL PROTECTED]:~/svn/installer/build$ apt-cache show libslang2-pic slang-pic Package: libslang2-pic ... Version: 2.0.7-3 Depends: libslang2-dev (= 2.0.7-3) [EMAIL PROTECTED]:~/svn/installer/build$ dpkg -L libslang2-pic /. /usr /usr/lib /usr/lib/libslang_pic.a /usr/share /usr/share/doc /usr/share/doc/libslang2-pic /usr/share/doc/libslang2-pic/copyright /usr/share/doc/libslang2-pic/changelog.gz /usr/share/doc/libslang2-pic/changelog.Debian.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libslang2-pic as you can see, the /usr/lib/libslang_pic.map file was not provided by that version of the package, so i modified the /etc/apt/sources.list file to take debs from unstable instead of lenny and, after updating the package list, a new libslang2-pic package, version 2.0.7-3 again, was pulled in, this time providing the needed map file and i could successfully complete the building of the installer. Still, i wonder why i had to mess with sources.list to get the correct package. Many thanks for helping me solve this issue! Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC
Package: mklibs Severity: serious Version: 0.1.26 I noticed the mklibs performs uncorrectly when building the d-i on PowerPC [1]: as i'm not mklibs expert , i'm reporting what FJP said about this issue: It looks like somehow the @SLANG2 extension changes to @Base during library reduction and that causes that the symbol cannot be found. The post can be found here [2] and this bug was workarounded for now by using mklibs-copy in place of mklibs. regards Attilio Fiandrotti [1] https://debian.polito.it/downloads/build_pkg-list.log.gz [2] http://lists.debian.org/debian-boot/2007/11/msg00500.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407205: LVM Volume deleted from graphical installer
retitle 395489 Handler for single SELECT and MULTISELECT questions updates debconf database even if BACK is selected severity 395489 normal severity 407205 normal merge 395489 407205 thanks Frans Pop wrote: On Tuesday 16 January 2007 21:27, Frans Pop wrote: The second problem _is_ in the graphical frontend. It turns out that the value of a question is changed even if GoBack is selected. In this respect it behaves different from the regular frontend. Cloning your report to cdebconf-gtk-udeb for this issue. This issue may a bit more subtle than this: the frontend may just be setting a proper default for the question. However, this is still not desired behavior when GoBack is used. Ok, i've already seen this before and even filed a BR (#395489). For single SELECT and MULTISELECT questions, which are all dislayed using a GtkTreeView, the question's value gets set in debconf database every time the user clicks/moves on a row. As a result, the last activated option is always made default for SELECT questions, no matter the user pressed Back. This was considered a minor bug, so never spent time in fixing it: should i do it now ? cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403639: Fix committed in svn repo
Frans Pop wrote: On Thursday 11 January 2007 18:21, Loïc Minier wrote: I've uploaded these debs to unstable. OK, thanks. That means that we can get some more testing in before requesting migration. Let's hope that with Lenny we can switch to a truly integrated 2.10 soon. I strongly agree: gtk/dfb has an always evolving codebase, with many important fixes (about to be) recently committed and backporting every one of them to 2.8 would be a real pain. No luck yet in tracking down mem leaks during progressbar runs :( Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403639: Fix committed in svn repo
Loïc Minier wrote: On Mon, Jan 08, 2007, Attilio Fiandrotti wrote: Just wanted to say the patch was eventually committed to gnome svn [1]: i tried a backport to our 2.8.20 but was unable to due to that complex set of patches already present :( Would be possible building an experimental 2-8-20 udeb with this patch to see what its effects are? It's not trivial to backport, the upstream 2.10 code doesn't map so well with our 2.8.20 with backported directfb and I think it wouldn't be possible to pull the 2.10 directfb files as they rely on the internal 2.10 functions. :-/ Yes, i know this patch adds comlexity to gtk+ 2.8.20, which is growing to be a complicated hairball.. I've applied the patch by hand the best I could, it built, could you please try the packages at: http://people.dooz.org/~lool/debian/gtk+2.0/2.8.20-4/sid-pbuilder/ thanks for patching: i built an iso [1] and it looks like leakage is now small during normal questions display and still noticeable during progressbar runs. I'd like someone else than me (Frans?) give this iso a objective test and report if he thinks the leakage is now reduced. By my side, i'll investigate why we still leak when a progressbar is run (this puzzles me, as the progressbar is never destroyed, just hidden). Attilio [1] https://debian.polito.it/downloads/mini_gtk+_2.8.20-4.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403639: Fix committed in svn repo
Hi Just wanted to say the patch was eventually committed to gnome svn [1]: i tried a backport to our 2.8.20 but was unable to due to that complex set of patches already present :( Would be possible building an experimental 2-8-20 udeb with this patch to see what its effects are? thanks Attilio [1] http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk/directfb/gdkwindow-directfb.c?r1=16906r2=17014rev=17014sortby=date -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403639: Patch for this bug should be available soon
Hi
following up to myself to announce that a preliminary patch (attached)
for this bug was worked out some days ago and should be soon available
in a definitive version as soon as mike emmel, gtkdfb maintainer,
reviews it.
The patch fixes the memory leaks that were experienced when destroying a
child gdkwindow (takes care of releasing the cairo surface associated
with a gdkwindow).
Experiments i did with cdebconf and various test scripts showed a huge
redcution in wasted memory (100KB vs 900KB) for a set of ~10 questions
asked in sequence.
Attilio
Index: gdk/directfb/gdkwindow-directfb.c
===
RCS file: /cvs/gnome/gtk+/gdk/directfb/gdkwindow-directfb.c,v
retrieving revision 1.11
diff -u -r1.11 gdkwindow-directfb.c
--- gdk/directfb/gdkwindow-directfb.c 14 Sep 2006 02:56:01 - 1.11
+++ gdk/directfb/gdkwindow-directfb.c 22 Dec 2006 10:32:14 -
@@ -613,7 +613,18 @@
impl-window-Close(impl-window);
impl-window-Release(impl-window);
}
+#if 1
+ if (impl-drawable.surface) {
+GdkDrawableImplDirectFB *dimpl = GDK_DRAWABLE_IMPL_DIRECTFB (private-impl);
+if(dimpl-cairo_surface) {
+ cairo_surface_destroy(dimpl-cairo_surface);
+ dimpl-cairo_surface= NULL;
+}
+impl-drawable.surface-Release (impl-drawable.surface);
+impl-drawable.surface = NULL;
+ }
+#endif
#if 0 /* let the finalizer kill it */
if (!recursing !foreign_destroy)
{
@@ -1265,15 +1276,15 @@
if (!private-input_only)
{
- if (impl-drawable.surface)
-{
- GdkDrawableImplDirectFB *dimpl;
- dimpl= GDK_DRAWABLE_IMPL_DIRECTFB (private-impl);
- impl-drawable.surface-Release (impl-drawable.surface);
- impl-drawable.surface = NULL;
- cairo_surface_destroy(dimpl-cairo_surface);
- dimpl-cairo_surface= NULL;
-}
+if (impl-drawable.surface) {
+ GdkDrawableImplDirectFB *dimpl = GDK_DRAWABLE_IMPL_DIRECTFB (private-impl);
+ if(dimpl-cairo_surface) {
+cairo_surface_destroy(dimpl-cairo_surface);
+dimpl-cairo_surface= NULL;
+ }
+impl-drawable.surface-Release (impl-drawable.surface);
+impl-drawable.surface = NULL;
+ }
parent_impl = GDK_WINDOW_IMPL_DIRECTFB (GDK_WINDOW_OBJECT (private-parent)-impl);
Bug#403639: Memory leaks happens when destroying a GdkWindow
package: libgtk-directfb-2.0-0 severity: serious tags: upsteam It was recently found that during a g-i installation the GTK frontend can easily cause an out of memory error, due to the big amount of memory allocated at every installation step (nearly 1 MB). After some investigations with test GTK applications, the problem was found to be [1] in the way gdk/directfb releases resources when a gdkwindow is destroyed ( i suspect because of [1] a missing g_object_unref() somewhere, but that's just my supposition ). Awaiting now a reply from gtk/dfb maintainers. CC'ing debian-boot as this strongly impacts on g-i usability. [1] http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00063.html Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401876: Different gtk behaviour from newt when a select question has no options
Hi I really wonder what's the difference between the newt and gtk frontend that causes some questions being asked by gtk frontend and not by newt. I noticed that when a SELECT question has no options, like this Name: test/select Type: select Default: Choices: Description: Choose,man Extended_description: This is the prompt for a select-type question. then the newt frontend returns automatically DC_OK or DC_GOBACK, don't know exactly, while the gtk frontend waits for an user's click on a button. Since, IIUC, in this case the user is anyway prompted for at least one option, i guess this is not the case, but maybe the gtk frontend has to follow newt in this particular case? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397678: main-menu: segfaults on amd64 after Set up users and passwords step
Some times ago Jerome reported a similar crash on amd64 with the graphical installer, he even provided a strace log [1] of the crash. Since this crash, suspected to be due to DFB libraries on AMD64, was impossible to reproduce on aregular debian AMD64 system, i wonder if it's related to some other d-i component. Eugeny, any bell ringing looking at Jerome's strace log? cheers Attilio [1] http://lists.debian.org/debian-boot/2006/10/msg01961.html Eugeniy Meshcheryakov wrote: Additional information: I cannot reproduce this bug with image from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-businesscard.iso built on 20061102 (at least it is written on F1 screen, I downloaded it today). 8 листопада 2006 о 22:06 +0100 Eugeniy Meshcheryakov написав(-ла): Package: main-menu Severity: grave After configuring users and passwords in d-i screen starts blinking and following messages appear at console (may contain typos): process: ###): INFO: kbd-mode: setting console mode to Unicode (UTF-8) On other console, following messages appear: init: starting pid ### console /dev/vc/1: '/sbin/debian-installer' debconf: setting debconf/language to uk kernel: main-menu[###]: segfault at rip error 4 I used image downloaded from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-businesscard.iso Image was built on 20061106. I also tried to run installation in English and got the same results (except that language in debconf's meesage was en). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397678: main-menu: segfaults on amd64 after Set up users and passwords step
Eugeniy Meshcheryakov wrote: Package: main-menu Severity: grave After configuring users and passwords in d-i screen starts blinking and following messages appear at console (may contain typos): process: ###): INFO: kbd-mode: setting console mode to Unicode (UTF-8) On other console, following messages appear: init: starting pid ### console /dev/vc/1: '/sbin/debian-installer' debconf: setting debconf/language to uk kernel: main-menu[###]: segfault at rip error 4 I used image downloaded from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-businesscard.iso Image was built on 20061106. I also tried to run installation in English and got the same results (except that language in debconf's meesage was en). Eugeny, were you installing textual (NEWT) or graphical (GTK) ? We experienced a similar crash (#373253 and #396520) with the g-i on AMD64 and it would b einteresting investigating if bugs are somehow related. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359336: gtk+2.0-directfb: GMemChunk deprecated and disabled.
hi Luckily, GTK+ 2.10 release is behind the corner (is scheduled for may [1]) and will include the now integrated and well-maintained DFB backend, so we have to hold on tight for some times still. Leaving behind the old ( and good :) GTKDFB 2.0.9 will be a great step ahead but to switch to a GTK+ 2.10 based GTK installer we'll need to wait for the next major release of libraries (mainly DFB and Cairo), currently in CVS. I hope i'll be able to post a detailed report about the status of the system libraries the g-i relies upon tomorrow, before the next d-i meeting. [1] http://www.gtk.org/plan/2.10/ friendly Attilio fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
