Hi All,
I'm back from my trip. I've made a couple of changes to the PPAs and things will hopefully be back to normal pretty soon. I have a couple of queries too...
Note that Launchpad seems to be having some headaches with recipe builds at the minute. See https://bugs.launchpad.net/launchpad/+bug/884516
== Changes == * Dropped unneeded version specifier for libwp* dependencies in lp:~inkscape.dev/inkscape/debian-packaging
* Enabled builds of the inkscape-trunk-daily recipe for Ubuntu Precise and Maverick.
* Bumped epoch of package version naming scheme to allow natty builds after the earlier incorrectly-named version
== Queries == * At the moment, the "stable" recipe is actually building the head of the lp:inkscape/0.48.x branch. Do we actually want to do this, or should we build inkscape 0.48.2?
* Is there much point having a daily build of the stable package? Surely we only need to rebuild it when a new stable version is released?
* Have we decided which Ubuntu versions we support? I think it's safe to drop Ubuntu Hardy now - Canonical no longer support it for desktop installations. I'll have to do some tweaking with the packaging code to build for Lucid, but it shouldn't be too difficult.
* Thinking about it, do we really need two separate PPAs? As far as I understand it, we can get multiple recipes to build in a single PPA. We can just create separate source packages ("inkscape-stable" and "inkscape-trunk") and use them to build similarly-named binaries in the same PPA. Should be easier for users that way. We can specify the binary packages as conflicting, to prevent any dependency hell.
* I don't know much about libwpd/libwpg. Do we actually need both dev packages available at build time?
Cheers,
AV
Regarding names
On Tue, 2011-11-01 at 00:14 +0000, Alex Valavanis wrote:
- Thinking about it, do we really need two separate PPAs? As far as I
understand it, we can get multiple recipes to build in a single PPA. We can just create separate source packages ("inkscape-stable" and "inkscape-trunk") and use them to build similarly-named binaries in the same PPA. Should be easier for users that way. We can specify the binary packages as conflicting, to prevent any dependency hell.
Shouldn't the stable package be called 'inkscape' unless the package is older than the inkscape shipped with Ubuntu.
My rationale here is that the Ubuntu Software Center uses a cached set of desktop files to provide meta data as well as a website to provide screenshots and a service for ratings and reviews.
If we split up the stable stream so we're not replacing the Ubuntu shipped version, then all that data will only point to Ubuntu's inkscape and not to upstream inkscape. Thus giving us a bad appearance in the software center and splitting the reviews between the Ubuntu official and upstream sources. (this may be what you want to do though, matter of policy).
I don't think the provides would cure any of these issues, but perhaps this is a non-issue.
Regards, Martin
On Mon, Oct 31, 2011 at 5:49 PM, Martin Owens <doctormo@...400...> wrote:
Shouldn't the stable package be called 'inkscape' unless the package is older than the inkscape shipped with Ubuntu.
This makes sense to me.
Since we're on this topic, would you be interested in the da stash plugin to be added to our PPA as well?
Cheers, Josh
On Mon, 2011-10-31 at 18:05 -0700, Josh Andler wrote:
Since we're on this topic, would you be interested in the da stash plugin to be added to our PPA as well?
That's a good idea, I don't have any skills on making a recipe for building so it's kind-of stuck with the manual packaging I have at the moment.
I also need to check to make sure it still works, deviantArt changed their domain to http://sta.sh (and I never got that website to work) so let me check on it's functionality so I know it works.
Martin,
I'm working on the packaging branch at the minute. I have updated to the new debhelper script format, which makes the package a lot easier to maintain. I'm not exactly sure how we would implement the packaging so that both the stable and trunk packages can be installed at once, but it's probably doable. I guess we'd need to rename the trunk source package, and ensure that the binaries are installed as "inkscape-trunk", "inkview-trunk" etc. Once we're happy that no conflicts exist with stable inkscape, we can drop the "Conflicts: inkscape" relationship in debian/control. I can look into packaging the da stash plugin when the main trunk package is ready.
Also, Inkscape trunk needs cairo >= 1.10, which isn't available in Ubuntu Lucid. Do we (a) provide our own updated Cairo package for Lucid (which may well break many other packages in Lucid!!) or (b) Just say that we only support Maverick and above.
Thanks,
Alex
On 1 November 2011 04:43, Martin Owens <doctormo@...400...> wrote:
On Mon, 2011-10-31 at 18:05 -0700, Josh Andler wrote:
Since we're on this topic, would you be interested in the da stash plugin to be added to our PPA as well?
That's a good idea, I don't have any skills on making a recipe for building so it's kind-of stuck with the manual packaging I have at the moment.
I also need to check to make sure it still works, deviantArt changed their domain to http://sta.sh (and I never got that website to work) so let me check on it's functionality so I know it works.
Martin,
Updated.
On Mon, 2011-10-31 at 18:05 -0700, Josh Andler wrote:
Since we're on this topic, would you be interested in the da stash plugin to be added to our PPA as well?
OK so this is our situation. The plugin still works well and works in Oneiric, Lucid, Natty and Maverick. it still contains the gtk/webkit inclusion that nails inkscape the first time you use it* and I had an email from one of the inkscape demi-gods about how to fix that but I can't find it now (any help? something to do with creating a separate process for the gtk/webkit oauth work.).
The packages require two dependencies not met in the default repositories. python-oauth2 >= 6.0 this module was horribly broken because oauth2 is still being developed as a standard so it needed updating for version 10 of the standard. Unfortunatly I couldn't upstream the changes so it's a bit of a problem.
The other is python-poster >= 0.8.1, the version included in Oneiric is 0.6, I can't remember exactly why I needed to update the python-poster package but I wouldn't have built it if it wasn't required. At any case this one is the upstream version.
Martin,
* Inkscape (oneiric) glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: Open failed
On Mon, Oct 31, 2011 at 5:14 PM, Alex Valavanis <valavanisalex@...400...> wrote:
== Queries ==
- At the moment, the "stable" recipe is actually building the head of
the lp:inkscape/0.48.x branch. Do we actually want to do this, or should we build inkscape 0.48.2?
0.48.2 is what we want.
- Is there much point having a daily build of the stable package?
Surely we only need to rebuild it when a new stable version is released?
It's a waste of resources. You are correct in only building once there is a new stable version. The only exception to this would be if we also build for Precise, since the libs are going to change often.
- Have we decided which Ubuntu versions we support? I think it's safe
to drop Ubuntu Hardy now - Canonical no longer support it for desktop installations. I'll have to do some tweaking with the packaging code to build for Lucid, but it shouldn't be too difficult.
Sounds good by me.
- Thinking about it, do we really need two separate PPAs? As far as I
understand it, we can get multiple recipes to build in a single PPA. We can just create separate source packages ("inkscape-stable" and "inkscape-trunk") and use them to build similarly-named binaries in the same PPA. Should be easier for users that way. We can specify the binary packages as conflicting, to prevent any dependency hell.
I'm fine with it as long as the users can have both copies installed at once. In fact, if we're going to go this route, can we add Tavmjong's Mesh branch as well (and provide the needed versions of cairo and pixman)? If we do, the cairo and pixman versions provided by the Xorg Edgers PPA works with his branch.
Cheers, Josh
participants (3)
-
Alex Valavanis -
Josh Andler -
Martin Owens