Mangled output in Copr logs

[voxik]

Observing Copr logs, there is corrupted output, presumably due to some encoding issues. Looking e.g. at libsbml build, the output contains:

/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp: In function ‘void* zipopen(const char*, const char*, int)’:
/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp:545:41: error: cannot convert ‘long unsigned int*’ to ‘uint32_t*’ {aka ‘unsigned int*’}
  545 |     filetime(filenameinzip,&zi.tmz_date,&zi.dosDate);
      |                                         ^~~~~~~~~~~
      |                                         |
      |                                         long unsigned int*
/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp:97:64: note:   initializing argument 3 of ‘long unsigned int filetime(const char*, tm_zip*, uint32_t*)’
   97 | unsigned long filetime(const char* f, tm_zip* tmzip, uint32_t* dt);
      |                                                      ~~~~~~~~~~^~

Please note the ’ sequences. Comparing with Koji, where the output is fine:

/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp: In function ‘void* zipopen(const char*, const char*, int)’:
/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp:545:41: error: cannot convert ‘long unsigned int*’ to ‘uint32_t*’ {aka ‘unsigned int*’}
  545 |     filetime(filenameinzip,&zi.tmz_date,&zi.dosDate);
      |                                         ^~~~~~~~~~~
      |                                         |
      |                                         long unsigned int*
/builddir/build/BUILD/libsbml-5.20.2/src/sbml/compress/zipfstream.cpp:97:64: note:   initializing argument 3 of ‘long unsigned int filetime(const char*, tm_zip*, uint32_t*)’
   97 | unsigned long filetime(const char* f, tm_zip* tmzip, uint32_t* dt);
      |                                                      ~~~~~~~~~~^~

I know that with RPM 4.19 the default encoding changed from C to C.UTF-8. Can it be the reason for the issue?

P.S. sorry if the links to the logs disappeared by the time you are looking at the ticket.

[voxik]

My guess is that gcc is using typographic quotes with C.UTF-8, while using straight quotes for C encoding. And Copr handles the logs as C encoded.

[FrostyX]

Thank you for the report @voxik,
I am uploading the log here so it doesn't get lost after Christmas - 06771727-builder-live.log.gz

[pgnd]

'll often use a 'lazy' debug tool in .spec work, namely dropping a tree ./ into %prep, %build, etc., to see/poke in builder-live.log.gz

when I do, the display fonts -- only in the tree cmd output used at COPR online -- are munged.
e.g., in a .spec

%prep
...
cd %{_builddir}
tree ./
...

in builder live log,

+ tree ./
	./
	├── milter-regex-milter-regex-80adf5d
	│   ├── ChangeLog
	│   ├── Makefile
	│   ├── Makefile.linux
	│   ├── Makefile.solaris
	│   ├── README.md
	│   ├── eval.c
	│   ├── eval.h
	│   ├── geoip.c
	│   ├── milter-regex-ip-prep.c
	│   ├── milter-regex.8
	│   ├── milter-regex.c
	│   ├── milter-regex.init
	│   ├── parse.y
	│   ├── rules
	│   ├── strlcat.c
	│   └── strlcpy.c
	└── milter-regex-milter-regex-80adf5d-SPECPARTS

when i build locally, no such issue -- fonts display as normal.
fwiw, i've never noticed (yet) any font mangling other than with tree

here locally,

mock --version
  5.3

mock -r fedora-39-x86_64 --shell
...
Start: shell
<mock-chroot> sh-5.2# tree ./
./
└── build
    ├── BUILD
    ├── BUILDROOT
    ├── RPMS
    ├── SOURCES
    ├── SPECS
    ├── SRPMS
    └── originals

9 directories, 0 files

[pgnd]

similarly, e.g. @ %build

...
Downloading pip-23.3.2-py3-none-any.whl (2.1 MB)
   ���������������������������������������� 2.1/2.1 MB 21.6 MB/s eta 0:00:00
Downloading wheel-0.42.0-py3-none-any.whl (65 kB)
   ���������������������������������������� 65.4/65.4 kB 66.6 MB/s eta 0:00:00
...

attaching
builder-live.log.gz

[penguinpee]

This issue appears t apply to any text file served by Copr. I noticed strange characters during package review. However, when downloading the file in question and viewing it locally (vim) it looked fine.

Here's a spec file that displays the first three words as We can’t run, whereas locally it displays correctly as We can’t run.

[praiskup]

This doesn't seem to be caused by CDN because even the source file is mangled.