<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>43906</bug_id>
          
          <creation_ts>2004-03-06 12:35 0000</creation_ts>
          <short_desc>fortune-mod-1.99.1 (updated ebuild)</short_desc>
          <delta_ts>2004-05-12 14:30:08 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Ebuilds</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          <bug_file_loc>http://www.redellipse.net/code/fortune/</bug_file_loc>
          
          
          <priority>P2</priority>
          <bug_severity>enhancement</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>lsmod@hotmail.com</reporter>
          <assigned_to>games@gentoo.org</assigned_to>
          

      

      
          <long_desc isprivate="0">
            <who>lsmod@hotmail.com</who>
            <bug_when>2004-03-06 12:35:14 0000</bug_when>
            <thetext>After a long 5 years, fortune-mod is once again actively maintained.

From http://www.redellipse.net/code/fortune/:

There are quite a few differences between this version of fortune, and the one which is currently available for most distributions. These changes include:

    * Some internationalisation support
    * UTF-8 support
    * Zillions of extra fortunes that have been suggested to the Debian maintainers over the last 5 years
    * Number of spelling fixes.
    * Fixes to REGEXPs searches
    * Changes in percentage allocations
    * A few bug fixes
    * A Y2K compliant version number
    * Some other stuff I&apos;ve probably forgotten about ;-) 


I had a problem with the &apos;-m&apos; option, which is supposed to search for fortunes matching an arbitrary regexp. It would segfault sometimes without printing anything, and other times it would print out a few fortunes and then segfault.

I found the offending code in fortune.c in matches_in_list() on line 1581:

if (fp-&gt;utf8_charset)
       free (output);

I&apos;m not exactly sure how the whole function works, but when i removed this code the &apos;-m&apos; option worked fine. Emailing the maintainer about this.


Oh yeah, and portage thinks that 1.99.1 is older than 9708.  Is there a way to specify version order in the ebuild?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lsmod@hotmail.com</who>
            <bug_when>2004-03-06 12:35:49 0000</bug_when>
            <thetext>Created an attachment (id=26952)
fortune-mod-1.99.1.ebuild
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wolf31o2@gentoo.org</who>
            <bug_when>2004-03-08 05:56:23 0000</bug_when>
            <thetext>Hrrrmn... unfortunately, there is no way that I know of to &quot;force&quot; an ebuild to install over another.  I think we&apos;ll definitely need to investigate this one a bit more before we can add it.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mr_bones_@gentoo.org</who>
            <bug_when>2004-03-08 10:54:37 0000</bug_when>
            <thetext>No problem.  First we add the new version to portage, then mask the old version
in profiles/package.mask.  It&apos;s pretty straight forward.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lsmod@hotmail.com</who>
            <bug_when>2004-03-08 12:19:17 0000</bug_when>
            <thetext>&gt;No problem.  First we add the new version to portage, then mask the old version
in profiles/package.mask.  It&apos;s pretty straight forward.

I know we can do that, but do you guys think specifying version order would be a good idea for portage?  It would probably only be a good idea if there are other packages out there that do something funky like this.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wolf31o2@gentoo.org</who>
            <bug_when>2004-03-18 16:39:51 0000</bug_when>
            <thetext>That would be useful in these few fringe cases where it happens, butit would make for a pretty hefty maintenance nightmare to keep up with version orders, unless it was completely optional.  SpanKY, what&apos;s the plan on this one?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2004-03-18 18:04:27 0000</bug_when>
            <thetext>9708 becomes 1.0.9708 and we delete 9708

then we add 1.99.1 as unstable

everyone in stable goes to 1.0.9708 (it&apos;s a small program so i dont care about the recompile hassle) while everyone in unstable goes to 1.99.1</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wolf31o2@gentoo.org</who>
            <bug_when>2004-05-12 14:30:08 0000</bug_when>
            <thetext>This has been done in CVS</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>26952</attachid>
            <date>2004-03-06 12:35 0000</date>
            <desc>fortune-mod-1.99.1.ebuild</desc>
            <filename>fortune-mod-1.99.1.ebuild</filename>
            <type>text/plain</type>
            <data encoding="base64">IyBDb3B5cmlnaHQgMTk5OS0yMDA0IEdlbnRvbyBUZWNobm9sb2dpZXMsIEluYy4KIyBEaXN0cmli
dXRlZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHYy
CiMgJEhlYWRlcjogL2hvbWUvY3Zzcm9vdC9nZW50b28teDg2L2dhbWVzLW1pc2MvZm9ydHVuZS1t
b2QvZm9ydHVuZS1tb2QtOTcwOC1yMS5lYnVpbGQsdiAxLjMgMjAwNC8wMi8yMCAwNjo0Mzo1OCBt
cl9ib25lc18gRXhwICQKCmluaGVyaXQgZXV0aWxzCgpERVNDUklQVElPTj0iVGhlIG5vdG9yaW91
cyBmb3J0dW5lIHByb2dyYW0iCkhPTUVQQUdFPSJodHRwOi8vd3d3LnJlZGVsbGlwc2UubmV0L2Nv
ZGUvZm9ydHVuZS8iClNSQ19VUkk9Imh0dHA6Ly93d3cucmVkZWxsaXBzZS5uZXQvY29kZS9kb3du
bG9hZHMvJHtQfS50YXIuZ3oiCgpMSUNFTlNFPSJCU0QiClNMT1Q9IjAiCktFWVdPUkRTPSJ+eDg2
IgpJVVNFPSJvZmZlbnNpdmUiCgpERVBFTkQ9InZpcnR1YWwvZ2xpYmMKCWFwcC10ZXh0L3JlY29k
ZSIKClsgYHVzZSBvZmZlbnNpdmVgIF0gJiYgb2ZmPTEgfHwgb2ZmPTAKCnNyY191bnBhY2soKSB7
Cgl1bnBhY2sgJHtBfQoJY2QgJHtTfQoJCglzZWQgLWkgXAoJCS1lICdzOi9nYW1lczo6JyBcCgkJ
LWUgJ3M6L2ZvcnR1bmVzOi9mb3J0dW5lOicgXAoJCS1lICdzOkZPUlRESVI9JChwcmVmaXgpL3Vz
cjpGT1JURElSPSQocHJlZml4KS91c3IvYmluOicgXAoJCS1lICJzOl5DRkxBR1M9LiokOkNGTEFH
Uz1cJChERUZJTkVTKSAke0NGTEFHU306IiBcCgkJTWFrZWZpbGUKCXNlZCAtaSAnczpjaGFyIGEs
IGI7OnNob3J0IGludCBhLCBiOzonIHV0aWwvcm90LmMKCgkjIGZpeGVzIHRoZSAnLW0nIHNlZ2Zh
dWx0IHByb2JsZW0gb24gX215XyBjb21wdXRlciwgaXQgbWlnaHQgc2NyZXcgc29tZXRoaW5nIGVs
c2UgdXAgaSBkb24ndCBrbm93IGFib3V0LgoJc2VkIC1pIFwKCQknL2lmIChmcC0+dXRmOF9jaGFy
c2V0KS97CgkJCU4KCQkJL2ZyZWUgKG91dHB1dCk7L2QKCQl9JyBmb3J0dW5lL2ZvcnR1bmUuYwp9
CgpzcmNfY29tcGlsZSgpIHsKCWVtYWtlIFwKCQlPRkZFTlNJVkU9IiR7b2ZmfSIgXAoJCXx8IGRp
ZQp9CgpzcmNfaW5zdGFsbCgpIHsKCW1ha2UgXAoJCU9GRkVOU0lWRT0iJHtvZmZ9IiBcCgkJcHJl
Zml4PSIke0R9IiBcCgkJaW5zdGFsbCBcCgkJfHwgZGllCgoJZG9kb2MgQ2hhbmdlTG9nIElOREVY
IElOU1RBTEwgTm90ZXMgT2ZmZW5zaXZlIFJFQURNRSBUT0RPIGNvb2tpZS1maWxlcwp9Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>