Re: Specs using %define
Jason L Tibbitts III writes: > baekmuk-bdf-fonts (ueno) > baekmuk-ttf-fonts (ueno) > ibus-gucharmap (ueno) > un-core-fonts (ueno) > un-extra-fonts (ueno) Done in rawhide. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2016-01-07 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2016-01-07 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2016-01-07 09:00 Thu US/Pacific PST 2016-01-07 12:00 Thu US/Eastern EST 2016-01-07 17:00 Thu UTC <- 2016-01-07 17:00 Thu Europe/London <- 2016-01-07 18:00 Thu Europe/Paris CET 2016-01-07 18:00 Thu Europe/Berlin CET 2016-01-07 22:30 Thu Asia/Calcutta IST --new day-- 2016-01-08 01:00 Fri Asia/Singapore SGT 2016-01-08 01:00 Fri Asia/Hong_Kong HKT 2016-01-08 02:00 Fri Asia/Tokyo JST 2016-01-08 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #558 Application/Library distinction and package splitting .fpc 558 https://fedorahosted.org/fpc/ticket/558 #topic #566 RPM file triggers .fpc 566 https://fedorahosted.org/fpc/ticket/566 #topic #567 Packaging Python 3 applications and modules for EPEL 7+ .fpc 567 https://fedorahosted.org/fpc/ticket/567 #topic #580 [Clarification] Policy on auto-generated code .fpc 580 https://fedorahosted.org/fpc/ticket/580 = New business = #topic #584 Update to latest AppData specification .fpc 584 https://fedorahosted.org/fpc/ticket/584 #topic #585 Blanket reauth. of bootstrapping exceptions (Free Pascal Compiler, atm.) .fpc 585 https://fedorahosted.org/fpc/ticket/585 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
On 01/06/2016 12:42 PM, Marcin Juszkiewicz wrote: > On środa, 6 stycznia 2016 09:31:01 CET Orion Poplawski wrote: >> I've created a "scitech" FAS and COPR group for the SciTech SIG >> (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate >> goal is to create some common repositories for updated builds of >> scientific software for EL7 (& 6). My thought is to have a have common >> repository (https://copr.fedoraproject.org/coprs/g/scitech/common/) for >> updated libraries, then individual repositories for updated programs >> like octave, julia, etc. > > Why COPR instead of EPEL? > > EPEL is part of Fedora package git tree, all extra stuff from Fedora is > available in one place... > > For me COPR is good solution for tests before package lands in Fedora (or > EPEL). Oh yeah, I already maintain quite a lot for EPEL. However, EPEL guidelines forbid major/disruptive updates, so this would be for such things as Octave 4. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
On 01/06/2016 12:52 PM, Corey Sheldon wrote: > Orion, > > FAS: corey84 please add me as well Done. I've turned off Invite only in the group, so people can now sign up directly via FAS. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
Orion, FAS: corey84 please add me as well Corey W Sheldon ph: +1 (310).909.7672 Freelance IT Consultant, Multi-Discipline Tutor cshel...@ameridea.net core...@fedoraproject.org linuxmod...@keybase.io Ameridea LLC, Founder, CTO Fedora Ambassador, North America Server Team Intern, City-Gate https://github.com/ameridea https://getfedora.org https://city-gate.org Find me elsewhere: https://gist.github.com/linux-modder/ac5dc6fa211315c633c9 PGP: 0xCe2ad4c03a9eff1c FP= ba7e aeba 7c64 1eca f4b9 70a8 ce2a d4c0 3a9e ff1c PGP: 0x76ef54b9aed032e2 FP= 984e 1693 de66 2109 596c 0930 76ef 54b9 aed0 32e2 Tox: core...@toxme.io | 9357bc6a5944a08afc7d1effd61f6a73b9eabf8b2fb84acf1dac9a1a4d0a4705ffccd0e5499b Linphone: sip:linuxmodder BitAddress:15cn1BvAFEREHk8UekJ6i9Dxi9Wbw6vzDD "Have no way as way, no limitation as limitation. One must never underestimate the power of boredom...from which creativity and laziness are borne, which can spark great works of chaos and genius." On Wed, Jan 6, 2016 at 2:42 PM, Marcin Juszkiewicz wrote: > On środa, 6 stycznia 2016 09:31:01 CET Orion Poplawski wrote: > > I've created a "scitech" FAS and COPR group for the SciTech SIG > > (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate > > goal is to create some common repositories for updated builds of > > scientific software for EL7 (& 6). My thought is to have a have common > > repository (https://copr.fedoraproject.org/coprs/g/scitech/common/) for > > updated libraries, then individual repositories for updated programs > > like octave, julia, etc. > > Why COPR instead of EPEL? > > EPEL is part of Fedora package git tree, all extra stuff from Fedora is > available in one place... > > For me COPR is good solution for tests before package lands in Fedora (or > EPEL). > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
On środa, 6 stycznia 2016 09:31:01 CET Orion Poplawski wrote: > I've created a "scitech" FAS and COPR group for the SciTech SIG > (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate > goal is to create some common repositories for updated builds of > scientific software for EL7 (& 6). My thought is to have a have common > repository (https://copr.fedoraproject.org/coprs/g/scitech/common/) for > updated libraries, then individual repositories for updated programs > like octave, julia, etc. Why COPR instead of EPEL? EPEL is part of Fedora package git tree, all extra stuff from Fedora is available in one place... For me COPR is good solution for tests before package lands in Fedora (or EPEL). -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Bug 1291095] Nonresponsive maintainer: jpo
https://bugzilla.redhat.com/show_bug.cgi?id=1291095 --- Comment #4 from Denis Fateyev --- Seems, the rubber hit the road there, and updates have been pushed to testing. Jose, could you confirm my previous commit requests for these packages anyway? I'd like to co-maintain them in order that we won't run into the same update issue with these packages in the future. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainer - jklimes
On Wed, 2016-01-06 at 10:51 -0700, Kevin Fenzi wrote: > On Wed, 06 Jan 2016 09:46:32 -0600 > Dan Williams wrote: > > > On Tue, 2016-01-05 at 17:07 -0700, Kevin Fenzi wrote: > > > Greetings, we've been told that the email addresses > > > for this package maintainer is no longer valid. I'm starting the > > > unresponsive maintainer policy to find out if they are still > > > interested > > > in maintaining their packages (and if so, have them update their > > > email > > > addresses in FAS). If they're not interested in maintaining or > > > we > > > can't locate them I'll have FESCo orphan the packages so that > > > others > > > can take them over. > > > > > > If you have a way to contact this maintainer, please let them > > > know that we'd appreciate knowing what to do with their packages. > > > Thanks! > > > > > > * jklimes - former email: jkli...@redhat.com > > > > Jirka last day with Red Hat was right before the holidays (he'll be > > missed), so yes this email is no longer active. I'll ask him if > > he'd > > like to continue maintaining packages, but that would of course > > involve an email change to his personal one anyway. We might as > > well > > remove jklimes@rh from package maintainership. > > ok. Do you want me to set the point of contact to you on that > package? Actually Lubomir Rintel should get it, he should be on all the other packages too. Dan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ca-legacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2016 11:23 AM, Michael Catanzaro wrote: > Hi, > > Is any important software (e.g. openssl, gnutls, glib-networking, > Qt) in Fedora still relying on our legacy 1024-bit root RSA > certificates? > > I believe Fedora is currently the only distro currently shipping > these insecure root certificates. Originally, this was a good > choice (and big thanks to Kai Engert for making it happen) because > they were needed for compatibility with software using OpenSSL or > GLib sockets. Nowadays, I'm not aware of any software that still > needs them. > > Since keeping these certificates around is a serious security > issue, I propose we remove them if nothing "important" still needs > them. > > You can test if any of your software needs these certificates by > running 'sudo ca-legacy disable'. > Well, the problem was never software that Fedora was shipping. The problem is Fedora *as a client*. There are unfortunately many websites out there that are still signed by insecure certificates. We certainly need to choose a sunset date to stop shipping those insecure CAs, but unfortunately we can't force everyone in the world to switch to sane certificates. (Realistically, this won't change until 6-12 months after Google Chrome, Microsoft Internet Explorer and Apple Safari all eliminate those CAs). I don't have any information on if or when this will happen, but that's just about the only way that website admins will suddenly care enough to fix things. (It would also be nice if the CA issuers would be kinder about just reissuing existing certificates without a fee, but they aren't...) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlaNVUoACgkQeiVVYja6o6OnuACfUoTJvME2cRMBNIvDv4gEpy57 9HoAnAwSDYQU+wkDsBF/VeQMZ0QJcW8d =qWyf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainer - jklimes
On Wed, 06 Jan 2016 09:46:32 -0600 Dan Williams wrote: > On Tue, 2016-01-05 at 17:07 -0700, Kevin Fenzi wrote: > > Greetings, we've been told that the email addresses > > for this package maintainer is no longer valid. I'm starting the > > unresponsive maintainer policy to find out if they are still > > interested > > in maintaining their packages (and if so, have them update their > > email > > addresses in FAS). If they're not interested in maintaining or we > > can't locate them I'll have FESCo orphan the packages so that others > > can take them over. > > > > If you have a way to contact this maintainer, please let them > > know that we'd appreciate knowing what to do with their packages. > > Thanks! > > > > * jklimes - former email: jkli...@redhat.com > > Jirka last day with Red Hat was right before the holidays (he'll be > missed), so yes this email is no longer active. I'll ask him if he'd > like to continue maintaining packages, but that would of course > involve an email change to his personal one anyway. We might as well > remove jklimes@rh from package maintainership. ok. Do you want me to set the point of contact to you on that package? Just let me know what you want to do and I can sort out the pkgdb side. kevin pgp7P2dBo66tM.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Suds Jurko Fork
On Wed, 6 Jan 2016, Vít Ondruch wrote: Chandan did contact him a while ago and I confirm that he did not receive any answer. Since maintainer is inactive for a while, I was thinking about doing the update as provenpackager after a reasonable delay. I think this whole thread is more something for the Nonresponsive Maintainer Process than for the Change Process. Sure, the fact that the package maintainer isn't active is something for the Nonresponsive Maintainer Process. This 'Change', though, is really about moving a package to a fork, which I thought was something that deserved wider attention and community input. Wouldn't be better to merge the fork back to upstream? Since from the response from the original author, one would say that he is not interested in maintenance anymore. Upstream is also unmaintained (for ~4 years). The Fedora maintainer is also the upstream maintainer. Scott-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Suds Jurko Fork
Dne 6.1.2016 v 17:50 Scott Talbert napsal(a): > On Wed, 6 Jan 2016, Kevin Kofler wrote: > >>> Chandan did contact him a while ago and I confirm that he did not >>> receive any answer. >>> Since maintainer is inactive for a while, I was thinking about doing >>> the update as provenpackager after a reasonable delay. >> >> I think this whole thread is more something for the Nonresponsive >> Maintainer >> Process than for the Change Process. > > Sure, the fact that the package maintainer isn't active is something > for the Nonresponsive Maintainer Process. > > This 'Change', though, is really about moving a package to a fork, > which I thought was something that deserved wider attention and > community input. Wouldn't be better to merge the fork back to upstream? Since from the response from the original author, one would say that he is not interested in maintenance anymore. Vít -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/06/2016 05:44 PM, Orion Poplawski wrote: > On 01/06/2016 09:39 AM, Antonio Trande wrote: >> On 01/06/2016 05:31 PM, Orion Poplawski wrote: >>> I've created a "scitech" FAS and COPR group for the SciTech SIG >>> (https://fedoraproject.org/wiki/Category:SciTech_SIG). My >>> immediate goal is to create some common repositories for >>> updated builds of scientific software for EL7 (& 6). My >>> thought is to have a have common repository >>> (https://copr.fedoraproject.org/coprs/g/scitech/common/) for >>> updated libraries, then individual repositories for updated >>> programs like octave, julia, etc. >>> >>> I'm starting off with a suitesparse44 package that is split >>> into individual libararies and can hopefully be installed in >>> parallel with the system suitesparse. >>> >>> Add yourself to >>> https://admin.fedoraproject.org/accounts/group/view/scitech if >>> you want to join the effort. >>> >> I wish to join; do I need an invitation? >> > > I'm honestly not sure. I know I need to approve members but I > thought people could request it themselves via the above web page. > If you can't, tell me your fas name and I'll add it. > I can't; my FAS is sagitter. Thanks. - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x565E653C Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWjUYoAAoJEF5tK7VWXmU8jQsH/RFZuW7FehWAO0m7ovCUZtMF gAgHmKhoVZhVh0zKdJrM7Uh4ZZfIzSj8UrqJ9MpGrTfB3JtkmbwDonhAxrJ23SWp Eh5MfE6Y0riH9RfJmatOvyy1qA9DMt9JBtPxhikcXqIT/TgqKBS/Hf8VSHPDuLGK HpB8yKrQI8/pIvWwfqvkm5vNXYSaroGu8FzOEeRl8f16GS93Nh67GTovyBqpmz73 P6+mpO3nLV4CcLKa9F0MYpXouKTsIBhFA1opfOSbFTuwkfgSwPyGnlnku4Ga6JCN pOCh2hR+1EnI0rd8aBRqDhagiEr8eJlYp5ORlTeMw8leJHP0lNvngDOIDLYpElM= =A2CJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Suds Jurko Fork
On Wed, 6 Jan 2016, Kevin Kofler wrote: Chandan did contact him a while ago and I confirm that he did not receive any answer. Since maintainer is inactive for a while, I was thinking about doing the update as provenpackager after a reasonable delay. I think this whole thread is more something for the Nonresponsive Maintainer Process than for the Change Process. Sure, the fact that the package maintainer isn't active is something for the Nonresponsive Maintainer Process. This 'Change', though, is really about moving a package to a fork, which I thought was something that deserved wider attention and community input. Scott -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
On 01/06/2016 09:39 AM, Antonio Trande wrote: > On 01/06/2016 05:31 PM, Orion Poplawski wrote: >> I've created a "scitech" FAS and COPR group for the SciTech SIG >> (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate goal is >> to create some common repositories for updated builds of scientific software >> for EL7 (& 6). My thought is to have a have common repository >> (https://copr.fedoraproject.org/coprs/g/scitech/common/) for updated >> libraries, then individual repositories for updated programs like octave, >> julia, etc. >> >> I'm starting off with a suitesparse44 package that is split into individual >> libararies and can hopefully be installed in parallel with the system >> suitesparse. >> >> Add yourself to https://admin.fedoraproject.org/accounts/group/view/scitech >> if >> you want to join the effort. >> > I wish to join; do I need an invitation? > I'm honestly not sure. I know I need to approve members but I thought people could request it themselves via the above web page. If you can't, tell me your fas name and I'll add it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New scitech FAS and COPR group
On 01/06/2016 05:31 PM, Orion Poplawski wrote: > I've created a "scitech" FAS and COPR group for the SciTech SIG > (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate goal is > to create some common repositories for updated builds of scientific software > for EL7 (& 6). My thought is to have a have common repository > (https://copr.fedoraproject.org/coprs/g/scitech/common/) for updated > libraries, then individual repositories for updated programs like octave, > julia, etc. > > I'm starting off with a suitesparse44 package that is split into individual > libararies and can hopefully be installed in parallel with the system > suitesparse. > > Add yourself to https://admin.fedoraproject.org/accounts/group/view/scitech if > you want to join the effort. > I wish to join; do I need an invitation? -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x565E653C Check on https://keys.fedoraproject.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
New scitech FAS and COPR group
I've created a "scitech" FAS and COPR group for the SciTech SIG (https://fedoraproject.org/wiki/Category:SciTech_SIG). My immediate goal is to create some common repositories for updated builds of scientific software for EL7 (& 6). My thought is to have a have common repository (https://copr.fedoraproject.org/coprs/g/scitech/common/) for updated libraries, then individual repositories for updated programs like octave, julia, etc. I'm starting off with a suitesparse44 package that is split into individual libararies and can hopefully be installed in parallel with the system suitesparse. Add yourself to https://admin.fedoraproject.org/accounts/group/view/scitech if you want to join the effort. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ca-legacy
Hi, Is any important software (e.g. openssl, gnutls, glib-networking, Qt) in Fedora still relying on our legacy 1024-bit root RSA certificates? I believe Fedora is currently the only distro currently shipping these insecure root certificates. Originally, this was a good choice (and big thanks to Kai Engert for making it happen) because they were needed for compatibility with software using OpenSSL or GLib sockets. Nowadays, I'm not aware of any software that still needs them. Since keeping these certificates around is a serious security issue, I propose we remove them if nothing "important" still needs them. You can test if any of your software needs these certificates by running 'sudo ca-legacy disable'. Michael -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Suds Jurko Fork
Haïkel wrote: > Chandan did contact him a while ago and I confirm that he did not > receive any answer. > Since maintainer is inactive for a while, I was thinking about doing > the update as provenpackager after a reasonable delay. I think this whole thread is more something for the Nonresponsive Maintainer Process than for the Change Process. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
Panu Matilainen wrote: > Right. Freetype is old enough to actually predate rpm's > %bcond_with/without so custom variants have been implemented + evolved > by various packagers over the years, but this should've really been > using %bcond already: IMHO, that conditional should just be dropped entirely. I build a freetype- freeworld in RPM Fusion which has subpixel rendering enabled and which overrides the libraries through ld.so.conf.d, which is IMHO a much better solution than having the user rebuild the freetype RPM with a non-default flag. And I don't need this conditional for freetype-freeworld. I actually removed it entirely from freetype-freeworld, because now that the hinting patents expired, there are only 2 ways of building Freetype: with or without subpixel rendering. freetype is without, freetype-freeworld is with. So I just hardcoded it to always enabed in freetype-freeworld, which simplified my specfile. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New package distribution-gpg-keys
On Sat, Oct 17, 2015 at 01:46:24AM +, Zbigniew Jędrzejewski-Szmek wrote: > Would it be possible for people who create those keys (or other people > from release-engineering who can verify that they keys are correct) to > sign them with their private keys and upload the resulting signatures > to public key servers? It would provide an additional verification > path. Distribution package signing keys are important enough for this > to be worth the extra work imho. FYI: I do this since some releases for the Fedora keys. Regards Till signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainer - jklimes
On Tue, 2016-01-05 at 17:07 -0700, Kevin Fenzi wrote: > Greetings, we've been told that the email addresses > for this package maintainer is no longer valid. I'm starting the > unresponsive maintainer policy to find out if they are still > interested > in maintaining their packages (and if so, have them update their > email > addresses in FAS). If they're not interested in maintaining or we > can't locate them I'll have FESCo orphan the packages so that others > can take them over. > > If you have a way to contact this maintainer, please let them > know that we'd appreciate knowing what to do with their packages. > Thanks! > > * jklimes - former email: jkli...@redhat.com Jirka last day with Red Hat was right before the holidays (he'll be missed), so yes this email is no longer active. I'll ask him if he'd like to continue maintaining packages, but that would of course involve an email change to his personal one anyway. We might as well remove jklimes@rh from package maintainership. Dan > Point of contact: > > rpms/mobile-broadband-provider-info -- Mobile broadband provider > database ( master f23 f22 ) > > Co-maintainer: > > rpms/ModemManager -- Mobile broadband modem management service ( > master f23 f22 ) > rpms/NetworkManager -- Network connection manager and user > applications ( master f23 f22 ) > rpms/NetworkManager-openvpn -- NetworkManager VPN plugin for > OpenVPN ( master f23 f22 ) > rpms/NetworkManager-pptp -- NetworkManager VPN plugin for PPTP ( > master f23 f22 ) > rpms/NetworkManager-vpnc -- NetworkManager VPN plugin for vpnc ( > master f23 f22 ) > rpms/network-manager-applet -- A network control and status > applet for NetworkManager ( master f23 f22 ) > rpms/wpa_supplicant -- WPA/WPA2/IEEE 802.1X Supplicant ( master > f23 > f22 ) > > kevin > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160106 compose check report
Missing expected images: Kde disk raw armhfp Cloud_atomic disk raw x86_64 Images in this compose but not Rawhide 20160105: Games live x86_64 Design_suite live x86_64 Games live i386 Scientific_kde live x86_64 Scientific_kde live i386 Server disk raw armhfp No images in Rawhide 20160105 but not this. Failed openQA tests: 2 of 61 ID: 2522Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2522 ID: 2521Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2521 Passed openQA tests: 59 of 61 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self introduction: Martin Ueding
On Sat, Jan 2, 2016 at 9:35 PM, Martin Ueding wrote: > Hi everyone, > > I switched to Fedora last October and found that `xss-lock` is not > packaged. It does not depend on much so I packaged it and just filed a > [review bug][1]. There I am looking for a sponsor since this is my first > Fedora package. > > Now a bit about myself: I am a theoretical physicist (currently in the > Master's programme) from Germany. My main interest is computational > physics. Last summer my appetite for supercomputing was whetted at the > Jülich supercomputing centre. > > Linux is my OS of choice to do my work, that is programming Python and > C++, preparing documents in LaTeX and everything else. Since 2009 I have > used Ubuntu but decided to try out Fedora because of current software > and effortless upgrades (rpmnew/rpmsave) as well as a couple [other > reasons][2]. > > So far I am very happy with Fedora and I would like to contribute a > little bit :-). Willkommen! Feel free to join us in irc.freenode.net/#fedora-de - fabian > Regards, > > Martin Ueding > > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1295144 > [2]: > http://martin-ueding.de/de/computer_stuff/linux_distributions/index.html#id7 > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Fedora 24 Rawhide 20160106 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 24 Rawhide 20160106. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20160103: 2.21-1, 20160106: 2.22-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160106_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_24_Rawhide_20160106_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On Wed, Jan 06, 2016 at 02:28:45PM +0200, Panu Matilainen wrote:
> On 01/06/2016 01:59 PM, Richard W.M. Jones wrote:
> >On Wed, Jan 06, 2016 at 11:54:06AM +, Richard W.M. Jones wrote:
> >>On Tue, Jan 05, 2016 at 09:15:29PM +0200, Panu Matilainen wrote:
> >>>On 01/05/2016 07:16 PM, Richard W.M. Jones wrote:
> On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
> >mingw-freetype (rjones, lfarkas, epienbro)
>
> This uses:
>
> %{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
> _without_subpixel_rendering --without-subpixel_rendering}}
>
> _without_subpixel_rendering is not used anywhere else in the file.
> No idea if that is right or not.
> >>>
> >>>Another case where %define is actually wrong. The whole construct
> >>>looks like a workaround for %bcond related misunderstanding, but
> >>>dunno.
> >
> >Actually in this second case, mingw-freetype.spec is just following
> >the freetype.spec file. Which also looks wrong because it defines
> >_without_subpixel_rendering which is never used anywhere.
> >
> >http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/tree/freetype.spec
>
> Right. Freetype is old enough to actually predate rpm's
> %bcond_with/without so custom variants have been implemented +
> evolved by various packagers over the years, but this should've
> really been using %bcond already:
> http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/commit/freetype.spec?id=417715cf8e484f8099e6c2561e1ba83e851d9751
>
> This is what it should be changed to (untested but should be
> "obviously correct"):
>
> diff --git a/freetype.spec b/freetype.spec
> index c6d492d..e479acf 100644
> --- a/freetype.spec
> +++ b/freetype.spec
> @@ -1,6 +1,6 @@
> # Patented subpixel rendering disabled by default.
> # Pass '--with subpixel_rendering' on rpmbuild command-line to enable.
> -%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering:
> %define _without_subpixel_rendering --without-subpixel_rendering}}
> +%bond_with subpixel_rendering
>
> %{!?with_xfree86:%define with_xfree86 1}
>
> @@ -37,7 +37,7 @@ BuildRequires: zlib-devel
> BuildRequires: bzip2-devel
>
> Provides: %{name}-bytecode
> -%if %{?_with_subpixel_rendering:1}%{!?_with_subpixel_rendering:0}
> +%if %{with subpixel_rendering}
> Provides: %{name}-subpixel
> %endif
>
> @@ -78,7 +78,7 @@ FreeType.
> %prep
> %setup -q -b 1 -a 2
>
> -%if %{?_with_subpixel_rendering:1}%{!?_with_subpixel_rendering:0}
> +%if %{with subpixel_rendering}
> %patch21 -p1 -b .enable-spr
> %endif
>
>
> If this seems backwards, see
> http://rpm.org/wiki/PackagerDocs/ConditionalBuilds
Thanks - I'll follow what freetype-owner decides, because we want to
try to keep mingw packaging as close to the native packages as
possible.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On 01/06/2016 01:59 PM, Richard W.M. Jones wrote:
On Wed, Jan 06, 2016 at 11:54:06AM +, Richard W.M. Jones wrote:
On Tue, Jan 05, 2016 at 09:15:29PM +0200, Panu Matilainen wrote:
On 01/05/2016 07:16 PM, Richard W.M. Jones wrote:
On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
mingw-freetype (rjones, lfarkas, epienbro)
This uses:
%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
_without_subpixel_rendering --without-subpixel_rendering}}
_without_subpixel_rendering is not used anywhere else in the file.
No idea if that is right or not.
Another case where %define is actually wrong. The whole construct
looks like a workaround for %bcond related misunderstanding, but
dunno.
Actually in this second case, mingw-freetype.spec is just following
the freetype.spec file. Which also looks wrong because it defines
_without_subpixel_rendering which is never used anywhere.
http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/tree/freetype.spec
Right. Freetype is old enough to actually predate rpm's
%bcond_with/without so custom variants have been implemented + evolved
by various packagers over the years, but this should've really been
using %bcond already:
http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/commit/freetype.spec?id=417715cf8e484f8099e6c2561e1ba83e851d9751
This is what it should be changed to (untested but should be "obviously
correct"):
diff --git a/freetype.spec b/freetype.spec
index c6d492d..e479acf 100644
--- a/freetype.spec
+++ b/freetype.spec
@@ -1,6 +1,6 @@
# Patented subpixel rendering disabled by default.
# Pass '--with subpixel_rendering' on rpmbuild command-line to enable.
-%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
_without_subpixel_rendering --without-subpixel_rendering}}
+%bond_with subpixel_rendering
%{!?with_xfree86:%define with_xfree86 1}
@@ -37,7 +37,7 @@ BuildRequires: zlib-devel
BuildRequires: bzip2-devel
Provides: %{name}-bytecode
-%if %{?_with_subpixel_rendering:1}%{!?_with_subpixel_rendering:0}
+%if %{with subpixel_rendering}
Provides: %{name}-subpixel
%endif
@@ -78,7 +78,7 @@ FreeType.
%prep
%setup -q -b 1 -a 2
-%if %{?_with_subpixel_rendering:1}%{!?_with_subpixel_rendering:0}
+%if %{with subpixel_rendering}
%patch21 -p1 -b .enable-spr
%endif
If this seems backwards, see
http://rpm.org/wiki/PackagerDocs/ConditionalBuilds
- Panu -
Adding CC freetype-owner.
Rich.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On Wed, Jan 06, 2016 at 11:54:06AM +, Richard W.M. Jones wrote:
> On Tue, Jan 05, 2016 at 09:15:29PM +0200, Panu Matilainen wrote:
> > On 01/05/2016 07:16 PM, Richard W.M. Jones wrote:
> > >On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
> > >>mingw-freetype (rjones, lfarkas, epienbro)
> > >
> > >This uses:
> > >
> > >%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
> > >_without_subpixel_rendering --without-subpixel_rendering}}
> > >
> > >_without_subpixel_rendering is not used anywhere else in the file.
> > >No idea if that is right or not.
> >
> > Another case where %define is actually wrong. The whole construct
> > looks like a workaround for %bcond related misunderstanding, but
> > dunno.
Actually in this second case, mingw-freetype.spec is just following
the freetype.spec file. Which also looks wrong because it defines
_without_subpixel_rendering which is never used anywhere.
http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/tree/freetype.spec
Adding CC freetype-owner.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On Tue, Jan 05, 2016 at 09:15:29PM +0200, Panu Matilainen wrote:
> On 01/05/2016 07:16 PM, Richard W.M. Jones wrote:
> >On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
> >>coccinelle (rjones)
> >
> >coccinelle.spec has:
> >
> >%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from
> >distutils.sysconfig import get_python_lib; print get_python_lib()")}
> >
> >TBH I have no idea if this is correct or not, or perhaps should be
> >completely removed. Thoughts?
>
> That's one of those cases where using %define is actually *wrong*
> because of the macro scoping thing. But in practise it'll never get
> used since these days %python_sitelib is always defined so its not
> just wrong but also pointless as well.
>
> >>mingw-freetype (rjones, lfarkas, epienbro)
> >
> >This uses:
> >
> >%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
> >_without_subpixel_rendering --without-subpixel_rendering}}
> >
> >_without_subpixel_rendering is not used anywhere else in the file.
> >No idea if that is right or not.
>
> Another case where %define is actually wrong. The whole construct
> looks like a workaround for %bcond related misunderstanding, but
> dunno.
Thanks Panu. I think I will delete both lines, and see if we
have any problems.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20160106 changes
Compose started at Wed Jan 6 05:15:02 UTC 2016 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [OpenColorIO] OpenColorIO-tools-1.0.9-8.fc23.i686 requires libOpenImageIO.so.1.5 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/pkg) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/machine) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/etcd) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/client) [golang-github
Re: WebKitGTK+ security status
On Mon, 2015-12-28 at 14:24 -0600, Michael Catanzaro wrote: > This mail is in regards to WSA-2015-0002: http://webkitgtk.org/securi > ty > /WSA-2015-0002.html > > In short, we have by my count: > > * Zero CVEs affecting the webkitgtk4 package in F23 > * 40 CVEs affecting the webkitgtk4 package in F22 > * 129 CVEs affecting the webkitgtk and webkitgtk3 packages in F22/F23 > > The vast majority of these issues allow for "remote attackers to > execute arbitrary code or cause a denial of service (memory corruption > and application crash) via a crafted web site." > > My proposal is to update webkitgtk4 in F22 from 2.8.5 to 2.10.4 and > hope that not much breaks. This is probably relatively safe, since > 2.10.4 has been in F23 for a while, I'm not aware of any issues related > to the upgrade, and it's API/ABI compatible. 2.8 -> 2.10 is a major > upgrade encompassing six months of development on WebKit trunk (from > February to August 2015). This means there will inevitably be > regressions. Normally I don't advocate large version updates for stable > Fedora releases, but web engines are special in that it's the only > practical way to provide security support. We can't backport 40 patches > to F22, so if we don't do this update, we should instead announce that > security support for webkitgtk4 is provided only to the latest Fedora > release. > > Certainly it's not practical to provide security support for the > webkitgtk or webkitgtk3 packages going forward. We can either remove > them from the distro at some flag date (F25 branch point?), or ignore > the problem like we do for qtwebkit. Probably the later is a better > approach, since there is a lot that still depends on these packages. As we already spoke about this on the Web Engines Hackfest I'm in favor of doing the rebase. If no one will raise any objections until the end of the week we will proceed with the rebase. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: WebKitGTK+ security status
Hi, On Sat, 2016-01-02 at 16:16 -0600, Michael Catanzaro wrote: > Looking over the list, most of the impacted software we could live > without, or stands a good chance of being ported in time. Evolution is > mostly ported upstream, as is Midori. Evolution's WebKit 2 port is targeted to be finished for Evolution 3.22 (that will be part of Gnome 3.22 - that will be included in F25). -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
