This is the last thing blocking the completion of T130950.

The repo is tagged and ready to go: debian/0.0.2

@fgiunchedi is this something you can help with or is there someone else I should poke?

If nothing else I'll bring it up on scrum of scrums this wednesday.

@mmodell sure I can help with it! I see the debian directory is on the deployment repo, though generally it should be found with in the same repo as the source itself lives, in this case phabricator/phutil and phabricator/arcanist unless I'm missing something? finally, is this something that would make sense to have uploaded to Debian officially and/or you'd be interested in having uploaded?

@fgiunchedi:

Debian already has packages for phabricator, libphutil and arcanist but I need them to be maintained in sync with our release cycle, this is why I've created packages instead of using the official debian package versions.

The reason we can't just use official packages is xhpast version, arcanist client api version and phabricator server api version are all sensitive to mismatches and any one of them being very far out of sync will break some things.

The best way I know to keep everything in sync is to build the deb from the deployment repo which has the right submodule versions already.

This way when I tag a new version for deployment I can merge that into the debian branch, tag a revision for the debian packaging and have an opsen update the package files.

I _could_ move the packaging to the source repos but it would duplicate a lot of packaging config. I took a look at how the official debian packages are built and it looks like libphutil, arcanist and phabricator are all packaged together in a similar way:

One source package named 'phabricator' contains the following directories:

arcanist debian libphutil phabricator

We could probably get away with just building our packages from the official packaging scripts, however, the official packages are built from source cloned from github. I needed a way to get the right version cloned from our repositories and packaging in the deployment repo seems like a really good way to do that.

thanks for the context @mmodell !
Since we're using the same package names as Debian we should ensure that version numbers make sense, namely that our internal versions sort correctly. I'd go for something like 0~git<date>-0wmf1 so in case of the same date the -1 from debian sorts before -0.

Also is there anything in the official packaging we would do differently modulo different upstream versions?

I'm not picky about the versioning and right now I can't think of anything that would be different depending on upstream version.

@fgiunchedi can you handle tagging a version according to your 0~git<date>-0wmf1 scheme then? Or should I do that?

would the version literally be 0~git20160616-0wmf?

For Zuul package I am using 2.1.0-151-g30a433b-wmf2precise1 where:

Unfortunately phabricator doesn't have any upstream version tags.

@fgiunchedi I landed D269, I believe this is ready to package and upload. Can you take it from here?

@mmodell for sure, I'm assuming you'd need it available for jessie and trusty?

@fgiunchedi Yes although jessie is my main target right now, trusty will be next.

@mmodell libphutil and arcanist are now in jessie-wikimedia

I just noticed arcanist is missing a dependency on php5-curl:

$ arc help

PHP CONFIGURATION ERRORS

You need to install the cURL PHP extension, maybe with 'apt-get install php5-curl' or 'yum install php53-curl' or something similar.

@fgiunchedi: See D276

as it turns out, the debs work fine in trusty too, I've copied them to trusty-wikimedia:

root@carbon:/home/filippo# reprepro -C universe includedeb trusty-wikimedia arcanist_0~git20160620-0wmf1_all.deb
Exporting indices...
root@carbon:/home/filippo# reprepro -C universe includedeb trusty-wikimedia libphutil_0~git20160620-0wmf1_amd64.deb
Exporting indices...

$ apt-cache policy arcanist
arcanist:
  Installed: (none)
  Candidate: 0~git20160620-0wmf1
  Version table:
     0~git20160620-0wmf1 0
       1001 http://apt.wikimedia.org/wikimedia/ trusty-wikimedia/universe amd64 Packages

On integration-slave-trusty-1012:

Notice: /Stage[main]/Packages::Arcanist/Package[arcanist]/ensure: ensure changed 'purged' to 'present'

arc --help pass just fine :-}

Another potential issue is the binary xhpast fails due to a missing dependency:

$ xhpast 
xhpast: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by xhpast)

$ ldd `which xhpast`
/usr/bin/xhpast: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/bin/xhpast)
	linux-vdso.so.1 =>  (0x00007ffd430e0000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc231819000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc231513000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc2312fd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc230f38000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc231b1d000)
$

Same issue appear on a Jessie instance ( integration-slave-jessie-1001 ). Not sure how much of a concern it is though.

thanks @hashar ! I found some issues with xhpast, addressed in {D289}

Mentioned in SAL [2016-07-04T18:58:04Z] <hashar> Upgrading arcanist on permanent CI slaves since xhpast was broken T137770

Thanks, that seems to work fine now :-]