Package xhpast (libphutil)
Closed, ResolvedPublic

Description

We need xhpast, libphutil and arcanist on nodepool instances to do proper arc lint tests.

Since xhpast is a native binary, it must be packaged.

I've set up basic debian packaging scripts using git-buildpackage in the debian branch of rPHDEP Phabricator Deployment

All that remains is getting the package built and uploaded to our apt repository.

mmodell created this task.Jun 14 2016, 5:46 AM
Restricted Application added a subscriber: Zppix. · View Herald TranscriptJun 14 2016, 5:46 AM
mmodell added a subscriber: fgiunchedi.EditedJun 14 2016, 5:48 AM

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:

2.1.0Upstream tag
151-g30a433bgit-describe part against the upstream version
wmf2The second iteration of /debian changes
precise1First iteration of /debian changes that are solely for Precise

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.
mmodell closed this task as Resolved.Jun 21 2016, 9:18 PM
hashar reopened this task as Open.Jun 30 2016, 10:27 AM

We would need the package to build for Trusty which we used for Zend 5.5 jobs. It is going to be provisioned via the puppet class contint::arcanist which does require_package('arcanist').

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: debian: clean source/binary artifacts

fgiunchedi closed this task as Resolved.Jul 4 2016, 2:05 PM

new version 0~git20160620-0wmf2 uploaded to trusty/jessie, tentatively resolving!

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

hashar added a comment.Jul 4 2016, 6:59 PM

Thanks, that seems to work fine now :-]

Qgil awarded a token.Jul 5 2016, 5:20 AM