devel-announce July 2017

devel-announce@lists.fedoraproject.org

7 participants
31 discussions

F27 System Wide Change: Reduce Initial Setup Redundancy
by Jaroslav Reznik 07 Jul '17

07 Jul '17

= System Wide Change: Reduce Initial Setup Redundancy = https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy Change owner(s): * Michael Catanzaro <mcatanzaro(a)gnome.org> Currently there is a high level of redundancy between the Anaconda installer and gnome-initial-setup. This change aims to eliminate these redundancies and streamline the initial user experience in Fedora Workstation. == Detailed Description == Firstly, please note that the effects of this change will be restricted to Fedora Workstation. We do not propose any changes that affect alternative Fedora installers (e.g. Calamares) or initial setup tools (e.g. the initial-setup package, not to be confused with gnome-initial-setup). A few years ago, Fedora Workstation developers discussed with Anaconda developers the redundancy between many Anaconda settings and gnome-initial-setup. The Anaconda developers responded by added a configuration file mechanism, /etc/sysconfig/anaconda, which can be used to suppress Anaconda spokes if written before Anaconda runs. This file is also written by Anaconda to tell the initial-setup tool which Anaconda spokes the user has visited, so that the initial-setup tool can suppress specific spokes. Although this functionality has existed for some time now, the Workstation developers until now failed to follow up and begin using it. We now intend to make use of this functionality to suppress Anaconda spokes that are redundant with gnome-initial-setup. Meanwhile, our friends at Endless OS have added a similar configuration file for gnome-initial-setup that allows us to suppress some configuration that is best handled in Anaconda. Below, we discuss what we plan to do with specific settings. Language and Keyboard Layout Although we do not propose it at this time, language and keyboard layout selection should be presented to the user *before* entering the live session, as it is currently too difficult for users to change these settings unless they are already familiar with Fedora, and -- unless you speak English and use a US keyboard -- these settings must be changed for the live session to be usable. Both Anaconda and gnome-initial-setup are too late for configuring these settings. (An exception would be for netinstalls of Fedora Workstation, where Anaconda is the best place for this configuration.) In the meantime, until we have a way to prompt users for these settings earlier than Anaconda, these panels should be removed from gnome-initial-setup, because Anaconda is clearly a better place than gnome-initial-setup for this configuration. (This would affect gnome-initial-setup when creating the first user account. Additional user accounts created later would still receive these panels in gnome-initial-setup.) Time and Date We want to remove the time and date spoke from Anaconda, since it is largely redundant with the timezone page in gnome-initial-setup. However, it might be necessary to remove this page from gnome-initial-setup instead, as previously there have been technical concerns raised regarding the necessity of configuring the system clock before running the installer. This choice will be based on technical feedback from the Fedora developer community. Network We will remove the network configuration spoke from Anaconda. Currently this spoke only allows configuring the system hostname, but it places restrictions on the possible characters in the hostname that do not match the restrictions used by Fedora Workstation. Fedora Workstation uses systemd-hostnamed to allow "pretty" hostnames with Unicode characters and spaces, which we expect to be displayed properly and consistently in the user interface, but the Anaconda configuration does not follow this pattern. Additionally, exposing the hostname as network configuration is confusing. We may consider adding a simpler "Computer Name" setting that allows "pretty" characters and is not presented as a networking setting in the future, but it does not seem necessary to prompt the user to set a hostname at all. Note: this applies only to USB install, obviously not to netinstall. We will need some way to differentiate between the two when writing the Anaconda configuration file. User Account Currently, users have the option of creating the initial user account in Anaconda, or not. Anaconda does not require this if the user sets a root password. Users who do not create a user account in Anaconda are required to create a user account later, by gnome-initial-setup. This means we currently have two different ways of creating the first user account in Workstation, with (potentially) two different sets of bugs. Since Anaconda allows configuring whether the initial user is added to the wheel group, it also means some initial users will be in wheel and others will not. We will remove the user account creation spoke in Anaconda. All users will create the first user account using gnome-initial-setup, and all initial users will be added to the wheel group. Of course, this can be easily changed after installation if desired. Root Account Currently, users have the option of setting a root password in Anaconda, or not. Anaconda does not require this if the user creates an initial user account and selects the option to add it to the wheel group. We will remove the root password creation spoke. All Workstation installs will have no root password set by default, as in Ubuntu. Having a root password is not useful for nontechnical users, and it is confusing to ask users to create multiple passwords. Because the initial user created by gnome-initial-setup will be added to the wheel group, all administrative functions will continue to be available within the desktop environment via Polkit. Additionally, the initial user will have sudo access to run commands as root. Of course, a root password can be set after installation using `sudo passwd`. == Scope == * Proposal owners: Provide a default /etc/config/anaconda file for Fedora Workstation. This could be e.g. shipped in the gnome-initial-setup package or written by the firstboot tool before Anaconda runs. * Other developers: Anaconda developers to review UI. QA team to review installation tests. * Release engineering: [1] * List of deliverables: No changes needed * Policies and guidelines: No changes needed * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6878 Thanks, Jaroslav

1 0

F27 System Wide Change: RPM 4.14
by Jaroslav Reznik 07 Jul '17

07 Jul '17

= System Wide Change: RPM 4.14 = https://fedoraproject.org/wiki/Changes/RPM-4.14 Change owner(s): * Igor Gnatenko <ignatenkobrain(a)fedoraproject.org> * Florian Festi <ffesti(a)redhat.com> * Panu Matilainen <pmatilai(a)redhat.com> Update RPM to the upcoming 4.14 release. == Detailed Description == RPM 4.14 contains several improvements that needs to get released and integrated in Fedora: * Major macro engine bug fix + sanity work: ** Macro scope simplification + enforcing ** Macro arguments expanded ** Nested lua macro scoping fixes ** Improved error reporting * Major header/package/signature rewrite: ** Unified code path for all header read/import ** Major hardening work on header parsing ** Unified code path for all header/package signature checking ** Signature checking before header imports ** Support for multiple signatures per package ** Support for configurable signature policies * Major debuginfo rewrite (covered by two other changes and already applied in F27) * Signal handling rewrite: ** Custom signal handlers while rpmdb open ** Signals blocked throughout write transactions * SSD conservation mode * Improved support for reproducible builds * RPMCALLBACK_ELEM_PROGRESS now carries index of header * Support for OpenSSL as a one of crypto libraries used for digests/signatures (already part of F27) * Support for rich dependencies coming out from dependency generators * %include can contain paths with whitespaces * Dependency generator for pkg-config files doesn't check dependencies in .pc recursively, but rather print top-level ones (if pkgconf is used) * Header digests use SHA256 by default * Improvements in Python dependency generator * Improvements and stabilization of "ndb" * Support for "with" rich-operator: ** Specifying version range dependencies ** Specifying packages which provide special ability == Scope == * Proposal owners: Rebase RPM * Other developers: Test new release, report issues and bugs, fix bugs in packaging (if it is not bug in RPM, should be detected during Mass Rebuild) * Release engineering: [1] (a check of an impact with Release Engineering is needed) * List of deliverables: Change affects whole distribution rather than deliverables * Policies and guidelines: FPC should look (and possibly approve) "with" rich dependency in Packaging Guidelines * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6875 Thanks, Jaroslav

1 0

Fedora 26 status is GO, release on July 11, 2017
by Jaroslav Reznik 06 Jul '17

06 Jul '17

The Fedora 26 Final 1.5 compose [1] is considered as GOLD and is going to be shipped live on Tuesday, July 11th, 2017. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. I'd like to thank everyone for the hard work on this release and great job Jan! [1] https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170705.0/compose/ [2] https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gon… [3] https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gon… Thanks, Jaroslav

1 0

Coming soon: Pagure service for dist-git
by Paul W. Frields 06 Jul '17

06 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For some time, the Fedora Infrastructure team and fellow community members have been working on service upgrades for package dist-git. This includes creating a Pagure front end like the one at <https://pagure.io>, a separate instance that enables forks and pull requests on dist-git. This change solves multiple problems -- both common, current ones, and predicted future ones -- that stymie community growth and contribution. Examples include proposing simple packaging fixes, changes to the dist-git branching model, and enabling better, more continuous production models for Fedora. These changes will *not* require packagers to change their workflows for existing processes. Using fedpkg and git at the command line to manage packaging will work just as before. However, it will now be possible for other contributors to suggest changes in a fork/pull-request model. WE'VE TALKED ABOUT THIS FOR A LONG TIME. WHY NOW? - ------------------------------------------------- If you've been paying attention to release tooling efforts in Fedora, you know we're trying to accelerate the release of the Atomic Host deliverable. Part of this effort is establishing a pipeline for continuous integration and delivery (CI/CD) in Fedora[1]. This and the modularity effort also are driving the establishment of services like this dist-git front end. The hooks and capabilities of Pagure are part of enabling CI/CD. In early phases, these efforts will target the packages that comprise the Atomic Host, rather than the entire universe of Fedora packages. This temporary measure will prove out the pipeline in an open source, iterative way. In later phases, packagers throughout Fedora will be able to opt-in to the pipeline as well. The benefit is that we will know more often whether a package has problems before either breaking the distro or impacting users. In the future, we hope this will have a positive impact on Rawhide, making it usable by more of the community, more often. WHAT TO EXPECT - -------------- One of the contributions expected in this early phase is testing. The standard interface[2] developed as part of the CI effort provides a framework for test contributions. Shortly after Pagure/dist-git shows up, we hope to receive test contributions from quality engineers for packages that comprise the Atomic Host. These should come in the form of pull requests for the package maintainers, following the established standards. This is a benefit for Fedora not only because it kickstarts the CI effort, but because it provides examples the whole Fedora community can use in later phases. The intention is that maintainers and co-maintainers continue to control these tests so they can modify or add to them as needed. If you're a packager with a package in the Atomic Host, you may receive pull requests soon after the new Pagure instance is deployed, with these tests included. We encourage you to review and merge these pull requests (provided they look good), so your package can take advantage of the CI work. If you have problems with the pull request, you can use the Pagure instance to work with the contributor to fix it. It is possible to turn off PRs for your dist-git repo in the repo settings. However, we strongly encourage you to allow PRs because this is a strong source of potential contributions with little or no downside. We plan to work with FESCo on a project-wide policy that makes sense and fits Fedora's values. WANT TO TRY IT OUT? - ------------------- If you're interested to see what this new capability looks like, and want to test a working version, visit <https://src.stg.fedoraproject.org/pagure/>. Changes here won't affect the actual Fedora RPMs, but the staging instance lets you explore the new functionality. Note that the staging content is updated on a schedule, so some newer package data may not appear there. It will be at least a few more weeks before the production instance is ready. We appreciate your constructive feedback and bugs[3], as always. * * * [1] https://fedoraproject.org/wiki/CI [2] https://fedoraproject.org/wiki/Changes/InvokingTests [3] https://pagure.io/pagure/issues - -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -----BEGIN PGP SIGNATURE----- iD8DBQFZXmrvrNvJN70RNxcRAv2CAJsHL66rtcFl6z/ooEOyfexkye3gBQCeOpHF LQjAwhGOmVD2kjCD4W5Ql0c= =AyX9 -----END PGP SIGNATURE-----

1 0

F27 System Wide Change: NSS signtool deprecation
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= System Wide Change: NSS signtool deprecation = https://fedoraproject.org/wiki/Changes/NSSSigntoolDeprecation Change owner(s): * Kai Engert <kaie(a)redhat.com> Deprecate the NSS tool named signtool, currently shipped as part of the nss-tools package, and available in the default search path at /usr/bin/signtool. Move it to /usr/lib*/nss/unsupported-tools/signtool. == Detailed Description == The NSS signtool is hardcoded to use SHA1 for signatures, however, SHA1 is no longer considered secure. Because it seems difficult to change the signtool default to make use of a more secure hash algorithm in a backwards and forwards compatible way, and because signtool might no longer be required for common uses, the suggestion is to deprecate it. See also [1] and [2] == Scope == * Proposal owners: The work required to implement this change is a simple packaging change. * Other developers: Users who used signtool for signing Jar/Zip/etc. files must use a different tool. A possible alternative is the jarsigner tool, which is shipped as part of the java-*-openjdk-devel package. * Release engineering: [1] * List of deliverables: N/A * Policies and guidelines: N/A, no changes should be necessary. * Trademark approval: N/A (not needed for this Change) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345528 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1444136 [3] https://pagure.io/releng/issue/6882 Thanks, Jaroslav

1 0

F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= System Wide Change: NSS Default File Format SQL = https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Change owner(s): * Kai Engert <kaie(a)redhat.com> Change the NSS library default to use the sqlite based data storage, when applications don't specify their preferred storage file format. == Detailed Description == Applications that use the NSS library often use a database for storage of keys, certificates and trust. NSS supports two different file formats, one called DBM (based on berkeley DB files) and another one called SQL (based on sqlite DB files). Today's default file format used by NSS, used when applications omit the type parameter, is the older DBM file format, which forbids parallel access to the storage. The suggestion is to change the default file format to SQL, which allows parallel access to the storage. Applications, or users using the NSS command line utilities, often provide the database storage location using a simple directory path parameter. Some might not be aware, or forget, that the parameter can be prefixed with a type modifier, either "dbm:" or "sql:". As a result, when not providing this parameter, the file format used will be the fragile DBM file format. This is particuarly problematic, if a user attempts to modify the NSS storage using command line tools, while another process, such as a daemon, is running concurrently, which also accesses the same database in the DBM file format. This often results in corrupted database storage, which cannot be recovered. By changing the default, all applications that currently use the DBM file format, will automatically be migrated to the SQL file format. NSS has the ability to discover if a storage location (a directory) contains the DBM file format. If configured to use the modern SQL format, NSS will automatically perform a one-time conversion from the DBM to the SQL format. The same applies to the NSS command line utilities. If the NSS library default is changed to SQL, the NSS tools will also trigger the one-time conversion, or access the already converted files. == Scope == * Proposal owners: A small downstream patch needs to be applied to the NSS library package, which changes the library default. * Other developers: It's up to developers of NSS applications, if they accept the new default and an automatic conversion, or if they prefer to continue to use the classic DBM storage format. Although not recommended, developers can easily do so, by adding a "dbm:" prefix to the storage parameter they provide to NSS at NSS library initialization time. * Release engineering: [1] No help should be necessary. No mass rebuild necessary. * Policies and guidelines: N/A * Trademark approval: N/A [1] https://pagure.io/releng/issue/6883 Thanks, Jaroslav

1 0

F27 System Wide Change: Graphical Applications as Flatpaks
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= System Wide Change: Graphical Applications as Flatpaks = https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks Change owner(s): * Owen Taylor <otaylor(a)redhat.com> This change is to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation. == Detailed Description == See Workstation/Flatpaks [1] for the full development plan. The goal of this change is make Flatpaks available as a distribution mechanism for software packaged in Fedora. Multiple Flatpaks on the system can share a runtime of common libraries. There will be a single Fedora runtime maintained on the same schedule as the Platform module for Fedora. It will be be defined as a module that includes libraries that are commonly used for graphical applications. Some of these will inherit from the Platform module. Applications then bundle the code for the application itself and for additional libraries they depend on beyond the base runtime. Each application has its own module in which the relevant RPMs are rebuilt with a special RPM macros (in the flatpak-rpm-macros package) to relocate the application and bundled libraries into the /app prefix. (This is necessary, because inside an executing Flatpak, the application is mounted at /app, and the runtime at /usr) The packages are then composed into Flatpaks by the layered image service, sharing as much of the workflow and code as possible with containers. While the native delivery mechanism for Flatpaks is as an ostree repository, they can also be distributed as OCI images, and our goal is to use this format during the build process, and to distribute them to users via registry.fedoraproject.com. Automation of rebuilds and integration with Bodhi will also be needed to make sure that security and bug-fix updates to packages end up being distributed to users. This part is least specified at the current time, and full automation may not be achievable for Fedora 27. If the above plan is followed, most of this work is shared with work needed for modularity in general and for server-side containers. == Scope == * Proposal owners: (f27) ** Create and maintain a flatpak-runtime module ** Provide tools for application authors to use to create module descriptions for their flatpaks ** Provide patches for the container build pipeline (atomic reactor and friends) to build flatpaks as well as containers ** Create some way to get summary information for all flatpaks on registry.fedoraproject.org; this might be a patch to the codebase, a look-aside file, or a separate service. ** Modify flatpak and gnome-software so that flatpaks can be installed from registry.fedoraproject.org. * Proposal owners: (f28) ** Provide a "SDK" profile of the flatpak-runtime module to create a Flatpak SDK for third-party non-RPM builds against the SDK using flatpak-builder * Other developers: (f27) ** Provide exports of built modules as repositories (the "On Demand Compose Service") ** Provide some reasonably self-service way for packagers to create modules without a lot of overhead. (Does it make sense to allow ''application modules'' where when a package corresponds one-to-one to a module to allow the modulemd to live in dist-git next to the spec file?) ** Allow Fedora packagers to submit module builds ** Allow uploading OCI images to registry.fedoraproject.org Upstream pull request [2] ** Make sure that Bodhi updates can be submitted for Flatpaks/OCI Images in the same way as for Docker containers (no significant code changes are expected beyond the current work to enable multiple types of Bodhi updates.) * Other developers: (f28) ** Create a unified workflow for package and container/flatpak updates (detailed plan to be developed, something like:) *** updates submitted to bodhi for a package should trigger automatic module and container/flatpak builds *** Pushing a package to stable should push the updated flatpaks/containers *** the Bodhi user interface should show modules/containers that include a package and their status * Release engineering: [3] (a check of an impact with Release Engineering is needed) ** List of deliverables: Most likely, runtime and applications would not be part of the deliverables list. However, we will need to consider the quality of the runtime and applications as part of the overall quality of release - if some common application did not run on upgrade that would seriously affect users. This should, as much as possible, be addressed through continuous automated testing. * Policies and guidelines: The people working on this change will need to work closely in the development of module guidelines, and make sure that Flatpak specifics are documented as well (for example, documenting the creation of a 'flatpak.json' with permissions and other metadata for the Flatpak). It's possible some changes will be needed to the packaging guidelines to make sure that all relevant packages relocate to /app properly, but it's expected that most packages that follow the current packaging guidelines will work correctly. * Trademark approval: N/A (not needed for this Change) [1] https://fedoraproject.org/wiki/Workstation/Flatpaks [2] https://github.com/docker/distribution/pull/2076 [3] https://pagure.io/releng/issue/6876 Thanks, Jaroslav

1 0

F27 System Wide Change: The GNU C Library version 2.26
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= System Wide Change: The GNU C Library version 2.26 = https://fedoraproject.org/wiki/Changes/GLIBC226 Change owner(s): * Carlos O'Donell <carlos(a)redhat.com> Switch glibc in Fedora 27 to glibc version 2.26. == Detailed Description == The GNU C Library version 2.26 will be released at the beginning of August 2017; we have started closely tracking the glibc 2.26 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 27 will branch after the GLIBC 2.26 upstream release. However, the mass rebuild schedule means Fedora 27 will mass rebuild just after GLIBC 2.26 upstream freezes ABI for release, so careful attention must be paid to any last minute ABI changes. == Scope == * Proposal owners: Update glibc to 2.26 from tested upstream release. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 27 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated. * Release engineering: [1] All Fedora releases must be released using a released version of glibc. The Fedora glibc team is responsible for ensuring that Fedora Rawhide stabilizes ABI before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by glibc or other components, the Fedora glibc team will ensure coordination with release engineering such that a mass rebuild uses the released version of glibc to fix any last minute ABI changes. The GNU C Library (glibc) does not require a mass rebuild for this release. * List of deliverables: all * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6890 Thanks, Jaroslav

1 0

F27 Self Contained Change: VirtualBox Guest Integration
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= Proposed Self Contained Change: VirtualBox Guest Integration = https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration Change owner(s): * Hans de Goede <hdegoede(a)redhat.com> VirtualBox is popular, easy to use virtual-machine software. The purpose of this change is to ship the VirtualBox guest-drivers and -tools by default in the Fedora workstation product. == Detailed Description == VirtualBox runs on Windows. MacOS and Linux and is used by many users to try it Linux for the first time. As such it is important for Fedora to work well in VirtualBox virtual-machines. Like other virtual-machines VirtualBox virtual-machines can offer an enhanced user-experience when some VirtualBox specific guest-drivers and guest-tools are installed. This change is about adding the guest-drivers to the Fedora kernel package, packaging the userspace-tools (VirtualBox Guest Additions) and adding the VirtualBox Guest Additions package to the default package list for the Workstation product. == Scope == * Proposal owners: ** Adding the VirtualBox guest drivers to the kernel package. To make this happen work is underway to clean them up and submit them upstream. ** Package VirtualBox Guest Additions userspace parts ** Add VirtualBox Guest Additions package to the default package list for the Workstation product * Other developers: N/A (not a System Wide Change) * Release engineering: [1] * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6880 Thanks, Jaroslav

1 0

F27 System Wide Change: 32 bit UEFI Support
by Jaroslav Reznik 06 Jul '17

06 Jul '17

= System Wide Change: 32 bit UEFI Support = https://fedoraproject.org/wiki/Changes/32BitUefiSupport Change owner(s): Peter Jones <pjones(a)redhat.com> Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel and distribution on these systems. So far this setup has not been supported in Fedora. This feature is about adding support for installing and booting Fedora on this hardware. == Detailed Description == To add support for booting Fedora x86_64 on x86 systems with 32 bit UEFI firmware a number of (small) changes to grub, various EFI related userspace tools and anaconda are necessary. See Scope for more details. == Scope == * Proposal owners: ** The x86_64 grub2 packages will need to include an extra grub build, next to the current classic BIOS and 64 bit UEFI build a new 32 bit UEFI build will be added to the x86_64 packages. ** This new grub will need to be added to the various x86_64 boot media ** A few EFI userspace utilities need to be updated to work with 32 bit x86 UEFI ** The installer (anaconda) needs some changes to the bootloader installation code to install the 32 bit UEFI grub binary * Other developers: No changes are necessary outside of the affected packages * Release engineering: [1] ** List of deliverables: This feature should be enabled on all non cloud/container x86_64 images * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6879 Thanks, Jaroslav

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2017