Re: hypre stalled on alpha buildd

[Adam C Powell IV]

On Mon, 2008-07-21 at 11:55 +0100, Tim Cutts wrote:
> On 9 Jul 2008, at 6:36 pm, Julien Cristau wrote:
> 
> > On Wed, Jul  9, 2008 at 13:22:18 -0400, Adam C Powell IV wrote:
> >
> >> Hello,
> >>
> >> Any ideas why the alpha buildd still shows "needs build" for hypre  
> >> after
> >> two weeks?
> >
> > there's still a big backlog as the alpha buildd was more or less down
> > for 2 weeks recently.  Things don't seem to be getting better very  
> > fast
> > unfortunately (still more than 300 packages in Needs-Build).
> 
> I'm really sorry about that.  We had a lot of crashes related to one  
> of the disk drives in goetz.d.o.  That disk has now been replaced, and  
> things have got better, although the machine has crashed once since.   
> If that happens again, I will have to do some more diagnostics on it.

I'm sorry to hear that.  No need to apologize to me, the explanation was
sufficient, and everything is fine for me now.

> It would be useful if the machine could run multiple buildd's in  
> parallel; it is, after all, a 4 CPU machine, and currently only runs  
> one build at a time, which seems to be a waste.  I will raise this  
> with the DSA team, and see if things can be changed to help work  
> through the backlog

DSA is of course more of a priority than something like hypre.  Another
thing is that a lot of packages can probably be made to build in
parallel...

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part

Re: hypre stalled on alpha buildd

[Adam C Powell IV]

On Wed, 2008-07-09 at 19:36 +0200, Julien Cristau wrote:
> On Wed, Jul  9, 2008 at 13:22:18 -0400, Adam C Powell IV wrote:
> 
> > Hello,
> > 
> > Any ideas why the alpha buildd still shows "needs build" for hypre after
> > two weeks?
> 
> there's still a big backlog as the alpha buildd was more or less down
> for 2 weeks recently.  Things don't seem to be getting better very fast
> unfortunately (still more than 300 packages in Needs-Build).
> 
> > In that time, alpha buildds have twice attempted opencascade
> > which is vastly larger and non-free...
> > 
> the non-free buildd network is separate.

I see.  Thanks for the clarifications!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part

hypre stalled on alpha buildd

[Adam C Powell IV]

Hello,

Any ideas why the alpha buildd still shows "needs build" for hypre after
two weeks?  In that time, alpha buildds have twice attempted opencascade
which is vastly larger and non-free...

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part

Re: Debian: removal of libffm (#399354): info / maintainer / work needed

[Adam C Powell IV]

On Wed, 2007-11-28 at 15:50 +0930, Paul Wise wrote:
> Hi all,
> 
> libffm (fast math library for alpha) may be removed from Debian:
> 
> http://bugs.debian.org/399354
> 
> Is it useful to have libffm on alpha? Is the libm from glibc 2.7 slower
> than the routines from libffm? If so, perhaps they should be ported to
> and merged into glibc? Is there anyone with alpha assembly skills who
> would like to attempt this task?

The feature of libffm that I used is its vectorized operations like
dsqrtv and dsqrtiv (double precision inverse square root, vectorized)
which can run just in a few clocks per operation.  This was great for
illuminator's semi-transparent software rendering engine, which is why I
stepped up to maintain it.  But it's not part of glibc, and probably
won't be.

If there are other useful parts, they've probably made their way into
glibc libm in the years since they were discussed on [EMAIL PROTECTED]

Too bad my alpha died or I'd still keep it up. :-(

> Adam, do you still intend to remove libffm from the illuminator deps?

D'oh!  Yes, I do.  Will take care of this soon.

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

O: ccc, cxx, libots, cpml, cxml, cfal, cfalrtl, libffm

[Adam C Powell IV]

Package: wnpp

Greetings,

I'm afraid my last piece of alpha hardware has gone out the door, and I
am no longer a linux-alpha or debian-alpha user. :-(  I'll have fond
memories of the machines and of lists like this one and linux-alpha, as
this was my first Linux platform, and my demonstration of its
performance/price in the late 90s initiated a Linux transition at my
former employer, in no small part thanks to the volunteer help I got,
and hopefully gave back.

Oh well.  More importantly for this list, I am no longer able to
maintain the DEC->Compaq->HP alpha compiler and math library installers,
nor the "free fast math" libffm of Goto and Wesner.  Unfortunately this
means I need to orphan them, and hope they find a maintainer.

libffm should be in good shape and, as far as I know, need little to no
maintenance at all, unless someone wants to add to the library.
Upstream has long since stopped supporting it, and though some of its
code has migrated to glibc, it has some unique and extremely
fast/powerful vectorized functions.  For example dsqrtiv() very rapidly
performs 1/sqrt(x) for an array of doubles; this function on the fastest
alpha may still be faster than glibc on the fastest Xeon or Opteron for
this purpose.

As for the others, because a three year campaign to get Compaq to let me
distribute the non-free libraries and (encrypted) compilers hit dead
ends, the biggest maintenance hassle is updating the debconf templates
to keep track of the elusive download URLs.  They also have template
translation bugs open which I never got to, and which will be dealt with
by NMUs around the end of this month; apologies to the translation
authors for the delay.  These too are long since abandoned by upstream,
and gcc/glibc have been catching up to them in performance, so their
need is not clear at this point.

Sorry about the sudden nature of this right before the etch release.  I
should have anticipated the effect of this change on my packages long
ago and done something preemptive about it. :-(

Best wishes for the continued upkeep of this great architecture and
platform!

Regards,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6 kernel of PWS 500au

[Adam C Powell IV]

On Thu, 2006-03-23 at 11:48 -0800, Steve Langasek wrote:
> On Thu, Mar 23, 2006 at 01:57:00PM -0500, Adam C Powell IV wrote:
> > On Sat, 2006-03-18 at 17:07 -0800, Steve Langasek wrote:
> > > On Sat, Mar 18, 2006 at 06:00:29PM -0700, Chris Brotherton wrote:
> > > > I want to upgrade my PWS 500au (Miata GL w/ usb) and I noticed that 
> > > > testing
> > > > now has 2.6.15.  For this system, do I want:
> 
> > > > linux-image-2.6.15-1-alpha-generic
> 
> > > > linux-image-2.6.15-1-alpha-legacy?
> 
> > > Generic.  Any system that supports SRM should work with the -generic 
> > > flavor.
> 
> > I have a bunch of LX164s without CD-ROMs, and a Nautilus with a broken
> > CD drive.  I haven't found a way to convert them to SRM without the CD.
> > Can they boot the -legacy kernels?
> 
> Any system that worked with sarge can *also* use the -legacy kernels,
> because -legacy uses the kernel config options that were used in the sarge
> kernels.  The only difference between the two, right now, is the option for
> using the old kernel load address.
> 
> FWIW, my LX164 system was flashed to SRM using a floppy rather than a CD.

Hmm, I've looked around and can't find floppy SRM images.  Can someone
point me to them?  On ftp.digital.com they only have CD .isos.

> > Haven't found a way to load an initrd on either of these subarches, that
> > is, using MILO or APB...
> 
> Er, both kernel flavors are still initrd-based.  I know it's possible to
> load an initrd with MILO, but I wouldn't be able to give you any practical
> help since I haven't used MILO in 5 years or so.

Any help on this would be appreciated too...  When I built 2.6.8 from
sarge without an initrd it booted okay (though network performance
degraded over time until after a few hours it was unusable).  Trying the
same with 2.6.15 or 2.6.16 does not work at all.  Couldn't get 2.4
working either.

So I'm still running on 2.2.25. :-(

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6 kernel of PWS 500au

[Adam C Powell IV]

On Sat, 2006-03-18 at 17:07 -0800, Steve Langasek wrote:
> On Sat, Mar 18, 2006 at 06:00:29PM -0700, Chris Brotherton wrote:
> > I want to upgrade my PWS 500au (Miata GL w/ usb) and I noticed that testing
> > now has 2.6.15.  For this system, do I want:
> 
> > linux-image-2.6.15-1-alpha-generic
> 
> > linux-image-2.6.15-1-alpha-legacy?
> 
> 
> Generic.  Any system that supports SRM should work with the -generic flavor.

I have a bunch of LX164s without CD-ROMs, and a Nautilus with a broken
CD drive.  I haven't found a way to convert them to SRM without the CD.
Can they boot the -legacy kernels?  Haven't found a way to load an
initrd on either of these subarches, that is, using MILO or APB...

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Upgrading to testing

[Adam C Powell IV]

On Sun, 2006-01-29 at 09:33 -0700, Chris Brotherton wrote:
> I have a 500au that is running sarge.  I was thinking about upgrading to
> testing.  Are there any potential problems I should be aware of.  I am
> planning on sticking with a 2.4 series kernel.
> 
> Chris.

Good, because it does not seem possible to compile the 2.6.12 testing
kernel using the testing compiler and .config (in case stock doesn't
work for you).

But otherwise, I've had good experiences with etch, no big probs I can
think of.  And this is on a nautilus running 2.2.25.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Etch compiler can't build etch linux-image-2.6.12-1 kernel??

[Adam C Powell IV]

What's with etch's inability to build its own 2.6.12 kernel?

  CC [M]  arch/alpha/oprofile/common.o
cc1: warnings being treated as errors
arch/alpha/oprofile/common.c: In function 'op_axp_setup':
arch/alpha/oprofile/common.c:68: warning: statement with no effect
arch/alpha/oprofile/common.c: In function 'op_axp_start':
arch/alpha/oprofile/common.c:89: warning: statement with no effect
arch/alpha/oprofile/common.c: In function 'op_axp_stop':
arch/alpha/oprofile/common.c:104: warning: statement with no effect
make[2]: *** [arch/alpha/oprofile/common.o] Error 1
make[1]: *** [arch/alpha/oprofile] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.12'
make: *** [stamp-build] Error 2

This seems RC...

Cheers,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Very slow networking on nautilus/3c905

[Adam C Powell IV]

Greetings,

Got a Nautilus machine from DCG a while back, and have been using it
under 2.2.25 with APB for ages.  I recently built 2.6.8 with almost the
debian .config (diff below, most changes allow non-initrd booting).

For some reason, over time the networking slows to a crawl under 2.6.8,
where 2.2.5 doesn't experience this problem.  This is with a 3c905B card
using the 3c59x driver.

Any ideas on why this happens?

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

--- /boot/config-2.6.8-2-generic2005-05-29 19:07:05.0 -0400
+++ /boot/config-2.6.8-2-nautilus   2005-10-31 21:09:26.0 -0500
@@ -52,7 +52,7 @@
 #
 # System setup
 #
-CONFIG_ALPHA_GENERIC=y
+# CONFIG_ALPHA_GENERIC is not set
 # CONFIG_ALPHA_ALCOR is not set
 # CONFIG_ALPHA_XL is not set
 # CONFIG_ALPHA_BOOK1 is not set
@@ -70,7 +70,7 @@
 # CONFIG_ALPHA_MARVEL is not set
 # CONFIG_ALPHA_MIATA is not set
 # CONFIG_ALPHA_MIKASA is not set
-# CONFIG_ALPHA_NAUTILUS is not set
+CONFIG_ALPHA_NAUTILUS=y
 # CONFIG_ALPHA_NONAME_CH is not set
 # CONFIG_ALPHA_NORITAKE is not set
 # CONFIG_ALPHA_PC164 is not set
@@ -87,18 +87,14 @@
 CONFIG_ISA=y
 CONFIG_PCI=y
 CONFIG_PCI_DOMAINS=y
-CONFIG_ALPHA_CORE_AGP=y
-CONFIG_ALPHA_BROKEN_IRQ_MASK=y
-CONFIG_EARLY_PRINTK=y
-CONFIG_EISA=y
-# CONFIG_SMP is not set
+CONFIG_ALPHA_EV6=y
+CONFIG_ALPHA_EV67=y
+CONFIG_ALPHA_IRONGATE=y
+# CONFIG_ALPHA_SRM is not set
 # CONFIG_DISCONTIGMEM is not set
 # CONFIG_VERBOSE_MCHECK is not set
 # CONFIG_PCI_LEGACY_PROC is not set
 CONFIG_PCI_NAMES=y
-CONFIG_EISA_PCI_EISA=y
-CONFIG_EISA_VIRTUAL_ROOT=y
-CONFIG_EISA_NAMES=y

 #
 # PCMCIA/CardBus support
@@ -288,20 +284,20 @@
 # CONFIG_BLK_DEV_SX8 is not set
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=8192
-CONFIG_BLK_DEV_INITRD=y
+# CONFIG_BLK_DEV_INITRD is not set

 #
 # ATA/ATAPI/MFM/RLL support
 #
-CONFIG_IDE=m
+CONFIG_IDE=y
 CONFIG_IDE_MAX_HWIFS=4
-CONFIG_BLK_DEV_IDE=m
+CONFIG_BLK_DEV_IDE=y

 #
 # Please see Documentation/ide.txt for help/info on IDE drives
 #
 # CONFIG_BLK_DEV_IDE_SATA is not set
-CONFIG_BLK_DEV_IDEDISK=m
+CONFIG_BLK_DEV_IDEDISK=y
 # CONFIG_IDEDISK_MULTI_MODE is not set
 CONFIG_BLK_DEV_IDECS=m
 CONFIG_BLK_DEV_IDECD=m
@@ -314,12 +310,12 @@
 #
 # IDE chipset support/bugfixes
 #
-CONFIG_IDE_GENERIC=m
-CONFIG_BLK_DEV_IDEPNP=m
+CONFIG_IDE_GENERIC=y
+CONFIG_BLK_DEV_IDEPNP=y
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
-CONFIG_BLK_DEV_GENERIC=m
+CONFIG_BLK_DEV_GENERIC=y
 CONFIG_BLK_DEV_OPTI621=m
 CONFIG_BLK_DEV_IDEDMA_PCI=y
 # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
@@ -395,12 +391,10 @@
 CONFIG_SCSI_7000FASST=m
 CONFIG_SCSI_ACARD=m
 CONFIG_SCSI_AHA1542=m
-CONFIG_SCSI_AHA1740=m
 CONFIG_SCSI_AACRAID=m
 CONFIG_SCSI_AIC7XXX=m
 CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
 CONFIG_AIC7XXX_RESET_DELAY_MS=15000
-CONFIG_AIC7XXX_PROBE_EISA_VL=y
 CONFIG_AIC7XXX_DEBUG_ENABLE=y
 CONFIG_AIC7XXX_DEBUG_MASK=0
 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
@@ -445,7 +439,6 @@
 # CONFIG_SCSI_IZIP_EPP16 is not set
 # CONFIG_SCSI_IZIP_SLOW_CTR is not set
 CONFIG_SCSI_NCR53C406A=m
-CONFIG_53C700_IO_MAPPED=y
 CONFIG_SCSI_SYM53C8XX_2=m
 CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
@@ -460,7 +453,6 @@
 CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
 CONFIG_SCSI_QLOGIC_1280=m
 CONFIG_SCSI_QLOGIC_1280_1040=y
-CONFIG_SCSI_SIM710=m
 CONFIG_SCSI_SYM53C416=m
 CONFIG_SCSI_DC395x=m
 CONFIG_SCSI_DC390T=m
@@ -992,7 +984,6 @@
 CONFIG_NET_VENDOR_SMC=y
 CONFIG_WD80x3=m
 CONFIG_ULTRA=m
-CONFIG_ULTRA32=m
 CONFIG_SMC9194=m
 CONFIG_NET_VENDOR_RACAL=y
 CONFIG_NI5010=m
@@ -1043,12 +1034,9 @@
 # CONFIG_EEPRO100_PIO is not set
 CONFIG_E100=m
 # CONFIG_E100_NAPI is not set
-CONFIG_LNE390=m
 CONFIG_FEALNX=m
 CONFIG_NATSEMI=m
 CONFIG_NE2K_PCI=m
-CONFIG_NE3210=m
-CONFIG_ES3210=m
 CONFIG_8139CP=m
 CONFIG_8139TOO=m
 # CONFIG_8139TOO_PIO is not set
@@ -1623,7 +1611,6 @@
 CONFIG_FT_FDC_MAX_RATE=2000
 CONFIG_FT_ALPHA_CLOCK=0
 CONFIG_AGP=m
-CONFIG_AGP_ALPHA_CORE=m
 CONFIG_DRM=y
 CONFIG_DRM_TDFX=m
 CONFIG_DRM_GAMMA=m


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: UP1100 and disk size

[Adam C Powell IV]

On Thu, 2005-11-10 at 17:23 -0500, Robert Funnell wrote:
> On Thu, 10 Nov 2005, Adam C Powell IV wrote:
> 
> > On Thu, 2005-11-10 at 16:03 -0500, WRJ Funnell wrote:
> ...
> > > I currently have SRM 5.6-9. I have found a 5.6-13 at
> > > www.microway.com (and at www.hungrycats.org). Does anyone know if
> > > there's a more recent version, or whether upgrading will solve my
> > > disk-size problem?
> >
> > What kernel are you running?  If you have the standard woody kernel (I
> > think 2.4.18), that had trouble with large disks, on i386 too.  Sarge
> > kernels should be fine.
> 
> Embarrassingly, I'm using 2.2. Upgrading the kernel is next on my
> to-do list. If I understand correctly, I should upgrade to 2.4, then
> upgrade to sarge, then upgrade to 2.6. I'm at the point of being
> confused by the fact that kernel images for both 2.4.18-5.0.1 and
> 2.4.18-15 are listed.

No need to be embarrassed.  I too still run 2.2, though with sarge; you
can upgrade to sarge and then to 2.6 just fine.  (I've had trouble with
the network under 2.6.8.)

> > I recently built 2.6.8 for nautilus, and posted the .config diffs here
> > (Nov. 1), in case you're interested.  (1100 is also nautilus, right? :-)
> 
> Well, it's nautilus but uses SRM so uses the generic kernel. At least
> that's what I was told back in 2000 when I installed it.

Right, then it can use initrds and the generic kernel, no problem.

> Glad to hear the disk problem is likely kernel and not SRM. Is there
> any point in upgrading SRM? Is there any information available about
> what differences there were in the different versions?

No idea, sorry.  (I still use APB/PAL. :-)

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: UP1100 and disk size

[Adam C Powell IV]

On Thu, 2005-11-10 at 16:03 -0500, WRJ Funnell wrote:
>  have a UP1100. I just installed two new 250-GB disks in it but it
> thinks they're only about 130 GB. Does anyone know if there's a way of
> using a disk larger than that?
> 
> I currently have SRM 5.6-9. I have found a 5.6-13 at
> www.microway.com (and at www.hungrycats.org). Does anyone know if
> there's a more recent version, or whether upgrading will solve my
> disk-size problem?

What kernel are you running?  If you have the standard woody kernel (I
think 2.4.18), that had trouble with large disks, on i386 too.  Sarge
kernels should be fine.

I recently built 2.6.8 for nautilus, and posted the .config diffs here
(Nov. 1), in case you're interested.  (1100 is also nautilus, right? :-)

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Evolution on alpha

[Adam C Powell IV]

On Sun, 2005-10-30 at 13:11 -0500, Adam C Powell IV wrote:
> Hello again,
> 
> Just submitted bug 320349 to GNOME Bugzilla on the second of these
> issues.

Could someone with both alpha and x86 on unstable give this a try?  It's
been a while since 2.0.4 in sarge was released, and the first reply to
my bug was, "This may have been fixed along with other 64-bit issues in
2.2.x".

> On the first, does any alpha person know what driver I need for an alpha
> nautilus with APB, so I can build it into a 2.4 or 2.6 kernel (i.e. not
> a module) which actually boots? :-)  The chipset appears to be ALI
> M5229, but I don't see a driver for that in the 2.6.8 IDE config list.
> 
> (Yes I know, upgrade to SRM, but the CD drive is broken.)

Just for the information of any other Alpha Nautilus APB users, here's
the diff vs. sarge 2.6.8 generic config which makes it work (though DMA
doesn't seem to work):

--- /boot/config-2.6.8-2-generic2005-05-29 19:07:05.0 -0400
+++ /boot/config-2.6.8-2-nautilus   2005-10-31 21:09:26.0 -0500
@@ -288,20 +284,20 @@
 # CONFIG_BLK_DEV_SX8 is not set
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=8192
-CONFIG_BLK_DEV_INITRD=y
+# CONFIG_BLK_DEV_INITRD is not set

 #
 # ATA/ATAPI/MFM/RLL support
 #
-CONFIG_IDE=m
+CONFIG_IDE=y
 CONFIG_IDE_MAX_HWIFS=4
-CONFIG_BLK_DEV_IDE=m
+CONFIG_BLK_DEV_IDE=y

 #
 # Please see Documentation/ide.txt for help/info on IDE drives
 #
 # CONFIG_BLK_DEV_IDE_SATA is not set
-CONFIG_BLK_DEV_IDEDISK=m
+CONFIG_BLK_DEV_IDEDISK=y
 # CONFIG_IDEDISK_MULTI_MODE is not set
 CONFIG_BLK_DEV_IDECS=m
 CONFIG_BLK_DEV_IDECD=m
@@ -314,12 +310,12 @@
 #
 # IDE chipset support/bugfixes
 #
-CONFIG_IDE_GENERIC=m
-CONFIG_BLK_DEV_IDEPNP=m
+CONFIG_IDE_GENERIC=y
+CONFIG_BLK_DEV_IDEPNP=y
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
-CONFIG_BLK_DEV_GENERIC=m
+CONFIG_BLK_DEV_GENERIC=y
 CONFIG_BLK_DEV_OPTI621=m
 CONFIG_BLK_DEV_IDEDMA_PCI=y
 # CONFIG_BLK_DEV_IDEDMA_FORCED is not set

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Evolution on alpha

[Adam C Powell IV]

Hello again,

Just submitted bug 320349 to GNOME Bugzilla on the second of these
issues.

On the first, does any alpha person know what driver I need for an alpha
nautilus with APB, so I can build it into a 2.4 or 2.6 kernel (i.e. not
a module) which actually boots? :-)  The chipset appears to be ALI
M5229, but I don't see a driver for that in the 2.6.8 IDE config list.

(Yes I know, upgrade to SRM, but the CD drive is broken.)

Thanks,
-Adam

On Mon, 2005-10-03 at 17:30 -0400, Adam C Powell IV wrote:
> Greetings,
> 
> I'm running evolution on an Alpha machine with kernel 2.2.19, and have
> noticed two issues.
> 
> First, there are a lot more evolution-related processes running than on
> x86: I have three evolution-alarm-notify processes, four
> evolution-data-servers, and about eleven evolutions.  When I log out, I
> only have the data servers, and when I kill the first, they all die.
> Could it be using processes instead of threads because of alpha, or
> because of the 2.2 kernel?  This is not a problem, just something
> interesting; evolution-data-server running after logout seems common to
> all arches.
> 
> Second, when I rsync my data back and forth to home, each time evolution
> runs for the first time on the new architecture it spends about two
> hours "Storing folder".  Do alpha and x86 have different formats for
> metedata files, such that on each switch it needs to recalculate
> everything again?  They're both little endian, but would some of the
> structures depend on the sizeof long??  This part is a problem...
> 
> Thanks,
> 
> -Adam

-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 325600 ( threads on Alpha).

[Adam C Powell IV]

On Sat, 2005-10-29 at 12:12 -0400, Tom Evans wrote:
> I apologize for not reading thoroughly -
> 
> the file I mentioned, is in 
> "build-tree/glibc-2.3.5/sysdeps/unix/sysv/linux".
> 
> I used "dpkg-buildpackage" to build the sources originally.  It 
> extracted everything
> into"build-tree" - I made my modifcation there and was able to do a 
> "make" in the "alpha-libc"
> directory to test my changes - not that the changes are made, I'm not 
> sure how to build a .deb without
> re-trashing everything - I figure the tools out - just hoped a patch 
> would come from my information
> quicker than it would take for me to be the fixer as well.

In such situations I just look through debian/rules, usually there's a
target to extract the tree and another target to make etc.  And if
there's a stamp file which would indicate the tree has been extracted,
just touch that and dpkg-buildpackage should build the .debs properly,
with your patch, without re-extracting.

Or you could integrate your patch into the package's patching mechanism.
But that takes just a bit more work, patience, etc.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Evolution on alpha

[Adam C Powell IV]

Greetings,

I'm running evolution on an Alpha machine with kernel 2.2.19, and have
noticed two issues.

First, there are a lot more evolution-related processes running than on
x86: I have three evolution-alarm-notify processes, four
evolution-data-servers, and about eleven evolutions.  When I log out, I
only have the data servers, and when I kill the first, they all die.
Could it be using processes instead of threads because of alpha, or
because of the 2.2 kernel?  This is not a problem, just something
interesting; evolution-data-server running after logout seems common to
all arches.

Second, when I rsync my data back and forth to home, each time evolution
runs for the first time on the new architecture it spends about two
hours "Storing folder".  Do alpha and x86 have different formats for
metedata files, such that on each switch it needs to recalculate
everything again?  They're both little endian, but would some of the
structures depend on the sizeof long??  This part is a problem...

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libffm adoption/change of soname

[Adam C Powell IV]

On Wed, 2005-08-17 at 23:26 +0200, Goswin von Brederlow wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 2005-08-17 at 13:19 +0200, Goswin von Brederlow wrote:
> >> Adam C Powell IV <[EMAIL PROTECTED]> writes:
> >> 
> >> > Greetings,
> >> >
> >> > I'm adopting libffm, and noticed that it has the erroneous soname of
> >> > libffm.so.0.  Since the library interface has changed on just about
> >> > every upgrade, it should really be libffm.so.0.28.
> >> >
> >> > On the other hand, the interface has only changed once since it was made
> >> > a Debian package, so libffm.so.1 sort of makes sense.  But this is
> >> > incompatible with upstream's name.
> >> >
> >> > So I'd like to leave the package name as libffm1(-dev), but change the
> >> > soname.  Packages won't need to change dependencies, but binaries built
> >> > against it will need to relink since libffm.so.0 will no longer exist.
> >> > As far as I know, the only package affected is illuminator, which I
> >> > maintain (hence my adoption, as it was headed for the trash bin).
> >> >
> >> > Any comments/objections?
> >> >
> >> > Thanks,
> >> >
> >> > -Adam
> >> 
> >> Why not rename the package and soname to libffm0.28(-dev) so they make
> >> sense and match up again?
> >
> > You know, that makes sense.  If I'm going to change the soname, so
> > packages have to be rebuilt anyway, I really should change the package
> > name with it (policy may even require it).  (That should have been
> > obvious to me...)
> >
> > Since it's not likely that people will want to install multiple versions
> > of the -dev package, I'll just make that libffm-dev.
> >
> > Thanks,
> >
> > -Adam
> 
> Don't forget to change the name on every _API_ change. Sounds like the
> lib is till highly under developement so I wouldn't be surprised if
> the API changes slightly with releases as well.

Right, used to be under heavy development.  But they haven't had a
release since 1998. :-)

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libffm adoption/change of soname

[Adam C Powell IV]

On Wed, 2005-08-17 at 13:19 +0200, Goswin von Brederlow wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:
> 
> > Greetings,
> >
> > I'm adopting libffm, and noticed that it has the erroneous soname of
> > libffm.so.0.  Since the library interface has changed on just about
> > every upgrade, it should really be libffm.so.0.28.
> >
> > On the other hand, the interface has only changed once since it was made
> > a Debian package, so libffm.so.1 sort of makes sense.  But this is
> > incompatible with upstream's name.
> >
> > So I'd like to leave the package name as libffm1(-dev), but change the
> > soname.  Packages won't need to change dependencies, but binaries built
> > against it will need to relink since libffm.so.0 will no longer exist.
> > As far as I know, the only package affected is illuminator, which I
> > maintain (hence my adoption, as it was headed for the trash bin).
> >
> > Any comments/objections?
> >
> > Thanks,
> >
> > -Adam
> 
> Why not rename the package and soname to libffm0.28(-dev) so they make
> sense and match up again?

You know, that makes sense.  If I'm going to change the soname, so
packages have to be rebuilt anyway, I really should change the package
name with it (policy may even require it).  (That should have been
obvious to me...)

Since it's not likely that people will want to install multiple versions
of the -dev package, I'll just make that libffm-dev.

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

libffm adoption/change of soname

[Adam C Powell IV]

Greetings,

I'm adopting libffm, and noticed that it has the erroneous soname of
libffm.so.0.  Since the library interface has changed on just about
every upgrade, it should really be libffm.so.0.28.

On the other hand, the interface has only changed once since it was made
a Debian package, so libffm.so.1 sort of makes sense.  But this is
incompatible with upstream's name.

So I'd like to leave the package name as libffm1(-dev), but change the
soname.  Packages won't need to change dependencies, but binaries built
against it will need to relink since libffm.so.0 will no longer exist.
As far as I know, the only package affected is illuminator, which I
maintain (hence my adoption, as it was headed for the trash bin).

Any comments/objections?

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HPaq cxx trouble

[Adam C Powell IV]

On Fri, 2005-04-22 at 00:23 -0700, Phil Carmody wrote:
> --- Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi Adam,
> > 
> > have seen the new ccc package in unstable. I am waiting for testing. The 
> > only thing that makes the user think it does not work: the link in the 
> > package description is invalid. If the download link in the package 
> > installer is also invalid you have a problem if you do not know where the 
> > compaq cc rpm can be found.
> 
> I've certainly hit that more than once in the past, it certainly is an
> annoyance.
> Is is possible to have the link in the package simply a stable .debian.org (or
> anyone else who can guarantee some kind of stability) URI which redirects to
> whatever is the correct current hp/compaq address for the rpms?
> 
> It requires a small amount of additional admin overhead, but the
> user-friendliness increase would far outweigh that.

That's not a bad idea, since HPaq keeps changing the URL (though I'm
pretty sure the current one in ccc is right).

I've also tried working through a few channels at HPaq to get permission
to distribute the libs and (encrypted) compilers, but everyone I've
worked with has run into administrative brick walls. :-(

I'll look into getting a people.d.o site and work through that.

Cheers,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HPaq cxx trouble

[Adam C Powell IV]

On Fri, 2005-04-22 at 02:05 +0100, Carlos Rodrigues wrote:
> Adam C Powell IV wrote:
> > Oh.  The error message made me think that "compaq" might be one of many
> > mangling styles supported, but it seems not.  Oh well, RIP CXX. :-(
> 
> I don't know, but if you really need to use CXX, maybe there is some way 
> to install some older binutils in parallel to the current ones, just to 
> support it (just guessing).
> But I guess at least a part of what's gained by using CXX (the math 
> part) can also be gained when using GCC, just by linking with cpml 
> (well, it does require adding an extra "#include " in the 
> code...). At least that's what I've seen in the few tests I've made 
> (with CCC in fact).

I don't really need cxx (as much as I used to), I just maintain its
installer package.

> > The good news: the CCC .deb now works again (in unstable, will be in
> > testing by the end of next week).
> 
> Hmm, I'm fairly new to Debian. I was unaware there were .debs for the 
> Compaq Compilers... (I rolled my own with alien and hat to jump through 
> hoops to make them work).

Indeed, the goal of the installer package is to avoid those hoops.  It
(theoretically) puts things in the right place, registers documentation
and shlibs, etc.

Cheers,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HPaq cxx trouble

[Adam C Powell IV]

Oops, you're right.  Sorry about that.  (I know I corrected that for the
cxx package, but of course, cxx doesn't work.)  Okay, filed a bug
report, will fix on next upload.

Thanks.

On Fri, 2005-04-22 at 21:21 +0200, Uwe Schindler wrote:
> This is using the URL from packages.debian.org:
> 
> [EMAIL PROTECTED]:~$ wget http://www.support.compaq.com/alpha-tools/
> --21:20:13--  http://www.support.compaq.com/alpha-tools/
> => `index.html'
> Auflösen des Hostnamen »www.support.compaq.com« 192.208.35.3
> Verbindungsaufbau zu www.support.compaq.com[192.208.35.3]:80... verbunden.
> HTTP Anforderung gesendet, warte auf Antwort... 404 Not Found
> 21:20:13 FEHLER 404: Not Found.
> 
> I think this is correct: 
> http://h18000.www1.hp.com/products/software/alpha-tools/

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

Re: HPaq cxx trouble

[Adam C Powell IV]

On Thu, 2005-04-21 at 12:55 +0100, Carlos Rodrigues wrote:
> Adam C Powell IV wrote:
> > retitle 175604 cxx's "compaq" mangling style not supported by binutils
> > severity 175604 grave
> > thanks
> > 
> > At some point in the past two years, binutils has stopped supporting the
> > "compaq" C++ name mangling style.  Therefore, cxx cannot be installed,
> > and cannot function once installed; this applies to 6.3.9.7-1 currently
> > in testing and my attempt to update to 6.5.9.31.
> > 
> > Does anyone know how this might be fixed?  I guess an approach is to get
> > an old binutils which worked and try to generate a patch, but I've no
> > idea what's involved there...
> 
> I don't know if there is something to fix. If GCC's C++ mangling 
> changed, it changed for a reason (not accidentally). This means that 
> CXX's days may be over.

Oh.  The error message made me think that "compaq" might be one of many
mangling styles supported, but it seems not.  Oh well, RIP CXX. :-(

The good news: the CCC .deb now works again (in unstable, will be in
testing by the end of next week).

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

HPaq cxx trouble

[Adam C Powell IV]

retitle 175604 cxx's "compaq" mangling style not supported by binutils
severity 175604 grave
thanks

At some point in the past two years, binutils has stopped supporting the
"compaq" C++ name mangling style.  Therefore, cxx cannot be installed,
and cannot function once installed; this applies to 6.3.9.7-1 currently
in testing and my attempt to update to 6.5.9.31.

Does anyone know how this might be fixed?  I guess an approach is to get
an old binutils which worked and try to generate a patch, but I've no
idea what's involved there...

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: woody->sarge upgrade trouble

[Adam C Powell IV]

On Thu, 2005-01-06 at 22:01 -0800, Steve Langasek wrote:
> On Thu, Jan 06, 2005 at 11:45:15AM -0500, Adam C Powell IV wrote:
> > I've run into two problems upgrading from woody to sarge.
> > Work-aroundable problems to be sure, but upgrade hitches nonetheless in
> > need of bug reports, and I don't know where to start.  (Not necessarily
> > Alpha issues, but noticed them on an alpha system, and not on i386.)
> 
> > First, perl and perl-modules upgraded without perl-base, such that a
> > package with install-docs in its pre- or postrm (libxml2-dev in this
> > case) can't find Basename.pm.  To fix this, I had to install perl-base
> > by hand and restart the upgrade.  This is pretty significant breakage,
> > but where to file the bug, perl, or apt, or ??
> 
> This is RC bug #278495.

Yup, that looks like the same behavior.  Thanks.

> > Second, menu reinstalled but was not configured prior to being used by a
> > prerm.  So when ghostview's update failed with:
> 
> > Removing ghostview ...
> > /var/lib/dpkg/info/ghostview.postrm: /usr/bin/update-menus: Permission 
> > denied
> > dpkg: error processing ghostview (--purge):
> >  subprocess post-removal script returned error exit status 1
> 
> > Again, where's the bug, and what's its nature?  Does menu need to be
> > configured right at install time, like many others?
> 
> I think this is generally considered to be a bug in the calling package; at
> least, the menu maintainer has stuck by this particular interface (i.e.,
> only setting update-menus executable when the package is configured),
> because there are a number of packages that use update-menus iff it's
> installed so they don't have to depend on menu.
> 
> Since this particular bug is caused by a *woody* version of a package
> calling update-menus, it would probably be a good idea to revisit this issue
> with the menu maintainer, however.  I would encourage you to file an RC bug
> against the menu package.

Okay, will do.

Thanks for the clarifications!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

woody->sarge upgrade trouble

[Adam C Powell IV]

Greetings,

I've run into two problems upgrading from woody to sarge.
Work-aroundable problems to be sure, but upgrade hitches nonetheless in
need of bug reports, and I don't know where to start.  (Not necessarily
Alpha issues, but noticed them on an alpha system, and not on i386.)

First, perl and perl-modules upgraded without perl-base, such that a
package with install-docs in its pre- or postrm (libxml2-dev in this
case) can't find Basename.pm.  To fix this, I had to install perl-base
by hand and restart the upgrade.  This is pretty significant breakage,
but where to file the bug, perl, or apt, or ??

Second, menu reinstalled but was not configured prior to being used by a
prerm.  So when ghostview's update failed with:

Removing ghostview ...
/var/lib/dpkg/info/ghostview.postrm: /usr/bin/update-menus: Permission denied
dpkg: error processing ghostview (--purge):
 subprocess post-removal script returned error exit status 1

Again, where's the bug, and what's its nature?  Does menu need to be
configured right at install time, like many others?

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

Re: X-Window System in 3.0r2

[Adam C Powell IV]

On Sun, 2004-04-25 at 09:47, benry wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sunday 25 April 2004 13:42, Gianluca Bonetti wrote:
> > Roman Rupp wrote:
> > > Hi,
> > >
> > > i want to install debian 3.0r2 (woody?) on my Alphastation 500/333MHz,
> > > and my problem is that when i come to tasksel during the installation
> > > sometimes i can choose x-window system to install and sometimes not. I
> > > have a Matrox Millenium 2 Card with 12 MB and this is a xfree86
> > > compatible card isn't it?
> >
> > tasksel sucks, use dselect instead and you will be very happy :)
> 
> use:
> 
> apt-get install x-window-system-core
> 
> instead and you will be much more happy :P
> p.s.
> in this way it won't install any window manager, so you'll need to do it by 
> hand later, for example:
> 
> apt-get install wmaker

[Incidentally, this is a good reason to use dselect instead of apt,
particularly during first install; also apt will miss important
Suggested packages like xfonts-base, and woody's apt doesn't even list
them...]

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: How to handle the -mieee SIGFPE problem in normal Debian packages

[Adam C Powell IV]

Greetings,

Here's a little m4 snippet you can stick into configure.in or .ac (from
my PETSc package's math-blaslapack.m4):

AC_DEFUN([ALPHA_MIEEE_CHECK],[
AC_CHECKING([whether -mieee is needed to avoid SIGFPE on divide by 
zero])
case $build/$CC in
alpha*/gcc* )
MIEEE_CFLAGS="-mieee"
AC_MSG_RESULT([yes])
;;
* )
MIEEE_CFLAGS=""
AC_MSG_RESULT([not needed])
;;
esac
AC_SUBST(MIEEE_CFLAGS)
])

Then you just add MIEEE_CFLAGS to CFLAGS, CXXFLAGS etc.

On Mon, 2004-02-09 at 12:18, Dominique Devriese wrote:
package konqueror
reopen 203722
thanks

Steve Langasek writes:

>> I'm currently looking at the following bug report
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203722 about a
>> frequent SIGFPE on an alpha machine.  I guess we all know the cause
>> of this bug, namely the non-standard alpha FPU semantics.

> Even if gcc will soon adopt a patch to make -mieee the default,
> there will be older versions of gcc around for a while.  This is a
> bug *now*, and there's no reason not to add the -mieee explicitly to
> the compiler flags for the time being: it will just become a no-op
> later once this is the gcc default.

I guess I'm in the minority (based on prior discussions on
debian-alpha), but IMHO the above is a better way to work around this
issue than making slower performance the default... :-)

Cheers,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: CCC/CXX installation

[Adam C Powell IV]

On Thu, 2003-12-04 at 14:27, Falk Hueffner wrote:
> Phil Carmody <[EMAIL PROTECTED]> writes:
> 
> > --- John Goerzen <[EMAIL PROTECTED]> wrote:
> > > I noticed the same problem recently.  Go into the create-comp-config.sh
> > > file and move the -v so it comes after the -V {GCC_PATH} thing.
> > 
> > Yup, I tried that hack myself! It kinda-sorta seemed to work.
> >  
> > > Also, I hacked it to call gcc instead of gcc-2.95.  You may need to make
> > > a few other minor adjustments to GCC_PATH.
> > 
> > OK, I've not noticed anything that I can be sure is caused by that yet, but 
> > I
> > am unable to build what I was trying to build :-(

Are these things that the ccc .deb can change so that it works?  I can't
seem to get create-comp-config.sh to work, even trying these edits.

If you can get it to work, please file a bug against ccc, if possible
with a patch.

> > ccc is complaining that 
> > <<<
> > ./compile speed.c
> > cc: Error: /usr/include/bits/pthreadtypes.h, line 71: Invalid declarator.
> > (declarator)
> >   __pthread_cond_align_t __align;
> > -^
> > >>>
> > 
> > Which is being pulled in via .
> 
> See bug #212233. As a workaround, rename __align to __align_ or
> whatever.

Likewise, can the ccc .deb assist in this workaround?
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: What happened to ffm?

[Adam C Powell IV]

On Tue, 2003-11-18 at 09:59, Adam C Powell IV wrote:
> Has libffm been orphaned and removed?

D'oh!  libffm-dev is provided by libffm1-dev.  Sorry about that.

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

What happened to ffm?

[Adam C Powell IV]

Has libffm been orphaned and removed?  If so, I want to adopt it...  Is
the latest version in woody, or was it upgraded since 2001?

[Yes, there's cpml and cxml, but AFAIK they don't have nice vectorized
things like dsqrtiv etc.]

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: using compaq fortran for linux on alpha

[Adam C Powell IV]

On Mon, 2003-11-03 at 09:03, Roberto Bernetti wrote:
> Hi
> I've installed Debian 3 on a personal workstation 500au with minor problems I 
> hope you can help to solve:
> 1)  The distribution CD's didn't contain some packages as LyX and Maxima but 
> on the official site they appear to be included
> 2) the symboic link of the BLAS library were not correct, they were 
> /usr/lib/libblas.so.2 instead of /usr/lib/libblas.so). 

I think this is deliberate, you have to install blas-dev to get
libblas.so.  But the soname is always libblas.so.2, whether you use
blas-dev or any of the ATLAS implementations.

> 3)Then I downloaded the compaq fortran for linux but after transforming the 
> *.rpm packages in *.deb I installed it using 
> dpkg -i *.rpm
> when I run the compiler I get:
> 
> /usr/lib/libcpml.so: file not recognized: File truncated
> collect2: ld returned 1 exit status
> fort: Severe: Failed while trying to link.
> make: *** [nlswe2d] Error 1
> 
> Could be the reason the installing of the library cpml after the compiler 
> packages?

The "recommended" way of doing this is to get the RPMs, then install the
installer .debs, which will prompt you for the location of the RPMs. 
Unfortunately, you have to get an installer .deb whose version exactly
matches the RPM.  But when you do this, it sets up lots of nice things
like doc-base registry of documentation, etc.

I have a contact at HP working on letting Debian distribute the actual
libs in the .debs for cpml, cxml, libots and cfalrtl, and encrypted RPMs
in the .debs for cfal, ccc and cxx.  So you can just "apt-get install
cfal" and, if you have the license key, just provide it and everything
will just install.  I'm not expecting anything real soon (it's been
about three months so far), but these may be ready in time for sarge...

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: return to testing - or stable?

[Adam C Powell IV]

Hello,

On Wed, 2003-10-29 at 14:39, Peter Watkinson wrote:
> Hi there,
> 
> I've sort of screwed up one my installs on unstable so now neither KDE or
> Gnome desktops work is there a fairly straightforward way I can return the
> system to either Testing or stable using apt-get without having to do a full
> re-install?

I'm finding on ARM that when GNOME goes through a major transition (e.g.
2.2-2.4 as now), the buildds sometimes attempt to build stuff in the
wrong order, so just getting the source and building it fixes the
problem.

apt-get source nautilus
cd nautilus-[version]
dpkg-buildpackage -rfakeroot -B -uc

Then when it complains about missing build-depends, you install those;
if the right packages/versions aren't available, you build those from
source, etc.  And if it doesn't build after all that, you file a bug.

Of course, this does take time...

(Oh - and yes, GNOME 2.4 runs quite nicely on a 200 MHz StrongARM. :-)
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: initrd/cramfs/etc (was Re: srm nightmare, milo & kernel future questions)

[Adam C Powell IV]

On Wed, 2003-06-18 at 21:48, Nick Ntarmos wrote:
> Hi there.
> 
> On Wed, Jun 18, 2003 at 06:00:08PM -0700, Chris Hecker wrote:
> > Okay, so I downloaded the 2.4.21 kernel source from kernel.org.  I upgrade 
> > gcc to build it.  I make the initrd image with mkinitrd.  The kernel won't 
> > mount it and panics.  I read the net for a while, finding that mkinitrd 
> > makes a cramfs image, but debian kernels are patched to allow initrd and 
> > the generic kernel source is not.  Herbert is quoted as saying you can just 
> 
> That's not true. Any decent linux kernel can support an initrd.

I think you're incorrect.  I've had the same problem on i386 for some
time.  Compiling a stock kernel with the Debian config never works
because of this initrd problem.

And the Debian kernel sources are quite different from stock sources. 
IMHO, this is not the way this should be done: the .tar.bz2 should
contain the pristine upstream (stock) source just like .orig.tar.gz, and
patches should ship separately.

So where can we get the Debian patches, aside from "diff -urN linux
kernel-source-2.4.20"?

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: SIGFPE and -mieee

[Adam C Powell IV]

On Tue, 2003-06-17 at 13:04, Helge Kreutzmann wrote:
> Hello,
> On Tue, Jun 17, 2003 at 11:10:01AM -0400, George France wrote:
> > Everything built for alpha should use -mieee.  It is not need on most other 
> > architrectures, but it is almost a requirement for the alpha architecture.  
> 
> Sure, since all other (popular) architectures implement the IEEE
> standard.
> 
> > This has been a subject of lengthy discussion on several mailing list.
> 
> Well, which ones? I can't remember such discussions with the outcome
> you mention on either debian alpha nor redhat-axp. 
> 
> One of the reasons for the speed of alpha is the ability to calculate
> fast, eliminating often unnecessary checks. So why should we do away
> this advantage by re-inserting those checks on a broad basis again
> when compiling software?

I agree.  For some software, it will be necessary to do this, but to
intentionally hobble everything by default will hurt the performance of
code which I rely on to be fast, such as ATLAS.

If someone runs into SIGFPE, that person should file a bug against the
package mentioning the -mieee fix described above.  IMHO, this is not a
good thing to force upon all of Debian on alpha.

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: more on Ccc install problem (fixed it)

[Adam C Powell IV]

Timothy Timmons wrote:
Oops. I just realized it's gcc-3.3 that won't take -v and -V at the
same time. gcc-2.95 WILL fine though. I simply changed the symlink
in /usr/bin for gcc to point to gcc-2.95 and it ran correctly!
So now it all works?
I wonder what the problem could have been.  The postinst script should 
properly use the full gcc-2.95 path when invoking create-comp-config.sh...

For future reference, instead of purging and reinstalling, you should be 
able to just do "dpkg-reconfigure ccc".
--

-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: ccc install

[Adam C Powell IV]

Hello,
They usually get back to me within a day or two, I'd be surprised if you 
didn't already have the key by now...

Richard Fillion wrote:
OK Now i see what i was doing wrong on their website.  I now have the
deb, but no password.  I applyed for the educational license, and am
waiting for that.  How long does that usually take?  And btw...i dont
mind at all if  you cc to the mailing list.  I'm sure i'm not the only
person out there who has this problem.
Richard Fillion
[EMAIL PROTECTED]
On Fri, 2003-05-09 at 11:28, Adam C Powell IV wrote:
 

The ccc .deb description says:
Compaq does not allow redistribution of their software. Therefore, this
package requires the user to fetch the ccc RPM archive separately
from their web site at http://www.support.compaq.com/alpha-tools/ .  When you
install this package you will be guided through that process.
When I go through that page, then click through "Enhtusiast and 
Education" license and fill in the fields, it sends me to 
ftp://ftp.compaq.com/pub/products/linuxdevtools/latest/downloads.html 
which has (encrypted) 6.5.9.001-6 (not 6.5.9.31 like I said earlier, 
that was the cxx version).

I hope that works for you, please let me know.
[BTW, do you mind that I replied back to the list last time?]
Richard Fillion wrote:
   

ftp://ftp.compaq.com/pub/products/C-Cxx/linux/compaq_c_v62/docs/ccc/download_files_.htm
That provides 
ccc-6.5.6.002-1.alpha.rpm

unstable ccc wants:
ccc-6.5.9.001-6.alpha.rpm
Will it make a difference?
Richard Fillion
[EMAIL PROTECTED]
On Thu, 2003-05-08 at 22:53, Adam C Powell IV wrote:
 

Richard Fillion wrote:
   

Maintainer: Adam C. Powell, IV <[EMAIL PROTECTED]>  
Architecture: alpha
Version: 6.2.9.506-4

This package installs the file ccc-6.2.9.506-1.alpha.rpm from the above
website.
ccc-6.4.9.005-1.alpha.rpm<--- thats what i had to download from the
website.
 

As we say in New York, "Akhaa!"  The website and sid/sarge .deb should 
be 6.5.9.31, I think the sid/sarge .deb is installable in woody, since 
it only depends on gcc-2.95.
   

Holy crap, you're the maintainer, i guess my problem is in good hands
then. eheh.
 

Well, I like to think so, but the truth is that I'm just the guy who 
volunteered, there are many people on this list who know quite a bit 
more than I.
   

I think the problem is an incompatibility between those 2
rpms.  I'm doing all of this on Debian Woody, should i try sarge's "ccc"
or sid's?
 

Both (sid and sarge are both 6.5.9.31).
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc install

[Adam C Powell IV]

Richard Fillion wrote:
Maintainer: Adam C. Powell, IV <[EMAIL PROTECTED]>  
Architecture: alpha
Version: 6.2.9.506-4

This package installs the file ccc-6.2.9.506-1.alpha.rpm from the above
website.
ccc-6.4.9.005-1.alpha.rpm<--- thats what i had to download from the
website.
As we say in New York, "Akhaa!"  The website and sid/sarge .deb should 
be 6.5.9.31, I think the sid/sarge .deb is installable in woody, since 
it only depends on gcc-2.95.

Holy crap, you're the maintainer, i guess my problem is in good hands
then. eheh.
Well, I like to think so, but the truth is that I'm just the guy who 
volunteered, there are many people on this list who know quite a bit 
more than I.

I think the problem is an incompatibility between those 2
rpms.  I'm doing all of this on Debian Woody, should i try sarge's "ccc"
or sid's?
Both (sid and sarge are both 6.5.9.31).
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc install

[Adam C Powell IV]

Well, "works" is relative, apparently from your description it doesn't 
quite work.

Which version of ccc did the .deb ask for, and which do you have?  And 
which version of the ccc deb were you trying to install?  The script 
does a couple of things to make this work which are somewhat 
non-trivial, and could have solve the problem you are seeing.

Richard Fillion wrote:
It may be ancient, but it "works".  I tried "apt-get install ccc" and
followed the instructions, but... seeing how i could not get the exact
version number for ccc that it wanted, i dont think it installed
properly.  I renmaed the rpm to match what the script was looking for,
but then afterwards it was complaining about a lack of
/usr/doc/ccc-x.x.x .  So i figured i'd try out other ways.
Richard Fillion
[EMAIL PROTECTED]
On Thu, 2003-05-08 at 12:59, Adam C Powell IV wrote:
 

Richard Fillion wrote:
   

I installed ccc on my box to see if i could get better performance out
of some apps with it instead of gcc.  I followed these instructions :
http://www.geocrawler.com/archives/3/241/2001/3/0/5451555/
 

This is ancient, you can now "apt-get install ccc" and follow the 
instructions so its script installs the ccc RPM "properly".
   

And ccc now runs, but i cant compile anything. 

[EMAIL PROTECTED]:~/dev/C$ cat helloworld.c 
 #include 
 main(){
  printf("Hello World\n");
 }
[EMAIL PROTECTED]:~/dev/C$ ccc helloworld.c -o helloworld
cc: Severe: /usr/include/stdio.h, line 34: Cannot find file 
specified in #include directive. (noinclfilef)
# include 
--^

 

I haven't seen this problem, but YMMV.
Note that I can't get cxx to work in unstable, but that shouldn't affect 
ccc.

Please let me know if uninstalling the aliened rpm and reinstalling via 
the .deb works.

--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc install

[Adam C Powell IV]

Richard Fillion wrote:
I installed ccc on my box to see if i could get better performance out
of some apps with it instead of gcc.  I followed these instructions :
http://www.geocrawler.com/archives/3/241/2001/3/0/5451555/
This is ancient, you can now "apt-get install ccc" and follow the 
instructions so its script installs the ccc RPM "properly".

And ccc now runs, but i cant compile anything. 

[EMAIL PROTECTED]:~/dev/C$ cat helloworld.c 
  #include 
  main(){
   printf("Hello World\n");
  }
[EMAIL PROTECTED]:~/dev/C$ ccc helloworld.c -o helloworld
cc: Severe: /usr/include/stdio.h, line 34: Cannot find file 
specified in #include directive. (noinclfilef)
# include 
--^

I haven't seen this problem, but YMMV.
Note that I can't get cxx to work in unstable, but that shouldn't affect 
ccc.

Please let me know if uninstalling the aliened rpm and reinstalling via 
the .deb works.

Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Relocation errors with g++-3.2

[Adam C Powell IV]

Falk Hueffner wrote:
Mats Rynge <[EMAIL PROTECTED]> writes:
 

main.o(.rodata+0x8b4):itimerspec/format.h:380: relocation truncated to fit: 
GPREL32 *UND*

This is only happening on Alpha and only with g++-3.2 (2.95 works
fine). Does anyone have some insight in what is causing this?
   

Jump tables relocated against symbols emitted mutiple times, where the
corresponding copy was dropped. See
http://gcc.gnu.org/ml/gcc/2003-04/msg00191.html
As a workaround, try to find out which switch statement causes it and
don't inline the function (a function complex enough to contain a
switch statement probably shouldn't be inline, anyway).
 

Just curious, gcc bugs aside, what's wrong with inlining functions with 
switch statements?  (I've done it a couple of times...)  Does switch 
take so much time that it's not worth saving the function call?

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Xfree

[Adam C Powell IV]

Helge Kreutzmann wrote:
The graphics card is a Crucial ATI Radeon 8500 AGP card.
   

Not supported by woody, I assume.
Right, my 8500 on Athlon requires X 4.2.1.  The apt line for i386 is:
   deb http://people.debian.org/~blade/woody/i386/ ./
and you should be able to get sources from somewhere in there that will 
build on alpha.

[To do that, once you have the orig.tar.gz, the .diff.gz and the .dsc, 
and have installed the fakeroot package:

   dpkg-source -x file.dsc [e.g. foo_1.2.3-4.dsc]
   cd dir-version [e.g. foo-1.2.3]
   dpkg-buildpackage -rfakeroot -us -uc
I prefer this to "fakeroot debian/rules binary" because it tests for 
build-depends and lets you know what's missing.]

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: network problems

[Adam C Powell IV]

Donald D. Daniel wrote:
Ever since I loaded Debian 3.0 on my machine I have
not been able to reach about 5% of the internet.
Just a guess: do the alpha kernels have ECN disabled?  Try:
less /proc/sys/net/ipv4/tcp_ecn
Does it give a 1?  If so, echo 0 > that file, and to make it permanent, 
add the following to /etc/sysctl.conf:

net/ipv4/tcp_ecn=0
(The i386 kernels have this disabled by default.)
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: ccc

[Adam C Powell IV]

Falk Hueffner wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:
 

Hmm, just compiled with std::cout and std::endl, and got even more
undefined symbols...
Can you tell me the steps you went through to get this installed?  I
know you didn't (merely) use the .deb, because that would have put
paths to 2.95.4 in your comp.config.
   

Hm, I don't really remember, I guess I used alien and then kicked it
till it worked :) Maybe your binutils is too old? I have
2.13.90.0.18-1.2.
Nope, same binutils.  I'm afraid my interest in C++ is not sufficient to 
keep kicking just now.  So the three bugs against the cxx .deb will 
likely remain open for at least a couple of months unless someone else 
looks into it (but I'll be sure to get this done before sarge freezes). :-(

Thanks for the info, it's encouraging to know it works for someone!
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc

[Adam C Powell IV]

Falk Hueffner wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:
 

Aha, I had an identical file minus the -std strict_ansi.  But with
those, it gives me compiler errors:
zither:/# cxx /tmp/bye.C -o /tmp/bye
cxx: Error: /tmp/bye.C, line 4: identifier "cout" is undefined
 cout << "Hello world" << endl;
--^
cxx: Error: /tmp/bye.C, line 4: identifier "endl" is undefined
 cout << "Hello world" << endl;
---^
cxx: Info: 2 errors detected in the compilation of "/tmp/bye.C".
zither:/# more /tmp/bye.C
#include 
int main()
{
 cout << "Hello world" << endl;
 return 0; }
   

Well, that's a correct message, g++ will tell you the same :)
Really??  Again, I'm not really a C++ person, but have seen this syntax 
without std:: lots of times, and it's in the create-comp-config.sh 
script provided by cxx.  Oh well, must not have been ANSI-compliant 
code; I'm happy to have the .deb patch create-comp-config.sh before 
running it.

You need std::cout and std::endl. And I think you really need -std
strict_ansi in comp.config to get it to work.
 

Hmm, just compiled with std::cout and std::endl, and got even more 
undefined symbols...

zither:/# cxx /tmp/bye.C -o /tmp/bye
bye.o(.text+0x18): undefined reference to 
`__7put__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFZ1Z_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x20): undefined reference to 
`__7put__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFZ1Z_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x20): undefined reference to 
`__7put__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFZ1Z_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x30): undefined reference to 
`__7flush__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFv_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x34): undefined reference to 
`__7flush__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFv_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x34): undefined reference to 
`__7flush__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFv_RQ2_3std27basic_ostream__tm__7_Z1ZZ2Z'
bye.o(.text+0x70): In function `main':
: undefined reference to 
`__7__CPR123ls__tm__30_Q2_3std20char_traits__tm__2_c__3stdFRQ2_3std25basic_ostream__tm__5_cZ1ZPCc_RQ2_3stdJ57J'
bye.o(.text+0x80): In function `main':
: undefined reference to 
`__7__CPR123ls__tm__30_Q2_3std20char_traits__tm__2_c__3stdFRQ2_3std25basic_ostream__tm__5_cZ1ZPCc_RQ2_3stdJ57J'
bye.o(.text+0x80): In function `main':
: undefined reference to 
`__7__CPR123ls__tm__30_Q2_3std20char_traits__tm__2_c__3stdFRQ2_3std25basic_ostream__tm__5_cZ1ZPCc_RQ2_3stdJ57J'
bye.o(.text+0x74): In function `main':
: undefined reference to `__7cout__3std'
bye.o(.text+0x90): In function `main':
: undefined reference to 
`__7__CPR183ls__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFPFRQ2_3std27basic_ostream__tm__7_Z1ZZ2Z_RQ2_3stdJ78J_RQ2_3stdJ78J'
bye.o(.text+0x98): In function `main':
: undefined reference to 
`__7__CPR183ls__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFPFRQ2_3std27basic_ostream__tm__7_Z1ZZ2Z_RQ2_3stdJ78J_RQ2_3stdJ78J'
bye.o(.text+0x98): In function `main':
: undefined reference to 
`__7__CPR183ls__Q2_3std52basic_ostream__tm__31_cQ2_3std20char_traits__tm__2_cFPFRQ2_3std27basic_ostream__tm__7_Z1ZZ2Z_RQ2_3stdJ78J_RQ2_3stdJ78J'

Can you tell me the steps you went through to get this installed?  I 
know you didn't (merely) use the .deb, because that would have put paths 
to 2.95.4 in your comp.config.

Thanks for your help!
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc

[Adam C Powell IV]

Falk Hueffner wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:
 

One warning though: since gcc became gcc-3.2, I haven't been able to
build a working cxx.  It must be trying to call gcc, which is 3.2,
but cxx's name mangling is incompatible with 3.2 so there are always
missing symbols (like cout). 
   

Hmm, works for me[tm] on sid with cxx cxx-6.5.9.31. My comp.config
looks like this:
-Wl,--demangle=compaq -tk -h/usr/bin -B -tl -h/usr/bin -B -ts 
-h/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin -B_rh70 -D__DECCXX_LIBCXX_RH70 
-D__linux_dist_debian -SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx 
-SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include -SD/usr/local/include 
-SD/usr/lib/gcc-lib/alpha-linux/3.2.2/include -SD/usr/include  | -SysIncCxxDir 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx -SysIncDir 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include   -SysIncDir 
/usr/local/include -SysIncDir /usr/lib/gcc-lib/alpha-linux/3.2.2/include 
-SysIncDir /usr/include -L/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/lib   
-L/usr/lib/gcc-lib/alpha-linux/3.2.2 -std strict_ansi
(Hmm, 3.2.2 should really be 3.2.3. Still works :)
 

Aha, I had an identical file minus the -std strict_ansi.  But with 
those, it gives me compiler errors:

zither:/# cxx /tmp/bye.C -o /tmp/bye
cxx: Error: /tmp/bye.C, line 4: identifier "cout" is undefined
 cout << "Hello world" << endl;
--^
cxx: Error: /tmp/bye.C, line 4: identifier "endl" is undefined
 cout << "Hello world" << endl;
---^
cxx: Info: 2 errors detected in the compilation of "/tmp/bye.C".
zither:/# more /tmp/bye.C
#include 
int main()
{
 cout << "Hello world" << endl;
 return 0;   
}

Funny, because at the top of cxx's iostream.hxx it says something about 
can't define -D__STD_STRICT_ANSI and use iostream, but that error 
doesn't show up.  Without -std strict_ansi, it gave:

# cxx -v /tmp/bye.C -o /tmp/bye
comp.config contains:  -Wl,--demangle=compaq -tk -h/usr/bin -B -tl 
-h/usr/bin -B -ts -h/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin -B_rh70 
-D__DECCXX_LIBCXX_RH70 -D__linux_dist_debian 
-SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx 
-SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include 
-SD/usr/local/include -SD/usr/lib/gcc-lib/alpha-linux/3.2.3/include 
-SD/usr/include  | -SysIncCxxDir 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx -SysIncDir 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include   -SysIncDir 
/usr/local/include -SysIncDir /usr/lib/gcc-lib/alpha-linux/3.2.3/include 
-SysIncDir /usr/include -L/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/lib   
-L/usr/lib/gcc-lib/alpha-linux/3.2.3

/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/lnxexx -D__LANGUAGE_C__ 
-D__unix__ -D__alpha -D_SYSTYPE_BSD -D_LONGLONG -D__arch64__ 
-D__LANGUAGE_C -D__ELF__ -D__alpha__ -D__linux -D__linux__ -D__unix 
-D__signed__=signed -D__const__=const -D__volatile__=volatile -g0 -O2 
-preempt_module -model ansi -D__DECCXX_LIBCXX_RH70 -D__linux_dist_debian 
-SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx 
-SD/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include 
-SD/usr/local/include -SD/usr/lib/gcc-lib/alpha-linux/3.2.3/include 
-SD/usr/include -v 
-I/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx 
-I/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx_cname 
-I/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include/cxx 
-I/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/include -I/usr/local/include 
-I/usr/lib/gcc-lib/alpha-linux/3.2.3/include -I/usr/include -o bye.o 
/tmp/bye.C

These macros are in effect at the start of the compilation.
- -- --- -- -- -- --- - -- --- 
-D__linux_dist_debian -D__DECCXX_LIBCXX_RH70 -D__volatile__=volatile
-D__const__=const -D__signed__=signed -D__linux -D__ELF__ -D__LANGUAGE_C
-D__LANGUAGE_C__ -Dunix -D__linux__ -D_SYSTYPE_BSD -D__unix__ -D__unix
-D__INITIAL_POINTER_SIZE=0 -D__arch64__ -D__IEEE_FLOAT -D__Alpha_AXP
-D_LONGLONG -D__alpha__ -D__alpha -D__ALPHA -D__DECCXX_VER=60590031
-D__MODEL_ANSI -D__STD_ANSI -D__STDC__ -D__IMPLICIT_INCLUDE_ENABLED 
-D__STDNEW
-D__X_FLOAT=0 -D__PRAGMA_ENVIRONMENT -D__DECCXX -D__EDG_VERSION__=245
-D__EDG__ -D__IMPLICIT_USING_STD -D__RTTI -D__EXCEPTIONS 
-D__GLOBAL_ARRAY_NEW
-D__BOOL_IS_A_RESERVED_WORD -D_BOOL_EXISTS -D__WCHAR_T -D_WCHAR_T
-D__cplusplus=199711L -D__TIME__="02:08:29" -D__DATE__="Mar 23 2003"

/usr/bin/ld -o /tmp/bye --demangle=compaq 
-L/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/lib 
-L/usr/lib/gcc-lib/alpha-linux/3.2.3 -O1 -m elf64alpha -G 8 -rpath 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/ 
-L/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/ -dynamic-linker 
/lib/ld-linux.so.2 /usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/crt1.o 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/crti.o 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/crtbegin.o 
/usr/lib/compaq/cxx-6.5.9.31/alpha-linux/bin/_mainma.o bye.o 
-lcx

Re: ccc

[Adam C Powell IV]

Joakim Roubert wrote:
Hi!
Today I gave the install of ccc another shot; I've failed so far.
(I suck.)
The latest rpm I found at Compaq was the ccc-6.5.6.002-1.alpha.rpm.
Running apt-get ccc for stable and unstable gives med the
ccc_6.5.9.001-1_alpha.deb, which prompts for ccc-6.5.9.001-1.alpha.rpm
I tried to rename the RPM in order to cheat the system, thinking it
wouldn't work. It didn't.
Before I try to make a manual workaround, is there a place to get a
ccc-6.5.9.001-1.alpha.rpm?
The package description gives: http://www.support.compaq.com/alpha-tools/
Hmm, clicking on "Compaq C" leads one down a trail which talks about 
version 6.2...

OTOH, clicking on the "Enthusiast & Education Program" (on the left-side 
bar) gives me a registration page, and then a downloads page with a link 
to "ccc-6.5.9.001-6.alpha.rpm.crypt".

Last time I tried to pump ccc in my system I made .deb-packages with alien
-c as said might work on this list, but when installed, ccc complained
about not finding correct libraries and stuff.
Does anybody have some tricks or advice here?
Hmm.  This is the stuff that the .deb does, but there are a lot of 
symlinks, script runs, etc. involved.  I guess the best advice I can 
give is just to follow the procedure in the postinst: use rpm2cpio to 
unpack, copy in as postinst does, and run the scripts that postinst 
does.  I think it should work...

Oh wait, just go to http://lyre.mit.edu/~powell/compaq/ and the 
6.5.6.002-1.deb binary is there.  (That should be in the 
README.Debian... but there is none!  Sorry about that.  I should stick a 
note in the templates file.)

So if you can't get 6.5.9, that should solve your problem with 6.5.6.
One warning though: since gcc became gcc-3.2, I haven't been able to 
build a working cxx.  It must be trying to call gcc, which is 3.2, but 
cxx's name mangling is incompatible with 3.2 so there are always missing 
symbols (like cout).  I've tried to do several things, like forcing it 
to use gcc-2.95, but it still calls "gcc" which is 3.2, and doesn't want 
to be convinced to do otherwise.  So cxx on unstable right now is dead, 
for all practical purposes, until someone at Compaq -er- HP decides to 
make it work on 3.2 -- or make the gcc call configurable.  (I suppose 
you could work-around using a diversion to make gcc be 2.95 again, but 
that would be ugly.)  I can't see how this might give you any trouble 
with ccc, but it might...

Ah, the joys of closed-source software!
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: ccc

[Adam C Powell IV]

Adam C Powell IV wrote:
Package: ccc
Joakim Roubert wrote:
Hi!
What exactly do the ccc-debian wrappers do?
I downloaded ccc-6.5.6.002, and wanted to install it; the ccc debian
package wants some older version, though... I tried to trick it by
renaming the file, but somehow that didn't work.
Well, I tried to install the rpm:s directly, but that was apparently not
the best thing to do...
Does anybody have an idea how I best install ccc here?
D'oh, another outdated installer .deb...  Sorry about that.
Hmm, just went to the download site, and the version of C available is 
6.5.9.001-6, which is what the (unstable/sarge) .deb has supported since 
last October...  Seems you have an out-of-date .rpm.

I'm not certain the sarge .deb works on woody though.  Would you be 
interested in testing it?

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: simple firewall for masquerade

[Adam C Powell IV]

Joakim Roubert wrote:
On Tue, 25 Feb 2003, Adam C Powell IV wrote:
 

That is, does it not auto-detect the EXTERNAL and INTERNAL interfaces
correctly?
   

It seems that it gets eth0 (my external) as EXTERNAL and then eth1 (my
internal) as INTERNAL, but I'm not sure. How can I confirm this?
I don't know, maybe sticking some echo statements into the script...
Which version of ipmasq are you using?  Woody has 3.5.10, can't help you
with anything higher.  (And I don't really know much about the version
in woody -- except that it works for me.)
   

Now I use ipmasq 3.5.11. It seems to start up properly and so on, and the
computer attached has the same settings as when I hade my firewall running
under RedHat (so I reckon that config is alright). Then I started checking
once more if there really wasn't something I had forgotten to put into the
kernel. The documentation says:
   * `CONFIG_NETFILTER'
   * `CONFIG_IP_NF_TABLES'
   * `CONFIG_IP_NF_CONNTRACK'
   * `CONFIG_IP_NF_NAT'
   * `CONFIG_IP_NF_TARGET_MASQUERADE'
And here I find a strange thing; I don't have the option
CONFIG_IP_NF_TABLES in my 2.4.20 config file. Instead, there is a
CONFIG_IP_NF_IPTABLES (could that be the same?), which I have compiled in
the kernel. Thus, I have the following in the current kernel:
CONFIG_IP_NF_IPTABLES=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
It still doesn't work, though... :(
You also need ipchains (or rather, the ipchains-compatible front-end to 
netfilter), as that's what ipmasq uses -- at least, that's what 3.5.10 
uses.  All of the stock Debian kernels seem to have everything needed...

Again, that's all I know -- you might consider emailing the author.
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: simple firewall for masquerade

[Adam C Powell IV]

Joakim Roubert wrote:
On Fri, 21 Feb 2003, Adam C Powell IV wrote:
 

apt-get install ipmasq
   

What does your /etc/ipmasq/rules/*.rul|def-files look like?
According to dpkg -L there should be some files installed in
/etc/ipmasq/rules, but I get none. In /usr/share/doc/ipmasq/examples I
find some stuff though, but trying them out I don't get it working.
I'm sorry to hear that.  I've been running successfully on PPC and ARM, 
potato and woody... are you using sid?

Except for the files copied from the exampels in "stronger" I made a file
A01interfaces.rul as said in the documentation:
octavia:/etc/ipmasq/rules# cat A01interfaces.rul
# Defines some basic stuff for the IP masquerade.
EXTERNAL="eth0 eth0:0"
INTERNAL="eth1 eth1:0"
(I hope this is not a totally FUBAR misunderstanding by me)
Is the normal /etc/ipmasq/rules/A01interfaces.def not working for you? 
That is, does it not auto-detect the EXTERNAL and INTERNAL interfaces 
correctly?

Trying the examples amongst the ordinary ones I get this:
/usr/sbin/ipmasq: ipnm_cache: command not found
In what package can I get ipnm_cache?
"grep cache /usr/sbin/ipmasq" gives nothing, so I don't see where it's 
calling that.

"zgrep ipnm debian/dists/woody/Contents-i386.gz" gives nothing (nor 
alpha), so no woody package has such a file, even on i386 -- it's not an 
alpha-specific issue.

Which version of ipmasq are you using?  Woody has 3.5.10, can't help you 
with anything higher.  (And I don't really know much about the version 
in woody -- except that it works for me.)

That's what I know,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: ccc

[Adam C Powell IV]

Package: ccc
Joakim Roubert wrote:
Hi!
What exactly do the ccc-debian wrappers do?
I downloaded ccc-6.5.6.002, and wanted to install it; the ccc debian
package wants some older version, though... I tried to trick it by
renaming the file, but somehow that didn't work.
Well, I tried to install the rpm:s directly, but that was apparently not
the best thing to do...
Does anybody have an idea how I best install ccc here?
D'oh, another outdated installer .deb...  Sorry about that.
Not that this helps you now, but I will get to it when I have time, 
likely in about 2-3 weeks.

[Note: PLEASE remove the BTS submit address if you reply.]
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: simple firewall for masquerade

[Adam C Powell IV]

Joakim Roubert wrote:
Hi!
I have a laptop that I usually attach to my alpha, which is connected to
the internet. Before (running RH) I had the most simple example script of
a firewall that I could find in the HOWTO:s, since this did masquerade for
me.
Now, running Debian, I have all thiss netconf with all the rules and
everything. Well, I don't need a very advanced firewall or so, I just need
the laptop to be masqueraded.
Does anybody have a hint on the easiest way to do this?
apt-get install ipmasq
It uses ipchains (or its front-end in 2.4), and installs an init.d 
script which automatically determines at boot time which interface is on 
the net, and sets up rules accordingly.  Fully automatic everything. 
Firewall rules are pretty conservative, but very customizable, and I've 
never need to open anything up -- its best to err on the conservative 
side right?

Ain't Debian great?
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: (re)compiling debian packages with ccc

[Adam C Powell IV]

Bas Zoetekouw wrote:
Hi Ted!
You wrote:
 

It was my (perhaps ignorant?) understanding that GCC3.2 closed the gap (at
least made the gap a lot smaller) between GCC and CCC.  Am I wrong?  (I have
yet to test this, however, as I don't have GCC3.2 working on my alpha.)
   

I'm not sure if the gap has become smaller, but ccc still generated code
that is a lot faster than gcc-3.2.
For example, take a look at these results from SCIbench
(http://math.nist.gov/scimark2), generated on an quadruple-proc EV67
machine (running Tru64 Unix btw, not Linux):
Compaq C compiler, V6.4-014 
CFLAGS = -arch ev67 -fast -O4
| Composite Score:  195.47
| FFT Mflops:   207.66(N=1024)
| SOR Mflops:   235.00(100 x 100)
| MonteCarlo: Mflops:53.33
| Sparse matmult  Mflops:   177.93(N=1000, nz=5000)
| LU  Mflops:   303.42(M=100, N=100)

GNU C compiler, V3.2.1
CFLAGS = -O3 -fomit-frame-pointer -ffast-math -mcpu=ev67
| Composite Score:  137.18
| FFT Mflops:   188.23(N=1024)
| SOR Mflops:   167.08(100 x 100)
| MonteCarlo: Mflops:49.71
| Sparse matmult  Mflops:   163.85(N=1000, nz=5000)
| LU  Mflops:   117.03(M=100, N=100)
 

I don't know much about the others, but LU is likely to be this 
different because ccc links to cxml with Kazushige Goto's assembler 
BLAS.  Those have always been free, and are also in ATLAS now, so at 
least for that benchmark, we can do as well with free software.

Or if both LUs are compiled from code, well, then we can do better than 
both with free software, as Goto's BLAS blow away anything compiled.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: LX164 -IDE problems - thanks

[Adam C Powell IV]

T. Weyergraf wrote:
Since IDE drives of large capacity are cheap nowadays, i'd
like to use them in the NFS-server. For that, I plan on using
a PCI IDE-controller to attach the drives to. Performance is
not paramount here, but I'd like to go for an optimum.
RAID is not necessary, there will most likely be only two drives,
being backup'd via network
Just curious, why the extra controller?  My experience is that even an 
Abit BP6 with two 466 MHz Celerons and software RAID0 and 5 gives great 
NFS performance, even with public Debian and kernel mirrors.  (I'm 
pretty sure it saturates 100 mb ethernet with NFS, because Debian 
upgrades via NFS on machines across the same switch are very much faster 
than on machines in another room across MITnet with a 10 mb drop.)  I've 
never seen any reason to put in an extra controller -- unless you plan 
to put in more than 4 IDE devices.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: EM86-> flash plugin

[Adam C Powell IV]

Laurent Jacques wrote:
On Wednesday 08 May 2002 15:19, Richard Fillion wrote:
Thats another problem, i just CANT connect to Compaq's site.  Its been
like that for like 6months for me.  It resolves the IP, but then
nothing.  Its weird.  So the URL you just gave me, i cant connect to. :(
Apt cant install deb files which arent from your apt sources or atleast
not that i know of.  To install stray deb files, use the "dpkg" tool.
The reason i wanted EM86 is to run things like netscape for x86 so that
i could view flash and all the other cool not-alpha-friendly stuff.
Unless you guys know how to get the flash plugin to work on the Alpha,
which would also be useful to know.
There is the GPL flash plugin available here:
http://www.swift-tools.com/Flash/
There's also a .deb in woody (try apt-cache search flash).  Has anyone 
used it as a plugin?

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What have we learned? (WAS -RE: Idea: Reponse to the responses( was RE: Interesting idea....(at least I think so) ))

[Adam C Powell IV]

Hello Maurice (and others),
Maurice Hilarius wrote:
Just for interest, I asked the Debian maintainers, through the 
recommended page, and through the Debian alpha list, where we should 
send/communicate with to donate a machine.

So far we have no response.
This is an example of what I perceive as the biggest issues with 
Debian ( and Alpha) at present:

Who is actually in charge of anything?
Certain people are officially in charge of certain activities, such as 
maintaining the repository and coordinating releases.  Where a specific 
need arises, there is often a "call" of sorts for help, and somebody 
steps in, such as when Sam Hartman put together the initial list of 
questions to ask of legal cousel regarding the crypto-in-main 
transition.  In a smaller way, each package has its maintainer, who is 
an important single contact for the maintenance of the package, and 
there are procedures for replacing that person if it proves necessary; 
we also have the single Debian Project Leader (DPL), and an interesting 
mechanism for electing that person...

But a lot of activities don't have a single point of contact.  Is that a 
problem?  Sometimes.  It might be nice to have single contacts for, say, 
each port, but I don't think there is one.  "Write to the list" has been 
sufficient.

Do they have time and inclination to deal with these issues and others?
The offer of a free machine still stands. Does the Debian project need 
it?
If not I will throw this open to others who might be interested in 
Linux Alpha development.
I'm going to put my neck out here and guess that the lack of any 
response whatsoever to Branden's email to debian-alpha in the last three 
days is probably a decent indication that the Debian project doesn't 
absolutely need such a machine right now.  There are three basic demands 
for machines of a given architecture:

   * Autobuilding.  As a maintainer, I can safely say that alpha
 binaries for my packages are autobuilt very promptly after source
 upload, so there's no big need there.
   * Rbuild for stable security updates, which is one of the
 requirements for an architecture to release with woody.  Again, I
 think we're okay here.
   * Miscellaneous machines for maintainers who need to debug/test
 their packages on a given architecture.  Haven't heard this need
 expressed for alpha either (though ARM often gets this complaint).
Since these are the three primary demands for machines, I think we're 
probably safe on the alpha port for the time being.

Alternatively, "it's only been three days," and with a volunteer project 
that is not a very long time, even if there is a port coordinator it 
could take longer than that to reply.  Also, you send your original post 
(Subject "Donation", 23 Apr 2002 03:30:23 -) as a reply to "Alpha 
newbie install woes", making it difficult for people to read it, since 
it threads under that message and is invisible in many mail clients, 
this is why creating a brand new message is encouraged vs. replying to 
an existing one on a list like this.  But that's a technicality.

Of course, it doesn't change some of your main points.  I don't think a 
central coordinator for the port would have helped things, but it might 
be worth considering; the downside is that a single point of contact is 
also a single point of failure.  Judging from the reply to one of 
Branden's emails, it seems the 68k port is similarly slow to process 
hardware donations.  Is this a problem?  Yes, it is, particularly in 
this instance for 68k which is slow to autobuild packages, and to the 
extent that it leaves a bad taste in your mouth and bad association with 
the Debian project, that is a problem too.  It is, of course, not 
Debian's only problem, but it's an important one.

Debian is also slow to package X 4.2.0, and KDE 3, and to actually 
complete a release.  But when a release is made, it's darn stable, 
because X 4.1.0 has gone through sixteen releases often with prereleases 
between them to make sure everything works properly on every single arch 
and subarch (for details: 
http://lists.debian.org/debian-devel-0204/msg01343.html), and KDE 2.2 is 
absolutely rock-solid, as is GNOME 1.4 (though much of GNOME 2 is also 
entering woody).  The Debian packages for these which will be released 
with woody are the best, most portable, thoroughly tested such packages 
anywhere, even if they don't have the latest bleeding-edge features.  I 
am hoping that package pools and active development of the next 
generation install system will make Debian 3.1 come out a whole lot 
closer to 3.0 than 3.0 was to 2.2, and will do my best to make my 
packages ready for that next release.

Back to the issue at hand, a small handful of dedicated volunteers is 
all it takes to make a port happen and keep it going.  Which is why 
Debian's released architectures keep growing: four with slink, six with 
potato, *eleven* with woody (with Hitachi SuperH also working in 
unstable

Linking C main() to shlibs with Fortran sources using ccc/fort

[Adam C Powell IV]

Greetings,
I'd like to link some shlibs with some Fortran source to some C programs 
using the Compaq compilers to compile everything.  Trouble is, some of 
the Fortran objects need symbols like for_write..., which are provided 
by libfor.so, and that in turn needs this "MAIN__()" symbol, which is 
*only* provided by an fort-compiled object file with a Fortran PROGRAM 
statement, it's not in any of the libs which come with fort, nor in 
for_main.o.

I've noticed that if the libs are static, linking works just fine, but 
if I rebuild objects to shared libs using:

${LD} -shared -soname,$$LIBNAME.${SLSUFFIX} -o $$LIBNAME.${SLSUFFIX} *.o
then linking against the resulting shlibs fails with an undefined 
reference to MAIN__() in libfor.so.  Also, if I provide a C function like:

void MAIN__()
{
   printf ("hello world\n");
}
then it links fine, but hello world is never printed, so the function is 
never entered.  I'd really like to not have to provide this bit of code 
for this one arch/compiler combo...

Is there a way to do this?
Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: boot-floppies 3.0.22

[Adam C Powell IV]

Jamie Wilkinson wrote:
This one time, at band camp, Anthony Towns wrote:
Boot-floppies 3.0.22 are final except for serious bug fixes. No new
features.
alpha b-f build and uploaded.
Crap.  My UP1000 just died again last Thursday, so I can't test the APB 
install method like I said I would. :-(

Any other takers?
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New boot floppies up for testing

[Adam C Powell IV]

Falk Hueffner wrote:
Hi,
I've updated the boot floppies, built them and put them at
http://people.debian.org/~falk/disks-alpha/current/
I would be interested especially in reports from MILO folks.
This release has APB disabled because of lack of testers (it's not yet
pruned from the docs, though).
I can test this, as that's how I boot my nautilus -- if it gets built...
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Shlibs with fortran source in ccc

[Adam C Powell IV]

Okay, minor clarification...
Adam C Powell IV wrote:
The really bizarre thing is that for PETSc 2.1.0 and the older fort 
(the -2 RPM, installed by cfal...-1.deb), it worked just fine with 
-lcpml. The old libpetsc.so contains the symbol for_write_seq_lis, but 
the linker is somehow finding it without -lfor.
Actually, for some reason, the 2.1.0 shared libs were never built, so 
-lpetsc was linking against libpetsc.a.  The old libpetsc.a has that 
for_write_seq_lis symbol, and that links with a C binary just fine.

If I use the new 2.1.1 libpetsc.a, that works fine too.  And when I make 
a shlib from the old 2.1.0 libpetsc.a, that fails with missing 
for_write_seq_lis.  So that's cool, it's not a compiler version issue.

I'm just building my shared lib wrong, or perhaps, there's just 
something different about shared libs which is making it drop that 
symbol...  I can't find other options on the ld manpage that would 
help...  Here it is again:

The old and new shared libs were linked in exactly the same way, using:
${LD} -shared -soname $$LIBNAME.${SLSUFFIX}.${SLVERSION} 
-whole-archive $$LIBNAME.a -o $$LIBNAME.${SLSUFFIX}.${SLVERSION}

I also tried mkdir tmp; ar x ../$$LIBNAME.a; same LD command with *.o 
instead of $$LIBNAME.a, same error.
So the question is: how do I build a shared lib with mixed fortran/C 
sources (including a fortran write statement) such that a C program can 
link to it?  Fortran programs can link fine because they have MAIN__...

Thanks for any help you can provide,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Shlibs with fortran source in ccc

[Adam C Powell IV]

Hello,
I'm having some trouble with ccc/fort and shared libs.  My PETSc package 
has the option of being built using Compaq compilers and libs for 
increased performance.  It includes the shared lib libpetsc.so (among 
others) which is built from some C sources with ccc and some fortran 
sources with fort.

When I go to link a C-based binary to that lib, if I use -lfor -lFutil 
-lcpml, it can't find MAIN__, which is a symbol only generated by 
compiling a Fortran source with PROGRAM (AFAICT).  If I build with just 
-lcpml, it can't find for_write_seq_lis symbol, which is in libfor.

The really bizarre thing is that for PETSc 2.1.0 and the older fort (the 
-2 RPM, installed by cfal...-1.deb), it worked just fine with -lcpml. 
The old libpetsc.so contains the symbol for_write_seq_lis, but the 
linker is somehow finding it without -lfor.  But with 2.1.1 and the 
newer fort (the -3 RPM, installed by cfal...-2.deb which I just 
uploaded), it fails.  (Apologies to Naotaka Yamamoto for taking over a 
month to upload the new cfal installer and close 132951!)

The old and new shared libs were linked in exactly the same way, using:
${LD} -shared -soname $$LIBNAME.${SLSUFFIX}.${SLVERSION} -whole-archive 
$$LIBNAME.a -o $$LIBNAME.${SLSUFFIX}.${SLVERSION}

I also tried mkdir tmp; ar x ../$$LIBNAME.a; same LD command with *.o 
instead of $$LIBNAME.a, same error.

It's a real PITA that the old non-free cfal doesn't work any more 
because the "beta period expired", so I can't try building PETSc using 
that to verify that the compiler is making the difference.  I guess 
that's what I get for using non-free software. :-(

Thanks in advance for any help you can provide,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Help compiling g77-2.95

[Adam C Powell IV]

Adam C Powell IV wrote:
Hello,
I'm trying to build a new g77-2.95/libf2c.a with -mieee to get around 
bug #136359 and make lapack build and test properly.
Never mind, the maintainer just fixed it so libf2c compiles with -mieee 
on alpha, so I'll wait for the autobuilder to get to it.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Help compiling g77-2.95

[Adam C Powell IV]

Hello,
I'm trying to build a new g77-2.95/libf2c.a with -mieee to get around 
bug #136359 and make lapack build and test properly.  But when I try to 
debian/rules binary the gcc-2.95 source package, it always fails at:

cd 
/home/hazelsct/packages/gcc-2.95-2.95.4.ds8/src-native/gcc/p/doc/en/info 
&& makeinfo -I .. -I ../.. -I ../../generated -o gpc-295.info gpc.texi
../internals.texi:263: First argument to cross-reference may not be empty.
makeinfo: Removing output file `gpc-295.info' due to errors; use --force 
to preserve.
make[4]: *** 
[/home/hazelsct/packages/gcc-2.95-2.95.4.ds8/src-native/gcc/p/doc/en/info/gpc-295.info] 
Error 2
make[4]: Leaving directory 
`/home/hazelsct/packages/gcc-2.95-2.95.4.ds8/build-native/gcc'
make[3]: *** [boot_stage_a] Error 2
make[3]: Leaving directory 
`/home/hazelsct/packages/gcc-2.95-2.95.4.ds8/build-native/gcc'
make[2]: *** [bootstrap-lean] Error 2
make[2]: Leaving directory 
`/home/hazelsct/packages/gcc-2.95-2.95.4.ds8/build-native'
s=`cat status`; rm -f status; test $s -eq 0
make[1]: *** [stamps/05-build-stamp-native] Error 1
make[1]: Leaving directory `/home/hazelsct/packages/gcc-2.95-2.95.4.ds8'

I'm stuck, as I can't even figure out where in which Makefile this 
happens (so I could comment it out and move on).  I have all of the 
Build-Depends installed.  Any ideas on why it doesn't work?

Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Enlightenment makes the mouse freeze intermittently

[Adam C Powell IV]

Peter Petrakis wrote:
Hi ,
So, the one problem I'm having is that if I run enlightenment, the mouse
stops working for a couple of seconds at a time, then works for a couple
of seconds, on and off.  With sawfish, I see this one-or-two second
delay only once every few minutes, and don't see it at all with no WM
running -- then again, haven't spent enough time sans WM to know whether
that has the every-few-minutes problem like sawfish.
Do you have the GPM daemon running while X is running?
If so, try disabling that before starting X. Call me crazy but this sounds
like some sort of interrupt problem.
D'oh!  Silly me.  That should have been the first thing I tried.  Turned 
gpm off, now it works beautifully.  I suppose I could also use 
/dev/gpmdata...

What kernel are you running
and what out of the ordinary options do you have enabled?
Debian's 2.2.19 nautilus binary image.  Nothing special otherwise.
Oh- enlightenment also segfaults a lot, but haven't looked into this yet
with gdb/strace.  And it's unlikely to be supported, since they're
focusing on E17...
I wrote a small fix for E 16.5 for a segfault or fpe , I dont remember
which. I'll dig it up and send it to you and the list.
Cool!  It segfaults for me every time it starts, but clicking "Restart 
Enlightenment" makes it work pretty well.  I'll try your patch when you 
send it to the list, and if that fails then I'll investigate further.

There's also
an outstanding bug against E's background managment that I found (didnt
report
and yet to fix). Doesn't read files that have spaces in the name  :-)
Cool.
Jay, I do have an IDE CDROM, but now that it works without gpm running, 
I'm not sure that was the problem...

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Enlightenment makes the mouse freeze intermittently

[Adam C Powell IV]

Greetings,
I just started using X on my group's Nautilus, and (almost) everything 
works great!  Galeon/mozilla, gnumeric, evolution...  I am so impressed 
that so much works so well under alpha -- but then, most stuff also 
works well on my pmac at home, and a Netwinder I use (ARM).  Haven't 
tried making the Voodoo 3 DRM work yet, will have to upgrade to a 2.4 
kernel first...  Hooray for cross-platform free software, and Debian in 
particular!

So, the one problem I'm having is that if I run enlightenment, the mouse 
stops working for a couple of seconds at a time, then works for a couple 
of seconds, on and off.  With sawfish, I see this one-or-two second 
delay only once every few minutes, and don't see it at all with no WM 
running -- then again, haven't spent enough time sans WM to know whether 
that has the every-few-minutes problem like sawfish.

Oh- enlightenment also segfaults a lot, but haven't looked into this yet 
with gdb/strace.  And it's unlikely to be supported, since they're 
focusing on E17...

This is a UP1000 with Voodoo3 and debconf-managed XF86Config-4 and 
Xwrapper-config, X nice-value set to -10.

Any ideas?
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: kernel 2.4.12 kills ide drives

[Adam C Powell IV]

Craig Small wrote:
Hello,
 I've just had one of the more unpleasant evenings with my alpha and
some ide drives.  This was kernel 2.4.12 on a PC164SX
I started getting these, lots of these:
Feb 12 21:03:54 fozzie kernel: hda: dma_intr: error=0x40 { UncorrectableError 
}, LBAsect=16083582, sector=15466680
Feb 12 21:03:54 fozzie kernel: end_request: I/O error, dev 03:04 (hda), sector 
1 5466680
Feb 12 21:03:54 fozzie kernel: EXT2-fs error (device ide0(3,4)): 
ext2_write_inode: unable to read inode block - inode=957825, block=195
Feb 12 21:03:54 fozzie kernel: Remounting filesystem read-only
I thought my drive was dying, so I had another drive in the system
so I started trying to move stuff across to it using the two tar trick.
Every time I did it either one or both drives played up, with messages
like that and other wierdness.  Stuff like the files went out of bounds
or something and then some nasty message from some ext2_ function.
Just booted into 2.4.9 now and it is all working again.  So if
you go up a few kernel versions be real careful.  I mean this is a
plain ext2 partition on an ide drive, nothing fancy.
Oh my, this is very interesting.  I just upgraded a dual-Celeron system 
from 2.4.9 to 2.4.17 last week, and it did the same thing to one of my 
drives!  This would be a very serious kernel bug...

What kind of controller is this on?  My drive that failed was on an HPT366.
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Installing a package interactively

[Adam C Powell IV]

Jim Woodruff wrote:
Thanks for the tip about reconfiguring debcon. It seems to work
now exect for another problem that I believe is in your area as
maintainer.
I have an DEC alpha SX164 which is a 21164PC and should require
the cpml-ev5. When running the apt-get install the dialog tells
me that I should be using the cpml-ev6. I tell it to install
anyway and the install aborts trying to configure the cpml-ev5.
Any ideas?
The CPML packages come with a little program called /usr/sbin/implver, 
which is used to determine the CPU type, written by Falk Hueffner to 
correct just this type of problem (http://bugs.debian.org/96332).  Can 
you send me the output of that program on your machine?

I'm again CCing debian-alpha, because I really don't understand the full 
details of /proc/cpuinfo entries nor exactly how implver works.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Installing a package interactively

[Adam C Powell IV]

Jim Woodruff wrote:
I'm running a DEC Alpha using Debian 3.0 (unstable). I have downloaded the
libots, cpml-ev5, cxml-ev5, ccc, and cxx rpm packages from Compaq.
When I "apt-get install" the cxx package (assuming it will retrieve all
the dependency files from Debian, it exits with the following error:
"You are running in non-interactive mode and the Compaq needs to prompt ...
Please re-install it in interactive mode."
I've also tried "dpkg -i" with the downloaded Debian packages with the
same results.
I've also tried converting the Red Hat rpm file with alien but it does not
build correctly and the resultant .deb package doesn't install correctly.
How dow I install these packages interactively?
Hmm.  I've tried to install both of these ways, and it's worked fine for 
me; with dpkg, the debconf stuff is done during postinst.

How is debconf configured for you -- which front end?
dpkg-reconfigure debconf
The packages need to interact with the user via debconf, so if you have 
debconf configured non-interactive, that's the problem...

I'm ccing this to debian-alpha in case folk there are aware of other 
issues I don't know about.  I hope you don't mind...

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: cfalrtl: undefined reference to `MAIN__'

[Adam C Powell IV]

Adam C Powell IV wrote:
Greetings,
So I finally got cfal(rtl) working properly, and uploaded.  And it 
works, for small programs.  Cool!

So now I'm trying to get PETSc working with cfal/ccc, which involves 
building C binaries linked against C and FORTRAN objects in libs built 
by ccc and fort.  But I keep running up against:

/usr/lib/libfor.so: undefined reference to `MAIN__' 
Problem solved.  When using a C main(), do *not* link (ccc) with -lfor 
-lutil -lFutil, even if you have objects with Fortran subroutines.  Just 
link -lcpml.

Hope this helps someone,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

cfalrtl: undefined reference to `MAIN__'

[Adam C Powell IV]

Greetings,
So I finally got cfal(rtl) working properly, and uploaded.  And it 
works, for small programs.  Cool!

So now I'm trying to get PETSc working with cfal/ccc, which involves 
building C binaries linked against C and FORTRAN objects in libs built 
by ccc and fort.  But I keep running up against:

/usr/lib/libfor.so: undefined reference to `MAIN__'
Any ideas?
Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: aptitude on alpha (again, sigh)

[Adam C Powell IV]

Christopher C. Chimelis wrote:
On Thu, 1 Nov 2001, Daniel Burrows wrote:
 Can anyone reproduce/hunt down 114270?  I can't reproduce it (I think
it's probably Alpha specific), and I don't really have much of an idea
where it could be.  I haven't gotten any other reports of this, which
makes me wonder if maybe it could be the reporter's system.
It's an Alpha thing.  I started looking into this bug a few weeks ago, but
got busy with other things.  One thing I do know that needs to be done is
adding "-mieee" to CFLAGS and CXXFLAGS on Alpha.  It would probably be
best to add this into the autoconf parts of the package rather than the
rules script (which is how I was experimenting with it).
Just FYI, my autoconf macro which does this:
AC_CHECKING([whether -mieee is needed to avoid SIGFPE on divide by zero])
case $build/$CC in
   alpha*/gcc* )
   build_gcc_alpha=yes
   AC_MSG_RESULT([yes, will be used for libpetscgraphics])
   ;;
   * )
   build_gcc_alpha=no
   AC_MSG_RESULT([not needed])
   ;;
esac
AM_CONDITIONAL(GCC_ALPHA, test x$build_gcc_alpha != xno)
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: dec/Q ccc compiler

[Adam C Powell IV]

Phil Mendelsohn wrote:
On Tue, 25 Sep 2001, Juha Jäykkä wrote:
 I have, though, tested compaq's fortran compiler - and it does not
seem to work at all. 

Check comp.lang.fortran for details, but I understand that it does work
well, provided you've installed properly which is non-trivial.
What was the subject for the relevant thread?  I've searched 
comp.lang.fortran (4300 messages) for compaq, dec, digital, alpha, fort 
and cfal, found nothing...

Or can you summarize the procedure, so I can make the Debian installer 
do the right thing?

How do you get it to find fstat()?
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: dec/Q ccc compiler

[Adam C Powell IV]

bad bob wrote:
Does anyone have this running on an alpha under debian? If so, are there
any noticable improvements over gcc?
Thanks
bob
For sid/woody, there's an "installer package" which requires you to get 
the latest ccc (and libots) from Compaq.  The debconf stuff gives the 
relevant URLs.

For potato, you have to get the source package and edit the gcc symlinks 
to use 2.95.2 instead of 2.95.4.

There is no cfal(rtl) yet, because libfor.so was built with an old 
glibc, so it tries to reference fstat() which has moved out of glibc. 
And it persists if you try to use the 3.0 gcc/g77.  That's all I know, 
see http://bugs.debian.org/103750 for details.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Compaq C and C++ compilers

[Adam C Powell IV]

bad bob wrote:
"T. Weyergraf" wrote:
Hi,
To follow up my own message, I did find the posting in the archives,
from T. Weyergraf about how to install them!! I am attempting to
get the c compiler installed using RPM now.  Got some of the support
stuff installed, working thru it.
bob
let me know, if they still work with the current stuff. If not, I'll do an 
update on the docs,
in a couple of days...
Thanks! I am currently making sure all the normal lib stuff is in
place...
the system told me there are some symlinks not present and a font is
missing
in the X11R6 area...working that
thanks again!
This should only be necessary for potato; for woody/sid there are 
installer packages which will do all of the Weyergraf magic for you. 
(Unfortunately, they depend on woody's debconf, so you can't use those 
packages with potato.)  To use it, you just need to get the RPMs and 
tell debconf where you put them.

Still working on cfal and cfalrtl, they should get in by the woody freeze...
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

(moderately urgent) request for toolchain help

[Adam C Powell IV]

Greetings,
I've had a cfal(rtl) installer package ready to upload for quite some 
time now, but compiled binaries fail at runtime because of a missing 
fstat symbol needed by one of the cfalrtl libs.  fstat is weekly defined 
in libc_nonshared.a, but the linker fails to pull it in.

For details, see bug #103750, http://bugs.debian.org/103750 .  I'm not 
sure I should make that bug release-critical, but with the base freeze 
coming real soon, if this doesn't get fixed, cfal just won't work at all 
with as-released Woody.

Worse still, I'm afraid this will affect other binaries compiled against 
alien shared libs...

Any ideas?
TIA,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: Correct way to build .deb with -mieee

[Adam C Powell IV]

Christopher C. Chimelis wrote:
On Tue, 19 Jun 2001, Adam C Powell IV wrote:
I have a program (petscgraphics) which, when built without -mieee, fails 
with SIGFPE (division by zero); with -mieee, works perfectly (still 
divides by zero, but works anyway).

So, should -mieee go in debian/rules, something like "CFLAGS=-mieee 
./configure --prefix=/usr"?  Or is there a more intelligent way for 
upstream (me) to put it in, such that it is only used for one source 
file (petscgraphics.c)?

It's usually ideal to make such changes in the autoconf scripts, unless
the software doesn't use autoconf.  If it doesn't, then the best way may
be to handle it via debian/rules.  Since it's only needed for one file,
though, doing a "blanket" -mieee compilation would probably be overkill...
Indeed.  I took this approach (autoconf scripts), and now PETScGraphics 
works on alpha.

Just "for the record", here's what I did: in configure.in
AC_CHECKING([whether -mieee is needed to avoid SIGFPE on divide by zero])
case $build/$CC in
   alpha*/gcc* )
   build_gcc_alpha=yes
   AC_MSG_RESULT([yes, will be used for libpetscgraphics])
   ;;
   * )
   build_gcc_alpha=no
   AC_MSG_RESULT([not needed])
   ;;
esac
AM_CONDITIONAL(GCC_ALPHA, test x$build_gcc_alpha != xno)
Then in Makefile.am, I copied the %.lo:%.c target from Makefile.in but 
added -mieee for this particular file:

# This is to get -mieee in for gcc on Alpha
if GCC_ALPHA
petscgraphics.lo: petscgraphics.c
   @echo '$(LTCOMPILE) -mieee -c $<'; \
   $(LTCOMPILE) -mieee -Wp,-MD,.deps/$(*F).pp -c $<
   @-sed -e 's/^\([^:]*\)\.o[ ]*:/\1.lo \1.o :/' \
 < .deps/$(*F).pp > .deps/$(*F).P; \
   tr ' ' '\012' < .deps/$(*F).pp \
 | sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
   >> .deps/$(*F).P; \
   rm -f .deps/$(*F).pp
endif # GCC_ALPHA
I really don't know what all the obscure sed and tr stuff does (except 
that it helps set up build dependencies properly), and it may break on 
automake upgrade, but at least for now it works. :-)

HTH, share and enjoy, etc.
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: Correct way to build .deb with -mieee

[Adam C Powell IV]

Robert Funnell wrote:
Adam C Powell IV wrote:
Note that it is possible to have one of
these three divisions by zero and still produce a triangle or two; one
can even have C1=C2q and get two triangles, so we can't
just test for any zeroes and skip the whole thing. ...
But you could test for any zeroes (maybe by precomputing the 4
denominators and checking whether their product is 0?) and then handle
that special case (presumably relatively rare and therefore causing
little performance penalty) with explicit checks for each denominator.
With floating-points the checks against 0 should probably involve a
finite tolerance, to avoid underflows and overflows.
Hmm, that's a good bit of additional code, especially since a good 
tolerance will depend on the scale of the mesh, and I don't think with 
much benefit (see below).  Also, for the phase field calculations I do, 
where there's a lot of action right at the interfaces and zero gradients 
everywhere else, this special case is all over the place; though not 
everyone is doing phase field. :-)

...  It just seems easier
to do it this way, and because it's just for graphics, I don't really
care about the divide by zero.
I'm not sure what happens to the graphics (might it cause a visual
artefact at some point?) but someone might try to use the programme's
output for some further analysis (e.g., volume calculations) rather
than just visualization.
I really don't think so.  The edge intercept is inf (or NaN?), which is 
not between zero and one, so no intercept, no triangle intersecting that 
edge. I don't think that will have any effect on the resulting 
triangulation, or its utility for volume calculations...  I think -mieee 
is the way to go.

Stefan, regarding trying out PETScGraphics, I recommend "apt-get install 
petscgraphics1-demo", which should drag in all the dependencies 
(including rsh-server!), then just run chts, or on an SMP box, "mpirun 
-np X /usr/bin/chts".  Oh- except I haven't uploaded alpha yet (will try 
Chris' "$ARCH==alpha*-*-linux-*" test).

Thanks all for the feedback.
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Re: Correct way to build .deb with -mieee

[Adam C Powell IV]

Hello,
First, Chris, I do use autoconf, and could do an AM_CONDITIONAL around 
something like petscgraphics_c_CFLAGS+=-mieee (I'll have to search the 
automake list archives for the right name there).  What's the right 
architecture test to use in configure.in?  Something like:

 AM_CONDITIONAL(IS_ALPHA, test "$ARCH" == "alpha")
but what can I use for $ARCH?  Or is there a test like AC_NEEDS_MIEEE? 
I don't see such things in the autoconf info pages.

Stefan Schroepfer wrote:
On Tue, 19 Jun 2001, Adam C Powell IV wrote:
I have a program (petscgraphics) which, when built without -mieee, fails
with SIGFPE (division by zero); with -mieee, works perfectly (still
divides by zero, but works anyway).
Please excuse my ignorance (I know nothing about petscgraphics),
but this problem could almost surely be solved in source code.
("Works anyway, but still divides by zero" --- brrr --- Is there
any chance to use some limits to prevent this to happen? --- Does
the code work on other architectures by chance? --- On all other
architectures?).
Just speaking from my own experience. In most cases I have seen,
the need for denormals came from erroneous source code and not
from a real dependency on that special feature of a CPU.
Of course, if it's possible to avoid divides by zero without performance 
penalty, I would love to.

The offending code considers a tetrahedron with field values at the 
corners, call them C0, C1, C2 and C3 (doubles), and calculates the edge 
intercepts of the plane defined by C=q in the linearized C field defined 
by the corner values.  It uses this to generate zero to two triangles 
representing the cut of C=q across that tentahedron.  The set of such 
triangles on all of the tetrahedra make up the C=q isoquant surface 
approximation, which is sent to Geomview for display.

Here's the code, which loops through the six tetrahedra that make up a 
hexahedron (often a cube):

 for(tet=0; tet<6; tet++)
   {
 /* Within a tetrahedron, edges 0 through 5 connect corners:
0,1; 1,2; 2,0; 0,3; 1,3; 2,3 respectively */
 c0 = tetras[tet][0];
 c1 = tetras[tet][1];
 c2 = tetras[tet][2];
 c3 = tetras[tet][3];
 edge0 = (isoquant-vals[c0]) / (vals[c1]-vals[c0]);
 edge1 = (isoquant-vals[c1]) / (vals[c2]-vals[c1]);
 edge3 = (isoquant-vals[c0]) / (vals[c3]-vals[c0]);
 whichplane = (edge0>0. && edge0<1.) | ((edge1>0. && edge1<1.) << 1) |
   ((edge3>0. && edge3<1.) << 2);
 if (whichplane)
   {
 ierr=DrawTetWithPlane
   (coords[c0&1],coords[2+((c0&2)>>1)],coords[4+((c0&4)>>2)],vals[c0],
coords[c1&1],coords[2+((c1&2)>>1)],coords[4+((c1&4)>>2)],vals[c1],
coords[c2&1],coords[2+((c2&2)>>1)],coords[4+((c2&4)>>2)],vals[c2],
coords[c3&1],coords[2+((c3&2)>>1)],coords[4+((c3&4)>>2)],vals[c3],
isoquant, edge0,edge1,edge3, whichplane, color); CHKERRQ (ierr);
   }
   }
DrawTetWithPlane() is a static inline function which actually creates 
the triangle(s).  So the problem is, if C1=C0, C2=C1, or C3=C0, then 
edge0, edge1 or edge3 intercept (respectively) will be infinite, i.e. 
there is no intercept.  The whichplane variable tells which of the seven 
possible cuts through the edges is made here, with zero indicating no 
triangles in this tetrahedron.

I could trap for these conditions with an if statement around them, but 
wouldn't that slow things down?  Note that it is possible to have one of 
these three divisions by zero and still produce a triangle or two; one 
can even have C1=C2q and get two triangles, so we can't 
just test for any zeroes and skip the whole thing.  It just seems easier 
to do it this way, and because it's just for graphics, I don't really 
care about the divide by zero.

Then again, I do have a test for whichplane in there, and a 
switch(whichplane) in DrawTetWithPlane()...  Hmm, with that switch, I 
could probably lose the if(whichplane).  Then again, the optimizer might 
do that automatically...

I don't know whether this algorithm is optimal, nor whether my 
implementation can be improved, just that it worked right the first 
time, with lots and lots of code in DrawTetWithPlane(), and I haven't 
touched it since.  If you have the interest and time to try to lose the 
SIGFPE without -mieee, or even speed things up, feel free to apt-get 
source petscgraphics and look at petscgraphics.c.  (It takes longer than 
the other files to compile- I'll bet the optimizer has quite a good time 
vectorizing inlined DrawTetWithPlane() within two functions... :-)

Share and enjoy, thanks in advance for any help you can provide.
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Correct way to build .deb with -mieee

[Adam C Powell IV]

Hello,
I have a program (petscgraphics) which, when built without -mieee, fails 
with SIGFPE (division by zero); with -mieee, works perfectly (still 
divides by zero, but works anyway).

So, should -mieee go in debian/rules, something like "CFLAGS=-mieee 
./configure --prefix=/usr"?  Or is there a more intelligent way for 
upstream (me) to put it in, such that it is only used for one source 
file (petscgraphics.c)?

Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: gcc too old for cxx ?

[Adam C Powell IV]

Helge Kreutzmann wrote:

> Hello !
> I tried to install the recent made "wrapper" debs for the compaq
> compilers. I got the rpms & the deps, installed ccc, updated cpml
> (which was already present) and finally wanted to install cxx.
> Unfortunately I get:
> Error: Unable to find GCC at /usr/lib/gcc-lib/alpha-linux/2.95.4. GCC
> must be in stalled.

Right.  I forgot to version the gcc dependency in the cxx installer package.  I
need to update ccc to use and depend on 2.95.4 too, will probably do that later
today.

> I "only" have /usr/lib/gcc-lib/alpha-linux/2.95.3
>
> I have a partially woody system so I updated gcc (was already latest
> version) and gcc-2.95 (got a new binutils as well). Nevertheless I am
> still on 2.95.3.

Yes, 2.95.4 is in unstable, where cxx is...

> Is it save to simply symlink 2.95.4 to 2.95.3 or else where do I get a
> newer gcc from ?

You can get it from unstable, or else look in /var/lib/dpkg/info/cxx.postinst
which has:

/usr/lib/compaq/cxx-6.3.9.7/alpha-linux/bin/create-comp-config.sh \
  cxx-6.3.9.7 /usr/lib/gcc-lib/alpha-linux/2.95.4

Just run that script again with 2.95.3 and it should work.  You should also run
the rest of the commands in the postinst- or just edit the postinst and rerun
that whole script.

HTH,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Sid linker/loader bug and cfal?

[Adam C Powell IV]

Hello,

Kenneth Block is giving me some help with the cfal packages.  Could the
fstat problem be a linker/loader bug, since the symbol seems to be
weakly defined in libc?

Attached is his last message...

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!


--- Begin Message ---
Is this a linker/loader bug? If you look at libfor.so, fstat is defined, but
it is defined as a weak symbol.

cxal.zko.dec.com> nm -A /usr/lib/compaq/cfalrtl-1.0/libfor.so | grep fstat
/usr/lib/compaq/cfalrtl-1.0/libfor.so:000648e0 T __fstat
/usr/lib/compaq/cfalrtl-1.0/libfor.so:000648e0 W fstat

Here is the same information on the RedHat 6.2 system which we used to
produce the compiler.

cxal.zko.dec.com> nm /usr/lib/libc.a | grep fstat | egrep -v
"fstatfs|fstatvf"
fstat.o:
 T __fstat
 W fstat
fstat64.o:
 T fstat64


cxal.zko.dec.com> cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6.1 /usr/lib/libc_nonshared.a )

cxal.zko.dec.com> nm /lib/libc.so.6.1 | grep fstat | egrep -v
"fstatfs|fstatvf"

cxal.zko.dec.com> nm /usr/lib/libc_nonshared.a | grep fstat | egrep -v
"fstatfs|
fstatvf"
fstat.oS:
 T __fstat
 W fstat
fstat64.oS:
 T fstat64


-Original Message-
From: hazelsct [mailto:hazelsct]On Behalf Of Adam C Powell IV
Sent: Sunday, April 15, 2001 10:36 AM
To: [EMAIL PROTECTED]
Subject: Re: Compaq Compiler on Debian


Kenneth Block wrote:

> Thanks for the reply. This is the first copy I have received.

Okay, so a Netscape crash must have eaten the last one.

> For the Fortran problem, I'm not sure what the deal is. fstat is in libc,
so
> I really can't say why it would be unresolved.

Aha!  This explains quite a bit.  Debian unstable (2.3) uses glibc 2.2.2,
stable (2.2) uses 2.1.3, so this symbol may have changed.

Have you tested cfal/cfalrtl on newer versions of other distributions with
glibc 2.2.2?

Just for fun:

% nm /usr/lib/libc.a | grep fstat
 U __fstatfs
 U __fstatvfs64
fstat.o:
 T __fstat
 W fstat
fstat64.o:
 T fstat64
fstatfs.o:
 T __fstatfs
 W __fstatfs64
 W fstatfs
 W fstatfs64
fstatfs64.o:
fstatvfs.o:
 U __fstatfs
 T fstatvfs
fstatvfs64.o:
 T __fstatvfs64
 U fstatvfs
 W fstatvfs64
 U __fstatfs
 U __fstatfs64

Thank you for the reply, I hope we can fix this soon.

Cheers,
--
  Adam Powellhttp://lyre.mit.edu/~powell/
  Thomas B. King Assistant Professor of Materials Engineering
  77 Massachusetts Ave. Rm. 4-117Phone (617) 452-2086
  Cambridge, MA 02139 USA  Fax (617) 253-5418



--- End Message ---

Re: cfalrtl question

[Adam C Powell IV]

A clue...

Adam C Powell IV wrote:

> % ./erf
> ./erf: error while loading shared libraries: /usr/lib/libfor.so.0:
> undefined symbol: fstat
>
> Where's fstat?
>
> % nm /usr/lib/compaq/cfalrtl-1.1.0/libUfor.a | grep fstat
> for_u_fstat.o:
>  U fstat
>  T fstat_
> % nm /usr/lib/compaq/cfalrtl-1.1.0/libfor.a | grep fstat
>  U fstat
>
> but the shared libs are stripped, so I don't know if fstat is really in
> libUfor.so or somewhere else that gets lumped into the static
> libUfor.a.

Turns out fstat is in libc!  So Q may have to rebuild their beta cfalrtl libs
for glibc 2.2.2...

Just for fun:

% nm /usr/lib/libc.a | grep fstat
 U __fstatfs
 U __fstatvfs64
fstat.o:
 T __fstat
 W fstat
fstat64.o:
 T fstat64
fstatfs.o:
 T __fstatfs
 W __fstatfs64
 W fstatfs
 W fstatfs64
fstatfs64.o:
fstatvfs.o:
 U __fstatfs
 T fstatvfs
fstatvfs64.o:
 T __fstatvfs64
 U fstatvfs
 W fstatvfs64
 U __fstatfs
 U __fstatfs64

So what does fstat do?  Does this mean the new glibc doesn't really have fstat?
Does this break binary compatibility for anything else?

And more importantly: does anybody have fort working on unstable at all?

I'm not uploading any cfal packages until this is resolved, though you can play
with what currently exists at http://lyre.mit.edu/~powell/compaq/ .

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

cfalrtl question

[Adam C Powell IV]

Greetings,

I'm mostly done with the cfal(rtl) installer packages, but there's a
missing symbol "fstat" I can't figure out.  Here's my source:

  program theerf
C This is the erf program
  write (*,*) 'Hello world'
  write (*,*) 'The error function of 1 is ', erf(1.0)
  end

I build with "fort erf.f -o erf", which goes fine (well, except the
"tempnam" warning), but then when I run it:

% ./erf
./erf: error while loading shared libraries: /usr/lib/libfor.so.0:
undefined symbol: fstat

Where's fstat?

% nm /usr/lib/compaq/cfalrtl-1.1.0/libUfor.a | grep fstat
for_u_fstat.o:
 U fstat
 T fstat_
% nm /usr/lib/compaq/cfalrtl-1.1.0/libfor.a | grep fstat
 U fstat

but the shared libs are stripped, so I don't know if fstat is really in
libUfor.so or somewhere else that gets lumped into the static
libUfor.a.  ldd shows:

% ldd erf
 libUfor.so.0 => /usr/lib/libUfor.so.0 (0x0203)
 libfor.so.0 => /usr/lib/libfor.so.0 (0x0205)
 libFutil.so.0 => /usr/lib/libFutil.so.0 (0x020e4000)
 libcpml.so.0 => /usr/lib/libcpml.so.0 (0x02138000)
 libots.so.0 => /usr/lib/libots.so.0 (0x021ca000)
 libc.so.6.1 => /lib/libc.so.6.1 (0x021e8000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0200)
% ls -l /usr/lib/libUfor.so.0
lrwxrwxrwx1 root root   31 Apr 12 09:53
/usr/lib/libUfor.so.0 -> compaq/cfalrtl-1.1.0/libUfor.so

(The .0s are there because I put them in the sonames, so packages linked
against them will automatically depend on cfalrtl.  For details: man
dh_shlibdeps.)

I tried buliding with -lfor -lUfor, and that switched the order of these
two in ldd output, but gave the same error.  I tried building with
-Wl,-static but that gave:

% ldd erf
 libUfor.so.0 => /usr/lib/libUfor.so.0 (0x0203)
 libfor.so.0 => /usr/lib/libfor.so.0 (0x0205)

Even tried putting /usr/lib/libUfor.a in the compile line, but same ldd,
same runtime error.

So what's the problem here?

Oh- BTW, for some reason the installed fort does *not* ask for license
information before running...  Current package is again at
http://lyre.mit.edu/~powell/compaq/

Thanks in advance,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

ANNOUNCE: ccc installer package

[Adam C Powell IV]

Greetings,

I have made a ccc installer package like the ones for libots, cpml and
cxml.  I just uploaded it, so it's in incoming, and you can also get it
from http://lyre.mit.edu/~powell/compaq/ .

The only hangup I can find is that the sml and rsml man pages go into
/usr/man in the RPM, but Debian's man does not look there or in
/usr/share/man so man sml or rsml turns up empty.  I can link them from
another section, if someone would suggest one.  There seem to be
references to /usr/man/sml.gz and /usr/man/rsml.gz in the ccc man page,
so "man ccc" gives an error because they're missing.  But making the
links from /usr/man gives a lintian error...

So I'm leaving it without those manpages for now.  Oh well.

Also, as I've mentioned before, it depends on gcc-2.95, so it won't
install on a potato system.  This is so I can specify the gcc directory
and dependency explicitly, and it won't break on gcc upgrade.  Oh well.

It installs without comp.config, then runs create-comp-config.sh to
generate it, and it seems to generate just fine, so we don't need to
patch comp.config.  It passes the "hello world" test, but I haven't
pushed it beyond that yet.

Try it, push it hard, share and enjoy, etc.

Coming next week: cfalrtl and cfal, then test with PETSc, then on to cxx
and ladebug...  Maybe someone else can do Q's Java stuff?  (BTW, can
mozilla use Q's JVM?  Is it high-performance?  If no, not much
motivation to build it.)

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: why nautilus is not available for alpha

[Adam C Powell IV]

"Ivan E. Moore II" wrote:

> > "Ivan E. Moore II" wrote:
> >
> > > Ok...did my research
> > >
> > > nautilus *Requires* 0.8 mozilla to build.  just that simple.  0.8 is not
> > > part of the distro and thus no naut.
> >
> > Did you get my email to this list of last Thursday 10:20:51 -0500?  If not,
> > please check the archives.
>
> If you refering to the "unofficial" 0.8 Mozilla packages message you
> sent then yes I did...however I don't deal with unofficial alpha packages when
> it comes to the buildd.  The reason there is no nautilus for the alpha arch
> right now is because there are no 0.8 official debs.

I'm sorry, I think this is one of those unfortunate situations where one has to
throw the hands up and say, "That's why they call it unstable."

The nautilus maintainer Takuo Kitame took matters into his own hands and built
his own 0.8, then uploaded x86 naut binaries depending on it.  Maybe you could 
do
the same for alpha, or else convince Kitame and the moz maintainer that an
0.8(.1)-0.1 NMU would be a good thing- at least in the short term...

In the meantime, have you tried building/running Kitame's unofficial 0.8 for
alpha?

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

 Welcome to the best software in

Re: why nautilus is not available for alpha

[Adam C Powell IV]

"Ivan E. Moore II" wrote:

> Ok...did my research
>
> nautilus *Requires* 0.8 mozilla to build.  just that simple.  0.8 is not
> part of the distro and thus no naut.

Did you get my email to this list of last Thursday 10:20:51 -0500?  If not,
please check the archives.

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: Compaq C-compiler quick install quide

[Adam C Powell IV]

Helge Kreutzmann wrote:

> Hello !
> On Fri, Mar 30, 2001 at 09:03:28AM -0500, Adam C Powell IV wrote:
> 
> > Does it just run create-comp-config.sh to do this, or is there more
> > to the rpm's "postinst" script? Anyone know how I can extract such
> > scripts from a binary rpm?
>
> The easiest way I know is to walk into the RPM with the midnight
> commander, go into the INFO/SCRIPTS directory and copy the out (F5).

Thank you.  I couldn't quite walk in with mc (right-cursor must work for
directories but not archives), but copied it to my current desktop and it opened
up in gmc just fine.

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

Hello,

I've made the new libots installer, and removed the libots dependency
from the cpml and cxml installer packages, so they are all up to version
-3.  I just uploaded all three of these.

I'll work on the FORTRAN, C and C++ compiler installer packages next
week.

Share and enjoy,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: Compaq C-compiler quick install quide

[Adam C Powell IV]

Hello Thomas, and thank you for the install guide.  Here are a few comments:

"T. Weyergraf" wrote:

> Here is a step-by-step list of the files/packages/libs/progs, which
> are needed by the Compaq Toolchain. They are presented in the order
> in which the compaq-packages will be installed:
>
> libots:
>ld-linux.so.2 is needed by libots-2.2.7-2
>libc.so.6.1 is needed by libots-2.2.7-2
>
> cpml:
>/bin/sh   is needed by cpml_ev6-5.1.0-2

The cpml installer does not depend on bash (which provides /bin/sh on Debian), 
should it?  I don't see why...

> ccc:
>man is needed by ccc-6.2.9.506-1
>/bin/sh   is needed by ccc-6.2.9.506-1
>
> And of course the Debian RPM packages:
>librpm1 3.0.3-1
>rpm 3.0.3-1
> as well as the gcc compiler:
>gcc 2.95.2-13

Ah, so these are potato directions. :-)  The cpml/cxml installers should work 
on potato, but the ccc installer will depend on gcc-2.95 in woody/sid because 
of the libgcc.a location (otherwise it will break on upgrade of gcc), and none 
of them depend on rpm (they include a small perl rpm2cpio in postinst, like the 
realplayer installer package they're based on).

> 2. Install the proper ( EV5 or EV6 ) version of the cpml-rpm.
>I'll use cpml for EV6, which is cpml_ev6-5.1.0-2.alpha.rpm
>
>rpm -i --nodeps ./cpml_ev6-5.1.0-2.alpha.rpm
>
>Now run the following commands manually:
>
>cd /usr/lib/compaq/cpml-5.1.0
>rm -f /usr/lib/compaq/cpml-5.1.0/libcpml_ev6.so
>
>Note, the following is *one* commandline:
>
>ld -shared -o libcpml_ev6.so -soname libcpml.so -whole-archive \
> libcpml_ev6.a -no-whole-archive -lots

Question: I have it in the installer now, but why is -lots there?  Does ld 
provide inter-library dependencies, or is it just ignored?  I thought that's 
part of why libtool exists.

And it's not even clear cpml should depend on libots at all...

>And now the last two
>
>strip libcpml_ev6.so
>/sbin/ldconfig

Okay, the cpml installer does all of this.

> 4. Now Install the ccc compiler package:
>
>rpm -i --nodeps ccc-6.2.9.506-1.alpha.rpm
>
>The install process should emit the following message:
>
>Using /usr/lib/gcc-lib/alpha-linux/2.95.2 (3).

Does it just run create-comp-config.sh to do this, or is there more to the 
rpm's "postinst" script?  Anyone know how I can extract such scripts from a 
binary rpm?

Thanks again,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6



w½w½w½w½w½w½w½w½s½w¾wÝwÞw½w½w¾wWelcome to the best software in the world today 
cafe!

Re: ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

"T. Weyergraf" wrote:

> IIRC, the only problem was with the create-comp-config.sh in the ccc-rpm, 
> which
> sets up the compiler. cpml will be handled by adam's installer and libots 
> seems failry
> straight-forward.

libots already has a .deb which you can get with the 1.0 FORTRAN compiler 
.debs.  But I do some
shlibs magic with cpml and cxml (I use the soname libcpml.so.0 and put an extra 
symlink from
/usr/lib/libcpml.so.0 to the shared lib, then put "libcpml 0 cpml" in shlibs, 
same with cxml), so
packages built against them will automatically depend on them through the 
shlibdeps mechanism.
(Isn't Debian amazing? :-)

I think this is a good enough reason to do a libots installer too, so I'll go 
ahead and do that and
upload today with the other two.

> I'll modify create-comp-config.sh to work on debian systems and supply a patch
> to the original, once it's done, so ppl will have to re-run the patched 
> version, once the
> rpm itself is installed.
> Still being a complete idiot wrt debian packages, i assume a debian-installer 
> similar
> to the one adam provided for cpml, will be able to patch the 
> create-comp-config.sh
> script and run the result along with the ususal "debian-magic" required ;-)

Yup.  Not much magic there.  Except it's more convenient for postinst to use 
sed than a patch, so
I'll convert your patch to do it that way.

> I think, i'll do it over the coming weekend, since i do have some work today 
> ( btw: trying to
> convince a customer to buy a fairly large debian-alpha based setup for 
> commercial
> server usage - very exciting after my years of SPARC/Solaris stuff - 
> hopefully compaq
> supports my effort ;-)

Great!

> Anyway, two questions remain:
> 1. is this patch-approach acceptable for The Debian Way (TM) ?

Of course. :-)

> 2. will compaq sue the crap out of me, if i distribute a patch ?

I'm pretty sure they won't.  The libots/cpml/cxml "license" doesn't even 
restrict redistribution of
the libraries (if it did, people would not be able to distribute 
statically-linked binaries, so
there would be no point in including the static libs).  We're just not doing 
that because they
don't like others to distribute them and we want to be good netizens and make 
them happy.

The create-comp-config.sh script is a trivial little thing in plain text for 
all to see, so I'm
pretty certain they won't object to patching it, though it would be good to get 
a second opinion
from someone with more authority...  And I need to know this too, since I'll 
have to distribute
such a patch or sed with the installer!  Now if we were making binary patches 
to their libs, they
might object to that. :-)

The other issue is forward compatibility with create-comp-config.sh in future 
ccc packages.  The
installer package tells the user it's only guaranteed to work on the specific 
RPM filename/version
given, but (s)he is welcome to try it with newer versions if necessary.  I hope 
create-comp-config
doesn't change much, so this forward compatibility will remain; in any case, a 
sed script is more
likely to keep working than a patch because it just looks for and replaces 
specific words instead
of entire lines.

Thanks for helping to make this happen!

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

   Welcome to the best software in the world today cafe!

Re: Uploads required for 2.2r3

[Adam C Powell IV]

Martin Schulze wrote:

> Jon Leonard wrote:
>
> > Last I checked (I currently have the package held), vim-gtk on Alpha needed
> > to be rebuilt.  It had been built without gtk installed, so didn't include
> > the expected gvim binary.
>
> If others feel the same, somebody please provide us with a binary
> only upload/recompile.

This is a problem on PPC too.  It's caused by an incomplete Build-Depends, which
is a bug, #67737 (246 days old!!), 83825, 87291, 92065.  I imagine it affects
other arches as well.

Should there maybe perhaps be a new source upload to make sure this is cleared
up everywhere, and to close all of those ancient bugs?

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: Nautilus, Mozilla and KDE

[Adam C Powell IV]

Per Wigren wrote:

> onsdagen den 28 mars 2001 18:46 skrev [EMAIL PROTECTED]:
> > On Wed, Mar 28, 2001 at 07:55:12PM -0500, Per Wigren wrote:
> [snip]
> > > What about a newer Mozilla? 0.8.1 builds fine on Alpha Debian/Sid...
> >
> > if it builds fine that the buildd will build it however I haven't seen it
> > hit the buildd... I didn't even know 0.8.1 was uploaded to unstable...
>
> It's not. M18 is the latest in unstable. But 0.8.1 does build from the
> original sources.

This from debian-powerpc on March 6:

Ethan Benson wrote:

> Hi,
>
> Takuo KITAME built some unofficial 0.8 Mozilla packages, a simple
> upgrade of the existing M18 packages in debian now.  The debian
> mozilla maintainer is still working on totally revamping his packages
> which will take some more time (mail, chat and all that crap will be
> in seperate packages when he done it looks like) in the meantime these
> packages are clean, and made for debian, they are NOT alienized rpm
> crud.
>
> Takuo only built the packages for i386, i rebuilt them for powerpc and
> checked that they work.  i have made an aptable archive available on
> penguinppc.org, add:
>
> deb http://penguinppc.org/~eb/ ./
>
> to your /etc/apt/sources.list and if you have the debian M18 packages
> already installed a simply apt-get update && apt-get dist-upgrade will
> upgrade them.  if you have any mozilla rpms or alienized rpms
> installed remove them first.  then run apt-get update && apt-get
> install mozilla.
>
> These packages include psm built in and it does work (test done via
> the fortify.net ssl check).  Due to US export regulatations you cannot
> download these packages if you reside in one of the `blacklisted'
> nations.
>
> mail any mozilla problems to [EMAIL PROTECTED]
>
> enjoy.
>
> --
> Ethan Benson
> http://www.alaska.net/~erbenson/
>
>   
>Part 1.2Type: application/pgp-signature

HTH,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

Hello,

The -2 CPML and CXML packages are up, same place.  I optimistically
closed the wnpp ITP "bug" in the cxml package changelog, but we'll see.

The CPU check (grep "cpu model" /proc/cpuinfo | cut -b 14-) from Thomas
seems to work, it allows overrides but issues a stern warning if
installing ev6 packages on ev5, and a milder one the other way around.
Also, the cxml doc-base registration works now, a careless omission
broke it earlier.

Can't say I'll have any other installer packages done by the end of the
week, but if there are no comments I'll upload these on Friday and ITP
ccc, cfalrtl and cfal.

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

"T. Weyergraf" wrote:

> I'd be happy to provide any assistance, if desired. I have written some
> scripts, that cleans up
> the mess left behind, if the packages are installed on a Debian system using
> the rpm-deb.
> I can complete them for the various packages involved - currently they only
> cover
> the C-compiler, since that's the only one I use ;-)

Great, it sounds like we have a good team.  I'm no Debian packaging expert, but
have spent a fair amount of time studying the system.  For cpml and cxml, the
"cleanup" is pretty simple: postinst merely creates and strips the shared lib,
sets permissions appropriately, and puts the files where they should be in a
Debian system.  Oh- and registers the MASSIVE cxml documentation with doc-base
(though this doesn't work yet, and I've no idea why).

I'll try to add the /proc/cpuinfo | grep | cut trick for identifying system
type.  I think it only needs to prohibit installation of the ev6 packages on
pre-ev6 machines, because the ev5 libs will work on ev6 machines, right?  (In
case someone wants to install a uniform package list on a heterogeneous cluster
or something...)  I'll issue a warning for ev5 package installation on an ev6.

One important note: these packages start with just the files, meaning no scripts
are run from the RPM at all.  (Are RPM "postinst" scripts included in alienized
.debs?  If so, I'll have to figure out a way to get at them.)

That said, I know the ccc installer should run create-comp-config.sh (or perhaps
create its own comp.config), adding the correct libgcc.a directory, and make the
symlinks right.  Anything else important?  The current location of libgcc.a is
/usr/lib/gcc-lib/alpha-linux/2.95.3/ with gcc-2.95 installed, so the installer
will depend on gcc-2.95 for this.  If the location changes, there will have to
be a new version of the installer package...  Oh- and I'll have to figure out
how to do the ccc man pages right.

Okay.  Chris and Thomas (and others), could you glance over the cpml and cxml
packages for correctness?  I'll make a couple of changes to those two packages
(like CPU dependence) and put up -2 at some point today or tomorrow, then get to
work on ccc, cfal, cfalrtl, cxx and ladebug in approximately that order.

I do have one question for the Debian packaging experts.  I specified the
section for cpml-ev5 as contrib/libs in the control file, and dpkg -I on the
binary package shows it there too.  But when installed, dpkg -s and dselect list
cpml-ev5 under section compaq, along with the libots .deb (which should be in
compaq), and cxml-ev5 is in contrib/libs as it should be.  Anyone with any ideas
on why?

Thanks very much,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

Adam C Powell IV wrote:

> I have already put together such a package for CPML (ev5 and ev6), files
> are at http://lyre.mit.edu/~powell/compaq/ .
>
> I'd like for the installer to determine the processor type and abort if
> inappropriate, but don't quite know how.  Aside from that, I think it's
> ready to go, and I'll put up a CXML version in the next day or two.
> I'll upload by the end of the week if nobody gives a good reason not to.

CXML source and "binary" packages are up, same place.

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

   Welcome to the best software in the world today cafe!

ITP: CPML and CXML alpha installer packages

[Adam C Powell IV]

Package: wnpp
Severity: wishlist
License: GPL
Section: contrib/libs

Hello,

The (proprietary) Compaq compilers and libraries for Alpha processors
mostly come only in RPM format, and installing them on a Debian system
is not quite as straightforward as "alien".

To simplify the process, I'd like to put together a set of "installer
packages" based on the realplayer i386 package by Joey Hess and Brian
Russo.  Each package would use debconf to prompt the user for the
location of the RPM, then use an included rpm2cpio to extract the files,
install them, and modify as necessary according to Thomas Weyergraf's
email instructions (see the debian-alpha archive, "compiling" thread
starting 10/25/2000), including stripping the libs (so the installers
depend on binutils).

I have already put together such a package for CPML (ev5 and ev6), files
are at http://lyre.mit.edu/~powell/compaq/ .

I'd like for the installer to determine the processor type and abort if
inappropriate, but don't quite know how.  Aside from that, I think it's
ready to go, and I'll put up a CXML version in the next day or two.
I'll upload by the end of the week if nobody gives a good reason not to.

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: RPMs/Alien/Compaq CC/CPML combo!

[Adam C Powell IV]

Phil Carmody wrote:

> This is going to sound dumb, but you only learn by asking...
>
> I'd like to get CCC and the CPML up and running on my fairly bare bones Alpha 
> (Ruffian with Stable, and not much else).

The relevant tool is indeed alien (apt-get install alien should do it), but 
getting ccc to work is a bit involved.  Check the "compiling" thread in the 
archives starting last October 25 for detailed instructions.

Contrib packages which install the downloaded RPMs properly (like the 
realplayer package for i386) have been on my todo list since last November...  
Hopefully I'll get them done in time for woody!

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Re: current postgres/how stable unstable

[Adam C Powell IV]

Paul Slootman wrote:

> How about
> fakeroot apt-get source -b postgresql
> :-)

In the spirit of one-upsmanship, I have to contribute:

fakeroot apt-get build-dep postgresql

which automatically gets the source and all of the Build-Depends, then compiles
it!  (Requires apt >= 0.5.0, which is in unstable now.)

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: Why wouldn't gcc release build on Alpha ?

[Adam C Powell IV]

"Christopher C. Chimelis" wrote:

> Ok, here's what I do for all builds:
>  apt-get source 
> rather than using the '-b' option.  This unpacks the sources, but does not
> build.  Then, I go into the unpacked dir and look at debian/control (or in
> this case, debian/control.in, since the control file is generated at build
> time).  In there, you'll see a line that begins with:
>  Build-Depends:
> Which will list everything you need to build the package (or should...in
> the case of glibc, it will...I can vouch for that personally).

The Build-Depends line, if there is one, is also inserted into the downloaded
.dsc file, so you don't even need to look into package-ver/debian/control.

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!

Re: Need a copy of /sbin/termwrap

[Adam C Powell IV]

Paul Slootman wrote:

> On Sat 03 Feb 2001, Bob Ogden wrote:
>
> > So I thought that just droping a copy of termwrap in should resolve it.
> > Anyone willing to send me a copy?
>
> $ locate termwrap
> $ grep termwrap ../../Contents-alpha.gz
> $
>
> I have no idea what you're talking about, unfortunately...

We're having this confusion on PPC too.  I think it got into our base2_2.tgz
somehow, but dpkg doesn't show it anywhere, which is a bug.  (Only the install
kernel and modules should not show up in dpkg, and maybe a couple of other
things built by the installer like /etc/fstab.)

I guess it's not just a PPC problem...

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

  Welcome to the best software in the world today cafe!