I have a few questions relating to pike in Debian (as you may know, the previous maintainer has retired from Debian and orphaned his packages).
I've figured out that one can get a fresh tarball from http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest. What's the difference between that and checking out from CVS and running "make source" (which is what I suspect Marek has done), if any? Is there any archive of such tarballs except for the official releases?
How did the packaging/debian subdirectory originally come to be? Do you synchronize with the Debian package yourself or has Marek been sending you patches? I see that export.pike adds new records to packaging/debian/changelog. AFAICT, export.pike --tag first increments the build number (to an even number, typically), then tags, then increment the build number again, so that an even build number represents a known state of the source, whereas an odd build number can include any number of commits inbetween.
I've figured out that one can get a fresh tarball from http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest. What's the difference between that and checking out from CVS and running "make source" (which is what I suspect Marek has done), if any? Is there any archive of such tarballs except for the official releases?
The dists from Pikefarm are untagged and are bundled with gmp and nettle (snapshot_export).
By checking out from CVS you won't get the bundles. Building straight from CVS also requires an installed Pike (for Pike 7.2 and later).
The release dists are the same as the Pikefarm dists, but are tagged (full_export).
How did the packaging/debian subdirectory originally come to be? Do you synchronize with the Debian package yourself or has Marek been sending you patches? I see that export.pike adds new records to
Marek has commit access to the Pike repository.
packaging/debian/changelog. AFAICT, export.pike --tag first increments the build number (to an even number, typically), then tags, then increment the build number again, so that an even build number represents a known state of the source, whereas an odd build number can include any number of commits inbetween.
Correct.
The dists from Pikefarm are untagged and are bundled with gmp and nettle (snapshot_export).
OK, but you can easily avoid using them in the build, can't you? Because Debian generally prefers shipping "official" tarballs (so that you can easily compare checksums).
I'm not sure that autogenerating debian/changelog entries is that meaningful. They should at least say "UNRELEASED" instead of "unstable", to reflect which versions have actually been in Debian. Actually, all the versions uploaded to Debian have been odd-numbered snapshots, contrary to the plea in packaging/README.
The "orig" tarballs made by Marek also contain autogenerated documentation (modref and traditional_manual), which the official tarball does not. While not a technical problem, it's still not quite right, I believe.
On Thu, May 17, 2007 at 12:45:00PM +0000, Magnus Holmgren, FR Ryd (Nu med m�l och syfte) @ Pike (-) developers forum wrote:
The dists from Pikefarm are untagged and are bundled with gmp and nettle (snapshot_export).
OK, but you can easily avoid using them in the build, can't you?
yes, i believe the bundles are only used if no other version on the system is found simply to make it easier on the user and not force them to find those packages themselves. (nettle and gmp are pretty much required to build a usable pike, while other things are optional. (i think there was discussion whether to bundle pcre as well)
i pretty much agree with your other points.
greetings, martin.
Debian hasn't been shipping the official tar balls though since Pike releases are to few and far between.
I think it would be nice if you'd release some unofficial tar balls inbetween the official ones (maybe providing the last three ones, or the last month's worth, is sufficient).
The goal is still one complete release every other month unless there is absolutely no changes in the repository. Which we are getting closer to. Windows builds finally got completely automated in the last release which has been the only major road block left.
I was going to release a new beta and Debian packages this weekend, but my broad band provider thought it would be funny to disable my network this morning, so we'll see if I have it back in time to do something.
So, after a long while, here is what I suggest you do with export.pike (the values of debian_rev and signature are merely placeholders).
--- bin/export.pike.old 2007-09-26 18:29:20.000000000 +0200 +++ bin/export.pike 2007-09-26 21:27:31.000000000 +0200 @@ -107,20 +107,29 @@
s = Stdio.read_file(pike_base_name+"/packaging/debian/changelog"); if (s) { + constant debian_rev = "0pikeauto"; + constant signature = "Pike Autobuilder xenofarm@pike.ida.liu.se" werror("Bumping Debian changelog.\n"); array(int) version = getversion(); - s = sprintf("pike%d.%d (%d.%d.%d-1) unstable; urgency=low\n" + + int sigpos = search(s, "\n -- ") + 5; + if (s[sigpos .. (sigpos+strlen(signature)-1)] == signature) { + s = s[(search(s, "\n", sigpos) + 2) ..]; + } + + s = sprintf("pike%d.%d (%d.%d.%d-%s) UNRELEASED; urgency=low\n" "\n" + " * %s\n" "\n" - " -- Marek Habersack grendel@debian.org %s\n" + " -- %s %s\n" "\n" "%s", version[0], version[1], - version[0], version[1], version[2], + version[0], version[1], version[2], debian_rev, is_release? "Release number bumped by export.pike.": "The latest cvs snapshot", + signature, Calendar.Second()->format_smtp(), s); Stdio.write_file(pike_base_name+"/packaging/debian/changelog", s);
Right, but the users don't know that. :-)
What do you suggest then? debian_rev = "0snapshot" and signature = "Pike Snapshot Export snapshots@pike.ida.liu.se"?
However: As you write in packaging/README, export.pike increments the build number twice, so that the the first version number (usually even for the 7.6 series, but odd for 7.7.x) represents a well-defined, unambigous state, whereas the second number (normally odd) encompasses all commits inbetween. You "would like only these 'unambigous' builds to be exported as packages to the world", and I agree. Yet almost all of Marek's uploads were odd versions ("The latest cvs snapshot."). I propose a scheme where official stable releases are uploaded to Debian unstable (if needed, selected patches from CVS can be applied), and packages based on tarballs like http://pike.ida.liu.se/generated/pikefarm/packages/7.%7B6,7%7D/latest [1] (but unambiguous versions would be preferred) are uploaded to experimental regularly.
Now, if we're going to follow this schedule and keep the debian packaging in Pike's CVS like before, there's gonna be obvious chronological problems. From the point of view of the Pike trunk, each series of Debian revisions based on a particular Pike version is a separate branch, but from the point of view of the Debian package, there is just one, parallel, branch, which from time to time pulls in new upstream versions. There's nothing wrong with keeping the Debian packaging in Pike CVS, but it should be kept in a separate tree. Otherwise ./packaging/debian should be moved to ./debian, development of it be more closely integrated with the main source, and pike?.? be made so-called native packages, but that's not recommended.
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and .../7.7/)? "file" identifies the format as "Raw G3 data" (Group 3 fax??), but that can't be right. It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of interest)?
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and
Looks like an ufs directory file to me...
What do you suggest then? debian_rev = "0snapshot" and signature = "Pike Snapshot Export snapshots@pike.ida.liu.se"?
It would be reasonable to have the mail address of whoever made the build. It would also be reasonable to not have the Pike export automatically update the debian packaging files though.
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and .../7.7/)? "file" identifies the format as "Raw G3 data" (Group 3 fax??), but that can't be right. It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of interest)?
The mountpoint at /generated/pikefarm/packages/7.7/ is handled by the xenofarm_fs module which you can find if you check out xenofarm from :pserver:anonymous@cvs.lysator.liu.se:/cvsroot/xenofarm
What you are actually getting though I have no idea. Looks like some very weird bug to me.
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and .../7.7/)? "file" identifies the format as "Raw G3 data" (Group 3 fax??), but that can't be right. It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of interest)?
The mountpoint at /generated/pikefarm/packages/7.7/ is handled by the xenofarm_fs module which you can find if you check out xenofarm from :pserver:anonymous@cvs.lysator.liu.se:/cvsroot/xenofarm
What you are actually getting though I have no idea. Looks like some very weird bug to me.
I would bet it's a case of "not implemented", as there wasn't any page linking there -- in other words it's almost, if not quite, a 404 page. Patches to xenofarm_fs adding wanted functionality (if any) there, are probably welcome. :-)
I propose a scheme where official stable releases are uploaded to Debian unstable (if needed, selected patches from CVS can be applied), and packages based on tarballs like http://pike.ida.liu.se/generated/pikefarm/packages/7.%7B6,7%7D/latest [1] (but unambiguous versions would be preferred) are uploaded to experimental regularly.
Sure. Should it be automated?
Now, if we're going to follow this schedule and keep the debian packaging in Pike's CVS like before, there's gonna be obvious chronological problems. From the point of view of the Pike trunk, each series of Debian revisions based on a particular Pike version is a separate branch, but from the point of view of the Debian package, there is just one, parallel, branch, which from time to time pulls in new upstream versions. There's nothing wrong with keeping the Debian packaging in Pike CVS, but it should be kept in a separate tree. Otherwise ./packaging/debian should be moved to ./debian, development of it be more closely integrated with the main source, and pike?.? be made so-called native packages, but that's not recommended.
We can move to packaging files to a separate module if that helps.
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and .../7.7/)? "file" identifies the format as "Raw G3 data" (Group 3 fax??), but that can't be right.
As marcus said it's probably a raw UFS directory node. Aka a bug for an unhandled call.
It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of >interest)?
There is no repository of old tar-balls because they aren't saved. They are volatile pieces of source that should only be used for testing. If you must retrieve an old snapshot you can use the date tag shown in Pikefarm.
I propose a scheme where official stable releases are uploaded to Debian unstable (if needed, selected patches from CVS can be applied), and packages based on tarballs like http://pike.ida.liu.se/generated/pikefarm/packages/7.%7B6,7%7D/latest [1] (but unambiguous versions would be preferred) are uploaded to experimental regularly.
Sure. Should it be automated?
It can be, but it can be a good idea with some manual inspection even when uploading to the experimental distribution.
We can move to packaging files to a separate module if that helps.
Yes, I think it would.
It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of >interest)?
There is no repository of old tar-balls because they aren't saved. They are volatile pieces of source that should only be used for testing. If you must retrieve an old snapshot you can use the date tag shown in Pikefarm.
It helps if there is an official upstream tarball that you can compare the .orig.tar.gz from Debian to, but it's perhaps not that important in experimental.
It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of >interest)?
There is no repository of old tar-balls because they aren't saved. They are volatile pieces of source that should only be used for testing. If you must retrieve an old snapshot you can use the date tag shown in Pikefarm.
It helps if there is an official upstream tarball that you can compare the .orig.tar.gz from Debian to, but it's perhaps not that important in experimental.
The test snapshots really shouldn't be used to make Debian packages. They should use a proper make export build.
The test snapshots really shouldn't be used to make Debian packages. They should use a proper make export build.
Yeah, that's what I'm trying to say too. But aren't http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest and http://pike.ida.liu.se/generated/pikefarm/packages/7.7/latest made the same and proper way, just from perhaps-not-stable source? If so they should be good enough for the experimental dist.
Source packages made by pikefarm are _more_ likely to contain bugs than if you make a CVS snapshot at a random time. This is because they are made (almost) immediately when someone checks in new functionality which might break on some platform. Even if the bug is quickly found and corrected, there will be some time before a new build is made.
You're talking of source packages made by pikefarm from arbitrary states of the repository, aren't you? Because I'd hoped that the manual exports (e.g. 7.6.114 and 7.6.116) were a bit less, well, arbitrary.
Yes, I expected /generated/pikefarm/packages to contain such packages, and not ones which have been manually exported. Was I wrong?
I suppose not.
But I didn't outright suggest that those packages be used. I suggested that properly generated tarballs be used, _like_ those, but preferably in a more controlled state. Still, everything goes in experimental - as packages.debian.org warns: "This package is from the experimental distribution. That means it is likely unstable or buggy, and it may even cause data loss."
Those tarballs are made by checking out a pristine pike tree from CVS, and running "make snapshot_export". In your case, preferrably checking out with cvs -D <iso8601timestamp>, picking a suitable UTC time from one of the appropriate times when export.pike tagged a "stable" tree.
A fairly good (if perhaps slightly cumbersome) way of finding such UTC timestamps is to parse the JSON output from
http://pike.ida.liu.se/_/cvsview/commits/7.7/src/version.h?u=Pike&f=2007...
for the second commit to src/version.c with a commit message matching "release number bumped to * by export.pike", the * of which is the build number. Its "T" key is the <iso8601timestamp> timestamp in UTC. (Feel free to vary the &f= argument to later dates, as you move on, as one possible method for filtering for only new builds since last time you ran your script.)
Presently, that thus means the relevant checkin is
{ "dt":1, "module":"Pike", "repository":"Pike", "committer":"peter", "t":1181472961, "T":"2007-06-10 10:56:01", "message":"release number bumped to 33 by export.pike", "files":[{ "add":2, "rem":2, "tot":15, "change":"edit", "ancestor":"1.390", "revision":"1.391", "path":"7.7/src/version.h", "dl":"http://pike.ida.liu.se/cvs/Pike/7.7/src/version.h?1.391", "show":"http://pike.ida.liu.se/development/cvs/view.xml?module=Pike&file=7.7/src...", "diff":"http://pike.ida.liu.se/development/cvs/diff.xml?module=Pike&file=7.7/src..." }]
and its timestamp thus 2007-06-10 10:56:01 UTC.
Those tarballs are made by checking out a pristine pike tree from CVS, and running "make snapshot_export". In your case, preferrably checking out with cvs -D <iso8601timestamp>, picking a suitable UTC time from one of the appropriate times when export.pike tagged a "stable" tree.
For builds by pikefarm this is indeed true.
for the second commit to src/version.c with a commit message matching "release number bumped to * by export.pike", the * of which is the build number. Its "T" key is the <iso8601timestamp> timestamp in UTC. (Feel free to vary the &f= argument to later dates, as you move on, as one possible method for filtering for only new builds since last time you ran your script.)
For builds created by make export it's better to use the tag generated at export. eg
cvs update -r v7_7_33
True; I forgot about the classic way. :-)
Which makes me wonder if I ever got to JSONifying pikefarm's data too. Probably not yet.
How did the packaging/debian subdirectory originally come to be?
The idea was that since the Debian packages of Pike broke much Pike functionality and we (upstream Pike developers) knew and saw so little of what happened when with the Debian Pike port, except feedback from Debian users that ended up with us instead of in the Debian package's bug reports where they are supposed to go,
(...dang, I'm stuck in endless sentence mode! ...oh, well.)
...we invited the code to live directly in the Pike codebase, where it would at least be visible to us, even if the Debian maintainer's decisions on packaging were still final (I think people tried to help point out patches that prevented Debian's pike from building external modules, but stopped, when there was little action to re-enable that).
There is some info in packaging/README too about these things, without going into that level of detail on the history that led to the present repository layout (no need spilling reader time on past events). It proved a good idea, and other package systems were invited with open arms too, so we now have fink there as well. It was also the natural spot to put the rather exotic Windows build procedure, once devised.
On Thu, May 17, 2007 at 11:25:06AM +0000, Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum wrote:
The idea was that since the Debian packages of Pike broke much Pike functionality and we (upstream Pike developers) knew and saw so little of what happened when with the Debian Pike port, except feedback from Debian users that ended up with us instead of in the Debian package's bug reports where they are supposed to go, ...we invited the code to live directly in the Pike codebase, where it would at least be visible to us, even if the Debian maintainer's decisions on packaging were still final (I think people tried to help point out patches that prevented Debian's pike from building external modules, but stopped, when there was little action to re-enable that).
these issues have been fixed by marek a long time ago! all it took was a bug report to the debian bugtracking system and a few pointers as to what exactly was broken along with suggestions to fix it.
in general i believe that things like the debian/ stuff should always go with the rest of the source to make it easier for anyone else to use it and build their own packages if they so desire.
greetings, martin.
The reply did not intend to bash Debian (or sound snarky), but to reply to the question on what initially prompted the good idea of keeping dist building scripts in the pike repository in the first place. It is still a good idea for lots of reasons, whether there remains any issues with particular custom builds or not.
I have a few questions relating to pike in Debian (as you may know, the previous maintainer has retired from Debian and orphaned his packages).
Marek has sent all of his scripts (that wasn't in CVS) to Peter Bortas who creates the "official" Pike packages and Peter has been working on creating Debian packages with Mareks procedures as base.
I have new packages for oldstable (sarge) if someone wants to test. If all goes as planned I'll complete my tests of that and set up automatic builds of stable and experimental this weekend.
hmm, wouldn't the pikefarm builds make suitable snapshots?
on the chart you can easely see whether the snapshot passed the testsuite, so you know it's a reasonable candidate for use.
greetings, martin.
You mean http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest?
I was expecting Debian source and binary packages. Pike is still orphaned in Debian, and I'm wondering if anyone is going to adopt it; otherwise I'm willing to.
yes,
i was relating them to the "Snapshot tarballs" part of the subject.
greetings, martin.
On Mon, 6 Aug 2007, Magnus Holmgren, FR Ryd (Nu med m??wrote:
Hi all!
I've been involved in pike in debian a little bit before etch release.
If you will take the lead on the pike-packages I'll help out.
I'm not yet a debian developer.
I think the first thing is to get 7.6.112 into the update of stable ?
You mean http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest?
I was expecting Debian source and binary packages. Pike is still orphaned in Debian, and I'm wondering if anyone is going to adopt it; otherwise I'm willing to.
Hi All!
I've started work on pike 7.6.112 packages, now if we have autobuilds of debian packages maybe this is unnessesery ...
Anyway here they are:
http://debian.han.pp.se/debian/dists/stable/main/binary-i386/
and
http://debian.han.pp.se/debian/dists/unstable/main/binary-i386/
//Henrik Andreasson (kinneh on irc@freenode)
Is there any difference in the source between stable and unstable?
The .orig.tar.gz is http://pike.ida.liu.se/pub/pike/latest-stable/Pike-v7.6.112.tar.gz, right?
I think we should do two things to begin with: 1) Apply the Debian-specific patches (debian/patches/*) at build time using dpatch or equivalent, and 2) clean up the clean target. I expect $(MAKE) distclean to restore everything to pre-build state, and it *almost* does. Two things are missing compared to the tarball: bin/pike and src/modules/Java/module.pmod.in. It's quite possible that those shouldn't have been in the tarball to begin with. After that I'm sure the install target can be simplified a lot too.
I don't know about bin/pike, but src/modules/Java/module.pmod.in definitely should be preserved, as you can't build the Java module without it in 7.6/7.7. What removes it?
Weird, I could swear that I only did debian/rules binary (or equivalent) followed by make distclean. But it must have been removed by debian/rules clean nevertheless. No big deal, I think, since we build --without-java.
Anyway, I've replaced the contents of the very messy clean target with just a $(MAKE) distclean (actually it just deletes the build directory), and it seems to be sufficient, except for one thing: The official tarballs don't contain the built documentation, which Marek's tarballs, built from CVS, did, so $(MAKE) documentation is needed, but there doesn't seem to be any corresponding clean-documentation target (make -C refdoc spotless doesn't work, because refdoc/.cvsigore is not in the tarball). However, I think rm refdoc/modref refdoc/traditional_manual does it.
I think you need it even with --without-java in order to prevent a build error.
why build without java though?
greetings, martin.
Dunno. I don't know what's supposedly wrong with the GTK2 module either.
well, i guess previously java was disabled because of the java license. and gtk was disabled because pike 7.6 only supports gtk1 and there were some issues with the gtk1 support of gtk2
greetings, martin.
Java license? GCJ is GPL. Isn't that good enough?
Yes, but it would have taken effort or actual communication for a maintainer to determine that fact.
that was only a speculation on my part. the speculation implies that the java bridge only works with sun java. (i am sure when roxen developed the bridge, sun java was what they tested it with)
no need to speculate further, especially since sun java is turning gpl now too, anyways, so now neither license nor technical limitations should keep the debian package from supporting it.
what do i need to do to get the java support built in the pikefarm?
greetings, martin.
The Java bridge works with at least Sun Java, Blackdown Java and GCJ. I use --with-java-lib-dir=/usr/lib/gcj-4.1 to get working Java on Ubuntu.
Then what's the GTK2 module doing there if GTK2 isn't supported? It can't be totally useless, can it?
I'm wondering if the .pike and .pmod files associated with binary modules really have to be in /usr/share/pike7.6, with symlinks there from /usr/lib/pike7.6. The situation seems similar to Perl: Debian installs all files associated with an XS module under /usr/lib, not just the shared library (.so) and mere wrappers, but also .pod files (stand-alone documentation) and larger .pm files.
"eXternal Subroutines". It's how you interface (e.g.) C libraries with Perl programs.
that would be a question of debian policy and the filesystem hierarchy standard. the current split between /usr/lib and /usr/share does fit the policy as far as i can tell.
greetings, martin.
It does, but it would be easier not to separate the files, especially since the we won't need all the symlinks then. Or do we really need them? It would make more sense if the symlinks went the other way, from /usr/share/pike7.6 to /usr/lib/pike7.6.
hmm, pike handles multiple module directories, if you put both places into the master, then maybe most symlinks should not be needed at all.
greetings, martin. ps: gratulations for filing the ITA
What's the reason for not having /usr/lib/pike/7.6 instead of /usr/lib/pike7.6, btw?
# honoka$ ls /usr/lib/perl/ totalt 4 0 5.8@ 4 5.8.8/ 4 5.8.7/
Sorry, it *is* actually /usr/lib/pike/7.6.(whatever)/.
Martin: I don't think there's a need to congratulate me. Filing the ITA wasn't too hard...
remind me not to congratulate you on your next birthday then ;-)
Does anybody know where the /usr/bin/pike7.676 symlink comes from and if it's doing any good?
The default behaviour of pike is to install symlinks to the binary from both "pike" and "pike"<major><minor>. That is, for pike 7.6, "pike" and "pike76", and for pike 7.7 "pike" and "pike77". I'm guessing someone has been doing some incomplete remodelling of how they want it to behave differently in Debian.
correct. as the debian tradition (or policy?) for versioned binaries seems to be to have the versioned name as the main one and a symlink to that, the main pike binary gets installed as: /usr/bin/pike7.6 and the symlink pike -> pike7.6
pike tradition is to make a link: pike76 -> pike since in debian pike becomes pike7.6 that link then becomes pike7.676
greetings, martin.
And they do not consider it a bug that the name is neither pike7.6 nor pike7.6.67, but instead pike7.676, a minor we should hopefully never release?
The tradition adopted so far in debian packaging of pike has beed to mindlessly follow the letter of the policy documents without considering for a second whether it makes any sense.
pike7.6 does exist. pike7.676 is being created because of pike being renamed to pike7.6
it probably went by unnoticed.
greetings, martin.
Well, my plan is to use --traditional and install the executable as /usr/bin/pike7.6. The alternatives system takes care of the symlink from /usr/bin/pike (via /etc/alternatives/pike). The shellscripts that merely call pike with some parameter (hilfe and rsif) weren't included before and still won't be. Modules and stuff will be installed in /usr/lib/pike/7.6.112 (without the extra /lib/ level).
right, that means you need to take care of the makefile creating the pike7.676 link.
i recall some reports about users trying pike scripts they downloaded on debian, and having problems because the scripts reference pike76,
so please check if there is any problem with having a pike76 link.
greetings, martin.
No symlinks are created with install.pike --traditional, but a /usr/bin/pike76 symlink might be warranted.
What kind of pike scripts? Not from official Debian packages I hope?
On Sat, Sep 01, 2007 at 05:40:01PM +0000, Magnus Holmgren, exim.org @ Pike developers forum wrote:
What kind of pike scripts? Not from official Debian packages I hope?
things published from pike users who don't use the debian packages.
now while i think that any pike user should be able to figure this out, users pr programs wirtten in pike are not nesesarily pike users themselves.
so at least whar works on one system should work on others, and wether pike76 as a link is a good idea or not, the links should be the same accross all distributions of pike.
(strictly speaking that would mean that pike everywhere also needs pike7.6 as a link to make scripts from a debian system work elsewhere, personally i don't care though, i think this versioning in the path is not very practical anyways and should be in the code with the preprocessor versioning method.)
greetings, martin.
I'm beginning to get things in shape, but some questions remain:
- Henrik's debian/rules replaces the precompile.sh and smartlink that "make install" installs with versions from the build directory. Why? That "smartlink" is a binary executable, so it doesn't fit well in an "Architecture: all" package.
- Does pike7.6-dev have to be "Architecture: all", though?
- Shouldn't GLU and GLUE be in pike7.6-gl?
- A number of modules are left out (Ssleay, Java, Msql, PDF, Ffmpeg, Oracle, Gnome, DVB), obviously because the required libraries are unavailable in Debian. Can't the build system prevent these modules from being built in the first place?
- I think more modules could have split out into separate packages in order to keep the dependencies of pike7.6-core down, but changing that now is difficult. Maybe it can be done in pike7.7 (pike7.8)?
I'm beginning to get things in shape, but some questions remain:
Henrik's debian/rules replaces the precompile.sh and smartlink that "make install" installs with versions from the build directory. Why? That "smartlink" is a binary executable, so it doesn't fit well in an "Architecture: all" package.
Does pike7.6-dev have to be "Architecture: all", though?
I don't know how the build process works in detail, so I can't help you here.
- Shouldn't GLU and GLUE be in pike7.6-gl?
Yes, that would be appropriate.
- A number of modules are left out (Ssleay, Java, Msql, PDF, Ffmpeg, Oracle, Gnome, DVB), obviously because the required libraries are unavailable in Debian. Can't the build system prevent these modules from being built in the first place?
Ssleay is obsolete. PDF, Ffmpeg and DVB I don't know if they are finished. Certainly not maintained. Java, Msql, Oracle and Gnome should probably be included somewhere. At the very least the Java module.
- I think more modules could have split out into separate packages in order to keep the dependencies of pike7.6-core down, but changing that now is difficult. Maybe it can be done in pike7.7 (pike7.8)?
We have traditionally favoured a big core to reduce the risk of Pike programs not running due to missing dependencies. Some sort of more active dependency tracking would be helpful.
mSQL is proprietary and development has more-or-less ceased.
In fact the mSQL module can probably be deprecated. I can't imagine anyone uses mSQL for any serious works these days, with postgresql, mysql and even free Oracle as available options.
In the last episode (Sep 24), Magnus Holmgren, exim.org @ Pike developers forum said:
I'm beginning to get things in shape, but some questions remain:
- A number of modules are left out (Ssleay, Java, Msql, PDF, Ffmpeg, Oracle, Gnome, DVB), obviously because the required libraries are unavailable in Debian. Can't the build system prevent these modules from being built in the first place?
Java at least is available:
ii sun-java6-jdk 6-00-2 Sun Java(TM) Development Kit (JDK) 6
It's still classified as non-free, however. Can the Java module work with some other JVM (configure.in suggests it)? Will it work well? Which one is recommended?
That statement is a little odd... Isn't LD_LIBRARY_PATH at least partially designed for the purpose of finding libraries that have been dynamically linked?
Perhaps it shouldn't be called libjvm.so if it's not meant to be linked as a library...
Bill
libjvm.so is designed to be dlopened at runtime (found on LD_LIBRARY_PATH). Any application, that tries to link that library, is buggy. Please never ever link it directly.
In the last episode (Sep 25), H. William Welliver III said:
libjvm.so is designed to be dlopened at runtime (found on LD_LIBRARY_PATH). Any application, that tries to link that library, is buggy. Please never ever link it directly.
That statement is a little odd... Isn't LD_LIBRARY_PATH at least partially designed for the purpose of finding libraries that have been dynamically linked?
Perhaps it shouldn't be called libjvm.so if it's not meant to be linked as a library...
Both linking and dlopen'ing are valid, but a distribution with mutiple possible jvms might prefer to dlopen. Section 7.2 of the JNI Programmer's Guide has some examples:
http://java.sun.com/docs/books/jni/html/invoke.html
Yeah, it would have made more sense if he said "(_not_ found on LD_LIBRARY_PATH)". I guess he made a typo.
libjvm.so is also unversioned. Is the ABI guaranteed never to change (at least not in a backwards-incompatible way)?
Regarding libjvm.so being unversioned, this is not a problem because the only function it contains is JNI_CreateJavaVM(), which returns a versioned vtable. New functions are added to the end of the vtable, leaving old functions in place for backwards compatibility.
The Java module works well with gij/classpath. You may need to give some configure option for it to be detected though.
More precisely, I use --with-java-lib-dir=/usr/lib/gcj-4.1-71/ to build the Java module against gij/gcj 4.1 on Ubuntu.
More precisely, I use --with-java-lib-dir=/usr/lib/gcj-4.1-71/ to build the Java module against gij/gcj 4.1 on Ubuntu.
Um, better make that /usr/lib/gcj-4.2-81/ instead. The current libgcj7.1 seems to have some problem preventing it from working well with Pike. (Or maybe there's something wrong with my installation?) libgcj8.1 works fine though:
chiyo:~/Pike/7.7% ldd build/linux-2.6.22-12-powerpc-ppc/modules/Java/module.so linux-vdso32.so.1 => (0x00100000) libdl.so.2 => /lib/libdl.so.2 (0x6ffa7000) librt.so.1 => /lib/librt.so.1 (0x6ff7e000) libnsl.so.1 => /lib/libnsl.so.1 (0x6ff44000) libm.so.6 => /lib/libm.so.6 (0x6fe7d000) libpthread.so.0 => /lib/libpthread.so.0 (0x6fe43000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x6fdf6000) libjvm.so => /usr/lib/gcj-4.2-81/./libjvm.so (0x6fdd3000) libc.so.6 => /lib/libc.so.6 (0x6fc56000) /lib/ld.so.1 (0x20000000) libgcj.so.81 => /usr/lib/libgcj.so.81 (0x6d7ab000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x6d776000) libz.so.1 => /usr/lib/libz.so.1 (0x6d740000) chiyo:~/Pike/7.7% make run_hilfe
Configure arguments: --with-java-lib-dir=/usr/lib/gcj-4.2-81 Use `make CONFIGUREARGS="..." ...' to change them. They will be retained in the build directory.
Making run_hilfe in build/linux-2.6.22-12-powerpc-ppc /home/marcus/Pike/7.7/build/linux-2.6.22-12-powerpc-ppc/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/marcus/Pike/7.7/build/linux-2.6.22-12-powerpc-ppc/master.pike Pike v7.7 release 38 running Hilfe v3.5 (Incremental Pike Frontend)
(string)Java.pkg.java.lang.System->getProperty("java.vendor");
(1) Result: "Free Software Foundation, Inc."
(string)Java.pkg.java.lang.System->getProperty("java.version");
(2) Result: "1.5.0"
make install throws complains a lot:
Could not resolv Getopt. (Perhaps the installed pike tree has been moved.) lib/master.pike:2346: master()->__lambda_65600_1_line_2343("Getopt",UNDEFINED) [ ... repeated 18 more times ... ] Dumping of some modules failed (not fatal) (0x0000000a) Pike installation completed successfully.
Is that of any consequence at all?
Some configure scripts (namely those of Java, ODBC, Mysql, Postgres, and Oracle) add "-L$some_lib_dir -R$some_lib_dir" to LDFLAGS (and LINKER_OPTIONS). But -R is not a recognized gcc option. Should that be "-Wl,-R$some_lib_dir" (i.e. -Wl,-rpath,$some_lib_dir) instead?
Maybe in the makefile, but AFAICT not when configure runs its tests ("if the JVM really works").
Both things build with makefiles and in configure scripts are built using $CC, which should contain smartlink. If it doesn't, there's something wrong with the configure system on a higher level.
I decided to make pike7.6-dev Arch: any to get rid of a special case (dynamic_module_makefile).
Now for a review of the pre-build patches and post-build fixups.
01_master.in.dpatch put the extra add_include_path() and add_module_path() calls in normalize_path(). WTF?? Moved to a sensible place.
02_smartlink_rpath.dpatch rather aggresively comments out code in smartlink.c, but things seem to work. But again, why are there both a shell script and a C program?
03_language.yacc_bison_fix.dpatch disables the following #define in language.c:
/* Bison is stupid, and tries to optimize for space... */ #ifdef YYBISON #define short int #endif /* YYBISON */
The above is immediately followed by:
#ifdef short # undef short #endif
Foo?
04_make_variables_fpic.dpatch adds -fPIC to OTHERFLAGS and NOOPTFLAGS in src/make_variables.in. Isn't Pike's build system competent enough to use -fPIC as needed?
05_install.pike.dpatch was merged with 06_src_makefile.in.dpatch. It should have been the other way around, since patching install.pike is no longer necessary with --traditional. However, patching src/Makefile.in is still necessary to allow INSTALLARGS and include_prefix to be passed from the top Makefile. (debian/rules now calls the top Makefile only, since I suppose that's what you're supposed to do.)
07_dynamic_module_makefile.in-libgcc.dpatch sets LIBGCC=$(shell gcc -print-libgcc-file-name) in dynamic_module_makefile.in. I suppose it's practical if modules can be built with some other version of gcc that the one Pike was built with.
debian/rules creates a file /usr/include/pike/7.6.112/specs containing various build parameters, such as CPPFLAGS and configure_args. I don't know if any other package uses it.
Finally, the location of dynamic_module_makefile is adjusted, in dynamic_module_makefile, from $(MODULE_BASE) to $(PIKE_SRC_DIR), which probably makes sense if PIKE_SRC_DIR is set to the include directory and MODULE_BASE is set to the modules directory when building modules. How does it work? Is there an example of how to build a binary module somewhere? http://pike.ida.liu.se/generated/manual/ref/chapter_18.html#2 is not very complete. And shouldn't "sinclude(../module_configuration.in)" be "sinclude(../module_configure.in)"?
01_master.in.dpatch put the extra add_include_path() and add_module_path() calls in normalize_path(). WTF?? Moved to a sensible place.
I assume the new place is create()?
02_smartlink_rpath.dpatch rather aggresively comments out code in smartlink.c, but things seem to work. But again, why are there both a shell script and a C program?
The shell script is the reference implementation, while the C code implementation is for speed in the common case where you are not cross-compiling.
03_language.yacc_bison_fix.dpatch disables the following #define in language.c:
[...]
Foo?
Some versions of Bison had problems with that code. Makefile.in nowadays has a proper workaround, so there should be no need for the patch anymore.
04_make_variables_fpic.dpatch adds -fPIC to OTHERFLAGS and NOOPTFLAGS in src/make_variables.in. Isn't Pike's build system competent enough to use -fPIC as needed?
It should be. If it isn't, it's a bug and should be reported.
05_install.pike.dpatch was merged with 06_src_makefile.in.dpatch. It should have been the other way around, since patching install.pike is no longer necessary with --traditional. However, patching src/Makefile.in is still necessary to allow INSTALLARGS and include_prefix to be passed from the top Makefile. (debian/rules now calls the top Makefile only, since I suppose that's what you're supposed to do.)
07_dynamic_module_makefile.in-libgcc.dpatch sets LIBGCC=$(shell gcc -print-libgcc-file-name) in dynamic_module_makefile.in. I suppose it's practical if modules can be built with some other version of gcc that the one Pike was built with.
Sounds reasonable.
debian/rules creates a file /usr/include/pike/7.6.112/specs containing various build parameters, such as CPPFLAGS and configure_args. I don't know if any other package uses it.
That file is (supposed to be) used by pike -x module.
Finally, the location of dynamic_module_makefile is adjusted, in dynamic_module_makefile, from $(MODULE_BASE) to $(PIKE_SRC_DIR), which probably makes sense if PIKE_SRC_DIR is set to the include directory and MODULE_BASE is set to the modules directory when building modules. How does it work? Is there an example of how to build a binary module somewhere?
http://pike.ida.liu.se/generated/manual/ref/chapter_18.html#2 is not very complete. And shouldn't "sinclude(../module_configuration.in)" be
Indeed.
"sinclude(../module_configure.in)"?
Where did you find this?
01_master.in.dpatch put the extra add_include_path() and add_module_path() calls in normalize_path(). WTF?? Moved to a sensible place.
I assume the new place is create()?
You assume correctly.
I forgot to mention that you can browse the Debian packaging files at http://svn.kibibyte.se/pike7.6/trunk/debian
03_language.yacc_bison_fix.dpatch disables the following #define in language.c:
[...]
Foo?
Some versions of Bison had problems with that code. Makefile.in nowadays has a proper workaround, so there should be no need for the patch anymore.
OK, I'll delete it then.
04_make_variables_fpic.dpatch adds -fPIC to OTHERFLAGS and NOOPTFLAGS in src/make_variables.in. Isn't Pike's build system competent enough to use -fPIC as needed?
It should be. If it isn't, it's a bug and should be reported.
OK, we'll investigate that further then. Too bad debian/changelog doesn't say anything about it.
05_install.pike.dpatch was merged with 06_src_makefile.in.dpatch. It should have been the other way around, since patching install.pike is no longer necessary with --traditional. However, patching src/Makefile.in is still necessary to allow INSTALLARGS and include_prefix to be passed from the top Makefile. (debian/rules now calls the top Makefile only, since I suppose that's what you're supposed to do.)
07_dynamic_module_makefile.in-libgcc.dpatch sets LIBGCC=$(shell gcc -print-libgcc-file-name) in dynamic_module_makefile.in. I suppose it's practical if modules can be built with some other version of gcc that the one Pike was built with.
Sounds reasonable.
Shall I open a bug report about the makefiles being inflexible wrt INSTALLARGS and such?
debian/rules creates a file /usr/include/pike/7.6.112/specs containing various build parameters, such as CPPFLAGS and configure_args. I don't know if any other package uses it.
That file is (supposed to be) used by pike -x module.
Oh, now I see. I'll take a closer look at the differences compared to the ordinary one.
Finally, the location of dynamic_module_makefile is adjusted, in dynamic_module_makefile, from $(MODULE_BASE) to $(PIKE_SRC_DIR), which probably makes sense if PIKE_SRC_DIR is set to the include directory and MODULE_BASE is set to the modules directory when building modules. How does it work? Is there an example of how to build a binary module somewhere?
http://pike.ida.liu.se/generated/manual/ref/chapter_18.html#2 is not very complete. And shouldn't "sinclude(../module_configuration.in)" be
Indeed.
"sinclude(../module_configure.in)"?
Where did you find this?
module_configure.in was the closest match I could find with a cursory search. There is no file called module_configuration.in AFAICS.
debian/rules creates a file /usr/include/pike/7.6.112/specs containing various build parameters, such as CPPFLAGS and configure_args. I don't know if any other package uses it.
That file is (supposed to be) used by pike -x module.
Oh, now I see. I'll take a closer look at the differences compared to the ordinary one.
The original generated specs file looks as follows:
| CC=/usr/include/pike/7.6.112/smartlink gcc
debian/specs.in simply sets CC=gcc. Isn't smartlink used for a reason? It's even patched.
| CFLAGS= -Wa,--execstack -mcpu=i686
debian/specs.in simply sets CFLAGS=-O2 -DDEBIAN, but I see no reason to override it and move -DDEBIAN from CPPFLAGS. The -mcpu makes me a bit worried that the build system optimizes too much. AFAICS that can only be disabled by setting CFLAGS to something. But what? And where did -O2 go? --without-copt was not used. This line in src/configure.in looks like a bug (but it shouldn't affect anything):
AC_ARG_WITH(copt, MY_DESCR([--without-mmx], [disable MMX usage]), [], [with_mmx=])
| LDFLAGS= -L/tmp/buildd/pike7.6-7.6.112/build/linux-2.6.18-proffe-4-i686/bundles/lib -z execstack -R/usr/local/lib/. -L/usr/local/lib/. | CPPFLAGS= -DDEBIAN -I/tmp/buildd/pike7.6-7.6.112/build/linux-2.6.18-proffe-4-i686/bundles/include -I/usr/local/include
I think --without-bundles should help here. debian/specs.in also excludes the /usr/local/ directories and redundantly includes -L/usr/lib and -I/usr/include, the obsolete /usr/X11R6/lib, and /usr/include/pike/$VERSION. I don't think the Debian package should have to add that last one.
| CPP=gcc -E | LDSHARED=gcc -shared | configure_args='--without-rtldebug' '--without-cdebug' '--without-debug' '--with-cflags=' '--with-cppflags=-DDEBIAN' '--with-bignums' '--with-gmp' '--with-poll' '--with-zlib' '--with-freetype' '--without-ttflib' '--with-libnettle' '--without-sybase' '--without-java' '--with-odbc' '--with-sane' '--with-postgres' '--with-postgres-include-dir=/usr/include/postgresql' '--with-libpq-dir=/usr/lib' '--with-perl' '--without-ffmpeg' '--without-fftw' '--without-libpdf' '--without-libpanda' '--without-GTK' '--without-GTK2' '--with-machine-code' '--with-security' 'CC=gcc' 'CFLAGS='
No differences here, except for quoting style.
| CFLAGS= -Wa,--execstack -mcpu=i686
debian/specs.in simply sets CFLAGS=-O2 -DDEBIAN, but I see no reason to override it and move -DDEBIAN from CPPFLAGS. The -mcpu makes me a bit worried that the build system optimizes too much. AFAICS that can only be disabled by setting CFLAGS to something. But what? And where did -O2 go? --without-copt was not used.
I see now that -O2 and other optimization flags are added via $(OTHERFLAGS), which contains $(OPTIMIZE) (and -fPIC comes from $(LINKAGE_CFLAGS), so the patch that adds it to OTHERFLAGS should be superfluous).
--without-cdebug is documented as disabling -g. But --with-cdebug doesn't enable it. Since --with-cdebug seems to be the default, I expected -g to be included by default.
If you set CFLAGS manually, configure will not add -g etc to it. If you let configure decide on CFLAGS, it should add -ggdb3 if you are compiling with gcc and specify --with-cdebug.
Ah. AC_PROG_CC adds -g to CFLAGS unless CFLAGS is already set. I don't set it explicitly, but configure sets it from $with_cflags before invoking AC_PROG_CC. I'd expected it to work the same as with the stuff configure does only when $cflags_is_set = "no", since --with-cflags is used to provide "_extra_ c compiler flags".
If you set CFLAGS manually, configure will not add -g etc to it. If you let configure decide on CFLAGS, it should add -ggdb3 if you are compiling with gcc and specify --with-cdebug.
The DVB module doesn't appear to work with Linux 2.6. configure.in contains the following comment:
linux 2.6 has dvb/version.h but not linux/dvb/sec.h, which dvb.c needs; this should probably be updated some better way: FIXME!!1!¡ /Mirar
Comments?
I noticed two more modules not being built correctly: Math.Transforms.FFT (needs fftw-dev) and Mird (needs mird-dev). Adding the Build-Depends should be all it takes, but Mird should perhaps be a separate package and can Math.Transforms.FFT be converted to use fftw3 instead?
I think Mird includes mird-dev in a subdirectory.
Yes, but *fortunately* that part of Mird/configure.in is commented out (Debian frowns sharply at convenience copies of libraries).
As I said, there is a Debian package, which I assumed is it. *checking...* Hmm, it's not heavily updated. Aha, mird means Mirar's DB! http://www.mirar.org/mird returns 404. I guess it's not exactly in widespread use...
Not afaik. I don't think it matters if it's not included in the build, I don't know anyone that uses it.
What is the difference between fftw-dev and fftw3? Sounds to me like you will always need a -dev package to build things that uses fftw.
fftw-dev is the dev package of fftw (version 2). fftw3 referred to the fftw library, version 3, in general. The Debian package needed in order to link against fftw3 is of course fftw3-dev, completely analogously.
Now I noticed that Marek added a fftw package to pike7.7, but he used the wrong build-dependency (fftw3-dev) and ended up with a non-functional module. Sigh...
He might be right in making it a separate package, though. fftw2 pulls in quite a few additional dependencies, libx11 among others. Opinions?
I have no strong feeling about fftw. It's normally not part of my binary packages at all. Having it a separate package if it pulls a lot of other stuff probably makes sense.
But why is it pulling x11?
It depends on libmpich1.0c2 ("MPI parallel computing system implementation"), which depends on libx11-6.
Turns out that libmpich1.0c2 package contains six libraries or library variants (shared object files), one of which uses libx11, and it's not the one fftw2 needs. fftw2, in turn, contains two times three library variants (mpi, threads, and vanilla), and I don't think Math.Transforms.FFT uses mpi, which is the one that actually depends on libmpich.
Waaaait a minute! I concluded yesterday that Math.Transforms.TTF isn't a file of it's own - it's baked into ___Math.so. And pike7.7-fftw is empty - Marek didn't even _try_ to put something in it.
I don't think the FFT is in use anywhere. I implemented it a long time ago because I wanted to do FFT for some project and thought it would be neat to have it in pike.
There is lots of potential for using FFTs and other transforms, but non of them are in use in pike atm.
Thus, the easiest solution is just to skip that module for now.
Now I noticed that Marek added a fftw package to pike7.7, but he used the wrong build-dependency (fftw3-dev) and ended up with a non-functional module. Sigh...
He might be right in making it a separate package, though. fftw2 pulls in quite a few additional dependencies, libx11 among others. Opinions?
Release candidate packages (i386 and source) can be downloaded from ftp://ftp.kibibyte.se/debian/pool/main/p/pike7.6 (or add
deb ftp://ftp.kibibyte.se/debian/ sid main
to /etc/apt/sources.list. Please test! If nobody has any further comments to any of my posts, and nobody finds any serious problems, I intend to get them uploaded in this state. Minor remaining issues can be addressed in 7.6.112-2.
I'd be delighted if someone who is already a Debian developer took charge of the packages. Especially if that person works with me to make sure Debian packages works and can be automatically built without extra manual work to set it up.
yes, something like make debianpackage would be nice, then those of us running pikefarm on debian machines could add that to the list of pikefarm build tests.
same would go for rpm packages too btw.
greetings, martin.
As long as it's
debianpackage: cp -rf packaging/debian debian dpkg-buildpackage -rfakeroot -uc -us
or something like that.
the first thing (after adopting the packages) is to get updates into debian unstable.
backports to stable (on backports.org) are not very likely to happen, because programming languages are generally not backported (as that could potentially break all the applications using that language)).
backports offered for download from the pike site are of course possible and would be very nice to have, but as these were not generally offered before, i don't think there is an urgent need for that right now.
making sure that the packages in debian have a maintainer, seems more important to me.
apart from core pike itself, there are also the modules from gotpike.org, some of them are already in debian (and waiting for a maintainer now), the rest would also be nice to have. (caudium packages also need a maintainer, if anyone is keen, btw)
greetings, martin.
On Mon, 6 Aug 2007, Martin Bähr wrote:
I'm trying to become a debian developer but it's a slow process. I'd like to set up a team to maintain the packages (both pike and caudium in this situation, when beeing un-maintained), to it dont has to be neglected as they has latly.
Anybody want to be part of that? We'll need atleast one dd to setup a team the rest need not to bee dd:s.
I'd say that we should make 7.6.112 availabe for stable somehow thou.
//Henrik Andreasson (kinneh)
the first thing (after adopting the packages) is to get updates into debian unstable.
backports to stable (on backports.org) are not very likely to happen, because programming languages are generally not backported (as that could potentially break all the applications using that language)).
backports offered for download from the pike site are of course possible and would be very nice to have, but as these were not generally offered before, i don't think there is an urgent need for that right now.
making sure that the packages in debian have a maintainer, seems more important to me.
apart from core pike itself, there are also the modules from gotpike.org, some of them are already in debian (and waiting for a maintainer now), the rest would also be nice to have. (caudium packages also need a maintainer, if anyone is keen, btw)
greetings, martin.
Hey,
I'm trying to become a debian developer but it's a slow process. I'd like to set up a team to maintain the packages (both pike and caudium in this situation, when beeing un-maintained), to it dont has to be neglected as they has latly.
Anybody want to be part of that? We'll need atleast one dd to setup a team the rest need not to bee dd:s.
I'd say that we should make 7.6.112 availabe for stable somehow thou.
As a Pike, Caudium and Debian user, i'd be happy to help. (I don't plan to become a dd).
pike-devel@lists.lysator.liu.se
-
bertrand.lupart＠linkeo.com -
Dan Nelson -
David Hedbor (Amazon.com) ＠ Pike (-) developers forum -
H. William Welliver III -
Henrik Andreasson -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Magnus Holmgren, exim.org ＠ Pike developers forum
-
Magnus Holmgren, FR Ryd (Nu med m�l och syfte) ＠ Pike (-) developers forum
-
Marcus Agehall () ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum