Ok, cool.

Ah, just found http://wiki.inkscape.org/wiki/index.php/Roadmap

It looks like doing this work on Github and (maybe) getting Travis CI working would be useful work-ahead, and not just a side-distraction for tinkering on the Mac build. I’d rather it didn’t come down to people relying on me to create and release builds ;-)

Building on Atsuyoshi’s work, I think there’s one issue that is critical to fix before calling it a generally usable release: figuring out what to do about python and libxml support. Without it extensions probably won’t work.

(I’d also like to see uniconvertor added to, but that might be quite a bit more work.)

Julian

From: Martin Owens <doctormo@...400...> <doctormo@...400...> Reply: Martin Owens <doctormo@...400...> <doctormo@...400...> Date: February 1, 2017 at 1:00:04 PM To: Julian Rendell <juliangrendell@...400...> <juliangrendell@...400...>, inkscape-devel@lists.sourceforge.net inkscape-devel@lists.sourceforge.net inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.92 via homebew on macOS

On Wed, 2017-02-01 at 15:21 -0500, Julian Rendell wrote:

If the packaging is figured out, does the Inkscape team have the resources to create and publish a Mac binary that can be hosted the same as the Windows/Linux builds? (I’m not sure what the CI/build infrastructure is for Inkscape.)

Our publishing procedure is fairly simple.

1. Have a user account on inkscape.org 2. Modify your account with your name, picture and gpg key (a fake key is ok, it must exist for you to upload an md5) 3. Contact the website administrator to increase your quota from 10MB 4. Upload your DMG along with an md5 or gpg signature 5. Inform people on the inkscape mailing list to do any final testing of the download. Provide a link. The files will be automatically cached by our CDN. 6. Change the website's CMS pages with the new links and announce more widely.

Best Regards, Martin Owens Website Administrator

Tim, I agree. I suggested github because that’s what I’m familiar with, and that’s where Atsuyoshi’s notes are. I had a quick look at the Inkscape Wiki and didn’t see “request access to the source” instructions. Besides, I’d be worried I’d do something wrong and screw stuff up causing more work for the “real” developers ;-).

My thought was that if it were to be got working, send in a patch request. (Launchpad is a little daunting for the casual user!)

I’m looking for the least effort path to try and help and also see a Mac build available long term. I no longer do development regularly, but am willing to try and help out… but have some concerns I might drown in learning the tools/mess up/make work for others before providing anything helpful.

OTOH, the roadmap I found suggests a long-term migration to github and using travis is under consideration. I’m a relative newb with both, but have managed to hook up travis on a trivial project, er, trivially.

Doing this in github might be helpful???

I’ll come back in a couple of days and see where the consensus lies, and help out if I can.

Cheers,

Julian

I'd personally rather put effort into helping sort out the official packaging situation rather than work on a satellite macOS packaging effort.

Specifically, I'd rather resurrect the old packaging/macos tree that was removed ( http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15381) so that it can be worked on. It's a bit annoying that it was removed rather than just disabling it and letting it to lie fallow in case people want to work on it. I've got some patches for it that I put on hold when it went.

I wasn't subscribed to inkscape-devel at the time, so am not clear on the background/issues/discussion that led up to its removal. If Martin, ~suv or whoever else could give a summary or link to any discussion, I'd really appreciate it.

Cheers, Tim

Nice!

If no one has objections let's:

- set up a gitlab repo in the inkscape team (who do we ask to do that?) - set up a github project mirror, to see if it can be built in Travis. I can do that. Send me your github IDs (privately if you prefer) and I'll add you. Will do it sometime over the weekend.

Tim, can you make the patches public? I'd love to try them/get them checked in.

But I suspect there maybe a few more things we need to address to make it an equivalent release to the other platforms. I highlighted a couple in comments to Atsuyoshi-san's gist: python/libxml (needed for extensions to run), and a conversion library for Corel draw files (important for laser cutting and sign making).

Both might be solved/fixed by embedding a python executable in the app. Travis build agents have homebrew installed, so maybe we can use that to get a known version of python, add it to the build area, pip install the dependencies and then add it all to the package?

Just throwing ideas out, with no idea how realistic they are!

Julian

On February 3, 2017 at 4:08:41 PM, Tim Sheridan (tghs@...3462...) wrote:

Hi Julian/everyone,

I’ll come back in a couple of days and see where the consensus lies, and help out if I can.

Just a quick update in case anyone's been putting effort into an external attempt at packaging 0.92.x.

I've currently got the old packaging scripts that were used for the 0.91 release updated and producing release App/DMG builds for 0.92. I'm going to be preparing a test build from the 0.92.x branch for anyone interested in trying it out. I'll start a new thread for this when it's ready. :-)

Cheers, Tim

Am 04.02.2017 um 02:08 schrieb Julian Rendell:

Nice!

If no one has objections let's:

• set up a gitlab repo in the inkscape team (who do we ask to do that?)

- Anyone who has at least master permissions, see list here: https://gitlab.com/groups/inkscape/group_members

Maren

Thanks for the warm welcome Bryce, and clear answers.

Good that you assume nothing; I’m mostly a user!

(Disclosure: I am starting a makerspace/education business and want to promote Inkscape to patrons. It’s trivial for Linux/Windows… but I suspect supporting brew/Macports might chew a lot of time :-) )

Extra: could the builds be signed so that they don’t raise security warnings?

If you mean can they be gpg signed like the source tarballs, then yes of course.

If you're talking about something more Mac-specific by the word 'signing', such as something relating to app-store registration or whatnot, then you'll need to elaborate. I've got no experience with how things are done on Mac.

Yes, it’s an Mac security thing. Mac’s give a warning before running “unsigned” apps. I’m only vaguely aware of what has to be done to build a package that doesn’t trigger this warning- I think being a registered Mac developer is required. At this point the end user can “approve” the app locally and run it anyway. It’s a “nice to have." This only affects non-Mac store apps (I assume all Mac store apps are signed.)

You're probably already aware of this, but we have plans in motion to migrate the Inkscape codebase to gitlab. This might influence your plans here. I'm guessing this will occur in the March timeframe, but we already have an Inkscape team set up on it and are using it for inkscape_web work to try it out. Would you be interested perhaps in hosting your development team work there within the Inkscape team account?

Not at all aware of this.

If the other interested parties are ok with using gitlab then let’s get it setup.

Let’s give them a couple of days to respond.

Another bit of data I'll mention, that again you probably are aware of but that might influence your planning, is that our earlier evaluation indicated the OS X packaging would need redone for supporting Gtk3, and indeed it was felt that native OS X packaging for Gtk3 would be significantly easier. We have already landed the Gtk3 changes for Inkscape's trunk, which will be released as 0.93, so I believe if someone wanted to start experimental work on native OS X packaging on top of trunk, the pre-requisites should be in place to permit that. The timeframe for the 0.93 release is uncertain, as always, but my personal hope is to see it released before the end of the year.

Vaguely aware of it. I got cmake to work, twiddled flags, rebuilt, and eventually got a local binary that ran using GTK3 native. It was sort of awful- lots of tearing and things not redrawing; sometimes tools couldn’t be clicked on. Then someone updated the brew file and I went back to using that, which appears to be GTK2 based. But there’s a very good chance I messed something up installing GTK3 via brew.

Having said that, I’d be happy to work with the gtk3/head, if it’s to support the goal of supporting future work. I can setup a VM for development/testing.

Let me know if you’d be interested in this and I’ll set up a repo/try to participate in figuring out the patches.

Thanks for undertaking this, and please feel comfortable to use the inkscape-devel@ and #inkscape-devel channels for discussion on this.

Thanks, I’ll keep that in mind.

Cheers,

Julian

On Feb 1, 2017, at 5:34 PM, Bryce Harrington <bryce@...961...> wrote:

What's involved in becoming a registered Mac developer?

One development team member needs to have a Mac on the current OS version, and pay a $99/year fee for access to the developer program. After that, there are some minor hurdles to install the necessary set of developer certificates and to sign the packages and/or installers.

Once an application or package is signed, it essentially communicates to other Mac computers that it has been digitally signed by a known developer, and has not been tampered with since it was signed.

(I manage this process for my own tiny apps. I have also signed copies of Inkscape.)

Windell H. Oskay, Ph.D. Co-Founder and Chief Scientist Evil Mad Scientist Laboratories 175 San Lazaro Ave, STE 150 Sunnyvale CA 94086 http://www.evilmadscientist.com/

On Wed, Feb 01, 2017 at 06:40:45PM -0800, Julian Rendell wrote:

...

If the other interested parties are ok with using gitlab then let’s get

it

...

setup.

Let’s give them a couple of days to respond.

Ok, sounds good.

Does the gitlab outages affect this suggestion at all?

Our current gitlab endeavors are primarily aimed at information-gathering to support a decision in around a month about migrating the core Inkscape codebase there. So in that context the recent gitlab outage is certainly an important data point to take into consideration.

However, in the context of nearer term efforts such as inkscape_web and this mac os porting work, so long as the outage has been resolved (as it appears it's been), I wouldn't let that color the decision.

Is the project planning on using Gitlabs CI system? Skimming < https://about.gitlab.com/gitlab-ci/%3E it looks like you have to self-host the runners (build agents.) Ok, found this thread ( https://github.com/travis-ci/travis-ci/issues/5931) that gives some details. There are free, shared runners, but only for linux.

I like CI, it keeps me honest. But worst case, primary hosting on gitlabs, secondary on github, use Travis with the github mirror for Mac builds. Git makes multiple remotes pretty straight forward :-)

Yes, gaining good CI capabilities is definitely going to be part of our decision process. Experimentation towards achieving multi-platform CI in the gitlab ecosystem would thus help a lot towards making the right decision - even failed experiments here will provide good data.

The Travis OS X support page looks pretty good ( https://docs.travis-ci.com/user/osx-ci-environment/) - looks like they have the current OS release, and the previous two available, and brew available to install tools and dependencies.

Hosting on Gitlabs and using Github as a mirror/CI system could be a nice backup strategy.

Yep, I could easily see us ending up with a bit of a hybrid of the two.

It depends of course on how you want to invest your energies and how urgent your needs are. That said, from the projects' perspective having Gtk3 OS X packaging ready for 0.93 is the more strategically important since it will be the longer term need. And to my knowledge no one is working on it at present, so it's a clear area where help is needed.

I’d much rather work on something that helps this long term. Right now, the brew tap that was created solves my personal and immediate needs. I’ll look into means of supporting other local Mac users when that crops up. By then I might have enough knowledge to at least build everything into a single directory and provide a bash script + icon for them to use in the interim.

Cool, I'll try to keep tabs on how things go.

Bryce