EPEL ghc-7.6.3 in 7
Hi, Just a heads up that ghc-7.6.3 (Haskell compiler) from F20 was built for EPEL 7 Beta last week. Lot of building of Haskell packages still to be done there. Current EPEL versions are: EPEL5: ghc-7.0.4 (recently updated) EPEL6: ghc-7.0.4 (updated in 2012; update to 7.4.2 planned) EPEL7: ghc-7.6.3 We will probably stay with 7.6.3 in EPEL7 at least until after ghc-7.8 is completely stable (ie when rawhide moves to 7.10+) and works on ppc64. Jens ps I would also like to add Software Collections for different ghc versions for EL to better allow users to choose the version of ghc best for them. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL requesting cloud-init bump in epel7beta
hi guys, can we get cloud-init in epel7beta bumped to match epel6 @ 0.7.4 ? - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Senior Fedora OS position open
Hi, Imagination/MIPS is hiring Fedora engineers. Please see: http://www.imgtec.com/corporate/vacancy_detail.asp?VacancyID=2286 for details, and feel free to pm me if you have any questions. All applications have to go via the website. The role presently says location 'Leeds,UK', but should say 'worldwide', and will be fixed. Imagination has 22 offices across the globe, and the present kernel/distro group is spread across 4 continents. Graham -- Graham Whaley Software Engineering Manager, MIPS platforms Imagination Technologies www.imgtec.com graham.wha...@imgtec.com -- 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: Five Things in Fedora This Week (2014-04-01)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2014 07:31 PM, Corey Sheldon wrote: where are you planning to host the final stable listing or blog beyond this mailing list? if it in a dev minded or dev friendly arena jsut make a quick 2-3 lines in a FAQ like page with futher reading links to the wiki or respective respcted authority in the particular space I also run in many linux and dev groups on and off social media if you need help in the distrubution in different spaces hit me up directly with tag line related to fedora or dev so it goes in my inbox with other dev stuffs... See the link at the top of the original post. This is posted to the Fedora Magazine site, where it will remain for posterity. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM7+poACgkQeiVVYja6o6PzgQCdEja/sJ59HLsRDQdKOP2250NC KC8AnjXiA5Gu2zpkESPRxFCfb4tqioCr =+q6L -END PGP 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
F21 Self Contained Change: KDE Frameworks 5
= Proposed Self Contained Change: KDE Frameworks 5 = https://fedoraproject.org/wiki/Changes/KDE_Frameworks_5 Change owner(s): Daniel Vrátil dvra...@redhat.com KDE Frameworks 5 is a set of libraries and technologies developed in the KDE project over the past 18 years. Most of the frameworks come from the kdelibs module, which has been split, cleaned up, dependencies were strightened and packed into individual libraries. This allows developers and projects outside the KDE ecosystem to make use of these technologies and benefit from work of the KDE Community. == Detailed Description == KDE Frameworks 5 is the successor to KDE Platform 4, bringing significant technical differences and a change in focus. It will be the first release of KDE libraries based on Qt 5, which brings significant improvements to users. New technologies are being introduced and libraries are being cleaned up, reviewed and brought up to date with new standards. At the same time, the team is making the development platform more modular and making it easier to reuse solutions in a wider range of platforms and devices, including desktop and mobile. Technologies such as QML allow KDE developers to take advantage of a leading graphics rendering engine, and allow for more organic and fluid user interfaces across devices. An important goal of KDE Frameworks 5 is to bring the benefits of KDE technology to Qt5 users outside the KDE Community. Libraries are split into distinct components, making it possible for Qt developers to take components without dragging in other unnecessary libraries. (from [1]) KDE Frameworks 5 don't provide any UI or applications on their own, but are meant as extensions and addons for the Qt toolkit. In future there will be various desktop shells like Plasma 2 and applications built on top of KDE Frameworks 5 providing the full-featured KDE desktop (KDE 5). All Frameworks are co-installable with current all KDE 4 packages. == Scope == * Proposal owners: All frameworks are already packaged and are currently provided in a COPR repository [2]. We only need to have all the packages reviewed and submit them into Fedora. Given the amount of frameworks (currently 60), this will take some time to process. This is a completely isolated change that will not affect any other packages or changes. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://dot.kde.org/2013/09/04/kde-release-structure-evolves [2] http://copr.fedoraproject.org/coprs/dvratil/kde-frameworks/ ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: Five Things in Fedora This Week (2014-04-01)
On 1 April 2014 21:11, Matthew Miller mat...@fedoraproject.org wrote: Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-01/ This is the third installment of this series, and I'm still calibrating a few things. I'm aiming at a wide audience, but I'm not quite sure how much explaining I should do of general Fedora knowledge. Is it helpful for me to (as above), give a quick explanation when I talk about Rawhide, Flock, or FESCo? Or, does that just increase the word count for no reason? Let me know. Finding these pretty interesting, please keep them going. Think it's useful to have a little context tagged onto things (like your explanation of Flock) for anyone coming across it for the first time. -- imalone http://ibmalone.blogspot.co.uk -- 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: Five Things in Fedora This Week (2014-04-01)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2014 03:11 PM, Matthew Miller wrote: Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-01/ 5tFTW note -- This is the third installment of this series, and I'm still calibrating a few things. I'm aiming at a wide audience, but I'm not quite sure how much explaining I should do of general Fedora knowledge. Is it helpful for me to (as above), give a quick explanation when I talk about Rawhide, Flock, or FESCo? Or, does that just increase the word count for no reason? Let me know. What you have here is perfect, in my opinion. The short intros are, I think, the perfect length at this time. Thanks for taking the time to write these posts. Mukundan. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTPBVyAAoJEGqtW2dEe0yGx1cQAJqyIDlW6IYzJsIFf/+PWlWy La/CA19S+zt8Gmi7c+OLAI1esfX5FNVap0GZ7lPJQM8DDAln2mvd0cxM+sg4/CTt 0Iw90VqGG1zMvC0qXTouLAXN67MYmPH1BQrM9M+RsovMcXNfMoY9nFfirVK3KL0N khZ4D6TZngoL22ssSMX3oh6EkUQKrlKN9x9q5Hf2KIkcmBzmkYkUpPB0Kb8QOR9P 83LhkBdNtNJVUNDmyo8o0p7CX86F82dexVRO8QTQaJ/DjQiG/G45IoQ+MJPR3hBl s/JMM5ZV7nJuPysKqqTW52sAFE7hsxDaL3g7aeS9CDJeqx5fMyiElXmNDBxkKGaO J9rXKTJh9m/zuVDa0cF0MYpbW+JsnHAN/RcLWtTca/wOpRGIqdcQDaBN7ciW4zX4 yea4DXss/AyfJWTIEnHGfLZUAjMDILhl86Yz/9NcTD2rY8ehY9fy1PLTNUG5TnwG 9jr3u6Za/ZlsEkxo/cR3ffJFW1aXK2qWl2bkWt4cy1fFwrzpnV7ccB89YQix7mYs rz8hyfFKIDoQ+mRx5NjHKz3ySVNgR2mb4+w0knTABaaZNJtGv05E+RrEXHiYGBAO FCWw8kZhC5n0pHgmle//QH0p5YA7p9+0kTU8Y/laA7ZBh0lB18jEPIvpRO/KqDI9 SZQh6C7Tmxv882QR1Ruw =3IoL -END PGP 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
ntl soname bump
I will build ntl 6.1.0 for Rawhide today. This involves an soname bump, so I will also rebuild dependent packages, namely: - eclib - flint - latte-integrale - linbox - Macaulay2 - polybori - sagemath - Singular I have already been in contact with maintainers of these packages about the rebuilds. -- Jerry James http://www.jamezone.org/ -- 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: Senior Fedora OS position open
On Wed, 2014-04-02 at 11:48 +0100, Graham Whaley wrote: Imagination/MIPS is hiring Fedora engineers. Please see: http://www.imgtec.com/corporate/vacancy_detail.asp?VacancyID=2286 for details, and feel free to pm me if you have any questions. All applications have to go via the website. I look forward to seeing the open graphics support story. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: GHC 7.8
= Proposed System Wide Change: GHC 7.8 = https://fedoraproject.org/wiki/Changes/GHC_7.8 Change owner(s): Jens Petersen peter...@redhat.com, Ricky Elrod rel...@redhat.com, Haskell_SIG hask...@lists.fedoraproject.org Update the GHC Haskell compiler to the major new 7.8 release, and update/rebuild all Haskell packages against it. == Detailed Description == * The involves updating ghc from 7.6.3 to 7.8.1 (or later), and rebuilding/updating all Fedora Haskell packages. * The initial work will be done locally offline to make sure that it is possible to build all our packages with ghc-7.8 and the latest updated libraries. * This may also include building with the llvm backend to ensure that building on ARM will work. * Once that is completed, building will be done into Koji for rawhide and testing done. == Scope == * Proposal owners: ** locally test rebuilding and updating of all packages ** update macros to subpackage static libraries ** push changes to Koji ** testing * Other developers: If you own a package which contains some Haskell code built with ghc you will need to rebuild you package to make sure it still rebuilds with ghc-7.8. Feel free to contact the Haskell SIG if we need assistance with fixing any build breakage, and we will try to help out. * Release engineering: not required * Policies and guidelines: There may be some lesser changes to the Haskell Packaging Guidelines needed - they could be done after this Change. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: Senior Fedora OS position open
Graham, I've been interested to revive the fedora-mips project myself, mostly to get Fedora usable on my home firewall/router. Very excited to see Imagination get involved! Do you have any recommendations for cheap MIPS dev boards? [1] I've been eyeing the Ubiquity board. [1] http://www.imgtec.com/mips/developers/development-platforms.asp On Wed, Apr 2, 2014 at 5:48 AM, Graham Whaley graham.wha...@gmail.com wrote: Hi, Imagination/MIPS is hiring Fedora engineers. Please see: http://www.imgtec.com/corporate/vacancy_detail.asp?VacancyID=2286 for details, and feel free to pm me if you have any questions. All applications have to go via the website. The role presently says location 'Leeds,UK', but should say 'worldwide', and will be fixed. Imagination has 22 offices across the globe, and the present kernel/distro group is spread across 4 continents. Graham -- Graham Whaley Software Engineering Manager, MIPS platforms Imagination Technologies www.imgtec.com graham.wha...@imgtec.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: Senior Fedora OS position open
Hi Jon. The Ubiquiti boards are some of the cheapest bang-per-buck right now, but don't really have local storage (there is some NAND, and they do have USB) - so network boot and NFS to start with (or the hassle of USB dongle for development). They released some new ones a week or two back I believe which clock higher (800MHz and 1GHz dual-core OcteonII's) and have more ram (2Gbyte DDR3). The little ones are cheap ($99 - dual 64bit 500MHz OcteonPlus core, 512Mb DDR), and the bigger ones not silly money (they are quite new, so I'm not seeing prices on a quick search - but a few hundred $ I think). Then there are the Loongson machines. I would recommend going with the 3A machines if you were going to invest, but I do actually have a 3A rack mount server sat here waiting to do Fedora work (quad 64bit core 1GHz, SATA sw raid twin disk and 8Gbyte DDR3). The 3A laptops are more expensive. The 2F and 2E based machines are probably too old now (but could still be useful in the interim). pm me - I can probably work something out (that offer is open to anybody who wants to do some MIPS stuff btw) Graham On 2 April 2014 15:32, Jon jdisn...@gmail.com wrote: Graham, I've been interested to revive the fedora-mips project myself, mostly to get Fedora usable on my home firewall/router. Very excited to see Imagination get involved! Do you have any recommendations for cheap MIPS dev boards? [1] I've been eyeing the Ubiquity board. [1] http://www.imgtec.com/mips/developers/development-platforms.asp On Wed, Apr 2, 2014 at 5:48 AM, Graham Whaley graham.wha...@gmail.com wrote: Hi, Imagination/MIPS is hiring Fedora engineers. Please see: http://www.imgtec.com/corporate/vacancy_detail.asp?VacancyID=2286 for details, and feel free to pm me if you have any questions. All applications have to go via the website. The role presently says location 'Leeds,UK', but should say 'worldwide', and will be fixed. Imagination has 22 offices across the globe, and the present kernel/distro group is spread across 4 continents. Graham -- Graham Whaley Software Engineering Manager, MIPS platforms Imagination Technologies www.imgtec.com graham.wha...@imgtec.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[CHANGE PROPOSAL] The securetty file is empty by default
[CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Status Meeting 2014-04-02
Please join us today (Wednesday, April 2nd) at 4PM EDT (8PM UTC) for the Fedora ARM status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 1) Fedora.Next 2) Fedora ARM Remixes 3) Deployment Tool to Customize Disk Images 4) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On 04/02/2014 04:12 PM, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? I think it would just be better to remove it along with pam_securetty.so altogether as opposed to be shipping it empty JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GnuTLS issue (Mandos Server/Client)
Hello, I'm working on getting a package (mandos) included in Fedora/EPEL. Currently its heavily focused on debian based distros so I'm not ready for a review. However I have it working in a few situations but have some issues in others. I'm hoping someone here may be able to shed light on what may be going on. So that I can finish adding the bits needed to be fully functional and then included. So the whole thing works only if servers and clients are on the same OS version. Different errors are thrown for different combinations. Client OS Server OSError F20CentOS 6 TLS packet with unexpected length was received CentOS 6 F20 The TLS connection was non-properly terminated CentOS 6 CentOS 6 No error F20F20 No error CentOS gnutls versions CentOS 6 = gnutls 2.8.5 F20 = gnutls 3.1.20 The server is a python app and sets the priority string as follows: priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP this is fed to some gnutls function somewhere in the stack. I'm at a complete loss as to why it doesn't work. Pointers or docs or anything else that can help me figure out why an app can talk to itself as long as the same base OS is used would be GREATLY appreciated.. Thanks, -- Nathanael -- 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: GnuTLS issue (Mandos Server/Client)
On Wed, 2014-04-02 at 10:50 -0600, Nathanael D. Noblet wrote: Hello, I'm working on getting a package (mandos) included in Fedora/EPEL. Currently its heavily focused on debian based distros so I'm not ready for a review. However I have it working in a few situations but have some issues in others. I'm hoping someone here may be able to shed light on what may be going on. So that I can finish adding the bits needed to be fully functional and then included. So the whole thing works only if servers and clients are on the same OS version. Different errors are thrown for different combinations. Client OS Server OS Error F20CentOS 6 TLS packet with unexpected length was received CentOS 6 F20 The TLS connection was non-properly terminated CentOS 6 CentOS 6 No error F20F20 No error CentOS gnutls versions CentOS 6 = gnutls 2.8.5 F20 = gnutls 3.1.20 The server is a python app and sets the priority string as follows: priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP this is fed to some gnutls function somewhere in the stack. I'm at a complete loss as to why it doesn't work. Pointers or docs or anything else that can help me figure out why an app can talk to itself as long as the same base OS is used would be GREATLY appreciated.. Well, have you tried the 'obvious' - building the newer gnutls on CentOS 6 (or the older on Fedora 20) and building mandos against that, to see if the issue is in gnutls or somewhere else in the 'base system'? That'd narrow it down at least. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
- Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: lbzip2 as default bzip2 implementation
= Proposed System Wide Change: lbzip2 as default bzip2 implementation = https://fedoraproject.org/wiki/Changes/lbzip2 Change owner(s): Mikolaj Izdebski mizde...@redhat.com This change aims at making lbzip2 [1] default bzip2 implementation used in Fedora. == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, * improved performance, even on single-core systems, * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), * improved compatibility with gzip. lbzip2 is a mature project and it has been used in production for years. It is already packaged for Fedora and it is also available in EPEL. The case of bzip2 and lbzip2 is an ideal candidate for usage of alternatives - both tools provide commands with compatible interfaces. This change proposes assigning higher priority to lbzip2 than to bzip2, which will effectively cause lbzip2 to be used instead of bzip2, if lbzip2 is installed. If for some reason some users don't like the change they can reconfigure alternatives manually and keep using bzip2. == Scope == * Proposal owners: ** make lbzip2 and bzip2 packages use alternatives for binaries and manpages they provide, ** set higher priority for lbzip2 in alternatives, ** identify packages which require bzip2 and port some of them to use lbzip2 instead. * Other developers: ** test if their packages work with lbzip2, ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. * Release engineering: no action required. * Policies and guidelines: no change required. [1] http://lbzip2.org/ ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Wednesday's FESCo Meeting (2014-04-02)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = New business = #topic #1268 Mesa 10.1 rebase in F20 .fesco 1268 https://fedorahosted.org/fesco/ticket/1268 #topic #1244 F21 System Wide Change: cron to systemd time units - https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units .fesco 1244 https://fedorahosted.org/fesco/ticket/1244 #topic #1250 F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250 #topic #1270 F21 System Wide Change: Java 8 - https://fedoraproject.org/wiki/Changes/Java8 .fesco 1270 https://fedorahosted.org/fesco/ticket/1270 #topic #1271 F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services - https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork .fesco 1271 https://fedorahosted.org/fesco/ticket/1271 #topic #1269 Closing all 'Merge Review' bugs .fesco 1269 https://fedorahosted.org/fesco/ticket/1269 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 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/fesco, 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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTPEXHAAoJEH7ltONmPFDRBH4P/3Hme9YlQqb6WVuaKsIpIMaS kLGn2XFNh+sXHydO3N4YZgv/sfhYqA8zZtVIX2exrXPDK4cJobaBx5nobtp4WpYg QpqjdQ9l0pLa53sh0YDsuoUbcesehcI8YtJ6xS9s5T1k6eHrsoOnFp8lAtATiQPe bYPBQ2CuN+rIU36l7eMOb/yG6eQb8Gkwc2cmVhPPGz3mr3rkupNNOC1T66p6mVBf e33KzCdY24y+dQ31Th7oJp0PFKGxdtm54Rg2Og+ktkAeeKU22JoKEInINtku+OJx xnmORSkOp8QV+KrY6ydOPurUqpuEP16tQfCs1AxTMzQhrXeH5kxUCTurRWTlSDl9 taJjMmXsPfdzKBXK9kCWYA74/lqqRcH77kkzKmB3KRy/nDkBsfS/K++DND0u3cKa fR6sYJ8p8o4+IXeXkLkENk8CZe2ccvXUmeO6U/vZr141yj8RyeDWAdB1X1g68kvG 1Kg73QAi2zCrTzphVOJlH8qAQ37U4cdvpJ4vsfPNNjg/zkKm/sQI2PnoERqMIQtq XSL+boX5Ba6oNrXNlm8k22YNTSm9gSFkHJsVqzMsvVEdpmUnpk5+tTwagkJOS/+f dXnFwRXfMv96fR49Zh0bpcSfCQVJf8lst272PkBYUlehIfGjqGHu6IMMUAcW61lb cKs+oo5Rd6X9nnwPQ6hA =Xh5C -END PGP 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
Re: Wednesday's FESCo Meeting (2014-04-02)
On Wed, Apr 02, 2014 at 05:19:13PM +, Jóhann B. Guðmundsson wrote: On 04/02/2014 05:15 PM, Dennis Gilmore wrote: #topic #1244 F21 System Wide Change: cron to systemd time units - https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units Why is this being added to the meeting agenda? Because https://fedorahosted.org/fesco/ticket/1244#comment:14 Talked with Jóhann on IRC. He thinks it would be best if FESCo sent a complete policy recommendation to FPC. The specific proposal is: * All packages with timed execution which already depend on systemd (for example because they contain service units) MUST use timer units instead of cron jobs, with no dependency on a cron daemon. * Packages which do not already depend on systemd MUST NOT use timer units and instead use cron, to avoid introducing unnecessary new dependencies on systemd directly. I recommend we vote on this in-ticket for expediency, and resolve at the next FESCo meeting if there are not enough votes to pass before then. (Note that this isn't in any way rescinding the approval of the feature overall, just clarifying the intended policy.) And there are only two votes in the ticket. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: Wednesday's FESCo Meeting (2014-04-02)
On 04/02/2014 05:27 PM, Matthew Miller wrote: And there are only two votes in the ticket. I thought everybody just wanted FPC to deal with this and were waiting until they did like me hence the ticket I created and it wont be dealt with until first time tomorrow as in their next meeting. JBG -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Jaroslav Reznik jrez...@redhat.com said: - Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. I'd be opposed to locking root out of the console login (having spent today at work tracking down miscellaneous VMs with only a root user created). Fedora still allows root SSH logins by default; how is that more secure than the console? -- Chris Adams li...@cmadams.net -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
Am 02.04.2014 19:29, schrieb Chris Adams: Once upon a time, Jaroslav Reznik jrez...@redhat.com said: - Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. I'd be opposed to locking root out of the console login (having spent today at work tracking down miscellaneous VMs with only a root user created) +1 a golden-master for a virtual infrastructure usually do not have any other login user because which one is decided after clone and intention of the final machine instead some generic user Fedora still allows root SSH logins by default; how is that more secure than the console? it is not but disable that in a default install makes nothing more secure the only secure SSH setup is that one where no password login is allowed and that is a chicken/egg problem not solveable at setup 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
Re: GnuTLS issue (Mandos Server/Client)
On Wed, 2014-04-02 at 10:15 -0700, Adam Williamson wrote: Well, have you tried the 'obvious' - building the newer gnutls on CentOS 6 (or the older on Fedora 20) and building mandos against that, to see if the issue is in gnutls or somewhere else in the 'base system'? That'd narrow it down at least. Hmm that does seem obvious in hindsight. However no I haven't tried that. I figured I'd end up with a huge mess trying to recompile something like that between distros with such huge time periods all the related packages that depend on them. For example the python bindings etc... I'll look into doing it however. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: RPM-4.12
= Proposed System Wide Change: RPM-4.12 = https://fedoraproject.org/wiki/Changes/RPM-4.12 Change owner(s): Florian Festi, Panu Matilainen rpm-ma...@rpm.org Update RPM to the upcoming 4.12 release. == Detailed Description == The current upstream repository contains several improvements that need to get released and integrated into Fedora: * Support for weak dependencies * Support for packaging files 4GB * Support for real package reinstallation * New API for accessing files and file contents * New tool for converting rpm packages to tar files * Internal plugin interface * Massive code clean ups * Many bug fixes Some of these features require the new version to reach the builders. So actually introducing them in Fedora will take longer that the Fedora 21 release. Nevertheless updating RPM in F21 is the first step to make this happen. == Scope == * Proposal owners: The RPM code base needs to get stabilized and release ready. The release candidates need to be tested in rawhide. * Other developers: Will test the release candidates during normal operation in raw hide. Need to report issues and bugs. * Release engineering: Have a look for compatibility issues. * Policies and guidelines: Packaging policies might need reconsidering in the light of the new options (F22 or even F23 time frame). ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: lbzip2 as default bzip2 implementation = https://fedoraproject.org/wiki/Changes/lbzip2 Change owner(s): Mikolaj Izdebski mizde...@redhat.com This change aims at making lbzip2 [1] default bzip2 implementation used in Fedora. == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, * improved performance, even on single-core systems, * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), * improved compatibility with gzip. lbzip2 is a mature project and it has been used in production for years. It is already packaged for Fedora and it is also available in EPEL. A quick check shows lbzip2 doesn't provide a library interface, much less one compatible with libbz2. Is that ever intended? If it's not, saying lbzip2 is the default bzip2 *implementation* may be a bit of a stretch. Perhaps s/implementation/command/. Bill -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 02/04/14 18:24, Jaroslav Reznik wrote: == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, Does that mean that it creates multiple streams in the compressed file? If it does then be aware that some bzip2 decoders (notable the Java one) will not be able to decompress the result. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 2014-04-02 at 09:12 -0700, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct How does someone express strong disagreement to this change ? I often install machines with root only as my users are all in my FreeIPA/LDAP server and I expect to be able to login as root on the console for maintenance purposes. This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. Please explain the logic of blocking console logins but allowing SSH logins, it is completely backwards. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 08:03 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: lbzip2 as default bzip2 implementation = https://fedoraproject.org/wiki/Changes/lbzip2 Change owner(s): Mikolaj Izdebski mizde...@redhat.com This change aims at making lbzip2 [1] default bzip2 implementation used in Fedora. == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, * improved performance, even on single-core systems, * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), * improved compatibility with gzip. lbzip2 is a mature project and it has been used in production for years. It is already packaged for Fedora and it is also available in EPEL. A quick check shows lbzip2 doesn't provide a library interface, much less one compatible with libbz2. Is that ever intended? That was once intended (in 2007-2010), but for now I decided to provide bzip2-compatible commands only. If there is demand I will reconsider providing a library with bzip2-compatible API/ABI. If it's not, saying lbzip2 is the default bzip2 *implementation* may be a bit of a stretch. Perhaps s/implementation/command/. You're right, the title and description may be ambiguous. In this sentence bzip2 means bzip2 command. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 08:10 PM, Tom Hughes wrote: On 02/04/14 18:24, Jaroslav Reznik wrote: == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, Does that mean that it creates multiple streams in the compressed file? If it does then be aware that some bzip2 decoders (notable the Java one) will not be able to decompress the result. lbzip2 creates only *one* stream per compressed file, even when using multiple threads. Such files can be decompressed with all versions of bzip2, libbz2 and other tools, such as Apache Commons Compress. This is a difference between lbzip2 and pbzip2, which creates multiple streams. Files created with pbzip2 cannot be decompressed by some software, such as libbzip2 (all versions), bzip2 older than version 0.9.0, Apache Commons Compress. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 710 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 52 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 42 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0846/mediawiki119-1.19.13-1.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0888/v8-3.14.5.10-7.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0889/moodle-2.4.9-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0938/seamonkey-2.21-5.ESR_24.4.0.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0980/perl-YAML-LibYAML-0.38-4.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0996/munin-2.0.20-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0990/libyaml-0.1.6-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1011/php-ZendFramework-1.12.5-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1020/php-ZendFramework2-2.2.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1039/mod_security-2.7.3-3.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing duply-1.7.1-1.el6 iperf3-3.0.3-2.el6 mod_security-2.7.3-3.el6 nodejs-jade-1.3.0-3.el6 nodejs-supertest-0.9.0-1.el6 opendnssec-1.4.4-3.el6 pen-0.22.0-1.el6 python-fedmsg-genacls-0.2-1.el6 uglify-js-2.4.13-3.el6 xvkbd-3.5-1.el6 Details about builds: duply-1.7.1-1.el6 (FEDORA-EPEL-2014-0933) Wrapper for duplicity Update Information: Update to the latest released version. Changes in version 1.7.0: - disabled gpg key id plausibility check, too many valid possibilities - featreq 7 Halt if precondition fails: added and(+), or(-) batch command(separator) support - featreq 26 pre/post script with shebang line: if a script is flagged executable it's executed in a subshell now as opposed to sourced to bash, which is the default - bugfix: do not check if dpbx, swift credentials are set anymore - bugfix: properly escape profile name, archdir if used as arguments - add DUPL_PRECMD conf setting for use with e.g. trickle Changes in version 1.7.1: - bugfix: purge-* commands renamed to purgeFull, purgeIncr due to incompatibility with new minus batch separator ChangeLog: * Tue Apr 1 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.1-1 - Update to 1.7.1 - Update %description. * Fri Mar 21 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.0-1 - Update to 1.7.0. iperf3-3.0.3-2.el6 (FEDORA-EPEL-2014-1037) Measurement tool for TCP/UDP bandwidth performance Update Information: Moved static library to devel section Update to 3.0.3 and added devel rpm support Update to 3.0.3 and added devel rpm support ChangeLog: * Wed Apr 2 2014 Susant Sahani ssah...@redhat.com 3.0.3-2 - Moved static library to devel section only . * Sun Mar 30 2014 Susant Sahani ssah...@redhat.com 3.0.3-1 - Update to 3.0.3 and added devel rpm support References: [ 1 ] Bug #1081486 - iperf3-3.0.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1081486 mod_security-2.7.3-3.el6 (FEDORA-EPEL-2014-1039) Security module for the Apache HTTP Server Update Information: Fix Chunked string case sensitive issue (CVE-2013-5705, RHBZ #1082904 #1082905 #1082906) ChangeLog: * Tue Apr 1 2014 Athmane Madjoudj athm...@fedoraproject.org 2.7.3-3 - Fix Chunked string case sensitive issue (CVE-2013-5705, RHBZ #1082904 #1082905 #1082906) References: [ 1 ] Bug #1082904 - CVE-2013-5705 mod_security: bypass of intended rules via chunked requests https://bugzilla.redhat.com/show_bug.cgi?id=1082904
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 710 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 165 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 45 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0840/mediawiki119-1.19.13-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0918/php-pecl-Fileinfo-1.0.4-3.el5,php-pecl-zip-1.8.10-3.el5,php-extras-5.1.6-6.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0984/munin-2.0.20-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0988/libyaml-0.1.2-7.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1041/mod_security-2.6.8-5.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing duply-1.7.1-1.el5 iperf3-3.0.3-2.el5 mod_security-2.6.8-5.el5 Details about builds: duply-1.7.1-1.el5 (FEDORA-EPEL-2014-0931) Wrapper for duplicity Update Information: Update to the latest released version. Changes in version 1.7.0: - disabled gpg key id plausibility check, too many valid possibilities - featreq 7 Halt if precondition fails: added and(+), or(-) batch command(separator) support - featreq 26 pre/post script with shebang line: if a script is flagged executable it's executed in a subshell now as opposed to sourced to bash, which is the default - bugfix: do not check if dpbx, swift credentials are set anymore - bugfix: properly escape profile name, archdir if used as arguments - add DUPL_PRECMD conf setting for use with e.g. trickle Changes in version 1.7.1: - bugfix: purge-* commands renamed to purgeFull, purgeIncr due to incompatibility with new minus batch separator ChangeLog: * Tue Apr 1 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.1-1 - Update to 1.7.1 - Update %description. * Fri Mar 21 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.0-1 - Update to 1.7.0. iperf3-3.0.3-2.el5 (FEDORA-EPEL-2014-1036) Measurement tool for TCP/UDP bandwidth performance Update Information: Moved static library to devel section Update to 3.0.3 and added devel rpm support Update to 3.0.3 and added devel rpm support ChangeLog: * Wed Apr 2 2014 Susant Sahani ssah...@redhat.com 3.0.3-2 - Moved static library to devel section only . * Sun Mar 30 2014 Susant Sahani ssah...@redhat.com 3.0.3-1 - Update to 3.0.3 and added devel rpm support References: [ 1 ] Bug #1081486 - iperf3-3.0.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1081486 mod_security-2.6.8-5.el5 (FEDORA-EPEL-2014-1041) Security module for the Apache HTTP Server Update Information: Fix Chunked string case sensitive issue (CVE-2013-5705, RHBZ #1082904 #1082905 #1082906) ChangeLog: * Tue Apr 1 2014 Athmane Madjoudj athm...@fedoraproject.org 2.6.8-5 - Fix Chunked string case sensitive issue (CVE-2013-5705, RHBZ #1082904 #1082905 #1082906) References: [ 1 ] Bug #1082904 - CVE-2013-5705 mod_security: bypass of intended rules via chunked requests https://bugzilla.redhat.com/show_bug.cgi?id=1082904 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
F21 Self Contained Change: MATE Desktop 1.8
= Proposed Self Contained Change: MATE Desktop 1.8 = https://fedoraproject.org/wiki/Changes/MATE_1.8 Change owner(s): Dan Mashal dan.mas...@fedoraproject.org, Wolfgang Ulbrich chat-to...@raveit.de Update MATE Desktop to version 1.8 == Detailed Description == Release 1.8 * New features - new mate-user-quide - add window snapping/tiling support to Marco window-manager - improved support for systemd-logind - command line panel-applet for displaying the result of a command in the panel - mpaste tool for using Mate's paste website - caja-beesu extension for opening a file as superuser - support for upower-1.0 (60% is done in rawhide) - allow rotation of mate-panel background - add support for Metacity as window manager - add shuffle mode in slideshow of eom image-viewer - eom image-viewer is migrated to lcms2 - show date and time in mate-screensaver lock dialog - show graphical time in logout/shutdown dialog - switch complete to pulseaudio, good bye gstreamer mixer - middle click on volume-applet toggles mute state - add undo functionality to Sticky-note applet - gnome-main-menu panel-applet (review request comming soon) * Renaming some packages - mate-file-manager to caja - mate-window-manager to marco - mate-text-editor to pluma - mate-document-viewer to atril - mate-menu-editor to mozo - mate-file-archiver to engrampa - mate-image-viever to eom * Replacements - mate-doc-utils with yelp-tools, help in all packages works now - single caja extensions packages are now summarized in the new caja- extensions package - libmatewnck with libwnck * Drops - mate-character-maps == Scope == * Proposal owners: 1) Upgrade all packages to 1.8 version. 2) Update comps with new package set. 3) Submit review requests for the following renamed packages: mate-file-manager - caja mate-window-manager - marco mate-image-viewer - eom mate-file-archiver - engrampa mate-text-editor - pluma mate-document-viewer - atril mate-menu-editor - mozo 4) Retire the following dropped packages: libmatewnck mate-doc-utils mate-keyring * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: GnuTLS issue (Mandos Server/Client)
On Wed, 2014-04-02 at 11:53 -0600, Nathanael D. Noblet wrote: On Wed, 2014-04-02 at 10:15 -0700, Adam Williamson wrote: Well, have you tried the 'obvious' - building the newer gnutls on CentOS 6 (or the older on Fedora 20) and building mandos against that, to see if the issue is in gnutls or somewhere else in the 'base system'? That'd narrow it down at least. Hmm that does seem obvious in hindsight. However no I haven't tried that. I figured I'd end up with a huge mess trying to recompile something like that between distros with such huge time periods all the related packages that depend on them. For example the python bindings etc... I'll look into doing it however. well, I was figuring you could build it separately from the system copy and then only link mandos (not anything else) against the 'special' copy. ought to be possible one way or another, i'd guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
Am 02.04.2014 20:18, schrieb Mikolaj Izdebski: lbzip2 is a mature project and it has been used in production for years. It is already packaged for Fedora and it is also available in EPEL. A quick check shows lbzip2 doesn't provide a library interface, much less one compatible with libbz2. Is that ever intended? That was once intended (in 2007-2010), but for now I decided to provide bzip2-compatible commands only. If there is demand I will reconsider providing a library with bzip2-compatible API/ABI. If it's not, saying lbzip2 is the default bzip2 *implementation* may be a bit of a stretch. Perhaps s/implementation/command/. You're right, the title and description may be ambiguous. In this sentence bzip2 means bzip2 command packages using the library (output of yum remove bzip2-libs-1.0.6-9.fc20.x86_64) -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gnupg-1.4.16-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket perl-Compress-Raw-Bzip2-2.062-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket libsemanage-2.1.10-14.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ImageMagick-c++-6.8.6.3-3.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket 6:kdelibs-4.12.3-1.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ffmpeg-libs-2.1.4-4.fc20.20140324.rh.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket bzip2-1.0.6-9.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ffmpeg-compat-0.6.7-4.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket python-deltarpm-3.6-3.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket libarchive-3.1.2-7.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gnome-vfs2-2.24.4-14.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket elfutils-libs-0.158-1.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket elinks-0.12-0.36.pre6.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket deltarpm-3.6-3.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket rpm-build-libs-4.11.2-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket rpm-4.11.2-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gstreamer-plugins-bad-free-0.10.23-20.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket unzip-6.0-12.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket php-5.5.10-2.fc20.20140306.rh.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ImageMagick-libs-6.8.6.3-3.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket GraphicsMagick-1.3.18-4.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket zip-3.0-9.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket php-cli-5.5.10-2.fc20.20140306.rh.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ImageMagick-6.8.6.3-3.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gstreamer1-plugins-bad-free-1.2.3-1.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gstreamer-ffmpeg-0.10.13-11.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket strigi-libs-0.7.8-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket python3-libs-3.3.2-11.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket clamav-lib-0.98.1-1.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket genisoimage-1.1.11-22.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket gnupg2-2.0.22-1.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket rpm-libs-4.11.2-2.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket 2:gimp-2.8.10-4.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket python-libs-2.7.5-11.fc20.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket ffmpeg-latest-2.2-2.fc20.20140324.rh.x86_64 verarbeitet -- Abhängigkeit libbz2.so.1()(64bit) wird für Paket tokyocabinet-1.4.48-2.fc20.x86_64 verarbeitet 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
Re: F21 Self Contained Change: NFS Ganesha File Server
Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: NFS Ganesha File Server = https://fedoraproject.org/wiki/Changes/NFSGanesha Change owner(s): Jim Lieb l...@sea-troll.net NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and NFSv4.1 including pNFS for distributed filesystems. It uses loadable filesystem driver modules to support its backend filesystems. It also integrates 9P.2000L file service. What's the long term roadmap for this vs. the existing NFS server? Why would someone choose one over the other, aside from ues with pNFS? Bill -- 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: F21 Self Contained Change: NFS Ganesha File Server
On Fri, 21 Mar 2014 13:42:57 +0100 Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: NFS Ganesha File Server = https://fedoraproject.org/wiki/Changes/NFSGanesha Change owner(s): Jim Lieb l...@sea-troll.net NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and NFSv4.1 including pNFS for distributed filesystems. It uses loadable filesystem driver modules to support its backend filesystems. It also integrates 9P.2000L file service. ...snip... From the Change page: NFS Ganesha supports the same protocols as the kernel's knfsd. Both cannot run at the same time. Systems running NFS Ganesha would stop and disable the kernel NFS server. The portmapper must be running in order for NFS Ganesha to properly export NFSv3. The idmapper must also be configured and running for NFSv4+ to operate properly. Will there be docs on how to do this? Possibly in release notes, or on the change page if they are simple enough? kevin signature.asc Description: PGP 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
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 02/04/14 19:22, Mikolaj Izdebski wrote: lbzip2 creates only *one* stream per compressed file, even when using multiple threads. Such files can be decompressed with all versions of bzip2, libbz2 and other tools, such as Apache Commons Compress. This is a difference between lbzip2 and pbzip2, which creates multiple streams. Files created with pbzip2 cannot be decompressed by some software, such as libbzip2 (all versions), bzip2 older than version 0.9.0, Apache Commons Compress. That's great then. I was aware that this was an issue with pbzip2 and wanted to make sure it wasn't a problem here. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 11:33 AM, Reindl Harald wrote: packages using the library (output of yum remove bzip2-libs-1.0.6-9.fc20.x86_64) Try: repoquery --whatrequires 'libbz2.so.1()(64bit)' We'll certainly need to keep the library around. -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 11:33 AM, Reindl Harald wrote: packages using the library (output of yum remove bzip2-libs-1.0.6-9.fc20.x86_64) Try: repoquery --whatrequires 'libbz2.so.1()(64bit)' We'll certainly need to keep the library around. Yes, but we can have /usr/bin/bzip2 (and other commands) pointing to lbzip2 binary and at the same time applications can keep using libbz2. -- Mikolaj Izdebski -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2014-04-02)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === #fedora-meeting Meeting === Meeting started by dgilmore at 18:01:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-04-02/fesco.2014-04-02-18.01.log.html . Meeting summary - --- * #1268 Mesa 10.1 rebase in F20 (dgilmore, 18:06:38) * LINK: https://fedorahosted.org/fesco/ticket/1268 (dgilmore, 18:06:40) * #1244 F21 System Wide Change: cron to systemd time units - (dgilmore, 18:13:53) * AGREED: 6+1 0-1 for approving update and ongoing exception (pjones, 18:14:18) * #1244 F21 System Wide Change: cron to systemd time units - https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units (dgilmore, 18:14:40) * LINK: https://fedorahosted.org/fesco/ticket/1244 (dgilmore, 18:14:51) * AGREED: : FESCo reccomends that FPC work with change owner to come up with suitable guidelines and we move forward with them (5+1 0-1) (dgilmore, 18:34:23) * #1250 F21 Self Contained Changes (dgilmore, 18:34:39) * LINK: https://fedorahosted.org/fesco/ticket/1250 (dgilmore, 18:34:40) * AGREED: self contained changes approved with addition to scala that they work to develop packaging guidelines (7+1 0-1) (dgilmore, 18:42:52) * #1270 F21 System Wide Change: Java 8 - https://fedoraproject.org/wiki/Changes/Java8 (dgilmore, 18:43:23) * LINK: https://fedorahosted.org/fesco/ticket/1270 (dgilmore, 18:43:34) * AGREED: Java 8 change accepted (8+1 0-1) (dgilmore, 18:45:23) * #1271 F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services - https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork (dgilmore, 18:45:54) * LINK: https://fedorahosted.org/fesco/ticket/1271 (dgilmore, 18:46:02) * AGREED: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services Change accepted (8+1 0-1) (dgilmore, 18:49:40) * notting has question to note: is disconnecting the netlink and audit namespace truly required, or just merely a choice of what they decided to remove? (dgilmore, 18:50:38) * #1269 Closing all 'Merge Review' bugs (dgilmore, 18:50:51) * LINK: https://fedorahosted.org/fesco/ticket/1269 (dgilmore, 18:50:53) * AGREED: tell provenpackagers to just fix things and make sure they know we'll support them if an unresponsive package maintainer suddenly wakes up and complains that the provenpackager did what we asked them to do. organise a vfad to get them done in a a day. (6+1 0-1) (dgilmore, 18:59:58) * open floor (dgilmore, 19:00:09) * t8m to chair next week (dgilmore, 19:00:59) * ACTION: t8m to chair next week (t8m, 19:01:17) * talk about rescheduling meeting at next week's meeting (mattdm, 19:07:03) Meeting ended at 19:08:29 UTC. Action Items - * t8m to chair next week Action Items, by person - --- * t8m * t8m to chair next week * **UNASSIGNED** * (none) People Present (lines said) - --- * dgilmore (81) * mattdm (61) * abadger1999 (57) * pjones (39) * nirik (30) * Viking-Ice (29) * zodbot (17) * t8m (15) * mitr (14) * notting (14) * willb (6) * crobinso (6) * sgallagh (5) * drago01 (3) * ajax (2) * yassinr (2) * omajid (1) * pjones- (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTPGNyAAoJEH7ltONmPFDR/moQAL7OSGRiWlG57m09khD2zV4R 70rC8iSDfldY/dOw51Gg39qm+zArBBwFfaq1uVz1vtFZywB+o5HzWNTXsZdcGysw muEyYPo1hQ4Pg5/F6hv0QJuZ/KYqsYGZAJczdP3FTOaJSA353hft58fCb41SBxUL KcSMX16ImKRjOvO0EBSnwCex1hz82+Dj/F3ulidicp0Y3vwE/i2PsTPoS3wISLBn 0Z04A6p5xZHlrpP6tdaGESvJFD9kaDq6xY59mrGosdf7fV4M2sW7hBu5jAaWTrLB 0oKzW9nPqSVh4qxgt9FYK1M+yf28SauWbSCTGSrK7fRJA22PmvJOCq+aURVuSTuB PGL65bEPdVx/3W5h4D8Rmr0oFCPOL8rcu9F47zrjHQGz8dGIOj331j16mFcxyTha dLquAxPIQO/DZwHOl5W+UdF+Qj2Pvg5EvLsoQUYOtlYQP0jvZLgTNKuMkiVVitcQ OSVTJd77PMsm5C89uaAVdm4KvPl4FPJCkuxWHbK1iw0jq2+SsChsi631TP9fGjza uIVusOPAg67YFAjdABA7MBjuc6WG57qh/np0+Suh6lzF22CemARp4uCG6LJYmvFW jGDizKovliTm6b8DpbvfB1M1qevURIvOwjLPJNhdbQ6eJuKT2lLjS2bTO9w2Kfbm OFhmM/8DuVqdDrL/4gri =vv6J -END PGP 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
Self Introduction: Guy Streeter
I've been a software developer for 30 years and at Red Hat for 14 years. I've done a lot of kernel development and other software development, and currently work in kernel support. I've written python bindings and classes for the hwloc (Portable Hardware Locality) library, and I have submitted a review request at https://bugzilla.redhat.com/show_bug.cgi?id=1083720 --Guy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2014-04-03 16:00 UTC) (post DST change UTC time)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-04-3 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. NOTE: UTC is now 1 hour _later_ than last week, due to DST changes. Local time information (via. rktime): 2014-04-03 09:00 Thu US/Pacific PDT 2014-04-03 12:00 Thu US/Eastern EDT 2014-04-03 16:00 Thu UTC - 2014-04-03 17:00 Thu Europe/London BST 2014-04-03 18:00 Thu Europe/Paris CEST 2014-04-03 18:00 Thu Europe/Berlin CEST 2014-04-03 21:30 Thu Asia/Calcutta IST --new day-- 2014-04-04 00:00 Fri Asia/Singapore SGT 2014-04-04 00:00 Fri Asia/Hong_Kong HKT 2014-04-04 01:00 Fri Asia/Tokyo JST 2014-04-04 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 (too big to fail vote?) #topic #391 Exception for bundled libraries in icecat .fpc 391 https://fedorahosted.org/fpc/ticket/391 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (remaining votes needed) #topic #405 Downstream versioning of shared libraries. .fpc 405 https://fedorahosted.org/fpc/ticket/405 (remaining votes needed) #topic #407 Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng .fpc 407 https://fedorahosted.org/fpc/ticket/407 (remaining votes needed) #topic #408 Temporary jquery bundling exception for libserialport .fpc 408 https://fedorahosted.org/fpc/ticket/408 = New business = #topic #409 Ruby guidelines: Updates for F21 .fpc 409 https://fedorahosted.org/fpc/ticket/409 #topic #411 proposal: migrate license files to %license instead of %doc .fpc 411 https://fedorahosted.org/fpc/ticket/411 #topic #412 Please change the packaging guidelines to include packaging policy regarding systemd timer units .fpc 412 https://fedorahosted.org/fpc/ticket/412 #topic #413 Bundling exception request for nodejs-shelljs .fpc 413 https://fedorahosted.org/fpc/ticket/413 #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 #topic #415 Temporary Javascript bundling exception for Ambari dependencies .fpc 415 https://fedorahosted.org/fpc/ticket/415 = 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/12 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 02, 2014 at 03:10:23PM -0400, Mikolaj Izdebski wrote: On 04/02/2014 11:33 AM, Reindl Harald wrote: packages using the library (output of yum remove bzip2-libs-1.0.6-9.fc20.x86_64) Try: repoquery --whatrequires 'libbz2.so.1()(64bit)' We'll certainly need to keep the library around. Yes, but we can have /usr/bin/bzip2 (and other commands) pointing to lbzip2 binary and at the same time applications can keep using libbz2. Hm, both python-libs and python3-libs, and rpm are on the list. This means that basically every system will have two implementations of bzip2. Not *that* big of an issue, but it certainly would be nicer to add the library interface so that we can get rid of this duplication. Zbyszek -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? Zbyszek -- 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: Fedora ARM Status Meeting 2014-04-02
Thanks to everyone who made it, due to low attendance we've decided to postpone the meeting. Paul - Original Message - Please join us today (Wednesday, April 2nd) at 4PM EDT (8PM UTC) for the Fedora ARM status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 1) Fedora.Next 2) Fedora ARM Remixes 3) Deployment Tool to Customize Disk Images 4) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 2, 2014 at 10:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? Why would people prefer it? If it is the same but slower? -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 2 April 2014 21:46, drago01 drag...@gmail.com wrote: On Wed, Apr 2, 2014 at 10:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? Why would people prefer it? If it is the same but slower? Yes, if it's interface compatible then it's pretty nice. Multithreaded compression is handy from time to time. Pity about no library interface (lbzip2 might be an unfortunate name choice...), particularly for things like perl and python. I suppose from the pov of minimal systems it might be nice to not have to have both if you need to fulfil both a bzip2 library requirement and a bzip2 requirement, but that's a very particular case for a few kB saving. -- imalone http://ibmalone.blogspot.co.uk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wednesday, April 2, 2014, 4:27:55 PM, Zbigniew Jędrzejewski-Szmek wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? This sounds like a very intrusive change that in the worst case could introduce errors and expose user data to permanent loss without any means to recover. Many tools read and write zip files. The actual ZIP standard format is controlled by (coordinated by) PKZIP via their application note. There is a lot of discussion about common extensions, but each tool can have their own private extensions that may be incompatible. The InfoZIP team that gives you the zip and unzip tools has added support for the bzip2 and lzma compression and decompression algorithms, as well as AES encryption/decryption in their upcoming beta release. I've been involved in reworking U*IX build support, and working towards better support on mainframe platforms (z/OS, z/VM) and AIX. I do all my primary development and testing on Fedora, but others have their own preferred platform. This implementation has been built and extensively tested using the current release of the real bzip2 library. Substituting a completely different library implementation without going through extensive and explicit validating and testing is risky and unreasonable. At best, it would complicate problem reporting, reproduction, analysis and correction. The libzip effort is not part of the InfoZIP project. They may have created a wonderful library, but it will not have identical interfaces and behaviours as the original bzip2 library. Let the upstream tools decide which bzip implementation(s) to support, and do the necessary validation to ensure that it all works correctly. It is the upstream tool's reputation that would be damaged if the Fedora library caused user data to be lost. Let them do their job correctly. Final gloomy thought of the day: Breaking zip files could you are breaking the actual tool used for backups. That makes data loss a very permanent problem. Al -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? You could do that, but then two packages would have the same virtual provide and it wouldn't be well defined which one would be installed. In such cases YUM seems to choose packages with shorter names, so it would prefer bzip2 over lbzip2. At least one package somewhere low in the system has to require lbzip2 explicitly. I think that package maintainers who want to use lbzip2 should declare it as explicit dependency. Assuming that packages are calling standard bzip2 command names (bzip2, bzcat and so on) users will still be able to switch implementations as they want by configuring alternatives, even if package has requires on lbzip2. We don't need to migrate all packages to Require lbzip2. If lbzip2 has highest priority in alternatives then it will be used as long as it is installed. It doesn't even need to Provide bzip2. It should be enough to include lbzip2 in minimal installation and add is a dependency of @buildsys-build to effectively make it default implementation. -- Mikolaj Izdebski -- 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: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2014-04-03 16:00 UTC) (post DST change UTC time)
On Wed, Apr 02, 2014 at 04:20:16PM -0400, James Antill wrote: (too big to fail vote?) #topic #391 Exception for bundled libraries in icecat .fpc 391 https://fedorahosted.org/fpc/ticket/391 Yep, there's four separate new exception criteria posted on: https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation that we can cote for. #topic #411 proposal: migrate license files to %license instead of %doc .fpc 411 https://fedorahosted.org/fpc/ticket/411 #topic #412 Please change the packaging guidelines to include packaging policy regarding systemd timer units .fpc 412 https://fedorahosted.org/fpc/ticket/412 These two are part of Fedora Changes/fedora.next so we'll probably move them up in the schedule. -Toshio pgpRd1Tmx7Ltd.pgp Description: PGP 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
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 2 April 2014 21:46, drago01 drag...@gmail.com wrote: On Wed, Apr 2, 2014 at 10:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? Why would people prefer it? If it is the same but slower? Yes, if it's interface compatible then it's pretty nice. Multithreaded compression is handy from time to time. Pity about no library interface (lbzip2 might be an unfortunate name choice...), particularly for things like perl and python. I suppose from the pov of minimal systems it might be nice to not have to have both if you need to fulfil both a bzip2 library requirement and a bzip2 requirement, but that's a very particular case for a few kB saving. It shouldn't be difficult to provide library interface. In fact I considered planned it from the very beginning, but then lacked motivation. I'm sure that accepting this Change will be a motivator good enough for me to finally do this. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 02, 2014 at 05:14:53PM -0400, Al Dunsmuir wrote: This implementation has been built and extensively tested using the current release of the real bzip2 library. Substituting a completely different library implementation without going through extensive and explicit validating and testing is risky and unreasonable. At best, it would complicate problem reporting, reproduction, analysis and correction. The suggestion is to replace the tool, not the library. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
Hello Al, On Wednesday, April 2, 2014, 5:14:53 PM, Al Dunsmuir wrote: On Wednesday, April 2, 2014, 4:27:55 PM, Zbigniew Jędrzejewski-Szmek wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 or something so that updating all those packages is not necessary, and also that people who prefer normal bzip2 can still use it? It's been a long day. In my haste to reply, I wrote libzip where I meant to say lbzip2. The rest of my point remains unchanged. By the way, part of the reason for my slip is that while I have heard of a libzip library, I have never heard of lbzip2 before. I've never seen it come up with web searches related to the InfoZIP work to support bzip2 encoding. I'm going to post the original post and my comments in the private InfoZIP development list, but I suspect I will get responses that I am not the only person becoming aware of this new tool. Al -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
This implementation has been built and extensively tested using the current release of the real bzip2 library. Substituting a completely different library implementation without going through extensive and explicit validating and testing is risky and unreasonable. At best, it would complicate problem reporting, reproduction, analysis and correction. lbzip2 does not (at least not yet) provide interfaces of libbz2 library, only command line tools. This Change does *not* affect users of libbz2. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 2, 2014 at 11:39 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Mikolaj Izdebski mizde...@redhat.com said: lbzip2 does not (at least not yet) provide interfaces of libbz2 library, only command line tools. This Change does *not* affect users of libbz2. Is there enough of a gain to the system to only partially replace a core program like this (especially with alternatives)? This seems like a case where either we get a new and improved and replaces the old version (where the new one just obsoletes the old one, such as the jpeg-turbo change), or just leave it alone. Please understand, I don't mean to attack you or your code. I just think adding a second implementation of a core utility like bzip2 is a bad idea unless there is a significant gain. If there's a point where lbzip2 can fully replace bzip2 (so all CLI and API uses), and there are good benefits, then Fedora should just replace the old implementation with a new one. Well the change says multi-threaded operation for both compression and decompression, with almost linear scalability linear scalability means speed ups on the range of 2-8x on current desktop / laptop systems. Which I'd call a significant gain ;) -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
Once upon a time, Mikolaj Izdebski mizde...@redhat.com said: lbzip2 does not (at least not yet) provide interfaces of libbz2 library, only command line tools. This Change does *not* affect users of libbz2. Is there enough of a gain to the system to only partially replace a core program like this (especially with alternatives)? This seems like a case where either we get a new and improved and replaces the old version (where the new one just obsoletes the old one, such as the jpeg-turbo change), or just leave it alone. Please understand, I don't mean to attack you or your code. I just think adding a second implementation of a core utility like bzip2 is a bad idea unless there is a significant gain. If there's a point where lbzip2 can fully replace bzip2 (so all CLI and API uses), and there are good benefits, then Fedora should just replace the old implementation with a new one. -- Chris Adams li...@cmadams.net -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 2, 2014 at 11:39 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Mikolaj Izdebski mizde...@redhat.com said: lbzip2 does not (at least not yet) provide interfaces of libbz2 library, only command line tools. This Change does *not* affect users of libbz2. Is there enough of a gain to the system to only partially replace a core program like this (especially with alternatives)? This seems like a case where either we get a new and improved and replaces the old version (where the new one just obsoletes the old one, such as the jpeg-turbo change), or just leave it alone. Eventually lbzip2 may replace bzip2, but I don't want to make any drastic changes. Using alternatives allows us to have a nice contingency plan in case something goes unexpected. Once lbzip2 is used by default, further chnages will be just a metter of agreement between maintainers. Please understand, I don't mean to attack you or your code. I just think adding a second implementation of a core utility like bzip2 is a bad idea unless there is a significant gain. If there's a point where lbzip2 can fully replace bzip2 (so all CLI and API uses), and there are good benefits, then Fedora should just replace the old implementation with a new one. I believe there is a signifficant gain, see below. Well the change says multi-threaded operation for both compression and decompression, with almost linear scalability linear scalability means speed ups on the range of 2-8x on current desktop / laptop systems. Which I'd call a significant gain ;) I don't have any recent benchmark comparing performance of lbzip2 with bzip2 because doing them doesn't make much sense for me -- lbzip2 is so much faster. I compare only different versions to make sure there are no performance regressions. However I have one *old* benchmark made just after lbzip2 2.0 release 2 and half years ago (current version is 2.5). But since then lbzip2 was improved. https://github.com/kjn/lbzip2/wiki/Benchmark:-Opteron-24 I will prepare more benchmarks of recent lbzip2 version for desktop (1, 2, 4, 8 cores) and bigger multicore server systems. A test of scalability (pretty old too) is available at: http://archive.lbzip2.org/scaling/scaling.html I hope that's convincing enough for now. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wednesday, April 2, 2014, 2:03:38 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: lbzip2 as default bzip2 implementation = https://fedoraproject.org/wiki/Changes/lbzip2 Change owner(s): Mikolaj Izdebski mizde...@redhat.com This change aims at making lbzip2 [1] default bzip2 implementation used in Fedora. == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, * improved performance, even on single-core systems, * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), * improved compatibility with gzip. lbzip2 is a mature project and it has been used in production for years. It is already packaged for Fedora and it is also available in EPEL. A quick check shows lbzip2 doesn't provide a library interface, much less one compatible with libbz2. Is that ever intended? If it's not, saying lbzip2 is the default bzip2 *implementation* may be a bit of a stretch. Perhaps s/implementation/command/. Bill, This clarification is significant. The change proposal text needs to be updated to reflect this. As long as the encoding is guaranteed to be byte-for-byte identical to that produced by the original bzip2 (and libbz2) implementation, the risks are lowered. Scenarios affected by this substitution are those with direct invocation of the command (from the command prompt, a shell script, or system() type call). The lbzip2 utility sounds interesting, and I am now disappointed that there is no separate library interface with these characteristics that we can investigate using instead of libbz2. As later comments state, perhaps in the future. Al -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
This clarification is significant. The change proposal text needs to be updated to reflect this. I will add a clarification tomorrow. As long as the encoding is guaranteed to be byte-for-byte identical to that produced by the original bzip2 (and libbz2) implementation, the risks are lowered. No, encoding is almost never bytewise identical to bzip2, but it doesn't have to be as long as the resulting bz2 file has correct format. bzip2 itself changed encoding between versions without any impact on users. Even the same version of bzip2 can produce different compressed files for the same input with and with the same block size. lbzip2 uses improved algorithms, which are not only faster, but allow for slighty better compression ratio, for example: $ echo test | bzip2 | wc -c 45 $ echo test | lbzip2 | wc -c 43 Scenarios affected by this substitution are those with direct invocation of the command (from the command prompt, a shell script, or system() type call). That's true. And even in the unlikely case that something goes wrong, developers (or even users themselves) have possibility to easily switch back to bzip2. -- Mikolaj Izdebski -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On 2 April 2014 17:15, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). I haven't seen a ticket listed and the wiki entry does not mention one. I personally think it is a bad default having had to deal with this from people who did this with the old Bastille scripts and choosing the equivalent to SECURE EVERYTHING without knowing exactly what that idd no matter how many Do you really want to do that? popups. While it sounds like a useful task, it basically requires a bad sudo file and you are now having to use very complicated rescue steps to get back into the box (and if you added other things.. maybe not even that.) This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- 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: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
On Tue, Apr 1, 2014 at 6:39 AM, Marcela Mašláňová mmasl...@redhat.com wrote: * Open Questions - Playground: Signing (mmaslano, 12:04:12) I saw that this got voted on in the meeting even though it didn't get recorded as such for the meeting minutes. The proposal seemed to be: use obs-sign to sign packages. That's not actually a proposal that we can approve here. The proposal here should probably be: is signing of packages a blocker for making the playground repo, nice to have, or optional? In terms of how to get the packages signed, that's something that the infrastructure team has to decide. IIRC past conversations correctly, adding another signing server (meaning a different code base) to infrastructure is at the bottom of their list of ways to sign packages in copr (and by extension in the playground repo). When I saw the vote in the meeting logs I mentioned it to nirik. In turn he told me that he hadn't heard anything about this and had only glanced briefly at obs-sign (mentioning that it wasn't even packaged for Fedora yet). As I related to tjanez on IRC today, I think lack of packaging probably slows down infra's ability to deploy it but is only a foottnote to the real problems. Compromising signing servers and gaining access to the private keys on them is a very high value target for an attacker. The more signing servers we have the greater the attack surface infrastructure has to protect. probably in the ideal scenario infra would run a single signing server and everything needing signing would be sent to that. (Jesse Kating had that use in mind when he designed sigul but I don't know if that design goal actually became part of the software that we are currently running). A step down from there might be running multiple instances of the same signing software to handle the various needs as infra would then have to protect the keys on these multiple hosts. At the bottom of the list is running separate signing software as that places the additional burden of auditing and protecting the software stack of the multiple signing servers. For whoever is going to approach infra about signing the packages in copr it probably makes more sense to either talk about enhancing sigul to work with copr or getting obs-sign to be able to sign packages from koji. We'd probably also want to ask bressers or someone else from the security team to do some sort of evaluation of the code bases that we're looking at. -Toshio -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
Once upon a time, drago01 drag...@gmail.com said: Well the change says multi-threaded operation for both compression and decompression, with almost linear scalability linear scalability means speed ups on the range of 2-8x on current desktop / laptop systems. Which I'd call a significant gain ;) That depends. If I made an alternate mv that ran 10 times faster, would we go through the pain of alternatives to offer two options for it? How much impact on real-world system usage will speeding up the bzip2 command offer? Many of the common users (such as rpm) are linked against the library and don't use the command, so they won't be impacted. We'll end up with more disk space used, because the current /usr/bin/bzip2 and friends are linked against the library (so there's only one copy of bzip2 code). Since lbzip2 doesn't offer a library, I guess each program has to have a copy of the code, and other system tools will still use the bzip2 library. I think the right way to move forward is to make a library that is at least API-compatible with the current libbz2.so.1, make all the tools use it, and just replace bzip2 with lbzip2. -- Chris Adams li...@cmadams.net -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote: I think the right way to move forward is to make a library that is at least API-compatible with the current libbz2.so.1, make all the tools use it, and just replace bzip2 with lbzip2. Although I'm still on the fence about whether I'd vote for the Change as is, I tend to agree with this sentiment. Having two sets of code with different characteristics seems like isomething of a disservice to users (I started bzip'ing my logs and backups because the performance was suitable for my task when I tested with /usr/bin/bzip2 but then when I operated on those logs with a custom python script it was 3x slower!) From past precedent I agree that getting the new package to the point where we think it's a suitable replacement and then just making the switch for the next release makes the most sense. -Toshio pgp1_BNd0eyBq.pgp Description: PGP 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
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 02, 2014 at 07:26:59PM -0700, Toshio Kuratomi wrote: On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote: I think the right way to move forward is to make a library that is at least API-compatible with the current libbz2.so.1, make all the tools use it, and just replace bzip2 with lbzip2. Although I'm still on the fence about whether I'd vote for the Change as is, I tend to agree with this sentiment. Having two sets of code with different characteristics seems like isomething of a disservice to users (I started bzip'ing my logs and backups because the performance was suitable for my task when I tested with /usr/bin/bzip2 but then when I operated on those logs with a custom python script it was 3x slower!) From past precedent I agree that getting the new package to the point where we think it's a suitable replacement and then just making the switch for the next release makes the most sense. I agree that this is desirable. OTOH, lbzip2.rpm is 90k, so I guess we can suffer the extra disk usage :) Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
My plan is to retire these two xorg input drivers in rawhide in a week or two. They are superseded by the evdev driver which is the default driver for input devices in Linux. Both drivers are still maintained upstream to get them to work you have to use custom xorg.conf files that disable other features (e.g. device hotplugging). There shouldn't be a need to use either driver under Linux. In fact, the default behaviour since Fedora 11 or so has been to ignore any mouse or keyboard entries and use evdev anyway. I think (almost?) all the bugs filed against mouse and keyboard are a result of the wrong package selection (my mouse doesn't work? must be xorg-x11-drv-mouse then). Actually, not true, the most avid filer of bug reports for these two packages is the upstream release monitoring script. This _will_ break some setups. If you have AutoAddDevices off in your xorg.conf then this will break. The main question to ask here is: do these setups still exist and if so why do you have that option set and can we fix the reason for it being set in the first place? Speak up now, or forever hold yada yada... Cheers, Peter -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Thu, Apr 03, 2014 at 04:48:03AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 02, 2014 at 07:26:59PM -0700, Toshio Kuratomi wrote: On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote: I think the right way to move forward is to make a library that is at least API-compatible with the current libbz2.so.1, make all the tools use it, and just replace bzip2 with lbzip2. Although I'm still on the fence about whether I'd vote for the Change as is, I tend to agree with this sentiment. Having two sets of code with different characteristics seems like isomething of a disservice to users (I started bzip'ing my logs and backups because the performance was suitable for my task when I tested with /usr/bin/bzip2 but then when I operated on those logs with a custom python script it was 3x slower!) From past precedent I agree that getting the new package to the point where we think it's a suitable replacement and then just making the switch for the next release makes the most sense. I agree that this is desirable. OTOH, lbzip2.rpm is 90k, so I guess we can suffer the extra disk usage :) If it was about disk usage :-) But it's not. It's about having two codebases that do the same thing in different ways. -Toshio pgp5MTiU5Fmrw.pgp Description: PGP 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
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, Apr 3, 2014 at 12:09 AM, Peter Hutterer peter.hutte...@who-t.netwrote: My plan is to retire these two xorg input drivers in rawhide in a week or two. They are superseded by the evdev driver which is the default driver for input devices in Linux. Speak up now, or forever hold yada yada... Hello Peter, With the software bumblebee, there seems to be a need for these packages. But I am not really sure why. I don't know if the evdev driver could work around this problem? If the packages are not installed, then the error message one gets is: [ 901.442296] [ERROR]Cannot access secondary GPU - error: XORGhttps://github.com/Bumblebee-Project/Bumblebee/issues/EEFailed to load module mouse The solution I was told on github is to install xorg-x11-drv-mouse and xorg-x11-drv-keyboard packages. Which did indeed solve the problem in fedora 20. The xorg.conf file in this case is: /etc/bumblebee/xorg.conf.nvidia The bumblebee developers have set Option AutoAddDevices false Should that / can that be changed do you think? Just wanted to mention this in case other fedora users have optimus laptops they use with the nvidia drivers? bumblebee is a solution that has been invented for hybrid graphics laptops with intel and Nvidia GPUs. It runs another X server in memory and copies the visuals with software. Either with VirtualGL or primus. Cheers, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bumblebee reviewer needed (Was: Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard)
On Thu, Apr 3, 2014 at 12:40 PM, Gary Gatling gsgat...@ncsu.edu wrote: Just wanted to mention this in case other fedora users have optimus laptops they use with the nvidia drivers? bumblebee is a solution that has been invented for hybrid graphics laptops with intel and Nvidia GPUs. It runs another X server in memory and copies the visuals with software. Either with VirtualGL or primus. Just another note that due to my knowledge on optimus I decide to drop the review of bumblebee[1], and someone told me it's just a dirty hack. If you are interested in this package, feel free to take it. Thanks. [1]--https://bugzilla.redhat.com/show_bug.cgi?id=827167 Yours sincerely, Christopher Meng Noob here. http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 914310] perl-Padre: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=914310 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2014-04-02 03:03:50 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=41kTDJhBR8a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083392] New: perl-HTTP-Request-Params FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083392 Bug ID: 1083392 Summary: perl-HTTP-Request-Params FTBFS Product: Fedora Version: 20 Component: perl-HTTP-Request-Params Assignee: tcall...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com perl-HTTP-Request-Params-1.01 fails to build in F21 or F20 due to tests: + make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t Can't locate object method new via package Email::MIME at /home/petr/fedora/perl-HTTP-Request-Params/HTTP-Request-Params-1.01/blib/lib/HTTP/Request/Params.pm line 86. # Looks like your test exited with 255 just after 3. t/test.t .. Dubious, test returned 255 (wstat 65280, 0xff00) All 3 subtests passed Test Summary Report --- t/test.t (Wstat: 65280 Tests: 3 Failed: 0) Non-zero exit status: 255 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.07 cusr 0.01 csys = 0.11 CPU) Result: FAIL -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7IYCfBEA01a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083396] New: perl-Padre-0.90-10.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083396 Bug ID: 1083396 Summary: perl-Padre-0.90-10.fc21 FTBFS Product: Fedora Version: rawhide Component: perl-Padre Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com perl-Padre-0.90-10.fc21 fails to build in F21 due to t/50-browser.t test failures: # Failed test 'undef isa 'Padre::Browser::Document'' # at t/50-browser.t line 47. # undef isn't defined Can't call method mimetype on an undefined value at t/50-browser.t line 48. # Looks like you planned 14 tests but ran 9. # Looks like you failed 1 test of 9 run. # Looks like your test exited with 25 just after 9. t/50-browser.t . Dubious, test returned 25 (wstat 6400, 0x1900) Failed 6/14 subtests [...] Test Summary Report --- t/27_task_signal.t (Wstat: 0 Tests: 16 Failed: 0) TODO passed: 15 t/50-browser.t (Wstat: 6400 Tests: 9 Failed: 1) Failed test: 8 Non-zero exit status: 25 Parse errors: Bad plan. You planned 14 tests but ran 9. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FgXUJue3IZa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083392] perl-HTTP-Request-Params FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083392 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|tcall...@redhat.com |ppi...@redhat.com External Bug ID||CPAN 86635 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=xPEo9DKZ85a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-Request-Params] Correct Email::MIME usage
commit ff829d867c314bafe84a862a4cdda1b26776a00f
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 2 09:35:09 2014 +0200
Correct Email::MIME usage
HTTP-Request-Params-1.01-RT86635.patch | 28
perl-HTTP-Request-Params.spec |9 -
2 files changed, 36 insertions(+), 1 deletions(-)
---
diff --git a/HTTP-Request-Params-1.01-RT86635.patch
b/HTTP-Request-Params-1.01-RT86635.patch
new file mode 100644
index 000..ca51c47
--- /dev/null
+++ b/HTTP-Request-Params-1.01-RT86635.patch
@@ -0,0 +1,28 @@
+From d2f2dd3cf76d4e33e8d75e5b2ee1de3a37565a9e Mon Sep 17 00:00:00 2001
+From: Slaven Rezic sla...@rezic.de
+Date: Wed, 3 Jul 2013 14:16:43 +0200
+Subject: [PATCH] added missing use Email::MIME
+
+It seems that with newer Email-MIME distribution there was
+some refactoring, so including Email::MIME::Modifier and/or
+Email::MIME::ContentType does not trigger loading of
+Email::MIME anymore.
+---
+ lib/HTTP/Request/Params.pm |1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+diff --git a/lib/HTTP/Request/Params.pm b/lib/HTTP/Request/Params.pm
+index f5e6e5f..b7e2adb 100644
+--- a/lib/HTTP/Request/Params.pm
b/lib/HTTP/Request/Params.pm
+@@ -22,6 +22,7 @@ use vars qw[$VERSION];
+ $VERSION = sprintf %d.%02d, split m/\./, (qw$Revision: 1.1 $)[1];
+
+ use CGI;
++use Email::MIME;
+ use Email::MIME::Modifier;
+ use Email::MIME::ContentType qw[parse_content_type];
+ use HTTP::Request;
+--
+1.7.2.5
+
diff --git a/perl-HTTP-Request-Params.spec b/perl-HTTP-Request-Params.spec
index 2c462ea..bad9090 100644
--- a/perl-HTTP-Request-Params.spec
+++ b/perl-HTTP-Request-Params.spec
@@ -1,12 +1,14 @@
Name: perl-HTTP-Request-Params
Version:1.01
-Release:15%{?dist}
+Release:16%{?dist}
Summary:Retrieve GET/POST Parameters from HTTP Requests
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/HTTP-Request-Params/
Source0:
http://www.cpan.org/authors/id/C/CW/CWEST/HTTP-Request-Params-%{version}.tar.gz
+# Correct Email::MIME usage, CPAN RT#86635, bug #1083392
+Patch0: HTTP-Request-Params-1.01-RT86635.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -15,6 +17,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Class::Accessor::Fast) = 0.19
BuildRequires: perl(HTTP::Request) = 1.40
+BuildRequires: perl(Email::MIME)
BuildRequires: perl(Email::MIME::Modifier) = 1.42
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Class::Accessor::Fast) = 0.19
@@ -26,6 +29,7 @@ incoming query parameters.
%prep
%setup -q -n HTTP-Request-Params-%{version}
+%patch0 -p1
%build
@@ -57,6 +61,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Apr 02 2014 Petr Pisar ppi...@redhat.com - 1.01-16
+- Correct Email::MIME usage (bug #1083392)
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.01-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-Request-Params/f20] Correct Email::MIME usage
Summary of changes: ff829d8... Correct Email::MIME usage (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083392] perl-HTTP-Request-Params FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083392 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-HTTP-Request-Params-1.01-16.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-HTTP-Request-Params-1.01-16.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=QFDiPii8kBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083392] perl-HTTP-Request-Params FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083392 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-HTTP-Request-Params-1. ||01-16.fc21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=oKWs8GZS3Oa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083418] New: perl-Log-Dispatch-2.41-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083418 Bug ID: 1083418 Summary: perl-Log-Dispatch-2.41-1.fc21 FTBFS Product: Fedora Version: rawhide Component: perl-Log-Dispatch Assignee: tcall...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de, tcall...@redhat.com perl-Log-Dispatch-2.41-1.fc21 fails to build in F21 due to test plan for t/01-basic.t: t/01-basic.t(Wstat: 0 Tests: 344 Failed: 167) Failed tests: 11-177 Parse errors: Plan (1..177) must be at the beginning or end of the TAP output Tests out of sequence. Found (11) but expected (178) Tests out of sequence. Found (12) but expected (179) Tests out of sequence. Found (13) but expected (180) Tests out of sequence. Found (14) but expected (181) Displayed the first 5 of 170 TAP syntax errors. The problem is: $ LOG_DISPATCH_TEST_EMAIL=root@localhost.localdomain prove -l -v t/01-basic.t t/01-basic.t .. ok 1 - created Log::Dispatch object ok 2 - First line in log file set to level 'emerg' is 'emerg level 1' ok 3 - Second line in log file set to level 'emerg' is 'emerg level 2' ok 4 - First line in log file set to level 'debug' is 'info level 2' ok 5 - Second line in log file set to level 'debug' is 'emerg level 2' ok 6 - second LD object used syswrite ok 7 - First line in log file with a max level of 'crit' is 'critical' ok 8 - Log::Dispatch::Handle created log file should contain 'handle test\n' # Sending email with Mail::Send to root@localhost.localdomain. # If you get it then the test succeeded (PID 3444) No real MTA found, using 'testfile' at /usr/share/perl5/vendor_perl/Mail/Mailer.pm line 108. ok 9 - sent email via MailSend # Sending email with Mail::Sendmail to root@localhost.localdomain. # If you get it then the test succeeded (PID 3444) Error sending mail: connect to localhost failed (Connection refused) connect to localhost failed connect to localhost failed (Connection refused) no (more) retries! ok 10 - sent email via MailSendmail # Sending email with MIME::Lite to root@localhost.localdomain. # If you get it then the test succeeded (PID 3444) ok 11 - sent mail via MIMELite [...] ok 177 - code received the expected messages 1..177 ok 11 - sent mail via MIMELite [...] ok 177 - code received the expected messages 1..177 Something echoes the output since test 11 twice which break TAP. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7FN7o2MSWaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083418] perl-Log-Dispatch-2.41-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1083418
--- Comment #1 from Petr Pisar ppi...@redhat.com ---
It's because emitting TAP messages after undefining Log::Dispatch object. E.g.
here:
# Log::Dispatch::Email::MIMELite
SKIP:
{
skip Cannot do MIMELite tests, 1
unless $tests{MIMELite} $TestConfig{email_address};
my $dispatch = Log::Dispatch-new;
$dispatch-add(
Log::Dispatch::Email::MIMELite-new(
name = 'Mime::Lite',
min_level = 'debug',
to= $TestConfig{email_address},
subject = 'Log::Dispatch test suite'
)
);
$dispatch-log(
level = 'emerg',
message =
MIME::Lite - If you can read this then the test succeeded (PID
$$)
);
diag(
Sending email with MIME::Lite to $TestConfig{email_address}.\nIf you
get it then the test succeeded (PID $$)\n
);
undef $dispatch;
ok( 1, 'sent mail via MIMELite' );
}
The 'sent mail via MIMELite', the first doubled TAP message, gets doubled
because it is invoked after undef $dispatch.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=nGgul1Cd6sa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Checksums] Remove more debuginfo remnants before running tests
commit 95708e6741936c545097d69fd1148b4fac5b5e2b
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 2 10:51:56 2014 +0200
Remove more debuginfo remnants before running tests
perl-CPAN-Checksums.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-CPAN-Checksums.spec b/perl-CPAN-Checksums.spec
index f99b95a..192c0b2 100644
--- a/perl-CPAN-Checksums.spec
+++ b/perl-CPAN-Checksums.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Checksums
Version:2.08
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Write a CHECKSUMS file for a directory as on CPAN
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,7 +46,7 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%check
# test checks MANIFEST - would fail because of debug files
-rm -rf ./debugfiles.list ./debuglinks.list ./debugsources.list
+rm -rf ./elfbins.list ./debugfiles.list ./debuglinks.list ./debugsources.list
make test
%files
@@ -55,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Apr 02 2014 Petr Pisar ppi...@redhat.com - 2.08-8
+- Remove more debuginfo remnants before running tests
+
* Sun Aug 04 2013 Petr Pisar ppi...@redhat.com - 2.08-7
- Perl 5.18 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Checksums/f20] Remove more debuginfo remnants before running tests
Summary of changes: 95708e6... Remove more debuginfo remnants before running tests (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1077585] perl-Class-MethodMaker-2.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1077585 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Class-MethodMaker-2.21 ||-1.fc19 Resolution|--- |ERRATA Last Closed||2014-04-02 05:06:18 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Class-MethodMaker-2.21-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=aGXdHQIjT7a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-SSL-1.974.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 1452f0c298b2278f7a0a95550c0228ce IO-Socket-SSL-1.974.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061003] FTBFS: perl-Data-ObjectDriver-0.09-9.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1061003 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Data-ObjectDriver-0.09 ||-10.fc20 Resolution|--- |ERRATA Last Closed||2014-04-02 05:10:15 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Data-ObjectDriver-0.09-10.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NWjO0VY26ua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Update to 1.974
commit 6156255fa49651d58f920abe139eee3b2831d9bb
Author: Paul Howarth p...@city-fan.org
Date: Wed Apr 2 10:09:58 2014 +0100
Update to 1.974
- New upstream release 1.974
- New function peer_certificates to get the whole certificate chain; needs
Net::SSLeay ≥ 1.58
- Extended IO::Socket::Utils::CERT_asHash to provide way more information,
like issuer information, cert and pubkey digests, all extensions, CRL
distribution points and OCSP uri
perl-IO-Socket-SSL.spec | 10 +-
sources |2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index d0071ac..a1bc6a5 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.973
+Version: 1.974
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -72,6 +72,14 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
%changelog
+* Wed Apr 2 2014 Paul Howarth p...@city-fan.org - 1.974-1
+- Update to 1.974
+ - New function peer_certificates to get the whole certificate chain; needs
+Net::SSLeay ≥ 1.58
+ - Extended IO::Socket::Utils::CERT_asHash to provide way more information,
+like issuer information, cert and pubkey digests, all extensions, CRL
+distribution points and OCSP uri
+
* Wed Mar 26 2014 Paul Howarth p...@city-fan.org - 1.973-1
- Update to 1.973
- With SSL_ca, certificate handles can now be used in addition to
diff --git a/sources b/sources
index c86858f..06b4123 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99215f419adcf1245c0aa7ce6c7a82f2 IO-Socket-SSL-1.973.tar.gz
+1452f0c298b2278f7a0a95550c0228ce IO-Socket-SSL-1.974.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.974-1.fc21
The lightweight tag 'perl-IO-Socket-SSL-1.974-1.fc21' was created pointing to: 6156255... Update to 1.974 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1077585] perl-Class-MethodMaker-2.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1077585 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Class-MethodMaker-2.21 |perl-Class-MethodMaker-2.21 |-1.fc19 |-1.fc20 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Class-MethodMaker-2.21-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=rV8mc4ZovMa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Glib-Object-Introspection-0.022.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Glib-Object-Introspection: e3e5d150658b11f8313bc97a4986a0bf Glib-Object-Introspection-0.022.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1040414] perl-Glib-Object-Introspection-0.022 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1040414 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppi...@redhat.com Assignee|berra...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=MYUMVHIoDva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib-Object-Introspection] 0.022 bump
commit 90c77730df09b6078cc25c2e20674a73c6923477
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 2 12:38:51 2014 +0200
0.022 bump
.rpmlint|2 ++
perl-Glib-Object-Introspection.spec | 26 +++---
sources |2 +-
3 files changed, 22 insertions(+), 8 deletions(-)
---
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..5ca1f28
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter(spelling-error .* (gobject|gtk|libffi|libsoup|webkit));
diff --git a/perl-Glib-Object-Introspection.spec
b/perl-Glib-Object-Introspection.spec
index e05a036..f5a5b29 100644
--- a/perl-Glib-Object-Introspection.spec
+++ b/perl-Glib-Object-Introspection.spec
@@ -1,33 +1,42 @@
Name: perl-Glib-Object-Introspection
-Version:0.016
+Version:0.022
Release:1%{?dist}
Summary:Dynamically create Perl language bindings
License:LGPLv2+
Group: Development/Libraries
URL:http://search.cpan.org/dist/Glib-Object-Introspection/
Source0:
http://www.cpan.org/modules/by-module/Glib/Glib-Object-Introspection-%{version}.tar.gz
-BuildRequires: gobject-introspection-devel
+BuildRequires: perl(Config)
BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::Depends) = 0.3
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::PkgConfig) = 1
BuildRequires: perl(File::Spec)
BuildRequires: perl(Glib::MakeHelper)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: pkgconfig(gobject-introspection-1.0) = 0.10.0
+BuildRequires: pkgconfig(gmodule-2.0) = 2.0.0
+BuildRequires: pkgconfig(libffi) = 3.0.0
# Run-time
BuildRequires: perl(Carp)
-BuildRequires: perl(ExtUtils::Depends) = 0.3
-BuildRequires: perl(ExtUtils::PkgConfig) = 1
BuildRequires: perl(Glib) = 1.280
+BuildRequires: perl(overload)
BuildRequires: perl(XSLoader)
# Tests
+BuildRequires: perl(Glib::Object::Subclass)
+BuildRequires: perl(POSIX)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
+BuildRequires: perl(utf8)
# Optional tests
-BuildRequires: cairo-gobject-devel
+BuildRequires: pkgconfig(cairo-gobject)
+BuildRequires: pkgconfig(gio-2.0)
BuildRequires: perl(Cairo::GObject)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(ExtUtils::Depends) = 0.3
-Requires: perl(ExtUtils::PkgConfig) = 1
Requires: perl(Glib) = 1.280
+Requires: perl(overload)
%{?perl_default_filter}
# Remove under-specified dependencies
@@ -68,6 +77,9 @@ LANG=en_US.UTF8 make test
%{_mandir}/man3/*
%changelog
+* Wed Apr 02 2014 Petr Pisar ppi...@redhat.com - 0.022-1
+- 0.022 bump
+
* Tue Oct 1 2013 Daniel P. Berrange berra...@redhat.com - 0.016-1
- Update to 0.016 release (rhbz #1013534)
diff --git a/sources b/sources
index 8a141b5..b06de5b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2d6b3a693b7109d184688468f079b28e Glib-Object-Introspection-0.016.tar.gz
+e3e5d150658b11f8313bc97a4986a0bf Glib-Object-Introspection-0.022.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-SSL-1.975.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: aff1da9c2bda589024c9147c6a3ae33a IO-Socket-SSL-1.975.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Update to 1.975
commit 70cd5c8b43aaec192539c9486c96e424459654fe
Author: Paul Howarth p...@city-fan.org
Date: Wed Apr 2 12:02:56 2014 +0100
Update to 1.975
- New upstream release 1.975
- BEHAVIOR CHANGE: work around TEA misfeature on OS X built-in openssl,
e.g.
guarantee that only the explicitly-given CA or the openssl default CA
will
be used; this means that certificates inside the OS X keyring will no
longer be used, because there is no way to control the use by openssl
(e.g. certificate pinning etc.)
- Make external tests run by default to make sure default CA works on all
platforms; it skips automatically on network problems like timeouts or
SSL
interception, and can also use http(s)_proxy environment variables
perl-IO-Socket-SSL.spec | 13 -
sources |2 +-
2 files changed, 13 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index a1bc6a5..50d7037 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.974
+Version: 1.975
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -72,6 +72,17 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
%changelog
+* Wed Apr 2 2014 Paul Howarth p...@city-fan.org - 1.975-1
+- Update to 1.975
+ - BEHAVIOR CHANGE: work around TEA misfeature on OS X built-in openssl, e.g.
+guarantee that only the explicitly-given CA or the openssl default CA will
+be used; this means that certificates inside the OS X keyring will no
+longer be used, because there is no way to control the use by openssl
+(e.g. certificate pinning etc.)
+ - Make external tests run by default to make sure default CA works on all
+platforms; it skips automatically on network problems like timeouts or SSL
+interception, and can also use http(s)_proxy environment variables
+
* Wed Apr 2 2014 Paul Howarth p...@city-fan.org - 1.974-1
- Update to 1.974
- New function peer_certificates to get the whole certificate chain; needs
diff --git a/sources b/sources
index 06b4123..d6c4604 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1452f0c298b2278f7a0a95550c0228ce IO-Socket-SSL-1.974.tar.gz
+aff1da9c2bda589024c9147c6a3ae33a IO-Socket-SSL-1.975.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.975-1.fc21
The lightweight tag 'perl-IO-Socket-SSL-1.975-1.fc21' was created pointing to: 70cd5c8... Update to 1.975 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1040414] perl-Glib-Object-Introspection-0.022 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1040414 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Glib-Object-Introspect ||ion-0.022-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-04-02 08:26:24 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ocw6ulsXlFa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-GnuPG-Interface
perl-GnuPG-Interface has broken dependencies in the rawhide tree: On x86_64: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) On i386: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) On armhfp: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
