EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 574 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 89 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 49 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6 31 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12025/seamonkey-2.22-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12064/drupal7-context-3.1-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12040/python-djblets-0.7.23-1.el6,ReviewBoard-1.7.18-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12102/moodle-2.4.7-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing cp2k-2.4-1.20130620svn12994.el6 latex2rtf-2.3.4-1.el6 php-EasyRdf-0.7.2-5.el6 php-Metadata-1.5.0-1.el6 php-PHPParser-0.9.4-1.el6 php-Pimple-1.1.0-3.el6 php-guzzle-Guzzle-3.7.4-2.el6 php-jsonlint-1.1.2-1.el6 php-scssphp-0.0.8-1.el6 php-twig-Twig-1.14.2-1.el6 pidgin-sipe-1.17.1-1.el6 python-fsmonitor-0.1-3.el6 python-py-1.4.18-1.el6 tubo-5.0.12-1.el6 Details about builds: cp2k-2.4-1.20130620svn12994.el6 (FEDORA-EPEL-2013-12130) A molecular dynamics engine capable of classical and Car-Parrinello simulations Update Information: Numerous bugfixes and enhancements. Upstream changelog: http://www.cp2k.org/version_history ChangeLog: * Fri Nov 15 2013 Dominik Mierzejewski r...@greysector.net - 2.4-1.20130620svn12994 - update to latest 2.4 branch snapshot - drop mpich2 subpackage on ppc(64) and s390(x) - use xz to compress SVN snapshot tarball - build psmp variants (MPI+OpenMP) - move ssmp build to main package and drop smp subpackage - save the output of tools/get_arch_code and re-use it - use (and patch) upstream-provided configs for x86_64 ssmp and popt builds - no need to force FC=gfortran anymore - link with libf77blas for MPI builds to avoid undefined reference to symbol 'dgemm_' - fix crashes in fftw on i686 (patch by Michael Banck) - add requires for respective blacs and scalapack versions - add -ffree-line-length-none to Fortran flags - add a patch to echo the name of reach test (from Debian package) - build with libxc - pass special CFLAGS to support libint's higher values of angular momentum - added snapshot creator script - define common description macro (Thomas Spura) - also build with openmpi/mpich2 (Thomas Spura) - new url (Thomas Spura) latex2rtf-2.3.4-1.el6 (FEDORA-EPEL-2013-12125) LaTeX to RTF converter that handles equations, figures, and cross-references Update Information: Update to 2.3.4, introducing tikz support. ChangeLog: * Sun Nov 17 2013 Susi Lehtola jussileht...@fedoraproject.org - 2.3.4-1 - Update to 2.3.4. * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.3.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #1030883 - latex2rtf-2.3.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=1030883 php-EasyRdf-0.7.2-5.el6 (FEDORA-EPEL-2013-12128) A PHP library designed to make it easy to consume and produce RDF Update Information: Removed test sub-package ChangeLog: * Fri Nov 15 2013 Shawn Iwinski shawn.iwin...@gmail.com 0.7.2-5 - Removed test sub-package - php-common = php(language) * Sun Aug 4 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.7.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #994034 - php-EasyRdf possibly affected by F-20 unversioned docdir change https://bugzilla.redhat.com/show_bug.cgi?id=994034
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 574 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 89 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5 65 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 29 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12067/drupal7-context-3.1-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing latex2rtf-2.3.4-1.el5 pidgin-sipe-1.17.1-1.el5 Details about builds: latex2rtf-2.3.4-1.el5 (FEDORA-EPEL-2013-12134) LaTeX to RTF converter that handles equations, figures, and cross-references Update Information: Update to 2.3.4, introducing tikz support. ChangeLog: * Sun Nov 17 2013 Susi Lehtola jussileht...@fedoraproject.org - 2.3.4-1 - Update to 2.3.4. * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.3.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #1030883 - latex2rtf-2.3.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=1030883 pidgin-sipe-1.17.1-1.el5 (FEDORA-EPEL-2013-12123) Pidgin protocol plugin to connect to MS Office Communicator Update Information: New upstream release: * added Lync 2013 support: buddy list modification, buddy photo, group chat * added support for group chat history * fixes group chat: duplicate messages users, HTML tags in text * fixes EWS autodiscover for Office 365 * fixes typing notifications * fixes that passwords were not entity encoded * accept alternatives for webticket timestamp/keydata ChangeLog: * Sat Nov 16 2013 Stefan Becker chemob...@gmail.com - 1.17.1-1 - update to 1.17.1: - fixes typing notifications - fixes that passwords were not entity encoded - accept alternatives for webticket timestamp/keydata * Sat Sep 21 2013 Stefan Becker chemob...@gmail.com - 1.17.0-1 - update to 1.17.0: - added Lync 2013 support: buddy list modification, buddy photo, group chat - added support for group chat history - fixes group chat: duplicate messages users, HTML tags in text - fixes EWS autodiscover for Office 365 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: OSGi 5 Implementation
On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Manuel Alexander Kurtakov Red Hat Eclipse team -- 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: OSGi 5 Implementation
- Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 10:50:33 AM Subject: Re: OSGi 5 Implementation On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Are you saying that Netbinox builds with equinox downloaded from eclipse.org but not with the one from our rpms? Alexander Kurtakov Red Hat Eclipse team Manuel Alexander Kurtakov Red Hat Eclipse team -- 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: unaccessability
While this has been amusing, a lot of useful detail may be lost in the furor. There are some good philosophy questions about what GUI's should support for replacing command line tools (the gnome installation tool), hooks for getting command line tools to pop up as GUI icons and behavior correctly, etc. But I'd like to strongly suggest stepping back and thinking about what should the GUI do, and how. Rather than merely pouring feature and workaround and tweak after tweak into the GUI's, go take a good look at Eric Raymond's essay on The Luxury of Ignorance and ask is this tool doing what a casual user reasonably expects it to do? System management tools such as package managers, benefit tremendously from clarity. So a tool that has install updates, but only lists the downloaded on ones, would benefit from being clear and saying install downloaded updates. The practice of wrapping command line tools (such as yum) in GUI's can be done well, but it often breaks down because the new GUI tries to wrap new features into the workflow without telling anyone, and creates a workflow that is inconsistent with or can't even be replicated from the command line tools without hand-editing config files. And the command line tools, in turn, break the GUI managed settings. It can get nasty. (Don't get me started on NetworkManager!) So step back, and let's think how can we make this work for someone who hasn't seen it before and doesn't know how to hand-edit config files? On Sun, Nov 17, 2013 at 1:33 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-11-17 at 05:33 +0100, Olav Vitters wrote: On Sat, Nov 16, 2013 at 12:50:11PM -0800, Adam Williamson wrote: Oh, hey, look. That place is rapidly becoming the 'crap, we don't know where to put this' dumping ground for GNOME 3, isn't it? It has been there since 3.0 AFAIK, so rapidly becoming is incorrect. It keeps growing more bits, though. Anyway, calling design decisions crap and dumping ground is kind of needlessly emotional. No emotion involved, I'm afraid. -- 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 -- 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: OSGi 5 Implementation
On Sun, 17 Nov 2013 04:39:06 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 10:50:33 AM Subject: Re: OSGi 5 Implementation On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Are you saying that Netbinox builds with equinox downloaded from eclipse.org but not with the one from our rpms? With version, i meant release version of Equinox, not the eclipse.com version vs. Packaged version of Fedora. The problem is, that Netbinox is intended to be built with Equinox 3.8.0, but Fedora ships Equinox 3.9.0, which causes complication errors. One problem is for example, that the constructor of org.eclipse.osgi.baseadaptor.bundlefile.DirBundleFile takes different arguments in Equinox 3.8.0 and 3.9.0. Manuel Alexander Kurtakov Red Hat Eclipse team Manuel Alexander Kurtakov Red Hat Eclipse team -- 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: OSGi 5 Implementation
- Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 2:40:25 PM Subject: Re: OSGi 5 Implementation On Sun, 17 Nov 2013 04:39:06 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 10:50:33 AM Subject: Re: OSGi 5 Implementation On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Are you saying that Netbinox builds with equinox downloaded from eclipse.org but not with the one from our rpms? With version, i meant release version of Equinox, not the eclipse.com version vs. Packaged version of Fedora. The problem is, that Netbinox is intended to be built with Equinox 3.8.0, but Fedora ships Equinox 3.9.0, which causes complication errors. This is something that must be handled at Netbinox site, Fedora project aims at shipping latest versions of software so Netbinox need to be fixed to compile/work with Equinox 3.9. Not to mention that Equinox 3.8 is no longer supported upstream so shipping it makes no sense. Alexander Kurtakov Red Hat Eclipse team One problem is for example, that the constructor of org.eclipse.osgi.baseadaptor.bundlefile.DirBundleFile takes different arguments in Equinox 3.8.0 and 3.9.0. Manuel Alexander Kurtakov Red Hat Eclipse team Manuel Alexander Kurtakov Red Hat Eclipse team -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131117 changes
Compose started at Sun Nov 17 09:15:02 UTC 2013 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-5.fc20.noarch requires python-qpid-qmf = 0:0.9.1073306 [fence-agents] fence-agents-common-4.0.4-3.fc20.armv7hl requires pexpect [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [ipython] python-ipython-console-0.13.2-2.fc20.noarch requires pexpect python3-ipython-console-0.13.2-2.fc20.noarch requires python3-pexpect [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openlmi-providers] openlmi-0.4.0-1.fc20.noarch requires openlmi-power [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [qpid-cpp] qpid-cpp-server-ha-0.24-6.fc20.armv7hl requires qpid-qmf(armv7hl-32) qpid-tools-0.24-6.fc20.noarch requires python-qpid-qmf [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [scilab] scilab-doc-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20 scilab-tests-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20 [sigul] sigul-0.100-3.fc20.noarch requires pexpect [spacewalk-admin] spacewalk-admin-2.0.1-2.fc20.noarch requires spacewalk-base spacewalk-admin-2.0.1-2.fc20.noarch requires perl(RHN::SatelliteCert)
Re: unaccessability
On 17 November 2013 04:33, Olav Vitters o...@vitters.nl wrote: On Sat, Nov 16, 2013 at 12:50:11PM -0800, Adam Williamson wrote: Oh, hey, look. That place is rapidly becoming the 'crap, we don't know where to put this' dumping ground for GNOME 3, isn't it? It has been there since 3.0 AFAIK, so rapidly becoming is incorrect. Anyway, calling design decisions crap and dumping ground is kind of needlessly emotional. Is this intentional misreading? Since 'crap' in the above is used as an expression of surprise. Of course it's fairly easy to paint people who are frustrated as emotional and irrational so their opinion can be ignored, but it's not very inclusive. -- 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: OSGi 5 Implementation
On Sun, 17 Nov 2013 07:58:48 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 2:40:25 PM Subject: Re: OSGi 5 Implementation On Sun, 17 Nov 2013 04:39:06 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 10:50:33 AM Subject: Re: OSGi 5 Implementation On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Are you saying that Netbinox builds with equinox downloaded from eclipse.org but not with the one from our rpms? With version, i meant release version of Equinox, not the eclipse.com version vs. Packaged version of Fedora. The problem is, that Netbinox is intended to be built with Equinox 3.8.0, but Fedora ships Equinox 3.9.0, which causes complication errors. This is something that must be handled at Netbinox site, Fedora project aims at shipping latest versions of software so Netbinox need to be fixed to compile/work with Equinox 3.9. Not to mention that Equinox 3.8 is no longer supported upstream so shipping it makes no sense. So in that situation the way a packager handles that situation is to tell upstream (NetBeans in that case) to fix the incompatibility? I just chose the way to fix it myself, since the previous maintainer of the netbeans packages also did it that way and I just adopted the spec files. The point with NetBeans is, that it does not only concern Equinox, but also some other libraries, which are shipped by Fedora in newer versions than NetBeans requires them. Manuel Alexander Kurtakov Red Hat Eclipse team One problem is for example, that the constructor of org.eclipse.osgi.baseadaptor.bundlefile.DirBundleFile takes different arguments in Equinox 3.8.0 and 3.9.0. Manuel Alexander Kurtakov Red Hat Eclipse team Manuel Alexander Kurtakov Red Hat Eclipse team -- 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 -- 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: How to handle non-free parts of a free software project
On Sat, 16 Nov 2013 00:25:17 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Manuel Faux wrote: I little bit more feedback would be welcome. You don't agree to give the option to manually download the file at all, or don't you agree with NOT packing the file to /usr/lib/jvm/...? By not giving the option to manually link to the file we will loose the functionality to create Java Web Start war files at all. Also other packages require the user to get some non-free files for some specific non-crucial functionality. Can't you package the offending JAR in RPM Fusion Nonfree? Then it can install to system directories such as /usr/lib/jvm without causing trouble. Of course, the ideal solution would be to have a Free replacement or to get the original relicensed, but failing that, that's what RPM Fusion Nonfree is for. Kevin Kofler Currently Dalibor Topic from Oracle is helping us to maybe change the license of that file (see conversation on legal list), since it might be the case that the file was tagged with a too restrictive license, anyway. In meanwhile I added a README.Fedora and explained that the non-free file is expected in ~/.netbeans/, in case the user wants to make use of that functionality. Manuel -- 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: unaccessability
On 17.11.2013 14:14, Nico Kadel-Garcia wrote: While this has been amusing, a lot of useful detail may be lost in the furor. There are some good philosophy questions about what GUI's should support for replacing command line tools (the gnome ... So step back, and let's think how can we make this work for someone who hasn't seen it before and doesn't know how to hand-edit config files? My answer would be: With an lightweight web consoles. Regular desktop users usually are scared by blank terminal window - They do not know what to type, also they are afraid that if they type something wrong and broke something then the severe sysadmin or the tech-y guy who was installed/supporting their system will be very angry :-) But they are curious to try new things, especially when the new thing could bring them something cool (like e.g. simple loop to convert their incoming media). The idea about the browser app, helping the users with command lines construction is not mine, I saw this in Cloud9 IDE (advanced browser based IDE, BTW, currently hosting user envs on OpenShift). They have command line at the bottom of IDE space, which exposes many of the IDE operations, offering code completion (visual equivalent of bash completion) for args filling + nice HTML (why not SVG) table results for (some of) the commands. If this exposure of the command line tools looks acceptable for more wide range of users, we could: * choose standard for backend/webapp communication (e.g. NullMQ/MsgPack with these and these messages) * choose standard args grammar, for describing valid command lines * choose standard results grammar, for parsing the utility output streams * make a reference metadata for tool or two, which in addition to the grammars, have references to the relevant man page sections for the subcommands and thier args. Given the e.g. above spec, the authors of current web based terminal emulators would be able to extend their projects, becoming funny and shiny command line composing (and why not simple snippets composing) tools and eventually package for Fedora. On the other side we can offer to upstreams (or maintainers, where willing) to add this pure metadata, which should be positive for them in two ways: * possibly their tool becomes easy to use and accessible for wider audience. * most of the projects, will benefit of any pure metadata definition of their in/out grammars and documentation cross-references, because they do not have any. I think, the Fedora as integrator of the half of the FLOSS software in the planet, with half of the Linuxes as downstreams is a good place for drafting such kind of standards. After the standards acceptance, the remaining part is easy - we could reuse the comps, tags, requires/provides in the packages, etc, to generate the Big Fat Fedora tools catalog (the pallete of the web console) - When the user wants to try a tool she clicks, we yum installing the thing and system is ready to be blown by this curious user :-) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20131117 changes
Compose started at Sun Nov 17 08:15:03 UTC 2013 Broken deps for i386 -- [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [R-RScaLAPACK] R-RScaLAPACK-0.6.1-13.fc20.i686 requires libatlas.so.3 [blueman] blueman-1.23-7.fc20.i686 requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.i686 requires gvfs-obexftp [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [digikam] digikam-3.5.0-2.fc21.i686 requires libkdcraw.so.22 digikam-libs-3.5.0-2.fc21.i686 requires libkdcraw.so.22 kipi-plugins-3.5.0-2.fc21.i686 requires libkdcraw.so.22 kipi-plugins-libs-3.5.0-2.fc21.i686 requires libkdcraw.so.22 libkgeomap-3.5.0-2.fc21.i686 requires libmarblewidget.so.16 [dragonegg] dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [fatrat] 1:fatrat-1.2.0-0.14.beta2.fc20.i686 requires liblog4cpp.so.4 [firstaidkit] firstaidkit-plugin-openscap-0.3.2-7.fc20.noarch requires openscap-content = 0:0.7.2 [freefem++] freefem++-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libatlas.so.3 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-15.fc21.i686 requires gcc = 0:4.8.2-1.fc21 gcc-python2-plugin-0.12-15.fc21.i686 requires gcc = 0:4.8.2-1.fc21 gcc-python3-debug-plugin-0.12-15.fc21.i686 requires gcc = 0:4.8.2-1.fc21 gcc-python3-plugin-0.12-15.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [gnome-shell-extensions] gnome-shell-extension-common-3.11.2-1.fc21.noarch requires gnome-shell = 0:3.11.2 [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [kdeartwork] kdeartwork-4.11.90-1.fc21.i686 requires kde-workspace = 0:4.11.90 kdeartwork-kxs-4.11.90-1.fc21.i686 requires kde-workspace = 0:4.11.90 [kdesdk] kdesdk-4.11.90-1.fc21.noarch requires kompare = 0:4.11.90 kdesdk-devel-4.11.90-1.fc21.noarch requires kompare-devel = 0:4.11.90 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kxstitch] kxstitch-0.8.4.1-16.fc20.i686 requires libMagick++-6.Q16.so.1 [kyua-cli] kyua-cli-0.5-3.fc19.i686 requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.i686 requires liblutok.so.0 [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [maven-doxia] maven-doxia-module-itext-1.4-4.fc21.noarch requires mvn(com.lowagie:itext:2.1.7) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires
Re: Self Introduction
Great! I appreciate any and all input. Regards, Jeff On 11/16/2013 08:06 PM, Christopher Meng wrote: This package is in my plan, I will help do an *informal* review. -- Jeff Backus jeff.bac...@gmail.com http://github.com/jsbackus -- 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: OSGi 5 Implementation
- Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 3:33:40 PM Subject: Re: OSGi 5 Implementation On Sun, 17 Nov 2013 07:58:48 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 2:40:25 PM Subject: Re: OSGi 5 Implementation On Sun, 17 Nov 2013 04:39:06 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Manuel Faux manuel.f...@conf.at To: devel@lists.fedoraproject.org Sent: Sunday, November 17, 2013 10:50:33 AM Subject: Re: OSGi 5 Implementation On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov akurt...@redhat.com wrote: I didn't see that Equinox satisfies the OSGi 5 part, since I didn't use this package anymore, as soon I recognized that NetBeans does not build with it. Is this still true? I know that jtulach(one of the netbeans guys) has his own equinox(like?) framework called Netbinox for usage in netbeans so you might want to get in contact with him for details. I haven't followed Netbeans in years but if you point to concrete problem I'll take a look. The problem was not with Equinox per se, but with the version shipped with Fedora. I needed to write some patches to be able to build NetBeans against the newest version of Equinox. The component which needs the patch is Netbinox. Are you saying that Netbinox builds with equinox downloaded from eclipse.org but not with the one from our rpms? With version, i meant release version of Equinox, not the eclipse.com version vs. Packaged version of Fedora. The problem is, that Netbinox is intended to be built with Equinox 3.8.0, but Fedora ships Equinox 3.9.0, which causes complication errors. This is something that must be handled at Netbinox site, Fedora project aims at shipping latest versions of software so Netbinox need to be fixed to compile/work with Equinox 3.9. Not to mention that Equinox 3.8 is no longer supported upstream so shipping it makes no sense. So in that situation the way a packager handles that situation is to tell upstream (NetBeans in that case) to fix the incompatibility? I just chose the way to fix it myself, since the previous maintainer of the netbeans packages also did it that way and I just adopted the spec files. Both, the mission of Fedora is to advance the whole ecosystem, as such it's hard for many upstreams to keep pace that's why Fedora maintainers fix incompatibilities with newer version and sends the patch upstream for inclusion in order to ease packaging in the future. See https://fedoraproject.org/wiki/Staying_close_to_upstream_projects which contains this information in detailed form. Regards, Alexander Kurtakov Red Hat Eclipse team The point with NetBeans is, that it does not only concern Equinox, but also some other libraries, which are shipped by Fedora in newer versions than NetBeans requires them. Manuel Alexander Kurtakov Red Hat Eclipse team One problem is for example, that the constructor of org.eclipse.osgi.baseadaptor.bundlefile.DirBundleFile takes different arguments in Equinox 3.8.0 and 3.9.0. Manuel Alexander Kurtakov Red Hat Eclipse team Manuel Alexander Kurtakov Red Hat Eclipse team -- 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 -- 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
File conflict when upgrading package
Hi,
There was an incorrect desktop-file-install call in a package I
maintain, i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from package
xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying
Conflicts: xflr5 5.09.05-5, but it did not help.
Thanks,
Sandro
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
glew 1.10 in rawhide
Hi, I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies but I can if anyone wants, but I thought I'd give a headsup to the maintainers so they can rebuild their packages. Dave. -- 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: File conflict when upgrading package
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain, i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying
Conflicts: xflr5 5.09.05-5, but it did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
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: File conflict when upgrading package
On 17.11.2013 22:00, Reindl Harald wrote:
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain, i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying Conflicts:
xflr5 5.09.05-5, but it did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
I didn't do it in the package in the repos. It was just something I
tried locally when trying to find a way to make the update work, since I
ran out of ideas how to solve it otherwise.
--
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: File conflict when upgrading package
Am 17.11.2013 22:02, schrieb Sandro Mani:
On 17.11.2013 22:00, Reindl Harald wrote:
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain,
i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying
Conflicts: xflr5 5.09.05-5, but it did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
I didn't do it in the package in the repos. It was just something I tried
locally when trying to find a way to make
the update work, since I ran out of ideas how to solve it otherwise
please describe the *real* problem without hacks
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: File conflict when upgrading package
On 17.11.2013 22:07, Reindl Harald wrote:
Am 17.11.2013 22:02, schrieb Sandro Mani:
On 17.11.2013 22:00, Reindl Harald wrote:
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain, i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying Conflicts:
xflr5 5.09.05-5, but it did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
I didn't do it in the package in the repos. It was just something I tried
locally when trying to find a way to make
the update work, since I ran out of ideas how to solve it otherwise
please describe the *real* problem without hacks
xflr5-6.09.05-4.fc21.x86_64 had an incorrect desktop-file-install call in the
spec file, namely
desktop-file-install --dir=%{buildroot}%{_datadir}/applications/%{name}.desktop
%{SOURCE1}
which caused the desktop file to get installed to
/usr/share/applications/xflr5.desktop/xflr5.desktop
In xflr5-6.09.05-5.fc21.x86_64, I fixed the desktop-file-install call to
desktop-file-install --dir=%{buildroot}%{_datadir}/applications/ %{SOURCE1}
so that the desktop file is correctly installed to
/usr/share/applications/xflr5.desktop
Upgrading from xflr5-6.09.05-4.fc21.x86_64 to xflr5-6.09.05-5.fc21.x86_64
however fails with
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
--
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: File conflict when upgrading package
Am 17.11.2013 22:12, schrieb Sandro Mani:
On 17.11.2013 22:07, Reindl Harald wrote:
Am 17.11.2013 22:02, schrieb Sandro Mani:
On 17.11.2013 22:00, Reindl Harald wrote:
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain,
i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file
from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying
Conflicts: xflr5 5.09.05-5, but it
did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
I didn't do it in the package in the repos. It was just something I tried
locally when trying to find a way to make
the update work, since I ran out of ideas how to solve it otherwise
please describe the *real* problem without hacks
xflr5-6.09.05-4.fc21.x86_64 had an incorrect desktop-file-install call in the
spec file, namely
desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the desktop file to get installed to
/usr/share/applications/xflr5.desktop/xflr5.desktop
In xflr5-6.09.05-5.fc21.x86_64, I fixed the desktop-file-install call to
desktop-file-install --dir=%{buildroot}%{_datadir}/applications/ %{SOURCE1}
so that the desktop file is correctly installed to
/usr/share/applications/xflr5.desktop
Upgrading from xflr5-6.09.05-4.fc21.x86_64 to xflr5-6.09.05-5.fc21.x86_64
however fails with
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
can you please provide both SPEC files
i still do not get why there can be any conflict
this is not a common behavior in changed %files section for whatever reason
no longer listed files are supposed to be removed without any noise
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: File conflict when upgrading package
On 17.11.2013 22:18, Reindl Harald wrote:
Am 17.11.2013 22:12, schrieb Sandro Mani:
On 17.11.2013 22:07, Reindl Harald wrote:
Am 17.11.2013 22:02, schrieb Sandro Mani:
On 17.11.2013 22:00, Reindl Harald wrote:
Am 17.11.2013 21:47, schrieb Sandro Mani:
There was an incorrect desktop-file-install call in a package I maintain, i.e.
|desktop-file-install
--dir=%{buildroot}%{_datadir}/applications/%{name}.desktop %{SOURCE1}
which caused the .desktop file to get installed to
/usr/share/applications/%{name}.desktop/%{name}.desktop
I fixed the syntax (by removing the %{name}.desktop part), but now when
upgrading the package I get
|
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file
from
package xflr5-6.09.05-4.fc21.x86_64
How can I make the update work smoothly? I tried explicitly specifying Conflicts:
xflr5 5.09.05-5, but it
did not
help.
xflr5-6.09.05-4.fc21.x86_64
xflr5-6.09.05-5.fc21.x86_64
why in the world do you specify any conflicts for a ordinary update?
I didn't do it in the package in the repos. It was just something I tried
locally when trying to find a way to make
the update work, since I ran out of ideas how to solve it otherwise
please describe the *real* problem without hacks
xflr5-6.09.05-4.fc21.x86_64 had an incorrect desktop-file-install call in the
spec file, namely
desktop-file-install --dir=%{buildroot}%{_datadir}/applications/%{name}.desktop
%{SOURCE1}
which caused the desktop file to get installed to
/usr/share/applications/xflr5.desktop/xflr5.desktop
In xflr5-6.09.05-5.fc21.x86_64, I fixed the desktop-file-install call to
desktop-file-install --dir=%{buildroot}%{_datadir}/applications/ %{SOURCE1}
so that the desktop file is correctly installed to
/usr/share/applications/xflr5.desktop
Upgrading from xflr5-6.09.05-4.fc21.x86_64 to xflr5-6.09.05-5.fc21.x86_64
however fails with
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
can you please provide both SPEC files
i still do not get why there can be any conflict
this is not a common behavior in changed %files section for whatever reason
no longer listed files are supposed to be removed without any noise
-4 spec file:
http://pkgs.fedoraproject.org/cgit/xflr5.git/tree/xflr5.spec?id=510af4da0c081c0b70ec03a35d8878053e5e87d0
-5 spec file: http://pkgs.fedoraproject.org/cgit/xflr5.git/tree/xflr5.spec
I guess this could be an rpm bug, specifically when a directory is
replaced with a file with the same name when the package is upgraded?
--
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: glew 1.10 in rawhide
If you don't want to do mass rebuild, maybe you should send this email directly to the owners of glew dependent packages, so they don't miss it. Especially when the traffic on devel is so high. Ne 17. listopad 2013, 21:48:31 CET, David Airlie napsal: Hi, I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies but I can if anyone wants, but I thought I'd give a headsup to the maintainers so they can rebuild their packages. Dave. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- 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: unaccessability
On Sat, Nov 16, 2013 at 10:33:09PM -0800, Adam Williamson wrote: On Sun, 2013-11-17 at 05:33 +0100, Olav Vitters wrote: On Sat, Nov 16, 2013 at 12:50:11PM -0800, Adam Williamson wrote: Oh, hey, look. That place is rapidly becoming the 'crap, we don't know where to put this' dumping ground for GNOME 3, isn't it? It has been there since 3.0 AFAIK, so rapidly becoming is incorrect. It keeps growing more bits, though. My memory is terrible, I thought that part is pretty much unchanged. It is not the perfect place, that was mentioned by a designer. But better to have it somewhere than nowhere. You can search for preferred and have this show up. Anyway, calling design decisions crap and dumping ground is kind of needlessly emotional. No emotion involved, I'm afraid. Ah ok, I should assume better -- Regards, Olav -- 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: File conflict when upgrading package
sön 2013-11-17 klockan 22:12 +0100 skrev Sandro Mani:
Upgrading from xflr5-6.09.05-4.fc21.x86_64 to xflr5-6.09.05-5.fc21.x86_64
however fails with
Transaction check error:
file /usr/share/applications/xflr5.desktop from install of
xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
package xflr5-6.09.05-4.fc21.x86_64
You are replacing a directory with an ordinary file. The requires a
%pretrans script. %pretrans scripts must be written in lua:
%pretrans -p lua
st = posix.stat(%{_datadir}/applications/%{name}.desktop)
if st and st.type == directory then
os.execute(rm -rf %{_datadir}/applications/%{name}.desktop)
end
Mattias
smime.p7s
Description: S/MIME cryptographic 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: glew 1.10 in rawhide
Actually I feel guilty now, I'll do a mass rebuild in rawhide. amanith-0.3-26.fc20.src.rpm avogadro-1.0.3-20.fc21.src.rpm blender-2.69-1.fc21.src.rpm bzflag-2.4.2-7.fc20.src.rpm calligra-2.7.4-2.fc21.src.rpm cegui06-0.6.2-15.fc20.src.rpm cegui-0.7.9-5.fc20.src.rpm compat-SFML16-1.6-3.fc21.src.rpm enblend-4.1.2-1.fc21.src.rpm FlightGear-Atlas-0.4.9-0.14.cvs20130922.fc21.src.rpm freewrl-1.22.13.1-9.fc20.src.rpm gambas3-3.5.1-1.fc21.src.rpm gimp-normalmap-1.2.3-6.fc21.src.rpm glew-1.9.0-4.fc20.src.rpm gource-0.40-1.fc21.src.rpm hugin-2013.0.0-1.fc21.src.rpm kalzium-4.11.90-1.fc21.src.rpm libprojectM-2.0.1-20.fc20.src.rpm linphone-3.6.1-2.fc20.src.rpm maniadrive-1.2-55.fc20.src.rpm megaglest-3.7.1-9.fc20.src.rpm mesa-demos-8.1.0-4.fc20.src.rpm meshlab-1.3.2-2.fc20.src.rpm opencsg-1.3.2-9.fc20.src.rpm OpenImageIO-1.2.3-1.fc21.src.rpm openmsx-0.9.1-1.fc20.src.rpm openscad-2013.06-5.fc21.src.rpm pymol-1.6.0-2.20130620svn4032.fc20.src.rpm quesoglc-0.7.2-8.fc20.src.rpm root-5.34.10-1.fc21.src.rpm rss-glx-0.9.1.p-17.fc20.src.rpm scorched3d-43.3d-9.fc21.src.rpm sdljava-0.9.1-23.fc20.src.rpm SFML-2.0-3.fc20.src.rpm spring-94.1-6.fc20.src.rpm supertux-0.3.3-13.fc20.src.rpm toped-0.9.81-5.svn2211.fc20.src.rpm vdrift-20120722-6.fc20.src.rpm warzone2100-3.1.0-3.fc20.src.rpm widelands-0-0.38.build17.fc20.src.rpm wxmacmolplt-7.4.4-2.fc20.src.rpm Dave. - Original Message - From: Miro Hrončok mhron...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, 18 November, 2013 7:54:03 AM Subject: Re: glew 1.10 in rawhide If you don't want to do mass rebuild, maybe you should send this email directly to the owners of glew dependent packages, so they don't miss it. Especially when the traffic on devel is so high. Ne 17. listopad 2013, 21:48:31 CET, David Airlie napsal: Hi, I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies but I can if anyone wants, but I thought I'd give a headsup to the maintainers so they can rebuild their packages. Dave. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- 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: glew 1.10 in rawhide
If you haven't done it yet, skip openscad and opencsg, I've rebuilt those once I read your email. Po 18. listopad 2013, 01:39:00 CET, David Airlie napsal: Actually I feel guilty now, I'll do a mass rebuild in rawhide. amanith-0.3-26.fc20.src.rpm avogadro-1.0.3-20.fc21.src.rpm blender-2.69-1.fc21.src.rpm bzflag-2.4.2-7.fc20.src.rpm calligra-2.7.4-2.fc21.src.rpm cegui06-0.6.2-15.fc20.src.rpm cegui-0.7.9-5.fc20.src.rpm compat-SFML16-1.6-3.fc21.src.rpm enblend-4.1.2-1.fc21.src.rpm FlightGear-Atlas-0.4.9-0.14.cvs20130922.fc21.src.rpm freewrl-1.22.13.1-9.fc20.src.rpm gambas3-3.5.1-1.fc21.src.rpm gimp-normalmap-1.2.3-6.fc21.src.rpm glew-1.9.0-4.fc20.src.rpm gource-0.40-1.fc21.src.rpm hugin-2013.0.0-1.fc21.src.rpm kalzium-4.11.90-1.fc21.src.rpm libprojectM-2.0.1-20.fc20.src.rpm linphone-3.6.1-2.fc20.src.rpm maniadrive-1.2-55.fc20.src.rpm megaglest-3.7.1-9.fc20.src.rpm mesa-demos-8.1.0-4.fc20.src.rpm meshlab-1.3.2-2.fc20.src.rpm opencsg-1.3.2-9.fc20.src.rpm OpenImageIO-1.2.3-1.fc21.src.rpm openmsx-0.9.1-1.fc20.src.rpm openscad-2013.06-5.fc21.src.rpm pymol-1.6.0-2.20130620svn4032.fc20.src.rpm quesoglc-0.7.2-8.fc20.src.rpm root-5.34.10-1.fc21.src.rpm rss-glx-0.9.1.p-17.fc20.src.rpm scorched3d-43.3d-9.fc21.src.rpm sdljava-0.9.1-23.fc20.src.rpm SFML-2.0-3.fc20.src.rpm spring-94.1-6.fc20.src.rpm supertux-0.3.3-13.fc20.src.rpm toped-0.9.81-5.svn2211.fc20.src.rpm vdrift-20120722-6.fc20.src.rpm warzone2100-3.1.0-3.fc20.src.rpm widelands-0-0.38.build17.fc20.src.rpm wxmacmolplt-7.4.4-2.fc20.src.rpm Dave. - Original Message - From: Miro Hrončok mhron...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, 18 November, 2013 7:54:03 AM Subject: Re: glew 1.10 in rawhide If you don't want to do mass rebuild, maybe you should send this email directly to the owners of glew dependent packages, so they don't miss it. Especially when the traffic on devel is so high. Ne 17. listopad 2013, 21:48:31 CET, David Airlie napsal: Hi, I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies but I can if anyone wants, but I thought I'd give a headsup to the maintainers so they can rebuild their packages. Dave. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- 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: glew 1.10 in rawhide
- Original Message - From: Miro Hrončok mhron...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, 18 November, 2013 10:54:38 AM Subject: Re: glew 1.10 in rawhide If you haven't done it yet, skip openscad and opencsg, I've rebuilt those once I read your email. Oops, I just pushed the changes to master, I'll skip rebuilding them though, Thanks, Dave. -- 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: unaccessability
On Sun, 2013-11-17 at 07:14 -0500, Nico Kadel-Garcia wrote: While this has been amusing, a lot of useful detail may be lost in the furor. There are some good philosophy questions about what GUI's should support for replacing command line tools (the gnome installation tool), hooks for getting command line tools to pop up as GUI icons and behavior correctly, etc. But I'd like to strongly suggest stepping back and thinking about what should the GUI do, and how. Rather than merely pouring feature and workaround and tweak after tweak into the GUI's, go take a good look at Eric Raymond's essay on The Luxury of Ignorance and ask is this tool doing what a casual user reasonably expects it to do? System management tools such as package managers, benefit tremendously from clarity. So a tool that has install updates, but only lists the downloaded on ones, would benefit from being clear and saying install downloaded updates. The practice of wrapping command line tools (such as yum) in GUI's can be done well, but it often breaks down because the new GUI tries to wrap new features into the workflow without telling anyone, and creates a workflow that is inconsistent with or can't even be replicated from the command line tools without hand-editing config files. And the command line tools, in turn, break the GUI managed settings. It can get nasty. (Don't get me started on NetworkManager!) So step back, and let's think how can we make this work for someone who hasn't seen it before and doesn't know how to hand-edit config files? Um. What? Apart from the rude top-posting, I don't see how any of the screed above relates to the discussion Olav and I were having at all. On Sun, Nov 17, 2013 at 1:33 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-11-17 at 05:33 +0100, Olav Vitters wrote: On Sat, Nov 16, 2013 at 12:50:11PM -0800, Adam Williamson wrote: Oh, hey, look. That place is rapidly becoming the 'crap, we don't know where to put this' dumping ground for GNOME 3, isn't it? It has been there since 3.0 AFAIK, so rapidly becoming is incorrect. It keeps growing more bits, though. Anyway, calling design decisions crap and dumping ground is kind of needlessly emotional. No emotion involved, I'm afraid. -- 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 -- 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
root rebuild failed after glew update
Hi owners, I tried to rebuild root after glew update, but it failed due to hadoop changes, Not sure if hadoop needs a build in rawhide for the current f20 build or something else. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
/usr/share/xsessions and window manager
Hi, Yesterday I reviewed a package notion, which is a new window manager(new to fedorian), it installs desktop file to /usr/share/xsession. Interesting, when I looking into more window manager in Fedora, I found that: openbox installs desktop file to /usr/share/xsessions pekwm installs desktop file to /usr/share/xsessions dwm installs desktop file to /usr/share/xsessions ratpoison installs desktop file to /usr/share/xsessions fvwm installs desktop file to /usr/share/xsessions sawfish installs desktop file to /usr/share/xsessions icwm installs desktop file to /usr/share/xsessions enlightenment installs desktop file to /usr/share/xsessions awesome installs desktop file to /usr/share/xsessions - fluxbox installs desktop file to /usr/share/applications xmonad installs desktop file to /usr/share/applications i3 installs desktop file to /usr/share/applications mutter installs desktop file to /usr/share/applications byobu installs desktop file to /usr/share/applications So I think that maybe these have been doing wrong for years? Should I file RFE for these? Thanks. -- Yours sincerely, Christopher Meng Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт. 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
Re: root rebuild failed after glew update
Il 18/11/2013 04:13, David Airlie ha scritto: Hi owners, I tried to rebuild root after glew update, but it failed due to hadoop changes, Not sure if hadoop needs a build in rawhide for the current f20 build or something else. Dave. hi Hadoop has nothing to do with glew ... can you please add the part, of the build.log, where fails to compile? regards gil attachment: puntogil.vcf-- 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: root rebuild failed after glew update
On Mon, Nov 18, 2013 at 11:26 AM, punto...@libero.it punto...@libero.it wrote: hi Hadoop has nothing to do with glew ... can you please add the part, of the build.log, where fails to compile? regards gil http://koji.fedoraproject.org/koji/buildinfo?buildID=479029: Checking for libhdfs ... no Checking for libjvm ... /usr/lib/jvm/java/jre/lib/amd64/server Explicitly required HDFS dependencies not fulfilled And libhdfs is from hadoop. -- 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: root rebuild failed after glew update
Il 18/11/2013 04:40, Christopher Meng ha scritto: On Mon, Nov 18, 2013 at 11:26 AM, punto...@libero.it punto...@libero.it wrote: hi Hadoop has nothing to do with glew ... can you please add the part, of the build.log, where fails to compile? regards gil http://koji.fedoraproject.org/koji/buildinfo?buildID=479029: Checking for libhdfs ... no Checking for libjvm ... /usr/lib/jvm/java/jre/lib/amd64/server Explicitly required HDFS dependencies not fulfilled And libhdfs is from hadoop. seem, you missing a buildrequires hdf5 or hdf (devel) http://pkgs.fedoraproject.org/cgit/hdf http://pkgs.fedoraproject.org/cgit/hdf5 attachment: puntogil.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-11-18 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-11-18 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! We're into Final validation already, so that's the main topic. I'm not aware of anything else specific that needs discussing, please suggest any missing topics! This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20131118 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 20 Final status 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: root rebuild failed after glew update
- Original Message - From: punto...@libero.it To: devel@lists.fedoraproject.org Sent: Monday, 18 November, 2013 1:54:06 PM Subject: Re: root rebuild failed after glew update Il 18/11/2013 04:40, Christopher Meng ha scritto: On Mon, Nov 18, 2013 at 11:26 AM, punto...@libero.it punto...@libero.it wrote: hi Hadoop has nothing to do with glew ... can you please add the part, of the build.log, where fails to compile? regards gil http://koji.fedoraproject.org/koji/buildinfo?buildID=479029: Checking for libhdfs ... no Checking for libjvm ... /usr/lib/jvm/java/jre/lib/amd64/server Explicitly required HDFS dependencies not fulfilled And libhdfs is from hadoop. seem, you missing a buildrequires hdf5 or hdf (devel) http://pkgs.fedoraproject.org/cgit/hdf http://pkgs.fedoraproject.org/cgit/hdf5 Did something get subpackaged, or requires rewritten since root built the last time it was tried. Though not my package, I'll let the package owner fix the depends if things have changed. Dave. -- 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: /usr/share/xsessions and window manager
On 11/18/2013 01:23 AM, Christopher Meng wrote: Hi, Yesterday I reviewed a package notion, which is a new window manager(new to fedorian), it installs desktop file to /usr/share/xsession. Interesting, when I looking into more window manager in Fedora, I found that: openbox installs desktop file to /usr/share/xsessions pekwm installs desktop file to /usr/share/xsessions dwm installs desktop file to /usr/share/xsessions ratpoison installs desktop file to /usr/share/xsessions fvwm installs desktop file to /usr/share/xsessions sawfish installs desktop file to /usr/share/xsessions icwm installs desktop file to /usr/share/xsessions enlightenment installs desktop file to /usr/share/xsessions awesome installs desktop file to /usr/share/xsessions - fluxbox installs desktop file to /usr/share/applications xmonad installs desktop file to /usr/share/applications i3 installs desktop file to /usr/share/applications mutter installs desktop file to /usr/share/applications byobu installs desktop file to /usr/share/applications So I think that maybe these have been doing wrong for years? Should I file RFE for these? Thanks. -- Yours sincerely, Christopher Meng Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт. http://cicku.me Hi Christopher, I fail to see what is the wrong location in your opinion. Do you think that a window manager should install its desktop file in /usr/share/xsessions or in /usr/share/applications? All the best, Germán. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- 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: root rebuild failed after glew update
mån 2013-11-18 klockan 04:26 +0100 skrev punto...@libero.it: Il 18/11/2013 04:13, David Airlie ha scritto: Hi owners, I tried to rebuild root after glew update, but it failed due to hadoop changes, Not sure if hadoop needs a build in rawhide for the current f20 build or something else. Dave. hi Hadoop has nothing to do with glew ... can you please add the part, of the build.log, where fails to compile? regards gil Hi! I have had an update of root in the pipeline for a few weeks. But it has been postponed waiting for fixes to the hadoop package. Fixing the root build for the current rawhide hadoop package would be possible, but those fixes would have to be thrown out once the next hadoop package update happens, so I currently prefer to wait for the hadoop update. Mattias maintainer of root package smime.p7s Description: S/MIME cryptographic 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
[perl-CGI-Application-Plugin-Session] Update to 1.04
commit 8066adff94c52c4fc26c2dfd5132d500f3b3d455
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 17 09:13:34 2013 +0100
Update to 1.04
.gitignore |1 +
...-hash-ordering-bug-in-what-I-think-is-CGI.patch | 32
perl-CGI-Application-Plugin-Session.spec | 24 ---
sources|2 +-
4 files changed, 15 insertions(+), 44 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b8d3e34..09d06c7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CGI-Application-Plugin-Session-1.03.tar.gz
+/CGI-Application-Plugin-Session-1.04.tar.gz
diff --git a/perl-CGI-Application-Plugin-Session.spec
b/perl-CGI-Application-Plugin-Session.spec
index 42d3dfc..7884e43 100644
--- a/perl-CGI-Application-Plugin-Session.spec
+++ b/perl-CGI-Application-Plugin-Session.spec
@@ -1,14 +1,11 @@
Name: perl-CGI-Application-Plugin-Session
-Version:1.03
-Release:14%{?dist}
+Version:1.04
+Release:1%{?dist}
Summary:Add CGI::Session support to CGI::Application
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/CGI-Application-Plugin-Session/
-Source0:
http://www.cpan.org/authors/id/C/CE/CEESHEK/CGI-Application-Plugin-Session-%{version}.tar.gz
-# Perl 5.18 comptability,
-# https://github.com/cees/cgi-application-plugin-session/pull/1
-Patch0:
CGI-Application-Plugin-Session-1.03-work-around-hash-ordering-bug-in-what-I-think-is-CGI.patch
+Source0:
http://www.cpan.org/authors/id/F/FR/FREW/CGI-Application-Plugin-Session-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(CGI)
@@ -30,20 +27,21 @@ accessible from anywhere in the application.
%prep
%setup -q -n CGI-Application-Plugin-Session-%{version}
-%patch0 -p1
%build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=%{buildroot}
+
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-./Build test
+make test
%files
%doc Changes README
@@ -51,6 +49,10 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Sun Nov 17 2013 Emmanuel Seyman emman...@seyman.fr - 1.04-1
+- Update to 1.04
+- Remove 5.18 compatibility patch (upstreamed)
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.03-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 1766254..ef60b8f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4fd76fb77afc8b1cfe721b4bc0cdafbf CGI-Application-Plugin-Session-1.03.tar.gz
+864ba11996043ac789973e41c0cb5882 CGI-Application-Plugin-Session-1.04.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 Log-Any-Adapter-Callback-0.07.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Log-Any-Adapter-Callback: e205460a9344207047d77350a238882e Log-Any-Adapter-Callback-0.07.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-Log-Any-Adapter-Callback] Update to 0.07
commit 8f829f907319d1cca1a27263e38c1c07a28bb821
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 17 09:18:59 2013 +0100
Update to 0.07
.gitignore |1 +
perl-Log-Any-Adapter-Callback.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ddb7c18..f464fcc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Log-Any-Adapter-Callback-0.06.tar.gz
+/Log-Any-Adapter-Callback-0.07.tar.gz
diff --git a/perl-Log-Any-Adapter-Callback.spec
b/perl-Log-Any-Adapter-Callback.spec
index c4f2bc0..0c130b0 100644
--- a/perl-Log-Any-Adapter-Callback.spec
+++ b/perl-Log-Any-Adapter-Callback.spec
@@ -1,6 +1,6 @@
Name: perl-Log-Any-Adapter-Callback
-Version:0.06
-Release:2%{?dist}
+Version:0.07
+Release:1%{?dist}
Summary:Send Log::Any logs to a subroutine
License:GPL+ or Artistic
@@ -45,6 +45,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Nov 17 2013 Emmanuel Seyman emman...@seyman.fr - 0.07-1
+- Update to 0.07
+
* Sun Oct 27 2013 Emmanuel Seyman emman...@seyman.fr - 0.06-2
- Take into acount package review (#1023619)
diff --git a/sources b/sources
index fa5b0ec..bbfa35b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-21dfebe671bf052bd75ee6ab1e740730 Log-Any-Adapter-Callback-0.06.tar.gz
+e205460a9344207047d77350a238882e Log-Any-Adapter-Callback-0.07.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 Mojolicious-4.57.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: 9ed3e4fbee5ad7fa2805d2d27cafe7d9 Mojolicious-4.57.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-Mojolicious] Update to 4.57
commit c7c9aba8527935c9e30c5a32ea308bdec61ca664
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 17 09:30:42 2013 +0100
Update to 4.57
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4971354..4be9a33 100644
--- a/.gitignore
+++ b/.gitignore
@@ -107,3 +107,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-4.50.tar.gz
/Mojolicious-4.53.tar.gz
/Mojolicious-4.56.tar.gz
+/Mojolicious-4.57.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 0f34775..b33d278 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:4.56
+Version:4.57
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Nov 17 2013 Emmanuel Seyman emman...@seyman.fr - 4.57-1
+- Update to 4.57
+
* Sun Nov 10 2013 Emmanuel Seyman emman...@seyman.fr - 4.56-1
- Update to 4.56
diff --git a/sources b/sources
index 384509f..fe86dac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1fd01e316e9bb64588c1a9a1268866ae Mojolicious-4.56.tar.gz
+9ed3e4fbee5ad7fa2805d2d27cafe7d9 Mojolicious-4.57.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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 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
File Software-License-0.103008.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Software-License: 14522397d2b34562b3a30be9e411267f Software-License-0.103008.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-Software-License] Update to 0.103008
commit 001cbe8fd092096aa3a5437cff3876bd0c38063b
Author: Paul Howarth p...@city-fan.org
Date: Sun Nov 17 12:37:50 2013 +
Update to 0.103008
- New upstream release 0.103008
- Faster!
- Add new_from_short_name to LicenseUtils for spdx.org-style short names
- Avoid double trailing dots in expanded licenses
- Fix some errors in (3-clause) BSD license text
- The 2-clause BSD (FreeBSD) license no longer incorrectly puts
FreeBSD
as the owner in the license full text
- Update patch for building with old Test::More versions
... Software-License-0.103008-old-Test::More.patch |2 +-
perl-Software-License.spec | 14 --
sources|2 +-
3 files changed, 14 insertions(+), 4 deletions(-)
---
diff --git a/Software-License-0.103007-old-Test::More.patch
b/Software-License-0.103008-old-Test::More.patch
similarity index 98%
rename from Software-License-0.103007-old-Test::More.patch
rename to Software-License-0.103008-old-Test::More.patch
index d528289..4592c9a 100644
--- a/Software-License-0.103007-old-Test::More.patch
+++ b/Software-License-0.103008-old-Test::More.patch
@@ -77,7 +77,7 @@
-note 'Checking Changes';
+diag 'Checking Changes';
my $changes_file = 'Changes';
- my $newver = '0.103007';
+ my $newver = '0.103008';
my $trial_token = '-TRIAL';
@@ -14,8 +14,6 @@ SKIP: {
ok(_get_changes($newver), $changes_file has content for $newver);
diff --git a/perl-Software-License.spec b/perl-Software-License.spec
index 6e32937..fa5002c 100644
--- a/perl-Software-License.spec
+++ b/perl-Software-License.spec
@@ -2,7 +2,7 @@
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-Software-License
-Version:0.103007
+Version:0.103008
Release:1%{?dist}
Summary:Package that provides templated software licenses
License:GPL+ or Artistic
@@ -11,7 +11,7 @@ URL:http://search.cpan.org/dist/Software-License/
# For unknown reasons this module URL is currently missing
#Source0:
http://www.cpan.org/modules/by-module/Software/Software-License-%{version}.tar.gz
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Software-License-%{version}.tar.gz
-Patch1: Software-License-0.103007-old-Test::More.patch
+Patch1: Software-License-0.103008-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: perl(Carp)
@@ -64,6 +64,16 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Software::LicenseUtils.3pm*
%changelog
+* Sun Nov 17 2013 Paul Howarth p...@city-fan.org - 0.103008-1
+- Update to 0.103008
+ - Faster!
+ - Add new_from_short_name to LicenseUtils for spdx.org-style short names
+ - Avoid double trailing dots in expanded licenses
+ - Fix some errors in (3-clause) BSD license text
+ - The 2-clause BSD (FreeBSD) license no longer incorrectly puts FreeBSD
+as the owner in the license full text
+- Update patch for building with old Test::More versions
+
* Sun Oct 27 2013 Paul Howarth p...@city-fan.org - 0.103007-1
- Update to 0.103007
- Fix regex to allow guessing from meta things like perl_5
diff --git a/sources b/sources
index 5182003..b30539a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c7884f8de01cede923e79c8c367ecf48 Software-License-0.103007.tar.gz
+14522397d2b34562b3a30be9e411267f Software-License-0.103008.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-Software-License/f20] Update to 0.103008
Summary of changes: 001cbe8... Update to 0.103008 (*) (*) 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 1031298] Missing perl(Return::Value) needed by the perl-Email-Send module-check
https://bugzilla.redhat.com/show_bug.cgi?id=1031298 Emmanuel Seyman emman...@seyman.fr changed: What|Removed |Added CC||perl-devel@lists.fedoraproj ||ect.org, ||tcall...@redhat.com Component|bugzilla|perl-Email-Send Assignee|ita...@ispbrasil.com.br |tcall...@redhat.com --- Comment #1 from Emmanuel Seyman emman...@seyman.fr --- This looks to be the same bug as #1000737 but with another module (Return::Value replaces Module::Pluggable as the guest of honor). perl -MEmail::Send -e '1' Can't locate Return/Value.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/vendor_perl/Email/Send.pm line 13. Re-assigning. -- 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=N45HFybBRKa=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
[perl-Software-License] Created tag perl-Software-License-0.103008-1.fc20
The lightweight tag 'perl-Software-License-0.103008-1.fc20' was created pointing to: 001cbe8... Update to 0.103008 -- 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-Software-License] Created tag perl-Software-License-0.103008-1.fc21
The lightweight tag 'perl-Software-License-0.103008-1.fc21' was created pointing to: 001cbe8... Update to 0.103008 -- 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
