Re: GTK
I meant, how can I remove GTK support when building installer. In other words how to generate debian installer image completely without gtk support. I have some troubles in generating d-i image, so I want to try if removing gtk support can resolve them. Michal Filka 2010/12/22 Ferenc Wagner wf...@niif.hu: Michal Filka michal.fi...@gmail.com writes: how can I remove GTK support from debian-installer? By removing the appropriate initrd file. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimvwxk=zoohaab1cecr=4savxidq8ynf+eb-...@mail.gmail.com
Re: GTK
Michal Filka michal.fi...@gmail.com writes: how can I remove GTK support from debian-installer? By removing the appropriate initrd file. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y67iujto@tac.ki.iif.hu
Re: GTK
Quoting Michal Filka (michal.fi...@gmail.com): I meant, how can I remove GTK support when building installer. In other words how to generate debian installer image completely without gtk support. I have some troubles in generating d-i image, so I want to try if removing gtk support can resolve them. You need to edit files in installer/build/pkg-lists -- signature.asc Description: Digital signature
Re: GTK+ 2.14 and directFB
On Sat, Feb 21, 2009 at 04:26:40PM +0100, Josselin Mouette wrote:
I’ve just uploaded 2.14.7-3 to experimental. Comments welcome.
2.14.7-3 segfaults, both in the installer and in a cdebconf test
environment. Here's the stack trace for the later:
[Switching to Thread 0x7f6f9ad216e0 (LWP 7055)]
0x7f6f99568a6c in IA__gdk_window_set_events (window=0x169ab50,
event_mask=64514)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:3608
3608 GDK_WINDOW_IMPL_GET_IFACE (private-impl)-set_events (window,
event_mask);
(gdb) bt full
#0 0x7f6f99568a6c in IA__gdk_window_set_events (window=0x169ab50,
event_mask=64514)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:3608
__PRETTY_FUNCTION__ = IA__gdk_window_set_events
#1 0x7f6f9957eb30 in gdk_directfb_window_new (parent=0x169a8d0,
attributes=0x7fffa2d45310,
attributes_mask=value optimized out, window_caps=value optimized out,
window_options=DWOP_NONE,
surface_caps=value optimized out) at
/mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/directfb/gdkwindow-directfb.c:499
window = (GdkWindow *) 0x169ab50
impl = value optimized out
visual = value optimized out
desc = {flags = 2588520016, caps = 32623, width = 98, height = 0,
pixelformat = -1706447280, posx = 32623,
posy = 23888016, surface_caps = DSCAPS_NONE}
x = 0
y = 0
__PRETTY_FUNCTION__ = gdk_directfb_window_new
#2 0x7f6f9956784e in IA__gdk_window_new (parent=0x169a8d0,
attributes=0x16abda0, attributes_mask=23771136)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:374
window = value optimized out
__PRETTY_FUNCTION__ = IA__gdk_window_new
#3 0x7f6f99a05e98 in gtk_window_realize (widget=0x16c8080)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gtk/gtkwindow.c:4615
parent_window = (GdkWindow *) 0x169a8d0
attributes = {title = 0x0, event_mask = 64514, x = 480, y =
-1717546880, width = 640, height = 480,
wclass = GDK_INPUT_OUTPUT, visual = 0x16ab4c0, colormap = 0x16745c0,
window_type = GDK_WINDOW_TOPLEVEL,
cursor = 0x1830500, wmclass_name = 0x16c9ea0 unknown, wmclass_class =
0x16d1820 unknown,
override_redirect = 23830096, type_hint = GDK_WINDOW_TYPE_HINT_NORMAL}
__PRETTY_FUNCTION__ = gtk_window_realize
#4 0x7f6f982fb11d in IA__g_closure_invoke (closure=0x16b9e50,
return_value=0x0, n_param_values=1,
param_values=0x1830500, invocation_hint=0x7fffa2d45500) at
/build/buildd/glib2.0-2.18.4/gobject/gclosure.c:767
marshal = (GClosureMarshal) 0x7f6f982f9620 g_type_class_meta_marshal
marshal_data = (gpointer) 0xe0
__PRETTY_FUNCTION__ = IA__g_closure_invoke
#5 0x7f6f9830e628 in signal_emit_unlocked_R (node=0x16ba050, detail=0,
instance=0x16c8080, emission_return=0x0,
instance_and_params=0x1830500) at
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3174
accumulator = (SignalAccumulator *) 0x0
emission = {next = 0x7fffa2d45990, instance = 0x16c8080, ihint =
{signal_id = 14, detail = 0,
run_type = G_SIGNAL_RUN_FIRST}, state = EMISSION_RUN, chain_type = 23823136}
class_closure = (GClosure *) 0x16b9e50
handler_list = (Handler *) 0x0
return_accu = (GValue *) 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong
= 0, v_int64 = 0, v_uint64 = 0,
v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0,
v_long = 0, v_ulong = 0, v_int64 = 0,
v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
signal_id = 14
max_sequential_handler_number = 17
return_value_altered = 0
#6 0x7f6f983101d8 in IA__g_signal_emit_valist (instance=0x16c8080,
signal_id=value optimized out, detail=0,
var_args=0x7fffa2d456e0) at
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:2977
signal_return_type = 4
param_values = (GValue *) 0x1830518
node = (SignalNode *) 0x16ba050
i = 0
n_params = 0
__PRETTY_FUNCTION__ = IA__g_signal_emit_valist
#7 0x7f6f983106d3 in IA__g_signal_emit (instance=0x169ab50,
signal_id=23772576, detail=23771136)
at /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3034
var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area =
0x7fffa2d457c0,
reg_save_area = 0x7fffa2d45700}}
#8 0x7f6f999f6506 in IA__gtk_widget_realize (widget=0x16c8080)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gtk/gtkwidget.c:3319
mode = value optimized out
__PRETTY_FUNCTION__ = IA__gtk_widget_realize
#9 0x7f6f99a066d8 in gtk_window_show (widget=0x16c8080) at
/mnt/incoming/tmp/gtk+2.0-2.14.7/gtk/gtkwindow.c:4314
info = (GtkWindowGeometryInfo *) 0x16dbb70
allocation = {x = 0, y = 0, width = 640, height = 480}
configure_request = {x = 0, y = 0, width = 640, height = 480}
new_geometry = {min_width = 640, min_height = 480, max_width = 0,
max_height = 0, base_width = 0,
base_height = 0, width_inc = 0,
Re: GTK+ 2.14 and directFB
Le samedi 21 février 2009 à 18:45 +0100, Sven Neumann a écrit : Hi, On Sat, 2009-02-21 at 16:26 +0100, Josselin Mouette wrote: I’ve just uploaded 2.14.7-3 to experimental. Comments welcome. From looking at the changelog it appears that you did not include the change that fixes scrolling. As far as I understand the situation, this is important for the graphical installer. It should be included. As the header of the 032_ patch shows: GNOME #554407 Upstream svn r22358,r22381,r22383,r22385 AFAICT it is r22385. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GTK+ 2.14 and directFB
Hi, On Mon, 2009-02-23 at 12:25 +0100, Josselin Mouette wrote: It should be included. As the header of the 032_ patch shows: GNOME #554407 Upstream svn r22358,r22381,r22383,r22385 AFAICT it is r22385. Correct. All is well then :) Sven -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GTK+ 2.14 and directFB
Le samedi 21 février 2009 à 12:54 +0100, Sven Neumann a écrit : I am somewhat surprised that there is still no GTK+ 2.14 package that has the DirectFB fixes applied, not even in experimental. I spent the last two evenings to fix all problems you pointed out. If there are still issues with the graphical installer, then I would like you to tell me about them. I suggest that you patch gtk+-2.4.7 with the full set of changes that I applied to the gtk-2-14 branch in svn.gnome.org. This will give you the state of the DirectFB port that will be released as GTK+ 2.4.8. I have attached a patch with these changes to this mail. Sorry, but I’ve been very busy with other stuff, and apparently no one else is interested enough to work on it. I’ve just uploaded 2.14.7-3 to experimental. Comments welcome. Looking forward to see gtk+ 2.14 and GNOME 2.24 finally appear in sid, It would be best to wait for 2.12.12 to migrate to testing so that we can upload prepare a 2.12.12 for the next stable point release, but given the state of the alpha buildds, this is not going to happen. If nothing changes, I’ll upload 2.14.7 to unstable and 2.12.12 to testing-proposed-updates instead. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GTK+ 2.14 and directFB
Josselin Mouette wrote: Le samedi 21 février 2009 à 12:54 +0100, Sven Neumann a écrit : I’ve just uploaded 2.14.7-3 to experimental. Comments welcome. Looking forward to see gtk+ 2.14 and GNOME 2.24 finally appear in sid, It would be best to wait for 2.12.12 to migrate to testing so that we can upload prepare a 2.12.12 for the next stable point release, but given the state of the alpha buildds, this is not going to happen. If nothing changes, I’ll upload 2.14.7 to unstable and 2.12.12 to testing-proposed-updates instead. The alpha buildd is unstuck since yesterday and there is a second one which might be added in the near future. Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GTK+ 2.14 and directFB
Hi, On Sat, 2009-02-21 at 16:26 +0100, Josselin Mouette wrote: I’ve just uploaded 2.14.7-3 to experimental. Comments welcome. From looking at the changelog it appears that you did not include the change that fixes scrolling. As far as I understand the situation, this is important for the graphical installer. But thanks anyway for the new package. At least things are moving again now. Sven -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GTK+ 2.14 and directFB
On Wed, Feb 18, 2009 at 02:30:58AM +0100, Josselin Mouette wrote:
thanks to Sven Neumann who jumped in very quickly to resolve this issue,
we now have a set of GTK+ 2.14 packages that are supposed to have a
working DirectFB backend.
I have just uploaded this version (2.14.7-2) to experimental. The
packages should install fine on unstable, so there is no need to upgrade
anything else.
What I need now is volunteers to test them, so that’s where debian-boot
is welcome to have a look. If you meet any major issues with this
version, please send the relevant debugging information or a test
program with instructions.
The graphical installer fails to start with this version as the result
of a segfault.
cdebconf GTK+ frontend also segfaults when using DirectFB/X11 on a
normal system. Here's the test procedure and the resulting stacktrace:
$ apt-get source cdebconf cd cdebconf-0.138lenny2
$ ./configure --with-frontend=gtk --enable-d-i \
--with-conffile=./cdebconf.conf
$ make
$ cd src/test
$ sed -n -e 's/text/gtk/' -e '/^global/,+31p' \
../../doc/testing.txt cdebconf.conf
$ ../debconf-loadtemplate d-i test.templates
$ ../debconf test.config
You also need to have libdirectfb-1.0-extra installed and to put in your
~/.directfbrc:
system=x11
When run under GDB, the previous command result in the following:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9ccdbde6e0 (LWP 32596)]
0x7f9ccc4269bc in IA__gdk_window_set_events (window=0x969350,
event_mask=64514)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:3608
3608 GDK_WINDOW_IMPL_GET_IFACE (private-impl)-set_events (window,
event_mask);
(gdb) bt full
#0 0x7f9ccc4269bc in IA__gdk_window_set_events (window=0x969350,
event_mask=64514)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:3608
__PRETTY_FUNCTION__ = IA__gdk_window_set_events
#1 0x7f9ccc43cbb0 in gdk_directfb_window_new (parent=0x9690d0,
attributes=0x7fffd5c041f0,
attributes_mask=value optimized out, window_caps=value optimized out,
window_options=DWOP_NONE,
surface_caps=value optimized out)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/directfb/gdkwindow-directfb.c:500
window = (GdkWindow *) 0x969350
impl = value optimized out
visual = value optimized out
desc = {flags = 3442835024, caps = 32668, width = 98, height = 0,
pixelformat = -852132272,
posx = 32668, posy = 10055824, surface_caps = DSCAPS_NONE}
x = 0
y = 0
__PRETTY_FUNCTION__ = gdk_directfb_window_new
#2 0x7f9ccc42579e in IA__gdk_window_new (parent=0x9690d0,
attributes=0x978ca0, attributes_mask=9930544)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gdk/gdkwindow.c:374
window = value optimized out
__PRETTY_FUNCTION__ = IA__gdk_window_new
#3 0x7f9ccc8c2e98 in gtk_window_realize (widget=0x997080)
at /mnt/incoming/tmp/gtk+2.0-2.14.7/gtk/gtkwindow.c:4615
parent_window = (GdkWindow *) 0x9690d0
attributes = {title = 0x0, event_mask = 64514, x = 480, y = -863231872,
width = 640, height = 480,
wclass = GDK_INPUT_OUTPUT, visual = 0x97a8c0, colormap = 0x9431c0,
window_type = GDK_WINDOW_TOPLEVEL,
cursor = 0xaff900, wmclass_name = 0x99cc20 unknown, wmclass_class =
0x9a0bc0 unknown,
override_redirect = 9998896, type_hint = GDK_WINDOW_TYPE_HINT_NORMAL}
__PRETTY_FUNCTION__ = gtk_window_realize
#4 0x7f9ccb1b911d in IA__g_closure_invoke (closure=0x989230,
return_value=0x0, n_param_values=1,
param_values=0xaff900, invocation_hint=0x7fffd5c043e0)
at /build/buildd/glib2.0-2.18.4/gobject/gclosure.c:767
marshal = (GClosureMarshal) 0x7f9ccb1b7620 g_type_class_meta_marshal
marshal_data = (gpointer) 0xe0
__PRETTY_FUNCTION__ = IA__g_closure_invoke
#5 0x7f9ccb1cc628 in signal_emit_unlocked_R (node=0x989430, detail=0,
instance=0x997080,
emission_return=0x0, instance_and_params=0xaff900) at
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3174
accumulator = (SignalAccumulator *) 0x0
emission = {next = 0x7fffd5c04870, instance = 0x997080, ihint =
{signal_id = 14, detail = 0,
run_type = G_SIGNAL_RUN_FIRST}, state = EMISSION_RUN, chain_type = 9991936}
class_closure = (GClosure *) 0x989230
handler_list = (Handler *) 0x0
return_accu = (GValue *) 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong
= 0, v_int64 = 0, v_uint64 = 0,
v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0,
v_long = 0, v_ulong = 0,
v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
signal_id = 14
max_sequential_handler_number = 17
return_value_altered = 0
#6 0x7f9ccb1ce1d8 in IA__g_signal_emit_valist (instance=0x997080,
signal_id=value optimized out,
detail=0, var_args=0x7fffd5c045c0) at
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:2977
Re: GTK+ update proposal for stable
Le dimanche 15 février 2009 à 17:07 -0300, Otavio Salvador a écrit : Josselin Mouette j...@debian.org writes: I don’t have anything right now that I’d like to put in these packages, so the thing they need the most is testing. I can upload them to s-p-u as soon as you want. If SRM do not object I think it would be nice to have them there ASAP so we can start testing them. Unfortunately a new GTK+ version needs to be uploaded to unstable and migrate to testing first, as it gets rejected by the archive consistency check :( -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GTK+ update proposal for stable
Le lundi 16 février 2009 à 12:48 +0100, Josselin Mouette a écrit : Le dimanche 15 février 2009 à 17:07 -0300, Otavio Salvador a écrit : If SRM do not object I think it would be nice to have them there ASAP so we can start testing them. Unfortunately a new GTK+ version needs to be uploaded to unstable and migrate to testing first, as it gets rejected by the archive consistency check : 2.12.12-1 has just been accepted to unstable. Let’s hope it can migrate to squeeze quickly, otherwise we’ll have to re-upload it to both squeeze and lenny… -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GTK+ update proposal for stable
On Sun, Feb 15, 2009 at 05:28:02PM +0100, Josselin Mouette wrote: Now that we have the hands more free, I’d like to propose GTK+ 2.12.12 for a lenny point release. We’ve received some requests to upgrade to this bugfix-only release, fixing a number of issues that you’re likely to hit with the 2.12.11 version currently in lenny, including several crashers. Ok, please go ahead. Thanks for contacting us that early so that it spends plenty of time in proposed-updates. We will see what d-i testing with the new binaries will bring us. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:p...@0x539.de Stable Release Manager `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: GTK+ update proposal for stable
Philipp Kern pk...@debian.org writes: On Sun, Feb 15, 2009 at 05:28:02PM +0100, Josselin Mouette wrote: Now that we have the hands more free, I’d like to propose GTK+ 2.12.12 for a lenny point release. We’ve received some requests to upgrade to this bugfix-only release, fixing a number of issues that you’re likely to hit with the 2.12.11 version currently in lenny, including several crashers. Ok, please go ahead. Thanks for contacting us that early so that it spends plenty of time in proposed-updates. We will see what d-i testing with the new binaries will bring us. In this case Josselin, please contact us at debian-boot once you've prepared the packages and binaries (it wasn't clear from your message if you consider current ones ready) so we can start testing them. -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GTK+ update proposal for stable
Le dimanche 15 février 2009 à 15:36 -0300, Otavio Salvador a écrit : Philipp Kern pk...@debian.org writes: Ok, please go ahead. Thanks for contacting us that early so that it spends plenty of time in proposed-updates. We will see what d-i testing with the new binaries will bring us. In this case Josselin, please contact us at debian-boot once you've prepared the packages and binaries (it wasn't clear from your message if you consider current ones ready) so we can start testing them. I don’t have anything right now that I’d like to put in these packages, so the thing they need the most is testing. I can upload them to s-p-u as soon as you want. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GTK+ update proposal for stable
Josselin Mouette j...@debian.org writes: Le dimanche 15 février 2009 à 15:36 -0300, Otavio Salvador a écrit : Philipp Kern pk...@debian.org writes: Ok, please go ahead. Thanks for contacting us that early so that it spends plenty of time in proposed-updates. We will see what d-i testing with the new binaries will bring us. In this case Josselin, please contact us at debian-boot once you've prepared the packages and binaries (it wasn't clear from your message if you consider current ones ready) so we can start testing them. I don’t have anything right now that I’d like to put in these packages, so the thing they need the most is testing. I can upload them to s-p-u as soon as you want. If SRM do not object I think it would be nice to have them there ASAP so we can start testing them. -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gtk d-i : using size instead of shape to differentiate text
Eduardo Silva wrote: --- Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eduardo Silva wrote: [cut] Yes :) I think that the creator of the current look, Andre Ferreira, may be wanting to do that as well, but I think the more icons done, the better :) I guess you're talking about these icons, right? http://wiki.debian.org/DebianDesktopArtwork/DebianInstallerEtch Cheers Attilio Yes, those are the ones. Only later did I read the text better and understood that they are icons from pre-existing themes. Oh, and attilio, my laptop went bust (doesn't power up), I'm still in the limbo I've been for some time, and I can't really promisse of being able to make the icons before etch releases. But if I was able, this is what I would do: I would get the svg sources (http://www.geocities.com/jobezone/icones_1.svg.tar.gz) for the icons I did ( http://www.geocities.com/jobezone/note_1.png and http://www.geocities.com/jobezone/warning_1.png ) and make them more simillar with http://www.geocities.com/jobezone/note_look.png and http://www.geocities.com/jobezone/warning_look.png . The main change would be having a white border instead of black, inverting the colors (like in these two links) and making a better triangle with rounded corners for the warning icon. Then, to give that final glassy look (web 2.0 kinda look) to go with the banner look, I would make it slightly shinny like in the image I'm sending to you (of a job I've done some time ago), but with less shininess. The trick would be to create a shape in inkscape on top of the icon, and make it white and with some transparency. The kind of shape you make ends up defining the roundiness of the icon, so I wouldn't put such a big one like in the attatched icon. I guess you are probably busy as hell to do this now, but maybe you know someone who could? To be honest, i' haven't any of the skills needed to do what you proposed :( I really hoped you could spend some time, before Etch is released, on the icons you originally drew, but as it looks like this is not possible i'm for leaving them as they are or switching to those by http://wiki.debian.org/DebianDesktopArtwork/DebianInstallerEtch cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk d-i : using size instead of shape to differentiate text
--- Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eduardo Silva wrote: [cut] Yes :) I think that the creator of the current look, Andre Ferreira, may be wanting to do that as well, but I think the more icons done, the better :) I guess you're talking about these icons, right? http://wiki.debian.org/DebianDesktopArtwork/DebianInstallerEtch Cheers Attilio Yes, those are the ones. Only later did I read the text better and understood that they are icons from pre-existing themes. Oh, and attilio, my laptop went bust (doesn't power up), I'm still in the limbo I've been for some time, and I can't really promisse of being able to make the icons before etch releases. But if I was able, this is what I would do: I would get the svg sources (http://www.geocities.com/jobezone/icones_1.svg.tar.gz) for the icons I did ( http://www.geocities.com/jobezone/note_1.png and http://www.geocities.com/jobezone/warning_1.png ) and make them more simillar with http://www.geocities.com/jobezone/note_look.png and http://www.geocities.com/jobezone/warning_look.png . The main change would be having a white border instead of black, inverting the colors (like in these two links) and making a better triangle with rounded corners for the warning icon. Then, to give that final glassy look (web 2.0 kinda look) to go with the banner look, I would make it slightly shinny like in the image I'm sending to you (of a job I've done some time ago), but with less shininess. The trick would be to create a shape in inkscape on top of the icon, and make it white and with some transparency. The kind of shape you make ends up defining the roundiness of the icon, so I wouldn't put such a big one like in the attatched icon. I guess you are probably busy as hell to do this now, but maybe you know someone who could? Be well, Eduardo OH MY ... http://www.geocities.com/jobezone/index.html Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: gtk d-i : using size instead of shape to differentiate text
Eduardo Silva wrote: --- Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eduardo Silva wrote: Hi everybody, In gtk d-i, wouldn't it be better to use size to differentiate the sections of text, instead of using diffent shapes(bold, italic, regular)? Currently, all the text has the same size, and are differentiated like this (ordered by importance): Step title - bold Question - regular Options/Text Entry title - italic Question description - regular What I sugest would be (assuming the Next/Go Back text size is now at 10 px): Step title - 12 px Question - 11 px Options/Text Entry title- 10 px Question description - 9 px. If it makes the interface too confusing (too many sizes), then 10 px. Of course, the diferences in size could be greater, for example, the Step title could be 2 pixels bigger than the question, and the Question 2 pixels bigger than the Options/Text Entry title. It would only depend on the maximum amount of text that there could exist on-screen at the minimum resolution possible. The reasons I ordered the sizes this way are: Step title: a user shouldn't loose himself in what part of the instalation he is in :) ; Question: a user must then know what is being requested/asked of him; Options/Text Entry title: a user must then know his available options, or what he must type exactly in the text entry; Question description: after getting the previous three, the user can read a semi-detailed description of what is being requested/asked of him. New users would read them anyway, but users which install many times debian, or have been using debian in the past, or are advanced users, etc., will know by heart or understand imediately what each question is about, and will disregard it. An example (not the best, because has little text) of how doing this improves the readability of an interface, see for example this gdm theme for etch: http://cdd.debian-br.org/~si0ux/artwork/debian/01/01gdm.png The title Welcome is the first thing grabing atention, then the Text entry title Username. I agree that weigth, size and style of text used for title, question description and extended question description should not be hardcoded in the GTK frontend, like it happens now, butexternally defined in the gtkrc file. I don't know if this is possible (i'd like to define css-like styles in gtkrc), but for sure it's something that is worth investigating. Eduardo, btw, do you think you can update the ! and X icons you created some times ago to match the look of clearlooks theme we're now using in the g-i? Thanks Attilio Yes :) I think that the creator of the current look, Andre Ferreira, may be wanting to do that as well, but I think the more icons done, the better :) I guess you're talking about these icons, right? http://wiki.debian.org/DebianDesktopArtwork/DebianInstallerEtch Cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk d-i : using size instead of shape to differentiate text
--- Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eduardo Silva wrote: Hi everybody, In gtk d-i, wouldn't it be better to use size to differentiate the sections of text, instead of using diffent shapes(bold, italic, regular)? Currently, all the text has the same size, and are differentiated like this (ordered by importance): Step title - bold Question - regular Options/Text Entry title - italic Question description - regular What I sugest would be (assuming the Next/Go Back text size is now at 10 px): Step title - 12 px Question - 11 px Options/Text Entry title- 10 px Question description - 9 px. If it makes the interface too confusing (too many sizes), then 10 px. Of course, the diferences in size could be greater, for example, the Step title could be 2 pixels bigger than the question, and the Question 2 pixels bigger than the Options/Text Entry title. It would only depend on the maximum amount of text that there could exist on-screen at the minimum resolution possible. The reasons I ordered the sizes this way are: Step title: a user shouldn't loose himself in what part of the instalation he is in :) ; Question: a user must then know what is being requested/asked of him; Options/Text Entry title: a user must then know his available options, or what he must type exactly in the text entry; Question description: after getting the previous three, the user can read a semi-detailed description of what is being requested/asked of him. New users would read them anyway, but users which install many times debian, or have been using debian in the past, or are advanced users, etc., will know by heart or understand imediately what each question is about, and will disregard it. An example (not the best, because has little text) of how doing this improves the readability of an interface, see for example this gdm theme for etch: http://cdd.debian-br.org/~si0ux/artwork/debian/01/01gdm.png The title Welcome is the first thing grabing atention, then the Text entry title Username. I agree that weigth, size and style of text used for title, question description and extended question description should not be hardcoded in the GTK frontend, like it happens now, butexternally defined in the gtkrc file. I don't know if this is possible (i'd like to define css-like styles in gtkrc), but for sure it's something that is worth investigating. Eduardo, btw, do you think you can update the ! and X icons you created some times ago to match the look of clearlooks theme we're now using in the g-i? Thanks Attilio Yes :) I think that the creator of the current look, Andre Ferreira, may be wanting to do that as well, but I think the more icons done, the better :) Eduardo OH MY ... http://www.geocities.com/jobezone/index.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk d-i : using size instead of shape to differentiate text
Eduardo Silva wrote: Hi everybody, In gtk d-i, wouldn't it be better to use size to differentiate the sections of text, instead of using diffent shapes(bold, italic, regular)? Currently, all the text has the same size, and are differentiated like this (ordered by importance): Step title - bold Question - regular Options/Text Entry title - italic Question description - regular What I sugest would be (assuming the Next/Go Back text size is now at 10 px): Step title - 12 px Question - 11 px Options/Text Entry title- 10 px Question description - 9 px. If it makes the interface too confusing (too many sizes), then 10 px. Of course, the diferences in size could be greater, for example, the Step title could be 2 pixels bigger than the question, and the Question 2 pixels bigger than the Options/Text Entry title. It would only depend on the maximum amount of text that there could exist on-screen at the minimum resolution possible. The reasons I ordered the sizes this way are: Step title: a user shouldn't loose himself in what part of the instalation he is in :) ; Question: a user must then know what is being requested/asked of him; Options/Text Entry title: a user must then know his available options, or what he must type exactly in the text entry; Question description: after getting the previous three, the user can read a semi-detailed description of what is being requested/asked of him. New users would read them anyway, but users which install many times debian, or have been using debian in the past, or are advanced users, etc., will know by heart or understand imediately what each question is about, and will disregard it. An example (not the best, because has little text) of how doing this improves the readability of an interface, see for example this gdm theme for etch: http://cdd.debian-br.org/~si0ux/artwork/debian/01/01gdm.png The title Welcome is the first thing grabing atention, then the Text entry title Username. I agree that weigth, size and style of text used for title, question description and extended question description should not be hardcoded in the GTK frontend, like it happens now, butexternally defined in the gtkrc file. I don't know if this is possible (i'd like to define css-like styles in gtkrc), but for sure it's something that is worth investigating. Eduardo, btw, do you think you can update the ! and X icons you created some times ago to match the look of clearlooks theme we're now using in the g-i? Thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Loïc Minier wrote: On Sun, Sep 24, 2006, Attilio Fiandrotti wrote: Meanwhile, if you want to see if you can reproduce the BOOM bug in GTK from CVS, you can proceed as follows (you'll need a ssh terminal). -Run gtk-demo and open the hypertext app -Attach gdb to the process and set a breakpoint at gtk_target_table_free() and continue running -close the hypertext window with meta-c, you'll enter the gtk_target_table_free() -At some point you should get a crash in the for() loop, can you reproduce this? Ok, I suppose I could reach the crash and setup an initial environment for testing, but that's not good enough for debugging for now. Here's what I did: - boot with a vesa framebuffer on the kernel command line - build gtk-demo against directfb from the gtk source: * fakeroot debian/rules debian/stampdir/configure-stamp-directfb * cd debian/tmp/build/directfb/demos/gtk-demo * make (should fail at the final link) * gcc $(pkg-config --cflags --libs gtk+-directfb-2.0) -o gtk-demo *.o * launch ./gtk-demo as root - I also had to setup mode= in /root/.directfbrc and capslock-meta So, I could launch the hypertext app, and close it with CapsLock+c. I still had the mouse afterwards, but I did *not* have the etch-a-sketch bug. Instead, nothing else was happening, I couldn't do anything with the interface anymore. I couldn't switch VT anymore. That's *exactly* the bug i used to experience and i reported about in July, you were able to reproduce it perfectly :) I'm not 100% sure this is also the BOOM bug, but if you try running a cdebconf test application with the GTK frontend, when you click the OK or BACK button, the bug will make cdebconf hang, so i guess it's important fixing it anyway. Now that this bug has been reproduced by someone else than me too, i'll file a bugreport in GNOME's BTS. Since I have a single console, it's not easy to debug the graphical problem; perhaps there's a virtual output for DirectFB (like Xvfb)? try adding to /etc/directfbrc this line system=sdl now you should be able to have DFB rendering into a X window. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Loïc Minier wrote: On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed, so to get a working GTKDFB library you'll have to use sources form CVS HEAD. The link you're giving seems like the solution of the bug I've searched the last hour or so. If it's only that, it should be easy to include in the Debian packages, thanks for the pointer. After talking with Mike Emmel, it looks like the following changes 2006-09-13 Michael Emmel [EMAIL PROTECTED] * gdk/directfb/gdkcolor-directfb.c small clean ups include order * gdk/directfb/gdkwindow-directfb.c fixed beep compile error * gdk/directfb/Makefile.am removed GDK_PIXBUF_DISABLE_DEPRECATED GDK_DISABLE_DEPRECATED to allow compile per Behdad * gdk/quartz/Makefile.am same change as directfb Makefile * gtk/Makefile.am fixed typo that cause socket stubs not to compile were not propagated to 2.8.4, so nor the directfb nor the glitz backends will work :( In addition to this, the bug i posted about in July still affects GTK CVS HEAD, so i think this is enough to try re-backporting from scratch the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is dated around May 2006). I checked with Joss, and he said you did the backporting. Would you provide a similar patch or explain the process you followed to make it? Ok, i'll try to rebuild the patch. Meanwhile, if you want to see if you can reproduce the BOOM bug in GTK from CVS, you can proceed as follows (you'll need a ssh terminal). -Run gtk-demo and open the hypertext app -Attach gdb to the process and set a breakpoint at gtk_target_table_free() and continue running -close the hypertext window with meta-c, you'll enter the gtk_target_table_free() -At some point you should get a crash in the for() loop, can you reproduce this? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Hi, Based on your messages, I included the fixes you mention plus some missing files as well, and was able to build Gtk 2.10.4 / DirectFB. I've uploaded the result to experimental. On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed On Sun, Sep 24, 2006, Attilio Fiandrotti wrote: After talking with Mike Emmel, it looks like the following changes 2006-09-13 Michael Emmel [EMAIL PROTECTED] were not propagated to 2.8.4, so nor the directfb nor the glitz backends will work :( -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Great! did you also manage to reproduce the crash that makes the g-i hang on button click? Loïc Minier wrote: Hi, Based on your messages, I included the fixes you mention plus some missing files as well, and was able to build Gtk 2.10.4 / DirectFB. I've uploaded the result to experimental. On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed On Sun, Sep 24, 2006, Attilio Fiandrotti wrote: After talking with Mike Emmel, it looks like the following changes 2006-09-13 Michael Emmel [EMAIL PROTECTED] were not propagated to 2.8.4, so nor the directfb nor the glitz backends will work :( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sun, Sep 24, 2006, Attilio Fiandrotti wrote: Meanwhile, if you want to see if you can reproduce the BOOM bug in GTK from CVS, you can proceed as follows (you'll need a ssh terminal). -Run gtk-demo and open the hypertext app -Attach gdb to the process and set a breakpoint at gtk_target_table_free() and continue running -close the hypertext window with meta-c, you'll enter the gtk_target_table_free() -At some point you should get a crash in the for() loop, can you reproduce this? Ok, I suppose I could reach the crash and setup an initial environment for testing, but that's not good enough for debugging for now. Here's what I did: - boot with a vesa framebuffer on the kernel command line - build gtk-demo against directfb from the gtk source: * fakeroot debian/rules debian/stampdir/configure-stamp-directfb * cd debian/tmp/build/directfb/demos/gtk-demo * make (should fail at the final link) * gcc $(pkg-config --cflags --libs gtk+-directfb-2.0) -o gtk-demo *.o * launch ./gtk-demo as root - I also had to setup mode= in /root/.directfbrc and capslock-meta So, I could launch the hypertext app, and close it with CapsLock+c. I still had the mouse afterwards, but I did *not* have the etch-a-sketch bug. Instead, nothing else was happening, I couldn't do anything with the interface anymore. I couldn't switch VT anymore. Since I have a single console, it's not easy to debug the graphical problem; perhaps there's a virtual output for DirectFB (like Xvfb)? I think I will setup a qemu or vmware to debug this. Thanks for the hints! Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Frans Pop wrote: On Wednesday 20 September 2006 11:00, Loïc Minier wrote: Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after dinstall). This new upstream release is not compatible with modules built with prior Gtk versions. Some longstanding issues have been addressed in this release as well. I have tested g-i with the libs currently in experimental: - libgtk* 2.10.3-3 - libcairo udeb 1.2.4-2 Unfortunately this results in the following screenshot. http://people.debian.org/~fjp/d-i/g-i_boom.png Although it is a very nice feature to be able to Etch-a-sketch with the installer (and very appropriate too), it does make installations impossible. What happens is that on the first screen, I can use cursor keys and the mouse to select items, but as soon as I press enter or click the Continue button with the mouse, the installer freezes and I can Etch-a-sketch with the mouse. Hey, now i remember i ran into a similar issue [1] some times ago. I wasn't able to fix it, but i eventually concluded it was due to a memory corruption issue that affects GTK (or GLib or something else), no matter what GDK backend was used, and not the DFB backend (see gdb traces in the below thread). Such a bug causes crashes with the DFB backend and on some test machines only, but never causes crashes with the X backend, even if memory corruption could be detected with gdb. I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? :) we could file a proper bugreport to have ot fixed in next GTK release. Attilio [1] http://mail.gnome.org/archives/gtk-devel-list/2006-July/msg00157.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Saturday 23 September 2006 12:54, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? Well, I see it completely reliably with the image I built for 2.10 in vmware. Possibly the fact that it is vmware also makes it reproducible for others. pgpe1PRpyxhhL.pgp Description: PGP signature
Re: Gtk 2.10 availability
Frans Pop wrote: On Saturday 23 September 2006 12:54, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? Well, I see it completely reliably with the image I built for 2.10 in vmware. Possibly the fact that it is vmware also makes it reproducible for others. if we could build a 2.10.x ISO with debugging symbols for GTK+, and processes run within vmware could be debugged remotlely using gdb (like qemu allows to do), this could be a a good proof for the bug. Meanwhile, let's see if can reproduced with GTKX 2.10.4. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? :) we could file a proper bugreport to have ot fixed in next GTK release. I would be happy to be a test puppet, but one of the reason I requested testing of Gtk 2.10 + DirectFB was that I don't know how to test it. I know it sounds a bit irresponsible, so I did my best to verify that I didn't break anything incrementally (but I still missed some stuff). I don't want you to lose too much time explaining me with details how your test environment is built, but if you could give some high level hints on the process you follow to test, what you test, and how you debug, that would be really nice. If such a documentation already exist, that would be nice! The most effective way for me would be to be able to test binaries from my laptop, perhaps from a different VT. I understand I might need to boot some d-i builds via the network or a CD in some cases. I also have a Xen setup, it it can help in any tests, and even a VMWare Workstation license (didn't update the kernel modules to 2.6.17 though). Thanks in advance for your help! Please don't feel obliged to document this in great length, I don't want to waste *your* time. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: if we could build a 2.10.x ISO with debugging symbols for GTK+, and processes run within vmware could be debugged remotlely using gdb (like qemu allows to do), this could be a a good proof for the bug. Meanwhile, let's see if can reproduced with GTKX 2.10.4. What would be the best way to have debug symbols? libgtk2.0-0-dbg has the debug symbols of both flavors of Gtk, for example it has: /usr/lib/debug/usr/lib/libgdk-directfb-2.0.so.0.1000.3 /usr/lib/debug/usr/lib/libgtk-directfb-2.0.so.0.1000.3 Some objects are built with both flavors, I'm not sure whether the debug symbols are for both or only one particular flavor. Perhaps you simply want a build with DEB_BUILD_OPTIONS=nostrip noopt of the udeb? -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Saturday 23 September 2006 19:22, Loïc Minier wrote: What would be the best way to have debug symbols? libgtk2.0-0-dbg has the debug symbols of both flavors of Gtk, for example it has: /usr/lib/debug/usr/lib/libgdk-directfb-2.0.so.0.1000.3 /usr/lib/debug/usr/lib/libgtk-directfb-2.0.so.0.1000.3 Some objects are built with both flavors, I'm not sure whether the debug symbols are for both or only one particular flavor. Perhaps you simply want a build with DEB_BUILD_OPTIONS=nostrip noopt of the udeb? I don't think we want a debug udeb in the archive. If someone needs debugging symbols, he can (I suppose) quite easily do a local build with debugging enabled and use that when bulding d-i images. Thanks for the offer though. pgpkDx3nM99yS.pgp Description: PGP signature
Re: Gtk 2.10 availability
Loïc Minier wrote: On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? :) we could file a proper bugreport to have ot fixed in next GTK release. I would be happy to be a test puppet, but one of the reason I requested testing of Gtk 2.10 + DirectFB was that I don't know how to test it. I know it sounds a bit irresponsible, so I did my best to verify that I didn't break anything incrementally (but I still missed some stuff). I don't want you to lose too much time explaining me with details how your test environment is built, but if you could give some high level hints on the process you follow to test, what you test, and how you debug, that would be really nice. If such a documentation already exist, that would be nice! The most effective way for me would be to be able to test binaries from my laptop, perhaps from a different VT. I understand I might need to boot some d-i builds via the network or a CD in some cases. I also have a Xen setup, it it can help in any tests, and even a VMWare Workstation license (didn't update the kernel modules to 2.6.17 though). Thanks in advance for your help! Please don't feel obliged to document this in great length, I don't want to waste *your* time. First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed, so to get a working GTKDFB library you'll have to use sources form CVS HEAD. In addition to this, the bug i posted about in July still affects GTK CVS HEAD, so i think this is enough to try re-backporting from scratch the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is dated around May 2006). Your help in testing and debugging GTKDFB would be really useful and appreciated: what i usually do to is compiling GTKDFB with debugging symbols, and then running a GTK application like gtk-demo or the GIMP within gdb. I have no special methods to test the d-i but runing it into a chroot cage and attaching gdb at it. I know davide viti used to attach gdb to the debconf process running in qemu, but i've never done this by myself. cheers Attilio [1] http://cvs.gnome.org/viewcvs/gtk%2B/gtk/Makefile.am?r1=1.315r2=1.316 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed, so to get a working GTKDFB library you'll have to use sources form CVS HEAD. The link you're giving seems like the solution of the bug I've searched the last hour or so. If it's only that, it should be easy to include in the Debian packages, thanks for the pointer. In addition to this, the bug i posted about in July still affects GTK CVS HEAD, so i think this is enough to try re-backporting from scratch the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is dated around May 2006). I checked with Joss, and he said you did the backporting. Would you provide a similar patch or explain the process you followed to make it? -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Wednesday 20 September 2006 11:00, Loïc Minier wrote: Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after dinstall). This new upstream release is not compatible with modules built with prior Gtk versions. Some longstanding issues have been addressed in this release as well. I have tested g-i with the libs currently in experimental: - libgtk* 2.10.3-3 - libcairo udeb 1.2.4-2 Unfortunately this results in the following screenshot. http://people.debian.org/~fjp/d-i/g-i_boom.png Although it is a very nice feature to be able to Etch-a-sketch with the installer (and very appropriate too), it does make installations impossible. What happens is that on the first screen, I can use cursor keys and the mouse to select items, but as soon as I press enter or click the Continue button with the mouse, the installer freezes and I can Etch-a-sketch with the mouse. So, it looks like 2.10.3 has RC issues for the installer. Cheers, FJP pgpH7yKJswgRn.pgp Description: PGP signature
Re: Gtk 2.10 availability
Frans Pop wrote: On Wednesday 20 September 2006 11:00, Loïc Minier wrote: Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after dinstall). This new upstream release is not compatible with modules built with prior Gtk versions. Some longstanding issues have been addressed in this release as well. I have tested g-i with the libs currently in experimental: - libgtk* 2.10.3-3 - libcairo udeb 1.2.4-2 Unfortunately this results in the following screenshot. http://people.debian.org/~fjp/d-i/g-i_boom.png Although it is a very nice feature to be able to Etch-a-sketch with the installer (and very appropriate too), it does make installations impossible. I was totally amazed when i saw the BOOM PNG, never seen anything like that, also because the GTK 2.10 libs provided by loic worked well for me previously: i'll try to look at this tomorrow. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Wednesday 20 September 2006 11:00, Loïc Minier wrote: Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after dinstall). This new upstream release is not compatible with modules built with prior Gtk versions. Some longstanding issues have been addressed in this release as well. Here's a quick summary of the important news with emphasis on the changes required or not in the installer. Or, considering the length of the mail, not so quick ;-) Thanks very much for taking the trouble to write this mail. I see no problematic issues for the switch to 2.6.10. The main question I guess is: is there more information on if/when 2.10 could migrate to unstable? What is the chance that it will make Etch? Main reason I ask is that there are a few RC issues in the graphical installer (not crashes, but important presentation issues) that should be solved in 2.10, but are still present in 2.8. If the chance that 2.10 will _not_ make Etch is high, then we need to try to find fixes for these issues in 2.8. If that chance is negligible, we can concentrate on testing with the 2.10 libs. To my knowledge, no package is built against libgtk-directfb-2.0-dev, cdebconf is the only package built against libgtk+2.0-directfb-dev (which is the flavor of Gtk maintained by debian-boot@), and hence no package is affected by this change, but it should taken care of when switching cdebconf to build against libgtk-directfb-2.0-dev. No, cdebconf in unstable is built against libgtk-directfb-2.0-dev: Build-Depends: debhelper (= 5.0.22), po-debconf (= 0.5.0), libslang2-dev, libnewt-dev, libtextwrap-dev (= 0.1-5), libdebian-installer4-dev (= 0.41) | libdebian-installer-dev, libgtk-directfb-2.0-dev (= 2.8.18-5) libgtk+2.0-directfb-dev is deprecated and is only used in Beta 3 as that is still based on 2.0.9 libs. So we do need to make this change. Cheers, FJP pgp2RPbl53zkH.pgp Description: PGP signature
Re: Gtk 2.10 availability
On Wed, Sep 20, 2006, Frans Pop wrote: The main question I guess is: is there more information on if/when 2.10 could migrate to unstable? What is the chance that it will make Etch? The biggest instability in Gtk 2.10 is due to the new filesystem module asynchronous implementation. In short, this feature permits opening the File open... dialog (the picker) empty, and filling it's content in a separate thread while continuously responding to user input. In other word, the UI doesn't hang when opening a large directory. This particular issue was a bit rushed to make it in 2.10, and it was afterwards considered to revert its inclusion. See the upstream thread for details: http://mail.gnome.org/archives/gtk-devel-list/2006-August/thread.html#00068 It seems upstream is currently trying to address all known issues related to this change instead of reverting the code, so I suppose Gtk 2.10.4 will show whether they have succeeded in stabilizing this feature. Another problem of switching to Gtk 2.10 is the transition it involves due to the backward incompatibility with modules. This affects 19 source packages, three of these are under the control of the GNOME team. The transition needs some source changes, but these are relatively simple. IMO, the advantages release-wise of the new Gtk counter-balance this transition, but this didn't get any release team acceptance yet. One important part of the decision will be on the side of debian-boot@ as well. It is not innocently that I wishes you test the Gtk 2.10 udebs. If you do happen to find showstoppers for your uses of Gtk with the new release, it might kill the idea of 2.10 in etch. On the contrary, if you happen to find big advantages of 2.10 over 2.8, it would be an argument in favor of pushing 2.10 into etch. Main reason I ask is that there are a few RC issues in the graphical installer (not crashes, but important presentation issues) that should be solved in 2.10, but are still present in 2.8. If the chance that 2.10 will _not_ make Etch is high, then we need to try to find fixes for these issues in 2.8. If that chance is negligible, we can concentrate on testing with the 2.10 libs. I don't think the chances are negligible, so I'm willing to work on any outstanding issues that you see with 2.8 to build a solid backup plan. (Please continue focusing on 2.10 as the primary target though.) Here's what is already ready for a gtk+2.0 2.8.20-2 upload: * New patch, 009_revert-gdkdrawable-directfb, to revert a fix for Italic letters which caused ugly unneeded horizontal/vertical lines; thanks Davide Viti. (Closes: #386860) * Fix typo, install-dfb depends on build-dfb, not build-shared. Other things that need to be done: - addition of the pixmap engine - fix the empty /etc/gtk-2.0/gdk-pixbuf.loaders (#382435) Could you list any other thing that you consider RC or important that still need fixing in 2.8? No, cdebconf in unstable is built against libgtk-directfb-2.0-dev So we do need to make this change. Oh, my mistake, I was looking at the sources both in etch and sid at the same time, and didn't notice cdebconf/sid was using the new lib. Then the changes I have described are recommended indeed (but the current package will continue building exactly as well as it did until now). -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Frans Pop wrote: snip Main reason I ask is that there are a few RC issues in the graphical installer (not crashes, but important presentation issues) that should be solved in 2.10, but are still present in 2.8. If the chance that 2.10 will _not_ make Etch is high, then we need to try to find fixes for these issues in 2.8. If that chance is negligible, we can concentrate on testing with the 2.10 libs. I've just finished running cdebconf on my laptop with a set of debconf test scripts, and below is a list of bugs, currently assigned to cdebconf-gtk-udeb package, that affect GTKDFB 2.8.20/21 and no longer affect gtkdfb 2.10.x - #385026: display issues in checkbox lists (multiselect) - Also, the vertical line that used to cut the Debian top banner is no longer displayed. - Bug #340007: SELECT questions are not automatically scrolled to the active choice seems to be gone, but a test with a real miniiso is needed to state it definitely. This is roughly what i expected to achieve from the 2.8.x - 2.10.x GTKDFB library switch. GTKDFB 2.10.4, when available, will provide us also an enhanched/cleaner DFB backend. I'll make my best to make sure GTK 2.10.4 is released with a fully functional DFB backend (e.g. : GTK 2.10.3 was released with a broken DFB backend). cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
On Sun, Sep 03, 2006, Dave Beckett wrote: I've done this. libcairo 1.2.4-2 is now uploaded to experimental. Works great! Thanks, I've uploaded a snapshot of ongoing Gtk 2.10 work to experimental. One thing though: I think it would be safest to bump the libcairo-directfb2 shlibs as, currently, a gtk built against a PS/PDF enabled libcairo-directfb might not run against one. (I didn't bump the gtk build-dep on this PS/PDF libcairo-directfb-dev right now, but gtk/i386 in experimental is built against this new libcairo-dfb.) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: Hi, On Thu, Aug 31, 2006, Attilio Fiandrotti wrote: i did some testing today compiling gtk+ from CVS HEAD against libcairo-directfb2 (1.2.4-1) and libdirectfb-0.9-25 (0.9.25.1-3) and it turns out that - a fresher DirectFB than the latest release (0.9.25.1); I hope the DirectFB maintainer has the time to prepare a snapshot for experimental as requested in Debian #383238 this is no longer a problem, as GTK+ = 2.10.2 selectively excludes from compilation all the code that needs DFB = 0.9.26 to work (minimum requirement is now DFB 0.9.24) Yes, actually I continued working on Gtk 2.10.0 in our SVN but backported the needed delta from Gtk's CVS back then (this was before the relevant Gtk release). This is in pkg-gnome's SVN since 10 days or so. The GDKDFB backend found in GTK+ 2.10.2 contains many very important enhancements and fixes Mike Emmel introduced Fri Aug 11, which are not found in earlier (2.10.0, 2.10.1) GTK+ relases. I strongly suggest to skip GTK+ 2.10.0 and 2.10.1 and jump directly to GTK+ 2.10.2. snip/ - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. cool! :) Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Dave Beckett wrote: snip/ No, do not do this. I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. If your only concern is about cairodfb size, i guess having the system libraries passing thru mklibs before being installed into the d-i ISO image will cut away any unneded symbol like all the GTK+ printing stuff. PS and PDF cairo's backends are required by the printing stuff introduced in GTK 2.10 series, which is usually unuseful in embedded devices. I remember plans for post 2.10 GTK+ releases were to allow selective disabling compilation of the printing stuff, but there is little chance this feature to be introduced in GTK 2.10 series. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. Current GTKDFB 2.8.20 libraries found in debian repositories contain an old DFB backend i backported some months ago from GTK 2.9.x, and this backends not only has poor performance in some cases, but is also affected by a couple of serious bugs (like #385026) that were solved in GTK+ 2.10.2 release. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? Yes, please: the GTK on DFB project is raising interest between people involved in embedded linux development because the possibility to run a GTK app without running an X server too. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Hi, On Sat, Sep 02, 2006, Dave Beckett wrote: I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. I agree that we don't need the PDF/PS support in cairo's udebs because we don't need printing support in gtk's udebs, but since I can't easily cut away printing support in gtk, I now need cairo udeb with PDF/PS support. I don't know whether it's an useful measure of the final real runtime memory consumption, but the *.so sizes are: 316Kusr-nopdf/lib/libcairo-directfb/lib/libcairo.so.2.9.1 364Kusr/lib/libcairo-directfb/lib/libcairo.so.2.9.1 which is a non-negligible 15% indeed. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. That's a good question, but I think we at least need to try, and that involves building stuff in experimental, and testing. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? I prefer the current approach; it bloats less DirectFB only apps. I don't know any app which would benefit from a DirectFB+X cairo. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: Hi, On Sat, Sep 02, 2006, Dave Beckett wrote: I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. I agree that we don't need the PDF/PS support in cairo's udebs because we don't need printing support in gtk's udebs, but since I can't easily cut away printing support in gtk, I now need cairo udeb with PDF/PS support. This information seems the deciding point - you can't get rid of this requirement from building gtk. So... I don't know whether it's an useful measure of the final real runtime memory consumption, but the *.so sizes are: 316Kusr-nopdf/lib/libcairo-directfb/lib/libcairo.so.2.9.1 364Kusr/lib/libcairo-directfb/lib/libcairo.so.2.9.1 which is a non-negligible 15% indeed. yes. But despite this, you need it. So as long as the debian-boot team realises this, I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. That's a good question, but I think we at least need to try, and that involves building stuff in experimental, and testing. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. So what I propose is that I'll make some experimental packages with the PDF+PS enabled and you can try building with them. Although from your earlier emails, I expect this will just work since you've been trying this already. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? I prefer the current approach; it bloats less DirectFB only apps. I don't know any app which would benefit from a DirectFB+X cairo. OK. You replied in another email about embedded users of gtk, and I can see that as making this worthwhile to package and ship. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
On Sun, Sep 03, 2006, Dave Beckett wrote: I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Great! That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. So what I propose is that I'll make some experimental packages with the PDF+PS enabled and you can try building with them. Although from your earlier emails, I expect this will just work since you've been trying this already. Sure, that will work. (What I considered risky was the triple build where I build against one version of cairo+directfb which has PS+PDF, but the udeb version of cairo+directfb doesn't.) Thanks! -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: On Sun, Sep 03, 2006, Dave Beckett wrote: I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Great! I've done this. libcairo 1.2.4-2 is now uploaded to experimental. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: ... - to rebuild the DirectFB flavor of Cairo with --enable-pdf and --enable-ps as requested in Debian #383297 still awaiting the patch to be applied, currently GTK+ from HEAD does not compile against DFB flavour of cairo from debian packages because of lack of PDF and PS support. Indeed, I hadn't any new from Dave Beckett either. Dave, would you mind if I NMU libcairo with the proposed changes perhaps to experimental if you so prefer? No, do not do this. I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Hi i did some testing today compiling gtk+ from CVS HEAD against libcairo-directfb2 (1.2.4-1) and libdirectfb-0.9-25 (0.9.25.1-3) and it turns out that - a fresher DirectFB than the latest release (0.9.25.1); I hope the DirectFB maintainer has the time to prepare a snapshot for experimental as requested in Debian #383238 this is no longer a problem, as GTK+ = 2.10.2 selectively excludes from compilation all the code that needs DFB = 0.9.26 to work (minimum requirement is now DFB 0.9.24) - to rebuild the DirectFB flavor of Cairo with --enable-pdf and --enable-ps as requested in Debian #383297 still awaiting the patch to be applied, currently GTK+ from HEAD does not compile against DFB flavour of cairo from debian packages because of lack of PDF and PS support. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 04/07/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Where from can I get the gtk-demo app source? usually it's built togheter with gtk libraries : you should have it already compiled and ready to run somewhere in the gtkdfb packages you built.. But those are linked against the X11 variant, will have o rebuild it. Unfortunately, I don't think I will have time for this as I will be on vacation starting tomorrow. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 03/07/06, Eddy Petrişor [EMAIL PROTECTED] wrote: I also remember that on sven's macintosh (which should be similar o yours), back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? I hope to try this tonight in spite of real life engagements I have scheduled for tonight. Where from can I get the gtk-demo app source? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrişor wrote: On 03/07/06, Eddy Petrişor [EMAIL PROTECTED] wrote: I also remember that on sven's macintosh (which should be similar o yours), back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? I hope to try this tonight in spite of real life engagements I have scheduled for tonight. Where from can I get the gtk-demo app source? usually it's built togheter with gtk libraries : you should have it already compiled and ready to run somewhere in the gtkdfb packages you built.. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
The new packages: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/ It seems nobody complained about this, but the permissions are wrong for this. I will fix them tonight when I get home. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 30/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: I also added a strace for a regular (no video=ofonly) session at the same place. I looked at both dfb and strace logs and this could be bug #342053 : have you tried booting with the textual frontend, adding no-hardware to directfbrc and then starting the graphical frontend ? It is not that bug, I have added no-hardware and tested and the crashing still happens. I don't remember if I said this before, ofonly also crashes[1] I also remember that on sven's macintosh (which should be similar o yours), back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? I hope to try this tonight in spite of real life engagements I have scheduled for tonight. [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/iso/ppc-gtk-2.8-crash-ofonly.log -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrişor wrote: snip I also added a strace for a regular (no video=ofonly) session at the same place. I looked at both dfb and strace logs and this could be bug #342053 : have you tried booting with the textual frontend, adding no-hardware to directfbrc and then starting the graphical frontend ? I also remember that on sven's macintosh (which should be similar o yours), back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 30/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: I also added a strace for a regular (no video=ofonly) session at the same place. Note that I ran a session with video=ofonly which also crashed, but I didn't made a trace. I looked at both dfb and strace logs and this could be bug #342053 : have you tried booting with the textual frontend, adding no-hardware to directfbrc and then starting the graphical frontend ? No I didn't. But this seems rather odd because I had the graphical installer running on my laptop with old libs. Is there any reason to expect regressions? I also remember that on sven's macintosh (which should be similar o yours), I think he had an older model, mine is PowerBook5,2, iirc, his was PowerBook4,6 or something like that. Sven? back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? I will tonight, but I fear there is something else here... Sven, could you try the image I made[1] and see if is working for you? [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/iso/miniiso2.8.18-powerpc/20060629mini.iso -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
On Fri, Jun 30, 2006 at 01:14:10PM +0300, Eddy Petrişor wrote: On 30/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: I also added a strace for a regular (no video=ofonly) session at the same place. Note that I ran a session with video=ofonly which also crashed, but I didn't made a trace. I looked at both dfb and strace logs and this could be bug #342053 : have you tried booting with the textual frontend, adding no-hardware to directfbrc and then starting the graphical frontend ? No I didn't. But this seems rather odd because I had the graphical installer running on my laptop with old libs. Is there any reason to expect regressions? I also remember that on sven's macintosh (which should be similar o yours), I think he had an older model, mine is PowerBook5,2, iirc, his was PowerBook4,6 or something like that. Sven? Even older : machine : PowerBook3,5 I will try it out on my pegasos boxes too. back at extremadura, we had to boot textua, run gtk-demo, close gtk-demo, and then run the graphical installer as we were experiencing a system crash very similar to the one you described. Could you try this latest trick too ? I will tonight, but I fear there is something else here... Sven, could you try the image I made[1] and see if is working for you? [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/iso/miniiso2.8.18-powerpc/20060629mini.iso I will this evening. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrişor wrote: Sadness is filling my body as I have seen yet another G-I on powerpc :(( On 29/06/06, Eddy Petrişor [EMAIL PROTECTED] wrote: On 29/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: ok, there is no hurry: i was just curious to know wheter some ppc bugs were gone with newer libs. I am also curious about this. Probably some publicity on -powerpc, after I have build some images might be a good way to attract testers. i realy hope #342053, which is the most severe, has disappeared in DFB 0.9.24. I would put my money on it, but we'll see. I've build the image with gtk 2.8.18...and it crashes. A friend tested the PPC mini ISO on a minimac and he had to boot with video=ofonly to prevent the installer from crashing, and colours were messed up as usual. He also reported the installer hangs ( but he wasn't able to specify at what stage ) if the wireless mouse the minimac is provided with isn't switched on before the g-i boots. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 30/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: I've build the image with gtk 2.8.18...and it crashes. A friend tested the PPC mini ISO on a minimac and he had to boot with video=ofonly to prevent the installer from crashing, and colours were messed up as usual. Wasn't that only for the mouse cursor? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrisor wrote: snip Done, they are available on my router[1], in case anybody else wants them. Man, the compilation needed about 1.5GB free disk space.. [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/gtk/2.8.18-4/ Good work! :) Any chance to build a ppc miniiso with updated dfb, cairodfb and gtkdfb libs ? there are some still open bugs (#342053, #338191, #341770) for cdebconf-gtk related to PPC architecture that i sustect are related to older libraries. Also, it would be interesting to know wheter bug #373253 shows up on AMD64 only or also with other architectures different from i386. ciao Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 29/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eddy Petrisor wrote: Done, they are available on my router[1], in case anybody else wants them. Man, the compilation needed about 1.5GB free disk space.. [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/gtk/2.8.18-4/ Good work! :) Any chance to build a ppc miniiso with updated dfb, cairodfb and gtkdfb libs ? there are some still open bugs (#342053, #338191, #341770) for cdebconf-gtk related to PPC architecture that i sustect are related to older libraries. I will try tonight, but I have other real life things to do tomorrow, so I can say for sure. On Friday I will leave Timişoara, so I am not sure if I can sqeeze it before the weekend. What's sure is that'll try to do it ;-) Also, it would be interesting to know wheter bug #373253 shows up on AMD64 only or also with other architectures different from i386. AFAIR, none of the working images for powerpc had this issue. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
As a summary, now we have on powerpc: I have recompiled the cairo packages yesterday for powerpc tried to the cairo packages are at: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/cairo/libcairo-1.1.10-2/ and gtk+2.0 packages: [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/gtk/2.8.18-4/ -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrişor wrote: As a summary, now we have on powerpc: I have recompiled the cairo packages yesterday for powerpc tried to the cairo packages are at: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/cairo/libcairo-1.1.10-2/ and gtk+2.0 packages: [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/gtk/2.8.18-4/ updated gtkdfb wiki page [1] with link to your ppc debs. Attilio [1] http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB#Precompiled_Debian_packages_.28i386.2C_PowerPC.29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
Eddy Petrişor wrote: On 29/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Any chance to build a ppc miniiso with updated dfb, cairodfb and gtkdfb libs ? there are some still open bugs (#342053, #338191, #341770) for cdebconf-gtk related to PPC architecture that i sustect are related to older libraries. I will try tonight, but I have other real life things to do tomorrow, s/tomorrow/tonight/ so I can say for sure. On Friday I will leave Timişoara, so I am not s/I can/I can't/ [gah, so many mistakes in just a paragraph - there was another one here] ok, there is no hurry: i was just curious to know wheter some ppc bugs were gone with newer libs. I am also curious about this. Probably some publicity on -powerpc, after I have build some images might be a good way to attract testers. i realy hope #342053, which is the most severe, has disappeared in DFB 0.9.24. For sure new libraries will need some testing. ciao Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On 29/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: ok, there is no hurry: i was just curious to know wheter some ppc bugs were gone with newer libs. I am also curious about this. Probably some publicity on -powerpc, after I have build some images might be a good way to attract testers. i realy hope #342053, which is the most severe, has disappeared in DFB 0.9.24. I would put my money on it, but we'll see. For sure new libraries will need some testing. If others don't object, then, after te build of the images, I shall make a call for testers for the iso image with new libriaries.. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK+ 2.8.18 experimental debs/udebs
On Thursday 29 June 2006 10:19, Eddy Petrişor wrote: If others don't object, then, after te build of the images, I shall make a call for testers for the iso image with new libriaries.. Please test it extensively yourself first and let us know the results. Wider testing is only useful if there are no obvious issues. pgpruAkAmWW5P.pgp Description: PGP signature
Re: GTK+ 2.8.18 experimental debs/udebs
On 29/06/06, Frans Pop [EMAIL PROTECTED] wrote: On Thursday 29 June 2006 10:19, Eddy Petrişor wrote: If others don't object, then, after te build of the images, I shall make a call for testers for the iso image with new libriaries.. Please test it extensively yourself first and let us know the results. Wider testing is only useful if there are no obvious issues. Right, will do. To be honest, I was thinking more about things like hardware diversity when I said that (for instance, I have never seen #342053 on my laptop ;-). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
RE: GTK+ 2.8.18 experimental debs/udebs
Please test it extensively yourself first and let us know the results. Wider testing is only useful if there are no obvious issues. While on the subject, I've written some notes (see bottom of [1]) about changes Involved when building test images based on the new packages. It's my intention to test and see which of the currently open bugs still reproduce, So that once we'll do the switch, we'll also know exatctly what gets fixed. Regards, Davide [1] http://wiki.debian.org/DebianInstaller/GUIBuild
Re: GTK+ 2.8.18 experimental debs/udebs
Sadness is filling my body as I have seen yet another G-I on powerpc :(( On 29/06/06, Eddy Petrişor [EMAIL PROTECTED] wrote: On 29/06/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: ok, there is no hurry: i was just curious to know wheter some ppc bugs were gone with newer libs. I am also curious about this. Probably some publicity on -powerpc, after I have build some images might be a good way to attract testers. i realy hope #342053, which is the most severe, has disappeared in DFB 0.9.24. I would put my money on it, but we'll see. I've build the image with gtk 2.8.18...and it crashes. For sure new libraries will need some testing. If others don't object, then, after te build of the images, I shall make a call for testers for the iso image with new libriaries.. This will have to wait. Image and sdterr output: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/iso/ The new packages: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/ -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
On 30/06/06, Eddy Petrişor [EMAIL PROTECTED] wrote: Sadness is filling my body as I have seen yet another G-I on powerpc :(( [snip] I've build the image with gtk 2.8.18...and it crashes. For sure new libraries will need some testing. If others don't object, then, after te build of the images, I shall make a call for testers for the iso image with new libriaries.. This will have to wait. Image and sdterr output: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/iso/ I also added a strace for a regular (no video=ofonly) session at the same place. The new packages: http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/ -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
On 27/06/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 27 juin 2006 à 00:29 +0200, Davide Viti a écrit : I started testing libgtk+2.0-directfb0-udeb_2.8.18-3_i386.udeb I've rebuilt gtk+ against a fixed glib, the correct cairo, and without all loaders except the PNG one. Same place: http://people.debian.org/~joss/packages/ I have recompiled the cairo packages yesterday for powerpc tried to compile the gtk packages, but it seems that the compialtion of this package needs about 1GB+ on the machine, I had issues with this. I will try again tonight. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: GTK+ 2.8.18 experimental debs/udebs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eddy Petrişor wrote: On 27/06/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 27 juin 2006 à 00:29 +0200, Davide Viti a écrit : I started testing libgtk+2.0-directfb0-udeb_2.8.18-3_i386.udeb I've rebuilt gtk+ against a fixed glib, the correct cairo, and without all loaders except the PNG one. Same place: http://people.debian.org/~joss/packages/ I have recompiled the cairo packages yesterday for powerpc tried to compile the gtk packages, but it seems that the compialtion of this package needs about 1GB+ on the machine, I had issues with this. I will try again tonight. Done, they are available on my router[1], in case anybody else wants them. Man, the compilation needed about 1.5GB free disk space.. [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8-ppc/libs/gtk/2.8.18-4/ - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoxbLY8Chqv3NRNoRAhKSAJ9c6k7ZlA8X6MRgF+rB9hoMGs1PsQCg2Ja8 qz/z3GrS0jj4EHDwCsk5GYo= =FPrD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk+-directfb packages: call for help
On 6/21/06, Davide Viti [EMAIL PROTECTED] wrote: We think there's everything you need to produce gtk+-directfb packages; it's not officially available yet, but packaging could be done anyway and would help the d-i team to start working on migrating from old libraries to new ones. Your help is thoroughly appreciated, TIA, As we talked on IRC, I have done some work on this issue. You can find what I have done[1]* in chronological order, so basically the most recent stuff is better. I will put the result of my work at the end of a day in separate directory (I know this is not version management ;-) ). [1] http://eddyp.homelinux.net:8080/eddy/g-i/gtk2.8transition/ * this machine sometimes blocks (I think it needs more cooling), so it might not be always accesible during the day, but when I arrive at home (around 7 o'clock in the evening, EET) I see this problem and restart it -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Josselin Mouette wrote: Le mercredi 17 mai 2006 à 00:37 +0200, Attilio Fiandrotti a écrit : The above library requirements apply to both GTK 2.9.0 and 2006-03- 26 CVS snapshot (which is older than 2.9.0 ). More recent GTK CVS snapshots require glib 2.11, pango 1.11 ( and DFB 0.9.25 i think). Does the 2006-03-26 integrate all the necessary changes for DFB? More interestingly, would it be possible to extract the necessary patches for DFB and to apply them to 2.8? If they are not invasive, that's probably a better way to go. That would be possible, but some patching of Makefile is required, as shown in this patchfile [0] for GTK 2.8.10 from DFB's CVS repository, where the GDKDFB project lived for many years before entering GTK mainline. Also, some bugfixes applied to the DFB backend after it was merged into GTK mainline should be backported. I just filed reports (and a patch) for two bugs [1][2] that currently prevent GTK 2.9.1 from compiling with the DFB backend. If GTK team fixes those bugs before GTK 2.9.2 is released, we could build the GTKDFB libraries without the need for patches to original source tarballs. Note that GTK 2.9.1 requires pango 1.13 (not udeb-packaged yet), while GTK 2.9.0 requires only pango 1.12 (available as udeb): if at GTK 2.9.2 release time pango 1.13 should not have udeb-packaged yet, backporting patches for bugs 342091 and 342093 to GTK 2.9.0 could be an option too. frienly Attilio [0] http://www.directfb.org/index.php/viewcvs.cgi/gdk-directfb/gtk- directfb.patch?rev=1.91content-type=text/vnd.viewcvs-markup [1] http://bugzilla.gnome.org/show_bug.cgi?id=342091 [2] http://bugzilla.gnome.org/show_bug.cgi?id=342093 Tiscali ADSL 4 Mega Flat Naviga senza limiti a 19,95 Euro al mese con 4 Megabps di velocita'. Attiva subito: hai 2 MESI di canone adsl GRATIS! In piu', se sei raggiunto dalla rete Tiscali, telefoni senza pagare il canone Telecom. Scopri subito come risparmiare! http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:48:30AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? Thanks in advance, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? As far as my understanding goes, Frans is not the one who expanded the CC list. In short, faudrait peut-être pas trop déconner, quand même. signature.asc Description: Digital signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Wed, May 17, 2006 at 10:27:38PM -0500, Christian Perrier wrote: Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? As far as my understanding goes, Frans is not the one who expanded the CC list. In short, faudrait peut-être pas trop déconner, quand même. Ah, but the original CC expanding had a reason and technical content, while frans reply had none. That said, it was not my intention to in any way try to take Frans place as d-i RM. I just wanted that we had the right information, so we could discuss this issue in good knowledge of facts, and not with random suppositions, like we did previously. I really fail to see how this could be interpreted as a problem, and if i am supposed to ask permission for writing this kind of emails, or ask frans to write it, things will very quickly turn very tedious. Frans, there is enough bureaucrazy in debian as is, no need to add another set of unnecessary layer. This is just discussion and planning, and everyone should be free to do that, as long as it doesn't indulge in insults and agressive bashing, but i believe my emails where devoid of that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tuesday 16 May 2006 09:37, you wrote: I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Thank you for this quick and sane reply. pgpicDYPrUyAW.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. I will now officially start ignoring _any_ mails you send unless it threatens to interfere with d-i work. Bye. P.S. Gnome packagers: please ignore the message sent by Sven. pgpKxZJzfgXgS.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:37:36AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be pro-active for this, and start experimenting, and even making them the default NOW. GTK 2.9 is GNOME 2.16 material, lot of packages Depends on GTK and making a start of unstable cycle version the default is not a good idea Ok, this is what i was afraid of. It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 Ah, i thought the 2.9 ones where already available. If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot or a final 2.10 package just for us would be no worse than the current 2.0.x packages that we have today. I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Ah, this was in the context of a gtk-dfb only package, and many of the g-i team are arguing that a development 2.9 snapshot is preferable than the unmaintained upstream 2.0.x stuff we are using now. So, basically, this means we will be forced to maintain our own gtk-dfb libs for the etch timeframe, unless there is some serious slip for the etch release, and we have the choice of keeping the 2.0.x gtk-dfb .udebs and using some out of the devel CVS. Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:48:30AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. Huh ? Whyever not ? Frans, you are backsliding in the bash-sven modus again. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. Please tell me what harm i have done. both attilio and davide and eddy seem to be in favour of 2.9+ .udebs, i did nothing but to get firm information outr of the gtk/gnome folk, so we have strong basis for this discussion. How could this ever be seen as hurting d-i or being a problem ? I will now officially start ignoring _any_ mails you send unless it threatens to interfere with d-i work. Well, maybe, but i don't understand why. You are over-reacting in this. Gnome packagers: please ignore the message sent by Sven. More anti-sven vendeta, thanksfully Sebastien already gave the information that was needed. Frans, we are discussing, this is an important issue, can you not put your pride or whatever aside, and let everyone discuss this ? I didn't a single time insult you or use other kind of bad behavior, and i believe my mail was both technically good and interesting to all involved, so what is it you are having a problem with ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 09:37, you wrote: I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Thank you for this quick and sane reply. Please consider that the GNOME guys might have answered in the light of _all_ the features and _all_ the bugs that might be present at this point in the current gtk, BUT the G-I need just a *tiny* piece of functionality of the whole GTK libraries (Attilio can give you a hint on which parts are actually used). (Just to give a scale of what we are talking about, not even the standard OK and cancel buttons are used in G-I.) Taking into account that, IMHO, it would make sense to have a different source package for the G-I suff (mainly because of the DFB backend and packaging issues that may occur), would you, the GNOME team, consider to state your oppinion on such a decision of using a CVS/2.9+ snapshot _just_ for the G-I stuff? I think this is a huge difference and many of the concerns you might have would not apply to this given situation. Attilio could you please summarize what is actualy used in G-I so that the GNOME guys can say what they think for this particular case? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 10:07:45AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Or would it make sense to build the gtk-dfb variant from the same cvs/svn repo as the rest of the gtk stuff is done, instead of a standalone snapshot outside of it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be pro-active for this, and start experimenting, and even making them the default NOW. GTK 2.9 is GNOME 2.16 material, lot of packages Depends on GTK and making a start of unstable cycle version the default is not a good idea It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot or a final 2.10 package just for us would be no worse than the current 2.0.x packages that we have today. I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Cheers, Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ?
Sebastien Bacher [EMAIL PROTECTED] writes: Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 IIRC the 2.9.0 was releases two weeks ago. Still, it's some time until 2.10 will be released and it *will* be too late for the current freeze plans. Marc -- Fachbegriffe der Informatik - Einfach erklärt 24: Future Computer Whiz Kids Energy Mobilizer Kühlschrank mit Cola und Kartoffelchips drin. (Peter Berlich) pgpITqUaT8uXG.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 10:58:52AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 10:23 +0200, Sven Luther a écrit : Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Are you saying you want to hijack GTK now? Err, no. I am saying, that upto now, the d-i team has been maintaining a set of gtk-dfb 2.0.x package. Since then, we worked with the directfb upstream folk to get gtk-dfb integrated in the main gtk pckages, and this has been happening for the current devel tree. The question at hand is if it would be more meaningfull to keep working with the 2.0.x libraries, knowing we are alone in maintaining them, and they have some known bugs which will not be fixed, or go with the development 2.9+ ones. This is for the d-i .udebs and related development files, not the main gtk packages. Having those gtk-dfb libraries being built from the main gtk packages would be good, which is why i asked you, but as i feared, it will not be in time for etch, but it is definitively something that should be kept in ming for gtk 2.10 and etch+1. So, my (akwardly asked maybe) question was, if it would make sense to share the work on the 2.9+ packages needed for .udebs (if we go that way), with the gtk/gnome team, in order that this work can be more easily reused by the gtk/gnome team once you are ready to go with 2.10, and maybe also benefit from the occasional hiint or advice. I am not familiar with the gtk packaging though, and maybe it is best if Eddy takes over this discussion, given the animosity between Frans and me, but it would be nice to have feedback on these issues. More clearly, there are two points : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 11:45:02AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no Yeah, but we use only gtk, no gnome components. I don't know how the d-i uses GTK, but does the ABI number change has an impact on it too? Given that right now we are using only gtk 2.0.x, and that there are some features (like the new C-based graphical partitioner Xavier Oswald is working on) which need a newer than gtk 2.6 version. So, no i don't think in the current state of g-i, that the ABI number will be an issue. 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Take the GTK source package, rename it, drop the binary packages you are not interested too, renamed the other ones to no conflict? Then you probably need to make them conflict with the unstable packages or change the location of the files and the .pc, etc according to that. Note that update to GTK 2.9 requires to package pango 1.13 too and a libcairo 1.1 and might have to do similar changes for them too. That's really a non trivial way, do you really need the new version for etch? Well, it is that or 2.0.x. Davide or Attilio already have some experimental packages. We need to rebuild the stuff with the -directfb support, so i guess this will mean building new binary packages, and doing an additional build for it, not sure. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 10:23 +0200, Sven Luther a écrit : Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Are you saying you want to hijack GTK now? Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... I had a quick look over the changes and nothing on that list should affect the G-I, AFAICT. We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Do you object somebody else doing it? As a _distinct_ package, of course, which will be either dropped when you feel you can maintain it, kept as a separate package, or will be given to you, if you like to maintain it. Nobody wants to hijack a package from anybody (although I don't know if one could call the creation of a distict non-interfering package a hijack, taking into account that the GTK team does not maintain a similar package). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no I don't know how the d-i uses GTK, but does the ABI number change has an impact on it too? 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Take the GTK source package, rename it, drop the binary packages you are not interested too, renamed the other ones to no conflict? Then you probably need to make them conflict with the unstable packages or change the location of the files and the .pc, etc according to that. Note that update to GTK 2.9 requires to package pango 1.13 too and a libcairo 1.1 and might have to do similar changes for them too. That's really a non trivial way, do you really need the new version for etch? Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. I object slightly (but hopefully we'll find time to discuss these issues live). This has not been my reading of Sven's mails in that particular thread. IMHO, the discussion that followed Sven proposals helped to figure out what are the options even though it seems that Sven's initial proposal does not seem possible to use. So, I would say that, here, I see no reason to re-create a conflict. In understand that you may be hurted by the fact that Sven contacting the Gnome team partly in name of the D-I team may be felt as acting like the D-I RM, and I fully understand you have some objections to this. I more see bad effects of our current different schedules. However, imho, this does not need to go to a heated discussion here, at least in public. That discussion is interesting and I think it's valuable for the future release of D-I. So I would just say that it can be probably continued as logn as Sven takes care of not giving the impression that he acts as the D-I team (Sebastien is for isntance not completely aware of our internal organization...and even underlyign conflicts...not everyone reads -project or -devel). Sven, mini message for you, in French because I think it is better suited for what I intend to say: tes efforts sont appréciés et je pense qu'il est possible de trouver un compromis de fonctionnement au sein de D-I qui te permette de continuer à participer, voire même plus tard de participer à nouveau comme cela a été possible par le passé -opinion purement personnelle et qui n'engage en aucun cas l'équipe de D-I-. Je pense que sur ce poitn particulier ton action a été intéressante mais qu'elle a pu malheureusement donner à des personnes extérieures à l'équipe de D-I que tu agissais au nom de l'équipe D-I. Je qualifierais donc cette action de maladroite ce qui explique que je comprenne la réaction épidermique de Frans même si je la trouve un peu exagéréeon peut attribuer cela à la fatigue d'une longue journée. (sorry for our English only speakers. I wanted to say thisI wanted to say this properly and I didn't want to say it in private) signature.asc Description: Digital signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Hi If i'm not wrong, current GTKDFB 2.0.9 libraries (binary .udeb and - dev .deb) are built from a completly different source package than regular GTKX libraries (currently 2.8.xx in unstable, IIRC). Standard GTK libraries used in the Debian are built with the X frontend, while GTK libraries used in the g-i have to be built with the DFB backend (now in GTK 2.9.0 and later ). When i asked on debian-boot to upgrade to more recent GTKDFB libraries for the g-i, i was thinking about replacing ONLY already existing custom source packages and binary (u)debs for GTKDFB, as touching standard GTKX 2.8.x libaries managed by the gnome-team is out of question for me too. Assuming that we keep the scheme of different source packages (and we'll have to, at least until GTK 2.10 is released) for GTKX and GTKDFB, is it possible delegating to the d-i team the management over the GTKDFB package (currently, the DFB backend to GTK is used only by the g-i and was also lately developed to be specifically used in the g- i) ?. Of course, if there is no way to update GTKDFB packages without updating GTKX ones too, the localeudebs solution proposed by Frans is the only way to proceed. The main reason why i think we should switch to GTK 2.9.0 (or later CVS snapshot ) in the g-i is that the DFB backend contained in GTK 2.9. x is much more stable than the one found in GTKDFB 2.0.9 (which was basically a standard GTK 2.0.9 set of libraries patched with the DFB backend taken from from directfb.org CVS repository). GTK 2.9.x introduces a lot of new advanced features, and more recently- written parts of code may still be buggy: luckily, the debian- installer's GTK frontend [1] is a very simple application that makes exclusive use of GTK features that were introduced previously GTK 2.6 was released. Past experiments done with hand-made GTK udebs [2] from CVS 2006-03-26 demonstrated it's stable enough for g-i purposes, while also giving a more stable background for fonts-testing. Attilio [1] http://svn.debian.org/wsvn/d- i/trunk/packages/cdebconf/src/modules/frontend/gtk/gtk.c? op=filerev=0sc=0 [2] http://wiki.debian.org/DebianInstaller/GUIBuild (Building images with more recent GTK+ libraries) Tiscali ADSL 4 Mega Flat Naviga senza limiti a 19,95 Euro al mese con 4 Megabps di velocita'. Attiva subito: hai 2 MESI di canone adsl GRATIS! In piu', se sei raggiunto dalla rete Tiscali, telefoni senza pagare il canone Telecom. Scopri subito come risparmiare! http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 11:45 +0200, Sebastien Bacher a écrit : Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no If we are going to ship GNOME 2.16 in etch, we will have to rebuild all modules, theme engines and the like for this new GTK+, and we'd better do it as soon as possible in experimental. Of course there is no way this new GTK+ can enter unstable before it is declared stable upstream. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 11:45 +0200, Sebastien Bacher a écrit : Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no If we are going to ship GNOME 2.16 in etch, we will have to rebuild all modules, theme engines and the like for this new GTK+, and we'd better do it as soon as possible in experimental. Let's stop the non-issues. It is quite clear that from a GNOME POV gtk 2.9+ is not an option at the moment. What everybody should focus on now in this discution is the gtk udebs (the ones with DFB backend which are needed for G-I and G-I only, at least for the moment). So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Again, please understand this is NOT hijacking, these should be distinct packages which have the DFB backend, not the X one, as it is now for the packages maintained by gtk/gnome code. - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that Good. So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? Well, it is if you look at version numbers ;-) . Also some GTK+DFB specifc libraries will be needed. AFAICT, now there will be no conflict on common ground with gtk, but in case that will happen , we will disscuss the issues with you and we will sort out the problems that might occur. - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) Sure, feel free to mail the debian-gtk-gnome list about any issue you have on the topic Thanks for the offer. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) Sure, feel free to mail the debian-gtk-gnome list about any issue you have on the topic Cheers, Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Eddy Petrişor wrote: On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that Good. So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 We already have correct glib, atk and pango, but we need to repackage a newer cairo compiling it with the DirectFB backend enable against DFB 0.9.24 (the detailed GTKDFB packaging process is described here [1]). Who's going to do this? in the case we can't do this by ourselves, could the debian-gnome team, who nicely offered to help us, support us? friendly Attilio [1] http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries I think it does not matter that much to us if it is a snapshot or 2.9.0, but I think that 2.9.0 would help us because we will not be alone on this ground (others might face different problems with 2.9.0, but there are less chances of that happening with a cvs snapshot). As the debian packaging system allows patching before building, I would opt for 2.9.0. glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 Do these change for 2.9.0? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 07:36:48PM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? Well, my proposal was to use the same packaging infrastructure for both the official 2.8 gtk and the .udeb producing 2.9+ gtk packages, add the necessary stuff to produce the new -directfb packages, and disable the build of the normal ones. it is indeed not taking the lead, but the experience may benefit the gtk team later on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 21:55 +0200, Attilio Fiandrotti a écrit : So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 Beware that the CVS version now requires pango 1.13. That would mean having to maintain a pango snapshot as well. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
