Homebrew packages for OS X updated for 2.7.0

[Fred McCann]

> On Feb 19, 2016, at 12:38 PM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>>> 
> 
>> All of these have stable releases that appear to be working with bzr
>> 2.7.0. Landing them in homebrew is just a matter of getting some
>> approvals. bzr-rewrite has now been accepted.
> 
> I'm not sure what that means as I don't know what a homebrew package
> is. The most important missing bit for me is: can you add patches as
> part of the package (like in debian/ubuntu) ?
> 


Patching in homebrew is discouraged. It’s not impossible to get them in, but they prefer that things are working upstream. I can see what I can do on that front.


>>> 
>>>> bzr-stats
>>> 
>>> That one is not working ? Wow, that's quite a surprise. What's the issue ?
>>> 
> 
>> https://bugs.launchpad.net/bzr-stats/+bug/1545883 <https://bugs.launchpad.net/bzr-stats/+bug/1545883>
> 
> Dupe https://bugs.launchpad.net/bzr-stats/+bug/1040560 <https://bugs.launchpad.net/bzr-stats/+bug/1040560>
> 
> We need a new release or a new tarball.
> 
> Sorry for being a bit vague and talking about different solutions :-)
> 
> But the two main important bits are:
> 
> - can you add patches to a homebrew package (in which case you're in the
>  same boat as debian/ubuntu and don't need a new release),
> 
> - what branches/revisions are you using, even without doing a release,
>  every plugin/project can build tarballs named
>  bzr-xxx-1.2.3~bzrrevno234.tar.gz which may suit your needs


The homebrew folks definitely won’t accept tarballs generated at a certain revision as opposed to an actual release. They’re sticklers on this one. I can see what I can do about patching. That might fly.


> 
>>>> bzr-bisect
>>>> bzr-difftools
>>>> bzr-extmerge
>>> 
>>> Branches/revisions references ?
>>> 
> 
> Please ?
> 
> It's hard to know what kind of issues you're dealing with without
> knowing which code you're using :-}


The issue with these is that homebrew won’t accept tools that don’t have a stable versioned release. They’ll reject anything where I build from a specific revision.

> 
>> I just took over bzr-extmerge, merged some very long standing proposals, and
>> cut a release. It seems like this is still a core plugin
> 
> Just to be on the same page, we generally call core plugins the ones
> that are under bzrlib/plugins in the lp:bzr tree.
> 
>> (it’s referenced in the documentation:
>> http://doc.bazaar.canonical.com/latest/en/user-guide/resolving_conflicts.html <http://doc.bazaar.canonical.com/latest/en/user-guide/resolving_conflicts.html>),
>> 
>> but it also had never had a formal release.
> 
> https://launchpad.net/bzr-extmerge/trunk <https://launchpad.net/bzr-extmerge/trunk> says....
> 
> WOW !
> 
> Looks like someone did a release since :)
> 
> Congrats !


I took over bzr-extmerge and made a release. It’s been stranded for a while, that said, it pretty much does what it needs to and isn’t broken. It does seem like this is something that ought to be in bzr core.


>> While I was poking around, I also noticed that bzrtools latest release is not working with bzr 2.7.0:
> 
>> https://bugs.launchpad.net/bzrtools/+bug/1547121 <https://bugs.launchpad.net/bzrtools/+bug/1547121>
> 
> Damn it, it's fixed in debian and ubuntu by getting rid of the
> compatibility check that is causing issues at each release (but replaced
> by a different one in debian/ubuntu that is *also* causing issues ;)
> 
> long story short, I fixed it in debian/ubuntu without realizing you'll
> face it for homebrew.
> 
> That needs to be fixed upstream indeed.
> 
> <snip/>

I did try removing the version check, but I ran into a more serious bug. If you have it working on Debian, maybe it’s just an issue of grabbing latest trunk code?


> 
>> I admit, I’m new on the dev side of things, but I’m willing to
>> pitch in to make 2.7.0 + whatever plugins stable. On the topic of
>> plugins, it does seem like the list of plugins on the bzr wiki is
>> out of date:
> 
>> http://wiki.bazaar.canonical.com/BzrPlugins <http://wiki.bazaar.canonical.com/BzrPlugins>
> 
> It's a wiki so feel free to update it, especially with the work you're
> doing right now, you're the most knowledgeable.
> 

I’m more than happy to update the plugin list. Do I need an account to do that? I’m don’t see any edit options.


>> I’m still working through these, but it seems like quite a few are
>> abandoned and in some case have been rolled into bzr core. How can
>> we get that cleaned up?
> 
> I think the best is to make a clear cut about what works with bzr-2.7
> and what doesn't.
> 
> If enough people care and help we can then add more to the what works
> list by doing releases for the plugins whose trunk is owned by lp:~bzr
> (bzr-stats for example), it's harder if they aren't (bzrtools for
> example) in that case, reaching to the project owner and nicely asking
> for a release may be the way to go.
> 
>> It’s lousy advertising to list very old plugins that don’t work
>> anymore.
> 
> Agree.
> 
>> Also, is there any plan/way to suggest that we look into rolling
>> some fundamental plugins like xmloutput, bzrtools (or some portion
>> of it), bisect, extmerge, etc into the core bzr codebase?
> 
> There has been discussions about that, but it's up to the project owners
> to do so. I know that in some cases, copyright issues were raised and
> blocked the process.
> 
>> It seems like quite a few critical batteries are not included in
>> the box.
> 
> It's a hard balance to find between freedom to evolve in the plugins and
> the additional work to carry them inside the core bzr tree.
> 
>    Vincent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20160219/c56171d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20160219/c56171d2/attachment-0001.pgp>