subject:"cdebconf patches"

Re: More cdebconf patches

2016-01-10 Thread Regis Boudin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> Looking at it, it seems the following part of the diff is strange 
> (src/modules/frontend/gtk/screenshot.c): |  width =
> gdk_window_get_width(gdk_window); |  height =
> gdk_window_get_height(gdk_window); | +#if GTK_CHECK_VERSION(3,0,0) 
> |  pixbuf = gdk_pixbuf_get_from_drawable( |  NULL /*
> allocate a new pixbuf */, gdk_window, |
> gdk_colormap_get_system(), 0 /* src_x */, 0 /* src_y */, | +#else |
> +pixbuf = gdk_pixbuf_get_from_window(gdk_window, | +#endif |
> 0 /* dest_x */, 0 /* dest_y */, width, height);
> 
> Contrary to other hunks, the if/else seems inverted: the else
> (gtk2) bit is getting the new code while the if (gtk3) gets the old
> one. nm seems to confirm this: 
> /usr/lib/x86_64-linux-gnu/libgtk-3.so   → U
> gdk_pixbuf_get_from_window 
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so → U
> gdk_pixbuf_get_from_drawable

Indeed it is inverted. And with the screenshot feature not getting
built for deb, I managed to miss it. Combined with the fact I've had
to disable -Werror because of some gcc warning flags.
I'll try to see if I can fix the warnings, unfortunately we use
asprintf quite a lot.

> The black screen seems easily explained by some missing symbols,
> leading to a UI crash (nothing shows up when grepping for gtk in
> /proc/*/maps).

Actually, what happens is that dlopen() fails to load the plugin
because all symbols cannot be resolved (been there with my tests). But
that's more informative.

> Inverting the logic fixes the black screen with gtk2, so I'm about
> to commit it.

Thanks, that was definitely the right thing to do, as it would
otherwise break gtk2 as well.

> Going back to a gtk3 build, I'm again getting a black screen,
> because something is trying to open libGL.so.1; the only hit in the
> temporary build tree is libepoxy (unsurprisingly, since that's an
> OpenGL wrapper).

Oh dear. that sounds... big. But unsurprising, with dlopen failing,
just like in the previous case.

> I'll be poking the libgtk-3-0-udeb bug report to see if we could
> do without pulling libepoxy/libGL…

Well, that's at least one thing this patch will have been useful to
find out and try to track.

Thanks a lot for the prompt testing and bug fixing.
Regis

Re: More cdebconf patches

2016-01-10 Thread Cyril Brulebois

Regis Boudin  (2016-01-11):
> Indeed it is inverted. And with the screenshot feature not getting
> built for deb, I managed to miss it. Combined with the fact I've had
> to disable -Werror because of some gcc warning flags.
> I'll try to see if I can fix the warnings, unfortunately we use
> asprintf quite a lot.
> 
> > The black screen seems easily explained by some missing symbols,
> > leading to a UI crash (nothing shows up when grepping for gtk in
> > /proc/*/maps).
> 
> Actually, what happens is that dlopen() fails to load the plugin
> because all symbols cannot be resolved (been there with my tests). But
> that's more informative.
> 
> > Inverting the logic fixes the black screen with gtk2, so I'm about
> > to commit it.
> 
> Thanks, that was definitely the right thing to do, as it would
> otherwise break gtk2 as well.

Great, thanks for confirming.

> > Going back to a gtk3 build, I'm again getting a black screen,
> > because something is trying to open libGL.so.1; the only hit in the
> > temporary build tree is libepoxy (unsurprisingly, since that's an
> > OpenGL wrapper).
> 
> Oh dear. that sounds... big. But unsurprising, with dlopen failing,
> just like in the previous case.

This is slightly different: I had checked libepoxy0's (and therefore
libepoxy0-udeb's) dependencies, both as Debian packages and as ELF
binaries, and those are satisfied.

libepoxy implements finding libGL internally (through do_dlsym on
GLX_LIB, see src/dispatch_common.c, which ends up in turn with dlsym()).

> > I'll be poking the libgtk-3-0-udeb bug report to see if we could
> > do without pulling libepoxy/libGL…
> 
> Well, that's at least one thing this patch will have been useful to
> find out and try to track.
> 
> Thanks a lot for the prompt testing and bug fixing.

Bah, you did all the heavy work. I'm only pointing out what isn't
working yet. ;)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: More cdebconf patches

2016-01-10 Thread Cyril Brulebois

Regis Boudin  (2016-01-10):
> On 10/01/16 21:40, Cyril Brulebois wrote:
[…]
> Hmm, I didn't test that far. I did follow the GTK doc about migrating
> away from gdk_draw_layout(), and use pango_cairo_show_layout() instead,
> so it should be fine.

I meant to check this part, but see below for more important matters.

> > Some things which come to mind for a gtk3 switch in d-i:
[…]
> >  - [ what am I forgetting? ]

We need to check runtime. :D

With the little package rebuild documented in the libepoxy bug report
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788711#12) and a
cdebconf rebuild after this single change in debian/rules:
-UDEB_FRONTENDS=passthrough text newt gtk
+UDEB_FRONTENDS=passthrough text newt gtk3

All I'm getting at start-up (through virt-manager if that matters in any
way) is a black screen and no apparent errors in syslog, but see below.

The sad part is that my old branch no longer builds due to other changes
in gtk3 (a bunch of functions were deprecated/removed since then), so I
can't really judge whether cdebconf or the gtk3 stack isn't behaving as
expected.

But. I'm getting the same results without building the udeb against
gtk3. Bisecting from 0.201 led to this commit being the first bad one:
| commit ae9f8d0f40eecceb7c42a77300a89b9ee86dfb05
| Author: Regis Boudin 
| Date:   Sat Jan 9 18:11:39 2016 +
| 
| First shot at being able to build for either GTK+2 or GTK+3

Looking at it, it seems the following part of the diff is strange
(src/modules/frontend/gtk/screenshot.c):
|  width = gdk_window_get_width(gdk_window);
|  height = gdk_window_get_height(gdk_window);
| +#if GTK_CHECK_VERSION(3,0,0)
|  pixbuf = gdk_pixbuf_get_from_drawable(
|  NULL /* allocate a new pixbuf */, gdk_window,
|  gdk_colormap_get_system(), 0 /* src_x */, 0 /* src_y */,
| +#else
| +pixbuf = gdk_pixbuf_get_from_window(gdk_window,
| +#endif
|  0 /* dest_x */, 0 /* dest_y */, width, height);

Contrary to other hunks, the if/else seems inverted: the else (gtk2) bit
is getting the new code while the if (gtk3) gets the old one. nm seems
to confirm this:
  /usr/lib/x86_64-linux-gnu/libgtk-3.so   → U gdk_pixbuf_get_from_window
  /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so → U gdk_pixbuf_get_from_drawable

The black screen seems easily explained by some missing symbols, leading
to a UI crash (nothing shows up when grepping for gtk in /proc/*/maps).

Inverting the logic fixes the black screen with gtk2, so I'm about to
commit it.

Going back to a gtk3 build, I'm again getting a black screen, because
something is trying to open libGL.so.1; the only hit in the temporary
build tree is libepoxy (unsurprisingly, since that's an OpenGL wrapper).

I'll be poking the libgtk-3-0-udeb bug report to see if we could do
without pulling libepoxy/libGL…

> At the very least we make it possible to build for gtk3 and look at
> dependencies, run tests, look at themes, etc

Sure, thanks for that!

> These were indeed added by me. In theory I'd have liked to keep them for
> GTK2 but not for GTK3.

OK. Not a big deal anyway.

Mraw,
KiBi.

signature.asc
Description: Digital signature

More cdebconf patches

2016-01-10 Thread Regis Boudin

Hi everyone,

I just pushed a couple of patches for cdebconf-gtk. Besides removing
conditional code to handle old versions of glib, the main change is for
the display of text in the banner, done directly with cairo, thus
removing the last bit of deprecated GDK code. I believe I've reproduced
the same behaviour ; but if you notice something different I might have
missed, please shout.

The next patch could be the one attached. It makes it possible to chose
at configure time to compile for either GTK+2 or GTK+3, and in this
version compiles the udeb for GTK+2, and the deb for GTK+3.

Unfortunately the #if in the code are rather ugly ; but my attempts at
making it cleaner ended with something even less readable, so I left
them that way. And there's only 6 occurrences, so it's not that bad.

Any thought about whether I should merge this patch ? If yes, about
enabling GTK+3 for the deb ?

Thanks,
Regis
>From d7c6920fc2293c4d3782988990234a29ab079ccb Mon Sep 17 00:00:00 2001
From: Regis Boudin 
Date: Sat, 9 Jan 2016 18:11:39 +
Subject: [PATCH] First shot at being able to build for either GTK+2 or GTK+3

---
 configure.ac   | 13 -
 debian/control |  1 +
 debian/rules   |  2 +-
 src/modules/frontend/gtk/Makefile.in   |  6 +++---
 src/modules/frontend/gtk/align_text_renderer.c | 14 ++
 src/modules/frontend/gtk/screenshot.c  |  4 
 src/modules/frontend/gtk/ui.c  |  8 
 7 files changed, 39 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1defce9..0982f0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -148,15 +148,18 @@ if test -z "$FRONTEND_MODULES"; then
 PKG_CHECK_EXISTS([slang], [FRONTEND_MODULES="$FRONTEND_MODULES slang"], [AC_MSG_WARN([cannot build Slang frontend])])
 fi
 
+FRONTEND_MODULES_BUILD=""
 for frontend in $FRONTEND_MODULES; do
 case $frontend in
-  gtk) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= 2.24 pango gdk-pixbuf-2.0]);;
-  ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses]);;
-  newt) PKG_CHECK_MODULES([NEWT],[libnewt slang]);;
-  slang) PKG_CHECK_MODULES([SLANG],[slang]);;
-  *);;
+  gtk|gtk2) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= 2.24 pango gdk-pixbuf-2.0], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);;
+  gtk3) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-3.0 pango gdk-pixbuf-2.0], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);;
+  ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD ncurses"]);;
+  newt) PKG_CHECK_MODULES([NEWT],[libnewt slang], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD newt"]);;
+  slang) PKG_CHECK_MODULES([SLANG],[slang], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD slang"]);;
+  *) FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD $frontend";;
 esac
 done
+FRONTEND_MODULES="$FRONTEND_MODULES_BUILD"
 
 AC_SUBST([FRONTEND_MODULES])
 AC_SUBST([DB_MODULES])
diff --git a/debian/control b/debian/control
index 5a6625b..c57d8eb 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  libdebian-installer4-dev (>= 0.41) | libdebian-installer-dev,
  libglib2.0-dev (>= 2.31),
  libgtk2.0-dev (>= 2.24),
+ libgtk3.0-dev,
  libcairo2-dev (>= 1.8.10-3),
  libselinux1-dev (>= 2.3) [linux-any] | libselinux-dev [linux-any],
  dh-autoreconf,
diff --git a/debian/rules b/debian/rules
index b2b35f4..d00bbb7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,7 +18,7 @@ CONFFILE=/etc/cdebconf.conf
 LIBDEBCONFDEV=libdebconfclient0-dev
 LIBDEBCONF=libdebconfclient0
 
-DEB_FRONTENDS=passthrough text newt gtk
+DEB_FRONTENDS=passthrough text newt gtk3
 UDEB_FRONTENDS=passthrough text newt gtk
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
diff --git a/src/modules/frontend/gtk/Makefile.in b/src/modules/frontend/gtk/Makefile.in
index 09fc801..aa45ede 100644
--- a/src/modules/frontend/gtk/Makefile.in
+++ b/src/modules/frontend/gtk/Makefile.in
@@ -19,9 +19,9 @@ endif
 MODCFLAGS = @GTK_X11_CFLAGS@
 LIBS = @GTK_X11_LIBS@
 
-MODCFLAGS += -DGTK_DISABLE_DEPRECATED
-MODCFLAGS += -DGDK_DISABLE_DEPRECATED
-MODCFLAGS += -DGSEAL_ENABLE
+#MODCFLAGS += -DGTK_DISABLE_DEPRECATED
+#MODCFLAGS += -DGDK_DISABLE_DEPRECATED
+#MODCFLAGS += -DGSEAL_ENABLE
 
 # XXX: Does not work because of a path issue, needs to be fixed.
 #MODLDFLAGS += -Wl,--version-script=linker-script
diff --git a/src/modules/frontend/gtk/align_text_renderer.c b/src/modules/frontend/gtk/align_text_renderer.c
index e85832c..ff5cbf8 100644
--- a/src/modules/frontend/gtk/align_text_renderer.c
+++ b/src/modules/frontend/gtk/align_text_renderer.c
@@ -203,7 +203,11 @@ static PangoLayout * get_layout(AlignTextRenderer * renderer,
 }
 
 static void align_text_renderer_get_size(
+#if GTK_CHECK_VERSION(3,0,0)
+GtkCellRenderer * cell, GtkWidget * widget,

Re: More cdebconf patches

2016-01-10 Thread Cyril Brulebois

Hi,

I'm sorry I didn't follow up to earlier mails about cdebconf patches,
haven't been able to process enough other requests…

Regis Boudin <re...@boudin.name> (2016-01-10):
> I just pushed a couple of patches for cdebconf-gtk. Besides removing
> conditional code to handle old versions of glib, the main change is
> for the display of text in the banner, done directly with cairo, thus
> removing the last bit of deprecated GDK code. I believe I've
> reproduced the same behaviour ; but if you notice something different
> I might have missed, please shout.

IIRC we mostly use this for things like rescue mode, did you check this
with various languages/fonts (esp. CJK)?

> The next patch could be the one attached. It makes it possible to
> chose at configure time to compile for either GTK+2 or GTK+3, and in
> this version compiles the udeb for GTK+2, and the deb for GTK+3.

Great, I suppose this totally obsoletes my pu/gtk3 branch then. I'm not
totally convinced by building one with gtk2 and the other with gtk3
though.

Some things which come to mind for a gtk3 switch in d-i:
 - we need theming
 - we need to check theme=dark has some equivalent
 - we now need to check that ctrl-+/- still works
 - we need to update the freeze hints
 - we need to make sure there are no uninstallable udebs; this used to
   be the case, that was solved a few times, but we now have a bogus
   dependency on libepoxy0 (#788703).
 - [ what am I forgetting? ]

Once everything is ready I think switching both cdebconf deb/udeb to
gtk3 at the same time would make more sense. (OTOH getting some gtk3
testing through the deb would be nice; but I'm not sure how common that
is, and how useful that'll be to test it from outside d-i.)

> Unfortunately the #if in the code are rather ugly ; but my attempts at
> making it cleaner ended with something even less readable, so I left
> them that way. And there's only 6 occurrences, so it's not that bad.

Those are fine with me.

> Any thought about whether I should merge this patch ? If yes, about
> enabling GTK+3 for the deb ?

The src/modules/frontend/gtk/Makefile.in changes look like something
that might have been needed during development, but that shouldn't be
needed anymore now that we have a clean patch?

For configure.ac, I think I'd prefer if we could align things a bit
to get better readability (but that's entirely subjective, and not a
reason not to merge the patch in its current state). I've tweaked this
part of your diff to show what I mean:

> --- a/configure.ac
> +++ b/configure.ac
> @@ -148,15 +148,18 @@ if test -z "$FRONTEND_MODULES"; then
>  PKG_CHECK_EXISTS([slang], [FRONTEND_MODULES="$FRONTEND_MODULES slang"], 
> [AC_MSG_WARN([cannot build Slang frontend])])
>  fi
>  
> +FRONTEND_MODULES_BUILD=""
>  for frontend in $FRONTEND_MODULES; do
>  case $frontend in
> -  gtk) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= 
> 2.24 pango gdk-pixbuf-2.0]);;
> -  ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses]);;
> -  newt) PKG_CHECK_MODULES([NEWT],[libnewt slang]);;
> -  slang) PKG_CHECK_MODULES([SLANG],[slang]);;
> -  *);;
> +  gtk|gtk2) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 
> >= 2.24 pango gdk-pixbuf-2.0],
> +  
> [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);;
> +  gtk3) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-3.0 
> pango gdk-pixbuf-2.0],
> +  
> [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);;
> +  ncurses)  PKG_CHECK_MODULES([NCURSES],[ncurses],
> +  
> [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD ncurses"]);;
> +  newt) PKG_CHECK_MODULES([NEWT],[libnewt slang],
> +  
> [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD newt"]);;
> +  slang)PKG_CHECK_MODULES([SLANG],[slang],
> +  
> [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD slang"]);;
> +  *) FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD $frontend";;
>  esac
>  done
> +FRONTEND_MODULES="$FRONTEND_MODULES_BUILD"

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: More cdebconf patches

2016-01-10 Thread Samuel Thibault

Regis Boudin, on Sun 10 Jan 2016 22:54:41 +, wrote:
> >  - we now need to check that ctrl-+/- still works
> 
> That one probably won't work, seeing that it modifies a file that's not
> used by gtk3.

Ok, no problem.  AIUI gtk3 can be just made to use the dpi information,
I'll have a look at that.

> At the very least we make it possible to build for gtk3 and look at
> dependencies, run tests, look at themes, etc

Yes, committing the code without switching allows to make development
much easier :)

Samuel

Re: More cdebconf patches

2016-01-10 Thread Regis Boudin

On 10/01/16 21:40, Cyril Brulebois wrote:
> Hi,
> 
> I'm sorry I didn't follow up to earlier mails about cdebconf patches,
> haven't been able to process enough other requests…

No worries. The previous patches I pushed we rather trivial.

> Regis Boudin <re...@boudin.name> (2016-01-10):
>> I just pushed a couple of patches for cdebconf-gtk. Besides removing
>> conditional code to handle old versions of glib, the main change is
>> for the display of text in the banner, done directly with cairo, thus
>> removing the last bit of deprecated GDK code. I believe I've
>> reproduced the same behaviour ; but if you notice something different
>> I might have missed, please shout.
> 
> IIRC we mostly use this for things like rescue mode, did you check this
> with various languages/fonts (esp. CJK)?

Hmm, I didn't test that far. I did follow the GTK doc about migrating
away from gdk_draw_layout(), and use pango_cairo_show_layout() instead,
so it should be fine.

>> The next patch could be the one attached. It makes it possible to
>> chose at configure time to compile for either GTK+2 or GTK+3, and in
>> this version compiles the udeb for GTK+2, and the deb for GTK+3.
> 
> Great, I suppose this totally obsoletes my pu/gtk3 branch then. I'm not
> totally convinced by building one with gtk2 and the other with gtk3
> though.
> 
> Some things which come to mind for a gtk3 switch in d-i:
>  - we need theming
>  - we need to check theme=dark has some equivalent
>  - we now need to check that ctrl-+/- still works

That one probably won't work, seeing that it modifies a file that's not
used by gtk3.

>  - we need to update the freeze hints
>  - we need to make sure there are no uninstallable udebs; this used to
>be the case, that was solved a few times, but we now have a bogus
>dependency on libepoxy0 (#788703).
>  - [ what am I forgetting? ]
> 
> Once everything is ready I think switching both cdebconf deb/udeb to
> gtk3 at the same time would make more sense. (OTOH getting some gtk3
> testing through the deb would be nice; but I'm not sure how common that
> is, and how useful that'll be to test it from outside d-i.)

Yeah, having the possibility to do some tests through the deb, and
making sure both versions compile was what I had on my mind. I also did
it to check it worked.

At the very least we make it possible to build for gtk3 and look at
dependencies, run tests, look at themes, etc

>> Any thought about whether I should merge this patch ? If yes, about
>> enabling GTK+3 for the deb ?
> 
> The src/modules/frontend/gtk/Makefile.in changes look like something
> that might have been needed during development, but that shouldn't be
> needed anymore now that we have a clean patch?

These were indeed added by me. In theory I'd have liked to keep them for
GTK2 but not for GTK3.

> For configure.ac, I think I'd prefer if we could align things a bit
> to get better readability (but that's entirely subjective, and not a
> reason not to merge the patch in its current state). I've tweaked this
> part of your diff to show what I mean:

Looks good. I was thinking about doing something like that.

Anyway, I've cleaned things a bit and will push a patch that builds all
for gtk2.

Thanks for the feedback.

Regis

cdebconf patches

2011-05-25 Thread Regis Boudin

Hi all,

Still working on cdebconf, despite being in the middle of a job change,
so here are a couple of patches I would like to sumit :

0001 fixes a trivial missing include (database.h includes a reference to
DEBCONF_MAX_CONFIGPATH_LEN, which is defined in constants.h

0002 fixes an obvious warning from my previous patch.

0003 moves the logic of loading a templates file from
debconf-loadtemplate.c into database.c, declares it in database.h, and
reuses it in dpkg-reconfigure.c instead of reproducing the almost
identical logic. The patch doesn't bring anything in itself, but this
logic will be needed in dpkg-preconfigure and debconf, so having it
shared sounds like a good idea.

Any feedback or comment would as usual be very welcome.

Regis
From 30e7d6a838a2936264b39871a963b544f85f2987 Mon Sep 17 00:00:00 2001
From: Regis Boudin re...@boudin.name
Date: Mon, 23 May 2011 23:27:26 +0100
Subject: [PATCH 1/3] fix missing include

---
 src/database.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/database.h b/src/database.h
index 574bfef..c350280 100644
--- a/src/database.h
+++ b/src/database.h
@@ -7,6 +7,8 @@
 #ifndef _DATABASE_H_
 #define _DATABASE_H_
 
+#include constants.h
+
 /* Debconf database interfaces */
 
 struct configuration;
-- 
1.7.5.1

From 929b37a2fb68493f8efb142b8276a76861b45bb5 Mon Sep 17 00:00:00 2001
From: Regis Boudin re...@boudin.name
Date: Mon, 23 May 2011 22:43:48 +0100
Subject: [PATCH 2/3] fix silly warning

---
 src/modules/db/rfc822db/rfc822db.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/modules/db/rfc822db/rfc822db.c b/src/modules/db/rfc822db/rfc822db.c
index 70da04d..4454dc7 100644
--- a/src/modules/db/rfc822db/rfc822db.c
+++ b/src/modules/db/rfc822db/rfc822db.c
@@ -130,7 +130,7 @@ static unsigned int parse_flags(char *string)
 char *wc, *owc;

 if (!string)
-	return;
+	return 0;
 
 owc = wc = strdup(string);
 
-- 
1.7.5.1

From 4b08b448faf505ba04b509c22f997a8efb546cd5 Mon Sep 17 00:00:00 2001
From: Regis Boudin re...@boudin.name
Date: Fri, 20 May 2011 00:11:47 +0100
Subject: [PATCH 3/3] shared template_db_loadfile()

Merge almost common code between debconf-loadtemplate and
dpkg-reconfigure into template_db_loadfile(), which will be reused
in dpkg-preconfigure and debconf itself as well
---
 src/database.c |   59 
 src/database.h |   12 +
 src/debconf-loadtemplate.c |   40 +++--
 src/dpkg-reconfigure.c |   42 +--
 4 files changed, 76 insertions(+), 77 deletions(-)

diff --git a/src/database.c b/src/database.c
index 2f1c9f2..39ac5dd 100644
--- a/src/database.c
+++ b/src/database.c
@@ -208,6 +208,65 @@ void template_db_delete(struct template_db *db)
 DELETE(db);
 }
 
+/
+ * Function: loadtemplate
+ * Inputs: tdb - templates database
+ * qdb - questions database
+ * filename - which file to load templates from
+ * owner - owner for the templates
+ * Outputs: none
+ * Description: loads all the templates from a file
+ * Assumptions: none
+ /
+void template_db_loadfile(struct template_db *tdb, struct question_db *qdb, const char *filename, const char *owner, int flags)
+{
+struct template *t, *oldt;
+struct question *q;
+
+if (!tdb)
+{
+INFO(INFO_ERROR, Templates database not initialised);
+return;
+}
+
+t = template_load(filename);
+while (t)
+{
+oldt = tdb-methods.get(tdb, t-tag);
+if (oldt == NULL || (flags  DC_LOADTEMPLATE_MERGE) == 0 || NULL == template_l10nmerge(oldt, t))
+{
+if (tdb-methods.set(tdb, t) != DC_OK)
+INFO(INFO_ERROR, Cannot add template %s, t-tag);
+}
+if (oldt)
+template_deref(oldt);
+
+if (qdb)
+{
+q = qdb-methods.get(qdb, t-tag);
+if (q == NULL)
+{
+q = question_new(t-tag);
+q-template = t;
+template_ref(t);
+}
+else if (q-template != t)
+{
+template_deref(q-template);
+q-template = t;
+template_ref(t);
+}
+question_owner_add(q, owner);
+if (qdb-methods.set(qdb, q) != DC_OK)
+INFO(INFO_ERROR, Cannot add question %s, t-tag);
+question_deref(q);
+}
+oldt = t;
+t = t-next;
+template_deref(oldt);
+}
+}
+
 /**
  *
  * Config database 
diff --git a/src/database.h b/src/database.h
index c350280..1dd027c 100644
--- a/src/database.h
+++ b/src/database.h
@@ -17,6 +17,9 @@ struct template_db;
 struct question;
 struct question_db;
 
+#define DC_LOADTEMPLATE_NONE  (0)
+#define

Re: More cdebconf patches

Re: More cdebconf patches

Re: More cdebconf patches

More cdebconf patches

Re: More cdebconf patches

Re: More cdebconf patches

Re: More cdebconf patches

cdebconf patches

8 matches

Site Navigation

Mail list logo

Footer information