On Saturday 24 October 2015 10:47:11 Jérémy Lal wrote: > In less than five minutes i was able to workaround the FTBFS and have > a gitg 3.18 debian package built.
It is nice that you see the obvious way to fix it. Maybe you could share your workaround? Unfortunately solution to FTBFS is not that obvious to me. Or maybe I would have more time to fix the issue if I wouldn't be involved to endless arguments about uploading immature Gitg to unstable... :( > Isn't your role as a maintainer to fix the FTBFS issue ? It is an upstream issue. Anyway even with little time on my hands I do my best supporting new Gitg in "experimental" for over the year despite that I consider it unusable as well as packaging and maintaining its dependency library... > If you're not considering fixing it yourself, than you might better hand > over the maintainer role to someone else. Considering. :( > Please test gitg in a clean environment, or on another machine. > Maybe you have something else slowing down gitg. Maybe you need to > git gc the repository you use. Maybe you have a bazillion repositories > and you don't open gitg from one of them ? Tried that. You are not listening. It is not "git gc" thing because effect is consistent and reproducible over multiple runs on the same repository. Once again, I do not consider poor speed a blocker. > As someone already told you, i also think your position is a bit > "chicken-and-egg" How is broken multi-file diff in new Gitg is "chicken-and-egg"? > problem. Anyway, uploading to experimental is fine for me. Thanks. > Hopefully you'll test it > some more until you're convinced gitg 3.18 is a great piece of software ! It's been already a year since I've been testing every new release of Gitg only to feel sad about what it became. It was indeed a great piece of software and maybe hopefully one day it will be OK again... -- Best wishes, Dmitry Smirnov.
signature.asc
Description: This is a digitally signed message part.
