New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare debian package and add repository for proper distribution on Linux #114

Closed
processing-bugs opened this Issue Feb 10, 2013 · 52 comments

Comments

Projects
None yet
5 participants
@processing-bugs

Original author: b...@processing.org (June 07, 2010 00:59:48)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=596

Comment from fry, 2007-07-15 11:36

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.

Original issue: http://code.google.com/p/processing/issues/detail?id=75

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:48
Comment from Swap, 2007-07-15 18:59

(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.

From b...@processing.org on June 07, 2010 00:59:48
Comment from Swap, 2007-07-15 18:59

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:49
Comment from fry, 2007-07-17 15:08

cool, so what's our next step?

From b...@processing.org on June 07, 2010 00:59:49
Comment from fry, 2007-07-17 15:08

cool, so what's our next step?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:49
Comment from fry, 2007-07-17 15:09

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.

From b...@processing.org on June 07, 2010 00:59:49
Comment from fry, 2007-07-17 15:09

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:50
Comment from Swap, 2007-07-17 15:34

(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).

From b...@processing.org on June 07, 2010 00:59:50
Comment from Swap, 2007-07-17 15:34

(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).

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:51
Comment from Swap, 2007-07-17 15:37

(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.

From b...@processing.org on June 07, 2010 00:59:51
Comment from Swap, 2007-07-17 15:37

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:51
Comment from hansi, 2007-07-19 06:19

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

From b...@processing.org on June 07, 2010 00:59:51
Comment from hansi, 2007-07-19 06:19

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:52
Comment from Swap, 2007-07-19 10:51

(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. :-)

From b...@processing.org on June 07, 2010 00:59:52
Comment from Swap, 2007-07-19 10:51

(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. :-)

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:52
Comment from fry, 2007-07-20 15:36

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.

From b...@processing.org on June 07, 2010 00:59:52
Comment from fry, 2007-07-20 15:36

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:53
Comment from hansi, 2007-07-23 20:51

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.

From b...@processing.org on June 07, 2010 00:59:53
Comment from hansi, 2007-07-23 20:51

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:54
Comment from hansi, 2007-07-23 22:37

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.

From b...@processing.org on June 07, 2010 00:59:54
Comment from hansi, 2007-07-23 22:37

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:54
Comment from fry, 2007-07-24 05:50

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?

From b...@processing.org on June 07, 2010 00:59:54
Comment from fry, 2007-07-24 05:50

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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:54
Comment from hansi, 2007-07-24 06:33

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.

From b...@processing.org on June 07, 2010 00:59:54
Comment from hansi, 2007-07-24 06:33

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:55
Comment from fry, 2007-07-24 11:16

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?

From b...@processing.org on June 07, 2010 00:59:55
Comment from fry, 2007-07-24 11:16

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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:56
Comment from hansi, 2007-07-24 11:28

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

From b...@processing.org on June 07, 2010 00:59:56
Comment from hansi, 2007-07-24 11:28

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:56
Comment from hansi, 2007-07-31 20:31

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...

From b...@processing.org on June 07, 2010 00:59:56
Comment from hansi, 2007-07-31 20:31

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...

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:57
Comment from Swap, 2007-08-01 12:19

(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.

From b...@processing.org on June 07, 2010 00:59:57
Comment from Swap, 2007-08-01 12:19

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:58
Comment from Swap, 2007-08-01 12:21

(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.

From b...@processing.org on June 07, 2010 00:59:58
Comment from Swap, 2007-08-01 12:21

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:58
Comment from hansi, 2007-08-01 12:45

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...

From b...@processing.org on June 07, 2010 00:59:58
Comment from hansi, 2007-08-01 12:45

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...

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:59
Comment from hansi, 2007-09-21 09:08

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

From b...@processing.org on June 07, 2010 00:59:59
Comment from hansi, 2007-09-21 09:08

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:59
Comment from fry, 2007-09-23 01:16

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.

From b...@processing.org on June 07, 2010 00:59:59
Comment from fry, 2007-09-23 01:16

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 00:59:59
Comment from Swap, 2007-09-24 10:41

(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.

From b...@processing.org on June 07, 2010 00:59:59
Comment from Swap, 2007-09-24 10:41

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:00
Comment from hansi, 2007-10-29 12:23

another nudge :)

From b...@processing.org on June 07, 2010 01:00:00
Comment from hansi, 2007-10-29 12:23

another nudge :)

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:01
Comment from Swap, 2007-10-29 13:06

(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...

  1. 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.

  2. Could anything conceivably break if I remove the non-Linux files?

Thanks!

From b...@processing.org on June 07, 2010 01:00:01
Comment from Swap, 2007-10-29 13:06

(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...

  1. 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.

  2. Could anything conceivably break if I remove the non-Linux files?

Thanks!

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:01
Comment from hansi, 2007-10-29 16:29

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.

  1. 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

  2. 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...

  1. 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"?

  1. 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,-

From b...@processing.org on June 07, 2010 01:00:01
Comment from hansi, 2007-10-29 16:29

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.

  1. 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

  2. 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...

  1. 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"?

  1. 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,-

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:01
Comment from fry, 2007-11-01 04:51

  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.

  1. 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).

  2. the non-linux files?

From b...@processing.org on June 07, 2010 01:00:01
Comment from fry, 2007-11-01 04:51

  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.

  1. 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).

  2. the non-linux files?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:02
Comment from Swap, 2007-11-01 11:18

(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
  1. 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.

  1. 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.

  1. 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.

From b...@processing.org on June 07, 2010 01:00:02
Comment from Swap, 2007-11-01 11:18

(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
  1. 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.

  1. 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.

  1. 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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:02
Comment from hansi, 2008-01-13 12:48

Created an attachment (id=178)
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!

From b...@processing.org on June 07, 2010 01:00:02
Comment from hansi, 2008-01-13 12:48

Created an attachment (id=178)
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!

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:03
Comment from fry, 2008-01-17 19:45

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

From b...@processing.org on June 07, 2010 01:00:03
Comment from fry, 2008-01-17 19:45

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:03
Comment from artifact, 2008-03-19 14:49

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

From b...@processing.org on June 07, 2010 01:00:03
Comment from artifact, 2008-03-19 14:49

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:04
Comment from hansi, 2008-03-21 04:00

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?

From b...@processing.org on June 07, 2010 01:00:04
Comment from hansi, 2008-03-21 04:00

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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:05
Comment from sun-tracker, 2008-08-19 17:20

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

From b...@processing.org on June 07, 2010 01:00:05
Comment from sun-tracker, 2008-08-19 17:20

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:05
Comment from Swap, 2008-12-07 05:58

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. :-)

From b...@processing.org on June 07, 2010 01:00:05
Comment from Swap, 2008-12-07 05:58

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. :-)

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:06
Comment from fry, 2008-12-08 10:27

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.

From b...@processing.org on June 07, 2010 01:00:06
Comment from fry, 2008-12-08 10:27

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:06
Comment from Swap, 2008-12-08 10:56

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

From b...@processing.org on June 07, 2010 01:00:06
Comment from Swap, 2008-12-08 10:56

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:10
Comment from hansi, 2008-12-08 11:51

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...

From b...@processing.org on June 07, 2010 01:00:10
Comment from hansi, 2008-12-08 11:51

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...

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:10
Comment from Swap, 2008-12-08 12:43

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.

From b...@processing.org on June 07, 2010 01:00:10
Comment from Swap, 2008-12-08 12:43

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:11
Comment from hansi, 2008-12-08 13:04

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...

From b...@processing.org on June 07, 2010 01:00:11
Comment from hansi, 2008-12-08 13:04

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...

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:12
Comment from Swap, 2008-12-09 07:33

(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.

From b...@processing.org on June 07, 2010 01:00:12
Comment from Swap, 2008-12-09 07:33

(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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:12
Comment from hansi, 2009-01-02 08:49

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...

From b...@processing.org on June 07, 2010 01:00:12
Comment from hansi, 2009-01-02 08:49

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...

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:13
Comment from Swap, 2009-01-27 12:50

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

From b...@processing.org on June 07, 2010 01:00:13
Comment from Swap, 2009-01-27 12:50

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:13
Comment from Swap, 2009-01-27 13:09

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.

From b...@processing.org on June 07, 2010 01:00:13
Comment from Swap, 2009-01-27 13:09

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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:14
Comment from hansi, 2009-02-03 06:24

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

From b...@processing.org on June 07, 2010 01:00:14
Comment from hansi, 2009-02-03 06:24

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:15
Comment from Swap, 2009-02-15 03:36

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

From b...@processing.org on June 07, 2010 01:00:15
Comment from Swap, 2009-02-15 03:36

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:15
Comment from fry, 2009-02-15 05:17

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

From b...@processing.org on June 07, 2010 01:00:15
Comment from fry, 2009-02-15 05:17

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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 19:37:15
Improved Startup Script (from hansi)

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!

From b...@processing.org on June 07, 2010 19:37:15
Improved Startup Script (from hansi)

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!

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From mamba2...@gmail.com on August 20, 2010 21:23:35
I think the script is flakey, as it relies on sun being included the "name" of the alternatives, which it need not be. Also what about the included jdk, that isn't detected unless the user manually sets it up as alternative?
Why not just just ignore the alternatives system.....

From mamba2...@gmail.com on August 20, 2010 21:23:35
I think the script is flakey, as it relies on sun being included the "name" of the alternatives, which it need not be. Also what about the included jdk, that isn't detected unless the user manually sets it up as alternative?
Why not just just ignore the alternatives system.....

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From f...@processing.org on July 29, 2012 15:25:58
We'd love to see a contributed, working .deb so that we can better support Ubuntu in particular (and Mint or vanilla Debian as well). To get this rolling, I strongly recommend that whoever wants to give it a shot begins with simply bundling the current code as-is, without worrying about proper dependency linking and not trying to reorganize the current code layout to be more "correct".

Several people have started this packaging effort, but it gets undermined by attempting too much, or the tail wagging the dog when I'm asked to redo the build system for the benefit of maintaining a Debian-compatible package. While important, this is for a very small portion of our audience (2-3% on Linux, then whatever percent of those are using a deb-compatible distro).

The two exceptions for dependencies are Sun (Oracle) Java (OpenJDK does not work properly yet), and GStreamer. But as for ant, the Eclipse tools, launch4j and others, please just use what's checked in. Once we have a decent working deb, we can start moving these out too, but let's get something usable first.

From f...@processing.org on July 29, 2012 15:25:58
We'd love to see a contributed, working .deb so that we can better support Ubuntu in particular (and Mint or vanilla Debian as well). To get this rolling, I strongly recommend that whoever wants to give it a shot begins with simply bundling the current code as-is, without worrying about proper dependency linking and not trying to reorganize the current code layout to be more "correct".

Several people have started this packaging effort, but it gets undermined by attempting too much, or the tail wagging the dog when I'm asked to redo the build system for the benefit of maintaining a Debian-compatible package. While important, this is for a very small portion of our audience (2-3% on Linux, then whatever percent of those are using a deb-compatible distro).

The two exceptions for dependencies are Sun (Oracle) Java (OpenJDK does not work properly yet), and GStreamer. But as for ant, the Eclipse tools, launch4j and others, please just use what's checked in. Once we have a decent working deb, we can start moving these out too, but let's get something usable first.

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Aug 16, 2013

One linux distro is already supporting processing checkout:-https://www.archlinux.org/packages/community/i686/processing/
Currently at processing-2.0.2 (they didn't hang about).
From what I've read debian folks require source (possibly for all binaries) and if apache can't get along with them some chance of an individual... You could just suggest people unzip processing in /usr/share like ArchLinux does, they then create a link to processing and java-processing to /usr/bin. The more debian way to do this is:-

sudo update-alternatives --install /usr/bin/processing processing /usr/share/processing-2.0.2/processing 100

and

sudo update-alternatives --install /usr/bin/processing-java processing-java /usr/share/processing-2.0.2/processing-java 100

It should not be too difficult to create a kde/gnome/etc launcher.
https://gist.github.com/monkstone/6256117

One linux distro is already supporting processing checkout:-https://www.archlinux.org/packages/community/i686/processing/
Currently at processing-2.0.2 (they didn't hang about).
From what I've read debian folks require source (possibly for all binaries) and if apache can't get along with them some chance of an individual... You could just suggest people unzip processing in /usr/share like ArchLinux does, they then create a link to processing and java-processing to /usr/bin. The more debian way to do this is:-

sudo update-alternatives --install /usr/bin/processing processing /usr/share/processing-2.0.2/processing 100

and

sudo update-alternatives --install /usr/bin/processing-java processing-java /usr/share/processing-2.0.2/processing-java 100

It should not be too difficult to create a kde/gnome/etc launcher.
https://gist.github.com/monkstone/6256117

@hellocatfood

This comment has been minimized.

Show comment
Hide comment
@hellocatfood

hellocatfood Dec 30, 2013

I've written a short guide on "installing" processing, creating a (Unity) launcher and associating .pde files with processing

http://askubuntu.com/questions/396857/how-can-i-add-processing-to-the-unity-launcher

Does this help in getting it into repositories?

I've written a short guide on "installing" processing, creating a (Unity) launcher and associating .pde files with processing

http://askubuntu.com/questions/396857/how-can-i-add-processing-to-the-unity-launcher

Does this help in getting it into repositories?

@kfeuz

This comment has been minimized.

Show comment
Hide comment
@kfeuz

kfeuz Nov 12, 2014

Contributor

As @benfry mentions, several people have started work on this before but never produced a working package. In attempting to avoid the previous pitfalls I have created a binary only .deb package which I have tested on several clean installs of various debian based distributions (primarily Ubuntu and Mint). Everything seems to work okay for me. I followed the organizational structure suggested by @hellocatfood and included a launcher and mime-type files. I did not associate the .pde files by default during the installation process but I believe it would be straight-forward to include if it is desired.

Before I submit a pull request I have two questions. Is there a contact I should put down as the maintainer of the package? Currently I just used my own contact information. I am fine leaving my info in place but I thought I would check first.

Second do you want to include copyright and license information? If so, I need a list of which files fall under which license, who the copyright owners are and the copyright dates. Since the package is just a binary distribution and I am not aiming to get it included in any of the package archives, leaving off this information is fine with me. The package still installs without any errors.

Contributor

kfeuz commented Nov 12, 2014

As @benfry mentions, several people have started work on this before but never produced a working package. In attempting to avoid the previous pitfalls I have created a binary only .deb package which I have tested on several clean installs of various debian based distributions (primarily Ubuntu and Mint). Everything seems to work okay for me. I followed the organizational structure suggested by @hellocatfood and included a launcher and mime-type files. I did not associate the .pde files by default during the installation process but I believe it would be straight-forward to include if it is desired.

Before I submit a pull request I have two questions. Is there a contact I should put down as the maintainer of the package? Currently I just used my own contact information. I am fine leaving my info in place but I thought I would check first.

Second do you want to include copyright and license information? If so, I need a list of which files fall under which license, who the copyright owners are and the copyright dates. Since the package is just a binary distribution and I am not aiming to get it included in any of the package archives, leaving off this information is fine with me. The package still installs without any errors.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 15, 2014

Member

Go ahead and use your contact info, since the main thing here is having someone who can maintain it as an ongoing thing. But please let us know if you cease ongoing maintenance.

For the license portion, the /core files are LGPL and the /app files are GPL. But elsewhere, we have more work to do on cleaning up and identifying the licenses for everything else. That's covered here: #224

Member

benfry commented Nov 15, 2014

Go ahead and use your contact info, since the main thing here is having someone who can maintain it as an ongoing thing. But please let us know if you cease ongoing maintenance.

For the license portion, the /core files are LGPL and the /app files are GPL. But elsewhere, we have more work to do on cleaning up and identifying the licenses for everything else. That's covered here: #224

@benfry benfry added the help wanted label Nov 19, 2014

benfry added a commit that referenced this issue Nov 19, 2014

Merge pull request #2972 from kfeuz/Issue114
Create .deb binary packages with ant. Fixes issue #114
@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 19, 2014

Member

Now incorporated with #2972, just a matter of using ant deb.

Member

benfry commented Nov 19, 2014

Now incorporated with #2972, just a matter of using ant deb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment