search

rmarquis / pacaur

[unmaintained] An AUR helper that minimizes user interaction
https://bbs.archlinux.org/viewtopic.php?pid=1755144#p1755144
ISC License
796 stars 113 forks source link

String is interpreted as malformed octal number #649

Closed nbars closed 7 years ago

nbars commented 7 years ago
Version

pacaur 4.7.2

Description

String is interpreted as malformed octal number

Output
[jenkins@7319028d53c0 /]$ pacaur -S seafile-client --noedit --noconfirm
:: Package seafile-client not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...
/usr/bin/pacaur: line 885: sumk + 0388812: value too great for base (error token is "0388812")
rmarquis commented 7 years ago

This is the same issue as #505, which was closed as I never got the asked information. So, here are my questions:

The error happens when adding repo packages size, to display the total download or install size on the main prompt. It seems very small values keep the initial '0', and as such '08..' and '09..' are computed as octal values. Which of course are non existing numbers in base 8.

I don't know why this happens on your system. Do you see any value that start with 0 with the following command: expac -S '%k\t\t%n' | sort -r? If yes, what is the name of the corresponding package?

nbars commented 7 years ago

There is no entry starting with 0. However the only entry that is partially matching the number in the error message is:

10388812        qt5-webkit
rmarquis commented 7 years ago

Thank you! I cannot reproduce on my end, but this is indeed very useful information.

nbars commented 7 years ago

I'am running pacaur on a docker instance. Don't know what there could be different from a real system that is causing this issue. This problem just appeared some weeks ago.

rmarquis commented 7 years ago

Maybe this is an issue in expac?

I'm not familiar with docker, but would it be possible to check the output of that command on a docker instance?

expac -S -1 '%k' qt5-webkit

In any case, it seems the first digit is truncated on long number. The issue is harmless when the first non-truncated digit isn't 0, although the computed total download/install size would be wrong.

nbars commented 7 years ago

The output of the comment is just fine. I dumped some variables while pacaur -S seafile-client is proccessed.

The command that is execute in line 878 is the following:

expac -S -1 '%k' alsa-lib cairo cdparanoia compositeproto damageproto ffmpeg fixesproto flac fontconfig freetype2 fribidi fuse-common fuse2 gdk-pixbuf2 giflib graphite gsm gst-plugins-base gst-plugins-base-libs gstreamer gtk-update-icon-cache harfbuzz hdf5 inputproto intltool jack jasper lame libaio libass libasyncns libavc1394 libbluray libdatrie libdrm libevdev libevent libgudev libiec61883 libinput libmariadbclient libmodplug libogg libomxil-bellagio libpciaccess libproxy libpulse libraw1394 libsamplerate libsndfile libsoxr libsrtp libssh libthai libtheora libtxc_dxtn libunwind libva libvdpau libvisual libvorbis libvpx libwacom libwebp libx264 libxcomposite libxcursor libxdamage libxfixes libxft libxi libxkbcommon libxkbcommon-x11 libxrandr libxrender libxshmfence libxslt libxss libxtst libxv libxxf86vm libzdb llvm-libs mesa mesa-libgl minizip mtdev netcdf opencore-amr openjpeg2 opus orc pango pciutils perl-xml-parser pixman postgresql-libs protobuf pygobject2-devel python2 python2-gobject2 python2-simplejson qt5-base qt5-declarative qt5-location qt5-sensors qt5-tools qt5-webchannel qt5-webengine qt5-webkit qt5-xmlpatterns randrproto recordproto renderproto schroedinger scrnsaverproto sdl2 snappy speex speexdsp tslib v4l-utils vala vid.stab videoproto wayland x265 xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm xf86vidmodeproto xkeyboard-config xvidcore zita-alsa-pcmi zita-resampler

This is the return value:

465160
736432
66468
7984
6044
8360232
11096
409608
821032
2684468
66804
6584
108132
663896
65004
233552
35004
191000
1733368
1896096
14512
362536
1717324
79764
41492
361464
293660
258028
4528
90500
16272
30032
816796
26964
229376
53796
225200
36992
30860
493312
4548548
156348
189324
119564
19508
92756
366236
46400
981004
263688
97292
85884
193216
153012
280932
10192
100152
443904
55200
124728
297152
1150964
60140
280708
378652
10392
27040
5896
13104
45248
148604
243932
18868
25704
24816
4532
367908
12820
28836
35596
14528
56044
11690728
8431712
4568
28960
15348
484004
129444
815196
351100
208520
438928
83972
145408
236788
1111708
1373000
13736
11335500
284060
88336
11320584
3445780
755508
159568
5975600
60172
29959800
10388812 <<< qt5-webkit
1202888
28740
14956
16168
339604
10832
586000
58724
488172
457600
65584
685600
1659628
49716
13928
229956
1429064
10572
16316
6924
8368
31228
4256
652880
209508
17840
113940

So, there is no zero as prefix in any of these numbers.

And these are the values of the variables inside the for loop until the error occurs:

sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 0
sumk: 0
binaryksize[i]: 41492
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 0
sumk: 41492
binaryksize[i]: 4548548
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 0
sumk: 4590040
binaryksize[i]: 75508
sumk: 4665548
binaryksize[i]: 159568
sumk: 4825116
binaryksize[i]: 5975600
sumk: 10800716
binaryksize[i]: 60172
sumk: 10860888
binaryksize[i]: 29959800
sumk: 40820688
binaryksize[i]: 0388812
/usr/bin/pacaur: line 885: sumk + 0388812: value too great for base (error token is "0388812")
nbars commented 7 years ago

Replacing the "substring replace call" at line 884 with a "suffix match substring replace" call seems to fix the problem:

[[ $builtpkg ]] && binaryksize=(${binaryksize[@]/%${binaryksize[$i]}/0})

I think this fix will also guarantee that there will be at least no leading zero if a substring replacement occurs accidentally.

rmarquis commented 7 years ago

@nbars I replaced that part with a more straightforward code (77514a7a9bcac9e77df7eeeec69325f79f2a9110). Let me know if that works for you and I will make a new release.

nbars commented 7 years ago

Well, that is obviously a more straightforward fix. I tested it and it works just great, thanks!