30894 2015-04-01 18:25:57 +0300 [1.0.25] исправления для старых сканеров через USB3 (xhci) 2020-09-24 11:17:36 +0300 1 1 4 Development Sisyphus sane unstable all Linux CLOSED WONTFIX https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1250196 P3 normal --- 1 mike lav cas lav ldv mike nickel rider qa-sisyphus oldest_to_newest 150958 0 mike 2015-04-01 18:25:57 +0300 Возможно, стоит втянуть в наш 1.0.24 эти патчи: http://anonscm.debian.org/cgit/sane/sane-backends.git/log/?qt=grep&q=USB3&showmsg=1 http://anonscm.debian.org/cgit/sane/sane-backends.git/commit/?id=71c1a0068fdb0273883096451db2bf1a0e7f4d2c http://anonscm.debian.org/cgit/sane/sane-backends.git/commit/?id=365b619dfe4ec49045d00dcda973ffa811599e80 http://anonscm.debian.org/cgit/sane/sane-backends.git/commit/?id=014b45d920f1fb630e1a31bb01f1da02ea2a6a87 152034 1 mike 2015-07-03 13:16:29 +0300 Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит? 154255 2 cas 2015-12-14 17:50:49 +0300 ping. Надо проверить на 1.0.25. 192650 3 lav 2020-09-19 12:02:42 +0300 (Ответ для Michael Shigorin на комментарий #0) > Возможно, стоит втянуть в наш 1.0.24 эти патчи: > > http://anonscm.debian.org/cgit/sane/sane-backends.git/log/ > ?qt=grep&q=USB3&showmsg=1 Возможно, но поезд ушёл. ... (Ответ для Michael Shigorin на комментарий #1) > Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит? Против, а какой смысл? 192746 4 nickel 2020-09-22 14:34:01 +0300 > (Ответ для Michael Shigorin на комментарий #1) > > Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит? > Против, а какой смысл? Я тоже голосую за гит, если решение не окончательно-бесповоротное, т.к., к примеру: git blame sane-backends/backend/gt68xx.c выдает нижеприведенное и нужны дополнительные телодвижения, чтобы определить кто, когда и зачем вносил правки... [...] ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 146) ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 147) static SANE_String_Const source_list[] = { ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 148) SANE_I18N ("Flatbed"), ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 149) SANE_I18N ("Transparency Adapter"), ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 150) 0 ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 151) }; ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 152) ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 153) static SANE_Range x_range = { 86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000 154) SANE_FIX (0.0), /* minimum */ 86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000 155) SANE_FIX (216.0), /* maximum */ 86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000 156) SANE_FIX (0.0) /* quantization */ ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 157) }; ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 158) ^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000 159) static SANE_Range y_range = { [...] 192764 5 lav 2020-09-22 23:54:22 +0300 (Ответ для nickel@altlinux.org на комментарий #4) > > (Ответ для Michael Shigorin на комментарий #1) > > > Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит? > > Против, а какой смысл? > > Я тоже голосую за гит, если решение не окончательно-бесповоротное, т.к., к > примеру: > > git blame sane-backends/backend/gt68xx.c > > выдает нижеприведенное и нужны дополнительные телодвижения, чтобы определить > кто, когда и зачем вносил правки... Не нужно превращать сборку пакета в разработку. Если хотите разрабатывать — есть апстрим. Если нужно просто собрать — надо держаться подальше от всех подробностей, а то можно дойти до крайностей и вычитывать все коммиты каждого релиза. В нормальном проекте есть свои CI, тестирование, принятие решения о релизе. И надо пользоваться релизами, а не повторять чужую работу, тратя время. 192767 6 rider 2020-09-23 06:38:31 +0300 ну конечно же нужно сборку пакета превращать в разработку. Иначе нормального сопровождения пакета невозможно добиться. Апстрим, к сожалению, в своих CI системах чаще всего ничего не знает про Альт. А разобраться в чём именно причина проблем с пакетом намного удобнее имея историю изменения исходного кода. 192811 7 lav 2020-09-24 11:06:23 +0300 (Ответ для Anton Farygin на комментарий #6) > ну конечно же нужно сборку пакета превращать в разработку. Иначе нормального > сопровождения пакета невозможно добиться. > > Апстрим, к сожалению, в своих CI системах чаще всего ничего не знает про > Альт. А разобраться в чём именно причина проблем с пакетом намного удобнее > имея историю изменения исходного кода. Чтобы устранить проблему, нужно отправить патч в апстрим. Для этого нужно а) иметь репозиторий апстрима б) собирать проект так, как это делает апстрим и репозиторий альта тут ни при чём. Нет, ну если кому-то нравится в невидимой ветке синхронизировать апстримный репозиторий, тут дело вкуса. Просто вы хотите на уровне коммитов разбираться, а я на уровне версий, вот у нас и разный подход к измельчению потока кода и апстрима. Просто у нас разные подходы. Я считаю, что работа мантейнеров не нужна и бессмысленна. А вы хотите в этом найти разработку. 192813 8 nickel 2020-09-24 11:17:36 +0300 (Ответ для Vitaly Lipatov на комментарий #7) > Нет, ну если кому-то нравится в невидимой ветке синхронизировать апстримный > репозиторий, тут дело вкуса. А почему в невидимой-то? Как раз слияние апстримной и ALT'овой веток даёт в исходном дереве пакета увидеть, а не влияют ли наши изменения на отвалившуюся часть функционала без необходимости скакать между ветками и грепать то там, то тут...