Hi all,
for all, who are interested, we have uploaded sources
and binaries for XFree86 3.3.6 under QNX6 to:
http://sourceforge.net/projects/openqnx/
Other QNX6 ports are at:
http://sourceforge.net/projects/pyqnx/
Enjoy,
Jutta
STEINHOFF Automation- & Fieldbus-Systems
http://www.dachs.net
Jutta Steinhoff <j-steinhoff@web.de> wrote:
Hi all,
for all, who are interested, we have uploaded sources
and binaries for XFree86 3.3.6 under QNX6 to:
Binaries? I don’t see these listed anywhere in the soureforge interface
(which I find confusing as heck!). Do you have a direct URL to the
binaries? Don’t suppose you have thought of making this into a
package with packager have you?
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Chris McKillop wrote:
Jutta Steinhoff <> j-steinhoff@web.de> > wrote:
Hi all,
for all, who are interested, we have uploaded sources
and binaries for XFree86 3.3.6 under QNX6 to:http://sourceforge.net/projects/openqnx/
Binaries? I don’t see these listed anywhere
You was too fast 
Have a look now…
in the soureforge interface (which I find confusing as heck!).
Do you have a direct URL to the binaries?
http://sourceforge.net/project/showfiles.php?group_id=21249
Don’t suppose you have thought of making this into a
package with packager have you?
No, … do you believe that the packager is currently able to
handle such a big project ??
BTW, for those who have already downloaded the sources:
… the release notes are updated!
Before you compile:
Jutta
Jutta Steinhoff <j-steinhoff@web.de> wrote:
You was too fast >
Ahhh! 
You posted too fast!
No, … do you believe that the packager is currently able to
handle such a big project ??
For sure - easy as pie. Basically setup a a “mock root” say
/home/cdm/fake-root and mimick the file locations in / from that
point on and run packager.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Previously, Chris McKillop wrote in qdn.public.qnxrtp.os:
Jutta Steinhoff <> j-steinhoff@web.de> > wrote:
You was too fast >
Ahhh! >
No, … do you believe that the packager is currently able to
handle such a big project ??
For sure - easy as pie. Basically setup a a “mock root” say
/home/cdm/fake-root and mimick the file locations in / from that
point on and run packager.
This is very mis-leading advice, Chris. I have had such overwhelming
problems with the packager that at this point I treat it as being a
“sometime when I’m bored” project to get our software into packages
again. The packager makes a number of undocumented and unintuitive
decisions on your behalf while splitting your files into the various
dev, x86, base, etc. components, and then seems unable to remember
what it did the last time, so that you have to go through the tedious
questionnaire every time you re-package your software. From a
developer’s standpoint, this is unusable. When I gave a complete
package that the package manager would not even recognize to somebody
at QSSL I was told to “start from scratch - the .qpm must be corrupt”,
which is just about the most ludicrous thing I have ever heard. It’s
a text file. It contains human-readable, formatted text. If it’s
corrupt, then a knowledgeable reader with access to the packager
specification should have a 100% chance of figuring out where it is
“corrupt”, and suggesting a fix. At this point, the packager is
highly resistant to automatically generating and re-generating
packages - it is a labour intensive and mystical process that is as
bound to fail as it is to succeed.
Cheers,
Andrew
Andrew Thomas <Andrew@cogent.ca> wrote:
For sure - easy as pie. Basically setup a a “mock root” say
/home/cdm/fake-root and mimick the file locations in / from that
point on and run packager.This is very mis-leading advice, Chris. I have had such overwhelming
problems with the packager that at this point I treat it as being a
“sometime when I’m bored” project to get our software into packages
again. The packager makes a number of undocumented and unintuitive
decisions on your behalf while splitting your files into the various
dev, x86, base, etc. components, and then seems unable to remember
what it did the last time, so that you have to go through the tedious
questionnaire every time you re-package your software.
Dunno about that Andrew. In under 10 minutes I had a 36M .qpr of all
the XFree stuff that installed like a breeze. As for having to
answer all the questions again, you must have skipped the use message.
(from ‘use packager’)
-m use an existing QPM, QPK, or QPR to get default values
-u unattended operation–do not prompt the operator
So you can basically do this…
packager -b+ -f . -m vim-6.0aa-x86-cdm.qpr -u /path/to/fake_root
Easy as pie. This is how I do all of the packages on my webpage
(http://staff.qnx.com/~cdm) and I have only had some strange stuff
happen once in a while when packager inserted some bad text into
one of the fields. Normally I am able to do stuff pretty wiz-bang.
For example, I did up a links package in under 15 minutes from
download to package on my webpage.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Previously, Chris McKillop wrote in qdn.public.qnxrtp.os:
Andrew Thomas <> Andrew@cogent.ca> > wrote:
For sure - easy as pie. Basically setup a a “mock root” say
/home/cdm/fake-root and mimick the file locations in / from that
point on and run packager.This is very mis-leading advice, Chris. I have had such overwhelming
problems with the packager that at this point I treat it as being a
“sometime when I’m bored” project to get our software into packages
again. The packager makes a number of undocumented and unintuitive
decisions on your behalf while splitting your files into the various
dev, x86, base, etc. components, and then seems unable to remember
what it did the last time, so that you have to go through the tedious
questionnaire every time you re-package your software.
Dunno about that Andrew. In under 10 minutes I had a 36M .qpr of all
the XFree stuff that installed like a breeze. As for having to
answer all the questions again, you must have skipped the use message. >(from ‘use packager’)
-m use an existing QPM, QPK, or QPR to get default values
-u unattended operation–do not prompt the operatorSo you can basically do this…
packager -b+ -f . -m vim-6.0aa-x86-cdm.qpr -u /path/to/fake_root
Easy as pie. This is how I do all of the packages on my webpage
(> http://staff.qnx.com/~cdm> ) and I have only had some strange stuff
happen once in a while when packager inserted some bad text into
one of the fields. Normally I am able to do stuff pretty wiz-bang.
For example, I did up a links package in under 15 minutes from
download to package on my webpage.
Problems:
packager alters the license URL, so that using -m -u does not find
a license URL in a file a second time.
packager creates, for example, “dev” packages based on its own
undocumented criteria, which package-installer cannot install from
a repository. package-installer wants a “base” package, which
packager does not necessarily create with the “dev”. In one case,
packager added extra prefixes in subsequent builds, so we ended up
with a -dev-dev- package on the second rebuild. We could not make
it go away no matter how we altered the .qpm.
package-installer does not recognize a versioned build using -b+
as being a new package, so it will not re-install when you create a
new one.
When the packager breaks your files into multiple pieces, it
rearranges its .qpm, and creates new .qpms, so you don’t have the
same input .qpm in subsequent builds. My observation has been that
packager misses things in rebuilds.
If you want to hand-alter the .qpm to correct a mistake for
example, there is no documentation on the inter-relationships among
keys in the file, nor about which of these will be magically
over-ridden by the packager, not about which is optional versus
mandatory. With the exception of correcting small typos, you have
no choice but to re-run the interactive packager and hope for the
best.
The package-installer will only install from a repository as .qpk
files, but will only install from file from a .qpr file. With this
system it is no longer possible to keep a single package that can
be both a) downloaded by FTP, b) installed through
package-installer from a repository, and c) e-mailed.
The license file is stored external to the packages in a
repository, which presents a legal issue. People can download and
install the .qpk packages without agreeing to the license.
You examples of your packaging experiences are not really reflective
of a development environment. I imagine I could find the path through
the packager that works for a functioning package that I downloaded
from the web and compiled. That’s not development, it’s wrapping a
running program, with no special care necessary for presentation,
modifiability, license, or the normal alterations that occur to a
program during its development lifetime. I reject the notion that a
package is a final step that you perform once every 6 months when you
want to make a product release (presumably then it doesn’t matter how
much trouble it is to do). We make packages of our development
software constantly, and use our release mechanisms as the way to
distribute test builds among developers internally. This ensures that
we have complete packages at the end of any development phase, and
helps us to organize our build process better.
I can make a self-extracting shell archive or a stowable tarball in no
time flat on any system. The packager has been a real battle for us.
I think the idea is great, but the implementation falls short.
If there was one over-riding change that the packager needs, it is
this: stop modifying your input files. Modifying URLs, modifying file
organizations, re-naming packages, splitting packages, etc. are all
fine in the output, but these changes should not be written back
into the input for the next iteration. Up until now, I have always
thought of this as a fundamental tenet of any build process.
We’d like to use the packager, really we would, but it is not in a
state right now where it is viable in a production environment, at
least not in ours.
Cheers,
Andrew