Если за 30 лет cmucl так и не научился бутстрапиться, то... туда ему и дорога.

Для Ъ, что с ним не так? Вероятно компилятор древний слишком. И можно подумать, что в других дистрибутивах все пакеты собраны идеально. Как раз дебиан часто радует качеством сборки.

Иди в мэнтейнеры.

хотела написать то же самое

Иди в мэнтейнеры.

А что для этого надо? Достаточно уметь делать ./configure && make && sudo checkinstall -D ?

Дело не в том, как софт собирается, а в том, что релиз тим про процесс сборки думает. Думают дебиановцы, как видно, плохо: кроме как на Си и ему подобных программы больше, по их мнению, ни на чём не пишут; «ненужные» функции из openssl выкидывают...

Нет ты.

> Иди в мэнтейнеры.

Я осуждаю инвалидов интеллектуального труда, вернее, их добровольной инвалидности, а ты предлагаешь мне к ним присоединиться?

http://www.debian.org/devel/join/newmaint

http://wiki.debian.org/Maintainers#AdvocatingaDebianMaintainer

https://nm.debian.org/

> хотела написать то же самое

Я давно и прочно на Федоре, которая, в отличие от Дебиана, движется в правильном направлении.

Ну толсто же :-(

> Моё предложение: дебиановских релизинженеров и мантейнеров повязать, осудить без права обжалования приговора и расстрелять.

Лучше вставь два карандашика в нос, и убейся головой апстол.

This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

hand-patched

hand-patched

hand-patched

Передайте этому узколобому быдлу, чтобы прочитал man patch

> Передайте этому узколобому быдлу, чтобы прочитал man patch

Ты прочитал, но не понял, о чём идёт речь. Что ж, похвально... Хотя бы читать умеешь.

Моё предложение: дебиановских релизинженеров и мантейнеров повязать, осудить без права обжалования приговора и расстрелять.

Это надо cделать с абсолютно всеми дистрибутивостроителями. Не существует дистрибутивов без серьёзных и глобальных косяков.

Например, ты когда-нить задумывался как сделать чтобы фаервольные правила в дебиане между ребутами выживали? Вот как предлагается делать: http://www.debian-administration.org/articles/445

Или угрёбищнейшая система конфигов exim. Три дня оттуда барахло выносил.

На багрепорт вместе с патчем никто с августа мне не отвечает, хотя тикет принят и assigned на мэйнтейнера.

Итд итп.

Я давно и прочно на Федоре, которая, в отличие от Дебиана, движется в правильном направлении.

И что это за направление?

давно пора было этот хлам выкинуть из дебиана, там вообще много чего давным-давно устаревшего и ненужного в репозитории лежит

> Ты прочитал, но не понял, о чём идёт речь.

А пацанчик так и не привел веских доводов. Обсуждение закончилось тем, что он промямлил невнятное «non-trivial». Выходит, своими кривыми ручками у себя на машине он что-то вхачивает. А написать скрипт, чтобы бутстрапнуться точно так же в несколько стадий - не в состоянии? Не говно ли?

А зачем тебе отвечать, если assigned? ЧСВ мешает?

Моё предложение: дебиановских релизинженеров и мантейнеров повязать, осудить без права обжалования приговора и расстрелять.

Боюсь, что если бы вместо них, мэнтейнерами дебиана были такие как ты, то он бы уже давно был бы RIP или, что еще хуже скатился в сраное гавно стал бы федорой.

А вообще толсто.

> Например, ты когда-нить задумывался как сделать чтобы фаервольные правила в дебиане между ребутами выживали?

http://www.debian-administration.org/articles/445

И чем тебя не устраивает этот вариант?

И чем тебя не устраивает этот вариант?

Тем что такой функционал должен быть в любом дистре. А так приходится свои велосипеды городить. Хотя исправляется вопрос двумя строчками. Зато у exim конфигов понаписали... Зайди в /etc/exim/conf.d :). Или права на рута 755 это верх кретинизма.

Винить сообщество в том что оно не делает того что нужно другим, конечно, неправильно. Но и оставлять ситуацию как есть тоже плохо. Только вот сами мейнтейнеры зачастую и сами вопросы не решают и другим не дают. С одной стороны берегут систему от бардака, а с другой уровень дистрибутива годами остаётся на низком уровне.

Я в раздумьях.

Надо или принять патч или объяснить почему этого делать нельзя. Это прямая обязанность мейнтейнера. Если мейнтейнер не может то его надо менять.

> Я давно и прочно на Федоре

Тогда почему тебя так волнует Дебильян?

P.S. это еще один знак того, что Лисп не нужен.

> А пацанчик так и не привел веских доводов. Обсуждение закончилось тем, что он промямлил невнятное «non-trivial».

Он писал для понимающих (да, в том числе и для меня). Непонимающие, типа тебя и дебиановских релизинженеров, не понимают. Если тебе интересно, то CMUCL и его подобные собираются в две стадии. На первой стадии из новых исходников бутстрапом собирается минимальный образ нового компилятора, которым потом (вторая стадия) собирается финальный продукт. В CMUCL автоматизации первой стадии нет.

Выходит, своими кривыми ручками у себя на машине он что-то вхачивает. А написать скрипт, чтобы бутстрапнуться точно так же в несколько стадий - не в состоянии? Не говно ли?

Написали 10 лет назад, называется SBCL. Тем не менее, в CMUCL до сих пор есть приятные плюшки, которых нет в его знаменитом форке. Например, green threads.

> В CMUCL автоматизации первой стадии нет.

Что мешает ее сделать? Импотенция?

> Тогда почему тебя так волнует Дебильян?

Люблю погнобить.

P.S. это еще один знак того, что Лисп не нужен.

После долгого и прочно сидения на Дебиане, я как-то в один момент понял, что Дебиан не нужен. Случилось это тогда, когда SIP-телефония начала входить в быт русского человека, но в Дебиане приходилось собирать ядро от RHEL, чтобы оная телефония не икала.

На самом деле, по работе столкнулся с Федорой (даже не RHEL), и с ней в production жизни оказалось меньше проблем.

Сходил по ссылке. Если этот древний кусок фекалий извращенской системой сборки до сих пор не переписали нормально, значит оно нахрен никому не нужно и должно мирно сдохнуть.
Старым извращенцам никто не мешает организовать свой собственный репозитарий и заниматься там ректальной сборкой пакетов. Или собирать на своей машине.

> В CMUCL автоматизации первой стадии нет.

Без автоматизации результат невоспроизводим. А это - однозначное говно и блоб. Пусть переносит свой блоб в non-free, там ему и место.

>на Федоре, которая, в отличие от Дебиана, движется в правильном направлении.

дооо. Федоровские мейнтейнеры настоящие Ъ. Если им лень разбираться с багрепортами, то они просто ждут очередного релиза и с чистой совестью закрывают все баги бета-версий.

>Дебиан ... скатывание в гогно...

Ура, ура, ура!

Как только, так сразу. Если тебя что-то не устраивает — пиши жалобные письма мейнтейнеру, в рассылку, но только не на ЛОР. Тут тебе ничто не поможет.

>> Тогда почему тебя так волнует Дебильян?

Люблю погнобить.

А вот тебя таки расстрелять.

> В CMUCL автоматизации первой стадии нет.

А что, за 30 лет не судьба было написать? Тридцать, целых, лять, тридцать лет ручками вхачивать вместо автоматизировать и на рыбалку лишний раз сходить! Или женщин покадрить. Это ж сколько поколений хардкорных любителей садомазо этим занимаются. Тридцать гребанных лет.

Срать на ЛОРе интереснее, видимо :}

Одного того, что этот компилятор не поддерживает 64-битную адресацию памяти уже достаточно, чтобы отправить его на пенсию.

So in the end the 'everybody uses C' camp won and cmucl on Debian will die a quiet death. It's a sad end for a system hand-patched from PDP10's to modern CPU's over the coarse of almost 30 years...

Сюжет для научно-фантастического триллера: Машина времени ЛОРа переносит из 1980 года в наше время юникс-админа. А тут ему такой спойлер: «Sendmail dies. CMUCL dies. BSD dies. Unix dies». У парня инсульт, остановка сердца.

Толстый гвоздь в крышку гроба CMUCL:

оно работает только на x86.
Нет, оно работает на PPC, но только под Darwin.
Ну, оно, конечно, еще на SPARC работает, но только под Solaris.
Еще оно с оговорками работает под FreeBSD на amd64.

Плюс еще танцы с бубнами вокруг версий ОС и версий CMUCL, которые возможно, ТЕОРЕТИЧЕСКИ, смогут работать на них!

Скажите, а оно нафиг нужно, если половина добрая техники, на которой хотелось бы гонять common lisp, на ARM?

Есть CLISP, переносимый на все, что движется.

Его перенесут в другой репозиторий? Бида...

Вот тебя заело. Подумай с какой целью я про это написал и кому отвечал.

С какой целью? Ты тролль. // К.О.

Был бы не тролль, не устраивал бы на ЛОРе своё ЖЖ.

Ъ мэнтейнеры.

>дооо. Федоровские мейнтейнеры настоящие Ъ. Если им лень разбираться с багрепортами, то они просто ждут очередного релиза и с чистой совестью закрывают все баги бета-версий.

А ви таки считаете, что исправление багов не связанных со сборкой задача мэнтейнеров? Может они и за добавление нового функционала отвечать должны?

напиши более хороший дистрибутив.

>Моё предложение: дебиановских релизинженеров и мантейнеров повязать, осудить без права обжалования приговора и расстрелять.

Дело не в том, как софт собирается, а в том, что релиз тим про процесс сборки думает. Думают дебиановцы, как видно, плохо: кроме как на Си и ему подобных программы больше, по их мнению, ни на чём не пишут; «ненужные» функции из openssl выкидывают...

А я согласен с shimon. Если для сборки нужна ручная правка, то это просто ад. И чего это CMUCL не может собраться сначала предыдущей версией? А FTPMasters — они пока просто решили закрыть аплоад бинарных пакетов, а только исходники.

Насколько я понимаю новую идею, пакеты в Debian должны теперь уметь собираться полностью автоматически без вмешательтсва сопровождающего и закидывания подправленных бинарей, необходимых для автоматической сборки? Не умеют — учитесь, типа.

>исправление багов не связанных со сборкой задача мэнтейнеров?

ви таки считаете, что пользователь сам должен выяснять причину возникновения бага? В нормальных дистрибутивах мейнтейнеры переправляют багрепорт в апстрим, если их собственные кривые руки не виноваты.

>Насколько я понимаю новую идею, пакеты в Debian должны теперь уметь собираться полностью автоматически без вмешательтсва сопровождающего и закидывания подправленных бинарей, необходимых для автоматической сборки
Очень здравая идея, кстати. Давно пора.
А то, что так собирать нельзя - давно пора на помойку.

> Есть CLISP, переносимый на все, что движется.

CLISP легко и непринуждённо падает везде, где libsigsegv криво работает. CMUCL память любит, а на типичном ARM-девайсе доступно 32-64 мб памяти.

> if you upload a package it will automatically be recompiled from source by using the packages already in the system.

For cmucl which needs cmucl to recompile itself it means that we can only use the previous version of cmucl in the archive, not the one we are just uploading. This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

То есть компилятор предыдущей версии гарантировано неспособен собрать компилятор текущей без вмешательства человека? Хреновый компилятор :)

Патчить надо бинарник? Что мешает сделать скрипт для сборки, который будет его патчить и запускать патченый бинарник?

> Думают дебиановцы, как видно, плохо: кроме как на Си и ему подобных программы больше, по их мнению, ни на чём не пишут;

Просто выбрасывают пакеты не поддающиеся автоматической сборке.

> Я осуждаю инвалидов интеллектуального труда, вернее, их добровольной инвалидности, а ты предлагаешь мне к ним присоединиться?

Ломай систему изнутри.

> На багрепорт вместе с патчем никто с августа мне не отвечает, хотя тикет принят и assigned на мэйнтейнера.

Связывайся с ним по электронной почте, джабберу или его любимому IM. Или обратись через его голову к следующему в иерархии. Или поспрашивай в IRC или джаббер-конференции дистрибутива. Или обратись в апстрим.

Вода не течет только под лежачий камень.

>The only requirement so far was that the package could be rebuild from source. This CMUCL can so: it can recompile itself given that we are talking about the same version. Going from one version to another is ... non-trivial.

Сопровождающий полностью не отрицает возможности собрать CMUCL, говорит о том, что это не так просто. Я ни разу не собирал CMUCL, поэтому специфики совершенно не знаю. Быть может, как-то сборочные скрипты и правила поменять, чтобы заработало? Но мне по тону сообщения показалось, что он как-то активно так закапывает CMUCL в Debian. Может, ему с ним возиться надоело? Он состоит в Debian Common Lisp Team и является также одним из сопровождающих CLISP и SBCL (из того, что я видел).