Summary: | app-arch/rpm2targz-9.0.0.1g doesn't work for gzip compressed rpm files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dmitry Karasik <dkarasik> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexxy, cov, daemon, dschridde+gentoobugs, flameeyes, gentoo-bugzilla, help, jdaluz, lister.lists, mobiusstripper, plaes, rahul |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Dmitry Karasik
2008-08-20 13:53:35 UTC
Another example, this version causes build of dev-python-pyxf86config-0.3.34-r1 to fail during unpack. Downgrading to 9.0.0.0g eliminates this problem. *** Bug 235351 has been marked as a duplicate of this bug. *** *** Bug 235339 has been marked as a duplicate of this bug. *** Also, the condition in the 'for' loop is always true: for (i = 0; p[2] != 0 || p[2] != 0xff; ++i) { I'm not sure what the original intention was there! The original reported problem is easily fixed by using hex constants instead of character constants: if (p[0] == 0x1f && p[1] == 0x8b && p[2] == 0x08) { *** Bug 235514 has been marked as a duplicate of this bug. *** Breaks the emerge of openoffice-bin-2.4.1....had to downgrade to install openoffice. Reason for failure of installation of netscape-flash. Had to downgrade to install. Actually, my problem is with rpm2targz-9.0.0.0g. Does not work. *** Bug 235613 has been marked as a duplicate of this bug. *** Same problem here when trying to merge bjfilter (not a portage ebuild) Downgrading to 9.0.0.0g worked *** Bug 235777 has been marked as a duplicate of this bug. *** *** Bug 235854 has been marked as a duplicate of this bug. *** *** Bug 235909 has been marked as a duplicate of this bug. *** can we p.mask =app-arch/rpm2targz-9.0.0.1g ? Why can't you just fix it? It's a simple 1 line fix! i was trying to fix a warning, but guess that didnt go so well no idea what's with that for loop limit ... that was from the cleanup in Bug 219711 i just rewrote rpmoffset again to use stdio layers and be much faster It mostly works now however the move offset is wrong: memmove(p, p + read_cnt - MAGIC_SIZE - 1, MAGIC_SIZE - 1); should probably be moved before left is adjusted and changed to: memmove(p, p + left + read_cnt - MAGIC_SIZE - 1, MAGIC_SIZE - 1); Should I open a seperate bug for that? And of course I'm not perfect either :) It should be + 1, i.e.: memmove(p, p + left + read_cnt - MAGIC_SIZE + 1, MAGIC_SIZE - 1); (In reply to comment #17) > Should I open a seperate bug for that? If there is a new bug, open a new bug report, please. |