Re: can't submit updates for f22?

On 08/25/2015 12:03 PM, Jan Chaloupka wrote: Happened to me as well. How many times did you repeated 'fedpkg update' before it worked? For me it takes from 1 to 3 times before it works. I've repeated it enough times to establish -- per Albert Einstein -- that I'm probably insane; none of them

Re: can't submit updates for f22?

> % fedpkg update > /usr/lib/python2.7/site-packages/fedpkg/cli.py:169: DeprecationWarning: > Commands._hash_file is deprecated and will be removed eventually. > Please use Commands.lookasidecache.hash_file instead. > hash = self.cmd._hash_file('bodhi.template', 'sha1') > Creating a new updat

Re: can't submit updates for f22?

Happened to me as well. How many times did you repeated 'fedpkg update' before it worked? For me it takes from 1 to 3 times before it works. On 08/25/2015 06:38 AM, Kaleb KEITHLEY wrote: I must have missed some announcement? Submitting from an up to date f22 box I get: % fedpkg update /usr/li

can't submit updates for f22?

I must have missed some announcement? Submitting from an up to date f22 box I get: % fedpkg update /usr/lib/python2.7/site-packages/fedpkg/cli.py:169: DeprecationWarning: Commands._hash_file is deprecated and will be removed eventually. Please use Commands.lookasidecache.hash_file instead.

rawhide report: 20150824 changes

Compose started at Mon Aug 24 20:59:03 UTC 2015 Broken deps for i386 -- [ScientificPython] ScientificPython-2.8-20.fc22.i686 requires libmpi.so.1 [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:ud

Re: Self Introduction: Benjamin Roberts

On Tue, 2015-08-25 at 12:28 +1000, Benjamin George Roberts wrote: > Good Afternoon > > My name is Benjamin Roberts. I've recently made a package review > request (https://bugzilla.redhat.com/show_bug.cgi?id=1209809) and am > hoping to have the package accepted and acquire member sponsorship. > >

Re: Self Introduction: Benjamin Roberts

Good Afternoon My name is Benjamin Roberts. I've recently made a package review request (https://bugzilla.redhat.com/show_bug.cgi?id=1209809) and am hoping to have the package accepted and acquire member sponsorship. A quick introduction about myself: * I'm a 3rd year software engineering stud

Re: Packaging Graylog2/unpackaged jar dependencies

Il 25/08/2015 00:40, Kevin Kofler ha scritto: Mikolaj Izdebski wrote: Currently all dependencies must be packaged as RPMs and available in Fedora. some deps are still unavailable https://gil.fedorapeople.org/swagger-core-1.5.2-0.1.M1.fc20.src.rpm https://github.com/droolsjbpm/drools/ (work in

Re: Packaging Graylog2/unpackaged jar dependencies

Mikolaj Izdebski wrote: > Currently all dependencies must be packaged as RPMs and available in > Fedora. And yes, this means EVERY SINGLE jar MUST be built from source separately. Yes, we know this is not how Java developers work. But it is how Free Software works. Binary blobs are not acceptabl

Re: Firefox testing - offscreen surfaces and OMTC

Martin Stransky wrote: > If you mean OMTC by "this" then you're right - it works fine on nightly > because nightly is built with in-tree cairo. Fedora it built with system > cairo which causes crashes with OMTC enabled. First build which supports > in-tree cairo & Gtk3 is FF41. Yet another bundled

Re: Do you know how many 64-bit architectures Fedora has?

Hi, > If someone can > suggest a better way than how I'm doing it now, I'm all ears, because I hate > this patch[0]. I think the solution you came up with from this thread is okay as a downstream hack, but I think a better solution would be to get upstream to ask apt at built time where to put met

Re: Do you know how many 64-bit architectures Fedora has?

On Monday, August 24, 2015 09:18:16 AM Neal Gompa wrote: > On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz > ​Oh, yes! I was trying to find something like this all weekend for my Copr > for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on > 64-bit systems, but on 32-bit

Re: Fedora 23 Branched 20150823 compose check report

On Mon, 2015-08-24 at 14:53 -0400, Fedora compose checker wrote: > Missing expected images: > > Generic Boot x86_64 > Generic Boot i386 nirik has figured out what was causing pungi to fail for both Rawhide and Branched the last few days (a problem with loop devices on the builder). We'll either g

Fedora Rawhide 20150823 compose check report

Missing expected images: Generic Boot x86_64 Kde Live x86_64 Kde Disk armhfp Kde Live i386 Generic Boot i386 No images in this compose but not the previous. No images in the previous compose but not this. Failed openQA tests: ID: 642 Test: x86_64 workstation_live default_install -- Mail gene

Fedora 23 Branched 20150823 compose check report

Missing expected images: Generic Boot x86_64 Generic Boot i386 No images in this compose but not the previous. No images in the previous compose but not this. Failed openQA tests: ID: 643 Test: x86_64 workstation_live default_install -- Mail generated by check-compose: https://git.fedorahost

Re: Package repositories missing both a spec file and a dead.package file

On Mon, Aug 24, 2015 at 11:09 AM, Till Maas wrote: > On Fri, Aug 21, 2015 at 08:45:30PM +0200, Kevin Kofler wrote: > >> EPEL-only packages should have their devel branch (and any other Fedora >> branches if they were already created) properly retired including adding the >> dead.package file. It c

Re: Package repositories missing both a spec file and a dead.package file

On Fri, Aug 21, 2015 at 08:45:30PM +0200, Kevin Kofler wrote: > EPEL-only packages should have their devel branch (and any other Fedora > branches if they were already created) properly retired including adding the > dead.package file. It can say something like "EPEL-only package." EPEL-only pa

[POC-change] Fedora packages point of contact updates

Change in package status over the last 168 hours 5 packages were orphaned awstats [f23, f22, f21, master, el6, epel7] was orphaned by plautrba Advanced Web Statistics https://admin.fedoraproject.org/pkgdb/package/a

Re: Do you know how many 64-bit architectures Fedora has?

W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze: It would be worthwhile adding this to: https://fedoraproject.org/wiki/Packaging_tricks Added -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproj

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 10:31 AM, Reindl Harald wrote: > > Am 24.08.2015 um 16:27 schrieb Neal Gompa: > >> On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely > >wrote: >> >> On 24/08/15 10:06 -0400, Neal Gompa wrote: >> >> On Mon, Aug 24, 2015 at 9:41 AM, Jon

Re: Do you know how many 64-bit architectures Fedora has?

Am 24.08.2015 um 16:27 schrieb Neal Gompa: On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely mailto:jwak...@redhat.com>>wrote: On 24/08/15 10:06 -0400, Neal Gompa wrote: On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely mailto:jwak...@redhat.com>> wrote: Oops, t

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely wrote: > On 24/08/15 10:06 -0400, Neal Gompa wrote: > >> On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely >> wrote: >> >>> Oops, to keep the quotes it would be >>> >>> -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"' >>> >> >> ​Would that override th

Re: Do you know how many 64-bit architectures Fedora has?

On 24/08/15 10:06 -0400, Neal Gompa wrote: On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely wrote: Oops, to keep the quotes it would be -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"' ​Would that override the in-code #define statement?​ Yes, because the #define is guarded by: #ifndef STD_MET

Re: Do you know how many 64-bit architectures Fedora has?

On 24 August 2015 at 14:12, Marcin Juszkiewicz wrote: [snip] > Because there are lot of code like: > > %ifarch x86_64 ppc64 ia64 s390x sparc64 > USE_64=1 > %endif > > Where is should be: > > %if 0%{?__isa_bits} == 64 > USE_64=1 > %endif > > Which works since RHEL6 (from what I know). And it a

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely wrote: > On 24/08/15 14:39 +0100, Jonathan Wakely wrote: > >> On 24/08/15 09:31 -0400, Neal Gompa wrote: >> >>> ​Well, the problem is that ​the path to apt-methods is hardcoded in >>> reprepro itself. Thankfully, it's in a #define, but I don't know

Re: Do you know how many 64-bit architectures Fedora has?

On 24/08/15 14:39 +0100, Jonathan Wakely wrote: On 24/08/15 09:31 -0400, Neal Gompa wrote: ​Well, the problem is that ​the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit sys

Re: Do you know how many 64-bit architectures Fedora has?

W dniu 24.08.2015 o 15:31, Neal Gompa pisze: ​ Well, the problem is that ​the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. ​If someone can suggest a better way th

Re: Do you know how many 64-bit architectures Fedora has?

On 24/08/15 09:31 -0400, Neal Gompa wrote: ​Well, the problem is that ​the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. ​If someone can suggest a better way than h

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 9:26 AM, Marcin Juszkiewicz wrote: > W dniu 24.08.2015 o 15:18, Neal Gompa pisze: > >> ​ Oh, yes! I was trying to find something like this all weekend for my >> Copr for reprepro. I have to make a patch to access apt-methods in >> /usr/lib64 on 64-bit systems, but on 32-bi

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote: > > ​Oh, yes! I was trying to find something like this all weekend for my Copr > for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on > 64-bit systems, but on 32-bit systems it should remain /usr/lib. > > You just

Re: Do you know how many 64-bit architectures Fedora has?

W dniu 24.08.2015 o 15:18, Neal Gompa pisze: ​ Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib. You just made my day. ​ You know

Re: bodhi 2 now live

On 23/08/15 18:41 -0400, Neal Gompa wrote: On Sun, Aug 23, 2015 at 6:32 PM, Jonathan Wakely wrote: On 23/08/15 16:36 -0400, Rahul Sundaram wrote: Hi On Sun, Aug 23, 2015 at 4:23 PM, Kevin Kofler wrote: No, sorry, but that is not true. I wrote those update notes in the Bodhi 1 web interfac

Re: Do you know how many 64-bit architectures Fedora has?

On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz wrote: > Hi > > During last few days I fetched over 26 thousand of Fedora package > repositories. Plan to go though all spec files and submit some patches > mainly related to my aarch64 work. > > We live in a world where most of Linux systems ar

Do you know how many 64-bit architectures Fedora has?

Hi During last few days I fetched over 26 thousand of Fedora package repositories. Plan to go though all spec files and submit some patches mainly related to my aarch64 work. We live in a world where most of Linux systems are either 32 or 64 bit. But do you know how many 64-bit architectures

Valgrind availability

Hi During last few days I fetched over 26 thousand of Fedora package repositories. Plan to go though all spec files and submit some patches mainly related to my aarch64 work. But there is one thing I want to note: %ifarch %{ix86} x86_64 BuildRequires: valgrind %endif Currently there is only

Re: Package repositories missing both a spec file and a dead.package file

Dne 21.8.2015 v 19:48 Viktor Jancik napsal(a): > Using an automated script I found 65 repositories that neither have a spec > file or a dead.package among Fedora package repositories on the master branch. > > Is this desired? Here is the list: > > > rubygem-amq-protocol Package was probably never

F-23 Branched report: 20150824 changes

Compose started at Mon Aug 24 07:15:03 UTC 2015 Broken deps for armhfp -- [QuantLib] QuantLib-test-1.6.1-1.fc23.armv7hl requires libboost_unit_test_framework.so.1.58.0 [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires

Re: Package repositories missing both a spec file and a dead.package file

Dne 21.8.2015 v 19:48 Viktor Jancik napsal(a): > Using an automated script I found 65 repositories that neither have a spec > file or a dead.package among Fedora package repositories on the master branch. > > Is this desired? Here is the list: > > > rubygem-amq-protocol This was never imported.

Broken dependencies: perl-Test-Vars

perl-Test-Vars has broken dependencies in the F-23 tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requir

Re: CMake cannot find some boost libraries on up to date F22 system

On Mon, 2015-08-24 at 11:21 +0100, Ankur Sinha wrote: > Would someone know what's happening here and how I can fix or work > around it please? It seems to be caused by the new cmake update in updates-testing[1]. Downgrading to 3.2.2-1 fixes the issue. I've left a negative karma. [1] https://bodhi

CMake cannot find some boost libraries on up to date F22 system

Hello, I'm trying to build a cmake project: auryn. The CMakeList.txt file[1], quite correctly has this line in it: > FIND_PACKAGE(Boost ${BOOST_MIN_VERSION} REQUIRED COMPONENTS mpi > serialization program_options date_time) but somehow, on both my systems, cmake cannot find the mentioned boost l

Re: Firefox testing - offscreen surfaces and OMTC

On 08/24/2015 10:41 AM, drago01 wrote: On Mon, Aug 24, 2015 at 10:18 AM, Martin Stransky wrote: On 08/24/2015 09:43 AM, drago01 wrote: On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky wrote: On 08/21/2015 08:28 PM, Thomas Daede wrote: I've been running nightly with this enabled for quit

Re: Firefox testing - offscreen surfaces and OMTC

On Mon, Aug 24, 2015 at 10:18 AM, Martin Stransky wrote: > On 08/24/2015 09:43 AM, drago01 wrote: >> >> On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky >> wrote: >>> >>> On 08/21/2015 08:28 PM, Thomas Daede wrote: I've been running nightly with this enabled for quite a while on In

Re: dnf doesn't check for rpmdb lock?

Hi Richard, DNF uses three types of locks (metadata, download and rpmdb lock) to allow more or less parallel execution of DNF commands. IIRC, the actual issue with kmods has been already resolved in upstream by switching rpmdb lock to blocking mode. Regards, Michal On 07/16/2015 05:20 PM,

Re: Firefox testing - offscreen surfaces and OMTC

On 08/24/2015 09:43 AM, drago01 wrote: On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky wrote: On 08/21/2015 08:28 PM, Thomas Daede wrote: I've been running nightly with this enabled for quite a while on Intel and it's been fine. Note that OMTC is required for e10s. If you mean OMTC by "t

Re: Firefox testing - offscreen surfaces and OMTC

On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky wrote: > On 08/21/2015 08:28 PM, Thomas Daede wrote: >> >> I've been running nightly with this enabled for quite a while on Intel >> and it's been fine. >> >> Note that OMTC is required for e10s. > > > If you mean OMTC by "this" then you're right -