Requests are one of the staples for collaboration in the OBS. You can review via the webui or with OSC.

WebUI

Lets take the request listing for openSUSE:Factory. Your normal workflow will probably end up as

1. middle mouse click on the little magnifying glass icon on the right.
2. review the request in a new tab
3. close the new tab
4. go back step 1

My issues with the WebUI

1. no advancing to the next request in my current list.
2. I have to manually unfold/fold many diff chunks for a proper review.
3. In the latest version of the WebUI: “We truncated the diff of some files because they were too big. If you want to see the full diff for every file, click here.” But even then I have to unfold every change myself again.

OSC - The normal way

1. one terminal: osc rq list -t submit -s new openSUSE:Factory
2. 2nd terminal: osc rq show -d ID - the ID is taken from the first listing.
3. 2nd or in worst case 3rd terminal: osc rq youraction ID
4. go back to step 2

My issues

1. all manually copy pasting of IDs

OSC interactive mode

My config:

Today I ported gnome-class from version 0.11 of the syn crate to version 0.12. syn is a somewhat esoteric crate that you use to parse Rust code... from a stream of tokens... from within the implementation of a procedural macro. Gnome-class implements a mini-language inside your own Rust code, and so it needs to parse Rust!

The API of syn has changed a lot, which is kind of a pain in the ass — but the new API seems on the road to stabilization, and is nicer indeed.

Here is a quick list of things I had to change in gnome-class to upgrade its version of syn.

There is no extern crate synom anymore. You can use syn::synom now.

extern crate synom;    ->   use syn::synom;

SynomBuffer is now TokenBuffer:

synom::SynomBuffer  ->  syn::buffer:TokenBuffer

PResult, the result of Synom::parse(), now has the tuple's arguments reversed:

- pub type PResult<'a, O> = Result<(Cursor<'a>, O), ParseError>;
+ pub type PResult<'a, O> = Result<(O, Cursor<'a>), ParseError>;

// therefore:

impl Synom for MyThing { ... }

let x = MyThing::parse(...).unwrap().1;   ->  let x = MyThing::parse(...).unwrap().0;

The language tokens like synom::tokens::Amp, and keywords like synom::tokens::Type, are easier to use now. There is a Token! macro which you can use in type definitions, instead of having to remember the particular name of each token type:

synom::tokens::Amp  ->  Token!(&)

synom::tokens::For  ->  Token!(for)

And for the corresponding values when matching:

syn!(tokens::Colon)  ->  punct!(:)

syn!(tokens::Type)   ->  keyword!(type)

And to instantiate them for quoting/spanning:

-     tokens::Comma::default().to_tokens(tokens);
+     Token!(,)([Span::def_site()]).to_tokens(tokens);

(OK, that one wasn't nicer after all.)

To the get string for an Ident:

ident.sym.as_str()  ->  ident.as_ref()

There is no Delimited anymore; instead there is a Punctuated struct. My diff has this:

-  inputs: parens!(call!(Delimited::<MyThing, tokens::Comma>::parse_terminated)) >>
+  inputs: parens!(syn!(Punctuated<MyThing, Token!(,)>)) >>

There is no syn::Mutability anymore; now it's an Option<token>, so basically

syn::Mutability  ->  Option<Token![mut]>

which I guess lets you refer to the span of the original mut token if you need.

Some things changed names:

TypeTup { tys, .. }  ->  TypeTuple { elems, .. }

PatIdent {                          ->  PatIdent {
    mode: BindingMode(Mutability)           by_ref: Option<Token!(ref)>,
                                            mutability: Option<Token![mut]>,
    ident: Ident,                           ident: Ident,
    subpat: ...,                            subpat: Option<(Token![@], Box<Pat>)>,
    at_token: ...,                      }
}

TypeParen.ty  ->  TypeParen.elem   (and others like this, too)

(I don't know everything that changed names; gnome-class doesn't use all the syn types yet; these are just the ones I've run into.)

This new syn is much better at acknowledging the fine points of macro hygiene. The examples directory is particularly instructive; it shows how to properly span generated code vs. original code, so compiler error messages are nice. I need to write something about macro hygiene at some point.

Powerslidin’ Sunday from jimmac on Vimeo.

Superb weather over the weekend, despite the thermometer dipping below 10°C.

Adapted from announcement to opensuse-factory mailing list:

Following up on my prior announcement of Tumbleweed Snapshots, introducing a snapshot review site. By utilizing a variety of sources of feedback pertaining to snapshots a stability score is estimated. The goal is to err on the side of caution and to allow users to avoid troublesome releases. Obviously, there are many enthusiasts who enjoy encountering issues and working to resolve them, but others are looking for a relatively stable experience.

Releases with a low score will continue to impact future release scores with a gradual trail-off. Given that issues generally are not fixed immediately in the next release this assumes the next few releases may still be affected. If the issue persists and is severe it will likely be mentioned again in the mailing list and the score again reduced.

Major system components that are either release candidates or low minor releases are also considered to be risky. For example, recent Mesa release candidates caused white/black screens for many users which is not-trivial to recover from for less-technical users. Such issues come around from time to time since openQA will not catch everything.

Release stability is considered to be pending for the first week after release to allow time for reports to surface. This of course depends on enthusiasts who update often, encounter, and report problems.

The scoring is likely to be tweaked over time to reflect observations. It may also make sense to add a manual override feature to aid scoring when something critical is encountered.

Integrating the scoring data into the tumbleweed-cli would allow users to pick a minimum stability level or score and only update to those releases. Such a mechanism can be vital for systems run by family members, servers, or the wave of gamers looking for the latest OSS graphics stack.

For more details see the code behind the site. Currently, you can see the very low scores for the releases laden with shader cache issues and those therafter. This is the first iteration of the site so nothing too fancy and the score is fairly basic.

The site also provides a machine readable (YAML) version of the data.

As a side-node, Tumbleweed Snapshots are limited to 50 snapshots due to a hosting restriction, but that should generally be over two months worth.

Hopefully others find this useful, enjoy!

Jordan Petridis has been kicking ass by overhauling librsvg's continous integration (CI) pipeline. Take a look at this beauty:

On every push, we run the Test stage. This is a quick compilation on a Fedora container that runs "make check" and ensures that the test suite passes.

We have a Lint stage which can be run manually. This runs cargo clippy to get Rust lints (check the style of Rust idioms), and cargo fmt to check indentation and code style and such.

We have a Distro_test stage which I think will be scheduled weekly, using Gitlab's Schedules feature, to check that the tests pass on three major Linux distros. Recently we had trouble with different rendering due to differences in Freetype versions, which broke the tests (ahem, likely because I hadn't updated my Freetype in a while and distros were already using a newer one); these distro tests are intended to catch that.

Finally, we have a Rustc_test stage. The various crates that librsvg depends on have different minimum versions for the Rust compiler. These tests are intended to show when updating a dependency changes the minimum Rust version on which librsvg would compile. We don't have a policy yet for "how far from $newest" we should always work on, and it would be good to get input from distros on this. I think these Rust tests will be scheduled weekly as well.

Jordan has been experimenting with the pipeline's stages and the distro-specific idiosyncrasies for each build. This pipeline depends on some custom-built container images that already have librsvg's dependencies installed. These images are built weekly in gitlab.com, so every week gitlab.gnome.org gets fresh images for librsvg's CI pipelines. Once image registries are enabled in gitlab.gnome.org, we should be able to regenerate the container images locally without depending on an external service.

With the pre-built images, and caching of Rust artifacts, Jordan was able to reduce the time for the "test on every commit" builds from around 20 minutes, to little under 4 minutes in the current iteration. This will get even faster if the builds start using ccache and parallel builds from GNU make.

Currently we have a problem in that tests are failing on 32-bit builds, and haven't had a chance to investigate the root cause. Hopefully we can add 32-bit jobs to the CI pipeline to catch this breakage as soon as possible.

Having all these container images built for the CI infrastructure also means that it will be easy for people to set up a development environment for librsvg, even though we have better instructions now thanks to Jordan. I haven't investigated setting up a Flatpak-based environment; this would be nice to have as well.

Самый разгар тестирования следующей major-версии openSUSE – Leap 15.0. Beta доступна уже без малого месяц. Как и обычно, качество системы зависит от нас с вами, друзья. Для тех, кто никогда не принимал участия в разработке openSUSE, но хотел бы наконец-то помочь, самое время скачать Leap 15.0, установить и погонять его по самые не балуй на своей машине (хотя бы виртуальной) или машине своего коллеги Помните, что beta-версия нестабильна и может сломаться в самом непредсказуемом месте.
О всех найденных ошибках надо сообщить нам в bugzilla.

Важно понимать, что система разрабатывается силами сообщества, и ее качество в большей мере зависит он нас с вами. Ошибается тот, кто думает, что в Нюрнберге все и так сделают как надо и даже лучше. Там ребята работают главным образом над SLE – тем, что приносит SUSE деньги. Дистрибутив openSUSE отдан сообществу: энтузиастам, дизайнерам, программистам… и простым пользователям. У нас есть права менять его как мы захотим. Более того – от нас этого ожидают. Не будем же делать вид, что это не так.

Итак, что мы имеем на сейчашний момент? На момент написания этого поста актуальным является build139. Второй и третьей официальной beta, как это было когда-то, не будет. Теперь beta меняется по принципу rolling release. Уже где-то через месяц, в апреле/мае, мы перейдем на фазу release candidate. Было бы здорово найти как можно больше и начать работать над исправлениями ДО начала этой фазы.
Так как следующий Leap получится мажором, поддерживаться он будет не 12 (в отличии от минорных релизов, привязанных к SUSE Linux Enterprise Service Packs), а 36 месяцев.

Так что же собственно тестировать? Для каждого из нас есть свои use cases. Кто-то админит самый обычный web- и mail-сервер, кто-то не может представить свою жизнь без какой-то хитроумной конфигурации Kerberos, кто-то в Leap видит исключительно desktop-систему и захочет посмотреть на сколько стабильна в ней работает Plasma 5.12 LTS. Я, к примеру, планирую протестировать sddm c PAM, а так же freeradius сервер со своим 802.1x L3-свитчем. Также будет интересно посмотреть, получится ли обновить свой Leap до нового Leap 15.0.
Кстати, в Leap 15.0 используется новый rpm из Tumbleweed – версии 4.14.1 (с целым вагоном и маленькой тялежкой SUSE-патчей). Возможно там получится что-то найти.

Я оставлю ссылку на эту таблицу. Туда вы можете добавить себя и добавить комментарий, если что-то сломано и не заработало (если заработало, тоже можете оставить комментарий). Помните только, что если что-то не заработало, и вы написали там об этом, мы будем ожидать, что вы откроете report в bugzilla, где и будет проходить дальнейшее обсуждение проблемы.
Возможно вам будет также интересно узнать о состоянии автотестирования.

Актуальное состояние пакетной базы Leap 15.0 можно посмотреть вот тут.
Там же есть ссылка на изменения, которые ожидают Leap 15.0.

Если у вас возникли вопросы, я всегда буду рад помочь вам. Оставляйте комментарии или просто пишите на alexander_naumov @openSUSE.org. Меня так же можно найти на freenode IRC-сервере. Мой ник там – anaumov. Удачи!

package lists generator drop list considers update repos

Following up on the addition of a drop list generator the code now considers update repositories. The released repositories, oss and non-oss, are merged with their update counterparts. This provides a more accurate drop list that should provide for a cleaner post-upgrade system. For an idea of the impact take a look at the diff on OBS after the change was deployed.

There is an ongoing discussion regarding where to store the solv files since they cannot be re-created for releases that are out of support and removed from download.opensuse.org.

Leap 15.0 repo-checker no longer reviews i586

The repo-checker was changed to only review the x86_64 repo, which includes imported i586 pacakges, rather than reviewing both repos in their entirety. Unlike Tumbleweed, Leap does not target i586 as an installable arch, but rather just for providing -32bit packages. Devel packages receiving repo-checker comments regarding i586 dependency chains should desist.

metrics.o.o weekly data ingest enabled

In lieu of OBS providing control over request order via API the data ingest process has been configured to run weekly, instead of daily. The service timer has been enabled and should ingest data regularly.

Tumbleweed snapshot review site

Extensive work was completed towards providing a site for reviewing Tumbleweed snapshot stability by aggregating data from a variety of sources. The goal is to provide insight into the stability trends of Tumbleweed and aid in avoiding troublesome snapshots when desired. More details to be forthcoming.

last year

factory-auto bot was corrected to properly warn when issue references were removed as the diff was backwards and to allow for self-submission for the purpose of reverting a package to a prior version of self.

The osc-staging plugin was enhanced to provide link in staging comment to project dashboard to aid in discovery and some ever important documentation corrections.

The ReviewBot base was significantly refactored to avoid duplication and over complexity in subsequent bots.

• #684: ReviewBot: refactor leaper comment from log functionality.
• #685: ReviewBot: use super().check_source_submission() in subclasses.
• #692: ReviewBot: extract __class__.__name__ as default for self.bot_name.
• #693: ReviewBot & leaper: provide deduplicate method for leaper comment (and other fixes)

In another attempt to aid in feature discovery the leaper bot was changed to let request submitters know when the request would have been automatically generated. On a similar note the staging unselect command was tweaked to print a message suggesting use of new ignore psuedo-sate.

Significant work was done towards providing completely automated staging strategies via the addition of --non-interactive, --merge, --try-strategies, and --strategies options. The prototype was run against Leap 42.3 and scrutinized to hone the strategies. A related tool was prototyped for triggering flaky package rebuilds in staging projects.

For SUSE Hackweek 15 I worked on what eventually turned into metrics.opensuse.org. The focus was on selecting the appropriate tools and determining what to use as the data source. After the OBS team denied request to get read access of data dumps of request related tables I settled on ingesting the data (over 800MB of XML) via the API.

I have started an RFC to integrate rsvg-rs into librsvg. rsvg-rs is the Rust binding to librsvg. Like the gtk-rs bindings, it gets generated from a pre-built GIR file.

It would be nice for librsvg to provide the Rust binding by itself, so that librsvg's own internal tools can be implemented in Rust — currently all the tests are done in C, as are the rsvg-convert(1) and rsvg-view-3(1) programs.

There are some implications for how rsvg-rs would get built then. For librsvg's internal consumption, the binding can be built from the Rsvg-2.0.gir file that gets built out of the main librsvg.so. But for public consumption of rsvg-rs, when it is being used as a normal crate and built by Cargo, that Rsvg-2.0.gir needs to be already built and available: it wouldn't be appropriate for Cargo to build librsvg and the .gir file itself.

If this sort of thing interests you, take a look at the RFC!