From malekith at pld.org.pl  Fri Nov  9 17:07:49 2001
From: malekith at pld.org.pl (Michal Moskal)
Date: Fri, 9 Nov 2001 17:07:49 +0100
Subject: ankry: SPECS linux-BOOT.spec
In-Reply-To: <20011109160516.82E17E1076@wun.zie.pg.gda.pl>
Message-ID: <20011109170749.B31265@ep09.kernel.pl>

On Fri, Nov 09, 2001 at 05:05:16PM +0100, PLD CVS wrote:
> Module name:	SPECS
> Changes by:	ankry	01/11/09 17:05:15
> 
> Modified files:
> 	.              : linux-BOOT.spec 
> 
> Log message:
> - updatd reiserfs patch

Oh well, I guess this spec isn't used anymore...

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:    Linux: We are dot in .ORG.    |                : {b,e>+}++ !tv h
: CurProj: ftp://ftp.pld.org.pl/people/malekith/ksi : PLD Team member


From klakier at pld.org.pl  Sat Nov  3 14:34:47 2001
From: klakier at pld.org.pl (=?iso-8859-2?q?Rafa=B3?= Kleger-Rudomin)
Date: 03 Nov 2001 14:34:47 +0100
Subject: Mirrors
Message-ID: <m3n124nfk8.fsf@zolw.dom>


Hello!

The following mirrors cause problems:
ftp://fr.rpmfind.net/linux/PLD
ftp://fr2.rpmfind.net/linux/PLD

First one does not allow directory listing ("cd RPMS; ls *" -> "List failed")
Second one seems to be incomplete (i.e. it lacks mozilla and poldek)

Regards,
Rafal

-- 
Rafa? Kleger-Rudomin (klakier at pld.org.pl)


From wrobell at ite.pl  Sun Nov 11 21:34:44 2001
From: wrobell at ite.pl (wrobell)
Date: Sun, 11 Nov 2001 21:34:44 +0100
Subject: python packages - rpm support
Message-ID: <20011111213444.A6265@pred.wroc.pl>

New rpm (rel. 43) contains pythonprov subpackage
with python macros which should be
used to build python modules (programs).

Every spec file with python stuff should contain:
%include /usr/lib/rpm/macros.python

For examples look into:
- python-ldap.spec
- python-SOAP.spec
- python-egenix-mx-base.spec 
- python-PyXML.spec
- python-numpy.spec
- python-4Suite.spec

BTW. The last one should be fixed to include only *.py? files.

    wrobell <wrobell at ite.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20011111/e94524d7/attachment.sig>

From jajcus at pld.org.pl  Mon Nov 12 11:22:28 2001
From: jajcus at pld.org.pl (Jacek Konieczny)
Date: Mon, 12 Nov 2001 11:22:28 +0100
Subject: python packages - rpm support
In-Reply-To: <20011111213444.A6265@pred.wroc.pl>
Message-ID: <20011112112228.E3053@nic.bnet.pl>

On Sun, Nov 11, 2001 at 09:34:44PM +0100, wrobell wrote:
> BTW. The last one should be fixed to include only *.py? files.
I don't like the idea of making binaries from scripts.
One of advantages of scripting languages is that you can look into the
code whenever you want.

Greets,
        Jacek


From wrobell at ite.pl  Mon Nov 12 11:37:27 2001
From: wrobell at ite.pl (wrobell)
Date: Mon, 12 Nov 2001 11:37:27 +0100
Subject: python, perl - byte compiled files
In-Reply-To: <20011112112228.E3053@nic.bnet.pl>
References: <20011111213444.A6265@pred.wroc.pl> <20011112112228.E3053@nic.bnet.pl>
Message-ID: <20011112113727.A2498@pred.posexperts.com.pl>

On Mon, Nov 12, 2001 at 11:22:28AM +0100, Jacek Konieczny wrote:
> On Sun, Nov 11, 2001 at 09:34:44PM +0100, wrobell wrote:
> > BTW. The last one should be fixed to include only *.py? files.
> I don't like the idea of making binaries from scripts.
> One of advantages of scripting languages is that you can look into the
> code whenever you want.
It was discussed some time ago and it has been decided that we distribute
only binary byte compiled files. It is the same case as in Java language,
where we distribute only *.class files (byte compiled) and not sources at all.
If you really need sources you can download .src.rpm.

I think, when Perl arrives with its own virtual machine and byte compiler
then we will distribute only binaries, too.

    wrobell <wrobell at ite.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20011112/a5e0cf4f/attachment.sig>

From dobrek at itp.uni-hannover.de  Wed Nov 14 14:18:06 2001
From: dobrek at itp.uni-hannover.de (Lukas Dobrek)
Date: Wed, 14 Nov 2001 14:18:06 +0100
Subject: Future of AXP
Message-ID: <20011114141805.A14787@zibal.itp.uni-hannover.de>


I think it can be interesting for some of you.

Lukasz


----- Forwarded message from "William H. Magill" <magill at isc.upenn.edu> -----

> Delivered-To: axp-list at listman.redhat.com
> From: "William H. Magill" <magill at isc.upenn.edu>
> To: axp-list at redhat.com
> Subject: Alpha roadmap
> Errors-To: axp-list-admin at redhat.com
> X-BeenThere: axp-list at redhat.com
> X-Mailman-Version: 2.0.1
> Precedence: bulk
> Reply-To: axp-list at redhat.com
> List-Help: <mailto:axp-list-request at redhat.com?subject=help>
> List-Post: <mailto:axp-list at redhat.com>
> List-Subscribe: <https://listman.redhat.com/mailman/listinfo/axp-list>,
>                 <mailto:axp-list-request at redhat.com?subject=subscribe>
> List-Id: Linux and Red Hat on Alpha processors <axp-list.redhat.com>
> List-Unsubscribe: <https://listman.redhat.com/mailman/listinfo/axp-list>,
>                   <mailto:axp-list-request at redhat.com?subject=unsubscribe>
> List-Archive: <https://listman.redhat.com/mailman/private/axp-list/>
> Date: Tue, 25 Sep 2001 15:36:29 -0400 (EDT)
> 
> >   From: kjetil.bugge at borregaard.com
> >   Date: Mon, 10 Sep 2001 09:59:14 +0200
> >
> >   Jay, I see that you are an employee of Compaq
> >
> >   Do you have any clue of what is happening with the Alpha-processor, now
> >   when HP is taking over Compaq ?
> >   Maybe you have some "inside" information....... ;-)
> 
> Compaq employees are in the "quiet period" mandated by the Securities and
> Exchange commision. Technically, they can't comment on things without
> clearing it with "the lawyers."
> 
> However, I have a copy of the Alpha/IPF and Tru64 Roadmap Power Point
> presentations from the CETS2001 conference last week. Nothing new in them. 
> (They can be distributed but are about a meg or two in size. If you
> attended the conference, they are now all on the conference web site for
> download. www.cets2001.com)
> 
> Basically EV 8 is now history. Scheduled (most recently) for 2004 it has
> been canceled completely, being replaced with an EV7/9 speed-bump in late
> 2003.
> 
> In place of the EV8 in 2004, Compaq will begin building "alphas" with IA64
> chips.
> 
> Alpha based processors themselves will supposedly still be built and sold
> through about 2006-10ish time frame. It all depends on if there are any
> people out there who still want to buy the old boxes, nominally EV7/9
> based.
> 
> [My personal prediction is that HP-Q won't be selling many alpha
> systems past 2003 except to existing customers who are software trapped.
> Unless my other prediction proves true -- the Madison and it's follow-on
> still will run slower than the EV7/9 through about 2008. Madison won't be
> around until 2006, not 2004 as projected, and the IPF follow-on won't see
> the light of day until 2-4 years after that.... even with all of the Alpha
> design engineers going to work at Intel. In fact, I'm not even convinced
> that we will see McKinley before 2004. (And forget about SPARC4, it will be
> the next chip abandoned.)]
> 
> Support (hardware and software) for the Alpha platforms will probably last 
> through 2010-2015, again depending upon market demand and existing
> contracts. 
> 
> Today, Tru64 runs on the IA64. Project Bravo ported the 4.x code stream
> some two years ago.  All of the nasty Compiler technology was developed
> then. The current 5.x code stream has apparently been completely ported
> (read re-compiled) already. 
> 
> [I'm still bitching at people, but there are currently no plans in the
> road-map to make the Tru64 on IA64 OS available outside of Compaq -- even
> though this would give Tru64 a 2-3 year jump on HP-UX as both a 64 bit OS
> and one that runs on IA64. But that statement was made last week before the
> Lawyers said, no you can't talk to HP until the merger is approved. So
> there is some hope.] 
> 
> Open VMS and NSK are expected to take about 2 years to port to IA64.
> 
> In the interum will come ?maybe? the HP-Compaq "merger." Unlike the
> GE-Honeywell failure, today's (25 Sept) meeting between the US and EU
> Anti-trust folks, in a "post WTC" environment, are likely to pave the way 
> for a rapid approval... but who knows. If the process IS speed-ed up and
> the approval given, first half of 2002 still seems like a reasonable date
> for shareholder approvals.
> 
> One last point, Samsung can still make all the Alphas it wants to, but I
> don't believe that it does.
> 
> > Fortunately, HP knows much more about former DEC than Compaq did and
> > does. I'm pretty sure, they (HP) know exactly, what they have
> > purchased. The DEC part of Compaq and HP are companies very much alike.
> >
> HP and DEC are (or were) alike only in that the original companies 10+
> years ago were run by engineers. Today both HP and Compaq are run by
> Financial people. And if HP thinks it purchased a working Services
> organization, they are buying the same crock that Compaq got from Digital.
> 
> Interestingly, amost 50% of HP's revenue comes from its printer division.
> The merged company will have a roughly even split between the 4 divisions
> -- Printers/PCs/Servers/Services. If that is good "asset allocation" or
> not, only time will tell.
> 
> Don't forget that Fiorina was in a desperate condition -- she had to get
> revenues up, and since she couldn't fix the company (she tried that the
> year before and they continued to spiral downward), she went out an bought
> "increased revenues." 
> 
> > So the only thing that puzzles me, is why Compaq got rid of Alpha in
> > june. Was this part of the plan together with HP?
> 
> No, I think it had as much to do with Intel killing off AMD by getting rid
> of the largest purchaser of AMD chips.
> 
> Well, the IA64 announcement was something like June 24th... something like
> 10 days later Fiorina and Capellas met for lunch.
> 
> -- 
>                         www.tru64unix.compaq.com
>                               www.tru64.org
>                              comp.unix.tru64
>                         
> T.T.F.N.
> William H. Magill                          Senior Systems Administrator
> Information Services and Computing (ISC)   University of Pennsylvania
> Internet: magill at isc.upenn.edu             magill at acm.org
> http://www.isc-net.upenn.edu/~magill/
> 
> 
> 

----- End forwarded message -----

-- 
?ukasz Dobrek
   An optimist believes that we live in the best of all possible worlds.
   A pessimist is sure that this must be so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20011114/c35ae0ad/attachment.sig>

From pawelk at ep09.kernel.pl  Sat Nov 17 15:01:40 2001
From: pawelk at ep09.kernel.pl (pawelk at ep09.kernel.pl)
Date: 17 Nov 2001 14:01:40 -0000
Subject: [MBT] new entry in pkg rpm "test mbt"
Message-ID: <20011117140140.29169.qmail@ep09.kernel.pl>


Date: 2001-11-17 15:01:35+01	Author: pawel kolodziej(pawelk2) <pawelk at sokrates.mimuw.edu.pl> 		
Title:         test mbt	
Ticket ID:     #2
Package:       rpm-4.0.2-42
Distribution:  PLD-1.0.beta.main
Cathegory:     unknown
Current state: closed -- resolved
Text:

last test


From malekith at pld.org.pl  Tue Nov 27 14:34:49 2001
From: malekith at pld.org.pl (Michal Moskal)
Date: Tue, 27 Nov 2001 14:34:49 +0100
Subject: qboosh: SPECS fortune-mod-bofh-excuses.spec
In-Reply-To: <20011127093550.54279E1004@wun.zie.pg.gda.pl>
Message-ID: <20011127143449.A29224@ep09.kernel.pl>

On Tue, Nov 27, 2001 at 10:35:50AM +0100, PLD CVS wrote:
> Module name:	SPECS
> Changes by:	qboosh	01/11/27 10:35:50
> 
> Modified files:
> 	.              : fortune-mod-bofh-excuses.spec 
> 
> Log message:
> - pl summary

btw: it is wrong, .dat file should be regenerated, as it was done
on some 64 bit arch. Probably .dat file generatation should be fixed
to always use 32 bit (or 64 bit, but the same on all archs), index
size, as the file goes to /usr/share/*. (endian stuff is handled
correctly).

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:    Linux: We are dot in .ORG.    |                : {b,e>+}++ !tv h
: CurProj: ftp://ftp.pld.org.pl/people/malekith/ksi : PLD Team member