Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Adam Williamson 
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 the source, but I got lost in the maze of repositories...)

Thanks! Tim's fixing that link now. The correct URL is:
https://qa.fedoraproject.org/docs/libtaskotron/latest/devguide.html

basically, anything that was
docs.qadevel.cloud.fp.o/libtaskotron/latest/docs/... is now
qa.fp.o/docs/libtaskotron/latest/...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Zbigniew Jędrzejewski-Szmek 
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 look at the source code. piuparts.py [1] has a mishmash
> > of debian/ubuntu distro-specific config, functions for chroot
> > creation, process management, helper functions, and the actual logic
> > of testing stuff. That's why it's so large. Thankfully we wouldn't need
> > most of that.
> > 
> > It seems that we *could* use a test like that in taskotron.
> > In particular, install the package, uninstall, reinstall, make sure
> > scriptlets don't fail and not errors are logged.
> 
> We certainly could build something like that. However, if you look at
> this case, it's not entirely a simple one - because the package that
> *broke* was polymake, but the package that *changed* was perl. polymake
> didn't change at all. Knowing that we need to run the 'installpkg' (or
> whatever we call it) test on polymake when perl changes makes things
> somewhat more complex. Of course in this particular case it's not crazy
> difficult - all we have to do is parse polymake's deps, easy right?! -
> but this kind of thing leads you down lots of rabbit holes...for
> instance, when perl gets an API bump, thousands of packages will
> suddenly start 'failing' this test, because in Rawhide there's no way
> to group package builds (so we can't 'group' the perl API bump with
> rebuilds of all dependent packages)...what do we do about that?

Yeah, the devil is in the details, as always ;)

> Still, we don't have to make it perfect, and even just a test which
> tried to install all of a source package's binary packages every time
> that package was changed could be useful. Tim says this is something
> that's been talked about but no-one's yet taken the time to do it.
> 
> > There's dist.upgradepath test, but I have no idea what it does.
> 
> It doesn't do that. It tries to check whether an update breaks the
> upgrade path between releases; it's intended to catch cases where, say,
> 'foo-2.0.fc24' is released while F25 still only has 'foo-1.5.fc25'.
> It's somewhat less important now dnf system-upgrade does a distro-sync
> by default, but still useful I think.
> 
> > Unfortunately taskotron is rather opaque :( [2]
> > 
> > [1] https://anonscm.debian.org/cgit/piuparts/piuparts.git/tree/piuparts.py
> > [2] https://taskotron.fedoraproject.org/ documentation link points to
> > https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs
> > which cannot be resolved.
> 
> We're sorry about that - Tim's been updating and moving documentation
> around (in an attempt to make it better), but that meant that URL went
> stale. Or in his verbatim words (it's 1:30am here and we're quite
> tired...), "Oh , I was going to do that tomorrow". :)
> 
> You can now find the docs here: 
> https://qa.fedoraproject.org/docs/libtaskotron/latest/
> Tim is also fixing the front page link now. There are supposed to be
> redirects from the old URLs but they're not working, he's figuring that
> out.
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 the source, but I got lost in the maze of repositories...)

Zbyszek



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Zbigniew Jędrzejewski-Szmek 
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-devel packages and
> overriding PYTHON in each %build , etc. But maybe there's a
> simpler solution?
That's what we did in systemd. Splitting out the python bindings into
a separate package cut down on the build time a lot.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Adam Williamson 
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-specific config, functions for chroot
> creation, process management, helper functions, and the actual logic
> of testing stuff. That's why it's so large. Thankfully we wouldn't need
> most of that.
> 
> It seems that we *could* use a test like that in taskotron.
> In particular, install the package, uninstall, reinstall, make sure
> scriptlets don't fail and not errors are logged.

We certainly could build something like that. However, if you look at
this case, it's not entirely a simple one - because the package that
*broke* was polymake, but the package that *changed* was perl. polymake
didn't change at all. Knowing that we need to run the 'installpkg' (or
whatever we call it) test on polymake when perl changes makes things
somewhat more complex. Of course in this particular case it's not crazy
difficult - all we have to do is parse polymake's deps, easy right?! -
but this kind of thing leads you down lots of rabbit holes...for
instance, when perl gets an API bump, thousands of packages will
suddenly start 'failing' this test, because in Rawhide there's no way
to group package builds (so we can't 'group' the perl API bump with
rebuilds of all dependent packages)...what do we do about that?

Still, we don't have to make it perfect, and even just a test which
tried to install all of a source package's binary packages every time
that package was changed could be useful. Tim says this is something
that's been talked about but no-one's yet taken the time to do it.

> There's dist.upgradepath test, but I have no idea what it does.

It doesn't do that. It tries to check whether an update breaks the
upgrade path between releases; it's intended to catch cases where, say,
'foo-2.0.fc24' is released while F25 still only has 'foo-1.5.fc25'.
It's somewhat less important now dnf system-upgrade does a distro-sync
by default, but still useful I think.

> Unfortunately taskotron is rather opaque :( [2]
> 
> [1] https://anonscm.debian.org/cgit/piuparts/piuparts.git/tree/piuparts.py
> [2] https://taskotron.fedoraproject.org/ documentation link points to
> https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs
> which cannot be resolved.

We're sorry about that - Tim's been updating and moving documentation
around (in an attempt to make it better), but that meant that URL went
stale. Or in his verbatim words (it's 1:30am here and we're quite
tired...), "Oh , I was going to do that tomorrow". :)

You can now find the docs here: 
https://qa.fedoraproject.org/docs/libtaskotron/latest/
Tim is also fixing the front page link now. There are supposed to be
redirects from the old URLs but they're not working, he's figuring that
out.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Alec Leamas 



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 PYTHON in each %build , etc. But maybe there's a
simpler solution?


Just an idea, nothing tested... but what about hacking 
AM_PATH_PYTHON2/AM_PATH_PYTHON3 macros?



Just my 5 öre


--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Peter Hutterer 
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 a
simpler solution?

Package in question is evemu and yes, we are also the upstream maintainers
so if there's a more sensible solution we can move that into upstream.

Thanks

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Zbigniew Jędrzejewski-Szmek 
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 wondering if there's some automation that should be
> >>done to detect that in packaging.
> >You mean something like debian's piuparts?
> Thanks for bringing it up---I didn't know about it:
> 
> https://piuparts.debian.org/doc/README.html
> "PIUPARTS is a tool for testing that packages can be installed,
> upgraded and removed"
> 
> In Debian it seems to be a 'big hammer' manual tool that has to be
> run as root, etc.

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-specific config, functions for chroot
creation, process management, helper functions, and the actual logic
of testing stuff. That's why it's so large. Thankfully we wouldn't need
most of that.

It seems that we *could* use a test like that in taskotron.
In particular, install the package, uninstall, reinstall, make sure
scriptlets don't fail and not errors are logged.
There's dist.upgradepath test, but I have no idea what it does.
Unfortunately taskotron is rather opaque :( [2]

[1] https://anonscm.debian.org/cgit/piuparts/piuparts.git/tree/piuparts.py
[2] https://taskotron.fedoraproject.org/ documentation link points to
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs
which cannot be resolved.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Neal Gompa 
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 there's some automation that should be
> done to detect that in packaging.
>
> You mean something like debian's piuparts?
>
> Thanks for bringing it up---I didn't know about it:
>
> https://piuparts.debian.org/doc/README.html
> "PIUPARTS is a tool for testing that packages can be installed, upgraded
> and removed"
>
> In Debian it seems to be a 'big hammer' manual tool that has to be run as
> root, etc.
> Could something like that be part of Bodhi?
>

Taskotron already has distcheck support (including installability and
upgrade paths). I'm not sure if they're enabled on all updates made,
though.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Przemek Klosowski 

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 packaging.

You mean something like debian's piuparts?

Thanks for bringing it up---I didn't know about it:

https://piuparts.debian.org/doc/README.html
"PIUPARTS is a tool for testing that packages can be installed, 
upgraded and removed"


In Debian it seems to be a 'big hammer' manual tool that has to be run 
as root, etc.

Could something like that be part of Bodhi?



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Zbigniew Jędrzejewski-Szmek 
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*, git*, vim*), while
> polymake can't just be bypassed because it is a dependency of quite a
> bit of other packages (python*, gap*, sage*, ocaml*), so it's a stalemate.
> 
> I reported that in https://bugzilla.redhat.com/show_bug.cgi?id=1415548
> 
> Now, the reason I mention it here is that I noticed a number of update
> hiccups recently, resulting from strict checks by DNF. I don't think it's
> DNF's fault: here, it just enforces a strict requirement specified by
> 'polymake'. I reported other cases, where the file specifications cause
> conflicts between the old and new version of the package:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1404897
> https://bugzilla.redhat.com/show_bug.cgi?id=1396848
> https://bugzilla.redhat.com/show_bug.cgi?id=1396319
> https://bugzilla.redhat.com/show_bug.cgi?id=1396849
> 
> and people commented that they also are all packaging errors. Still,
> they do block upgrades.
> 
> 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 packaging.

You mean something like debian's piuparts?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

polymake blocks system updates by strict Perl dependence

2017-01-25 Thread Przemek Klosowski 

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 of quite a
bit of other packages (python*, gap*, sage*, ocaml*), so it's a stalemate.

I reported that in https://bugzilla.redhat.com/show_bug.cgi?id=1415548

Now, the reason I mention it here is that I noticed a number of update
hiccups recently, resulting from strict checks by DNF. I don't think it's
DNF's fault: here, it just enforces a strict requirement specified by
'polymake'. I reported other cases, where the file specifications cause
conflicts between the old and new version of the package:

https://bugzilla.redhat.com/show_bug.cgi?id=1404897
https://bugzilla.redhat.com/show_bug.cgi?id=1396848
https://bugzilla.redhat.com/show_bug.cgi?id=1396319
https://bugzilla.redhat.com/show_bug.cgi?id=1396849

and people commented that they also are all packaging errors. Still,
they do block upgrades.

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 packaging.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Testing on armv7hl

2017-01-25 Thread Mike Miller 
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, Kevin Fenzi  wrote:

> 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.
> >
> > Does anyone know of an AWS image for ARM?  Any other tips for
> > building on ARM architecture?
>
> If you are a packager or qa member:
>
> https://fedoraproject.org/wiki/Test_Machine_Resources_
> For_Package_Maintainers
>
> (the arm03-*packager* ones are for packagers and the *qa* ones are for
> people in the qa group).
>
> These are the same hardware thats currently used for official builds.
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Testing on armv7hl

2017-01-25 Thread Kevin Fenzi 
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.
> 
> Does anyone know of an AWS image for ARM?  Any other tips for
> building on ARM architecture?

If you are a packager or qa member: 

https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

(the arm03-*packager* ones are for packagers and the *qa* ones are for
people in the qa group). 

These are the same hardware thats currently used for official builds. 

kevin


pgpQzF8d0us5k.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Testing on armv7hl

2017-01-25 Thread Josh Boyer 
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.

When you say you've tested on all architectures, what exactly do you
mean?  Fedora has ppc64, ppc64le, aarch64, armv7hl, i686, and x86_64
in Fedora 26.  As far as I know, AWS only supports x86_64.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Testing on armv7hl

2017-01-25 Thread Peter Robinson 
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.
>
> Does anyone know of an AWS image for ARM?  Any other tips for building on
> ARM architecture?

Not supported on AWS but you can test on libvirt/qemu on x86

https://fedoraproject.org/wiki/Architectures/ARM/F25/Installation#For_Versatile_Express_Emulation_with_QEMU
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Help Testing on armv7hl

2017-01-25 Thread Mike Miller 
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 building on
ARM architecture?

Here is my latest scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17403429
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %pre is a lie?

2017-01-25 Thread Richard Shaw 
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 scriptlet that creates the unifi user and group uses "exit 0" at the
end which was preventing my migration from running! Moving the migration to
the beginning of %pre solved the problem!

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %pre is a lie?

2017-01-25 Thread Stephen Gallagher 
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 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. Of course, it would've been easier if we could
> see your spec file.
> 
> 
> Maybe but that doesn't make sense to me. I have verified on a fresh install 
> that
> the symlink is created correctly but only when upgrading it fails.
> 
>  $ ll /var/lib/unifi
> total 12
> drwxr-xr-x. 6 unifi unifi 4096 Jan 25 08:44 data
> drwxr-xr-x. 2 unifi unifi 4096 Jan 25 08:32 logs
> lrwxrwxrwx. 1 unifi unifi   15 Jan 25 08:44 'logs;5888ba05' -> ../../log/unifi
> drwxr-xr-x. 3 unifi unifi 4096 Jan 25 08:04 work
> 
> This shows me the the real directory logs is still present even though it 
> should
> have been rm -rf'ed out and what I assume happens is cpio does a random rename
> to the symlink. 
> 
> In either case, the full spec file is here:
> https://hobbes1069.fedorapeople.org/unifi.spec
> 
> Thanks,
> Richard

See https://fedoraproject.org/wiki/Packaging:Directory_Replacement

Replacing a directory with a symlink is a known limitation of RPM. The
workaround is there.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170125.n.0 compose check report

2017-01-25 Thread Fedora compose checker 
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):

ID: 55589   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/55589
ID: 55641   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/55641
ID: 55654   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/55654

Old failures (same test failed in Rawhide-20170120.n.0):

ID: 55564   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/55564
ID: 55566   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/55566
ID: 55568   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/55568
ID: 55572   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/55572
ID: 55575   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55575
ID: 55576   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/55576
ID: 55579   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55579
ID: 55583   Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/55583
ID: 55586   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/55586
ID: 55590   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/55590
ID: 55595   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/55595
ID: 55596   Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/55596
ID: 55597   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55597
ID: 55616   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/55616
ID: 55621   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/55621
ID: 55627   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/55627
ID: 55655   Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/55655
ID: 55656   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/55656
ID: 55657   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/55657
ID: 55658   Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/55658
ID: 55659   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/55659
ID: 55660   Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/55660
ID: 55661   Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/55661
ID: 55662   Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/55662
ID: 55663   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/55663
ID: 55664   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/55664
ID: 55665   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/55665
ID: 55666   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/55666

Soft failed openQA tests: 52/96 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170120.n.0):

ID: 55577   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55577
ID: 55628   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/55628

Old soft failures (same test soft failed in Rawhide-20170120.n.0):

ID: 4   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/4
ID: 5   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/5
ID: 6   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/6
ID: 7   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/7
ID: 55565   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/55565
ID: 55574   Tes

Re: %pre is a lie?

2017-01-25 Thread Richard Shaw 
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 files that are in %files
> are not there after unpacking the cpio payload. Try removing them from
> %files completely. Of course, it would've been easier if we could
> see your spec file.


Maybe but that doesn't make sense to me. I have verified on a fresh install
that the symlink is created correctly but only when upgrading it fails.

 $ ll /var/lib/unifi
total 12
drwxr-xr-x. 6 unifi unifi 4096 Jan 25 08:44 data
drwxr-xr-x. 2 unifi unifi 4096 Jan 25 08:32 logs
lrwxrwxrwx. 1 unifi unifi   15 Jan 25 08:44 'logs;5888ba05' ->
../../log/unifi
drwxr-xr-x. 3 unifi unifi 4096 Jan 25 08:04 work

This shows me the the real directory logs is still present even though it
should have been rm -rf'ed out and what I assume happens is cpio does a
random rename to the symlink.

In either case, the full spec file is here:
https://hobbes1069.fedorapeople.org/unifi.spec

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %pre is a lie?

2017-01-25 Thread Dominik 'Rathann' Mierzejewski 
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. Of course, it would've been easier if we could
see your spec file.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

%pre is a lie?

2017-01-25 Thread Richard Shaw 
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 putting a log file where I didn't want it so I
tried adding some logic in %pre to migrate it to the correct location.

Per the Fedora Packaging Guidelines for sciptlets %pre runs BEFORE the
updated package is installed but that doesn't appear to be the case...

I took out all my logic and just tried a brute force rm -rf of the old
location to get a minimal test case:

%pre
# Migrate UniFi log to the proper directory
#if [ ! -h /var/lib/unifi/logs ]; then
#   if [ -f /var/lib/unifi/logs/server.log ]; then
#   mv -f /var/lib/unifi/logs/server.log \
# /var/log/unifi/ 2>/dev/null
#   fi
#   rmdir /var/lib/unifi/logs
rm -rf /var/lib/unifi/logs
#fi

On an attempted upgrade I get the following:
Running transaction
  Upgrading   : unifi-5.3.8-2.1.fc24.x86_64
1/2
Error unpacking rpm package unifi-5.3.8-2.1.fc24.x86_64
Error unpacking rpm package unifi-5.3.8-2.1.fc24.x86_64
error: unpacking of archive failed on file /var/lib/unifi/logs: cpio: rename
unifi-5.3.8-2.1.fc24.x86_64 was supposed to be installed but is not!
  Verifying   : unifi-5.3.8-2.1.fc24.x86_64
1/2
unifi-5.3.8-2.fc24.x86_64 was supposed to be removed but is not!
  Verifying   : unifi-5.3.8-2.fc24.x86_64
2/2

Failed:
  unifi.x86_64 5.3.8-2.1.fc24

And in the directory in question I get:
$ ll /var/lib/unifi
total 12
drwxr-xr-x. 6 unifi unifi 4096 Jan 25 08:44 data
drwxr-xr-x. 2 unifi unifi 4096 Jan 25 08:32 logs
lrwxrwxrwx. 1 unifi unifi   15 Jan 25 08:44 'logs;5888ba05' ->
../../log/unifi
drwxr-xr-x. 3 unifi unifi 4096 Jan 25 08:04 work

So it seems to me that %pre did not run.

Am I missing something?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Martin Gansser 
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 signal.
gsad main:WARNING:2017-01-25 13h21.05 utc:2730: main: Locale defined by 
environment variables is not an "en_..." one.
gsad main:  DEBUG:2017-01-25 13h21.05 utc:2730: main: gettext translation 
extensions are enabled (using locale "de_DE.UTF-8").

A fedora ticket has already been opened
https://bugzilla.redhat.com/show_bug.cgi?id=1416034

any help would be appreciated
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji build - unexpected keyword argument 'canfail'

2017-01-25 Thread Dan Horák 
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 local srpm) completed successfully though.
> > > 
> > > [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=17403559
> > 
> > I think I just tracked down and fixed this issue. 
> 
> Kevin, what was the fix for the "canfail" issue? s390 koji suffers
> from that too.

and the solution is downgrade to koji-1.11.0-1.fc25 from a newer infra
build


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Jan Kurik 
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 for System Wide Changes it is always
good to have most of Self Contained Changes proposed as well. In case
you'll need any help with your Change proposals, feel free to contact
me.

[1] https://fedoraproject.org/wiki/Releases/26/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji build - unexpected keyword argument 'canfail'

2017-01-25 Thread Dan Horák 
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.fedoraproject.org/koji/taskinfo?taskID=17403559
> 
> I think I just tracked down and fixed this issue. 

Kevin, what was the fix for the "canfail" issue? s390 koji suffers
from that too.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: more problems with koji builders for f26

2017-01-25 Thread Peter Robinson 
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:21:52 AM
>> Subject: Re: more problems with koji builders for f26
>>
>> On Tue, Jan 24, 2017 at 11:07 AM, Kaleb Keithley  wrote:
>> > Hi,
>> >
>> > Trying to build latest nfs-ganesha––
>> >
>> > Yesterday (for me, 02:00 UTC, 24 Jan) I was getting (on both a fedpkg build
>> > and koji scratch builds):
>> >DEBUG util.py:435:  Error: package
>> >pkgconf-pkg-config-1.2.0-1.fc26.ppc64le conflicts with pkgconfig <
>> >1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.ppc64le
>> > on ppc64, ppc64le, and aarch64 (x86_64, i686, armv7hl built succuessfully).
>> > See, e.g.,
>> > https://kojipkgs.fedoraproject.org//work/tasks/7502/17397502/root.log
>> >
>> >
>> > Today (for me, 11:00 UTC, 24 Jan) on a koji scratch build of the same srpm
>> > as above I'm getting
>> >   DEBUG util.py:435:  Error: nothing provides libproj.so.9()(64bit) needed
>> >   by qt-mobility-location-1.2.2-0.24.20140317git169da60c.fc26.x86_64
>> > on all six platforms.  see, e.g.,
>> > https://kojipkgs.fedoraproject.org//work/tasks/697/17400697/root.log
>> >
>> > f25 scratch builds worked both yesterday and today.
>>
>> A feature in F-26 needs a new dnf on the builders, other versions are
>> unaffected and hence f25 scratch or otherwise are unaffected.
>>
>> > Any ideas?
>>
>> There was a miscommunication and there's updates that need to be
>> pushed to those arches. They will be fixed today but of course the
>> package signing is taking eons. It's a known problem and it's being
>> actively worked on and will be solved as soon as I can push out the
>> signed updates.
>>
>> > Thanks
>> >
>> > --
>> >
>> > Kaleb
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread rawhide 
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/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20170120.n.0: pungi-4.1.12-3.fc26.src, 20170125.n.0: 
pungi-4.1.12-4.fc26.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/26

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170125.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Guido Aulisi 

> 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 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 packages (from
> drobilla.net ) to try to package the latest versions 
> (in rawhide).
> The packages are:
> 
> lv2
> sratom
> serd
> sord
> suil
> lilv
> 
> I'm requiring the epel7 ones, so I requested branches for some of them a few 
> months ago. Count me in if you need additional maintainership, would be nice 
> to make sure the packages build also on el7 so we can just merge the commits 
> in the various branches.
That’s great.
Really I was talking about rawhide and maybe fedora 26. Many programs depend on 
lv2, I think it could be unsafe to update f25.

Ciao
Guido

> Thanks,
> --Simone

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Simone Caronni 
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 new releases, so I'm
> proposing myself as a co-maintainer of lv2 related packages (from
> drobilla.net) to try to package the latest versions (in rawhide).
> The packages are:
>
> lv2
> sratom
> serd
> sord
> suil
> lilv
>

I'm requiring the epel7 ones, so I requested branches for some of them a
few months ago. Count me in if you need additional maintainership, would be
nice to make sure the packages build also on el7 so we can just merge the
commits in the various branches.

Thanks,
--Simone




>
> Ciao
> Guido
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-01-25 Thread Guido Aulisi 
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 packages (from
drobilla.net) to try to package the latest versions (in rawhide).
The packages are:

lv2
sratom
serd
sord
suil
lilv

Ciao
Guido

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Transdiff

2017-01-25 Thread Sundeep Anand 
[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 (translation-specific) including
> notification. This should be talking to Fedora apps/services (koji, fas,
> etc.) and translation platforms (zanata, pootle, etc.) where we have
> translations of Fedora packages. Plus keep upstream info as well. A project
> is already under development on this line[1].
>
> 2) A translation check during/post build - as discussed it (transdiff)
> will be a taskotron task.
>
> Coming back to - why this need to be a change - sorry, I do not have any
> concrete answer at this point of time, perhaps as I need some more time
> working on this. I believe aligning this with *Fedora 27* would be more
> meaningful and working.
>
> thanks,
> sundeep
>
> On Fri, Jan 20, 2017 at 9:54 PM, Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
>
>> Hello, Sundeep.
>>
>> On Thursday, 12 January 2017 at 08:03, pravin@gmail.com wrote:
>> > On 10 January 2017 at 16:31, Dominik 'Rathann' Mierzejewski <
>> > domi...@greysector.net> wrote:
>> >
>> > > On Tuesday, 10 January 2017 at 09:39, Jan Kurik wrote:
>> > > > = Proposed Self Contained Change: Transdiff =
>> > > > https://fedoraproject.org/wiki/Changes/Transdiff
>> > > >
>> > > > Change owner(s):
>> > > > *Sundeep Anand 
>> > > >
>> > > > Often even after 100% translation in Zanata, few packages do not get
>> > > > build with latest translations in Fedora. This result in poor
>> > > > localization experience. Transdiff is a python program to run on
>> > > > products installations for tracking translations with project
>> upstream
>> > > > and generate diff reports.
>> > >
>> > > Nice. On the wiki page, you (Sundeep) also mention automation.
>> > > Where do you see this in our packaging pipeline?
>> > >
>> > > As a taskotron check? A regular report mailed to the devel list?
>> >
>> > Good point. While discussing on string breakage monitoring we discussed
>> > this idea as well.
>> > Yeah, taskotron is good fit for uses of transdiff, so rather than post
>> > installation of translation, we will have this check in Bodhi itself.
>>
>> Could you update the proposal with the conclusions from this thread
>> and also, more importantly, answer my question? Why does this need
>> to be a Change?
>>
>> Regards,
>> Dominik
>> --
>> Fedora http://fedoraproject.org/wiki/User:Rathann
>> RPMFusion http://rpmfusion.org
>> "Faith manages."
>> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Transdiff

2017-01-25 Thread Sundeep Anand 
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 translation platforms (zanata, pootle, etc.) where we have
translations of Fedora packages. Plus keep upstream info as well. A project
is already under development on this line[1].

2) A translation check during/post build - as discussed it (transdiff) will
be a taskotron task.

Coming back to - why this need to be a change - sorry, I do not have any
concrete answer at this point of time, perhaps as I need some more time
working on this. I believe aligning this with *Fedora 27* would be more
meaningful and working.

thanks,
sundeep

On Fri, Jan 20, 2017 at 9:54 PM, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Hello, Sundeep.
>
> On Thursday, 12 January 2017 at 08:03, pravin@gmail.com wrote:
> > On 10 January 2017 at 16:31, Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> >
> > > On Tuesday, 10 January 2017 at 09:39, Jan Kurik wrote:
> > > > = Proposed Self Contained Change: Transdiff =
> > > > https://fedoraproject.org/wiki/Changes/Transdiff
> > > >
> > > > Change owner(s):
> > > > *Sundeep Anand 
> > > >
> > > > Often even after 100% translation in Zanata, few packages do not get
> > > > build with latest translations in Fedora. This result in poor
> > > > localization experience. Transdiff is a python program to run on
> > > > products installations for tracking translations with project
> upstream
> > > > and generate diff reports.
> > >
> > > Nice. On the wiki page, you (Sundeep) also mention automation.
> > > Where do you see this in our packaging pipeline?
> > >
> > > As a taskotron check? A regular report mailed to the devel list?
> >
> > Good point. While discussing on string breakage monitoring we discussed
> > this idea as well.
> > Yeah, taskotron is good fit for uses of transdiff, so rather than post
> > installation of translation, we will have this check in Bodhi itself.
>
> Could you update the proposal with the conclusions from this thread
> and also, more importantly, answer my question? Why does this need
> to be a Change?
>
> Regards,
> Dominik
> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org