Re: Fedora 40 apache now giving errors
On Tue, Apr 23, 2024 at 08:52:18PM -0400, Steven A. Falco wrote: > I upgraded to F40, and suddenly an apache cgi script that was working > perfectly in F39 (and earlier) is giving me a "Read-only file system" error > when trying to write data into a file. > > The directory where the cgi is trying to write is owned by > apache:apache, and it is mode 777. The file the cgi is trying to > write to is also owned by apache:apache and is mode 666. > > If I manually run the cgi (a trivial perl script), it works perfectly, > but apache gives the "Read-only file system" error. Apache can read > the file fine, it just cannot write to it. > > I also tried having the cgi simply touch a file in /tmp, and that fails too. > > Any suggestions gratefully accepted. As Xose suggests it is likely related to the new systemd hardening restrictions which are applied for httpd from Fedora 40. There is a bit more information in "man httpd.service." Exactly what directory are you trying to write to? /usr is blocked by ProtectSystem=yes, /home is blocked by ProtectHome=yes, for example. Writing to /tmp works fine OOTB for a trivial CGI in /var/www/cgi-bin for me - if that is failing you please file a bug. (Because PrivateTmp has been used for a *long* time in httpd, httpd's /tmp is different to the system /tmp) Regards, Joe -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote: > There will always be some effort related to such a transition, but > that effort will have to happen one way or the other eventually. I > suspect if Fedora decides to keep ENGINE support, we’ll have the exact > same discussion in a few years when OpenSSL 4.0 is released, and > people will demand that the rebase to 4.0 that removes engine support > should be a system-wide change proposal because it breaks engines. Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the API is optional upstream, and its use has produced compiler warnings since it was introduced in Fedora 36, it seems perfectly reasonable to disable this API in Fedora 41. We have to deal with a very large numbers of FTBFS bugs from e.g. Python API breaks every other release cycle, or the latest compiler flag tuning. The fact that the transition creates work for other package maintainers is obviously not a reasonable blocker for a Fedora Change. Regards, Joe -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote: > Another alternative is to continue providing fully functional engine > symbols, but remove the header files so in practice you can't compile > something new that uses it. This is still forking the API, but at least > has not forked the ELF ABI, so the upgrade doesn't explode. This is a really good idea, I hope Daniel's comment is not lost here. In fact no need to remove the header files - adding the required: #define OPENSSL_NO_ENGINE into will make the OpenSSL API act as if it was built with the no-engine option - this would not be an API fork since it's one of many configurations supported upstream. It will have the desired effect of disabling ENGINE support across most of Fedora in the next mass-rebuild. Or at least we can easily track down the places where the detection isn't perfect, they will break at compile time. Regards, Joe -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Change: RPM 4.18 (System-Wide Change proposal)
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote: > On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton wrote: > > == Detailed Description == > > > > RPM 4.18 contains various improvements over previous versions, but in > > particular this release addresses a whole class of symlink handling > > related security issues, some with CVE's, from 2021. Other notable > > improvements include > > * A more intuitive conditional builds macro `%bcond` > > I looked this up[1] because it caught my attention. This is an > extremely welcome change and I would like to shower praise upon > everyone who worked on it. Big +1 from me too, this is so good to see. Thanks Panu & all. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 09:07:58AM -0400, Ben Cotton wrote:
> Note from the change owner: I'm submitting this as very-very-late
> change for F35. The implementation in systemd is mostly done, so it'll
> become available in rawhide pretty soon. To actually make use of the
> new functionality, individual packages should be changed to use
> _with_restart in their scriptlets and rebuilt. This will happen over
> time, and it's fine if each package does that on its own schedule. We
> still do not have that many user services, and restarting from
> packaging scriptlets will be possible and appropriate only for some of
> them. I think it's important to make the functionality available,
> without trying to use it everywhere immediately.
>
> https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade
We've been restarting httpd on upgrades in %posttrans for a while, so
it's good to see a more general version of this available. A couple of
notes:
1) Users asked to be able to turn this off ("why did running dnf break
my web server" etc), which I think is reasonable, we added a crude
mechanism (touch /etc/sysconfig/thing) to disable it.
2) Blocking the dnf transaction from completing before the service
restarts turned out to be quite painful UX and we now only run
try-restart with --no-block. Depending on the service or service
configuration there it can be a significant delay. Obviously a trade-off
here since it can hide the failure case.
I tried to trace through the systemd macros (the links from the Change
wiki under "Macro details" are broken) and it looks like you do block on
restart/reload, is that worth reconsidering? Maybe we could wrap the
systemd macros to achieve (1) as well for httpd, but I'd say that it
might be a more generally useful feature too to allow users control over
this feature.
Regards, Joe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: How to handle nginx 3rd party modules?
On Tue, Mar 09, 2021 at 10:29:53AM -0500, Felix Kaechele via devel wrote: ... [snip great email] ... > So I'd appreciate some input here as to what the best way forward would be > from a distribution engineering perspective. Hi Felix, that's a fantastic write up! I think you have outlined the different options, the complexity and trade-offs involved there extremely well, that matches exactly how I see it. One thing I'd add - even for something as "simple" as the lua module, the OpenResty folks seem to not recommend it's used with upstream nginx, instead they recommend what is basically their own fork of nginx: https://github.com/openresty/lua-nginx-module#installation Hence it's never been obvious to me that if you start down this road, it you can easily stop. If you worked out how to ship the lua module, the next bug report will be that you need to adopt a handful of the OpenResty patches for nginx as well to make the lua module work properly. And then you end up packaging "OpenResty" rather than "nginx"? For RHEL we have maintained a hard line on your (4) - just don't do it. We ship "nginx", and that's it. Until NGINX upstream wants to support an external API/ABI and externally built third-party modules, we should not try to do it ourselves. (Apache httpd has supported this model for *over two decades*. It's not like it is rocket science, nor can it be unclear there is is some demand for this.) I think your option (1) - bundle some extra modules directly in the nginx SRPM - would be absolutely fine for Fedora *if* those maintaining that package have the time & effort to maintaining that. I'm afraid I'm not going to volunteer any time for that though :( Regards, Joe [Manager for team which owns RHEL HTTP servers, inter alia] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
dropping php-imap (was Re: Orphaned packages looking for new maintainers)
On Mon, Feb 08, 2021 at 06:43:29PM +, Gwyn Ciesla via devel wrote: > Can uw-imap be replaced with something else, or should someone pick it up? There has not been an upstream release since 2007 - the maintainer Mark Crispin sadly died in 2012, and nobody else has formed an upstream around it. In my view it makes sense to drop it from Fedora 35+ and take the pain of disabling functionality until the various upstreams switch to alternatives. Hopefully Remi can comment on alternatives. Regards, Joe ___ 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: The Future of the Java Stack (also regarding ELN and RHEL)
Hi all, I'm writing as the Red Hat engineering manager responsible for Maven and Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my team. I want to give a broad response to some of the points here: 1. The team has two missions in Fedora: a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is to provide developers with the most popular Java build systems which are reviewed, tested, and updated through the release lifecycle. b) We design, develop and document tooling that enables anyone to package Java software with a simple, efficient and scalable process. We are also active members of Java SIG, collaborating on complex changes and guiding new contributors. 2. We are committed to maintaining the Ant and Maven modules in Fedora. We have always expected to make them available as default streams and in the buildroot so they can be available and consumed by non-modular packages, but we completely respect the decisions of FESCo to disallow default streams and of other contributors to adopt and maintain the non-modular packages. We are not going to promise to commit time and resources to maintain the non-modular packages. 3. Our efforts are currently directed mainly at minimization of the dependency tree which leads to maven and ant, automating the process of bootstrapping maven and updating related components, so that new versions can be imported and built reproducibly and with consistent quality. 4. The benefit we want to preserve from modules is to maintain packages with varying expectation of quality, specifically separating the build-time-only vs runtime dependencies. e.g. in that case that a web server like Eclipse Jetty is required as a dep for testing another component during the build, we want to be able to use and build that component, without being indefinitely on the hook for security errata. (The build dependency tree is particularly complex for Maven and involves many examples of packages with frequent and high severity vulnerabilies) Regards, Joe ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Sun, Jul 12, 2020 at 02:27:49PM -0700, John M. Harris Jr wrote: > There's no reason to "update" any config, php-fpm is just an alternative > option. mod_php still works well, and doesn't need to be replaced by those > currently using it. It's still supported by the upstream, is still widely > used > in RHEL, Debian-based systems and so on, and has a few users in Fedora as > well. It doesn't make sense to drop support for this. > > It'd be as simple as accepting ngompa's PR, here: > https://src.fedoraproject.org/rpms/php/pull-request/4 Remi has rejected the PR. There is really nothing more to discuss here, and I cannot really see you are making a productive contribution to technical debate in Fedora by continuing this thread, especially given the misinformation which others have already had to correct. If you are struggling to adapt existing servers from mod_php to php-fpm please use the users list to ask for help. Fedora 33 will not include mod_php - end of story. Regards, Joe ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote: > > == Detailed Description == > > By default php-fpm is used for a few versions. mod_php is not > > supported for threaded modules. mod_php usage also increases security > > risk, sharing the same process than httpd. > > > > Drop mod_php from php build. This will only affect user of httpd in > > "prefork" mode, which will also use php-fpm. > > > > php-fpm is already used but most users of httpd and nginx without any issue. > > Based on the replies downthread, it seems that some people are still > using it and want to keep it... If the existence of non-zero user demand blocked removal of defunct technology in Fedora I guess we'd still be shipping SysV init. We made the switch from forked-httpd + mod_php to threaded-httpd + php-fpm by default in Fedora 27, so we've spread this transition over six full release cycles. We've had AFAIK *zero* bug reports about making the default switch. > Is mod_php a maintainance burder and/or a noticable installation > overhead when not used? And if it is, would additional help with the > maintainance that was offered make it easier to keep? I'm not seeing any technical argument in this thread to support keeping mod_php. If there were, that would be interesting, but otherwise I think the package owner should be trusted and empowered to make this change. Regards, Joe ___ 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: PSA: please stop manually titling Bodhi updates
On Wed, Nov 27, 2019 at 09:33:04AM -0800, Adam Williamson wrote: > Hey folks! > > Since the new Bodhi UI rolled out recently I've noticed a big uptick in > updates where the update creator manually set the update title. > > This is a problem because in every single case so far, the manually- > created title is worse than an auto-generated title would have been. > > If you just leave that box blank, Bodhi will set the update title to be > the NVR(s) of the package(s) in the update, just like it always has. > But the new UI seems to really encourage people to override this and > write a title manually...and people are picking titles that are worse. > e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2019-edc1551b22 > where the auto-generated title would have been > "container-selinux-2.123.0-1.fc31" but the update author manually set it to > "container-selinux", which is clearly much less useful. I think the web site UI can change the title to the component name like that when you edit an existing update. It did it to me a couple of times, I thought I was doing something wrong but maybe it's just a bug. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What are the benefits of default modular streams over non-modular packages?
On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > Where is the end-user benefit with the modular default stream? I don't see > it either, sorry. It's not clear to me how those examples are related to my argument, which I could summarize as: a) multiple module streams have a benefit to users, and b) default streams have a benefit to package owners. > > This comes at a high cost to package owners if we have to keep > > non-modular packages - we have to maintain, build, and test X streams > > plus Y non-modular release branch builds for each component, rather than > > just X streams. > > Yes. This is the benefit of the default modular stream for the modular > maintainers. I have never questioned it. OK great, though it is a bit surprising to hear in a thread which you started explicitly to question the benefits of default modular streams. > In my opinion (and that is my very subjective opinion, but based on > experience) the cost of that difference is otherwise paid by everybody else. > > The group of everybody else is very much bigger than the group of modular > maintainers. Hence, I'd approve such trade off. So it's clear to me that you see that packagers chosing default streams over non-modular packages impose external costs on the rest of the distro (packagers and/or users?) somehow. This thread was supposed to focus on benefits, and these vague claims about costs and trade-offs seem speculative, but maybe you could expand on that a bit? Perhaps this stuff is obvious to others already. In RHEL8 while we have certainly hit various problems with modularity at least I don't recall my teams hitting major issues with default streams being available for non-modular packages. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What are the benefits of default modular streams over non-modular packages?
On Thu, Nov 14, 2019 at 04:56:28PM +0100, Miro Hroncok wrote: > I'll admit that I personally don't see any benefits, but of course that > doesn't mean that they don't exist or that it's not worth having this > discussion. > > Considering we have 6 default modular streams, let me acknowledge that for > the maintainers who decided to deliver default modular streams instead of > non-modular packages, there clearly are some benefits. > While some of us might not understand them, let's not say there are none. > But even if there are clear benefits for the maintainers of those modules, > I'm asking about the benefits for everybody else. Seems like a bit of an odd question. There is an end-user benefit from making multiple module streams available both in the short run (more features/choices today) and long run (better tested software via making development/unstable releases available more widely). This comes at a high cost to package owners if we have to keep non-modular packages - we have to maintain, build, and test X streams plus Y non-modular release branch builds for each component, rather than just X streams. In some cases the costs will be prohibitive to supporting modular streams - the aim of switching to default streams + dropping non-modular packages is precisely to eliminate that cost difference. Regards, Joe ___ 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: Will orphan packages with NEW F31FTBFS bugs tomorrow
On Thu, Nov 14, 2019 at 12:32:29AM +0100, Miro Hroncok wrote: > On 13. 11. 19 21:10, Miro Hrončok wrote: > > libserf > > This one bothers me. It is required by subversion and thus transitively by > git, koji and others. > > Joe, I see you have assigned the bugzilla to yourself: > > https://bugzilla.redhat.com/show_bug.cgi?id=1736050 > > Do you also plan to unorphan the package? Yes, I'll take it, I am sure I was watching that project before but never knew this was FTBFS until seeing your list last night. It looks like a transient failure and builds fine now -> https://pagure.io/releng/issue/9012 Regards, Joe ___ 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: Stepping away from packaging (and request for owners)
On Sat, Oct 19, 2019 at 06:38:47PM +0100, Jamie Nguyen wrote: > It's been incredible to part of this project and community! :-) > > Once upon a time I was an (over?)enthusiastic packager and it's left me > with ownership of 300+ packages. O_o Jamie, just wanted to say a big THANKS for all the time you have dedicated to Fedora, you've made a huge contribution to the project and its users. Best of luck for the future, and you'll always be welcome back! Regards, Joe ___ 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: Modules in Non-Modular Buildroot
On Mon, Oct 14, 2019 at 11:44:46PM +0200, Kevin Kofler wrote: > The net result of this proposed Change for the end user is still the same as > the status quo: They have to use modules whether they want to or not, the > choice is taken away from them. And while the default stream approach tries > to hide Modularity from the users (and with this proposed Change, also from > the packagers of dependent packages), the abstraction is leaky, as > evidenced, e.g., by the libgit2 upgrade blocker. Yup, it is certainly not perfect and we'll have to work through those kinds of issues carefully as Stephen & others are doing. I am very confident in trusting Fedora developers to make sensible choices for our users, though - including whether we should make packages module-only. As package maintainers we all make technical decisions which have significant impact on our users every day - whether that's in the choice of defaults, choice of build flags, or whatever. Honestly delivering as modules-vs-non-modules is a completely trivial issue compared to most of the stuff I spend time on. If "yum install X" still works most people just don't care about the RPM/dnf/repo mechanics behind that. If you don't want to ship any of your packages as modules I think that's great and you should continue doing that. On the other hand, I want to move a bunch of my packages to module-only because I think I can do a better job serving Fedora users that way. Regards, Joe ___ 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: Modules in Non-Modular Buildroot
On Wed, Oct 09, 2019 at 04:46:52PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > > Enable module default streams in the buildroot repository for modular > and non-modular RPMs. > > == Summary == > This Change (colloquially referred to as "Ursa Prime") enables the > Koji build-system to include the RPM artifacts provided by module > default streams in the buildroot when building non-modular (or > "traditional") RPMs. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgall...@redhat.com > * Responsible WG: Modularity WG Thanks for writing this up Stephen, I fully support this. For some people here it is clear they don't want to develop modules and that will always be fine. Others see a benefit (whether small or large) from developing as modules, and that should also be fine and I want Fedora to allow that. Allowing modules in buildroots prevents the conflict between packagers who make different choices (e.g. non-modular Eclipse can't use module-only Maven) so seems like a good compromise. I find myself a bit reluctant to write this mail because the language others are using in this thread is fairly ugly for a technical discussion in an open source project - about "forcing" people to develop packages in a certain way, "teaching them a lesson" etc. Please calm it down & have some respect for technical decisions of other developers. Regards, Joe ___ 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: Source File Verification
On Thu, Jul 25, 2019 at 07:22:56PM +0200, Björn Persson wrote: > Jason L Tibbitts III wrote: > > >>>>> "JO" == Joe Orton writes: > > > > JO> In the historic CVS-based build system which predated what we now > > JO> use, we could do GPG key verification at the time of downloading and > > JO> importing a new tarball. > > > > You're right; tmz dug up a copy of the old Makefile.common file: > > https://tmz.fedorapeople.org/tmp/Makefile.common > > It looks like that searched for and verified signatures when the > packager ran "make download". If they downloaded a new tarball with a > browser, then it would not be verified automatically. The packager > could then download the signature too and run "make download-checks" > manually – if they happened to remember and care. Experience shows that > most people don't care about security until it's too late, so the > verification would often not happen. No one else could know whether the > signature had been verified or not. > > Having that functionality back could be a useful tool, but it would not > replace verification during the build, which the packager can't just > forget to do once they have added the one-liner to the spec file. If you don't enforce GPG verification at or before "fedpkg upload" there is no assurance that what hits the lookaside cache is trusted, so I agree - doing this at build time is a good example of not caring about security until it's too late. But I assume the FPC is off doing its own thing and will totally ignore community feedback as normal, so I'll feel free to carry on ignoring FPC output and this whole conversation is pointless. ___ 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: Source File Verification
On Thu, Jul 25, 2019 at 12:46:11PM +0200, Björn Persson wrote:
> Joe Orton wrote:
> > We'd put the set of trusted GPG keys in the repository alongside the
> > spec file, using some standard filename, and the build system would try
> > check the .asc against the keys when downloading (or uploading? I can't
> > remember) a new tarball. This would ensure the tarball uploaded to the
> > lookaside cache was trusted.
>
> If you can implement that in such a way that the packager can't neglect
> to verify the signature, then that might also work for Fedora's needs.
> You'll have to think hard about how the code will know which source
> file to verify against which signature in all possible situations.
You talk like this is a hard problem but it was implemented that way for
the first N years of Fedora - possibly when the infrastructure was only
internal to Red Hat, I don't remember. It just got thrown away with the
move to git & fedpkg.
It worked from Makefiles but a fedpkg equivalent would be something
like:
fedpkg download => worked like spectool -g specfile.spec
but also fetched ${tarball}.asc
fedpkg upload X =>
if ./gpgkeys exists:
enforce verification of ${tarball} against ${tarball}.asc using ./gpgkeys
actually upload X and update sources
___
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: Source File Verification
On Wed, Jul 24, 2019 at 11:15:26PM +0200, Igor Gnatenko wrote: > 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 It seems completely daft doing this at build time. In the historic CVS-based build system which predated what we now use, we could do GPG key verification at the time of downloading and importing a new tarball. This makes FAR more sense to me than checking the signature on the same tarball every build. We'd put the set of trusted GPG keys in the repository alongside the spec file, using some standard filename, and the build system would try check the .asc against the keys when downloading (or uploading? I can't remember) a new tarball. This would ensure the tarball uploaded to the lookaside cache was trusted. Regards, Joe ___ 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
Orphaned crypto-utils
I've orphaned crypto-utils. If there is any interest in keeping /usr/bin/certwatch I created a new upstream for that so could revive it as a new package without all the other stuff which accumulated in crypto-utils, let me know. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
On Wed, Oct 04, 2017 at 10:07:22AM +0200, Lukas Vrabec wrote: > This change is already in Fedora Rawhide. I had discussion with Dan Walsh > and Joe Orton (apache maintainer) about this and I would be great have it > also in Fedora 27. > > Users, upgrading from F26 to F27 won't be affected (we change only default > value of boolean not a actual value), but fresh installs will be affected. > Apache in default configuration doesn't need this boolean anymore and as I > said above, this is big security improvement. Is it somehow possible to push > it into F27 ? +1 from me for Fedora 27. We have documented the need to change the boolean in the httpd.service(8) man page and in the MPM config file[1] in an updated httpd. Regards, Joe [1] /etc/httpd/conf.modules.d/00-mpm.conf -- Joe Orton // Red Hat Core Services ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Retired mod_auth_kerb in Fedora master
Hi, I've retired mod_auth_kerb in the master branch. mod_auth_kerb has been unmaintained for many years. mod_auth_gssapi is now available and is an up-to-date, maintained replacement. Koji is the only dependency, let me or Simo know if you want help adjusting the koji-web configuration. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphan package: webalizer
This thing is not actively maintained upstream; no intent to carry this any more. Regards, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: nodejs update
On Thu, Sep 08, 2016 at 01:27:54PM -0400, Stephen Gallagher wrote: > > * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL > > 1.0.2 > > and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both > > EPEL 6 > > and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution > > (SCL > > or otherwise) for linking EPEL to a newer version of OpenSSL. Have you got details on what exactly is required from 1.0.2? Is it ALPN support? I strongly suspect it will be possible (with sufficient effort) to patch node to build against older OpenSSL, albeit at the cost of losing some features. There is a trade-off here between disabling 1.0.2 features & waiting for RHEL OpenSSL to catch up, versus having to maintain & patch a copy of OpenSSL 1.0.2 in addition to the RHEL OpenSSL. i.e. someone is ready to deal with patching all future Critical security issues in a bundled OpenSSL. Regards, Joe -- Joe Orton // Red Hat Core Services ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: PSA: heads-up replacing mod_auth_kerb with mod_auth_gssapi
On Fri, Oct 23, 2015 at 05:39:05PM -0400, Simo Sorce wrote: > Hello fellow Fedora developers, > I have relatively recently completed a project to replace the ancient and > aging and unmaintained mod_auth_kerb Apache module with a new, slimmer, more > modern and maintained module called mod_auth_gssapi[1]. > > The plan is to retire mod_auth_kerb soon and get it out of the distribution. > So this is a heads up that if you have a project that somehow relies on > mod_auth_kerb it would be nice if you could migrate it to mod_auth_gssapi > instead, and if you have any issue doing so (missing features, > incompatibilities, anything) that you let us know so we can address whatever > problem you may find and accelerate the demise of mod_auth_kerb. Great, thanks Simo. I'm not sure if we need a Feature for this, but I'm happy to drop mod_auth_kerb in f24+. I see deps from ipsilon-authkrb and koji-web FWIW. Regards, Joe -- Joe Orton // Red Hat // Web Stack Team // webstack-t...@redhat.com // @notroj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BerkeleyDB 6 symbol versioning and associated problems
On Wed, May 07, 2014 at 03:19:42PM +0200, Jan Staněk wrote: One of the planned parts of the F21 System Wide Change: BerkeleyDB 6 [1] is the introduction of downstream symbol versioning of both versions of the libraries (libdb with v6 and libdb5 with v5). This part is planned in order to not introduce bugs similar to [2]. However, if we introduce downstream versioning (as upstream is generally unresponsive), then we face the problem similar to [3]. Just wondering: is this getting punted to F22 now? Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BerkeleyDB 6 symbol versioning and associated problems
On Wed, May 07, 2014 at 03:19:42PM +0200, Jan Staněk wrote: One of the planned parts of the F21 System Wide Change: BerkeleyDB 6 [1] is the introduction of downstream symbol versioning of both versions of the libraries (libdb with v6 and libdb5 with v5). This part is planned in order to not introduce bugs similar to [2]. However, if we introduce downstream versioning (as upstream is generally unresponsive), then we face the problem similar to [3]. If we keep libdb5 (forever?) then the [3] problem is less of an issue, IMO. Given that portably linking against libdb has historically been a major headache I'd be surprised if there are any binary third-party apps which even try doing this, to be honest. I don't claim to understand the licensing matrix here, though, is there any background reading on that? Can we even switch *anything* which is potentially linked into httpd to using BDB 6? If not then basically nothing in $libdir can link against BDB 6. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote: AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python major.minor, loaded by Apache at the same time for various reasons. So the best solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that would conflict with mod_wsgi. It should be perfectly doable and it shouldn't break anything. CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think? This is done in f21 already thanks to Jakub Dorňák (#1035876) - I guess we could backport to f20 without any problems. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
On Tue, Apr 15, 2014 at 09:21:50AM -0700, Toshio Kuratomi wrote: We should probably have a similar guard in the mod_wsgi config file as well. Then be sure that we consciously name the conf files so that we are promoting one of these as the default (because sort order will load one of them before the other) if both packages are installed. I agree about the Conflicts, and it would be better to use the numeric prefix to guarantee the sort order. It is a little ugly to have both modules installed but to silently disable one, though the Python version does get logged at startup so it is reasonably obvious which was selected. It might be nice to have a run-time warning or debug message for that case, but I can't think of a way to do that. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: httpd-filesystem proposal
On Thu, Mar 27, 2014 at 07:55:19AM -0400, Matthew Miller wrote: I don't think gnome-user-share is installed by default anymore (or used by anyone?), but maybe we could finally really solve https://bugzilla.redhat.com/show_bug.cgi?id=235682, while we are at it. :) I still don't really know what is required there other than make httpd smaller. There are probably a few small things we can do there but I don't know of anything which could make a big difference. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RFC: httpd-filesystem proposal
We're proposing to add an httpd-filesystem subpackage which will simplify some dependency problems; particularly for packages which want to contain files owned by the apache user, but don't need a dependency on httpd itself. https://bugzilla.redhat.com/show_bug.cgi?id=1081453 Any comments welcome, either here on the bug. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
On Mon, Feb 17, 2014 at 12:37:53PM +0200, Ville Skyttä wrote: I don't think this calls for a mass rebuild or any kind of a rebuild actually, nor should it be rawhide only. AFAIU this doesn't affect runtime at all, only build time, and affected packages can be just fixed at the same time if they need an update in affected releases in the first place. The new rpmbuild cannot build an httpd which will satisfy dependencies of current Fedora packages. The new rpmbuild will force us to break the existing ABI dependency for httpd, breaking compatibility with existing and third-party packages. And all that breakage is for zero gain, with a bunch of engineering time wasted. This change is inappropriate for a F19/20 update IMO. Yes, we know the deps are wrong, but that was not hurting any Fedora users, and we've fixed it properly for F21. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: 64-bit stat (or not) in 32-bit Fedora binaries
On Wed, Feb 20, 2013 at 11:32:46AM +0100, Florian Weimer wrote: If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes pretty close to an ABI bump. But considering the numbers, I wonder if it's the right thing to do if we need to cope with 64-bit inode numbers. I think that would break the principle of least surprise. If I write a library which happens to expose ino_t or off_t in the API/ABI, that library should not build under a different ABI inside rpmbuild than outside. If we want the system default for the LFS APIs to change, surely it is safer and more correct to change the system (libc) default and have _FILE_OFFSET_BITS defined to 64 eveywhere? Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 64-bit stat (or not) in 32-bit Fedora binaries
On Wed, Feb 20, 2013 at 09:01:30AM -0500, Colin Walters wrote: The first option on the table should be patching upstreams, not hacking around it in RPM or changing the default. With autoconf, all you need is to add AC_SYS_LARGEFILE to configure.ac, and assuming no source changes are necessary (note: not always the case), then you're good. I agree, and using the LFS transitional interfaces (stat64 etc) is not hard either when _FILE_OFFSET_BITS=64 is not desirable. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On Wed, Jun 20, 2012 at 05:59:09PM +0200, Reindl Harald wrote: i saw a dist-upgrade on the fist-testmachine restart httpd which failed for some reason and AFTER some time you could start httpd again Leaving version X of /usr/sbin/httpd running after version Y of /usr/sbin/httpd is installed, plus associated loadable modules, is simply not a supportable system state. The software is not designed to cope with this situation. Notably, a SIGHUP of the httpd binary will attempt to use loadable modules from the new httpd with the old httpd binary. That is liable to kill or segfault the running daemon at best. Prior to the %posttrans-restart, we had numerous bug reports from people who updated, forget to restart the daemon, and then found their web server got killed during the night at the weekend when logrotate kicked in. That's not a good default. It's not unreasonable to request that the %posttrans-restart be made configurable, though I'm not sure exactly the best way. It would be nice if this could be co-ordinated in some fashion, so an update of any httpd module package could (optionally) trigger an httpd restart in %posttrans. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to retire: mod_python
On Mon, Mar 26, 2012 at 04:04:46PM +0100, Joe Orton wrote: mod_python upstream has been inactive for five years, since Graham Dumpleton went to work on mod_wsgi. IMO it is long past time to retire mod_python in Fedora. Last call. If anybody wants this package to remain in Fedora 17, please take ownership of the package in the pkgdb. Otherwise I will start the EOL process next week. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upcoming libdb/db4/compat-db reorganization
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote: So the plan is: 1) remove 4.5, 4.6 and 4.7 from compat-db 2) put 4.8 to compat-db 3) make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...) Sounds great. For Fedora 17 also, right? #768846 is bad. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access Did you read this part: The old access control idioms should be replaced by the new authentication mechanisms, although for compatibility with old configurations, the new module mod_access_compat is provided. It would be easy to include mod_access_compat in the Fedora default config for a release or two while the compat config is deprecated (and noted in the release notes as such). Yup - the default config in the f18 httpd does load mod_access_compat, and I don't see a problem with shipping like that. It would be good to convert webapps over for f18, having said that. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Intent to retire: mod_python
mod_python upstream has been inactive for five years, since Graham Dumpleton went to work on mod_wsgi. IMO it is long past time to retire mod_python in Fedora. But the following packages still depend on it: Source : glump-0.9.11-10.fc17.src.rpm Source : koji-1.6.0-3.fc17.src.rpm Source : viewvc-1.1.13-1.fc17.src.rpm Source : yawn-0-0.3.20120227svn561.fc18.src.rpm I haven't checked whether these are simply to convert over to WSGI or not. Does anybody want to maintain mod_python? If not, I'm going to retire it. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Fri, Mar 23, 2012 at 06:39:25PM +0100, Michał Piotrowski wrote: Do you know if the new version of httpd has major changes in modules API? I'm trying to cobble together spec file for mod_spdy https://github.com/eventhorizonpl/mod_spdy/blob/master/mod_spdy.spec and I hope to finish it for F18 :) Hi Michal, yes, there are changes in the 2.4 module API, though mostly relatively small - details are here: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
httpd 2.4 is coming, RFC on module packaging draft
httpd 2.4.1 packages are ready for dist-f18 and will be built early next week. Rebuilds will be required for all packages containing httpd modules. There are API changes in 2.4, so module packages may need patches if upstream has not done that work already: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html There are some significant changes in the packaging, also: 1) Config changes: I've moved to a minimal default httpd.conf which is very close to what we're shipping upstream. a) I'm proposing to split out packaged config snippets from mutable config, with the former in /etc/httpd/conf.modules.d/, containing only LoadModule lines, and ordered to avoid load-ordering issues. b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged modules, and only any reasonable default configurations. 2) Loadable MPMs! MPMs are now loadable modules, so we only need to ship one httpd binary again. Changing MPM is a config tweak. 3) Content. Putting unmutable content in /var was bad practice, so I've moved the /var/www/manual and /var/www/icons to into /usr/share/httpd. We now ship /var/www/* as empty directories. 4) Filesystem locations have moved in-line with upstream, e.g. apxs is now in /usr/bin. /etc/rpm/httpd.macros has macros for everything module packages should need. Since much of the above requires packaging changes for module packages, I've prepared a draft packaging guideline to document best practice: https://fedoraproject.org/wiki/PackagingDrafts/ApacheHTTPModules If anything there looks stupid, needs fixing, is missing, or there's any other feedback, please shout! Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP 5.4 as Fedora 17 feature ?
Hi Remi, sorry for the slow reply... On Sun, Nov 27, 2011 at 10:11:14AM +0100, Remi Collet wrote: PHP 5.4 enter RC stage So, I'm working to upgrade all the PHP stack (for now in my testing repo) I think PHP 5.4.0 (finale/stable) will be available for fedora 17, so I plan to update it (and all C extension before fedora 17 feature freeze) Do you think I should submit a feature proposal ? http://fedoraproject.org/wiki/Features/Policy Please do, if you have the time! Is this a good time to reconsider the ZTS stuff? Should we continue shipping a standalone -zts SAPI build, but no modules? Or start building modules? Or drop it? I kind of regret doing this half-assed to begin with! Any all opinions welcome. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retired packages: mod_auth_pgsql, mod_auth_mysql, mod_authz_ldap
I'm retiring these packages in devel, because: a) their functionality is duplicated by modules shipped with httpd (mod_authn_dbd, mod_authnz_ldap) b) their upstreams are no longer active Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
init script behaviour
Any opinions on this? I've had a query. What should service start do for a daemon - or more specifically, when should it return? There is inconsistency amongst different current init scripts, two general approaches: 1) fire and forget: start the daemon, return immediately 2) stop and wait: start the daemon, and wait, either: a) a short fixed period of time, or b) in a loop until the pidfile appears, with some maximum wait time Notable implication of (1) is that running e.g. service xxx status (or stop etc) may not immediately succeed after a start, nor may the service be immediately usable directly after a start returns. (2b) may have surprising failure cases of an init script waiting a long time to return - dirsrv will wait up to ten minutes, which seems rather extreme. (2a) may be unreliable, being dependant on timing/machine speed I found at least one init scripts which also has this stop-and-wait behaviour for stop (mysqld). I'd instinctively prefer (1) from a do one thing and do it well perspective; (2) starts down the road of a better/more complex form of service-monitoring/management and ends up doing it really badly in messy sh script in N places. (A logical extension of (2) would be to require not merely that the pidfile exists, but that the service is accepting connections on TCP port N, before returning from the init script start invocation) Thoughts? Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Mon, Mar 08, 2010 at 09:59:29PM +, Matthew Garrett wrote: It is the expectation of Fesco that the majority of updates should easily be able to garner the necessary karma in a minimal space of time. This seems naive to me. My experience is that there are few people willing to provide testing karma, even for relatively high-profile packages. It took about three months to get as many people to submit positive testing results for an httpd F-11 update in updates-testing recently. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Tue, Mar 09, 2010 at 02:20:20PM +0100, Mathieu Bridon wrote: On Tue, Mar 9, 2010 at 10:51, Joe Orton jor...@redhat.com wrote: On Mon, Mar 08, 2010 at 09:59:29PM +, Matthew Garrett wrote: It is the expectation of Fesco that the majority of updates should easily be able to garner the necessary karma in a minimal space of time. This seems naive to me. My experience is that there are few people willing to provide testing karma, even for relatively high-profile packages. It took about three months to get as many people to submit positive testing results for an httpd F-11 update in updates-testing recently. If the issues this update was solbing really bothered them, they would have provided feedback earlier. Hah, right. Back in the real world, most users expect free cake and complain if they don't get it. I would not be optimistic about resetting expectations there. For most updates I do, I end up doing the testing myself and ignorning automated karma pushes. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
