Wine Wizard 2.0.0

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

--2016-07-07 13:40:02-- https://raw.githubusercontent.com/LLIAKAJL/WineWizard-Utils/master/update.linux
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.36.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.36.133|:443... failed: Connection refused.

На самом деле там 404. На гитхабе лимиты есть по трафику или что-то пошло не так?

Странно, проверил только что - все работает. А просто по ссылке заходит?

Для других дистрибутивов такие же строчки в Help добавить, и все. Как думаете?

Отличная идея. Я за. И да. Спасибо за новость.

Может у тебя прокси? Вот вроде как описано: http://www.thegeekstuff.com/2010/07/wget-connection-refused-error/

А причём здесь сайт проекта, если новость не о нём, а о самом проекте (т. е. о какой-то гуйне к вину, что явно десктоп-приложение)?

сейчас зашло, но было 404

прокси нет

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

Не знаю тогда, может сбой какой-то был. Не слышал про траффик на GitHub.

А вот на это как смотришь: Wine Wizard 2.0.0 (комментарий)

Тогда мейнтейнерам один раз достаточно будет все сделать, и этот скрипт больше обновлять не нужно будет(ну, если новых зависимостей не появится, но это и не планируется).

какая-то фигня у гитхаба

$ curl -v https://raw.githubusercontent.com/LLIAKAJL/WineWizard-Utils/master/update.linux
*   Trying 151.101.36.133...
* connect to 151.101.36.133 port 443 failed: Operation timed out
* Failed to connect to raw.githubusercontent.com port 443: Operation timed out
* Closing connection 0
curl: (7) Failed to connect to raw.githubusercontent.com port 443: Operation timed out
$ ping 151.101.36.133
PING 151.101.36.133 (151.101.36.133): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 151.101.36.133 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Не плохо наверное. Но из за qt5 не буду пока ставить (kde4 в gentoo, уж больно муторно будет зависимости рулить).

По поводу установщика: Всё таки было бы неплохо сделать универсальный .tar.gz. Из него запаковать универсальные .deb и .rpm, с указанием зависимостей (вроде бы не сложно было). А также попросить знакомых гентушника и арчевода написать ебилд и что там для арча надо. Слаководы сами соберут из выложенных сорцев. 99% дистрибутивов перекрыты. snap, xdg-app и прочее для этого не надо, раз оно со статичного бинарника может запускаться.

Ясно. Стоило это расписать подробнее прям в тексте новости для тех, кто не знал о существовании этой софтины и её особенностей

Aur для арча есть, но его тоже, как я понимаю, обновлять вручную надо. Опять же неудобно даже из rpm и deb ставить. Говорю, может скрипт сделать, назвать его winewizard, а саму прогу winewizard-client, к примеру? Скрипт будет проверку версии делать и качать бинарник в /home/<user>/некая-папка-где-лежит-бинарник, а также запускать клиент и вырубаться. А сам скрипт и добавить в репы, он меняться не будет, значит и репы не придется часто обновлять. Какие минусы у этого видите?

Это конкретно у моей репы или вообще? Другие попробуй.

Wine Wizard 2.0.0

P.P.S.: Релиз тестовый

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

Aur для арча есть, но его тоже, как я понимаю, обновлять вручную надо.

Обновить номер версии и чексумму в PKGBUILD-файле при релизе — сложно? Ну в таком случае можно сделать winewizard-git, который просто тянет текущую версию всегда. А если это поделие нужное, то за релизами станет следить кто-то, кому интересно, и запилить поддерживаемый PKGBUILD для стабильных версий.

Но я так понимаю, что всё же ты заинтересован в том, чтобы у программы были пользователи (ведь они в том числе наполняют базу), поэтому лучше всё же приложить совсем немного усилий (меньше, чем ты тут приложил на доказывание почему не хочешь сделать нормально) и обновлять в PKGBUILD версии нормально, аналогично ebuild, а также собрать deb и rpm универсальные. Это покроет самые популярные дистрибутивы, а те, у кого несовместимо, соберут сами, они привыкли.

Да знаю, просто зарелизил, а только потом об этом подумал, поздно уже было менять.

Так е-мае, репы и так есть, но ими не я занимаюсь! Просто мейнтейнеры не всегда за обновлениями успевают, я и пытаюсь эту проблему решить. Про недостатки идеи скрипта обновления скажите лучше, который я описал выше.

Недостаток в том, что это костыли и виндузятничество. Никто не будет этим пользоваться. Устанавливать софт должен пакетный менеджер.

Если бы я решил этим воспользоваться, я бы не запускал всякие скрипты, а написал бы PKGBUILD.

да просто поставил pol и сразу сказал ставь диаблу мне, два раза попробовал и снес, дружбан через pol в танки играет, я думал тоже себе что-то next-next-ok поставить попробовать вот и попробовал, так у меня полторы программы которые я запускаю раз в пол года :)

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

Он у тебя основную программу качает куда? В хомяк пользователю? Если да, то всё я понял. Вот уже на этом месте бред — хомяк может быть смонтирован в noexec. Бинарники должны лежать там, где им место.

Страшный и неотесанный ненужный костыль -> главная новость на ЛОРе

Окей

Понятно. Задумка Wine Wizard по большей части даже не в упрощении пользования, а в том, чтобы сохранять весь опыт установки вендософта. Как например на WineHQ сидят люди, обсуждают, как что-нибудь ставить, какие пакеты качать и т.д. Но их опыт пропадает впустую, т.к., во-первых, не все WineHQ читают, а во-вторых, еще меньше туда пишут те, у кого получилось установить. А в моей программе это все сохраняется автоматом, абсолютно ненапряжно для пользователя. Просто если для Diablo инструкций полно в инете, то для узкоспециализированной проги или непопулярной игрушки их найти не удастся. А тут все в одном месте и искать ничего не надо. Если кто-то поставил - никому больше париться не надо.

А вот на это как смотришь

Отличная идея. Я за.

ненужный костыль

Но ведь кому то нужно...

Про noexec не знал, спасибо. Значит, не покатит так. Но, если мне память не изменяет, я видел на Линуксе какую-то прогу, которая обновляется прямо из самой себя. Вроде как NetBeans так может делать, но возможно я ошибаюсь.

И вообще, обращаюсь к тем, кому нужны пакеты - сделайте тогда мне скрипты их автоматической сборки, пожалуйста. Я никогда не сидел на арче, генте или чем-то подобном, поэтому понятия не имею, как там что-то надо делать. Даже пакетов для дебиана я никогда не делал, мне всегда хватало checkinstall. Накосячю, блин - сами же рады не будете.

да это dns проблемы, у них подсеть поменялась, а у меня по старым ip ходит

$ nslookup raw.githubusercontent.com
Server:		192.168.0.2
Address:	192.168.0.2#53

Non-authoritative answer:
raw.githubusercontent.com	canonical name = github.map.fastly.net.
github.map.fastly.net	canonical name = prod.github.map.fastlylb.net.
Name:	prod.github.map.fastlylb.net
Address: 151.101.36.133

$ nslookup raw.githubusercontent.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
raw.githubusercontent.com	canonical name = github.map.fastly.net.
github.map.fastly.net	canonical name = prod.github.map.fastlylb.net.
Name:	prod.github.map.fastlylb.net
Address: 151.101.12.133

Утасновка Fallout of Nevada заканчивается ошибкой

/root/.local/share/winewizard/e852c9a2d63737971c0378cec5370eb774966b31/.wine/bin/wineboot: 26: exec: /root/.local/share/winewizard/e852c9a2d63737971c0378cec5370eb774966b31/.wine/bin/wine: not found
/bin/sh: 3: wineserver: not found
/bin/sh: 6: cd: can't cd to dosdevices/c:/users/
/bin/sh: 16: cd: can't cd to /root/.local/share/winewizard/e852c9a2d63737971c0378cec5370eb774966b31/dosdevices
xargs: wine: No such file or directory

apt-get ругается на сломанный пакет

# apt-get install wine
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 wine : Depends: wine1.6 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Это же интерфейс по запуску скриптов? Пусть проверяет обновления и выводит уведомление. Возможно с инструкцией и списком изменений. Но ведь важна база решений, а не гуй? Вот она то и должна быть самой актуальной. И тогда всё будет работать (пока вы не поменяете api этих самых решений), и не важно с какой версией кнопочек.

Минусы лежащего хз где бинарника очевидны пользователям винды: через полгода-год забываешь, что ставил, где лежит, как обновляется. Если в gentoo принято писать ебилд, который качает и распаковывает архив с бинарником, то надо писать ебилд. Чтобы всё, пусть и плохо, но интегрировалось в подсистему слежения за помойкой бинарников и библиотек.

Вот не надо. Не так часто появляется и динамично развивается что то новое, потенциально полезное. Причём целевой аудитории - школьникам-линуксоидам (как ни крути). А вдруг взлетит?

Скрипт самообновления накосячит с большей вероятностью.

Вывесите на сайте объявление, типа нужна помощь в опакечивании, скрипты и советы на ${адрес} приветствуются.

Пусть проверяет обновления и выводит уведомление.

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

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

Где скрины?

Не знаю, как тут можно накосячить, но точно знаю, что любой скрипт найдёт способ накосячить. Например выкачать бинарник, который окажется несовместим с libc или ещё чем то (мало ли что обновится у вас в сборочной среде или у абстрактного юзера). Или может быть некоректная скачка, или ещё что. И если вы собираетесь держать бинарники под разные архитектуры и дистрибутивы, то может сразу сделать под них пакеты?

Steam так делает.

Так, во-первых - ты как его ставишь? Я сейчас посмотрел и не нашел в решениях Fallout of Nevada. Или ты как-то по другому назвал или другое решение выбрал?

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

Подскажите, а планируется ли в wine поддерживать DXt3/DXt5 сжатие текстур? А то пробуем на портале http://fidblog.ru/worldofwarplanes/ тему - затык с чернотой - и всё из-за этого...

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

Значит он не будет работать, если noexec выставить, или как?

Тут наверное не подскажу, это надо у разработчиков Wine спрашивать.

Не должен. Но тут я скорее к тому, что ЦА использующих Steam и Wine весьма пересекается.

Попробуй open build service. Поддерживает все более-менее известные дистры, кроме Gentoo.

Никогда не слышал, интересно, потыкаем-с.

Но, если мне память не изменяет, я видел на Линуксе какую-то прогу, которая обновляется прямо из самой себя.

youtube-dl так умеет, если запускать с ключом --update. Только нужны права на запись в соответствующее место.

$ youtube-dl --update 
Updating to version 2016.07.07 ...
ERROR: no write permissions on /usr/bin/youtube-dl

...в контексте сквозит, что заявлена (или готовится) поддержка 4.6 фреймворка.

был бы вообще полный шоколад