Re: F21 downloads repository metadata in 3 places!
/*Samuel Sieb */ wrote on Sat, 13 Dec 2014 23:32:23 -0800: On 12/13/2014 01:10 PM, Hedayat Vatankhah wrote: Hi! I noticed that F21 can potentially download repository metadata 3 times: 1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see I'm not aware of the PackageKit cache, where is it? /var/cache/PackageKit I did accidentally discover about dnf recently on some F20 systems. I don't remember if it was network traffic or disk space that tipped me off, but I discovered that dnf was downloading stuff when I didn't even know it was installed. I immediately disabled it, but that does seem like rather unfriendly behaviour... I'd call it evil. Apparently, nobody around here cares. I think I should start thinking about my own "Fedora for Poor" product. Regards, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 downloads repository metadata in 3 places!
On Sunday, December 14, 2014 12:09:14 PM Hedayat Vatankhah wrote: > I'd call it evil. Apparently, nobody around here cares. I think I should > start thinking about my own "Fedora for Poor" product. It certainly affects me. Most decision are being made on two assumptions 1. people have fast and unlimited internet connections and 2. people have high RAM and multiple core CPU powerful computers. Both of these assumptions are arbitrarily at best. DNF regularly downloads cache, disables delta RPM support, and doesn't support local repos. Instead of implementing different profiles for different type of networks like wifi vs mobile we are throwing it out without people's consent. I am in favor of automation but it should be implemented when it's ready. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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
ssh problem with pkgs.fedoraproject.org
Hey, According to https://lists.fedoraproject.org/pipermail/devel/2014-June/199631.html disabling selinux should do the trick, in my case it didn't really help still getting: ssh bronh...@pkgs.fedoraproject.org -vvv OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /home/ybronhei/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 51: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to pkgs.fedoraproject.org [209.132.181.4] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/home/ybronhei/.ssh/id_rsa" as a RSA1 public key debug1: identity file /home/ybronhei/.ssh/id_rsa type 1 debug1: identity file /home/ybronhei/.ssh/id_rsa-cert type -1 debug1: identity file /home/ybronhei/.ssh/id_dsa type -1 debug1: identity file /home/ybronhei/.ssh/id_dsa-cert type -1 debug1: identity file /home/ybronhei/.ssh/id_ecdsa type -1 debug1: identity file /home/ybronhei/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.4 and when trying to clone a project fedpkg clone vdsm Cloning into 'vdsm'... ssh_exchange_identification: read: Connection reset by peer fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Command '['git', 'clone', 'ssh:// bronh...@pkgs.fedoraproject.org/vdsm', '--origin', 'origin']' returned non-zero exit status It worked few weeks ago.. and I updated my pk in my fas account.. its not permission failure, so any ideas what can is it ? Thanks Yaniv Bronhaim. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141214 changes
Compose started at Sun Dec 14 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.i686 requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [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 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.i686 requires libmarblewidget.so.19 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.i686 requires libmarblewidget.so.19 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.x86_64 requires libsword-1.7.3.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 pam_mapi-0.2.0-3.fc22.x86_64 requires libmapi.so.0()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bibletime] bibletime-2.10.1-4.fc22.armv7hl requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [gcc-python
Re: F21 downloads repository metadata in 3 places!
Hi On Sun, Dec 14, 2014 at 5:17 AM, Sudhir Khanger wrote: > > DNF > regularly downloads cache, disables delta RPM support, and doesn't support > local repos. > With the latest dnf update, Delta RPM support is enabled again. https://admin.fedoraproject.org/updates/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 As a general recommendation, always refer to specific bug reports when talking about issues 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: is it possible to skip a noarch subpackage on certains archs (arm)
On Sat, Dec 13, 2014 at 4:32 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Dec 13, 2014 at 10:00:00AM -0500, Nico Kadel-Garcia wrote: >> Would it be saner to make a separate SRPM that builds just the >> documentation, even if it uses the same source tarball? That way, >> minor version updates of the software would not force a rebuild of the >> documentation. > Yeah, but that's additional work for each update... and more chance to make > an error. I actually prefer for the build to be long. Yeah, it's a trade-off. There are tools where the documentation is bulky, or inappropriate for streamlined builds. "apr-api-docs" comes to mind as a good example. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 downloads repository metadata in 3 places!
Sudhir Khanger wrote: > Most decision are being made on two assumptions 1. people have fast and > unlimited internet connections and 2. people have high RAM and multiple > core CPU powerful computers. Both of these assumptions are arbitrarily at > best. DNF regularly downloads cache, disables delta RPM support, It's actually ENABLING DeltaRPM support (as the latest DNF update now does) that makes assumption 2. DeltaRPMs reduce download bandwidth consumption at the expense of a lot of CPU power. It's a tradeoff between 1. and 2. If you have 1. more than 2. (as is the case for me), then DeltaRPMs actually make your updates slower. If you have 2. more than 1., they make your updates faster. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On 12/13/2014 12:54 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Dec 12, 2014 at 09:38:52AM -0500, Bastien Nocera wrote: >> >> >> - Original Message - >>> On 12/12/2014 03:18 PM, Bastien Nocera wrote: - Original Message - > On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote: >>> > Agreed, a static library is a waste of time. What about a normal > shared library? Do you think patches to do that would be accepted? How does a shared library solve any of those problems? >>> I wonder why I have to explain this ;) >>> >>> It would concentrate/centralize a distributed, undetectable origin of >>> bug into one point of maintenance and development. >> >> It wouldn't solve the problem of not wanting to offer an API to >> third-parties... > Hi, > > I understand why upstream did not want to do that, but current > situation is not very attractive either. The same piece of library-like > code is duplicated in two places in gnome, in cinnamon, and we are talking > about duplicating in a fourth place. > > FPC wants to have it split out and shared. gvc has the last commmit in > git 13 months ago. Shouldn't be that much of an issue to split it out. > Having a static lib that goes against upstream's wishes, and that won't be used by the core GNOME applications anyway, seems rather anomalous as well. On the other hand, given that Cinnamon, Budgie, and other GNOME-related external projects are using this internal dependency anyway, I'd say the intent of not offering an API to third-parties has already failed... and not offering a *stable* API should be obvious enough by offering only a static lib. We could even add a README.Fedora file clearly stating that this library comes with no API stability guarantee. Seems that we should go back to the FPC, now that the objection from upstream (in some cases overlapping with Fedora package maintainers) is clear. At the very least, we need a decision on what to do with shared internal modules that are not intended to be used by external third parties - like libgd and libg-v-c, but I won't be surprised if there are others. - is the current practice acceptable, or (per last week's FPC decision) should the use of a static lib be required - once such a static lib is made available, is its use optional or mandatory for existing / new packages, and what's the timeline for requiring dependent packages to build against it - or should we have a two-tier policy, with, say, modules from the originating project allowed to pull in such dependencies via git submodules as per the current practice, but external modules required to use the static lib? With the latter, in the case that, say, individual GNOME modules need to be built against different commits of such a shared dependency, they still can, while we at least have centralized such dependency's usage by external projects. Best regards, - Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A IDs:keybase.io/michel-slm | IRC: michel_...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 downloads repository metadata in 3 places!
On Dec 14, 2014 10:12 PM, "Kevin Kofler" wrote: > > Sudhir Khanger wrote: > > Most decision are being made on two assumptions 1. people have fast and > > unlimited internet connections and 2. people have high RAM and multiple > > core CPU powerful computers. Both of these assumptions are arbitrarily at > > best. DNF regularly downloads cache, disables delta RPM support, > > It's actually ENABLING DeltaRPM support (as the latest DNF update now does) > that makes assumption 2. DeltaRPMs reduce download bandwidth consumption at > the expense of a lot of CPU power. It's a tradeoff between 1. and 2. If you > have 1. more than 2. (as is the case for me), then DeltaRPMs actually make > your updates slower. If you have 2. more than 1., they make your updates > faster. I don't know why the time to rebuild rpms is important, updates are now applied at boot time, so rpms can be rebuilt with smaller nice/ionice before the user reboots (on Workstation product). Meanwhile bandwidth cost money. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
