EPEL RHEL6 libgeotiff package missing
Hello, It seems like the libgeotiff package has been removed from the RHEL6 repository. We could not find any news on the subject. Does anyone know if the package has been removed intentionally? Our servers show the installed version to be as follows: Name: libgeotiff Arch: x86_64 Version : 1.2.5 Release : 5.el6 Size: 4.4 M Repo: installed From repo : epel Summary : GeoTIFF format library URL : http://www.remotesensing.org/geotiff/geotiff.html Currently we cannot install some software to our new servers due to the missing libgeotiff dependency. For example yum install gdal fails. Regards, Mika Heiskanen / FMI ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RHEL6 libgeotiff package missing
Hi, On Mon, Oct 06, 2014 at 10:24:30AM +0300, Mika Heiskanen wrote: It seems like the libgeotiff package has been removed from the RHEL6 repository. We could not find any news on the subject. Does anyone know if the package has been removed intentionally? the process to remove the package was started before May this year but it was not finished (the package was retired in packagedb: https://admin.fedoraproject.org/pkgdb/package/libgeotiff/) Before recently, a second step was required to actually remove the package from the repos. This is now automated, which is why the package is now not available via the mirrors. I do not know how retired the package, because it cannot be easily queried right now, but it might have been Orion, who built the package the last time. Our servers show the installed version to be as follows: Name: libgeotiff Arch: x86_64 Version : 1.2.5 Release : 5.el6 Currently we cannot install some software to our new servers due to the missing libgeotiff dependency. For example yum install gdal fails. You can still download the package from kojipkgs if it helps you now: https://kojipkgs.fedoraproject.org//packages/libgeotiff/1.2.5/5.el6/x86_64/libgeotiff-1.2.5-5.el6.x86_64.rpm However it is not maintained currently in EPEL 5 and 6. To get it back into EPEL 6 someone needs to step up as a new maintainer and ask for a re-review: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package Regards Till ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RHEL6 libgeotiff package missing
On 10/06/2014 10:39 AM, Till Maas wrote: Hi, On Mon, Oct 06, 2014 at 10:24:30AM +0300, Mika Heiskanen wrote: It seems like the libgeotiff package has been removed from the RHEL6 repository. We could not find any news on the subject. Does anyone know if the package has been removed intentionally? the process to remove the package was started before May this year but it was not finished (the package was retired in packagedb: https://admin.fedoraproject.org/pkgdb/package/libgeotiff/) Don't think it was me. CC'ing Volker and Devrim. -- 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 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL gfal2-plugin-xrootd 0.3 for EL5 EL6 ?
Hello, We would like to use a version of gfal2-plugin-xrootd built against xrootd 4 for EL5 and EL6. Does anyone know if there are plans to build and release version 0.3 (or 0.3.pre1) for EL5 EL6? (The version available in EL7 is built against xrootd 4, but EL5 EL6 are built against xrootd 3.) More details: It looks like the current version available in EPEL for EL5 EL6 is 0.2.2-2: http://koji.fedoraproject.org/koji/buildinfo?buildID=420560 http://koji.fedoraproject.org/koji/buildinfo?buildID=420579 from May 2013. Since this version was built against xrootd 3, we're not able to install it along with xrootd 4. Also, attempting to rebuild this version (0.2.2-2) fails both against the latest version of gfal2 and against xrootd 4. But I see that there is a newer version 0.3.pre1-2 available for EL7: https://bugzilla.redhat.com/show_bug.cgi?id=1140171 http://koji.fedoraproject.org/koji/buildinfo?buildID=576482 It looks like this version addresses the build issues and we can rebuild it in EL5 EL6 against the latest gfal2 and xrootd 4. I'm wondering if there are plans for EPEL to update to release the new version of gfal2-plugin-xrootd in EL5 EL6 also (so we can get it directly from EPEL). And if not, is this something EPEL would consider? Thanks! Carl ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Dash as default shell
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto: It used to give significant boost for automake libtool based software - however at some point libtool started to use bashisms and so you cannot just replace /bin/sh - dash - as build will fail. This is wrong. libtool detects whether you can use bashisms, and falls back to POSIX shell constructs if it cannot use them. The non-POSIX constructs are usually faster because they do not need to fork() the shell. Autoconf does the same. dash rejects some of these constructs, and accept others. Before Autoconf started doing this, dash was indeed quite a bit faster than bash on configure scripts. So your estimate of 50% is valid for projects on which Autoconf has last been run 7-8 years ago. Paolo -- 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: Dash as default shell
Il 04/10/2014 18:17, Zdenek Kabelac ha scritto: And yes - with UsrMove we lost distinction between what are system tools and what are usr tools. What you call system tools is simply the content of the initramfs. Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Activity Day - 1st Nov 2014 - theme security
Hello all, See - https://fedoraproject.org/wiki/FAD_Pune_Security_1 Date: Say, 1st Nov 2014 Venue: Red Hat Inc. Tower-10, Magarpatta City, Near Hadapsar, Pune, India. On 1st Nov 2014, we plan to host a Fedora Activity Day(FAD) geared towards triaging security bugs in Fedora. The day would start with a brief introduction to Fedora Security and progress towards collective bug triaging. If you are in Pune or plan to be here on 1st Nov, please feel free to drop in and join the action. :) Please note:- we have limited capacity(=~25) to accommodate participants. ...see you there! :) --- Regards -Prasad http://feedmug.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: Dash as default shell
Dne 6.10.2014 v 08:21 Paolo Bonzini napsal(a): Il 04/10/2014 18:17, Zdenek Kabelac ha scritto: And yes - with UsrMove we lost distinction between what are system tools and what are usr tools. What you call system tools is simply the content of the initramfs. Paolo Close - but not exactly. initramfs needs to have only those tool to mount root volume. So while my system could have richer set of tools, not all of those are necessary to bring up the system. Anyway the main idea is - these basic system tools could happily live with 'dash' as in /bin/sh - while the users may enjoy bash shell. Often invocation of sh being bash is just expensive - and it's even more then that when such shell is purely used to reexec some other command. Of course I'm fully aware people are not going to change their habits, and don't care about that at all - and just always expect bash Zdenek -- 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: Dash as default shell
Dne 6.10.2014 v 08:06 Paolo Bonzini napsal(a): Il 02/10/2014 11:04, Zdenek Kabelac ha scritto: It used to give significant boost for automake libtool based software - however at some point libtool started to use bashisms and so you cannot just replace /bin/sh - dash - as build will fail. This is wrong. libtool detects whether you can use bashisms, and falls back to POSIX shell constructs if it cannot use them. The non-POSIX constructs are usually faster because they do not need to fork() the shell. Autoconf does the same. dash rejects some of these constructs, and accept others. Before Autoconf started doing this, dash was indeed quite a bit faster than bash on configure scripts. So your estimate of 50% is valid for projects on which Autoconf has last been run 7-8 years ago. Well all I can say is autoconf (at least on my rawhide) doesn't work with dash for quite some time. So yes - I admit my numbers are dated. But purely because I cannot revalidate them Zdenek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to handle upgrades to Fedora 21
On 10/01/2014 10:28 PM, Stephen Gallagher wrote: Fedora officially only supports upgrades from a*fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this I tried the upgrade during weekend. And I tried to simulate this requires during upgrade. The problem is that once you get fedora-release-standard, you will get other *-standard (e.g. firewalld-config-standard) and there is no way to switch -workstation (or other product) unless you use 'rpm --nodeps', which is pretty dirty hack. If you use this Requires, then at the same time please provide users migration tool product2product. Or at least standard2product. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to handle upgrades to Fedora 21
On 10/03/2014 10:57 PM, Stephen Gallagher wrote: To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. For those rebels who use fedora-upgrade(8): this script now ask you right after distro-sync, which product you want to choose or if you want to stay on -standard version. Available since fedora-upgrade-21.2-1.fc20 Enjoy and report problems -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to handle upgrades to Fedora 21
Hi On Mon, Oct 6, 2014 at 3:18 AM, Miroslav Suchý msu...@redhat.com wrote: I tried the upgrade during weekend. And I tried to simulate this requires during upgrade. The problem is that once you get fedora-release-standard, you will get other *-standard (e.g. firewalld-config-standard) and there is no way to switch -workstation (or other product) unless you use 'rpm --nodeps', which is pretty dirty hack. No. You can use yum swap or dnf --allowerasing 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
Updates and AutoQA
Hi I was pushing out updates for deluge for F20 and F19 and when I tried to push to stable, AutoQA figured out what this was breaking the upgrade path since I had forgotten to do a push for F21. So far so good however, the message is a bit misleading https://admin.fedoraproject.org/updates/FEDORA-2014-11788/deluge-1.3.7-1.fc20 Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test. The push was not automatic. I was doing it manually. Moreover after I had submitted a F21 build, it wasn't clear from the message that I was supposed to revoke the request inorder to resubmit again. Also wouldn't it be better to run the autoqa checks when the update was being pushed to testing and provide me a quick warning instead of waiting til I push to stable? 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: dnf vs yum
W dniu 04.10.2014 o 18:32, Matthew Miller pisze: I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper. Too bad that it does not also say that it provides yum ;( 09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock Error: package mock-1.1.41-3.fc22.noarch requires yum = 2.4, but none of the providers can be installed -- 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: dnf vs yum
Hi On Mon, Oct 6, 2014 at 3:52 AM, Marcin Juszkiewicz wrote: Too bad that it does not also say that it provides yum ;( 09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock Error: package mock-1.1.41-3.fc22.noarch requires yum = 2.4, but none of the providers can be installed Because it doesn't provide yum. It only provides a command line api. Tools that depend on the yum API including mock won't work with dnf-yum. They actually need to be ported over just like yumex-dnf has. 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
No more deltarpms by default
Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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: Dash as default shell
On 10/06/2014 08:57 AM, Zdenek Kabelac wrote: Well all I can say is autoconf (at least on my rawhide) doesn't work with dash for quite some time. Care to share more details? Could be a dash bug, could be an autoconf bug, could be a local configuration breakage, could be something else. 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: Dash as default shell
On Sat, Oct 4, 2014 at 8:37 AM, Panu Matilainen pmati...@laiskiainen.org wrote: I'm sure rpmlint can (be made to) check for bashisms... https://sourceforge.net/p/rpmlint/tickets/39/ -- 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
Hello All! 2014-10-06 12:41 GMT+04:00 Rahul Sundaram methe...@gmail.com: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this At last! -- With best regards, Peter Lemenkov. -- 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 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retiring OpenShift v2 non-client packages from Fedora
On 10/03/2014 10:51 PM, Haïkel wrote: 2014-10-03 22:30 GMT+02:00 Stephen Gallagher sgall...@redhat.com: On Fri, 2014-10-03 at 21:43 +0200, Haïkel wrote: This makes sense to me, though it annoys me as a token of our failure to be an attractive platform for such use cases. DId you consider providing a copr repository ? A COPR repository probably wouldn't work, because they'd have to provide a conflicting version of the ruby platform. I doubt that would fly. They *could* stick a private copy of ruby in a non-standard location and use it, but that's an awful lot of work for uncertain gain. * I'm not an OpenShift dev In this case, I was thinking about using an SCL. Just asking, not forcing a burden upon anyone.m I guess, this is where the work from EnvStack WG will be critical to ensure that Fedora remains a viable platform for services developers (not only OpenShift). H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Well, yes, we were trying... I'm currently running rebuilds of RHSCL also for Fedora, but there are some differences in buildroots, so it will take some time. Also I don't think it will be easy to attract those who already left for CentOS back to Fedora. Marcela -- 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 Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 The amount of time taken to rebuild rpms from delta rpms meant that they didn't seem to save anything for me. I had always assumed that this is because the rebuilding code was written in Python. In fact this is not so! Although the yum-presto plugin is written in Python, it just calls out to the applydeltarpm program written in C (assuming I'm looking at the right place: https://gitorious.org/deltarpm/deltarpm). Has anyone analyzed why the rebuild step is slow? Seems like the best thing to do would be to make it faster if possible. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
Am 06.10.2014 um 13:00 schrieb Richard W.M. Jones: On Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote: One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 The amount of time taken to rebuild rpms from delta rpms meant that they didn't seem to save anything for me. I had always assumed that this is because the rebuilding code was written in Python. In fact this is not so! Although the yum-presto plugin is written in Python, it just calls out to the applydeltarpm program written in C (assuming I'm looking at the right place: https://gitorious.org/deltarpm/deltarpm). Has anyone analyzed why the rebuild step is slow? Seems like the best thing to do would be to make it faster if possible because it needs to build the complete xz-compressed RPM there was a discussion here not that long ago signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141006 changes
Compose started at Mon Oct 6 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 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [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 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gdb-heap] gdb-heap-0.5-18.fc21.armv7hl requires glibc(armv7hl-32) = 0:2.19.90 [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
rawhide report: 20141006 changes
Compose started at Mon Oct 6 05:15:04 UTC 2014 Broken deps for i386 -- [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 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [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 [gnustep-back] gnustep-back-0.23.0-5.fc21.i686 requires libgnustep-gui.so.0.23 [gnustep-examples] gnustep-examples-1.3.0-19.fc20.i686 requires libgnustep-gui.so.0.23 [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 [hledger] ghc-hledger-0.19.3-5.fc22.i686 requires
Re: [Base] Base Design WG agenda meeting 03 October 2014 15:00 UTC on #fedora-meeting
Dennis, how can I help you to figure out image publishing process? Let me know if I can be any help, we should definitely move forward on this and it probably doesn't make sense vote until you say we have a workflow how to ship the image. Vašek On 3.10.2014 08:56, Václav Pavlín wrote: Hi I will be traveling to Prague in the afternoon so I'd suggest to cancel this meeting as 2 members are not going to be there and I my bus might get delay. Vašek On 3.10.2014 02:57, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 02 Oct 2014 18:28:40 +0200 Phil Knirsch pknir...@redhat.com wrote: Unfortunately tomorrow is a public holiday in Germany, but if someone else from the WG would run the meeting i've put together a proposed agenda for tomorrow to give a few updates: Agenda: - Update buildrequires cleanup work (davids) - Update Alpha base image - Open Floor Thanks regards, Phil I will be missing the meeting due to being on PTO Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJULfRzAAoJEH7ltONmPFDRB7kQAKkrlI37MubsAPVtpgHl8riB +kzk4owFeyxRMOwhEahRWDNAPOj9GA2gB53DjE9sWfTrlBfgIQxK+vjrOGCUfkaJ hvPRVOTp1yrpchea6FnR7H8ZWD1HEcFgTt8ffpCHegnWJCfGlRgE4Ac1FZ75DicC wPx3z9iSzYTMNei13QgDFjsUyVROI7BDT0eQAuCGAqoJ5waGhoNzIuGf7HiNYpi5 VhYUuHXrOWRGBf8rRnxo94MLZWJKuLCd0mGNklMnZoA7eyJ1fxclfAEUf4NBFc7/ mfpK1zpQRiHkfsQSfZFOghTNOepWCWxKlLJIC2aYEbWDSQFTyzyigX8cm6tflfzi pBGuukHq/SNhcBtrnnNCKLGfB4T2kzPr3ph52urqqcKlDOLXTJ16nD2GdDmMdG8F ija2QmhZBEHO5b99J/b74iTgGmbrA+5XPrCF2c0hD6YG+CIcxI0e+uie6Y2e2zsC AoJnOf94eavkEWCJhIzKOhieLBo/pZ0JfwAuvR//euf52tUlaAvE2/aEehY5Ezb+ PaZ8fKgH71BST/r3exNKKv7BOWkQkcyBXeFhOkPuaToEOX17UoHisJdDrdxx/tAk AeZAAGvJSYeEt57HzObCbeS/OEZ+cCfnJu4s+zmuSiXImWkbyYV04xLTmLxzE+oP NvsU1+XAno8as7nylz5U =DLam -END PGP SIGNATURE- -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: btrfs as default filesystem for F22?
On 10/05/2014 08:25 PM, Josh Boyer wrote: On Sun, Oct 5, 2014 at 3:03 PM, Gene Czarcinski gczarcin...@gmail.com wrote: On 10/05/2014 09:50 AM, Josef Bacik wrote: On Oct 2, 2014 11:32 PM, Andre Robatino robat...@fedoraproject.org wrote: openSUSE 13.2, scheduled for release in November, will have btrfs as the default filesystem. What are the chances that F22 will follow suit, assuming openSUSE has no major problems with it? https://news.opensuse.org/2014/09/22/ My plan is to push for F23, I'm still wrapping up some balance bugs and some other issues we've found at work and then this will be my next priority. Suse benefits from having a narrow supported criteria, like only use it with lots of space and don't use any of the RAID stuff, plus they have two kernel guys on it and Dave Sterba who is now in charge of btrfs-progs. Fedora unfortunately has me who has Facebook work to do and Eric who is a professional fs juggler. We will get there, and when we do it will be less painful than its going to be for Suse since they will have fixed it all for us ;). Thanks, F23 sounds about right to me. I am very much a fan of BTRFS and currently use it on all of my systems with few problems but I think that F22 is a bit early to make it the default. However, I do believe that there a couple of things that need to happen to make thjings easier/better: 1. The Fedora developers/maintainers need to take BTRFS more seriously and address btrfs related problems seriously and quickly. Yes, I know that BTRFS swap draining is a little bit difficult to deal with when you are up to you rear end in alligators but, a little more attension please. Nope. See, we deal with what we think we can deal with and what is impacting the most people. There are two of us. A non-default filesystem with a lot of known issues isn't high on the priority list. If you would like to see more attention on btrfs, find some people that share your interest to triage and work on the bugs (which are all upstream bugs) or chip in yourself. Nope, I understand. However, what I said is with the understanding to change to using BTRFS as the default ... whenever it takes place and I stand by my statement of needing more attention as a requirement. 2. Currently anaconda supports supports installation of /boot on BTRFS either as a simple directory on a BTRFS volume (yes, I don't understand why someone would do this but ...), as a simple directory on a rootfs (/) subvolume, or as a spepate subvolume. Grub2.02 also supports this and grubby will support if real soon now when pjones can get enough time to examine and integrate my grubby patches adding BTRFS support. This isn't a requirement for btrfs by default. It's a nice to have. Using btrfs by default needs more users to want to use it. Making it easier for more users to install into btrfs will see increased use. It will also demonstrate that Fedora development/maintenance is paying attention to BTRFS. Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Anyway, we are getting close. If it's getting close, it's entirely because of Josef's and the SuSE team's efforts. They should be applauded. Yes, they should! But Fedora moving to increased use of BTRFS seems to be receding at the speed of time: it is always a couple of releases from now; go away I am busy with other stuff. Sorry is this bothers some people but that is the impression I get. Gene -- 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: btrfs as default filesystem for F22?
On 10/06/2014 02:29 PM, Gene Czarcinski wrote: Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Let me answer from the position of a mere user. It's not clear to me why and when users should switch to BTRFS or xfs or else, nor am I not interested in using anything which would potentially endanger existing installations (So far, reports I am reading from openSUSE users don't necessarily sound convincing). In other words, you'd have to do a lot of marketing and convincing work to persuade users to use BTRFS/xfs etc. 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: btrfs as default filesystem for F22?
On Mon, Oct 6, 2014 at 8:29 AM, Gene Czarcinski gczarcin...@gmail.com wrote: On 10/05/2014 08:25 PM, Josh Boyer wrote: On Sun, Oct 5, 2014 at 3:03 PM, Gene Czarcinski gczarcin...@gmail.com wrote: On 10/05/2014 09:50 AM, Josef Bacik wrote: On Oct 2, 2014 11:32 PM, Andre Robatino robat...@fedoraproject.org wrote: openSUSE 13.2, scheduled for release in November, will have btrfs as the default filesystem. What are the chances that F22 will follow suit, assuming openSUSE has no major problems with it? https://news.opensuse.org/2014/09/22/ My plan is to push for F23, I'm still wrapping up some balance bugs and some other issues we've found at work and then this will be my next priority. Suse benefits from having a narrow supported criteria, like only use it with lots of space and don't use any of the RAID stuff, plus they have two kernel guys on it and Dave Sterba who is now in charge of btrfs-progs. Fedora unfortunately has me who has Facebook work to do and Eric who is a professional fs juggler. We will get there, and when we do it will be less painful than its going to be for Suse since they will have fixed it all for us ;). Thanks, F23 sounds about right to me. I am very much a fan of BTRFS and currently use it on all of my systems with few problems but I think that F22 is a bit early to make it the default. However, I do believe that there a couple of things that need to happen to make thjings easier/better: 1. The Fedora developers/maintainers need to take BTRFS more seriously and address btrfs related problems seriously and quickly. Yes, I know that BTRFS swap draining is a little bit difficult to deal with when you are up to you rear end in alligators but, a little more attension please. Nope. See, we deal with what we think we can deal with and what is impacting the most people. There are two of us. A non-default filesystem with a lot of known issues isn't high on the priority list. If you would like to see more attention on btrfs, find some people that share your interest to triage and work on the bugs (which are all upstream bugs) or chip in yourself. Nope, I understand. However, what I said is with the understanding to change to using BTRFS as the default ... whenever it takes place and I stand by my statement of needing more attention as a requirement. The attention needed is a prerequisite for it to even remotely be considered for default. I'm explaining the people working on the kernel aren't staffed to give that attention, so if people would like btrfs to be the default filesystem in Fedora they need to start working on it now. 2. Currently anaconda supports supports installation of /boot on BTRFS either as a simple directory on a BTRFS volume (yes, I don't understand why someone would do this but ...), as a simple directory on a rootfs (/) subvolume, or as a spepate subvolume. Grub2.02 also supports this and grubby will support if real soon now when pjones can get enough time to examine and integrate my grubby patches adding BTRFS support. This isn't a requirement for btrfs by default. It's a nice to have. Using btrfs by default needs more users to want to use it. Making it easier for more users to install into btrfs will see increased use. It will also demonstrate that Fedora development/maintenance is paying attention to BTRFS. Um... sure? Except nobody cares if /boot is btrfs or not. It's a nicety that results in btrfs being the main fs in use for the system, but it isn't a requirement. You can use it for the rootfs and for home just fine without /boot being btrfs. (It's also somewhat of a pipe dream, given that the EFI system partition is never going to be btrfs and that's another mountpoint under /boot.) Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Depends. There is no single grand unified plan for Fedora filesystems. Believe me, if there was that would be amazing. Workstation would like to use btrfs for a number of nice desktop technologies (like easy backups, time slider, etc). It's not ready, so WS stuck with the existing default of ext4. We discussed (briefly) following SuSE's approach and limiting the features possible with btrfs, but after discussing with Josef we decided to forego that as well. There are alternatives that could be used (like dm snapshots) but the userspace work wasn't going to happen for F21 in any case. Cloud uses ext4. I don't believe they have any benefit to switching to any other filesystem so it doesn't matter to them. Server already switched to using XFS as the default fs, which makes sense given that RHEL 7 defaults to XFS. I believe
Re: btrfs as default filesystem for F22?
On Oct 6, 2014 8:29 AM, Gene Czarcinski gczarcin...@gmail.com wrote: On 10/05/2014 08:25 PM, Josh Boyer wrote: On Sun, Oct 5, 2014 at 3:03 PM, Gene Czarcinski gczarcin...@gmail.com wrote: On 10/05/2014 09:50 AM, Josef Bacik wrote: On Oct 2, 2014 11:32 PM, Andre Robatino robat...@fedoraproject.org wrote: openSUSE 13.2, scheduled for release in November, will have btrfs as the default filesystem. What are the chances that F22 will follow suit, assuming openSUSE has no major problems with it? https://news.opensuse.org/2014/09/22/ My plan is to push for F23, I'm still wrapping up some balance bugs and some other issues we've found at work and then this will be my next priority. Suse benefits from having a narrow supported criteria, like only use it with lots of space and don't use any of the RAID stuff, plus they have two kernel guys on it and Dave Sterba who is now in charge of btrfs-progs. Fedora unfortunately has me who has Facebook work to do and Eric who is a professional fs juggler. We will get there, and when we do it will be less painful than its going to be for Suse since they will have fixed it all for us ;). Thanks, F23 sounds about right to me. I am very much a fan of BTRFS and currently use it on all of my systems with few problems but I think that F22 is a bit early to make it the default. However, I do believe that there a couple of things that need to happen to make thjings easier/better: 1. The Fedora developers/maintainers need to take BTRFS more seriously and address btrfs related problems seriously and quickly. Yes, I know that BTRFS swap draining is a little bit difficult to deal with when you are up to you rear end in alligators but, a little more attension please. Nope. See, we deal with what we think we can deal with and what is impacting the most people. There are two of us. A non-default filesystem with a lot of known issues isn't high on the priority list. If you would like to see more attention on btrfs, find some people that share your interest to triage and work on the bugs (which are all upstream bugs) or chip in yourself. Nope, I understand. However, what I said is with the understanding to change to using BTRFS as the default ... whenever it takes place and I stand by my statement of needing more attention as a requirement. 2. Currently anaconda supports supports installation of /boot on BTRFS either as a simple directory on a BTRFS volume (yes, I don't understand why someone would do this but ...), as a simple directory on a rootfs (/) subvolume, or as a spepate subvolume. Grub2.02 also supports this and grubby will support if real soon now when pjones can get enough time to examine and integrate my grubby patches adding BTRFS support. This isn't a requirement for btrfs by default. It's a nice to have. Using btrfs by default needs more users to want to use it. Making it easier for more users to install into btrfs will see increased use. It will also demonstrate that Fedora development/maintenance is paying attention to BTRFS. Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Anyway, we are getting close. If it's getting close, it's entirely because of Josef's and the SuSE team's efforts. They should be applauded. Yes, they should! But Fedora moving to increased use of BTRFS seems to be receding at the speed of time: it is always a couple of releases from now; go away I am busy with other stuff. Sorry is this bothers some people but that is the impression I get. Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef -- 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 Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). 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: How to handle upgrades to Fedora 21
On Sat, 2014-10-04 at 12:46 -0400, Mike Pinkerton wrote: On 3 Oct 2014, at 19:37, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant The nonstandard and noncompliant names seem a bit pejorative. However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk. Rehashing the conversation elsewhere, the problem with DIY and similar is that it doesn't make much sense in the context of Spins, which are non-productized but not particularly do-it-yourself. Perhaps we should have just gone with 'fedora-release-nonproduct' like I originally suggested months ago... Anyway, I don't really care what we pick, so long as it's decided in the next 24 hours so we can deal with the Obsoletes hoops and make sure it gets pushed out and into a test compose. 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: fedora-review: 'Illegal return' warnings
On 10/05/2014 05:15 PM, Florian Weimer wrote: On 10/04/2014 10:18 PM, Alec Leamas wrote: Hm seems that recent bash patch to fix the shellshock problem introduces this. Fedora-review relies on exported shell functions (export -f) and the bash fix changes the syntax for exported functions in an incompatible way. It's the attempt at cleaning up the environment, see /usr/share/fedora-review/plugins/shell_api.py: unset $(env | sed -n 's/=.*//p') With exported functions, that was fairly broken before (with multi-line function definitions and “=” somewhere in the body), but after the bash change, this is much more obvious and is even triggered by the exported function in the environment-modules package. It would have been preferable to clean the environment either in the Python code, or wrap the shell invocation with “env -i”. And indeed this had already been reported as a bug, completely unrelated to exported functions: https://bugzilla.redhat.com/show_bug.cgi?id=1085761 -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 2 packages were orphaned libvmime07 [master] was orphaned by robert A powerful C++ class library for working with MIME/Internet messages https://admin.fedoraproject.org/pkgdb/package/libvmime07 unicap [el5] was orphaned by robert Library to access different kinds of (video) capture devices https://admin.fedoraproject.org/pkgdb/package/unicap 21 packages were retired - LibRaw [epel7] was retired by limb Library for reading RAW files obtained from digital photo cameras https://admin.fedoraproject.org/pkgdb/package/LibRaw askbot [f21] was retired by till Question and Answer forum https://admin.fedoraproject.org/pkgdb/package/askbot globus-core [f21, master] was retired by ellert Globus Toolkit - Globus Core https://admin.fedoraproject.org/pkgdb/package/globus-core globus-rls-client [master, f21, el6, epel7, el5] was retired by ellert Globus Toolkit - Replica Location Service Client https://admin.fedoraproject.org/pkgdb/package/globus-rls-client globus-rls-server [master, f21, el6, epel7, el5] was retired by ellert Globus Toolkit - Replica Location Service Server https://admin.fedoraproject.org/pkgdb/package/globus-rls-server grid-packaging-tools [f21, master] was retired by ellert Grid Packaging Tools (GPT) https://admin.fedoraproject.org/pkgdb/package/grid-packaging-tools openshift-origin-broker [master] was retired by tdawson OpenShift Origin broker components https://admin.fedoraproject.org/pkgdb/package/openshift-origin-broker openshift-origin-broker-util [master] was retired by tdawson Utility scripts for the OpenShift Origin broker https://admin.fedoraproject.org/pkgdb/package/openshift-origin-broker-util openshift-origin-cartridge-cron [master] was retired by tdawson Embedded cron support for OpenShift https://admin.fedoraproject.org/pkgdb/package/openshift-origin-cartridge-cron openshift-origin-cartridge-diy [master] was retired by tdawson DIY OpenShift cartridge https://admin.fedoraproject.org/pkgdb/package/openshift-origin-cartridge-diy openshift-origin-cartridge-mongodb [master] was retired by tdawson Embedded mongodb support for OpenShift https://admin.fedoraproject.org/pkgdb/package/openshift-origin-cartridge-mongodb openshift-origin-cartridge-mysql [master] was retired by tdawson Embedded mysql support for OpenShift https://admin.fedoraproject.org/pkgdb/package/openshift-origin-cartridge-mysql openshift-origin-msg-common [master] was retired by tdawson Common msg components for OpenShift https://admin.fedoraproject.org/pkgdb/package/openshift-origin-msg-common openshift-origin-node-proxy [master] was retired by tdawson Routing proxy for OpenShift Origin Node https://admin.fedoraproject.org/pkgdb/package/openshift-origin-node-proxy openshift-origin-node-util [master] was retired by tdawson Utility scripts for the OpenShift Origin node https://admin.fedoraproject.org/pkgdb/package/openshift-origin-node-util openshift-origin-util [master] was retired by tdawson Utility scripts for the OpenShift Origin https://admin.fedoraproject.org/pkgdb/package/openshift-origin-util pam_openshift [master] was retired by tdawson Openshift PAM module https://admin.fedoraproject.org/pkgdb/package/pam_openshift python-gevent [epel7] was retired by till Coroutine-based Python networking library https://admin.fedoraproject.org/pkgdb/package/python-gevent rubygem-openshift-origin-auth-remote-user [master] was retired by tdawson OpenShift plugin for remote-user authentication https://admin.fedoraproject.org/pkgdb/package/rubygem-openshift-origin-auth-remote-user rubygem-openshift-origin-dns-nsupdate [master] was retired by tdawson Provides a DNS service update plugin using nsupdate https://admin.fedoraproject.org/pkgdb/package/rubygem-openshift-origin-dns-nsupdate rubygem-passenger [master] was retired by wakko666 Phusion Passenger? is an application server for Ruby on Rails https://admin.fedoraproject.org/pkgdb/package/rubygem-passenger 2 packages unorphaned - jbrout [master] was unorphaned by pingou Photo manager, written in python/pygtk https://admin.fedoraproject.org/pkgdb/package/jbrout python-sqlalchemy [epel7] was unorphaned by pingou Modular and flexible ORM library for python https://admin.fedoraproject.org/pkgdb/package/python-sqlalchemy 0 packages were unretired 11 packages were given - diskimage-builder [master, f21, f19, el6, f20] was given by jpeeler to slagle Image building tools for OpenStack https://admin.fedoraproject.org/pkgdb/package/diskimage-builder gzip [f21, f19, master, f20] was given by mluscon to pstodulk The
Re: fedora-review: 'Illegal return' warnings
On 2014-10-06 15:16, Florian Weimer wrote: On 10/05/2014 05:15 PM, Florian Weimer wrote: On 10/04/2014 10:18 PM, Alec Leamas wrote: Hm seems that recent bash patch to fix the shellshock problem introduces this. Fedora-review relies on exported shell functions (export -f) and the bash fix changes the syntax for exported functions in an incompatible way. It's the attempt at cleaning up the environment, see /usr/share/fedora-review/plugins/shell_api.py: unset $(env | sed -n 's/=.*//p') With exported functions, that was fairly broken before (with multi-line function definitions and “=” somewhere in the body), but after the bash change, this is much more obvious and is even triggered by the exported function in the environment-modules package. It would have been preferable to clean the environment either in the Python code, or wrap the shell invocation with “env -i”. And indeed this had already been reported as a bug, completely unrelated to exported functions: https://bugzilla.redhat.com/show_bug.cgi?id=1085761 blushes I shall try to have a look at this. MIght take some time, though. --alec -- 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 Mon, Oct 06, 2014 at 12:00:04PM +0100, Richard W.M. Jones wrote: The amount of time taken to rebuild rpms from delta rpms meant that they didn't seem to save anything for me. It's not about saving *time*; it's about reducing the amount of data sent over the wire -- this is particularly important when you have a slow/congested (and/or metered) internet connection. Personally, I leave deltarpms on unless I have a local repo mirror. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpF9Y005QRiT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
On Mon, Oct 6, 2014 at 3:07 PM, Stephen Gallagher sgall...@redhat.com wrote: On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel s/massively parallel/not done at all/ ... but we had this discussion each time this comes up. There is no point in compressing something just to uncompress it a few minutes later. -- 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
Hi, It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel s/massively parallel/not done at all/ ... but we had this discussion each time this comes up. There is no point in compressing something just to uncompress it a few minutes later. IIRC the problem is that the _compressed_ rpm is signed, so things go compress - check sig - uncompress and you can't cut the compress +uncompress without also cutting the signature check :( cheers, Gerd -- 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: btrfs as default filesystem for F22?
On 10/06/2014 08:54 AM, Josef Bacik wrote: Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef I think that the out of space issues are not that different from any file system on write enabled snapshots - it certainly can be mysterious and confuse users, but that is something that we have to deal with in order to get this kind of sophistication into end users hands (documentation? better tooling like the snapper tool, etc?). One of the harder challenges I think for btrfs is still getting the repair tools rock solid - how is our track record these days with repairing btrfs after bad things happen :) ? Regards, Ric -- 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 Mon, Oct 6, 2014 at 3:48 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel s/massively parallel/not done at all/ ... but we had this discussion each time this comes up. There is no point in compressing something just to uncompress it a few minutes later. IIRC the problem is that the _compressed_ rpm is signed, so things go compress - check sig - uncompress and you can't cut the compress +uncompress without also cutting the signature check :( Is the payload actually signed? The conclusion from the last discussion was that only the header is signed (which in turn contains the checksums of the files). -- 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: btrfs as default filesystem for F22?
On 10/6/14 8:50 AM, Ric Wheeler wrote: On 10/06/2014 08:54 AM, Josef Bacik wrote: Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef I think that the out of space issues are not that different from any file system on write enabled snapshots - it certainly can be mysterious and confuse users, but that is something that we have to deal with in order to get this kind of sophistication into end users hands (documentation? better tooling like the snapper tool, etc?). One of the harder challenges I think for btrfs is still getting the repair tools rock solid - how is our track record these days with repairing btrfs after bad things happen :) ? In my recent (past couple weeks) testing, it's dismal, although a bunch of fsck patches have shown up on the list which I haven't tried yet. Doing what I considered to be light fuzzing of a filesystem, and attempting a btrfsck mount led to segfaults, aborts, and mount failures the vast majority of the time - more or less often, depending on the particular metadata layout. Other filesystems fared much better in this testing. And the best-practice repair strategy with btrfs is still not clear to me; there is btrfs check (aka btrfsck) of course, with various suboptions the admin should know about: init-csum-tree, init-extent-tree, backup, subvol-extents; several of these are not documented ... and also mount options: -o degraded, -o recovery, -o skip_balance. And other tools; btrfs rescue, with various suboptions - super-recovery, chunk-recover. There's btrfs scrub, which will work online and Errors are corrected along the way if possible. and btrfs-rescue, a last-ditch effort to extract files from the smoking remains of an otherwise unrescuable filesystem. It may be that I'm just not up to speed on btrfs - I've realized that I can't be an in-depth expert on 3 different filesystems - but to me, the filesystem repair and recovery plan for btrfs is not at all reliable or obvious or clear. (I need to send this same post to the btrfs-list, I guess, but I did want to point out that it is, to me, a big concern for Fedora decision-making. btrfs was first proposed as default in F17, 3 years ago, and ISTR reliable fsck being a gating item back then. And now here we are...) Thanks, -Eric -- 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: btrfs as default filesystem for F22?
On Mon, Oct 6, 2014 at 9:50 AM, Ric Wheeler rwhee...@redhat.com wrote: On 10/06/2014 08:54 AM, Josef Bacik wrote: Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef I think that the out of space issues are not that different from any file system on write enabled snapshots - it certainly can be mysterious and confuse users, but that is something that we have to deal with in order to get this kind of sophistication into end users hands (documentation? better tooling like the snapper tool, etc?). One of the harder challenges I think for btrfs is still getting the repair tools rock solid - how is our track record these days with repairing btrfs after bad things happen :) ? Funny you should ask, I just added a bunch of functionality last week! So right now our fsck fixes anything wrong in the extent tree, which is where a majority of the problems happen. The other side of course is the fs tree which is infinitely easier to deal with, but I usually wait for a user with a broken fs to fix before adding the ability to fix it into fsck so I'm sure we have a good testcase to work against. Every fix I add to fsck gets a test image added to btrfs-progs to make sure we're never regressing. Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of the problems and then the other 10% are just a matter of having an example to work off of. Thanks, Josef -- 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: btrfs as default filesystem for F22?
On 10/6/14 7:45 AM, Ralf Corsepius wrote: On 10/06/2014 02:29 PM, Gene Czarcinski wrote: Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Let me answer from the position of a mere user. It's not clear to me why and when users should switch to BTRFS or xfs or else, nor am I not interested in using anything which would potentially endanger existing installations (So far, reports I am reading from openSUSE users don't necessarily sound convincing). In other words, you'd have to do a lot of marketing and convincing work to persuade users to use BTRFS/xfs etc. Ralf I think this is an important point. To make a fundamental change like this, the rationale and benefits need to be very clearly spelled out, and not just chase the new hotness (although 6-7 years in, I'm not sure btrfs can be called new? XFS certainly can't!) ;) IOWs, I'd like to see much more than because it can do snapshots and checksums as the rationale; there are most definitely interesting things that btrfs can do (or is working on doing), but as btrfs has evolved, so has the rest of the Linux storage ecosystem: DM thin provisioning, xfs and ext4 metadata checksums, System Storage Manager (SSM) aiming for administration ease, etc. It's up to those proposing a new default to clearly spell out the compelling advantage to the change. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-10-07)
WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston, 22:00 Tokyo) in #fedora-meeting on Freenode. = Topics = * FollowUp: mapping CVEs to Docker images that need rebuilding * Docker Documentation for Fedora * Idea: Ability to define dependencies between coprs (correctly) * Picking chairman for the next meeting * OpenFloor -- 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
- Original Message - On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. This is a good point but even in developing countries internet access is getting better and better. A few years ago installation DVD was the only way how to access Fedora repo. It's not requested anymore. But yeah, I do not live there. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). One idea - could we do some measurements in presto code? Aka remember download speed for drpms, then try to rebuild a few drpms and compare speed. If internet connection is significantly faster, offer full rpms re-download. If not, continue with rebuild. I don't have really fast net connection, just VDSL limited to 16 mbit due to distance from DSLAM but still using older netbook - the first thing I had to do, was to disable drpms. Same my wife's laptop - any bigger update means she can't really work. That's one option. And I agree delta rpms optimization would be great first step. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Dash as default shell
On 6 October 2014 00:06, Paolo Bonzini pbonz...@redhat.com wrote: Il 02/10/2014 11:04, Zdenek Kabelac ha scritto: It used to give significant boost for automake libtool based software - however at some point libtool started to use bashisms and so you cannot just replace /bin/sh - dash - as build will fail. This is wrong. libtool detects whether you can use bashisms, and falls back to POSIX shell constructs if it cannot use them. The non-POSIX constructs are usually faster because they do not need to fork() the shell. Autoconf does the same. dash rejects some of these constructs, and accept others. Actually this might be the most important item in the whole conversation about moving to dash. If dash excepts some bashisms and not others... it isn't a 'default posix' shell and we really need someone to audit it and not expect that just because XYZ project uses it.. that they audited it. [And no this isn't a I want to keep bash as root shell argument, I don't really care what the default exec is as much as it is audited and secure. While it is clear that bash hasn't been that iwth only one maintainer.. I have no idea about dash and I am not sure who does.] -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
On Mon, Oct 6, 2014 at 4:46 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 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. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. This is a good point but even in developing countries internet access is getting better and better. A few years ago installation DVD was the only way how to access Fedora repo. It's not requested anymore. But yeah, I do not live there. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). One idea - could we do some measurements in presto code? Aka remember download speed for drpms, then try to rebuild a few drpms and compare speed. If internet connection is significantly faster, offer full rpms re-download. If not, continue with rebuild. I don't have really fast net connection, just VDSL limited to 16 mbit due to distance from DSLAM but still using older netbook - the first thing I had to do, was to disable drpms. Same my wife's laptop - any bigger update means she can't really work. That's one option. And I agree delta rpms optimization would be great first step. I am not convinced that being fast and download less are mutually exclusive when using deltas. So we should keep deltas *and* make them faster. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to handle upgrades to Fedora 21
Stephen Gallagher (sgall...@redhat.com) said: Rehashing the conversation elsewhere, the problem with DIY and similar is that it doesn't make much sense in the context of Spins, which are non-productized but not particularly do-it-yourself. While they're not DIY in the context of the initial install, they're not going to get the 'always get the latest version of the $PRODUCT features' that fedup and the assocated infrastructure may enforce for actual products (unless I missed something?). This means that they're likely to have more and more drift from the initial spin as time goes on, leaving them in a more custom state. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
On Mon, Oct 6, 2014 at 8:00 AM, drago01 drag...@gmail.com wrote: I am not convinced that being fast and download less are mutually exclusive when using deltas. So we should keep deltas *and* make them faster. Exactly. The fact that some users have more bandwidth means exactly what? Most people also have faster processors and disks now. It is more efficient from a networking perspective to minimize unnecessary traffic and use local processing. That was behind the rationale when delta was introduced and made the default. It was valid then, and it is valid now. You don't change the default without following the proper process. -- 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 Mon, 06 Oct 2014 09:07:33 -0400 Stephen Gallagher sgall...@redhat.com wrote: The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). I don't recall this ever being a reason. (I could be wrong). I think this actually is worse for mirrors in some ways. They have to mirror a bunch more files and take up space (which is very dear to mirrors). It does get them less BW used, but most mirrors are on big links and don't really notice. It's definitely worse for releng. Generating drpms takes a long time and delays things like updates pushes or composes. It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). Folks wanting to do so are welcome to help out... Get to coding. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: btrfs as default filesystem for F22?
On 10/6/14 9:26 AM, Josef Bacik wrote: Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of the problems and then the other 10% are just a matter of having an example to work off of. Thanks, Josef Josef, just as a datapoint: after corrupting 32k random bytes on a 2G image lightly populated and made with default mkfs options, then running fsck with all of your recent fixes, I got 9 mount failures out of 20 attempts, 55% success. Running the same test, but w/ 2 devices, each randomly damaged to the same extent, and created with -m raid1 -d raid0, I get 10 failures out of 20, 50% success. (Note that this is just a low-bar will it mount test, I'm not looking at what's in the repaired filesystem at all). What sort of testing yielded your 90% success rate? Thanks, -Eric -- 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: Dash as default shell
- Original Message - On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote: Is it worth considering using Dash as the default (non-interactive) shell in Fedora? Other distributions including Ubuntu and Debian (https://lwn.net/Articles/343924/) have been using dash as the default shell and Android uses mksh. While this appears to have been done primary to increase bootup efficiency (which is not relevant with systemd), it might help with security More bashism's in .spec files: + pushd src /tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found All the other things aside, I think it'd be fine for us to leave bash as the shell for spec file scripts even if we changed /bin/sh and/or the root shell. At that point switching anything to dash can _only increase_, not reduce, the disk space needed, and is very likely to increase the total page cache usage/requirement as well. Bringing the benefits of supporting dash to… the satisfaction of pedantically using the POSIX /bin/sh path as frequently as possible? Mirek -- 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: btrfs as default filesystem for F22?
On Mon, Oct 6, 2014 at 11:52 AM, Eric Sandeen sand...@redhat.com wrote: On 10/6/14 9:26 AM, Josef Bacik wrote: Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of the problems and then the other 10% are just a matter of having an example to work off of. Thanks, Josef Josef, just as a datapoint: after corrupting 32k random bytes on a 2G image lightly populated and made with default mkfs options, then running fsck with all of your recent fixes, I got 9 mount failures out of 20 attempts, 55% success. Running the same test, but w/ 2 devices, each randomly damaged to the same extent, and created with -m raid1 -d raid0, I get 10 failures out of 20, 50% success. (Note that this is just a low-bar will it mount test, I'm not looking at what's in the repaired filesystem at all). What sort of testing yielded your 90% success rate? The 90% is just off the top of my head, I used to be doing lots of fsck work for users with corrupted fs, I do that a lot less now, so it seems like we're making progress. I have never done any fsfuzzer testing, I'll put that on the list. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[pkgdb] Call for beta-testers for group maintainership
Dear all, A long desired and awaited feature for pkgdb2 is the possibility to have FAS groups maintain packages. The idea is the following: - You have a FAS group - People are members of this group - This group can be given commit or even be made point of contact of packages on pkgdb - If the group has commit, members of the group will have commits (so you don't need anymore to ask for ACL in pkgdb, you can just ask to be added in the group in FAS). After some preliminary testing with positive results, I would like to call for more testers. Ideally, if we could get a few groups of not too many people (ie: not the perl-sig group) that would be good. The idea is to make sure that the process works well and that people in the group are getting the correct notifications about actions happening on the packages (git commit, bodhi update, koji builds...) which is of course harder to do on a group that involves many people and packages. I put together some instructions on the requirements and steps: http://pkgdb2.readthedocs.org/en/latest/groups.html Thanks for your attention, Best regards, Pierre On behalf of the Fedora Infrastructure team ___ 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: Dash as default shell
On 6 October 2014 16:57, Miloslav Trmač m...@redhat.com wrote: - Original Message - On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote: Is it worth considering using Dash as the default (non-interactive) shell in Fedora? Other distributions including Ubuntu and Debian (https://lwn.net/Articles/343924/) have been using dash as the default shell and Android uses mksh. While this appears to have been done primary to increase bootup efficiency (which is not relevant with systemd), it might help with security More bashism's in .spec files: + pushd src /tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found All the other things aside, I think it'd be fine for us to leave bash as the shell for spec file scripts even if we changed /bin/sh and/or the root shell. At that point switching anything to dash can _only increase_, not reduce, the disk space needed, and is very likely to increase the total page cache usage/requirement as well. Bringing the benefits of supporting dash to… the satisfaction of pedantically using the POSIX /bin/sh path as frequently as possible? Also known as portability, compatibility and transparency. Do we encourage people to turn compiler warnings off? -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dash as default shell
- Original Message - At that point switching anything to dash can _only increase_, not reduce, the disk space needed, and is very likely to increase the total page cache usage/requirement as well. Bringing the benefits of supporting dash to… the satisfaction of pedantically using the POSIX /bin/sh path as frequently as possible? Also known as portability, compatibility Upstreams can be interested in cross-distro portability and compatibility. I don’t see much benefit for Fedora and Fedora’s users. and transparency. Perhaps for changing the #! line; adding yet another programming language to the OS would make it more complex and thus _reduce_ transparency. Do we encourage people to turn compiler warnings off? No, but most compiler warnings are useful _for increasing quality noticeable to users of Fedora_. A warning about use of a bash construct when we are using bash doesn’t help us help users. Mirek -- 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
FWIW, I wrote and maintained yum-presto before it was integrated into yum. I've commented inline: On 10/06/2014 06:31 PM, Kevin Fenzi wrote: On Mon, 06 Oct 2014 09:07:33 -0400 Stephen Gallagher sgall...@redhat.com wrote: The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. When I wrote yum-presto it was for this reason. We were on a lousy link and I couldn't run a local mirror without deltarpms. Having said that, with download caps now being a thing in certain developed countries, this is no longer just a developing countries problem. 2) (Major) Deltarpms significantly (Kevin, can you comment with numbers?) reduces the load on the Fedora update servers and mirrors, thereby reducing hosting costs as well as increasing the efficiency of the available bandwidth (since smaller downloads mean you will be tying up the line for a shorter amount of time). I don't recall this ever being a reason. (I could be wrong). I think this actually is worse for mirrors in some ways. They have to mirror a bunch more files and take up space (which is very dear to mirrors). It does get them less BW used, but most mirrors are on big links and don't really notice. It's definitely worse for releng. Generating drpms takes a long time and delays things like updates pushes or composes. +1 It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). Folks wanting to do so are welcome to help out... Get to coding. ;) As mentioned elsewhere, the problem *is* signatures. yum (quite rightly) refuses to install an rpm whose signature doesn't match the one in the primary repodata. And I believe that the signature in the RPM is also over the whole compressed rpm. To make this work, we'd need to add an uncompressed signature for every package to the primary repodata as well as probably the rpms themselves. We have already written the code to have yum run applydeltarpm in parallel according to the number of processors on a system, but it remains a single-threaded application that spends most of its time recompressing the data. Finally, if we do want to stop using deltarpms by default, I think the easiest thing to do would be to set dnf to use deltarpms if deltarpm is not installed, remove the deltarpm requirement that dnf has, and remove deltarpm from default installs. Then upgrades don't get unexpected changes in behavior and new installs can be told that getting deltarpm support is as easy as dnf install deltarpm. Jonathan -- 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/06/2014 05:16 PM, Gerald B. Cox wrote: The fact that some users have more bandwidth means exactly what? Most people also have faster processors and disks now. It is more efficient from a networking perspective to minimize unnecessary traffic and use local processing. That was behind the rationale when delta was introduced and made the default. It was valid then, and it is valid now. This argument is not valid. While most parts of a computer got faster things are not growing at the same rate. So what might have made sense a few years ago might be completely useless now. One thing that makes deltarpm less useful nowadays are seek times in hard disks (although they are going away). They are still the same as in the nineties while the number of files have been growing. At the same time network bandwidth has been growing at a faster rate as everything else. So if you want to make an argument for deltarpm, please do so but do not try to convince us to buy into an outdated rational. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -- 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
Bandwidth may be growing faster, but it started way behind processing power. It hasn't caught up. The current definition from the FCC for broadband is 4Mb. They are working to increase it, but that hasn't happened. Carriers are looking for ways to throttle traffic. Your assumption that everyone has great amounts of bandwidth available is erroneous. You've also got it backwards. Deltarpm is the default. If you want to change it, you need to convince the Fedora community. On Mon, Oct 6, 2014 at 10:01 AM, Florian Festi ffe...@redhat.com wrote: On 10/06/2014 05:16 PM, Gerald B. Cox wrote: The fact that some users have more bandwidth means exactly what? Most people also have faster processors and disks now. It is more efficient from a networking perspective to minimize unnecessary traffic and use local processing. That was behind the rationale when delta was introduced and made the default. It was valid then, and it is valid now. This argument is not valid. While most parts of a computer got faster things are not growing at the same rate. So what might have made sense a few years ago might be completely useless now. One thing that makes deltarpm less useful nowadays are seek times in hard disks (although they are going away). They are still the same as in the nineties while the number of files have been growing. At the same time network bandwidth has been growing at a faster rate as everything else. So if you want to make an argument for deltarpm, please do so but do not try to convince us to buy into an outdated rational. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -- 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
because it needs to build the complete xz-compressed RPM there was a discussion here not that long ago Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or at least gzip -1. Or Rich can add new feature to his ultra-blazing-fast multi-core XZ decompressor. Compression :-) -- Later, Lukas #lzap Zapletal -- 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
Am 06.10.2014 um 19:18 schrieb Lukas Zapletal: because it needs to build the complete xz-compressed RPM there was a discussion here not that long ago Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or at least gzip -1. Or Rich can add new feature to his ultra-blazing-fast multi-core XZ decompressor. Compression :-) the last discussions suggested that the result needs to be *identical* to the full RPM downloaded for not break signatures for me the greatest thing about deltarpm is that finally you have a full RPM in /var/cache/yum and from there can populate your local caching repo and deploy to the other 10,20,50,100 machines which means finally you win on both sides: download/traffic and no other machine in the network needs to touch the internet or know about deltarpms signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
On Mon, Oct 6, 2014 at 7:01 PM, Florian Festi ffe...@redhat.com wrote: On 10/06/2014 05:16 PM, Gerald B. Cox wrote: The fact that some users have more bandwidth means exactly what? Most people also have faster processors and disks now. It is more efficient from a networking perspective to minimize unnecessary traffic and use local processing. That was behind the rationale when delta was introduced and made the default. It was valid then, and it is valid now. This argument is not valid. While most parts of a computer got faster things are not growing at the same rate. So what might have made sense a few years ago might be completely useless now. One thing that makes deltarpm less useful nowadays are seek times in hard disks (although they are going away). They are still the same as in the nineties while the number of files have been growing. No they aren't. Even on cheap SSDs there are at least one order of magnitude faster. -- 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
Ok I think the above thread explains it, the Jonathan's mail lists what would be needed and it looks like there are some blockers on the infra side. Disregard. -- Later, Lukas #lzap Zapletal -- 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/06/2014 06:53 PM, Jonathan Dieter wrote: Get to coding. ;) As mentioned elsewhere, the problem *is* signatures. yum (quite rightly) refuses to install an rpm whose signature doesn't match the one in the primary repodata. And I believe that the signature in the RPM is also over the whole compressed rpm. To make this work, we'd need to add an uncompressed signature for every package to the primary repodata as well as probably the rpms themselves. We have already written the code to have yum run applydeltarpm in parallel according to the number of processors on a system, but it remains a single-threaded application that spends most of its time recompressing the data. The way of getting around all this unnecessary computation is establishing trust via the deltarpm itself and giving up the idea of reconstructing the originally rpm as a prove of everything worked out just fine. To save even more time the delta would need to be applied directly on disk without creating an package at all. This would require a deeper integration with rpm and requires some tricky algorithms to make sure everything is ok in advance and won't blow up during the rpm transaction. So if anyone needs a hobby... Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to include fonts in Gnome Software?
Hello, I noticed Titillium typeface is unlisted in Gnome Software. How to include it? I tried to look at the documentation about the process but not available. Thank you, -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
Am 06.10.2014 um 19:45 schrieb Florian Festi: On 10/06/2014 06:53 PM, Jonathan Dieter wrote: Get to coding. ;) As mentioned elsewhere, the problem *is* signatures. yum (quite rightly) refuses to install an rpm whose signature doesn't match the one in the primary repodata. And I believe that the signature in the RPM is also over the whole compressed rpm. To make this work, we'd need to add an uncompressed signature for every package to the primary repodata as well as probably the rpms themselves. We have already written the code to have yum run applydeltarpm in parallel according to the number of processors on a system, but it remains a single-threaded application that spends most of its time recompressing the data. The way of getting around all this unnecessary computation is establishing trust via the deltarpm itself and giving up the idea of reconstructing the originally rpm as a prove of everything worked out just fine. To save even more time the delta would need to be applied directly on disk without creating an package at all. This would require a deeper integration with rpm and requires some tricky algorithms to make sure everything is ok in advance and won't blow up during the rpm transaction. So if anyone needs a hobby... oh no - don't tie all together for reasons which did not destory the world over years - it is a damned good design that the part dealing with rpm packages don't need to know anything aboutt delta rpms because the normal packages are created before that step don't break the unix-way of work the current behavior follows for no good reason and there is none - otherwise deltarpm would not have been default over years the way it works now signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.2 Released
Hi all, DNF 0.6.2 is released. See: http://dnf.baseurl.org/2014/10/05/dnf-0-6-2-released/ Honza -- 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: btrfs as default filesystem for F22?
On 10/06/2014 10:26 AM, Josef Bacik wrote: On Mon, Oct 6, 2014 at 9:50 AM, Ric Wheeler rwhee...@redhat.com wrote: On 10/06/2014 08:54 AM, Josef Bacik wrote: Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef I think that the out of space issues are not that different from any file system on write enabled snapshots - it certainly can be mysterious and confuse users, but that is something that we have to deal with in order to get this kind of sophistication into end users hands (documentation? better tooling like the snapper tool, etc?). One of the harder challenges I think for btrfs is still getting the repair tools rock solid - how is our track record these days with repairing btrfs after bad things happen :) ? Funny you should ask, I just added a bunch of functionality last week! So right now our fsck fixes anything wrong in the extent tree, which is where a majority of the problems happen. The other side of course is the fs tree which is infinitely easier to deal with, but I usually wait for a user with a broken fs to fix before adding the ability to fix it into fsck so I'm sure we have a good testcase to work against. Every fix I add to fsck gets a test image added to btrfs-progs to make sure we're never regressing. Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of the problems and then the other 10% are just a matter of having an example to work off of. Thanks, Josef One of the things that the GFS2 people have done really well in helping their repair tools is to keep an anonymized (file names randomized, data blocks skipped) set of corrupt file system metadata layouts around to use to verify the tools. Every time they hit a really nasty file system, they try to get this kind of dump so they can validate the tools... Adding in Bob who does most of this :) ric -- 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/06/2014 07:53 PM, Jonathan Dieter wrote: As mentioned elsewhere, the problem *is* signatures. yum (quite rightly) refuses to install an rpm whose signature doesn't match the one in the primary repodata. And I believe that the signature in the RPM is also over the whole compressed rpm. To make this work, we'd need to add an uncompressed signature for every package to the primary repodata as well as probably the rpms themselves. IIRC repodata doesn't carry signatures, it caries a (sha256) checksum of its own on the entire package. Rpm signatures are a different beast: there's (sha1) checksum and a signature on the header, plus rpm v3 checksum and signature on header + payload. rpm -K style signature checking is the only thing that looks at the header + payload checksum and signature, otherwise rpm only uses the checksum/signature on header, which of course then has checksums of the individual files. Rpm can (and usually does) ignore the payload signature, file-level checksums get checked anyway (that too *can* be disabled but...) However it still requires the input data to be compressed in the format specified in the header. So to avoid having to compress tons of data only to decompress it shortly afterwards, there would have to be a way to tell librpm to expect a different payload compression (or specifically, that the payload is not compressed). Shouldn't be rocket science. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to include fonts in Gnome Software?
On Mon, 2014-10-06 at 10:49 -0700, Luya Tshimbalanga wrote: Hello, I noticed Titillium typeface is unlisted in Gnome Software. How to include it? I tried to look at the documentation about the process but not available. Hey Luya, I see these fonts here: https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra/font and there is appdata for them in /usr/share/app-info/xml/ on my system, but for some reason they still don't show up in gnome-software. Kalev and I briefly looked into it, but couldn't quite figure it out. I'll ask Richard to take a look tomorrow (he's off today). -- 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/06/2014 08:57 PM, Reindl Harald wrote: Am 06.10.2014 um 19:45 schrieb Florian Festi: The way of getting around all this unnecessary computation is establishing trust via the deltarpm itself and giving up the idea of reconstructing the originally rpm as a prove of everything worked out just fine. To save even more time the delta would need to be applied directly on disk without creating an package at all. This would require a deeper integration with rpm and requires some tricky algorithms to make sure everything is ok in advance and won't blow up during the rpm transaction. So if anyone needs a hobby... oh no - don't tie all together for reasons which did not destory the world over years - it is a damned good design that the part dealing with rpm packages don't need to know anything aboutt delta rpms because the normal packages are created before that step don't break the unix-way of work the current behavior follows for no good reason and there is none - otherwise deltarpm would not have been default over years the way it works now Ok, granted, this sounds pretty scary. But if we give rpm the ability to upgrade an installed package with a deltarpm, it wouldn't take away deltarpm's ability to generate a full rpm from a deltarpm. And it does have the advantage of cutting right through the knot. We already store checksums of the deltarpms in prestodelta.xml, as well as in the deltarpm itself. Probably the biggest weakness would be the chance that something would change on-disk between the check stage and actual install stage. We'd have to evaluate whether it's worth making a temporary copy of the old data during the check stage and then applying the deltarpm to that. All of this would require a lot of buy-in from the rpm guys, though (Florian, you're one of them, right?). If I recall correctly, when we first looked at deltarpms, one of the selling points was that rpm didn't have to change at all. Jonathan -- 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: btrfs as default filesystem for F22?
On Mon, Oct 6, 2014 at 2:19 PM, Ric Wheeler rwhee...@redhat.com wrote: On 10/06/2014 10:26 AM, Josef Bacik wrote: On Mon, Oct 6, 2014 at 9:50 AM, Ric Wheeler rwhee...@redhat.com wrote: On 10/06/2014 08:54 AM, Josef Bacik wrote: Well that's exactly what it is, go away I'm busy with other stuff :). The fact is I'm the only one who can drive btrfs as the default filesystem feature in Fedora, and since I've left Red Hat that has become much less of an priority for me. But my other stuff is still mostly related to btrfs, so its not like this has just been abandoned, the focus has just shifted and I no longer feel like we need to be using btrfs as the default fs in Fedora to have a successful project, so it got moved down the priority list. It will happen, and when it happens it will be relatively painless because Suse will have worked out a lot of the distro esque kinks and us at Facebook will have worked out a lot of the at scale kinks. Thanks, Josef I think that the out of space issues are not that different from any file system on write enabled snapshots - it certainly can be mysterious and confuse users, but that is something that we have to deal with in order to get this kind of sophistication into end users hands (documentation? better tooling like the snapper tool, etc?). One of the harder challenges I think for btrfs is still getting the repair tools rock solid - how is our track record these days with repairing btrfs after bad things happen :) ? Funny you should ask, I just added a bunch of functionality last week! So right now our fsck fixes anything wrong in the extent tree, which is where a majority of the problems happen. The other side of course is the fs tree which is infinitely easier to deal with, but I usually wait for a user with a broken fs to fix before adding the ability to fix it into fsck so I'm sure we have a good testcase to work against. Every fix I add to fsck gets a test image added to btrfs-progs to make sure we're never regressing. Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of the problems and then the other 10% are just a matter of having an example to work off of. Thanks, Josef One of the things that the GFS2 people have done really well in helping their repair tools is to keep an anonymized (file names randomized, data blocks skipped) set of corrupt file system metadata layouts around to use to verify the tools. Every time they hit a really nasty file system, they try to get this kind of dump so they can validate the tools... Adding in Bob who does most of this :) Yup we have something similar, btrfs-image will pull all the metadata off of the fs and compress it and then I can replay it to have something to reproduce on. We have a sanitize option that will sanitize filenames and such if the user cares about that. I'm pretty happy with fsck at this point and it is really easy for me to fix it to fix whatever new corruption we've found, its everything else that's making me go prematurely bald (well ok maybe Liam is to blame for most of that too.) Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Introduction
Hi All Just wanted to introduce myself. I'm James smith aka Smittix I am a UK ambassador and thought I would try my hand at packaging. For my first package I have packaged up an icon theme so I could get used to the guidelines and best practices. I enjoyed this for my first venture and hope to do more soon. I am also in need of a sponsor :) Good to meet you all. Regards James Smith -- 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: btrfs as default filesystem for F22?
On 10/06/2014 08:45 AM, Ralf Corsepius wrote: Let me answer from the position of a mere user. It's not clear to me why and when users should switch to BTRFS or xfs or else, nor am I not interested in using anything which would potentially endanger existing installations (So far, reports I am reading from openSUSE users don't necessarily sound convincing). In other words, you'd have to do a lot of marketing and convincing work to persuade users to use BTRFS/xfs etc. +1. BTRFS as the default is not ready for Fedora 23. However, there are some things that could be done to make it easier for those of us who want to make it easier to install Fedora onto a btrfs filesystem. My point was that unless and until there is more support for BTRFS by members of the Fedora Project, btrfs cannot be made the default. That is, *IF* it makes sense to have it be the default. Gene -- 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: Intent to update libinfinity to 0.6.1 (soname bump)
On Thu, Oct 02, 2014 at 07:50:01AM -0500, Rex Dieter wrote: I can't find my test kdte-collaborative build, but don't let that stop you, I'll just make a fresh snapshot when needed. OK, I asked around and seems the consensus is that this is safe/ok for F21. kte-collaborative now needs to be updated in Rawhide. I forgot to build libqinfinity for F21, but it is building now. Btw. strigi is currently orphaned in all Fedora branches but seems to be a critical KDE dependency: https://admin.fedoraproject.org/pkgdb/package/strigi/ Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Possible PPC kernel bug on builders
I posted about this 5 days ago on ppc list [1], but have had no response. I tried to get some attention on #fedora-ppc today, also with no success. I am failing miserably to get the attention of any of the PPC folks, so I am trying email here to see if this will work. GCL is failing to build sometimes on ppc64/ppc64le. I have had both successful [2] and unsuccessful [3] builds. Both of those build logs contain lots of extra debugging junk I threw in so I could gather information on what is going on. Here's the critical part. The uname -a invocation I added at the top of %build always shows a 3.14 kernel when the build succeeds and always shows a 3.16 kernel when the build fails. I believe there is a bug in the 3.16 ppc64/ppc64le kernels on (some of?) the builders. The bug, whatever it is, is causing spurious mprotect() failures. If somebody can either confirm or deny that, I am very interested. I have not had this problem on any other architecture. Thank you. Footnotes: [1] https://lists.fedoraproject.org/pipermail/ppc/2014-October/003024.html [2] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2138082 [3] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2138060 -- 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: [pkgdb] Call for beta-testers for group maintainership
On Mon, Oct 6, 2014 at 12:04 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: Dear all, A long desired and awaited feature for pkgdb2 is the possibility to have FAS groups maintain packages. Hooray! Thanks for this, I'm going to start testing it with the robotics-sig FAS group and some of my packages. I put together some instructions on the requirements and steps: http://pkgdb2.readthedocs.org/en/latest/groups.html I followed the above instructions to update the FAS group, but I have a question about one of the requirements. The instructions say that the mailing list for the group needs to have a rhbz account. As far as I know bugzilla sends a confirmation email during the account creation process. This seems kind of iffy when the email address is for a public list: should I just create the account and try to be the first list subscriber to click the confirmation link? Or is there another way to create a bugzilla account for SIG mailing lists? Rich -- 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: Dash as default shell
On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote: - Original Message - At that point switching anything to dash can _only increase_, not reduce, the disk space needed, and is very likely to increase the total page cache usage/requirement as well. Bringing the benefits of supporting dash to… the satisfaction of pedantically using the POSIX /bin/sh path as frequently as possible? Also known as portability, compatibility Upstreams can be interested in cross-distro portability and compatibility. I don’t see much benefit for Fedora and Fedora’s users. Fedora is never upstream? Ever? What happened to all the discussions of remixes in Janurary for a start? And we're not interested in interoperability with other distros? Because Fedora-land is quite small compared to the whole picture. and transparency. Perhaps for changing the #! line; adding yet another programming language to the OS would make it more complex and thus _reduce_ transparency. Not another programming language, one that is already being used. Being explicit about it. Why be so resistant to that? Do we encourage people to turn compiler warnings off? No, but most compiler warnings are useful _for increasing quality noticeable to users of Fedora_. A warning about use of a bash construct when we are using bash doesn’t help us help users. Getting dependencies right isn't helpful? Lastly: http://en.wikipedia.org/wiki/Open_Build_Service Even the scripts that you might think are solely Fedora specific could be useful to other people. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: btrfs as default filesystem for F22?
On 2014-10-06, 14:30 GMT, Eric Sandeen wrote: IOWs, I'd like to see much more than because it can do snapshots and checksums as the rationale; there are most definitely interesting things that btrfs can do (or is working on doing), but as btrfs has evolved, so has the rest of the Linux storage ecosystem: DM thin provisioning, xfs and ext4 metadata checksums, System Storage Manager (SSM) aiming for administration ease, etc. So, would you say that the critical path for achieving Time Slider is on the GUI side now? I mean what is shown on http://www.youtube.com/watch?v=-pNh1n3seTg (I don't even know what language it is), and http://www.youtube.com/watch?v=kdjulcvhhuU (which is Spanish, I guess). Unfortunately, I cannot find any screencast of this in English or any other language I could actually comprehend. Matěj -- 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: btrfs as default filesystem for F22?
On 10/06/2014 10:30 AM, Eric Sandeen wrote: On 10/6/14 7:45 AM, Ralf Corsepius wrote: On 10/06/2014 02:29 PM, Gene Czarcinski wrote: Now, there is another question which has not been voiced: what is the plan for filessystems in Fedora (and by implication RHEL)? Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ago it was stated that the plan was to move to BTRFS. It is not clear to me that everyone is onboard with that decision. Or, perhaps that decision is being reconsidered. Let me answer from the position of a mere user. It's not clear to me why and when users should switch to BTRFS or xfs or else, nor am I not interested in using anything which would potentially endanger existing installations (So far, reports I am reading from openSUSE users don't necessarily sound convincing). In other words, you'd have to do a lot of marketing and convincing work to persuade users to use BTRFS/xfs etc. Ralf I think this is an important point. To make a fundamental change like this, the rationale and benefits need to be very clearly spelled out, and not just chase the new hotness (although 6-7 years in, I'm not sure btrfs can be called new? XFS certainly can't!) ;) IOWs, I'd like to see much more than because it can do snapshots and checksums as the rationale; there are most definitely interesting things that btrfs can do (or is working on doing), but as btrfs has evolved, so has the rest of the Linux storage ecosystem: DM thin provisioning, xfs and ext4 metadata checksums, System Storage Manager (SSM) aiming for administration ease, etc. It's up to those proposing a new default to clearly spell out the compelling advantage to the change. -Eric I see btrfs as doing a few things that currently cannot be done with device mapper + xfs/ext4: * full data and metadata data integrity checking * fine grained control for compression/encryption * ability to quickly reverse map from a block (and most interesting block level error) into something meaningful (file, metadata, etc) Things that btrfs does well include the ease of use and built in support for snapshots, but I think that device mapper and other user space projects have worked hard to provide some of that for the traditional file systems. Of course, all of these features need to be rock solid (and easy to repair) for production users. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Governance Proposal
As I hope most of you have heard by now the Fedora Board and many community members have been discussing changes to the Fedora governance model at its highest level. I think it is fair for me to say the primary motivation in doing this is to create a system of governance that includes a much more active leadership responsibility. While the proposal before the current Board today is still a work in progress, it is detailed enough now for the Board to decide whether to make the change. As you read the proposal understand that not every detail will be spelled out, those can be added over time. Try to focus on the bigger issues including the new composition of the body, the new decision making process, and the focus on helping drive the Fedora Project as a whole in a clear direction. The Board will be voting on this proposal over the next couple of days but I wanted to share the proposal as widely as possible before we finish. Please read the proposal here https://fedoraproject.org/wiki/MatthewMiller/council-draft and feel free to provide feedback on the board-discuss list or contact any current Board member directly. There will be a public vote on the proposal here https://fedorahosted.org/board/ticket/13 over the next couple of days. Please do not add any comments in this ticket. Thanks, John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf and yum. again.
Just check this First. # dnf update Dependencies resolved. Nothing to do. Second. # yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies SKIP Transaction Summary = Upgrade 2 Packages Total download size: 15 M Is this ok [y/d/N]: Exiting on user command What wrong with dnf? - Dmitrij -- 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: Updates and AutoQA
On Mon, 6 Oct 2014 03:49:26 -0400 Rahul Sundaram methe...@gmail.com wrote: Hi I was pushing out updates for deluge for F20 and F19 and when I tried to push to stable, AutoQA figured out what this was breaking the upgrade path since I had forgotten to do a push for F21. So far so good however, the message is a bit misleading https://admin.fedoraproject.org/updates/FEDORA-2014-11788/deluge-1.3.7-1.fc20 Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test. The push was not automatic. I was doing it manually. Moreover after I had submitted a F21 build, it wasn't clear from the message that I was supposed to revoke the request inorder to resubmit again. That's a bodhi thing, if you can think of a better way to word that then please submit a RFE there. Also wouldn't it be better to run the autoqa checks when the update was being pushed to testing and provide me a quick warning instead of waiting til I push to stable? That's something which has been discussed in the past and it was decided that running upgradepath on updates-testing was problematic to the point where it wasn't worth doing. https://fedorahosted.org/fesco/ticket/474 https://lists.fedorahosted.org/pipermail/autoqa-devel/2010-September/001189.html If there's a sane solution to the problem, it might be possible to start doing running upgradepath on updates-testing. However, we don't have any plans to start doing this. Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf and yum. again.
Hi, On Tue, Oct 7, 2014 at 8:31 AM, Dmitrij S. Kryzhevich kr...@land.ru wrote: Just check this First. # dnf update Dependencies resolved. Nothing to do. Second. # yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies SKIP Transaction Summary = Upgrade 2 Packages Total download size: 15 M Is this ok [y/d/N]: Exiting on user command What wrong with dnf? Its expected result since long time from dnf and has not changed its behaviour. Just read this http://dnf.readthedocs.org/en/latest/user_faq.html?highlight=faq#why-do-i-get-different-results-with-dnf-upgrade-vs-yum-update 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: Updates and AutoQA
Hi On Mon, Oct 6, 2014 at 11:04 PM, Tim Flink wrote: The push was not automatic. I was doing it manually. Moreover after I had submitted a F21 build, it wasn't clear from the message that I was supposed to revoke the request inorder to resubmit again. That's a bodhi thing, if you can think of a better way to word that then please submit a RFE there. Fair enough. Filed https://fedorahosted.org/bodhi/ticket/762 If there's a sane solution to the problem, it might be possible to start doing running upgradepath on updates-testing. However, we don't have any plans to start doing this. Is it possible to opt-in to get them? 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: dnf and yum. again.
Hi, On Tue, Oct 7, 2014 at 8:31 AM, Dmitrij S. Kryzhevich kr...@land.ru wrote: Just check this First. # dnf update Dependencies resolved. Nothing to do. Second. # yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies SKIP Transaction Summary = Upgrade 2 Packages Total download size: 15 M Is this ok [y/d/N]: Exiting on user command What wrong with dnf? Its expected result since long time from dnf and has not changed its behaviour. Just read this http://dnf.readthedocs.org/en/latest/user_faq.html?highlight=faq#why-do-i-get-different-results-with-dnf-upgrade-vs-yum-update Regards, Parag. Thanks, that is. It's not a bug it's a feature. Ok. -- Dmitrij -- 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: Updates and AutoQA
On Mon, 6 Oct 2014 23:17:52 -0400 Rahul Sundaram methe...@gmail.com wrote: snip If there's a sane solution to the problem, it might be possible to start doing running upgradepath on updates-testing. However, we don't have any plans to start doing this. Is it possible to opt-in to get them? Not really - we're not set up to even run upgradepath on updates-testing, much less run the check or send results out on a package-by-package basis. I'd honestly prefer to enable that for all packages if we go that route - if there's enough interest in something like that, we could look into doing it but given the complexity I don't think it would happen soon. Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1141390] Review Request: perl-DBIx-RunSQL - Run SQL commands from a file
https://bugzilla.redhat.com/show_bug.cgi?id=1141390 --- Comment #5 from David Dick dd...@cpan.org --- Okay, give me the new spec and SRPM file and i'll complete the review. -- 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=A77aq70DHEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-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
[Bug 1141486] Review Request: perl-enum - C-style enumerated types and bitmask flags in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1141486 David Dick dd...@cpan.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||dd...@cpan.org Assignee|nob...@fedoraproject.org|dd...@cpan.org Flags||fedora-review? -- 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=9vG9Ge2rU4a=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 1136340] perl-Qt-0.96.0-12.fc22: FTBFS with Perl 5.20
https://bugzilla.redhat.com/show_bug.cgi?id=1136340 --- Comment #8 from Petr Pisar ppi...@redhat.com --- There are two bugs in the perl-Qt. The first one relying on a removed function can be fixed by attached patch. The second one remaining is not working overloaded == operator. More specifically, using == for second time on a QPoint object throws an exception. I don't know if this is a bug in perl-Qt or Perl, but this is a bug which makes perl-Qt faulty and I agree with Ralf that package in this state should not be delivered by the Fedora. I recommend to perl-Qt's maintainer to ask KDE developers for a help because the code is currently maintained by them. The CPAN release is abandoned. KDE should release the code and perl-Qt maintainer should use that source instead. (However I believe that even current KDE's code does not work with perl 5.20.) -- 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=mwNhaBffKBa=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 1141486] Review Request: perl-enum - C-style enumerated types and bitmask flags in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1141486 David Dick dd...@cpan.org changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #1 from David Dick dd...@cpan.org --- License is correct Builds ok in rawhide http://koji.fedoraproject.org/koji/taskinfo?taskID=7779090 rpmlint only complains about irrelevant spelling errors Build and Runtime requires are correct Package APPROVED -- 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=zkwJNRpMnVa=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 1141486] Review Request: perl-enum - C-style enumerated types and bitmask flags in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1141486 Denis Fateyev de...@fateyev.com changed: What|Removed |Added Flags||fedora-cvs? --- Comment #2 from Denis Fateyev de...@fateyev.com --- Thanks for the review. New Package SCM Request === Package Name: perl-enum Short Description: C-style enumerated types and bitmask flags in Perl Owners: dfateyev Branches: f19 f20 f21 el5 el6 epel7 InitialCC: perl-sig -- 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=CDn5Z7R95ma=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
[389-devel] Please review: ticket 47918: result of dna_dn_is_shared_config is incorrectly used
https://fedorahosted.org/389/ticket/47918 https://fedorahosted.org/389/attachment/ticket/47918/0001-Ticket-47918-result-of-dna_dn_is_shared_config-is-in.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: python-sig in pkgdb2?
Le 6 oct. 2014 21:56, Thomas Spura toms...@fedoraproject.org a écrit : Hi all, there just was a request to test groups for pkgdb2 [1] and I thought it might be a good opportunity to maybe start sharing at least some core python packages among a few people. For instance, I maintain ipython and the dependency chain when other maintainers chose to orphan something I need for it (or ipython introduces a new dependency). Such packages are good candidates to be maintained by a group of people, so updates can be managed better and several people have an eye on them. What do others think about that? Who else would be interested in starting a common python-sig group in pkgdb2? I am. Greetings, Tom [1] https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001445.html ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: python-sig in pkgdb2?
I've stepped back from packaging for the most part but I think this is a great idea. When I was active I'd often find something to cleanup in python packaging for each release (pil = pillow; removing python-setuptools-devel). A python-sig group would definitely help with future cleanups like those. -Toshio On Oct 6, 2014 2:49 PM, Haïkel hgue...@fedoraproject.org wrote: Le 6 oct. 2014 21:56, Thomas Spura toms...@fedoraproject.org a écrit : Hi all, there just was a request to test groups for pkgdb2 [1] and I thought it might be a good opportunity to maybe start sharing at least some core python packages among a few people. For instance, I maintain ipython and the dependency chain when other maintainers chose to orphan something I need for it (or ipython introduces a new dependency). Such packages are good candidates to be maintained by a group of people, so updates can be managed better and several people have an eye on them. What do others think about that? Who else would be interested in starting a common python-sig group in pkgdb2? I am. Greetings, Tom [1] https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001445.html ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
