Re: New look for Koji Web
On Wed, Jun 21, 2023 at 6:31 AM Ryan Lerch wrote: > > The Koji web front end is now running a new theme that brings it into > line with the majority of our other devel focused web applications: > > https://koji.fedoraproject.org/ Love it, thank you. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 38 mass rebuild is finished
On Mon, Jan 23, 2023 at 6:23 PM Tomas Hrcka wrote: > The mass rebuild was done in a side tag (f38-rebuild) and moved over to > f38. Failures can be seen at > https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html pamix fixed in pamix-1.6-7.fc38. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
tintin: license updated
PSA: I've updated the license of tintin from GPLv2+ to GPL-3.0-only in its 2.02.30 update. This should have been done a while ago, in 2.01.8; Bodhi updates submitted. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 11, 2023 at 1:59 PM Miro Hrončok wrote: > > Dear maintainers. > > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 38 approximately one week before branching. > > tabbed psabata Okay, finally fixed tabbed tonight (#2047035). P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Deprecating intents in Modularity
On Wed, Nov 2, 2022 at 5:04 PM Petr Pisar wrote: > Summing all these facts suggests that intents in Modularity are completely > unused and their future won't be better. Therefore I'd like to deprecate > intents in Modularity. > > What would it mean? The current YAML specification for module-defaults would > warn that intents are deprecated. Any future tools or speciciations for > modularity would not implement the intents. > > Does anybody have a problem with deprecating intents? No, +1. As you note, this never became a thing and no one was really interested in it. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What to do about ELN-related "spam"?
On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini wrote: > > Hi everybody, > > I'm unsure how to deal with this, so I'm asking here if anybody has ideas. > > - I'm getting serious spam from fedora-notif on IRC about successful - > and a lot more failed - ELN builds for my packages (triggered either > by ELN developers or automatically by their CI) I hope successful builds aren't too much of a pain; failed builds should preferably be addressed, ideally by you. Unless it's clearly not a problem in your package. > - bodhi is spamming bugzilla by changing the "Fixed in Version" field > every time a new ELN build succeds with a new %dist value (one > bugzilla email each for eln106, eln107, eln108, etc.) This sounds wrong to me but maybe it's relevant for potential ELN consumers to know if a bug was also addressed in ELN. Is that an issue? > At this point, almost half of the bugzilla mail I get and a majority > of the IRC notifications are "ELN spam" that I do not know how to deal > with / is not actionable for me. It's now so bad that I'd like to get > the packages that are failing to build (multiple times a day) in ELN > fixed just so I don't get spammed with "failed to build" notifications > anymore ... I wonder why you're getting so many build notifications. These should only be triggered when you update your package in Rawhide. But again, fixing build failures would generally be a good thing. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Tue, Dec 15, 2020 at 11:33 PM Miroslav Suchý wrote: > > I am looking for challenges for upcoming year - what I and my team should > enhance. I have some ideas, but I want to hear > yours. > > What you - as Fedora packager - find most time consuming on packaging? > Where you will welcome more simplicity or automation? I suppose many of us have scripts or aliases for this kind of thing but maybe something could be integrated into the tools to make it easier: Review changes in the upstream sources; maybe just a diff between the two tarballs would be sufficient. This helps one identify changes in dependencies, potential breaking behavior, new files or features (hello, shell completions), minor changes in licensing, and so on. Not every upstream has a reasonable SCM one can inspect. And not every upstream provides a changelog, or a changelog that can be trusted. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))
On Thu, Dec 10, 2020 at 11:08 PM James Szinger wrote: > > On Thu, 10 Dec 2020 22:10:03 +0100 > Petr Šabata wrote: > > Disable the freeradius module; it only has a context for the default > > perl stream and is blocking the switch. > > Still no joy. By the way, my point here is not to get this working, > but rather to demonstrate the complexity of modularity and the lack of > documentation. > > Jim Yes, I get it. And I'm pretty sure perl module switching is covered in RHEL release docs (I recall reviewing that) as it's a content-specific problem here. The user interface could always be improved and guide the user to the correct resolution better in any generic instance of this situation. Until then, some of these common problems could be documented upstream, too. You probably know you have other modules that require not-5.30 streams of perl enabled then. The message below points at perl-libwww-perl:6.34. P > $ podman run --rm -it registry.centos.org/centos:8 bash > [root@eb931d6dd4b0 /]# yum -y module disable freeradius > Failed to set locale, defaulting to C.UTF-8 > CentOS-8 - AppStream417 kB/s | 6.2 MB 00:15 > CentOS-8 - Base 121 kB/s | 2.3 MB 00:19 > CentOS-8 - Extras24 kB/s | 8.1 kB 00:00 > Dependencies resolved. > > Package Architecture Version Repository > Size > > Disabling modules: > freeradius > > Transaction Summary > > > Complete! > [root@eb931d6dd4b0 /]# yum -y module enable perl:5.30 postgresql:12 -y > Failed to set locale, defaulting to C.UTF-8 > Last metadata expiration check: 0:00:57 ago on Thu Dec 10 21:51:46 2020. > Problems in request: > Modular dependency problems with Defaults: > > Problem: conflicting requests > - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 > requires module(perl:5.24), but none of the providers can be installed > - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 > requires module(perl:5.26), but none of the providers can be installed > - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with > module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64 > - module perl:5.26:820190628020724:55190bc5-0.x86_64 conflicts with > module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.26) provided by perl:5.26:820190628020724:55190bc5-0.x86_64 > Dependencies resolved. > > Package Architecture Version Repository > Size > > Enabling module streams: > perl 5.30 > postgresql 12 > > Transaction Summary > > > Complete! > [root@eb931d6dd4b0 /]# yum -y module install perl-DBD-Pg > Failed to set locale, defaulting to C.UTF-8 > Last metadata expiration check: 0:01:04 ago on Thu Dec 10 21:51:46 2020. > Modular dependency problem: > > Problem: conflicting requests > - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 > requires module(perl:5.24), but none of the providers can be installed > - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 > requires module(perl:5.26), but none of the providers can be installed > - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with > module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64 > - module perl:5.26:820190628020724:55190bc5-0.x86_64 conflicts with > module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.26) provided by perl:5.26:820190628020724:55190bc5-0.x86_64 > All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7
Re: Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))
On Thu, Dec 10, 2020 at 9:55 PM James Szinger wrote: > > On Tue, 8 Dec 2020 17:18:24 -0500 > Matthew Miller wrote: > > > Is there a particular part of the documentation you're struggling > > with, or something specifically you find missing? I don't mean to be > > snarky, but I heard a lot of this complaint at the last DevConf.cz, > > and then when the things mentioned were checked out, they actually > > _are_ covered pretty nicely in the > > https://docs.fedoraproject.org/en-US/modularity/ docs. > > The modularity docs do not even begin to address how to resolve the > following: > > $ podman run --rm -it registry.centos.org/centos:8 bash > [root@ad899f6f999b /]# yum module enable perl:5.30 postgresql:12 > Failed to set locale, defaulting to C.UTF-8 > CentOS-8 - AppStream665 kB/s | 6.2 MB 00:09 > CentOS-8 - Base 1.8 MB/s | 2.3 MB 00:01 > CentOS-8 - Extras22 kB/s | 8.1 kB 00:00 > Problems in request: > Modular dependency problems with Defaults: > > Problem: module perl:5.26:820190628020724:55190bc5-0.x86_64 conflicts > with module(perl:5.30) provided by > perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.26) provided by perl:5.26:820190628020724:55190bc5-0.x86_64 > - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires > module(perl:5.26), but none of the providers can be installed > - conflicting requests > Dependencies resolved. > > Package Architecture Version Repository > Size > > Enabling module streams: > perl 5.30 > postgresql 12 > > Transaction Summary > > > Is this ok [y/N]: y > Complete! > [root@ad899f6f999b /]# yum module install perl-DBD-Pg > Failed to set locale, defaulting to C.UTF-8 > Last metadata expiration check: 0:00:49 ago on Thu Dec 10 20:46:36 2020. > Modular dependency problem: > > Problem: module perl:5.26:820190628020724:55190bc5-0.x86_64 conflicts > with module(perl:5.30) provided by > perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.26) provided by perl:5.26:820190628020724:55190bc5-0.x86_64 > - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires > module(perl:5.26), but none of the providers can be installed > - conflicting requests > All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7' are not > active > Error: Problems in request: > broken groups or modules: perl-DBD-Pg > Modular dependency problems: > > Problem: module perl:5.26:820190628020724:55190bc5-0.x86_64 conflicts > with module(perl:5.30) provided by > perl:5.30:8030020200715145239:568f3a16-0.x86_64 > - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with > module(perl:5.26) provided by perl:5.26:820190628020724:55190bc5-0.x86_64 > - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires > module(perl:5.26), but none of the providers can be installed > - conflicting requests > [root@ad899f6f999b /]# > > How do I get Perl 5.30, PostgreSQL 12 and the DBD::Pg that works with > them? Disable the freeradius module; it only has a context for the default perl stream and is blocking the switch. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi wrote: > > On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote: > > On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi wrote: > > > > > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi wrote: > > > > > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > > > Also a couple of notes on modularity here: > > > > > > > > > > > > # By default, module stream name is derived from the branch name > > > > > > If we have any "master" modules, those will get unexpectedly renamed > > > > > > as soon as they get rebuilt. This might impact tagging or updates > > > > > > and > > > > > > cause confusion in general. We should check if there are any like > > > > > > that > > > > > > and decide on further steps. > > > > > > > > > > Good thing to check yes. I can try and do so. > > > > > > > > Thanks. > > > > > > hum, but I am not 100% sure what I am looking for. > > > modules with a master branch and no name defined? > > > What does the name being defined look like in the yaml file? > > > > Yes. You could also query MBS for stream=master and see if there's > > anything reasonably recent to narrow your search. But branches would > > be enough. > > > > In modulemd, stream name is defined as "stream: ". > > So, I looked back the last 3 months and I am pretty sure the only ones > are all flatpaks. (firefix, thunderbird, etc) https://mbs.fedoraproject.org/module-build-service/1/module-builds/?stream=master I can also see avocado:master built for f33 there on the first page. But it could also matter for flatpaks if the name is referenced in the build process. CC'ing Owen. > > > > > > # Modules might be pulling components from their master branches to > > > > > > build Rawhide artifacts > > > > > > There are various use cases for this, too long to list. If the > > > > > > master > > > > > > ref is no longer available, these will not build. Modulemd files > > > > > > that > > > > > > pull components from master need to be updated after Phase 2. > > > > > > > > > > Yep. +1 > > > > > > > > Great, will you do that, too? > > > > > > There seems to be a bunch of them. ;( > > > > Many of those are definitely obsolete, though! > > Well, I checked out all the modules from rawhide. How can I tell they > are obsolete? Uh; I was fairly certain some of those were my dev modules from the Boltron era. If I recall correctly, Merlin was working on marking modules as obsolete at some point. Maybe we didn't actually run it all of them and they're being built automatically. We should review everything that's in Rawhide and obviously isn't supposed to be. CC'ing Merlin. P > > > > > > # The modulemd component ref is optional and defaults to master > > > > > > Unless this got changed later, if the ref field is omitted, the > > > > > > value > > > > > > defaults to "master". This is part of the specification and is > > > > > > handled > > > > > > by libmodulemd. Not sure how to proceed here. > > > > > > > > > > Can we change the default? > > > > > > > > According to Vít that's already happened (for completely unrelated > > > > reasons), so we're good here. > > > > > > ok. > > > > > > > > > And besides modularity: > > > > > > > > > > > > There are people and teams who use bots to autobuild their upstream > > > > > > projects in Rawhide. If they have a bot account (and I hope they > > > > > > do), > > > > > > they should be notified to update their tooling. > > > > > > > > > > We don't have much tracking on bot accounts. People make them and sign > > > > > up for fas for them, etc. > > > > > > > > > > We can try and find things that are obvious, but we are likely to miss > > > > > some. We can definitely help people who notice breakage tho. > > > > > > > > Ah, I kinda expected these accounts to be clearly marked as being > > >
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi wrote: > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi wrote: > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > Also a couple of notes on modularity here: > > > > > > > > # By default, module stream name is derived from the branch name > > > > If we have any "master" modules, those will get unexpectedly renamed > > > > as soon as they get rebuilt. This might impact tagging or updates and > > > > cause confusion in general. We should check if there are any like that > > > > and decide on further steps. > > > > > > Good thing to check yes. I can try and do so. > > > > Thanks. > > hum, but I am not 100% sure what I am looking for. > modules with a master branch and no name defined? > What does the name being defined look like in the yaml file? Yes. You could also query MBS for stream=master and see if there's anything reasonably recent to narrow your search. But branches would be enough. In modulemd, stream name is defined as "stream: ". > > > > # Modules might be pulling components from their master branches to > > > > build Rawhide artifacts > > > > There are various use cases for this, too long to list. If the master > > > > ref is no longer available, these will not build. Modulemd files that > > > > pull components from master need to be updated after Phase 2. > > > > > > Yep. +1 > > > > Great, will you do that, too? > > There seems to be a bunch of them. ;( Many of those are definitely obsolete, though! > > > > # The modulemd component ref is optional and defaults to master > > > > Unless this got changed later, if the ref field is omitted, the value > > > > defaults to "master". This is part of the specification and is handled > > > > by libmodulemd. Not sure how to proceed here. > > > > > > Can we change the default? > > > > According to Vít that's already happened (for completely unrelated > > reasons), so we're good here. > > ok. > > > > > And besides modularity: > > > > > > > > There are people and teams who use bots to autobuild their upstream > > > > projects in Rawhide. If they have a bot account (and I hope they do), > > > > they should be notified to update their tooling. > > > > > > We don't have much tracking on bot accounts. People make them and sign > > > up for fas for them, etc. > > > > > > We can try and find things that are obvious, but we are likely to miss > > > some. We can definitely help people who notice breakage tho. > > > > Ah, I kinda expected these accounts to be clearly marked as being > > non-human. Oh well. > > > > Anyway, besides the magical module stream renames, all of this should > > continue to work fine if we get the symbolic refs, I think? > > Well, I am ok with a symbolic ref from main to/from rawhide, but I don't > like the idea of a master symbolic ref. It kind of defeats the purpose > of the entire thing. ;( Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for me. If not, it implies a lot of downstream RHEL work we'll have to handle. Just let us all know in due time. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing noise on devel list
On Fri, Dec 4, 2020 at 10:46 PM Dennis Gilmore wrote: > Hi all, > > I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all > automated emails to a separate list where people who want to follow > can, while I was part of the proliferation of compose reports coming > here, there is now a great deal of them, and they no longer seem to > trigger any conversation. I think that devel list would benefit from > having all automated reports sent to a reports-list and letting people > bring reports over when there is something to discuss. I was asked to > bring the request to the list for people to weigh in. +1, thank you. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi wrote: > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > Also a couple of notes on modularity here: > > > > # By default, module stream name is derived from the branch name > > If we have any "master" modules, those will get unexpectedly renamed > > as soon as they get rebuilt. This might impact tagging or updates and > > cause confusion in general. We should check if there are any like that > > and decide on further steps. > > Good thing to check yes. I can try and do so. Thanks. > > # Modules might be pulling components from their master branches to > > build Rawhide artifacts > > There are various use cases for this, too long to list. If the master > > ref is no longer available, these will not build. Modulemd files that > > pull components from master need to be updated after Phase 2. > > Yep. +1 Great, will you do that, too? > > # The modulemd component ref is optional and defaults to master > > Unless this got changed later, if the ref field is omitted, the value > > defaults to "master". This is part of the specification and is handled > > by libmodulemd. Not sure how to proceed here. > > Can we change the default? According to Vít that's already happened (for completely unrelated reasons), so we're good here. > > And besides modularity: > > > > There are people and teams who use bots to autobuild their upstream > > projects in Rawhide. If they have a bot account (and I hope they do), > > they should be notified to update their tooling. > > We don't have much tracking on bot accounts. People make them and sign > up for fas for them, etc. > > We can try and find things that are obvious, but we are likely to miss > some. We can definitely help people who notice breakage tho. Ah, I kinda expected these accounts to be clearly marked as being non-human. Oh well. Anyway, besides the magical module stream renames, all of this should continue to work fine if we get the symbolic refs, I think? P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Also a couple of notes on modularity here: # By default, module stream name is derived from the branch name If we have any "master" modules, those will get unexpectedly renamed as soon as they get rebuilt. This might impact tagging or updates and cause confusion in general. We should check if there are any like that and decide on further steps. # Modules might be pulling components from their master branches to build Rawhide artifacts There are various use cases for this, too long to list. If the master ref is no longer available, these will not build. Modulemd files that pull components from master need to be updated after Phase 2. # The modulemd component ref is optional and defaults to master Unless this got changed later, if the ref field is omitted, the value defaults to "master". This is part of the specification and is handled by libmodulemd. Not sure how to proceed here. And besides modularity: There are people and teams who use bots to autobuild their upstream projects in Rawhide. If they have a bot account (and I hope they do), they should be notified to update their tooling. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote: > > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote: > > Since I don't see those on the list, does this impact > > > > * rpkg (fedpkg)? > > Wrapper to git, should not be impacted. The only thing I could think of was: > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M > main" > directly. That being said, I'm not 100% sure when we creating a project on > dist-git today we create them empty. Also fedpkg anything that tries to figure out what the release string and build target are based on the branch name. E.g. fedpkg build. > > * koji (if no git commit is provided)? > > koji builds from a git reference be that a commit, branch name or git tag. > There will be no consequences for koji there (instead of building from > url#master you'll be build from url#main). Yes, but I think, and correct me if I'm wrong, that if the SCMURL is simply a repo name, it uses master HEAD. You could say it's an edge case but if it does that, is should now attempt to use main, with master as a fallback. > > * COPR? > > I'll let the COPR folks answer. > > > * Koschei or other such services? > > I don't know enough koschei to answer for it. > For the other services, we've tried to be exhaustive. If you can think of some > we missed/may have missed feel free to raise them. I can only think of not-strictly-Fedora stuff, like people's bots that autoupdate packages or do various things based on bus messages. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Since I don't see those on the list, does this impact * rpkg (fedpkg)? * koji (if no git commit is provided)? * COPR? * Koschei or other such services? P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass spec file change: Adding BuildRequires: make
On Tue, Dec 1, 2020 at 7:38 PM Tom Stellard wrote: > > On 12/1/20 8:33 AM, Vít Ondruch wrote: > > > > Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a): > >> On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote: > >>> Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a): > False positive because they use gcc which was crashing due to the > (at the time) missing make dependency. Are these packages missing > BuildRequires: gcc ? > > > >>> Do I understand correctly, that gcc requires make [0]? Therefore at > >>> this stage, it should be enough to have `BuildRequires: gcc` and > >>> hence such packages should not be on your list? > >> Please don't rely on gcc requiring make. This is an internal > >> implementation detail of the gcc package, and hopefully one day > >> we'll be able to drop this dependency. > >> If a package uses make directly, it should BR:make itself. > > > > > > I think this was never clear cut if such dependency should be specified > > or not. The dependencies, which are at some point added for whatever > > good reason might be left behind while they are not useful anymore. This > > problem on itself is much harder to solve then adding the missing > > dependencies should they be needed one day. > > > > So while I don't disagree with your point, I think the the `BR: make` > > should be automatically added only where needed right now to prevent > > FTBFS after make removal. > > > > Now that gcc requires make, if we took this approach there would be very > few packages that need to be updated for this change request. If gcc > did decide to drop the make dependency or make it weak, who would take > on the work of updating the thousands of packages that use make? Right > now, we have someone (me) who is willing an able to do the updates, and > I think we should this is a good reason to update all the packages now. Please, update all of them. Assuming that something is present because default buildroot / my dependencies have always pulled it in for me / magic just leads to unexpected future breakage. If the packages call make, they need to BR make. And the same for everything else. Yes, packages might accumulate dependencies that are no longer required but it's the packager's responsibility to ensure everything is up-to-date. Rebasing isn't just about uploading a new tarball and checking if it builds. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass spec file change: Adding BuildRequires: make
On Mon, Nov 30, 2020 at 11:10 PM Tom Stellard wrote: > If you are a package maintainer and would prefer to update your packages > on your own, please do so before Dec 14, which is when I will begin > doing the mass update. Checking packages linked to my name... pamix: only calls %cmake macros, BRs cmake, so that's the other topic perl-Dist-Zilla-Plugin-Test-Compile: uses perl(Module::Build); false positive, I believe sselp: fixed & switched to %make_* macros P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How is the list of emails used for "Email sent to" on bugzilla.redhat.com generated?
On Thu, Nov 26, 2020 at 12:30 PM Marcin Dulak wrote: > > I noticed several, surprising to me email addresses, listed under "Email sent > to" when making changes to my bugzilla.redhat.com bugs. > For example this bug https://bugzilla.redhat.com/show_bug.cgi?id=1900680 > > The individual email recipients used for "Email sent to" are not included in > the given bug "CC list", and the only other email in the bug settings seems > to be "extras...@fedoraproject.org". > I don't see anybody "watching" the spec repository > https://src.fedoraproject.org/rpms/nwchem. > > The situation is similar to > https://bugzilla.redhat.com/show_bug.cgi?id=680247, except my bug and > comments are public. > > How/why are those additional email addresses added? People can also watch you specifically; it's a Bugzilla setting. For instance I watch all people I've ever sponsored into the packager group, as well as some others. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: finding recursive builddeps
On Sun, Nov 15, 2020 at 4:13 PM Jason Edgecombe wrote: > > Hi everyone, > > I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for > example), but I'm having trouble getting all of the build dependencies right. > I ran dnf to download the SRPMS with the --resolve option, but I'm still > missing dependencies when I submit the builds to copr. > > My current workflow is to download an RPM from Fedora 33, then submit it to > copr to build on the EPEL8 image in my personal COPR projects, waiting for > any library errors, then download those and build, repeat as needed. > > That workflow is tedious and I feel like there must be a better way, but I > don't know what that is. How can I recursively find all of the builddeps for > packages? > > Ideally, I would like some type of (semi-)automated way to track packages on > Fedora and automatically build them on EL8, but I'm at a loss for how to do > so. > > Thanks, > Jason That is a common [bootstrapping] problem, yes. In short, you need to query the SRPM & RPM dependencies and their runtime and build time dependencies, recursively. You also need to do that on every architecture (due to the potential use of conditional build deps), so your process should involve SRPM rebuilds as the ones you download from Fedora repos have only been built on one; and it's random -- there's a chance you won't be able to resolve your tree if you use those. Binary RPMs are already available for all arches so you just need to fetch the repodata. You can do all this on a single host and arch, don't worry. No uploads and actual RPM builds are necessary. Once you have your package list, just compare it to your target distribution's package list and you have your set. It's no longer maintained and it was rather quirky buy could try depchase; it did exactly this when we were experimenting with fully modular distributions: https://github.com/fedora-modularity/depchase P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
On Wed, Nov 4, 2020 at 7:16 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot > > == Summary == > This change will remove make from the default buildroot in Koji and mock. Huge +1 here, by the way. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
On Wed, Nov 4, 2020 at 7:52 PM Richard Shaw wrote: > > Is the expectation to explicitly BR: make? > > Or would pulling in autotools/automake/cmake suffice? My general approach is that if I call it, or call things in my package that directly call it, I buildrequire it. If you do that, you don't have to worry about your build breaking because of suddenly missing deps when the deps of your deps (all the way down) change or something like this gets removed from the default buildroot. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: EOL and Obsoletes in Modularity
On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar wrote: > Another option would be adding the EOL data into modules dist-git > repositories. To the same branches where modules are built from. But > a different file. Pungi would enumarate all module builds directed to > a compose, locate their dist-git sources by mapping name:stream to > git://src.fedoraproject/org/modules/name.git#stream and download EOL data from > there. That would enable module maintains to control EOLs simply by pushing an > eol.yaml file into the branch of the module. This is not a reliable method as the branch name can be anything if stream name is defined in modulemd. Technically even the repository name can be anything. You could look at the xmd section and check out the relevant commit used to build it. That would imply you couldn't change EOL for already built artifacts, however. Only new ones. Also I don't remember if xmd gets stripped during compose. If so, pungi would need to ask MBS or Koji about every build. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-06-15)
= #fedora-meeting-1: FESCO (2020-06-15) = Meeting started by contyk at 15:00:27 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-06-15/fesco.2020-06-15-15.00.log.html Meeting summary --- * init process (contyk, 15:00:33) * Welcome new FESCo members & Meeting time (contyk, 15:02:15) * The new meeting time is Wednesday, 1400 UTC, starting June 24. (contyk, 15:18:33) * Council Engineering Representative (contyk, 15:21:17) * LINK: https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/ (contyk, 15:21:33) * contyk will step down from the Council Engineering representative position; FESCo will process the nominations in #2405 over the next week. (contyk, 15:24:20) * #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change (contyk, 15:24:55) * AGREED: FESCo asks rrelyea to rephrase the request and add details about the expected impact, particularly on rebuilds and revisit in a week (+8, 0, -0) (contyk, 15:34:38) * What is the scope of Modularity? (contyk, 15:35:03) * AGREED: Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+9, 0, -0) (contyk, 15:58:47) * There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such (contyk, 15:58:54) * AGREED: Default streams are not allowed in Fedora. This may be revised in the future, especially if the functionality of default streams is improved. (+9, 0, -0) (contyk, 16:00:26) * AGREED: Encourage compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability). (+9, 0, -0) (contyk, 16:02:07) * AGREED: Make *modular*.repo optional by splitting them into a separate package. (+8, 1, -0) (contyk, 16:03:24) * AGREED: Disable *modular*.repo by default in new installations. (2, 0, -7) (contyk, 16:04:58) * Modular repo will remain enabled. (contyk, 16:05:05) * AGREED: Defer to the next meeting. Meanwhile sgallagh will work on improving policy for those modules with feedback from FESCo members. (+9, 0, -0) (contyk, 16:52:36) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJD3V43ONMVE37DQO6RVQ5ZGN6PJXDBC/ is the case on fedora-devel today. (zbyszek, 16:52:38) * Next week's chair (contyk, 16:52:56) * ACTION: ignatenkobrain will chair the next meeting. (contyk, 16:53:25) * Open Floor (contyk, 16:53:32) * LINK: https://docs.fedoraproject.org/en-US/fesco/ is not getting updated. (zbyszek, 16:55:06) * LINK: https://pagure.io/fedora-infrastructure/issue/8964 (bcotton, 16:56:54) Meeting ended at 16:59:24 UTC. Action Items * ignatenkobrain will chair the next meeting. Action Items, by person --- * ignatenkobrain * ignatenkobrain will chair the next meeting. People Present (lines said) --- * mhroncok (153) * sgallagh (120) * contyk (107) * zbyszek (70) * nirik (57) * King_InuYasha (54) * ignatenkobrain (51) * dcantrell (49) * zodbot (34) * cverna (30) * decathorpe (28) * bookwar (21) * bcotton (9) * Conan_Kudo (0) * Eighth_Doctor (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2020-06-15)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-06-15 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Special topics = #topic Welcome new FESCo members & Meeting time https://pagure.io/fesco/issue/2407 #topic Council Engineering Representative #link https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/ https://pagure.io/fesco/issue/2405 = Discussed and Voted in the Ticket = F33 Self-Contained Change: Drop mod_php https://pagure.io/fesco/issue/2402 APPROVED (+4, 2, -0) F33 Self-Contained Change: No more automagic Python bytecompilation (phase 3) https://pagure.io/fesco/issue/2401 APPROVED (+6, 0, -0) F33 System-Wide Change: Node.js 14.x by default https://pagure.io/fesco/issue/2391 APPROVED (+5, 0, -0) = Followups = #topic What is the scope of Modularity? https://pagure.io/fesco/issue/2114 #topic Request to permit module default streams in ELN https://pagure.io/fesco/issue/2390 = New business = #topic #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change https://pagure.io/fesco/issue/2400 = 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Mondays's FESCo Meeting (2020-06-08) — proposal to cancel
On Mon, Jun 8, 2020 at 2:46 PM Miro Hrončok wrote: > > On 08. 06. 20 13:36, Petr Šabata wrote: > > Hi, > > > > while we have some open tickets, we're waiting for the Modularity > > presentation later this week. In the meantime, the discussion > > continues in the tickets. There doesn't appear to be anything else to > > discuss today so I'm proposing we cancel the meeting. > > +1 > > > I'll chair the next one. > > If it is needed, I can chair the next one (I'm not being re-elected this > time). Thanks but I think I can chair it even if I don't get re-elected; no harm in that :) P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2020-06-08) — proposal to cancel
Hi, while we have some open tickets, we're waiting for the Modularity presentation later this week. In the meantime, the discussion continues in the tickets. There doesn't appear to be anything else to discuss today so I'm proposing we cancel the meeting. I'll chair the next one. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Wed, Apr 29, 2020 at 9:43 PM Colin Walters wrote: > > On Mon, Apr 27, 2020, at 7:19 AM, Petr Šabata wrote: > > > Details in the gist: > > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408 > > How about s/use/globalbuildopt/ ? Please, no :) The reason I went with "use" is because this is reimplementing a Gentoo concept and is virtually identical. I wanted to keep the terminology as many people are already familiar with it. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Tue, Apr 28, 2020 at 9:55 AM Nicolas Mailhot via devel
wrote:
>
> Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
> > On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> > >
> > > %_use_ncurses %{lua:
> > > if rpm.expand("%{name}") == "yourpackage1"
> > > or rpm.expand("%{name}") == "yourpackage2" then
> > > print(rpm.expand("%{bcond_with foo}%{with foo}"))
> > > else
> > > print(rpm.expand("%{bcond_without foo}%{with foo}"))
> > > end
> > > }
>
> %{name} use in macro logic is unsafe because %{name} does not exist in
> the preamble before the Name: line, and the Name: line does not exist
> before you start declaring package headers.
>
> Once you’re in package
> header declaration mode rpm parser behaviour will prevent you from
> doing logic between headers blocks, so it all needs interleaving, which
> ends un not possible sanely in any semi-complex spec file.
You're correct but I can't think of any solution besides not using the
macros before you define Name, just like in your example below. It's
certainly a drawback.
P
> The rpm parser will now insult you with messages like
> warning: undefined macro(s) in %{_sourcedir}:
> /var/lib/builder/rpmbuild/SOURCES/%{name}
>
> if you try to use %{name} at the srpm level.
>
> This is an rpm 4.15 change
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
>
> Regards,
>
> --
> Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Tue, Apr 28, 2020 at 8:55 AM Petr Pisar wrote:
>
> On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> > On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar wrote:
> > > (2) Is it possible to override them on a per-package basis?
> > >
> > > E.g. I have ncurses in global.yaml:
> > >
> > > - name: ncurses
> > > description: Add support for ncurses.
> > > enabled: true
> > >
> > > and I have plenty of packages that use the ncurses feature in my module.
> > > What
> > > should I write to my modulemd so that "ncurses" feature for "pcre"
> > > package is
> > > disabled, but all the other packages have it enabled? Or is it a
> > > completelly
> > > illed request to have the same feature enabled at one package and
> > > disabled on
> > > another one?
> >
> > It is and that's actually how the local is implemented. It extends the
> > basic definitions with %{name} checks like this:
> >
> > %_use_ncurses %{lua:
> > if rpm.expand("%{name}") == "yourpackage1"
> > or rpm.expand("%{name}") == "yourpackage2" then
> > print(rpm.expand("%{bcond_with foo}%{with foo}"))
> > else
> > print(rpm.expand("%{bcond_without foo}%{with foo}"))
> > end
> > }
> >
> > I know it's not very user friendly. Maybe there's a better way that
> > doesn't blow up on recursive macro definition.
> >
> Do I understand it correctly that modules should reimplement the %_use_ncurses
> macro? That's really clumsy and I'd like to avoid it. Not speaking about the
> issues with recursion you are aware and I was hoping you found a solution.
> Modules would have to simply redefine the macro covering all packages built in
> the module.
Yes, it is clumsy and you're correct here.
MBS also just extends the macro definitions so I'm not sure how to
work around the recursion problem even if we introduced a new modulemd
section just for this (which wouldn't feel right either). Would you
have any suggestions?
> Since you use Lua (because RPM conditions are not allowed there), wouldn't
> be better to export the mapping from a package name to a feature as a Lua
> associative array? Modules would then just added/rewrote a tuple there and
> than call a Lua function to regenerate the %_use macros?
Yes, that would be nicer. I'll look into that.
> Actually if the generation of the macros was postponed to a spec file, there
> would not have to exist any local.yaml file. That way the spec file would be
> be self-contained. I agree with others that separating the local overrides
> into local.yaml maintained in a different package is not handy and slows the
> packager's work flow.
But it also defeats the idea of these being set by the system, leaving
package repos untouched.
P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Tue, Apr 28, 2020 at 3:40 AM clime wrote:
>
> Few more notes:
>
> I think an idea that build system could be simply passing
> --with/--without options on mock's command-line should be
> considered...then basically no change in spec files is needed (i.e. no
> syntax change).
Yes but I'd say such a change would be more complex and invasive. You
would still need a place to store these values and make sure the
systems (koji, mocks, rpmbuilds on the system, many more) would read
the correct configs and pass the values.
> It would be great if rpm remembered either the rpmbuild's command-line
> in case the solution above is chosen or the set of with options (and
> the final values for them) that were used during build if the
> buildroot config approach is chosen. I think that would be very useful
> for debugging and inspection of rpms.
>
> ...that's probably it from me.
>
> clime
>
> On Tue, 28 Apr 2020 at 03:06, clime wrote:
> >
> > On Mon, 27 Apr 2020 at 13:21, Petr Šabata wrote:
> > >
> > > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > > and %bcond generally being confusing to work with, I came up with a
> > > distribution-wide feature that defines generic feature keywords and
> > > associated helper macros that packages can check in build-time
> > > conditionals.
> > >
> > > The key advantage here is the defaults are defined by the buildroot,
> > > not the package. The package is just a building block.
> > >
> > > I'd like some input to improve this and unless this turns out to be a
> > > really bad idea, I intend to submit it as a change proposal. Even
> > > though the more packages use it the more beneficial it gets, it's, of
> > > course, perfectly optional.
> > >
> > > Details in the gist:
> > > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> >
> > Ad. Dan Mach's presented spec file:
> >
> > > https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec
> >
> > I really like how all the switches are defined almost on top of the
> > spec file so I think lots of inspiration can be drawn from that.
> >
> > Now I also think that introduction of the new %use scheme for build
> > options instead of the current with/without scheme might be an
> > overkill.
> >
> > I think lines like these:
> >
> > %bcond_with html
> > %bcond_without man
> >
> > could be replaced by:
> >
> > %with_option_env html 0
> > %with_option_env man 1
> >
> > i.e. %with_option_env
> >
> > %with_option_env could be looking at an environmental buildroot
> > setting with the possibility to be overridden on command-line by
> > --with and --without as usual.
> >
> > There could be also:
> > %with_option
> >
> > which wouldn't look at environment settings so it would be the same
> > thing as %bcond_with/%bcond_without but less confusing.
> >
> > So with this, you wouldn't need to change conditions like:
> >
> > %if %{with foo}
> > ...
> > %endif
> >
> > and
> >
> > %if %{without foo}
> > ...
> > %endif
> >
> > ...so fewer changes and less work. I also think these conditions are
> > quite fine (except relying on with_foo being either defined or
> > undefined, which is quite funky but I don't think it is a reason to
> > replace them).
I was trying to keep SPEC files as brief as possible. The first time
you call any of these macros, the feature is initialized even without
any preamble definitions. These are already compatible with
--with/--without so you can override the defaults with them.
Technically you could do just #%{use foo} in your preamble and then
work with %with and %without, which is pretty much what you're
suggesting. However, combining the two approaches feels more ugly and
confusing to me than sticking to one.
> > The yml files and translation from them into the actual macro files
> > are nice but I would consider if the hw dependent default values can
> > be added in future as a feature.
> >
> > The local_.yml file seems somewhat out of place to me. I think it
> > could be rather kept as an idea for future and for now we could just
> > start with only buildroot configs?
It's a possibility for packages that want or need it. I wouldn't
expect many if any local files in the beginning.
P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 6:38 PM Vít Ondruch wrote:
>
>
> Dne 27. 04. 20 v 16:25 Petr Šabata napsal(a):
> > On Mon, Apr 27, 2020 at 3:01 PM Vít Ondruch wrote:
> >>
> >> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> >>> Based on the recent discussions around %fedora/%rhel macros and ELN,
> >>> and %bcond generally being confusing to work with, I came up with a
> >>> distribution-wide feature that defines generic feature keywords and
> >>> associated helper macros that packages can check in build-time
> >>> conditionals.
> >>
> >> The most confusing part of the %bcond is the definition itself. The rest
> >> is fine IMO. Therefore, I somehow don't understand why would you like to
> >> replace:
> >>
> >>
> >> ```
> >>
> >> %if %{with ssl}
> >> BuildRequires: openssl-devel
> >> %endif
> >>
> >> ```
> >>
> >>
> >> by
> >>
> >>
> >> ```
> >>
> >> %if %{use ssl}
> >> BuildRequires: openssl-devel
> >> %endif
> >>
> >> ```
> > The difference here is %use defaults are defined by the buildroot
> > while %with %bconds are defined by the package.
>
>
> Looking at the provided example and the binary RPM and what not, I am
> still confused and it is not clear to me what you actually want to achieve.
>
> I think the biggest issue I have is that you seems to propose to use the
> `%{use ssl}`, `%{use_enable ssl openssl}` and `%{?_use_ssl:-DSSL}` in
> places, where it would make more sense to use the well established
> `with/without` rpm(build) macros.
>
> Also, this `%{use_enable ssl openssl}` for example looks like you have
> some distribution wide `ssl` feature, but you want to locally implement
> it via openssl and moreover it seems you are trying to address the case
> where `configure` does not accept with/without but enable/disable
> instead (which was probably not an issue so far, otherwise rpmbuild
> would probably provide enable/disable options alongside with/without).
Yes, this is exactly what I'm trying to achieve -- to have
distribution-wide generic keywords that control default build options
in packages. In the example SSL support is enabled via the openssl
package.
The well-established with/without options and their defaults are bound
to the package, not the buildroot, which is the key idea behind this,
not the exact helper scripts. Considering it's a repeated point in
this thread, I should have done better job emphasizing it :)
> IOW it could be probably better if there was something like `%{use ssl
> openssl}` call on top of the .spec file, which would enable use of
> standard RPM macros instead of introducing set of new macros. This would
> also make the `general availability` section much shorter, because there
> would be probably need to check the macro existence on a single place.
Something like that could be done and would be an option if no one
cared for the helper macros (currently limited to autotools but the
list could grow). We could actually make this nice and SPECs more
readable.
P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar wrote:
>
> On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> >
> I'm very interested in overriding the global settings:
>
> (1) Is it possible to override them from a modulemd when building a module?
>
> I guess the asnswer is define %_with_ and %_without_ macros in
> a buildopts/rpms/macros section of the module. Could elaborate more
> the "Compatibility with RPM's --with & --without options" section?
Yes, you can, and that's exactly how you would do that.
Currently the macros as defined with bconds, in the basic form for
enabled by default:
%_with_foo %{bcond_without foo}%{with foo}
> Please note hat the RPM options and the macros have three states (true, false,
> undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
> I don't ask about preserving a compatibility with this silly semantics, but
> some clarification will be needed if this proposal becomes approved.
It might not work if with/without is set with these macros directly as
it is written right now. I'll have to test that.
> (2) Is it possible to override them on a per-package basis?
>
> E.g. I have ncurses in global.yaml:
>
> - name: ncurses
> description: Add support for ncurses.
> enabled: true
>
> and I have plenty of packages that use the ncurses feature in my module. What
> should I write to my modulemd so that "ncurses" feature for "pcre" package is
> disabled, but all the other packages have it enabled? Or is it a completelly
> illed request to have the same feature enabled at one package and disabled on
> another one?
It is and that's actually how the local is implemented. It extends the
basic definitions with %{name} checks like this:
%_use_ncurses %{lua:
if rpm.expand("%{name}") == "yourpackage1"
or rpm.expand("%{name}") == "yourpackage2" then
print(rpm.expand("%{bcond_with foo}%{with foo}"))
else
print(rpm.expand("%{bcond_without foo}%{with foo}"))
end
}
I know it's not very user friendly. Maybe there's a better way that
doesn't blow up on recursive macro definition.
P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 3:01 PM Vít Ondruch wrote:
>
>
> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
>
>
> The most confusing part of the %bcond is the definition itself. The rest
> is fine IMO. Therefore, I somehow don't understand why would you like to
> replace:
>
>
> ```
>
> %if %{with ssl}
> BuildRequires: openssl-devel
> %endif
>
> ```
>
>
> by
>
>
> ```
>
> %if %{use ssl}
> BuildRequires: openssl-devel
> %endif
>
> ```
The difference here is %use defaults are defined by the buildroot
while %with %bconds are defined by the package.
> Also I don't understand, why there is exposed some underscore macro,
> such as `make test %{?_use_ssl:-DSSL}`. Shouldn't the underscore macro
> be just implementation detail? For `%bcond`s, the `_with` macros are
> discouraged, so why would you encourage them?
Yes, this should be an internal detail. I'd like to replace this with
%use_defined or something similar.
P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 3:42 PM Robin Lee wrote: > > On Mon, Apr 27, 2020 at 7:21 PM Petr Šabata wrote: > > > > Based on the recent discussions around %fedora/%rhel macros and ELN, > > and %bcond generally being confusing to work with, I came up with a > > distribution-wide feature that defines generic feature keywords and > > associated helper macros that packages can check in build-time > > conditionals. > > > > The key advantage here is the defaults are defined by the buildroot, > > not the package. The package is just a building block. > > > > I'd like some input to improve this and unless this turns out to be a > > really bad idea, I intend to submit it as a change proposal. Even > > though the more packages use it the more beneficial it gets, it's, of > > course, perfectly optional. > > > > Details in the gist: > > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408 > Should the use flags be automatically recorded in Provides of binary packages? > Package A "Provides: A(+feature)" > Then package B may 'Requires: A(+feature)" > > That semantics is implemented in Gentoo. Yes, I think that's a good idea. I already have that in the Ideas section of the gist, although with a more verbose format. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 2:15 PM Daniel P. Berrangé wrote:
>
> On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
> >
> > The key advantage here is the defaults are defined by the buildroot,
> > not the package. The package is just a building block.
>
> IMHO it is valuable having the package self-contained as it is
> today, as both maintainers & users are able to see and control
> exactly what features are intended, from a single place.
>
> With this proposal they'd have to read the global.yml and the
> local.$PKG.yml and the $PKG.spec file to figure out what is going
> to be built. Some features will need to vary per-architecture too,
> so this will need a global-$ARCH.yml and a local-$ARCH.$PKG.yml file
> too for each Fedora arch, or the global.yml file will need to ship
> different content on each arch somehow. So that's potentially 3-5
> files that need to be consulted to figure out what the enabled
> features are for a given package build.
Yes, there is this additional complexity of changing it / looking at
two different places but that's the price paid for having the package
itself independent and the features set by the environment. These
approaches are not exclusive, people can use whichever method,
although I obviously prefer the latter. Hence this proposal.
You're correct about the architecture-specific needs. I wanted to keep
this simple and have people check for that in their packages. However,
that might be contradicting the point above. Architecture-specific
macros would solve this but be more complex to navigate and maintain.
> > I'd like some input to improve this and unless this turns out to be a
> > really bad idea, I intend to submit it as a change proposal. Even
> > though the more packages use it the more beneficial it gets, it's, of
> > course, perfectly optional.
>
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
> IIUC, the global.yml file is intended to live in the use-macros
> package. It wasn't clear though where the local-$PKG.yml file is
> intended to live ? Is it for the use-macros too, or in the
> per-package dist-git ?
Both global and local macros live in the use-macros package. The YAMLs
are sources and generate a single file with all the macros defined in
it. Again, there's nothing binding the distribution local YAMLs to the
packages themselves; they could be built in completely different
buildroots with different macros set from exactly the same commit.
> I'd be concerned about the per-package yml file living in "use-macros"
> because that would means when package maintainers need to rebase to a
> newer release, they potentially have to wait for any "use-macros" update
> to be approved & built before they can update their specfile in Fedora
> and do a build based on those features. This could also be an impact for
> users trying to build new upstream releases in Copr, if the features for
> the new upstream release ned to be different from those in the existing
> release for that Fedora release stream.
It's true this requires some coordination or uglier package checks
(assume the originally submitted default value if undefined and
simplify it later).
> On the point about trying to maintain compat for existing distros which
> lack %use macros. I think the example shown is not the route I would take.
>
> Instead I'd just define a %{with_XXX} macro for the feature upfront, based
> on the %{use XXX} macro value, and then not use the %use macros at all.
> In fact I might be inclined to do this even ignoring the old distro compat
> question, because it makes it easy to override the %{use} global defaults
> in the package.
>
> %define with_foo %{?use:%{use foo}}%{!?use:1}
>
> %if %{with_foo}
> BuildRequires: foo-devel
>
> % define foo_configure_arg --with-foo
> % define foo_test_arg -Dfoo
> %endif
>
> %prep
> %configure %{?foo_configure_arg}
>
> %check
> make test %{?foo_test_arg}
You should also explicitly define --without-foo here. Sure, you could
do it this way if you think it's nicer.
> NB The "%{use_enable ...}" macro is targetting autoconf syntax, but
> autotools is not the only build system. Should this aim for a
> consistent approach - either provide macros for all build systems,
> or for none.
I started with these two helpers because autotools a
Re: RFC: Feature macros (aka USE flags)
On Mon, Apr 27, 2020 at 1:24 PM Neal Gompa wrote: > > On Mon, Apr 27, 2020 at 7:21 AM Petr Šabata wrote: > > > > Based on the recent discussions around %fedora/%rhel macros and ELN, > > and %bcond generally being confusing to work with, I came up with a > > distribution-wide feature that defines generic feature keywords and > > associated helper macros that packages can check in build-time > > conditionals. > > > > The key advantage here is the defaults are defined by the buildroot, > > not the package. The package is just a building block. > > > > I'd like some input to improve this and unless this turns out to be a > > really bad idea, I intend to submit it as a change proposal. Even > > though the more packages use it the more beneficial it gets, it's, of > > course, perfectly optional. > > > > Details in the gist: > > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408 > > > > This looks pretty good! Have you considered submitting it into > upstream RPM so that we don't wind up having so many catch-22s with > its usability, though? That would be an option, even though it would have to work somehow differently, I presume. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
RFC: Feature macros (aka USE flags)
Based on the recent discussions around %fedora/%rhel macros and ELN, and %bcond generally being confusing to work with, I came up with a distribution-wide feature that defines generic feature keywords and associated helper macros that packages can check in build-time conditionals. The key advantage here is the defaults are defined by the buildroot, not the package. The package is just a building block. I'd like some input to improve this and unless this turns out to be a really bad idea, I intend to submit it as a change proposal. Even though the more packages use it the more beneficial it gets, it's, of course, perfectly optional. Details in the gist: https://gist.github.com/contyk/0f0585c57976ca18a293b3566408 Cheers, P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-04-06)
= #fedora-meeting-1: FESCO (2020-04-06) = Meeting started by contyk at 15:00:22 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-06/fesco.2020-04-06-15.00.log.html Meeting summary --- * init process (contyk, 15:00:28) * #2369 Request: Postpone F32 Final Freeze by 3 ≤ N ≤ 7 days (contyk, 15:02:40) * AGREED: Fedora 32 Final Freeze is posponed to Thursday 2020-04-09 14:00 UTC (+9, 0, -0) (contyk, 15:13:12) * ACTION: bcotton to update schedule (bcotton, 15:13:24) * #2364 F33 System-Wide Change: Introduce module Obsoletes and EOL (contyk, 15:14:16) * This topic needs more discussion and responses from the proposal owners. We'll discuss this next week. (contyk, 15:16:44) * #2365 F33 System-Wide Change: ELN Buildroot and Compose (contyk, 15:17:43) * sgallagh will address mhroncok's comments and clarify the proposal; we will vote next week; in case of no quorum, we commit to voting in the ticket async. (contyk, 15:24:47) * Next week's chair (contyk, 15:37:36) * ACTION: sgallagh will chair the next meeting. (contyk, 15:39:19) * ACTION: mhroncok will chair the meeting of 2020-04-20 (contyk, 15:39:29) * Open Floor (contyk, 15:39:38) Meeting ended at 15:41:11 UTC. Action Items * bcotton to update schedule * sgallagh will chair the next meeting. * mhroncok will chair the meeting of 2020-04-20 Action Items, by person --- * bcotton * bcotton to update schedule * mhroncok * mhroncok will chair the meeting of 2020-04-20 * sgallagh * sgallagh will chair the next meeting. People Present (lines said) --- * contyk (47) * sgallagh (32) * mhroncok (25) * nirik (20) * zodbot (19) * adamw (13) * zbyszek (9) * dcantrell (8) * decathorpe (7) * ignatenkobrain (5) * mboddu (4) * bookwar (3) * bcotton (3) * frantisekz (2) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2020-04-06)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-04-06 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = New business = #topic #2364 F33 System-Wide Change: Introduce module Obsoletes and EOL https://pagure.io/fesco/issue/2364 #topic #2365 F33 System-Wide Change: ELN Buildroot and Compose https://pagure.io/fesco/issue/2365 = 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-02-24)
= #fedora-meeting-1: FESCO (2020-02-24) = Meeting started by contyk at 15:00:04 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-24/fesco.2020-02-24-15.00.log.html . Meeting summary --- * init process (contyk, 15:00:10) * #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to ban default modular streams) (contyk, 15:01:53) * LINK: https://pagure.io/fesco/issue/2341#comment-627466 (nirik, 15:03:42) * AGREED: For Fedora 32 and onward, all default modular streams are banned. Existing defaults are removed. (+8, 0, -0) (contyk, 15:25:24) * #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) (contyk, 15:26:14) * No change in last week's FESCo decision, the ticket can be closed. (contyk, 15:27:52) * #2328 F32 Self-Contained Change: Additional buildroot to test x86-64 micro-architecture update (contyk, 15:28:11) * AGREED: Provided releng agrees, the change proposal is approved. (+7, 0, -0) (contyk, 15:52:12) * #2342 F32 incomplete Changes (contyk, 15:52:40) * LINK: https://pagure.io/fedora-infrastructure/issue/7677 (nirik, 16:01:43) * DNF Better Counting: Non-blocking, client-side done, let's give the server-side part more time. (contyk, 16:02:59) * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1469799 (mhroncok, 16:05:02) * Free Pascal Compiler 3.20: Appears to be done, bug status should be updated. (contyk, 16:05:03) * LLVM 10: Appears to be done, bug status should be updated. (contyk, 16:06:02) * LINK: https://src.fedoraproject.org/rpms/clang/blob/master/f/clang.spec has -DBUILD_SHARED_LIBS=OFF, not yet sure if built or just committed (mhroncok, 16:07:45) * Restart services at end of rpm transaction: Status unclear; if no action is taken before the deadline, let's move this to F33. (contyk, 16:16:40) * Stop shipping individual component libraries in clang-libs package: Appears to be done, bug status should be updated. (contyk, 16:18:28) * Use update-alternatives for /usr/bin/cc and /usr/bin/c++: Moved to F33, any changes should be reverted. (contyk, 16:20:28) * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b0652e4f4b (2 hours ago ;) (nirik, 16:22:08) * Haskell package to Stackage LTS 14: Done. (contyk, 16:22:12) * Ship BerkeleyDB backend as a module: Moved to F33. (contyk, 16:23:03) * Limit scriptlet usage of core packages: An ongoing change, status unknown. No action needed. (contyk, 16:25:18) * #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint (contyk, 16:25:36) * AGREED: Close for now; as soon as something is ready to enable, ask us again about that specific thing (+6, 0, -0) (contyk, 16:42:31) * #2340 Get a process established to remove branches (contyk, 16:42:44) * LINK: https://pagure.io/fedora-infrastructure/issue/8390 (nirik, 16:47:40) * AGREED: Branches reachable from any other branch that are not used for building anything can be removed (+6, 0, -0) (contyk, 16:51:52) * #2344 Enable new fonts packaging guidelines in F31 (contyk, 16:52:19) * FPC approval is sufficient in this case. (contyk, 16:54:25) * No explicit approval needed for backwards compatible changes Close the ticket. (contyk, 16:59:56) * Next week's chair (contyk, 17:00:08) * ACTION: mhroncok will chair the next meeting. (contyk, 17:01:29) * Open Floor (contyk, 17:01:33) * beta freeze/bodhi enablement is at 14UTC on tuesday (2020-02-25). We moved it from 00:00, so 14 extra hours... (contyk, 17:02:42) Meeting ended at 17:03:13 UTC. Action Items * mhroncok will chair the next meeting. Action Items, by person --- * mhroncok * mhroncok will chair the next meeting. People Present (lines said) --- * contyk (145) * mhroncok (92) * nirik (71) * sgallagh (58) * decathorpe (39) * dcantrell (28) * zodbot (24) * bookwar (15) * nim-nim (8) * ignatenkobrain (5) * tflink (4) * smooge (3) * zbyszek (0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Mondays's FESCo Meeting (2020-02-24)
Sure. On Mon, Feb 24, 2020 at 2:01 PM Nicolas Mailhot wrote: > > Le 2020-02-24 13:37, Petr Šabata a écrit : > > Following is the list of topics that will be discussed in the > > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > > irc.freenode.net. > > Hi, > > Can you please add > https://pagure.io/fesco/issue/2344 > > to the list since FESCO arbitration was requested within the project? > Regards, > > -- > Nicolas Mailhot > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2020-02-24)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-02-24 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to ban default modular streams) https://pagure.io/fesco/issue/2341 #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) https://pagure.io/fesco/issue/2339 #topic #2328 F32 Self-Contained Change: Additional buildroot to test x86-64 micro-architecture update https://pagure.io/fesco/issue/2328 = New business = #topic #2342 F32 incomplete Changes https://pagure.io/fesco/issue/2342 #topic #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint https://pagure.io/fesco/issue/2343 #topic #2340 Get a process established to remove branches https://pagure.io/fesco/issue/2340 = 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Points of contact for Modularity
Just a minor FYI announcement: As most of the original Modularity Team is moving on to face new challenges, Red Hat's effort will now be primarily represented by the software management group, with Daniel Mach coming up with an updated Modularity Objective in the following weeks. In essence, everything remains the same; continue using the Pagure tracker and our IRC channel when interacting with the team -- just expect to see "new" faces from now on. The weekly meetings are temporarily cancelled until the group agrees on a new time slot and way of working. Thank you, P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-01-13)
= #fedora-meeting-1: FESCO (2020-01-13) = Meeting started by contyk at 14:59:55 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-01-13/fesco.2020-01-13-14.59.log.html Meeting summary --- * init process (contyk, 15:00:07) * #2310 F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ (contyk, 15:05:16) * LINK: https://pagure.io/fesco/issue/2310 (contyk, 15:05:18) * AGREED: F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ is approved (+6, 2, -1) (contyk, 15:27:09) * #2309 F32 System-Wide Change: Enable fstrim.timer by default (contyk, 15:28:05) * LINK: https://pagure.io/fesco/issue/2309 (contyk, 15:28:07) * AGREED: F32 System-Wide Change: Enable fstrim.timer by default is approved (+6, 3, -0) (contyk, 15:44:19) * #2312 Python2 exception for mailman (contyk, 15:45:06) * LINK: https://pagure.io/fesco/issue/2312 (contyk, 15:45:12) * AGREED: Time estimate and approval from relevant parties should be provided by the end of the months or the package will be retired; can be unretired later when ported (+8, 0, -0) (contyk, 15:52:08) * Next week's chair (contyk, 15:52:31) * ACTION: mhroncok will chair the next meeting. (contyk, 15:53:03) * Open Floor (contyk, 15:53:08) Meeting ended at 15:56:07 UTC. Action Items * mhroncok will chair the next meeting. Action Items, by person --- * mhroncok * mhroncok will chair the next meeting. People Present (lines said) --- * contyk (62) * dcantrell (34) * mhroncok (30) * zodbot (19) * zbyszek (19) * cmurf (16) * sgallagh (14) * nirik (11) * decathorpe (9) * ignatenkobrain (7) * tstellar (6) * bookwar (5) * bcotton (1) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-01-06)
= #fedora-meeting-1: FESCO (2020-01-06) = Meeting started by contyk at 15:00:16 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-01-06/fesco.2020-01-06-15.00.log.html Meeting summary --- * init process (contyk, 15:00:34) * #2303 F32 System-Wide Change: Drop Optical Media Release Criterion (contyk, 15:02:22) * LINK: https://pagure.io/fesco/issue/2303#comment-617872 (nirik, 15:04:04) * AGREED: Blocking status remains unchanged, however FESCo no longer requires QA to test and report on physical media as part of the formal release criteria. (+6, 2, -0) (contyk, 15:19:56) * LINK: https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking has the limits (zbyszek, 15:22:10) * Next week's chair (contyk, 15:22:52) * ACTION: contyk will chair the next meeting. (contyk, 15:24:18) * Open Floor (contyk, 15:24:23) * #2310 F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ (contyk, 15:27:04) * LINK: https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ (mhroncok, 15:32:08) * AGREED: FESCo will discuss #2310 next week (+8, 0, -0) (contyk, 15:39:02) Meeting ended at 15:47:36 UTC. Action Items * contyk will chair the next meeting. Action Items, by person --- * contyk * contyk will chair the next meeting. People Present (lines said) --- * contyk (59) * mhroncok (44) * sgallagh (39) * dcantrell (28) * zbyszek (25) * nirik (19) * zodbot (18) * frantisekz (10) * ignatenkobrain (9) * smooge (6) * decathorpe (3) * bcotton (2) * bookwar (0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2020-01-06)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-01-06 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 = F32 System-Wide Change: Ruby 2.7 https://pagure.io/fesco/issue/2308 APPROVED (+7, 0, -0) F33 System-Wide Change: Python 3.9 https://pagure.io/fesco/issue/2299 APPROVED (+5, 0, -0) Nonresponsive maintainer: Clément David (davidcl) https://pagure.io/fesco/issue/2306 APPROVED (+0, 0, -0) Acked by davidcl in the ticket. F32 System-Wide Change: Stop shipping individual component libraries in clang-libs package https://pagure.io/fesco/issue/2305 APPROVED (+4, 0, -0) F32 System-Wide Change: LLVM 10 https://pagure.io/fesco/issue/2304 APPROVED (+5, 0, -0) Nonresponsive maintainer: Moez Roy (moezroy) https://pagure.io/fesco/issue/2302 APPROVED (+5, 0, -0) Nonresponsive maintainer: Anuj More (anujmore) https://pagure.io/fesco/issue/2301 APPROVED (+4, 0, -0) Packages and account for automated testing of the packager workflow with gating https://pagure.io/fesco/issue/2300 APPROVED (+3, 0, -0) = New business = #topic #2303 F32 System-Wide Change: Drop Optical Media Release Criterion https://pagure.io/fesco/issue/2303 = 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-12-16)
= #fedora-meeting-1: FESCO (2019-12-16) = Meeting started by contyk at 15:00:06 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-12-16/fesco.2019-12-16-15.00.log.html Meeting summary --- * init process (contyk, 15:00:19) * Next week's chair (contyk, 15:03:13) * ACTION: contyk will chair the next meeting again (contyk, 15:03:22) * Open floor (contyk, 15:03:29) Meeting ended at 15:07:31 UTC. Action Items * contyk will chair the next meeting again Action Items, by person --- * contyk * contyk will chair the next meeting again People Present (lines said) --- * contyk (19) * zodbot (15) * decathorpe (4) * mhroncok (2) * zbyszek (2) * ignatenkobrain (1) * bookwar (1) * bcotton (1) * nirik (0) * dcantrell (0) * sgallagh (0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2019-12-16)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-12-16 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 = F32 Self-Contained Change: Rebase apt package from apt-rpm to Debian's apt https://pagure.io/fesco/issue/2292 APPROVED (+6, 0, -0) F32 System-Wide Change: Disallow Empty Password By Default https://pagure.io/fesco/issue/2291 REJECTED (+0, 0, -9) Note: We also agreed to instantly reject tickets once they get seven or more negative votes; this is anologous to the ticket acceptance criteria. F32 System-Wide Change: The GNU C Library version 2.31 https://pagure.io/fesco/issue/2289 APPROVED (+6, 0, -0) Nonresponsive maintainer: Cédric OLIVIER: cquad https://pagure.io/fesco/issue/2286 APPROVED (+5, 0, -0) Nonresponsive maintainer: Eric Smith (brouhaha) https://pagure.io/fesco/issue/2283 APPROVED (+3, 0, -0) = Followups = No floowups. = New business = No new business. Note: We'll hold the meeting for a couple of minutes in case there is anything for the open floor. = 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Modularity and all the things
Starting a new thread since the old one is hard to navigate at this point. Modularity is a distribution-level change and requires some mindset shift from packagers and users alike. I understand the concerns some people have, feeling it’s something new and half-baked that is being forced on them. We’re an open source community and in order to drive innovation, we need to be able to try new approaches and technologies in the open, not develop them without any input and hands-on experience behind closed doors, later serving them on a silver plate. The feedback we’re getting is extremely valuable, but some of it is too narrowly focused on one specific problem area and not taking into account the other aspects, requirements, or goals that we’re pursuing. Our objective is still to deliver multiple versions, or variants, of our content across releases or even distributions (think EPEL or CentOS). And it’s a good one. The concept of default streams was introduced to make modularity invisible to anyone who has no interest in alternatives and wants the system to operate as it historically has. Whether a specific package is delivered via a module or not shouldn’t matter. (This does not mean it should be hidden, just that it should have no practical difference to the system.) This applies to both buildroots and runtime, leaving the choice of whether to modularize or not to the maintainer. Obviously, the implementation is falling short in this regard right now, but we have solutions in development or under design. This includes making the default streams available in the non-modular buildroot via Ursa Prime or tracking the module enablement intent in our software management stack, as Stephen suggested in the original post. While these issues are being resolved, we are considering temporarily disallowing default streams in Fedora. I don’t want to abandon the idea completely, as doing so reduces the motivation to actually build modules and reap the benefits they might provide. Yes, modularity still has some additional development ahead. We need to improve the software management stack experience; we need to revisit our release engineering SOPs; we need to stabilize and boost performance of our infrastructure; and last but not least, we need to improve the packager experience, providing more features to make the creation of modules easier, as well as guidance, best practices and policies that make it easy to collaborate. These changes are similar to those for other useful but disruptive technologies that Fedora has successfully introduced in the past. I do believe we all intend the best, even if we sometimes disagree. We currently don’t have any other proposal that would fulfill the vision of our Objective and the needs of our users. The input here helps us re-focus on the most acute pain points but the manpower and control we have is also rather limited. If you want to and can help with the implementation, I’d like to encourage you to do so. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-09-23)
= #fedora-meeting-1: FESCO (2019-09-23) = Meeting started by contyk at 15:00:22 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-23/fesco.2019-09-23-15.00.log.html Meeting summary --- * init process (contyk, 15:00:29) * #2149 Proposal to change non-responsive maintainer policy (contyk, 15:02:54) * LINK: https://pagure.io/fesco/issue/2149 (contyk, 15:02:57) * #2003 Modules in buildroot enablement (contyk, 15:04:49) * LINK: https://pagure.io/fesco/issue/2003 (contyk, 15:04:51) * Let's reuse #2003 to discuss this potential dependency; the modularity team will focus tomorrow's meeting on the topic, too (contyk, 15:25:48) * #2227 Nonresponsive maintainer: Henrik Nordström hno (contyk, 15:26:16) * LINK: https://pagure.io/fesco/issue/2227 (contyk, 15:26:18) * AGREED: Orphan bzr next week unless the maintainer does it before then (+8, 0, -0) (contyk, 15:32:28) * #2225 F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions (contyk, 15:33:21) * LINK: https://pagure.io/fesco/issue/2225 (contyk, 15:33:23) * AGREED: F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions is approved (+8, 1, -0) (contyk, 15:37:33) * #2230 FESCo blocker bug: Broken upgrades via libgit2 (contyk, 15:37:47) * LINK: https://pagure.io/fesco/issue/2230 (contyk, 15:37:49) * AGREED: The upgrade issue identified here is significant enough for FESCo to declare it a blocker. FESCo will vote to determine if a proposed solution or workaround is sufficient to unblock the release. At minimum, we require that a non-expert user is provided sufficient information to accomplish the upgrade without resorting to Google (+7, 0, -0) (contyk, 16:08:01) * Next week's chair (contyk, 16:08:25) * ACTION: sgallagh will chair the next meeting (contyk, 16:10:32) * Open floor (contyk, 16:10:35) Meeting ended at 16:12:08 UTC. Action Items * sgallagh will chair the next meeting Action Items, by person --- * sgallagh * sgallagh will chair the next meeting People Present (lines said) --- * mhroncok (78) * contyk (77) * sgallagh (62) * bookwar (24) * nirik (23) * zodbot (15) * jforbes (10) * otaylor (9) * bcotton (5) * zbyszek (4) * adamw (1) * ignatenkobrain (0) signature.asc Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2019-09-23)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-09-23 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 = request to sponsor my bot account "rhcontainerbot" into the packager group https://pagure.io/fesco/issue/2228 APPROVED (+4, 1, -0) = Followups = #topic #2149 Proposal to change non-responsive maintainer policy https://pagure.io/fesco/issue/2149 #topic #2003 Modules in buildroot enablement https://pagure.io/fesco/issue/2003 = New business = #topic #2227 Nonresponsive maintainer: Henrik Nordström hno https://pagure.io/fesco/issue/2227 #topic #2225 F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions https://pagure.io/fesco/issue/2225 #topic #2230 FESCo blocker bug: Broken upgrades via libgit2 https://pagure.io/fesco/issue/2230 = 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. signature.asc Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-09-16)
= #fedora-meeting-1: FESCO (2019-09-16) = Meeting started by contyk at 15:00:22 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-16/fesco.2019-09-16-15.00.log.html Meeting summary --- * init process (contyk, 15:00:28) * #2223 gdesklets : exception to continue using python2 (contyk, 15:03:32) * AGREED: The request is rejected (+0, 0, -8) (contyk, 15:07:04) * Next week's chair (contyk, 15:07:30) * ACTION: contyk will chair next meeting (contyk, 15:08:56) * Open Floor (contyk, 15:09:06) Meeting ended at 15:17:30 UTC. Action Items * contyk will chair next meeting Action Items, by person --- * contyk * contyk will chair next meeting People Present (lines said) --- * contyk (30) * zodbot (18) * sgallagh (15) * mhroncok (11) * nirik (10) * zbyszek (7) * jforbes (5) * bookwar (4) * bcotton (3) * otaylor (2) * ignatenkobrain (0) signature.asc Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2019-09-16)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-09-16 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 = Nonresponsive Maintainer: Chitlesh Goorah chitlesh https://pagure.io/fesco/issue/2220 APPROVED (+3, 0, -0) python2-mlt : exception to continue using python2 https://pagure.io/fesco/issue/2219 APPROVED (+3, 0, -0) postgresql: exception to use python2 as a runtime dependency https://pagure.io/fesco/issue/2217 APPROVED (+1, 0, -0) texlive-base: exception to use python2 in runtime https://pagure.io/fesco/issue/2215 APPROVED (+2, 0, -0) F31 System-Wide Change: Set skip_if_unavailable default to false https://pagure.io/fesco/issue/2125 REJECTED (+3, 0, -0) = New business = #2223 gdesklets : exception to continue using python2 https://pagure.io/fesco/issue/2223 = 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. signature.asc Description: 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-06-28)
=== #fedora-meeting: FESCO (2019-06-28) === Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-06-28/fesco.2019-06-28-15.00.log.html Meeting summary --- * init process (contyk, 15:00:07) * #2152 "backport" branches in src.fp.o for backports to coreos stable streams (contyk, 15:02:22) * LINK: https://pagure.io/fesco/issue/2152 (contyk, 15:02:26) * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1266753 This was a build for a test day kernel (jforbes, 15:34:25) * AGREED: Let's use tags. The exact workflow is up to the CoreOS team. (+8, 0, -0) (contyk, 15:47:52) * #2145 python2 packaging exception for python2-soupsieve, python2-css-parser (contyk, 15:48:14) * LINK: https://pagure.io/fesco/issue/2145 (contyk, 15:48:18) * AGREED: python2 packaging exception for python2-soupsieve, python2-css-parser is approved (+7, 1, -0) (contyk, 15:50:22) * Next week's chair (contyk, 15:50:55) * The next FESCo meeting will be held on July 12 (contyk, 15:52:59) * ACTION: ignatenkobrain will chair the next meeting, on July 12 (contyk, 15:56:33) * Open Floor (contyk, 15:56:45) * #2149: Proposal to change non-responsive maintainer policy (contyk, 16:04:52) * Will be discussed in two weeks (contyk, 16:07:10) Meeting ended at 16:08:17 UTC. Action Items * ignatenkobrain will chair the next meeting, on July 12 Action Items, by person --- * ignatenkobrain * ignatenkobrain will chair the next meeting, on July 12 People Present (lines said) --- * contyk (101) * mhroncok (80) * dustymabe (66) * zbyszek (49) * jforbes (36) * nirik (35) * sgallagh (26) * zodbot (21) * ignatenkobrain (18) * bookwar (13) * bcotton (3) * jcline (1) * otaylor (0) signature.asc 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2019-06-28)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-06-28 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 = Nonresponsive maintainer: bioinfornatics https://pagure.io/fesco/issue/2147 APPROVED (+4, 0, -0) Non-responsive maintainer: mflobo https://pagure.io/fesco/issue/2142 APPROVED (+5, 0, -0) = Followups = #topic #2152 "backport" branches in src.fp.o for backports to coreos stable streams .fesco 2152 https://pagure.io/fesco/issue/2152 = New business = #topic #2145 python2 packaging exception for python2-soupsieve, python2-css-parser .fesco 2145 https://pagure.io/fesco/issue/2145 = 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. signature.asc 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedocal] Reminder meeting : Modularity Team (weekly)
#fedora-meeting-3: Weekly Meeting of the Modularity Team Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-3/2019-06-25/modularity.2019-06-25-15.00.log.html Meeting summary --- * Roll Call (contyk, 15:00:04) * Redefine default for branch ref: (contyk, 15:03:02) * We would propose solving the use case with special modulemd variables; we will discuss this more in the ticket (contyk, 15:16:23) * What is the process to change default profile name with zero down time? (contyk, 15:16:49) * AGREED: Profiles cannot be removed during the lifetime of the stream in order to avoid breaking scripts. Options may exist for exceptional cases on an individual basis. (contyk, 15:41:06) * Next week's chair (contyk, 15:41:19) * ACTION: langdon will chair next week (contyk, 15:43:13) * Open floor (contyk, 15:43:19) Meeting ended at 15:55:50 UTC. Action Items * langdon will chair next week Action Items, by person --- * langdon * langdon will chair next week People Present (lines said) --- * contyk (81) * sgallagh (51) * langdon (34) * zodbot (14) * ignatenkobrain (8) * x3mboy (8) signature.asc 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-06-14)
=== #fedora-meeting: FESCO (2019-06-14) === Meeting started by contyk at 15:00:04 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-06-14/fesco.2019-06-14-15.00.log.html Meeting summary --- * init process (contyk, 15:00:10) * #2136 F32 Self-Contained Change: Track Changes in Taiga (contyk, 15:04:48) * LINK: https://pagure.io/fesco/issue/2136 (contyk, 15:04:51) * AGREED: The Taiga switch is approved without any specific release restrictions. We can revisit in the future if there is a need for it. (contyk, 15:13:21) * #2144 F31 System-Wide Change: Switch RPMs to zstd compression (contyk, 15:13:36) * LINK: https://pagure.io/fesco/issue/2144 (contyk, 15:13:39) * LINK: https://pagure.io/releng/issue/8395 (ignatenkobrain, 15:33:22) * LINK: https://pagure.io/releng/issue/8395 (bowlofeggs, 15:33:45) * AGREED: F31 System-Wide Change: Switch RPMs to zstd compression is approved. (+5, 0, -0) (contyk, 15:43:34) * Next week's chair (contyk, 15:43:54) * ACTION: jforbes will chair the next meeting (contyk, 15:44:41) * Open Floor (contyk, 15:44:49) Meeting ended at 15:50:04 UTC. Action Items * jforbes will chair the next meeting Action Items, by person --- * jforbes * jforbes will chair the next meeting People Present (lines said) --- * contyk (64) * bowlofeggs (61) * sgallagh (38) * zbyszek (25) * zodbot (21) * jforbes (21) * bcotton (12) * ignatenkobrain (11) * dmach (9) * mboddu (4) * kwizart (2) * nirik (0) * mhroncok (0) * bookwar (0) * otaylor (0) signature.asc 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
Schedule for Friday's FESCo Meeting (2019-06-14)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-06-14 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 = F31 System-Wide Change: Node.js 12.x by default https://pagure.io/fesco/issue/2143 ACCEPTED (+6, 0, -0) Unresponsive maintainer of python-reportlab (wish to take over the package) https://pagure.io/fesco/issue/2132 ACCEPTED (+3, 0, -0) = Followups = #topic #2136 F32 Self-Contained Change: Track Changes in Taiga .fesco 2136 https://pagure.io/fesco/issue/2136 = New business = #topic #2144 F31 System-Wide Change: Switch RPMs to zstd compression .fesco 2144 https://pagure.io/fesco/issue/2144 = 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. signature.asc 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
Summary/Minutes from today's FESCo Meeting (2019-05-17)
=== #fedora-meeting: FESCO (2019-05-17) === Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-05-17/fesco.2019-05-17-15.00.log.html Meeting summary --- * init process (contyk, 15:00:06) * #2128 Policy needed: Modules built against EOL Fedora releases (contyk, 15:03:45) * LINK: https://pagure.io/fesco/issue/2128 (contyk, 15:03:49) * AGREED: Policy for modules in Fedora and EPEL is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora, EPEL or Rawhide (+9, 0, -0) (contyk, 15:34:08) * #2127 Election Interview Questions — FESCo (Jun 2019) (contyk, 15:34:44) * LINK: https://pagure.io/fesco/issue/2127 (contyk, 15:34:48) * AGREED: The same set of questions will be used again (+5, 0, -0) (contyk, 15:37:19) * Next week's chair (contyk, 15:37:38) * ACTION: sgallagh will chair next meeting (contyk, 15:40:00) * Open Floor (contyk, 15:40:08) Meeting ended at 15:55:36 UTC. Action Items * sgallagh will chair next meeting Action Items, by person --- * sgallagh * sgallagh will chair next meeting People Present (lines said) --- * contyk (103) * sgallagh (58) * bowlofeggs (43) * mhroncok (39) * nirik (25) * zbyszek (18) * zodbot (17) * bookwar (8) * jforbes (7) * ignatenkobrain (4) * bcotton (2) * otaylor (0) signature.asc 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
Schedule for Friday's FESCo Meeting (2019-05-17)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-05-17 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #2128 Policy needed: Modules built against EOL Fedora releases .fesco 2128 https://pagure.io/fesco/issue/2128 = New business = #topic #2127 Election Interview Questions — FESCo (Jun 2019) .fesco 2127 https://pagure.io/fesco/issue/2127 = 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. signature.asc 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: Should I always create a dedicated stream branch for my module?
On Fri, May 10, 2019 at 08:27:07AM +0200, Igor Gnatenko wrote: > It is up to you. If the plan is always to have master in sync with your > module stream, then you can keep master. If you want to retire sway from > rawhide at some point, you would need to move to the stream branch. This. Though I'd recommend separate branches for the components so that you get a fine control over what goes into your module. P > > On Fri, May 10, 2019 at 8:25 AM Till Hofmann > wrote: > > > Hi all, > > > > I'm currently working on a module for sway. We basically just want to > > have a stream that always contains the latest version of sway (including > > all its dependencies), the same version that is also in rawhide (this > > stream should be named 'rolling' if I understand the guidelines > > correctly). In that case, is it better to just use the master branch of > > the package git, or should I create a dedicated stream branch nevertheless? > > > > Thanks, > > Till > > ___ > > 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 signature.asc 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
Summary/Minutes from today's FESCo Meeting (2019-03-11)
= #fedora-meeting-1: FESCO (2019-03-11) = Meeting started by contyk at 15:00:01 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-11/fesco.2019-03-11-15.00.log.html Meeting summary --- * init process (contyk, 15:00:08) * #2101 Fedora 30 incomplete changes (contyk, 15:02:51) * LINK: https://pagure.io/fesco/issue/2101 (contyk, 15:02:56) * Firefox Wayland by default on GNOME -- FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. If it does not land in F30 Beta, this Change is Deferred to F31. (contyk, 15:18:02) * LINK: https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles (zbyszek, 15:21:42) * Make BootLoaderSpec-style configuration files the default should be ready now (contyk, 15:26:01) * Haskell GHC 8.4 and Stackage LTS 12 -- if the maintainer wants this change to land in F30, they need to push it as an update bundle, otherwise defer to F31 (contyk, 15:34:05) * MongoDB removal -- the Change is implemented, but some dependencies on removed packages remain. Those should be treated as bugs and resolved in the usual fashion. (contyk, 15:39:39) * LINK: https://pagure.io/pungi-fedora/pull-request/636 was the releng change that blocked it going in for F29 (otaylor, 15:40:47) * LINK: https://src.fedoraproject.org/rpms/glibc32/commits/master (mhroncok, 15:42:35) * glibc32 build adjustments -- not ready; there was no reply since we moved this to f30. needinfo the change owner to ack it as f31 change. if there is no reply until we evaluate this for f31, we cancel the change (contyk, 15:46:44) * Build non-RELRO ELF binaries with .got.plt isolation -- also not ready; there was no reply since we moved this to f30. needinfo the change owner to ack it as f31 change. if there is no reply until we evaluate this for f31, we cancel the change (contyk, 15:48:39) * Reset locale if not available -- code ready but there's no build yet; we'll follow the standard fe/blocker process; if it doesn't land by beta, it will be deferred to f31 (contyk, 15:53:35) * #2096 F31 System-Wide Change: BuildRequires generators (contyk, 15:55:18) * LINK: https://pagure.io/fesco/issue/2096 (contyk, 15:55:22) * We'll continue the discussion in the ticket for another week. (contyk, 15:59:41) * #2092 Fedora 31 schedule (contyk, 16:01:13) * LINK: https://pagure.io/fesco/issue/2092 (contyk, 16:01:18) * AGREED: Fedora 31 schedule is APPROVED (+7, 0, -0) (contyk, 16:19:36) * #2027 RFC: Module lifecycles (contyk, 16:19:49) * LINK: https://pagure.io/fesco/issue/2027 (contyk, 16:19:54) * LINK: https://pagure.io/modularity/working-documents/c/dcd4d53df39b2500e19ad67b323fd90972046d94 (zbyszek, 16:22:19) * FESCo will review the new proposal within the following week (contyk, 16:24:28) * Next week's chair (contyk, 16:24:49) * ACTION: jforbes will chair next meeting (contyk, 16:25:52) * Open Floor (contyk, 16:25:57) Meeting ended at 16:32:44 UTC. Action Items * jforbes will chair next meeting Action Items, by person --- * jforbes * jforbes will chair next meeting People Present (lines said) --- * contyk (117) * mhroncok (89) * sgallagh (61) * zbyszek (52) * nirik (49) * bowlofeggs (36) * zodbot (27) * bcotton (23) * bookwar (23) * jforbes (22) * otaylor (14) * stransky_ (12) * asamalik (7) * kalev (6) * ignatenkobrain (5) * adamw (4) signature.asc 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: Schedule for Monday's FESCo Meeting (2019-03-11)
On Mon, Mar 11, 2019 at 09:56:35AM +0100, Petr Šabata wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2019-03-11 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 = > F31 System-Wide Change: Move Gold Into A SubpackageOf Binutils > https://pagure.io/fesco/issue/2097 > ACCEPTED (+5, 0, -0) > > F31 System-Wide Change: Automatic strict inter-package dependencies > https://pagure.io/fesco/issue/2095 > ACCEPTED (+4, 0, -0) > > F31 System-Wide Change: Python 3.8 > https://pagure.io/fesco/issue/2093 > ACCEPTED (+8, 0, -0) > > require a re-review to unretire packages after 8 weeks instead of 2 weeks > https://pagure.io/fesco/issue/2089 > ACCEPTED (+5, 0, -0) > > = Followups = > > #topic #2096 F31 System-Wide Change: BuildRequires generators > .fesco 2096 > https://pagure.io/fesco/issue/2096 > > #topic #2092 Fedora 31 schedule > .fesco 2092 > https://pagure.io/fesco/issue/2092 + #topic #2027 RFC: Module lifecycles .fesco 2027 https://pagure.io/fesco/issue/2027 > > = New business = > > #topic #2101 Fedora 30 incomplete changes > .fesco 2101 > https://pagure.io/fesco/issue/2101 > > = 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 signature.asc 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: Schedule for Monday's FESCo Meeting (2019-03-11)
On Mon, Mar 11, 2019 at 09:56:35AM +0100, Petr Šabata wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2019-03-11 15:00 UTC' Note the meeting is scheduled in UTC, so if you just switched to DST, the meeting time changed for you. P signature.asc 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
Schedule for Monday's FESCo Meeting (2019-03-11)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-03-11 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 = F31 System-Wide Change: Move Gold Into A SubpackageOf Binutils https://pagure.io/fesco/issue/2097 ACCEPTED (+5, 0, -0) F31 System-Wide Change: Automatic strict inter-package dependencies https://pagure.io/fesco/issue/2095 ACCEPTED (+4, 0, -0) F31 System-Wide Change: Python 3.8 https://pagure.io/fesco/issue/2093 ACCEPTED (+8, 0, -0) require a re-review to unretire packages after 8 weeks instead of 2 weeks https://pagure.io/fesco/issue/2089 ACCEPTED (+5, 0, -0) = Followups = #topic #2096 F31 System-Wide Change: BuildRequires generators .fesco 2096 https://pagure.io/fesco/issue/2096 #topic #2092 Fedora 31 schedule .fesco 2092 https://pagure.io/fesco/issue/2092 = New business = #topic #2101 Fedora 30 incomplete changes .fesco 2101 https://pagure.io/fesco/issue/2101 = 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. signature.asc 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: modular repositories in mock configs: please don't
On Mon, Mar 04, 2019 at 11:11:48AM +0100, Pavel Raiskup wrote: > On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote: > > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote: > > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote: > > > > Replying in general. > > > > > > > > While it's never been entirely the same, I'd also like our mock configs > > > > to be as close to koji environment as possible. In the current > > > > situation that would mean no modules being available. > > > > > > I don't understand your point of view. If it is safe to enable modular > > > repositories on user boxes by default (that's what we have now), why we > > > can not enable them in koji and why we can not enable them in mock? > > > > We're currently discussing how to enable them in koji. It's just not > > the case at the moment. Also the module set available and enabled in > > koji might differ from the repo we ship. > > So the thing is to fix koji, not to fix mock - but you suggested to remove > modular repos from mock config, iirc so why? So if there's actually a > reason to do so, shouldn't we removed it from > /etc/yum.repos.d/fedora-modular.repo as well? I suggested to drop the modular repo from the mock config to get an environment similar to what we have in koji. The koji change might take a while, and, as noted, the module set available in koji might ultimately differ from the one in distribution repos. > > > > Once/if we proceed with one of the modules-in-the-non-modular-buildroot > > > > proposals, I would like them to include the same module set that is > > > > available in the non-modular buildroot in koji. > > > > > > Can you elaborate? How the 'non-modular buildroot in koji' differs from > > > modules-in-the-non-modular-buildroot? > > > > https://pagure.io/fesco/issue/2003 > > > > The standard buildroot doesn't currently include any modular > > content. There are ways to put it in but we haven't decided how > > to do it yet. > > > > Non-modular buildroot is the base buildroot that non-modular > > packages use to build. It may or may not include modules. It > > currently doesn't but we would like to change that. > > > > Once it does, I would like the mock config to include modules that > > the koji buildroot includes. Currently it doesn't include any so > > I'd rather not include any. > > Ah, so we consider "modular" content to be a standard, and non-modular to > be non-standard. I understood it vice versa before TBH. No. Where am I saying that? > > > > If you're building content that depends on modular packages at this > > > > point, you should be building a module anyway. > > > > > > Please elaborate on "why" on this, too. > > > > Since the buildroot normally doesn't include modules (see above) > > and there might be multiple incompatible streams anyway, you > > should build your content as a module and define proper > > module-level dependencies on the content you need -- either to > > build, to run, or both. > > You should be able to pick what you build/run/both against, and there > should be some default (== no stream enabled by default seems to be the > sanest default to me). And you do that by wrapping your content in a module and declaring your deps. We still want to enable streams by default as we believe it contributes to better user experience -- users don't have to look for packages in modules and enable them manually. Still, if you depend on modular content, you should say so. They only have to care if they want to consume alternative content. > > I don't think this is all that different from normal package > > builds where you simply declare your RPM-level deps rather than > > hope that something is magically pulled into the buildroot or > > already installed on the system. > > Well, this comes from my misunderstanding how the modularity is used > probably... E.g. there are attempts to move e.g. java stack to modular > content - only because the MBS allows building against all fedora release > by one command (== to avoid fedora branching "burden"). Even though this > use-case is probably a misuse - to explain why I'm asking - I'd still > expect that the java modular content is somehow available in buildroots > by default configured in mock. We would like that to be the case but for that we need to resolve the FESCo ticket I linked earlier. If Java goes mo
Re: modular repositories in mock configs: please don't
On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote: > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote: > > Replying in general. > > > > While it's never been entirely the same, I'd also like our mock configs > > to be as close to koji environment as possible. In the current > > situation that would mean no modules being available. > > I don't understand your point of view. If it is safe to enable modular > repositories on user boxes by default (that's what we have now), why we > can not enable them in koji and why we can not enable them in mock? We're currently discussing how to enable them in koji. It's just not the case at the moment. Also the module set available and enabled in koji might differ from the repo we ship. When I build in mock, I typically do it to test my changes before sending a build to koji; I would therefore like the environment to be nearly identical. But I'd like to learn about other use cases, too. > > Once/if we proceed with one of the modules-in-the-non-modular-buildroot > > proposals, I would like them to include the same module set that is > > available in the non-modular buildroot in koji. > > Can you elaborate? How the 'non-modular buildroot in koji' differs from > modules-in-the-non-modular-buildroot? https://pagure.io/fesco/issue/2003 The standard buildroot doesn't currently include any modular content. There are ways to put it in but we haven't decided how to do it yet. Non-modular buildroot is the base buildroot that non-modular packages use to build. It may or may not include modules. It currently doesn't but we would like to change that. Once it does, I would like the mock config to include modules that the koji buildroot includes. Currently it doesn't include any so I'd rather not include any. > > If you're building content that depends on modular packages at this > > point, you should be building a module anyway. > > Please elaborate on "why" on this, too. Since the buildroot normally doesn't include modules (see above) and there might be multiple incompatible streams anyway, you should build your content as a module and define proper module-level dependencies on the content you need -- either to build, to run, or both. I don't think this is all that different from normal package builds where you simply declare your RPM-level deps rather than hope that something is magically pulled into the buildroot or already installed on the system. > > In that case your local MBS manages the build and pulls the relevant > > packages for you. > > Ok, but consider that > > $ mock -r fedora-rawhide-x86_64 \ > --config-opts module_enable=postgresql:10 > --rebuild my.srpm > > is much more convenient and economical than approaching the whole MBS > "thingy". This is actually pretty cool. P signature.asc 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: modular repositories in mock configs: please don't
On Fri, Mar 01, 2019 at 08:25:32AM -0600, Richard Shaw wrote: > Not replying to anyone in particular but just a nit for me... > > I've been a Fedora packager for probably 10 years now (need to check!) but > I *STILL* don't really understand modules other than at a high level (it > lets you use dependencies that aren't available in the main repos). I've > read through some of the documentation but it's still not clear. I know I > would have to crate some kind of module file which I think tools could be > developed to mostly automate (spec->module template converter?). You can view them as virtual repositories with dependencies. I think that might be the simplest way to put it. You can try playing with fedmod to generate your modulemd file or you can just write it from scratch; it's not all that complicated. P signature.asc 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: modular repositories in mock configs: please don't
Replying in general. While it's never been entirely the same, I'd also like our mock configs to be as close to koji environment as possible. In the current situation that would mean no modules being available. Once/if we proceed with one of the modules-in-the-non-modular-buildroot proposals, I would like them to include the same module set that is available in the non-modular buildroot in koji. If you're building content that depends on modular packages at this point, you should be building a module anyway. In that case your local MBS manages the build and pulls the relevant packages for you. But I also kinda like the idea of having two configs -- one that aims to somewhat replicate the koji experience and one that's close to installations. Not sure if there's really any value in it, though. P signature.asc 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: Is dnf update --releasever=30 supposed to work with modules?
On Mon, Mar 04, 2019 at 08:56:26AM +0100, Miroslav Suchý wrote: > Dne 04. 03. 19 v 7:30 Richard W.M. Jones napsal(a): > > Bonus question: Are "Problem 1" (etc) in each section of the error > > message supposed to relate to each other in some way? Or is the > > second list a new list of problems? > > > You mean this error: > - nothing provides module(platform:f30) needed by module > stratis:1:20181215204600:a5b0195c-0.x86_64 > - nothing provides module(platform:f30) needed by module > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > ... > > The dependency > module(platform:f30) > is virtual. There is no package which provides this. The dependency is put > into an RPM transaction sack by DNF based on > PLATFORM_ID from *current* /etc/os-release Indeed. I'm not sure whether we can reasonably support this upgrade method, although suggestions welcome :| The failure in this case isn't caused by modules, however; the messages are informational. P signature.asc 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: Broken modules on rawhide
On Tue, Feb 26, 2019 at 03:23:19PM +0100, Miro Hrončok wrote: > On 26. 02. 19 15:07, Petr Šabata wrote: > > On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote: > > > From: > > >https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > > > > > When you try to run: > > >mock -r fedora-rawhide-x86_64 shell > > > > > > You will get: > > > Problem 1: conflicting requests > > >- nothing provides module(platform:f30) needed by module > > > stratis:1:20181215204600:a5b0195c-0.x86_64 > > > Problem 2: conflicting requests > > >- nothing provides module(platform:f30) needed by module > > > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > > > > > > > rawhide has module_id=platform:f31. > > > > I think this shouldn't have been updated until after the branch > > point. > > > > > When will be all rawhide modules rebuild? Or what is the solution for > > > this? Because right now all rawhide modules are > > > basically broken. And because Mock started using modular fedora repos, > > > then all Mock attempts for rawhides builds are > > > broken too. > > > > At branch point, modules that can run on any platform, or are > > compatible with platform:f31, will simply be tagged. Modules that > > could run of f31 if rebuilt will be rebuilt. > > > > I think this is an unfortunate timing issue and needs to be > > coordinated better in the future. The branch point happens later > > this week; perhaps we could revert the change for the time being? > > I don't know what do you exactly mean by "branch point" but "Branch Fedora > 30 from Rawhide" already happened a week ago. Uh, you're correct. I need to refresh my calendar skills. In that case discard what I wrote before; I'll follow up with rel-eng today. P signature.asc 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: Broken modules on rawhide
On Tue, Feb 26, 2019 at 02:41:56PM +0100, Fabio Valentini wrote: > On Tue, Feb 26, 2019, 14:24 Miroslav Suchý wrote: > > > From: > > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > > > When you try to run: > > mock -r fedora-rawhide-x86_64 shell > > > > You will get: > > Problem 1: conflicting requests > > - nothing provides module(platform:f30) needed by module > > stratis:1:20181215204600:a5b0195c-0.x86_64 > > Problem 2: conflicting requests > > - nothing provides module(platform:f30) needed by module > > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > > > > rawhide has module_id=platform:f31. > > > > When will be all rawhide modules rebuild? Or what is the solution for > > this? Because right now all rawhide modules are > > basically broken. And because Mock started using modular fedora repos, > > then all Mock attempts for rawhides builds are > > broken too. > > > > Related: It would be nice if module repositories in mock (and COPR) were an > optional thing (right now, probably default=off, until that stuff is > fixed), like bootstrap chroot and network access. > > I know, "just add another option" ... still, I'll manually disable all > modular repos in mock configs on my local system, but that's not an option > for COPR. I always wonder why people disable the repo -- it's part of Fedora. What's your motivation? P signature.asc 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: Broken modules on rawhide
On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote: > From: > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > When you try to run: > mock -r fedora-rawhide-x86_64 shell > > You will get: > Problem 1: conflicting requests > - nothing provides module(platform:f30) needed by module > stratis:1:20181215204600:a5b0195c-0.x86_64 > Problem 2: conflicting requests > - nothing provides module(platform:f30) needed by module > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > rawhide has module_id=platform:f31. I think this shouldn't have been updated until after the branch point. > When will be all rawhide modules rebuild? Or what is the solution for this? > Because right now all rawhide modules are > basically broken. And because Mock started using modular fedora repos, then > all Mock attempts for rawhides builds are > broken too. At branch point, modules that can run on any platform, or are compatible with platform:f31, will simply be tagged. Modules that could run of f31 if rebuilt will be rebuilt. I think this is an unfortunate timing issue and needs to be coordinated better in the future. The branch point happens later this week; perhaps we could revert the change for the time being? P signature.asc 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
Summary/Minutes from today's FESCo Meeting (2019-02-18)
= #fedora-meeting-1: FESCO (2019-02-18) = Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-18/fesco.2019-02-18-15.00.log.html Meeting summary --- * init process (contyk, 15:00:07) * #1974 Problematic blocker for F29: dnf 'offline' module tracking (contyk, 15:02:32) * LINK: https://pagure.io/fesco/issue/1974 (contyk, 15:02:36) * AGREED: As we're fairly sure this wouldn't be fixed in time for F30, we're moving this to F31. Modularity & DNF folks with prepare a specific implementation plan and will update the ticket (+6, 0, -1) (contyk, 15:20:34) * #2003 Ursa Major (modules in buildroot) enablement (contyk, 15:20:56) * LINK: https://pagure.io/fesco/issue/2003 (contyk, 15:21:00) * AGREED: contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -0) (contyk, 15:48:53) * LINK: https://pagure.io/fesco/issue/2078 (contyk, 15:49:12) * AGREED: F30 Change: MongoDB removal is approved. (+6, 0, -0) (contyk, 15:59:17) * #2046 Change process: Releng impact tickets are tedious and possibly contribute to (contyk, 15:59:27) * LINK: https://pagure.io/fesco/issue/2046 (contyk, 15:59:34) * AGREED: System wide changes remain the same for now. For self contained changes if the proposal owner(s) think releng involvement is needed, they open a ticket, but it is not mandatory, Anyone who feels releng should be notified of and discuss the change can file a releng ticket anytime. (+8, 0, -0) (contyk, 16:04:36) * #2067 tss2 package ownership (contyk, 16:04:49) * LINK: https://pagure.io/fesco/issue/2067 (contyk, 16:04:54) * LINK: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers?rd=PackageMaintainers/Policy/NonResponsiveMaintainers#Notes_for_invalid_email_addresses (nirik, 16:06:51) * AGREED: Agreed to add snits as a comaintainer for tss2 (+7, 0, -0) (contyk, 16:15:49) * #2071 F30 Change: Firefox Wayland By Default On Gnome (contyk, 16:16:03) * LINK: https://pagure.io/fesco/issue/2071 (contyk, 16:16:08) * AGREED: F30 Change: Firefox Wayland By Default On Gnome is approved but might get reverted if the glitches are not fixed in time for F30 final (+8, 0, -0) (contyk, 16:26:53) * #2072 Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935) (contyk, 16:27:30) * LINK: https://pagure.io/fesco/issue/2072 (contyk, 16:27:34) * LINK: https://meetbot-raw.fedoraproject.org/teams/releng/releng.2019-02-14-17.00.log.html (nirik, 16:29:06) * LINK: https://pagure.io/fesco/issue/2090 (tyll, 16:30:25) * LINK: https://pagure.io/fesco/issue/2090 (mboddu, 16:30:30) * huzaifas and releng will discuss the solution in #2090; FESCo will revisit next week (contyk, 16:43:49) * #2077 F30 Change: SWID tag enablement (contyk, 16:44:08) * LINK: https://pagure.io/fesco/issue/2077 (contyk, 16:44:13) * AGREED: F30 Change: SWID tag enablement approved (+9, 0, -0) (contyk, 16:47:21) * #2088 Late F30 Change – “dnf --best” as default behavior (contyk, 16:47:37) * LINK: https://pagure.io/fesco/issue/2088 (contyk, 16:47:41) * LINK: https://pagure.io/fesco/issue/2088#comment-553962 (otaylor, 16:49:49) * There are too many things to consider. We will discuss this in the ticket for another week. (contyk, 17:02:34) * #2084 "Fedora packaging service" kickoff (contyk, 17:03:35) * LINK: https://pagure.io/fesco/issue/2084 (contyk, 17:03:40) * ttomecek will share this on devel@, FESCo will continue discussing in the ticket and will revisit in a week (contyk, 17:06:09) * Next week's chair (contyk, 17:06:22) * ACTION: zbyszek will chair next meeting (contyk, 17:06:57) * Open Floor (contyk, 17:07:01) Meeting ended at 17:08:18 UTC. Action Items * zbyszek will chair next meeting Action Items, by person --- * zbyszek * zbyszek will chair next meeting People Present (lines said) --- * contyk (165) * bowlofeggs (123) * nirik (97) * zbyszek (56) * otaylor (31) * zodbot (30) * tyll (27) * ignatenkobrain (21) * jforbes (17) * mboddu (13) * bcotton (6) * ttomecek (6) * jmracek (4) * tibbs (2) * tyll_ (1) * mhroncok (0) * sgallagh (0) signature.asc 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
Schedule for Monday's FESCo Meeting (2019-02-18)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-02-18 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 = F30 Change: Vagrant 2.2 https://pagure.io/fesco/issue/2085 APPROVED (+5, 0, -0) F30 Change: Improved Grub Menu https://pagure.io/fesco/issue/2079 APPROVED (+5, 0, -0) F30 Change: LXQt 0.14.0 https://pagure.io/fesco/issue/2076 APPROVED (+6, 0, -0) F30 Change: GHC 8.4 https://pagure.io/fesco/issue/2075 APPROVED (+5, 0, -0) F30 Change: Fish 3.0 https://pagure.io/fesco/issue/2073 APPROVED (+6, 0, -0) = Followups = #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking .fesco 1974 https://pagure.io/fesco/issue/1974 #topic #2003 Ursa Major (modules in buildroot) enablement .fesco 2003 https://pagure.io/fesco/issue/2003 #opitc #2078 F30 Change: MongoDB removal .fesco 2078 https://pagure.io/fesco/issue/2078 = New business = #topic #2046 Change process: Releng impact tickets are tedious and possibly contribute to overwhelm releng .fesco 2046 https://pagure.io/fesco/issue/2046 #topic #2067 tss2 package ownership .fesco 2067 https://pagure.io/fesco/issue/2067 #topic #2071 F30 Change: Firefox Wayland By Default On Gnome .fesco 2071 https://pagure.io/fesco/issue/2071 #topic #2072 Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935) .fesco 2072 https://pagure.io/fesco/issue/2072 #topic #2077 F30 Change: SWID tag enablement .fesco 2077 https://pagure.io/fesco/issue/2077 #topic #2088 Late F30 Change – “dnf --best” as default behavior .fesco 2088 https://pagure.io/fesco/issue/2088 #topic #2084 "Fedora packaging service" kickoff .fesco 2084 https://pagure.io/fesco/issue/2084 = 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. signature.asc 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: Ownership of rogue
On Mon, Feb 11, 2019 at 08:08:38PM -0600, Wart wrote: > As per > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package > > ...I will be taking ownership of the rogue package. I was actually the > maintainer for this package many years ago, and would hate to see it > dropped. As a former maintainer, thank you :) P signature.asc 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: Modularity implementation with rpm DistTag
On Wed, Dec 19, 2018 at 09:54:07AM +0100, Michal Novotny wrote:
> Hello Fedora devels!
>
> TL;DR: let's use rpm DistTag (DistTag, not the %dist macro) to denote
> stream names
>
> As we all know, modularity was created to provide
> parallel-availability, that is providing the same package in its
> different major versions from the same rpm repository.
>
> The first question to ask is: "Why can't we just place two major
> versions of a package alongside in the repo?"
>
> That's possible but there are two problems with this. The first one is
> that when you type
>
> $ sudo dnf install git
>
> dnf needs to determine what major version of git it should install.
> User should be able to provide the information explicitly on
> command-line, that is:
>
> $ sudo dnf install git-1
>
> or
>
> $ sudo dnf install git-2
>
> but doing that always for each package you install could be quite demanding.
>
> The second problem is that once you have a git package of a certain
> major version installed, you want to keep it on that version when
> running an ordinary update command:
>
> $ sudo dnf update git
>
> dnf shouldn't be tempted to install git-2 (e.g. git-2.17.2-2) but it
> should instead update git-1 on the system to the latest available
> minor version if git-1 is the major version of git currently
> installed.
>
> Modularity solves the second problem by "streams" and the first
> problem by a "default stream".
>
> That's okay but I would argue there is much more simple solution to
> those two problems, which reuses already known terminology and
> technology.
>
> What can be done is to put the information into which stream a package
> belongs into the package spec file. That means, a packager will not
> need to edit some additional files to enable parallel-availability.
>
> I would argue that if every single package in Fedora used semantic
> versioning, then we wouldn't need streams at all. dnf could simply
> have a config option that would assure staying on the same major
> version during updates unless told otherwise.
>
> The concept of "stream" is only needed if there are upstreams/packages
> that do not exactly conform to semantic versioning where change in the
> first number means API breakage. I suspect there are quite a lot of
> them still and maybe, in some cases, we would like to have streams
> that stand for something else than a major version? E.g. devel that
> stores always the latest upstream state and is updated automatically.
>
> For that reason, I assume the concept of stream might be useful.
>
> But the question is how to provide a stream name through rpm?
>
> I was looking at
> https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtag.h
> and found there is DistTag rpm tag that you can put into a spec file
> and that seems to be unused these days.
>
> According to what I have found in a comment in /usr/lib/rpm/macros on this
> tag:
>
> # Configurable distribution tag, same as DistTag: tag in a specfile.
> # The tag will be used to supply reliable information to tools like
> # rpmfind.
> #
> #%disttag
>
> Fedora packages do not have it set:
>
> E.g.:
>
> $ rpm -q --queryformat '%{DISTTAG}\n' prunerepo-1.13-1.fc28.noarch.rpm
> (none)
>
> and I don't think we need to care that much about rpmfind at least as
> far as DistTag is the concern.
>
> So it could be used to provide a "stream" name. I mean we don't really
> need to call it stream either. What we essentially want is to group
> packages of the same name by their major version or in some case by a
> descriptive string like "devel".
>
> Once we have this grouping provided for dnf, we can add an option like:
>
> updates_maintain_disttag=true/false
>
> which will make dnf updates stable if true and if packagers keep their
> DistTags set to package major versions.
>
> Another thing is that DistTag value can be automatically derived from
> DistGit branch name. Meaning that if you use arbitrary branching like
> e.g. nodejs uses (https://src.fedoraproject.org/rpms/nodejs/branches)
> where branch names correspond to major versions, then with some kind
> of auto-generation in place you can be just-about done only by
> creating a branch with a proper name.
>
> Funny thing is that this would work even if used with distro branches
> because in distro branches, packagers should not update majors per
> packaging guidelines (only maybe for leaf nodes with FESCo exception
> it might be possible) so even though such stream (e.g. f29) would be a
> mix of many different packages, those packages would maintain the same
> major version during the stream active existence.
>
> The second problem was to make
>
> $ sudo dnf update git
>
> work if there are e.g. two DistTags ("streams") 1 and 2.
>
> Do you pick git-1 from DistTag 1 or git-2 from DistTag 2?
>
> I would leave the decision what version to pick on a dnf config
> option, which could be e.g.:
>
> default_disttag_select_strategy=lowest_compatible
>
> where
Summary for Monday's FESCo Meeting (2018-12-17)
= #fedora-meeting-1: FESCO (2018-12-17) = Meeting started by maxamillion at 15:05:25 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-12-17/fesco.2018-12-17-15.05.log.html . Meeting summary --- * init process (maxamillion, 15:05:25) * Follow Up Business (maxamillion, 15:09:49) * #2020 Firefox is switching from gcc to clang/llvm (maxamillion, 15:09:52) * LINK: https://pagure.io/fesco/issue/2020 (maxamillion, 15:09:52) * AGREED: : Revisit "Firefox is switching from gcc to clang/llvm" after the new year (+1: 6 -1:0, +0:0) (maxamillion, 15:19:21) * New Business (maxamillion, 15:19:26) * #2021 F30 Change: Migrate Python-based Nautilus extensions to Python 3 (maxamillion, 15:20:14) * LINK: https://pagure.io/fesco/issue/2021 (maxamillion, 15:20:14) * AGREED: Wait until more information is provided as per https://pagure.io/fesco/issue/2021#comment-545919 (+1:6, -1:0, +0:0) (maxamillion, 15:25:58) * Next week's chair (maxamillion, 15:26:18) * ACTION: bowlofeggs to chair next meeting (maxamillion, 15:30:05) * Open Floor (maxamillion, 15:30:18) Meeting ended at 15:38:12 UTC. Action Items * bowlofeggs to chair next meeting Action Items, by person --- * bowlofeggs * bowlofeggs to chair next meeting People Present (lines said) --- * maxamillion (32) * bowlofeggs (21) * zodbot (16) * zbyszek (11) * jforbes (9) * nirik (8) * jsmith (6) * bukaj (2) * bcotton (1) * tyll (0) * sgallagh (0) * contyk (0) signature.asc 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
Schedule for Monday's FESCo Meeting (2018-12-17)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-12-17 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 = Enable "Prevent creating new branches by git push" in dist-git https://pagure.io/fesco/issue/2018 ACCEPTED (+4, 0, -0) = Followups = #topic #2020 Firefox is switching from gcc to clang/llvm .fesco 2020 https://pagure.io/fesco/issue/2020 = New business = #topic #2021 F30 Change: Migrate Python-based Nautilus extensions to Python 3 .fesco 2021 https://pagure.io/fesco/issue/2021 = 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. signature.asc 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
Summary/Minutes from today's FESCo Meeting (2018-12-03)
= #fedora-meeting-1: FESCO (2018-12-03) = Meeting started by contyk at 15:00:02 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-12-03/fesco.2018-12-03-15.00.log.html . Meeting summary --- * init process (contyk, 15:00:16) * F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras (contyk, 15:03:34) * LINK: https://pagure.io/fesco/issue/2016 (contyk, 15:03:40) * AGREED: FESCo approves of the DNF stack rebase (+7, 1, -0) (contyk, 15:10:27) * Enabling pm_request in fedoraproject koji (contyk, 15:10:43) * LINK: https://pagure.io/fesco/issue/2004 (contyk, 15:10:49) * We're waiting for another concrete proposal to resolve this (contyk, 15:12:28) * Ursa Major (modules in buildroot) enablement (contyk, 15:12:36) * LINK: https://pagure.io/fesco/issue/2003 (contyk, 15:12:43) * There two major points that need to be addressed regarding Ursa Major. #1 Make it painless for package maintainers and releng to maintain the UM config, and #2 Make it reasonably easy for non-koji users to consume our buildroot content (contyk, 16:07:21) * We will discuss these topics in the ticket (contyk, 16:07:37) * The FTBFS cleanup policy is not happening (contyk, 16:07:58) * LINK: https://pagure.io/fesco/issue/1973 (contyk, 16:08:07) * It *is* happening! (contyk, 16:08:56) * Action needed: Orphan packages will be retired if they remain orphaned for six weeks (contyk, 16:09:00) * LINK: https://pagure.io/fesco/issue/1970 (contyk, 16:09:07) * Also ongoing (contyk, 16:10:36) * https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation (contyk, 16:10:53) * AGREED: GnuPG2 as the default GPG implementation approved (+7, 0, -0) (contyk, 16:17:10) * Next week's chair (contyk, 16:17:40) * ACTION: zbyszek will chair the next meeting (contyk, 16:18:49) * Open Floor (contyk, 16:19:00) * No FESCo meetings on Dec 24 & Dec 31 (contyk, 16:21:04) Meeting ended at 16:22:24 UTC. Action Items * zbyszek will chair the next meeting Action Items, by person --- * zbyszek * zbyszek will chair the next meeting People Present (lines said) --- * contyk (138) * bowlofeggs (44) * zbyszek (37) * nirik (34) * sgallagh (27) * zodbot (21) * maxamillion (17) * tyll (16) * jforbes (13) * mizdebsk (12) * jsmith (5) * nim (3) * till__ (2) * ignatenkobrain (1) * smooge (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot signature.asc 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: Schedule for Monday's FESCo Meeting (2018-12-03)
On Mon, Dec 03, 2018 at 11:43:33AM +0100, Igor Gnatenko wrote: > Any idea why > https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation > still doesn't have FESCo ticket? It's been a week since it was sent to ML. Nope but I wanted to put it on the agenda anyway but apparently forgot. The last week's agreement was to wait another week to discuss any open questions. P > > On Mon, Dec 3, 2018, 10:40 Petr Šabata > > Following is the list of topics that will be discussed in the > > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > > irc.freenode.net. > > > > To convert UTC to your local time, take a look at > > http://fedoraproject.org/wiki/UTCHowto > > > > or run: > > date -d '2018-12-03 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 (or the last meeting) = > > F30 System-Wide Change: The GNU C Library version 2.29 > > https://pagure.io/fesco/issue/2014 > > ACCEPTED (+6, 0, -0) > > > > too strict rules for branches deletion alongside with norules for theirs > > creations > > https://pagure.io/fesco/issue/2013 > > ACCEPTED (+7, 0, -0) > > > > Preclusion of Firefox automatic download of OpenH264 (#1359) may have been > > violated at some point > > https://pagure.io/fesco/issue/2015 > > CLOSED (+6, 0, -0) > > > > = Followups = > > > > #topic F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras > > .fesco 2016 > > https://pagure.io/fesco/issue/2016 > > > > #topic Enabling pm_request in fedoraproject koji > > .fesco 2004 > > https://pagure.io/fesco/issue/2004 > > > > #topic Ursa Major (modules in buildroot) enablement > > .fesco 2003 > > https://pagure.io/fesco/issue/2003 > > > > #topic The FTBFS cleanup policy is not happening > > .fesco 1973 > > https://pagure.io/fesco/issue/1973 > > > > #topic Action needed: Orphan packages will be retired if they remain > > orphaned for six weeks > > .fesco 1970 > > https://pagure.io/fesco/issue/1970 > > > > = New business = > > > > Nothing. > > > > = 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 > > > ___ > 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 signature.asc 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
Schedule for Monday's FESCo Meeting (2018-12-03)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-12-03 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 (or the last meeting) = F30 System-Wide Change: The GNU C Library version 2.29 https://pagure.io/fesco/issue/2014 ACCEPTED (+6, 0, -0) too strict rules for branches deletion alongside with norules for theirs creations https://pagure.io/fesco/issue/2013 ACCEPTED (+7, 0, -0) Preclusion of Firefox automatic download of OpenH264 (#1359) may have been violated at some point https://pagure.io/fesco/issue/2015 CLOSED (+6, 0, -0) = Followups = #topic F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras .fesco 2016 https://pagure.io/fesco/issue/2016 #topic Enabling pm_request in fedoraproject koji .fesco 2004 https://pagure.io/fesco/issue/2004 #topic Ursa Major (modules in buildroot) enablement .fesco 2003 https://pagure.io/fesco/issue/2003 #topic The FTBFS cleanup policy is not happening .fesco 1973 https://pagure.io/fesco/issue/1973 #topic Action needed: Orphan packages will be retired if they remain orphaned for six weeks .fesco 1970 https://pagure.io/fesco/issue/1970 = New business = Nothing. = 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. signature.asc 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: Schedule for Monday's FESCo Meeting (2018-10-15)
= #fedora-meeting-1: FESCO (2018-10-15) = Meeting started by contyk at 15:00:02 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-15/fesco.2018-10-15-15.00.log.html . Meeting summary --- * init process (contyk, 15:00:13) * #1974 Problematic blocker for F29: dnf 'offline' module tracking (contyk, 15:02:46) * LINK: https://pagure.io/fesco/issue/1974 (contyk, 15:02:52) * AGREED: drop blocker status on bug, document in release notes, common bugs and anywhere else we can (+7, 0, -0) (contyk, 15:21:05) * Next week's chair (contyk, 15:21:33) * ACTION: jforbes will chair next meeting (contyk, 15:23:32) * Open Floor (contyk, 15:23:43) Meeting ended at 15:43:14 UTC. Action Items * jforbes will chair next meeting Action Items, by person --- * jforbes * jforbes will chair next meeting People Present (lines said) --- * contyk (46) * bowlofeggs (30) * sgallagh (27) * bcotton (19) * zbyszek (18) * nirik (16) * zodbot (14) * jforbes (9) * tyll (1) * jsmith (0) * maxamillion (0) signature.asc 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
Schedule for Monday's FESCo Meeting (2018-10-15)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-10-15 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 = F30 Change: PHP 7.3 https://pagure.io/fesco/issue/1997 DECISION (+6, 0, -0) = Followups = #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking .fesco 1974 https://pagure.io/fesco/issue/1974 = 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. signature.asc 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: Moving on from Council Engineering role
On Thu, Oct 11, 2018 at 05:29:44PM -0400, Paul Frields wrote: > On Thu, Oct 11, 2018 at 12:54 PM Josh Boyer wrote: > > I believe it's time for me to move on from my current role as the > > Council Engineering representative. When I resigned from FESCo a bit > > ago, I thought I could still fulfill this role. Unfortunately, that > > turns out to not be the case. I cannot in good conscience hold a seat > > on the Council and be an absentee member. > > > > As we look to the future for Fedora, we need someone with more active > > participation to be present. Fortunately, we have a large set of very > > competent people that I believe can step into this role without issue. > > While it is only a suggestion, I would like to nominate Petr Šabata as > > the new Council Engineering rep. He is more than capable of > > discussing the technical implications of Modularity and the newly > > proposed Objective from Paul. The decision will ultimately be up to > > FESCo and the Council of course. > > > > These are important times for Fedora and I'm excited for the future! > > I will continue to participate as I can and I'm looking forward to > > seeing the directions we take as a project and as a distribution. It > > has been an honor to be part of the Fedora Council for the past few > > years. Thank you to the community for trusting me with that role for > > so long. > > I'm abstaining from weighing in on the nomination for obvious reasons. > But I did want to say a huge thank you to Josh for all he's done in > these roles over the past years. He was an enormously helpful Board > member during my FPL days, and has continued to be a steady guide > since then. My blue fedora is off to you, sir! Seconded. I would also like to thank Josh and accept the nomination. P signature.asc 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: Modularity is still confusing
On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote: > On 10/3/18 9:53 PM, Christopher wrote: > > I'm still very confused about how to do modular packaging in Fedora. I > > don't know: > > > > 1. How do I create a module for a new Fedora package? > > 2. How do I create a module for my existing non-modular Fedora package? > > 3. How do I declare BuildRequires on my build dependencies from another > > module? > > 4. How do I declare Requires on my runtime dependencies from another module? > > 5. How do I know what modules are available? > > 6. How do I figure out which packages are in a particular module? > > 7. How do I find out what module a particular package is in? > > The documentation noted elsewhere in this thread is pretty handy; I've read > through it a couple of times now and really appreciate the work that has gone > into it -- thank you. I do have some suggestions: > >-- I'm going to be a little cranky and say the use of "ursine" is very > confusing to me; it's a cute pun, but we have actual bears -- who are > intensely ursine, as it were -- that live nearby so I constantly have > to remind myself of context and translate since proper use of that word > has been familiar to me for many years. This could just be me being an > old codger, however, and I freely admit that :). sadbearissad.jpeg You should know we also have this service named Ursa Major... >-- Could we put the answers to the questions above into the FAQ? Good idea. >-- And the one question I have to add on to Christopher's wonderful list: > I have a package where upstream releases about once a month, and each > new release must by definition be backwards compatible (acpica-tools, > specifically). I can think of no scenario where a module provides value > to me or end-users; in fact, using anything other than the most recent > causes problems. Do I have to create and maintain a module for this > package anyway? Or are the defaults robust enough that a package can > remain a package without touching modularity at all? The answer to this > is completely unclear to me -- what I've read seems to imply that I must > create a module definition regardless. First of all, you don't have to create and maintain a module. You can continue packaging this like you're used to. But if you decide to embrace modularity, there's nothing wrong with providing a single stream with just one package. You could call it the "latest", or, as some people prefer, "stable" (uh). That way you could benefit from some of the build automation and maintain just one SPEC file for all releases, at least. I see there are packages that depend on yours. At runtime this isn't a real problem as long as your module is enabled by default; however, moving your package to modules only would make it unavailable to non-modular content in the buildroot (until the above-mentioned Ursa Major is a thing in Fedora). Module defaults only select default module streams and default installation profiles (similar to package groups) for each. If you don't package your software as a module, you don't have to care about this at all. P signature.asc 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: Modularity is still confusing
On Thu, Oct 04, 2018 at 05:46:54PM -, Raphael Groner wrote: > >> 4. How do I declare Requires on my runtime dependencies from another > >> module? > > No changes on the RPM level. You also have dependencies on the module > > level, > > which makes their packages available to you. At buildtime it means their > > packages > > are available for you to install in the buildroot, at runtime that they are > > available as > > installable deps. Besides ensuring you depend on the modules that provide > > your > > packages in the appropriate situations, you don't need to do anything. > > Isn't this what comps are designed for? > # dnf group install $name Unless I'm missing something, comps don't really pin you to sets of NVRs for the same name. If I have, for example, two conflicting stacks available, say perl:5.26 and perl:5.28, with modules I can choose which of the two I have available in the buildroot and can later select the package set at runtime. With comps I'd need to hardcode this in package names and reflect that in every Perl package in Fedora. At runtime I also get updates for perl:5.26 with the usual "dnf upgrade", without being upgraded to 5.28, unless I choose to switch. Maybe you had something else in mind. In that case, please elaborate. P signature.asc 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: Modularity is still confusing
On Wed, Oct 03, 2018 at 11:53:25PM -0400, Christopher wrote: > I'm still very confused about how to do modular packaging in Fedora. I > don't know: > > 1. How do I create a module for a new Fedora package? > 2. How do I create a module for my existing non-modular Fedora package? https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ > 3. How do I declare BuildRequires on my build dependencies from another > module? > 4. How do I declare Requires on my runtime dependencies from another module? No changes on the RPM level. You also have dependencies on the module level, which makes their packages available to you. At buildtime it means their packages are available for you to install in the buildroot, at runtime that they are available as installable deps. Besides ensuring you depend on the modules that provide your packages in the appropriate situations, you don't need to do anything. > 5. How do I know what modules are available? This one is tricky. If you only care about runtime and what's available to Fedora end users directly, you can just run "dnf module list" or inspect the repodata (*modules.yaml.gz) of the release you're targeting. Not all modules are included in the repos. Some are used as building blocks and discovering these is more difficult. You can query the MBS database to inspect everything there is: https://mbs.fedoraproject.org/module-build-service/1/module-builds/ The REST API is documented here: https://pagure.io/fm-orchestrator > 6. How do I figure out which packages are in a particular module? > 7. How do I find out what module a particular package is in? These also need more work and depdends on what you're looking for. "dnf module info" and "dnf module provides" or looking at the repodata of your targetted release can help you identify what binary packages are provided by particular modules. This doesn't include building block modules as those aren't in the repo. MBS database (see above) has links to all modular component builds in koji. You could use that, too. This includes everything, sources and binaries, available in the repos or not. For sources and build instructions, the database is enough but you could also just pull the modulemd files from dist-git. > Learning modularity, now that the primary maintainer for most of the > Java build ecosystem in Fedora is orphaning their non-modular > packages, has become very important for several of my packages, but > I'm still struggling to find where these basic answers are documented. > I'm a loyal Fedora user, but a novice packager, and still occasionally > struggle with basic non-modular packaging tasks. Understanding modular > packaging seems to be even harder to find clear, step-by-step > instructions to follow, than regular non-modular packaging > instructions, which I'm still not an expert with. Thanks for asking these questions. We're aware of some gaps but sometimes you just don't know what people don't know. Modules also have the concept of defaults, making their packages available at runtime, even as dependencies for non-modular packages. There are also mechanisms to make select modules available in the buildroot for everyone but this isn't currently possible in Fedora. We would like to change that at some point, though. With these, you shouldn't be forced to switch to modularity if you don't want to and the maintainers of your dependencies handle their transition properly. > The answers to these questions should be clear, step-by-step > command-line instructions, or specific examples of a SPEC file > modification. Where can I find that kind of documentation? I know I've > attempted to ask similar questions in the past, but I just haven't > seen good documentation in response. Is there anybody who really, > truly, understands how to do modular packaging well enough to write a > clear step-by-step instructions for the rest of us to follow? So, we have this: https://docs.fedoraproject.org/en-US/modularity/ Suggestions for improvements or even PRs are definitely appreciated. P signature.asc 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: Changes in packages workflow vs. modular Fedora
On Mon, Sep 17, 2018 at 12:45:59PM +0200, Miro Hrončok wrote: > On 17.9.2018 12:36, Petr Šabata wrote: > > On Thu, Sep 13, 2018 at 11:07:50PM +0200, Miro Hrončok wrote: > > > > > d) (this example is not real (yet)) We decide to retire (remove) > > > > > python2-sphinx because upstream Sphinx no longer supports Python 2. > > > > > We make > > > > > sure that nothing in Fedora requires or buildrequires it, as all > > > > > Fedora's > > > > > Python packages use python3-sphinx or no Sphinx at all. However there > > > > > is a > > > > > Django 1.6 module where python-django uses python2-sphinx to build > > > > > the docs, > > > > > while python2-sphinx is not part of the module itself. How do we find > > > > > out > > > > > about this and is it our reprehensibility to keep it in rawhide or > > > > > add it to > > > > > the module? > > > > > > > > I wouldn't say it's your responsibility to resolve the issue > > > > but it is your responsibility to file a bug for the module. > > > > > > How would I know about that in the first place? How do I query it? > > > > It will either be in the archive :) or you check the tags and > > their binaries & modulemds. > > > This is not going to be trivial. If you could provide examples, it would be > great. It indeed isn't. To get the list of F29 modular tags, you could run: % koji list-tags | grep -P '^f29-modular(-.*)?$' To get the list of modules in those tags, e.g. F29 "GA": % koji list-tagged f29-modular But now it gets complicated. Even if you fetch the modulemd from koji or MBS, you won't have the list of RPM artifacts in these (yet, that will change in the near future). For that you'll need the composed modulemd. So ignoring the above, you could just check the latest F29 modular repos, get the modules.yaml.gz in their repodata and see the data.artifacts.rpms sections which list all their RPMs in the repo. Once you have those, you can query them individually. However, since DNF hides disabled streams, you'd either need to download them or enable each stream before running the queries. I know, it's bad. We need to enhance repoquery quite a bit here. I guess you could also fetch primary.xml and work with that. If you're interested in SPEC files, the modulemds in koji and MBS tell you what refs were used to build the components, both the original input (usually branch names) and the expanded variant (commit hashes). Example for testmodule-master-20180405123256.c2c572ec: https://koji.fedoraproject.org/koji/buildinfo?buildID=1065618 You can then fetch these from dist-git. Feel free to ask on our channel so that we can find a workable solution for you now... and something for the future. P signature.asc 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: DNF and Modularity
On Mon, Sep 24, 2018 at 10:02:39AM +0200, Miroslav Suchý wrote: > Hi, > I have to admit that I am a bit puzzled about DNF behavior with modularity. > > I have installed repo files with modularity repos, but all of them are > disabled. I have no module enabled on my system > (F29 BTW). To be precise: > output of `dnf module list` > https://paste.fedoraproject.org/paste/3QvX2xv4OgVVmgckTnEQcQ > > And every time I run `dnf upgrade` I get this output: > > Problem 1: cannot install the best update candidate for package > bubblewrap-0.3.0-2.fc29.x86_64 > - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled > Problem 2: cannot install the best update candidate for package > docker-distribution-2.6.2-7.git48294d9.fc28.x86_64 > - package > docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 is disabled > Problem 3: cannot install the best update candidate for package > eog-3.28.3-1.fc29.x86_64 > - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled > Problem 4: cannot install the best update candidate for package > exempi-2.4.5-3.fc29.x86_64 > - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled > Problem 5: cannot install the best update candidate for package > flatpak-runtime-config-27-7.fc29.x86_64 > - package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is > disabled > Problem 6: cannot install the best update candidate for package > gimp-2:2.10.6-2.fc29.x86_64 > - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled > Problem 7: cannot install the best update candidate for package > gimp-libs-2:2.10.6-2.fc29.x86_64 > - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled > Problem 8: cannot install the best update candidate for package > kubernetes-client-1.10.3-1.fc29.x86_64 > - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is disabled > Problem 9: cannot install the best update candidate for package > libnghttp2-1.33.0-1.fc29.x86_64 > - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled > Problem 10: cannot install the best update candidate for package > libpeas-1.22.0-9.fc29.x86_64 > - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled > Problem 11: cannot install the best update candidate for package > libpeas-gtk-1.22.0-9.fc29.x86_64 > - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled > Problem 12: cannot install the best update candidate for package > libpeas-loader-python3-1.22.0-9.fc29.x86_64 > - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is > disabled > Problem 13: cannot install the best update candidate for package > libuv-1:1.22.0-2.fc29.x86_64 > - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled > Problem 14: cannot install the best update candidate for package > nghttp2-1.33.0-1.fc29.x86_64 > - package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled > Problem 15: cannot install the best update candidate for package > nodejs-1:10.11.0-1.fc29.x86_64 > - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled > Problem 16: cannot install the best update candidate for package > npm-1:6.4.1-1.10.11.0.1.fc29.x86_64 > - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is disabled > Problem 17: cannot install the best update candidate for package > perl-DB_File-1.842-1.fc29.x86_64 > - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled > Problem 18: cannot install the best update candidate for package > perl-HTTP-Tiny-0.076-1.fc29.noarch > - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled > Problem 19: cannot install the best update candidate for package > perl-Thread-Queue-3.13-1.fc29.noarch > - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled > > It does not matter if I pass `--best` option or not. > Why I - as a user - see this warnings/errors? > > Is this an error or a feature? Definitely an error. Could be another case of https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it should have been fixed last week. Is your repo current? Could you check for the presence of modular repodata (the *modules.yaml.gz) file. P > > Miroslav > ___ > 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 signature.asc 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 Guid
Re: Managing stream (arbitrary) branch and module lifecycles
On Thu, Sep 20, 2018 at 09:11:57AM -0400, Matthew Miller wrote: > On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote: > > There is another concept in Modularity we can use here: defaults. You could > > have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora > > releases, but have different default for each. So in your case, F27 could > > have 1.7 as a default and F28+ could have 1.8 as a default. > > > > Independently of this, you could also retire 1.7 with the end of F27 if > > there was no need to have it in the future releases. > > Is there a way for users to say "keep me on whatever module is the default" > when upgrading? If they enable the module explicitly, they will keep that stream, regardless of what the current defaults are. Explicit enablement can happen in two ways: 1. By running `dnf module enable name:stream`, or 2. by installing any package from that module. P signature.asc 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: Blocking criteria proposal for F30+: Printing
On Thu, Sep 20, 2018 at 08:33:05AM -0400, Stephen Gallagher wrote: > There was a bug[1] filed recently that indicated that printing was > broken on certain printers. As a result of that discussion, it became > apparent that there was no criteria for printing to work at all, which > seems like an oversight. > > I discussed this briefly with Matthias Clasen this morning and he > agreed that this should be treated as blocking for Workstation. > > I'd like to propose that we add the following criteria to Beta for Fedora 30+: > * Printing must work on at least one printer available to Fedora QA. > "Work" is defined as the output from the device matching a preview > shown on the GNOME print preview display. (Note that differences in > color reproduction are not considered "non-working".) > > and this to Final for Fedora 30+: > * Printing must work on at least one printer using each of the > following drivers: > (I don't know which ones to specify here, but we ought to try to > figure out a cross-section that covers a large swath of our expected > user base). Makes sense overall. Perhaps we could compose a list of major CUPS drivers and make sure we test each with at least one printer. P > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255 signature.asc 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: Changes in packages workflow vs. modular Fedora
On Thu, Sep 13, 2018 at 11:07:50PM +0200, Miro Hrončok wrote:
> On 13.9.2018 22:44, Petr Šabata wrote:
> > On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:
> > > Hi,
> > >
> > > I was thinking about this for a while and I got the impression that this
> > > is
> > > something I don't know the answer for. The question is a bit harder to
> > > formulate simply, so let put it in examples:
> >
> > I see no one's really responded to this yet (ack!), so let me try...
>
> Thank You! I was starting to feel like nobody cares.
I really hope that's not the case :)
> > > a) A need packaging guideline is about to be discussed. A member of FPC
> > > wants to know how many packages would be affected so they run a quick grep
> > > query over all the rawhide specfiles at [0].
> >
> > Obviously this wouldn't be enough. We would need to find all
> > modules shipped with Rawhide, then all the RPM stream branches
> > they build from, and grep those as well. Perhaps we could
> > do something to generate archives that include all of this
> > automatically.
>
> Please do, otherwise this would be tedious. There are archives with rawhide
> specs.
Noted. I don't have any ETA at this point, though.
> > > b) A CVE is found in a web framework, so bugz are filled for the
> > > "framewrok"
> > > package to be fixed in Fedora 27, because newer Fedoras have newer version
> > > of the framework where the CVE is not applicable.
> >
> > Also valid. Rather than just relying on the non-modular package
> > upgrade path, all currently supported modules and their RPMs
> > would need to be checked.
>
> Is the Red Hat security response team aware of that? Do they file bugs for
> modules?
Not yet. I think this is tied to the previous point. They will
also need that archive or something similar. Also noted.
> > > c) A new version of interpreted language lands in rawhide. All packages
> > > depending on the interpeter need mass rebuild in a side tag.
> >
> > This would be a new stream of the interpreter module.
>
> No interpreter module here. An interpreter that lives in non-modular Fedora,
> but various modules possibly use it. I have no idea what modules use it (if
> any) and I have no idea how to easily find out.
>
> I know there is at least one module that uses non-modular Python 2. At least
> we won't rebase that Python to a newer version.
Again the archive ;) We should be including stream-branched
SPEC files as well as currently included modulemds.
> > > d) A packager decides to retire a library and they check nothing in Fedora
> > > requires it.
> >
> > Similar to a) and b). They need to check the currently supported
> > modules as well.
>
> How? We are mass removing python2 packages from rawhide that nothing in
> rawhide depend on. Our automation has no clue about modules and if there are
> modules that use python2-... packages from nonmodular Fedora, we need to
> know.
Same as above.
> > > I wonder how are such situations meant to be handled with modules?
> > > Do we build modules for rawhide? If so, should Fedora changes (such as,
> > > but
> > > not limited to, "the Changes") somehow handle all the modules, or is it
> > > the
> > > modular maintainer responsibility to make sure their module works on the
> > > next Fedora version?
> >
> > We're aware there are many gaps here. I consider identifying &
> > resolving them a priority for the Modularity WG at the moment,
> > so thank you for contributing.
>
> Thanks for looking into this.
We (Modularity WG) are thinking about new way of organizing &
tracking all these things (currently it's mostly just a shared
document). We'll announce it once ready.
> > > a) I was planning to propose a more strict "No more automagic Python
> > > bytecompilation" [1] change for Fedora 30 where we would query all
> > > packages
> > > that depend on the old behavior and mass add "%global
> > > _python_bytecompile_extra 1" to all of them, so we could switch the
> > > default
> > > to be 0. Normally, we would do it in Rawhide only. But how do I handle
> > > modules? How do I find out what modular packages rely on the old behavior?
> >
> > Modules typically build the same content in all contexts
> > (buildroots). If that's a problem for this particular change
> > of yours, I think the proper way would be adding %{fedora}
> > conditionals around that macro
Re: Managing stream (arbitrary) branch and module lifecycles
On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote: > This is a summary of a recent thread [1]. > > Traditional branches (such as "f29") have their EOL (end of life) encoded > in the name. But what about stream branches [2] (such as "2.4" or "latest")? > > Stream branches of RPM packages would always have an EOL associated with > them. The format would be on of the following: > a) A date — mostly tied to an upstream version and its EOL. > b) A specific Fedora release — for release-specific packages. > c) Forever — rolling forward with upstream, latest development versions, > etc. > > Module streams would inherit their EOL from the packages they include — the > earliest EOL would win. This could be optionally overridden on the module > stream level by specifying one of the following: > a) A date. > b) A specific Fedora release. > > There would be a policy that a module can reach its EOL in the middle of a > Fedora release to prevent madness. > > We need a way to specify the EOL value and to manage it over time, because > it might change. For RPM stream branches, there is currently a way to > specify an EOL value when requesting the branch [3] — the actual format > might change based on this discussion. However, I'm not aware of a way to > change the value if necessary nor a process associated with that. Also, > there is currently no way to specify an EOL for modules. > > After we figure this out, we also need to make sure the build system takes > that into account (some recent progress [4]) and that the client tooling > (mostly DNF) presents that to the user. > > So... any comments to the concept? Any ideas about workflows or processes > of managing the EOL values? I went through both threads and thought I'd offer my point of view. From experience I can tell that defining the EOL, be it a module or a package, is rather difficult. Even in the rare case where upstream is clear about their support plans, it doesn't mean we have to follow that. We might want to drop the package earlier, or the opposite -- support it on our own long after it was abandoned upstream. I think both cases are somewhat common. And we rarely, if ever, know this information at the branch creation time. So, a few things. If we need to define these for something, I'd rather only do it for modules rather than packages. Not only to simplify the process for everyone but also because I kinda feel that the module maintainer is responsible for the packages they include. I have a hard time imagining packagers maintaining stream branches "just in case someone wants to consume them". They either maintain the module or only care about the release branches. Also if you have a module with 200 components and you derive your module's EOL from the packages' EOLs, you need to be constantly watching all your components and their "arbitrary" EOL dates or risk your module being dropped. I don't think this is very user friendly. I think the rolling model would be the most commonly chosen option. Basically "supported until I decide to kill it in Rawhide". We could then update existing stable modules with a more specific date, such as the date when that release goes EOL. Maintainers should still be able to choose a date ahead of time if they wish but I'd rather not tie it to Fedora release numbers as that doesn't work very well for EPEL. Finally, I also don't see a point in really killing package stream branches. If someone is consuming these, they are responsible. If not, it doesn't matter that they exist. Not sure how much sense this makes. P > [1] Previous thread: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/ > [2] Now "stream branches", formerly "arbitrary branches": > https://fedoraproject.org/wiki/Changes/ArbitraryBranching > [3] Requesting a stream branch + specifying its EOL: > https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_repositories_and_stream_branches_existing_packages > [4] https://pagure.io/modularity/issue/102 > > -- > > Adam Šamalík > --- > Software Engineer > Red Hat > ___ > 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 signature.asc 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/archive
Re: Proposal to modify release criteria for fwraid
On Fri, Sep 14, 2018 at 10:22:12AM -0400, Stephen Gallagher wrote: > At yesterday's F29 Go/No-Go meeting, we discussed the blocker status > of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID > device. While the blocker criteria clearly states that this should be > a blocker for Beta, many of the people present at the meeting > disagreed, for a variety of reasons. > > * Hardware supporting fwraid is considerably less pervasive than it > was when the criterion was written > > * Testing this criterion can only be done with install media, which > limits our testing pool to the very dedicated members of Fedora QA. > Yes, anyone *can* download a nightly compose and try it, but in > practice this tends to be limited to the core testers. The majority of > testing that this feature will get will tend to happen as people try > out the Beta release. > > To that end, I'd like to propose that we make the following change to > the criteria going forward: > > "The blocking criterion for successful installation atop a firmware > RAID array is moved to the GA release criteria." I hope this won't just mean we discover the problems later, in practice. P signature.asc 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: Changes in packages workflow vs. modular Fedora
On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:
> Hi,
>
> I was thinking about this for a while and I got the impression that this is
> something I don't know the answer for. The question is a bit harder to
> formulate simply, so let put it in examples:
I see no one's really responded to this yet (ack!), so let me try...
> a) A need packaging guideline is about to be discussed. A member of FPC
> wants to know how many packages would be affected so they run a quick grep
> query over all the rawhide specfiles at [0].
Obviously this wouldn't be enough. We would need to find all
modules shipped with Rawhide, then all the RPM stream branches
they build from, and grep those as well. Perhaps we could
do something to generate archives that include all of this
automatically.
Currently supported modules are tagged in the f*-modular* tags.
> b) A CVE is found in a web framework, so bugz are filled for the "framewrok"
> package to be fixed in Fedora 27, because newer Fedoras have newer version
> of the framework where the CVE is not applicable.
Also valid. Rather than just relying on the non-modular package
upgrade path, all currently supported modules and their RPMs
would need to be checked.
> c) A new version of interpreted language lands in rawhide. All packages
> depending on the interpeter need mass rebuild in a side tag.
This would be a new stream of the interpreter module.
Supposedly those packages would be also modularized? In that
case everything that builds against the interpreter module with
stream expansion would need to be "rebuilt".
This also affects platform branching and needs to be solved
before f30. It should be easy to automate this. And there's
no point in limiting that to platform branching.
> d) A packager decides to retire a library and they check nothing in Fedora
> requires it.
Similar to a) and b). They need to check the currently supported
modules as well.
> I wonder how are such situations meant to be handled with modules?
> Do we build modules for rawhide? If so, should Fedora changes (such as, but
> not limited to, "the Changes") somehow handle all the modules, or is it the
> modular maintainer responsibility to make sure their module works on the
> next Fedora version?
We're aware there are many gaps here. I consider identifying &
resolving them a priority for the Modularity WG at the moment,
so thank you for contributing.
> For the above examples, here are some more specific situations with more
> specific questions:
>
>
> a) I was planning to propose a more strict "No more automagic Python
> bytecompilation" [1] change for Fedora 30 where we would query all packages
> that depend on the old behavior and mass add "%global
> _python_bytecompile_extra 1" to all of them, so we could switch the default
> to be 0. Normally, we would do it in Rawhide only. But how do I handle
> modules? How do I find out what modular packages rely on the old behavior?
Modules typically build the same content in all contexts
(buildroots). If that's a problem for this particular change
of yours, I think the proper way would be adding %{fedora}
conditionals around that macro definition.
> b) A CVE was filled for Django [2]. How does the security team responsible
> for tracking CVEs figure out we have Django 1.6 in modular Fedora? How is a
> bugzilla filled against a modular package anyway?
They should file a report against Fedora Modules rather than
Fedora, although in practice I suspect people will report bugs
as usual. Then it's about the non-modular package maintainer
re-assigning the bug properly, if necessary.
> c) When we recently mass rebuilt Python 3 packages for Python 3.7, should we
> go and seek for modules that use Python 3 (how do I do that?) and rebuild
> the packages in the modules (or even the modules?)?
Python is part of the "platform" module, so you really need
to check all the RPM stream branches used by the currently
supported modules.
You do not rebuild these packages, you rebuild the modules.
If there's no change to the SPEC files, you'll have to instruct
MBS to do a full rebuild (fedpkg module-build --optional
rebuild_strategy=all). We also plan to add more options to
limit these rebuilds to specific platforms so you wouldn't be
rebuilding for all three or more releases if not required.
> d) (this example is not real (yet)) We decide to retire (remove)
> python2-sphinx because upstream Sphinx no longer supports Python 2. We make
> sure that nothing in Fedora requires or buildrequires it, as all Fedora's
> Python packages use python3-sphinx or no Sphinx at all. However there is a
> Django 1.6 module where python-django uses python2-sphinx to build the docs,
> while python2-sphinx is not part of the module itself. How do we find out
> about this and is it our reprehensibility to keep it in rawhide or add it to
> the module?
I wouldn't say it's your responsibility to resolve the issue
but it is your responsibility to file a bug for the module.
Re: [Fedora-packaging] DNF: "There are following alternatives to this package"
On Thu, Sep 13, 2018 at 06:17:39PM +0200, Tomas Orsava wrote:
> Hi!
> We'd like to propose a new functionality for dnf: When a user tries to
> install a package XYZ and dnf doesn't find it, dnf would recommend them
> alternative packages. These offered packages would advertise that they are
> an alternative for XYZ using a specially formatted Provides tag.
>
> For example, packages `python2-requests` and `python3-requests` would both
> have the following tag:
>
> Provides: alternative-for(python-requests) = %{version}-%{release}
You could probably achieve that behavior with normal provides
we have today and a DNF plugin.
Just guessing. And people who care for such a feature could just
get the plugin, you know...
P
signature.asc
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: [modularity] Removing obsolete github repositories with module definitions
On Tue, Sep 11, 2018 at 04:24:05PM -0400, Langdon White wrote: > On Tue, Sep 11, 2018 at 3:09 PM Stephen Gallagher > wrote: > > > Go ahead > > > > > +1 +1 as well. P > > On Tue, Sep 11, 2018 at 3:04 PM Adam Samalik wrote: > > > >> We have some obsolete github repositories [1] from the f26 and f27 period > >> we are no longer using. I feel like it might be confusing to people. So I'd > >> like to remove them all. Any objections? > >> > >> [1] https://github.com/modularity-modules/ > >> -- > >> > >> Adam Šamalík > >> --- > >> Software Engineer > >> Red Hat > >> ___ > >> 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 > > > ___ > 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 signature.asc 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: Buildroot-only modules
On Fri, Aug 31, 2018 at 03:24:06AM +0200, Kevin Kofler wrote: > Mikolaj Izdebski wrote: > > Some modules are built in MBS/Koji but are never released to users. > > Currently such modules can only be used as build dependencies of other > > modules. In future, if solution like "ursa-major" [1] is implemented, > > such modules could also be used as build dependencies for non-modular > > packages. > > > > An example of buildroot-only module is javapackages-tools. This > > module is used as build dependency for 4 modules, but it is not > > included in any compose and it's not shipped to users. > > > > Should such modules be considered as allowed in Fedora? > > IMHO, no, why should that be allowed? If you think it through, it > effectively means Fedora is no longer self-hosting. > > If you need a module to build your packages, you also need to make that > module available to the users, if only to build their software. Available can mean many things. It doesn't have to mean "be present in Fedora repos", I'd say. If the building block module is easy to get via other means, it should be fine. Module local builds (via fedpkg module-build-local) are definitely capable of finding the dependency and fetching the packages for you. I suppose there could be other tools that would allow you to download such modules so you could play with them without polluting the "applications" repo. P signature.asc 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
