Re: HEADS UP: Source File Verification
On 2019-07-24, Igor Gnatenko wrote:
> we've got new section in Packaging Guidelines about verifying upstream
> sources[0] with GPG. Please use it whenever possible :)
[...]
> [0]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
May I know a FPC ticket where this change was discussed and approved?
I have few objections:
(1) I don't agree this feature is helpful. If we don't trust ./sources
file content in dist-git, we cannot trust keyring stored in the the same
dist-git repository. In other words it only brings another code into
spec files and build process that consumes resources and can fail.
(2) The "%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}'
--data='%{SOURCE0}'" command awfully verbose. "%{gpgverify}" defaulting
to "%{gpgverify 2 1 0}" for single-source packages would provide the
same functionality with less boiler-plate code. Actually augmenting
%setup macro that would perform the check automatically while user would
only build-require gnupg2 would be the best option.
(3) Recommended way of verifying uncompressed sources means double
decompression. Decompressing, verifying, and unpacking uncompressed
archive would be more processor friendly.
(4) Verification of modified archives conflicts with a legal requirement
that Fedora cannot distribute the unmodified archive.
-- Petr
___
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
Package nagstamon seems unmaintained / non-responsive maintainer
Hi, does anyone know how to reach out for the maintainer of nagstamon? There's a FTBFS bug [1] since ages without any response so far. It would be bad to see this useful package go away from Fedora. Regards, Raphael [25.07.19 07:23] whoowns nagstamon [25.07.19 07:23] owner: jaur; admin: echevemaster [25.07.19 07:23] fasinfo jaur [25.07.19 07:23] User: jaur, Name: Nikita Klimov, email: nk(at)jaur.su, Creation: 2013-03-26, IRC Nick: , Timezone: Europe/Moscow, Locale: en, GPG key ID: , Status: active [25.07.19 07:23] Approved Groups: cla_fpca cla_done packager fedorabugs [1] https://bugzilla.redhat.com/show_bug.cgi?id=1675438 ___ 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
Intent to drop python2-kobo*
I plan to drop the following python2 subpackages from rawhide: python2-kobo python2-kobo-client python2-kobo-worker python2-kobo-rpmlib python2-kobo-rpmlib already fails to install in rawhide due to the removal of python2-koji (bug 1732080). One package depends on these: freshmaker: qwan Also fails to install in rawhide, https://bugzilla.redhat.com/show_bug.cgi?id=1731903 Anyone who wants to spin off and adopt these python2 packages please get in touch by 2019-08-15. This announcement is being sent per removal process: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal -- Rohan McGovern ___ 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 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Wed, Jul 24, 2019 at 8:01 PM John Reiser wrote: > > Chris Murphy wrote: > > > > ... If the change is approved, I'll suggest Docs team revise > > documentation to recommend any resize of the pre-installed OS (macOS > > or Windows) be done within those operating systems using their tools. > > Right now, there's no support for resizing any macOS file system > > layout anyway, so we have to advise the user accordingly anyway. > > When I do this (at least every Fedora release) I use gparted (via a > LiveUSB if necessary) to produce the physical partitions that I want, > then use the Manual partitioning dialog to choose and assign them. While I think it's fine and dandy software for the task, when giving users advice it has two drawbacks: a. it doesn't apply to macOS b. anaconda offers blivet-gui which has a conceptually similar interface to gparted, but does allow assignment of mountpoints, all in one whack; so we'd be asking users to do something quite a lot more complicated by suggesting they use gparted and a bootable image we don't provide. Anyway, I'm curiously on the fence with this feature proposal. I see no mockups of the replacement dialog. Also the proposal doesn't say what happens to the Installation Options dialog that immediately precedes the Reclaim Disk Space dialog. That dialog is pretty wordy. Also the dialog proposed for replacement arguably isn't all that simple to understand: https://drive.google.com/open?id=1YxIbJKtL0FT7G0g7j5Un1PU3NLrI0K53 This is the layout for Windows 10 (created Microsoft's installer, not an OEM - but Windows isn't installed so the reclaimable space values are inflated). All five of those partitions are related to that single Windows 10 installation and it's silly to be able to delete any one of them, which has a good chance of breaking the Windows installation. OK so it's fair to say the installer can't know about these relationships, but it surely can know it's silly to offer two of the small volumes for resize when even if fully resized Fedora can't fit in the ensuing space. It's instantly a complicated adventure fraught with peril. It could also hide all the smaller volumes, and only show the large NTFS formatted volume. It really does need simplification and instead of putting in that effort, I can see why the installer team just wants to drop this dialog. But I'm skepical of the installer transporting the user from the automatic path, the safe road, into Custom partitioning as if they're now an advanced user. Custom partitioning has no resize interface. You just have to somehow know, or imagine, that you can click on a volume and change Desired Capacity, and that this causes file system shrink to happen. I don't really think the simple path should advocate for the complex path. That's not what the user signed up for. -- Chris Murphy ___ 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 Thursday's FPC Meeting (2019-07-25 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-07-25 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-07-25 09:00 PDT US/Pacific 2019-07-25 12:00 EDT --> US/Eastern <-- 2019-07-25 16:00 UTC UTC 2019-07-25 17:00 BST Europe/London 2019-07-25 18:00 CEST Europe/Berlin 2019-07-25 18:00 CEST Europe/Paris 2019-07-25 21:30 IST Asia/Calcutta New Day: Friday - 2019-07-26 00:00 HKT Asia/Hong_Kong 2019-07-26 00:00 +08 Asia/Singapore 2019-07-26 01:00 JST Asia/Tokyo 2019-07-26 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 = New business = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * 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: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
Chris Murphy wrote: ... If the change is approved, I'll suggest Docs team revise documentation to recommend any resize of the pre-installed OS (macOS or Windows) be done within those operating systems using their tools. Right now, there's no support for resizing any macOS file system layout anyway, so we have to advise the user accordingly anyway. When I do this (at least every Fedora release) I use gparted (via a LiveUSB if necessary) to produce the physical partitions that I want, then use the Manual partitioning dialog to choose and assign them. ___ 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: Rolling out Phase I of rawhide package gating
On 24. 07. 19 17:30, Robbie Harwood wrote: Pierre-Yves Chibon writes: When you run `fedpkg build` on Rawhide, your package will be built in a new koji tag (which will be the default target for Rawhide). The package will be picked up from this koji tag, signed and moved onto a second tag. Bodhi will be notified by koji once this new build is signed and will automatically create an update for it (you will be notified about this by email by bodhi directly) with a “Testing” status. If the package maintainer has not opted in into the CI workflow, the update will be pushed to “Stable” and the build will be pushed into the regular Rawhide tag, making it available in the Rawhide buildroot, just as it is today. Hi, how will we programatically check what state the tests are in? For instance, `fedpkg build` (`koji watch-task`) waits until builds are complete - what do we do to wait until tests are complete (and check the result)? If I understand this properly, `koji wait-repo` will do for packages without gated test or when the tests pass. However, it will eventually timeout if the tests fail. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: are the ppc64le builders healthy?
> "TS" == Tom Stellard writes: TS> Are these updated builders only used for f30? It appears that there are 29 PPC64le builders configured currently: https://koji.fedoraproject.org/koji/hosts?start=80&state=enabled&order=name They don't all have the same "capacity" rating. TS> Because I'm still getting builders with 4 CPU/ 10GB RAM/2GB swap on TS> rawhide. I imagine that there is some randomness in play. The build you list ran on buildvm-ppc64le-21.ppc.fedoraproject.org which has a capacity rating of 2.0. Some of the builders have a rating of 4.0. (Which I guess doesn't correspond to the increase in core count, but I don't know how it's calculated.) - J< ___ 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: are the ppc64le builders healthy?
On 7/24/19 3:53 PM, Tom Stellard wrote: > On 07/23/2019 11:36 AM, Jason L Tibbitts III wrote: >>> "KK" == Kaleb Keithley writes: >> >> KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days >> KK> ago. Two different builds on f30 built or are building fine on >> KK> x86_64, i686, and aarch64, but failed with different errors on >> KK> ppc64le at different places in the build. One looks like it ran out >> KK> of space in the file system. The other may have been OOM killed (?). >> >> There was just a bit of talk about this in IRC. The issue seems to be >> that the CPU count of the PPC64le builders was bumped from 4 to 12, but >> the amount of memory was unchanged at 10GB RAM/2GB swap. This could >> potentially cause resource exhaustion. >> >> Seems they've now been bumped to 22GB of RAM, which should help with OOM >> issues but probably not with disk space issues. >> > > Are these updated builders only used for f30? Because I'm still getting > builders with 4 CPU/ 10GB RAM/2GB swap on rawhide. For example: > https://koji.fedoraproject.org/koji/taskinfo?taskID=36476090 It's not all ppc64le builders. Only the ones on the power9 virthosts for now (01-19). I'm planning on redoing the rest (20-29) (which are on power8 vhosts), but I ran out of time before the mass rebuild. I'll do them as soon as it's over, likely next week. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: are the ppc64le builders healthy?
On 07/23/2019 11:36 AM, Jason L Tibbitts III wrote: >> "KK" == Kaleb Keithley writes: > > KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days > KK> ago. Two different builds on f30 built or are building fine on > KK> x86_64, i686, and aarch64, but failed with different errors on > KK> ppc64le at different places in the build. One looks like it ran out > KK> of space in the file system. The other may have been OOM killed (?). > > There was just a bit of talk about this in IRC. The issue seems to be > that the CPU count of the PPC64le builders was bumped from 4 to 12, but > the amount of memory was unchanged at 10GB RAM/2GB swap. This could > potentially cause resource exhaustion. > > Seems they've now been bumped to 22GB of RAM, which should help with OOM > issues but probably not with disk space issues. > Are these updated builders only used for f30? Because I'm still getting builders with 4 CPU/ 10GB RAM/2GB swap on rawhide. For example: https://koji.fedoraproject.org/koji/taskinfo?taskID=36476090 -Tom > - J< > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: dridi
On 24. 07. 19 18:51, Dridi Boukelmoune wrote: Greetings fellow package maintainers, I'm starting the non-responsive maintainer process on myself because the time I can dedicate to Fedora will significantly drop for the next 3 months. It wasn't that much to begin with... I don't think I will be able to follow up on anything, especially bugzillas, at best I plan to keep on reading what's going on on the devel list. All my packages are rather low traffic and don't require much maintenance. If you wish to become a co-maintainer, please bypass me and follow the non-responsive maintainer process. By following the process, all of your packages will get orphaned. If that is your desire, shall we do it directly? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Wed, 2019-07-24 at 14:24 -0700, Adam Williamson wrote: > On Wed, 2019-07-24 at 15:29 +0200, Jiri Eischmann wrote: > > Kamil Paral píše v St 24. 07. 2019 v 13:37 +0200: > > > On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton > > > wrote: > > > > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > > > > > > > The Manual Partitioning screen supports all actions of the Resize > > > > Disk > > > > Space dialog, so it doesn't make sense to have two user interfaces > > > > with the same functionality. > > > > > > The manual partitioning screen is also much more complex and > > > therefore more difficult to use. For the common use case of > > > installing Fedora alongside Windows (where you need to shrink the > > > Windows partition), the simple dialog is/was great. Linux novice > > > users might not be able to accomplish that in the manual partitioning > > > screen. > > > > > > Just my personal opinion, I'm not trying to convince you to revert > > > your plan. > > > > I second Kamil here. I've introduced hundreds of people to Fedora and > > "I've got Windows on the disk and need to reclaim space" is by far the > > most common scenario among Fedora novices and instead of giving them a > > simple dialog we're sending them to the manual setup which I as a Linux > > user for 15 years have problems to get oriented in. > > Is it really such engineering overhead to keep that dialog there? > > Yeah...this is specifically why this screen exists: to not be as scary > as the full-on custom partitioning screen. Or, you know...either of the > *two* full-on custom partitioning flows we have now. BTW, as a general note, it seems there's a trend building up where quite significant changes to anaconda's design are being made apparently without the design team's involvement. The 'newUI' design was worked on *extensively* by the design team, particularly Mo Duffy, and the whole UI design is a piece. I'm a bit worried that all these changes are compromising the overall 'vision' for how the installer is supposed to work. I think perhaps we should consider running noticeable changes to the anaconda design by the design team for their review and input... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Wed, 2019-07-24 at 15:29 +0200, Jiri Eischmann wrote: > Kamil Paral píše v St 24. 07. 2019 v 13:37 +0200: > > On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton > > wrote: > > > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > > > > > The Manual Partitioning screen supports all actions of the Resize > > > Disk > > > Space dialog, so it doesn't make sense to have two user interfaces > > > with the same functionality. > > > > The manual partitioning screen is also much more complex and > > therefore more difficult to use. For the common use case of > > installing Fedora alongside Windows (where you need to shrink the > > Windows partition), the simple dialog is/was great. Linux novice > > users might not be able to accomplish that in the manual partitioning > > screen. > > > > Just my personal opinion, I'm not trying to convince you to revert > > your plan. > > I second Kamil here. I've introduced hundreds of people to Fedora and > "I've got Windows on the disk and need to reclaim space" is by far the > most common scenario among Fedora novices and instead of giving them a > simple dialog we're sending them to the manual setup which I as a Linux > user for 15 years have problems to get oriented in. > Is it really such engineering overhead to keep that dialog there? Yeah...this is specifically why this screen exists: to not be as scary as the full-on custom partitioning screen. Or, you know...either of the *two* full-on custom partitioning flows we have now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
HEADS UP: Source File Verification
Hello, we've got new section in Packaging Guidelines about verifying upstream sources[0] with GPG. Please use it whenever possible :) Thanks! [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification ___ 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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, 2019-07-24 at 15:48 -0400, Matthew Miller wrote: > On Wed, Jul 24, 2019 at 01:32:29PM +0100, Peter Robinson wrote: > > In general there's usecases where a low resource desktop is useful, > > such on devices with only 1Gb of RAM where Workstation doesn't provide > > a good experience. > > I definitely agree that there's value in providing for such usecases, but I > also think there's value in defining that as outside of Workstation's scope > and using another name for that offering -- whether just Fedora XFCE or > other. That's what's proposed here, AFAICS. There doesn't seem to be any indication that this would be Workstation-branded. It's just bringing up an existing spin on another arch, essentially. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 06:05:50PM +0200, Pierre-Yves Chibon wrote: > I've added an entry in the FAQ for this: > https://pagure.io/cpe/rawhide-gating-docs/pull-request/5 > Maybe we could also expend fedpkg to provide some information on this. Speaking with my occasional-packager hat on, yes please. That would be really, really helpful. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 System-Wide Change proposal: Boost 1.70 upgrade
On Wed, Jul 24, 2019 at 09:48:01AM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/F31Boost170 > > == Summary == > > This change brings Boost 1.70 to Fedora. This will mean Fedora ships > > with a recent upstream Boost release. > This change, previously approved by FESCo, has been withdrawn by the > change owner. What happened? Problems with 1.70? Is this withdrawn or pushed to F32? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, Jul 24, 2019 at 01:32:29PM +0100, Peter Robinson wrote: > In general there's usecases where a low resource desktop is useful, > such on devices with only 1Gb of RAM where Workstation doesn't provide > a good experience. I definitely agree that there's value in providing for such usecases, but I also think there's value in defining that as outside of Workstation's scope and using another name for that offering -- whether just Fedora XFCE or other. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 06:31:50PM -, Robbie Harwood wrote: > > On Wed, Jul 24, 2019 at 11:30:45AM -0400, Robbie Harwood wrote: > > > > So we don't have an easy way to do this. I have a script that monitors the > > entire pipeline/workflow in production and in staging. > > I have been querying datagrepper for messages about the build that I've > > made to > > see if/when the tests are done. > > You can find the code in: > > https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b86378... > > called in: > > https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b86378... > > This is pretty bad from a workflow perspective, especially when it's going to > take 11 minutes (or 8 - I can't actually tell which from replies above) > longer per-package on top of what we have now, plus time for any tests to run. Agreed and as we said, this is opt-in and is only the first release. Not everything is as polished as we want it to be, the core of it is though which is why we want to have this available to the people who are interested in giving it a try. If: "I want to be able to follow/know what's going on" is a hard-requirement for you to test this system, then you'll have to wait a bit longer. If you're ok with these shortcomings, knowing they are meant to improve, then you are more than welcome to opt-in and give us some feedback on how it works for you. > Your scripts are helpful, but there are a number of issues: you repeatedly > send requests to datagrepper in a `while True` (is it okay with this load? > What if we all start doing it?), and you make assumptions about the number of > messages that can appear in an interval. I would want to see a proper > interface for querying this (i.e., not polling datagrepper in a loop), as > well as `fedpkg` integration as you suggest. It is a reasonable request. I could quickly hack something that listens to fedmsg and give you some clues as to what is going on for a specified build if that's helpful to you (and others). I've opened a ticket to fedpkg to track this idea: https://pagure.io/fedpkg/issue/346 feel free to contribute your ideas there :) Thanks for your feedback, Pierre ___ 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: [Heads up] Fedora Container base image is getting smaller
Le mercredi 24 juillet 2019 à 20:05 +0200, Clement Verna a écrit : > On Wed, 24 Jul 2019 at 16:58, Matthew Miller < > mat...@fedoraproject.org> wrote: > > On Wed, Jul 24, 2019 at 07:09:24AM +0200, Clement Verna wrote: > > > Last couple days a bigger change [2] have been introduced in the > > > fedora:rawhide image. This change drops all the weak dependencies > > > from > > > the base image which allowed us to have a smaller base image > > > (215MB). > > > > This makes me happy. Is that compressed (transfer) size or size on > > disk? > > This is the size on the disk, the compressed size is around 70MB. > > > What are the biggest things remaining? I'd love to get it into > > double-digits. > > WIthout looking in to too much details, I would say the next big > thing > we have is python3 (~50MB) that we need because of dnf. I think there > are still a few things that we can improve for example we have 7.4 MB > of timezone info and we have around 5 MB for the dejavu font which I > don't think are needed in the container context :-) Yes, DejaVu is only in the minimal install, because some users could not be bothered to select the fonts group when they needed a system with fonts, and pestered maintainers till a font was added to the default install (and DejaVu Sans is good value for that, because it provides a large coverage, in a single font, taking less space than many smaller fonts with coverage overlaps) 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] target font model on Freedesktop systems
Le mercredi 24 juillet 2019 à 14:37 +0200, Kevin Kofler a écrit : Hi, Kevin Thank you for taking the time to answer, > Nicolas Mailhot wrote: > > 2. fontconfig strives to hide all the legacy ways to designate > > different > > parts of this ideal font, and strives to expose a single "font" > > objet no > > matter what quirks exist in individual font files. We stop exposing > > lots > > of weird quirky bits right and left, that need manual assembling by > > users, or glue-ing with TEX macros. > > > > No foo variable, foo hebrew, foo narrow, foo caption, just a single > > foo > > with different available features (full variability or fixed states > > on > > the default axis, real upstream provided states or fakes generated > > by > > fontconfig at pango’s request[5], etc) > > While such a model sounds really nice in theory, especially if > missing > variants can be synthesized (e.g., automatic slanting to provide > italic > versions where no native one is available), I am worried about some > of the > practical implications: Those are all real problems, but not directly related to the proposal. The core of the proposal is agreeing to expose existing font file capabilities to apps and users in an uniform way, instead of blindly relaying whatever custom capability ID mix each font project came up with. From an end-user point of view that manifests as applying uniform font naming conventions. But, that also has consequences on the way we structure fontconfig config files, on API design between font-using libs, where we split font packages, how we present them in software catalogs, etc It will not magically add missing coverage to font files. As you pointed out we already have fonts where narrow has less coverage than bold italic for example. We also have fonts were coverage regressed after updates (Cantarell dumped cyrillic some years ago for example; it sucked to have existing Russian documents using Cantarell). It will not magically add good font selectors to all apps. We’ve been shipping DejaVu Sans as one of our main font families for a dozen year at least and some apps have still not bothered with a font selector able to handle it. It will be surprising to humans, that expect everything to be neat and tidy. Things have not been neat and tidy for quite a long time fonts- side. It’s obscured by the naming mess in current fonts, if we fix the mess the un-tidiness will become obvious to everyone. Yet, breaking (bad) habits is sometimes necessary. People objected stridently to fontconfig, because it enabled substituting missing glyphs, and that was breaking their mental model. Now even Microsoft is doing it in Windows. Humans will just have to get used that, a clean convenient uniform naming, does not imply that the font file themselves are free of holes, that different faces of a font may have different coverage levels. We can fix the naming at the lib level we can not fix the coverage, except by substitution and interpolation. It’s no different from how migration to vector fonts was managed twenty years ago. Vector and bitmap fonts appeared the same in selectors. Vector fonts allowed selecting any size you wanted, bitmap fonts only a specific subset. While synthesis is an obvious next step (after all variable fonts are just interpolating internally between fixed points) it is not included in the proposal. The proposal is just to agree on a common exposition format, regardless of the mess original font files are, regardless of the mess the app- side of font handling is. If you want to be fancy you can decline the exposition format at several levels of tech (pretend everything is Postscript, with a single face per font, pretend everything is first- gen TrueType, with just Normal/Bold/Italic/Bold Italic, pretend variability does not exist, etc). That‘s for fontconfig maintainers to decide. (IMHO, it’s pretty pointless to add fake old-style naming APIs to fontconfig, apps that won't bother supporting new fonts, are not going to use new API calls, even to keep in the past.) Agreeing on a common exposition format, at the fontconfig level, means that interested apps target this format in their devs, instead of waiting for the font catalog to magically become coherent (it never has been and never will be). It means that users do not have to remember "I want to write in Syldavian script, in A font it’s included in “A Syldavian”, in B font it’s in “B not-Bordurian”, in C font it’s directly named C, except for last year’s C where it was stashed in C phantasyeuropean. And app X names them all some way, and app Y another way." With an uniform exposition format fontconfig collects all the A B and C fragments available and presents them as A B or C, hiding the mutable fragment names. If it is not handled at the fontconfig level, workarounds will start appearing at app or lib level. Or, we'll have more and more of proposals like “make variability work for noto in pango, let other fonts libs and apps fe
Re: Rolling out Phase I of rawhide package gating
> On Wed, Jul 24, 2019 at 11:30:45AM -0400, Robbie Harwood wrote: > > So we don't have an easy way to do this. I have a script that monitors the > entire pipeline/workflow in production and in staging. > I have been querying datagrepper for messages about the build that I've made > to > see if/when the tests are done. > You can find the code in: > https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b86378... > called in: > https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b86378... This is pretty bad from a workflow perspective, especially when it's going to take 11 minutes (or 8 - I can't actually tell which from replies above) longer per-package on top of what we have now, plus time for any tests to run. Your scripts are helpful, but there are a number of issues: you repeatedly send requests to datagrepper in a `while True` (is it okay with this load? What if we all start doing it?), and you make assumptions about the number of messages that can appear in an interval. I would want to see a proper interface for querying this (i.e., not polling datagrepper in a loop), as well as `fedpkg` integration as you suggest. Thanks, --Robbie ___ 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: [Heads up] Fedora Container base image is getting smaller
On Wed, 24 Jul 2019 at 16:58, Matthew Miller wrote: > > On Wed, Jul 24, 2019 at 07:09:24AM +0200, Clement Verna wrote: > > Last couple days a bigger change [2] have been introduced in the > > fedora:rawhide image. This change drops all the weak dependencies from > > the base image which allowed us to have a smaller base image (215MB). > > This makes me happy. Is that compressed (transfer) size or size on disk? This is the size on the disk, the compressed size is around 70MB. > What are the biggest things remaining? I'd love to get it into > double-digits. WIthout looking in to too much details, I would say the next big thing we have is python3 (~50MB) that we need because of dnf. I think there are still a few things that we can improve for example we have 7.4 MB of timezone info and we have around 5 MB for the dejavu font which I don't think are needed in the container context :-) We have the fedora-minimal image that is using microdnf (no python needed) which is 136 MB (40MB compressed) big. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning/retiring 3 Java packages
> Am 23.07.2019 um 16:08 schrieb Mikolaj Izdebski : > > On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok wrote: >> On 23. 07. 19 13:27, Mikolaj Izdebski wrote: >>> Soon after Fedora 31 branching I intend to retire java-packaging-howto >>> package and orphan byaccj and javapackages-tools packages. The reason >>> is that I intend to maintain these packages as part of modules. >>> >>> I will continue to maintain non-modular packages through lifecycles of >>> Fedora 29-31, but starting from Fedora 32 I will maintain modular >>> versions only. >> >> Do you realize that while your decision to move essential bits of Java >> packaging >> to modules might untie your hands a lot, it is causing everybody else >> involved >> more and more trouble? > > Perhaps I don't realize the trouble, could you elaborate? I expect > orphaned packages to be adopted by someone, likely a member of > Stewardship SIG. These two packages are low-maintenance and don't > require much work - they don't have many upstream changes and don't > get many bugs reported. So I don't see that much trouble in this case. > >> I acknowledge that it is your right to orphan essentially anything you want, >> however the motivation here seems a bit... nonempathetic. >> >> Would you mind to reconsider? > > Definitely - this is the reason I wrote to the list. Do you have any > proposal what to do with these packages instead of orphaning them? Sorry for jumping in. I think this might be an opportunity to participate in the Fedora Projekt. I’ve a lot of experience in java development and in creating application rpms, but none in the specialties of Fedora packaging. Would you accept me as co-maintainer and provide some guidance at the beginning? Peter > > -- > Mikolaj Izdebski > ___ > 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 — Dr. Peter Boy Universität Bremen Mary-Sommerville-Str. 5 28359 Bremen Germany p...@zes.uni-bremen.de www.zes.uni-bremen.de Are you looking for a web content management system for scientific research organizations? Have a look at http://www.scientificcms.org Are you looking for a web content management system for public administrations? Have a look at http://www.aplaws.org & https://fedorahosted.org/aplaws/ ___ 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 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Wed, Jul 24, 2019 at 5:38 AM Kamil Paral wrote: > > On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space >> >> The Manual Partitioning screen supports all actions of the Resize Disk >> Space dialog, so it doesn't make sense to have two user interfaces >> with the same functionality. > > > The manual partitioning screen is also much more complex and therefore more > difficult to use. For the common use case of installing Fedora alongside > Windows (where you need to shrink the Windows partition), the simple dialog > is/was great. Linux novice users might not be able to accomplish that in the > manual partitioning screen. > > Just my personal opinion, I'm not trying to convince you to revert your plan. I agree. If the change is approved, I'll suggest Docs team revise documentation to recommend any resize of the pre-installed OS (macOS or Windows) be done within those operating systems using their tools. Right now, there's no support for resizing any macOS file system layout anyway, so we have to advise the user accordingly anyway. And manual partitioning can be suggested as an alternative for advanced users. -- Chris Murphy ___ 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: MPFR 4
On Thu, Jul 18, 2019 at 11:31:02AM -0600, Jerry James wrote: > On Fri, Jul 12, 2019 at 9:07 AM Jerry James wrote: > > I'm down to these 3 still to go: arm-none-eabi-gcc-cs, avr-gcc, and > > cross-gcc. Those gcc builds take a long time. :-) So far the builds > > have gone smoothly. > > All the builds have completed without trouble. I did have to patch a > couple of packages to use mpfr_rootn_ui() instead of mpfr_root(). > That required a little care since those two functions are only > *mostly* equivalent. Other than that, there have been no issues at > all. > > > Does anyone at RedHat know if Pavel is on vacation? If not, what is > > the best way to contact him? > > I would like to ask again if anyone who works at RedHat can check on > Pavel's status. It would be good to know if he is not available until > , or if he is too busy to pay attention to mpfr. Thank you. Hi, sorry for the delayed reply. I will not be able to look into it before Monday. 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: Self Introduction: Dee'Kej (looking for sponsor)
On Wed, Jul 24, 2019 at 6:52 PM Pavel Valena wrote: > > - Original Message - > > From: "David Kašpar" > > To: devel@lists.fedoraproject.org > > Sent: Thursday, July 18, 2019 5:23:22 PM > > Subject: Self Introduction: Dee'Kej (looking for sponsor) > > > > Hello, > > > > my name is David Kaspar (a.k.a. Dee'Kej), and I used to be a package > > maintainer as a Red Hat employee for 3.5 years. Now that I'm no longer part > > of Red Hat I can't use my old Red Hat associated accounts to help with the > > work on Fedora... > > > > Therefore I have restored my old 'deekej' FAS account, and I'm currently > > looking for a sponsorship for packagers group here, because right now I > > don't have any new package I would like to add into Fedora (to set a blocker > > to FE-NEEDSPONSOR BZ). I hope my previous contributions & experience will be > > enough for someone to grant it. :) > > > > I used to maintain these packages: > > * initscripts > > * ghostscript (+ libijs, urw-base35-fonts, ...) > > * gawk > > * tcsh > > > > With kind regards, > > > > Dee'Kej > > > > Hello again! > > So what's your plan? :) > - Interested in Ruby packaging[0]? Let me advertise Rust then! We have plenty of stuff to do. https://fedoraproject.org/wiki/SIGs/Rust > > Greetings, > Pavel > > [0] https://fedoraproject.org/wiki/SIGs/Ruby > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Non-responsive maintainer: dridi
Greetings fellow package maintainers, I'm starting the non-responsive maintainer process on myself because the time I can dedicate to Fedora will significantly drop for the next 3 months. It wasn't that much to begin with... I don't think I will be able to follow up on anything, especially bugzillas, at best I plan to keep on reading what's going on on the devel list. All my packages are rather low traffic and don't require much maintenance. If you wish to become a co-maintainer, please bypass me and follow the non-responsive maintainer process. I'm not going away from Fedora, it will remain my main OS, and I plan to stick around and revisit my involvement in a couple months. Dridi ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
> "FW" == Florian Weimer writes: FW> ELF multilib DSOs inside RPMs result in code deduplication, FW> affecting container image size. I think it's important to quantify this kind of thing. I think we can all agree that there is very little benefit to duplicating every single library, so extra space usage would come only from libraries which meet all of: * Compiling with AVX2 (or whatever) provides benefit * Special runtime detection code isn't included * Function multiversioning or the fancy target_clones attribute isn't used And by implementing the latter two, the set can shrink. So, really, how much space are we really talking about here? FW> Currently, there is no dynamic loader FW> support for selecting an AVX2 baseline. Fixing this requires FW> complete agreement among all involved parties what the actual CPU FW> requirements are (currently, not even glibc and GCC agree what FW> “haswell” means, the closest we have to an AVX2 baseline). But FW> similar fixes are required for any baseline update. I have a hard time believing that solving that would be somehow less preferable than either making Fedora unusable on a whole class of hardware or splitting off a completely new architecture. - J< ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 11:30:45AM -0400, Robbie Harwood wrote: > Pierre-Yves Chibon writes: > > > When you run `fedpkg build` on Rawhide, your package will be built in > > a new koji tag (which will be the default target for Rawhide). The > > package will be picked up from this koji tag, signed and moved onto a > > second tag. Bodhi will be notified by koji once this new build is > > signed and will automatically create an update for it (you will be > > notified about this by email by bodhi directly) with a “Testing” > > status. If the package maintainer has not opted in into the CI > > workflow, the update will be pushed to “Stable” and the build will be > > pushed into the regular Rawhide tag, making it available in the > > Rawhide buildroot, just as it is today. > > Hi, how will we programatically check what state the tests are in? For > instance, `fedpkg build` (`koji watch-task`) waits until builds are > complete - what do we do to wait until tests are complete (and check the > result)? So we don't have an easy way to do this. I have a script that monitors the entire pipeline/workflow in production and in staging. I have been querying datagrepper for messages about the build that I've made to see if/when the tests are done. You can find the code in: https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b863786e3c610656fb4a6/f/monitor_gating.py#_284 called in: https://pagure.io/fedora-ci/monitor-gating/blob/97bc5b619032cfd3218b863786e3c610656fb4a6/f/monitor_gating.py#_460 I've added an entry in the FAQ for this: https://pagure.io/cpe/rawhide-gating-docs/pull-request/5 Maybe we could also expend fedpkg to provide some information on this. Best, Pierre 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: Self Introduction: Dee'Kej (looking for sponsor)
- Original Message - > From: "David Kašpar" > To: devel@lists.fedoraproject.org > Sent: Thursday, July 18, 2019 5:23:22 PM > Subject: Self Introduction: Dee'Kej (looking for sponsor) > > Hello, > > my name is David Kaspar (a.k.a. Dee'Kej), and I used to be a package > maintainer as a Red Hat employee for 3.5 years. Now that I'm no longer part > of Red Hat I can't use my old Red Hat associated accounts to help with the > work on Fedora... > > Therefore I have restored my old 'deekej' FAS account, and I'm currently > looking for a sponsorship for packagers group here, because right now I > don't have any new package I would like to add into Fedora (to set a blocker > to FE-NEEDSPONSOR BZ). I hope my previous contributions & experience will be > enough for someone to grant it. :) > > I used to maintain these packages: > * initscripts > * ghostscript (+ libijs, urw-base35-fonts, ...) > * gawk > * tcsh > > With kind regards, > > Dee'Kej > Hello again! So what's your plan? :) - Interested in Ruby packaging[0]? Greetings, Pavel [0] https://fedoraproject.org/wiki/SIGs/Ruby ___ 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: Rolling out Phase I of rawhide package gating
Pierre-Yves Chibon writes: > When you run `fedpkg build` on Rawhide, your package will be built in > a new koji tag (which will be the default target for Rawhide). The > package will be picked up from this koji tag, signed and moved onto a > second tag. Bodhi will be notified by koji once this new build is > signed and will automatically create an update for it (you will be > notified about this by email by bodhi directly) with a “Testing” > status. If the package maintainer has not opted in into the CI > workflow, the update will be pushed to “Stable” and the build will be > pushed into the regular Rawhide tag, making it available in the > Rawhide buildroot, just as it is today. Hi, how will we programatically check what state the tests are in? For instance, `fedpkg build` (`koji watch-task`) waits until builds are complete - what do we do to wait until tests are complete (and check the result)? Thanks, --Robbie 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: Rolling out Phase I of rawhide package gating
On Wed, 24 Jul 2019 at 11:09, Tomasz Torcz wrote: > On Wed, Jul 24, 2019 at 03:36:35PM +0200, Miro Hrončok wrote: > > On 24. 07. 19 14:32, Josh Boyer wrote: > > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok > wrote: > > > > > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > > > That said, having to go round adding a mega ugly config file > > > > > to every package that looks an awful lot like an internal braindump > > > > > from some system doesn't really inspire confidence, or make for an > > > > > easy way of opting in. > > > > > > > > This. The gating.yaml file is terrible. > > > > > > Do either of you have a better suggestion? > > > > This looks quite better: > > https://pagure.io/fedora-ci/general/issue/52#comment-584489 > > Pagure.io is not reachable since few days (traceroute end at > 2605:bc80:f03:4::2 corv-car1-gw.nero.net) so it a bit hard > to discuss this proposal. > > > Check to see if you have a hard coded /etc/hosts entry for pagure.io or a DNS cache which isn't timing things out. That is an old IP address from a move previously announced. The DNS entries should be [smooge@smoogen-laptop ~]$ host pagure.io pagure.io has address 8.43.85.75 pagure.io has IPv6 address 2620:52:3:1:dead:beef:cafe:fed5 pagure.io mail is handled by 10 pagure.io. [smooge@smoogen-laptop ~]$ host stg.pagure.io stg.pagure.io has address 8.43.85.77 stg.pagure.io has IPv6 address 2620:52:3:1:dead:beef:cafe:fed3 stg.pagure.io mail is handled by 10 stg.pagure.io. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 04:42:11PM +0200, Miro Hrončok wrote: > On 23. 07. 19 22:51, Pierre-Yves Chibon wrote: > > How do I enroll? > > Great! We’re glad to see such enthusiasm! You can find the instruction in > > the > > docs on how to enable gating:https://docs.fedoraproject.org/en-US/ci/gating/ > > Assuming I want to gate openssl for python_selftest from here: > > https://src.fedoraproject.org/rpms/openssl/blob/master/f/tests/tests_python.yml > > What would be the test_case_name? > > org.centos.prod.ci.pipeline.allpackages-build.package.test_python.python_selftest > ? No the pipeline doesn't send a message per test, it will run all the tests and return a global pass|fail. So you'll want to gate on org.centos.prod.ci.pipeline.allpackages-build.complete or org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete as in the example (the first one is the very last message send by the pipeline, the second one is when it finished the step of running the tests). Best, Pierre ___ 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: Rolling out Phase I of rawhide package gating
On 7/24/19 7:22 AM, Tomasz Torcz wrote: > On Wed, Jul 24, 2019 at 03:36:35PM +0200, Miro Hrončok wrote: >> On 24. 07. 19 14:32, Josh Boyer wrote: >>> On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: On 24. 07. 19 10:24, Tom Hughes wrote: > That said, having to go round adding a mega ugly config file > to every package that looks an awful lot like an internal braindump > from some system doesn't really inspire confidence, or make for an > easy way of opting in. This. The gating.yaml file is terrible. >>> >>> Do either of you have a better suggestion? >> >> This looks quite better: >> https://pagure.io/fedora-ci/general/issue/52#comment-584489 > > Pagure.io is not reachable since few days (traceroute end at > 2605:bc80:f03:4::2 corv-car1-gw.nero.net) so it a bit hard > to discuss this proposal. This is likely going to the old ip for pagure.io (we moved it a week or so ago). Please check that your dns is updating and that you do not have a /etc/hosts entry or the like? Otherwise, happy to help debug more off list. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On 23. 07. 19 22:51, Pierre-Yves Chibon wrote: How do I enroll? Great! We’re glad to see such enthusiasm! You can find the instruction in the docs on how to enable gating:https://docs.fedoraproject.org/en-US/ci/gating/ Assuming I want to gate openssl for python_selftest from here: https://src.fedoraproject.org/rpms/openssl/blob/master/f/tests/tests_python.yml What would be the test_case_name? org.centos.prod.ci.pipeline.allpackages-build.package.test_python.python_selftest ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 04:22:01PM +0200, Tomasz Torcz wrote: > On Wed, Jul 24, 2019 at 03:36:35PM +0200, Miro Hrončok wrote: > > On 24. 07. 19 14:32, Josh Boyer wrote: > > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > > > > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > > > That said, having to go round adding a mega ugly config file > > > > > to every package that looks an awful lot like an internal braindump > > > > > from some system doesn't really inspire confidence, or make for an > > > > > easy way of opting in. > > > > > > > > This. The gating.yaml file is terrible. > > > > > > Do either of you have a better suggestion? > > > > This looks quite better: > > https://pagure.io/fedora-ci/general/issue/52#comment-584489 > > Pagure.io is not reachable since few days (traceroute end at > 2605:bc80:f03:4::2 corv-car1-gw.nero.net) so it a bit hard > to discuss this proposal. You may want to email admin@fp.o since you can't open a ticket on the infra tracker. We should be able to figure things out with you. Note: there has been reports of IPv6 issues in a specific office/network. Does it work better if you enable IPv4 only? Best, Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 04:18:25PM +0200, Kamil Paral wrote: >On Wed, Jul 24, 2019 at 2:33 PM Josh Boyer <[1]jwbo...@fedoraproject.org> >wrote: > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok <[2]mhron...@redhat.com> > wrote: > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > That said, having to go round adding a mega ugly config file > > > to every package that looks an awful lot like an internal braindump > > > from some system doesn't really inspire confidence, or make for an > > > easy way of opting in. > > > > This. The gating.yaml file is terrible. > > Do either of you have a better suggestion? > >If most people would have the same default yaml file copy-pasted into a >thousand places, it could be easily replaced with just: >``` >gating: default >``` >And allow people to override the default policy (with the current syntax >or hopefully something more readable) only when they really have some >specific needs. This will also help in future when the defaults need to be >changed. >More preset values can be defined subsequently, e.g.: >gating: default/minimal/custom/disabled >etc. This is an interesting idea, I've opened a ticket on greenwave to track it: https://pagure.io/greenwave/issue/466 We already have global (ie: distro-wide) policies that we can enforce, so they would be your "default", but your mechanism still allows for opt-in/opt-out which the distro-wide policies do not. Thanks for the idea :) Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 03:17:41PM +0100, Tom Hughes wrote: > On 24/07/2019 14:51, Pierre-Yves Chibon wrote: > > On Wed, Jul 24, 2019 at 02:13:02PM +0100, Tom Hughes wrote: > > > > Then there's decision_context which apparently does nothing > > > but has to be there. > > > > It is used! It is what define which tests are used to gate the build/update > > when > > entering the -testing repo vs which ones are used to gate entering the > > -stable > > repo. > > Sorry... I can't find it now but I was sure when I was reading > last night I came across a ticket where somebody claimed that it > didn't actually do anything. To be complete, in the context of rawhide, only the -stable one is needed, but for stable branches, both are. Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 03:36:35PM +0200, Miro Hrončok wrote: > On 24. 07. 19 14:32, Josh Boyer wrote: > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > > That said, having to go round adding a mega ugly config file > > > > to every package that looks an awful lot like an internal braindump > > > > from some system doesn't really inspire confidence, or make for an > > > > easy way of opting in. > > > > > > This. The gating.yaml file is terrible. > > > > Do either of you have a better suggestion? > > This looks quite better: > https://pagure.io/fedora-ci/general/issue/52#comment-584489 Pagure.io is not reachable since few days (traceroute end at 2605:bc80:f03:4::2 corv-car1-gw.nero.net) so it a bit hard to discuss this proposal. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 2:33 PM Josh Boyer wrote: > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > That said, having to go round adding a mega ugly config file > > > to every package that looks an awful lot like an internal braindump > > > from some system doesn't really inspire confidence, or make for an > > > easy way of opting in. > > > > This. The gating.yaml file is terrible. > > Do either of you have a better suggestion? > If most people would have the same default yaml file copy-pasted into a thousand places, it could be easily replaced with just: ``` gating: default ``` And allow people to override the default policy (with the current syntax or hopefully something more readable) only when they really have some specific needs. This will also help in future when the defaults need to be changed. More preset values can be defined subsequently, e.g.: gating: default/minimal/custom/disabled etc. ___ 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: Rolling out Phase I of rawhide package gating
On 24/07/2019 14:51, Pierre-Yves Chibon wrote: On Wed, Jul 24, 2019 at 02:13:02PM +0100, Tom Hughes wrote: Then there's decision_context which apparently does nothing but has to be there. It is used! It is what define which tests are used to gate the build/update when entering the -testing repo vs which ones are used to gate entering the -stable repo. Sorry... I can't find it now but I was sure when I was reading last night I came across a ticket where somebody claimed that it didn't actually do anything. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 9:57 AM Tom Hughes wrote: > > On 24/07/2019 13:32, Josh Boyer wrote: > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > >> > >> On 24. 07. 19 10:24, Tom Hughes wrote: > >>> That said, having to go round adding a mega ugly config file > >>> to every package that looks an awful lot like an internal braindump > >>> from some system doesn't really inspire confidence, or make for an > >>> easy way of opting in. > >> > >> This. The gating.yaml file is terrible. > > > > Do either of you have a better suggestion? > > Well more ordinary YAML would be a good start. > > I mean I literally had to go and try and read the YAML spec > to try and work out what it was doing and let me tell you, for > something that I had always thought was a simple format it has > a very long and hard to read spec... > > So a single document would be good, and get rid of the tags > which I assume are the result of serialising objects with > those name. > > The very.long.reverse.domain.test.names are not ideal. > > Then there's decision_context which apparently does nothing > but has to be there. > > Is there any rule type other than PassingTestCaseRule? > > If not then what's wrong with: > > --- > rules: >fedora-*: >- dist.abicheck >- dist.rpmlint >fedora-30: >- my.special.text > > or something equally simple, which just a list of tests > to require for each version. > I'd like to second that simpler hierarchy, but I'd say switching to TOML would make it considerably more simple to understand and imposes limits on the format so that it can't get wildly complicated. gating.toml: [[rules]] [[rules.fedora]] dist.abicheck = true dist.rpmlint = true [[rules.fedora.30]] my.special.test = true [[rules.epel]] dist.abirestrict = true [[rules.epel.8]] dist.modularcheck = true [[tests]] my.special.test = ["/path/to/test", arg1, arg2] Under no circumstances should the driving system for checks be too complex for people to grok. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Heads up] Fedora Container base image is getting smaller
On Wed, Jul 24, 2019 at 07:09:24AM +0200, Clement Verna wrote: > Last couple days a bigger change [2] have been introduced in the > fedora:rawhide image. This change drops all the weak dependencies from > the base image which allowed us to have a smaller base image (215MB). This makes me happy. Is that compressed (transfer) size or size on disk? What are the biggest things remaining? I'd love to get it into double-digits. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 02:13:02PM +0100, Tom Hughes wrote: > On 24/07/2019 13:32, Josh Boyer wrote: > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > > That said, having to go round adding a mega ugly config file > > > > to every package that looks an awful lot like an internal braindump > > > > from some system doesn't really inspire confidence, or make for an > > > > easy way of opting in. > > > > > > This. The gating.yaml file is terrible. > > > > Do either of you have a better suggestion? > > Well more ordinary YAML would be a good start. > > I mean I literally had to go and try and read the YAML spec > to try and work out what it was doing and let me tell you, for > something that I had always thought was a simple format it has > a very long and hard to read spec... > > So a single document would be good, and get rid of the tags > which I assume are the result of serialising objects with > those name. > > The very.long.reverse.domain.test.names are not ideal. Agreed, we could look for better ones. > Then there's decision_context which apparently does nothing > but has to be there. It is used! It is what define which tests are used to gate the build/update when entering the -testing repo vs which ones are used to gate entering the -stable repo. > Is there any rule type other than PassingTestCaseRule? There actually are others: https://docs.pagure.org/greenwave/policies.html There is the one that is used to pull policies from remote locations (which is what is used to allow package-specific rules) and we had another one in the past to allow, globally, certain rules to apply only to some packages. That being said, maybe there would be a way to simplify the syntax for remote policies, so I've opened a ticket to greenwave to see what they think about it and if it is doable: https://pagure.io/greenwave/issue/465 Thanks for your feedback :) Pierre ___ 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 31 System-Wide Change proposal: Boost 1.70 upgrade
On Tue, Jul 2, 2019 at 10:02 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/F31Boost170 > > == Summary == > This change brings Boost 1.70 to Fedora. This will mean Fedora ships > with a recent upstream Boost release. > This change, previously approved by FESCo, has been withdrawn by the change owner. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On 24. 07. 19 14:32, Josh Boyer wrote: On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: On 24. 07. 19 10:24, Tom Hughes wrote: That said, having to go round adding a mega ugly config file to every package that looks an awful lot like an internal braindump from some system doesn't really inspire confidence, or make for an easy way of opting in. This. The gating.yaml file is terrible. Do either of you have a better suggestion? This looks quite better: https://pagure.io/fedora-ci/general/issue/52#comment-584489 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, Jul 24, 2019 at 07:07:27AM -0400, Stephen Gallagher wrote: > On Wed, Jul 24, 2019 at 5:29 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote: > > > We currently offer Workstation, Minimal and Server images for use with > > > AArch64 Single Board Computer's (SBC's). We would like to add a > > > lighter weight desktop image for hardware that lacks the ability to > > > run accelerated desktops. > > > > Are people using gnome-shell on arm64 machines? Would it make sense to > > simply switch Workstation default to xfce on arm64? > > Workstation isn't just the "default desktop". It's a curated > experience that GNOME is a key part of. > > I assume that what they're looking for here is aarch64 media for the XFCE > Spin. Ah, OK. That's a much clearer description. Maybe we could change the Change summary to this? (We already have Fedora Minimal spin for arm64, so the path for arm64 spins is already trodden.) Zbyszek ___ 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 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
Kamil Paral píše v St 24. 07. 2019 v 13:37 +0200: > On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton > wrote: > > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > > > The Manual Partitioning screen supports all actions of the Resize > > Disk > > Space dialog, so it doesn't make sense to have two user interfaces > > with the same functionality. > > The manual partitioning screen is also much more complex and > therefore more difficult to use. For the common use case of > installing Fedora alongside Windows (where you need to shrink the > Windows partition), the simple dialog is/was great. Linux novice > users might not be able to accomplish that in the manual partitioning > screen. > > Just my personal opinion, I'm not trying to convince you to revert > your plan. I second Kamil here. I've introduced hundreds of people to Fedora and "I've got Windows on the disk and need to reclaim space" is by far the most common scenario among Fedora novices and instead of giving them a simple dialog we're sending them to the manual setup which I as a Linux user for 15 years have problems to get oriented in. Is it really such engineering overhead to keep that dialog there? Jiri ___ 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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, 24 Jul 2019 09:28:12 +, you wrote: >On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote: >> We currently offer Workstation, Minimal and Server images for use with >> AArch64 Single Board Computer's (SBC's). We would like to add a >> lighter weight desktop image for hardware that lacks the ability to >> run accelerated desktops. > >Are people using gnome-shell on arm64 machines? Would it make sense to >simply switch Workstation default to xfce on arm64? There are finally better ARM boards coming out with more memory (the new Pi 4 has a 4GB option) so going forward Gnome or KDE should become more viable for at least some of these boards. So an alternative to Workstation for the lower specification boards would seem a better option in addition to the other mentioned issue of what Workstation actually means in a Fedora context. ___ 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: Rolling out Phase I of rawhide package gating
On 24/07/2019 13:32, Josh Boyer wrote: On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: On 24. 07. 19 10:24, Tom Hughes wrote: That said, having to go round adding a mega ugly config file to every package that looks an awful lot like an internal braindump from some system doesn't really inspire confidence, or make for an easy way of opting in. This. The gating.yaml file is terrible. Do either of you have a better suggestion? Well more ordinary YAML would be a good start. I mean I literally had to go and try and read the YAML spec to try and work out what it was doing and let me tell you, for something that I had always thought was a simple format it has a very long and hard to read spec... So a single document would be good, and get rid of the tags which I assume are the result of serialising objects with those name. The very.long.reverse.domain.test.names are not ideal. Then there's decision_context which apparently does nothing but has to be there. Is there any rule type other than PassingTestCaseRule? If not then what's wrong with: --- rules: fedora-*: - dist.abicheck - dist.rpmlint fedora-30: - my.special.text or something equally simple, which just a list of tests to require for each version. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: ownership of /proc and /sys
On Mi, 24.07.19 13:24, Jun Aruga (jar...@redhat.com) wrote: > Sorry I posted my previous email wrongly. > > > > I have bunch of ideas, but all of them ugly (e.g., not own that file and > > > create that directories in scriptlet). Do you > > > have any ideas about this situation? > > > > Make systemd create them? It has to manage them anyway. > > I see this situation to think about the ownership of /proc happens > when qemu-user-static RPM creates new > /proc/sys/fs/binfmt_misc/qemu-$cpu files by "dnf install > qemu-user-static" through running systemd. [1] > Who is the owner of the /proc/sys/fs/binfmt_misc/qemu-$cpu files? > The possible solution I am considering is "(e.g., not own that file > and create that directories in scriptlet)". These directories are runtime objects, i.e. kernel API exposed as a file system. RPM should not own files below /proc. Something should own/create /proc itself, since it needs to exist to be overmounted with procfs, but beyond that stuff below /proc should be off limits for any package manager I figure. Lennart -- Lennart Poettering, Berlin ___ 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: [Fontconfig] [RFC] target font model on Freedesktop systems
Le 2019-07-24 13:49, Akira TAGOH a écrit : Hi Akira On Tue, Jul 23, 2019 at 10:45 PM Nicolas Mailhot wrote: No foo variable, foo hebrew, foo narrow, foo caption, just a single foo with different available features (full variability or fixed states on the default axis, real upstream provided states or fakes generated by fontconfig at pango’s request[5], etc) Such family name issue should be more likely a font issue. it could be worked around but there are a lot of patterns to drop such things heuristically and that may be huge costs to be automated; well, that may depends what the level of support you expect on it. Having something more or less would be useful though, I hope some moves happens in fonts side for that too. I've given up on font creators cleaning up their mess. Microsoft and Adobe have been trying for a decade to get them to adopt common conventions, and they continue not fixing old projects, and diverging randomly on new projects. Each font tooling author and each font creator thinks he knows best. If we agree that this OpenType theorical definition is our target to enable freedesktop apps to do interesting text things, the logical consequence is to perform naming fixing at the fontconfig level (and make sure text libs like Pango do not re-expose accidentally the upstream broken naming to apps). Fixing at the fontconfig level means lots of naming heuristics (that you've started working on thank you very much). But, an heuristic is not a 100% solution by definition. So we’ll also need you help to define the fontconfig grammar, to tell fontconfig things, it can not guess alone. This is also linked to Peng Wu’s request for an API to tell fontconfig what faces to fake using variable font axis. Because: – such faking needs to persist on disk to be convenient — the persisting needs to be done fontconfig-side, otherwise the faked faces are not shared with apps that do not use pango — the next logical step is to preset convenient faked faces directly in the font package, so you don't need to redo-them in a GUI on all the computers one uses So what Peng Wu sees as a fontconfig API need, I see as a fontconfig config file need. Also, once variable fonts become more common, I'm sure everyone will get sick of faking the same font faces in all variable fonts, so someone is bound to ask for a generic fontconfig heuristic, that takes available axes, and auto-segment them at useful points (probably, using all the segmentation levels defined by Microsoft in the WWS whitepaper) That’s why I’m requesting a formal agreement on the target. Lots of things become evident and easy to plan once the exit point is known. And, it will probably take years to get there (getting everyone on harfbuzz was defined as a target in the 2006 text summit IIRC, we’re finishing it now) but at least we’ll be all pushing in the same direction. 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] target font model on Freedesktop systems
Nicolas Mailhot wrote: > 2. fontconfig strives to hide all the legacy ways to designate different > parts of this ideal font, and strives to expose a single "font" objet no > matter what quirks exist in individual font files. We stop exposing lots > of weird quirky bits right and left, that need manual assembling by > users, or glue-ing with TEX macros. > > No foo variable, foo hebrew, foo narrow, foo caption, just a single foo > with different available features (full variability or fixed states on > the default axis, real upstream provided states or fakes generated by > fontconfig at pango’s request[5], etc) While such a model sounds really nice in theory, especially if missing variants can be synthesized (e.g., automatic slanting to provide italic versions where no native one is available), I am worried about some of the practical implications: * There is no longer a way to filter only for native high-quality variants, excluding synthesized ones. Or in particular, to just request a bold, thin, wide, narrow, or italic version of a font without caring about (e.g.) how thick the bold version actually is, but preferring a native variant over a synthesized one with some arbitrary thickness. * The native variant may only support a subset of the characters of the base font. See, e.g., Liberation Sans Narrow, which is stuck at an older version because it is not part of the upstream "code" drop used as the basis for the new version. With your approach, there is also no way to explicitly force the use of the synthesized version. Will fontconfig or a higher level be smart enough to synthesize from the base font characters missing in the native variant but available in the base font? * How will fontconfig decide which of the versions to pick as the base? If, e.g., there is a Foo with 100% width and a Foo Narrow with 50% width, which one would be picked for, say, Foo 71%? (Note that 71% is between the geometric mean and the arithmetic mean of 100% and 50%.) Or, say, you have a Foo with 100% width and a Foo Narrow with 80% width, and the user requests Foo 160%, would the integer factor 2 from 80% to 160% potentially lead to a better scaling? Or, say, the font provides only Foo Bold and Foo Italic, and the user requests Foo Bold Italic, do you bolden Foo Italic or slant Foo Bold, or even bolden and slant Foo Regular? * I see you mentioning pango. What will happen for applications not using pango? Qt applications come to my mind, obviously, but also applications using neither GTK+ nor Qt (which include popular ones where fonts are crucial, such as LibreOffice, where GTK+ and Qt support are only in optional plugins). * The font selectors also need to support all those settings. If an application shows some legacy font selector that does not support them, the user is stuck with no way to use the variants, whereas the current approach of abusing the family name with suffixes does the job. E.g., Liberation Sans Narrow would just vanish from legacy applications with no way for the user to select it. So, to sum it up, I kinda like the idea, but I am very worried about functionality regressions popping up in practice. Kevin Kofler ___ 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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, Jul 24, 2019 at 11:24 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote: > > We currently offer Workstation, Minimal and Server images for use with > > AArch64 Single Board Computer's (SBC's). We would like to add a > > lighter weight desktop image for hardware that lacks the ability to > > run accelerated desktops. > > Are people using gnome-shell on arm64 machines? Would it make sense to > simply switch Workstation default to xfce on arm64? We're already creating images for Workstation on aarch64, I am a little late, but am planning on a similar Workstation change I'm just finishing the write up on. In general there's usecases where a low resource desktop is useful, such on devices with only 1Gb of RAM where Workstation doesn't provide a good experience. Peter > > An initial set of supported devices: > > * Pine64 > > * Raspberry Pi 3/4 > > * 96boards HiKey > > * 96boards Dragonboard 410c > > > > == Benefit to Fedora == > > Better user experience and an additional desktop choice for AArch64 SBC's. > > > > == Scope == > > * Proposal owners: The ARM SIG will make the kickstart changes needed > > to add the desktop images to the compose. > > * Other developers: N/A > > * Release engineering: Enable building of the AArch64 XFCE desktop > > image. Small tweaks may be required to the pungi configs or fedora > > kickstarts but those will be completed by the SIG and sent as pull > > requests. Issue[https://pagure.io/releng/issue/8556 #8556] > > * Policies and guidelines: N/A (not needed for this Change) > > * Trademark approval: N/A (not needed for this Change) > > > > == Upgrade/compatibility impact == > > No upgrade compatibility required, this is a new image variant. > > > > == How To Test == > > Testing can be completed on any supported AArch64 SBC using the > > existing arm-image-installer. Any additional instructions will be > > added to the ARM installation documentation. > > > > == User Experience == > > Users will have increased choice in desktop offerings for AArch64 > > SBC's. Those looking to install a desktop on hardware that lacks an > > accelerated graphics driver or lower system specifications will have a > > useable option. > > > > == Dependencies == > > > > N/A (not a System Wide Change) > > > > == Contingency Plan == > > > > * Contingency mechanism: N/A > > * Contingency deadline: N/A > > * Blocks release? No > > * Blocks product? No > > > > == Documentation == > > All documentation will be added or updated via the ARM Landing Page. > > > > -- > > Ben Cotton > > He / Him / His > > Fedora Program Manager > > Red Hat > > TZ=America/Indiana/Indianapolis > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > On 24. 07. 19 10:24, Tom Hughes wrote: > > That said, having to go round adding a mega ugly config file > > to every package that looks an awful lot like an internal braindump > > from some system doesn't really inspire confidence, or make for an > > easy way of opting in. > > This. The gating.yaml file is terrible. Do either of you have a better suggestion? josh ___ 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
Fedora-Rawhide-20190724.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 45 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all Failed openQA tests: 13/147 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190723.n.0): ID: 425894 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/425894 ID: 425895 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/425895 ID: 425898 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/425898 ID: 425931 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/425931 ID: 426015 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/426015 ID: 426023 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/426023 Old failures (same test failed in Fedora-Rawhide-20190723.n.0): ID: 425890 Test: x86_64 Server-dvd-iso mediakit_repoclosure URL: https://openqa.fedoraproject.org/tests/425890 ID: 425896 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/425896 ID: 425945 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/425945 ID: 425981 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/425981 ID: 426012 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/426012 ID: 426020 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/426020 ID: 426021 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/426021 ID: 426024 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/426024 Soft failed openQA tests: 3/147 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20190723.n.0): ID: 425903 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/425903 Old soft failures (same test soft failed in Fedora-Rawhide-20190723.n.0): ID: 425921 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/425921 ID: 426016 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/426016 Passed openQA tests: 121/147 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190723.n.0): ID: 425974 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/425974 ID: 425987 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/425987 ID: 426002 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/426002 Skipped gating openQA tests: 4/147 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20190723.n.0): ID: 425937 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/425937 ID: 425938 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/425938 ID: 425940 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/425940 ID: 425941 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/425941 Skipped non-gating openQA tests: 7 of 149 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: Used mem changed from 176 MiB to 198 MiB Previous test data: https://openqa.fedoraproject.org/tests/425722#downloads Current test data: https://openqa.fedoraproject.org/tests/425881#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: Used mem changed from 176 MiB to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/425723#downloads Current test data: https://openqa.fedoraproject.org/tests/425882#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 21 MiB to 29 MiB 1 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freed
Re: [RFC] target font model on Freedesktop systems
On Tuesday, 23 July 2019 at 15:45, Nicolas Mailhot via devel wrote: > Hi, > > Now that things are starting to move fonts-side[1], I’d like the various > actors to agree on a common font model target. [...] > Therefore, I’d like to propose that the target font model on freedesktop > systems, is the functional unit defined in variable fonts[2]: [...] > Is this something we can agree on? I am no font expert, but the above sounds reasonable to me. I maintain just one font package, though. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
Fedora rawhide compose report: 20190724.n.0 changes
OLD: Fedora-Rawhide-20190723.n.0 NEW: Fedora-Rawhide-20190724.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 5 Dropped packages:28 Upgraded packages: 101 Downgraded packages: 0 Size of added packages: 1.43 MiB Size of dropped packages:50.98 MiB Size of upgraded packages: 10.36 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -72.64 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: disomaster-0.2.0-1.fc31 Summary: Library to manipulate DISC burning RPMs:disomaster disomaster-devel Size:308.39 KiB Package: kafs-client-0.3-1.fc31 Summary: The basic tools for kAFS and mounter for the AFS dynamic root RPMs:kafs-client kafs-client-compat kafs-client-libs kafs-client-libs-devel Size:578.91 KiB Package: lua-psl-0.3-2.fc31 Summary: Lua bindings to Public Suffix List library RPMs:lua-psl lua5.1-psl Size:171.72 KiB Package: python-pytest-sugar-0.9.2-1.fc31 Summary: Change the default look and feel of pytest RPMs:python3-pytest-sugar Size:23.10 KiB Package: python2-pytest-4.4.1-3.fc31 Summary: Simple powerful testing with Python 2 RPMs:python2-pytest Size:382.50 KiB = DROPPED PACKAGES = Package: aesh-0.66.8-7.fc30 Summary: Another Extendable SHell RPMs:aesh aesh-javadoc Size:766.32 KiB Package: cookcc-0.3.3-16.fc27 Summary: Lexer and Parser Generator RPMs:cookcc cookcc-javadoc Size:347.50 KiB Package: fedocal-0.16-3.fc31 Summary: A web based calendar application RPMs:fedocal Size:361.07 KiB Package: golang-github-BurntSushi-toml-test-0.2.0-0.15.git85f50d0.fc30 Summary: Language agnostic test suite for TOML RPMs:golang-github-BurntSushi-toml-test Size:6.27 MiB Package: golang-github-asn1-ber-1.3-2.fc31 Summary: ASN1 BER Encoding / Decoding Library for the Go programming language RPMs:golang-github-asn1-ber-devel Size:22.02 KiB Package: golang-github-fatih-pool-0-0.13.20180609gitcba550e.fc30 Summary: Connection pool for Go's net.Conn interface RPMs:golang-github-fatih-pool-devel Size:14.93 KiB Package: golang-github-go-tomb-tomb-0-16.20181031gitd5d1b58.fc30 Summary: The tomb package helps with clean goroutine termination in the Go language RPMs:golang-github-go-tomb-tomb-devel golang-github-go-tomb-tomb-devel-v2 Size:32.39 KiB Package: golang-github-influxdb-influxdb-0.9.5.1-0.9.git9eab563.fc30 Summary: Scalable datastore for metrics, events, and real-time analytics RPMs:golang-github-influxdb-influxdb-client golang-github-influxdb-influxdb-devel golang-github-influxdb-influxdb-unit-test Size:1.68 MiB Package: golang-github-macaron-v1-1.3.2-1.fc31 Summary: Productive and modular web framework in Go RPMs:golang-github-macaron-v1-devel golang-gopkg-1-macaron-devel golang-gopkg-macaron-1-devel Size:134.77 KiB Package: golang-github-neurosnap-sentences-1.0.6-5.fc30 Summary: Multilingual command line sentence tokenizer in Golang RPMs:golang-github-neurosnap-sentences golang-github-neurosnap-sentences-devel golang-github-neurosnap-sentences-unit-test-devel Size:8.53 MiB Package: golang-github-redis-v2-2.3.2-1.fc31 Summary: Redis client for Go RPMs:golang-github-redis-v2-devel Size:35.55 KiB Package: golang-googlecode-log4go-0-0.13.hgc3294304d93f.fc31 Summary: Logging package similar to log4j for the Go programming language RPMs:golang-googlecode-log4go-devel golang-googlecode-log4go-unit-test Size:104.37 KiB Package: golang-googlecode-net-0-0.50.20190302git16b79f2.fc31 Summary: Supplementary Go networking libraries RPMs:golang-golang-org-net-devel Size:3.88 MiB Package: golang-googlecode-uuid-0-0.17.gitb984ec7.fc30 Summary: Generates and inspects UUIDs based on RFC 4122 and DCE 1.1 RPMs:golang-github-pborman-uuid-unit-test golang-googlecode-uuid-devel Size:100.02 KiB Package: hibernate-hql-1.3.0-0.2.Alpha2.fc26 Summary: Hibernate Query Parser RPMs:hibernate-hql hibernate-hql-javadoc Size:1.27 MiB Package: hibernate-search-5.5.4-2.fc26 Summary: Hibernate Search RPMs:hibernate-search hibernate-search-javadoc Size:2.36 MiB Package: jacorb-2.3.2-3.jbossorg.5.fc27 Summary: The Java implementation of the OMG's CORBA standard RPMs:jacorb jacorb-javadoc Size:11.11 MiB Package: jboss-dmr-1.3.0-3.fc27 Summary: JBoss DMR RPMs:jboss-dmr jboss-dmr-javadoc Size:149.63 KiB Package: jboss-jaxb-intros-1.0.2-10.fc24 Summary: JBoss JAXB Intros RPMs:jboss-jaxb-intros jboss-jaxb-intros-javadoc Size:90.18 KiB Package: jboss-web-native-2.0.10-9.fc24 Summary: JBoss Web Native RPMs:jboss-web-native jboss-web-native-devel Size:652.32 KiB Package: libemu-0.2.0-10.20130410gitab48695.fc30.1 Summary: The x86 shell-code detection and emulation RPMs:libemu libemu-devel python2-libemu Size:1.91 MiB Package: narayana-5.3.3-4.fc
Re: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > The Manual Partitioning screen supports all actions of the Resize Disk > Space dialog, so it doesn't make sense to have two user interfaces > with the same functionality. > The manual partitioning screen is also much more complex and therefore more difficult to use. For the common use case of installing Fedora alongside Windows (where you need to shrink the Windows partition), the simple dialog is/was great. Linux novice users might not be able to accomplish that in the manual partitioning screen. Just my personal opinion, I'm not trying to convince you to revert your plan. ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
On Wed, Jul 24, 2019 at 1:07 PM Florian Weimer wrote:
>
> * Stephen Gallagher:
>
> > With my FESCo hat on, I can't support this action as currently stated.
> > I think I'd be more inclined to consider it if the Change was proposed
> > as a new architecture bring-up. Effectively, this would be a whole new
> > architecture that would just happen to be largely compatible with
> > x86_64.
>
> Can we make this happen at the RPM level? So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)? I do not see many explicit dependencies on
> anything “x86_64” in Fedora 30, so perhaps this is doable, assuming that
> packages of the other architecture would continue to provide …(…)(64bit)
> for soname dependencies.
This depends on RPM and libsolv "archpolicy". So yes, as long as
dependencies do not change, it is fine. We need to keep %{?_isa} to
provide x86_64.
> Could we rebuild x86_64 Fedora with a different dist tag and different
> compiler flags, and release that as a new spin? And retain the x86_64
> for that architecture?
Yes, that was my proposal.
> Regarding doing something like the old i686 packages when we had an i586
> baseline (or the ppc64p7 work that was perhaps never upstreamed to
> Fedora), I'm a bit worried about increasing the complexity of composes.
> We already see upgrade issues doe to i686 packages come and go, and that
> could potentially multiply them. The advantage is that packaging
> changes themselves will be relatively minor, once we have agreemeent
> which packages should do this.
>
> ELF multilib DSOs inside RPMs result in code deduplication, affecting
> container image size. Packaging changes are *not* minor for this
> approach. It can be tricky to ensure full testing coverage if both DSOs
> are installed. Currently, there is no dynamic loader support for
> selecting an AVX2 baseline. Fixing this requires complete agreement
> among all involved parties what the actual CPU requirements are
> (currently, not even glibc and GCC agree what “haswell” means, the
> closest we have to an AVX2 baseline). But similar fixes are required
> for any baseline update.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ownership of /proc and /sys
Sorry I posted my previous email wrongly. > > I have bunch of ideas, but all of them ugly (e.g., not own that file and > > create that directories in scriptlet). Do you > > have any ideas about this situation? > > Make systemd create them? It has to manage them anyway. I see this situation to think about the ownership of /proc happens when qemu-user-static RPM creates new /proc/sys/fs/binfmt_misc/qemu-$cpu files by "dnf install qemu-user-static" through running systemd. [1] Who is the owner of the /proc/sys/fs/binfmt_misc/qemu-$cpu files? The possible solution I am considering is "(e.g., not own that file and create that directories in scriptlet)". [1] https://bugzilla.redhat.com/show_bug.cgi?id=1732178 -- Jun Aruga | He - His - Him ___ 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: Rolling out Phase I of rawhide package gating
On 24. 07. 19 10:17, Dan Horák wrote: On Tue, 23 Jul 2019 22:51:28 +0200 Pierre-Yves Chibon wrote: Good Morning Everyone, TL;DR: On July 24th we will turn on the first phase of Rawhide package gating, for single build updates. In a later phase, Rawhide updates that contain multiple builds will also be enabled for gating. Our goal is to improve our ability to continuously turn out a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora package maintainers as possible, including maintainers of the base OS. But this phase of gating remains opt-in, and should not affect packagers who choose for now not to opt in. What is your level of confidence about reliability of the whole process? How much baby-sitting from the maintainer will be required (for lost messages, crashed or stuck processes, etc)? How arch specific packages will be handled? I mean how s390x or ppc64le specific packages will be handled if the infra would be ready for x86_64 only? Other architectures are low priority :( https://pagure.io/fedora-ci/general/issue/16 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
On 24. 07. 19 10:24, Tom Hughes wrote: That said, having to go round adding a mega ugly config file to every package that looks an awful lot like an internal braindump from some system doesn't really inspire confidence, or make for an easy way of opting in. This. The gating.yaml file is terrible. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: ownership of /proc and /sys
> I have bunch of ideas, but all of them ugly (e.g., not own that file and > create that directories in scriptlet). Do you > have any ideas about this situation? Make systemd create them? It has to manage them anyway. On Tue, Jul 23, 2019 at 5:30 PM Lennart Poettering wrote: > > On Di, 23.07.19 10:56, Adam Jackson (a...@redhat.com) wrote: > > > On Tue, 2019-07-23 at 11:01 +0200, Miroslav Suchý wrote: > > > Hi, > > > directories /proc/ and /sys/ are owned by filesystem package. This worked > > > in past where we needed those directories to > > > exist so we can mount the procfs and sysfs. > > > > > > However this cause issues in containers: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1548403 > > > and during building where hacks are needed: > > > https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e > > > > > > I have bunch of ideas, but all of them ugly (e.g., not own that file and > > > create that directories in scriptlet). Do you > > > have any ideas about this situation? > > > > Make systemd create them? It has to manage them anyway. > > It does, if they are missing. In fact, it's totally supported to boot > up with an empty / (for example: tmpfs, which is what > systemd.volatile=yes on the kernel cmdline will do) with the one > exception of a populated /usr and systemd will create all the basic > mount points and symlinks needed to make the system boot. > > That said, that only works if / is writable. Which is not a given. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > 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 -- Jun Aruga | He - His - Him jar...@redhat.com / IRC: jaruga ___ 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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Wed, Jul 24, 2019 at 5:29 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote: > > We currently offer Workstation, Minimal and Server images for use with > > AArch64 Single Board Computer's (SBC's). We would like to add a > > lighter weight desktop image for hardware that lacks the ability to > > run accelerated desktops. > > Are people using gnome-shell on arm64 machines? Would it make sense to > simply switch Workstation default to xfce on arm64? Workstation isn't just the "default desktop". It's a curated experience that GNOME is a key part of. I assume that what they're looking for here is aarch64 media for the XFCE Spin. ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 11:41:16AM +0200, Florian Weimer wrote: > * Pierre-Yves Chibon: > > > On Wed, Jul 24, 2019 at 08:29:03AM +0200, Florian Weimer wrote: > >> * Pierre-Yves Chibon: > >> > >> > Good Morning Everyone, > >> > > >> > TL;DR: On July 24th we will turn on the first phase of Rawhide package > >> > gating, > >> > for single build updates. > >> > >> How does this interact with the mass rebuild? > > > > It does not. Mass-rebuild are done in a dedicated side-tags from which > > they are merged directly into the buildroot tag. So they entirely > > by-pass gating (current and future versions of it). > > Thanks for the clarification. So the mass rebuild effectively waives > all previous gating failures. I don't think there's a good choice here, > either approach has its problems. 8-/ > > Maybe in the future, perhaps we should do the mass rebuild, tag it in, > and then re-run all gating tests to see what kind of regressions there > are? I would certainly not vote against this :) And if we get to the point where we can run tests again mass-rebuilds to find regressions across our entire package selection, I think Fedora will be in a good place then :) Pierre ___ 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: portable performance engineering
Florian Weimer wrote: > * Kevin Kofler: >> As I wrote elsewhere in this huge thread: just turn the program into a >> library with a dummy main program. > > That requires manual work, so it's unclear how to do this for large > parts of the distribution. I would not do this for large parts of the distribution, but only for the handful programs where it makes sense. It is surely not worth doubling the distribution's size to have ls run maybe 1% faster on some computers. > And people will worry about PIC-related losses, or due to assumptions > regarding symbol interposition (which affect inter-procedural analysis). > The latter even affects Fedora because PIE does not turn off these > optimizations. Then use -fno-semantic-interposition. Kevin Kofler ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 10:27:35AM +0100, Peter Robinson wrote: > > On Wed, Jul 24, 2019 at 09:14:05AM +0100, Peter Robinson wrote: > > > On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon > > > wrote: > > > > > > > > On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: > > > > > On 23/07/2019 21:51, Pierre-Yves Chibon wrote: > > > > > > > > > > > When you run `fedpkg build` on Rawhide, your package will be built > > > > > > in a new koji > > > > > > tag (which will be the default target for Rawhide). The package > > > > > > will be picked > > > > > > up from this koji tag, signed and moved onto a second tag. Bodhi > > > > > > will be > > > > > > notified by koji once this new build is signed and will > > > > > > automatically create an > > > > > > update for it (you will be notified about this by email by bodhi > > > > > > directly) with > > > > > > a “Testing” status. If the package maintainer has not opted in into > > > > > > the CI > > > > > > workflow, the update will be pushed to “Stable” and the build will > > > > > > be pushed > > > > > > into the regular Rawhide tag, making it available in the Rawhide > > > > > > buildroot, just > > > > > > as it is today. > > > > > > > > > > Do we have an estimate of how much extra latency this is likely to add > > > > > both with and without gating enabled? ie how much more delay there is > > > > > likely to be before new builds are available? > > > > > > > > Currently the extra latency is about 3 minutes. It's the frequency at > > > > which the > > > > > > What is that based upon? What level of capacity is there to run the CI etc > > > > > > > cron job pushing the updates having past CI to stable runs. We do want > > > > to make > > > > > > I'm assuming you mean passed and not past here, the later gives it > > > quite a different meaning. > > > > Sorry, I wasn't clear, the 3 minutes extra latency is for non-gated > > packages. > > For gated packages, this highly depends on the tests you run. On my canary > > test > > that is just call the "fail" method of ansible, it takes about 8 minutes to > > have > > the tests set up, ran and tear down. > > So that makes an extra 8 minutes for the tests + up to 3 minutes for the > > update > > to be pushed to stable (assuming tests passed). > > Is there documentation on the failure work flow? What does a packager > need to do to get it resubmitted etc? I've been meaning to add that question to the FAQ since this morning but still haven't got to it :( We do want to have a mechanism to allow all packagers to re-trigger tests for their package. However, at this point we do not have it. There are thus two ways to move forward, either bump the release and rebuild (that will re-trigger the tests) or waive the missing tests (that will let the build go through gating). We're not fond of that situation since we're teaching our packagers to waive tests, but this is targeting early-adopters and we hope they can forgive us for this. I'll made a PR to the doc for this right now :) Best, Pierre ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
* Stephen Gallagher: > With my FESCo hat on, I can't support this action as currently stated. > I think I'd be more inclined to consider it if the Change was proposed > as a new architecture bring-up. Effectively, this would be a whole new > architecture that would just happen to be largely compatible with > x86_64. Can we make this happen at the RPM level? So that third-party RPMs install just fine even though the operating system is something else (not x86_64 anymore)? I do not see many explicit dependencies on anything “x86_64” in Fedora 30, so perhaps this is doable, assuming that packages of the other architecture would continue to provide …(…)(64bit) for soname dependencies. Could we rebuild x86_64 Fedora with a different dist tag and different compiler flags, and release that as a new spin? And retain the x86_64 for that architecture? Regarding doing something like the old i686 packages when we had an i586 baseline (or the ppc64p7 work that was perhaps never upstreamed to Fedora), I'm a bit worried about increasing the complexity of composes. We already see upgrade issues doe to i686 packages come and go, and that could potentially multiply them. The advantage is that packaging changes themselves will be relatively minor, once we have agreemeent which packages should do this. ELF multilib DSOs inside RPMs result in code deduplication, affecting container image size. Packaging changes are *not* minor for this approach. It can be tricky to ensure full testing coverage if both DSOs are installed. Currently, there is no dynamic loader support for selecting an AVX2 baseline. Fixing this requires complete agreement among all involved parties what the actual CPU requirements are (currently, not even glibc and GCC agree what “haswell” means, the closest we have to an AVX2 baseline). But similar fixes are required for any baseline update. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: portable performance engineering
* Kevin Kofler: > Dave Love wrote: >> they'd be rather limited by the compiler options we're supposed to use, >> that don't include vectorization, so you don't even get the benefit you >> could from SSE2. (I've been told off in review for turning that on, >> though an FPC member has approved it.) > > Why don't we enable -ftree-vectorize by default? GCC upstream thinks that it is still not beneficial in general. Obviously, there will always be *some* regressions, but for GCC 9, the thinking was that the regressions still outweight the striking benefits in some cases. I believe Clang enables the auto-vectorizer at -O2. >> However, hwcaps won't help for programs with no separate library >> performance component; Gromacs is an example. On a heterogeneous HPC >> system you need multiple parallel-installable versions with a convention >> for the paths they'll be on. > > As I wrote elsewhere in this huge thread: just turn the program into a > library with a dummy main program. That requires manual work, so it's unclear how to do this for large parts of the distribution. And people will worry about PIC-related losses, or due to assumptions regarding symbol interposition (which affect inter-procedural analysis). The latter even affects Fedora because PIE does not turn off these optimizations. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rolling out Phase I of rawhide package gating
* Pierre-Yves Chibon: > On Wed, Jul 24, 2019 at 08:29:03AM +0200, Florian Weimer wrote: >> * Pierre-Yves Chibon: >> >> > Good Morning Everyone, >> > >> > TL;DR: On July 24th we will turn on the first phase of Rawhide package >> > gating, >> > for single build updates. >> >> How does this interact with the mass rebuild? > > It does not. Mass-rebuild are done in a dedicated side-tags from which > they are merged directly into the buildroot tag. So they entirely > by-pass gating (current and future versions of it). Thanks for the clarification. So the mass rebuild effectively waives all previous gating failures. I don't think there's a good choice here, either approach has its problems. 8-/ Maybe in the future, perhaps we should do the mass rebuild, tag it in, and then re-run all gating tests to see what kind of regressions there are? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 31 Self-Contained Change proposal: AArch64 Xfce Desktop image
On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote: > We currently offer Workstation, Minimal and Server images for use with > AArch64 Single Board Computer's (SBC's). We would like to add a > lighter weight desktop image for hardware that lacks the ability to > run accelerated desktops. Are people using gnome-shell on arm64 machines? Would it make sense to simply switch Workstation default to xfce on arm64? Zbyszek > > An initial set of supported devices: > * Pine64 > * Raspberry Pi 3/4 > * 96boards HiKey > * 96boards Dragonboard 410c > > == Benefit to Fedora == > Better user experience and an additional desktop choice for AArch64 SBC's. > > == Scope == > * Proposal owners: The ARM SIG will make the kickstart changes needed > to add the desktop images to the compose. > * Other developers: N/A > * Release engineering: Enable building of the AArch64 XFCE desktop > image. Small tweaks may be required to the pungi configs or fedora > kickstarts but those will be completed by the SIG and sent as pull > requests. Issue[https://pagure.io/releng/issue/8556 #8556] > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > No upgrade compatibility required, this is a new image variant. > > == How To Test == > Testing can be completed on any supported AArch64 SBC using the > existing arm-image-installer. Any additional instructions will be > added to the ARM installation documentation. > > == User Experience == > Users will have increased choice in desktop offerings for AArch64 > SBC's. Those looking to install a desktop on hardware that lacks an > accelerated graphics driver or lower system specifications will have a > useable option. > > == Dependencies == > > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: N/A > * Contingency deadline: N/A > * Blocks release? No > * Blocks product? No > > == Documentation == > All documentation will be added or updated via the ARM Landing Page. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
> On Wed, Jul 24, 2019 at 09:14:05AM +0100, Peter Robinson wrote: > > On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon > > wrote: > > > > > > On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: > > > > On 23/07/2019 21:51, Pierre-Yves Chibon wrote: > > > > > > > > > When you run `fedpkg build` on Rawhide, your package will be built in > > > > > a new koji > > > > > tag (which will be the default target for Rawhide). The package will > > > > > be picked > > > > > up from this koji tag, signed and moved onto a second tag. Bodhi will > > > > > be > > > > > notified by koji once this new build is signed and will automatically > > > > > create an > > > > > update for it (you will be notified about this by email by bodhi > > > > > directly) with > > > > > a “Testing” status. If the package maintainer has not opted in into > > > > > the CI > > > > > workflow, the update will be pushed to “Stable” and the build will be > > > > > pushed > > > > > into the regular Rawhide tag, making it available in the Rawhide > > > > > buildroot, just > > > > > as it is today. > > > > > > > > Do we have an estimate of how much extra latency this is likely to add > > > > both with and without gating enabled? ie how much more delay there is > > > > likely to be before new builds are available? > > > > > > Currently the extra latency is about 3 minutes. It's the frequency at > > > which the > > > > What is that based upon? What level of capacity is there to run the CI etc > > > > > cron job pushing the updates having past CI to stable runs. We do want to > > > make > > > > I'm assuming you mean passed and not past here, the later gives it > > quite a different meaning. > > Sorry, I wasn't clear, the 3 minutes extra latency is for non-gated packages. > For gated packages, this highly depends on the tests you run. On my canary > test > that is just call the "fail" method of ansible, it takes about 8 minutes to > have > the tests set up, ran and tear down. > So that makes an extra 8 minutes for the tests + up to 3 minutes for the > update > to be pushed to stable (assuming tests passed). Is there documentation on the failure work flow? What does a packager need to do to get it resubmitted etc? ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 10:17:20AM +0200, Dan Horák wrote: > On Tue, 23 Jul 2019 22:51:28 +0200 > Pierre-Yves Chibon wrote: > > > Good Morning Everyone, > > > > TL;DR: On July 24th we will turn on the first phase of Rawhide > > package gating, for single build updates. > > In a later phase, Rawhide updates that contain multiple builds will > > also be enabled for gating. Our goal is to improve our ability to > > continuously turn out a useful Fedora OS. So we hope and expect to > > get opt-in from as many Fedora package maintainers as possible, > > including maintainers of the base OS. But this phase of gating > > remains opt-in, and should not affect packagers who choose for now > > not to opt in. > > What is your level of confidence about reliability of the whole process? > How much baby-sitting from the maintainer will be required (for lost > messages, crashed or stuck processes, etc)? We have move the most significant pieces of the workflow from fedmsg to fedora-messaging which should eliminate or drastically reduce the risk of lost messages. We have three pieces that are still fedmsg and that we are still working on porting to fedora-messaging: the CI system itself, resultsdb-listener (uploads results from CI into resultsdb) and robosignatory. All of which are actively being worked on and should land in the coming weeks (hopefully days). The process is pretty straight forward, so I am pretty confident in it. There will be bugs (there always are) but I don't think we'll have that are actually blocking the update process. > How arch specific packages will be handled? I mean how s390x or ppc64le > specific packages will be handled if the infra would be ready for > x86_64 only? I cannot answer for the CI system, maybe Dominik or Aleksandra can :) Best, Pierre ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
On Tue, Jul 23, 2019 at 7:37 PM Adam Williamson wrote: > > On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote: > > On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi wrote: > > > On 7/22/19 10:34 PM, Igor Gnatenko wrote: > > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko > > > > wrote: > > > > Thinking about this even more, it should not be very hard thing to do: > > > > > > > > * Define new architecture in RPM/libsolv (let's call it "haswell" or > > > > "x86_64modern") > > > > * Define set of capabilities it should have, write appropriate check > > > > in RPM/libdnf > > > > * Add new architecture in Fedora Koji > > > > * Once bootstrapped, create composes > > > > * At some point in future, merge this arch back to x86_64 and move > > > > forward > > > > > > > > What do you think? > > > > > > Unless someone can show some kind of MASSIVE benefit, I'm not in favor. > > > > I think too often we focus on the technical implications (performance > > gain, etc) and sometimes don't consider wider aspects. So I'm curious > > what your view is. Can you elaborate on what kind of benefit you > > would view as warranting this? > > > > > It's a ton of duplication of effort, tons more disk space, tons more cpu > > > cycles wasted, a ton more mirror disk space, a ton more bandwith, etc. > > > > So let's look at this statement, for example. Everything listed is > > machine related, except the first part on duplication of effort. > > Machine related items are solvable with more machine resources. (That > > is not to be flippant, but it's far easier to solve than human > > impact.) > > Well, sort of - except that, life being life, machines inevitably go > wrong. Fans give out and they choke. Builds mysteriously fail because > of some test flake or a neutrino hitting the CPU at just the wrong > moment or something. Disks go wonky. And all of these things get fixed > by...people. Adding an arch adds another arch worth of all those things > happening and needing to be fixed by someone. > > Also, we can't really solve the machine resources of mirrors. Well, I > mean, I guess we *could*, but I doubt anyone in RH is going to sign off > on us buying a ton of expensive storage hardware and shipping it off to > random universities around the world... > > > On the effort part, what if we structured it so it wasn't immediately > > 2x the effort. That would indeed be poor. If we assume for a minute > > that we have the machine resources, we can certainly come up with > > workflows that facilitate something like this in a manner that doesn't > > cause a large human overhead. I'm actually thinking of other areas > > that would benefit from not exactly the new architecture approach as > > traditionally know, but a new target space that allows the Fedora > > project to do new things. > > I agree that this would be possible, but it comes with the caveat that > the people who would likely get stuck with improving the workflows are > the same people currently being overworked by the bad workflows. Completely agree here, but I've seen no concrete proposals from the leadership as to how they intend to fix this. There's proposals from the CPE team to jettison things, which makes sense for them but it's completely undefined what the wider impact on other teams or the wider community will be there, I suspect it just moves the bottleneck. > The 'don't do a release for a year' proposal (or whatever variations of > it were discussed) was supposed to help with that kinda thing, > but...that didn't happen. So, we're all still on the treadmills. Part of that was because the proposal was just "stop releasing to fix stuff" but there wasn't any form of proposal of what was going to be fixed or how, there was just wide ranging hand wavy "stuff". ___ 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: Rolling out Phase I of rawhide package gating
On 24/07/2019 09:14, Peter Robinson wrote: On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon wrote: On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: On 23/07/2019 21:51, Pierre-Yves Chibon wrote: When you run `fedpkg build` on Rawhide, your package will be built in a new koji tag (which will be the default target for Rawhide). The package will be picked up from this koji tag, signed and moved onto a second tag. Bodhi will be notified by koji once this new build is signed and will automatically create an update for it (you will be notified about this by email by bodhi directly) with a “Testing” status. If the package maintainer has not opted in into the CI workflow, the update will be pushed to “Stable” and the build will be pushed into the regular Rawhide tag, making it available in the Rawhide buildroot, just as it is today. Do we have an estimate of how much extra latency this is likely to add both with and without gating enabled? ie how much more delay there is likely to be before new builds are available? Currently the extra latency is about 3 minutes. It's the frequency at which the What is that based upon? What level of capacity is there to run the CI etc Well I assume that's just the overhead of the extra moving things around on top of any time for the actual tests to run. I generally run tests in %check anyway so test wise I'm mostly interested in using rpmdeplint and maybe abicheck, although I'm pretty sure that's not really robust enough yet. That said, having to go round adding a mega ugly config file to every package that looks an awful lot like an internal braindump from some system doesn't really inspire confidence, or make for an easy way of opting in. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 09:14:05AM +0100, Peter Robinson wrote: > On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon > wrote: > > > > On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: > > > On 23/07/2019 21:51, Pierre-Yves Chibon wrote: > > > > > > > When you run `fedpkg build` on Rawhide, your package will be built in a > > > > new koji > > > > tag (which will be the default target for Rawhide). The package will be > > > > picked > > > > up from this koji tag, signed and moved onto a second tag. Bodhi will be > > > > notified by koji once this new build is signed and will automatically > > > > create an > > > > update for it (you will be notified about this by email by bodhi > > > > directly) with > > > > a “Testing” status. If the package maintainer has not opted in into the > > > > CI > > > > workflow, the update will be pushed to “Stable” and the build will be > > > > pushed > > > > into the regular Rawhide tag, making it available in the Rawhide > > > > buildroot, just > > > > as it is today. > > > > > > Do we have an estimate of how much extra latency this is likely to add > > > both with and without gating enabled? ie how much more delay there is > > > likely to be before new builds are available? > > > > Currently the extra latency is about 3 minutes. It's the frequency at which > > the > > What is that based upon? What level of capacity is there to run the CI etc > > > cron job pushing the updates having past CI to stable runs. We do want to > > make > > I'm assuming you mean passed and not past here, the later gives it > quite a different meaning. Sorry, I wasn't clear, the 3 minutes extra latency is for non-gated packages. For gated packages, this highly depends on the tests you run. On my canary test that is just call the "fail" method of ansible, it takes about 8 minutes to have the tests set up, ran and tear down. So that makes an extra 8 minutes for the tests + up to 3 minutes for the update to be pushed to stable (assuming tests passed). Best, Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Tue, 23 Jul 2019 22:51:28 +0200 Pierre-Yves Chibon wrote: > Good Morning Everyone, > > TL;DR: On July 24th we will turn on the first phase of Rawhide > package gating, for single build updates. > In a later phase, Rawhide updates that contain multiple builds will > also be enabled for gating. Our goal is to improve our ability to > continuously turn out a useful Fedora OS. So we hope and expect to > get opt-in from as many Fedora package maintainers as possible, > including maintainers of the base OS. But this phase of gating > remains opt-in, and should not affect packagers who choose for now > not to opt in. What is your level of confidence about reliability of the whole process? How much baby-sitting from the maintainer will be required (for lost messages, crashed or stuck processes, etc)? How arch specific packages will be handled? I mean how s390x or ppc64le specific packages will be handled if the infra would be ready for x86_64 only? Thanks, Dan ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon wrote: > > On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: > > On 23/07/2019 21:51, Pierre-Yves Chibon wrote: > > > > > When you run `fedpkg build` on Rawhide, your package will be built in a > > > new koji > > > tag (which will be the default target for Rawhide). The package will be > > > picked > > > up from this koji tag, signed and moved onto a second tag. Bodhi will be > > > notified by koji once this new build is signed and will automatically > > > create an > > > update for it (you will be notified about this by email by bodhi > > > directly) with > > > a “Testing” status. If the package maintainer has not opted in into the CI > > > workflow, the update will be pushed to “Stable” and the build will be > > > pushed > > > into the regular Rawhide tag, making it available in the Rawhide > > > buildroot, just > > > as it is today. > > > > Do we have an estimate of how much extra latency this is likely to add > > both with and without gating enabled? ie how much more delay there is > > likely to be before new builds are available? > > Currently the extra latency is about 3 minutes. It's the frequency at which > the What is that based upon? What level of capacity is there to run the CI etc > cron job pushing the updates having past CI to stable runs. We do want to make I'm assuming you mean passed and not past here, the later gives it quite a different meaning. > this be bus-based (instead of cron-based) which will reduce this latency even > more. > > > Best, > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 08:29:03AM +0200, Florian Weimer wrote: > * Pierre-Yves Chibon: > > > Good Morning Everyone, > > > > TL;DR: On July 24th we will turn on the first phase of Rawhide package > > gating, > > for single build updates. > > How does this interact with the mass rebuild? It does not. Mass-rebuild are done in a dedicated side-tags from which they are merged directly into the buildroot tag. So they entirely by-pass gating (current and future versions of it). > Will Fedora 31 release with an unrebuilt package if gating fails? Since there is a mass-rebuild no (unless they fail to rebuild). For releases where we have no mass-rebuild, we could, indeed, see that if the maintainers do not fix the tests or the packages. Best, Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote: > On 23/07/2019 21:51, Pierre-Yves Chibon wrote: > > > When you run `fedpkg build` on Rawhide, your package will be built in a new > > koji > > tag (which will be the default target for Rawhide). The package will be > > picked > > up from this koji tag, signed and moved onto a second tag. Bodhi will be > > notified by koji once this new build is signed and will automatically > > create an > > update for it (you will be notified about this by email by bodhi directly) > > with > > a “Testing” status. If the package maintainer has not opted in into the CI > > workflow, the update will be pushed to “Stable” and the build will be pushed > > into the regular Rawhide tag, making it available in the Rawhide buildroot, > > just > > as it is today. > > Do we have an estimate of how much extra latency this is likely to add > both with and without gating enabled? ie how much more delay there is > likely to be before new builds are available? Currently the extra latency is about 3 minutes. It's the frequency at which the cron job pushing the updates having past CI to stable runs. We do want to make this be bus-based (instead of cron-based) which will reduce this latency even more. Best, Pierre ___ 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: Rolling out Phase I of rawhide package gating
On 24. 07. 19 8:29, Florian Weimer wrote: * Pierre-Yves Chibon: Good Morning Everyone, TL;DR: On July 24th we will turn on the first phase of Rawhide package gating, for single build updates. How does this interact with the mass rebuild? Will Fedora 31 release with an unrebuilt package if gating fails? Mass rebuild happens in a side tag and AFAIK it will just be merged after no matter what gating says. Effectively, it bypasses it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Request to take ownership of gimp-resynthetizer
On 24. 07. 19 3:42, Luya Tshimbalanga wrote: Following the bug report[1], I would like to take ownership of gimp-resynthetizer because of its use on Fedora Design Suite Labs. Would it be possible to orphan that package? You can follow either: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Or: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ The package will likely get retired in 2 weeks: https://pagure.io/releng/issue/8522 If you have a fix ready, I can help you push it. Is it https://src.fedoraproject.org/rpms/gimp-resynthesizer/pull-request/1 ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
