[EPEL-devel] transitioning packages to EPEL version
Hi all, I have previously installed backuppc 3.1.0 from centos 5 testing. The package is now not maintaned by centos anymore. EPEL have BackupPC version 3.3.0, but yum check-update did not suggest that this package is a replacement for the backuppc package by centos How do I transition the backuppc centos to BackupPC EPEL? I'm not planning to perform re-installation, as this machine have a lot of configuration done to arrive at its condition now. Any idea? Thanks [root@backup yum.repos.d]# yum info backuppc Loaded plugins: downloadonly Installed Packages Name : backuppc Arch : i386 Version: 3.1.0 Release: 1.el5.centos Size : 2.5 M Repo : installed Summary: BackupPC is a high-performance, enterprise-grade system for backing up Unix, Linux License: GPL Description: BackupPC is a high-performance, enterprise-grade system : for backing up Linux, Win32, and laptops to a server's disk. : Features include clever pooling of identical files, no client-side : software, and a powerful Apache/CGI user interface. Available Packages Name : BackupPC Arch : i386 Version: 3.3.0 Release: 2.el5 Size : 666 k Repo : epel Summary: High-performance backup system URL: http://backuppc.sourceforge.net/ License: GPLv2+ Description: BackupPC is a high-performance, enterprise-grade system for backing up Linux : and WinXX and Mac OS X PCs and laptops to a server's disk. BackupPC is highly : configurable and easy to install and maintain. -- Sharuzzaman Ahmat Raslan https://www.linkedin.com/in/sharuzzaman ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] transitioning packages to EPEL version
Hello, On Thursday, 16 October 2014 at 11:40, Sharuzzaman Ahmat Raslan wrote: I have previously installed backuppc 3.1.0 from centos 5 testing. The package is now not maintaned by centos anymore. EPEL have BackupPC version 3.3.0, but yum check-update did not suggest that this package is a replacement for the backuppc package by centos It isn't. At least not according to package name (hint: package names are case-sensitive). The requisite Obsoletes: tag is most probably missing as well in the EPEL package. How do I transition the backuppc centos to BackupPC EPEL? You have to either fix the EPEL package .spec file yourself and rebuild or file a bug against the package. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] transitioning packages to EPEL version
On 10/16/2014 02:32 PM, Dominik 'Rathann' Mierzejewski wrote: Hello, On Thursday, 16 October 2014 at 11:40, Sharuzzaman Ahmat Raslan wrote: I have previously installed backuppc 3.1.0 from centos 5 testing. The package is now not maintaned by centos anymore. EPEL have BackupPC version 3.3.0, but yum check-update did not suggest that this package is a replacement for the backuppc package by centos It isn't. At least not according to package name (hint: package names are case-sensitive). The requisite Obsoletes: tag is most probably missing as well in the EPEL package. How do I transition the backuppc centos to BackupPC EPEL? You have to either fix the EPEL package .spec file yourself and rebuild or file a bug against the package. Or backup configs, erase old package, install new package, restore configs. Manuel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Nominations for Engineering representative to the Fedora Council
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, As you are likely aware, we are undergoing some changes in governance[1] for Fedora On behalf of FESCo I am writing to you all to ask for nominations. preferably people will self nominate, however we will accept nominations from others as longa s the nominated person agrees to be considered. In order to submit your nomination please notify FESCo via the currently open ticket[2] in trac requesting a FESCo appointee. you have until Tuesday October 21 @ 23:59 UTC to get nominations in. FESCo will choose a representive in next weeks meeting. Thank you Dennis [1] https://fedoraproject.org/wiki/Council [2] https://fedorahosted.org/fesco/ticket/1355 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUP1+IAAoJEH7ltONmPFDRfb4P/1xvmQpyqMuECBQEBoQi3d5l 6FGJCV2ckbfxzFhqzuunbOWM7/k/e6J3F4zmJvL3QoefV9svUs/uNtCVM5ZNfgEZ W87Qf8K9Zar0dXyhhu2X6NFvKNnKMVCZZ4k7izfAAD/Kh8esutx9wujzaPXJYBBe uLscNfUG8fUAfBCmMjqlAyYgongOaOg7c27M3rRG7Q28Dmo5O17UdCvX1Kz4cdzX Pusblj3JSiIBnNtrug+d8OzQIrP8M0tITy/yxFi0m40lMOEH/zve85gg8nrF/yf5 F61IKeh8B39pp5iZkZdOSQ3AVR63sUbpNW3YM1KKQ8YMZ3RSA+sfK95v0cIgfGKM mikySeEJgALh1tDl6J5ROoIItZRzhsO5ZdleMYTEMDMBg0jVZGeGVht1E4iVn05l VDGh41oAXOfvyo5SDW8nYzogeawW/bLIV1ie8q4GTZRObOCckQjJ6bePEVMkByFt 0T7y4HBmHd7RodPpEn8luDLE0neju+vFwvkQQGaA9F+uHwdq4m4+Anfw/IEflYj1 GcngtzDAMKAqokJf66btqbRrXzjqKnfPGpQOc0LcVQ2BX6q9t3AHCOdff0m1h433 c/5JGSmBHhcOA/X5dZn+lF6HEM7IvA2ITZEdDsRLSNzvNUASUqEVlBpvXrKY4Kx0 pjUQFWFe9yoqCz3DNvqZ =CNA+ -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. On the majority of systems these days, is it really an issue to cache man pages anymore? That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work. (I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.) Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue. Cheers, -- Colin Watson [cjwat...@debian.org] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Tripwire fails to build for F21 and Rawhide
Tripwire fails to build for F21 and Rawhide. Is there a proven packager out there who has some spare time to submit a fix for this? Relevant info: https://bugzilla.redhat.com/show_bug.cgi?id=1107464 https://pkgs.fedoraproject.org/cgit/tripwire.git/ https://koji.fedoraproject.org/koji/taskinfo?taskID=7880302 https://kojipkgs.fedoraproject.org//work/tasks/302/7880302/build.log make[3]: Entering directory '/builddir/build/BUILD/tripwire-2.4.2.2-src/src/cryptlib' g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o algebra.o algebra.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o asn.o asn.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o cryptlib.o cryptlib.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o des.o des.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o dessp.o dessp.cpp cryptlib.cpp: In member function 'virtual void StreamCipher::ProcessString(byte*, unsigned int)': cryptlib.cpp:47:45: warning: operation on 'inoutString' may be undefined [-Wsequence-point] *inoutString++ = ProcessByte(*inoutString); ^ g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o elgamal.o elgamal.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o eprecomp.o eprecomp.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o filters.o filters.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o forkjoin.o forkjoin.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o integer.o integer.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o iterhash.o iterhash.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o misc.o misc.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o nbtheory.o nbtheory.cpp integer.cpp: In function 'void MontgomeryReduce(word*, word*, const word*, const word*, const word*, unsigned int)': integer.cpp:743:8: warning: unused variable 'carry' [-Wunused-variable] word carry = Add(R, R, M, N); ^ integer.cpp: In function 'void CorrectQuotientEstimate(word*, word*, word, word, const word*, unsigned int)': integer.cpp:903:7: warning: unused variable 'borrow' [-Wunused-variable] word borrow = Subtract(R, R, T, N+2); ^ integer.cpp: In member function 'Integer Integer::operator++()': integer.cpp:1617:8: warning: unused variable 'borrow' [-Wunused-variable] word borrow = Decrement(reg, reg.size); ^ g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o pch.o pch.cpp g++ -DHAVE_CONFIG_H -I.. -I../..-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o queue.o queue.cpp g++ -DHAVE_CONFIG_H -I..
Can you help with making fonts awesome in Fedora 21?
If you maintain a font in Fedora, or are a provenpackager, I could really need your help this weekend. Basically, we want to implement AppStream metadata[1] for all the fonts we want to show in the software center. I've already made a good start, and now other people are starting to help as well, so I'm pretty sure we can get the majority finished for next week when we can submit a mega-update of updated fonts. I've started a shared spreadsheet here: https://docs.google.com/spreadsheets/d/1o2sPWF7PEe6BKnBeZUI23m51nfFHUMx61IRsdNDozig/edit#gid=0 with what needs doing -- if you can help, please put your FAS name in the second column and get building. If any fonts are missing that you think belong in the software center please feel free to add them. It's really easy to add content for fonts. This is an example with multiple subpackages: http://pkgs.fedoraproject.org/cgit/silkscreen-fonts.git/commit/?id=32acdd5aa900ad732c023a73f7cd269a136f0957 and fonts with only one package are even easier, e.g. http://pkgs.fedoraproject.org/cgit/oflb-brett-fonts.git/commit/?id=72ff3099f733949f9526221b47a63eff9b9b969d If you've got any questions, please grab me on IRC (hughsie on FreeNode) or reply to this mail. Thanks! Richard [1] http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/ -- 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: Can you help with making fonts awesome in Fedora 21?
On Thu, Oct 16, 2014 at 11:44 AM, Richard Hughes hughsi...@gmail.com wrote: If you maintain a font in Fedora, or are a provenpackager, I could really need your help this weekend. Basically, we want to implement AppStream metadata[1] for all the fonts we want to show in the software center. I've already made a good start, and now other people are starting to help as well, so I'm pretty sure we can get the majority finished for next week when we can submit a mega-update of updated fonts. I've started a shared spreadsheet here: https://docs.google.com/spreadsheets/d/1o2sPWF7PEe6BKnBeZUI23m51nfFHUMx61IRsdNDozig/edit#gid=0 with what needs doing -- if you can help, please put your FAS name in the second column and get building. If any fonts are missing that you think belong in the software center please feel free to add them. It's really easy to add content for fonts. This is an example with multiple subpackages: http://pkgs.fedoraproject.org/cgit/silkscreen-fonts.git/commit/?id=32acdd5aa900ad732c023a73f7cd269a136f0957 and fonts with only one package are even easier, e.g. http://pkgs.fedoraproject.org/cgit/oflb-brett-fonts.git/commit/?id=72ff3099f733949f9526221b47a63eff9b9b969d If you've got any questions, please grab me on IRC (hughsie on FreeNode) or reply to this mail. Thanks! Richard [1] http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Mega updates, sound a litlle wrong to me so late in the F21 cycle, Fine for rawhide (f22) Tim -- 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: Can you help with making fonts awesome in Fedora 21?
On 16 October 2014 10:51, Tim Lauridsen tim.laurid...@gmail.com wrote: Mega updates, sound a litlle wrong to me so late in the F21 cycle, Fine for rawhide (f22) I did think about creating a new update for each build, but that's so much clicking. For something as simple as this an update with ~30 packages is very easy to submit, test and push. Feel free to submit individual updates for your packages if that's preferable. Richard. -- 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: man-db without cache update (no cron or systemd *.timer)
Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a): Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. Actually that is good idea IMO. The %post script could silently fail if no systemd is no the system. On the majority of systems these days, is it really an issue to cache man pages anymore? That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work. (I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.) %triggerin and %triggerun probably can't achieve this, but RPM plugin could do that. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue. Cheers, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141016 changes
Compose started at Thu Oct 16 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires
Re: Tripwire fails to build for F21 and Rawhide
On Thu, 16 Oct 2014 02:32:49 -0700, Moez Roy wrote: Tripwire fails to build for F21 and Rawhide. Is there a proven packager out there who has some spare time to submit a fix for this? Where is the package maintainer? The non-responsive maintainer procedure ought to get restarted for him, if the package is semi-orphaned apparently. And why did you quote 143 KB of build.log output instead of cutting off the irrelevant output? archive.cpp: In member function 'virtual void cLockedTemporaryFileArchive::OpenReadWrite(const char*, uint32)': archive.cpp:889:28: error: redeclaration of 'eArchiveOpen e' [-fpermissive] eArchiveOpen e(strTempFile, errStr); ^ archive.cpp:886:29: note: 'eFSServices e' previously declared here catch( eFSServices e) Rename e in line 886 to something else, e.g. eFSServices es and see how far it compiles then. Perhaps it's not the only file that causes trouble. -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 12:56 PM, Vít Ondruch wrote: Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a): Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. This did not crossed my mind. Actually that is good idea IMO. The %post script could silently fail if no systemd is no the system. Agree with Vita, this sound very good to me. Made a test build and it is working fine. Now the installation is much more smaller: Package ArchVersion Repository Size Installing: man-db x86_64 2.6.7.1-10.fc21 /man-db-2.6.7.1-10.fc21.x86_64 1.7 M Installing for dependencies: less x86_64 458-13.fc21 fedora 125 k libpipeline x86_64 1.3.0-4.fc21 fedora 49 k Transaction Summary Install 1 Package (+2 Dependent packages) Total size: 1.9 M Installed size: 2.0 M Installed: man-db.x86_64 0:2.6.7.1-10.fc21 Dependency Installed: less.x86_64 0:458-13.fc21 libpipeline.x86_64 0:1.3.0-4.fc21 On the majority of systems these days, is it really an issue to cache man pages anymore? That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work. (I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.) %triggerin and %triggerun probably can't achieve this, but RPM plugin could do that. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue. Cheers, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Django-1.7 for Fedora 21
Hello, in Fedora 21, we have Django-1.6. Django-1.7 was released a few weeks ago. As we're in feature freeze, but still pre-beta. I'd like to ask for opinions, if an upgrade to Django-1.7 would be still acceptable. I have a copr available containing Django-1.7 [1] Thoughts? Matthias [1] https://copr.fedoraproject.org/coprs/mrunge/django-1.7/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Qt 5 Fedora 21 packages
Some confusion here trying to use Fedora's Qt 5 packages, and it seems they cannot be use quickly. $ rpm -qa qt5\*|sort qt5-qtbase-5.3.2-3.fc21.x86_64 qt5-qtbase-devel-5.3.2-3.fc21.x86_64 qt5-qtbase-gui-5.3.2-3.fc21.x86_64 qt5-qtbase-ibase-5.3.2-3.fc21.x86_64 qt5-qtbase-mysql-5.3.2-3.fc21.x86_64 qt5-qtbase-odbc-5.3.2-3.fc21.x86_64 qt5-qtbase-postgresql-5.3.2-3.fc21.x86_64 qt5-qtbase-tds-5.3.2-3.fc21.x86_64 No moc in PATH, no uic either. Just moc-qt5 and uic-qt5. $ pkg-config --variable=moc Qt5 /usr/lib64/qt5/bin/moc $ pkg-config --variable=uic Qt5 $ $ rpm -qf /usr/lib64/qt5/bin/moc qt5-qtbase-devel-5.3.2-3.fc21.x86_64 No documentation in that package: $ rpm -qd qt5-qtbase-devel $ It seems to be specific to Fedora. Looking up the qt5-qtbase spec file, even the Qt5.pc file is generated there. The moc variable is added there to help finding MOC, but why not also UIC? All binaries get renamed to avoid a conflict, but I couldn't find a helper script to make them available in path again. I think of a shell file in a fixed location one could source. And why isn't any of this documented in the package description? It looks like one could simply prepend /usr/lib64/qt5/bin to $PATH to make available the executables, which are renamed to avoid conflicts with other Qt versions. $ rpm -qi qt5-qtbase-devel|tail -2 Description : Development files for qt5-qtbase. -- 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: 20141016 changes
Compose started at Thu Oct 16 05:15:05 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-9.fc22.i686 requires libowcapi-2.9.so.5 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [hadoop] hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient [hledger] ghc-hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-hledger-devel-0.19.3-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [idris] idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires
[PkgDB] limb:perl-Net-Dropbox-API watchbugzilla set to Approved
user: limb set for cheeselee acl: watchbugzilla of package: perl-Net-Dropbox-API from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: man-db without cache update (no cron or systemd *.timer)
On Thu, 2014-10-16 at 13:34 +0200, Jan Chaloupka wrote:
On 10/16/2014 12:56 PM, Vít Ondruch wrote:
Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
Forwarding Colin's response
[... snip ...]
Have you considered installing the timer file, but without the
dependency? If systemd is there, it could use it, otherwise not. That
would make a whole lot more sense to me than creating another package,
and would be my recommendation.
This did not crossed my mind.
Actually that is good idea IMO. The %post script could silently fail if
no systemd is no the system.
Agree with Vita, this sound very good to me. Made a test build and it is
working fine.
But it's contrary to the guidelines, as you're installing the unit file
in %{_unitdir}, without requiring systemd to own this directory.
Which goes back to the idea of either moving %{_unitdir} to the
filesystem package, or having a systemd-filesystem package...
--
Mathieu
--
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: man-db without cache update (no cron or systemd *.timer)
On Wed, Oct 15, 2014 at 05:53:41PM +, Jóhann B. Guðmundsson wrote: I discussed this with Peter Schiffer and the end result was in the future the man-db cron should be removed and man-db database should be updated with rpm triggerand the cron job should be kept as is until then, presicecly to prevent this from happening ( systemd being pulled in when it should not or component magically expecting it to be there ) and correct dependency on coreOS/baseOS components would be kept. Just make FESCO/FPC clean this up it was them who decided not to make it mandatory what should or should not be migrated to timer units and this is precisely the fallout I had expected from not doing that. I'm not seeing a problem here. If Peter said no way! I'm migrating to timer units, then maybe we would need to revisit. But as predicted, that's a non-issue. There really is no crisis here — we can continue to make incremental improvements as things come up, and if someone — you or anyone else! —is interested in reviving a concerted effort to do https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units, I'm all for it. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 12:03 PM, Matthew Miller wrote: On Wed, Oct 15, 2014 at 05:53:41PM +, Jóhann B. Guðmundsson wrote: I discussed this with Peter Schiffer and the end result was in the future the man-db cron should be removed and man-db database should be updated with rpm triggerand the cron job should be kept as is until then, presicecly to prevent this from happening ( systemd being pulled in when it should not or component magically expecting it to be there ) and correct dependency on coreOS/baseOS components would be kept. Just make FESCO/FPC clean this up it was them who decided not to make it mandatory what should or should not be migrated to timer units and this is precisely the fallout I had expected from not doing that. I'm not seeing a problem here. If Peter said no way! I'm migrating to timer units, then maybe we would need to revisit. But as predicted, that's a non-issue. There really is no crisis here — we can continue to make incremental improvements as things come up, and if someone — you or anyone else! —is interested in reviving a concerted effort to do https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units, I'm all for it. Obviously you have never had to implement features on the scale I had bumbing into the brokenness in the distribution while at it and I'm still waiting for you to picked that up, you where such an expert on the matter so man up and complete this yourself and god forbit that anyone has to clean up the mess you leave behind! -- 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: man-db without cache update (no cron or systemd *.timer)
On Thu, Oct 16, 2014 at 01:54:41PM +0200, Mathieu Bridon wrote:
Which goes back to the idea of either moving %{_unitdir} to the
filesystem package, or having a systemd-filesystem package...
https://bugzilla.redhat.com/show_bug.cgi?id=1153638
--
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
--
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: Qt 5 Fedora 21 packages
There are several strategies: * The bin-qt5 convention is already used by most distributions, so many applications/tools have adapted to it already. If you're aware of any that haven't yet, I'd be happy to help produce upstreamable patches to implement such support. * qt5-qtbase-devel provides rpm macros (in /usr/lib/rpm/macros.d/macros.qt5) that are useful during package creation, including: %_qt5_qmake %_qt5_bindir As you noted, one way to ensure Qt5 gets used is to prepend %_qt5_bindir to $PATH. This is essentially what kf5's %_cmake_kf5 (and similarly %_cmake_kde4) macros do. * As far as 'moc', that's not *usually* a tool an end-user typically runs, so we've never seen a need to provide easy access (via pkg-config, or rpm macro). If you have a justifiable use-case, we can certainly add it. * there's a developer tool 'qtchooser' that allows users to switch between default Qt developer environments. For the Qt5 qmake case, $ qtchooser -qt=qt5 -run-tool=qmake qtchooser is a little controversial (not universally endorsed by the kde- sig), so currently it is not recommended to rely on it in any fedora package builds. -- Rex Michael Schwendt wrote: Some confusion here trying to use Fedora's Qt 5 packages, and it seems they cannot be use quickly. $ rpm -qa qt5\*|sort qt5-qtbase-5.3.2-3.fc21.x86_64 qt5-qtbase-devel-5.3.2-3.fc21.x86_64 qt5-qtbase-gui-5.3.2-3.fc21.x86_64 qt5-qtbase-ibase-5.3.2-3.fc21.x86_64 qt5-qtbase-mysql-5.3.2-3.fc21.x86_64 qt5-qtbase-odbc-5.3.2-3.fc21.x86_64 qt5-qtbase-postgresql-5.3.2-3.fc21.x86_64 qt5-qtbase-tds-5.3.2-3.fc21.x86_64 No moc in PATH, no uic either. Just moc-qt5 and uic-qt5. $ pkg-config --variable=moc Qt5 /usr/lib64/qt5/bin/moc $ pkg-config --variable=uic Qt5 $ $ rpm -qf /usr/lib64/qt5/bin/moc qt5-qtbase-devel-5.3.2-3.fc21.x86_64 No documentation in that package: $ rpm -qd qt5-qtbase-devel $ It seems to be specific to Fedora. Looking up the qt5-qtbase spec file, even the Qt5.pc file is generated there. The moc variable is added there to help finding MOC, but why not also UIC? All binaries get renamed to avoid a conflict, but I couldn't find a helper script to make them available in path again. I think of a shell file in a fixed location one could source. And why isn't any of this documented in the package description? It looks like one could simply prepend /usr/lib64/qt5/bin to $PATH to make available the executables, which are renamed to avoid conflicts with other Qt versions. $ rpm -qi qt5-qtbase-devel|tail -2 Description : Development files for qt5-qtbase. -- 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: Django-1.7 for Fedora 21
Hi On Thu, Oct 16, 2014 at 7:37 AM, Matthias Runge wrote: Hello, in Fedora 21, we have Django-1.6. Django-1.7 was released a few weeks ago. As we're in feature freeze, but still pre-beta. I'd like to ask for opinions, if an upgrade to Django-1.7 would be still acceptable. I have a copr available containing Django-1.7 [1] Thoughts? Does it bring any substantial benefits? Does it break existing apps? Rahul -- 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: man-db without cache update (no cron or systemd *.timer)
Dne 16.10.2014 v 14:09 Matthew Miller napsal(a):
On Thu, Oct 16, 2014 at 01:54:41PM +0200, Mathieu Bridon wrote:
Which goes back to the idea of either moving %{_unitdir} to the
filesystem package, or having a systemd-filesystem package...
I can't see nothing against guidelines [1]. They says that you *can*
depend on systemd package. If man-db owns the directory, then it should
be perfectly fine (althoug you might be referring to systemd unit files
must put them into %{_unitdir}, but I deliberately interpret is as
expanded path).
Of course this should be revisited when Zbigniew will find a time or the
ticket below is resolved.
https://bugzilla.redhat.com/show_bug.cgi?id=1153638
Thanks Matthew.
Vít
[1] https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? -- Kalev On 10/15/2014 01:45 PM, Fedora Branched Report wrote: Compose started at Wed Oct 15 07:15:03 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch
Re: Django-1.7 for Fedora 21
On 16/10/14 14:25, Rahul Sundaram wrote: Hi On Thu, Oct 16, 2014 at 7:37 AM, Matthias Runge wrote: Hello, in Fedora 21, we have Django-1.6. Django-1.7 was released a few weeks ago. As we're in feature freeze, but still pre-beta. I'd like to ask for opinions, if an upgrade to Django-1.7 would be still acceptable. I have a copr available containing Django-1.7 [1] Thoughts? Does it bring any substantial benefits? Does it break existing apps? Two things to be considered: - Django-1.6 will get out of maintenance when F21 is still released (probably in March 2015) - when running an app, the following lines in your wsgi file need to be placed or replaced: from django.core.wsgi import get_wsgi_application application = get_wsgi_application() instead of whatever was there earlier to define the application. Matthias -- 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: Qt 5 Fedora 21 packages
On Thu, 16 Oct 2014 07:24:53 -0500, Rex Dieter wrote: There are several strategies: * The bin-qt5 convention is already used by most distributions, so many applications/tools have adapted to it already. If you're aware of any that haven't yet, I'd be happy to help produce upstreamable patches to implement such support. * qt5-qtbase-devel provides rpm macros (in /usr/lib/rpm/macros.d/macros.qt5) that are useful during package creation, including: %_qt5_qmake %_qt5_bindir As you noted, one way to ensure Qt5 gets used is to prepend %_qt5_bindir to $PATH. This is essentially what kf5's %_cmake_kf5 (and similarly %_cmake_kde4) macros do. That (even if shortened) would be a great addition to %description or a README.Fedora. I mean, those are customisations and could/should be mentioned somewhere, so using the RPM packages does not require listing files and trying to solve the puzzle. * As far as 'moc', that's not *usually* a tool an end-user typically runs, so we've never seen a need to provide easy access (via pkg-config, or rpm macro). If you have a justifiable use-case, we can certainly add it. Did you mean UIC and not MOC? I'm aware of Qt based programs (my own ones included) that pregenerate source files from UI forms prior to wrapping up the source tarball release - but do other programs nowadays really ship files pregenerated using MOC? Btw, the program I've had to build is Audacious from git, the ongoing port to Qt with --enable-qt. It expects moc in path, and the plugins package expects uic in path. -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 14:40:50 +0200, Kalev Lember kalevlem...@gmail.com wrote: Does anyone have ideas how to deal with these packages? I have been meaning to deal with meshmagick. I actually did a small part of the changes locally. The issue is that stricter checking by gcc is resulting in the package not building and some repeated consructs need to be fixed. -- 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: Broken dependencies in F21
Thanks for bringing this up. Speaking of broken Ruby stuff: [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libruby.so.2.0 A while ago, I suggested to drop these and rubygem-ruby-debug19 as well, but the question is still unanswered by maintainer: https://lists.fedoraproject.org/pipermail/ruby-sig/2014-August/001654.html [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 This seems to be abandoned by upstream: https://github.com/drnic/rubigen/issues/15 [rubygem-simple_form] rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(activemodel) 0:4.1 rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(actionpack) 0:4.1 I guess we are waiting for new upstream release here. [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) Not sure how active is the upstream, but I asked maintainer/deltacloud upstream and he seems to go to orphan this package. But the fix might be as easy as dropping the dependencies, since they were retired in Fedora. [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [rubygem-thinking-sphinx] rubygem-thinking-sphinx-3.1.0-2.fc21.noarch requires rubygem(joiner) = 0:0.2.0 Not sure about the state of these two. It seems they were broken by updated dependencies, so they should be either updated, the dependencies should be relaxed (but also in .gemspec file, so it would need some patching) or fixed if there are some incompatibilities. Vít Dne 16.10.2014 v 14:40 Kalev Lember napsal(a): Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? -- 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: Broken dependencies in F21
On 16/10/14 14:40, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? openslides: Needs an update to latest version, and a few reviews for currently unpackaged deps. I didn't had the time for it django-recaptcha: I'm not the maintainer here. IMHO we just can drop it right now. pipelight-selinux: a leftover from pipelight removal. Should be dropped ASAP. python-askbot-fedmsg: askbot was retired, so should this one. Matthias -- 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: man-db without cache update (no cron or systemd *.timer)
On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote: Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. Nope, this is not going to work. If there's no dependency on systemd then during installation rpm can install man-db before systemd and and the timer will not get enabled. Currently it is not possible to install systemd units without a dependency on systemd. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Django-1.7 for Fedora 21
On Thu, 2014-10-16 at 14:46 +0200, Matthias Runge wrote: On 16/10/14 14:25, Rahul Sundaram wrote: Hi On Thu, Oct 16, 2014 at 7:37 AM, Matthias Runge wrote: Hello, in Fedora 21, we have Django-1.6. Django-1.7 was released a few weeks ago. As we're in feature freeze, but still pre-beta. I'd like to ask for opinions, if an upgrade to Django-1.7 would be still acceptable. I have a copr available containing Django-1.7 [1] Thoughts? Does it bring any substantial benefits? Does it break existing apps? Two things to be considered: - Django-1.6 will get out of maintenance when F21 is still released (probably in March 2015) - when running an app, the following lines in your wsgi file need to be placed or replaced: from django.core.wsgi import get_wsgi_application application = get_wsgi_application() instead of whatever was there earlier to define the application. Matthias There are no Django applications that are part of the install sets of any of the Products or Spins so far as I am aware, so the risk to the Project deliverable dates would be minimal. I'd suggest bringing it to FESCo for a more complete risk-analysis, but I'd argue that we'd be better off shipping python-django as 1.7 and also the python-django16 package in Fedora 21. signature.asc Description: This is a digitally signed message part -- 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: Django-1.7 for Fedora 21
On 10/16/2014 09:32 AM, Stephen Gallagher wrote: snip There are no Django applications that are part of the install sets of any of the Products or Spins so far as I am aware, so the risk to the Project deliverable dates would be minimal. I'd suggest bringing it to FESCo for a more complete risk-analysis, but I'd argue that we'd be better off shipping python-django as 1.7 and also the python-django16 package in Fedora 21. +1 Shipping F21 with Django 1.6 as the default will *definitely* have us kicking ourselves in 6 months. And shipping 1.7 by default will make lots of Django users/devs happy. Definitely bring it up to FESCo, but it's probably riskier to be shipping something that will become unsupported within the release lifetime than to upgrade to the newer version. -- 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: Qt 5 Fedora 21 packages
Michael Schwendt wrote:
Some confusion here trying to use Fedora's Qt 5 packages, and it seems
they cannot be use quickly.
Depends on the build system you (or the upstream project you're packaging)
use:
* CMake: just works
* qmake: call qmake-qt5 and it'll find all the rest just fine
* qbs: hopefully just works too, but not tested by me yet
* anything else: see below
I couldn't find a helper script to make them available in path again.
[snip]
It looks like one could simply prepend
/usr/lib64/qt5/bin
to $PATH to make available the executables, which are renamed to avoid
conflicts with other Qt versions.
There you have your wrapper script:
export PATH=%{_qt5_bindir}:$PATH
IMHO, it doesn't make sense to install a one-line script, one that would
also have to be sourced rather than run normally.
In addition, as Rex Dieter said, the upstream project's build setup should
be fixed to look for the binaries with -qt5 suffixes in the long run.
Kevin Kofler
--
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: Qt 5 Fedora 21 packages
Rex Dieter wrote:
* there's a developer tool 'qtchooser' that allows users to switch between
default Qt developer environments. For the Qt5 qmake case,
$ qtchooser -qt=qt5 -run-tool=qmake
qtchooser is a little controversial (not universally endorsed by the kde-
sig), so currently it is not recommended to rely on it in any fedora
package builds.
The reason I (and last we discussed this, also Than Ngo) don't endorse
qtchooser is that it is IMHO the entirely wrong approach: What Qt version to
use is a property of the project you're trying to build, not of your system
or your user account. It shouldn't be the person building a project to
decide what version of Qt to build it against (where usually only one will
actually work), but the project's build setup.
To be clear, using -run-tool as in Rex Dieter's example:
qtchooser -qt=qt5 -run-tool=qmake
will only work for qmake, where you can also just run qmake-qt5 directly and
not use qtchooser at all. For other build systems, which run tools more than
once and want to run just moc and uic, if you use qtchooser, you
actually need to select the Qt version user-account-wide (eww!).
And the same effect as qtchooser can be had with the simple:
export PATH=%{_qt5_bindir}:$PATH
which also has the advantage of only affecting that particular shell, and
thus not break concurrent builds using other Qt versions. (And if you REALLY
want to set it user-account-wide, that's what ~/.bash_profile is for.)
Therefore, I see no reason whatsoever to even ship qtchooser in Fedora at
all (as Rex Dieter is now doing, over my and Than's objections), let alone
support it.
It is really unfortunate that upstream decided to promote this broken
solution instead of officially renaming the binaries to suffixed versions
as we distributors have been doing for years.
Kevin Kofler
--
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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. ## libint soname bump [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This can just be rebuilt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This hasn't finished building yet, but it seems ok so far: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650 ## json-c soname bump [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643 ## rbtorrent soname bump [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 Seems this will need some upstream work: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881660 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 So does this: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881679 ## ocaml-camlp4 update The dep was updated: $ repoquery --provides ocaml-camlp4 ocaml(Camlp4) = 315363230d084ceb1cc5e85bfe2bfd49 [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760 ## vala update [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881927 However, there's a new upstream release which might fix the problem. [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881961 However, there's a new upstream release which might fix the problem. [valabind] valabind-0.7.4-4.fc21.armv7hl requires libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881954 However, there's a new upstream release which might fix the problem. ## Django 1.4 retired [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 Django 1.4 has been retired: https://lists.fedoraproject.org/pipermail/devel/2014-September/202593.html [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot Askbot was retired in f21 and master: https://lists.fedoraproject.org/pipermail/devel/2014-September/202687.html [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 Seems libaudclient was part of audacious but has then been removed upstream: http://audacious-media-player.org/download ## Unknown cases [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so This is weird, edelib provides libedelib.so.2.1.0, but somehow it requires libedelib.so Could it be the rpmbuild automatic requires generator misbehaved? [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [freesteam]
Re: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 01:30 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote: Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. Nope, this is not going to work. If there's no dependency on systemd then during installation rpm can install man-db before systemd and and the timer will not get enabled. Currently it is not possible to install systemd units without a dependency on systemd. Right which in turn will lead up to the scenario I tried to explain thousand times with FESCO that we would end up having components depend on systemd when they should not and with absolutely no benefit of and worse outcome as well as more frustrating aministrator/enduser experience than continuing to use cron for those jobs as well as obfuscating the work of those working on cleaning up the core/baseOS. If it would have made sense to migrate every cron job to timer units I would have written and filed a feature proposal then and there which would achieve exactly that but the fact is that systemd timers and cronie are two component that complement each others short comings and systemd has quite few of those shortcomings compared to cron. Unfortunately people only seem to see the outcome for their own component or their ( cloud ) product instead of thinking about the whole. If people are so inclined and anxious to drop that cron job then they should spend their time and energy and write that rpm trigger(s) for man in accordance with what Peter Schiffer said as opposed to try to implement this with timer units and or workaround the FPG. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken dependencies in F21
On 10/16/2014 02:40 PM, Kalev Lember wrote: [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 And replying to my own mail, this should be fixed with: https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.32.0-20.fc21 -- Kalev -- 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: No more deltarpms by default
Ian Malone wrote: I have an internet flatrate at 150 mbs, and downloading the full rpms is ALOT faster than the the work that the delta rpms requires. Wow. Good to see normal users are taken into account. I have a normal Austrian broadband connection, and it is still much faster to just download the full RPMs than to use delta RPMs. And parallelization (as others in the thread have suggested) will not help at all on the single-core machine I'm typing this on. Thus, I disabled delta RPMs long ago and agree that they should be off by default. Kevin Kofler -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. ## libint soname bump [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This can just be rebuilt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637 Re-built: https://admin.fedoraproject.org/updates/PyQuante-1.6.4-13.fc21 Amusingly, it FTBFS on F22, apparently due to a change in numpy: http://koji.fedoraproject.org/koji/taskinfo?taskID=7882563 I'll let the maintainer fix that one. Pierre -- 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: Can you help with making fonts awesome in Fedora 21?
Hi, On Thu, Oct 16, 2014 at 3:29 PM, Richard Hughes hughsi...@gmail.com wrote: On 16 October 2014 10:51, Tim Lauridsen tim.laurid...@gmail.com wrote: Mega updates, sound a litlle wrong to me so late in the F21 cycle, Fine for rawhide (f22) I did think about creating a new update for each build, but that's so much clicking. For something as simple as this an update with ~30 packages is very easy to submit, test and push. Feel free to submit individual updates for your packages if that's preferable. I have pushed all my fedora 21 updates as an individual updates now. Regards, Parag. -- 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: Qt 5 Fedora 21 packages
On Thu, 16 Oct 2014 16:27:57 +0200, Kevin Kofler wrote:
It looks like one could simply prepend
/usr/lib64/qt5/bin
to $PATH to make available the executables, which are renamed to avoid
conflicts with other Qt versions.
There you have your wrapper script:
export PATH=%{_qt5_bindir}:$PATH
As pointed out, I would have preferred a brief %description or README.Fedora
as a quickstart rather than examining package contents and trying to figure
out whether something is is the right way to do it and not only a work-around.
It could also have been that setting environment variables would be _the_
way to point Qt detection configure scripts at the right places.
Obviously, adjusting $PATH is what I've done as a work-around, albeit not using
the RPM macro, because I only looked in /etc/rpm because I always forget about
the new directory.
It could have been more convenient to use the rpms. That's all!
IMHO, it doesn't make sense to install a one-line script, one that would
also have to be sourced rather than run normally.
I mentioned a helper script based on the assumption that there might
be more environment variables that need adjustment. ;-)
--
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: Broken dependencies in F21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 https://lists.fedoraproject.org/pipermail/devel/2014-August/201840.html - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIbBAEBAgAGBQJUP+86AAoJEFyovWBm4V0AdA0P+Lz7W/0XubV3oN3VJz4lrKqQ JXrLFlYfMtaD2aZUdlOv6hhGnpbZashhXDbL0jw176sx+Y43v5/b7wnHcxTGEBoB udgfE/I6ansxzzrnjXc3boyDJ7sDFmEcMAkUcQ6RohQLZye4hEGXGH4s9Rz2EPfn zDZNX7du9NQ9aNwkLpz3T67n7bNAXRyUL10CXEn82PFbWfokPePf79i+yMXG9I77 IlaA2VYmevIMMVDbrkduF7P5drqmEcZL/gUiYuy6Qc3TGqyOaeZiGjIAk/xhavNS z6/pe4279HGsFNcAQ1iVUVtchvDc/mzyTTKz67VSeGSvabgcdD4J+wV8kkZsMYy3 aG768vMdN55foldOozm59WOdYezBsqi0+HEmP4tCu6X6PyfT1eYEJ7QpvWibB7Pj DfD9bsjyvNGLPZCOvIrvbL1X/HyBrtP9RCrgtwpg6NKB8jle+OZs8sQ9sqpZ29E/ YroJnrCc+8oXPodFbSdKAarsDanD7/qPZcakHaXrBeVEkdTbpc1THMvoKNvTC5b/ 40HGnn9EIvZgyDqvMI/bbuBGstkcbqucsZQlBDMN1BIPbe/frS8wfu+8Mwiip2I5 DlbhvqRhMB0I10JEgCqt/+zKNdnLR6ErmcxmqiaSmuyXemT2QR5912e/D2ouZkb4 tOeM60v5kSqFoI1/Dgc= =uehC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken dependencies in F21
On 10/16/2014 06:16 PM, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 https://lists.fedoraproject.org/pipermail/devel/2014-August/201840.html Likely fixed by https://admin.fedoraproject.org/updates/FEDORA-2014-12872/ascend-0.9.8-15.20140710svn4695.fc21 , can you test it and give the update karma? -- Thanks, Kalev -- 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: Broken dependencies in F21
On 10/16/2014 04:47 PM, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: ## json-c soname bump json-c seems to have dropped the /usr/include/json - /usr/include/json-c symlink. This breaks packages, which depend upon /usr/include/json, e.g. libverto-jsonrpc. Was this change intentional or an accident? [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643 Apart from the fact this package's spec appears suffer from bit rot, this package depends upon libverto-jsonrpc-devel, i.e. it indirectly is a victim of /usr/include/json having gone. Ralf -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 04:49 PM, Jóhann B. Guðmundsson wrote: On 10/16/2014 01:30 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote: Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. Nope, this is not going to work. If there's no dependency on systemd then during installation rpm can install man-db before systemd and and the timer will not get enabled. Currently it is not possible to install systemd units without a dependency on systemd. Right which in turn will lead up to the scenario I tried to explain thousand times with FESCO that we would end up having components depend on systemd when they should not and with absolutely no benefit of and worse outcome as well as more frustrating aministrator/enduser experience than continuing to use cron for those jobs as well as obfuscating the work of those working on cleaning up the core/baseOS. If it would have made sense to migrate every cron job to timer units I would have written and filed a feature proposal then and there which would achieve exactly that but the fact is that systemd timers and cronie are two component that complement each others short comings and systemd has quite few of those shortcomings compared to cron. Unfortunately people only seem to see the outcome for their own component or their ( cloud ) product instead of thinking about the whole. crontabs itself depends on systemd so what is the diffrence then? mock -r fedora-21-x86_64 --init ... mock -r fedora-21-x86_64 --install crontabs ... Installed: crontabs.noarch 0:1.11-9.20130830git.fc21 Dependency Installed: acl.x86_64 0:2.2.52-7.fc21 cronie.x86_64 0:1.4.12-1.fc21 cronie-anacron.x86_64 0:1.4.12-1.fc21 cryptsetup-libs.x86_64 0:1.6.6-1.fc21 dbus.x86_64 1:1.8.6-3.fc21 dbus-libs.x86_64 1:1.8.6-3.fc21 device-mapper.x86_64 0:1.02.90-1.fc21 device-mapper-libs.x86_64 0:1.02.90-1.fc21 fipscheck.x86_64 0:1.4.1-7.fc21 fipscheck-lib.x86_64 0:1.4.1-7.fc21 kmod.x86_64 0:18-3.fc21 kmod-libs.x86_64 0:18-3.fc21 libseccomp.x86_64 0:2.1.1-5.fc21 qrencode-libs.x86_64 0:3.4.2-4.fc21 systemd.x86_64 0:215-19.fc21 If people are so inclined and anxious to drop that cron job then they should spend their time and energy and write that rpm trigger(s) for man in accordance with what Peter Schiffer said as opposed to try to implement this with timer units and or workaround the FPG. Which will led to a lot of dependencies on man-db because man-db's cache has to be updated. JBG Regards Jan -- 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: Django-1.7 for Fedora 21
-Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Ryan S. Brown Sent: Thursday, October 16, 2014 09:59 To: devel@lists.fedoraproject.org Subject: Re: Django-1.7 for Fedora 21 On 10/16/2014 09:32 AM, Stephen Gallagher wrote: snip There are no Django applications that are part of the install sets of any of the Products or Spins so far as I am aware, so the risk to the Project deliverable dates would be minimal. I'd suggest bringing it to FESCo for a more complete risk-analysis, but I'd argue that we'd be better off shipping python-django as 1.7 and also the python-django16 package in Fedora 21. +1 Shipping F21 with Django 1.6 as the default will *definitely* have us kicking ourselves in 6 months. And shipping 1.7 by default will make lots of Django users/devs happy. Definitely bring it up to FESCo, but it's probably riskier to be shipping something that will become unsupported within the release lifetime than to upgrade to the newer version. +1 -r -- John Florian -- 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: Broken dependencies: freesteam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2014 02:46 PM, Rich Mattes wrote: On Mon, Aug 25, 2014 at 8:34 AM, Antonio Trande anto.tra...@gmail.com mailto:anto.tra...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. On 08/25/2014 01:39 PM, build...@fedoraproject.org mailto:build...@fedoraproject.org wrote: freesteam has broken dependencies in the F-21 tree: On x86_64: freesteam-ascend-2.1-6.20140724svn753.fc21.x86_64 requires libascend.so.1()(64bit) On i386: freesteam-ascend-2.1-6.20140724svn753.fc21.i686 requires libascend.so.1 On armhfp: freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 Please resolve this as soon as possible. build...@fedoraproject.org mailto:build...@fedoraproject.org sends me above message via mail. It's okay to me: $repoquery -R freesteam-ascend --enablerepo=updates-testing ascend-libs(x86-64) freesteam(x86-64) = 2.1-6.20140724svn753.fc20 libascend.so.1()(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libfreesteam.so.1()(64bit) rtld(GNU_HASH) $repoquery --whatprovides libascend.so.1* - --enablerepo=updates-testing --archlist=x86_64 ascend-libs-0:0.9.8-10.20140710svn4695.fc20.x86_64 I don't know what's the problem... It looks like your repoquery running over f20, not f21. The latest f21 build of ascend doesn't seem to have any of the Requires or Provides metadata[1] that the previous build lists[2]. It might have something to do with the recent rpm dependency generation problem[3] (the version of rpm used to build the broken ascend was 4.12.0-0.beta1.3.fc21,) or it could be something else. I would try to rebuild ascend to see if that fixes things. Rich [1] http://koji.fedoraproject.org/koji/rpminfo?rpmID=5510532 [2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=5369008 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1131960 Ascend is re-built with a new packaging release ascend-0.9.8-15.20140710svn4695. This problem should be fixed. - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIbBAEBAgAGBQJUP/3ZAAoJEFyovWBm4V0AcqUP+JNtD1sjWRBTusMqyQfhMj4t hGI8Sot/KDPE39X5hZnEuogZPM0D0nK1DMpvWThwYqPKBYaBq6iKE+2/mcbpk2fd i/wlhCRDpUCN28tGcHzbj/HoJZ9RrvTZn8tXRnG/JzQ46cnfmMIKkHWw8aye3ujl L+uzSo6XP6OPHPunnKFoe/D6uogVvxh7gsleceDK8CSQ5+j6dajVyhpoGHCVw6v6 khI8ibD5Ds/jJpQN9R9PF/zpmyPCoNrqbfq15g8lnZmmn0UG3gvWLg6PIouEDB/F Lq0Kws+VtsxoMrPUKgsfkcFPmPpajlnMKJjtfYM80u92w/y1knsUvfnGRHZ8L2uW 14M7c/RXT88XA79hIIYAPTBKHkBLI1GAgk7oWenyLOXK9QoDYylvKmhng4Vtm0BG 6ufgSZwm4Af3QVbAaRc8wR81hChiPatRik6vQMPIM8uhkoyDHMK2nCbydN3bdN/2 P1TNGFU4sj5lyuGn0aZzKDw6sQ2sT5wCU9DK9Z4VYTd0p2UEjaf5Kg3DWmZayi3V uKdkLJ+pNRL3oSuxdb24+iDctSAs/rtXf2vyk0b20w4Tw8YYfd+lVEqQrarZZdWn 7zrgsVG2LExq7u7RQULXEFZgKlucCK9FkVNH+NGpI/s30c6HE31s0cXOPHY981Xe 17WHZag9jrXSiII3EXs= =qA9C -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can you help with making fonts awesome in Fedora 21?
On 16 October 2014 16:25, Parag N(पराग़) panem...@gmail.com wrote: I have pushed all my fedora 21 updates as an individual updates now. Cool, thanks. Any chance you could mark those in the spreadsheet somehow? e.g. Make the packages have a red background or something. Thanks. Richard -- 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: Django-1.7 for Fedora 21
Latest greatest, please. Especially since django 1.7 brought south (migrations) to core. Also, in a couple of months, I believe that a lot of folks would love to use 1.7, so let's make their life easier (by NOT doing 'pip install'). Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
enhancing crypto policies for other languages than C
Hello, The currently proposed fedora maintainer instructions for the system-wide crypto policy are mainly for the C language. Could some experienced in other languages (e.g., ruby/python) propose some text for them? https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies regards, Nikos -- 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: New hardware for Retrace Server
On 10/15/2014 11:50 PM, Jakub Filak wrote: On Wed, 2014-10-15 at 16:55 -0600, Orion Poplawski wrote: We used to have the ability to get statistics grouped by packager, right, or am I mis-remembering? We still have it, but you can filter by packager only on 'Problems' page: https://retrace.fedoraproject.org/faf/problems/hot/*/265/*/ Perfect, thanks. I guess I looked everywhere but there. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thursday, 16 October 2014 at 16:47, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. [...] [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This hasn't finished building yet, but it seems ok so far: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650 https://admin.fedoraproject.org/updates/FEDORA-2014-12957/ in testing. Sorry, it took a while to get elpa building first and then fix the remaining issues in cp2k build. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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: No more deltarpms by default
On Thu, Oct 16, 2014 at 8:00 AM, Kevin Kofler kevin.kof...@chello.at wrote: And parallelization (as others in the thread have suggested) will not help at all on the single-core machine I'm typing this on. Single-Core? Really Kevin? Even the One Laptop Per Child machines are dual-core. ;-) -- 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: Review swap
On Wed, Oct 15, 2014 at 1:35 PM, Jerry James loganje...@gmail.com wrote: On Mon, Oct 13, 2014 at 11:42 AM, Jerry James loganje...@gmail.com wrote: One of my packages has picked up a dependency on libpuma in a new release: https://bugzilla.redhat.com/show_bug.cgi?id=1135654 Would someone care to do a review swap? Thanks, I've had some helpful comments on the bug, but no takers for a review yet. Would someone care to swap with me? Give me a hard one. I probably deserve it. I am still in need of a reviewer. Who can help me out? I'm willing to review for you in exchange. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
Gerald B. Cox composed on 2014-10-16 12:52 (UTC-0700): Kevin Kofler wrote: And parallelization (as others in the thread have suggested) will not help at all on the single-core machine I'm typing this on. Single-Core? Really Kevin? Even the One Laptop Per Child machines are dual-core. ;-) I have F20, F21 and/or F22 installed on 15 machines, of which one has more than one core, and only 2-3, maybe 4, of which have HT. Some people need to get the most out of their money, and/or take whatever they can get. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, 16 Oct 2014 14:40:50 +0200, Kalev Lember wrote: We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 That library has been discontinued, but meanwhile has reappeared in a separate tarball. The original audtty packager had retired audtty in response to bugzilla tickets, but someone else has taken over the package without any activity [yet]. IMO, it would have been fine to resurrect the package no sooner than when something would be ready. E.g. a libaudclient review request with approval. -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 05:10 PM, Jan Chaloupka wrote: Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation. Nope, this is not going to work. If there's no dependency on systemd then during installation rpm can install man-db before systemd and and the timer will not get enabled. Currently it is not possible to install systemd units without a dependency on systemd. Right which in turn will lead up to the scenario I tried to explain thousand times with FESCO that we would end up having components depend on systemd when they should not and with absolutely no benefit of and worse outcome as well as more frustrating aministrator/enduser experience than continuing to use cron for those jobs as well as obfuscating the work of those working on cleaning up the core/baseOS. If it would have made sense to migrate every cron job to timer units I would have written and filed a feature proposal then and there which would achieve exactly that but the fact is that systemd timers and cronie are two component that complement each others short comings and systemd has quite few of those shortcomings compared to cron. Unfortunately people only seem to see the outcome for their own component or their ( cloud ) product instead of thinking about the whole. crontabs itself depends on systemd so what is the diffrence then? That makes no sense crontabs serves as a virtual requires for cron daemon functionality Those cron daemons can either be cronie, fcron, dcron,vixie-cron and or whatever else exist and is being shipped now and or in the future ( and now with products none should be the default, that should be left up to be specified by each product ) and those are the once that depend on systemd so either crontab depends directly on one of those daemons ( hardly ) or simply requires cron.d ( more likely ) which is provided by one of those cron daemons. ( I have not look at the spec so I dont know what the crontab did once my guideline changes finally got approved although they did not get approved in it's original form ) The difference is that you actually get correct dependencies on core/base installation but today alot of components don't mention ( or incorrectly ) mention dependencies on the core/base installation. Now you might be scratching your head and think like those that got us into this mess to begin with nah I dont need to worry too much about adding dependencies, this stuff is optional and the core/base installation will remain the same wondering why is this so important? The reason why it's so important is because nothing in this life is certain except for death and taxes and the components that make up the core/base installation are no exception in that regard. Unlike most if not all features owners I take my work very seriously and I do not expect others to do my features for me ( there seems to be common practices for someone to come up with an idea which they label feature then tag all maintainers for affected components and tried to have them implement it for them, leaving the distribution with majority of it's feature half implemented since those maintainers either dont exist, dont care or dont have the time to do it ) and unlike other features owners I deal with components in the hundreds so I know more then most people how utterly broken the feature process in the distribution is. One of my responsability as an feature owner is to gather the scope of the change I'm proposing so I can up to the best of my ability see how that change will affect the distribution and it was FESCo responsibility to validate that scope ( I would assume now that their role no longer exists or at least change significantly since there is no distributions default now with the products ). I for the life of me could not property, reliable determine ( thus neither could FESCo ) the scope of my features because the dependency chain in the core/base installation is so utterly and completely broken. cron, logwatch, syslog, logging in general all utterly and totally broken. Seriously out of the entire what 600 components that ship daemons/services, 4 I think depended on rsyslog none on logwatch/logrotate 5 on cronie I think etc. Now for the second half of my lengthy answer the benefical of migrating to timer units is only relevant to bootup,udev,unit startup,suspend,shutdown hence if your component does not already depend on systemd but ships cron job it should not be migrated period. If people are so inclined and anxious to drop that cron job then they should spend their time and energy and write that rpm trigger(s) for man in accordance with what Peter Schiffer said as opposed to try to implement this with timer units and or workaround the FPG. Which will led to a lot
Re: No more deltarpms by default
My comment was not meant to be argumentative, but rather tongue-in-cheek. However, I do believe when changing a default, it isn't about what is convenient for me. It's about what is best for the entire community and what are the real world ramifications. I'm not buying the let's change the default because high bandwidth is pervasive argument. I'll go out on a limb here and suggest: 1. Most people who can afford to pay the monthly recurring cost for a high speed bandwidth connection have multi-core machines. 2. People who are running Fedora on multiple machines possess the skill set to easily change the default and turn Presto off if they wish. I can't speak for other countries, but in the USA low cost high speed bandwidth is not pervasive. We're fighting about net neutrality and the FCC is trying to change the definition of a broadband connection. The carriers are fighting it. They are constantly looking for ways to cut bandwidth, shape traffic. Most people would rather use their bandwidth to stream media than to get an update applied a little faster. What about the repositories and mirrors? Do they all have unlimited, cheap bandwidth? Who is the target demographic of Fedora? People with single-core machines and high speed broadband? What about people with slow connections? Is our response to them sucks to be you? Yes, not everyone can afford to buy a new machine - but neither can everyone afford to pay the monthly recurring cost for high speed broadband. The purpose of Presto is still sound. It was a good idea then, it remains a good idea now. http://fedoraproject.org/wiki/Features/Presto Full disclosure: Yes, I have a high speed broadband connection. I'd rather use it for streaming and other downloading than downloading full RPMs. It doesn't bother me if it takes a few more minutes to update my system. I do it when I'm sleeping anyway. On Thu, Oct 16, 2014 at 1:03 PM, Felix Miata mrma...@earthlink.net wrote: Gerald B. Cox composed on 2014-10-16 12:52 (UTC-0700): Kevin Kofler wrote: And parallelization (as others in the thread have suggested) will not help at all on the single-core machine I'm typing this on. Single-Core? Really Kevin? Even the One Laptop Per Child machines are dual-core. ;-) I have F20, F21 and/or F22 installed on 15 machines, of which one has more than one core, and only 2-3, maybe 4, of which have HT. Some people need to get the most out of their money, and/or take whatever they can get. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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 -- 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: No more deltarpms by default
On 10/17/2014 05:40 AM, Gerald B. Cox wrote: My comment was not meant to be argumentative, but rather tongue-in-cheek. However, I do believe when changing a default, it isn't about what is convenient for me. It's about what is best for the entire community and what are the real world ramifications. IMO, the default should be about what fits most users needs bests. I'll go out on a limb here and suggest: 1. Most people who can afford to pay the monthly recurring cost for a high speed bandwidth connection have multi-core machines. 2. People who are running Fedora on multiple machines possess the skill set to easily change the default and turn Presto off if they wish. I can't speak for other countries, but in the USA low cost high speed bandwidth is not pervasive. We're fighting about net neutrality and the FCC is trying to change the definition of a broadband connection. The same applies to my home country (Germany) and as I would guess probably most of the Western World. What about the repositories and mirrors? Do they all have unlimited, cheap bandwidth? Probably not all, but I guess, most of them have. Who is the target demographic of Fedora? I thought, we are talking about defaults/presets and not about disabling delta-rpms at all? Changing the default would not be much a problem to me, but not providing delta-rpms could likely become a problem. People with single-core machines and high speed broadband? What about people with slow connections? Is our response to them sucks to be you? Yes, not everyone can afford to buy a new machine Also keep in mind that we are in the age of mobile platforms, i.e. a user's situation isn't necessarily static. A user may prefer full rpms in one situation but may prefer delta rpms in another. E.g. you may have a high-speed broadband at your usual places (at home/in the office), but you may easily find yourself in situations with access to a slow, unreliable and costly internet connection, were using full rpms could be prohibitive. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #13 from Petr Pisar ppi...@redhat.com --- (In reply to Paul Howarth from comment #12) If you do that, are you then going to post-bootstrap rebuild every package that pulled in Module::Build during the bootstrap process, to make sure it still builds OK with Software::License in the buildroot? I'm not going. I could, but I think that rel-engs would kill us. We already have a non-bootstrap rebuild check in Koschei http://koschei.cloud.fedoraproject.org/groups/perl-sig?order_by=-state%2Cname. Adding bootstrap-dependent Requires (as opposed to bootstrap-dependent RuildRequires) has a much bigger impact in terms of post-bootstrap rebuilds I think. I understand. -- 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=C9IjAVKiu8a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1153134] FTBFS: No longer works with the current Lingua::EN::Numbers
https://bugzilla.redhat.com/show_bug.cgi?id=1153134 --- Comment #1 from Miro Hrončok mhron...@redhat.com --- 1. Latest upstream release is ~5 years old 2. No other package requires this any more = I suggest retiring. Any objections? -- 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=XlZelDfriXa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1153134] FTBFS: No longer works with the current Lingua::EN::Numbers
https://bugzilla.redhat.com/show_bug.cgi?id=1153134 --- Comment #2 from Petr Šabata psab...@redhat.com --- It's your package, your call. The fix is trivial, though... -- 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=JmnKMvCg6Oa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Simple-1.001008.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Simple: 17c7705c15430c0d7a81575113f22ac6 Test-Simple-1.001008.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-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 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-Test-Simple] Update to 1.001008
commit 2bd015c72dfa00e3d7d16b62c16f2272614aa5dc
Author: Paul Howarth p...@city-fan.org
Date: Thu Oct 16 11:20:28 2014 +0100
Update to 1.001008
- New upstream release 1.001008
- Fix subtest name when skip_all is used
perl-Test-Simple.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-Simple.spec b/perl-Test-Simple.spec
index 1863253..35425f7 100644
--- a/perl-Test-Simple.spec
+++ b/perl-Test-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Simple
Summary:Basic utilities for writing tests
-Version:1.001006
+Version:1.001008
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -80,6 +80,10 @@ make test
%{_mandir}/man3/Test::Tutorial.3pm*
%changelog
+* Thu Oct 16 2014 Paul Howarth p...@city-fan.org - 1.001008-1
+- Update to 1.001008
+ - Fix subtest name when skip_all is used
+
* Tue Sep 9 2014 Paul Howarth p...@city-fan.org - 1.001006-1
- Update to 1.001006
- Documentation updates
diff --git a/sources b/sources
index ed54bd9..15ccffc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-581ac4d2d7ace1f56409bc112e8ad02c Test-Simple-1.001006.tar.gz
+17c7705c15430c0d7a81575113f22ac6 Test-Simple-1.001008.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-Test-Simple] Created tag perl-Test-Simple-1.001008-1.fc22
The lightweight tag 'perl-Test-Simple-1.001008-1.fc22' was created pointing to: 2bd015c... Update to 1.001008 -- 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-Test-Simple/f21] Update to 1.001008
Summary of changes: 2bd015c... Update to 1.001008 (*) (*) 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
[perl-Test-Simple] Created tag perl-Test-Simple-1.001008-1.fc21
The lightweight tag 'perl-Test-Simple-1.001008-1.fc21' was created pointing to: 2bd015c... Update to 1.001008 -- 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
Re: Announcing Tangerine
On Thu, Oct 16, 2014 at 11:02:09AM +0100, Paul Howarth wrote: A handy feature to have would be to be able to compare two directories (or better still, tarballs) and see where there are usage changes in any file, ignoring line numbers. That would help when doing package updates. Paul. I usually check the diff on metacpan.org (or just run tangerine Makefile.PL lib/ t/ if it's a long time neglected package) but I can see how this could be more comfortable. I'll think about it. Thanks for the suggestion. By the way, I released v0.10 yesterday: http://cpansearch.perl.org/src/CONTYK/Tangerine-0.10/Changes Fedora updates coming soon :) P pgpC5GBYMUIke.pgp Description: PGP signature -- 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 1147892] perl-Tangerine-0.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1147892 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Tangerine-0.05-1.fc20 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 07:43:39 -- 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=NevIVPX9zva=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
[PkgDB] limb updated perl-Net-Dropbox-API
user: limb created branch el6 on package perl-Net-Dropbox-API To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API approveacls set to Approved
user: limb set for cheeselee acl: approveacls of package: perl-Net-Dropbox-API from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API watchcommits set to Approved
user: limb set for cheeselee acl: watchcommits of package: perl-Net-Dropbox-API from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API watchcommits set to Approved
user: limb set for cheeselee acl: watchcommits of package: perl-Net-Dropbox-API from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API watchbugzilla set to Approved
user: limb set for cheeselee acl: watchbugzilla of package: perl-Net-Dropbox-API from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb updated perl-Net-Dropbox-API
user: limb created branch epel7 on package perl-Net-Dropbox-API To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API approveacls set to Approved
user: limb set for cheeselee acl: approveacls of package: perl-Net-Dropbox-API from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API commit set to Approved
user: limb set for cheeselee acl: commit of package: perl-Net-Dropbox-API from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-Net-Dropbox-API commit set to Approved
user: limb set for cheeselee acl: commit of package: perl-Net-Dropbox-API from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Dropbox-API -- 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
[PkgDB] limb:perl-X11-Protocol-Other watchcommits set to Approved
user: limb set for cheeselee acl: watchcommits of package: perl-X11-Protocol-Other from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other approveacls set to Approved
user: limb set for cheeselee acl: approveacls of package: perl-X11-Protocol-Other from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other commit set to Approved
user: limb set for cheeselee acl: commit of package: perl-X11-Protocol-Other from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other watchbugzilla set to Approved
user: limb set for cheeselee acl: watchbugzilla of package: perl-X11-Protocol-Other from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb updated perl-X11-Protocol-Other
user: limb created branch epel7 on package perl-X11-Protocol-Other To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other watchcommits set to Approved
user: limb set for cheeselee acl: watchcommits of package: perl-X11-Protocol-Other from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other approveacls set to Approved
user: limb set for cheeselee acl: approveacls of package: perl-X11-Protocol-Other from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other watchbugzilla set to Approved
user: limb set for cheeselee acl: watchbugzilla of package: perl-X11-Protocol-Other from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb:perl-X11-Protocol-Other commit set to Approved
user: limb set for cheeselee acl: commit of package: perl-X11-Protocol-Other from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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
[PkgDB] limb updated perl-X11-Protocol-Other
user: limb created branch el6 on package perl-X11-Protocol-Other To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-X11-Protocol-Other -- 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 1127475] Please update to upstream version = 0.24
https://bugzilla.redhat.com/show_bug.cgi?id=1127475 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Locale-PO-0.24-1.fc19 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:15:31 -- 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=mqKhf57nDOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1127474] Please update to upstream version = 0.24
https://bugzilla.redhat.com/show_bug.cgi?id=1127474 Bug 1127474 depends on bug 1127475, which changed state. Bug 1127475 Summary: Please update to upstream version = 0.24 https://bugzilla.redhat.com/show_bug.cgi?id=1127475 What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |CURRENTRELEASE -- 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=FpddOcBAISa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1138274] perl-Date-Manip-6.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1138274 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Date-Manip-6.47-1.fc19 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:16:37 -- 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=wJrifjMEaya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1136269] perl-Net-GitHub-0.68 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1136269 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Net-GitHub-0.68-1.fc20 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:15:54 -- 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=jvVSFr0UG9a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1138283] perl-XXX-0.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1138283 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-XXX-0.28-1.fc21 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:17:01 -- 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=75ZVxyl5jEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1142195] Update perl-POE in several branches
https://bugzilla.redhat.com/show_bug.cgi?id=1142195 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-POE-1.356-1.fc19 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:17:21 -- 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=g0No7SR8rxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1146465] perl-Inline-Struct-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1146465 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Inline-Struct-0.11-1.f ||c21 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:18:31 -- 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=pQy6vnfNfna=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1145013] perl-Inline-0.77 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1145013 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Inline-0.77-1.fc21 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:17:48 -- 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=GKiWzbOktka=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1145014] perl-Inline-C-0.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1145014 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Inline-C-0.64-1.fc21 Resolution|--- |CURRENTRELEASE Last Closed||2014-10-16 08:18:10 -- 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=rQ485fooIva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-SSL-2.000.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: cc45d249551032e09daa421ca59d5565 IO-Socket-SSL-2.000.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
