pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: The "no-break-space" problem, aka "blank" posts, that sh


From: Duncan
Subject: [Pan-users] Re: The "no-break-space" problem, aka "blank" posts, that shouldn't be
Date: Sat, 26 Dec 2009 08:13:11 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

K. Haley posted on Fri, 25 Dec 2009 00:21:25 -0700 as excerpted:

> On 12/3/2009 11:44 PM, K. Haley wrote:
>> the issue was the line wrap code assuming that all spaces were only one
>> utf-8 char wide.  The non-breaking space is two 0xc2a0.  The new code
>> should not only fix that but support the non-breaking part as well.
>>
>>
> I've just updated this to support spaces that might be encoded to more
> than two bytes.  The update is on the testing branch.  You might need to
> use git fetch --all
> to get the branch the first time.  At least it's supposed to update all
> remote branches.

My problem was that I run a (self-created) Gentoo ebuild script to fetch, 
build, binpkg (I have FEATURES=binpkg set), then install the binpkg, and 
while I knew git well enough to pull and checkout a branch manually, I 
didn't know how to tell Gentoo's git.eclass (which the ebuild uses) how 
to do that.

So I figured that out today, updated the ebuild with a new 
USE=testingbranch flag to build from it instead of master (as I had 
originally updated it with a USE=khaley flag to pull from you instead of 
gnome's git... and had updated it from the old svn.eclass using ebuild to 
the current git.eclass using ebuild, using Jack Cuyler's hints, as posted 
here... the live-svn ebuild in portage was originally mine, too), and 
tried it...

And it didn't work!  There was some weirdness in the eclass.  Setting 
just the branch variable told it what to pull, but when it checked it out 
locally, it still tried to use master.  GRRR!!!

So I spent quite some time figuring out what the eclass was doing, and 
finally figured out that it had a commit variable as well.  If commit 
wasn't set to the same as branch, it assumed it was a tag or commit ID 
and defaulted the checkout to master.  So it was pulling branch and 
checking out (local) master!  GRRR!!!

Then I tried setting the commit var too, but something else went wrong.  
I'm not sure what.  But it wasn't taking.  It was still trying to 
checkout master.

But I **FINALLY** got it all working, got the new live package built, and 
tested against the original test-case post I posted here originally.

VIOLA!  FIXED! =:^)

Now I just need to post my new ebuild to the bug where I posted the 
original git-update.  It seems they've not put it in the Gentoo tree yet, 
so the in-tree one is still the old svn one I submitted years ago...  Now 
I can update the one on the bug, to allow building from the testing repo 
as well. =:^)

BTW, do you know if the gnome repo has a testing branch?  Is it named 
testing?  If not, I need some logic in the ebuild to ignore the 
testingbranch USE flag (with a warning to that effect) if USE=khaley 
isn't set, which means it's pulling from the main gnome repo.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]