much of the work has already been done by hansi, this is his most recent
message:

hello!


get the file
http://www.chiefmag.com/processing/repository.zip

extract it directly in processing.orgs root folder, it should create the
folder processing.org/repository/debian/...

now you can add
deb http://processing.org/repository/debian processing main
at the end of your /etc/apt/sources.list file and then execute
apt-get update
apt-get install processing


things to be discussed:
* The changelist is not included because it has to be a
standardized format (see
http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-changelog)
and it would be a lot of work each time to make it suitable

* I've created a new launch file (/usr/bin/processing when installed)
It checks if jdk 5/6 is installed, but also creates the folder
~/processing/ folder if it doesn't exist yet.

* maybe there's more.

* I have only tested in ubuntu yet, but it should work on any
debian based system cause i haven't used any ubuntu specific
things.



if that works i could send you the files required to create the debian
package and the files to create the repository indexes.


best, hansi.

(In reply to comment #0)
> * The changelist is not included because it has to be a
> standardized format (see

Upstream (i.e. the processing devs) can use whatever changelog format they
want. The Debian-specific changelog (changelog.Debian) is the one that has
to be under a strict format. The first Debian changelog will probably only
need "initial release (closes: [ITP bug number]). Btw, I've just opened
such an ITP bug.


> * I have only tested in ubuntu yet, but it should work on any
> debian based system cause i haven't used any ubuntu specific
> things.

It's always dangerous to assume that just because it works in Ubuntu, it'll
also work in Debian. You may have inadvertently linked to some
Ubuntu-specific libraries in strange ways. Admittedly unlikely, but possible.

cool, so what's our next step?

oh, and the email addresses for casey and i should be fry@processing.org
and reas@processing.org... mail@ and info@ addresses are our work/personal
email.

(In reply to comment #2)
> cool, so what's our next step?

I'm not sure. Been a tad busy past couple of days. :-)

But it sounds like hansi could already have a package ready. At the very
least, he should attept to build it with pbuilder, which builds in a Debian
chroot, making sure all the dependencies are properly stated and satisfied.
If that succeeds, he (?) could RFS in the debian-mentors@debian.org mailing
list and wait for a Debian developer (DD) to review his package for upload
to the Debian servers. I was kinda hoping I could review it myself before
that, but I'm not sure how soon I can get around to doing that, and if
impatience is high, then there's no need to wait for me.

I'm not a DD, btw, I've only ever packaged one thing for Debian, and I'm
not even sure it's going to be approved the by the Debian ftpmasters
(although I have little reason to suspect that it could be rejected;
another DD already looked at my upload and approved it).

(In reply to comment #3)
> oh, and the email addresses for casey and i should be
fry@processing.org
> and reas@processing.org... mail@ and info@ addresses are our work/personal
> email.

Sorry. I tried to find contact information for principal authors as quickly
as I could when I was writing the ITP bug. Your name is on the front page
and links to your personal sites which then list the contact information.
You might want to consider making the Processing-specific contact
information more prominent than your personal webpages.

At present, the ITP bug submission will stand as it is, but once the
debian/control and debian/copyright files are written for the package we
can fix that.

hey all!

first of all the bad message... i've switched to os x a week ago, so i'm
not running linux on a daily basis right now.

@swap i don't know exactly what pbuilder is and why i need chroot, but
processing is the first package i've ever tried to create.
if you just open up
http://www.chiefmag.com/processing/
then get the file "processing_debian.zip", it contains all the files needed
to build the processing debian package from the processing linux zip archive.


for the debian packagers request... i'd definitely bring up the time to
keep the package up to date and test a little bit...should i try getting in
touch with the debian developers in the next couple of days?

just to make the list complete, my email address is super@superduper.org

(In reply to comment #6)
> first of all the bad message... i've switched to os x a week ago, so i'm
> not running linux on a daily basis right now.

Hm. I never run anything but GNU/Linux (yeah, I'm one of those hardcore
free software proponents). I'm about to go on a vacation, so I won't be
able to commit much time to this immediately. However, if running GNU/Linux
can be a hassle for you, I'm happy to do it instead and keep tabs on the
Processing package.

> @swap i don't know exactly what pbuilder is and why i need chroot,

Debian has to be able to build your package automatically for 14
architectures or so (although Ubuntu only seems to care about three or four
of those). On some architectures, it may need to link to libraries in a
different way or to different versions of a library. In short, your package
must be portable, and there may be unexpected surprises and your package
can fail to build on a certain architecture. My recent example is that the
one Debian package I made needed an X server during the build process or
else it would fail to build. This is bad, because you can't assume that the
Debian autobuilding servers will have an X server running in them (in fact,
I understand most of them don't). I had to patch my package's build process
in order to get around this problem, which took a bit of effort.

Pbuilder builds your package closely emulating the build environment of the
Debian autobuilders. It's a minimal test that your package will work for
Debian. Failure to build from source (FTBFS) is a pretty severe bug in a
Debian package and can result in your submission to Debian getting rejected.

> http://www.chiefmag.com/processing/
> then get the file "processing_debian.zip", it contains all the files needed
> to build the processing debian package from the processing linux zip
archive.

Okay, I'll try to build it soon. Maybe today or tomorrow.

> for the debian packagers request... i'd definitely bring up the time to
> keep the package up to date and test a little bit...

Good. Or we can co-maintain, if you'd like. I also am willing for now to
commit some time to maintaining a Debian package or processing.

> should i try getting in
> touch with the debian developers in the next couple of days?

Sure. Try the debian-mentors@lists.debian.org mailing list. People there
are generally friendly and wiling to help. I personally really like its
atmosphere. :-)

as another point of interest, i'll be showing processing at OSCON next
week, so it may even be fun to have this ready to go (for 0125) in time for
that, rather than waiting for the next release. but it depends on how the
timing on all this works.

hey!

i've prepared a .deb package of 0125, it works in ubuntu gutsy and it
should work on all debian (based) systems too, but its not tested.

you can get it from http://www.chiefmag.com/processing/processing-0.125.deb

i haven't setup a repository, that wouldn't make much sense cause the url
would change soon and that would be confusing for everyone...

hansi.

thanks to vmware i could also test in debian, it works perfectly - all you
need to do is enable the "non-free" repositories to get sun-java.

cool, so what else do i need to run to set this up as a proper repository?
i figure we'll just use processing.org/download for the repository folder
(so i assume that means that there wll be a subfolder called 'debian' and
the rest). the repos zip file you sent had a fairly complicated setup...
from the repos howto, it looked like we could do a "trivial setup":
http://www.debian.org/doc/manuals/repository-howto/repository-howto.en.html#id2452849
though perhaps that's already what you're up to?

yes, it doesn't matters much at this point if we use a trivial repository
or a "proper" one.

i've set up a later one cause i was wondering if arduino and maybe some
other stuff like libraries or library-packs might go in there too one day.

it's not very hard either, there's a repo for 0124 at
deb http://www.chiefmag.com/repository/ processing contrib [multiverse
universe]
i put java+jikes in multiverse/universe, but that doesn't matter much cause
every major dist has java in the non-free section by now. processing goes
in contrib cause it depends on non oss software.


what do you think? if going for the more complex type of repository i have
a little script file where you just place the .deb files in the pool
directory and it updates all the package.gz automatically.

i don't see us moving libraries or arduino or mobile into the repository
anytime soon (meaning six months or more), we'd probably have to get a lot
more coordination going with everyone for that. so the simple repository
will suffice. but is it more trouble to switch back to the simple model
from the more complex one?

no, only people would have to update their repositories which would be a
little bit anoying, thats all there's to it.

i have started to read into the debian maintainers documents and somehow
found out that swap already filed an "intend to package" report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433270

does that mean you are already working on the package?
if i can help somehow let me know...

(In reply to comment #10)
> thanks to vmware i could also test in debian, it works perfectly -
all you
> need to do is enable the "non-free" repositories to get sun-java.

This is a bit of a problem. Processing should go in main, not in contrib. I
don't understand how the Java liberation schedule is coming along for
Debian, but in the meantime, we could try using gij instead which *should*
provide a JRE.

(In reply to comment #15)
> i have started to read into the debian maintainers documents and
somehow
> found out that swap already filed an "intend to package" report:
[..]
> does that mean you are already working on the package?

Yes, I am. But slowly. :-)

> if i can help somehow let me know...

You already have. I'm trying to build upon your work.

I didn't invest more than a couple of minutes to test, but processing
didn't seem to work under gjt. Thats why i made it depend on sun-java, and
thats why it has to go to contrib.

Sun's Java will be fully opensource one day, but they're still having a
rough time freeing all the components.

I have personally made tons of bad experiences with gjt, thats why I would
rather want to see processing in contrib working nicely, than in main and
being unstable. Most will have non-free and contrib enabled anyway because
they need codecs, graphics card drivers or whatever...

hey swap!

are there any updates on the package?
i'd love to see this work...

@fry: do have any numbers how many users would actually be affected by this?
like... how many people download the linux version?

hansi

i haven't done the hard numbers for a bit, but i think we have a few
hundred linux users in any given week.. probably 5% of our audience if i
were to guess. that may even go up a bit if we had an easy ubuntu solution
since that's a good entry point for most people.

(In reply to comment #19)
> are there any updates on the package?
> i'd love to see this work...

Eep! I've fallen behind on work with this. Things are a little rough right now.

I still plan on doing this. Thanks for the nudge. I'll see if I can work on
it this week.

another nudge :)

(In reply to comment #22)
> another nudge :)

Ok, ok, ok. And my numerical analysis students want to use Processing on
Debian too.

So I found quite a few problems with hansi's packaging. Not least of which,
it doesn't work. :-)

Well, the dotdeb didn't work even though I satisfied its dependencies. Java
threw an exception at me I've since forgotten when I tried to run hansi's
binary, probably due to incompatible libraries. This is why it's important
to build the Debian packages with $shlibs instead of manually putting in
there what the libraries should be.

Now, I have a few questions.

Processing seems to distribute its own Java and Jikes. This won't do for
inclusion in Debian, since the ftpmasters won't be happy about a package
including files that another package already has. Removing these components
from the upstream Processing distribution will be simple enough, but I'll
have to heavily patch the build process in order to work without these (the
make.sh script).

So, before I plunge ahead my questions are:

1) Any reason to expect difficulties using the Java and Jikes packaged in
Debian instead of the ones packaged with Processing?

2) Any clues on what needs to be modified in the make.sh script? I also see
a Perl preproc.pl script. Any idea if I should mess around with that one?

3) The build process needs to be modified in order to build into any target
directory, for compatibility with Debian's autobuilders. However, it looks
like the build process is a weird imitation of a Makefile which manually
does its own cd's and such. Any hints if changing the make.sh script to use
a specified target directory could be difficult?

And a few more things...

4) Are there any files that absolutely need the useless ".txt" extension?
I'd rather remove it. It looks out of place in a GNU system.

5) Could anything conceivably break if I remove the non-Linux files?

Thanks!

> Ok, ok, ok. And my numerical analysis students want to use Processing on
> Debian too.
you're a math professor?

aaanyways, i have answers to a few of your questions:

> 1) Any reason to expect difficulties using the Java and Jikes packaged in
> Debian instead of the ones packaged with Processing?
no, as long as you use sun-java it's fine. i had huge problems with the gnu
implementation.
the only downside of this is that processing will have to go in the contrib
section (until sun-java is completely gpl-ed)

the tricky part is finding out which java versions are installed and using
the right one.


> 2) Any clues on what needs to be modified in the make.sh script? I also see
> a Perl preproc.pl script. Any idea if I should mess around with that one?
no idea

> 3) The build process needs to be modified in order to build into any target
> directory, for compatibility with Debian's autobuilders. However, it looks
> like the build process is a weird imitation of a Makefile which manually
> does its own cd's and such. Any hints if changing the make.sh script to use
> a specified target directory could be difficult?
no idea either

>
> And a few more things...
>
> 4) Are there any files that absolutely need the useless ".txt" extension?
> I'd rather remove it. It looks out of place in a GNU system.
i think it would require some changes in processing. for instance the file
"preferences.txt" is referenced in the settings dialog. either it has to be
changed in processing too, or you leave the .txt in there.

how about other unix software? is it really insane to have files called
".txt"?


>
> 5) Could anything conceivably break if I remove the non-Linux files?
which non-linux files? for instance some of the core libraries (eg opengl)
have native libraries for other operating systems that have to stay in
there for the export functionality.


happy you're still on it, hansi,-

1) jikes can be the one packaged with debian. java should be sun-java, gij
or others will not work.

2 & 3) make.sh is just a sequence of command line things to compile and
move files around. it's simply evolved over time as processing has become
more complex. others have worked on moving it to an ant script, but it's
never been finished (see elsewhere in the bugs db). fixing it is a very low
priority because traditionally i've been the only one building processing
(and certainly building it across all platforms). i'm gradually moving away
from make.sh to build the whole thing with eclipse and ant.
to set up your own make.sh setup, you'd want to create a 'debian' folder in
'build', and add a make.sh there. that should build into
processing/build/debian/work which will be your playground for the files
that need to be distributed.
preproc.pl adds PGraphics methods to PApplet when the api changes. api
changes are never made on linux, so it's less important but it needn't be
left out.

4) leave the "useless" .txt extension. if i keep telling people to read
revisions.txt or libraries/howto.txt then people on linux will complain
that there is no such thing (you'd be surprised).

5) the non-linux files?

(In reply to comment #24)
> > Ok, ok, ok. And my numerical analysis students want to use Processing on
> > Debian too.
>
> you're a math professor?

Not quite. A grad student, and I'm co-teaching this numerical analysis
course. I'm taking care of teaching them the coding part and my
colleague is teaching them the theory.

> how about other unix software? is it really insane to have files called
> ".txt"?

It's not a big deal, but it does look out of place. I have written a
longer diatribe about this in case you're interested:

http://sums.math.mcgill.ca/~jordi/rants/txt.html


> > 5) Could anything conceivably break if I remove the non-Linux
> > files?
>
> which non-linux files? for instance some of the core libraries (eg opengl)
> have native libraries for other operating systems that have to stay in
> there for the export functionality.

I was thinking more of anything with an .exe, .app or .dll
extension. Mostly the stuff in the build/ directory.


(In reply to comment #25)
> 1) jikes can be the one packaged with debian. java should be sun-java, gij
> or others will not work.

Understood.

> 2 & 3) make.sh is just a sequence of command line things to compile and
> move files around.

Why didn't you use a real Makefile to begin with, if I may be as
blunt? That's exactly what they're for too.

> others have worked on moving it to an ant script, but it's
> never been finished (see elsewhere in the bugs db).

Hm, I had never heard of ant script before, but it looks like it's
just another kind of Makefile. I imagine it must be favoured by Java
users.

> traditionally i've been the only one building processing

Hopefully this will change soon. :-)

> i'm gradually moving away from make.sh to build the whole thing with
> eclipse and ant.

It's important for Debian for Processing to build without the need for
a GUI. The autobuilders often don't have a running X server. I'm not
sure if an ant script needs an X server, and if it does, I urge you to
consider an alternative.

I'm thinking that I may autoconfiscate Processing (i.e. move it to GNU
autotools). If I run into too many problems getting Processing to
suitably build for Debian as it is, I'll consider this more seriously.

> to set up your own make.sh setup, you'd want to create a 'debian' folder in
> 'build', and add a make.sh there. that should build into
> processing/build/debian/work which will be your playground for the files
> that need to be distributed.

This certainly sounds like a simple solution. It's highly nonstandard,
but it could work.

> preproc.pl adds PGraphics methods to PApplet when the api changes. api
> changes are never made on linux, so it's less important but it needn't be
> left out.

Ok. I'll leave it in, then. This will add Perl to Processing's build
dependencies, but that's ok, as sufficient Perl utilities are part of
Debian's base system.

> 4) leave the "useless" .txt extension. if i keep telling people to read
> revisions.txt or libraries/howto.txt then people on linux will complain
> that there is no such thing (you'd be surprised).

This can be alleviated with a README.Debian saying that I removed the
.txt extension, although it's probably more trouble than it's worth to
track down the files that can have the extension removed.

> 5) the non-linux files?

The stuff in build/ , mostly. If I run into something else that doesn't
seem necessary for Debian to distribute, I'll ask you about it.

Thanks for your careful response.

edit]
Improved Startup Script

I figured out why my processing package didn't work on all debian based
computers.
It just was a problem with the startup script. This is an improved version that
uses the debian alternatives system to find out which java versions are
installed on the system.
Hope it helps!

cool, i'll try to integrate this for 0136.

what exactly is the state on these packages/repos. none of those listed
seem to be in operation any longer.. would really like to be able to
apt-get processing.. thnx

swap is working on a debian source package now, but i dunno how far he got.

@swap is there already a testing version that can be downloaded somewhere?

Any news on this?
What is the status of recent versions running on debian?
(in particular, regarding the use of apt-get)
Thanks,
-Austin

Hi guys.

Now that you've made a stable release and Processing is out of Beta (and
I've had more experience packaging for Debian), my interest in making this
package happen is renewed.

A few requests, though:

1) The build system is still kinda messy. I'd be happy to help complete the
move to Ant. Where should I go?

2) How about a nice, clean, source tarball? Yes, I know you have a tagged
svn release, but a tarball is nicer, one that's source only, with no
precompiled things (in particular, no jars under app/lib, and no jre.tgz).
It would be nice (once the build system is fixed) to also be able to get
rid of the platform-specific windows, linux, macosx build directories. By
the way, where's the source for the jars that you distribute?

3) Can we fix the file permissions? howto.txt shouldn't be executable.

I think the last two are pretty easy to do. I'd like to help with the first
one. Oh, and you guys should try using OpenJDK. It seems to work fine and
dandy here. It's scheduled to be the official Sun implementation of Java
anyways, and it's like 99.9% done. :-)

Before making requests, please just *do* something first. With infinite
time, I could implement all manner of requests. But I don't have that, and
as I've explained before, as the lone developer who develops, builds, and
releases Processing, such requests are exceptionally low priority for me.

I'm happy to do things to make the process easier, but not until someone
pitches in significantly, and is committed to long-term maintenance. This
bug has been open for a year and a half and we last heard from you 13
months ago. There's nothing wrong with that, I simply need to prioritize my
time.

Okay, should I make the clean source tarball for you to sanctify and put
on the website?

i think it's very important not to forget that most people will only care
about the binary package and having the "proper" source packages a vehicle
to get processing into the official repositories.

so is this the intended way:
processing source -> source tarball -> debian source package -> debian
binary package
?
would this work (semi-) automated?

@swap - do you have a good (step by step) guide for how to build java
source packages? you can reach me at "super, superduper.org" if you wanna
work on this together...

In reply to comment #35)

> i think it's very important not to forget that most people will only care
> about the binary package and having the "proper" source packages a vehicle
> to get processing into the official repositories.

Right. Which is why this is entirely justified in being a very
low-priority project.

> so is this the intended way:
> processing source -> source tarball -> debian source package -> debian
> binary package
> ?

Pretty much, yes.

> would this work (semi-) automated?

Ideally yes, but not right now. I am starting to think that the proper
source package isn't going to happen until we are able to move
Processing to build with Ant. It's easy right now to just rip out
jre.tgz and the jars that don't belong in a source package, but we'll
get something pretty useless that has no hope of building.

> @swap - do you have a good (step by step) guide for how to build java
> source packages?

Well, once it builds with Ant, it should be pretty trivial. The source
tarball basically has to be what the svn checkout for 1.0.1 is, except
without the jars and without the jre.tgz.

> you can reach me at "super, superduper.org" if you wanna
> work on this together...

I'm trying to recruit more help from Debian Java developers

http://lists.debian.org/debian-java/2008/12/msg00003.html

Since this is a project that mostly only interests Debian and
derivatives (like you said, everyone else is happy getting the
binaries), I think it makes sense to keep the project within Debian
infrastructure. We can set up an svn on Debian's dev server, Alioth,
and mailing lists and what not.

this view might not be ideal in the long run but for now - would it be okay
to consider some of the jars as artefacts? just like png images aren't
rendered from some other source...

i do have a lot of ant experience and from what i've seen it should be
fairly easy to write a build file that replaces the perl script. i would
have time to do this somepoint around new years (leaving for a longer
vacation this week...). would that help? if yes i'll write myself a
reminder...

(In reply to comment #37)
> this view might not be ideal in the long run but for now - would it
be okay
> to consider some of the jars as artefacts? just like png images aren't
> rendered from some other source...

I don't think so... First, such a work would never get accepted into Debian
(and probably not Ubuntu either), since it duplicates code already in
Debian (e.g. Debian already ships its own jars for JOGL). Plus, if any of
those jars are under the (L)GPL, they have to be shipped with source. For
instance, I see that Tritonus is under the LGPL, but it seems to be shipped
without source. Lastly, *most* of the work in packaging this is gonna be
tracking down those jars and making Processing build properly when the jars
are provided by the system instead of being shipped by Processing.

> i do have a lot of ant experience and from what i've seen it should be
> fairly easy to write a build file that replaces the perl script.

Nice. I've just started getting into reading about Ant yesterday and try a
few toy examples.

I'm seeing about how we can get a VCS set up. I was thinking of Debian's
Alioth, but I'm not sure if we actually need all of its infrastructure. I
suppose the present Bugzilla is sufficient for discussion.

okay, everything but the preprocessor-stuff is built using ant scripts now.
i made tiny sub-buildfiles for every component (app, core, serial, etc.)
and one bigger one that collects all the files to assemble the application
(so far linux only).

swap - now if i understand you correctly having jogl.jar, itext.jar etc.
precompiled in the libraries' folders is still cheating. any suggestion how
to get around this? would we really have to have source jars (say
jogl-src.jar) that are automatically extracted, compiled and packaged into
jars by ant?

about the vcs: yea, i wouldn't worry about that for now...

Hey, could I see the ant script you've made?

Oh, it's not that we need to put all of Processing's source packages in one
single package. Ideally, we create or find packages for other things in
Debian and Ubuntu that Processing uses. JOGL is one example of something
that we can already grab from a Debian package, but there are a bunch of
other libraries that we need to track down.

hey!

sorry... have the build scripts on a computer i don't have access to right
now, however,
jeff ramsdale (and i guess me) are working on fixing bug 151
(http://dev.processing.org/bugs/show_bug.cgi?id=151) which would save this
bug here a whole lot of work.

i'll write back as soon as there's some work produced

Alright... so what's it gonna be? ant or maven? Or both?

Response added to Bug #151 since it's more relevant (for others looking for
the information) there.