You are not logged in.
Pages: 1
Сегодня полностью обновил все, что хотело обновиться (подписано как новая сборка).
После этого сломался слим.
Причина: libng & libpng+apng
Слим не хочет запускаться без обеих версий (если поставить 12, говорит, что не могу найти 16, и наоборот). 12 поверх 16 не ставится. Костыль в виде ручного добавления нужных библиотек не работает. Слим ругается, что собран с 12, а запустить хотят с 16.
Собственно, спасите от ковыряния в конфигах (лень менять дисплей-менеджер).
Вручную запускать Х-ы (как и автоматом влетать) тоже не вариант.
На всяк случай: версия tazpkg 942, Database timestamp: 02/17/17 00:02
Offline
Здравствуй, Юрий.
В последнее время идет "массированное" обновление пакетов на сервере. Видимо, что-то сломалось, и теперь сборочное окружение наводнено не одной сотней пакетов (тогда как при нормальной работе их должно быть около 60), в том числе и libpng из серии libpng12 и libpng+apng из серии libpng16. Сборочные скрипты тихо офигевают и выдают такие вот вещи, о которых ты пишешь. Также, в связи с появившимися новыми пакетами в сборочном окружении, у некоторых собираемых пакетов обнаруживаются новые фичи 
Как это случилось? Некоторые пакеты не были удалены по окончании сборки и остались в сборочном окружении, причем механизм Aufs при этом не работал. Почему это случилось? Предполагаю, что из-за спешки и "параллельного" запуска сборочного бота (на что, похоже, он не рассчитан): каким-то образом обновляется гора пакетов, один за другим (скорее всего скриптом), и в то же время собираются новые пакеты согласно изменениям в hg.slitaz.org/wok.
Всё это "весело" и "интересно", но что делать? Сопровождающие проекта знают о проблеме (со вчерашнего дня), но, похоже что ничего по проблеме "libpng12 vs libpng16+apng" не меняется. Пакеты продолжают собираться автоматически. Я попробую ночью, придя с работы, удалить из сборочного окружения libpng16+apng и пересобрать slim с libpng12. Но это только в том случае, если там не будет никакой активности - не хочу сделать хуже. Если нет, прошу извинить. Похоже, этой проблеме подвержен не только slim, но и все пакеты которые при сборке требовали libpng...
Offline
Фуу... аж легче стало, а то сегодня создавал топик "Поломка после обновления!" по данной проблеме (из сматфона поскольку сами понимаете) так его Pacso банит(или система автоматически), котороче установил релиз не стал ничего обновлять...
Так когда говорите можно уже будет все таки обновления подключить?!)))
А так вообще жесть!
Offline
Привет, Андрей.
Я смотрю, две твоих темы были модерированы. Кем - не знаю. Помечены как спам. Возможно, это Akismet (антиспам) автоматом это сделал, бывает такое, учишь его, учишь, а он всё равно в лес смотрит :]
Выволок темы на белый свет, так лучше?
По поводу обновлений, прошу, воздержитесь. Систему еще можно будет починить, если в консоли есть интернет и можно будет поставить обновленные пакеты командой tazpkg -gi...
Жесть, да, пришла беда откуда не ждали... Не ошибается тот, кто ничего не делает. Но на ошибках нужно учиться. Какие будут выводы? У меня пока только один вывод - на время подобных грандиозных перетрубаций отключать обновление пакетов в репозитории mirror1.
Хмм, кажется так оно и было вначале. Кто-то жаловался на то, что mirror1 не обновляется... Мне пора закругляться, рекомендую просмотреть лог обновления: http://mirror1.slitaz.org/check - может, что-то интересное увидишь...
Offline
> Некоторые пакеты не были удалены по окончании сборки и остались в сборочном окружении. Почему это случилось? Предполагаю, что из-за спешки и "параллельного" запуска сборочного бота
Проблема явно в строке PROVIDE="libpng" вместо PROVIDE="libpng16" в рецепте libpng+apng и "tazpkg -gi optipng --quiet --cookmode" в cookutils/compressor. optipng же требует libpng+apng...
Offline
Просмотри пожалуйста файл на сервере tank:
[c]/home/slitaz/cooking/chroot/var/log/slitaz/tazpkg.log[/c]
Пакет libpng+apng благополучно:
[*]устанавливался,
[*]затем спустя какое-то время удалялся.
Потом пришло 13-е число и этот пакет после установки удалился дважды. А затем пришел час и он после установки не удалился совсем.
Вот еще цитата из моего письма:
от: Aleksej Bobylev
Кому: "Pankso@SliTaz"
копия: Pascal Bellard, Eric Joseph-Alexandre, Paul Issott, Claudinei Pereira
дата: 18 февраля 2017 г., 5:43
тема: Re: SliTaz 6.0 Notes
Hi there,
Cooking chroot is broken and should be killed and rebuild from scratch.
I do not know the reason why it happened, I can only guess: the
"parallel builds" broke the chroot.
Please, take a look into a couple of logs:
1. http://cook.slitaz.org/?pkg=libcaca
Package "libcaca" build, but package "xorg-libX11" appear in the log.
2. http://cook.slitaz.org/?pkg=exosip
Two dependencies are installed, but 21 are removed.
Note, since January, 17 (tazpkg-933 and cookutils-867) cooking log
show ALL the dependencies installed, no more hidden sub-dependencies
there.
http://hg.slitaz.org/tazpkg/rev/5dd363e1726e
http://hg.slitaz.org/cookutils/rev/5f6be706ab4f
http://hg.slitaz.org/wok/rev/faf865f8822c
3. http://cook.slitaz.org/?pkg=turnserver
Installed 1 dep, removed 3 deps.
4. http://cook.slitaz.org/?pkg=xorg-xf86-video-trident
Installed 44, removed 10.
And so on...
Regards
--------
Просьба пройтись по ссылкам...
А вообще ты прав. Но я когда создавал этот пакет давным-давно, еще не знал о зоопарке версий libpng. Казалось, что чем выше версия, тем лучше. Поэтому и принял самую большую версию, и собрал optipng с нею.
Offline
Hi Aleksej
If you check the libcaca receipt, it has to cook xorg-libX11 (as well) to be able to borrow some files in order for libcaca to work.
Hope this helps
Offline
Hi Paul,
Sorry, I actually not checked the receipt then. Now I see, it's yours, and I have one advice for you. It's enough to add the package xorg-... into $BUILD_DEPENDS: "cook" will build the package if it not built yet:
http://hg.slitaz.org/cookutils/file/9474bf43c080/cook#l648
Well. But what about other facts? I even will leave the questions "why it?.." and do ask only "how to fix it?". Developers still not responded to mail, forum topic about broken updates is still here. Can I fix it on my own? Sorry, not now. The "cook" is always on the run, it still prepares the new weird packages, and Pascal still fixes the weird bugs.
"Cook" build environment now flooded by the huge number of the packages. Receipt defaults are now differen. For example, some package not built the man pages earlier. It need libxslt and docbook-xsl for it. Now libxslt is here, but docbook-xsl missing: receipt now finished with the error. The same receipt is worked flawlessly earlier. Do we need to fix it? Or just to clean build environment from hundreds of unwanted packages?
The new man pages isn't a problem. The two different libpng at the same time is the problem. Anyone can download "slim" package, unpack it and execute "ldd /path/to/that/usr/bin/slim". It depends on libpng12 and on libpng16 at the same time. And what about other packages? SliTaz developers just didn't read no mail, nor forum. I'm busy until Sunday night. And I hope on some reaction from that side, or at least on time when "cook" will stop make the weird packages and I will be able to clean build environment on my own.
Regards.
Offline
Hi Aleksej
Sorry, I can only explain the weird behaviour for the libcaca package (because I wrote the code for it), not the other stuff.
I can only hope that's it's not a major problem with the wok and all the members of the team can work on it.
Offline
Hi Paul,
OK. I hope too.
Offline
Pages: 1
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]