Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
On 04/22/13 13:03, Tobias Klausmann wrote:
Hi!
Since we probably will have to fix the files coming out of
tarballs until the various upstreams have fixed them, I propose
running a PNG fixer during or after the install phase. Since
having pngcrush as dep for everything is not exactly lightweight,
I hacked together a PNG file fixer in pure(ish, see below)
Python:
No please, this real should stay really far from any package manager.
There are only two sane options:
1) fix libpng to be backward compatible
2) fix the package, and re-package / add a package for broken images
But please don't push on all our user systems something like this.
http://git.schwarzvogel.de/?p=pngfixer;a=summary
Feel free to send patches
Note that all I wrote is the mind-numbingly simple pngfixer.py
script. The rest of the Python code is excised from PIL
(http://www.pythonware.com/products/pil/index.htm). I didn't have
to change anything there.
Also note that it is not _strictly_ pure Python I'm using: the
PIL components use Python's zlib.so and therefore are subject to
bugs in _that_ code.
Thanks for taking the time to write this it could be useful for
developers, but hopefully not as initially intended ;-)
Still needed:
- How do we ship this?
- How do we run it for every ebuild? (probably something like
find /var/tmp/portage/.../image/ -iname \*.png -exec {...}\;)
Regards,
Tobias
Regards,
Francesco
Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
Hi! On Tue, 23 Apr 2013, Ulrich Mueller wrote: I appericiate the work done by Tobias utmost too but I have to agree this is not something I want to see running automatically, or even from within ebuilds. +1 In Tobias's list, I count some 80 packages that need fixing. That's way too few to merit a general solution. Also this number will decrease when files are fixed upstream. I see two problems with this approach: - What do we do with unresponsive-yet-not-dead upstreams? - What about future packages that ship broken files? I mean not just existing packages that keep issuing broken PNGs but also future packages that we just didn't cover now? The former has two and a half solutions: - Wait until itmagically fixes itself or upstream comes around. This is only 1/2 a solution, IMO. - Add a separate tarball or the like that the Gentoo maintainer generates from the broken PNGs. Use this tarball to overwrite the broken results of equivalent_of(make install). - Have a convenience function that can be used for known-bad packages to fix broken IDATs. Basically calling my script or the binary Samuli mentioned. The second problem, however, is trickier. We can rely on people noticing the error messages/broken packages and hope they file bugs. The other option is to have a QA-like check for it, again using the simplest possible binary to do so. Regards, Tobias
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman ri...@gentoo.org wrote: On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers j...@gentoo.org wrote: Er, you can't be seriously suggesting we will drop repoman checks with the migration to git? I don't see how that would benefit anyone. Interesting point. One thing to keep in mind with git is that commits don't affect the central repository. Pushes are what impacts the repository. If I spend six months working on a bunch of coordinated package changes, nobody will see a thing until I push those commits and 500 ebuilds all change atomically (not that I'm suggesting that lack of communication is to be encouraged). A repoman check on a commit may not reflect its impact six months later when it actually hits the main tree. ... if you're squashing 6 months of work into a single commit before pushing. I don't think we want to do that, do we? Maybe bisecting isn't particularly interesting for the portage tree.
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Tue, 23 Apr 2013 21:31:10 +0200 Michał Górny mgo...@gentoo.org wrote: Just to make it clear -- there are four CVS commits. Ebuild commit followed by GPG-signed Manifest commit. Hopefully the developer has persistent SSH connections set up. AFAIK setting these up still isn't properly documented. I once read about it in a post somewhere by robbat2 and have been using this ever since, and I also recall suggesting using persistent SSH connections without finding a trace of evidence of their use in developer documentation. jer
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On 04/23/2013 01:27 PM, Tom Wijsman wrote: Maybe the question is rather why `repoman` takes 15 seconds on a quite fast system in a package folder that contains 2 ebuilds and 1 metadata. See the call graph for repoman at http://i.imgur.com/OQTUBdR.png. A third of the time, ~5 seconds, are spent on 60,000 - 70,000 calls to the function that is listed in the bottom; but the ebuilds barely list any dependencies. Why are there so much calls to this? There's lots of redundant repetition involved in repoman's iteration over the profiles listed in profiles.desc. It may be possible to optimize away the redundancy by taking advantage of all the things that each of the profiles have in common. -- Thanks, Zac
