Hi Thorsten,
在 2024/6/19 上午6:23, Thorsten Alteholz 写道:
Hi Dandan,
On Mon, 17 Jun 2024, zhangdandan wrote:
I hope you don't mind if I already make use of the Loongson team. Do
you have any idea why package cups does occasionally fail to build
on loong64?
(-> https://buildd.debian.org/status/logs.php?pkg=cups&arch=loong64)
Thanks for your reply and help.
There is no additional need for architectural support for cups.
Currently, the cups package has been built and installed.
Please view
http://ftp.ports.debian.org/debian-ports/pool-loong64/main/c/cups/.
Sometimes fail to build in Debian Package Auto-Building ENV due to
source package version upgrades, but are quickly fixed by the cups
maintainers.
when you look at the link I provided:
https://buildd.debian.org/status/logs.php?pkg=cups&arch=loong64
you can see that building cups failed several times. It even failed
twice for version 2.4.7-1.2+b1 and once for 2.4.7-3. Those failures
have nothing to do with source package version upgrades and please be
assured that the maintainer didn't fix anything but just gave back the
package to the buildd. Such unreliable builds might be fine with the
ports architectures, but not really acceptable for release
architectures (I am not part of the release team, so I hope nobody
disagrees with this statement).
This issue looks like a typical task for the porters of an
architecture, so I have a favour to ask you. Could the Loongson team
please have a look at it and maybe provide a patch to make the build
more reliable?
Thorsten
Thanks for your care and reminder.
An analysis of why building cups occasionally fail several times in the
Debian Package Auto-Building environment.
Two types of phenomena exist, as follows,
1. Compiling 2.4.7-1.1 (experimental) and 2.4.7-1.2 (sid) failed once each.
From the error log, we can see that the header file "asm/errno.h" is
missing, and the error message is as follows:
```
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file
or directory
1 | #include <asm/errno.h>
```
The full log can be found at
https://buildd.debian.org/status/fetch.php?pkg=cups&arch=loong64&ver=2.4.7-1.2&stamp=1709193457&raw=0.
The reason for both failures is the same, that the
linux-libc-dev_6.6.9-1 all package has incomplete loong64 support.
After we manually built the unreleased version of linux-libc-dev all
6.6.15-2+loong64, the cups build with linux-libc-dev all
6.6.15-2+loong64 no longer reports missing header file errors.
The root cause is that Debian linux did not merge the loong64 patch in
the build rules before version 6.7.9-1 (sid), and we needed to manually
upload the unreleased version of the linux-libc-dev header file to the
pool-loong64 repository.
In January and February Debian linux versions were updated very quickly,
and the linux-libc-dev_6.6.9-1 package that the cups build relied on
happened not to be the one we manually uploaded.
But thanks to the help of linux maintainers, the patch for loong64 [1]
was merged by Debian linux.
Based on linux unstable, loong64 was built natively since 6.7.9-1 (sid)
[2] in the Debian Auto-Building.
[1]:https://salsa.debian.org/kernel-team/linux/-/merge_requests/879
[2]:https://buildd.debian.org/status/fetch.php?pkg=linux&arch=loong64&ver=6.7.9-1&stamp=1710019550&raw=0
With the support for loong64 in Debian linux, compiling cups no longer
reports missing header file errors.
2. Compiling cups failed twice for version 2.4.7-1.2+b1 and once for
2.4.7-3.
For loong64, the compilation failures are consistent with the problem of
occasional test case failures, specifically the occurrence of 1 test
case failure.
For amd64, the same error was reported before, link below:
https://buildd.debian.org/status/fetch.php?pkg=cups&arch=amd64&ver=2.4.1op1-1&stamp=1645484739&raw=0.
Intercepting the error log for 1 test case failure is:
```
FAIL: 4 warning messages, expected 14.
W [16/Jun/2024:00:41:15.064175 +0000] No JobPrivateAccess defined in
policy default - using defaults.
W [16/Jun/2024:00:41:15.064183 +0000] No JobPrivateValues defined in
policy default - using defaults.
W [16/Jun/2024:00:41:15.064189 +0000] No SubscriptionPrivateAccess
defined in policy default - using defaults.
W [16/Jun/2024:00:41:15.064194 +0000] No SubscriptionPrivateValues
defined in policy default - using defaults.
grep: /tmp/cups.b28ApG/log/error_log: binary file matches
......
```
From the code of the test case in test/run-stp-tests.sh file:
if the number of "^W" searched by grep is not equal to 14, it will
report "FAIL: $count warning messages, expected 14." and then
"fail=`expr $fail + 1`".
```
# Warning log messages
count=`$GREP '^W ' $BASE/log/error_log | $GREP -v CreateProfile | $GREP
-v 'libusb error' | $GREP -v ColorManager | $GREP -v 'Avahi client
failed' | wc -l | awk '{print $1}'`
if test $count != 14; then
echo "FAIL: $count warning messages, expected 14."
$GREP '^W ' $BASE/log/error_log
echo " <p>FAIL: $count warning messages, expected 14.</p>"
>>$strfile
echo " <pre>" >>$strfile
$GREP '^W ' $BASE/log/error_log | sed -e '1,$s/&/&/g' -e
'1,$s/</</g' >>$strfile
echo " </pre>" >>$strfile
fail=`expr $fail + 1`
else
echo "PASS: $count warning messages."
echo " <p>PASS: $count warning messages.</p>" >>$strfile
fi
```
The result is that the error_log file itself is an ASCII text, and when
the error_log contains binary data, if the "^W" number is not equal to
14 it will add 1 to the number of "FAIL". The fact is that the number of
"^W" keywords in the corresponding error_log is 14(Opening error_log
with the vim command and searching from the beginning of the line for
the "W" keyword is 14).
```
loongson@localhost:~/cups$ grep "^W " -rni /tmp/cups.o9Kbv9/log/error_log
2:W [19/Jun/2024:05:10:28.024792 +0000] No JobPrivateAccess defined in
policy default - using defaults.
3:W [19/Jun/2024:05:10:28.024800 +0000] No JobPrivateValues defined in
policy default - using defaults.
4:W [19/Jun/2024:05:10:28.024806 +0000] No SubscriptionPrivateAccess
defined in policy default - using defaults.
5:W [19/Jun/2024:05:10:28.024812 +0000] No SubscriptionPrivateValues
defined in policy default - using defaults.
grep: /tmp/cups.o9Kbv9/log/error_log: binary file matches
```
My suggested solution for occasional test case failures:
The compiled cups and the compiled logs are fine, maybe we should change
the method that counts the "^W".
We can add "--binary-file=text" parameter or "-a" parameter to grep
($GREP) to ensure compilation stability.
Please refer to my local test case:
```
// Note: The error_log for failing to compile cups is
/tmp/cups.o9Kbv9/log/error_log.
loongson@localhost:~/cups$ file /tmp/cups.o9Kbv9/log/error_log
/tmp/cups.o9Kbv9/log/error_log: ASCII text
loongson@localhost:~/cups$ grep "^W " -rni
/tmp/cups.o9Kbv9/log/error_log |wc -l
grep: /tmp/cups.o9Kbv9/log/error_log: binary file matches
4
loongson@localhost:~/cups$ grep --binary-file=text "^W " -rni
/tmp/cups.o9Kbv9/log/error_log |wc -l
14
loongson@localhost:~/cups$ grep -a "^W " -rni
/tmp/cups.o9Kbv9/log/error_log |wc -l
14
```
Additional info:
1. Run "CUPS Automated Test Script" as a normal user.
2. I've compiled locally many times and only had 1 test case failure
issue on the first compilation.
3. Two commands are included in the judgment used by the $GREP parameter
in /tmp/cups.o9Kbv9/log/error_log.
/usr/xpg4/bin/grep and grep (Various architectures are using "grep").
The above is my initial analysis of the two types of error messages when
compiling cups.
For other suggestions about loong64, we can continue to communicate on IRC.
Thanks
Dandan Zhang
