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