Re: Orphaning python-orderedset and auto-destdir
I took python-orderedset. On 12/30/20 4:41 PM, Jerry James wrote: > I maintain packages that used to BR the packages in $SUBJECT, but with > their latest versions no longer do. I'm orphaning these packages. If > you need them, please pick them up. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
On 2020-07-01 15:43, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha wrote: >> >> On 7/1/20 2:03 PM, Neal Gompa wrote: >>> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: On 6/30/20 9:35 PM, Igor Raits wrote: > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/SID > >> == Summary == >> Introduce Storage Instantiation Daemon (SID) that aims to provide a >> central event-driven engine to write modules for identifying specific >> Linux storage devices, their dependencies, collecting information and >> state tracking while >> being aware of device groups forming layers and layers forming whole >> stacks or simply creating custom groups of enumerated devices. SID >> will provide mechanisms to retrieve and query collected information >> and a possibility to bind predefined or custom triggers with actions >> for each group. > >> == Owner == >> * Name: [[User:prajnoha | Peter Rajnoha]] >> * Email: prajn...@redhat.com > >> == Detailed Description == >> Over the years, various storage subsystems have been installing hooks >> within udev rules and calling out numerous external commands for them >> to be able to react on events like device presence, removal or a >> change in general. However, this approach ended up with very complex >> rules that are hard to maintain and debug if we are considering >> storage setups where we build layers consisting of several underlying >> devices (horizontal scope) and where we can stack one layer on top of >> another (vertical scope), building up diverse storage stacks where we >> also need to track progression of states either at device level or >> group level. > >> SID extends udevd functionality here in a way that it incorporates a >> notion of device grouping directly in its core which helps with >> tracking devices in storage subsystems like LVM, multipath, MD... >> Also, it provides its own database where records are separated into >> per-device, per-module, global or udev namespace. The udev namespace >> keeps per-device records that are imported and/or exported to/from >> udev environment and this is used as compatible communication channel >> with udevd. The records can be marked with restriction flags that aid >> record separation and it prevents other modules to read, write or >> create a record with the same key, hence making sure that only a >> single module can create the records with certain keys (reserving a >> key). > >> Currently, SID project provides a companion command called 'usid' >> which is used for communication between udev and SID itself. After >> calling the usid command in a udev rule, device processing is >> transferred to SID and SID strictly separates the processing into >> discrete phases (device identificaton, pre-scan, device scan, >> post-scan). Within these phases, it is possible to decide whether the >> next phase is executed and it is possible to schedule delayed actions >> or set records in the database that can fire triggers with associated >> actions or records which are then exported to udev environment >> (mainly >> for backwards compatibility and for other udev rules to have a chance >> to react). The scheduled actions and triggers are executed out of >> udev >> context and hence not delaying the udev processing itself and >> improving issues with udev timeouts where unnecessary work is done. > >> A module writer can hook into the processing phases and use SID's API >> to access the database as well as set the triggers with actions or >> schedule separate actions and mark devices as ready or not for use in >> next layers. The database can be used within any phase to retrieve >> and >> store key-value records (where value could be any binary value in >> general) and the records can be marked as transient (only available >> during processing phases for current event) or persistent so they can >> be accessed while processing subsequent events. > >> == Benefit to Fedora == >> The main benefit is all about centralizing the solution to solve >> issues that storage subsystem maintainers have been hitting with >> udev, >> that is: > >> * providing a central infrastructure for storage event processing, >> currently targeted at udev events > >> * improving the way storage events and their sequences are recognized >> and for which complex udev rules were applied before > >> * single notion of device readiness shared among various storage >> subsystems (single API to set the state instead of setting various >> variables by different subsystems) > >> * providing more enhanced possibilities to store and retrieve >> storage-device-re
Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
On 2020-07-01 14:03, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: >> >> On 6/30/20 9:35 PM, Igor Raits wrote: >>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/SID >>> == Summary == Introduce Storage Instantiation Daemon (SID) that aims to provide a central event-driven engine to write modules for identifying specific Linux storage devices, their dependencies, collecting information and state tracking while being aware of device groups forming layers and layers forming whole stacks or simply creating custom groups of enumerated devices. SID will provide mechanisms to retrieve and query collected information and a possibility to bind predefined or custom triggers with actions for each group. >>> == Owner == * Name: [[User:prajnoha | Peter Rajnoha]] * Email: prajn...@redhat.com >>> == Detailed Description == Over the years, various storage subsystems have been installing hooks within udev rules and calling out numerous external commands for them to be able to react on events like device presence, removal or a change in general. However, this approach ended up with very complex rules that are hard to maintain and debug if we are considering storage setups where we build layers consisting of several underlying devices (horizontal scope) and where we can stack one layer on top of another (vertical scope), building up diverse storage stacks where we also need to track progression of states either at device level or group level. >>> SID extends udevd functionality here in a way that it incorporates a notion of device grouping directly in its core which helps with tracking devices in storage subsystems like LVM, multipath, MD... Also, it provides its own database where records are separated into per-device, per-module, global or udev namespace. The udev namespace keeps per-device records that are imported and/or exported to/from udev environment and this is used as compatible communication channel with udevd. The records can be marked with restriction flags that aid record separation and it prevents other modules to read, write or create a record with the same key, hence making sure that only a single module can create the records with certain keys (reserving a key). >>> Currently, SID project provides a companion command called 'usid' which is used for communication between udev and SID itself. After calling the usid command in a udev rule, device processing is transferred to SID and SID strictly separates the processing into discrete phases (device identificaton, pre-scan, device scan, post-scan). Within these phases, it is possible to decide whether the next phase is executed and it is possible to schedule delayed actions or set records in the database that can fire triggers with associated actions or records which are then exported to udev environment (mainly for backwards compatibility and for other udev rules to have a chance to react). The scheduled actions and triggers are executed out of udev context and hence not delaying the udev processing itself and improving issues with udev timeouts where unnecessary work is done. >>> A module writer can hook into the processing phases and use SID's API to access the database as well as set the triggers with actions or schedule separate actions and mark devices as ready or not for use in next layers. The database can be used within any phase to retrieve and store key-value records (where value could be any binary value in general) and the records can be marked as transient (only available during processing phases for current event) or persistent so they can be accessed while processing subsequent events. >>> == Benefit to Fedora == The main benefit is all about centralizing the solution to solve issues that storage subsystem maintainers have been hitting with udev, that is: >>> * providing a central infrastructure for storage event processing, currently targeted at udev events >>> * improving the way storage events and their sequences are recognized and for which complex udev rules were applied before >>> * single notion of device readiness shared among various storage subsystems (single API to set the state instead of setting various variables by different subsystems) >>> * providing more enhanced possibilities to store and retrieve storage-device-related records when compared to udev database >>> * direct support for generic device grouping (matching subsystem-related groups like LVM, multipath, MD... or creating arbitrary groups of devices) >>> * centralized solution for scheduling triggers with assoc
Re: How to enable package gating
Thank you, I feel really stupid for missing this. (But to my defense, having gating.yaml and tests.yml is quite confusing.) On 2020-04-03 14:49, Lukas Holecek wrote: > Hi Vojtěch, > > The issue is that the file suffix should be `.yaml`, not `.yml`. > > Damn that YAML suffix. It's a hard-to-find issue that happened before. Maybe > Greenwave should fallback to get `gating.yml` (it would require an > additional > request to git repo thought). > > Lukas > > > On Tue, Mar 31, 2020 at 2:07 PM Vojtěch Trefný wrote: > >> Hi, I need help with enabling gating on my package. I actually thought >> I've already enabled it 2 months ago but I've noticed the tests are not >> running in Bodhi and it also says that "no tests are required" on my >> last rawhide Bodhi update [1] >> >> This [2] is my gating.yml, I think the problem is wrong >> "test_case_name", I was able to find three different examples with three >> different "test_case_name" values: >> - fedora-ci.koji-build.tier0.functional [3] >> - org.centos.prod.ci.pipeline.allpackages-build.complete [4] >> - >> >> org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete >> [5] >> >> so which one of these should I use? Or is there a different problem with >> my gating.yml? I am quite sure the problem is not in the tests or >> tests.yml because tests on PRs in Pagure are working as expected. >> >> Thanks in advance. >> >> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-19a9c20b6f >> [2] https://src.fedoraproject.org/rpms/blivet-gui/blob/master/f/gating.yml >> [3] https://docs.fedoraproject.org/en-US/ci/gating/ >> [4] https://docs.fedoraproject.org/en-US/rawhide-gating/optin/ >> [5] https://docs.pagure.org/greenwave/package-specific-policies.html >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
How to enable package gating
Hi, I need help with enabling gating on my package. I actually thought I've already enabled it 2 months ago but I've noticed the tests are not running in Bodhi and it also says that "no tests are required" on my last rawhide Bodhi update [1] This [2] is my gating.yml, I think the problem is wrong "test_case_name", I was able to find three different examples with three different "test_case_name" values: - fedora-ci.koji-build.tier0.functional [3] - org.centos.prod.ci.pipeline.allpackages-build.complete [4] - org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete [5] so which one of these should I use? Or is there a different problem with my gating.yml? I am quite sure the problem is not in the tests or tests.yml because tests on PRs in Pagure are working as expected. Thanks in advance. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-19a9c20b6f [2] https://src.fedoraproject.org/rpms/blivet-gui/blob/master/f/gating.yml [3] https://docs.fedoraproject.org/en-US/ci/gating/ [4] https://docs.fedoraproject.org/en-US/rawhide-gating/optin/ [5] https://docs.pagure.org/greenwave/package-specific-policies.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Seeking the maintainer of dbus-python
On 2020-02-12 12:18, Ray Strode wrote: > hi, > > On Wednesday, February 12, 2020, Miro Hrončok wrote: >>> sure. amigadave, do you want to be comaintainer too? >> >> You can only make one person a main admin. Any co-maintainers can be > handled later by them. > > well i added neal and amigadave as admins, too, before giving the project > to vojtech. > > Ray > Thank you. And thank you to neal and amigadave too, I expect dbus-python to be quite easy to maintain but help is always appreciated. Leigh already did the update to the latest upstream so everything should be ok for now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Seeking the maintainer of dbus-python
On 2020-02-12 11:01, Vojtěch Trefný wrote: > > > On 2020-02-12 03:03, Neal Gompa wrote: >> On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro >> wrote: >>> >>> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok >>> wrote: >>>> Since cca mid-2018 there was no reply from any maintainer in >>>> Bugzillas. >>> >>> Hi, >>> >>> This package has been deprecated for a very long time (a decade?). >>> Nothing should be using it anymore. Either use GDBus via PyGObject, or >>> another D-Bus client library instead. If anybody wants to take this >>> package, I'm sure that could be arranged. Working out a retirement plan >>> would also be a good idea, though if there are too many rdeps it might >>> not be practical. >>> >> >> This is probably not going to be workable: >> >> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l >> 106 >> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l >> 3 >> >> I don't think this was the library that was deprecated either. I'm >> pretty sure that was the libdbus-glib library, though this is >> unfortunately built on top of that. >> > > From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS: > > "The deprecated dbus-glib library is no longer required. A bundled copy > of its main loop integration code is included instead." > > We are using dbus-python in some of our packages (mostly test suite for > UDisks and some helper scripts etc.). Actually lvmdbusd is using dbus-python so Anaconda indirectly depends on it (Blivet is using LVM DBus API for LVM management). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Seeking the maintainer of dbus-python
On 2020-02-12 03:03, Neal Gompa wrote: > On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro > wrote: >> >> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok >> wrote: >>> Since cca mid-2018 there was no reply from any maintainer in >>> Bugzillas. >> >> Hi, >> >> This package has been deprecated for a very long time (a decade?). >> Nothing should be using it anymore. Either use GDBus via PyGObject, or >> another D-Bus client library instead. If anybody wants to take this >> package, I'm sure that could be arranged. Working out a retirement plan >> would also be a good idea, though if there are too many rdeps it might >> not be practical. >> > > This is probably not going to be workable: > > $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l > 106 > $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l > 3 > > I don't think this was the library that was deprecated either. I'm > pretty sure that was the libdbus-glib library, though this is > unfortunately built on top of that. > From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS: "The deprecated dbus-glib library is no longer required. A bundled copy of its main loop integration code is included instead." We are using dbus-python in some of our packages (mostly test suite for UDisks and some helper scripts etc.). From the git repo it looks like the project is actively maintained and latest release is less than month old so I think there is no reason to retire dbus-python. If nobody wants to maintain this package I can do that. It's definitely easier than rewriting our code to something else. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
On 2019-10-14 18:06, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > weeks ago > sl orphan 1 > weeks ago Taken, we can't have distribution without sl :-) -- vtrefny ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/10/19 11:57 AM, Kamil Paral wrote: > On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy > wrote: > >>> 1. multipathd. >> >> I'm pretty sure it gets dragged in by the installer > > > Nope, multipath seems to be present because libblockdev and udisks (and > perhaps some more), which is in turn required by GNOME: > > $ rpm -q --whatrequires device-mapper-multipath > libblockdev-fs-2.21-2.fc30.x86_64 > libblockdev-part-2.21-2.fc30.x86_64 That's actually a bug in libblockdev, only multipath plugin should depend on device-mapper-multipath. > libblockdev-mpath-2.21-2.fc30.x86_64 > fcoe-utils-1.0.32-6.fc29.x86_64 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretire python-svgwrite
Hi, I'd like to unretire python-svgwrite. It was originally retired because it failed to build with Python 3.7. Upstream released a new version that fixes this. Copr build -- https://copr.fedorainfracloud.org/coprs/vtrefny/svgwrite/ Review request -- https://bugzilla.redhat.com/show_bug.cgi?id=1678568 -- Vojtech Trefny ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/18/2018 06:09 PM, Igor Gnatenko wrote: If you fixed package(s), found false positive, found missing packages in list or anything else -- please let me know. libbytesize fixed in rawhide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] udisks 2.6.4 released, replacing storaged
Hi, we released a new version of the udisks storage management daemon. The biggest news is actually the name itself -- udisks was replaced by storaged in Fedora 25[1] but since then we have agreed with udisks maintainer on merging both projects back (storaged was originally fork of udisks) using the original name 'udisks'. This is the first release of 'storaged' using the old 'udisks' name[2]. We will also retire the storaged package and use the 'old' udisks2 package for Fedora starting with this release. Only cockpit currently depends on the storaged package, other projects still depend on the udisks2 package (which had been provided by the storaged package), so this change won't affect them. The 2.6.4 release contains numerous bugfixes and a lot of new tests. For full list of changes visit our GitHub[3]. -- [1] https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged [2] https://github.com/storaged-project/udisks/pull/191 [3] https://github.com/storaged-project/udisks/blob/master/NEWS ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Blivet-GUI in Anaconda
On 10/19/2016 08:39 PM, Chris Murphy wrote: On Wed, Oct 19, 2016 at 7:54 AM, Jan Kurik wrote: = Proposed Self Contained Change:Blivet-GUI in Anaconda = https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI Change owner(s): * Martin Kolman * Vojtěch Trefný Add blivet-gui as an alternative option for storage configuration in Anaconda Installer. == Detailed Description == Add blivet-gui as an alternative option for storage configuration in Anaconda Installer. I think making Anaconda more complicated is the wrong direction to go in. Examples of stable installers that have exactly zero bugs at release time are stupid point and shoot installers that reliably meet the needs of 80% of the user base. A stand alone partitioning tool meets the needs of the remaining 19%. I continue to suggest pulling the existing custom storage UI out of anaconda. Make it the Easy UI option for blivet-gui, with the existing blivet-gui the Advanced UI. And then have blivet-gui write out some metadata that anaconda can use to override whatever its autopartitioning configuration is, leaving the user to only deal with the other spokes. The proposal as it is strikes me as creating even more traps for unsuspecting users. Already a good portion of Anaconda's custom UI isn't tested by QA, and yet there's a release criterion that says if the installer offers a way to do something, then it needs to work, otherwise it's a release blocking bug. This proposal increases the footprint for blocking bugs, in a tool that currently has 5 of 13 release blocking bugs. The contingency plan for adding blivet-gui to Anaconda is simple -- if it is not stable enough we just won't include it. This will be quite small change in Anaconda code base and removing it will take just few seconds. Unlike the current custom partitioning screen in Anaconda, which works in a top-down way (user specifies mountpoints and their properties), blivet-gui works with the bottom-up principle (user has full control to assemble the storage configuration from individual members). By integrating blivet-gui into anaconda we will make the bottom-up partitioning available to users during the installation. Blivet-gui is built on top of the blivet library, which is used by Anaconda for storage configuration, this makes the change very easy to implement and doesn't bring new code and dependecies into the installer other than a relatively small GUI package. Integration is not the only way to make it available to users. I'm fairly perturbed that Windows and macOS have rock solid OS installers, and Fedora continues to have the most indefensible asinine bugs in its installer - even including data loss bugs in autopartitioning - and the idea is to make it even more complicated? I just see this as a proposal for more bugs, and not fixing the warts the installer already has. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Blivet-GUI in Anaconda
On 10/19/2016 04:29 PM, Matthew Miller wrote: On Wed, Oct 19, 2016 at 03:54:57PM +0200, Jan Kurik wrote: == Detailed Description == Add blivet-gui as an alternative option for storage configuration in Anaconda Installer. I'm in favor of this; it addresses one of the persistant remaining complaints I hear from systems administrators and Linux enthusiasts (the latter usually with very strong opinions on how they want things) about the new Anaconda. It's currently hard to respond to these without telling people that their preferences are wrong - which is not a strong way to convince someone. That's exactly the reason to add this option. I do hope there is UX thought put into how to present the choice, though -- making it available without making the whole process seem 4x as complicated seems like a challenge. The change in the storage spoke* will be very small. Now, you have to choose between autopart and manual storage configuration and we will add a third option to use blivet-gui (it will be probably labeled "expert storage configuration" or something like that) and blivet-gui will be in a separate spoke -- just like the current "manual" configuration (custom spoke). *) Storage Spoke is the "Installation Destination" screen -- https://docs.fedoraproject.org/en-US/Fedora/21/html-single/Installation_Guide/images/anaconda/StorageSpoke.png ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Blivet-GUI in Anaconda
On 10/19/2016 04:17 PM, Vít Ondruch wrote: Sounds interesting. I hope it won't be choice one or the another, but that I'll be able to do basic setup by Anaconda and probably tweak some properties of the default setup using blivet gui. Hi, good idea. Unfortunately this will most likely work similarly to current custom spoke -- you'll need to choose if you want to use autopart, manual configuration (custom spoke) or blivet-gui and leaving the spoke will reset the storage configuration. But custom spoke has an option to create the storage configuration automatically and it shouldn't be so hard to add it to blivet-gui too (it can even call the same anaconda/blivet functions). V. Dne 19.10.2016 v 15:54 Jan Kurik napsal(a): = Proposed Self Contained Change:Blivet-GUI in Anaconda = https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI Change owner(s): * Martin Kolman * Vojtěch Trefný Add blivet-gui as an alternative option for storage configuration in Anaconda Installer. == Detailed Description == Add blivet-gui as an alternative option for storage configuration in Anaconda Installer. Unlike the current custom partitioning screen in Anaconda, which works in a top-down way (user specifies mountpoints and their properties), blivet-gui works with the bottom-up principle (user has full control to assemble the storage configuration from individual members). By integrating blivet-gui into anaconda we will make the bottom-up partitioning available to users during the installation. Blivet-gui is built on top of the blivet library, which is used by Anaconda for storage configuration, this makes the change very easy to implement and doesn't bring new code and dependecies into the installer other than a relatively small GUI package. == Scope == * Proposal owners: - blivet-gui devs: Prepare blivet-gui for integration into Anaconda -- change the UI to look consistently while running fullscreen inside an Anaconda spoke, change look and feel of blivet-gui dialogs to match Anaconda dialogs, add storage configuration sanity checking into blivet-gui. - anaconda devs: Add an option to use blivet-gui to the Storage spoke, add blivet-gui package as a dependency of the anaconda package so that it is pulled into the installation environment and also add an option to not show blivet-gui in anaconda if requested (see https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction-config-file-spec.rst%7C for detailed explanation how hiding spokes works in Anaconda). * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * 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) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packages up for grabs
I'd like to take freecol, love this game. FAS: vtrefny Thanks. -- Vojtech Trefny On 07/04/2016 12:11 AM, Hans de Goede wrote: Hi All, Between my $dayjob, other foss projects and last but not least spending time with my wife and children I'm way too busy lately. So I'm trying to find a new home for the packages I maintain pretty much anything on the point of contact list here is fair game: https://admin.fedoraproject.org/pkgdb/packager/jwrdegoede/ If you want to take some packages over please let me know which ones and what your fas login is then I'll "give" them to you in pkgdb. Thanks & Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Vojtech Trefny
Hi all, my name is Vojtech Trefny and I am from the Czech Republic. I have been using Linux and OSS for nearly ten years now. I spent most of this time in Ubuntu community doing non-development work (localisation, documentation, advocacy...), but I switched to Fedora in 2013, joined Red Hat later that year as an intern and finally last year's october moved to the Installer team where I work on storage, mostly on a small application called blivet-gui. Regards Vojtech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
Dne 5.9.2014 15:04, Bastien Nocera napsal(a): - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is "why not gnome-disk-utility?" :) Because it doesn't support LVMs and RAIDs. GNOME Disks is application for "normal" users -- it helps them to format their USB flash drive or create an image of disk or check smart data etc. One of its goals is to not provide "expert" functions. Vojta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
