Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Vojtěch Trefný


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
>> 

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Vojtěch Trefný


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 

Re: How to enable package gating

2020-04-06 Thread Vojtěch Trefný
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

2020-03-31 Thread Vojtěch Trefný
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

2020-02-12 Thread Vojtěch Trefný


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

2020-02-12 Thread Vojtěch Trefný


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

2020-02-12 Thread Vojtěch Trefný


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

2019-10-14 Thread Vojtěch Trefný


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?

2019-04-11 Thread Vojtěch Trefný


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

2019-02-18 Thread Vojtěch Trefný
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++

2018-02-21 Thread Vojtěch Trefný



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

2017-03-14 Thread Vojtěch Trefný
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

2016-10-20 Thread Vojtěch Trefný



On 10/19/2016 08:39 PM, Chris Murphy wrote:

On Wed, Oct 19, 2016 at 7:54 AM, Jan Kurik <jku...@redhat.com> wrote:

= Proposed Self Contained Change:Blivet-GUI in Anaconda =
https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI

Change owner(s):
* Martin Kolman <mkol...@redhat.com>
* Vojtěch Trefný <vtre...@redhat.com>


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

2016-10-20 Thread Vojtěch Trefný



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

2016-10-20 Thread Vojtěch Trefný

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 <mkol...@redhat.com>
* Vojtěch Trefný <vtre...@redhat.com>


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

2016-07-04 Thread Vojtěch Trefný

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

2015-01-22 Thread Vojtěch Trefný

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

2014-09-05 Thread Vojtěch Trefný


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