а на 32 можно обновляться уже? а то помню были какие-то вещи, из-за которых не рекомендовалось...

Btrfs at Facebook https://lwn.net/SubscriberLink/824855/30c689f442d0033c/

из приватной дискуссии от того человека, который раньше предлагал подождать и потестить btfs подольше: Full disk issues (despite free disk space) with ext4+lvm: likely (based on having hit this myself multiple times and multiple reports in the discussion) Corruption of individual files: unlikely (It seems internal drive crc is effective in catching those kinds of small-scale corruptions. There don't seem to be many reports despite lack of fs-level checksumming.) Loss of individual files: unlikely Loss of big chunk of the filesystem with ext4+lvm: very unlikely (I'm limiting this to data loss because of file system corruption. A disk dying is something else.) Full disk issues (primarily metadata space exhaustion) with btrfs: unlikely This has become much better over the last few years, I don't think this is an important worry. Corruption of individual files: none Loss of individual files: unlikely Loss of big chunk of the filesystem with btrfs: unlikely, but possible. And that last one is the big unknown. For the sake of discussion, let's say it happens 1e-5 / machine / year. This might still result in a handful of cases over all Fedora users. If we stagger the introduction of the new default, we might get half or one-third of such cases. And btrfs might be improved upstream in response to our reports, so we'd not just be delaying such failures, but reducing the total number of occurrences. After writing this out, I'm starting to think that we should just switch the default, period. Some people will follow the default, others will pick a different layout, and staggering will occur naturally.

Lvm классический или с thinpool? Между ними довольно существенная разница, в т.ч. в надежности.

а на 32 можно обновляться уже? а то помню были какие-то вещи, из-за которых не рекомендовалось...

классический, конечно же

Тогда сравнение не очень корректное, т.к. и набор фич существенно отличается.

lvm thin не очень подходит для обычного юзера

Почему?

потому что расширять вольюмы надо руками

Меня, кстати, тоже интересует. Как минимум, я помню, что после релиза высплывали массовые проблемы с крешами софта из-за бага в gcc, которым 32-ой релиз был собран.

Ты про то, что флаг -r у lvresize не работает?

нет, я про то что когда у пользователя заканчивается место - нужно ему что-то делать - вручную запукать какую-то команду

Меня, кстати, тоже интересует. Как минимум, я помню, что после релиза высплывали массовые проблемы с крешами софта из-за бага в gcc, которым 32-ой релиз был собран.

FIXED. REBUIT.

Ну так с обычным lvm всё точно так же обстоит

одна из проблем которую нужно решить - разделение /, /home. потому что у многих с флэтпаками заканчивается место на /, но не на /home

Ну так в этом случае thinpool наоборот для юзера удобнее, чем классический лвм

нет, что то не подходит, что другое. thinpool в целом лучше при этой проблеме, но то что пользователь сам должен расширять тома - это no-go

Тогда я не вижу, как с этой проблемой справляется лучше классический лвм

есть эксперты по getopt?

это который man 3 getopt? или утилита?

есть эксперты по getopt?

Ты про шелльный или про глибцешный?

нужно сделать чтобы можно было передавать любы параметры .. т.е. если -X foo передаётся, а в optstring не было :X:, то он бы всё равно принял этот аргумент

нужно сделать чтобы можно было передавать любы параметры .. т.е. если -X foo передаётся, а в optstring не было :X:, то он бы всё равно принял этот аргумент

А в чем в таком случае будет заключаться работа getopt?

опишу юзкейс, в RPM у макросов можно делать аргументы. соотв-но если есть unknown option, то rpm отказывается из принимать. хочу модифицировать таким обраном, чтобы мжно было указать что в целом все опции подходят

А что тогда с этими опциями должен будет делать макрос?

@ignatenkobrain If the caller has set the global variable opterr to zero, then getopt() does not print an error message. не оно?

https://rpm.org/user_doc/macros.html

Вообще, ман говорит вот это If getopt() does not recognize an option character, it prints an error message to stderr, stores the character in optopt, and returns '?'. The calling program may prevent the error message by setting opterr to 0.

opterr=0 это отключает

У меня про это же и написано

https://github.com/rpm-software-management/rpm/blob/master/rpmio/macro.c#L963-L988

да, поэтому хочу сделать так, чтобы не просто всё время передавать всевозможные опции, а сделать это каким-то параметром

Я бы, как пользователь rpmbuild, хотел бы видеть ошибки, связанные с определением флагов, которые я допустил, а не получать имплицитно данные, которые не удалось разобрать, внутрь argv

Я бы, как пользователь rpmbuild, хотел бы видеть ошибки, связанные с определением флагов, которые я допустил, а не получать имплицитно данные, которые не удалось разобрать, внутрь argv

всё, что передаётся в %ctest - хочется присунуть внутри в %__ctest

cd "%{__cmake_builddir}" %__ctest --output-on-failure --force-new-ctest-process %{?_smp_mflags} %{**} cd -

/usr/bin/ctest --output-on-failure --force-new-ctest-process -j8 -- -j1

должно быть ctest -j8 -j1, а не ctest -j8 -- -j1

вообще идеально было бы всё же запилить без --, потому что %make_build -j8 работает, а %ctest -j8 нет