Closed #259.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/259#event-1175541987___
Rpm-maint mailing list
Looks like mjw found commits which are already in upstream and fixing issue...
f0a58d1dced6215b7caaa70db17d54834e0cd44e +
3c74e34e8d8c5b3db024dbe04a352e807ed2b627
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hmmm ... endianness *does* become an issue when a int64 is somehow returned
through an int32: LE will Just Work (for small offers) and BE will fail through
truncation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Either set _romiodebug = -1, or (even better) fish out the change to set the
FD_t specific debugging flag in cvtfmode() if Fopen(path, "r?.fpio") is the
invocation. There's really no other way to set FD_t specific debugging because
FD_t is totally opaque in rpmio/rpmio.c
--
You are receiving
Hmmm ... its a reasonable guess that failures on BE platforms might be related
to endianness, but damfino how endianness becomes an issue on an octet oriented
I/O API thru python bindings. I's suggest looking closely at the return codes
from *seek/*tell which have never been well supported in
this test passes on all other architectures, so I suppose this is
endianess-related bug. ppc64 and s390x are BE while all others are LE.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
```python
299. rpmpython.at:35: testing basic rpmio ...
./rpmpython.at:35:
cat << EOF > test.py
import rpm, sys
dbpath=rpm.expandMacro('%_dbpath')
rpm.addMacro('_dbpath', '${abs_builddir}/testing%s' % dbpath)
def myprint(msg = ''):
sys.stdout.write('%s\n' % msg)
msg = 'Killroy was here\n'
data
