[LinuxBrit]
  • del.icio.us links
  • Random Photo
    • IMG_1488
    Recent Photos
    • IMG_1469
    • IMG_1468
    • IMG_1467
  • Meta:
  • Categories:
  • Archives:

31/8/2004

feh work

23:22 in Software

By popular demand, I’m currently working on adding lossless jpeg rotation to feh - also ensuring all EXIF metadata is preserved. This basically involves working around imlib2, which isn’t interested in preserving EXIF or avoiding recompression. I’ve ended up invoking libjpeg directly but it’s working so far. feh CVS has the changes if anyone wants to test them. Btw CVS for feh has moved to linuxbrit:

  1. export CVSROOT=\
  2. :pserver:anonymous@linuxbrit.co.uk:/var/lib/cvs
  3. cvs co feh

15 Responses to “feh work”

  1. anti's blog » feh Says:

    […] x/” title=”View all posts in Linux”> Tom started playing around with feh again. [LinuxBrit] - Blog - feh work I hope he will apply the

  2. Roeland Says:

    Is it possible that this is the wrong CVS dir?
    (/cvs: no such repository)

  3. giblet Says:

    You’re quite right (my bad). Try /var/lib/cvs for now..

  4. richlowe Says:

    Errr… Assuming linuxbrit.co.uk is the host I think it is, /cvs has existed for ever and ever…

    How did you manage that? :)

  5. giblet Says:

    I know - /cvs exists on the server, but CVS pserver hates it - I tested it myself and it does indeed say no such repository.. CVS over ssh seems to work fine with it though, so I didn’t immediately notice.

  6. richlowe Says:

    That explains a lot, I’ve never touched pserver.
    pserver is evil, pserver should never be used, ever.

    Maybe it doesn’t like it being a link, or (more likely), maybe nobody told pserver that /cvs is valid…

    I’d much rather something like anoncvssh was used though.

    (the thingy that acts a shell for a nonpriviledged account and does nothing other than allow anonymous CVS checkouts over ssh, I think the name is anoncvssh anyway, something like that :))

  7. giblet Says:

    Yeah - I feel the same, only I don’t feel like bothering to set it up as I’m in the process of switching to subversion :D

  8. pabs Says:

    /var/lib/cvs is for anon, /cvs is for spiffy ssh users like myself. And you forgot to tell them about the ViewCVS interface you.

  9. giblet Says:

    Oh yeah, actually I’m told viewcvs supports subversion too, so maybe we can set that up now :)

  10. pabs Says:

    Yup. The article on your link bar mentioned something about ViewCVS support. Wel, the comments did anyway

  11. richlowe Says:

    I still have an intense hatred of subversion related to spending upwards of a solid 24 hour block fixing a repo after it moved between machines of diferent endiannesseses.

    From what I read the FSFS stuff fixes that, at the expense of using more space, and not being as reliable.

    What a fun choice.

    Why oh why can’t they finish OpenCM already :(
    That looked nifty, then they rewrote it, then it looked nifty again, then they rewrote it.

    Wait, I’ve seen this pattern before…

  12. richlowe Says:

    Ooooooh, I just realized if feh CVS is there now I can commit again!

    Not sure what I’d commit, but still, it’s theoretically possible!

    Maybe I’ll spend my time enhancing pheh back to the level of feh… it’s a cooler app anyway ;-)

  13. giblet Says:

    Hrm, according to the docs there’s an svnadmin dump command which spits out the repository in a neutral format - I gather you’re supposed to use that if you’re going to move between endiannesses.. Sounds like you had a standard Berkeley DB portability problem to me, rather than anything specific to subversion..

  14. richlowe Says:

    You are entirely correct on all counts, I was going for brevity :)

    The machine that the subversion server was on died.
    That machine was MSB, I had to move to an LSB machine.

    but to run the dump, I needed an MSB host, no other way around it.

    Thus I spent 24 hours trying to remember who I knew with an MSB machine, getting an account on there, and waiting (a considerable amount of time) for subversion, apr, neon, and berkelydb to run on it. rsyncing my entire repo to the host, running the dump, and rsyncing the data back.

    My point is that I tend to think that using an endian agnostic format for the repo would have been a damn good idea, and know first hand just how much of a pain in the ass it can be in disaster recovery if you have to move between ends for reasons beyond your control :)

  15. giblet Says:

    Hehe, okay I’m with you there. There was one comment I almost added to my post - which was “I’d be a lot happier if the repo wasn’t stored in a berkeley DB, or maybe just the metadata..”. But then I figured I was being fussy, and I know how much cool stuff like transactions and atomicity you get for free with DB, so I left it out.

    That kind of recovery would definitely be a bitch though. I think my backup policy for subversion is going to be twofold. A hot backup (cp -a on the tree) and an endian-agnostic database dump :)