Посмотрю

Перенос на конкретный пакет

Бага как бага, critical -- это если б он на старте ложился.

(In reply to comment #3)
> Бага как бага, critical -- это если б он на старте ложился.

Это critical, так как не соответстует условиям КД.

(In reply to comment #4)
> Это critical, так как не соответстует условиям КД.
(посмотрев в Product) к Sisyphus это каким боком?  Задача для core dev/QA ООО
или контрактная, а не майнтейнерская.  Разве если packaging bug, передать в
апстрим или майнтейнер участвует в разработке, но тогда нет слова "срок", что
вряд ли приемлемо.

+1

-> cas@

Перевесил на Школьный и на ktirf@, critical относится к ним.

Господа, не мутите воду, багами на Школьный комплект занимается Руслан. Я могу
быть только в CC, а данный конкретный баг вообще может исправить только sbolshakov@.

(In reply to comment #9)
> Господа, не мутите воду, багами на Школьный комплект занимается Руслан. Я могу
> быть только в CC, а данный конкретный баг вообще может исправить только
sbolshakov@.

Ok. Вы начальник, Вам виднее на кого вешать.

пакет skencil включается в школьный комплект с 20080311, если не раньше.
если баг заключался в его отсутствии в более ранних версиях, то fixed.

Не поддерживается импорт (ошибка конвертации в скрипте) и экспорт (вообще нет 
в списке форматов) Sketch.

удалось выяснить, в каком пакете ошибка ?

Если формата нет в списке, значит skencil не установлен, или установлен, но не
найден.

Не залезая в код Inskape, а только ориетируясь пока на Google для импорта 
файлов *.sk и *.sk1 нужен uniconvertor 
http://wiki.inkscape.org/wiki/index.php/Tools#uniconvertor. 

Sketch создаёт эти файлы, но не участвует в импорте Inkscape. 

Сам uniconvertor может конвертировать различные файлы и сам, но из командной 
строки. 

ps смотрю дальше

Извиняюсь - у нас участвует через sckonvert, входящий в пакет skencil

(In reply to comment #15)
> Не залезая в код Inskape, а только ориетируясь пока на Google для импорта 
> файлов *.sk и *.sk1 нужен uniconvertor 
> http://wiki.inkscape.org/wiki/index.php/Tools#uniconvertor. 
Прокудин тоже говорил, что нужно его использовать. 
Осталось сбэкпортировать его на school-4.0 (или в branch-4.0) и обеспечить 
интеграцию с Inkscape.

Там этот *&^&*^&* питон, будь он не ладен.  "Последний".

Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов
вообще, нравится тебе это или нет. Причём, он будет нужен не только Inskcape, но
и Scribus. И, кстати, для импорта не столько SK, сколько CDR и прочей
проприетарной фигни. Так что нравится это тебе или нет, но тебе придётся с этим
жить.

Да, текущая версия UC лажает с импортом SK. Это уже исправлено в транке sK1 и
будет перетащено в UC при первой возможности.

(In reply to comment #19)
> Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов
> вообще, нравится тебе это или нет.
Слушай, я почти пошёл его в сизиф собирать в своё время благодаря frob :)

Одна маленькая проблема, которая быстро вылезла (сразу после необходимости
обновления/перелопачивания ряда модулей) -- python-2.5, на который автор успел
спрыгнуть, пока разбирались с первой частью.

Для мастхэвов противопоказано гоняться за последними пе... питонами.  Увы, факт.

(In reply to comment #19)
> Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов
> вообще, нравится тебе это или нет. 

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

> удалось выяснить, в каком пакете ошибка ?
Ошибка в скрипте skconvert.py, входящем в skencil.

error in line 19
Traceback (most recent call last):
  File "/usr/lib/skencil-0.6.17/Plugins/Filters/skloader.py", line 469, in Load
    funcname, args, kwargs = parse(line)
SyntaxError: unexpected character
Traceback (most recent call last):
  File "/usr/bin/skconvert", line 55, in ?
    main()
  File "/usr/bin/skconvert", line 52, in main
    convert(sys.argv[1], sys.argv[2])
  File "/usr/bin/skconvert", line 35, in convert
    doc = load.load_drawing(infile)
  File "/usr/lib/skencil-0.6.17/Sketch/Base/load.py", line 368, in load_drawing
    return load_drawing_from_file(file, filename)
  File "/usr/lib/skencil-0.6.17/Sketch/Base/load.py", line 343, in 
load_drawing_
from_file
    doc = loader.Load()
  File "/usr/lib/skencil-0.6.17/Plugins/Filters/skloader.py", line 506, in Load
    raise SketchLoadError('%d:%s' % (num, value))
Sketch.skexceptions.SketchLoadError: 19:unexpected character

На сегодня можно предложить хак для Inkscape

- в скрипте /usr/share/inkscape/extensions/sk2svg.sh 
строчку 
skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1
заменить на 
LC_ALL=C skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1

А вот и подтверждение :)
http://wald.intevation.org/tracker/index.php?func=detail&aid=345&group_id=5&atid=101

(In reply to comment #23)
> На сегодня можно предложить хак для Inkscape
> 
> - в скрипте /usr/share/inkscape/extensions/sk2svg.sh 
> строчку 
> skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1
> заменить на 
> LC_ALL=C skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1
>

Почему же это хак? Наверное, будет корректнее LC_NUMERIC=C
 

Created attachment 2579 [details]
Патч для skencil

Аот это уже в меньшей мере хак :)

>Почему же это хак? Наверное, будет корректнее LC_NUMERIC=C
 
Потому, что менять надо в скриптах sketcil, а не в вызывающих скриптах :)

В приложенном выше хаке, на всякий случай изменил LC_NUMERIC в аналогичных 
скриптах :

sk2ps.py и sk2ppm.py, но я из не проверил.

Исправленно

Да? И сохранение в Sketch работает?

Выдать расширение, добавляющее экспорт в скетч при наличии юниконвертора в системе?

,----------------------------------------------------------------------------.
| Выдать расширение, добавляющее экспорт в скетч при наличии юниконвертора в |
| системе?                                                                   |
|                                                                            |
|                           [ Зажать ]  | Выдать |                           |
|                                                                            |
`----------------------------------------------------------------------------'

Ну раз ты, Майк, такой шутник, собирай юниконвертор :)

Вы тут не о
http://sisyphus.ru/srpm/Sisyphus/uniconvertor
?

> Вы тут не о
>http://sisyphus.ru/srpm/Sisyphus/uniconvertor
>?
Именно о нём, вернее о его бэкпортировании в школьный комплект.

(In reply to comment #32)
> Ну раз ты, Майк, такой шутник, собирай юниконвертор :)
Вообще-то меня frob и пинал это сделать, но основной разработчик очень вовремя тогда спрыгнул на python-2.5, а в сизифе был ещё 2.4...

(In reply to comment #34)
> >http://sisyphus.ru/srpm/Sisyphus/uniconvertor?
> Именно о нём, вернее о его бэкпортировании в школьный комплект.
Смутно припоминается, что опять же Валёк уточнял насчёт 2.4/2.5, но лучше переспросить апстрима.

2 cas: возможно, сейчас это лучше проигнорировать, а решить к M41 в рабочем порядке.  Если только не "любой ценой" (ТМ).

PS: хорошая иллюстрация к тому, почему питон для production противопоказан: постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками.

(In reply to comment #35)
...
> > Именно о нём, вернее о его бэкпортировании в школьный комплект.
> Смутно припоминается, что опять же Валёк уточнял насчёт 2.4/2.5, но лучше
> переспросить апстрима.
Да, вроде бы с 2.4 не собирается.


> 2 cas: возможно, сейчас это лучше проигнорировать, а решить к M41 в рабочем
> порядке.  Если только не "любой ценой" (ТМ).
> 
> PS: хорошая иллюстрация к тому, почему питон для production противопоказан:
> постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками.
Мне кажется уже стоит прекратить рассказывать какой плохой Питон и почему его нельзя использовать. Слишком уже похоже на "сосед напел", или "да 30 лет назад я программистом работал". просто вот взять и прекратить выступать об этом на каждом встречном пеньке.
И иллюстрация к тому - плохая. Если бы разработчики не использовали новые конструкции, появившиеся в 2.5, проблемы бы не было.

(In reply to comment #36)
> > PS: хорошая иллюстрация к тому, почему питон для production противопоказан:
> > постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками.
> Мне кажется уже стоит прекратить рассказывать какой плохой Питон и почему
> его нельзя использовать. Слишком уже похоже на "сосед напел"
Да нет, сам споткнулся.

> просто вот взять и прекратить выступать об этом на каждом встречном пеньке.
> И иллюстрация к тому - плохая. Если бы разработчики не использовали новые
> конструкции, появившиеся в 2.5, проблемы бы не было.
(пожимая плечами) Ты майнтейнер, тебе видней.

Да только помимо новых конструкций -- на новые версии питона разработчиков толкает и то, что старый код на них не работает.  Потому как с совместимостью проблемы в обе стороны.

Всё, слез с пенька.

Продукт ПСПО давно не существует, неактуально.