- А в чём проблема У пользователей минта некроверсия, отвечай -- обновитесь Их д, Аноним (3), 10:56 , 19-Июл-26 (1) +20 [^]
А в чём проблема? У пользователей минта некроверсия, отвечай -- обновитесь. Их дистрибутив их выбор.

- Заманало отвечать на такие багрепорты, может быть Хотя сомневаюсь что их за все, Аноним (3), 11:05 , 19-Июл-26 (3) –3
- Именно Тут какие-то личные заморочки, ну, все мы знаем, кто разрабатывает гном , Аноним (3), 11:12 , 19-Июл-26 (9)
- Этот крендель выпускает новую версию, прибитую гвоздями к новому гному, и хочет,, анони (?), 11:50 , 19-Июл-26 (31) +16 [^]
- Он хочет, чтобы если его поделку не обновляют, то чтобы убрали инфу о его отве, Аноним (73), 14:00 , 19-Июл-26 (73) +3
- Ну да, обновить весь гном из-за календаря, потратить херову тонну времени и сил , анони (?), 14:25 , 19-Июл-26 (84) +3
- если ты не хочешь обновлять калькулятор, то не ной, что в нем что то не работает, Аноним (-), 14:40 , 19-Июл-26 (91)
- Ему кто-то платит за LTS релизы и их поддержку Неадекваты это те кто сидят на L, morphe (?), 17:28 , 19-Июл-26 (129)
- С каких это пор весь Гном нужно обновлять из-за одного приложения Или там имеет, Vladjmir (ok), 07:18 , 20-Июл-26 (191)
- Ну так пусть сделает шаблон в багтрекере, чтобы в котором так прямо и напишет, ч, freehck (ok), 16:40 , 19-Июл-26 (120) +3
- Ну, то есть, он хочет, чтобы люди вообще не запускали старые версии его недодели, Аноним (59), 18:45 , 19-Июл-26 (146) +1
- Не факт, что это возможно Как уже неоднократно обсуждалось, у GNOME во-первых н, freehck (ok), 16:34 , 19-Июл-26 (119) +1
- Вроде бота просто создать Если нет версии, то спросить Если есть старая версия, , iPony128052 (?), 11:57 , 19-Июл-26 (34)
- Вот в чём About MeWelcome to my personal website My name is Hari Rana pronoun, EuPhobos (ok), 21:44 , 19-Июл-26 (160) +3
- Вот именно поэтому флатпаки единственная правильная модель дистрибуции по для де, Аноним (5), 11:06 , 19-Июл-26 (5) –29 [VVV]
Вот именно поэтому флатпаки единственная правильная модель дистрибуции по для десктопа, хоть и не без своих недостатков

- Единственная правильная модель дистрибуции для десктопа 8212 HPKG На втором , Аноним (42), 11:09 , 19-Июл-26 (8) –3
- день добрый вопрос чем хайковский bsd пакет так правильно хорош, что лучше в 10, sunjob (ok), 11:14 , 19-Июл-26 (12) +5
- Всем Обычные пакеты, это не приложения которые устанавливаются в ОС, а кусок ср, Dependency hater (?), 14:20 , 19-Июл-26 (79) +1
- И которые создают ситуацию, где у тебя на выбор 2 стула lts система в которую с, Dependency hater (?), 14:23 , 19-Июл-26 (82) +1
- Нихрена не объяснил, зато как грудь выпятил В большинстве случаев это вранье Ку, q (ok), 14:28 , 19-Июл-26 (86) –4 [V]
- Даже в генте и раче спокойно распаковывают эти rpm и устанавливают блобы, всё ра, Аноним (3), 15:19 , 19-Июл-26 (103) –1
- Аргументация - твой конек Не создают dependency hell это когда я ставлю apk из , Dependency hater (?), 16:06 , 19-Июл-26 (115) +2
- Ты путаешь с обратной совместимостью Понимаю, технические термины -- не твой ко, q (ok), 16:15 , 19-Июл-26 (117)
- Нечего сказать - докопайся до терминов Запомнить умные технические слова можешь,, Dependency hater (?), 16:52 , 19-Июл-26 (123) +1
- Что именно важно в пакетнике, зависит от конкретной задачи Вначале изучаем зада, q (ok), 17:04 , 19-Июл-26 (127) –2
- У меня задача поставить рандомную прогу нужной версии под дефолтный десктопный л, Dependency hater (?), 17:54 , 19-Июл-26 (134)
- Пакетник это не профессиональный инструмент, а дефолотная часть ос, уровня экран, Dependency hater (?), 18:00 , 19-Июл-26 (135)
- Лучше иметь один нормальный вариант без выбора, чем большой выбор из сортов говн, Dependency hater (?), 18:01 , 19-Июл-26 (136) +2
- https apps gnome org ru Calendar , Аноним (74), 11:58 , 19-Июл-26 (35)
- Разработчик GNOME неадекватен Некоторые дистрибутивы могут поддерживаться больш, Аноним (6), 11:06 , 19-Июл-26 (6) +25 [^]
Разработчик GNOME неадекватен. Некоторые дистрибутивы могут поддерживаться больше 10 лет. Устаревшая версия там будет всегда. К тому же его поделка прибита гвоздями к новой версии гнома. Обновить её не представляются возможным без перепахивания всего дистрибутива.Вывод напрашивается такой. Надо сразу выпускать нормальную протестированную версию, а не вкидывать сырой нейрослоп, в надежде, что там кто-то чего-то протестирует и обновит.

- Абсолютно адекватен Прочитайте ещё раз Вывод напрашивается такой, что вы не уме, Colorado_House_of_Representatives (?), 11:12 , 19-Июл-26 (11) –11 [VVV]
- Ему сказали, там пара изменений отличий, а он вместо того чтобы их бегло как не, Аноним (17), 11:26 , 19-Июл-26 (17) +18 [^]
- а почему он должен их смотреть очевидно, что нет времени - это отговорка есл, Аноним (-), 12:21 , 19-Июл-26 (48) –5 [V]
- Уважаемый местный нейрослоп, а почему автор должен принимать на веру чьи-то утве, Аноним (115), 12:33 , 19-Июл-26 (51) –4 [V]
- Очевидно, что, если даст слабину сейчас, потом придут эти горе-писатели уникальн, Colorado_House_of_Representatives (?), 12:51 , 19-Июл-26 (60)
- Это заявляния самого разработчика, который отказался смотреть на код, чтобы поня, анони (?), 11:53 , 19-Июл-26 (32) +9 [^]
- Разработчик GNOME Calendar обвинил Linux Mint в игнорировани..., Аноним (24), 13:19 , 19-Июл-26 (67) +1
- Вообще-то в этом суть всех стабильных дистрибутивов с релизным циклом при подго, freehck (ok), 16:56 , 19-Июл-26 (124) +5
- а поддерживать их должны разработчики гномога или кто а почему калькулятор воо, Аноним (-), 11:23 , 19-Июл-26 (16) –2
- ага значит Линус обязан вам поддержвать ядро 2 59 больше и больше ну ну , dannyD (?), 11:34 , 19-Июл-26 (19) –3
- Вот поэтому LTS для десктопов не нужны Это тебе не сервер, trolleybus (ok), 11:12 , 19-Июл-26 (10)
Вот поэтому LTS для десктопов не нужны. Это тебе не сервер

- Отказаться от ниши поставляемого оборудования , Аноним (38), 12:05 , 19-Июл-26 (40)
- Если б ещё роллинги нормальные существовали в природе , Аноним (41), 12:05 , 19-Июл-26 (41) +1
- Система должна быть LTS, а софт роллинг, как во всех нормальных ОС Но комьюнити, Dependency hater (?), 14:26 , 19-Июл-26 (85) +1
- Однажды гномеры в смысле разработчики перестанут вести себя как самые последни, Аноним (58), 11:20 , 19-Июл-26 (13) +6 [^]
Однажды гномеры (в смысле разработчики) перестанут вести себя как самые последние проприетарщики с гиперконтролем, но не сегодня.
- В чем проблема разработчика гном-каленадаря пофиксать LTS баги , Аноним (20), 11:36 , 19-Июл-26 (20) +2
В чем проблема разработчика гном-каленадаря пофиксать LTS баги

- Не все баги можно пофиксить в минорном обновлении продукта , warlock66613 (ok), 11:39 , 19-Июл-26 (23) +1
- в том, что для него нет LTS версии, он не выпускает LTS версии, а то, что какие , Аноним (-), 11:46 , 19-Июл-26 (29) –1
- Ну да, гном весь такой из себя, у него нет лтс версии, поэтому обновляйтесь в ра, анони (?), 12:00 , 19-Июл-26 (36) +3
- Немного не так Для него нет никаких версий, кроме текущей версии разработки С е, Аноним (38), 12:07 , 19-Июл-26 (42) +1
- В том, что у GNOME нет такого понятия, как LTS Они выпускают новый стабильный , freehck (ok), 14:39 , 19-Июл-26 (90)
- Разработчики привыкли, что если налажал в коде, но потом в новой версии исправил, warlock66613 (ok), 11:37 , 19-Июл-26 (21) +3
Разработчики привыкли, что если налажал в коде, но потом в новой версии исправил, то всё в порядке и ошибки как бы и не было. Так вот это работает далеко не всегда! Иногда надо сразу делать как следует, а если не сделал, то честно нести ответственность за последствия.

- Вся суть, от GNOME нужно держаться подальше Cinnamon не планируют переводить на, Аноним (35), 11:45 , 19-Июл-26 (27) +10 [^]
Вся суть, от GNOME нужно держаться подальше. Cinnamon не планируют переводить на Qt?

- Получается, что минтовцы по каким-то причинам более склонны к багреплптам на кал, Аноним (17), 12:09 , 19-Июл-26 (43) +3
Получается, что минтовцы по каким-то причинам более склонны к багреплптам на календарь, чем убунтовцы.

- Форкнуть или переписать и в мейнтейнерство X-Apps , Аноним (2), 12:17 , 19-Июл-26 (46) +2
Форкнуть или переписать и в мейнтейнерство X-Apps.
- Ясно, понятно , Аноним (2), 12:20 , 19-Июл-26 (47) +2
>hostile distributions >работает на федоруЯсно, понятно.
- Вот и выросло поколение, которое не умеет багфиксы бекпортировать , Аноним (61), 12:52 , 19-Июл-26 (61)
Вот и выросло поколение, которое не умеет багфиксы бекпортировать.

- Таки бомбануло у чуваков Это ж уже не новость кто в курсе Но, в принципе, , Аноним (34), 13:10 , 19-Июл-26 (64) –2
Таки бомбануло у чуваков :) Это ж уже не новость (кто в курсе). Но, в принципе, их понять можно: проблемы Минта чуваки пытались повесить на разрабов. лол.
- Почитал переписку и статью Разработчик 8212 снежинка, неадекват и лицемер Н, freehck (ok), 14:25 , 19-Июл-26 (83) +2
Почитал переписку и статью. Разработчик — снежинка, неадекват и лицемер. Ну или просто дypaк, не знаю.=== Вот он в своей статье пишет, что очень неправильно тратить время волонтёров, но в то же самое время приходит в багтрекер к мейнтейнерам Mint — точно таким же волонтёрам, поддерживающим пакет с его программой, — и требует от них проделать огромную работу по форку и ребрендингу. Видимо он считает, что его время ценнее времени мейнтейнеров. Однако именно мейнтейнеры делают его софт доступным для миллионов пользователей. Его претензия по сути — это не претензия к Mint, это претензия к самой модели стабильных дистрибутивов с релизным циклом. Разработчик хочет, чтобы пользователи всегда использовали последнюю версию его программы, то есть, по сути, желает дистрибутив с роллинг-релизами. Но цель стабильных дистрибутивов — предоставить, собственно, стабильную и предсказуемую платформу, где ничего не сломается от обновлений. И мейнтейнеры Mint-а в принципе не могут пойти ему навстречу, потому что это так не работает; ибо если мейнтейнеры начнут бездумно обновлять GNOME Calendar до последних мажорных версий, то произойдёт следующее: 1. Обновление может сломать интеграцию программы с остальной системой 2. Новая версия программы может изменить интерфейс и дизориентировать пользователей, привыкших к старому интерфейсу 3. Новая версия программы может привнести новые, более серьёзные баги, которые ещё не были протестированы в контексте всей системы Пользователь, которому "нужно просто работать" выбирает стабильный дистрибутив не просто так, а именно потому, что он предпочитает старый, но знакомый баг, а не тратить время на то, чтобы разобраться, как жить с новым; потому что он не хочет, чтобы при обновлении изменился интерфейс, и ему пришлось бы тратить время на то, чтобы разобраться с новым, в тот момент, когда ему работать надо прямо сейчас; потому что он не хочет, чтобы отвалилась интеграция с каким-то другим софтом, потому что обновление данного — поменяло api-шку / поменяло протокол / изменило формат конфига / ожидает по дефолту сокет в другом месте... === Вопрос, который Hari Rana стоило бы себе задать: а кто собственно виноват в том, что стабильном релизе присутствуют баги? Вот он выпустил 46й релиз GNOME Calendar. Он сам назвал его стабильным релизом. Мейнтейнеры просто взяли его и сказали: "мы берём на себя ответственность за эту конкретную версию на следующие N лет". Если в этой версии есть баги — то уж позвольте, это баги, которые разработчик допустил в релизе, который сам же и назвал стабильным. Дистрибутив сам по себе не добавялет баги. Он просто их консервирует ради предсказуемости. Требовать от мейнтейнеров Mint, чтобы они исправляли ошибки разработчика, выпуская новые мажорные версии — это, по сути, требовать, чтобы они делали работу разработчика. === Таким образом, разработчик ведёт себя эгоцентрично и недальновидно, если не сказать глупо и нагло: 1. Он хочет, чтобы мейнтейнеры взяли на себя все издержки (форк, ребрендинг, перенаправление багов) 2. Он отказывается признать, что пользователи приходят к нему в трекер как раз потому, что они доверяют дистрибутиву 3. Он не предлагает простого и обоюдно удобного решения (своей) проблемы, не пытается договориться о совместной фильтрации багов: он требует радикальных и трудозатратных действий, а когда не получает желаемого — пишет язвительную статью Но стабильные дистрибутивы существуют для пользователей, а не для удобства разработчиков. И они совершенно правильно выбирают стабильность и предсказуемость для своих пользователей, даже если это раздражает одного разработчика из GNOME. === Имхо, Hari Rana глупостями занимается. Как верно сказали в сабжевой Issue, всё, что ему нужно сделать — это шаблон на своём багтрекере завести, где добавить пункты "мой дистрибутив" и "версия программы в дистрибутиве". После этого все баг-репорты о более не поддерживаемых разработчиком версиях из состава дистрибутивов — просто перенаправлять в багтрекеры дистрибутивов, а у себя закрывать. Это вообще-то довольно просто.
- Самоё интересное, я некоторое время назад подбирал себе календарь на Fedora, про, Аноним (99), 14:30 , 19-Июл-26 (87) +1
Самоё интересное, я некоторое время назад подбирал себе календарь на Fedora, пробовал и сабж. Даже самая актуальная версия глючила просто невообразимо. От нежелания показывать изменения после синхронизации до сегфолтов на пустом месте. Это был наверно самый раздражающий календарь из всех что я пробовал. Теперь вот разработчик ходит и поучает других как они должны делать свою работу.
- Но ведь разработчик календаря сам поставил под глюками свою подпись Вот пусть и, Аноним (93), 14:43 , 19-Июл-26 (93) +4
Но ведь разработчик календаря сам поставил под глюками свою подпись. Вот пусть и ловит карму. Хочет обелить карму - может выпустить корректирующую минорную версию, не требующую установку новых библиотек, которых в старом дистрибутиве нет. Думаю, мейнтенер с радостью пойдёт на встречу и будет поставлять обновлённую версию.Но так было принято двадцать лет назад. Сейчас принято нейрослопить новую версию, не совместимую со старым окружением, вместо того чтобы пофиксить старые баги.

- Что можно обновлять в календаре кроме дат Хотя о чём я спрашиваю, когда в линук, Аноним (42), 15:05 , 19-Июл-26 (100)
Что можно обновлять в календаре кроме дат? Хотя о чём я спрашиваю, когда в линукс десятилетиями калькуляторы изобретают.
- А почему разработчики гнома такие как бы мягко сказать непрофессиональные , Аноним (24), 15:46 , 19-Июл-26 (107) +2
> Разработчик GNOME Calendar пояснил, что у него нет времени анализировать измененияА почему разработчики гнома такие... как бы мягко сказать... непрофессиональные. Ведут многомесячный флейм, не разобравшись в проблеме?

- Ты статью прочти сначала, минтовцы тупо дурака включили и все камни в соседний о, HotR (?), 15:59 , 19-Июл-26 (114) –1
- Mint, Gnome Кто этим пользуется Еще Gnome более менее, но Mint, недавно специаль, Аноним (3), 18:13 , 19-Июл-26 (141)
- Это классический дизайн Он востребован 90 пользователей А оставшимся 10 никт, Vladjmir (ok), 07:29 , 20-Июл-26 (192) +1
- Что ж там хипстерского-то такого Cinnamon, KDE, LXQt - там панель, окна и т д ,, Аноним (205), 10:41 , 20-Июл-26 (205)
- Про 90 ты конечно с потолка взял, просто тебе показалось, что эта та цифра кото, Nmmv (?), 22:55 , 20-Июл-26 (237)
- Я работаю в организации и вижу насколько консервативны сотрудники Им нужно рабо, Vladjmir (ok), 09:24 , 21-Июл-26 (247)
- Ой Не надо сказок только Все это твои личные проблемы и взятые с потолка взгля, Nmmv (?), 09:37 , 21-Июл-26 (249)
- Тоже замечал подобное Софт просто должен работать Всем прделагаю простое решен, anonymous (??), 12:45 , 21-Июл-26 (262)
- Они не консервативны, а умеют в экономику, смена интерфейса потеря времени, как , BeLord (ok), 14:12 , 23-Июл-26 (335)
- Опять разработчики каких-то маргинальных недо дистрибутивов маскируют старое д-р, Аноним (121), 16:47 , 19-Июл-26 (121) –2
Опять разработчики каких-то маргинальных недо дистрибутивов маскируют старое д-рмо под современные версии. > приложение поставляется под именем GNOME CalendarПо хорошему на этих удаков надо в суд подать, за обман пользователй и порчу репутации.
- Гунытй мир, под апач указанно что имя - трейдмарк , Аноним (33), 18:11 , 19-Июл-26 (139)
Гунытй мир, под апач указанно что имя - трейдмарк.
- Если никто ещё не посмотрел, GNOME Calendar в Linux Mint отличается от версии в , Аноним (155), 21:27 , 19-Июл-26 (155) +1

- Ровно по этой причине некоторые разработчики отказываются поддерживать чужие сбо, историк_кун (?), 21:37 , 19-Июл-26 (157)
Ровно по этой причине некоторые разработчики отказываются поддерживать чужие сборки в принципе: фиг его знает, как и что там собрано и насколько оно протухшее.В остальном, типичный конфликт между LTSниками и любителями свежака.
- Прекрасно понимаю разработчика Ненавижу псевдо-LTS дистрибутивы, они обновляют , Программист (?), 21:37 , 19-Июл-26 (158)
Прекрасно понимаю разработчика. Ненавижу псевдо-LTS дистрибутивы, они обновляют только базовые компоненты. Весь остальной софт древний и дырявый. Ошибка может быть исправлена несколько лет назад, а там будет кривая версия.

- Алаверды, так-то Неадекватные разрабы, которые считают, что люди вместо решени, Аноним (226), 21:46 , 19-Июл-26 (161)
- А вот разработчик гном-календаря даже не попытался понять , Аноним (24), 00:17 , 20-Июл-26 (180)
- Эти псевдо-LTS построены на другой идее LTS - это только стабильная база, чтобы , Аноним (205), 10:31 , 20-Июл-26 (204) –1
- Скрыто модератором, Аноним (24), 00:15 , 20-Июл-26 (179) +1 [---]
Ещё одна причина не связываться с Гномерами.
- Это вроде не первый раз, когда тухлость Минта вызывает проблемы На него и разра, Beta Version (ok), 02:35 , 20-Июл-26 (181) –3
Это вроде не первый раз, когда тухлость Минта вызывает проблемы. На него и разработчики Месы жаловались: пользователи систематически создают багрепорты на баги, которые давно были исправлены, но в Минте поставляется древняя Меса. И на реддите минтоводы часто создаются темы с жалобами на баги в играх, которые исправляются подключением kisak-ppa, но юзеры же об этом не знают, т.к. закономерно считают, что дистрибутив им поставляет последние версии дров, ведь на сайте Минта нигде не написано, что он протухшее овно мамонта.Сейчас с приходом игровых блидинг эдж дистров стало получше, но поскорее бы уже Минт и подобная ему тухлятина сгинули.

- Гномер сломал всё и разбираться не захотел - а обвинил Минта , Аноним (24), 04:54 , 20-Июл-26 (184) +1
- Свежий Linux Mint 22 х - это Ubuntu 24 04 LTS с некоторыми модификациями, со в, Аноним (155), 08:48 , 20-Июл-26 (198) +1
- Вся проблема из-за отсутствия денег в мире open source подачки на содержание ин, Аноним (199), 08:51 , 20-Июл-26 (199)
- Нэйт тоже высказался по этому поводу https pointieststick com 2026 07 19 whos-, Аноним (185), 05:58 , 20-Июл-26 (185)
- Сделать окно с информированием об использовании устаревшей версии видимо разрабу, Аноним (91), 09:27 , 20-Июл-26 (200)
Сделать окно с информированием об использовании устаревшей версии видимо разрабу ума не хватило, зато хватило высрать полотно... Типичный разраб гнома

- ладно, скажу как есть, потом заминусуют и ладноgnome перестал быть конструктором, Аноним (209), 12:04 , 20-Июл-26 (210) +1
ладно, скажу как есть, потом заминусуют и ладноgnome перестал быть конструктором. не "случайно сломал совместимость", не "не подумал о других де" — перестал специально. это было решение. хватит быть набором деталек из которого каждый собирает свой десктоп мечты, давайте сделаем один продукт, целостный, с нормальными отступами, с адекватной типографикой, чтоб не стыдно было рядом с маком поставить. и знаете что, за пять лет это сработало. gnome сейчас единственный десктоп на линуксе который выглядит как будто его дизайнили, а не выращивали а целостность стоит денег. чтобы приложение выглядело одинаково, оно должно брать виджеты из одного места и не давать никому это переопределять. вот и вся libadwaita. это не заговор против cinnamon, это просто цена того что кнопка везде одна и та же кнопка и вот тут выясняется что минт стоит на фундаменте, который под ним поехал. они же не независимый проект, они форк shell плюс gtk плюс десяток наших приложений. календарь наш. калькулятор наш. просмотрщик наш. они годами брали это бесплатно и правильно делали, для того и открытый код. но когда фундамент решил ехать в другую сторону — оказалось что влиять на него им нечем вообще нечем. вот в чем штука. они могут написать в блог. могут откатить пакет на gtk3. могут форкнуть еще что-нибудь. чего они не могут — прийти в тулкит и что-то там изменить, потому что для этого нужны люди которые пишут код в gtk, а не люди которые собирают дистрибутив. у red hat такие люди есть, у canonical есть, у минта — клем и донаты. позиция без рычага. и когда рычага нет, единственное что остается это замораживать чужой код и надеяться что пронесет не пронесло, само собой. заморозили нас на 3.36 и сидят. а мне прилетает и вот к чему я веду. я не хочу быть их поставщиком. не потому что злой, а потому что этих отношений просто нет — они берут, я поддерживаю, обратной связи ноль, влияния ноль, зато багрепорты в полном объеме. так не работает. если ты завязался на аптрим который открыто сказал куда идет — ты либо идешь туда же, либо идешь своей дорогой и пишешь свой календарь. а вот стоять посередине, взяв мой код и заморозив, и слать мне последствия — нельзя выбирайте уже. вы традиционный десктоп для тех кому надо чтоб как в семерке — отлично, честная ниша, миллион пользователей, уважаю. но тогда это ваш стек, ваш код и ваш багтрекер. а не наш, которому вы приделали свою тему (да, понимаю, звучит как "уходите". примерно так и есть, только без злобы. просто устал притворяться что мы в одной лодке когда лодки давно две)

- ну не хотите принимать баги - не принимайте По факту это ваш код багнутый И исп, anonymous (??), 13:28 , 20-Июл-26 (218)
- Скрыто модератором, Аноним (226), 14:19 , 20-Июл-26 (219) –1 [---]
- Ух, занесло-то Выше уже писали версия та же, что и в Debian Trixie И собрана, Аноним (155), 05:26 , 21-Июл-26 (242)
- Открыл ссылку, увидел автора, закрыл вкладку Не удивился https tesk page 2023, мимо (?), 21:42 , 20-Июл-26 (232)

- Подтверждаю, есть буквально единственное отличие кода программы в репозитории Mi, yurikoles (ok), 08:37 , 21-Июл-26 (243) +2
Подтверждаю, есть буквально единственное отличие кода программы в репозитории Mint от Debian 13 "Trixie".Это проверяется за считанные минуты тремя консольными командами: $ git clone https://salsa.debian.org/gnome-team/gnome-calendar.git debian -b debian/trixie $ git clone https://gitlab.com/linuxmint/pins/mint/gnome-calendar.git mint $ git -C debian --work-tree=../mint diff И мы видим буквально одно изменение — безобидную возможность открытия системных настроек календаря в других основных DE Mint. Судя по тому, что на написание данного комментария у меня ушло больше времени, чем на саму проверку, а разработчик GNOME вместо этого простого действия предпочел раздуть скандал, напрашивается два возможных вывода: 1. Ключевому программисту то ли не хватило желания, то ли помешало ЧСВ провести это элементарное сравнение. Ведь куда эффектнее отчитаться про "несколько часов на анализ аномалий в статистике дистрибутивов в отчётах об ошибках". 2. Сам скандал и попадание в новости были самоцелью, это просто инфоповод для PR. Повестка читается легко: не пользуйтесь протухшими версиями из downstream, а ставьте только последние сертифицированные ванильные версии GNOME из наших шлакпаков. А ещё лучше — сразу свежайшую GNOME OS Nightly.

- прост минтом одним из дистров реально пользуются на десктопах вот оттуда активны, Аноним (279), 13:24 , 21-Июл-26 (279)
прост минтом одним из дистров реально пользуются на десктопах вот оттуда активные пользователи пишут о проблеме, но, незнаючи, не туда. У разраба подгорает, и он создал иллюзию заботы о проблеме, сказав, что нет времени реально что-то там фиксить. А на сратч и статью кстати есть время. Любопытно...

- Всколыхнул этот календарь блогосферу, вон Nate ещё один пост написал https poi, Аноним (327), 06:42 , 22-Июл-26 (328)
- Короткий вывод прямых доказательств, что актуальные патчи Mint в gnome-calendar, Аноним (209), 13:25 , 22-Июл-26 (332)
Короткий вывод: прямых доказательств, что актуальные патчи Mint в gnome-calendar ломают события, повторения или синхронизацию, нет. Но набор пакетов Mint действительно создаёт несколько других проблем: 1. подтверждённая ошибка интеграции Cinnamon с Calendar; 2. хрупкий Mint-патч запуска настроек; 3. использование устаревших, уже не поддерживаемых upstream версий; 4. backend-проблемы в Evolution Data Server, который Flatpak Calendar всё равно получает от хост-системы. ### Что именно патчит Mint В официальном репозитории Mint присутствуют: - Mint 22/22.1: 43.really41+mint2+wilma, то есть фактически GNOME Calendar 41.2 на GTK3; - Mint 22.2/22.3: 46.1-1mint2+zara, уже GTK4/libadwaita; - LMDE 7: 48.1+mint1+gigi. Это видно непосредственно в каталоге исходных пакетов Mint (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/g.../). Я сравнил распакованный 46.1-1mint2+zara с Ubuntu 46.1-0ubuntu2, а 48.1+mint1+gigi — с upstream 48.1. В обоих случаях единственное существенное Mint-изменение в коде Calendar — 29 строк в gcal-utils.c, которые заменяют запуск GNOME Settings: - Online Accounts → gnome-online-accounts-gtk; - Date & Time в Cinnamon → cinnamon-settings calendar; - MATE/XFCE → time-admin. К обработке событий, CalDAV, recurrence, датам событий или EDS этот патч отношения не имеет. Ubuntu-патчи в версии 46 исправляют сохранение звука и состояния напоминаний, то есть также не являются источником рассматриваемых проблем. Исходник пакета: 46.1-1mint2+zara.dsc (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/g...). Сам launcher-патч всё же хрупкий: - он сравнивает XDG_CURRENT_DESKTOP с точными строками и неправильно обработает значения вида ubuntu:GNOME; - пакет Calendar не зависит от gnome-online-accounts-gtk; - ошибка запуска helper’а игнорируется; - для неизвестного рабочего стола функция может просто завершиться, ничего не открыв. Поэтому симптом «пункт настроек ничего не делает» он потенциально создать может. Но не порчу календарных данных. ### Проверка обсуждавшихся багов Баг Результат ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ #300: Online Accounts на Mint 18.3 (https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/300) Реальная старая проблема интеграции Cinnamon. Текущий Mint-патч как раз предназначен для исправления этого класса проблем. ───────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────────────────────────────────────────────────────────────────────────────────────────── #1562: медленная загрузка и неработающие настройки (https://gitlab.gnome.org/GNOME/gnome-calendar/-/ ... Проверялся Calendar 49.1 из Flatpak, то есть без Mint-патча Calendar. Меню не работает потому, что work_items/1562) upstream запускает GNOME Control Center вне GNOME. Задержка холодного старта отнесена к EDS; графические задержки зависели от GPU. ───────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────────────────────────────────────────────────────────────────────────────────────────── #1535: день и месяц поменялись местами (https://gitlab.gnome.org/GNOME/gnome-calendar/-/ ... Подтверждённая ошибка Mint/Cinnamon. Cinnamon запускает gnome-calendar --date и передаёт work_items/1535) gdate.format("%x"). Calendar отдаёт строку locale-зависимому парсеру EDS. При различающихся LC_TIME и LC_MESSAGES 07/01/2026 превращается из 7 января в 1 июля. Проблемная строка по-прежнему находится в eventView.js (https://github.com/linuxmint/cinnamon/blob/master/files/usr/.../ calendar%40cinnamon.org/eventView.js#L732-L738) и была добавлена этим коммитом (https://github.com/ linuxmint/cinnamon/commit/c59e107d3ba24626bbc989a2ff68a03254dec121). ───────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────────────────────────────────────────────────────────────────────────────────────────── #1526: RANGE=THISANDFUTURE (https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1526) Evolution 3.58 Flatpak тоже воспроизводил неверный результат, потому наиболее вероятная общая причина — хостовый EDS. Старый Calendar 41 дополнительно ухудшал отображение, но причинность Mint-патча не подтверждена. ───────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────────────────────────────────────────────────────────────────────────────────────────── #1429: “1 day” в напоминании (https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1429) Окно принадлежало evolution-alarm-notify, а “1 day” обозначало продолжительность события, не число оставшихся дней. Это не баг GNOME Calendar. Особенно существенен случай Mint 22/22.1: Mint намеренно оставил Calendar 41.2 и портировал его на новые libsoup3, GWeather4 и EDS из Ubuntu 24.04. Большинство таких изменений являются upstream cherry-pick’ами, но итоговая комбинация «интерфейс 2021 года + backend 2024 года» upstream не поддерживается. На июль 2026 года GNOME поддерживает ветки Calendar 50 и 49; версии 48, 46 и тем более 41 уже EOL согласно официальному календарю релизов GNOME (https://release.gnome.org/calendar/). Это справедливая часть критики Mint: старые ошибки не получают upstream-исправлений. Но само по себе это не доказывает, что Mint-патчи породили эти ошибки. ### Про libAdapta Утверждение из публикации Hari Rana (https://tesk.page/2026/07/18/how-far-would-hostile-distribut.../) о том, что Calendar переведён на libAdapta, технически неверно для текущих пакетов. Mint 22.2/22.3 Calendar зависит от libadwaita-1-0, а LMDE 7 — также от libadwaita. Mint действительно патчит саму libadwaita, добавляя загрузку CSS системной темы и поддержку Mint-акцентов. Это может вызывать визуальные или layout-регрессии, но связи с CalDAV, повторениями и синхронизацией событий я не нашёл. Пакеты можно проверить в репозитории Mint libadwaita (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/l.../). ### Итоговый вердикт - Mint-патч непосредственно в текущем GNOME Calendar: не является причиной известных ошибок с событиями. - Cinnamon-интеграция: содержит как минимум один подтверждённый баг с передачей даты. - Launcher настроек: потенциально может приводить к «ничего не происходит». - Старые версии Calendar: реальная проблема поддержки, особенно 41.2 в Mint 22/22.1. - CalDAV/медленная холодная загрузка: вероятнее EDS из базовой Ubuntu, а не Mint-патч Calendar. - Обвинение про libAdapta: не соответствует зависимостям актуального пакета. Для проверки конкретной установки достаточно прислать вывод: gnome-calendar --version apt policy gnome-calendar evolution-data-server libadwaita-1-0 \ gnome-online-accounts gnome-online-accounts-gtk cinnamon flatpak info org.gnome.Calendar 2>/dev/null printf 'XDG_CURRENT_DESKTOP=%s\n' "$XDG_CURRENT_DESKTOP" locale | grep -E '^(LANG|LANGUAGE|LC_TIME|LC_MESSAGES)='
- Да Если перемотать к сентябрю 8211 октябрю 2025 года, позиция разработчика GNO, Аноним (209), 13:42 , 22-Июл-26 (333)
Да. Если перемотать к сентябрю–октябрю 2025 года, позиция разработчика GNOME выглядит заметно сильнее — но всё равно не потому, что Mint внёс патч, ломающий обработку событий. ### Что было доступно тогда Исходный тикет Mint был открыт 26 сентября 2025 года (https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work...). Система на тот момент GNOME Calendar ━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Mint 22 Wilma фактически 41.2 ─────────────────────── ──────────────────────────────────────── Mint 22.1 Xia фактически 41.2 ─────────────────────── ──────────────────────────────────────── Mint 22.2 Zara 46.1 ─────────────────────── ──────────────────────────────────────── LMDE 6 Faye фактически 41.2 ─────────────────────── ──────────────────────────────────────── LMDE 7 Gigi ещё не выпущена; позднее получила 48.1 Mint 22.2 вышел 4 сентября 2025 года (https://blog.linuxmint.com/?p=4881), а LMDE 7 — только 14 октября 2025 года (https://blog.linuxmint.com/?p=4924). Поэтому в момент открытия тикета аргумент «мы поставляем Calendar 46 из Ubuntu и 48 из Debian 13» был лишь частично применим: - Calendar 46 действительно уже был в свежем Mint 22.2; - пакет 48 уже лежал в git Mint с 10 сентября, но публичная LMDE 7 ещё не вышла; - поддерживаемые Mint 22, 22.1 и LMDE 6 продолжали поставлять 41.2. Причём Mint официально считает 22, 22.1 и 22.2 поддерживаемыми до апреля 2029 года — обновление между point-релизами не происходит само по себе. Это подтверждает таблица поддержки Mint (https://linuxmint-user-guide.readthedocs.io/en/latest/upgrad...). Поэтому поздняя формулировка «в поддерживаемых ветках у нас только Ubuntu 46 и Debian 48» как минимум неполна. ### Что действительно было «наворочено» в Calendar 41 Пакет имел замаскированную версию: 43.really41+mint2+wilma То есть Mint сознательно оставил Calendar 41.2, хотя базовая Ubuntu 24.04 уже поставляла Calendar 46. Исходник доступен как 43.really41+mint2+wilma (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/g...). Это был существенно более крупный downstream-форк, чем современный пакет: - старый GTK3/libhandy-интерфейс; - порт на libsoup3; - порт на GWeather4; - удаление старой зависимости geocode-glib; - адаптация к более новому EDS; - собственный запуск Online Accounts; - исправление преобразования месяца struct tm → GDateTime. Порты на libsoup3/GWeather4 были взяты из более поздней истории upstream GNOME и приспособлены к ветке 41. Они затрагивали в том числе: - обнаружение CalDAV-источников; - создание и редактирование календарей; - HTTP-запросы; - event popover; - weather service. Это уже реальная зона риска. Не «злонамеренный патч», но поддерживаемая Mint комбинация старого приложения с библиотеками на несколько поколений новее. При этом я не нашёл в этих изменениях патча, который непосредственно меняет recurrence expansion, чтение событий из EDS или обработку RANGE=THISANDFUTURE. Поэтому конкретный CalDAV-баг всё ещё логичнее связывать с EDS и старым frontend, а не с уникальным алгоритмом Mint. ### Что было в свежем Mint 22.2 К выпуску Zara ситуация уже изменилась. В июле–августе 2025 года Mint импортировал Ubuntu Calendar 46.1 и добавил только launcher-патч: - gnome-online-accounts-gtk; - cinnamon-settings calendar; - поддержка MATE/XFCE. История видна в репозитории Mint Calendar (https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/comm...), а пакет — 46.1-1mint2+zara (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/g...). Следовательно, в Zara уже не было скрытого большого форка Calendar, который затем незаметно убрали. На момент тикета пакет 46 выглядел практически так же, как сегодня. ### Другие Mint-патчи того периода Весной–летом 2025 года Mint действительно довольно сильно модифицировал libadwaita: - загрузка CSS текущей системной темы; - отслеживание имени темы через portal/GSettings; - определение dark/light-варианта по имени темы. Это влияет на все libadwaita-приложения и теоретически способно создавать визуальные проблемы, неверные размеры или ошибки при смене темы. В патче даже есть небольшая утечка строки при смене темы. Но на загрузку и семантику календарных событий он не влияет. Пакеты находятся в репозитории Mint libadwaita (https://mirror.ourhost.az/linuxmint-packages/pool/upstream/l.../). Также уже существовал подтверждённый Cinnamon-баг: applet передавал выбранную дату как локализованный %x. Эта строка находилась в коде с 2021 года и присутствовала в октябре 2025-го — проблемный запуск Calendar (https://github.com/linuxmint/cinnamon/blob/master/files/usr/...). Именно он вызывает инверсию дня и месяца при смешанных locales. ### Скорректированный вердикт - Mint 22.2 Zara на момент тикета: прямых проблемных патчей в логике Calendar не видно. - Mint 22/22.1 и LMDE 6: да, это был заметно модифицированный Calendar 41.2, искусственно удерживаемый на старой архитектуре. Здесь критика GNOME обоснованнее. - Каких-то особенно плохих патчей, которые Mint позже тихо удалил: не обнаружено. - Главная проблема того периода: не конкретный сломанный Mint-патч, а поддержка старой ветки 41 и её портирование на новые библиотеки. - Подтверждённая непосредственно Mint-ошибка: передача даты из Cinnamon через %x. - Аргумент Mint про 46/48: верен для тогдашних новейших Zara/Gigi, но задним числом скрывает тот факт, что несколько официально поддерживаемых выпусков продолжали поставлять 41.2.
- В этом вся суть минта, надо все форкнуть и забить на апстрим, Анонимомус (?), 17:48 , 22-Июл-26 (334)
В этом вся суть минта, надо все форкнуть и забить на апстрим
- Как по мне LTS дистрибутив должен иметь LTS версии софта, а не просто заморозили, BeLord (ok), 14:17 , 23-Июл-26 (336)
Как по мне LTS дистрибутив должен иметь LTS версии софта, а не просто заморозились, иначе это манипуляция. Будь у этого календаря LTS версия, конфликта бы не было и пользователи не имели проблем.
|