NEW changes in proposedupdates

[Debian FTP Masters]

Processing changes file: dokuwiki_0.0.20091225c-10+squeeze2_amd64.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qbpzn-0005b2...@franck.debian.org

NEW changes in oldproposedupdates

[Debian FTP Masters]

Processing changes file: dokuwiki_0.0.20080505-4+lenny3_amd64.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qbpzo-0005bh...@franck.debian.org

Re: Bug#632028: postgresql 8.4.8 regression - failure to handle char(4) = bpchar

[Philipp Kern]

On Wed, Jun 29, 2011 at 10:32:27AM +0200, Josip Rodin wrote:
> Unfortunately this "stable" upgrade of PostgreSQL 8.4.7-0squeeze2 to
> 8.4.8-0squeeze1 introduced a bug apparently from the 9.0 branch that is
> now consistently breaking queries on our production "stable" machines.

I propose the attached debdiff as an update to stable.  The patch applies
properly during the build and the regression test suite runs successfully.
(Of course the test case shipped with the patch got reverted, though.)

Kind regards
Philipp Kern
diff -u postgresql-8.4-8.4.8/debian/changelog 
postgresql-8.4-8.4.8/debian/changelog
--- postgresql-8.4-8.4.8/debian/changelog
+++ postgresql-8.4-8.4.8/debian/changelog
@@ -1,3 +1,10 @@
+postgresql-8.4 (8.4.8-0squeeze2) stable; urgency=low
+
+  * Back out "Fix plpgsql's issues with dropped columns in rowtypes in 8.4
+branch.", which introduces a regression.  (Closes: #632028)
+
+ -- Philipp Kern   Wed, 29 Jun 2011 11:45:11 +0200
+
 postgresql-8.4 (8.4.8-0squeeze1) stable; urgency=low
 
   * New upstream bug fix release: (Closes: #626559)
only in patch2:
unchanged:
--- postgresql-8.4-8.4.8.orig/debian/patches/15-debian-bug-632028.patch
+++ postgresql-8.4-8.4.8/debian/patches/15-debian-bug-632028.patch
@@ -0,0 +1,755 @@
+commit 626efda94f53c6285c02552da3fae924f40508bd
+Author: Philipp Kern 
+Date:   Wed Jun 29 11:43:04 2011 +0200
+
+Revert "Fix plpgsql's issues with dropped columns in rowtypes in 8.4 
branch."
+
+This caused a regression.  See Debian bug #632028 for details.
+
+This reverts commit 5d3853a7fa40b28b44b14084863fd83a188c9a9e.
+
+diff --git a/src/backend/access/common/Makefile 
b/src/backend/access/common/Makefile
+index a80ee38..9e05a6a 100644
+--- a/src/backend/access/common/Makefile
 b/src/backend/access/common/Makefile
+@@ -12,7 +12,6 @@ subdir = src/backend/access/common
+ top_builddir = ../../../..
+ include $(top_builddir)/src/Makefile.global
+ 
+-OBJS = heaptuple.o indextuple.o printtup.o reloptions.o scankey.o \
+-  tupconvert.o tupdesc.o
++OBJS = heaptuple.o indextuple.o printtup.o reloptions.o scankey.o tupdesc.o  
+ 
+ include $(top_srcdir)/src/backend/common.mk
+diff --git a/src/backend/access/common/tupconvert.c 
b/src/backend/access/common/tupconvert.c
+deleted file mode 100644
+index 34e5f11..000
+--- a/src/backend/access/common/tupconvert.c
 /dev/null
+@@ -1,365 +0,0 @@
+-/*-
+- *
+- * tupconvert.c
+- *  Tuple conversion support.
+- *
+- * These functions provide conversion between rowtypes that are logically
+- * equivalent but might have columns in a different order or different sets
+- * of dropped columns.There is some overlap of functionality with the
+- * executor's "junkfilter" routines, but these functions work on bare
+- * HeapTuples rather than TupleTableSlots.
+- *
+- * Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
+- * Portions Copyright (c) 1994, Regents of the University of California
+- *
+- *
+- * IDENTIFICATION
+- *  src/backend/access/common/tupconvert.c
+- *
+- *-
+- */
+-#include "postgres.h"
+-
+-#include "access/tupconvert.h"
+-#include "utils/builtins.h"
+-
+-
+-/*
+- * The conversion setup routines have the following common API:
+- *
+- * The setup routine checks whether the given source and destination tuple
+- * descriptors are logically compatible.  If not, it throws an error.
+- * If so, it returns NULL if they are physically compatible (ie, no conversion
+- * is needed), else a TupleConversionMap that can be used by do_convert_tuple
+- * to perform the conversion.
+- *
+- * The TupleConversionMap, if needed, is palloc'd in the caller's memory
+- * context.  Also, the given tuple descriptors are referenced by the map,
+- * so they must survive as long as the map is needed.
+- *
+- * The caller must supply a suitable primary error message to be used if
+- * a compatibility error is thrown.  Recommended coding practice is to use
+- * gettext_noop() on this string, so that it is translatable but won't
+- * actually be translated unless the error gets thrown.
+- *
+- *
+- * Implementation notes:
+- *
+- * The key component of a TupleConversionMap is an attrMap[] array with
+- * one entry per output column.  This entry contains the 1-based index of
+- * the corresponding input column, or zero to force a NULL value (for
+- * a dropped output column).  The TupleConversionMap also contains workspace
+- * arrays.
+- */
+-
+-
+-/*
+- * Set up for tuple conversion, matching input and output columns by
+- * position.  (Dropped columns are ignored in both input and output.)
+- *
+- * Note: the errdetail messages speak of indesc as the "returned" rowtype,
+- * outdesc as the "expected" rowtype.  This is okay for current uses but
+- * might need generalization in future.
+- */
+-TupleConversionMap *
+-convert_tuples_by_position(Tu

Processed: unblock 622279 with 624975 625027 614619 621829

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # packages not in testing, they do not block anything
> unblock 622279 with 624975 625027 614619 621829
Bug #622279 [release.debian.org] transition: python-defaults (switching 
default: 2.6 -> 2.7)
Was blocked by: 628860 629085 628243 625676 623587 622966 623578 629087 625171 
606363 622912 631800 625153 624917 625040 631823 624940 621879 625880 631820 
624824 625151 624901 621993 626800 625520 618094 624975 599127 622976 614498 
608640 628827 622154 553961 625677 625108 629091 622001 623418 618055 625722 
622072 625853 622070 621992 555767 606006 625137 616364 626259 605875 623165 
621402 628820 625678 622978 618084 628826 553930 624889 621948 628830 629122 
624787 628839 626199 629817 624950 625707 623927 625115 554552 629148 631856 
628852 629145 624740 618159 626421 631821 629090 606681 624811 625011 622027 
626416 606642 624982 625679 624597 625087 610777 625135 628828 621932 624429
Removed blocking bug(s) of 622279: 625027, 621829, 624975, and 614619
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
622279: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622279
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130934891619872.transcr...@bugs.debian.org

Re: Updates for dokuwiki

[Adam D. Barratt]

On Wed, 29 Jun 2011 01:59:28 +0200, Tanguy Ortolo wrote:

Adam D. Barratt, 2011-06-27 19:48 UTC+0100:
The security patches themselves look fine, however a 
Standards-Version

change isn't really appropriate for a stable update, even when it
requires no modification to the package other than changing the 
field.


Okay, I understand that, I does not make much sense and it could even 
be

misleading. Removed that.


Thanks.

Please feel free to upload, minus the debian/control change as 
above.


Done.


For the record, both stable and oldstable updates were accepted earlier 
today; thanks for working on this.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/7834241cdad276dbcbbaa647e4647...@adsl.funky-badger.org

Updates question

[Pontus Andersson]

Hi.

I have previously downloaded all Debian 6.0.1 DVD's to be used on
non-internet access computers.

Question 1: To get updates 6.0.2 is it enough to download:

debian-update-6.0.2.1-i386-DVD-1.iso

and debian-update-6.0.2.1-i386-DVD-2.iso


Then mount and install the updates?


Question 2: Can I remove, debian-update-6.0.1-i386-DVD-1.iso

from my harddrive? Cause this updates are in the new DVD's too right?


Best Regards
/Pontus

Re: Updates question

[Steve McIntyre]

On Wed, Jun 29, 2011 at 03:48:49PM +0200, Pontus Andersson wrote:
>Hi.
>
>I have previously downloaded all Debian 6.0.1 DVD's to be used on
>non-internet access computers.
>
>Question 1: To get updates 6.0.2 is it enough to download:
>
>debian-update-6.0.2.1-i386-DVD-1.iso
>
>and debian-update-6.0.2.1-i386-DVD-2.iso
>
>
>Then mount and install the updates?

Correct. The 6.0.2.1 update DVDs should contain everything needed -
they contain all the packages that were updated between 6.0.0 and
6.0.2.1.

>Question 2: Can I remove, debian-update-6.0.1-i386-DVD-1.iso
>
>from my harddrive? Cause this updates are in the new DVD's too right?

Correct. The 6.0.2.1 update DVDs should contain everything needed -
they contain all the packages that were updated between 6.0.0 and
6.0.2.1.

Yes, same answer. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110629141726.ga21...@einval.com

Re: SAT based britney - formalisation of the problem

[Ralf Treinen]

Hi again,

On Thu, Jun 23, 2011 at 01:06:44PM +0200, Joachim Breitner wrote:

> > But according to our experience, for it to happen
> > the problem should not be underestimated and, more importantly, should
> > be properly formalized in a way which is independent of some specific
> > encoding technique.
>
> Correct. That is why I suggested to use the format already used in a
> MAX-SAT competition:
> http://maxsat.ia.udl.cat/requirements/

In fact, from out point of view the DIMACS format or MAX-SAT input
format are already a specific encoding technique, and we think that
one should first find a logical specification of what exactly one
tries to achieve, before thinking about a specific encoding into
MAX-SAT or whatever other solver technology. One way of formalising
this could be stated in the following style:

1) one defines first a certain abstraction of a distribution (like 
ignoring certain kinds of conflicts). This has of course to be exactly
defined. Lets call this function a().
2) lets say that the result of migration a set m to a testing distribution
t is denoted as "t+m"
3) then you say: you look for a migration set m, such that for the
testing distribution t:

  every "interesting" installation request that is satisfiable in a(t)
  is also satisfiable in a(t+m)

Ideally, a() would be the identity function, that is no abstraction
at all.

The important question here would be to define what are precisely the
"interesting" installation requests. Candidates are:
- install one arbitrary single package A. This seems to be the definition
  currently used in britney.
- install an arbitray *set* of packages together. This might be interesting
  in some cases, but seems to be too restrictive.

Another element of the precise specification would be: one wants to
have a maximal solution. What precisely is the sense of maximality here?
Maximal number of binary packages? Maximal number of source packages? Should
there be a way to give more weight to more "important" packages?

Cheers -Zack and Ralf. 
-- 
Ralf Treinen
Laboratoire Preuves, Programmes et Systèmes
Université Paris Diderot, Paris, France.
http://www.pps.jussieu.fr/~treinen/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110629155524.gb9...@pps.jussieu.fr

Re: SAT based britney - handling conflicts

[Ralf Treinen]

Hi,

On Thu, Jun 23, 2011 at 10:25:55AM +0200, Raphael Hertzog wrote:

> You're suggesting that one way to legitimately ignore the problem of
> Conflicts would be to have the Debian policy only allow usage of Conflicts
> for cases that cannot create problems during testing migration. Is that
> right ?

This is one reason, but it would also work the other way round: if we
had a way to say that certain kinds of conflicts between packages must
not occur then we should put it into policy so that we have a precise
rule for telling problematic packages (in case the criterion is
certain), or at least implement some check, using the edos tools for
instance, to get a list of problematic cases that then can be
investigated by hand.

> I'm not sure how you can formally define whether a Conflicts is likely to
> create migrations problems or not.

I don't know either ATM how to do it. Anyway, your classification
below helps a lot in this discussion:

> However we know the common use cases for Conflicts and it seems to me that
> they are ok:
>
> 1/ conflict for files that have moved within binary packages of the same
>source, policy requires the conflicts/breaks to be versionned, and the
>simple rule that requires all the binary packages of the source to
>be moved together makes it moot

Agreed.

> 2/ conflicts for files that have moved between binary packages of
>different sources, policy requires the conflicts/breaks to be
>versionned, and the problem can be solved prior to the definition of
>the SAT problem by adding a supplementary rule that forces the upgrade
>of both source packages together

I see two problems here:

1) lets call A and B the two binary packages between whom the file was
moved. Why should we add a constraint that A and B must migrate
together?  Maybe A is not ready to migrate for any other reason, so
this would stop B from migrating. It is true that migrating B without
migrating A would create a conflict in testing between A and B, but
maybe this conflict was already there before, or maybe this new
conflict is nothing we should worry about. I think that in general it
would be much too restrictive to require that, if a set {A,B,C} was
installable together before the migration, then the same should hold
after the migration.

One way of approaching this question is: we should put a requirement
that A and B must migrate together only in case there is a third
package, say C, that depends both on A and B.

2) However, this leads us to another problem that is related to an
example by Raphael early in this thread (this was the example with
disjunctive dependendencies in [1]): It is not so clear what it means
for a package to depend on another package since dependencies possibly
are not local to the package (like: C declares directly a dependency
on A and B) but may be indirect, like in any of the following
situations:

example a) Here, C logically depends on A and B, but this seen only
when following dependency chains:

Package: C
Depends: E, F

Package: E
Depends: A

Package: F
Depends: B

Package: A
Conflicts B

example b) Here, C logically depends on A and B, despite the fact that
there is a disjunction involved. This is due to the fact that one
of the branches of the disjunction, that is G, is invalidated.

Package: C
Depends: E, F|G

Package: E
Depends: A

Package: F
Depends: B

Package: G
Conflicts: A

Package: B
Conflicts: A

For added fun, in any of the two examples the dependency from E to A may
exist only in testing and not in unstable, or the other way round. That is,
dependencies between packages may be indirect (we call these "strong
dependencies" [2]). In this case they are relative to the repository,
and not an isolated property of the package alone.

> 3/ permanent conflict for a service provided, the various conflicting
>packages are usually alternatives in dependencies (via virtual
>packages) and as such there's very few dependency trees that would
>force to have two conflicting packages together

This is interesting. If we had a way of distinguishing this case 3/
from 4/ below then we could implement a check of the archive that
detects whether some package strongly depends (in the above sense) on
two packages that are in a type-3 conflict. One special case would be
relatively easy to detect: C strongly depends on A,B, and both A and B
do a "provides: v" and "conflicts: v". Maybe we should add this check to
edos.debian.net :-)

> 4/ permament conflict for a random file conflict that has not yet been
>solved by renaming one side. This should be temporary.


On Thu, Jun 23, 2011 at 01:06:44PM +0200, Joachim Breitner wrote:
> A clean solution would be to require package maintainers to be specific
> in their Conflicts, and have different fields for „This package should
> generally not be installed along the other package.“ and „There is
> something temporary wrong with the combination of this package and the
> other package (usually with some versi

Bug#623999: transition: libuim6

[Philipp Kern]

On Wed, May 18, 2011 at 02:24:46PM +0200, Mehdi Dogguy wrote:
> On 25/04/2011 09:59, Kiwamu Okabe wrote:
> > I'd like to upload
> > http://mentors.debian.net/debian/pool/main/u/uim/uim_1.6.1-3.dsc,
> > which has changed SONAME (libuim6 => libuim7), to unstable.
> > 
> > There is reverse-dependencies, which will need binNMUs:
> >  mlterm, gkrelluim, mozc, scim-uim.
> > 
> > Please let me know when I can start the transition.
> Provided that your did test your reverse dependencies with this new
> version, you can go ahead with the upload. The status of this transition
> will be tracked at:

The upload happened…

> Please let us once uim_1.6.1-3 is accepted.

The notification didn't.  The upload FTBFSed on kfreebsd-* due to a symbol
mismatch.

I've scheduled binNMUs for gkrelluim and scim-uim despite of this.  Let's see
how they work out.  At least scim-uim hasn't been rebuilt for ages.

Kind regards
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110629163444.ga18...@thrall.0x539.de

Bug#630044: transition: poppler 0.16

[Philipp Kern]

Hi,

the only issue I see at the moment is this:

On Fri, Jun 10, 2011 at 05:03:47PM +0200, Pino Toscano wrote:
> * python-poppler (poppler-glib)
> The (small) patch needed to compile with poppler 0.16 is not
> compatible with poppler 0.12, so it cannot be uploaded right now.
> Asked to provide a version in experimental compilable with poppler
> 0.16, see #628047.

There's a claim at the LP bug[1] that the patch isn't suitable.  From a casual
look that comment seems wrong, but you can judge this better than me.

If that's resolved I'm ok with you going ahead with this transition.  Please
ping me when it's uploaded, though, so that I can take care of the binNMUs.

Kind regards
Philipp Kern

[1] https://bugs.launchpad.net/poppler-python/+bug/696025



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110629171126.ga19...@thrall.0x539.de

Re: Bug#632028: postgresql 8.4.8 regression - failure to handle char(4) = bpchar

[Martin Pitt]

Hello Josip,

Josip Rodin [2011-06-29 10:32 +0200]:
> Unfortunately this "stable" upgrade of PostgreSQL 8.4.7-0squeeze2 to
> 8.4.8-0squeeze1 introduced a bug apparently from the 9.0 branch that is
> now consistently breaking queries on our production "stable" machines.

I uploaded 8.4.8-0squeeze2 with a reversion of that patch. Thanks
muchly for testing, and thanks to Philipp for preparing the patch!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

NEW changes in proposedupdates

[Debian FTP Masters]

Processing changes file: postgresql-8.4_8.4.8-0squeeze2_amd64.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qc6sd-xs...@franck.debian.org

NEW changes in oldproposedupdates

[Debian FTP Masters]

Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_amd64.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_alpha.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_arm.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_armel.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_hppa.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_i386.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_ia64.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_mips.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_mipsel.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_powerpc.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_s390.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny11_sparc.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_amd64.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_alpha.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_arm.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_armel.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_hppa.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_i386.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_ia64.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_mips.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_mipsel.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_powerpc.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_s390.changes
  ACCEPT
Processing changes file: php5_5.2.6.dfsg.1-1+lenny12_sparc.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qc6si-ys...@franck.debian.org

Bug#630044: transition: poppler 0.16

[Michael Biebl]

Am 29.06.2011 19:11, schrieb Philipp Kern:
> Hi,
> 
> the only issue I see at the moment is this:
> 
> On Fri, Jun 10, 2011 at 05:03:47PM +0200, Pino Toscano wrote:
>> * python-poppler (poppler-glib)
>> The (small) patch needed to compile with poppler 0.16 is not
>> compatible with poppler 0.12, so it cannot be uploaded right now.
>> Asked to provide a version in experimental compilable with poppler
>> 0.16, see #628047.
> 
> There's a claim at the LP bug[1] that the patch isn't suitable.  From a casual
> look that comment seems wrong, but you can judge this better than me.
> 
> If that's resolved I'm ok with you going ahead with this transition.  Please
> ping me when it's uploaded, though, so that I can take care of the binNMUs.
> 
> Kind regards
> Philipp Kern
> 
> [1] https://bugs.launchpad.net/poppler-python/+bug/696025

Jakub mentioned on irc that the patch in [1] is wrong.
There's an alternate patch shipped in the fedora package.

I've attached this patch and hope the more python/poppler savvy people can take
a look at it.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff -up pypoppler-0.12.1/poppler.defs.poppler15 pypoppler-0.12.1/poppler.defs
--- pypoppler-0.12.1/poppler.defs.poppler15	2010-10-06 16:02:47.023101009 -0400
+++ pypoppler-0.12.1/poppler.defs	2010-10-06 16:10:32.749101000 -0400
@@ -1760,6 +1760,12 @@
   (return-type "int")
 )
 
+(define-method get_label
+  (of-object "PopplerPage")
+  (c-name "poppler_page_get_label")
+  (return-type "gchar*")
+)
+
 (define-method get_duration
   (of-object "PopplerPage")
   (c-name "poppler_page_get_duration")
@@ -1805,9 +1811,15 @@
   (of-object "PopplerPage")
   (c-name "poppler_page_get_text")
   (return-type "char*")
+)
+
+(define-method get_selected_text
+  (of-object "PopplerPage")
+  (c-name "poppler_page_get_selected_text")
+  (return-type "char*")
   (parameters
 '("PopplerSelectionStyle" "style")
-'("PopplerRectangle*" "rect")
+'("PopplerRectangle*" "selection")
   )
 )
 
@@ -1895,6 +1907,16 @@
   )
 )
 
+(define-function poppler_page_add_annot
+  (of-object "PopplerPage")
+  (c-name "poppler_page_add_annot")
+  (return-type "none")
+  (parameters
+'("PopplerAnnot*" "annot")
+'("GList*" "list")
+  )
+)
+
 (define-method get_crop_box
   (of-object "PopplerPage")
   (c-name "poppler_page_get_crop_box")
@@ -1904,6 +1926,16 @@
   )
 )
 
+(define-method get_text_layout
+  (of-object "PopplerPage")
+  (c-name "poppler_page_get_text_layout")
+  (return-type "gboolean")
+  (parameters
+'("PopplerRectangle**" "rectangles")
+'("guint*" "n_rectangles")
+  )
+)
+
 (define-function poppler_rectangle_get_type
   (c-name "poppler_rectangle_get_type")
   (return-type "GType")


signature.asc
Description: OpenPGP digital signature