И снова на арене Gentoo-дистмейкеры

Было такое счастливое время, когда структура каталогов в пакетах Gentoo была очень стройна и логична.

Но до чего (и как? что пить? что нюхать?) нужно было дойти, чтобы lxc-create создавал виртуальные машины в… /etc!

Следующий этап — кидать в /etc логи?

Очередной прикол. Стабильный net-firewall/iptables-1.4.13 требует virtual/os-headers-0, который, в свою очередь требует нестабильный sys-kernel/linux-headers-3.3

Девелоперы продолжают всё дальше забивать на стабильную ветку?

Пилятъ!

  (net-analyzer/fping-3.0::gentoo, ebuild scheduled for merge) conflicts with
    <=net-analyzer/fping-2.9 required by (net-analyzer/zabbix-1.8.11-r2::gentoo, ebuild scheduled for merge)

Ничего, что и zabbix-1.8.11-r2, и net-analyzer/fping-3.0 помечены стабильными?

Про то, что уже который раз стабильные пакеты требуют нестабильных уже и не пишу. Такое впечатление, что дистромейкеры у Gentoo совсем забили на «стабильную» версию…

можно пожалуйста подробнее почему это оно требует нестабильный linux-headers

        kernel_linux? ( sys-kernel/linux-headers:0 )

DEPEND="${RDEPEND}
    virtual/os-headers
"

А про sys-kernel/linux-headers там вообще ни слова. Только в iptables-1.4.6

Вообще, там дофига arch пакетов хотят virtual/os-headers безусловно:

net-misc/iputils-20101006-r2 (virtual/os-headers)
net-misc/openssh-5.9_p1-r4 (virtual/os-headers)
sys-apps/ipmitool-1.8.11-r1 (virtual/os-headers)
sys-apps/openrc-0.9.8.4 (virtual/os-headers)
sys-apps/sysvinit-2.88-r3 (virtual/os-headers)
sys-apps/util-linux-2.20.1-r1 (virtual/os-headers)
sys-fs/udev-171-r5 (virtual/os-headers)
sys-libs/glibc-2.14.1-r3 (virtual/os-headers)

а он, в свою очередь, только одной версии, хотящей ~arch kernel/linux-headers:

RDEPEND="
    || (
        kernel_linux? ( sys-kernel/linux-headers:0 )
        !prefix? ( sys-freebsd/freebsd-lib )
    )"

При этом флаг kernel_linux включен по умолчанию в стабильном профиле.

Девелоперы продолжают всё дальше забивать на стабильную ветку?

Дублируй это в багзиллу, епрст!
Я поддержу там комментариями :)

я скопировал код из virtual/os-headers, который зависит от любых linux-headers, а не нестабильных. Сейчас собираю чрут стабильный чтобы проверить на живой системе.

Дублируй это в багзиллу, епрст!

Я забил уже (писал об этом выше). Помрёт, так помрёт.

Я забил уже (писал об этом выше). Помрёт, так помрёт.

:(((

на образе stage3-amd64-20120510.tar.bz2 не воспроизводится, например. Если есть идеи как воспроизвести выслушаю

который зависит от любых linux-headers, а не нестабильных

Вообще-то говоря, да. Но факт остаётся фактом, сразу на двух оставшихся машинах при обновлении (все системы — arch) вываливается:

The following keyword changes are necessary to proceed:
#required by virtual/os-headers-0, required by @system, required by @world (argument)
=sys-kernel/linux-headers-3.4 ~amd64

И система не обновляется, пока не размаскируешь =sys-kernel/linux-headers-3.4 (так и сделал, но…)

Ложь, данной зависимости (kernel_linux? ( sys-kernel/linux-headers:0 )) удовлетворяет linux-headers-3.1, который стабильный. kernerl_linux естественно включен, иначе и быть не может, если ты не gentoo/bsd или gentoo/nt и т.п. пользуешь.

Ложь, данной зависимости (kernel_linux? ( sys-kernel/linux-headers:0 )) удовлетворяет linux-headers-3.1, который стабильный

Скажи это моим emerge. А то они не в курсе.

будут идеи как воспроизвести попробую сделать, спецом для этого систему подготовил. Щас ещё обновлю до последнего актуального состояния и перепроверю, хотя повлиять не должно.

а тут я тебя ну совсем не понимаю. Вполне нормальная ситуация когда две стабильные программы не могут работать вместе. Или mpich и mpd тоже нестабильными помечать, раз они вместе стоять не могут (без магии).

может emerge --info покажешь, или скажешь, что ты с ним делал, поскольку в «дефолтном» стабильном emerge этой проблемы не возникает.

будут идеи как воспроизвести попробую сделать

Забавно. На одной из машин, где эта ошибка 23-го вылезала, если вручную замаскировать =sys-kernel/linux-headers-3.3, то при emerge -av1 virtual/os-headers он теперь предлагает честный downgrade до 3.1 без ошибок.

и да если ставить fping, а потом zabbix то проблемы не будет она возникает только при обновлении zabbix с -r1

19 Apr 2012; <...> +zabbix-1.8.11-r2.ebuild, zabbix-2.0.0_rc2.ebuild: Update zabbix dependencies, not compatible with fping >= 3.0, Tracking Bug 412659

хотелось бы услышать, как надо было сделать. в случае если у человека уже стоит 1.18.11-r1 (когда баг не был обнаружен) и fping-3.0

Вполне нормальная ситуация когда две стабильные программы не могут работать вместе

Раньше в Gentoo такое не было нормальным. И за это я её раньше и любил. И то, что сейчас это стало нормальным — это с моей точки зрения очень плохо.

может emerge --info покажешь, или скажешь, что ты с ним делал

emerge --info
Portage 2.1.10.49 (default/linux/amd64/10.0/server, gcc-4.5.3, glibc-2.14.1-r3, 3.2.12-gentoo x86_64)
=================================================================
System uname: Linux-3.2.12-gentoo-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_2386_SE-with-gentoo-2.1
Timestamp of tree: Sun, 27 May 2012 02:30:01 +0000
app-shells/bash:          4.2_p20
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.3-r1, 3.2.3
dev-util/cmake:           2.8.7-r5
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.9.9.3
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.5.3-r2
sys-devel/gcc-config:     1.5-r2
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 3.1 (virtual/os-headers)
sys-libs/glibc:           2.14.1-r3
Repositories: gentoo x-portage
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA Q3AEULA Nero-EULA-US PUEL dlj-1.1"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=barcelona -mmmx -msse -msse2 -msse4a -m3dnow"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/bind /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=barcelona -mmmx -msse -msse2 -msse4a -m3dnow"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="-bD --jobs=10 --load-average=5"
FEATURES="assume-digests binpkg-logs buildpkg distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://gd.tuwien.ac.at/opsys/linux/gentoo/ http://mirror.gentoo.no/ http://gentoo.kiev.ua/ftp/ http://mirror.netcologne.de/gentoo/"
LANG="ru_RU.utf8"
LC_ALL=""
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="ru"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext 3dnowprefetch X acl admin amd64 apache2 berkdb bsf bzip2 c3p0 cairo cgi cli cracklib crypt ctype curl custom-cflags cxx djvu dri examples exif extensions extras fastcgi ffmpeg fortran ftp gd gdbm geoip gif git gpm graphviz hdri iconv imagemagick jabber java java6 javascript jpeg jpeg2k json ldap lua math memcache mercurial mmap mmx modules mono mudflap multilib mysql ncurses nls nptl odbc openexr openipmi openmp optimization pam pcntl pcre perl php png postgres pppd python raw readline ruby session slang snmp sqlite sqlite3 sse sse2 sse4a ssl stemmer strong-optimization subversion svg sysvipc tcpd threads tiff tools truetype unicode unzip vhosts vim-syntax web webdav webinterface wmf xfs xml xorg xsl zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="itk" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="none" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="ru" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi flv geo gzip limit_req limit_zone map memcached proxy referer rewrite scgi split_clients ssi upstream_ip_hash userid uwsgi addition cache_purge geoip gzip_static image_filter perl realip stub_status upload" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby19 jruby" USERLAND="GNU" VIDEO_CARDS="none" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

хм.. интересно, а у тебя случаем до linux-headers-3.2 не было обновлено?

Самое печальное, что и мигрировать-то некуда.

хм.. интересно, а у тебя случаем до linux-headers-3.2 не было обновлено?

Нет. У меня [почти?] все системные пакеты — arch. И linux-header был 3.1:

# genlop sys-kernel/linux-headers
 * sys-kernel/linux-headers

     Wed Mar  2 01:07:43 2011 >>> sys-kernel/linux-headers-2.6.36.1
     Fri Jul  8 11:15:48 2011 >>> sys-kernel/linux-headers-2.6.36.1
     Sun Oct 23 01:34:30 2011 >>> sys-kernel/linux-headers-2.6.39
     Wed Jan 25 12:38:57 2012 >>> sys-kernel/linux-headers-3.1
     Wed May 23 14:13:41 2012 >>> sys-kernel/linux-headers-3.3
     Mon May 28 01:39:54 2012 >>> sys-kernel/linux-headers-3.1

Самое печальное, что и мигрировать-то некуда.

Это да. Если на десктопе я со скрипом, но без большого морального урона пересел на Ubuntu, то на сервере пока альтернативы [для меня] нет.

На другой машине, соответственно:

# genlop sys-kernel/linux-headers
 * sys-kernel/linux-headers

     Tue Oct 18 01:48:29 2011 >>> sys-kernel/linux-headers-2.6.39
     Wed Jan 25 12:20:33 2012 >>> sys-kernel/linux-headers-3.1
     Mon May 28 01:19:49 2012 >>> sys-kernel/linux-headers-3.4

Тут хитрая ситуация. Последний zabbix и fping по факту не могут работать вместе, но это было обнаружено не сразу итого проблема появляется только у тех, кто успел поставить zabbix-1.8.11-r1 и fping-3.0 потому, что в противном случае будет или предложено поставить zabbix-1.8.10-r1 или fping-2.4_beta2_p161-r1, которые тоже стабильные.

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

Поэтому я и спросил как бы ты хотел, чтобы в твоём случае всё разрулилось.

очень странно, особенно с учётом того, что на свежей системе не воспроизводится; в в emerge --info и в логах обновления я ничего того, что могло привести к этой проблеме не увидел, завтра ещё попытаюсь помучать систему, чтобы воспроизвести, и подключить «тяжелую артиллерию», если идей не придёт. А щас спать пора, а то экзамен завтра.

Тут хитрая ситуация. Последний zabbix и fping по факту не могут работать вместе

Так у меня претензии именно к тому, что в Gentoo забили на тщательное тестирование.

Скорее всего, это связано с http://www.google.com/trends/?q=Gentoo — но, с другой стороны, тут возникает вопрос, что было раньше, курица или яйцо.

Так у меня претензии именно к тому, что в Gentoo забили на тщательное тестирование.

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

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

1.Насколько трудоемко создать автоматический разбор исходников по USE флагам и зависимостям, основываясь только на голых исходниках и базе данных для определения USE флагов, чтобы исключить eduild-ы от блондинок с гранатами?

(Может быть для первоначальной верстки edbuild-а выделять виртуальный корневой каталог, откуда потом на основе анализа выделять информацию для установки-зачистки частей пакета)

2.Как автоматически формировать рабочие конфигурационные файлы пакетов?

Вероятно есть еще нюансы, но это то что приходит на ум сразу.

http://www.google.com/trends/?q=Путин, Медведев, Gentoo, Slackware&ctab=0... Странно это всё.

1. в общем случае нет. От защиты от ebuild-ов от блондинок с гранатами хорошо спасает офиц. дерево.

(Может быть для первоначальной верстки edbuild-а выделять виртуальный корневой каталог, откуда потом на основе анализа выделять информацию для установки-зачистки частей пакета)

чо?

2. Как автоматически формировать рабочие конфигурационные файлы пакетов?

чо?

Гниет как раз официальное дерево. Окунитесь туда разок.

На первое

чо

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

На второе

чо

Как вариант сделать 3-х уровневую конфигурацию таких файлов. Офицальный основной, профильный и личный, а из них уже формировать настройки пакета.

Гниет как раз официальное дерево. Окунитесь туда разок.

больше конкретных примеров, пожалуйста.

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

1). автоматическое формирование ебилда в невозможно.

2). я вот читаю предложение и не понимаю, что Вы пытаетесь донести. Можете внятно сформулировать что хотите получить и отдельным предложением, что предлагаете сделать.

3). ебилд мусорит только в /var/tmp/portage/category/package-atom

Как вариант сделать 3-х уровневую конфигурацию таких файлов. Офицальный основной, профильный и личный, а из них уже формировать настройки пакета.

я не понял, что Вы пытаетесь получить.

больше конкретных примеров, пожалуйста.

Простой пример новые версии transmission только под gtk3. Как следствие переделка ebuild и под gtk2. Официальное дерево.

автоматическое формирование ебилда в невозможно

Откуда такая уверенность? Сейчас просто отсутствуют такие возможности.

я вот читаю предложение и не понимаю, что Вы пытаетесь донести. Можете внятно сформулировать что хотите получить и отдельным предложением, что предлагаете сделать

Автоматическое формирование ebuild пакетов

ебилд мусорит только в /var/tmp/portage/category/package-atom

Речь шла о пакете для которого нужно формировать ebuild.

я не понял, что Вы пытаетесь получить.

Отделить как минимум личные настройки пакетов, к примеру конкретную настройку конфигурации сети или веб сервера и т.д. от общих, чтобы не анализировать кучу файлов конфигураций в случае глобальных изменений в дистрибутиве.

P.S.

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

Лучше бы свои замечания направляли мантейнерам портов FreeBSD — это чаще приветствуется, чем бездумно отвергается.

Очень нужна помощь в портировании новых версий ключевых приложений и библиотек. Тестирование сборок ПО с помощью системного LLVM/Clang.

в общем на чистой системе перекинул питон на 2.7 всё обновил, но всё равно не смог воспроизвести проблему с linux-headers, так, что подозреваю, какое-то хитрое изменение в твоей системе выползшее наружу.

Откуда такая уверенность? Сейчас просто отсутствуют такие возможности.

из опыта и наблюдений за проблемными ебилдами, а что? Для частных случаев вполне можно генерить примеры: g-ctan, hackport, и т.п. Но эти частные случае отделяет более строгая и узкая билд система.

Автоматическое формирование ebuild пакетов

концепт в студию.

Речь шла о пакете для которого нужно формировать ebuild.

использовать команду ebuild и мусор будет только в var, это всё есть готовое.

Отделить как минимум личные настройки пакетов, к примеру конкретную настройку конфигурации сети или веб сервера и т.д. от общих, чтобы не анализировать кучу файлов конфигураций в случае глобальных изменений в дистрибутиве.

идея ломать стандартные файлы конфигурации пакетов (если я правильно понял) не самая лучшая идея, в плане легкости поддержки и принципа least surprise. Если я понял неправильно, то рад видеть на примере конкретных программ.

P.S. Если не понимаем друг друга, то можно просто прекратить прения. Для меня это не жизненно необходимо. В данный момент это просто сырая идея, которая требует осмысления.

это не прения это попытка понять, что не устраивает и что хочется изменить. Минимум попытка помочь сформулировать запрос. Напр. из 3-х страничного спора с мегабаксом вытекли патчи к smart-live-rebuild позволяющие держать только верхний срез live пакетов и тем самым экономить место.

Лучше бы свои замечания направляли мантейнерам портов FreeBSD — это чаще приветствуется, чем бездумно отвергается.

спрячься отсюда, пожалуйста.

А поясните, что это у меня гента паясничает:

# layman -L
* Failed to update the overlay list from: http://www.gentoo.org/proj/en/overlays/repositories.xml
* Error was:
* Failed to parse the overlays list fetched from http://www.gentoo.org/proj/en/overlays/repositories.xml
* This means that the downloaded file is somehow corrupt or there was a problem with the webserver. Check the content of the file. Error was:
* 'module' object has no attribute 'expat'

# mirrorselect -i
* Downloading a list of mirrors...Traceback (most recent call last):
  File "/usr/sbin/mirrorselect", line 888, in <module>
    main(sys.argv)
  File "/usr/sbin/mirrorselect", line 875, in main
    hosts = Extractor(MIRRORS_3_XML, options).hosts
  File "/usr/sbin/mirrorselect", line 153, in __init__
    hosts = self.getlist(parser, list_url)
  File "/usr/sbin/mirrorselect", line 195, in getlist
    parser.parse(urllib.urlopen(url).read())
  File "/usr/lib64/python2.7/site-packages/mirrorselect/mirrorparser3.py", line 37, in parse
    for mirrorgroup in ET.XML(text):
  File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML
    parser = XMLParser(target=TreeBuilder())
  File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1466, in __init__
    "No module named expat; use SimpleXMLTreeBuilder instead"
ImportError: No module named expat; use SimpleXMLTreeBuilder instead

/bin/sh ../libtool --silent --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python2.7 -I../include -I../include -I../python -shared   -march=native -O2 -pipe -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wno-long-long -c -o libxml2mod_la-types.lo `test -f './types.c' || echo './'`./types.c
Traceback (most recent call last):
  File "./generator.py", line 1186, in <module>
    buildStubs()
  File "./generator.py", line 517, in buildStubs
    (parser, target)  = getparser()
  File "./generator.py", line 34, in getparser
    parser = xml.sax.make_parser()
  File "/usr/lib64/python2.7/xml/sax/__init__.py", line 93, in make_parser
    raise SAXReaderNotAvailable("No parsers found", None)
xml.sax._exceptions.SAXReaderNotAvailable: No parsers found

мантейнерам портов FreeBSD

А что, они пилят gentoo/kfreebsd?

python-updater сделай

Так делал. Ладно, ещё раз сделаю.

Сделал. Не изменилось. Плюс оно норовит пересобрать libxml2, которая не собирается с ключом python, пересобрал без него.

Простой пример новые версии transmission только под gtk3. Как следствие переделка ebuild и под gtk2. Официальное дерево.

согласен, раз в transmission есть поддержка gtk-2, то можно было её и вынести наверх. btw, готовый ебилд для этого есть?

так оно пересобрало или «поломалось» при пересборке?

Так я флаг убрал — пересобралось.

Упс, я кажется случайно питону поставил флаг build...

это не прения это попытка понять, что не устраивает и что хочется изменить. Минимум попытка помочь сформулировать запрос. Напр. из 3-х страничного спора с мегабаксом вытекли патчи к smart-live-rebuild позволяющие держать только верхний срез live пакетов и тем самым экономить место.

Вас услышал. По всем вопросам отпишу немногим позднее. Сразу оговорюсь, что у меня могут быть некоторые сложности с терминологией, так как все познавал самостоятельно. Готовый ebuild для transmission само собой есть и не только для него.