Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[drago01]

On Monday, November 26, 2018, Matthew Miller 
wrote:

> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> I know it was a big time-off holiday week in the US, but I expected a
> little
> more interest in this post. Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> proposals:
>
> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)
> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * define a base platform -- Red Hat wants to focus resources here
> * better tooling for non-base deliverables
> * better metrics for everything
>
>
> Please read https://fedoraproject.org/wiki/Objectives/Lifecycle/
> Problem_statements
> and comment in this thread.
>
>
I am not really convinced that delaying the release for that makes sense.

It's not like people will stop updating packages or that existing release
tools will magically disappear (they have to work to keep existing versions
running).

So people can work on those improvement and bring them in when ready but
stopping everything for that is overkill.
___
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: Any plans to support .heic files in Fedora?

[Samuel Sieb]

On 11/26/18 8:58 PM, Dusty Mabe wrote:

Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin [1]. The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.


They would have to be provided through rpmfusion.  I thought I saw a 
comment a while back that getting the libraries in was being worked on, 
but I could be mistaken.

___
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: Is Fedora 27 EOL?

[Mohan Boddu]

Okay, all of the eol entries for f27 in pdc should be updated now.

Please create a ticket at https://pagure.io/releng if you find any issues.

Thanks.

On Mon, Nov 26, 2018 at 7:03 PM Mohan Boddu  wrote:

> I am still updating the EOL's in pdc, but some of them should be updated.
>
> I will send another email once all of them are updated.
>
> On Mon, Nov 26, 2018 at 11:10 AM Matthew Miller 
> wrote:
>
>> On Mon, Nov 26, 2018 at 10:30:32AM -0500, Ben Cotton wrote:
>> > The policy on the wiki[1] says "one month", which is fairly ambiguous.
>> > I'll update that to say "four weeks", which is what we mean, but is
>> > not the practical interpretation of what we say. Since I dropped the
>> > ball on this, let's do the F27 EOL on Friday and I'll fix both the
>> > text of the policy and my own workflow to prevent this issue in the
>> > future.
>>
>> For the record, FESCo ticket where 4 weeks / 28 days was made official:
>> https://pagure.io/fesco/issue/1750
>>
>>
>>
>> --
>> Matthew Miller
>> 
>> Fedora Project Leader
>> ___
>> 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
>>
>
___
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

Any plans to support .heic files in Fedora?

[Dusty Mabe]

Seems like Apple converted their phones over to using a new file format
to store pictures. I was copying some pictures from a phone and noticed
my linux box couldn't read them and they had an interesting extension .heic.

Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin [1]. The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.

Anybody been down this road? Is it as simple as getting the libraries in or
is there much more pain involved that I haven't discovered yet?

Thanks,
Dusty

[1] https://github.com/strukturag/heif-gimp-plugin
___
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

[389-devel] 389 DS nightly 2018-11-27 - 90% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/27/report-389-ds-base-1.4.0.19-20181127git4fd73c5.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Proposal: Move to an annual platform release starting at F30

[Brendan Conoboy]

On 11/16/18 7:50 AM, Paul Frields wrote:
[snip]

We should skip the F31 release cycle and leave F30 in place longer in
order to focus on improving the tooling and testing changes. These
tooling changes will improve the overall reliability of Fedora, and
will decrease the manual effort and complexities involved in producing
the distribution artifacts. Although we’ve done this before to make
“editions” happen, the intent is to track this multi-team effort more
actively so we can (1) use the time as well as possible, and (2) give
the work maximum transparency.


If there is going to be a pause F30 seems like a good place to do it: 
New glibc, new compiler- and a full year for them to mature.  It's a 
nice basis for a stable platform.  What would the update policy be for 
this year- same as today?  It seems like you're proposing this as a 
one-time event to pay down technical debt, which is great, but would 
you perhaps consider doing the same thing for F31, F32, etc?  The 
basic reasons for technical debt will continue- why not plan to 
service the debt regularly?


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
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: Bugzilla outage/upgrade on 2 December 2018

[Neal Gompa]

On Mon, Nov 26, 2018 at 5:08 PM Jeff Fearn  wrote:
>
> On 27/11/18 02:06, Emmanuel Seyman wrote:
> > * Neal Gompa [26/11/2018 11:01] :
> >>
> >> Out of curiosity, does anyone know where the source code for Red Hat
> >> Bugzilla actually is? I tried to find it a while ago, and even tried
> >> to send an email asking about it (with no response...). This variant
> >> of Bugzilla has features that aren't present in vanilla Bugzilla 5.x,
> >> nor are they present in the Mozilla fork (bmo)...
> >
> > The source code isn't avaliable (although I've been told at least one
> > Bugzilla developer has access to it).
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=478886
>
> This is correct. We are in a very drawn out, and painful, process to get
> this opened up.
>
> Dylan from BMO is helping us out by doing an audit for us, but he is
> doing it as a favor, in his own time, so it's taking about as long as
> you'd expect to audit a 20 year old code base in your spare time.
>
> Once Dylan is done, and we are putting no pressure on him to meet or
> specify a time line, I'll do another round of infosec/product security
> team hand shaking and then we should be able to open it.
>

My recent interest in RHBZ code stems from two things:
* it has working SAML auth
* it supports external bug tracking (though I'm not sure if the
functionality has completely worked recently, and lacks pagure.io
itself...)

In Mageia, we're looking at revamping our identity management, and
we'd like to use SSO via SAML with our BZ5 system, but sadly this code
is not available for vanilla bz5 systems, and BMO uses CAS instead of
SAML or OIDC. :(

And of course, external bug tracking is useful for obvious reasons. :)


--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Brian C. Lane]

On Mon, Nov 26, 2018 at 04:30:21PM +0100, Tomas Mraz wrote:
> On Mon, 2018-11-26 at 09:59 -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implemen
> > tation
> > 
> > == Summary ==
> > The /usr/bin/gpg path representing the main GPG implementation will
> > now use GnuPG 2 instead of GnuPG 1.
> 
> I, as the primary maintainer of the gnupg2 package, welcome this change
> and I will cooperate on its implementation if it is acked by FESCo.


As the maintainer of gnupg (1) I also agree. This has been proposed by
upstream and I've been meaning to slip a rename and symlink into rawhide
but just haven't gotten around to it yet.

To be clear, gnupg v1.4.x will not be going away, I plan to maintain it
for as long as upstream supports it.

-- 
Brian C. Lane (PST8PDT)
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Paul Frields]

On Mon, Nov 26, 2018 at 5:47 PM Dennis Gilmore  wrote:
> El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió:
> > Because the people that would be tasked with doing the development are
> > also tasked with cranking out the release.  It's a "need more people 
> > problem".
>
> This is no longer entirely true, development of the compose tools is
> done entirely by PNT DevOps today. Bodhi and other tools in parts of
> the delivery pipeline are developed by people in Fedora Engineering who
> also have other tasks to do.
>
> > > ready to go. Ultimately a lot of those sort of ways of optimising
> > > things are things that have been known for some time but no one has
> > > actually stepped up to do the dev work and it it into production
> > > shape. Stopping the standard distro work won't miraculously make
> > > that
> > > other work happen and appear.
> >
> > Well, I kind of disagree.  Barring magical people that appear out of
> > the woodwork that know how the tools work and how they need to be
> > improved, I don't see an alternative.  Not doing a release to focus on
> > our tech debt seems like a good tradeoff.  If there are others that
> > really WANT to continue cranking the release with the tools as they
> > are today... that might be something that could be pursued.  It would
> > still require net new contributors to a critical area.
>
> We would need to engage with the team working on the compose tools and
> see what time they can dedicate to meeting Fedora's needs.  Likely a
> end state needs to be defined. then the work can be scoped.

There are a lot of assumptions wrapped up in these statements. I'm not
sure we should be assuming that delivery mechanisms ought to all be
tied to internal Red Hat teams. This might be a good opportunity for
us (meaning people variously assigned in both places) to think about
whether we should try to decouple more of our delivery side (compose,
push, etc.), while keeping a tight bond at the build/test side.

The customers RH serves have specific expectations, and in part that
dictates how delivery tooling is done. Binding the community to that
may be counterproductive. This is especially true now that RHEL 8 Beta
is out -- it's the perfect time for us to be rethinking at that level.

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

Fedora Rawhide-20181126.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 16/142 (x86_64), 4/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181125.n.0):

ID: 312255  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/312255
ID: 312256  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/312256
ID: 312314  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/312314
ID: 312316  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/312316
ID: 312389  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/312389

Old failures (same test failed in Rawhide-20181125.n.0):

ID: 312257  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/312257
ID: 312258  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/312258
ID: 312282  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/312282
ID: 312283  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/312283
ID: 312300  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/312300
ID: 312301  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/312301
ID: 312305  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/312305
ID: 312320  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/312320
ID: 312332  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/312332
ID: 312334  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/312334
ID: 312385  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/312385
ID: 312392  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/312392
ID: 312399  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/312399
ID: 312400  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/312400
ID: 312402  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/312402
ID: 312421  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/312421

Soft failed openQA tests: 60/142 (x86_64), 15/24 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20181125.n.0):

ID: 312308  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/312308

Old soft failures (same test soft failed in Rawhide-20181125.n.0):

ID: 312265  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/312265
ID: 312266  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/312266
ID: 312278  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/312278
ID: 312284  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/312284
ID: 312285  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/312285
ID: 312286  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/312286
ID: 312322  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/312322
ID: 312323  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/312323
ID: 312333  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/312333
ID: 312336  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/312336
ID: 312337  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/312337
ID: 312338  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/312338
ID: 312339  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/312339
ID: 312340  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/312340
ID: 312341  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/312341
ID: 312342  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/312342
ID: 312343  Test: x86_64 universal install_kickstart_user_creation
URL: 

Re: Is Fedora 27 EOL?

[Mohan Boddu]

I am still updating the EOL's in pdc, but some of them should be updated.

I will send another email once all of them are updated.

On Mon, Nov 26, 2018 at 11:10 AM Matthew Miller 
wrote:

> On Mon, Nov 26, 2018 at 10:30:32AM -0500, Ben Cotton wrote:
> > The policy on the wiki[1] says "one month", which is fairly ambiguous.
> > I'll update that to say "four weeks", which is what we mean, but is
> > not the practical interpretation of what we say. Since I dropped the
> > ball on this, let's do the F27 EOL on Friday and I'll fix both the
> > text of the policy and my own workflow to prevent this issue in the
> > future.
>
> For the record, FESCo ticket where 4 weeks / 28 days was made official:
> https://pagure.io/fesco/issue/1750
>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
>
___
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: nsswitch.conf: list of module packages that enables themselves

[Ian Kent]

On Mon, 2018-11-26 at 14:38 +0100, Pavel Březina wrote:
> On 11/26/18 2:21 PM, Stephen Gallagher wrote:
> > On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:
> > > 
> > > This e-mail is long so I just put the question here before explanation:
> > > 
> > > Do you know about any package that installs an nsswitch.conf module and
> > > automatically enables it in /etc/nsswitch.conf? So far I have two
> > > packages - nss-mdns and systemd.
> > > 
> > > Why?
> > > 
> > > As you might have noticed, in Fedora 28 we switched from authconfig to
> > > authselect. This brought some adoption issues and feature requests which
> > > we tried hard to resolved, mostly related to nsswitch.conf. Thank you
> > > for all your feedback.
> > > 
> > > At this point I am aware of only one nsswitch.conf related issue that we
> > > would like to fix. The problem is that when you choose to use authselect
> > > you are no longer allowed to touch /etc/nsswitch.conf (and various file
> > > in /etc/pam.d) manually but you should use authselect and its profiles
> > > instead.
> > > 
> > > However, this does not work well for small environments (possibly single
> > > user machines) where you want to just change something in nsswitch.conf
> > > and do not want to create custom profile. For this, we introduced
> > > /etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
> > > command to do this the authselect way (of course you are free to not use
> > > authselect and just modify the files manually).
> > > 
> > > But there are some packages that installs nsswitch modules and
> > > automatically puts them in /etc/nsswitch.conf in %post which conflicts
> > > with authselect. We would like to provide an authselect call for these
> > > packages, that would make sure it does not conflict with authselect [1].
> > > 
> > > I started working on a design for such feature and I'm trying to obtain
> > > list of all packages that installs nsswitch modules and automatically
> > > enable them in /etc/nsswitch.conf.
> > > 
> > > So far I was able to find these packages:
> > > - nss-altfiles
> > > - nss_db
> > > - nss-mdns
> > > - nss_nis
> > > - nss-pam-ldapd
> > > - nss_updatedb
> > > - sssd
> > > - systemd
> > > 
> > > But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
> > > you know about any other package?
> > > 
> > > Thank you,
> > > Pavel.
> > > 
> > > [1] https://github.com/pbrezina/authselect/issues/77
> > 
> > 
> > IIRC, doesn't autofs also use nsswitch.conf for configuration?
> 
> Yes, but it is not part of glibc. AFAIK it works similar to sudo - 
> lookup automount line in nsswitch.conf and acts according to its 
> settings. But it does not have proper support in glibc.

Yes, automount uses the "automount:" line of nsswitch.conf.

It doesn't mess with nsswitch.conf and I'm not willing to
change a file autofs doesn't own, it's the users responsibility
to set the autofs map sources they need.

Umm .. "proper" ... I'll take that to just mean I don't use
the glibc API rather than a criticism of what I chose to do.

Originally I tried to use the glibc API and I even had autofs
specific nsswitch example code but I found I couldn't do what
I needed. When I did this I didn't have time to work through
the glibc API code to work out if it did provide what I needed
so I wrote my own parser.

If I need to change that then I'll need pointers to adequate
glibc nsswitch API documentation as I still don't want to dive
into the glibc code to work out how do this.

Ian
___
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: Last dbus upgrade issues

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 20:04, Owen Taylor  wrote:
> On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko  
> wrote:
> > 1) if dbus service crashes/is not availaible temporary IMO it wold be
> > good to prepare whole desktop apps code to not crash but handle dbus
> > disconnection and maybe display centered message that it is not
> > possible to connect to dbus. Crashing everything looks really *bad*.
>
> The design of D-Bus is that it is the central point of lifecycle
> management for your desktop - when the session bus goes away,
> everything on it should go away. Trying to make things survive bus
> restart compromises that, and makes it more likely you'll get stray
> processes after exit. Now with systemd user sessions, cgroups, etc, we
> have other mechanisms for session cleanup, but removing the older
> concept of exit-with-the-bus would require major rethinking.

Cleaning the session is perfect example of what can be done with using
Solaris contracts which is kind of grouping attribute for some group
of processes which needs to be treated as the group. When session
needs to be closed all processes which are part of the contract needs
to be killed by contract id (which works like task id or pid).
Lack of contacts is IMO another cause current systemd complexity
(Solaris SMF for example kills all service processes by not looking
for all PIDs but simple by killing all processes with the same ctid).
Is it any other propose of the dbus communication? (my question is
more about original initial design than what is now)
I'm asking because I do not fully understand of the cause why dbus has
been designed and to solve current design issue original cause of
erecting/designing such communication needs to be well understood.

> Plus, when the connection to the bus is lost, all assumptions that the
> app has about the state of the system are invalid. (Normally, with
> D-Bus you reliably get messages, or you reliably get notification when
> your communication partner goes away.) So the app state needs to be
> reinitialized from scratch. There's significant code complexity there
> which will be exercised in only very rare circumstance.

Looks like again contracts could solve such scenarios with sending
normal signal to PID 1 (like HUP) with masking to be received by all
processes with the same ctid. No new communication or protocols ..
just minute modifications of well known signal handlers.
https://docs.oracle.com/cd/E18752_01/html/816-5174/contract-4.html#REFMAN4contract-4
This idea already is used on live systems from more than decade.

kloczek
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Dennis Gilmore]

El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió:
> On Mon, Nov 26, 2018 at 5:01 PM Peter Robinson 
> wrote:
> > On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller <
> > mat...@fedoraproject.org> wrote:
> > > On Mon, Nov 26, 2018 at 08:02:26PM +, Peter Robinson wrote:
> > > > transactions is substantial. This may solve (or greatly reduce)
> > > > the
> > > > compose speed problem, TBD." but it doesn't report the context
> > > > of the
> > > > "speed increase for transactions"  like which transactions?
> > > > There's a lot of I/O heavy processes in the compose, like
> > > > createrepo,
> > > > that don't run any rpm tracsactions what so ever.
> > > 
> > > It seems like there's a lot of room to optimize those things too.
> > > For
> > > example, extract the needed metadata into a database and update
> > > that at
> > > build time rather than compose time, and run createrepo against
> > > that instead
> > > of rpms directly.
> > 
> > Completely agree there's a LOT of improvement that can be done, but
> > I
> > don't see why that development work cannot be done in parallel and
> > put
> > it into production when each of the various different components
> > are
> 
> Because the people that would be tasked with doing the development
> are
> also tasked with cranking out the release.  It's a "need more people
> problem".

This is no longer entirely true, development of the compose tools is
done entirely by PNT DevOps today. Bodhi and other tools in parts of
the delivery pipeline are developed by people in Fedora Engineering who
also have other tasks to do.

> > ready to go. Ultimately a lot of those sort of ways of optimising
> > things are things that have been known for some time but no one has
> > actually stepped up to do the dev work and it it into production
> > shape. Stopping the standard distro work won't miraculously make
> > that
> > other work happen and appear.
> 
> Well, I kind of disagree.  Barring magical people that appear out of
> the woodwork that know how the tools work and how they need to be
> improved, I don't see an alternative.  Not doing a release to focus
> on
> our tech debt seems like a good tradeoff.  If there are others that
> really WANT to continue cranking the release with the tools as they
> are today... that might be something that could be pursued.  It would
> still require net new contributors to a critical area.

We would need to engage with the team working on the compose tools and
see what time they can dedicate to meeting Fedora's needs.  Likely a
end state needs to be defined. then the work can be scoped. 

Dennis


signature.asc
Description: This is a digitally signed message part
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Josh Boyer]

On Mon, Nov 26, 2018 at 5:01 PM Peter Robinson  wrote:
>
> On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller  
> wrote:
> >
> > On Mon, Nov 26, 2018 at 08:02:26PM +, Peter Robinson wrote:
> > > transactions is substantial. This may solve (or greatly reduce) the
> > > compose speed problem, TBD." but it doesn't report the context of the
> > > "speed increase for transactions"  like which transactions?
> > > There's a lot of I/O heavy processes in the compose, like createrepo,
> > > that don't run any rpm tracsactions what so ever.
> >
> > It seems like there's a lot of room to optimize those things too. For
> > example, extract the needed metadata into a database and update that at
> > build time rather than compose time, and run createrepo against that instead
> > of rpms directly.
>
> Completely agree there's a LOT of improvement that can be done, but I
> don't see why that development work cannot be done in parallel and put
> it into production when each of the various different components are

Because the people that would be tasked with doing the development are
also tasked with cranking out the release.  It's a "need more people
problem".

> ready to go. Ultimately a lot of those sort of ways of optimising
> things are things that have been known for some time but no one has
> actually stepped up to do the dev work and it it into production
> shape. Stopping the standard distro work won't miraculously make that
> other work happen and appear.

Well, I kind of disagree.  Barring magical people that appear out of
the woodwork that know how the tools work and how they need to be
improved, I don't see an alternative.  Not doing a release to focus on
our tech debt seems like a good tradeoff.  If there are others that
really WANT to continue cranking the release with the tools as they
are today... that might be something that could be pursued.  It would
still require net new contributors to a critical area.

josh
___
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: Bugzilla outage/upgrade on 2 December 2018

[Jeff Fearn]

On 27/11/18 02:06, Emmanuel Seyman wrote:
> * Neal Gompa [26/11/2018 11:01] :
>>
>> Out of curiosity, does anyone know where the source code for Red Hat
>> Bugzilla actually is? I tried to find it a while ago, and even tried
>> to send an email asking about it (with no response...). This variant
>> of Bugzilla has features that aren't present in vanilla Bugzilla 5.x,
>> nor are they present in the Mozilla fork (bmo)...
> 
> The source code isn't avaliable (although I've been told at least one
> Bugzilla developer has access to it).
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=478886

This is correct. We are in a very drawn out, and painful, process to get
this opened up.

Dylan from BMO is helping us out by doing an audit for us, but he is
doing it as a favor, in his own time, so it's taking about as long as
you'd expect to audit a 20 year old code base in your spare time.

Once Dylan is done, and we are putting no pressure on him to meet or
specify a time line, I'll do another round of infosec/product security
team hand shaking and then we should be able to open it.

Cheers, Jeff.
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller  wrote:
>
> On Mon, Nov 26, 2018 at 08:02:26PM +, Peter Robinson wrote:
> > transactions is substantial. This may solve (or greatly reduce) the
> > compose speed problem, TBD." but it doesn't report the context of the
> > "speed increase for transactions"  like which transactions?
> > There's a lot of I/O heavy processes in the compose, like createrepo,
> > that don't run any rpm tracsactions what so ever.
>
> It seems like there's a lot of room to optimize those things too. For
> example, extract the needed metadata into a database and update that at
> build time rather than compose time, and run createrepo against that instead
> of rpms directly.

Completely agree there's a LOT of improvement that can be done, but I
don't see why that development work cannot be done in parallel and put
it into production when each of the various different components are
ready to go. Ultimately a lot of those sort of ways of optimising
things are things that have been known for some time but no one has
actually stepped up to do the dev work and it it into production
shape. Stopping the standard distro work won't miraculously make that
other work happen and appear.
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Matthew Miller]

On Mon, Nov 26, 2018 at 08:02:26PM +, Peter Robinson wrote:
> transactions is substantial. This may solve (or greatly reduce) the
> compose speed problem, TBD." but it doesn't report the context of the
> "speed increase for transactions"  like which transactions?
> There's a lot of I/O heavy processes in the compose, like createrepo,
> that don't run any rpm tracsactions what so ever.

It seems like there's a lot of room to optimize those things too. For
example, extract the needed metadata into a database and update that at
build time rather than compose time, and run createrepo against that instead
of rpms directly.



-- 
Matthew Miller

Fedora Project Leader
___
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

Fedora rawhide compose report: 20181126.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181125.n.0
NEW: Fedora-Rawhide-20181126.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:1
Upgraded packages:   30
Downgraded packages: 1

Size of added packages:  0 B
Size of dropped packages:44.95 KiB
Size of upgraded packages:   372.27 MiB
Size of downgraded packages: 4.96 MiB

Size change of upgraded packages:   -3.52 MiB
Size change of downgraded packages: -3.20 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: python-nectar-1.5.6-4.fc29
Summary: A download library that separates workflow from implementation details
RPMs:python2-nectar
Size:44.95 KiB


= UPGRADED PACKAGES =
Package:  cobbler-2.8.4-3.fc30
Old package:  cobbler-2.8.3-4.fc29
Summary:  Boot server configurator
RPMs: cobbler cobbler-web koan
Size: 3.01 MiB
Size change:  14.57 KiB
Changelog:
  * Sat Nov 24 2018 Orion Poplawski  - 2.8.4-1
  - Update to 2.8.4 (Fixes BZ 1613292, 1643860, 1614433, CVE-2018-1000226, 
CVE-2018-10931)

  * Sun Nov 25 2018 Orion Poplawski  - 2.8.4-2
  - Make koan require python2-ethtool (BZ 1638933)

  * Sun Nov 25 2018 Orion Poplawski  - 2.8.4-3
  - Use pathfix.py to fix python shebangs


Package:  cqrlog-2.3.0-3.fc30
Old package:  cqrlog-2.3.0-2.fc29
Summary:  An amateur radio contact logging program
RPMs: cqrlog
Size: 35.15 MiB
Size change:  -2.62 KiB
Changelog:
  * Sat Oct 27 2018 Jim Lieb  - 2.3.0-3
  - Fix mysql/mariadb client lib search path

  * Fri Nov 09 2018 Richard Shaw  - 2.3.0-3
  - Clean up scripts that are no longer required by the packaging guidelines.


Package:  dbus-broker-16-6.fc30
Old package:  dbus-broker-16-4.fc30
Summary:  Linux D-Bus Message Broker
RPMs: dbus-broker
Size: 843.34 KiB
Size change:  1.05 KiB
Changelog:
  * Sun Nov 25 2018 Tom Gundersen  - 16-4
  - fix SELinux bug

  * Mon Nov 26 2018 Tom Gundersen  - 16-5
  - use full paths when calling binaries from rpm scripts


Package:  egl-wayland-1.1.0-0.2.20181015git0eb29d4.fc30
Old package:  egl-wayland-1.1.0-0.1.20180916git1676d1d.fc30
Summary:  Wayland EGL External Platform library
RPMs: egl-wayland egl-wayland-devel
Size: 248.67 KiB
Size change:  1.86 KiB
Changelog:
  * Mon Nov 26 2018 Leigh Scott  - 
1.1.0-0.2.20181015git0eb29d4
  - Update to latest git snapshot (rhbz#1653118)


Package:  gmsh-4.0.6-1.fc30
Old package:  gmsh-4.0.5-1.fc30
Summary:  A three-dimensional finite element mesh generator
RPMs: gmsh gmsh-common gmsh-devel gmsh-devel-private gmsh-doc gmsh-libs 
gmsh-mpich gmsh-mpich-devel gmsh-mpich-devel-private gmsh-mpich-libs 
gmsh-openmpi gmsh-openmpi-devel gmsh-openmpi-devel-private gmsh-openmpi-libs 
python3-gmsh python3-gmsh-private
Size: 100.44 MiB
Size change:  17.06 KiB
Changelog:
  * Sun Nov 25 2018 Sandro Mani  - 4.0.6-1
  - Update to 4.0.6


Package:  golang-github-vbatts-tar-split-0.11.1-1.fc30
Old package:  golang-github-vbatts-tar-split-0.11.0-1.fc30
Summary:  Tar archive assembly/dis-assembly
RPMs: golang-github-vbatts-tar-split 
golang-github-vbatts-tar-split-devel
Size: 6.44 MiB
Size change:  1.20 KiB
Changelog:
  * Fri Nov 23 2018 Steve Baker  - 0.11.1-1
  - rebuilt for upstream 0.11.1


Package:  moin-1.9.10-1.fc30
Old package:  moin-1.9.9-5.fc29
Summary:  MoinMoin is a WikiEngine to collaborate on easily editable web 
pages
RPMs: moin
Size: 12.05 MiB
Size change:  74.87 KiB
Changelog:
  * Sun Nov 25 2018 Athmane Madjoudj  - 1.9.10-1
  - Update to 1.9.10 (rhbz #1641242)
  - Remove the backported patch
  - Minor spec fix: README path and py2/env shebang


Package:  octave-image-2.8.1-1.fc30
Old package:  octave-image-2.8.0-1.fc30
Summary:  Image processing for Octave
RPMs: octave-image
Size: 3.61 MiB
Size change:  1.25 KiB
Changelog:
  * Sun Nov 25 2018 Orion Poplawski  - 2.8.1-1
  - Update to 2.8.1


Package:  pam-1.3.1-10.fc30
Old package:  pam-1.3.1-9.fc30
Summary:  An extensible library which provides authentication for 
applications
RPMs: pam pam-devel
Size: 4.58 MiB
Size change:  3.41 KiB
Changelog:
  * Sun Nov 25 2018 Bj??rn Esser  - 1.3.1-10
  - Fix passphraseless sudo with crypt_checksalt (#1653023)


Package:  pcb-rnd-2.1.0-1.fc30
Old package:  pcb-rnd-2.0.1-1.fc30
Summary:  Modular Printed Circuit Board layout tool
RPMs: pcb-rnd pcb-rnd-auto pcb-rnd-cloud pcb-rnd-core pcb-rnd-debug 
pcb-rnd-doc pcb-rnd-export pcb-rnd-export-extra pcb-rnd-export-sim 
pcb-rnd-extra pcb-rnd-hid-gtk2-gdk pcb-rnd-hid-gtk2-gl pcb-rnd-hid-lesstif 
pcb-rnd-import-geo pcb-rnd-import-net pcb-rnd-io-alien pcb-rnd-io-standard 
pcb-rnd-lib-gl pcb-rnd-lib-gtk pcb-rnd-lib-gui pcb-rnd-lib-io
Size: 12.16 MiB
Size change:  705.84 KiB
Changelog:
  * Sun Nov 25 2018 Alain Vigne  2.1.0-1
  - New 2.1.0 upstream

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Igor Gnatenko]

On Mon, Nov 26, 2018, 20:09 Randy Barlow  On Mon, 2018-11-26 at 17:23 +0100, Igor Gnatenko wrote:
> > > * really actually for real gated Rawhide
> >
> > Is the "creating side tag for chain builds or by automated requests"
> > is planned here?
> > When I deal with rust packages, I often need to build some update
> > which will break other packages and I need to fix them, but if
> > something will prevent going that build in buildroot.
>
> Hey Igor!
>

Hey Randy,

Indeed, I do plan to have Bodhi manage side tags in order to accomplish
> this. There's a Bodhi kanban board that covers the various items
> planned to be part of this:
>
> https://github.com/fedora-infra/bodhi/projects/3
>
> You can see that a few of the cards in there relate to side tags. My
> current thinking is that you will be able to create a side tag update,
> which will work slightly different than a normal update in a few ways:
>
> * You create the side tag update before you make any builds, instead of
>   after.
> * The side tag update makes, well, a side tag in Koji for you.
> * You go build all the builds you need in your side tag.
> * When you are done, you tell Bodhi you are ready to go to testing, and
>   it will work like a normal update from there on.
>
> Does that sound useful to you?
>

It definitely does, just wanted to ensure if it is one of things which is
supposed to be worked on if we skip release.

___
> 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
>
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Kevin Fenzi]

On 11/26/18 11:55 AM, Paul Frields wrote:
> On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson
>>
>> While we're on the topic of unicorns, if I were the person actually in
>> charge of this and had the freedom to do it how I wanted, what I'd
>> really want to do is create a much more *modular* compose process,
>> where inputs and outputs were defined and associated with each other,
>> and you could easily define subsets to be produced at different times
>> for different reasons. Not a compose, but a Compose Construction Kit. A
>> big chunk of the length of "the compose" is associated with the fact
>> that we define "the compose" as a single thing which produces (last
>> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
>> right now we need a compose which produces A, B, C and D from the
>> minimum necessary sets of inputs', that would be a massive improvement.
>>
>> This hasn't been true for a while (we actually have something like half
>> a dozen or more different "composes", right now), but the system is
>> still less flexible and it's still more difficult to configure
>> different composes than it really ought to be.

Agreed, that would be nice. The one issue I see off hand is that koji
tags are kind of expensive so we can't just tag everything the way we
may want to, but perhaps we can come up with some clever workflow for that.

> Adam puts his finger on an important aspect of the work, which is to
> "decompose the compose" (sorry). We need the ability to produce enough
> A, B, C and D (abusing his example) to do integration tests for
> specific inputs, such that maintainers get feedback in a reasonable
> timeframe on their builds. 

Yeah, thats long been a desire of releng/qa... weeding out the obviously
broken would be very nice.

>With that, gating Rawhide can be an actual
> thing.

Indeed.

kevin



signature.asc
Description: OpenPGP digital signature
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Stephen Gallagher]

On Mon, Nov 26, 2018 at 3:34 PM Peter Robinson  wrote:
>
> On Mon, Nov 26, 2018 at 8:22 PM Stephen Gallagher  wrote:
> >
> > On Mon, Nov 26, 2018 at 3:03 PM Peter Robinson  wrote:
> > > There's no facts or details, to quote "The reported speed increase for
> > > transactions is substantial. This may solve (or greatly reduce) the
> > > compose speed problem, TBD." but it doesn't report the context of the
> > > "speed increase for transactions"  like which transactions?
> > > There's a lot of I/O heavy processes in the compose, like createrepo,
> > > that don't run any rpm tracsactions what so ever.
> >
> > Paul was referring to image creation here. We should be able to get a
> > fairly significant (at least one order of magnitude) speed-up on
> > creating any image that runs an RPM installation transaction. I'm not
> > sure how much that will save in the *whole* compose process, but as
> > it's an identified spot where we know how to optimize it, we should do
> > so.
>
> But ultimately removing rpm transactions is an optimisation to rpm
> which, when it lands, the compose plus numerous other compoents that
> use that code path will just consume and at that point get the
> benefits of, it's not a reason to skip a release nor is it going to be
> a revolution that gets the composes down to an hour. I don't believe
> that that alone is and order of magnitude change, do you have any
> actual hard figured to back the statement up?

Paul overstated the general importance of the scriptlet work. As I
said above, it will affect the RPM transactions. Will Woods has
numbers on the actual performance gains that I'm sure he'll share on
this thread at some point. I said above "I'm not sure how much that
will save in the *whole* compose process" and I meant that. I'm not
advocating that we postpone F31 solely for these changes. At the same
time, let's be careful not to slip into a "perfect is the enemy of
good" situation where we start critiquing individual solutions as not
having enough of an effect.
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 8:22 PM Stephen Gallagher  wrote:
>
> On Mon, Nov 26, 2018 at 3:03 PM Peter Robinson  wrote:
> > There's no facts or details, to quote "The reported speed increase for
> > transactions is substantial. This may solve (or greatly reduce) the
> > compose speed problem, TBD." but it doesn't report the context of the
> > "speed increase for transactions"  like which transactions?
> > There's a lot of I/O heavy processes in the compose, like createrepo,
> > that don't run any rpm tracsactions what so ever.
>
> Paul was referring to image creation here. We should be able to get a
> fairly significant (at least one order of magnitude) speed-up on
> creating any image that runs an RPM installation transaction. I'm not
> sure how much that will save in the *whole* compose process, but as
> it's an identified spot where we know how to optimize it, we should do
> so.

But ultimately removing rpm transactions is an optimisation to rpm
which, when it lands, the compose plus numerous other compoents that
use that code path will just consume and at that point get the
benefits of, it's not a reason to skip a release nor is it going to be
a revolution that gets the composes down to an hour. I don't believe
that that alone is and order of magnitude change, do you have any
actual hard figured to back the statement up?
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Stephen Gallagher]

On Mon, Nov 26, 2018 at 3:03 PM Peter Robinson  wrote:
> There's no facts or details, to quote "The reported speed increase for
> transactions is substantial. This may solve (or greatly reduce) the
> compose speed problem, TBD." but it doesn't report the context of the
> "speed increase for transactions"  like which transactions?
> There's a lot of I/O heavy processes in the compose, like createrepo,
> that don't run any rpm tracsactions what so ever.

Paul was referring to image creation here. We should be able to get a
fairly significant (at least one order of magnitude) speed-up on
creating any image that runs an RPM installation transaction. I'm not
sure how much that will save in the *whole* compose process, but as
it's an identified spot where we know how to optimize it, we should do
so.
___
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: prevent accidentally creating branches in dist-git

[Jason L Tibbitts III]

I filed https://pagure.io/fedora-infrastructure/issue/7398 to see if the
infrastructure folks (or pingou or whoever) would be willing to turn
this on for all existing repositories.

 - J<
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:52 PM Paul Frields  wrote:
>
> On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson  wrote:
> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> >  wrote:
> > >
> > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
> > > >  wrote:
> > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > Here's the summary from the page, which proposes we pause the 
> > > > > > release
> > > > > > after F30 for these efforts:
> > > > >
> > > > > I know it was a big time-off holiday week in the US, but I expected a 
> > > > > little
> > > > > more interest in this post. Perhaps it seemed like too much text to 
> > > > > digest
> > > > > along with turkey and stuffing. :) I'm highlighting it with a subject
> > > > > reflecting the big, direct impact, and here's some other top-level
> > > > > proposals:
> > > > >
> > > > > * embrace Taiga (an open source kanban tool) for project planning
> > > > > * fix the compose speed (target: one hour!)
> > > >
> > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > done analysis.
> > >
> > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > have both looked into it before.
> >
> > Yes, I mean recently, I was involved in the last time we attempted
> > this, and there was a number of things identified but quite a bit has
> > changed since that last happened.
>
> One of the large factors -- which I think was noted in the page -- was
> RPM scriptlets. Stephen Gallagher met with WIll Woods and James Antill
> just recently to talk about this. The time savings was substantial.
> Combining that with reducing the size of "speculative composes" that

There's no facts or details, to quote "The reported speed increase for
transactions is substantial. This may solve (or greatly reduce) the
compose speed problem, TBD." but it doesn't report the context of the
"speed increase for transactions"  like which transactions?
There's a lot of I/O heavy processes in the compose, like createrepo,
that don't run any rpm tracsactions what so ever.
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Matthew Miller]

On Mon, Nov 26, 2018 at 11:39:52AM -0800, Adam Williamson wrote:
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.

+1000


-- 
Matthew Miller

Fedora Project Leader
___
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: Last dbus upgrade issues

[Jan Pokorný]

Hello ,

On 26/11/18 15:12 +0100, Tom Gundersen wrote:
> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
> wrote:
> 
>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>> zbys...@in.waw.pl> wrote:
>> 
>>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
 After last dbus upgrade gdm found that is not able to start.

[...] 

> Thanks for the report, and sorry for the inconvenience. There was indeed a
> bug in the dbus-broker spec file, which we now fixed with version 16-7
> (should land in rawhide any minute).

Thanks for sparing others if not early adopters (nicely demonstrated
like even mere-text-mode-friendly available tooling is dependent on
this single central point these days, NetworkManager/nmtui, even
dhclient complained about DBus, luckily it worked regardless).

Anyway, I've hit another new incompatibility, preventing me to, e.g.,
run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
Workaround is to switch back to dbus-daemon.service.

-- 
Nazdar,
Jan (Poki)


pgpw4_pEtklQO.pgp
Description: PGP signature
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Paul Frields]

On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson
 wrote:
> On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> > Yeah, I think our goal should be 1 minute... just as realistic as one
> > hour. ;)
> >
> > I have not looked into things recently. However:
> >
> > * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> > some.
> >
> > * We have plans to redo the setup on the s390x builders, which should
> > result in them being much faster. That should help.
> >
> > * I know pungi maintaienrs have been doing some work to make things
> > faster (even in the last release out this morning).
> >
> > All that said, I am not sure there's going to be a way to get it down to
> > an hour. I think getting it down to 3-4hours may be very helpful tho and
> > might be possible.
>
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.
>
> This hasn't been true for a while (we actually have something like half
> a dozen or more different "composes", right now), but the system is
> still less flexible and it's still more difficult to configure
> different composes than it really ought to be.

Adam puts his finger on an important aspect of the work, which is to
"decompose the compose" (sorry). We need the ability to produce enough
A, B, C and D (abusing his example) to do integration tests for
specific inputs, such that maintainers get feedback in a reasonable
timeframe on their builds. With that, gating Rawhide can be an actual
thing.

-- 
Paul
___
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: Automating package maintainers responsivity check

[Jason L Tibbitts III]

> "PO" == Peter Oliver  writes:

PO> Also, it's hard to volunteer to co-maintain a package which has a
PO> non-responsive maintainer, because there is no one to grant you
PO> access.

Well, certainly there is but the issue is finding the proper way to ask
for it.  And I don't think we have any well-defined policy for that.
Certainly admin privileges have been in the past to rectify this
sort of situation on a one-off basis.  I've done it a few times when
presented with a reasonable case.

Since the earliest days of pkgdb we've struggled with the best way to
deal with requests for package comaintainership which went unprocessed.
The problem has always been to maintain some reasonable openness while
still allowing maintainers to have some control over what goes into a
package.

And now with the switch to pagure we've lost the means for someone to
request access (though of course bugzilla works as a fallback while
still preserving an audit trail).

Personally I'd propose something like this as a policy:

-
If you are an existing packager and wish to be added as a comaintainer
on a package, you should first communicate with the existing maintainers
via email (pkg-maintain...@fedoraproject.org), on IRC, in person, etc.
But if you receive no response, please open a bugzilla ticket against
the package.  Use "Requesting comaintainer access to PKG" as the ticket
summary.  In the ticket description, please explain why you should be
added as a comaintainer.  (XXX perhaps include more detail on what
someone should say.)

If you have not received a response in (one month/two weeks/???) you may
file a ticket with (FESCo/another group) requesting that you be granted
commit access to the package.  They will review your request and if
warranted grant the requested permissions.

If your need is urgent, perhaps because you are attempting to fix
security issues or significant bugs in a package, you may also wish to
contact the provenpackagers (XXX link) to ask them to merge a pull
request for you.
-

PO> For simple packages that only require a minor version
PO> update, invoking and following through the non-responsive maintainer
PO> process is often more effort than the outstanding work required on
PO> the package.

True, but that's part of why we have provenpackagers.  Certainly if
there's no urgent need then there's no reason to go outside of existing
policy but we should still have something in between "ask
provenpackagers to merge ignored PRs" and "orphan packages because of
unresponsive maintainers".  If someone wants to help maintain a package,
we really should consider just letting them.

 - J<
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Paul Frields]

On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson  wrote:
> On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
>  wrote:
> >
> > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  
> > > wrote:
> > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > Here's the summary from the page, which proposes we pause the release
> > > > > after F30 for these efforts:
> > > >
> > > > I know it was a big time-off holiday week in the US, but I expected a 
> > > > little
> > > > more interest in this post. Perhaps it seemed like too much text to 
> > > > digest
> > > > along with turkey and stuffing. :) I'm highlighting it with a subject
> > > > reflecting the big, direct impact, and here's some other top-level
> > > > proposals:
> > > >
> > > > * embrace Taiga (an open source kanban tool) for project planning
> > > > * fix the compose speed (target: one hour!)
> > >
> > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > done analysis.
> >
> > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > have both looked into it before.
>
> Yes, I mean recently, I was involved in the last time we attempted
> this, and there was a number of things identified but quite a bit has
> changed since that last happened.

One of the large factors -- which I think was noted in the page -- was
RPM scriptlets. Stephen Gallagher met with WIll Woods and James Antill
just recently to talk about this. The time savings was substantial.
Combining that with reducing the size of "speculative composes" that
could be used for CI and other pre-ship purposes could get us to where
we want to be. Stephen's carrying a heavy duty project at the moment
but when that's done in a few weeks, this will be getting more
attention.

> > >  The fact of the matter is that the compose has a LOT of
> > > I/O and I/O is slow and the cost to upgrade the infrastructure to get
> > > high through put I/O is expensive and no one has ever offered the
> > > budget to resolve that problem. The fact of the matter with this is
> > > that we now produce a lot of release artifacts and that takes time,
> > > some of it can probably be run more in parallel, and possibly some
> > > things run at different times but without a combination of investment
> > > in infrastructure, and maybe even hacking and slashing of components
> > > this is not simply a check box.
> >
> > That's why the proposal is to skip an entire release to give us time to
> > work on it. If it was easy, that wouldn't be necessary.
> >
> > There are of course at least *two* possible solutions to "there's lots
> > of I/O". One is "throw money at making the I/O faster", the other is
> > "figure out how to do less I/O".
> >
> > One hour is a *target*, not a *requirement*. I don't think anyone's
> > going to consider the time wasted if we wind up getting it down to two
> > hours instead of one.
> >
> > (Though personally I'd like ten minutes. And two unicorns.)

Just so.

-- 
Paul
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Mohan Boddu]

On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson 
wrote:

> On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> > On 11/26/18 10:58 AM, Peter Robinson wrote:
> > > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> > >  wrote:
> > > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller <
> mat...@fedoraproject.org> wrote:
> > > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > > Here's the summary from the page, which proposes we pause the
> release
> > > > > > > after F30 for these efforts:
> > > > > >
> > > > > > I know it was a big time-off holiday week in the US, but I
> expected a little
> > > > > > more interest in this post. Perhaps it seemed like too much text
> to digest
> > > > > > along with turkey and stuffing. :) I'm highlighting it with a
> subject
> > > > > > reflecting the big, direct impact, and here's some other
> top-level
> > > > > > proposals:
> > > > > >
> > > > > > * embrace Taiga (an open source kanban tool) for project planning
> > > > > > * fix the compose speed (target: one hour!)
> > > > >
> > > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > > done analysis.
> > > >
> > > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > > have both looked into it before.
> > >
> > > Yes, I mean recently, I was involved in the last time we attempted
> > > this, and there was a number of things identified but quite a bit has
> > > changed since that last happened.
> >
> > Yeah, I think our goal should be 1 minute... just as realistic as one
> > hour. ;)
> >
> > I have not looked into things recently. However:
> >
> > * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> > some.
> >
> > * We have plans to redo the setup on the s390x builders, which should
> > result in them being much faster. That should help.
> >
> > * I know pungi maintaienrs have been doing some work to make things
> > faster (even in the last release out this morning).
> >
> > All that said, I am not sure there's going to be a way to get it down to
> > an hour. I think getting it down to 3-4hours may be very helpful tho and
> > might be possible.
>
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.
>
> This hasn't been true for a while (we actually have something like half
> a dozen or more different "composes", right now), but the system is
> still less flexible and it's still more difficult to configure
> different composes than it really ought to be.
>
This would be great.

I want to get to a state where different WG's can run their own composes
by calling a service.

They might actually release on their own schedules as well. (Not all, but
something like Labs or Spins) .

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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
>
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:47 PM Mohan Boddu  wrote:
>
>
>
> On Mon, Nov 26, 2018 at 2:30 PM Kevin Fenzi  wrote:
>>
>> On 11/26/18 10:58 AM, Peter Robinson wrote:
>> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
>> >  wrote:
>> >>
>> >> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
>> >>> On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
>> >>>  wrote:
>>  On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
>> > Here's the summary from the page, which proposes we pause the release
>> > after F30 for these efforts:
>> 
>>  I know it was a big time-off holiday week in the US, but I expected a 
>>  little
>>  more interest in this post. Perhaps it seemed like too much text to 
>>  digest
>>  along with turkey and stuffing. :) I'm highlighting it with a subject
>>  reflecting the big, direct impact, and here's some other top-level
>>  proposals:
>> 
>>  * embrace Taiga (an open source kanban tool) for project planning
>>  * fix the compose speed (target: one hour!)
>> >>>
>> >>> Can I have a unicorn? Everyone wants this bug absolutely no one has
>> >>> done analysis.
>> >>
>> >> I just don't believe this is true. I'm pretty sure Dennis and Kevin
>> >> have both looked into it before.
>> >
>> > Yes, I mean recently, I was involved in the last time we attempted
>> > this, and there was a number of things identified but quite a bit has
>> > changed since that last happened.
>>
>> Yeah, I think our goal should be 1 minute... just as realistic as one
>> hour. ;)
>>
>> I have not looked into things recently. However:
>>
>> * The mock fsync change (https://pagure.io/releng/issue/7909) may help
>> some.
>>
>> * We have plans to redo the setup on the s390x builders, which should
>> result in them being much faster. That should help.
>>
>> * I know pungi maintaienrs have been doing some work to make things
>> faster (even in the last release out this morning).
>>
>> All that said, I am not sure there's going to be a way to get it down to
>> an hour. I think getting it down to 3-4hours may be very helpful tho and
>> might be possible.
>
> I totally agree, also as Peter mentioned, IOT composes are just taking 1 hour 
> as its
> just consuming the repo rather than generating newRepo as the normal
> nightly composes does. If we can generate the newRepo on the fly whenever
> a package gets build and just use the repo to generate the artifacts either
> individually (splitting the compose) or parallely (as we are doing right now 
> mostly)
> that would really help.

Unfortunately the newRepo/installer bit is likely the most I/O
intensive, but I think it we split it out into it's own process, see
mail I just sent, it would be a good start, and then also a good
separate standalone focus for optimizations.

Peter
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:42 PM Adam Williamson
 wrote:
>
> On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> > On 11/26/18 10:58 AM, Peter Robinson wrote:
> > > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> > >  wrote:
> > > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
> > > > >  wrote:
> > > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > > Here's the summary from the page, which proposes we pause the 
> > > > > > > release
> > > > > > > after F30 for these efforts:
> > > > > >
> > > > > > I know it was a big time-off holiday week in the US, but I expected 
> > > > > > a little
> > > > > > more interest in this post. Perhaps it seemed like too much text to 
> > > > > > digest
> > > > > > along with turkey and stuffing. :) I'm highlighting it with a 
> > > > > > subject
> > > > > > reflecting the big, direct impact, and here's some other top-level
> > > > > > proposals:
> > > > > >
> > > > > > * embrace Taiga (an open source kanban tool) for project planning
> > > > > > * fix the compose speed (target: one hour!)
> > > > >
> > > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > > done analysis.
> > > >
> > > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > > have both looked into it before.
> > >
> > > Yes, I mean recently, I was involved in the last time we attempted
> > > this, and there was a number of things identified but quite a bit has
> > > changed since that last happened.
> >
> > Yeah, I think our goal should be 1 minute... just as realistic as one
> > hour. ;)
> >
> > I have not looked into things recently. However:
> >
> > * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> > some.
> >
> > * We have plans to redo the setup on the s390x builders, which should
> > result in them being much faster. That should help.
> >
> > * I know pungi maintaienrs have been doing some work to make things
> > faster (even in the last release out this morning).
> >
> > All that said, I am not sure there's going to be a way to get it down to
> > an hour. I think getting it down to 3-4hours may be very helpful tho and
> > might be possible.
>
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.
>
> This hasn't been true for a while (we actually have something like half
> a dozen or more different "composes", right now), but the system is
> still less flexible and it's still more difficult to configure
> different composes than it really ought to be.

Yes, that was one of the ideas I had. Basically do the "newRepo" part
of the compose that generates the new set of tagged in and signed rpms
and base network isntallers 3-4 times a day and then run all the other
components separately (live/arm images, CoreOS, IoT, cloud images) on
their own schedule in separate components consuming the updates. This
is basically what some of the bits do now as you'd indicated. It then
allows focus to be put on each component to speed each piece up
independently rather than as a whole.

Peter
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Mohan Boddu]

On Mon, Nov 26, 2018 at 2:30 PM Kevin Fenzi  wrote:

> On 11/26/18 10:58 AM, Peter Robinson wrote:
> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> >  wrote:
> >>
> >> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> >>> On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller <
> mat...@fedoraproject.org> wrote:
>  On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
> 
>  I know it was a big time-off holiday week in the US, but I expected a
> little
>  more interest in this post. Perhaps it seemed like too much text to
> digest
>  along with turkey and stuffing. :) I'm highlighting it with a subject
>  reflecting the big, direct impact, and here's some other top-level
>  proposals:
> 
>  * embrace Taiga (an open source kanban tool) for project planning
>  * fix the compose speed (target: one hour!)
> >>>
> >>> Can I have a unicorn? Everyone wants this bug absolutely no one has
> >>> done analysis.
> >>
> >> I just don't believe this is true. I'm pretty sure Dennis and Kevin
> >> have both looked into it before.
> >
> > Yes, I mean recently, I was involved in the last time we attempted
> > this, and there was a number of things identified but quite a bit has
> > changed since that last happened.
>
> Yeah, I think our goal should be 1 minute... just as realistic as one
> hour. ;)
>
> I have not looked into things recently. However:
>
> * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> some.
>
> * We have plans to redo the setup on the s390x builders, which should
> result in them being much faster. That should help.
>
> * I know pungi maintaienrs have been doing some work to make things
> faster (even in the last release out this morning).
>
> All that said, I am not sure there's going to be a way to get it down to
> an hour. I think getting it down to 3-4hours may be very helpful tho and
> might be possible.
>
I totally agree, also as Peter mentioned, IOT composes are just taking 1
hour as its
just consuming the repo rather than generating newRepo as the normal
nightly composes does. If we can generate the newRepo on the fly whenever
a package gets build and just use the repo to generate the artifacts either
individually (splitting the compose) or parallely (as we are doing right
now mostly)
that would really help.

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

[EPEL-devel] Re: New developer toolkit beta

[Tom Callaway]

Just checking in on this again, still need this update to build Chromium
for EPEL7.

~tom

On 11/2/18 1:05 PM, Tom Callaway wrote:
> 
> 
> On 10/30/18 11:19 AM, Stephen John Smoogen wrote:
>> On Tue, 30 Oct 2018 at 10:36, Tom Callaway  wrote:
>>>
>>> https://developers.redhat.com/blog/2018/10/24/gcc-8-and-tools-now-in-beta-for-red-hat-enterprise-linux-6-and-7/
>>>
>>> Can we get this beta into the epel build root? Chromium needs this to build 
>>> again.
>>>
>>
>> I will see what I can do later this week. I need to get the 7.6
>> buildroots 'fixed' and try to work out how many packages need to be
>> rebuilt to work with that.
> 
> Thanks, please reply back when it is done.
> 
> ~tom
> 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Adam Williamson]

On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> On 11/26/18 10:58 AM, Peter Robinson wrote:
> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> >  wrote:
> > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
> > > >  wrote:
> > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > Here's the summary from the page, which proposes we pause the 
> > > > > > release
> > > > > > after F30 for these efforts:
> > > > > 
> > > > > I know it was a big time-off holiday week in the US, but I expected a 
> > > > > little
> > > > > more interest in this post. Perhaps it seemed like too much text to 
> > > > > digest
> > > > > along with turkey and stuffing. :) I'm highlighting it with a subject
> > > > > reflecting the big, direct impact, and here's some other top-level
> > > > > proposals:
> > > > > 
> > > > > * embrace Taiga (an open source kanban tool) for project planning
> > > > > * fix the compose speed (target: one hour!)
> > > > 
> > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > done analysis.
> > > 
> > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > have both looked into it before.
> > 
> > Yes, I mean recently, I was involved in the last time we attempted
> > this, and there was a number of things identified but quite a bit has
> > changed since that last happened.
> 
> Yeah, I think our goal should be 1 minute... just as realistic as one
> hour. ;)
> 
> I have not looked into things recently. However:
> 
> * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> some.
> 
> * We have plans to redo the setup on the s390x builders, which should
> result in them being much faster. That should help.
> 
> * I know pungi maintaienrs have been doing some work to make things
> faster (even in the last release out this morning).
> 
> All that said, I am not sure there's going to be a way to get it down to
> an hour. I think getting it down to 3-4hours may be very helpful tho and
> might be possible.

While we're on the topic of unicorns, if I were the person actually in
charge of this and had the freedom to do it how I wanted, what I'd
really want to do is create a much more *modular* compose process,
where inputs and outputs were defined and associated with each other,
and you could easily define subsets to be produced at different times
for different reasons. Not a compose, but a Compose Construction Kit. A
big chunk of the length of "the compose" is associated with the fact
that we define "the compose" as a single thing which produces (last
time I counted) 70+ deliverables. If we had an easy way to say 'ok,
right now we need a compose which produces A, B, C and D from the
minimum necessary sets of inputs', that would be a massive improvement.

This hasn't been true for a while (we actually have something like half
a dozen or more different "composes", right now), but the system is
still less flexible and it's still more difficult to configure
different composes than it really ought to be.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

[389-devel] please review: PR 50048 - Remove irrelevant debug-log messages from CLI tools

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50048
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Kevin Fenzi]

On 11/26/18 10:58 AM, Peter Robinson wrote:
> On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
>  wrote:
>>
>> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
>>> On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  
>>> wrote:
 On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> Here's the summary from the page, which proposes we pause the release
> after F30 for these efforts:

 I know it was a big time-off holiday week in the US, but I expected a 
 little
 more interest in this post. Perhaps it seemed like too much text to digest
 along with turkey and stuffing. :) I'm highlighting it with a subject
 reflecting the big, direct impact, and here's some other top-level
 proposals:

 * embrace Taiga (an open source kanban tool) for project planning
 * fix the compose speed (target: one hour!)
>>>
>>> Can I have a unicorn? Everyone wants this bug absolutely no one has
>>> done analysis.
>>
>> I just don't believe this is true. I'm pretty sure Dennis and Kevin
>> have both looked into it before.
> 
> Yes, I mean recently, I was involved in the last time we attempted
> this, and there was a number of things identified but quite a bit has
> changed since that last happened.

Yeah, I think our goal should be 1 minute... just as realistic as one
hour. ;)

I have not looked into things recently. However:

* The mock fsync change (https://pagure.io/releng/issue/7909) may help
some.

* We have plans to redo the setup on the s390x builders, which should
result in them being much faster. That should help.

* I know pungi maintaienrs have been doing some work to make things
faster (even in the last release out this morning).

All that said, I am not sure there's going to be a way to get it down to
an hour. I think getting it down to 3-4hours may be very helpful tho and
might be possible.

kevin




signature.asc
Description: OpenPGP digital signature
___
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: nsswitch.conf: list of module packages that enables themselves

[DJ Delorie]

Pavel B™ezina  writes:
> Do you know about any package that installs an nsswitch.conf module and 
> automatically enables it in /etc/nsswitch.conf? So far I have two 
> packages - nss-mdns and systemd.

I don't know about enabling, but it's easy to ask the database what
packages provide NSS modules.  Here's a run from my (sorry, old)
system:

$ dnf whatprovides '/usr/lib64/libnss_*'

sssd-client-1.16.0-4.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-7.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-7.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2

glibc-nss-devel-2.25-13.fc26.x86_64 : Development files for directly linking NSS
: service modules
Filename: /usr/lib64/libnss_compat.so
Filename: /usr/lib64/libnss_db.so
Filename: /usr/lib64/libnss_dns.so
Filename: /usr/lib64/libnss_files.so
Filename: /usr/lib64/libnss_hesiod.so
Filename: /usr/lib64/libnss_nis.so
Filename: /usr/lib64/libnss_nisplus.so

libvirt-nss-3.2.1-7.fc26.x86_64 : Libvirt plugin for Name Service Switch
Filename: /usr/lib64/libnss_libvirt.so.2
Filename: /usr/lib64/libnss_libvirt_guest.so.2

samba-winbind-modules-2:4.6.15-0.fc26.x86_64 : Samba winbind modules
Filename: /usr/lib64/libnss_winbind.so
Filename: /usr/lib64/libnss_winbind.so.2
Filename: /usr/lib64/libnss_wins.so
Filename: /usr/lib64/libnss_wins.so.2

sssd-client-1.16.1-4.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-7.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-7.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2

glibc-nss-devel-2.25-6.fc26.x86_64 : Development files for directly linking NSS
   : service modules
Filename: /usr/lib64/libnss_compat.so
Filename: /usr/lib64/libnss_db.so
Filename: /usr/lib64/libnss_dns.so
Filename: /usr/lib64/libnss_files.so
Filename: /usr/lib64/libnss_hesiod.so
Filename: /usr/lib64/libnss_nis.so
Filename: /usr/lib64/libnss_nisplus.so

libnss-mysql-1.5-26.fc26.x86_64 : NSS library for MySQL
Filename: /usr/lib64/libnss_mysql.so.2
Filename: /usr/lib64/libnss_mysql.so.2.0.0

libnss-pgsql-1.5.0-0.15.beta.fc26.x86_64 : Name Service Switch library that
 : interface with PostgreSQL
Filename: /usr/lib64/libnss_pgsql.so.2
Filename: /usr/lib64/libnss_pgsql.so.2.0.0

libvirt-nss-3.2.1-3.fc26.x86_64 : Libvirt plugin for Name Service Switch
Filename: /usr/lib64/libnss_libvirt.so.2
Filename: /usr/lib64/libnss_libvirt_guest.so.2

netresolve-core-0.0.1-0.17.20160317git.fc26.x86_64 : Core netresolve libraries
Filename: /usr/lib64/libnss_netresolve.so.2
Filename: /usr/lib64/libnss_netresolve.so.2.0.0

netresolve-devel-0.0.1-0.17.20160317git.fc26.x86_64 : Development files for
: netresolve
Filename: /usr/lib64/libnss_netresolve.so

nss-altfiles-2.18.1-8.fc26.x86_64 : NSS module to look up users in
  : /usr/lib/passwd too
Filename: /usr/lib64/libnss_altfiles.so.2

nss-pam-ldapd-0.8.14-8.fc26.x86_64 : An nsswitch module which uses directory
   : servers
Filename: /usr/lib64/libnss_ldap.so
Filename: /usr/lib64/libnss_ldap.so.2

nss_wrapper-1.1.3-2.fc26.x86_64 : A wrapper for the user, group and hosts NSS
: API
Filename: /usr/lib64/libnss_wrapper.so
Filename: /usr/lib64/libnss_wrapper.so.0
Filename: /usr/lib64/libnss_wrapper.so.0.2.3

samba-winbind-modules-2:4.6.5-0.fc26.x86_64 : Samba winbind modules
Filename: /usr/lib64/libnss_winbind.so
Filename: /usr/lib64/libnss_winbind.so.2
Filename: /usr/lib64/libnss_wins.so
Filename: /usr/lib64/libnss_wins.so.2

sssd-client-1.15.2-5.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-6.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-6.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2
___
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 

Re: Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Kevin Fenzi]

On 11/26/18 8:21 AM, Brian (bex) Exelbierd wrote:
> On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller  
> wrote:
>>
>> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
>>> Here's the summary from the page, which proposes we pause the release
>>> after F30 for these efforts:
>>
>> I know it was a big time-off holiday week in the US, but I expected a little
>> more interest in this post. Perhaps it seemed like too much text to digest
>> along with turkey and stuffing. :) I'm highlighting it with a subject
>> reflecting the big, direct impact, and here's some other top-level
>> proposals:
>>
>> * embrace Taiga (an open source kanban tool) for project planning
>> * fix the compose speed (target: one hour!)
>> * really actually for real gated Rawhide
>> * better CI pipeline tests for everything
>> * define a base platform -- Red Hat wants to focus resources here
>> * better tooling for non-base deliverables
>> * better metrics for everything
> 
> I am +100 to these changes.
> 
> The idea that we can essentially not release for a year to do this
> raises the interesting point that perhaps our release cadence is not
> as rigid as we think it may be.  I don't think we are going to skip
> Gnome and other major updates, are we?  If not, then this also runs
> into the conversation about longer lifecycles and whether we need
> releases, imho.

Indeed.

If we push as updates things we normally wait for releases for, would
that disrupt our users?

Is there a cutoff of things we would push in updates? For example, we
usually do mass rebuilds of the entire collection of packages when new
gcc/etc are ready, would we do that as a update in a stable release?

We could solve the rolling changes issue by requiring all major changes
to be modular and not enable the new module (ie, gnome 3.32 releases in
f30, in 6 mmonths 3.34 comes out, we enable it as a new module, users
can choose to switch to if they want, or stay on 3.32 if they ignore it
or don't want to right then). That won't help for tool changes tho.

kevin




signature.asc
Description: OpenPGP digital signature
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Adam Williamson]

On Mon, 2018-11-26 at 20:03 +0100, Fabio Valentini wrote:
> 
> Also, I find it funny that - somehow - tons of resources would be
> available for "better CI pipeline tests for everything" (!), but we'd
> have to "focus resources" when it comes to the fedora "platform"
> itself.

These two sort of go together, I think: we don't truly expect to have
'better CI pipeline tests for EVERYTHING', as in *every package in the
distro*, but rather one advantage of somehow defining the 'Platform' is
that it gives us a *smaller* set of bits to focus the CI work on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Fabio Valentini]

On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller  wrote:
>
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> I know it was a big time-off holiday week in the US, but I expected a little
> more interest in this post.

Hi Matthew,

I initially basically ignored the previous E-Mail,  because it didn't
come from a person I knew, and - from quickly glancing over the
contents - read like marketing fluff. I should have dug deeper there,
but we all only have limited time.

> Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> proposals:

This is definitely getting more attention. Maybe the initial E-Mail
should have had a less bland Subject line, too ;)

> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)
> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * better tooling for non-base deliverables
> * better metrics for everything

Those all sound like good things to work on.

> * define a base platform -- Red Hat wants to focus resources here

This point though ... hmm. Also kind of mentioned on the linked wiki page:

> #3 (...) Define a small, draft set of content for the Platform which can 
> iterate over time

What exactly does that mean? Moving to something two-tiered like the
ubuntu model (main / universe) - which I think is a terrible solution?
(And what would be the names for this in fedora - "core" and "extras"?
(pun definitely intended))

Also, I find it funny that - somehow - tons of resources would be
available for "better CI pipeline tests for everything" (!), but we'd
have to "focus resources" when it comes to the fedora "platform"
itself.

I hope my response doesn't read overly negative or critical - but I
think some fedora contributors (including me) have been weary of
something like this ("focusing resources") since the IBM news got
announced.

Fabio

> Please read 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
> and comment in this thread.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Randy Barlow]

On Mon, 2018-11-26 at 17:23 +0100, Igor Gnatenko wrote:
> > * really actually for real gated Rawhide
> 
> Is the "creating side tag for chain builds or by automated requests"
> is planned here?
> When I deal with rust packages, I often need to build some update
> which will break other packages and I need to fix them, but if
> something will prevent going that build in buildroot.

Hey Igor!

Indeed, I do plan to have Bodhi manage side tags in order to accomplish
this. There's a Bodhi kanban board that covers the various items
planned to be part of this:

https://github.com/fedora-infra/bodhi/projects/3

You can see that a few of the cards in there relate to side tags. My
current thinking is that you will be able to create a side tag update,
which will work slightly different than a normal update in a few ways:

* You create the side tag update before you make any builds, instead of
  after.
* The side tag update makes, well, a side tag in Koji for you.
* You go build all the builds you need in your side tag.
* When you are done, you tell Bodhi you are ready to go to testing, and
  it will work like a normal update from there on.

Does that sound useful to you?


signature.asc
Description: This is a digitally signed message part
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
 wrote:
>
> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  
> > wrote:
> > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > Here's the summary from the page, which proposes we pause the release
> > > > after F30 for these efforts:
> > >
> > > I know it was a big time-off holiday week in the US, but I expected a 
> > > little
> > > more interest in this post. Perhaps it seemed like too much text to digest
> > > along with turkey and stuffing. :) I'm highlighting it with a subject
> > > reflecting the big, direct impact, and here's some other top-level
> > > proposals:
> > >
> > > * embrace Taiga (an open source kanban tool) for project planning
> > > * fix the compose speed (target: one hour!)
> >
> > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > done analysis.
>
> I just don't believe this is true. I'm pretty sure Dennis and Kevin
> have both looked into it before.

Yes, I mean recently, I was involved in the last time we attempted
this, and there was a number of things identified but quite a bit has
changed since that last happened.

> >  The fact of the matter is that the compose has a LOT of
> > I/O and I/O is slow and the cost to upgrade the infrastructure to get
> > high through put I/O is expensive and no one has ever offered the
> > budget to resolve that problem. The fact of the matter with this is
> > that we now produce a lot of release artifacts and that takes time,
> > some of it can probably be run more in parallel, and possibly some
> > things run at different times but without a combination of investment
> > in infrastructure, and maybe even hacking and slashing of components
> > this is not simply a check box.
>
> That's why the proposal is to skip an entire release to give us time to
> work on it. If it was easy, that wouldn't be necessary.
>
> There are of course at least *two* possible solutions to "there's lots
> of I/O". One is "throw money at making the I/O faster", the other is
> "figure out how to do less I/O".
>
> One hour is a *target*, not a *requirement*. I don't think anyone's
> going to consider the time wasted if we wind up getting it down to two
> hours instead of one.
>
> (Though personally I'd like ten minutes. And two unicorns.)
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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
___
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: Last dbus upgrade issues

[Owen Taylor]

On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko  wrote:
> 1) if dbus service crashes/is not availaible temporary IMO it wold be
> good to prepare whole desktop apps code to not crash but handle dbus
> disconnection and maybe display centered message that it is not
> possible to connect to dbus. Crashing everything looks really *bad*.

The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.

Plus, when the connection to the bus is lost, all assumptions that the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.

In general, I don't think being able to replace the bus implementation
on a running system is *that* interesting - sometimes the user will
have to reboot, and if that's too disruptive, we need to work on
making it less disruptive.

Owen
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Adam Williamson]

On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  
> wrote:
> > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > Here's the summary from the page, which proposes we pause the release
> > > after F30 for these efforts:
> > 
> > I know it was a big time-off holiday week in the US, but I expected a little
> > more interest in this post. Perhaps it seemed like too much text to digest
> > along with turkey and stuffing. :) I'm highlighting it with a subject
> > reflecting the big, direct impact, and here's some other top-level
> > proposals:
> > 
> > * embrace Taiga (an open source kanban tool) for project planning
> > * fix the compose speed (target: one hour!)
> 
> Can I have a unicorn? Everyone wants this bug absolutely no one has
> done analysis.

I just don't believe this is true. I'm pretty sure Dennis and Kevin
have both looked into it before.

>  The fact of the matter is that the compose has a LOT of
> I/O and I/O is slow and the cost to upgrade the infrastructure to get
> high through put I/O is expensive and no one has ever offered the
> budget to resolve that problem. The fact of the matter with this is
> that we now produce a lot of release artifacts and that takes time,
> some of it can probably be run more in parallel, and possibly some
> things run at different times but without a combination of investment
> in infrastructure, and maybe even hacking and slashing of components
> this is not simply a check box.

That's why the proposal is to skip an entire release to give us time to
work on it. If it was easy, that wouldn't be necessary.

There are of course at least *two* possible solutions to "there's lots
of I/O". One is "throw money at making the I/O faster", the other is
"figure out how to do less I/O".

One hour is a *target*, not a *requirement*. I don't think anyone's
going to consider the time wasted if we wind up getting it down to two
hours instead of one.

(Though personally I'd like ten minutes. And two unicorns.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 4:23 PM Brian (bex) Exelbierd
 wrote:
>
> On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller  
> wrote:
> >
> > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > Here's the summary from the page, which proposes we pause the release
> > > after F30 for these efforts:
> >
> > I know it was a big time-off holiday week in the US, but I expected a little
> > more interest in this post. Perhaps it seemed like too much text to digest
> > along with turkey and stuffing. :) I'm highlighting it with a subject
> > reflecting the big, direct impact, and here's some other top-level
> > proposals:
> >
> > * embrace Taiga (an open source kanban tool) for project planning
> > * fix the compose speed (target: one hour!)
> > * really actually for real gated Rawhide
> > * better CI pipeline tests for everything
> > * define a base platform -- Red Hat wants to focus resources here
> > * better tooling for non-base deliverables
> > * better metrics for everything
>
> I am +100 to these changes.
>
> The idea that we can essentially not release for a year to do this
> raises the interesting point that perhaps our release cadence is not
> as rigid as we think it may be.  I don't think we are going to skip
> Gnome and other major updates, are we?  If not, then this also runs
> into the conversation about longer lifecycles and whether we need
> releases, imho.

I like some of the ideas here but I feel we need to have an extremely
well defined set of problems to be solved else we'll delay the
release, achieve very little, and either never release again or not
have anything achieved except a waste of time.
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  wrote:
>
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> I know it was a big time-off holiday week in the US, but I expected a little
> more interest in this post. Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> proposals:
>
> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)

Can I have a unicorn? Everyone wants this bug absolutely no one has
done analysis. The fact of the matter is that the compose has a LOT of
I/O and I/O is slow and the cost to upgrade the infrastructure to get
high through put I/O is expensive and no one has ever offered the
budget to resolve that problem. The fact of the matter with this is
that we now produce a lot of release artifacts and that takes time,
some of it can probably be run more in parallel, and possibly some
things run at different times but without a combination of investment
in infrastructure, and maybe even hacking and slashing of components
this is not simply a check box.

For example the IoT compose takes around an hour but ATM we currently
produce 5 artifacts, mostly in parallel, and don't do things like
newRepo for the base rpms because we consume that from the main
compose.

> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * define a base platform -- Red Hat wants to focus resources here
> * better tooling for non-base deliverables
> * better metrics for everything

They are very nice top level ideas, but each of those components need
to have in depth analysis and not just the hand wavy overview in the
link below.

> Please read 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
> and comment in this thread.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
___
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: Orphaned Packages in rawhide (2018-09-07)

[Miro Hrončok]

On 11. 10. 18 12:00, Fabio Valentini wrote:

Are there plans to publish the orphaned packages report regularly? I
seem to remember that it was a weekly thing at some point in the past
...


Yes, I plan to work on that.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Last dbus upgrade issues

[Adam Williamson]

On Mon, 2018-11-26 at 15:12 +0100, Tom Gundersen wrote:
> Hi Tomasz,
> 
> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
> wrote:
> 
> > On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> > 
> > > On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> > > > After last dbus upgrade gdm found that is not able to start.
> > > 
> > > What Fedora version? Ideally provide specific rpm versions.
> > > dbus-in-F29 != dbus-in-F30 now.
> > > 
> > 
> > I’m talking about F30 recent change in which has been implemented switch
> > to dubs-broker.
> > 
> 
> Thanks for the report, and sorry for the inconvenience. There was indeed a
> bug in the dbus-broker spec file, which we now fixed with version 16-7
> (should land in rawhide any minute).

Per https://bugzilla.redhat.com/show_bug.cgi?id=1653059#c25 I believe
this is still wrong, and - intentionally or otherwise - significantly
out of the scope of the Change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Last dbus upgrade issues

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 17:44, Tomasz Torcz  wrote:
[..]
>   Feel free to provide patches.  There was 15 years to fix it.
>
>   Alternatively, dbus-broker may store fds in systemd and serialize state
> over restarts.

So you want to say that in reality it is dbus communication protocol
issue? (protocol is not stateless like for example NFS).
Good to know. .. thx.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Last dbus upgrade issues

[Tomasz Torcz]

On Mon, Nov 26, 2018 at 03:57:25PM +0100, Tomasz Kłoczko wrote:
> On Mon, 26 Nov 2018 at 15:19, Tom Gundersen  wrote:
> [..]
> >>> What Fedora version? Ideally provide specific rpm versions.
> >>> dbus-in-F29 != dbus-in-F30 now.
> >>
> >> I’m talking about F30 recent change in which has been implemented switch 
> >> to dubs-broker.
> >
> > Thanks for the report, and sorry for the inconvenience.
> 
> np .. when tree is chopped chops are flying around :)
> 
> >  There was indeed a bug in the dbus-broker spec file, which we now fixed 
> > with version 16-7 (should land in rawhide any minute).
> 
> IMO it would be good to learn something out of that small fault
> because few thing went really odd way.
> 
> 1) if dbus service crashes/is not availaible temporary IMO it wold be
> good to prepare whole desktop apps code to not crash but handle dbus
> disconnection and maybe display centered message that it is not
> possible to connect to dbus. Crashing everything looks really *bad*.
> 
> 3) any other dependency on running dbus service should be IMO closely
> investigated and if something is just crashing it should be
> changed/redesigned to handle this to at least log that  to system logs
> (nothing like this after all was possible to find in systemd journal
> or rsyslogd logs).

  Feel free to provide patches.  There was 15 years to fix it.

  Alternatively, dbus-broker may store fds in systemd and serialize state
over restarts.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox
___
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

Tune boinc-client spec file in order to ease debugging process

[Germano Massullo]

Hi everybody, I am debugging boinc-manager, and everytime I run 
$ gdb boincmgr
(gdb) run
then I trigger the crash, after running
(gdb) thread apply all backtrace
I obtain stuff like
[...] argc=
so I need help in tuning the boinc-client spec file[1] in order to avoid that 
(for example using gcc -O0).
To begin, I started removing -DNDEBUG flag in order to re-enable the wxWidgets 
debug standard output.

Thank you for your time

[1]: 
https://src.fedoraproject.org/rpms/boinc-client/blob/master/f/boinc-client.spec#_167
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[mcatanzaro]

On Mon, Nov 26, 2018 at 10:03 AM, Matthew Miller 
 wrote:
I know it was a big time-off holiday week in the US, but I expected a 
little
more interest in this post. Perhaps it seemed like too much text to 
digest

along with turkey and stuffing. :) I'm highlighting it with a subject
reflecting the big, direct impact, and here's some other top-level
proposals:


Can we use this as an opportunity to work out how to use the blocker 
bugs process for a megaupdate? Our reputation for providing an 
up-to-date desktop took a hit last time we did this, so we'll want to 
provide a GNOME 3.34 megaupdate in October 2019 to compensate for the 
missing Fedora release there. We'll need a monthslong testing process 
for this to go smoothly mid-release.


Michael
___
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: Dec 2018 Fedora Elections: Nomination & Campaign period is open

[Ben Cotton]

This is your reminder that the nomination period for Fedora elections
ends 2018-Nov-28 at 23:59:59 UTC. Submit your nominations for the
steering bodies at the wiki links below.

* FESCo (Engineering) (5 seats) [1]
* Fedora Council (1 seat) [2]
* Mindshare (1 seat) [3]

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Igor Gnatenko]

On Mon, Nov 26, 2018 at 5:14 PM Matthew Miller  wrote:
>
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> I know it was a big time-off holiday week in the US, but I expected a little
> more interest in this post. Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> proposals:
>
> * embrace Taiga (an open source kanban tool) for project planning

That would be good, however I don't know how it is related to
lifecycle of distro.

P.S. would be great if someone finishes packaging of it (I did a lot
of work here, but not everything).

> * fix the compose speed (target: one hour!)

Do we have analysis of what is taking how much time?

> * really actually for real gated Rawhide

Is the "creating side tag for chain builds or by automated requests"
is planned here?
When I deal with rust packages, I often need to build some update
which will break other packages and I need to fix them, but if
something will prevent going that build in buildroot.

> * better CI pipeline tests for everything

Does it mean that finally someone will make it usable? Do we have
definition of "better"? I've tried to use CI for all rust-* packages,
but it is basically unusable.

* No way to re-trigger tests
* Koji repo is broken even is enabled
(https://pagure.io/fedora-ci/general/issue/14, no single comment for >
0.5 month)
* Doesn't re-trigger after dependency changes
* No way to tell that set of tests should be run on some file pattern
(copy-cating same tests folder to 480 packages is not much fun)

> * define a base platform -- Red Hat wants to focus resources here

Can you elaborate?

> * better tooling for non-base deliverables

Are Ursa Major and Freshmaker included in here?

> * better metrics for everything
>
>
> Please read 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
> and comment in this thread.

I would appreciate having this thread on discourse because since
introduction it is my main place where I try to have such
conversations.

>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
___
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

[389-devel] please review: PR 50045 - dscreate should correctly handle ports that are within a selinux port range

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50045
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Brian (bex) Exelbierd]

On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller  wrote:
>
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> I know it was a big time-off holiday week in the US, but I expected a little
> more interest in this post. Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> proposals:
>
> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)
> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * define a base platform -- Red Hat wants to focus resources here
> * better tooling for non-base deliverables
> * better metrics for everything

I am +100 to these changes.

The idea that we can essentially not release for a year to do this
raises the interesting point that perhaps our release cadence is not
as rigid as we think it may be.  I don't think we are going to skip
Gnome and other major updates, are we?  If not, then this also runs
into the conversation about longer lifecycles and whether we need
releases, imho.

regards,

bex



>
>
> Please read 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
> and comment in this thread.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
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

[EPEL-devel] Re: Broken EPEL updates due to Centos 7.6 delay?

[Stephen John Smoogen]

On Mon, 26 Nov 2018 at 11:00, Christopher  wrote:
>
> On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen  wrote:
> >
> > On Mon, 26 Nov 2018 at 01:03, Christopher  
> > wrote:
> > >
> > > Anybody know what's going on with Centos 7.6-1810?
> > > Some packages in EPEL depend on it, but it is apparently not yet 
> > > available.
> > > This discrepancy is breaking yum updates for me.
> > >
> >
> > This isn't a Fedora development issue. Please refer this to the CentOS
> > or EPEL lists.
> >
>
> EPEL is a Fedora project. My question wasn't really about CentOS, but
> rather, about maintainer best practices for EPEL branches. To clarify,
> my question is whether package maintainers are expected to ensure
> their EPEL branch for their packages works against the latest CentOS
> release (without enabling 'cr' repo) or whether it is expected that
> packages will work as soon as the corresponding RHEL release is
> available (which is usually available about 3-4 weeks earlier). What
> do we use for the EPEL buildroot in koji?
>

Even though EPEL is a Fedora project, the main development and work is
done on the epel-devel@lists.fedoraproject.org mailing list.

EPEL is built from the 'current' state of Red Hat Enterprise Linux as
synced from 'rhn (or whatever they call it these days)' every 12
hours. This means that CentOS users must use CR during the
intermediate time.


> > > For example, xorgxrdp-0.2.8-3.el7 depends on xorg-x11-server-Xorg
> > > 1.20.1, which isn't yet available (rather, available on in the cr
> > > repo, not in CentOS updates yet).
> >
> > --
> > Stephen J Smoogen.
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Broken EPEL updates due to Centos 7.6 delay?

[Stephen John Smoogen]

On Mon, 26 Nov 2018 at 11:00, Christopher  wrote:
>
> On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen  wrote:
> >
> > On Mon, 26 Nov 2018 at 01:03, Christopher  
> > wrote:
> > >
> > > Anybody know what's going on with Centos 7.6-1810?
> > > Some packages in EPEL depend on it, but it is apparently not yet 
> > > available.
> > > This discrepancy is breaking yum updates for me.
> > >
> >
> > This isn't a Fedora development issue. Please refer this to the CentOS
> > or EPEL lists.
> >
>
> EPEL is a Fedora project. My question wasn't really about CentOS, but
> rather, about maintainer best practices for EPEL branches. To clarify,
> my question is whether package maintainers are expected to ensure
> their EPEL branch for their packages works against the latest CentOS
> release (without enabling 'cr' repo) or whether it is expected that
> packages will work as soon as the corresponding RHEL release is
> available (which is usually available about 3-4 weeks earlier). What
> do we use for the EPEL buildroot in koji?
>

Even though EPEL is a Fedora project, the main development and work is
done on the epel-de...@lists.fedoraproject.org mailing list.

EPEL is built from the 'current' state of Red Hat Enterprise Linux as
synced from 'rhn (or whatever they call it these days)' every 12
hours. This means that CentOS users must use CR during the
intermediate time.


> > > For example, xorgxrdp-0.2.8-3.el7 depends on xorg-x11-server-Xorg
> > > 1.20.1, which isn't yet available (rather, available on in the cr
> > > repo, not in CentOS updates yet).
> >
> > --
> > Stephen J Smoogen.
> ___
> 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



-- 
Stephen J Smoogen.
___
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: Is Fedora 27 EOL?

[Matthew Miller]

On Mon, Nov 26, 2018 at 10:30:32AM -0500, Ben Cotton wrote:
> The policy on the wiki[1] says "one month", which is fairly ambiguous.
> I'll update that to say "four weeks", which is what we mean, but is
> not the practical interpretation of what we say. Since I dropped the
> ball on this, let's do the F27 EOL on Friday and I'll fix both the
> text of the policy and my own workflow to prevent this issue in the
> future.

For the record, FESCo ticket where 4 weeks / 28 days was made official:
https://pagure.io/fesco/issue/1750



-- 
Matthew Miller

Fedora Project Leader
___
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: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 26, 2018 at 09:59:26AM -0500, Ben Cotton wrote:
> == Upgrade/compatibility impact ==
> Users will have to adapt to change that gpg is now called gpg1 if
> their usage is not compatible with both 1.x and 2.x.

What are the actual incompatibilities? I'm in particular interested
about command line uses that will be get broken.

Zbyszek
___
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: Bugzilla outage/upgrade on 2 December 2018

[Emmanuel Seyman]

* Neal Gompa [26/11/2018 11:01] :
>
> Out of curiosity, does anyone know where the source code for Red Hat
> Bugzilla actually is? I tried to find it a while ago, and even tried
> to send an email asking about it (with no response...). This variant
> of Bugzilla has features that aren't present in vanilla Bugzilla 5.x,
> nor are they present in the Mozilla fork (bmo)...

The source code isn't avaliable (although I've been told at least one
Bugzilla developer has access to it).

https://bugzilla.redhat.com/show_bug.cgi?id=478886

Emmanuel
___
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: Bugzilla outage/upgrade on 2 December 2018

[Neal Gompa]

On Mon, Nov 26, 2018 at 10:59 AM Ben Cotton  wrote:
>
> Hi all,
>
> If you haven't seen the banner at the top of bugzilla.redhat.com, it
> is scheduled to undergo an upgrade from Bugzilla 4 to Bugzilla 5 on
> December 2 2018. The outage will begin on 2 December at 0:00 UTC and
> end on 2 December at 12:00 UTC.
>
> For more information on Bugzilla 5, see:
> https://partner-bugzilla.redhat.com/page.cgi?id=whats-new.html
> https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html
>
> Bugzilla 5.0 introduces a new REST endpoint to replace XML-RPC and
> JSON-RPC. The XML-RPC and JSON-RPC APIs will remain available.
>

Out of curiosity, does anyone know where the source code for Red Hat
Bugzilla actually is? I tried to find it a while ago, and even tried
to send an email asking about it (with no response...). This variant
of Bugzilla has features that aren't present in vanilla Bugzilla 5.x,
nor are they present in the Mozilla fork (bmo)...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Matthew Miller]

On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> Here's the summary from the page, which proposes we pause the release
> after F30 for these efforts:

I know it was a big time-off holiday week in the US, but I expected a little
more interest in this post. Perhaps it seemed like too much text to digest
along with turkey and stuffing. :) I'm highlighting it with a subject
reflecting the big, direct impact, and here's some other top-level
proposals:

* embrace Taiga (an open source kanban tool) for project planning
* fix the compose speed (target: one hour!)
* really actually for real gated Rawhide
* better CI pipeline tests for everything
* define a base platform -- Red Hat wants to focus resources here
* better tooling for non-base deliverables
* better metrics for everything


Please read 
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
and comment in this thread.

-- 
Matthew Miller

Fedora Project Leader
___
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: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Christopher]

On Mon, Nov 26, 2018 at 10:02 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
>
> == Summary ==
> The /usr/bin/gpg path representing the main GPG implementation will
> now use GnuPG 2 instead of GnuPG 1.
>

This is great. This is a change I've been looking forward to for quite
some time now.
___
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: Is Fedora 27 EOL?

[Mohan Boddu]

I am working on fixing it.

It should be fixed soon, I will send an update once its fixed.

On Mon, Nov 26, 2018 at 10:52 AM Florian Weimer  wrote:

> * Ben Cotton:
>
> > On Mon, Nov 26, 2018 at 10:20 AM Mohan Boddu  wrote:
> >>
> >> The 27 EOL should be tomorrow.
> >>
> >> The n release gets EOL'ed 4 weeks after n+2 release.
> >>
> > The policy on the wiki[1] says "one month", which is fairly ambiguous.
> > I'll update that to say "four weeks", which is what we mean, but is
> > not the practical interpretation of what we say. Since I dropped the
> > ball on this, let's do the F27 EOL on Friday and I'll fix both the
> > text of the policy and my own workflow to prevent this issue in the
> > future.
>
> I don't understand.
>
> Fedora 27 is already EOL *today* because it is impossible to push
> updates:
>
> $ git push
> Counting objects: 3, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 531 bytes | 531.00 KiB/s, done.
> Total 3 (delta 2), reused 0 (delta 0)
> remote: Running hooks for rpms/glibc
> remote: Branch refs/heads/f27 is unsupported
> remote: Denied push for ref 'refs/heads/f27' for user 'fweimer'
> remote: All changes have been rejected
> To ssh://pkgs.fedoraproject.org/rpms/glibc
>  ! [remote rejected] HEAD -> f27 (pre-receive hook declined)
> error: failed to push some refs to 'ssh://
> fwei...@pkgs.fedoraproject.org/rpms/glibc'
>
> Thanks,
> Florian
> ___
> 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
>
___
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: Broken EPEL updates due to Centos 7.6 delay?

[Christopher]

On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen  wrote:
>
> On Mon, 26 Nov 2018 at 01:03, Christopher  wrote:
> >
> > Anybody know what's going on with Centos 7.6-1810?
> > Some packages in EPEL depend on it, but it is apparently not yet available.
> > This discrepancy is breaking yum updates for me.
> >
>
> This isn't a Fedora development issue. Please refer this to the CentOS
> or EPEL lists.
>

EPEL is a Fedora project. My question wasn't really about CentOS, but
rather, about maintainer best practices for EPEL branches. To clarify,
my question is whether package maintainers are expected to ensure
their EPEL branch for their packages works against the latest CentOS
release (without enabling 'cr' repo) or whether it is expected that
packages will work as soon as the corresponding RHEL release is
available (which is usually available about 3-4 weeks earlier). What
do we use for the EPEL buildroot in koji?

> > For example, xorgxrdp-0.2.8-3.el7 depends on xorg-x11-server-Xorg
> > 1.20.1, which isn't yet available (rather, available on in the cr
> > repo, not in CentOS updates yet).
>
> --
> Stephen J Smoogen.
___
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

Bugzilla outage/upgrade on 2 December 2018

[Ben Cotton]

Hi all,

If you haven't seen the banner at the top of bugzilla.redhat.com, it
is scheduled to undergo an upgrade from Bugzilla 4 to Bugzilla 5 on
December 2 2018. The outage will begin on 2 December at 0:00 UTC and
end on 2 December at 12:00 UTC.

For more information on Bugzilla 5, see:
https://partner-bugzilla.redhat.com/page.cgi?id=whats-new.html
https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html

Bugzilla 5.0 introduces a new REST endpoint to replace XML-RPC and
JSON-RPC. The XML-RPC and JSON-RPC APIs will remain available.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Is Fedora 27 EOL?

[Florian Weimer]

* Ben Cotton:

> On Mon, Nov 26, 2018 at 10:20 AM Mohan Boddu  wrote:
>>
>> The 27 EOL should be tomorrow.
>>
>> The n release gets EOL'ed 4 weeks after n+2 release.
>>
> The policy on the wiki[1] says "one month", which is fairly ambiguous.
> I'll update that to say "four weeks", which is what we mean, but is
> not the practical interpretation of what we say. Since I dropped the
> ball on this, let's do the F27 EOL on Friday and I'll fix both the
> text of the policy and my own workflow to prevent this issue in the
> future.

I don't understand.

Fedora 27 is already EOL *today* because it is impossible to push
updates:

$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 531 bytes | 531.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Running hooks for rpms/glibc
remote: Branch refs/heads/f27 is unsupported
remote: Denied push for ref 'refs/heads/f27' for user 'fweimer'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/glibc
 ! [remote rejected] HEAD -> f27 (pre-receive hook declined)
error: failed to push some refs to 
'ssh://fwei...@pkgs.fedoraproject.org/rpms/glibc'

Thanks,
Florian
___
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: Is Fedora 27 EOL?

[Ben Cotton]

On Mon, Nov 26, 2018 at 10:20 AM Mohan Boddu  wrote:
>
> The 27 EOL should be tomorrow.
>
> The n release gets EOL'ed 4 weeks after n+2 release.
>
The policy on the wiki[1] says "one month", which is fairly ambiguous.
I'll update that to say "four weeks", which is what we mean, but is
not the practical interpretation of what we say. Since I dropped the
ball on this, let's do the F27 EOL on Friday and I'll fix both the
text of the policy and my own workflow to prevent this issue in the
future.


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Tomas Mraz]

On Mon, 2018-11-26 at 09:59 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implemen
> tation
> 
> == Summary ==
> The /usr/bin/gpg path representing the main GPG implementation will
> now use GnuPG 2 instead of GnuPG 1.

I, as the primary maintainer of the gnupg2 package, welcome this change
and I will cooperate on its implementation if it is acked by FESCo.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
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

[389-devel] please review: PR 50043 - dsctl db2index fails when no attributes are specified

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50043
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Is Fedora 27 EOL?

[Mohan Boddu]

The 27 EOL should be tomorrow.

The n release gets EOL'ed 4 weeks after n+2 release.

But I am not sure why fedpkg is rejecting the push.

On Mon, Nov 26, 2018 at 10:06 AM Ben Cotton  wrote:

> On Mon, Nov 26, 2018 at 9:48 AM John Florian 
> wrote:
> >
> > At the very least, I don't recall seeing the announcement that it will
> > be EOL in ~30 days.
>
> That's my fault. I missed my reminder to send it. I apologize for the
> short notice.
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> ___
> 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
>
___
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: Last dbus upgrade issues

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 15:57:25 +0100,
 Tomasz Kłoczko  wrote:


4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!


I was able to login to a shell, so this one might be configuration specific.
___
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

REMINDER: Fedora 27 End of Life on 2018-Nov-30

[Ben Cotton]

I apologize for the short notice. As a reminder, Fedora 27 reaches End
of Life on Friday, 30 November 2018. On this date, we will close all
the Fedora 27 bugs which remain open[1].

[1] 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING=Fedora_id=9748312_format=advanced=26

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Is Fedora 27 EOL?

[Ben Cotton]

On Mon, Nov 26, 2018 at 9:48 AM John Florian  wrote:
>
> At the very least, I don't recall seeing the announcement that it will
> be EOL in ~30 days.

That's my fault. I missed my reminder to send it. I apologize for the
short notice.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: CC-BY-SA-4.0

[Tom Callaway]

On 11/23/18 7:08 AM, Carmen Bianca Bakker wrote:
> I am currently packaging a program whose README and documentation is
> licensed under CC-BY-SA-4.0.  However,
>  only lists CC-BY-SA as
> meaning version 3.0 of that licence.
> 
> Is CC-BY-SA-4.0 a "good" licence according to Fedora?  How might one
> package a program that uses this licence?

The 4.0 version of the Creative Commons licenses are as good as the 3.0
versions. I have updated the links to the CC licenses to point to the
4.0 revision, no change in License tag in package spec files is required.

~tom
___
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

Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation

== Summary ==
The /usr/bin/gpg path representing the main GPG implementation will
now use GnuPG 2 instead of GnuPG 1.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:till|Till
Maas]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobr...@fedoraproject.org, opensou...@till.name,
ngomp...@gmail.com

== Detailed Description ==
For long time, GnuPG 2 is de-facto standard and it is unfortunate to
have /usr/bin/gpg to point to GnuPG 1 given that all major
repositories already have it that way.
Some of them don't even have GnuPG 1 shipped (RHEL is one example).

== Benefit to Fedora ==
This change will bring Fedora in line with other major distributions,
users will get consistent experience between distributions and the
naive expectation that "gpg" binary is the latest and greatest
implementation of GnuPG.

== Scope ==
* Proposal owners:
** Rename gnupg package to gnupg1
** Rename gpg binary to gpg1
** Rename gpg2 binary to gpg
** Create gpg2 → gpg symlink
** Check and fix if needed existing packages which require /usr/bin/gpg
* Other developers: Everything can be handled by change owners.
* Release engineering: [https://pagure.io/releng/issue/7920 #7920]
* Policies and guidelines: No changes are needed.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Users will have to adapt to change that gpg is now called gpg1 if
their usage is not compatible with both 1.x and 2.x.

== How To Test ==
Before change is implemented, owners will prepare COPR repository. You
will need to enable it and update and ensure that your
applications/scripts still work.

== User Experience ==
* /usr/bin/gpg is pointing to latest release of GnuPG 2 which makes
consistent user experience between distributions

== Dependencies ==
What can't be adopted to this change will be patched to use gpg1
explicitly, no action is needed from any developers.

== Contingency Plan ==
* Contingency mechanism: Owners will revert changes and postpone
change to next release.
* Contingency deadline: Beta Freeze.
* Blocks release? No
* Blocks product? No

== Documentation ==
Both gpg1 and gpg2 have their own documentation shipped with them.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation

== Summary ==
The /usr/bin/gpg path representing the main GPG implementation will
now use GnuPG 2 instead of GnuPG 1.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:till|Till
Maas]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobr...@fedoraproject.org, opensou...@till.name,
ngomp...@gmail.com

== Detailed Description ==
For long time, GnuPG 2 is de-facto standard and it is unfortunate to
have /usr/bin/gpg to point to GnuPG 1 given that all major
repositories already have it that way.
Some of them don't even have GnuPG 1 shipped (RHEL is one example).

== Benefit to Fedora ==
This change will bring Fedora in line with other major distributions,
users will get consistent experience between distributions and the
naive expectation that "gpg" binary is the latest and greatest
implementation of GnuPG.

== Scope ==
* Proposal owners:
** Rename gnupg package to gnupg1
** Rename gpg binary to gpg1
** Rename gpg2 binary to gpg
** Create gpg2 → gpg symlink
** Check and fix if needed existing packages which require /usr/bin/gpg
* Other developers: Everything can be handled by change owners.
* Release engineering: [https://pagure.io/releng/issue/7920 #7920]
* Policies and guidelines: No changes are needed.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Users will have to adapt to change that gpg is now called gpg1 if
their usage is not compatible with both 1.x and 2.x.

== How To Test ==
Before change is implemented, owners will prepare COPR repository. You
will need to enable it and update and ensure that your
applications/scripts still work.

== User Experience ==
* /usr/bin/gpg is pointing to latest release of GnuPG 2 which makes
consistent user experience between distributions

== Dependencies ==
What can't be adopted to this change will be patched to use gpg1
explicitly, no action is needed from any developers.

== Contingency Plan ==
* Contingency mechanism: Owners will revert changes and postpone
change to next release.
* Contingency deadline: Beta Freeze.
* Blocks release? No
* Blocks product? No

== Documentation ==
Both gpg1 and gpg2 have their own documentation shipped with them.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Last dbus upgrade issues

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 15:19, Tom Gundersen  wrote:
[..]
>>> What Fedora version? Ideally provide specific rpm versions.
>>> dbus-in-F29 != dbus-in-F30 now.
>>
>> I’m talking about F30 recent change in which has been implemented switch to 
>> dubs-broker.
>
> Thanks for the report, and sorry for the inconvenience.

np .. when tree is chopped chops are flying around :)

>  There was indeed a bug in the dbus-broker spec file, which we now fixed with 
> version 16-7 (should land in rawhide any minute).

IMO it would be good to learn something out of that small fault
because few thing went really odd way.

1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.

2) dbus and glibc NSS subsystem dependency. Still needs to reviewed. I
think that it is anchored in systemd and such dependency must be kind
of wrong design issue.

3) any other dependency on running dbus service should be IMO closely
investigated and if something is just crashing it should be
changed/redesigned to handle this to at least log that  to system logs
(nothing like this after all was possible to find in systemd journal
or rsyslogd logs).

4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!

5) review all scriptlets and delete redirections to /dev/null. If
during upgrade some programs are to much chatty it should be changed
to in the application started in sctriplets. IMO should be considered
replace redirection to /dev/null by logging to system logs. That would
be helpful on post mortem diagnose of any existing scriptlets issues.
However second thought .. to not depend on systemd (because dnf/rpm
are changing state of the systemd) probably it would be good to log or
tee scriptlets output to log file in /var/log.

kloczek
___
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: Is Fedora 27 EOL?

[John Florian]

On 11/26/18 9:40 AM, Florian Weimer wrote:

There has been no EOL announcement, my guess for the EOL data
(2018-11-30) has not passed yet


At the very least, I don't recall seeing the announcement that it will 
be EOL in ~30 days.

___
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

Is Fedora 27 EOL?

[Florian Weimer]

There has been no EOL announcement, my guess for the EOL data
(2018-11-30) has not passed yet, but I get this when pushing to
src.fedoraproject.org:

remote: Running hooks for rpms/glibc
remote: Branch refs/heads/f27 is unsupported
remote: Denied push for ref 'refs/heads/f27' for user 'fweimer'
remote: All changes have been rejected

Is Fedora 27 EOL or not?

Thanks,
Florian
___
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

[Bug 1653174] Upgrade perl-ExtUtils-F77 to 1.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1653174

Orion Poplawski  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-ExtUtils-F77-1.21-1.fc
   ||30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-26 09:33:27



--- Comment #1 from Orion Poplawski  ---
Done, thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Last dbus upgrade issues

[Tom Gundersen]

Hi Tomasz,

On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
wrote:

> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>> > After last dbus upgrade gdm found that is not able to start.
>>
>> What Fedora version? Ideally provide specific rpm versions.
>> dbus-in-F29 != dbus-in-F30 now.
>>
>
> I’m talking about F30 recent change in which has been implemented switch
> to dubs-broker.
>

Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).


> Ps. If this change has been propagated to F29 (hopefully not) more things
> will be screwed.
>

It has not (and will not be).

Cheers,

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

Schedule for Monday's FESCo Meeting (2018-11-26)

[Jared K. Smith]

(Apologies for the late notice -- I forgot to do this before the long
holiday weekend.)


Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 onirc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-11-26 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
#topic 2014 F30 System-Wide Change: The GNU C Library version 2.29
https://pagure.io/fesco/issue/2014
DECISION (+6, 0, -0)

= Followups =

#topic #2013 too strict rules for branches deletion alongside with
norules for theirs creations
.fesco 2013
https://pagure.io/fesco/issue/2013

= New business =

#topic #2015 Preclusion of Firefox automatic download of OpenH264
(#1359) may have been violated at some point
.fesco 2015
https://pagure.io/fesco/issue/2015

#topic  #2016 F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras
.fesco 2016
https://pagure.io/fesco/2016


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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: nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

On 11/26/18 2:21 PM, Stephen Gallagher wrote:

On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:


This e-mail is long so I just put the question here before explanation:

Do you know about any package that installs an nsswitch.conf module and
automatically enables it in /etc/nsswitch.conf? So far I have two
packages - nss-mdns and systemd.

Why?

As you might have noticed, in Fedora 28 we switched from authconfig to
authselect. This brought some adoption issues and feature requests which
we tried hard to resolved, mostly related to nsswitch.conf. Thank you
for all your feedback.

At this point I am aware of only one nsswitch.conf related issue that we
would like to fix. The problem is that when you choose to use authselect
you are no longer allowed to touch /etc/nsswitch.conf (and various file
in /etc/pam.d) manually but you should use authselect and its profiles
instead.

However, this does not work well for small environments (possibly single
user machines) where you want to just change something in nsswitch.conf
and do not want to create custom profile. For this, we introduced
/etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
command to do this the authselect way (of course you are free to not use
authselect and just modify the files manually).

But there are some packages that installs nsswitch modules and
automatically puts them in /etc/nsswitch.conf in %post which conflicts
with authselect. We would like to provide an authselect call for these
packages, that would make sure it does not conflict with authselect [1].

I started working on a design for such feature and I'm trying to obtain
list of all packages that installs nsswitch modules and automatically
enable them in /etc/nsswitch.conf.

So far I was able to find these packages:
- nss-altfiles
- nss_db
- nss-mdns
- nss_nis
- nss-pam-ldapd
- nss_updatedb
- sssd
- systemd

But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
you know about any other package?

Thank you,
Pavel.

[1] https://github.com/pbrezina/authselect/issues/77



IIRC, doesn't autofs also use nsswitch.conf for configuration?


Yes, but it is not part of glibc. AFAIK it works similar to sudo - 
lookup automount line in nsswitch.conf and acts according to its 
settings. But it does not have proper support in glibc.



Also CCing Will Woods and James Antill who have been looking at
scriptlets in Fedora in general and may have further information
handy.


Thanks.
___
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: nsswitch.conf: list of module packages that enables themselves

[Stephen Gallagher]

On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:
>
> This e-mail is long so I just put the question here before explanation:
>
> Do you know about any package that installs an nsswitch.conf module and
> automatically enables it in /etc/nsswitch.conf? So far I have two
> packages - nss-mdns and systemd.
>
> Why?
>
> As you might have noticed, in Fedora 28 we switched from authconfig to
> authselect. This brought some adoption issues and feature requests which
> we tried hard to resolved, mostly related to nsswitch.conf. Thank you
> for all your feedback.
>
> At this point I am aware of only one nsswitch.conf related issue that we
> would like to fix. The problem is that when you choose to use authselect
> you are no longer allowed to touch /etc/nsswitch.conf (and various file
> in /etc/pam.d) manually but you should use authselect and its profiles
> instead.
>
> However, this does not work well for small environments (possibly single
> user machines) where you want to just change something in nsswitch.conf
> and do not want to create custom profile. For this, we introduced
> /etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
> command to do this the authselect way (of course you are free to not use
> authselect and just modify the files manually).
>
> But there are some packages that installs nsswitch modules and
> automatically puts them in /etc/nsswitch.conf in %post which conflicts
> with authselect. We would like to provide an authselect call for these
> packages, that would make sure it does not conflict with authselect [1].
>
> I started working on a design for such feature and I'm trying to obtain
> list of all packages that installs nsswitch modules and automatically
> enable them in /etc/nsswitch.conf.
>
> So far I was able to find these packages:
> - nss-altfiles
> - nss_db
> - nss-mdns
> - nss_nis
> - nss-pam-ldapd
> - nss_updatedb
> - sssd
> - systemd
>
> But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
> you know about any other package?
>
> Thank you,
> Pavel.
>
> [1] https://github.com/pbrezina/authselect/issues/77


IIRC, doesn't autofs also use nsswitch.conf for configuration?

Also CCing Will Woods and James Antill who have been looking at
scriptlets in Fedora in general and may have further information
handy.
___
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

nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

This e-mail is long so I just put the question here before explanation:

Do you know about any package that installs an nsswitch.conf module and 
automatically enables it in /etc/nsswitch.conf? So far I have two 
packages - nss-mdns and systemd.


Why?

As you might have noticed, in Fedora 28 we switched from authconfig to 
authselect. This brought some adoption issues and feature requests which 
we tried hard to resolved, mostly related to nsswitch.conf. Thank you 
for all your feedback.


At this point I am aware of only one nsswitch.conf related issue that we 
would like to fix. The problem is that when you choose to use authselect 
you are no longer allowed to touch /etc/nsswitch.conf (and various file 
in /etc/pam.d) manually but you should use authselect and its profiles 
instead.


However, this does not work well for small environments (possibly single 
user machines) where you want to just change something in nsswitch.conf 
and do not want to create custom profile. For this, we introduced 
/etc/authselect/user-nsswitch.conf and 'authselect apply-changes' 
command to do this the authselect way (of course you are free to not use 
authselect and just modify the files manually).


But there are some packages that installs nsswitch modules and 
automatically puts them in /etc/nsswitch.conf in %post which conflicts 
with authselect. We would like to provide an authselect call for these 
packages, that would make sure it does not conflict with authselect [1].


I started working on a design for such feature and I'm trying to obtain 
list of all packages that installs nsswitch modules and automatically 
enable them in /etc/nsswitch.conf.


So far I was able to find these packages:
- nss-altfiles
- nss_db
- nss-mdns
- nss_nis
- nss-pam-ldapd
- nss_updatedb
- sssd
- systemd

But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do 
you know about any other package?


Thank you,
Pavel.

[1] https://github.com/pbrezina/authselect/issues/77
___
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: fedora-rawhide-kernel-nodebug is not getting updates

[Justin Forbes]

On Fri, Nov 23, 2018 at 7:47 AM Dan Horák  wrote:
>
> On Fri, 23 Nov 2018 14:28:46 +0100
> Igor Gnatenko  wrote:
>
> > Does anybody know why?
> >
> > Last kernel available there is 2 weeks old.
> >
> > https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/
>
> I've already pinged #fedora-kernel few days ago, but let's notify the
> kernel list too.
>
Between Plumbers conference and some vacation, I was not around to
keep it updated, it should get rc4 today and remain on track.

Thanks,
Justin
___
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: Last dbus upgrade issues

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 12:57:34 +0100,
 Tomasz Kłoczko  wrote:


4) Nevertheless my system ended up with *not enabled* dbus-broker.
If it was caused by upgrade over rpm it clear sign that dnf is not
fully compliant with upgrade semantics implemented in rpm. This will
cause more issues in the future (why dnf is not doing upgrade by use
rpm libs calls? why someone started duplicating this code? It must be
some reason but splitting the code is not a solution)


I ended up with this (dbus broken because dbus-daemon wasn't enabled) as well. 
I eventually figured out to enable dbs-daemon, but I first tried downgrading 
dbus which was a pain, because the machine doesn't support ethernet and I'm 
not sure how to manaully wireless when NetworkManager can't be used.


Now I know to re-enable it on my other machines before rebooting.
___
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: Broken EPEL updates due to Centos 7.6 delay?

[Stephen John Smoogen]

On Mon, 26 Nov 2018 at 01:03, Christopher  wrote:
>
> Anybody know what's going on with Centos 7.6-1810?
> Some packages in EPEL depend on it, but it is apparently not yet available.
> This discrepancy is breaking yum updates for me.
>

This isn't a Fedora development issue. Please refer this to the CentOS
or EPEL lists.

> For example, xorgxrdp-0.2.8-3.el7 depends on xorg-x11-server-Xorg
> 1.20.1, which isn't yet available (rather, available on in the cr
> repo, not in CentOS updates yet).
> ___
> 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



-- 
Stephen J Smoogen.
___
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: Last dbus upgrade issues

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 07:04, David Herrmann  wrote:
[..]
> > Other problem is that dnf and rpm are executing batch of packages
> > scriplets not the same order with other operations. Breaking rpm
> > semantics by dnf is kind of asking for troubles.
>
> Thanks a lot for the report. We tested this upgrade with several
> different setups (both dbus-daemon and broker installed/not installed
> before the upgrade, etc.), and we didn't see this behavior. We are
> aware that this update needs a reboot to fully work, but we made sure
> it somewhat works even if you don't reboot. For rawhide, there is
> sadly no way to mark updates as "needs reboot".

1) Nothing from any implemented scriptlets printed out such
message/warning that system needs to be rebooted ASAP..

2) Even if some scriplets would be printing something like this dnf
will redirect stdout messages to /dev/null. rpm does not do this and
IMO good question is why dnf is doing this, So generally your 'there
is sadly no way to mark updates as "needs reboot"' is not real barrier
but barrier in dnf. Other thing is that many existing scriptlets which
may emit some workings or even errors are usually redirected by
packagers to /dev/null. For example now it is some number of packages
systemd files are still pointing to /var/run instead to /run. No one
is going to fix those issues because almost no one knows that it is
already reported by some systemd commands. IMO general policy about
scriptlets should be not redirect stdout/stderr to /dev/null because
it hides potential issues in scriplts, configuration files or other
resources.

3) If all dbus connections are not stateless which if it is true would
not allow restart dbus service on running system IMO it is big flaw in
dbus design. In case any dbus security issues this will cause that
Linux will be more like old time Windows (when application level fix
required OS reboot) than modern U*nix. Hopefully this is not truth and
dbus restart is possible.

4) Nevertheless my system ended up with *not enabled* dbus-broker.
If it was caused by upgrade over rpm it clear sign that dnf is not
fully compliant with upgrade semantics implemented in rpm. This will
cause more issues in the future (why dnf is not doing upgrade by use
rpm libs calls? why someone started duplicating this code? It must be
some reason but splitting the code is not a solution)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Fedora Lifecycles: imagine longer-term possibilities

[Brian (bex) Exelbierd]

On Tue, Nov 20, 2018 at 5:12 PM Fabio Valentini  wrote:
>
> On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd >
>> On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann  wrote:
>> >
>> > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
>> > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
>> > >
>> > > > I understand this argument, but I think more and more desktop users
>> > > > are being trained that updates happen on a schedule they didn't
>> > > > choose
>> > > > and are hard to avoid.  This is how most mobile operating systems
>> > > > function.
>> > >
>> > > iOS prompts you for the yearly updates, and it can be avoided if you
>> > > really want.
>> > >
>> > > macOS requires you to specifically choose the yearly update, though
>> > > they may have changed with Mojave.
>> > >
>> > > Not sure about Android, but the fact that Google has had to twist
>> > > things into a knot to try and get updates out to users indicates that
>> > > upgrades to Android aren't being pushed out for the most part.
>> > >
>> > > Windows is the only one forcing upgrades, and it is perhaps one of
>> > > the
>> > > reasons that hardware vendors are showing more interest in Linux as
>> > > people are now more willing to consider anything other than Windows.
>> > >
>> > > Really, the only place where forced upgrades are happening, are
>> > > accepted, and seem to actually work are on the application side and
>> > > that is because, demonstrated by the web browsers, frequent updates
>> > > can be done unobtrusively and reliably.
>> >
>> > And with the named examples are you gonna get any support and updates
>> > if you decide to hold off an upgrade to a newer OS? I doubt.
>> > I can certainly hold off upgrade to Android 9 on my phone, but that
>> > doesn't mean I'm gonna get any further updates for Android 8 from the
>> > phone vendor.
>> > There is a huuuge difference between "not forcing upgrades" and
>> > "providing supported and secure way to stay on the current release".
>>
>> I think this tied up with one of the major problems we are trying to
>> solve with Fedora Modularity, the "Too Fast, Too Slow" problem.
>
>
> I think identifying which components move too slow or too fast would be a 
> good start - even if those lists might depend on the specific user or 
> use-case.

I think this is a great way to differentiate various
spins/labs/editions, however the OS as a whole needs to be able to
allow as much as possible to flex as much as possible.  I think that
trying to define a core beyond "boots the machine" quickly leads to an
endless rabbit hole.

>> I am not sure it is bad for Fedora to only have a single supported
>> "release."  If you refuse an upgrade, you're on your own.  If you
>> refuse it because you're going on a trip, have a presentation, etc.
>> and plan to do it later, you generally don't care.  If you do it
>> because you don't want your system to change, I am not sure Fedora
>> should be your distribution of choice (I'll introduce you to my
>> friends CentOS and RHEL).
>>
>> If we did a "stable rolling release base" that, described simply and
>> incompletely, had a beta and stable option where you knew your
>> hardware would work and your apps would run I think most users,
>> desktop and server, would be happy.
>
>
> What about aliasing fedora-N to "rolling-beta", and fedora-N-1 to 
> "rolling-stable" (similar to what Debian does)? Every 6 months or so, 
> rolling-stable users would get an upgrade to a fedora release that's been 
> well-used and -tested for about 6 months. (Which I guess is what some people 
> already do manually.)

I agree that we need a beta vs stable pathway, but I am not sure
having a release helps us.  We can do version numbers if we need them
for marketing, but I think some of what appeals about rolling releases
is that upgrades are a non-event.  We've basically accomplished that
with Fedora today, except that we still make a big deal out of hte
upgrade and hte new version number.  Let's push it further to
non-event status and instead talk about updates as new features and
benefits, not a new version.  (this is poorly worded - I am in a
rush).

regards,

bex

>
> We only need to make sure that the upgrade path always works for, say, the 
> last 4 fedora releases (or however many we need to support upgrading from). 
> Upgrades from N-2 to N are already supposed to work (I think), so this 
> shouldn't be too hard.
>
> (Also, silverblue would make this really easy, by "just" automatically 
> switching to the new N-1 branch every 6 months, when N-2 hits EOL).
>
> That way, the number of supported fedora releases stays the same, and only 
> the upgrade path needs to be reliable for longer.
>
> Fabio
>
>> We use the "beta" to find
>> hardware regressions and to signal hardware we are dropping support
>> for or adding new support for, and we use stable for people who want
>> to get things done.  Layer on Modules. containers and Flatpaks and we
>> have the apps moving on their own speed on this 

new maintainer needed: vpnc-script

[Nikos Mavrogiannopoulos]

Hi,
 I'm the main contact point for vpnc-script (used by vpnc and
openconnect VPN), however I no longer spend time in maintaining it. 

If someone would like to pick it up, please let me know. The main
outstanding issue on that package is:
https://bugzilla.redhat.com/show_bug.cgi?id=1648108

Upstream (David Woodhouse) is responsive and very friendly.

regards,
Nikos

___
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: How much is dnf's minimum memory requirement?

[Richard W.M. Jones]

On Sun, Nov 25, 2018 at 05:53:21PM +0100, Benjamin Kircher wrote:
> What are dnf’s minimum memory requirements?

I think "creeping upwards" is a fair description.  We have
occasionally seen trouble with virt-builder and virt-customize which
are using a smallish virtual machine.  In Fedora 28+ I have had to
increase the memory available to 1G (from 500M previously, note there
is no swap) to get package installation to work reliably.  I also
filed:

  https://bugzilla.redhat.com/show_bug.cgi?id=1432219

which is closed now, but I think the issue has returned since I closed
it.

> Anyway, is memory consumption a thing with the new libdnf-in-C++
> efforts?

No idea whether rewriting dnf has helped.  I'm not clear which version
of dnf is the rewritten one.

> Could a look into microdnf be a thing for me?

For Fedora/RISC-V, in the early days while we were getting all the
dependencies for full dnf ready, we used ‘tdnf’ which is another of
these cut down solvers (written in C IIRC).  I wouldn't recommend that
particular program as it has many shortcomings compared to regular
dnf.  I don't think we tried microdnf however.

I think a more productive way to resolve this will be to try to
diagnose what's consuming memory.  You can probably do this by getting
dnf (or python?) to core dump when it runs out of memory, then
examining the core dump file for strings to see if you can identify
what data is consuming the memory.

Another way would be to use an instrumented malloc implementation
such as https://github.com/memtt/malt

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Last dbus upgrade issues

[Peter Robinson]

On Mon, Nov 26, 2018 at 5:57 AM David Herrmann  wrote:
>
> Hi
>
> On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
>  wrote:
> >
> > On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko  
> > wrote:
> > [..]
> > > I’m talking about F30 recent change in which has been implemented switch 
> > > to dubs-broker.
> > > Ps. If this change has been propagated to F29 (hopefully not) more things 
> > > will be screwed.
> >
> > Seems I found what caused the issue.
> > I've been doing upgrade (only) dbus packages using rpm and for some
> > reason after all old dbus-daemon has been killed and deactivated and
> > at the same time dbus-broker has not been started.
> > Instant effect was very strange. For example I was unable to unpack
> > any archives with files owned by group/user not present in my system
> > because NSS seems now depends on dbus as well. After next few minutes
> > Gnome GUI crashed,
> >
> > if [ $1 -eq 1 ] ; then
> > systemctl --no-reload disable dbus-daemon.service
> > systemctl --no-reload --global disable dbus-daemon.service
> > systemctl --no-reload enable dbus-broker.service
> > systemctl --no-reload --global enable dbus-broker.service
> > fi
> >
> > This dbus-broker %post scriplet seems is only swapping started
> > services but does not stops dbus-daemon and starts dbus-broker if
> > dbus-daemon is already runimg.
>
> You cannot stop dbus-daemon on a running system. This would tear down
> everything. The package upgrade needs a reboot.
>
> > At the same time because in spec file is missing uninstall dbus-daemon
> > by missing "Obsoletes: dbus-daemon" below
>
> Uninstalling dbus-daemon would break a running system, because it
> would stop the system bus. Furthermore, other packages still depend on
> tools provided by the old dbus-package. Can you elaborate why it is
> harmful to keep dbus-daemon around? We made sure you can manually
> remove it, unless other packages explicitly depend on the dbus-daemon
> binary for private buses.
>
> > %triggerpostun -- dbus-daemon
> > systemctl --no-reload preset dbus-broker.service
> > systemctl --no-reload --global preset dbus-broker.service
> >
> > has not been activated as well. IMO implementing whole transition with
> > leaving both old and new packages installed seems is wrong.
> >
> > Solution: login after all in single mode and execute "systemctl enable
> > dbus-broker" than reboot.
>
> This surprises me. You are saying a simple reboot did not solve your
> issues? The `enable` line is executed during upgrade, but you are
> saying on your system dbus-broker was not enabled after the upgrade?
>
> > Other problem is that dnf and rpm are executing batch of packages
> > scriplets not the same order with other operations. Breaking rpm
> > semantics by dnf is kind of asking for troubles.
>
> Thanks a lot for the report. We tested this upgrade with several
> different setups (both dbus-daemon and broker installed/not installed
> before the upgrade, etc.), and we didn't see this behavior. We are
> aware that this update needs a reboot to fully work, but we made sure
> it somewhat works even if you don't reboot. For rawhide, there is
> sadly no way to mark updates as "needs reboot".

I have two arm systems running rawhide and they've both had problems
where I've ended up without dbus running so no network etc. I needed
to explicitly login locally and enable/disable services and reboot to
get things working again.
___
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

[Bug 1653176] Upgrade perl-Imager to 1.007

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1653176

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Imager-1.007-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-26 03:10:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Container updates available in bodhi

[Clement Verna]

On Wed, 21 Nov 2018 at 16:37, Ken Dreyer  wrote:

> On Thu, Nov 15, 2018 at 6:09 AM Clement Verna 
> wrote:
> >
> > On Thu, 15 Nov 2018 at 13:55, Petr Pisar  wrote:
> >> And unrelated question: The koji build NVR does not contain dist-git
> >> name space. Does that mean there will be race conditions between rpms
> >> and container builds when the NVR string will conflict and preventing
> >> from an successfull koji build?
> >
> > OSBS grabs from koji the latest NVR available and increments the release
> > number, so we would not have identical NVR. But indeed that could mess
> up the
> > build of the rpm package if the release number was already used by OSBS,
> > that's something that needs to be improved.
>
> I think it's a good idea for Koji content generators to import builds
> named with a particular suffix.
>
> For OSBS, it makes sense to have all the container builds named with a
> "-container" suffix. This is how we do it in another Koji+OSBS
> instance I use. I guess there is nothing in OSBS (yet!) that enforces
> this convention for the "BZComponent' or "com.redhat.component" labels
> in the Dockerfile.
>
> Yes I think that's a good idea, and will not be very difficult to put in
place. I have opened an issue [0] for the container SIG to implement that

[0] - https://pagure.io/ContainerSIG/container-sig/issue/20


> When we use name suffixes with content generator builds, we won't have
> Release number collisions, or pollute "koji list-tagged --latest" or
> "koji list-builds --package", or throw off getAverageBuildDuration,
> etc.
>
> - Ken
> ___
> 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
>
___
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