Dear Maintainer,

LibreOffice created a patch to clucene to make their help pages
reproducible. Maybe we should include it here? (libreoffice in Debian
uses the system library instead of the embedded copy.)

See
https://cgit.freedesktop.org/libreoffice/core/patch/?id=ff071078ee5f13f0e9d430d6783444a631d232a0
(clucene-reprobuild.patch.1)

which adds a new method setting the "start position" (which then is used
in libreoffice to consistently set it 0)

Regards,

Rene

Source: clucene-core
Followup-For: Bug #1059805
X-Debbugs-Cc: rene@debian.org, thorsten.behrens@allotropia.de
additional API function to implements this when _not_ configured[1] to use the
system-provided clucene.

And so a question: could the fix be achieved by changing the default value of
the version field from millis-timestamp to zero -- meaning: without needing to
adjust the API?

FWIW: I think Debian should avoid carrying an API that is divergent to
upstream, even if the current upstream is no-longer-maintained.  Otherwise
people may unintentionally write software that works on Debian but that does
not build/run on other platforms.

[1] - https://cgit.freedesktop.org/libreoffice/core/tree/helpcompiler/source/HelpIndexer.cxx?id=ff071078ee5f13f0e9d430d6783444a631d232a0#n109

Hi,

Am 03.01.24 um 16:47 schrieb James Addison:

I know. :)

That is not really a reason, though. I am  happy to patch it to make it
work (and build-depend on a matching clucene-core).

AFAICS this doesn't require a runtime dependency here since it writes
some other value to a field at generation time, which is read anyway in
the unpatched version even.


Actually  back then when Thorsten proposed it first I said "please make
it a configure check"...


Regards,


Rene

James Addison wrote:
Note that we _only_ need this during build time (so another option
would be using the custom clucene during build, but still link the
system clucene for runtime).

I simply don't know enough about the motivations to have this
pseudo-random value there in the first place, to opine on whether the
default can/should be changed...

Cheers,

There's a thread at LUENE-3606 (ref[0]) that seems relevant, and I've
included a few notes below from scouring through some git history.


Notes:

This timestamping was introduced[1] in Lucene 1.9RC1 back in Y2005 -
the changelog entry[2] doesn't tell us much more, although we can
imply that it was for a timing/refreshness related fix, because the
change adds an isCurrent method (described as useful to check whether
an IndexReader has an up-to-date object reference to an index/segment)
and test coverage.  There is a subsequent race-condition fixup[3].

At Lucene v4.x, the field returned to being a zero-initialized
counter[4].  That change[5] was made for LUCENE-3672 (ref[6]).
However: the clucene-core/2.3.3.4
package currently in Debian is currently based on Lucene v2.3.2 - so
that's the version to maintain compatibility with.

This[7] comment makes me think that resettng to zero isn't entirely unrealistic.

[0] - https://issues.apache.org/jira/browse/LUCENE-3607

[1] - https://github.com/apache/lucene/commit/c636897dc4a8a333295792718548bb50e9ab87ec

[2] - https://github.com/apache/lucene/commit/6455d1a1061f85c9ae7837967370b43bc1add4a1

[3] - https://github.com/apache/lucene/commit/9a9da2f7703ead41fd5f21f146d77aaddd4a76a0

[4] - https://github.com/apache/lucene/blob/30b22298bacb5238437864128bc9005d49d0d3ed/lucene/core/src/java/org/apache/lucene/index/SegmentInfos.java#L131-L132

[5] - https://github.com/apache/lucene/blob/30b22298bacb5238437864128bc9005d49d0d3ed/lucene/core/src/java/org/apache/lucene/index/SegmentInfos.java#L131-L132

[6] - https://issues.apache.org/jira/browse/LUCENE-3672

[7] - https://issues.apache.org/jira/browse/LUCENE-3607?focusedCommentId=13159392&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13159392

(with apologies for forgetting to cc Rene on my previous message)
[ ... snip ... ]
[ ... snip ... ]

Squinting more at the test coverage, a hypothetical explanation I can
think of is this:

If two index writer processes were likely to recreate an index file
near the same time, or in the presence of long-lived index reader
processes, then with a zero-based counter, a reader could easily
mistake two independently-created index segments (created with segment
version zero) as being 'current'.

I don't know for certain that this is the scenario that the timestamp
is intended to mitigate against -- it's certainly also possible that
Solr replication (noted elsewhere in the LUCENE-3607 JIRA thread) was
just as important, or maybe moreso.

However: libreoffice is, as I understand it, using this during
one-time build processes, and does not require replication of those
indexes.

I think the safe middle-ground rather than resetting to zero during a
reproducible build would be to use the value of SOURCE_DATE_EPOCH[1].
That should mean no API changes, and we're still using a timestamp,
keeping us close to the current behaviour -- but in a more
reproducible way.

There's also a useful note in LUCENE-3607 that the selected segment
merge algorithm in Lucene is relevant when attempting to build indexes
reproducibly.  Fortunately from a quick inspection, I think that
clucene-core uses SerialMergeScheduler (non-concurrent, recommended
for reproducibility) by default[2] already.

[1] - https://reproducible-builds.org/docs/source-date-epoch/

[2] - https://sources.debian.org/src/clucene-core/2.3.3.4+dfsg-1.1/src/core/CLucene/index/IndexWriter.cpp/?hl=185#L185

[ ... snip ... ]

The attached patch for clucene-core-2.3.3.4+dfsg-1.1 compiles and
implements SOURCE_DATE_EPOCH time retrieval -- but only in the context
of the segment info version fields.

Running a help build with SOURCE_DATE_EPOCH=0 should, with this patch,
be more-or-less equivalent to calling the proposed additional API
method to reset the segment version to zero.

The reason it doesn't override system time retrieval globally in the
codebase is that RAMDirectory objects are initialized[1] using the
system current time, and contain a while loop[2] that compares the
lastmodified on those objects to the output of another, subsequent
call to retrieve the system time -- so I thought it'd be sensible to
avoid the risk of an infinite loop there (while ts1 == ts2).

Please note: I haven't tested the patch yet, hence not adding a
'patch' tag to this bug yet - I'm building libreoffice locally after
installing the patched+compiled clucene package, and will inspect the
help indexes constructed by the build.  Feedback / review /
alternative approach suggestions are welcome.

[1] - https://sources.debian.org/src/clucene-core/2.3.3.4%2Bdfsg-1.1/src/core/CLucene/store/RAMDirectory.cpp/#L45

[2] - https://sources.debian.org/src/clucene-core/2.3.3.4%2Bdfsg-1.1/src/core/CLucene/store/RAMDirectory.cpp/#L523

Followup-For: Bug #1059805
X-Debbugs-Cc: rene@debian.org, thb@libreoffice.org

I'd underanticipated the build time requirements here (although I have read
since then that 24h or so is not unexpected for a first build) - so I don't
know if/when I'll get around to testing it properly.

Is there another way I could go about confirming whether my patch could work
for libreoffice, or to get some help doing that?

(also note: I hadn't noticed that this bugthread already had the 'patch' tag
applied)

PS: Reminded by a thread[1] on the RB mailing lists about potential issues
with SOURCE_DATE_EPOCH reader code, and from reading the relevant strtoul(3)
manual: the patch I provided lacks error-checking, and should be updated to
follow the guidelines in the manual and RB best-practices.

C isn't really my expertise but I'll rewrite the patch when I find time to add
the relevant checks.

[1] - https://lists.reproducible-builds.org/pipermail/rb-general/2024-January/003225.html

Dear Maintainer, Rene, Thorsten,

I have to admit that I have not, and am not likely to, find the time or gain
the necessary experience to properly develop and test an alternative to the
libreoffice clucene-core patch[1].

As a result, I would like to add my support for proceeding with that original
patch in Debian (ignoring my earlier concern about the fact that it adjusts the
clucene ABI).

In other words: unless someone gathers a sudden burst of enthusiasm to test my
possibly-broken 'reproducible-output.patch' proposal[2], please ignore it and
prefer the existing, known-working patch instead.

Regards,
James

[1] - https://cgit.freedesktop.org/libreoffice/core/patch/?id=ff071078ee5f13f0e9d430d6783444a631d232a0

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059805#35

Hi,

I'd like to propose some procedure for packages that appear to lack
active maintenance, but where no formal orphaning has taken place.  Lets
have a look for instance at clucene-core:

  1. High popcon[1]
  2. Important rdepends like libreoffice-core
  3. Maintainer was contacted in #879296, but there has been no response
     recorded there; the last upload was nearly ten years ago
  4. Uploader was asked about interest to become Maintainer four
     years ago with no response[2]
  5. Open bug with patch to solve reproducibly problem #1059805
     requested by libreoffice maintainer with no progress since
     nearly two years
  6. Package was NMUed three times in a row (one 64-bit time_t,
     others to fix RC bugs)

One possible solution to consider would be to move the package to Debian
Commons maintenance, host it in the Debian team on Salsa, and upload the
change with a delayed upload to allow objections.  For the example above
I prepared this in

https://salsa.debian.org/debian/clucene-core

This example should simply give some evidence that we might need some
solution which does not block contributors to invest some time into
packages.  While another NMU would address the immediate issue, it would
not improve the long-term maintenance situation of the package.

Since this is not the only example we have I would like to go beyond
this example and start a discussion about criteria under which a move to
Debian Commons maintenance could be proposed.  (BTW, thanks a lot to
Paul for this suggestion which enabled me to have finally all my
packages team maintained.)

Possible criteria might include:

  * no maintainer upload for N years (combined with unsuccessful contact
    attempts)
  * repeated NMUs
  * unanswered contact attempts
  * pending fixes from contributors
  * importance of the package within Debian

Are these reasonable indicators, and are there others that should be
considered?  The delayed upload would provide another opportunity for
any interested maintainer or uploader to object, participate, or take
over maintenance.  The Debian Commons maintenance model is also easy to
reverse if an existing maintainer returns or another person volunteers
to take over primary responsibility for the package.

The goal is not to replace maintainers who are still interested in their
packages, but to provide a straightforward path to propose ongoing
maintenance when there is no active maintainer involvement.

Debian already has contributors willing to maintain such packages. The
question is how we can provide a clear and scalable path for those
contributors to assume ongoing responsibility when traditional
single-maintainer maintenance has effectively become inactive.

Kind regards
    Andreas.

[1] https://qa.debian.org/popcon.php?package=clucene-core
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879296#15
[3] https://qa.debian.org/developer.php?login=team%2Bdebian%40tracker.debian.org
https://lists.debian.org/debian-devel/2026/05/msg00105.html

That's the important question needing to be answered. Everything else
might be indicative, and probably these packages are important - but
why is the process that we have not working?

Is this an attempt of a workaround for the orphaning?

Best,
Chris

PS: I think the time_t-64bit NMUs should not be counted for this
purpose.

Hello Andreas,

thank you very much for picking up this topic. I am just an upstream
maintainer
but also in high interest in the Debian packaging process and
communication
between Debian and upstream.

Am 05.06.2026 14:30 schrieb Andreas Tille:

Interesting. I was not aware of this option.

This measures the timespan between "now" and the last upload. Would it
be
more meaningful to measure the time since the last upstream release that
has not yet been uploaded?

Alternativly, one could measure the time since the last merge request or
patch that has not yet been incorporated into an upload.

Kind regards
Christian Buhtz

Hi,

Le 5 juin 2026 14:30:35 GMT+02:00, Andreas Tille <tille@debian.org> a écrit :

how would that be different from the existing package salvaging procedure already documented at [1][2] ?


[1] <https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging>
[2] <https://wiki.debian.org/PackageSalvaging>


Happy hacking,
--
Aurélien

As a preface, I think the Cc list on these emails is horrible but I'm sure
it's intentional so I'm not dropping anyone.

[...]

I still think that formally orphaning unmaintained but not formally
orphaned packages is the best
thing (when they can't/shouldn't be RMed) because it's the only thing that
explicitly marks a package as orphaned, i.e. that nobody cares about it.
Shoving them into Debian Commons is not better than shoving them into
random teams as was done before: it still hides their status, adds some
busywork and prevents them from being formally orphaned for some more
years.

*cough* I mean...

Don't we have a mechanism where a specific really existing person can become a
maintainer of an unmaintained but not formally orphaned package directly?

Are you asking about mass-orphaning via the MIA team or is there another
process I've forgot about?

Hello Aurélien,

Am 05.06.2026 15:25 schrieb Aurélien COUDERC:

Sometimes there are packages where "uploaders" jumping in, doing
the work and the DM only uploads the work of "uploaders" without much
more. Such cases are IMHO not covered by the current salvaging
process.

Best,
Christian

Quoting Aurélien COUDERC (2026-06-05 15:25:48)

As I understand it, salvaging is a process to adopt a package, whereas
this seems to be an interest in revoking a maintainer *without*
adoption.

 - Jonas

...so orphaning + a QA upload...

G'luck,
Peter

Salvaging requires someone to become the maintainer.

Such cases also are likely irrelevant (hard to be sure when one needs to
guess what do you mean by ""uploaders"" and "the DM").

There is no incomplete orphaning process, the package was not supposed
to be orphaned.

This bug (#879296) is a "remove from Uploaders"-type bug, it has been
filed as a result of an MIA process in 2017.

It only affects only one of the two uploaders recorded in d/control, so
orphaning the package was not warranted when I filed this bug.

Hi Andrey,

Am Fri, Jun 05, 2026 at 06:34:02PM +0500 schrieb Andrey Rakhmatullin:

The CC list involves all people who posted to the two open bugs (+ MIA
team).

I personally see a difference between the QA team and Debian Commons, but
even if we assume for the sake of discussion that moving the package to
the QA team would be preferable in this particular case, what process
would you suggest to formally orphan the package under the current
circumstances?

For clucene-core we have a maintainer who has not uploaded in nearly ten
years, contact attempts that went unanswered, repeated NMUs, and pending
fixes from contributors. Yet, as far as I understand, there is currently
no established procedure that would allow the package to become formally
orphaned without active involvement from the maintainer.

This is exactly the gap I am trying to discuss. If we believes that such
packages should become formally orphaned rather than move to Debian
Commons, what is the practical path to achieve that?

That would be ITS. Any volunteer(s)? I think most of the work needed for
the next upload is already done. However, even if somebody steps forward,
that would only solve the problem for this particular package.

BTW, we had a somewhat similar situation with libasyncns[1]. At the time,
the my mail received neither comments about how such situations should be
handled nor any volunteer willing to take over maintenance. I eventually
experimented with an "Intent to Orphan" process[2].

In hindsight, I agree that starting such a process without first seeking
consensus on the procedure was not a good idea. The criticism I received
on that point was fair.

However, that experience also reinforced my impression that we currently
lack a generally accepted process for dealing with packages that appear
to have no active maintenance but are not formally orphaned. In the case
of libasyncns, the package has since been adopted (#1123614), which is a
good outcome. My takeaway is not that the specific process I used should
be adopted, but that we would benefit from agreeing on some process for
handling such cases.

Without a shared procedure, we seem to be left with discussing individual
packages one by one, while contributors willing to help have no clear path
forward.

Kind regards
    Andreas.

[1] https://lists.debian.org/debian-devel/2025/06/msg00131.html
[2] https://bugs.debian.org/1107475#10

Sure.

Discussing a process to orphan someone else's packages (which, even to my
knowledge, was asked for multiple times as a better alternative to adhoc
processes such as ITS hijacking) would be better IMO but that's not what
you asked :)

My personal opinion is that it should be similar to ITS in principle but
with (much) tighter requirements for package eligibility and (not too
much) longer timelines for the process. And with a thicker skin for the
submitter.

(restoring the context) you said there are volunteers, that's why I
pointed to ITS. If there are no volunteers, that's a different matter than
what you said.

Hi

[No need to CC me, I already get this 3 times]

Small comment.


In my opinion, if you want to maintain it in Debian Commons, you are
salvaging the package and should use the salvation process. Debian
Commons is intended to declare weak ownership, which is something else
than no ownership. If you are willing to stick your name to a package in
uploaders at least, ITS should work for you already. If you don't, than
Debian Commons shouldn't be part of your solution.

Paul

Hi Paul,

Am Sat, Jun 06, 2026 at 11:06:40AM +0200 schrieb Paul Gevers:

Reduced the CC to relevant bugs + Maintainer + Uploader.

OK, you do not consider Debian Commons part of the solution, and I can
understand the argument that Debian Commons should only be used when at
least one person explicitly wants to take ongoing responsibility for the
package.

My reading of the current thread is that several people agree that
clucene-core appears to lack active maintenance, while there is less
agreement about the appropriate process to handle such packages. Since
the package does not seem to fit the usual MIA workflow, perhaps we
should discuss what criteria and procedure would be appropriate for
formal orphaning in such cases.


To solve this we need criteria for packages for which a formal orphaning
process may be initiated by a contributor and concluded by a QA upload.
I'd suggest the following criteria:

Mandatory criteria
------------------
  * No maintainer upload for at least 5 years.
  * At least two documented contact attempts over a period of at least 6
    months with no response from the maintainer
  * At least one non-trivial NMU has been required since the last
    maintainer upload (no mass transitions and similar archive-wide
    changes)
  * No indication from the maintainer that they still intend to maintain
    the package
  * A contributor is willing to prepare the QA upload and document the
    evidence.

Other indicators
----------------
These are not required but strengthen the case:

  * Repeated (non-mass) NMUs
  * RC bugs remaining unfixed for an extended period
  * Patches pending without maintainer response
  * Uploader(s) also unresponsive


If a package fulfills these criteria, I suggest the following process:

 1. File an Intent to Orphan bug documenting why the package satisfies
    the mandatory criteria.
 2. Make sure to CC Maintainer and Uploaders when filing the bug.
 3. Wait 21 days.
 4. Upload to DELAYED/15 *and* CC debian-devel list when informing
    Maintainer and Uploaders about the upload.
 5. Any response from the Maintainer or member of the Uploaders list
    indicating continued interest in the package immediately stops the
    process. Substantial objections raised on debian-devel should also
    result in cancellation of the upload until those objections have
    been addressed.

(Motivation for DELAYED/15 is that there might be additional input
from debian-devel with good reasons to cancel the upload.)

The intent is not to replace the MIA process, but to provide a path for
cases where contributors believe a package lacks active maintenance and
no MIA process has been initiated.

If there appears to be support for such a procedure, I will file an MR
against developers-reference to document it.

Kind regards
    Andreas.

* Andreas Tille <tille@debian.org> [260608 11:01]:

I do not understand why clucene-core "does not seem to fit the usual MIA
workflow", and I suspect that this is where others are also not
following your logic.

What I am reading from others in this thread is that the correct way
forward with this package is to start the MIA process with the remaining
uploader associated with this package.

You seem to be saying that there should be a way to orphan a package
without either involving the MIA team or getting the blessing of the
maintainer, and my question is "Why?"  If there is a maintainer or
uploader who is not MIA, then discuss with that person options such as
orphaning the package or moving it to Debian Commons or something else.
If not, then follow the MIA process.

If there are multiple maintainers, and none of them are responding to
both collective and individual pings, start the MIA process, letting the
MIA team know the specific package you are concerned about.

I think all of your "criteria" constitute unnecessary bureaucracy for a
problem that already has enough bureaucracy.

...Marvin

I feel like the answer is "I don't want to wait some more years".

I think this framing is useful. And think the answer is:

* In past several years the MIA team was reportedly nonexistent.
* When someone sees a package that has been clearly unmaintained for
   years, a normal desire is to mark it as orphaned "now-ish" and not "in a
   year or several".

It's replacing one kind of bureaucracy with another, simpler, one.

Maybe I should have asked what the intention of the plan here is in
the first place. It seemed to me that the subject was packages that,
to quote:

| appear to lack
| active maintenance, but where no formal orphaning has taken place

So either they need orphaning or salvaging.

I don't understand why we need yet another thing.

Chris

Then I don't see why this discussion exists in the first place.

Best,
Chris

Hi Chris,

Am Wed, Jun 10, 2026 at 06:08:36PM +0200 schrieb Chris Hofstaedtler:

I think this discussion exists because we have packages that appear to
lack active maintenance, yet the existing processes have not resulted in
either orphaning, salvaging, or renewed maintenance.

My proposal is simply to add another option for volunteers who are
willing to document the situation and do the work needed to improve the
package's maintenance situation.

People who consider orphaning or salvaging sufficient can continue to
use those processes. Nobody would be forced to use the additional one.

What harm would such an additional, optional process actually cause?

Kind regards
    Andreas.

So I think I understand where you are coming from, and I know
you mean well :) But still, I am going to give a couple of answers to
this question :)

First and foremost, it will cause confusion. At the very least, it will
be one more thing to think about when somebody looks at a package and
considers their options to make it better: should they ask for it to
be orphaned? Should they file an ITS? Or should they use the Debian
Commons thing (that still needs to be clearly defined)? What are
the differences, what are the pros and cons?

For more inexperienced Debian contributors, especially those who have
not been around long enough or simply have not followed the discussions
over the past couple of years, this may be a lot of confusion :)

Second, the additional process needs to be clearly defined first.
And from what I'm seeing in this thread, and from the way I read
the original Debian Commons thread (the one that started at
https://lists.debian.org/debian-devel/2026/05/msg00105.html),
I really am not quite certain *how* exactly taking over a package for
Debian Commons differs from salvaging it and also adding Debian Commons
as an uploader. I sincerely, truly don't understand that.
(as noted elsewhere in this thread, including by himself, Paul Gevers's
original idea is much closer to LowNMU that to the QA team)

So... yeah. Confusion abounds :)

G'luck,
Peter

Oh, sorry, I forgot to reply to that. From what I'm reading here,
the existing processes did not result in orphaning for one main
reason, one reason that, in my mind, eclipses anything else:
nobody actually decided to start an orphaning process :)
Now, the reasons for that I cannot speculate about.

G'luck,
Peter

Hi Peter,

Am Fri, Jun 12, 2026 at 01:04:58PM +0300 schrieb Peter Pentchev:

I agree that introducing a new process requires a clear definition. In
fact, one outcome of this thread for me was that Debian Commons and the
orphaning discussion should be treated separately, which is why I
changed the subject line in my follow-up mails[1].

Regarding the potential confusion, I am not yet convinced that the
decision process would become significantly more complicated.

As I see it, somebody who encounters a package that appears to lack
active maintenance has a fairly simple set of choices:

 * If they want to take responsibility for the package themselves, they
   can use the existing salvaging/adoption mechanisms.

 * If they do not want to maintain the package themselves but are
   willing to investigate the situation, collect evidence and prepare
   the necessary QA upload, they could use the additional process I am
   proposing, together with the possible criteria discussed in [1].
   In this case the volunteer takes responsibility for documenting why
   the proposed QA action is justified rather than merely asking others
   to investigate the package.

 * If they do not want to do either of these things, they can ask the
   MIA team to investigate.

So I see the proposed process less as an alternative to salvaging and
more as an option for people who are willing to help move a package
towards a maintenance status that matches reality, but who do not want
to become the maintainer themselves.

Hope this helps clarifying the confusion
   Andreas.

[1] https://lists.debian.org/debian-devel/2026/06/msg00086.html

We believe that the bug you reported is fixed in the latest version of
clucene-core, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1059805@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille <tille@debian.org> (supplier of updated clucene-core package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 05 Jun 2026 08:40:27 +0200
Source: clucene-core
Architecture: source
Version: 2.3.3.4+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Commons <clucene-core@packages.debian.org>
Changed-By: Andreas Tille <tille@debian.org>
Closes: 879296 1059805 1139752 1139802
Changes:
 clucene-core (2.3.3.4+dfsg-2) unstable; urgency=medium
 .
   * Team upload.
   * Migrate package to Debian Commons
     Closes: #879296, #1139752, #1139802
   * Secure URI in Homepage
   * Add watch file documenting that project is Untrackable
   * d/copyright: DEP5
   * debhelper-compat (= 13)
   * Add CLuceneConfig.cmake to devel package
   * Remove unused lintian-overrides
   * Apply LibreOffice patch to allow not writing random timestamps into
     generated files, making them unreproducible
     Closes: #1059805
   * Standards-Version: 4.7.4 (Removed Priority field)
Checksums-Sha1:
 a184ec39e79fbf64dce8affeb4093eafdb058098 2192 clucene-core_2.3.3.4+dfsg-2.dsc
 1fcf29e69b7918dcab9aee79b82cba4d94b51a58 12340 clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 c8203218fb5776b8f2fd3de5bc41358958f2e9dd 6890 clucene-core_2.3.3.4+dfsg-2_source.buildinfo
Checksums-Sha256:
 cec5d6b729ceaf2b835957ef5c52ff9562b0471ab888cc6af8f9a7ee86b560b0 2192 clucene-core_2.3.3.4+dfsg-2.dsc
 ac37f056368461fad4f86649b42d2ad65f73b41a81a39ef2cb39f3e7da87c7b7 12340 clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 ed43fa710f402af7abff6478f093fc61a3b6c27fd4eb840b582794ca400c132f 6890 clucene-core_2.3.3.4+dfsg-2_source.buildinfo
Files:
 f50c40ea5245347c0f551ac7b8546afa 2192 libs optional clucene-core_2.3.3.4+dfsg-2.dsc
 98c0b4d40ebafa287a11fa95ca4fb63a 12340 libs optional clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 1ef2c3eb5a777e359aaf2b2e6c2a1fe8 6890 libs optional clucene-core_2.3.3.4+dfsg-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE4S3qRnUGcM+pYIAdCqBFcdA+PnAFAmotKDMACgkQCqBFcdA+
PnBL4A//RHncYLz7dSfUv0ddOqkkfo+/OAJdRSPhMods/DWGbeeQn8V12oF745Ab
s6RfB/vbUz38FCk6YrqR0r8/4UV+82Z0RQ2HI96XhRAXHjo3wBDkZHetmmNOzP05
oE8ceL7kbuWv4Jm5iGqupEK3YQ1G32rB4JnC1Jop/AFUAbCS1ZFaiwwSENBNkRx6
5oqid85qMFrgXtIL4HEzdxVn8EwlYvsOy1wpZoheoGaCRKoik3kC9AgJVXvdlN6Y
W4FqYcvTx7hYeVUtGE1SGBX7bR8DMU4ULKB9hiXRcT0MXjgWeGScg/rIEwd9h4uX
MFkQvuwVDAzqvBeHFh9AH6AGB3C/biskaa2fVkqk9zsmVmHZT8hyMXV55KkGNNzi
sxKB2YCHMyDscRZPFYL+ZDDx4bACt1lYCfXFHCA9nJl7q4OvMEbKVbvUBKlxWiXt
rjVY9OZUoYwRDDL5bDEVAq4qgy7XWCNp7A5zjDe3TfQMxO2u2ySi4yjQ7MA9Px5A
hSrytjRQDJbxU3/bhE9hy1QvmA/N2eyerUEcAfT64J9FSeaDyNT0J3ku2DojIa+h
9VaAWxc91E4pYj/c9n4zvYXssaxPzqTx2msicDgUr4EJ25J82zir6EMUL/GuZrGy
wz3cNoxvcJDL+6RjP1mg+yFxahwYxQ+hIiM9e0rHzH31lP0pf+I=
=lM+6
-----END PGP SIGNATURE-----