Re: polymake blocks system updates by strict Perl dependence

On Thu, 2017-01-26 at 01:51 +, Zbigniew Jędrzejewski-Szmek wrote: > > Thanks! > > There's another broken link on the https://taskotron.fedoraproject.org/ page: > "Development guide" → > https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest//docs/devguide.html. > (I tried to find t

Re: polymake blocks system updates by strict Perl dependence

On Thu, Jan 26, 2017 at 01:51:54AM +0100, Adam Williamson wrote: > On Wed, 2017-01-25 at 21:37 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > You generally need to root to create and run a chroot, so this is > > expected. > > > > > Could something like that be part of Bodhi? > > > > I had a l

Re: How to build both python 2 and 3 bindings from autotools?

On Thu, Jan 26, 2017 at 09:10:30AM +1000, Peter Hutterer wrote: > Before I start hacking up something nasty I figured it's better to ask: how > do I build both py2 and py3 bindings from a package using autotools (i.e. > AM_PATH_PYTHON)? > > So far my idea revolves around installing both python-de

Re: polymake blocks system updates by strict Perl dependence

On Wed, 2017-01-25 at 21:37 +, Zbigniew Jędrzejewski-Szmek wrote: > > You generally need to root to create and run a chroot, so this is > expected. > > > Could something like that be part of Bodhi? > > I had a look at the source code. piuparts.py [1] has a mishmash > of debian/ubuntu distro-

Re: How to build both python 2 and 3 bindings from autotools?

On 26/01/17 00:10, Peter Hutterer wrote: Before I start hacking up something nasty I figured it's better to ask: how do I build both py2 and py3 bindings from a package using autotools (i.e. AM_PATH_PYTHON)? So far my idea revolves around installing both python-devel packages and overriding PY

How to build both python 2 and 3 bindings from autotools?

Before I start hacking up something nasty I figured it's better to ask: how do I build both py2 and py3 bindings from a package using autotools (i.e. AM_PATH_PYTHON)? So far my idea revolves around installing both python-devel packages and overriding PYTHON in each %build , etc. But maybe there's

Re: polymake blocks system updates by strict Perl dependence

On Wed, Jan 25, 2017 at 03:39:50PM -0500, Przemek Klosowski wrote: > On 01/25/2017 01:22 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>My question is: is reporting them individually the best approach? I am > >>happy to keep doing it, but there's been more than the usual amount > >>recently, and I am w

Re: polymake blocks system updates by strict Perl dependence

On Wed, Jan 25, 2017 at 3:39 PM, Przemek Klosowski wrote: > On 01/25/2017 01:22 PM, Zbigniew Jędrzejewski-Szmek wrote: > > My question is: is reporting them individually the best approach? I am > happy to keep doing it, but there's been more than the usual amount > recently, and I am wondering if

Re: polymake blocks system updates by strict Perl dependence

On 01/25/2017 01:22 PM, Zbigniew Jędrzejewski-Szmek wrote: My question is: is reporting them individually the best approach? I am happy to keep doing it, but there's been more than the usual amount recently, and I am wondering if there's some automation that should be done to detect that in packa

Re: polymake blocks system updates by strict Perl dependence

On Wed, Jan 25, 2017 at 12:48:33PM -0500, Przemek Klosowski wrote: > Polymake blocks system updates by strict Perl dependence: > > polymake-3.0r2-1.fc25.x86_64 requires perl = 4:5.24.0 > > and the new perl package is tagged 4:5.24.1 > > This blocks upgrades for dependent packages (perl*, g

polymake blocks system updates by strict Perl dependence

Polymake blocks system updates by strict Perl dependence: polymake-3.0r2-1.fc25.x86_64 requires perl = 4:5.24.0 and the new perl package is tagged 4:5.24.1 This blocks upgrades for dependent packages (perl*, git*, vim*), while polymake can't just be bypassed because it is a dependency o

Re: Help Testing on armv7hl

Thanks for the responses. @Josh - I have only tested Local Build on F26 x86_64. I was talking about the scratch build passing on other architectures. @Kevin - I am a packager so access to a Test machine would be perfect! Thanks I will give one a try today. On Wed, Jan 25, 2017 at 11:39 AM, Kevi

Re: Help Testing on armv7hl

On Wed, 25 Jan 2017 10:59:21 -0500 Mike Miller wrote: > I have been testing package updates to Hadoop on a Fedora Rawhide AWS > VM. I am able to build locally on the Rawhide VM and scratch build > successfully on all architectures but ARMv7hl. I have no way to > debug/test on this architecture.

Re: Help Testing on armv7hl

On Wed, Jan 25, 2017 at 10:59 AM, Mike Miller wrote: > I have been testing package updates to Hadoop on a Fedora Rawhide AWS VM. I > am able to build locally on the Rawhide VM and scratch build successfully on > all architectures but ARMv7hl. I have no way to debug/test on this > architecture. W

Re: Help Testing on armv7hl

On Wed, Jan 25, 2017 at 3:59 PM, Mike Miller wrote: > I have been testing package updates to Hadoop on a Fedora Rawhide AWS VM. I > am able to build locally on the Rawhide VM and scratch build successfully on > all architectures but ARMv7hl. I have no way to debug/test on this > architecture. > >

Help Testing on armv7hl

I have been testing package updates to Hadoop on a Fedora Rawhide AWS VM. I am able to build locally on the Rawhide VM and scratch build successfully on all architectures but ARMv7hl. I have no way to debug/test on this architecture. Does anyone know of an AWS image for ARM? Any other tips for b

Re: %pre is a lie?

On Wed, Jan 25, 2017 at 9:42 AM, Stephen Gallagher wrote: > > See https://fedoraproject.org/wiki/Packaging:Directory_Replacement > > Replacing a directory with a symlink is a known limitation of RPM. The > workaround is there. Thanks for the tip! I did find the core problem though... The scrip

Re: %pre is a lie?

On 01/25/2017 04:31 PM, Richard Shaw wrote: > On Wed, Jan 25, 2017 at 9:18 AM, Dominik 'Rathann' Mierzejewski > mailto:domi...@greysector.net>> wrote: > > On Wednesday, 25 January 2017 at 15:52, Richard Shaw wrote: > [...] > > So it seems to me that %pre did not run. > > > > Am

Fedora Rawhide-20170125.n.0 compose check report

Missing expected images: Cloud_base qcow2 x86_64 Atomic qcow2 x86_64 Kde live x86_64 Cloud_base raw-xz x86_64 Xfce raw-xz armhfp Atomic raw-xz x86_64 Minimal raw-xz armhfp Kde live i386 Failed openQA tests: 14/96 (x86_64), 17/17 (i386) New failures (same test did not fail in Rawhide-20170120.n.0

Re: %pre is a lie?

On Wed, Jan 25, 2017 at 9:18 AM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Wednesday, 25 January 2017 at 15:52, Richard Shaw wrote: > [...] > > So it seems to me that %pre did not run. > > > > Am I missing something? > > I think it did run and RPM is complaining that fil

Re: %pre is a lie?

On Wednesday, 25 January 2017 at 15:52, Richard Shaw wrote: [...] > So it seems to me that %pre did not run. > > Am I missing something? I think it did run and RPM is complaining that files that are in %files are not there after unpacking the cpio payload. Try removing them from %files completely

%pre is a lie?

I'm working on creating a package for the UniFi controller software for Fedora/EL7. It has no chance of making it into Fedora but has been blessed by Ubiquity so for now it's packaged as an SRPM which the end user has to build to comply with their license restrictions. I recently found out it was

update to libmicrohttpd-0.9.52-1.fc24.x86_64 breaks openvas-gsa-6.0.11-3.fc24.x86_64

Hi, since the update to libmicrohttpd-0.9.52-1.fc24.x86_64 the log file /var/log/openvas/gsad.log of openvas-gsa prints the following error: gsad main:CRITICAL:2017-01-25 13h21.04 utc:2726: main: start_https_daemon failed! gsad main: DEBUG:2017-01-25 13h21.04 utc:2727: Received Terminated sign

Re: Koji build - unexpected keyword argument 'canfail'

On Wed, 25 Jan 2017 13:05:01 +0100 Dan Horák wrote: > On Tue, 24 Jan 2017 12:12:18 -0700 > Kevin Fenzi wrote: > > > On Tue, 24 Jan 2017 13:49:18 -0500 (EST) > > Charalampos Stratakis wrote: > > > > > Getting the same issue for gcc-python-plugin [0]. The scratch build > > > in koji (from my lo

REMINDER: Submission deadline for System Wide Changes of Fedora 26 in less than a week

Hi everyone! The submission deadline for System Wide Changes of Fedora 26 [1] is coming pretty soon - in less than a week on January 31st. Alpha release of Fedora 26 is planned then on March 14th. Please, submit your System Wide Changes by this deadline, earlier better. As the deadline applies fo

Re: Koji build - unexpected keyword argument 'canfail'

On Tue, 24 Jan 2017 12:12:18 -0700 Kevin Fenzi wrote: > On Tue, 24 Jan 2017 13:49:18 -0500 (EST) > Charalampos Stratakis wrote: > > > Getting the same issue for gcc-python-plugin [0]. The scratch build > > in koji (from my local srpm) completed successfully though. > > > > [0] https://koji.fed

Re: more problems with koji builders for f26

Should all be fixed now. On Tue, Jan 24, 2017 at 11:25 AM, Kaleb Keithley wrote: > > Okay, thanks for the info. I'll hold off until later. > > > - Original Message - >> From: "Peter Robinson" >> To: "Development discussions related to Fedora" >> >> Sent: Tuesday, January 24, 2017 6:2

[Test-Announce] Fedora 26 Rawhide 20170125.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 26 Rawhide 20170125.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki

Re: Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)

> Il giorno 25 gen 2017, alle ore 10:57, Simone Caronni > ha scritto: > > Hello, > > On Wed, Jan 25, 2017 at 9:36 AM, Guido Aulisi > wrote: > Hello, > I recently joined the packager group and I made 2 audio related > packages (setBfree and lv2-ir-plugins). > I n

Re: Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)

Hello, On Wed, Jan 25, 2017 at 9:36 AM, Guido Aulisi wrote: > Hello, > I recently joined the packager group and I made 2 audio related > packages (setBfree and lv2-ir-plugins). > I noticed that lv2 related packages are behind upstream releases, and I > know there are important bug fixes in these

Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)

Hello, I recently joined the packager group and I made 2 audio related packages (setBfree and lv2-ir-plugins). I noticed that lv2 related packages are behind upstream releases, and I know there are important bug fixes in these new releases, so I'm proposing myself as a co-maintainer of lv2 related

Re: F26 Self Contained Change: Transdiff

[1] https://github.com/sundeep-co-in/transtats On Wed, Jan 25, 2017 at 1:38 PM, Sundeep Anand wrote: > Hi Dominik, > > Thanks, I have updated the proposal. I see solution to this in two parts: > > 1) Some service/web-application which do specified tasks based on > milestones in a release cycle (

Re: F26 Self Contained Change: Transdiff

Hi Dominik, Thanks, I have updated the proposal. I see solution to this in two parts: 1) Some service/web-application which do specified tasks based on milestones in a release cycle (translation-specific) including notification. This should be talking to Fedora apps/services (koji, fas, etc.) and