Ubuntu installation instructions

[Jan Groenewald]

Hi

Could we add PPA (Ubuntu 11.04 and higher) installation instructions to:
http://www.sagemath.org/doc/installation/binary.html#linux-and-os-x

sudo apt-add-repository -y ppa:aims/sagemath
sudo apt-get update
sudo apt-get install sagemath-upstream-binary
sudo apt-get get install sagemath-optional # optional

Regards,
Jan



--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^

[Andrea Lazzarotto]

I didn't know about the PPA, that's great! :-)

Andrea Lazzarotto
(inviato da Android)

[Jeroen Demeyer]

On 2012-07-11 10:28, Jan Groenewald wrote:
> Hi
>
> Could we add PPA (Ubuntu 11.04 and higher) installation instructions to:
> http://www.sagemath.org/doc/installation/binary.html#linux-and-os-x
>
> sudo apt-add-repository -y ppa:aims/sagemath
> sudo apt-get update
> sudo apt-get install sagemath-upstream-binary
> sudo apt-get get install sagemath-optional # optional

What is a PPA, what does it do, how does it get created, can this be
automated?

[Minh Nguyen]

Hi Jan,

On Wed, Jul 11, 2012 at 6:28 PM, Jan Groenewald <j...@aims.ac.za> wrote:
> Could we add PPA (Ubuntu 11.04 and higher) installation instructions to:
> http://www.sagemath.org/doc/installation/binary.html#linux-and-os-x

This is now ticket #13228:

http://trac.sagemath.org/sage_trac/ticket/13228

On the ticket or a patch to the ticket, perhaps you would add some
explanation about PPA?

--
Regards,
Minh Van Nguyen
http://bit.ly/mvngu

[John Cremona]

See http://en.wikipedia.org/wiki/Personal_Package_Archive

(Wikipedia has several possibilities for PPA but I assume this is not
the Professional Putters Association, or any of the others).

John

> --
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

[Jan Groenewald]

Hi

A PPA is a personal package archive, provided on the launchpad platform
of Canonical, the company behind Ubuntu. Here one can host one's own
free software packages for Ubuntu.

http://en.wikipedia.org/wiki/Personal_Package_Archive
http://blog.launchpad.net/ppa/personal-package-archives-for-everyone
https://launchpad.net/ubuntu/+ppas

Then the package works via apt and the software centre,
so for example can get updates.

It can be automated up to a point. I am scripting bits of it.
There will be potential hiccups --

1) I gpg sign the packages. I enter my password for this.
Even this can be automated with expect or perhaps directly with
the debuild (debian package building) tools, and if sagemath took over
the PPA and the key and signing, many people can be in a team and sign
a package, I think. You sign to upload, launchpad rebuilds and signs
the packages with the PPA key.

2) If upstream changes become incompatible with the current rollout,
the PPA will suddenly break many poeple's sage. I do (some very basic)
testing of the package before I upload. Even this can be automated, I guess.
How do I re-run all the tests in a binary installation?
sage -testall?

Regards,
Jan





 

--
--
To post to this group, send an email to sage-...@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[Jeroen Demeyer]

On 2012-07-11 10:58, Jan Groenewald wrote:
> http://en.wikipedia.org/wiki/Personal_Package_Archive
> http://blog.launchpad.net/ppa/personal-package-archives-for-everyone
> https://launchpad.net/ubuntu/+ppas

So if I understand things correctly, we give them our source and they
build it for us, is that right?

We could still use the buildbot to test the PPA-built binaries (at least
some systems).

I'd like to automate as much as possible of the release process. The
more is done by hand and the more different people are involved, the
more chance there is of something going wrong (where "wrong" could just
mean something not being updated).

[Andrea Lazzarotto]

Il giorno 11/lug/2012 11:08, "Jeroen Demeyer" <jdem...@cage.ugent.be> ha scritto:
>
> On 2012-07-11 10:58, Jan Groenewald wrote:
> > http://en.wikipedia.org/wiki/Personal_Package_Archive
> > http://blog.launchpad.net/ppa/personal-package-archives-for-everyone
> > https://launchpad.net/ubuntu/+ppas
>
> So if I understand things correctly, we give them our source and they
> build it for us, is that right?

No, PPAs contain binaries and also the corresponding sources, you have to successfully build a package in order to upload it to the PPA for other people to download it.

Andrea Lazzarotto

[Jan Groenewald]

Hi

Normally, PPAs are used to compile source the debian way into debian packages.

I work at an institution that heavily uses both Sage and Ubuntu, upgrades a lot
institutionally, trains people with low Linux Skills to run similar institutional deployments,
offer it to private visitor laptops and I needed this to be done via a PPA immediately.
So I created a upstream-binary PPA. We also use PPAs to make metapackages,
e.g. aims-desktop, which depends on all the stuff we need installed on all our
institutional desktops (or visiting laptops).

Step two would be a from-source monolithic PPA would probably be used until/if sage
gets into debian proper. I hope to work on that at some point, but it is quite intimidating
before gets two weeks off to start on it.

Step three would be a monolithic from-source Sage in Debian and whether or not a non-monolithic
i.e. depending on debian components, debianization gets finished, is not my call now.

Debian will fight the intermediate steps all the way, as it is the Wrong Way. I did it because
I needed it Now not Later.

So, this upstream-binary PPA was a bit of a cheat. In the meantime, to bridge the gap to
all those future goals, in the interest of

1) easy installation for Ubuntu people
2) automatic update notifications via the official package management/software centre
3) signed packages

I have created a kind of "fake" package that
1) untars the upstream binaries from buildbot for 32 and 64bit Ubuntu 12.04 (more versions later)
2) skips compiling any source
3) simply copies them into the right place (/usr/lib/sage).

Notes:

A default PPA is 2G. I have requested doubling this twice and will need to again
if I create this for all supported Ubuntu versions. (I think otherwise one can purchase
more).

Each time I speak to launchpad/Ubuntu people, they get confused again, suspect
that this is a binary package, violating GPL, and re-iterate to me that this is
the Wrong Way To Do Things (and I re-iterate that it bloody well Fills The Gap),
and ask for assistance in Debianization and point them at the latest effort
that way: http://lists.debian.org/debian-science/2012/05/msg00092.html

Regards,
Jan

[Andrea Lazzarotto]

Well, maybe I didn't understand properly your "they"... did you mean the final users or the Launchpad system?

Andrea Lazzarotto
(inviato da Android)

[Jan Groenewald]

Hi

On 11 July 2012 11:08, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

On 2012-07-11 10:58, Jan Groenewald wrote:
> http://en.wikipedia.org/wiki/Personal_Package_Archive
> http://blog.launchpad.net/ppa/personal-package-archives-for-everyone
> https://launchpad.net/ubuntu/+ppas

So if I understand things correctly, we give them our source and they
build it for us, is that right?

Yes. Normally. Except this particular package simply copies the buildbot
built files. My reasoning is mostly to work within the Ubuntu package manager.
but a future from-source monolithic Sage would build on the launchpad
farm, yes. One is supposed to test building locally before uploading,
and so not to simply use buildbot as a compile test.

We could still use the buildbot to test the PPA-built binaries (at least
some systems).

I'd like to automate as much as possible of the release process.  The
more is done by hand and the more different people are involved, the
more chance there is of something going wrong (where "wrong" could just
mean something not being updated).

I will most certainly start to put together a script that can download
new buildbot binaries, and make a package, install it, run all sage
tests again (64bit anyway), only prompting me to sign the packages
before uploading (if the tests passed).

Regards,
Jan

[Jan Groenewald]

Hi

You can upload packages that fail to build on launchpad. You are supposed to test
them properly first. Nothing technically stops you.

In particular, this package is like a binary (documentation or non-free driver)
package: it just copies files in place.

It HAPPENS to include all the source, but when I speak to launchpad people
they are immediately suspicious of a binary package, as it might violate GPL.

So far I do NOT upload the binary debs, only the "source" (in my case a debian
package source including upstream built binaries). It then builds the deb packages,
and if successful publishes them.

Regards,
Jan 

[Jan Groenewald]

Hi

On 11 July 2012 11:24, Andrea Lazzarotto <andrea.l...@gmail.com> wrote:

Well, maybe I didn't understand properly your "they"... did you mean the final users or the Launchpad system?

Launchpad "builds", yes. Usually source. In our case a debian package
wrapped around a binary. So "building" is midleading.

Also launchpad is a buildfarm, but is not supposed to be used as a buildbot,
as your packages are supposed to be built and tested using debian development
tools. If you use pbuilder, you should theoretically be able to build just as
launchpad will do it.

End users download binaries. End users may not know what "binaries"
or "source" are. They click on the "app". This is what we provide so we
don't have to explain to people what "tar" is. Never mind "permissions".

Regards,
Jan

[Andrea Lazzarotto]

Ok yes, at the first time I misunderstood the sentence and thought you were talking about standard users, in a Gentoo like fashion. Sorry for the confusion.

[Jan Groenewald]

Hi

On 11 July 2012 11:45, Andrea Lazzarotto <andrea.l...@gmail.com> wrote:

Ok yes, at the first time I misunderstood the sentence and thought you were talking about standard users, in a Gentoo like fashion. Sorry for the confusion.

I cannot resist. Gentoo users are "standard"?
http://funroll-loops.info/

;-)

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 11:08, Jeroen Demeyer wrote:
> On 2012-07-11 10:58, Jan Groenewald wrote:
>> http://en.wikipedia.org/wiki/Personal_Package_Archive
>> http://blog.launchpad.net/ppa/personal-package-archives-for-everyone
>> https://launchpad.net/ubuntu/+ppas
>
> So if I understand things correctly, we give them our source and they
> build it for us, is that right?

"them" = Launchpad

[Jeroen Demeyer]

On 2012-07-11 11:33, Jan Groenewald wrote:
> Hi
>
> On 11 July 2012 11:24, Andrea Lazzarotto <andrea.l...@gmail.com

> <mailto:andrea.l...@gmail.com>> wrote:
>
> Well, maybe I didn't understand properly your "they"... did you mean
> the final users or the Launchpad system?
>
> Launchpad "builds", yes. Usually source. In our case a debian package
> wrapped around a binary. So "building" is midleading.

Why "in our case a Debian package wrapped around a binary"? What's the
point of that? If Launchpad builds, why not actually build on Launchpad?

> Also launchpad is a buildfarm, but is not supposed to be used as a buildbot,
> as your packages are supposed to be built and tested using debian
> development
> tools.

I don't understand the difference between "buildfarm" and "buildbot",
unless you mean that buildbot should also *test* while the buildfarm
doesn't.

[Jan Groenewald]

Hi

On 11 July 2012 12:49, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

On 2012-07-11 11:33, Jan Groenewald wrote:
> Hi
>
> On 11 July 2012 11:24, Andrea Lazzarotto <andrea.l...@gmail.com

> <mailto:andrea.l...@gmail.com>> wrote:
>
>     Well, maybe I didn't understand properly your "they"... did you mean
>     the final users or the Launchpad system?
>
> Launchpad "builds", yes. Usually source. In our case a debian package
> wrapped around a binary. So "building" is midleading.

Why "in our case a Debian package wrapped around a binary"?  What's the
point of that?  If Launchpad builds, why not actually build on Launchpad?

Because even a monolithic from-source fails to build.

debuild has many rules and requirements. It does not just run make.
It bombs out on adding -Wsymbolic to the maxima install. I did not even
get much further.

I opted to make a binary package instead, because I could finish that quickly.

When launchpad "builds" my package, it is spending about an hour and a half
untarring and uncompressing and retarring and recompressing the amd64 and
i686 binaries I got from sagemath.org (those built by the current sage buildbot network).
It never compiles code, because I disabled that in the debian/rules file, because
this was the quick and easy way to a package management system the way
I need it: signed, update-able, and through the official package manager for Ubuntu.
 

> Also launchpad is a buildfarm, but is not supposed to be used as a buildbot,
> as your packages are supposed to be built and tested using debian
> development
> tools.

 

I don't understand the difference between "buildfarm" and "buildbot",
unless you mean that buildbot should also *test* while the buildfarm
doesn't.

Launchpad's build farm (hardware and software) is intended to build *packages* after you have
tested building the *code* on your own hardware. It does usually compile your code again in a
clean environment, but it's intention is to produce a package, not to test your code compilation.
It is also testing installation of build dependencies, of runtime dependencies, etc.

Sage's Buildbot (software) is meant to build *code* (and binaries), but not to make a package
for any particular distribution's package management.

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 12:57, Jan Groenewald wrote:
> When launchpad "builds" my package, it is spending about an hour and a half
> untarring and uncompressing and retarring and recompressing the amd64 and

> i686 binaries I got from sagemath.org <http://sagemath.org> (those built

> by the current sage buildbot network).
> It never compiles code, because I disabled that in the debian/rules
> file, because
> this was the quick and easy way to a package management system the way
> I need it: signed, update-able, and through the official package manager
> for Ubuntu.

If Launchpad for Sage doesn't do more than move files around and
repackage them, why do we need Launchpad in the first place?
Why can't we do this packaging in Sage itself?

[Jan Groenewald]

Hi

Technically it might be possible to reproduce my Ubuntu needs/goals by
automating in Sage's buildbot network instead of me doing it. I want this:

0) a system-wide install by default, not per-user (think computer lab environment)
1) so I can cryptographically sign packages via an APT debian package mechanism
2) so I can be notified of updates via update-manager, and even automate
installation if I wish
3) so that  the package are available in the distribution's official software centre
and from a launchpad PPA, which has a fair degree of trust from the community
4) more Ubuntu versions, in future, all supported Ubuntu versions

I guess this could be doable: Have Sage's buildbot network build
the system-wide debian package, by running the appropriate commands
on Ubuntu build-slaves, install the debian package on itself, re-run the tests,
sign the package, upload to a PPA. I am happy to try and help with that attempt
while I keep the current PPA running in the meantime.

Regards,
Jan

[Jeroen Demeyer]

Another obvious question: why are we not actually building from source
on Launchpad? From what I understand, building from source is the usual
thing to do.

[Jan Groenewald]

Hi Jeroen,

 
It's too hard. Sage fails to compile. I could not fix it.

I spent some trying this, and got stuck on too many
library errors in too many different components of Sage.
maxima failed to build because in that environment
debian/rules added the -Wsymbolic flag to gcc.

Actually, you could cheat, and in the postinst script run
"make", but this is even more horrible than
copying the binary, and much less immune
to being interrupted, as the package management
system could get broken, and then all software updates,
which is a system-wide effect way past the sage install.
It can break all security updates as apt-get update and
apt-get install anything will start to give errors about the
broken package. I also had heavy resistance from the
volunteers teaching me debian packaging to this approach.

What I could complete in the allotted two weeks I had to teach
myself debian packaging, was a binary repackage.

When my time allows, a monolithic from-source is my next project.
If I do it alone, after hours, my best current guess is it can take a year.

If there is any assistance, that project can start now.
Until it is ready, I am maintaining the from-binary PPA.

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 15:13, Jan Groenewald wrote:
> It's too hard. Sage fails to compile.

> I spent some trying this, and got stuck on too many
> library errors in too many different components of Sage.

How does this build Sage? Clearly it doesn't just do "make", but then
what does it do?

[Jeroen Demeyer]

On 2012-07-11 15:13, Jan Groenewald wrote:

> When my time allows, a monolithic from-source is my next project.

Apologies if I ask a totally stupid question, but why can't you replace
the "download and extract binary" step that you currently have by
"dowload and extract source && make"?

In other words: I still don't understand what is different about the
Launchpad environment that Sage doesn't build from source.

[Jan Groenewald]

Hi

debuild, which calls about a hundred dh_* commands.

I don't profess to understand or know all of those. I guess that is why I didn't finish.
This link shows a high level breakdown of what debuild does:
http://www.debian.org/doc/manuals/maint-guide/build.en.html#completebuild


Regards,
Jan

[Jan Groenewald]

Hi

On 11 July 2012 15:36, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

On 2012-07-11 15:13, Jan Groenewald wrote:

> When my time allows, a monolithic from-source is my next project.

Apologies if I ask a totally stupid question, but why can't you replace
the "download and extract binary" step that you currently have by
"dowload and extract source && make"?

I don't think it makes a big difference if I take a buildbot built binary,
or whether I make one myself (though I am not sure what all the requirements are
after setting SAGE_FAT_BINARY, to be sure to have a binary for all 64bit platforms.
I was afraid of breaking that, so I didn't. If I get to understand buildbot, and what variables
you set, and what scritps need to be run, or whether it is just sage -bdist, I can then do
that myself. However, I've managed to give you a buildslave so this is now already done.)
 

In other words: I still don't understand what is different about the
Launchpad environment that Sage doesn't build from source.

You don't get a shell to type make. You don't get to do anything but
upload a source package. So "make a binary myself" means on my
own machine, not on launchpad. That step happens BEFORE uploading
to launchpad. Launchpad does not accept source code. It accepts debian
source packages.

That is, on your OWN box, after testing in pbuilder (a debian/ubuntu
way to test building packages), you can upload with:

dput ppa:aims/sagemath sagemath-optional_5.1_source.changes

(where dput is a debian command)

where the inside of that file lists all my upstream tarball and debian
package managment files that are uploaded with it. After that launchpad
does not run make, it runs debuild, the main part being debian/rules build.

0 jan@snapperkob:~/src/sagemath-upstream-binary$cat sagemath-upstream-binary_5.1_source.changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 10 Jul 2012 20:48:35 +0200
Source: sagemath-upstream-binary
Binary: sagemath-upstream-binary
Architecture: source
Version: 5.1
Distribution: precise
Urgency: low
Maintainer: Jan Groenewald <j...@aims.ac.za>
Changed-By: Jan Groenewald <j...@aims.ac.za>
Description:
 sagemath-upstream-binary - Sage is a free open-source mathematics software system
Changes:
 sagemath-upstream-binary (5.1) precise; urgency=low
 .
Checksums-Sha1:
 464600b4a128dd2752aa525f412bf446d1113b90 2433 sagemath-upstream-binary_5.1.dsc
 153689a21bd412c24b3e3ae0cd69e5dfbd6a4288 519672192 sagemath-upstream-binary_5.1.orig-amd64.tar.xz
 bb928dbd434cbd5166117f8c5316dd45e2119068 489769212 sagemath-upstream-binary_5.1.orig-i386.tar.xz
 403bd0ef9622a02a17e181916dd2bcac71b48ce2 45 sagemath-upstream-binary_5.1.orig.tar.gz
 4e25c3f82808f300f1999a5696d77f38066626a0 24593 sagemath-upstream-binary_5.1.debian.tar.gz
Checksums-Sha256:
 89c490dc6b202bef2d470ee1fdebb215281c10584a6f41b29a3439e873ae66ac 2433 sagemath-upstream-binary_5.1.dsc
 65fd9d37c102af57ee2af6ba7f91121ae9710594a839e2ce4281ed521e78db1c 519672192 sagemath-upstream-binary_5.1.orig-amd64.tar.xz
 9c50619466139be83328cba0c68f149b777a2f7d7643203aea4ece4ddec9575c 489769212 sagemath-upstream-binary_5.1.orig-i386.tar.xz
 8884ce4e4d81a1be84e1c79a2f03330e78863b27d83d227ca249c4c0b9bfd844 45 sagemath-upstream-binary_5.1.orig.tar.gz
 b6eacae1cf4be14e07d602b2cc910583302862776b32e424d764e7a159310bd2 24593 sagemath-upstream-binary_5.1.debian.tar.gz
Files:
 3831b89aaed799926a68f71476990b5d 2433 math extra sagemath-upstream-binary_5.1.dsc
 f1a0b581a2e2aff6617bd598a7e96a39 519672192 math extra sagemath-upstream-binary_5.1.orig-amd64.tar.xz
 8f42ea73e67c64b75f6b435f37650e8b 489769212 math extra sagemath-upstream-binary_5.1.orig-i386.tar.xz
 1715a5568d0fcaa33ef525cf85725e63 45 math extra sagemath-upstream-binary_5.1.orig.tar.gz
 caa0ec937da225675567930bcf3a5cfd 24593 math extra sagemath-upstream-binary_5.1.debian.tar.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJP/RJvAAoJEOQ3NBTWsMJCP6QP/0bVS/qG1pbar+iiOpLSaQaG
jQ4fIgexWydelJbjNFccs9LLx3VLSVyKxLDajlo52AicU91aDl4Q5Fg4AncoIp3y
DaWSnao1p+lcqaLkVUcCSW4s9g6fuN7B5WreQ+nOD+sGhrFQaM/z0g8/hHwqpFtl
Tk5bPvKTKRWPVb0ST2O5FWvE9uiw5yZ9kQyKGDhUxryX77v8mgU/srvmf3ZsQtsv
VWsYsH7oQSD7WTpmuRKSVJfT3NSvil+BRysA+dZW8EBXld3jQeACkqescmIWj2fK
N7S50M+D32SHPAUa0e3w6ArfvlUPHcqsWLvwxCsKyE1XKWqRHyO9k6bUW8FpyahY
KR6ncUjIXTz9cVRB6Pq4pGmMtqjYsV2S3JUUiGa2zgjmf3+6C212MHK+pi38H1FD
fshzc4xTlmzm8SPw+oBecioKPIt2mqPS4hdTGj2ClU5zY/QUSqcxWp6S5fFFMvZ1
NcDUX270bA+eWjRaAIeR1gnkiy7PZsnOtSnO9Ow6rxrCCSCKRop3MH57wYqNC72W
DDHuMeFvSRUw/zOEJdVpMqI0qdqbX2JOz07+HAmCn4N4icb25sqnMvZiJH7kFHtK
o59ZHL0AhLM36HZz+Z7/6d7BSc6+K2Zw9moxVjpfgQMlWGLET4046iMGN1wwCzZN
8WCwIs+S3cwyqriKwUYv
=fWCr
-----END PGP SIGNATURE-----
0 jan@snapperkob:~/src/sagemath-upstream-binary$         


Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 15:49, Jan Groenewald wrote:
> I don't think it makes a big difference if I take a buildbot built binary,
> or whether I make one myself

We would automatically support all systems that Launchpad supports (are
there more versions/architectures of Ubuntu on Launchpad than currently
on the Sage buildbot?)

A minor gain is that the package building would contain fewer steps (the
Sage buildbot would not be needed).

[Jeroen Demeyer]

On 2012-07-11 15:49, Jan Groenewald wrote:

> where the inside of that file lists all my upstream tarball and debian
> package managment files that are uploaded with it. After that launchpad
> does not run make, it runs debuild, the main part being debian/rules build.

This debian/rules thing is something that you created, right? So, you
could just have it run "make".

[Julien Puydt]

Le 11/07/2012 15:36, Jeroen Demeyer a �crit :

> On 2012-07-11 15:13, Jan Groenewald wrote:
>> When my time allows, a monolithic from-source is my next project.
>
> Apologies if I ask a totally stupid question, but why can't you replace
> the "download and extract binary" step that you currently have by

> "dowload and extract source&& make"?

>
> In other words: I still don't understand what is different about the
> Launchpad environment that Sage doesn't build from source.

Well, apparently some longer explanations are needed.

(1) A user just goes in the package manager, clicks on the software
(s)he wants and it gets downloaded and installed as fast as her/his
network & disk can. Those debian packages are binary -- no compilation.

(2) The debian maintainers create source packages -- those get on the
buildbots, which use them to create (and check for sanity) binary
packages. Those binary packages are then stored in repositories where
users will fetch them.

(3) But of course, if a user has a specific need about a package, (s)he
can also download the source package, modify it and build the
corresponding binary packages, then install those (a typical example is
a custom optimized atlas package...).

(4) A binary package which hides sources and compiles itself on
installation is technically possible but is a hanging offense
(especially if it starts by recompiling dozens of existing packages for
itself in a corner of the disk and it takes hours).

Ubuntu derives from debian, so everything I wrote above applies to it ;
launchpad has its own buildbots, and it is where compilations happen. A
ppa is just a repository which isn't an official one.

Snark on #sagemath

[Jan Groenewald]

Hi

I don't know how. I could not find out in reasonable time.
It is in fact a modified makefile, with some additional debian syntax.

PS.
Just having a package run "make" is possible not in this debian/rules
file, but much easier in a postinst (post install) script, but like Julian
says, is a hanging offense, and like I said more likely to break the
user's package manager if they interrupt it, which they will, because
it takes so long, and it should not be installing post install of a binary
package on the user's computer.

Regards,
Jan

[Julien Puydt]

Le 11/07/2012 15:57, Jeroen Demeyer a �crit :

Ok, let's not panic ; this describes debian's building network, and
explains why it's necessary :
http://www.debian.org/devel/buildd/

Indeed, a *_CORRECT_* packaging of sage would make things easier :
maintainers are valuable partners of upstreams -- filtering bugs
(keeping the packaging problems for themselves, opening a single
ticket/issue even though many users reported the same thing), providing
patches, catching issues beforehand...

Snark on #sagemath

[Jeroen Demeyer]

On 2012-07-11 16:02, Julien Puydt wrote:
> Well, apparently some longer explanations are needed.

I understand all of this, but that wasn't my question.

Let me try to phrase my question better:

Currently, Jan Groenewald has a Debian Sage source package which is in
reality a Sage binary with some Debian magic added to it. That Debian
magic allows Launchpad to extract the binary and repackage it such that
end-users can install it.

Now, why cannot Jan Groenewald replace the Sage binary in his source
package by a Sage source in the source package and then trivially adjust
the Debian magic to simply run "make" on Launchpad (not in the end-user
install!).

[Julien Puydt]

Le 11/07/2012 16:48, Jeroen Demeyer a �crit :

Oh ; it would be technically possible, but I'm actually surprised the
server admins haven't already protested against such a big binary blob.
They definitely wouldn't like a source package which hides a hundred of
others -- especially when those others are already in ubuntu separately!

I have better hopes for the debian work going on : separate packages for
separate spkg. No sage-as-a-distribution, but a serious
sage-as-a-software packaging.

It's not there yet, but things are getting in place.

Snark on #sagemath

[Jan Groenewald]

Hi

Neither Launchpad nor Debian Magic allows one to trivially run "make"

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 16:15, Jan Groenewald wrote:
> I don't know how. I could not find out in reasonable time.
> It is in fact a modified makefile, with some additional debian syntax.

But didn't you already have to create such a file for the PPA you
currently have? Changing that to build from source on the Ubuntu
buildfarm should be easy.

[Jeroen Demeyer]

On 2012-07-11 17:05, Jan Groenewald wrote:
> Neither Launchpad nor Debian Magic allows one to trivially run "make"

Please elaborate. How do they prevent you from running "make"?

[Jeroen Demeyer]

On 2012-07-11 16:55, Julien Puydt wrote:
> They definitely wouldn't like a source package which hides a hundred of
> others -- especially when those others are already in ubuntu separately!

Can we find out, ask them if needed? Wouldn't they be happy if it makes
their end users happy by allowing an easier install of Sage?

[Jan Groenewald]

Hi

On 11 July 2012 16:55, Julien Puydt <julien...@laposte.net> wrote:

I have better hopes for the debian work going on : separate packages for separate spkg. No sage-as-a-distribution, but a serious sage-as-a-software packaging.

It's not there yet, but things are getting in place.

The original question was whether PPA instructions should be given on Sagemath.org

This is not a problem for me if it is not. I asked, because I expect

1) a monolithic from-source PPA or DEB
2) the debianization mentioned above

to take at least more than one year. I estimated this woudl take so long that I made
a from-binary PPA. I don't propose it as the final solution. I propose it merely.
as a currently working solution.

Regards,
Jan

[Jan Groenewald]

Hi

Maybe it should be. It is not. I found the debnian packaging documentation to
be at the wrong levels, not well integrated, and made my way ahead. I had two
weeks on IRC and reading docs and I could not find this out.

Regards,
Jan

[Julien Puydt]

Le 11/07/2012 17:05, Jan Groenewald a �crit :

> Hi
>
> On 11 July 2012 16:48, Jeroen Demeyer <jdem...@cage.ugent.be

> <mailto:jdem...@cage.ugent.be>> wrote:
>
> On 2012-07-11 16:02, Julien Puydt wrote:
> > Well, apparently some longer explanations are needed.
> I understand all of this, but that wasn't my question.
>
> Let me try to phrase my question better:
>
> Currently, Jan Groenewald has a Debian Sage source package which is in
> reality a Sage binary with some Debian magic added to it. That Debian
> magic allows Launchpad to extract the binary and repackage it such that
> end-users can install it.
>
> Now, why cannot Jan Groenewald replace the Sage binary in his source
> package by a Sage source in the source package and then trivially adjust
> the Debian magic to simply run "make" on Launchpad (not in the end-user
> install!).
>
> Neither Launchpad nor Debian Magic allows one to trivially run "make"

Uh, debian/rules has a target to trigger a build -- and it can
definitely run make. In fact, it generally does just that!

I know that : I learned to package for debian recently. I even have a
few packages I'm trying to push into debian (I need sponsorphip...).

Snark on #debian

[Jan Groenewald]

Hi

#launchpad and #ubuntu-packaging on are the best places to ask.

Regards,
Jan



 

[Jan Groenewald]

Hi

On 11 July 2012 17:12, Julien Puydt <julien...@laposte.net> wrote:

Le 11/07/2012 17:05, Jan Groenewald a écrit :

Hi

On 11 July 2012 16:48, Jeroen Demeyer <jdem...@cage.ugent.be

<mailto:jdem...@cage.ugent.be>> wrote:

    On 2012-07-11 16:02, Julien Puydt wrote:
     > Well, apparently some longer explanations are needed.
    I understand all of this, but that wasn't my question.

    Let me try to phrase my question better:

    Currently, Jan Groenewald has a Debian Sage source package which is in
    reality a Sage binary with some Debian magic added to it.  That Debian
    magic allows Launchpad to extract the binary and repackage it such that
    end-users can install it.

    Now, why cannot Jan Groenewald replace the Sage binary in his source
    package by a Sage source in the source package and then trivially adjust
    the Debian magic to simply run "make" on Launchpad (not in the end-user
    install!).

Neither Launchpad nor Debian Magic allows one to trivially run "make"

Uh, debian/rules has a target to trigger a build -- and it can definitely run make. In fact, it generally does just that!

If you show me how, I'll maintain the from-source monolithic while work continues
on debianization. Feel free to contact me off list with details.

Regards,
Jan

[Julien Puydt]

Le 11/07/2012 17:09, Jeroen Demeyer a �crit :

Yes, definitely! And a few people are quietly working on it.

I'm one of them...

Snark

[Julien Puydt]

Le 11/07/2012 17:14, Jan Groenewald a �crit :

> On 11 July 2012 17:12, Julien Puydt <julien...@laposte.net

> <mailto:julien...@laposte.net>> wrote:
> Uh, debian/rules has a target to trigger a build -- and it can
> definitely run make. In fact, it generally does just that!
>
> If you show me how, I'll maintain the from-source monolithic while work
> continues
> on debianization. Feel free to contact me off list with details.

The most basic debian/rules looks like this four lines file :

#!/usr/bin/make -f

%:
dh $@

and dh (debhelper) will already quite nicely handle many things (in
particular, it should call make and make install correctly!). If
something isn't satisfying, just add overrides. For example, something
like :

override_dh_auto_test:
make ptestlong

should run the tests automagically (by default it will run "make test"
or "make check" if the target exists... so it should already do
something sensible!).

It's pretty easy to know which overrides_* exist : as many as there are
debhelper commands listed in "man 7 debhelper"!

Of course, that is assuming sage does the right thing when make/make
test/make install are called ; I'm a little worried about the later for
instance.

Snark on #sagemath

[Jan Groenewald]

HI

On 11 July 2012 17:40, Julien Puydt <julien...@laposte.net> wrote:

Le 11/07/2012 17:14, Jan Groenewald a écrit :

On 11 July 2012 17:12, Julien Puydt <julien...@laposte.net

<mailto:julien.puydt@laposte.net>> wrote:
    Uh, debian/rules has a target to trigger a build -- and it can
    definitely run make. In fact, it generally does just that!

If you show me how, I'll maintain the from-source monolithic while work
continues
on debianization. Feel free to contact me off list with details.

The most basic debian/rules looks like this four lines file :

#!/usr/bin/make -f

%:
        dh $@

I tried that, it failed to build maxima in ways I could not fix.
I'm sorry I won't have time immediately to restart that. I will
definitely contact again when I get around to it.

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 17:11, Jan Groenewald wrote:
> Maybe it should be. It is not.

Weird, I still don't get why it should be that hard. Could you show
what you did? I mean, show the sources of the "binary" PPA.

[Jan Groenewald]

Hi

Maybe because I was not experienced in it. I will try it again.
But I don't know when exactly. Busy with other things at work.

For the source package of sagemath-upstream-binary:

apt-add-repository -y ppa:aims/sagemath
apt-get update
apt-get source sagemath-upstream-binary

If you don't have Ubuntu, log into buil...@build.aims.ac.za
and run only the last command.  The first two are done
and the last command does not require root.

Regards,
Jan

[Jan Groenewald]

Hi

On 11 July 2012 15:57, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

We would automatically support all systems that Launchpad supports (are
there more versions/architectures of Ubuntu on Launchpad than currently
on the Sage buildbot?)

Just a note on the architectures: i386, amd64, armel, powerpc

https://help.ubuntu.com/12.04/installation-guide/amd64/hardware-supported.html

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-11 17:09, Jan Groenewald wrote:
> The original question was whether PPA instructions should be given on
> Sagemath.org

I think we should first figure out the right workflow (for me this is
still: build from source on Launchpad), then add instructions.

[Jan Groenewald]

Hi

Sure, not a problem. Rather close the ticket
http://trac.sagemath.org/sage_trac/ticket/13228
now as progressing will likely take a months or years:
people have been trying various Debian related
things since 2009.

While I have a intermediate and up-to-date
working solution (for my set of problems),
it is still a temporary solution supported
by a small team with institutional priorities.

So leave it off the official documentation,
but I will be advertising, reading and supporting
PPA related mails on sage-*, unless this is felt
to be disruptive; I hope there is no current need
to split it to a separate mailing list.

Note: this topic was started by a  thread about a PPA
specific crash, which has now been fixed by providing
a 12.04 buildbot-slave, so that it is built on the correct
toolchain. The PPA is not inherently adding instability.

Regards,
Jan

[Jeroen Demeyer]

On 2012-07-12 10:06, Jan Groenewald wrote:
> Hi
>
> On 12 July 2012 09:45, Jeroen Demeyer <jdem...@cage.ugent.be

> <mailto:jdem...@cage.ugent.be>> wrote:
>
> On 2012-07-11 17:09, Jan Groenewald wrote:
> > The original question was whether PPA instructions should be given on
> > Sagemath.org
> I think we should first figure out the right workflow (for me this is
> still: build from source on Launchpad), then add instructions.
>
>
> Sure, not a problem. Rather close the ticket
> http://trac.sagemath.org/sage_trac/ticket/13228
> now as progressing will likely take a months or years:
> people have been trying various Debian related
> things since 2009.

I'm still not convinced that implementing "build Sage on Launchpad"
should take more than 10 minutes work, given what you have already done.
So we really should try to make that work.