Re: OSGi 5 Implementation
On Sat, 16 Nov 2013 02:46:51 -0500 Aleksandar Kurtakov 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" > 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 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 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 wrote: > - Original Message - > > From: "Manuel Faux" > > 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 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" > 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 wrote: > > > - Original Message - > > > From: "Manuel Faux" > > > 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 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) [spring-i
Re: unaccessability
On 17 November 2013 04:33, 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. > > 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 wrote: > - Original Message - > > From: "Manuel Faux" > > 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 wrote: > > > > > - Original Message - > > > > From: "Manuel Faux" > > > > 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 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 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 libvtkIn
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" > 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 wrote: > > > - Original Message - > > > From: "Manuel Faux" > > > 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 wrote: > > > > > > > - Original Message - > > > > > From: "Manuel Faux" > > > > > 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 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
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" > To: "Development discussions related to Fedora" > > 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" To: "Development discussions related to Fedora" 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" > To: "Development discussions related to Fedora" > > 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 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 <>-- 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 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 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 <>-- 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 > > 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: F21 System Wide Change: Headless Java
Quoting Richard W.M. Jones (2013-11-16 10:13:33) > On Sat, Nov 16, 2013 at 02:34:00AM +0100, Miloslav Trmač wrote: > > On Fri, Nov 15, 2013 at 12:28 PM, Jaroslav Reznik > > wrote: > > > == Scope == > > > Proposal owners: > > > * Modify javapackages-tools package to automatically generate > > > "java-headless" > > > autorequires (simple change) > > > * Identify and file bugs for affected packages (repoquery and bugzilla bug > > > creation) > > > * (optional) Mass-change spec files that have "Requires: java" to > > > "Requires: > > > java-headless" > > > > What about packages that do requires the non-headless dependencies? > > Can they be identified automatically, or would "other developers" be > > required to manually revert the change back from java-headless to full > > java? > > Wouldn't it be better to inspect the *.class files to find out what > other classes they depend on. Then you could have automatically > generated Perl-style dependencies like: > > Requires: java(java.net.URL) > > Or if that results in too many dependencies, then at least inspect the > *.class files to find out if the package only needs the java-headless > classes. > > (I'm aware it's possible for Java programs to dynamically create and > load classes. The same is true for Perl programs but that doesn't > stop the automatically generated requires being useful most of the > time.) I am quite certain rel-engs and RPM maintainers would love us for that. Just rt.jar from OpenJDK has over 18000 class files. Do we really want an rpm with 18000 provides? Could we even handle it? And that's just tip of the iceberg really...We have a database of all class files in Fedora. I believe it was over half a million classes. I wouldn't be surprised if we'd double current metadata size... We already generate requires/provides based on Maven metadata which are far more accurate than anything Perl has (based on my chats with Perl maintainers). We also require correct minimal version of JRE. But any action we'd take wrt java-headless would be inaccurate and mostly confusing. Incomplete automatization is worse that no automatization. People will rely on it and it *will* fail. I believe OpenJDK maintainers will agree that automatically detecting if java or java-headless is supposed to be required is not really feasible. There's too many variables at play. I'd expect out of ~800 packages that BR java only very few are going to be affected by java-headless change (i.e. they'd have to revert the change). I'd estimate maybe 30 broken packages and some we know wouldn't work so we would exclude them. How about this: * I file bug for every package that BRs java * We'll give maintainers two weeks (or maybe a month) to look at the bug and possibly fix their packages. * If they don't take any action on the bug (i.e. leave it in NEW) we'll fix up the package in automated way. * If they close the bug or assign it to themselves we'll leave the package alone However I am worried some maintainers will close those bugs without even glancing at their packages. And it takes just one screwed up package which pulls in full java and we're back at square one. I am open to suggestions on how to allow maintainers to opt-out if they feel confident their package is OK. -- Stanislav Ochotnicky Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.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: /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
