| 1 |
On Tue, 2004-06-22 at 17:14, Peter S. Mazinger wrote: |
| 2 |
> On 22 Jun 2004, Ned Ludd wrote: |
| 3 |
> |
| 4 |
> > On Tue, 2004-06-22 at 07:03, Peter S. Mazinger wrote: |
| 5 |
> > > Hello! |
| 6 |
> > > |
| 7 |
> > > 1. perl-5.8.4 misses the uclibc changes |
| 8 |
> > |
| 9 |
> > > 2. perl-5.8.4 does not work w/ ndbm provided by berkdb (neither on glibc) |
| 10 |
> > |
| 11 |
> > <rac> solar: DB_File (which uses ndbm internally) works fine here |
| 12 |
> > <rac> solar: my little bit of futzing around with lcars on wasabi used |
| 13 |
> > that berkeley db interface extensively, and was all done on 5.8.4) |
| 14 |
> > <solar> Can you Re: that and say.. provide a test case? |
| 15 |
> > <rac> solar: i can't keep up with all my gentoo mailing list email as it |
| 16 |
> > is, and can't add another mailing list. can you ask them to file a bug? |
| 17 |
> |
| 18 |
> it's not DB_File (that is pure Berkeley DB) |
| 19 |
> NDBM_File (compat libs) is recognised by 5.8.2, but not by 5.8.4, so |
| 20 |
> either the test fails running configure, or something else changed (tested |
| 21 |
> against db-4.1.25_p1) |
| 22 |
|
| 23 |
Can you mail rac (the perl maintainer) about this please. |
| 24 |
|
| 25 |
> |
| 26 |
> > > 3. miscfiles using compressed files will work only if cracklib gets |
| 27 |
> > > compressed file support, else cracklib can't use them |
| 28 |
> > Ok there seems to be a logic error in your patch. The 644 mode never |
| 29 |
> > took place. |
| 30 |
> > I'm fixing this up and put it into the -r7 in a few mins. |
| 31 |
> |
| 32 |
> well, I'll wait for the logic error ;) |
| 33 |
> |
| 34 |
> > Note: for now we have to use uclibc? ( app-arch/gzip ) |
| 35 |
> |
| 36 |
> ok for now |
| 37 |
> |
| 38 |
> > > 4. db4 could also get a c++ disable option (for uclibc) |
| 39 |
Do we even need berkdb? |
| 40 |
|
| 41 |
> > > 5. my not-answered question: will gcc get a c++ flag? |
| 42 |
|
| 43 |
Can you propose it to the toolchain@ with your reasoning for it. |
| 44 |
|
| 45 |
> > |
| 46 |
> > oh.. this one is going to be tricky ;/ |
| 47 |
|
| 48 |
|
| 49 |
> |
| 50 |
|
| 51 |
|
| 52 |
> than we would need subpackaging, to separate out c++ and libstdc++ from |
| 53 |
> the main gcc package |
| 54 |
Speaking of sub packaging have you had a chance to muck with the |
| 55 |
multipackage FEATURE I posted a week or so ago? I've talked the idea of |
| 56 |
multi packaging over with the portage team. They don't like it. They |
| 57 |
offered No ideas or solutions either. So I'm thinking for the actually |
| 58 |
embedded devices themselves we can/should abopt the ipkg format. ipkg is |
| 59 |
a pretty common packaging format for embedded devices, and it would |
| 60 |
probably be in our best interests to adopt an existing standard vs |
| 61 |
making a new one. One advantage of the ipkg is you can actually use it |
| 62 |
from your embedded devices. ie pkg management on a 2 meg flash is 100% |
| 63 |
doable with it. |
| 64 |
|
| 65 |
> |
| 66 |
> Peter |
| 67 |
-- |
| 68 |
Ned Ludd <solar@g.o> |
| 69 |
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer |
Archives