Cannot change fedora-cvs flag on bugzilla
Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
Dan Horák: Jamie Nguyen píše v Pá 23. 11. 2012 v 15:05 +: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org those emails must match, otherwise bugzilla can't know about the Fedora privileges like setting the flags. Dan I had a conversation with (IIRC) Kevin Fenzi about this a few months back. He did some magic to let me use jamielinux@fedoraproject for my bugzilla account, and I was under the impression that it would still work for me. I've had no complaints and everything has seemed to be fine, but perhaps the flags are an edge case. The easiest thing to do might be just to change my bugzilla email address to match.. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
Jamie Nguyen: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Kind regards, Jamie Well, I changed my bugzilla email to match, logged out and back in, and it still doesn't let me change the fedora-cvs flag. Any ideas? Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
Kevin Fenzi: On Fri, 23 Nov 2012 15:29:10 + Jamie Nguyen j...@jamielinux.com wrote: I had a conversation with (IIRC) Kevin Fenzi about this a few months back. He did some magic to let me use jamielinux@fedoraproject for my bugzilla account, and I was under the impression that it would still work for me. yes, that mapping is still in there and active. Our scripts give your privs to that bugzilla email account, so it should have the needed stuff to set flags. I've had no complaints and everything has seemed to be fine, but perhaps the flags are an edge case. The easiest thing to do might be just to change my bugzilla email address to match.. That won't work unless you have us now remove that mapping. It's a static mapping... this fas account has this bugzilla account you should grant packager privs to. Do you simply not see the flags? or there's no edit field? kevin I changed the bugzilla email to j...@jamielinux.com earlier to see if it would make a difference, but as you've just explained, that won't work. I've just looked in my account and it won't let me change the email address again, at least not for a few days. Not really sure what the best course of action is at the moment. I'd be happy with either of the email addresses. I can see the fedora-cvs flag, but it's greyed out and I can't select it. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
John5342: On Fri, Nov 23, 2012 at 3:05 PM, Jamie Nguyen j...@jamielinux.com wrote: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Just a wild guess but you don't appear to be in the packager group. Just the CLA groups and the fedorabugs group. Since it only makes sense to change the cvs flag if you are a packager perhaps you are required to be in the group before you can edit the field. On my FAS it says I'm also in Fedora Packager GIT Commit Group and I own or co-maintain 10+ packages. Is that what you're referring to as packager group? Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
John5342: Ok. Ignore me. FAS clearly shows you are in the group but for some reason admin.fedoraproject.org/community doesn't show you in the group. Will see about filing a bug shortly. OK, ignore my reply to your earlier post! Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
Alec Leamas: On 2012-12-29 17:01, Ken Dreyer wrote: I noticed our package review process doesn't explicitly say After you make an update to the package, bump the 'Release' number and post a new link each time. This is a popular convention, but it doesn't seem to be formally documented. https://fedoraproject.org/wiki/Package_Review_Process Should this guidance be part of our instructions? - Ken The GL nowadays allows updating of the spec without a release bump as long as nothing is released [1]. However, the changelog should still be updated one way or another. Also, in many cases the same link is reused, at least for the spec. I see nothing wrong in that That said, what's the problem you want to solve here? --alec Being able to track changes is very useful. I've seen on a few occasions reviewers mention that they can't tell what has changed in the spec since the previous version, as the new packager has overwritten the previous spec. I've also seen reviewers ask the new packager to document changes in the changelog as they go along, even before release, as it's quite helpful for both packager and reviewer. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please test Tor Fedora 17 package
Please could testers give some karma: https://admin.fedoraproject.org/updates/FEDORA-2012-14650/tor-0.2.2.39-1700.fc17?_csrf_token=3663fa7adec7f8e5c46ed89b7a0b59cfab9844d9 Tor package for Fedora 17 has been out-of-date with security issues for 4 months. Maintainer Enrico Scholz says he will not push the update without enough karma (despite even critical path updates only requiring 14-days without negative karma before they can be pushed): https://bugzilla.redhat.com/show_bug.cgi?id=903515 -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please test Tor Fedora 17 package
On 27/01/13 12:00, Reindl Harald wrote: Am 27.01.2013 12:54, schrieb Jamie Nguyen: Please could testers give some karma: https://admin.fedoraproject.org/updates/FEDORA-2012-14650/tor-0.2.2.39-1700.fc17?_csrf_token=3663fa7adec7f8e5c46ed89b7a0b59cfab9844d9 done Thanks very much. Hopefully now Mr Scholz will push the update. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please test Tor Fedora 17 package
On 27/01/13 16:54, Paul Wouters wrote: On Sun, 27 Jan 2013, Jamie Nguyen wrote: Please could testers give some karma: https://admin.fedoraproject.org/updates/FEDORA-2012-14650/tor-0.2.2.39-1700.fc17?_csrf_token=3663fa7adec7f8e5c46ed89b7a0b59cfab9844d9 Tor package for Fedora 17 has been out-of-date with security issues for 4 months. Maintainer Enrico Scholz says he will not push the update without enough karma (despite even critical path updates only requiring 14-days without negative karma before they can be pushed): https://bugzilla.redhat.com/show_bug.cgi?id=903515 I have long ago given up on tor in Fedora. I've gone through several rounds of battles with Enrico, one up to Fesco. The package should have been taken away from him a long time ago. It's basically Enciro's package and not a Fedora package. As a security dev, I can sadly only recommend using the upstream rpms. Paul I'm maintainer of Tor packages for EL6 and they are in fact currently more up-to-date than the Fedora 18 packages, as crazy as that sounds. Fedora users can alternatively use my own Tor repository (which includes Tor Browser too): http://repos.fedorapeople.org/repos/jamielinux/tor/ -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nodejs-slide license change MIT to ISC
Next update across all Fedora branches plus EL6 changes the license from MIT (nodejs-slide 1.1.4) to ISC (nodejs-slide 1.1.5). Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nodejs-read-package-json license change BSD to ISC
Next update across all Fedora branches plus EL6 changes the license from BSD (nodejs-read-package-json-1.1.1) to ISC (nodejs-read-package-json-1.1.3). Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nodejs-read-installed license change BSD to ISC
Next update across all Fedora branches plus EL6 changes the license from BSD (nodejs-read-installed-0.2.3) to ISC (nodejs-read-installed-0.2.4). Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nginx custom script location
Hi, Currently trying to sort out: https://bugzilla.redhat.com/show_bug.cgi?id=821926 Following an update to the nginx package, the command below would allow the server to switch to the new binary with zero-downtime (new process created, old process gracefully phased out): /etc/init.d/nginx upgrade This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality. My question is, where should this shell script go? In /usr/bin/nginx-upgrade? (As an aside, the other approach is to *automatically* do a zero-downtime upgrade in %post. This is the simplest solution and I think Debian do an automatic zero-downtime upgrade for their nginx package. I was entertaining this idea earlier but now feel it's safer and more in line with user expectations to require manual intervention. In most cases, currently running services are not affected by system updates without manually restarting the service.) Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nginx custom script location
On 16 May 2012 00:19, Michal Schmidt mschm...@redhat.com wrote: On 05/16/2012 12:21 AM, Jamie Nguyen wrote: /etc/init.d/nginx upgrade This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality. My question is, where should this shell script go? In /usr/bin/nginx-upgrade? Yes, this looks like a good choice to me. Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition? This script doesn't do anything new compared to our initscript, so upstream probably won't do much more than document it here: http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_On_The_Fly The simplest form of the script is literally just 2 commands (though I've implemented it in a slightly more calculated manner): /bin/systemctl kill --signal=USR2 nginx.service /bin/systemctl kill --signal=QUIT --kill-who=main nginx.service Nonetheless, I have offered both our nginx.service file and the above script to be upstreamed, or at least documented in their wiki: http://mailman.nginx.org/pipermail/nginx-devel/2012-May/002228.html Thanks for your advice. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nginx custom script location
On 16 May 2012 08:16, Tomasz Torcz to...@pipebreaker.pl wrote: On Wed, May 16, 2012 at 01:19:20AM +0200, Michal Schmidt wrote: On 05/16/2012 12:21 AM, Jamie Nguyen wrote: /etc/init.d/nginx upgrade This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality. My question is, where should this shell script go? In /usr/bin/nginx-upgrade? Yes, this looks like a good choice to me. Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition? Also, implementing socket-activation in nginx would make it upgradable without losing any connections. Sorry, could you clarify? I don't see how that would help in this situation. AFAIK, systemd socket activation is useful either for parallelization during system startup, or on-demand activation. The former doesn't help, and the latter is definitely not what we want for a web server. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nginx custom script location
On 16 May 2012 20:09, Tomasz Torcz to...@pipebreaker.pl wrote: On Wed, May 16, 2012 at 06:10:08PM +0100, Jamie Nguyen wrote: On 16 May 2012 08:16, Tomasz Torcz to...@pipebreaker.pl wrote: Also, implementing socket-activation in nginx would make it upgradable without losing any connections. Sorry, could you clarify? I don't see how that would help in this situation. AFAIK, systemd socket activation is useful either for parallelization during system startup, or on-demand activation. The former doesn't help, and the latter is definitely not what we want for a web server. If the new request comes during nginx restart¹, it won't be lost. Socket is always opened by systemd and the connection will be buffered until new nginx is ready to server it. ¹ in time between old nginx closing its socket and new nginx creating new Will look into this. Thanks for clarifying! Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hello, My name is Jamie Nguyen. I'm a student in the UK and part-time Linux system administrator. I am an active contributer to the TOMOYO Linux security project [1] and provide a binary repository containing RPMS/SRPMS for TOMOYO Linux kernels for Enterprise Linux 6 and Fedora 16 [2]. I also have experience in tech documentation; I have edited the How to create an RPM page in the Fedora wiki and have so far revamped the first half [3] with a view to doing a more complete revamp soon. I have one pending review request [4] for bashmount. I happen to be the author of this command-line tool :-) I would also be glad in the near future to co-maintain some or all of the MPD stack of applications (e.g. libmpdclient, mpc, ncmpc, ncmpcpp, sonata etc.). I have already posted a package review on the RPMFusion bugzilla [5] for a very heavily revised mpd.spec that includes a systemd service file (the mpd.spec file is much more complex than bashmount.spec, so it may interest you to take a look). Thanks everyone. [1] http://tomoyo.sourceforge.jp/ [2] http://repo.tomoyolinux.co.uk/ [3] https://fedoraproject.org/wiki/Special:Contributions/Jamielinux [4] https://bugzilla.redhat.com/show_bug.cgi?id=787858 [5] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1944 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to determine FAS from BZ email?
Thomas Spura wrote: 2012/2/23 Miroslav Suchý msu...@redhat.com: But I find incredibly hard to find relation between bugzilla email and FAS account. How do you do this check? Show all useres in the cla_signed group [3] and search for the mail address. When it's not there it may be overritten in [4]. When it's not there either, the user has not signed cla yet and cannot be a packager, yet. You can't be a packager without signing the CLA, but you can sign the CLA without being a packager. I signed my CLA well before being sponsored, so it wouldn't indicate to Miroslav that I should have blocked FE-NEEDSPONSOR. Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to determine FAS from BZ email?
Thomas Spura toms...@fedoraproject.org wrote: On Thu, Feb 23, 2012 at 3:24 PM, Jamie Nguyen ja...@tomoyolinux.co.uk wrote: Thomas Spura wrote: 2012/2/23 Miroslav Suchý msu...@redhat.com: But I find incredibly hard to find relation between bugzilla email and FAS account. How do you do this check? Show all useres in the cla_signed group [3] and search for the mail address. When it's not there it may be overritten in [4]. When it's not there either, the user has not signed cla yet and cannot be a packager, yet. You can't be a packager without signing the CLA, but you can sign the CLA without being a packager. Yes, no cla - no packager, like I wrote above. When someone has signed the cla, you then need to look if the user is already member of the packager group... Perhaps I misunderstand, but I think the real problem is that the email used for bugzilla doesn't have to be the same as the email specified when signing up for a FAS account. So if the bugzilla email isn't found in FAS, it doesn't necessarily mean that they don't yet have a FAS account. Similarly, it also doesn't necessarily mean that they haven't signed the CLA yet. I don't know how these queries are done, but I would have thought that if you can query whether any members of the CLA group have the email address in question, you might as well query the Packager group from the start. Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to determine FAS from BZ email?
Ken Dreyer wrote: 2012/2/23 Miroslav Suchý msu...@redhat.com: But I find incredibly hard to find relation between bugzilla email and FAS account. How do you do this check? I use zodbot's fasinfo command, because it's faster than searching the FAS web interface. Therefore I suggest to enhance template of [2] to include line: FAS account: your FAS login I'm in agreement with this. Do we need to open a ticket with the FPC? If you know the email but not the FAS username, then fas em...@email.com to query an email. But yes, the template solution is best. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg question: no f17 branch
Neal Becker wrote: What do I need to do to update my copy to include f17 branch? Just do fedpkg switch-branch f17 and the branch will automagically appear :-) Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Tor maintainership
Hi Enrico, Thanks very much for adding me as a co-maintainer. I guess that you probably don't have much time for updating the Tor package, so I'm glad to be on board and will be taking a very active role in maintaining the package so that you can spend time on other things. I have some package cleanup tasks lined up and will be closing the security bugs on our bugzilla very soon. Thanks again. (Also cc'd to fedora-devel to inform the public that any recent problems with the package should hopefully now be history :) Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: udisks in rawhide
On 05/02/13 16:41, Tomas Bzatek wrote: FYI, the old-generation udisks package has been made orphan in rawhide, nothing should be really using it nowadays. There's udisks2 (with incompatible API) as a supported method for handling storage. Is anybody still using udisks, the first generation? I see a few from quick repoquery check. Maintainers please check if it's possible to use/port to udisks2 instead. # repoquery --whatrequires udisks bashmount-0:1.6.2-4.fc18.noarch emelfm2-0:0.8.2-1.fc19.x86_64 exaile-0:3.3.1-1.fc19.noarch liveusb-creator-0:3.11.7-2.fc18.noarch wmudmount-0:1.13-4.fc19.x86_64 yumex-0:3.0.10-1.fc19.noarch (please keep me on Cc: when replying) bashmount is a script I wrote ages ago (back in my Arch Linux days when I was obsessed with being able to do everything via the command-line). I've not used it in a while, nor have I had the time/motivation to port to udisks2 (which has been bottom of my TODO list for some years). I'll likely orphan it. Does orphaning it on rawhide also remove it from the repository? Thanks. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: udisks in rawhide
On 06/02/13 17:35, Kevin Fenzi wrote: http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Thanks Kevin. OK, package retired! Package bashmount in Fedora devel has been retired by jamielinux To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/bashmount -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
On 07/02/13 21:33, Stephen Gallagher wrote: On Thu 07 Feb 2013 02:26:48 PM EST, Jamie Nguyen wrote: On 07/02/13 19:24, Jamie Nguyen wrote: Now that I'm a bit more familiar with node.js packaging (ie, never even looked at node.js before this week...), I'll take it. I don't currently have any packages for you to review, so you get off scot-free. Well, for now at least ;) Oops, looks like Stephen beat me to it by 30 minutes :) I took care of the high-priority one, but by all means, please dig into the nodejs-tap dependency chain. As T.C. says, that will make it easier to test and validate future reviews. Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
On 08/02/13 10:52, Stanislav Ochotnicky wrote: Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! Ah, buddycloud in Fedora? Cool. I'll have to try it out one day :-) Hopefully one day is going to be reasonably soon :) There are quite a few nodejs new package reviews that still need to be done (which I'll be working on trying to review), and I'll be opening something like 30+ new package reviews myself. I've now discovered the hell that is nodejs packaging, which is almost as painful as rubygems packaging, complete with vast arrays of specific versioned dependencies... -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does anybody know how to contact louizatakk?
Hello, I'm trying to contact the maintainer of python-sleekxmpp to request to co-maintain (as it's a bit out of date). Emails to his/her FAS email address are bouncing but there are no other maintainers to contact. Not really sure how exactly to get in touch given that email is the only form of communication on offer: User: louizatakk, Name: None, email: lo...@louiz.org, Creation: 2008-04-22, IRC Nick: None, Timezone: None, Locale: None, GPG Approved Groups: cla_fedora cla_done fedorabugs cvsl10n packager cla_fpca Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anybody know how to contact louizatakk?
On 16/02/13 01:55, Michael Scherer wrote: Le vendredi 15 février 2013 à 23:04 +, Jamie Nguyen a écrit : I'm trying to contact the maintainer of python-sleekxmpp to request to co-maintain (as it's a bit out of date). Emails to his/her FAS email address are bouncing but there are no other maintainers to contact. Not really sure how exactly to get in touch given that email is the only form of communication on offer: User: louizatakk, Name: None, email: lo...@louiz.org, Creation: 2008-04-22, IRC Nick: None, Timezone: None, Locale: None, GPG Approved Groups: cla_fedora cla_done fedorabugs cvsl10n packager cla_fpca Seems he forgot to renew his domain name. I can try to ask to people who have his phone number, but not sure to find it. However, you can try to contact him on the email listed on his github account : https://github.com/louiz Excellent, thanks. I've sent another email to the email address on his github. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SCM request not quite complete?
Hi Jon (and list), I opened an SCM request here: https://bugzilla.redhat.com/show_bug.cgi?id=910142 The master branch seems fine. I've cloned, imported and built nodejs-send for rawhide. However, I can't switch to f18 branch: $ fedpkg switch-branch f18 Could not execute switch_branch: Unknown remote branch f18 The message on the bug report says: Complete, clearing flag. It turns out the SCM request may have been cancelled half-way or something: Jon Ciesla limburg...@gmail.com has canceled Jamie Nguyen jamieli...@fedoraproject.org's request for fedora-cvs: Bug 910142: Review Request: nodejs-send https://bugzilla.redhat.com/show_bug.cgi?id=910142 I didn't get any [pkgdb] emails about nodejs-send, but it is on pkgdb: https://admin.fedoraproject.org/pkgdb/acls/name/nodejs-send Not sure what happened here? -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SCM request not quite complete?
On 25/02/13 10:38, Michael Schwendt wrote: On Mon, 25 Feb 2013 10:07:10 +, Jamie Nguyen wrote: $ fedpkg switch-branch f18 Could not execute switch_branch: Unknown remote branch f18 Jon Ciesla limburg...@gmail.com has canceled Jamie Nguyen jamieli...@fedoraproject.org's request for fedora-cvs: Bug 910142: Review Request: nodejs-send https://bugzilla.redhat.com/show_bug.cgi?id=910142 Not sure what happened here? The requested branches have not been created as can also be seen in pkgdb and this pkgdb notification: http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130225/965146.html You could simply reset fedora-cvs flag and re-request the missing branches. Sure, sounds good. Re-requested: https://bugzilla.redhat.com/show_bug.cgi?id=910142#c8 Thanks. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tor maintainership
On 10/02/13 13:12, Enrico Scholz wrote: Jamie Nguyen j...@jamielinux.com writes: Thanks very much for adding me as a co-maintainer. I guess that you probably don't have much time for updating the Tor package, so I'm glad to be on board and will be taking a very active role in maintaining the package so that you can spend time on other things. I have some package cleanup tasks lined up and will be closing the security bugs on our bugzilla very soon. I will revert most of your changes. please avoid to apply your personal style (e.g. whitespaces vs. tabs) on a package where you are a comaintainer for 1 week. Although some of the changes might be useful, it is impossible for me to distinguish between them because they were all in an huge commit. Hi Enrico, I want to clarify that my whitespace changes were an attempt to make the spec more legible for everyone, not myself. I also feel it would have been nicer for you to ask me to revert the changes rather than reverting them yourself, since I did go through the effort of making the changes and helping you to update and fix the package, but that's just a small suggestion. Anyway, I agree that it would perhaps have been better to split the commit into chunks. Thus, I post below a patch series that includes all the various changes in easily digestible chunks. http://jamielinux.fedorapeople.org/tor/0001-Remove-release_func-macro.patch http://jamielinux.fedorapeople.org/tor/0002-Cleanup-systemd-macros.patch http://jamielinux.fedorapeople.org/tor/0003-Remove-unnecessary-EPEL-5-tags-and-macros.patch http://jamielinux.fedorapeople.org/tor/0004-Unify-core-systemd-and-torify-into-one-package.patch http://jamielinux.fedorapeople.org/tor/0005-Remove-dependency-on-fedora-user-mgmt.patch http://jamielinux.fedorapeople.org/tor/0006-Remove-unnecessary-Requires-on-logrotate-directory.patch http://jamielinux.fedorapeople.org/tor/0007-Use-defaults-torrc-as-recommended-by-upstream.patch http://jamielinux.fedorapeople.org/tor/0008-Change-var-log-tor-permissions-to-match-upstream.patch All of these help to bring the package closer both to our packaging guidelines and upstream defaults and requests. Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tor maintainership
On 27/02/13 18:03, Jamie Nguyen wrote: Hi Enrico, I want to clarify that my whitespace changes were an attempt to make the spec more legible for everyone, not myself. I also feel it would have been nicer for you to ask me to revert the changes rather than reverting them yourself, since I did go through the effort of making the changes and helping you to update and fix the package, but that's just a small suggestion. Anyway, I agree that it would perhaps have been better to split the commit into chunks. Thus, I post below a patch series that includes all the various changes in easily digestible chunks. I just want to clarify here the reasoning for each patch. http://jamielinux.fedorapeople.org/tor/0001-Remove-release_func-macro.patch This custom macro is rather confusing to hard to understand There's no real need for it. http://jamielinux.fedorapeople.org/tor/0002-Cleanup-systemd-macros.patch This custom macro here just makes it harder to read the spec as the bits inside are not in the place that most people would expect. http://jamielinux.fedorapeople.org/tor/0003-Remove-unnecessary-EPEL-5-tags-and-macros.patch Not needed for Fedora 17 and 18. I have adopted your orphaned EPEL 5 and EPEL 6 branches, and I'm fine with these macros not being present in the Fedora specs. http://jamielinux.fedorapeople.org/tor/0004-Unify-core-systemd-and-torify-into-one-package.patch The main tor package is empty. There is no reason for it to be, and no reason for the others to be subpackages. http://jamielinux.fedorapeople.org/tor/0005-Remove-dependency-on-fedora-user-mgmt.patch This is an unnecessary dependency and I see no benefit for it. http://jamielinux.fedorapeople.org/tor/0006-Remove-unnecessary-Requires-on-logrotate-directory.patch This is not required. http://jamielinux.fedorapeople.org/tor/0007-Use-defaults-torrc-as-recommended-by-upstream.patch This will help to make sure some sane defaults are set. This was recommended by upstream. http://jamielinux.fedorapeople.org/tor/0008-Change-var-log-tor-permissions-to-match-upstream.patch This matches the defaults in the upstream RPM packages. The SPEC is also 100 lines shorter :) -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Tor package on the way to awesome, and looking for a re-review
Hello, In the FESCo meeting yesterday (February 27th), it was decided that Enrico Scholz would be removed as maintainer of the tor package, and that I should become the primary maintainer. I am going about fixing the package and bringing it back into shape with the help of co-maintainer Paul Wouters and hopefully with input from upstream. We hope that upstream will be able to stop telling people not to use the Fedora tor packages. Changes so far: http://jamielinux.fedorapeople.org/fix-tor/CHANGELOG http://jamielinux.fedorapeople.org/fix-tor/series/ Because there are so many changes, and in the interests of doing things properly, I've requested for a re-review of the package to make sure the changes are good for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=916627 I've already applied the 20 patch series in git, but before pushing any updates out I want to make sure things really are in good shape, and will make further changes as necessary. Reviewing the latest spec should be quite straightforward, as excluding the changelog it's only 120 lines, compared to the 250 lines is used to be. The package is buildable and installable/upgradable after each patch in the series, so the reviewer may alternatively choose to review each patch individually. Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tor package on the way to awesome, and looking for a re-review
On 28/02/13 14:49, Richard Hughes wrote: On 28 February 2013 14:18, Jamie Nguyen j...@jamielinux.com wrote: I've already applied the 20 patch series in git, but before pushing any updates out I want to make sure things really are in good shape, and will make further changes as necessary. The spec file looks much less batshit-insane now, thanks for doing this. Richard Thanks Richard. I should probably thank you also for the colorhug that arrived last week :) Also I just wanted to make sure people don't interpret the opening paragraphs of my previous email as gloating. My intention was just to inform. It's sad that it had to come to this, and I hope this kind of situation will remain rare. Please also keep any discussions here entirely technical. I'm pretty sure Enrico has received about 10 times his fair share of flames over the years, so I don't think we need to discuss that particular topic any longer. Thanks! -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On 11/03/13 22:57, Richard W.M. Jones wrote: On Mon, Mar 11, 2013 at 03:28:47AM +0100, Kevin Kofler wrote: Lennart Poettering wrote: True thing. libselinux is a library we really really should avoid linking against. Why the sarcasm? SELinux and libselinux only ever cause problems, why can't we finally kick them out of Fedora? This is a tad unfair. SELinux is (more than theoretically) a last line of defence against some exploits, and for at least a few years I've been able to run my laptop with SELinux set to enforcing, only disabling it occasionally to do specific tasks or when investigating permissions problems. Rich. I agree. Years ago pretty much every single Fedora guide would recommend disabling SELinux, but these days (after years of refining the default policy) SELinux is rock solid and usually just stays out of the way. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nodejs-graceful-fs incorrect license, now BSD
License change notification: Upstream specifies in package.json (metadata) that the license is BSD, but has actually been shipping a LICENSE file containing the MIT license. Upstream have now replaced it with the text of the BSD license. The license of the Fedora package has been changed from MIT to BSD accordingly, and contains a copy of the updated LICENSE. Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New avconv instead of ffmpeg
On 04/06/13 08:26, Dario Lesca wrote: About ffmpeg, a Debian's user say: This package contains the deprecated ffmpeg program. This package also serves as a transitional package to libav-tools. Users are advised to use avconv from the libav-tools package instead of ffmpeg. Libav is a complete, cross-platform solution to decode, encode, record, convert and stream audio and video. ffmpeg is not deprecated at all and is still being actively developed. In fact, the upstream MPlayer tarball still contains ffmpeg, not libav. Libav is a fork of ffmpeg that happened early 2011 as some were unhappy with the project leader (Michael Niedermayer). Libav tried to take the ffmpeg trademark/website for themselves, but the owner of the trademark (Fabrice Bellard, original author of ffmpeg) intervened. The two projects are now going their separate ways. One of the members of the libav fork happens to be the maintainer of ffmpeg on Debian/Ubuntu, so he deprecated ffmpeg and spread what some might call misleading information about ffmpeg. Neither ffmpeg or libav seem significantly better or worse than the other, either in features or stability. Certainly neither of them can be considered deprecated projects. I was under the impression that they stopped showing the deprecation message, but it appears I may be wrong. This gives a detailed look at what happened. The author claims objectivity, but I'd take the facts and weigh things for yourself: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html I'm looking for a Fedora's package for libav-tools (or avcomv) ffmpeg can be found in the RPMFusion repository: http://rpmfusion.org/ I don't think libav-tools is in any of our official repositories, though I believe the gstreamer1-libav package uses libav instead of ffmpeg. Most of our other media-related software is built with ffmpeg, not libav. Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
informed decision about whether to update? For many of my previous updates, the message was just update to upstream release 1.2.3, which the user can't use to answer any of the above questions. All of your update messages above seem to satisfy this criteria, so in my eyes they look good :-) Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji down?
On 19/07/13 08:03, Joachim Backes wrote: Getting this when connecting to http://koji.fedoraproject.org/koji --- Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, ad...@fedoraproject.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.15 (Red Hat) Server at koji.fedoraproject.org Port 80 Storage migration http://status.fedoraproject.org/ https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001176.html Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Backslash swallowed by %configure on koji rawhide build
Hi,
The spec in question:
http://jamielinux.fedorapeople.org/strongswan.spec
The lines in question:
%configure --disable-static \
--with-ipsec-script=%{name} \
... snip
Last week build on koji rawhide was fine:
http://koji.fedoraproject.org/koji/buildinfo?buildID=433709
Today, the %configure macro swallowed a backslash linking the next line,
so --with-ipsec-script=%{name} was run as a command:
http://koji.fedoraproject.org/koji/getfile?taskID=5654451name=build.log
Koji builds on f19 and f18 worked fine today with an identical spec.
Tried a scratch build using a triple backslash (\\\) which I've seen
used in some specs but never really understood if it's really needed or
not. It didn't fix the problem though:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5654592
Any ideas?
Kind regards,
--
Jamie Nguyen
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backslash swallowed by %configure on koji rawhide build
On 25/07/13 09:03, Panu Matilainen wrote:
On 07/25/2013 10:52 AM, Jamie Nguyen wrote:
Hi,
The spec in question:
http://jamielinux.fedorapeople.org/strongswan.spec
The lines in question:
%configure --disable-static \
--with-ipsec-script=%{name} \
... snip
Last week build on koji rawhide was fine:
http://koji.fedoraproject.org/koji/buildinfo?buildID=433709
Today, the %configure macro swallowed a backslash linking the next line,
so --with-ipsec-script=%{name} was run as a command:
http://koji.fedoraproject.org/koji/getfile?taskID=5654451name=build.log
Koji builds on f19 and f18 worked fine today with an identical spec.
Tried a scratch build using a triple backslash (\\\) which I've seen
used in some specs but never really understood if it's really needed or
not. It didn't fix the problem though:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5654592
Any ideas?
Looks like breakage caused by the recent libtool-related hardening
hackery in redhat-rpm-config
(https://bugzilla.redhat.com/show_bug.cgi?id=978949)
Ah ok, thanks. I'll just wait it out then. The new build isn't urgent
and the previous build from last week works just fine.
Kind regards,
--
Jamie Nguyen
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GIT development branches for packagers?
On 14/01/14 20:41, Andrew Lutomirski wrote: I have some trivial cleanups I want to make to a package a maintain. These cleanups are trivial enough that I don't think they're worth a new build. Should I commit them to the master branch? If so, I can imagine a couple of issues: - A provenpackager could kick off a rebuild for whatever reason (e.g. dependency soname bump). That will (I think) inadvertently include my changes. - I need to think about whether to add a changelog entry or not. If not, those changes might be included silently. If yes, then I need to think about what to do about the revision number. The normal GIT approach would be to develop on another branch and to merge when I want to build a new revision (the Fedora equivalent of tagging a new release). Should Fedora provide branches like master-devel, f20-devel, etc that store pending changes? Committing spec changes without a subsequent build is a perfectly reasonable thing to do. When doing spec clean-up, I would normally bump the Release tag and add a changelog entry. This is essentially what happens when packages are being reviewed for inclusion in Fedora. -- Jamie Nguyen -- 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: Non-responsive package maintainer (affix)
On 09/10/14 06:28, Brandon Vincent wrote: Over the past month, I have tried contacting Keiran Smith (affix) in regards to nagios with no success [1]. Is anyone aware to his present status in regards to the Fedora Project or possibly have an alternative method to reach him? Strangely, no successful builds from Affix in ~7 years of koji build logs [1], and there are only 4 (trivial) commits from Affix in the git history in July 2013. I think you should probably ignore the fact that Affix happens to be the first point of contact, and instead email peter or jpo who are the active maintainers. [1] http://koji.fedoraproject.org/koji/packageinfo?buildStart=0packageID=2593 -- Jamie Nguyen signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Between a rock and a hard place
Hi! libunwind package is now part of RHEL 7.2. It got retired from EPEL7 three days ago (and incidentally the Release went backwards so upgrade path is broken): https://bugzilla.redhat.com/show_bug.cgi?id=1288313 Unfortunately, that leaves CentOS users in a bit of a pickle, as libunwind is no longer installable (unless they enable CR repository or wait X weeks until CentOS 7.2 is released). NGINX depends on gperftools which depends on libunwind. So NGINX cannot be installed on CentOS: https://bugzilla.redhat.com/show_bug.cgi?id=1289073 I could rebuild NGINX without gperftools as a temporary solution, but that would break NGINX for anyone using the google perftools module. If I don't rebuild, then users can't even install NGINX in the first place. It seems I'm in between a rock and a hard place. By the way, I don't actually plan on rebuilding NGINX without gperftools as that would break it for existing users, and new users can enable CR (but that assumes the user can figure out the solution themselves). So, in the general case of packages being retired from EPEL7 because they have moved to RHEL, how do we avoid missing packages in the future? Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Between a rock and a hard place
On 07/12/15 14:59, Pierre-Yves Chibon wrote: >> So, in the general case of packages being retired from EPEL7 because >> they have moved to RHEL, how do we avoid missing packages in the future? > > Could make a compat package in EPEL7 be an option? > This way you introduce back the version that was present without conflicting > with RHEL. The .so version is exactly the same, so it wouldn't really be a compat package, but more of an exact duplicate. I'm not sure that's desirable? Is there some kind of Red Hat policy for retiring EPEL packages that have been brought to RHEL? If I understand correctly, there would have been no need to retire libunwind so quickly if the upgrade path had been kept intact (ie, the retirement could then at least have been delayed until CentOS 7.2 was released). I'd like to unretire libunwind for EPEL while waiting for CentOS 7.2, but that would break RHEL. So I think what I need to do is wait until the libunwind.rh maintainer has bumped the Release of libunwind.rh, then request for libunwind.el7 to be unretired. But this process may not even complete before CentOS 7.2 is released... thus making it rather pointless. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Between a rock and a hard place
On 07/12/15 15:33, Ken Dreyer wrote: > On Mon, Dec 7, 2015 at 6:44 AM, Jamie Nguyen <j...@jamielinux.com> wrote: >> So, in the general case of packages being retired from EPEL7 because >> they have moved to RHEL, how do we avoid missing packages in the future? > > What is the issue with the CR CentOS repository? It's not enabled by default. Newcomers to CentOS who want NGINX will most likely follow some guide on the Internet that tells them to do this: 1. install CentOS 2. install EPEL 3. install NGINX These newcomers have probably not heard of CR yet, and shouldn't need to know about CR for NGINX to be installable. It's also not obvious when installation fails that CR is the answer. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Between a rock and a hard place
On 08/12/15 08:58, Paul Howarth wrote: > It's not a different version. It's an exact clone of the RHEL package > except with "0." in front of the release to make sure the RHEL package > "wins" where it is available. It is in fact the official EPEL > limited-arch package policy: > > https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages > > The problem this would fix is the broken deps in the window between RHEL > 7.2 and CentoOS 7.2 releases, However, given the amount of time such a > package would take to get pushed to EPEL anyway, it's possible that > CentOS 7.2 would be released before the temporary fix, so it might not > be worth doing at all. Unfortunately, I don't think this is possible until the Red Hat maintainer for libunwind bumps the Release. RHEL = libunwind-1.1-5 EPEL = libunwind-1.1-10 If I introduce libunwind-1.1-0.5 then it doesn't mess up RHEL but it *does* mess up EPEL (where the Release will go backwards from 10 to 0.5). And even if this was desirable, I doubt koji/bodhi would let anyone do something like this (for good reason). Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Between a rock and a hard place
On 08/12/15 16:07, Jamie Nguyen wrote: > Unfortunately, I don't think this is possible until the Red Hat > maintainer for libunwind bumps the Release. > > RHEL = libunwind-1.1-5 > EPEL = libunwind-1.1-10 > > If I introduce libunwind-1.1-0.5 then it doesn't mess up RHEL but it > *does* mess up EPEL (where the Release will go backwards from 10 to > 0.5). And even if this was desirable, I doubt koji/bodhi would let > anyone do something like this (for good reason). Bad news is that the RHEL maintainer got back to me and said that the Release tag will be bumped in the next update push on January 19th. So I gave up on my idea of "unretire libunwind for EPEL once Release is bumped on RHEL". Good news is that I opened a discussion on centos-devel [0] to ask if the libunwind from CentOS-CR could be included in CentOS 7.1 repo, and Johnny Hughes very kindly agreed to put libunwind in CentOS 7.1 Extras repo. It's already on mirror.centos.org and once mirrors sync then NGINX will be installable again (as will ceph which also broke). Hurray! Kind regards, Jamie [0]: https://lists.centos.org/pipermail/centos-devel/2015-December/014101.html -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Automate nag emails for pending ACL/pkgdb requests?
On 23/11/15 14:50, Richard Shaw wrote: > This is not about any particular instance, but browsing around pkgdb for > various reasons I've run across ACL/pkgdb request that haven't gotten > approved (or rejected). I know we all get busy but it's not right to ignore > (intentionally or not) these requests from other packagers. > > Some might be in favor of auto approval after a defined period of > inactivity but what if someone goes on an extended vacation? How long is > too long? > > I think the least disruptive approach would be to start sending nag emails > after a certain period (1 week?). > > Thoughts? I don't think there are any official guidelines about ACL etiquette, but the approach I've always taken before requesting ACLs is to first post a comment on bugzilla or send an email to the owner(s) of the package to ask if they'd be happy, just to be polite. On quite a few occasions I've received an ACL request (or many) out of the blue from a packager I haven't had any associated communication from (via email or bugzilla). I just ignore these requests (and reject eventually after giving them a chance to offer any form of communication). I haven't ever denied anyone commit access that has asked, so I'm certainly not trying to create a wall around "my packages", but I think opening a line of communication (preferably in a public channel such as bugzilla) should be the default. As such, I would be firmly against auto-approval. If the maintainer doesn't respond (via bugzilla or email) to a co-maintainership request and there are for example outstanding bugs then there is a non-responsive maintainer protocol. Kind regards, Jamie -- 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: Automate nag emails for pending ACL/pkgdb requests?
On 23/11/15 16:31, Richard Shaw wrote: > On Mon, Nov 23, 2015 at 9:55 AM, Jamie Nguyen <j...@jamielinux.com> wrote: >> I don't think there are any official guidelines about ACL etiquette, but >> the approach I've always taken before requesting ACLs is to first post a >> comment on bugzilla or send an email to the owner(s) of the package to >> ask if they'd be happy, just to be polite. >> >> On quite a few occasions I've received an ACL request (or many) out of >> the blue from a packager I haven't had any associated communication from >> (via email or bugzilla). I just ignore these requests (and reject >> eventually after giving them a chance to offer any form of communication). > > Perhaps the fix for this is to have a comments field when requesting access > to a package so you can easily do it in one step rather than have to use > something else for the communications part. Is communication that much of a chore? ;-) Requesting ACLs isn't really something the average packager does so many times a day that we need to optimize it with a comment system. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning some python packages
Hi! Sadly, due to lack of time, I've orphaned these 3 packages: rpms/python-ctypesgen -- A pure-python ctypes wrapper generator ( master f24 f23 f22 el6 ) https://admin.fedoraproject.org/pkgdb/package/rpms/python-ctypesgen/ rpms/python-py2neo -- A simple Python library that provides access to Neo4j ( master f24 f23 f22 el6 ) https://admin.fedoraproject.org/pkgdb/package/rpms/python-py2neo/ rpms/python-testify -- A replacement for Python's unittest module and nose ( master f24 f23 f22 el6 ) https://admin.fedoraproject.org/pkgdb/package/rpms/python-testify/ Please feel free to take them! Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning some python packages
On 05/06/16 17:43, Antonio Trande wrote: > I'm taking python-testify. Thanks, Antonio! :-) Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Bodhi error: security updates stuck with no way to request stable
Hi, This update for 3 Nginx CVEs was auto-submitted to stable yesterday: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fd3428577d I got this error message: nginx-1.8.1-1.fc23 ejected from the push because 'Request --RAW HTML NOT ALLOWED-- inconsistent with mash request --RAW HTML NOT ALLOWED--' Now there isn't an option for me to request a push to stable. I notice that this also happened for the Firefox 44 security update that's currently in testing. How do I push this and get these CVEs fixed? (Meanwhile, I also have F22/EL7 updates for the same CVEs that are still waiting to hit testing after 72 hours.) Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Request for advice: Major version update of Nginx on EL5/6/7
On 28/01/16 10:10, Neal Gompa wrote: > I personally think you should. EPEL isn't supposed to unreasonably > hold back when even the upstream project no longer maintains that > version. As long as all consumers of the nginx package are > appropriately updated (if necessary) and the transition notes are > documented, I don't see why not. However, the problem really comes in > with how to do get people to read the upgrade notes, as that's pretty > much the only way to make that work. There isn't any way to ensure users read upgrade notes, except between new versions of Fedora/RHEL (as major changes would be expected). This will inevitably bite someone when their Nginx configuration isn't valid after the update, which could for example be via yum-cron. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bodhi error: security updates stuck with no way to request stable
On 29/01/16 07:24, Adam Williamson wrote: > I think it was a releng snafu. From #fedora-releng today: > > masta / lmacken: tons of ejected from push messages. Perhaps because > you did one and another one right away or something? > nirik: yeah, most likely > * lmacken should have suggested doing `bodhi-push --builds > openssl-1.0.2f-1.fc23` instead > > so, I'm guessing they're on it... Ah, I didn't realise this channel existed. It's wasn't listed on the wiki page below but I've added it now: https://fedoraproject.org/wiki/Communicating_and_getting_help#Administration Also, in hindsight, I should probably have opened a ticket on the releng trac instead of posting to fedora-devel. Remi has opened one already for the same problem: https://fedorahosted.org/rel-eng/ticket/6344 Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Request for advice: Major version update of Nginx on EL5/6/7
On 28/01/16 19:00, Kevin Fenzi wrote: > Well, this kind of question would probibly be better on the epel-devel > list Ah, I forgot about epel-devel. > And you can ask for an exception. This would entail pushing the new > version to testing and leaving it there a while, mailing epel-announce > to note that there's an incompatible version in testing and please test > and then another note before you push it stable to give them a heads > up. You may want to wait and push it stable at the same time as the > next .X release comes out. This sounds like a reasonable plan. It will be a big change for EL6, and a spectacularly big change for EL5 (jumping forward 5 major versions, assuming it will even compile), so a very prolonged period in epel-testing will be essential. Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Request for advice: Major version update of Nginx on EL5/6/7
Hi, Distributions like RHEL and Debian have a very strict update policy (for good reason). People expect stability and don't want surprises. When CVEs arise, patches can often be backported. Nginx 1.8.1 recently fixed three CVEs and I've backported to Nginx 1.6.x on EL7. Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but backporting the patches reliably without creating new CVEs is beyond my expertise. Nginx 0.8.x on EL5 is prehistoric. I've had a couple of bug reports recently suggesting that I rebase Nginx to 1.8.1 on all branches. On the one hand, I want to avoid causing surprises and breaking somebody's website. On the other hand, these vulnerabilities do need to be fixed. (The approach I took with the Tor package is to always use the latest stable release on all branches, which is working well.) What do people think? Should I go ahead and update all branches (with appropriate migration notes)? Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Request for karma: Nginx CVEs
Hi all, Three CVEs were fixed in Nginx 1.8.1. I'd be very grateful for some karma for the following updates. (I pushed updates for them yesterday, but unfortunately the RPMs still haven't hit updates-testing so you'll have to manually download the nginx.rpm and nginx-filesystem.rpm from koji.) F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fd3428577d http://koji.fedoraproject.org/koji/buildinfo?buildID=713957 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bf03932bb3 http://koji.fedoraproject.org/koji/buildinfo?buildID=713959 EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f17c082f00 http://koji.fedoraproject.org/koji/buildinfo?buildID=713981 Kind regards, Jamie -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Guidelines for scriptlets modifying %config(noreplace) files
Hi Jason, Thanks for that :-) Sounds like I don't need to file a bug report. (Though I guess I'll be watching ansible runs more closely, since /etc seems to be fair game.) Kind regards, -- Jamie Nguyen ___ 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
Guidelines for scriptlets modifying %config(noreplace) files
Hi, I noticed on an Ansible run that a recent update to bind changed /etc/named.conf directly, instead of creating a separate rpmnew file. (It's running sed in a scriptlet.) I couldn't find clear packaging policy on this. The guidelines [0] talk about %config(noreplace) vs %config, but /etc/named.conf is installed as a "noreplace" file. I've not really been a particularly active packager in a long time so I could be wrong, but my expectation was that you're not meant to edit "noreplace" files in scriptlets. I was sure this must be in the guidelines somewhere? [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_configuration_files Kind regards, -- Jamie Nguyen ___ 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)
Hi Joe, On 01/11/2019 07:06, Joe Orton wrote: > 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! That's such a kind message! You've made my week. Thank you :-) I do hope to be a regular contributor again one day, in one capacity or another. Kind regards, -- Jamie Nguyen ___ 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
Stepping away from packaging (and request for owners)
imist: 7 nodejs-opts: 1 nodejs-osenv: 1 nodejs-package: 1 nodejs-paperboy: 1 nodejs-parseurl: 4 nodejs-pause: 1 nodejs-pkginfo: 4 nodejs-pretty-bytes: 1 nodejs-promise: 3 nodejs-proto-list: 1 nodejs-pubcontrol: 1 nodejs-q: 12 nodejs-qs: 5 nodejs-range-parser: 1 nodejs-raw-body: 1 nodejs-read: 2 nodejs-readdirp: 1 nodejs-read-package-json: 1 nodejs-reduce-component: 1 nodejs-repl: 1 nodejs-require-cs: 1 nodejs-requirejs: 2 nodejs-resolve: 7 nodejs-retry: 1 nodejs-revalidator: 1 nodejs-rimraf: 12 nodejs-runforcover: 1 nodejs-sax: 3 nodejs-semver: 9 nodejs-showdown: 2 nodejs-slide: 2 nodejs-snockets: 1 nodejs-source-map: 13 nodejs-stack-trace: 1 nodejs-stream-counter: 1 nodejs-strip-ansi: 5 nodejs-tar: 2 nodejs-through: 6 nodejs-tiny-lr-fork: 1 nodejs-transformers: 1 nodejs-traverse: 3 nodejs-tunnel-agent: 1 nodejs-uglify-to-browserify: 1 nodejs-uid-number: 1 nodejs-underscore-dot-string: 2 nodejs-url2: 1 nodejs-weak-map: 1 nodejs-websocket-driver: 1 nodejs-which: 6 nodejs-wordwrap: 3 nodejs-yamlish: 1 nodejs-zlibjs: 1 uglify-js1: 6 [e]: Need owner, listed as BuildRequires jasmine-node: 4 nodejs-grunt-contrib-clean: 1 nodejs-grunt-contrib-concat: 1 nodejs-grunt-contrib-uglify: 1 nodejs-ronn: 2 nodejs-supertest: 1 ycssmin: 1 = [f]: Need owner, not listed as Requires/BuildRequires = compat-libuv010 docco expresso js-jquery-migrate js-json nodejs-ain2 nodejs-archy nodejs-aws-sign nodejs-basic-auth-connect nodejs-child-process-close nodejs-chmodr nodejs-chownr nodejs-compressible nodejs-compression nodejs-config-chain nodejs-connect nodejs-connect-timeout nodejs-console-dot-log nodejs-cookie-jar nodejs-cookie-parser nodejs-couch-login nodejs-cssom nodejs-csurf nodejs-dryice nodejs-editor nodejs-errorhandler nodejs-expect-dot-js nodejs-express-session nodejs-fileset nodejs-fstream-npm nodejs-github-url-from-git nodejs-grip nodejs-grunt-compare-size nodejs-grunt-git-authors nodejs-grunt-lib-contrib nodejs-i nodejs-init-package-json nodejs-iso8601 nodejs-isodate nodejs-joosex-namespace-depended nodejs-jscoverage nodejs-jsonfile nodejs-keypress nodejs-lazystream nodejs-lockfile nodejs-ltx nodejs-method-override nodejs-morgan nodejs-muffin nodejs-multiparty nodejs-negotiator nodejs-node-int64 nodejs-normalize-package-data nodejs-npmconf nodejs-npm-registry-client nodejs-npm-user-validate nodejs-opener nodejs-promzard nodejs-q-io nodejs-read-installed nodejs-response-time nodejs-scmp nodejs-serve-index nodejs-serve-static nodejs-setimmediate nodejs-sigmund nodejs-static-favicon nodejs-stylus nodejs-temporary nodejs-testswarm nodejs-underscore-dot-logger nodejs-vhost nodejs-watchit nodejs-zlib-browserify web-assets == [g]: Sent emails to co-maintainers == lua-event (robert) node-gyp (tomh) nodejs-argparse (jsmith) nodejs-cli (jsmith) nodejs-colors (jsmith) nodejs-concat-stream (tomh) nodejs-constantinople (tomh) nodejs-debug (piotrp) nodejs-dep-graph (tomh) nodejs-detective (piotrp) nodejs-escodegen (piotrp) nodejs-esprima (jsmith) nodejs-esutils (piotrp) nodejs-express (tomh) nodejs-fs-extra (tomh) nodejs-globule (tomh) nodejs-graceful-fs (tomh) nodejs-grunt (piotrp) nodejs-grunt-cli (tomh) nodejs-grunt-contrib-internal (piotrp) nodejs-grunt-contrib-watch (piotrp) nodejs-grunt-init (piotrp) nodejs-i2c (tomh) nodejs-iconv-lite (tomh) nodejs-jade (jsmith) nodejs-libxmljs (tomh) nodejs-load-grunt-tasks (tomh) nodejs-lodash (tomh) nodejs-lru-cache (jsmith) nodejs-merge-descriptors (tomh) nodejs-mkdirp (jsmith) nodejs-monocle (tomh) nodejs-multimatch (tomh) nodejs-nan (tomh) nodejs-node-expat (tomh) nodejs-node-stringprep (tomh) nodejs-once (jsmith) nodejs-pg (tomh) nodejs-prompt (tomh) nodejs-request (tomh) nodejs-send (tomh) nodejs-should (tomh) nodejs-sntp (jsmith) nodejs-superagent (piotrp) nodejs-tape (tomh) nodejs-temp (piotrp) nodejs-underscore (dcallagh) nodejs-utile (piotrp) nodejs-vows (tomh) nodejs-winston (piotrp) nodejs-with (tomh) -- Jamie Nguyen ___ 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)
I've been responding privately to people stepping up, to reduce noise. Thank you to everyone who has volunteered so far :-) FYI, nginx and tor/torsocks have new owners now. Felix (heffer) and Marcel (maha) respectively. Kind regards, -- Jamie Nguyen ___ 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)
Of course, just after I post, I find I've somehow missed three packages: These go in list [d] (depended on by other packages at runtime): nodejs-shelljs: 4 nodejs-walkdir: 1 This goes in list [f] (not depended on by anything): nodejs-sha Kind regards, -- Jamie Nguyen ___ 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 215 packages
Hi, This is a follow up for this post: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RR2KB64SGUM7IJKBSQORQGZGUSROPFHD/ Below are the packages I've orphaned. See section [d] of the linked email to see how many times each package is listed as Requires by something else. Most are Node.js packages, some still maintained via the 'nodejs-sig' user, though 'nodejs-sig' can't own packages so I orphaned instead. - compat-libuv010 - CutyCapt - dateformat - expresso - jasmine-node - js-json - js-zlib - marked - mocha - nodejs-abbrev - nodejs-ain2 - nodejs-ansi - nodejs-ansi-styles - nodejs-archy - nodejs-asap - nodejs-asn1 - nodejs-assertplus - nodejs-async - nodejs-aws-sign - nodejs-basic-auth-connect - nodejs-batch - nodejs-better-assert - nodejs-bindings - nodejs-block-stream - nodejs-boom - nodejs-buffer-crc32 - nodejs-buffer-equal - nodejs-bunker - nodejs-burrito - nodejs-bytes - nodejs-callsite - nodejs-chalk - nodejs-character-parser - nodejs-charm - nodejs-child-process-close - nodejs-chmodr - nodejs-chownr - nodejs-cmd-shim - nodejs-combined-stream - nodejs-commander - nodejs-component-emitter - nodejs-config-chain - nodejs-connect-timeout - nodejs-console-dot-log - nodejs-cookie - nodejs-cookiejar - nodejs-cookie-jar - nodejs-cookie-parser - nodejs-cookie-signature - nodejs-couch-login - nodejs-cryptiles - nodejs-css - nodejs-cssom - nodejs-css-parse - nodejs-css-stringify - nodejs-csurf - nodejs-ctype - nodejs-cycle - nodejs-debug - nodejs-defined - nodejs-delayed-stream - nodejs-detective - nodejs-diff - nodejs-dryice - nodejs-editor - nodejs-ejs - nodejs-escodegen - nodejs-estraverse - nodejs-esutils - nodejs-eventemitter2 - nodejs-exit - nodejs-expect-dot-js - nodejs-express-session - nodejs-faye-websocket - nodejs-fileset - nodejs-findup-sync - nodejs-forever-agent - nodejs-form-data - nodejs-formidable - nodejs-fresh - nodejs-fstream - nodejs-fstream-ignore - nodejs-fstream-npm - nodejs-generic-pool - nodejs-getobject - nodejs-github-url-from-git - nodejs-glob - nodejs-grip - nodejs-growl - nodejs-grunt-compare-size - nodejs-grunt-contrib-concat - nodejs-grunt-contrib-internal - nodejs-grunt-contrib-uglify - nodejs-grunt-contrib-watch - nodejs-grunt-git-authors - nodejs-gzip-size - nodejs-has-color - nodejs-hawk - nodejs-hoek - nodejs-hooker - nodejs-http-signature - nodejs-inherits1 - nodejs-ini - nodejs-iso8601 - nodejs-isodate - nodejs-jasmine-reporters - nodejs-joose - nodejs-joosex-namespace-depended - nodejs-joosex-simplerequest - nodejs-jscoverage - nodejs-jsonfile - nodejs-jsonify - nodejs-json-stringify-safe - nodejs-js-yaml - nodejs-jwt-simple - nodejs-keypress - nodejs-lazystream - nodejs-lockfile - nodejs-markdown - nodejs-maxmin - nodejs-methods - nodejs-mime - nodejs-mimeparse - nodejs-minimatch - nodejs-minimist - nodejs-morgan - nodejs-ms - nodejs-muffin - nodejs-multiparty - nodejs-mute-stream - nodejs-nan0 - nodejs-ncp - nodejs-node-int64 - nodejs-node-uuid - nodejs-nopt - nodejs-noptify - nodejs-npmlog - nodejs-npm-user-validate - nodejs-oauth-sign - nodejs-opener - nodejs-optimist - nodejs-opts - nodejs-osenv - nodejs-package - nodejs-paperboy - nodejs-parseurl - nodejs-pause - nodejs-pkginfo - nodejs-pretty-bytes - nodejs-promise - nodejs-promzard - nodejs-proto-list - nodejs-pubcontrol - nodejs-qs - nodejs-range-parser - nodejs-read - nodejs-readdirp - nodejs-read-package-json - nodejs-reduce-component - nodejs-repl - nodejs-require-cs - nodejs-requirejs - nodejs-resolve - nodejs-response-time - odejs-response-time rpms - nodejs-retry - nodejs-rimraf - nodejs-ronn - nodejs-runforcover - nodejs-sax - nodejs-semver - nodejs-serve-index - nodejs-setimmediate - nodejs-sha - nodejs-shelljs - nodejs-showdown - nodejs-sigmund - nodejs-slide - nodejs-source-map - nodejs-stack-trace - nodejs-static-favicon - nodejs-stream-counter - nodejs-strip-ansi - nodejs-superagent - nodejs-supertest - nodejs-tar - nodejs-temp - nodejs-temporary - nodejs-testswarm - nodejs-through - nodejs-tiny-lr-fork - nodejs-transformers - nodejs-traverse - nodejs-tunnel-agent - nodejs-uglify-to-browserify - nodejs-uid-number - nodejs-underscore - nodejs-underscore-dot-string - nodejs-utile - nodejs-vhost - nodejs-walkdir - nodejs-weak-map - nodejs-websocket-driver - nodejs-which - nodejs-wordwrap - nodejs-yamlish - nodejs-zlib-browserify - nodejs-zlibjs - uglify-js1 - web-assets Kind regards, Jamie ___ 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 215 packages
Also orphaned after speaking with co-maintainers: - ycssmin Kind regards, Jamie ___ 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 og my nodejs packages
Hi Tom, Thank you for your tireless nodejs packaging over the years! I vaguely recall trading tens and tens of nodejs package reviews with you back when Fedora's nodejs ecosystem was rapidly growing. Kind regards, -- Jamie Nguyen jamielinux.com ___ 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
Bugzilla Assignee
Hi, I was wondering if someone could help me. I stopped (co-)maintaining weechat and adobe-source-code-pro-fonts several years ago, but I discovered I'm still listed as the Bugzilla Assignee for EPEL on both packages [1][2] despite not have commit access. (FAS username: jamielinux) I contacted the current maintainers 3 months ago but didn't get a response so I thought I'd try here. Could someone please set the Bugzilla Assignee for EPEL for both packages to match the main Bugzilla Assignee? Thank you! [1]: https://src.fedoraproject.org/rpms/weechat [2]: https://src.fedoraproject.org/rpms/adobe-source-code-pro-fonts Kind regards, Jamie ___ 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: Bugzilla Assignee
Miro Hrončok wrot Done. But maybe the Fedora maintainers were never interested in EPEL? Should the assignee be set to orphan instead? Thanks Miro! The main assignees for both packages have pushed EPEL builds before, so they have at least had interest in the past. -- Jamie Nguyen ___ 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: Bugzilla Assignee
Ben Cotton wrote: On Tue, Jul 5, 2022 at 2:34 AM Jamie Nguyen wrote: Could someone please set the Bugzilla Assignee for EPEL for both packages to match the main Bugzilla Assignee? It looks like you're still the EPEL assignee in dist-git. I could make the change in Bugzilla, but it will get reset the next time dist-git syncs. I suggest filing a ticket with Release Engineering to get that updated: https://pagure.io/releng/issues Hi Ben, Thanks for the recommendation :-) I have opened a ticket. -- Jamie Nguyen ___ 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
[EPEL-devel] Exception request: major version bump for Nginx
Hi, A few days ago, three CVEs for Nginx and were fixed in 1.8.1. Upstream only maintain 1.8.x and above, so they didn't release any fixes for older versions of Nginx. I was able to backport the relevant commits to Nginx 1.6.x on EL7. Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but backporting the patches reliably without creating new CVEs is beyond my expertise. Nginx 0.8.x on EL5 is prehistoric. This leaves the package in a bit of a pickle. Leaving things as they are would leave web servers vulnerable. On the other hand, updating Nginx to 1.8.x on EL5/6/7 will inevitably break something for someone (eg, via yum-cron). I had a small discussion on fedora-devel ML about the situation [0], and the consensus was to request for an exception. My plan: 1. Update to 1.8.x on all branches (or to as recent a version as they can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce. Sound reasonable? [0]: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VFCIBCTGIYMVJCCUE3ZQVAARVHUF3YPP/ Kind regards, Jamie ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Exception request: major version bump for Nginx
On 29/01/16 14:56, Stephen John Smoogen wrote: > Thank-you for your request. I think that this is a good candidate for a > break in all three channels. I will try to get enough EPSco people to look > at this and give feedback while we are at FOSDEM. Hope to have a +1 for you > soon Awesome. Thanks! Kind regards, Jamie ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Exception request: major version bump for Nginx
On 28/04/16 06:28, Anssi Johansson wrote: > This change to the plans was discussed briefly in yesterday's EPEL > Steering Committee meeting, and we're OK with updating straight to 1.10.x. > > I believe there are a number of people who are interested in HTTP/2 > support, so please do go on with this plan. Excellent, thanks. Kind regards, -- Jamie Nguyen ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Major Nginx update for EL7, EL6, EL5
of the "charset_types" directive was changed accordingly. *) Change: now the "image_filter" directive with the "size" parameter returns responses with the "application/json" MIME type. *) Change in internal API: now u->length defaults to -1 if working with backends in unbuffered mode. *) Change: now after receiving an incomplete response from a backend server nginx tries to send an available part of the response to a client, and then closes client connection. Changes with nginx 1.4.x *) Change: opening and closing a connection without sending any data in it is no longer logged to access_log with error code 400. *) Change: a compiler with name "cc" is now used by default. *) Change: domain names specified in configuration file are now resolved to IPv6 addresses as well as IPv4 ones. *) Change: now if the "include" directive with mask is used on Unix systems, included files are sorted in alphabetical order. *) Change: the "add_header" directive adds headers to 201 responses. *) Change: the ngx_http_mp4_module module no longer skips tracks in formats other than H.264 and AAC. *) Change: the "ipv6only" parameter is now turned on by default for listening IPv6 sockets. *) Change: the "single" parameter of the "keepalive" directive is now ignored. *) Change: SSL compression is now disabled when using all versions of OpenSSL, including ones prior to 1.0.0. Changes with nginx 1.2.x *) Change: now if the "include" directive with mask is used on Unix systems, included files are sorted in alphabetical order. *) Change: the "add_header" directive adds headers to 201 responses. *) Change: the "single" parameter of the "keepalive" directive is now ignored. *) Change: SSL compression is now disabled when using all versions of OpenSSL, including ones prior to 1.0.0. *) Change: keepalive connections are no longer disabled for Safari by default. *) Change: the simultaneous subrequest limit has been raised to 200. *) Change: a "proxy_pass" directive without URI part now uses changed URI after redirection with the "error_page" directive. Thanks to Lanshun Zhou. *) Change: now double quotes are encoded in an "echo" SSI-command output. Thanks to Zaur Abasmirzoev. *) Change: the ngx_http_limit_zone_module was renamed to the ngx_http_limit_conn_module. *) Change: the "limit_zone" directive was superseded by the "limit_conn_zone" directive with a new syntax. *) Change in internal API: now module context data are cleared while internal redirect to named location. Requested by Yichun Zhang. *) Change: if a server in an upstream failed, only one request will be sent to it after fail_timeout; the server will be considered alive if it will successfully respond to the request. *) Change: now the 0x7F-0x1F characters are escaped as \xXX in an access_log. *) Change: now if total size of all ranges is greater than source response size, then nginx disables ranges and returns just the source response. *) Change: now cache loader processes either as many files as specified by "loader_files" parameter or works no longer than time specified by the "loader_threshold" parameter during each iteration. *) Change: now SIGWINCH signal works only in daemon mode. Changes with nginx 1.0.x *) Change: now double quotes are encoded in an "echo" SSI-command output. Thanks to Zaur Abasmirzoev. *) Change: now the 0x7F-0x1F characters are escaped as \xXX in an access_log. *) Change: now SIGWINCH signal works only in daemon mode. *) Change: now if total size of all ranges is greater than source response size, then nginx disables ranges and returns just the source response. *) Change: now default SSL ciphers are "HIGH:!aNULL:!MD5". Thanks to Rob Stradling. *) Change: now regular expressions case sensitivity in the "map" directive is given by prefixes "~" or "~*". *) Change: now the "split_clients" directive uses MurmurHash2 algorithm because of better distribution. Thanks to Oleg Mamontov. *) Change: now long strings starting with zero are not considered as false values. Thanks to Maxim Dounin. *) Change: now nginx uses a default listen backlog value 511 on Linux. *) Change: now nginx uses a default listen backlog value -1 on Linux. Thanks to Andrei Nigmatulin. *) Change: the "secure_link_expires" directive has been canceled. *) Change: a logging level of resolver errors has been lowered from "alert" to "error". Kind regards, -- Jamie Nguyen ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
