From: |
Dmitriy Romanov 2:6078/1 |
27 Sep 2022 23:34 +0300 |
To: |
Dima Krylov 2:5020/570.1 |
|
Subject: |
exec failed, code 256
|
Приветики, Dima!
Писал как-то Dima Krylov к Michael Dukelsky примерно 27 Сен 22 в 23:14
А я смотрю и фигею.
DK> [ ... ]
MD>> По идее 256 - это код ошибки, выданный командой unzip. Hо в man unzip
MD>> такого кода ошибки нет. Попробуй убрать qq из опций unzip и выполни
MD>> команду `unzip -j -Lo /ftn/spool/inbound/ee30fe00.tos -d
MD>> /ftn/spool/tempinb/` вручную, может быть unzip скажет, что ему не
MD>> нравится.
DK> Если ee30fe00.bad переименовать в ee30fe00.tu0 то уже никакой ругани нет
DK> даже с qq и все тоссится. :-(
Самое простое и тупое предположение - тоссер не может найти unzip, чтобы
запустить. Когда руками запускаешь - то все
нормально, он находится. Попробуй в конфиге прописать полный путь к нему. Так,
на всякий случай, чтобы отбросить хотя
бы это предположение. Я на такие грабли наступал, хоть и не с тоссером.
Hа сем разрешите письмо закончить. Elec (RA2FDR)
From: |
Dima Krylov 2:5020/570.1 |
27 Sep 2022 23:14 +0300 |
To: |
Michael Dukelsky 2:5020/1042 |
|
Subject: |
exec failed, code 256
|
оПХвЕР!
Kaк-тo нa дняx (27 сен 22) Michael Dukelsky пишeт к Dima Krylov...
[ ... ]
MD> По идее 256 - это код ошибки, выданный командой unzip. Hо в man unzip
MD> такого кода ошибки нет. Попробуй убрать qq из опций unzip и выполни
MD> команду `unzip -j -Lo /ftn/spool/inbound/ee30fe00.tos -d
MD> /ftn/spool/tempinb/` вручную, может быть unzip скажет, что ему не
MD> нравится.
Если ee30fe00.bad переименовать в ee30fe00.tu0 то уже никакой ругани нет даже с
qq и все тоссится. :-(
From: |
Michael Dukelsky 2:5020/1042 |
27 Sep 2022 22:37 +0300 |
To: |
Dima Krylov 2:5020/570.1 |
|
Subject: |
exec failed, code 256
|
Привет, Dima!
27 September 2022 20:49, Dima Krylov послал(а) письмо к All:
DK> Hачалось недавно и только с пакетами от одного линка. Hикто ничего не
DK> менял и мы не знаем, что это такое. (c)
DK> После тоссинга пакет переименовывается в битый. Лог от этого действия
DK> ниже. Руками .pkt от туда я могу достать совершенно без вопросов и оно
DK> дальше тоссится корректно.
DK> ---------- Tue 27 Sep 22, hpt/lnx 1.9.0-cur 17-02-17
DK> 1 18:00:02 Start
DK> 1 18:00:02 Start tossing...
DK> 7 18:00:02 bundle /ftn/spool/inbound/ee30fe00.tu0: renaming to .tos
DK> 6 18:00:02 bundle /ftn/spool/inbound/ee30fe00.tos: unpacking with
DK> "unzip -j -Loqq /ftn/spool/inbound/ee30fe00.tos -d
DK> /ftn/spool/tempinb/" A 18:00:02 exec failed, code 256 A 18:00:02
DK> Renaming pkt/arc to .bad
DK> Что такое code 256 и куда копать?
По идее 256 - это код ошибки, выданный командой unzip. Но в man unzip такого
кода ошибки нет. Попробуй убрать qq из опций unzip и выполни команду `unzip -j
-Lo /ftn/spool/inbound/ee30fe00.tos -d /ftn/spool/tempinb/` вручную, может быть
unzip скажет, что ему не нравится.
Желаю успехов, Dima!
За сим откланиваюсь, Michael.
... node (at) f1042 (dot) ru
From: |
Dima Krylov 2:5020/570.1 |
27 Sep 2022 20:49 +0300 |
To: |
All |
|
Subject: |
exec failed, code 256
|
оПХвЕР!
Hачалось недавно и только с пакетами от одного линка. Hикто ничего не менял и
мы не знаем, что это такое. (c)
После тоссинга пакет переименовывается в битый. Лог от этого действия ниже.
Руками .pkt от туда я могу достать совершенно без вопросов и оно дальше тоссится
корректно.
---------- Tue 27 Sep 22, hpt/lnx 1.9.0-cur 17-02-17
1 18:00:02 Start
1 18:00:02 Start tossing...
7 18:00:02 bundle /ftn/spool/inbound/ee30fe00.tu0: renaming to .tos
6 18:00:02 bundle /ftn/spool/inbound/ee30fe00.tos: unpacking with "unzip -j
-Loqq /ftn/spool/inbound/ee30fe00.tos -d /ftn/spool/tempinb/"
A 18:00:02 exec failed, code 256
A 18:00:02 Renaming pkt/arc to .bad
Что такое code 256 и куда копать?
From: |
husky inspector 2:5020/1042.3 |
23 Sep 2022 23:49 +0300 |
To: |
All |
|
Subject: |
Changes in husky sources
|
Legend: (A) Added, (C) Copied, (D) Deleted, (M) Modified, (R) Renamed,
(T) Type changed, (U) Unmerged, (X) Unknown, (B) Pairing Broken
===========================
huskybse:
add an option to build the sources without updating them
Author: Michael Dukelsky
Date: 2022-08-02 12:10:54 +0300
Committed by: Michael Dukelsky
Files:
M script/build.sh
===========================
huskybse:
fix the case when mock cannot be installed
Author: Michael Dukelsky
Date: 2022-07-30 22:44:32 +0300
Committed by: Michael Dukelsky
Files:
M script/init_rpm_build
From: |
husky inspector 2:5020/1042.3 |
01 Sep 2022 01:00 +0300 |
To: |
All |
|
Subject: |
Changes in husky sources
|
Legend: (A) Added, (C) Copied, (D) Deleted, (M) Modified, (R) Renamed,
(T) Type changed, (U) Unmerged, (X) Unknown, (B) Pairing Broken
===========================
huskybse:
add an option to build the sources without updating them
Author: Michael Dukelsky
Date: 2022-08-02 12:10:54 +0300
Committed by: Michael Dukelsky
Files:
M script/build.sh
===========================
huskybse:
fix the case when mock cannot be installed
Author: Michael Dukelsky
Date: 2022-07-30 22:44:32 +0300
Committed by: Michael Dukelsky
Files:
M script/init_rpm_build
From: |
Nil A 2:5015/46 |
27 Aug 2022 20:30 +0300 |
To: |
Oleg Bolshakov 2:5030/722.1368 |
|
Subject: |
Проблемы при сборке husky на *nix и их возможные решения
|
Hello, Oleg!
Saturday August 27 2022 16:02, from Oleg Bolshakov -> Semen Panevin:
OB> - *CR* (ASCII 0x0D) используется в 8-битовых машинах Commodore,
OB> машинах TRS-80, Apple II, системах Mac OS до версии 9 и OS-9;
А так же в сообщениях сети фидонет! Надо педовики подправить, чтобы знали
основы.
Best Regards, Nil
From: |
Oleg Bolshakov 2:5030/722.1368 |
27 Aug 2022 16:02 +0300 |
To: |
Semen Panevin 2:5025/121 |
|
Subject: |
Проблемы при сборке husky на *nix и их возможные решения
|
Пожимаю руку тебе, Semen!
27 авг 22 14:55, Semen Panevin -> Michael Dukelsky:
MD>> Вот если файлы, полученные в Windows, бездумно использовать в
MD>> Linux, то ничего хорошего не получится, это да. Поэтому, если уж
MD>> хатчить виндовые файлы в файлэху, то надо писать, что они
MD>> виндовые.
SP> С какой стороны они виндовые? CRLF не является показателем
SP> "виндовости" файла, это всего лишь один из вариантов концов строк в
SP> текстовых файлах, используемый в разных редакторах разных операционных
SP> систем (да, в windows возможно немного чаще, но это проблема
SP> используемых редакторов и их настроек, а не самой ОС как таковой).
Эх, придётся процитировать педовикию:
Системы, основанные на ASCII или совместимом наборе символов, используют или LF
(перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или
последовательность CR+LF (...)
- *LF* (ASCII 0x0A) используется в Multics, *UNIX*, UNIX-подобных операционных
системах (*GNU/Linux*, AIX, Xenix, Mac OS X, FreeBSD и др.), BeOS, Amiga UNIX,
RISC OS и других;
- *CR* (ASCII 0x0D) используется в 8-битовых машинах Commodore, машинах
TRS-80, Apple II, системах Mac OS до версии 9 и OS-9;
- *CR+LF* (ASCII 0x0D 0x0A) используется в DEC RT-11 и большинстве других
ранних не-UNIX- и не-IBM-систем, а также в CP/M, MP/M (англ.), MS-DOS, OS/2,
*Microsoft Windows*, Symbian OS, протоколах Интернет.
Руку отпускаю, пока, ob
... Мёртвые ходят не спеша ...
From: |
Semen Panevin 2:5025/121 |
27 Aug 2022 14:55 +0300 |
To: |
Michael Dukelsky 2:5020/1042 |
|
Subject: |
Проблемы при сборке husky на *nix и их возможные решения
|
Доброго здоровьица тебе, Michael!
Saturday August 20 2022 22:40, Michael Dukelsky писал Alex Shuman:
MD> Решение не является ни сомнительным, ни вредным. В Юниксах, если не
MD> менять настройки по умолчанию, git выдаёт файлы с LF без CR, как и
MD> ожидалось. В Windows, если не менять настройки git по умолчанию, git
MD> for Windows выдаёт файлы с CR/LF, как и ожидалось.
Ожидалось кем? Кто решил, что настройки по умолчанию - самые лучшие и
правильные?
Лично я ожидаю, что гит хранит то, что я в него заливаю, ровно в том виде, в
котором я его туда заливаю, и отдаёт в том же виде. Вне зависимости от
операционной системы. Всё, что делает неявную модификацию файлов - это и есть не
ожидаемое, а костыльное поведение, по моему мнению.
Если есть какое-то конкретное приложение (не важно под какой ОС), которое
почему-то хочет концы строк или что-то там ещё в каком-то определённом формате -
можно перекодировать файлы под это конкретное приложение, опять же, не
обязательно с помощью гита, но можно и с его помощью...
MD> Вот если файлы, полученные в Windows, бездумно использовать в Linux,
MD> то ничего хорошего не получится, это да. Поэтому, если уж хатчить
MD> виндовые файлы в файлэху, то надо писать, что они виндовые.
С какой стороны они виндовые? CRLF не является показателем "виндовости" файла,
это всего лишь один из вариантов концов строк в текстовых файлах, используемый в
разных редакторах разных операционных систем (да, в windows возможно немного
чаще, но это проблема используемых редакторов и их настроек, а не самой ОС как
таковой).
С наилучшими пожеланиями, Семён.
... От правды далеко не убежишь (с) Sage
From: |
Nil A 2:5015/46 |
26 Aug 2022 23:44 +0300 |
To: |
Alexey Vissarionov 2:5020/545 |
|
Subject: |
Проблемы при сборке husky на *nix и их возможные решения
|
Hello, Alexey!
Friday August 26 2022 23:26, from Alexey Vissarionov -> Nil A:
RS>>> Я не знаю что такое formdos и todos. И даже предположить не могу
RS>>> где такое может быть.
NA>> Щас две копеечки подкачю, а чё сразу man sed, тут это оверкилл,
NA>> тут в тему man tr ;-)
AV> Ну и где же там аналог sed'овского параметра -i ?
Пайпы наше всё, программирование в функциональном стиле.
Про sed, а не хватит его синтаксиса, будет sed+awk, так сразу надо perl и фсё
уж там.
Best Regards, Nil