usbmux.1.0 - via opam-publish

[fxfactorial]

Control port remapping for iOS devices

Talk to jailbroken iDevices over USB with the CLI, gandalf.

Basically this lets you do:

ssh -p <some_port> root@localhost

for an iPhone/iPod/iDevice.

Example usage:

sudo which gandalf --mappings etc/mapping --daemonize --verbose

See uptime, tunnels and other metadata with:

gandalf --status

Check out the man page or see the README at:
https://github.com/onlinemediagroup/ocaml-usbmux/blob/master/README.org

---

• Homepage: https://github.com/onlinemediagroup/ocaml-usbmux
• Source repo: https://github.com/onlinemediagroup/ocaml-usbmux.git
• Bug tracker: https://github.com/onlinemediagroup/ocaml-usbmux/issues

---

Pull-request generated by opam-publish v0.3.1

[camelus]

✅ All lint checks passed 5e94fe8

• These packages passed lint tests: usbmux.1.0

---

✅ Installability check (4451 → 4452)

• new installable packages (1): usbmux.1.0

[dsheets]

Is there something wrong with putting files/_oasis_remove_.ml and files/usbmux.install in your package?

[fxfactorial]

No, I just don't understand 100% what is desired and have deadlines, especially as the current way seemingly works. I understand you want me to do it and I will, just when I have time to spend on new optimizations.

[dsheets]

What is desired: stop shipping parts of your package to everyone who uses opam.

What you can do: put those files in your package repository and include them in tarballs like any other source file.

Nice side effects: your package is now usable with opam pin.

[fxfactorial]

You're saying it as if I do it maliciously.

I use oasis2opam and use whatever is given, are you saying to stop using that tool and instead do this by hand? Do you have an alternative to oasis2opam ? I'm using the tools that the OCaml community says to use and now I get burned for using those tools. I can skip opam altogether and just use a private repo instead if this is a hassle for maintainers and those upsetting about losing 5kb of space on their disk.

And I have been using opam pin just fine, not sure what you're referring to about it.

As a cynic I understand that maintainers now want to put opam in the best light in front of their new benefactors, that said I don't get why people who used this just fine before are getting grilled now. If there's some kind of failing then its with the process and toolchain, not this PR.

[dsheets]

opam remove is broken with opam pin when the files are distributed here but not with the package. This affects the use of dev-repo and this extra executable cruft should not be necessary in a world where opam tracks installed files (Coming Soon (TM)).

I've filed ocaml/oasis2opam#24 to report the misuse of opam files/ feature. I didn't realize that oasis2opam does this. I don't use oasis and I recommend to most people I talk to about OCaml build systems to stop using oasis due to a number of limitations and headaches.

[fxfactorial]

I see, thank you, ugh, then I have to fix this in multiple packages.

So instead of oasis you're presumably just using ocamlbuild directly in a makefile?

[dbuenzli]

@fxfactorial oasis2opam makes a few number of unfortunate decisions, I don't know who in the OCaml community tells you to use that, but I personally wouldn't. If you are looking for an alternative you can look at topkg. But don't use it right know, I'll do a revamp of it in the following weeks, so that it's used as a library (avoids having the script in your repo) and provides tools for streamlining your release process.

[fxfactorial]

@dbuenzli and then I'll use yours and then someone else will tell me "I don't know who told you to use topkg but you should use foo...." I'm back where I started years ago, Makefiles.

[dsheets]

I think oasis2opam should tell you to add the .install file to your repo at least.

I prefer ocamlbuild and make but there are a lot of metadata files to maintain then. It's far, far from ideal but it also doesn't get in your way and cause surprising and pointless errors (setup.data out-of-date). The state of OCaml build is sad and there are a number of attempts to improve it but nothing clearly "good" right now. Hopefully, we can get some improvements in oasis2opam at least and perhaps oasis itself to reduce the need for this kind of cruft in the repository.

[dbuenzli]

So instead of oasis you're presumably just using ocamlbuild directly in a makefile?

Don't do this. There's now more and more people doing it that way but they don't handle correctly a number of situations (e.g. bytecode only switches, lack of dynlink, windows, etc.). If you don't want to move away from oasis, stick with it, it handles these cases correctly.

@dbuenzli and then I'll use yours and then someone else will tell me "I don't know who told you to use topkg but you should use foo...."

Don't listen to people, look at what is provided and choose on technical grounds --- w.r.t. I personally think that oasis + oasis2opam is a poor choice. I designed topkg because oasis didn't allow me to scale with the number of packages I distribute.

[Chris00]

On Thu, 4 Feb 2016 12:15:51 -0800, Daniel Bünzli wrote:

@fxfactorial oasis2opam makes a few number of unfortunate decisions

When criticizing the work of someone else, you may at least want to be specific about what you are not happy with.

[samoht]

I'm really looking forward the day where we have a build system that I'd recommend to newcomers. Until then, I'm fine with accepting the quirks of existing solutions, and keep opam a neutral place. It'd be indeed quite nice to not put too many unnecessary files in opam-repository: but I think it's more an upstream problem than a user problem, so merging this PR anyway.

[dbuenzli]

When criticizing the work of someone else, you may at least want to be specific about what you are not happy with.

Well I don't really have the time to list everything that I'm not happy with in this combo. But for one thing oasis has an install procedure that works perfectly and I don't see why oasis2opam has to fiddle with .install files. If .install file had to be supported in oasis worfklows this should be added to oasis itself not bolted on top or on the side of it. There's also the case of dubious build dependencies generated by oasis2opam I mentioned in another PR. Anyways, in general I find all these layers of indirections, oasis2opam only addding one more, quite distasteful and generating a lot of crap in repositories (very tired of looking at PRs of oasis auto generated noise) and prevents people from learning how their concrete build system (usually ocamlbuild) and package system works.

[Chris00]

On Sun, 7 Feb 2016 09:37:46 -0800, Daniel Bünzli wrote:

Well I don't really have the time to list everything that I'm not happy with in this combo. But for one thing oasis has an install procedure that works perfectly and I don't see why oasis2opam has to fiddle with .install files.

This is because oasis needs some setup files in order to uninstall the binaries which must therefore be preserved.

If .install file had to be supported in oasis worfklows this should be added to oasis itself not bolted on top or on the side of it.

I agree about that. It is just a matter of delivering a solution in the short time I can spend on this — an oasis plugin would of course be a better solution!

There's also the case of dubious build dependencies generated by oasis2opam I mentioned in another PR.

oasis2opam has to guess some dependencies because not of the impedance mismatch between the ocamlfind view of them and the opam one. Case in point: not every package advertises the ocamlfind libraries it provides... (Can't comment more since I do not remember the particular case you "point".)

Anyways, in general I find all these layers of indirections, oasis2opam only addding one more, [...]

oasis2opam is a practical solution (as opposed to a principled one) to the fact that oasis users already declare their dependencies in _oasis and should not be forced to do it twice — which of course would quickly lead to discrepancies between the _oasis and opam.