Re: F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases
Hi all, Change author here. I think that everything is on-track now. Sorry I hadn't seen any of these messages before, there's a newer post over here (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/L64OGN7XWO7VQEUDKFB3IJ2HYUFTSPFA/) and I hadn't realised that this had been active. I've posted two scripts over there too. I'd appreciate any feedback on them. Chris, The only system for automatic decryption with a TPM that I know of is clevis, which operates in the initramfs for both LUKS1 and LUKS2. I mention it in the change proposal as a recommendation, but it is by no means a requirement. Petr, While you are correct, I'd rather attempt to prevent tampering and also set-up a system through which to detect any. Besides, this change proposal is simply meant to offer security-minded users options that weren't available to them before. Benjamin ___ 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
[389-devel] 389 DS nightly 2019-07-15 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/07/15/report-389-ds-base-1.4.1.4-1.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/389-devel@lists.fedoraproject.org
Re: python-oauthlib update
Hi! I just wanted to chime in as the maintainer and developer of Apprise. I'm only using the OAuth v1 client and only for Twitter notifications, so i don't foresee any issues. Either way, I'll test it out as per your advice. If it's incompatible, I'll do my part and fix it up on my side. Thank you kindly for the heads up! :) Chris On Sat, Jul 13, 2019 at 4:32 PM Kevin Fenzi wrote: > Greetings. > (I am posting this to the devel list and also Bccing the maintainers of > the involved packages below). > > A bit back I updated python-requests-oauthlib to 1.2.0. > > I didn't realize at the time that this version needs python-oauthlib > 3.0.0 or newer. > > 3.0.0 is a api breaking major version: > https://github.com/oauthlib/oauthlib/releases/tag/v3.0.0 > > The following packages depend on python-oauthlib: > > cloud-init > python-apprise > python-jira > python-requests-oauthlib > python-social-auth-core > > From what I can tell: > > python-requests-oauthlib is already set for the update. > python-social-auth-core - uses the oauth1 interface, should be ok. > python-jira - users the oauth1 interface should be ok. > python-apprise - uses the oauth1 interface should be ok. > cloud-init - users the oauth1 interface should be ok. > > I will wait until mid next week to hear back from anyone that I > shouldn't do the update. Otherwise I will go ahead and build 3.0.2 in > rawhide. > > If I've missed any packages or compatibility, please let me know. > > Thanks! > > kevin > > ___ 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: roundup of failing images for 2019-07-07
On 7/7/19 7:55 PM, Kevin Fenzi wrote: 6. Fedora robotics live: https://koji.fedoraproject.org/koji/taskinfo?taskID=36106496 I've submitted a PR and triggered a rebuild of an offending package to get this at least working again. I'm hoping to dedicate some more time this cycle to do some more significant updates. Rich ___ 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 (late): No i686 Repositories
On 7/14/19 2:35 PM, John Reiser wrote: > Kevin Fenzi wrote: >> Neal Gompa wrote: > > [[snip]] > >>> This will also make it impossible for people to locally do multilib >>> build/installs. It will remove COPR’s ability to do the same. For that >>> reason alone, I don’t particularly want this change to happen. > >> Can you expand on what you mean by 'locally do' ? > > I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box > to build executables that run as 32-bit apps on multilib x86_64. > For some apps 2GB of malloc() arena is plenty, and they run faster > in 32-bit mode because a 64-byte cache line contains 16 pointers > instead of only 8. This should still work, unless there are libraries you use that are not multilib. > [[snip]] > >> Finally, if you would prefer this not happen now, is there a time when >> you would further down the road? Whats the critera/goalpost/cutoff? > > One year after Red Hat Enterprise Linux version 7 reaches end-of-support. > It would be handy for Fedora to have 32-bit *-devel packages until then. We will still have 32bit devel packages in the x86_64 repos after this change. It doesn't affect multilib at all. It only stops building and publishing the 'pure' i386 repos on the mirror network. I don't think we can drop multilib until at least steam/wine are ready for it at least. 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: Orphaned python-breathe
I'll take it: https://pagure.io/releng/issue/8531 Miro Hrončok writes: > Upon the maintainers request, I've just orphaned python-breathe. > > https://bugzilla.redhat.com/show_bug.cgi?id=1706355 > -- > 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 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: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 7/14/19 2:27 PM, Neal Gompa wrote: > Building library packages and making your own multilib repo is > impossible without having both the i686 repo and the x86_64 repo, as > you need to build for both and then munge them together for a multilib > repo. Sure. Do many people do that anymore? > Historically, we really haven’t wanted people to pull from the Koji > repo, and we probably still don’t want to do that, since it’s not > mirrored and stressing it could cause more problems our already > overtaxed build system environment. I contend that the number of people who would want to do this is miniscule and in the noise. No one (sane) would start a 32bit app these days, so likely it's legacy support. The cases I know of are steam and wine. I am sure there's 3rd party items beyond that, but even rhel6 is going to go away soon, so these folks are going to have to come up with some solution really soon. >>From my point of view, I don’t think it’s worth getting rid of the > 32-bit x86 repo until we’re at the point where people would not need > to build their own multilib repositories. The cost of generating that > for mirroring isn’t that high relative to the amount of pain we’ll > cause for external folks trying to build off Fedora. Fair enough. I see it as already at the time when there are very few of thoese people and we can keep them going for a while by asking them to use the koji buildroot repo. > Think, for example, the repo that shall not be named. That project’s > Koji instance pulls in Fedora through the mirrored content as an > external source, which feeds its ability to do multilib builds. Sure, they can repoint that to koji buildroot and keep going. > I’m sorry, but I don’t see us getting rid of this for the foreseeable > future without breaking virtually all of our downstreams. Those few that need to be 32bit applications still. I really don't think this is "all of our downstreams". 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: manpath.be, man page package checks/policy
On Sun, Jul 14, 2019 at 04:49:40PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jul 13, 2019 at 04:19:02PM +0200, Georg Sauthoff wrote: [..] > > See also its about page https://manpath.be/about for some of its > > features (e.g. permalinks, short links, reverse links ...). > > Looks interesting. One thing that seems missing at first sight is > search: it'd be great to have interactive search across sections. > Right now, it's only easy to find a page is one knows the section > and the exact name. Right now you can google search the site like this: memory management site:manpath.be/f30 This turns up the malloc and fork man pages, for example. I plan to add a search feature to the site. Probably first a search form in the left column that redirects the query to a google search like in the above example. In a second step perhaps I'll also add some internal search functionality. > One issue that I had before with similar services was that it was > never possible to rely on any given one to provide _all_ man > pages. In systemd we link to man pages online from online versions > of our pages under http://www.freedesktop.org/software/systemd/man/index.html, > and we have to link to a bunch of different services > (man7.org, linux.die.net, mankier.com), because we need to link > to kernel man pages, and various fringe tools, some distro-specific > man pages, etc. Two suggestions: 1. pull pages from many different My approach for Fedora/CentOS is to import all valid man pages from all available packages (i.e. what is available if you just enable the fedora/base + updates repositories). Thus, with respect to Fedora/CentOS the man page repository should be pretty complete. I plan to add more distributions/versions in the future. > sources, 2. include a suggestion box for people to mention what > they can't find. There is a suggestion feature when a requested page isn't found but is available in another section. For example: https://manpath.be/f30/2/popen yields: Page not found (404) No such man page: popen(2) Similar pages: popen(3) popen(3p) (where the alternatives are linked) If you navigate to a page that is available in a certain section but also in others the right column lists the alternatives - in case one wasn't aware of the alternatives - and/or used a suboptimal section. Example: https://manpath.be/f30/1/write lists the alternatives: write(1p), write(2) and write(3p) Best regards Georg ___ 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 (late): No i686 Repositories
Kevin Fenzi wrote: Neal Gompa wrote: [[snip]] This will also make it impossible for people to locally do multilib build/installs. It will remove COPR’s ability to do the same. For that reason alone, I don’t particularly want this change to happen. Can you expand on what you mean by 'locally do' ? I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box to build executables that run as 32-bit apps on multilib x86_64. For some apps 2GB of malloc() arena is plenty, and they run faster in 32-bit mode because a 64-byte cache line contains 16 pointers instead of only 8. [[snip]] Finally, if you would prefer this not happen now, is there a time when you would further down the road? Whats the critera/goalpost/cutoff? One year after Red Hat Enterprise Linux version 7 reaches end-of-support. It would be handy for Fedora to have 32-bit *-devel packages until then. ___ 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 (late): No i686 Repositories
On Sun, Jul 14, 2019 at 5:21 PM Kevin Fenzi wrote: > > On 7/14/19 1:15 PM, Neal Gompa wrote: > > > This will also make it impossible for people to locally do multilib > > build/installs. It will remove COPR’s ability to do the same. For that > > reason alone, I don’t particularly want this change to happen. > > Can you expand on what you mean by 'locally do' ? > > Current multilib packages will still be available in the x86_64 repo. > Users can still install them from there just fine. > > If a user wants to locally build a i686 package, they can use mock > against the koji i686 buildroot repo to do so. They could then put that > package in a local repo with x86_64 packages and run createrepo on it. > > It's true there would be no easily mirrored i386 for them to copy to > aviod the internet, but is that really a big use case? > > Finally, if you would prefer this not happen now, is there a time when > you would further down the road? Whats the critera/goalpost/cutoff? > Building library packages and making your own multilib repo is impossible without having both the i686 repo and the x86_64 repo, as you need to build for both and then munge them together for a multilib repo. Historically, we really haven’t wanted people to pull from the Koji repo, and we probably still don’t want to do that, since it’s not mirrored and stressing it could cause more problems our already overtaxed build system environment. From my point of view, I don’t think it’s worth getting rid of the 32-bit x86 repo until we’re at the point where people would not need to build their own multilib repositories. The cost of generating that for mirroring isn’t that high relative to the amount of pain we’ll cause for external folks trying to build off Fedora. Think, for example, the repo that shall not be named. That project’s Koji instance pulls in Fedora through the mirrored content as an external source, which feeds its ability to do multilib builds. I’m sorry, but I don’t see us getting rid of this for the foreseeable future without breaking virtually all of our downstreams. -- 真実はいつも一つ！/ 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: Difference between pungi and livemedia-creator
On 7/14/19 1:19 PM, Sergio Belkin wrote: > Hi, > I was using livemedia-creator but I'd want to understand well what's the > differences between both pungi and livemedia-creator. pungi is a higher level tool for making everything. So, pungi talks to koji, gathers rpms, calls createrepo_c to make repos, calls koji to run livemedia-creator and oz and imagefactory and appliance-tools to make those images, etc. So, if you just want a live media, livemedia-creator is likely what you want. If you want to make a bunch of deliverables, pungi would likely be a better fit. 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: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 7/14/19 1:15 PM, Neal Gompa wrote: > This will also make it impossible for people to locally do multilib > build/installs. It will remove COPR’s ability to do the same. For that > reason alone, I don’t particularly want this change to happen. Can you expand on what you mean by 'locally do' ? Current multilib packages will still be available in the x86_64 repo. Users can still install them from there just fine. If a user wants to locally build a i686 package, they can use mock against the koji i686 buildroot repo to do so. They could then put that package in a local repo with x86_64 packages and run createrepo on it. It's true there would be no easily mirrored i386 for them to copy to aviod the internet, but is that really a big use case? Finally, if you would prefer this not happen now, is there a time when you would further down the road? Whats the critera/goalpost/cutoff? 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
Difference between pungi and livemedia-creator
Hi, I was using livemedia-creator but I'd want to understand well what's the differences between both pungi and livemedia-creator. Thanks in advance -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.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: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Sun, Jul 14, 2019 at 4:10 PM Miro Hrončok wrote:
>
> https://fedoraproject.org/wiki/Changes/Noi686Repositories
>
> (Ben is on vacation, so I announcing this on his behalf.)
>
> == Summary ==
>
> Stop producing and distributing the Modular and Everything i686 repositories.
>
> == Owner ==
>
> * Name: Kevin Fenzi
> * Email: ke...@scrye.com
>
> == Current status ==
> * Targeted release: [[Releases/31| Fedora 31 ]]
> * Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
> * Tracker bug:
> * Release notes tracker:
>
> == Detailed Description ==
>
> With the dropping of the i686 kernel package it's no longer possible to
> directly
> install Fedora 31 or later on i686 hardware, however, it is still possibly to
> upgrade older releases as long as we continue to provide a repository. This
> will
> leave those users with an old possibly vulnerable kernel installed.
>
> The only other use/need for the repostories is to allow maintainers to debug
> and
> test fixes for multilib shipped packages, but the koji buildroot repo can be
> used for this use case.
>
> == Benefit to Fedora ==
>
> * users won't try and upgrade old i686 installs with insecure kernels.
> * compose times will be decreased (no more gathering i686 packages up and
> running createrepo on them).
> * Updates push times will be reduced.
> * disk size on mirrors will be reduced.
>
> == Scope ==
> * Proposal owners:
>
> ** modify pungi-fedora to no longer produce i386 repo for Everything and
> Modular, modify bodhi config for f31+ to not make i386 repos for
> updates/updates-testing.
> ** modify mock to use the koji buildroot for i686 for f31+ for those few users
> that need to build i686 packages locally.
>
> * Other developers: n/a
>
> * Release engineering: [https://pagure.io/releng/issues 8529]
>
> == Upgrade/compatibility impact ==
>
> i686 users will not be able to upgrade, and will have to move to another
> supported arch.
>
This will also make it impossible for people to locally do multilib
build/installs. It will remove COPR’s ability to do the same. For that
reason alone, I don’t particularly want this change to happen.
--
真実はいつも一つ！/ 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
Fedora 31 System-Wide Change proposal (late): No i686 Repositories
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: ke...@scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug:
* Release notes tracker:
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
== How To Test ==
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Everything/i386/
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modular/i386/
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Modular}/i386
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Everything|Modular}/i386
* Confirm that mock can init a chroot for fedora-i386-31 using the koji
buildroot repository.
== User Experience ==
* Users will get updates and rawhide and rc composes faster.
* Users will not be able to upgrade to a insecure Fedora configuration.
== Contingency Plan ==
i686 trees will just continue to be composed and published. Users can upgrade to
them (with an old kernel from f30).
--
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: Long standing FTBFS
On 23. 06. 19 22:38, Miro Hrončok wrote: The following packages fail to build from source from at least Fedora 28 and their FTBFs bugs are still in the NEW state. Please make them build or retire them from Fedora. If you cannot work on the packages but still consider them useful, orphan them: PyPE https://bugzilla.redhat.com/show_bug.cgi?id=1674593 cas https://bugzilla.redhat.com/show_bug.cgi?id=1674721 cyphesis https://bugzilla.redhat.com/show_bug.cgi?id=1674783 encuentro https://bugzilla.redhat.com/show_bug.cgi?id=1674855 fedora-motd https://bugzilla.redhat.com/show_bug.cgi?id=1674876 gnome-activity-journal https://bugzilla.redhat.com/show_bug.cgi?id=1674988 googsystray https://bugzilla.redhat.com/show_bug.cgi?id=1675050 ipsilon https://bugzilla.redhat.com/show_bug.cgi?id=1675158 igor https://bugzilla.redhat.com/show_bug.cgi?id=1675141 libhocr https://bugzilla.redhat.com/show_bug.cgi?id=1675279 librapi https://bugzilla.redhat.com/show_bug.cgi?id=1675303 librra https://bugzilla.redhat.com/show_bug.cgi?id=1675308 pyroom https://bugzilla.redhat.com/show_bug.cgi?id=1675708 python-googlevoice https://bugzilla.redhat.com/show_bug.cgi?id=1675741 python-libturpial https://bugzilla.redhat.com/show_bug.cgi?id=1675752 resiprocate https://bugzilla.redhat.com/show_bug.cgi?id=1675888 kupfer https://bugzilla.redhat.com/show_bug.cgi?id=1675241 ladish https://bugzilla.redhat.com/show_bug.cgi?id=1675245 libopensync-plugin-python https://bugzilla.redhat.com/show_bug.cgi?id=1675299 qct https://bugzilla.redhat.com/show_bug.cgi?id=1675829 synce-kpm https://bugzilla.redhat.com/show_bug.cgi?id=1676103 turpial https://bugzilla.redhat.com/show_bug.cgi?id=1676167 writetype https://bugzilla.redhat.com/show_bug.cgi?id=1676219 This is the second reminder sent 3 weeks after the first one. -- 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: manpath.be, man page package checks/policy
On Sat, Jul 13, 2019 at 04:19:02PM +0200, Georg Sauthoff wrote: > Hello, > > so I've created https://manpath.be - a site that provides access to the > man pages of several distributions - including several Fedora and CentOS > versions. > > See also its about page https://manpath.be/about for some of its > features (e.g. permalinks, short links, reverse links ...). Looks interesting. One thing that seems missing at first sight is search: it'd be great to have interactive search across sections. Right now, it's only easy to find a page is one knows the section and the exact name. One issue that I had before with similar services was that it was never possible to rely on any given one to provide _all_ man pages. In systemd we link to man pages online from online versions of our pages under http://www.freedesktop.org/software/systemd/man/index.html, and we have to link to a bunch of different services (man7.org, linux.die.net, mankier.com), because we need to link to kernel man pages, and various fringe tools, some distro-specific man pages, etc. Two suggestions: 1. pull pages from many different sources, 2. include a suggestion box for people to mention what they can't find. I don't have any comment on the issues you listed. It'd be useful to diagnose such issues automatically. That'd probably help to cut down on the number of issues. 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 Data Engineering SIG: interested in a Fedora SIG to work on this?
Hmm .. I think I'll do something in between, .. a set of documentation on how to install and run the softwares , and a set of rpms which contains Fedora integration (systemd service, profile.d files, wrapper scripts, etc) to make things works better with Fedora if the user followed the convention provided by the docs. Which I think it's somewhat similar with the approach of some existing foss game engine packages which requires separate, manual download of data files / proprietary components. Thanks for the feedback! ___ 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
[Bug 1727848] perl-Mojolicious-8.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1727848 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.20-1.fc3 ||1 Resolution|--- |RAWHIDE Last Closed||2019-07-14 09:06:38 --- Comment #2 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1312899 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/perl-devel@lists.fedoraproject.org
[Bug 1728178] perl-Data-ObjectDriver-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1728178 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Data-ObjectDriver-0.18 ||-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-07-14 09:02:53 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1312906 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/perl-devel@lists.fedoraproject.org
[Bug 1728299] perl-MojoX-JSON-RPC-0.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1728299 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MojoX-JSON-RPC-0.12-1. ||fc30 Resolution|--- |RAWHIDE Last Closed||2019-07-14 09:02:10 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1312907 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/perl-devel@lists.fedoraproject.org
