Re: Rename of boost-python to python2-boost

2017-09-12 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Sep 12, 2017 at 11:54:24PM +0100, Jonathan Wakely wrote:
> On 12/09/17 18:41 -0400, Scott Talbert wrote:
> >On Tue, 12 Sep 2017, Zbigniew Jędrzejewski-Szmek wrote:
> >
> >>>Was this package rename discussed anywhere?
> >>>
> >>>I don't think it makes any sense. It's not a python package, as the
> >>>name python2-boost would suggest.
> >>
> >>Hi,
> >>
> >>yes, it was discussed on fedora-devel@ and python@ for a few weeks.
> >>An announcement was sent to fedora-announce@.
> >>
> >>>It installs a shared library, libboost_python2.so, which is a library
> >>>of C++ symbols that implement the Boost.Python C++ library.
> >>>
> >>>Why is "python2-boost" a better name for this than "boost-python2"?
> >>That's what the packaging guidelines require for python packages.
> >
> >But he's trying to point out that this *isn't* a python library package.
> 
> Exactly.

OK, I see now. In this case it's reasonable to revert.
Make sure you add Obsoletes for the python2- name so upgrades happen properly.

> >Of course, I understand the other side of the coin - this was done
> >by your script which made some assumptions about which packages
> >are python packages, so it's understandable that there were some
> >false positives.
> 
> Sure, that's understandable. I'll revert the change then.

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

Re: GNOME 3.25.92 megaupdate

2017-09-12 Thread Adam Williamson 
On Mon, 2017-09-11 at 13:06 +0200, Kalev Lember wrote:
> On 09/11/2017 10:49 AM, Vít Ondruch wrote:
> > Why the updated version of gjs 1.49 was not released yet? F27+ users
> > apparently still fight gjs crashes:
> 
> It needs mozjs52 that we don't have in Fedora yet.

Well, also, we're in Beta freeze right now. It would need a blocker /
FE bug to go to stable even if it was built.
-- 
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

Fedora Rawhide-20170912.n.0 compose check report

2017-09-12 Thread Fedora compose checker 
Missing expected images:

Cloud_base qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Kde live i386

Failed openQA tests: 24/128 (x86_64), 3/18 (i386), 1/2 (arm)

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

ID: 141075  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/141075
ID: 141077  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/141077
ID: 141103  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/141103
ID: 141109  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/141109
ID: 141110  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/141110
ID: 141134  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/141134
ID: 141167  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/141167
ID: 141180  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/141180

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

ID: 141038  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/141038
ID: 141039  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/141039
ID: 141042  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/141042
ID: 141045  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/141045
ID: 141064  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/141064
ID: 141076  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/141076
ID: 141088  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/141088
ID: 141090  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/141090
ID: 141092  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/141092
ID: 141099  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/141099
ID: 141101  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/141101
ID: 141106  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/141106
ID: 141107  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/141107
ID: 141145  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/141145
ID: 141146  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/141146
ID: 141147  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/141147
ID: 141150  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/141150
ID: 141160  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/141160
ID: 141163  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/141163
ID: 141179  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/141179

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

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

ID: 141104  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/141104
ID: 141162  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/141162

Passed openQA tests: 84/128 (x86_64), 15/18 (i386)

New passes (same test did not pass in Rawhide-20170910.n.0):

ID: 141033  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/141033
ID: 141074  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/141074
ID: 141102  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/141102
ID: 141131  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/141131
ID: 141161  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/141161

Skipped openQA tests: 14 of 148

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
2 packages(s) added since previous compose: dejavu-fonts-common, 
dejavu-sans-fonts
2 packages(s) removed since previous compose: amiri-fonts, 
amiri-fonts-common
Previous test data: https://openqa.fedoraproject.org/tests/139805#down

Re: Kernel 4.13 rebase plans

2017-09-12 Thread James Hogarth 
On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:

On 09/05/2017 09:41 AM, Laura Abbott wrote:

> Hi,
>
> Kernel 4.13 was released this past weekend. This kernel has been
> built for rawhide and is building for F27 as well. We will be
> following the same upgrade procedure as in the past. F25 and F26
> will get rebased to 4.13 after a few stable releases, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
>
> Thanks,
> Laura
>
>
4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
this morning but given it was released in conjunction with a new
publicized CVE, it was slightly smaller and I'm inclined to wait
for 4.13.3 before attempting to push anything to bodhi for F26.



Thanks for the update Laura

I'll pop that on my system tomorrow for some early testing and when you're
ready with the bodhi update will add the feedback.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rename of boost-python to python2-boost

2017-09-12 Thread Jonathan Wakely 

On 12/09/17 18:41 -0400, Scott Talbert wrote:

On Tue, 12 Sep 2017, Zbigniew Jędrzejewski-Szmek wrote:


Was this package rename discussed anywhere?

I don't think it makes any sense. It's not a python package, as the
name python2-boost would suggest.


Hi,

yes, it was discussed on fedora-devel@ and python@ for a few weeks.
An announcement was sent to fedora-announce@.


It installs a shared library, libboost_python2.so, which is a library
of C++ symbols that implement the Boost.Python C++ library.

Why is "python2-boost" a better name for this than "boost-python2"?

That's what the packaging guidelines require for python packages.


But he's trying to point out that this *isn't* a python library package.


Exactly.

Of course, I understand the other side of the coin - this was done by 
your script which made some assumptions about which packages are 
python packages, so it's understandable that there were some false 
positives.


Sure, that's understandable. I'll revert the change then.

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

Re: Rename of boost-python to python2-boost

2017-09-12 Thread Scott Talbert 

On Tue, 12 Sep 2017, Zbigniew Jędrzejewski-Szmek wrote:


Was this package rename discussed anywhere?

I don't think it makes any sense. It's not a python package, as the
name python2-boost would suggest.


Hi,

yes, it was discussed on fedora-devel@ and python@ for a few weeks.
An announcement was sent to fedora-announce@.


It installs a shared library, libboost_python2.so, which is a library
of C++ symbols that implement the Boost.Python C++ library.

Why is "python2-boost" a better name for this than "boost-python2"?

That's what the packaging guidelines require for python packages.


But he's trying to point out that this *isn't* a python library package.

Of course, I understand the other side of the coin - this was done by your 
script which made some assumptions about which packages are python 
packages, so it's understandable that there were some false positives.


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

Re: Kernel 4.13 rebase plans

2017-09-12 Thread Laura Abbott 

On 09/05/2017 09:41 AM, Laura Abbott wrote:

Hi,

Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.

Thanks,
Laura



4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
this morning but given it was released in conjunction with a new
publicized CVE, it was slightly smaller and I'm inclined to wait
for 4.13.3 before attempting to push anything to bodhi for F26.

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

Re: Build failures on armv7hl with "No such file or directory"

2017-09-12 Thread Alexander Ploumistos 
On Wed, Sep 13, 2017 at 12:22 AM, Jerry James  wrote:
> I looked through the armv7hl build log for sip errors or warnings and
> found this:
>
> sip: src/scidavis.sip:175: ::Column::replaceValues() unsupported
> function argument type - provide %MethodCode and a C++ signature
>
> I don't see that in the x86_64 build logs, so that may be related.

Thank you James, I think I'll take this upstream.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removing myself from packages in pagure?

2017-09-12 Thread Ville Skyttä 
On Tue, Sep 12, 2017 at 11:52 PM, Matthew Miller
 wrote:
> On Tue, Sep 12, 2017 at 09:53:26PM +0300, Ville Skyttä wrote:
>> I would like to remove myself from being a co-maintainer for various
>> packages. I cannot find a way to do it in pagure, nor am I able to
>> locate instructions for doing that in wiki. I cannot access /settings
>> for those projects, because I don't have sufficient rights (I get
>> "Forbidden: You are not allowed to change the settings for this
>> project").
>
> I think currently the easiest way is to ask the main admin to remove
> you. It would certainly be nice to have the ability to remove oneself.
> There's an open issue for this: https://pagure.io/pagure/issue/2599

Yep, thanks, that was created in response to my report per Adam's
suggestion: https://pagure.io/releng/issue/7027
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build failures on armv7hl with "No such file or directory"

2017-09-12 Thread Jerry James 
On Tue, Sep 12, 2017 at 3:10 PM, Alexander Ploumistos
 wrote:
> Thanks Phil, but I don't think this applies in my case. Had I
> forgotten to declare a dependency, the build would fail on all arches
> and not only armv7hl. Plus, that thread and another one about a
> missing sipAPIscidavis.h were from 7-8 years ago, there have been
> extensive changes to the code since then.

I looked through the armv7hl build log for sip errors or warnings and
found this:

sip: src/scidavis.sip:175: ::Column::replaceValues() unsupported
function argument type - provide %MethodCode and a C++ signature

I don't see that in the x86_64 build logs, so that may be related.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rpmlint and rpmdevtools upstream help welcome

2017-09-12 Thread Neal Gompa 
On Tue, Sep 12, 2017 at 2:57 PM, Ville Skyttä  wrote:
> Hello,
>
> I don't have the time I'd like to have to participate in all my Fedora
> related activities these days. Therefore, the rpmlint and rpmdevtools
> upstream projects would benefit from more manpower. Anyone interested?
>
> https://github.com/rpm-software-management/rpmlint
> https://pagure.io/rpmdevtools
>

I'm certainly interested in helping out with both projects.



-- 
真実はいつも一つ！/ 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: rpmlint and rpmdevtools upstream help welcome

2017-09-12 Thread Benjamin Kircher 
On Tue 12. Sep 2017 at 20:59, Ville Skyttä  wrote:

> Hello,
>
> I don't have the time I'd like to have to participate in all my Fedora
> related activities these days. Therefore, the rpmlint and rpmdevtools
> upstream projects would benefit from more manpower. Anyone interested?
>
> https://github.com/rpm-software-management/rpmlint
> https://pagure.io/rpmdevtools


I might be interested in rpmlint. Are there any easy issues or issues with
limited scope to start with? Are you able to mentor on one or two issues?

BK

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

Re: getting kernel-devel added

2017-09-12 Thread Sérgio Basto 
On Tue, 2017-09-12 at 18:03 +0200, Dan Horák wrote:
> On Tue, 12 Sep 2017 11:49:38 -0400
> Matthew Miller  wrote:
> 
> > On Tue, Sep 12, 2017 at 11:35:08AM -0400, Ben Williams wrote:
> > > case A) Students are using Fedora on windows in a VM (Vbox in
> > > this
> > > case) for a class. they are required for said class to install
> > > the
> > > guest additions. they are constantly running into errors that the
> > > guest addidions will not build  (there install does not have
> > > kernel-devel install.  They used the F26 release so now have the
> > > release kernel and so they install sudo dnf install kernel-devel
> > > and
> > > still have issues (kernel and kernel-devel versions do not
> > > match).
> > 
> > Isn't the solution here for the guest addons to require kernel-
> > devel?
> 
> Isn't
> https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
> going to fix all the problems?

Yes , but "dnf installs the wrong kernel variant subpackages" [1] is an
well known problem, in all faqs we have [2], anyway never understood
why we can install kernel-devel without kernel count part [3] (which
also may solve the problem), also with use of rpm boolean dependencies,
seems we can solve this problem, but rpm boolean dependencies will be
just available in F27 or 28 if I'm correct .

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1228897

[2]
dnf install VirtualBox kernel-devel-$(uname -r) akmod-VirtualBox

https://rpmfusion.org/Howto/VirtualBox#Fedora_as_a_Virtual_Machine_and_
VBoxGuestAdditions

https://rpmfusion.org/Howto/VirtualBox#Quick_install
 

[3] 
https://bugzilla.redhat.com/show_bug.cgi?id=1228897#c13

> 
>   Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build failures on armv7hl with "No such file or directory"

2017-09-12 Thread Alexander Ploumistos 
On Tue, Sep 12, 2017 at 11:31 PM, Phil K  wrote:
>
> Did you search the upstream mailing list?  Try this:
>
> SciDAVis / Discussion / Help & Tips:compile issues on suse
>
> SciDAVis / Discussion / Help & Tips:compile issues on suse

Thanks Phil, but I don't think this applies in my case. Had I
forgotten to declare a dependency, the build would fail on all arches
and not only armv7hl. Plus, that thread and another one about a
missing sipAPIscidavis.h were from 7-8 years ago, there have been
extensive changes to the code since then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rename of boost-python to python2-boost

2017-09-12 Thread Jonathan Wakely 

On 12/09/17 19:48 +, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Sep 12, 2017 at 06:56:02PM +0100, Jonathan Wakely wrote:

Was this package rename discussed anywhere?

I don't think it makes any sense. It's not a python package, as the
name python2-boost would suggest.


Hi,

yes, it was discussed on fedora-devel@ and python@ for a few weeks.
An announcement was sent to fedora-announce@.


Ah, yes, I missed that 'boost' was listed in
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/DQ4VMCKFO7I5ZVRDTGEMISG6LG7P7BM7/

I only skimmed the mail because it talked about python packages.

But boost-python is not a python package.


It installs a shared library, libboost_python2.so, which is a library
of C++ symbols that implement the Boost.Python C++ library.

Why is "python2-boost" a better name for this than "boost-python2"?

That's what the packaging guidelines require for python packages.


It's not a python package.


Why was boost-python3 not also renamed? Having "boost-python3" and
"python2-boost" makes no sense.

I decided not to rename python3 subpackages to reduce the scope
of the change (and potential for errors). Hopefully this state will be
only temporary, and the python3 subpackages will be renamed (along with
the remaining python2 subpackages which don't follow the new naming).


Was this thought through at all?


Zbyszek
___
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: Removing myself from packages in pagure?

2017-09-12 Thread Matthew Miller 
On Tue, Sep 12, 2017 at 09:53:26PM +0300, Ville Skyttä wrote:
> I would like to remove myself from being a co-maintainer for various
> packages. I cannot find a way to do it in pagure, nor am I able to
> locate instructions for doing that in wiki. I cannot access /settings
> for those projects, because I don't have sufficient rights (I get
> "Forbidden: You are not allowed to change the settings for this
> project").

I think currently the easiest way is to ask the main admin to remove
you. It would certainly be nice to have the ability to remove oneself.
There's an open issue for this: https://pagure.io/pagure/issue/2599

-- 
Matthew Miller

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

Re: rpmlint and rpmdevtools upstream help welcome

2017-09-12 Thread Richard W.M. Jones 
On Tue, Sep 12, 2017 at 09:57:41PM +0300, Ville Skyttä wrote:
> https://pagure.io/rpmdevtools

As I use rpmdevtools a lot, I added myself.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build failures on armv7hl with "No such file or directory"

2017-09-12 Thread Phil K 
Did you search the upstream mailing list?  Try this:
SciDAVis / Discussion / Help & Tips:compile issues on suse
  
|  
|   |  
SciDAVis / Discussion / Help & Tips:compile issues on suse
   |  |

  |

 
 

On Tuesday, September 12, 2017 3:52 PM, Alexander Ploumistos 
 wrote:
 

 Hello,

I have a package under review[0], that I realized had python scripting
support disabled, so I enabled it. Before that, it built fine in
rawhide on all arches[1].

After enabling it (which involves python obviously and at least sip)
the build failed only on armv7hl[2], because a file that is generated
during the %build stage was not found:

src/PythonScripting.cpp:65:10: fatal error: sipAPIscidavis.h: No such
file or directory

Antonio Trande told me that I should disable parallel building on ARM,
so I modified my build section from

%build
[…]
make %{?_smp_mflags}

to

%build
[…]
%ifarch %{arm}
make -j1
%else
%make_build
%endif

Even though the output is a bit different now, the builds still
fail[3] with the same error. Is this something I can fix in my spec
file or with a patch, should this be taken upstream, or is there some
other problem with my armv7hl dependencies?

These are the package's requirements:

BuildRequires:  desktop-file-utils
BuildRequires:  doxygen
BuildRequires:  gsl-devel
BuildRequires:  muParser-devel
BuildRequires:  PyQt4-devel
BuildRequires:  python2-devel
BuildRequires:  qt-assistant-adp-devel
BuildRequires:  qt-devel
BuildRequires:  qwt5-qt4-devel
BuildRequires:  qwtplot3d-qt4-devel
BuildRequires:  sip-devel
BuildRequires:  zlib-devel
Requires:      PyQt4

Can anyone shed some light?



0. https://bugzilla.redhat.com/show_bug.cgi?id=1490054
1. https://koji.fedoraproject.org/koji/taskinfo?taskID=21806163
2. https://koji.fedoraproject.org/koji/taskinfo?taskID=21822435
3. https://koji.fedoraproject.org/koji/taskinfo?taskID=21826998
___
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

Build failures on armv7hl with "No such file or directory"

2017-09-12 Thread Alexander Ploumistos 
Hello,

I have a package under review[0], that I realized had python scripting
support disabled, so I enabled it. Before that, it built fine in
rawhide on all arches[1].

After enabling it (which involves python obviously and at least sip)
the build failed only on armv7hl[2], because a file that is generated
during the %build stage was not found:

src/PythonScripting.cpp:65:10: fatal error: sipAPIscidavis.h: No such
file or directory

Antonio Trande told me that I should disable parallel building on ARM,
so I modified my build section from

%build
[…]
make %{?_smp_mflags}

to

%build
[…]
%ifarch %{arm}
make -j1
%else
%make_build
%endif

Even though the output is a bit different now, the builds still
fail[3] with the same error. Is this something I can fix in my spec
file or with a patch, should this be taken upstream, or is there some
other problem with my armv7hl dependencies?

These are the package's requirements:

BuildRequires:  desktop-file-utils
BuildRequires:  doxygen
BuildRequires:  gsl-devel
BuildRequires:  muParser-devel
BuildRequires:  PyQt4-devel
BuildRequires:  python2-devel
BuildRequires:  qt-assistant-adp-devel
BuildRequires:  qt-devel
BuildRequires:  qwt5-qt4-devel
BuildRequires:  qwtplot3d-qt4-devel
BuildRequires:  sip-devel
BuildRequires:  zlib-devel
Requires:   PyQt4

Can anyone shed some light?



0. https://bugzilla.redhat.com/show_bug.cgi?id=1490054
1. https://koji.fedoraproject.org/koji/taskinfo?taskID=21806163
2. https://koji.fedoraproject.org/koji/taskinfo?taskID=21822435
3. https://koji.fedoraproject.org/koji/taskinfo?taskID=21826998
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rename of boost-python to python2-boost

2017-09-12 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Sep 12, 2017 at 06:56:02PM +0100, Jonathan Wakely wrote:
> Was this package rename discussed anywhere?
> 
> I don't think it makes any sense. It's not a python package, as the
> name python2-boost would suggest.

Hi,

yes, it was discussed on fedora-devel@ and python@ for a few weeks.
An announcement was sent to fedora-announce@.

> It installs a shared library, libboost_python2.so, which is a library
> of C++ symbols that implement the Boost.Python C++ library.
> 
> Why is "python2-boost" a better name for this than "boost-python2"?
That's what the packaging guidelines require for python packages.

> Why was boost-python3 not also renamed? Having "boost-python3" and
> "python2-boost" makes no sense.
I decided not to rename python3 subpackages to reduce the scope
of the change (and potential for errors). Hopefully this state will be
only temporary, and the python3 subpackages will be renamed (along with
the remaining python2 subpackages which don't follow the new naming).

> Was this thought through at all?

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

Re: getting kernel-devel added

2017-09-12 Thread Ben Williams 

Date: Tue, 12 Sep 2017 16:35:50 +
From: "Klosowski, Przemek (Fed)"
Subject: Re: getting kernel-devel added
To:"devel@lists.fedoraproject.org"  
Message-ID:<1d935df8-f710-94a2-cda0-afa670dee...@nist.gov>
Content-Type: multipart/alternative;
boundary="_000_1d935df8f71094a2cda0afa670dee62cnistgov_"

--_000_1d935df8f71094a2cda0afa670dee62cnistgov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 09/12/2017 11:35 AM, Ben Williams wrote:
They used the F26 release so now have the release kernel and so they instal=
l sudo dnf install kernel-devel and still have issues (kernel and kernel-de=
vel versions do not match).

You're saying that they need to reboot, because kernel-devel update forces =
 the new kernel but they still run on the old kernel? that's going to bite =
them repeatedly every time kernel updates, if the virtual tools bypass the =
system packaging. It needs to be solved by virtual tools integration, or by=
 more explicit warnings on kernel updates.

no not what i said and the reboots are not the issue
once kernel-devel is on the system with the correct kernel any future updates 
both will be updated.
the issue is kernel-devel is not installed ootb with any of our DEs and i am 
giving the issue to you from the enduser prespective

install the f26 release iso from get fedora do a rpm -qa |grep kernel  
kernel-devel is needed by lots of our endusers

I produce the updated isos i have added kernel-devel to my ks but it would be a 
better exiperence going forward for the new enduser if kernel-devel was 
included by default in the woekstation and spins

Ben

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

[Test-Announce] Fedora 27 Branched 20170912.n.0 nightly compose nominated for testing

2017-09-12 Thread rawhide 
Announcing the creation of a new nightly release validation test event
for Fedora 27 Branched 20170912.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:
anaconda - 20170901.n.1: anaconda-27.20-1.fc27.src, 20170912.n.0: 
anaconda-27.20.1-3.fc27.src

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

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_27_Branched_20170912.n.0_Summary

The individual test result pages are:

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

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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: Removing myself from packages in pagure?

2017-09-12 Thread Adam Williamson 
On Tue, 2017-09-12 at 21:53 +0300, Ville Skyttä wrote:
> Hello,
> 
> I would like to remove myself from being a co-maintainer for various
> packages. I cannot find a way to do it in pagure, nor am I able to
> locate instructions for doing that in wiki. I cannot access /settings
> for those projects, because I don't have sufficient rights (I get
> "Forbidden: You are not allowed to change the settings for this
> project").
> 
> I tried to file a releng issue for this, but it got rejected and
> closed almost immediately, automatically I suppose.
> https://pagure.io/releng/fedora-scm-requests/issue/1116

That's not the right tracker. That's strictly for SCM requests that fit
the process, not filing wider issues with the process.

You could file it directly in releng pagure:

https://pagure.io/releng/issues

not sure if that's the best place, but not sure where would be better
off the top of my head.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rpmlint and rpmdevtools upstream help welcome

2017-09-12 Thread Ville Skyttä 
Hello,

I don't have the time I'd like to have to participate in all my Fedora
related activities these days. Therefore, the rpmlint and rpmdevtools
upstream projects would benefit from more manpower. Anyone interested?

https://github.com/rpm-software-management/rpmlint
https://pagure.io/rpmdevtools

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

Removing myself from packages in pagure?

2017-09-12 Thread Ville Skyttä 
Hello,

I would like to remove myself from being a co-maintainer for various
packages. I cannot find a way to do it in pagure, nor am I able to
locate instructions for doing that in wiki. I cannot access /settings
for those projects, because I don't have sufficient rights (I get
"Forbidden: You are not allowed to change the settings for this
project").

I tried to file a releng issue for this, but it got rejected and
closed almost immediately, automatically I suppose.
https://pagure.io/releng/fedora-scm-requests/issue/1116
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Rename of boost-python to python2-boost

2017-09-12 Thread Jonathan Wakely 

Was this package rename discussed anywhere?

I don't think it makes any sense. It's not a python package, as the
name python2-boost would suggest.

It installs a shared library, libboost_python2.so, which is a library
of C++ symbols that implement the Boost.Python C++ library.

Why is "python2-boost" a better name for this than "boost-python2"?

Why was boost-python3 not also renamed? Having "boost-python3" and
"python2-boost" makes no sense.

Was this thought through at all?

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

Re: getting kernel-devel added

2017-09-12 Thread Klosowski, Przemek (Fed) 
On 09/12/2017 11:35 AM, Ben Williams wrote:
They used the F26 release so now have the release kernel and so they install 
sudo dnf install kernel-devel and still have issues (kernel and kernel-devel 
versions do not match).

You're saying that they need to reboot, because kernel-devel update forces  the 
new kernel but they still run on the old kernel? that's going to bite them 
repeatedly every time kernel updates, if the virtual tools bypass the system 
packaging. It needs to be solved by virtual tools integration, or by more 
explicit warnings on kernel updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testing graphical applications inside mock fails

2017-09-12 Thread Samuel Rakitničan 
> Thank you for your detailed answer!
> 
> 
> The error messages about drm device are gone if I manually create the 
> character file
> inside the chroot. However the original issue remains the same. Tried a GTK 
> application
> easystroke however and that seems to work fine even without a drm device, so 
> maybe it has
> to do something with Qt. The Qt application camotics gives a bunch of these 
> messages.
> 
> X Error: BadAccess (attempt to access private resource denied) 10
>   Extension:130 (MIT-SHM)
>   Minor opcode: 1 (X_ShmAttach)
>   Resource id:  0x131
> X Error: BadShmSeg (invalid shared segment parameter) 128
>   Extension:130 (MIT-SHM)
>   Minor opcode: 5 (X_ShmCreatePixmap)
>   Resource id:  0x280005f
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x2800060
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x2800060
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x2800060
> ...

QT_X11_NO_MITSHM=1 helps with these, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: A less "bloated" KDE spin

2017-09-12 Thread Ian Malone 
On 11 September 2017 at 14:19, Gerald B. Cox  wrote:
>
>
> On Mon, Sep 11, 2017 at 3:45 AM, Richard W.M. Jones 
> wrote:
>>
>> On Sun, Sep 10, 2017 at 07:17:56PM -0400, Gerald Henriksen wrote:
>> > While you (and others) may well know the name of the software you like
>> > for a given task, new people will not have that knowledge.
>>
>> Isn't that really a discoverability problem?
>>
>> I could imagine having menu items pointing to best-in-class
>> applications which are not actually installed.  Selecting the menu
>> item would bring up a box asking you if you want to install it.
>
>
> That wasn't his main point which you removed:
> "But there is also the audience who are trying out KDE (or Gnome/etc)
> for the first time and providing them with an installed base of
> software to try / check out is convenient and the right thing to do."
>
> This is an issue about default applcaitons.  As I said above:
> "I believe you are missing the point of defaults which is to provide as
> complete environment as possible out of the box.  Since this is a KDE spin,
> we should be providing as complete of a KDE environment as possible.   Users
> shouldn't be required to go on a treasure hunt to seek out available KDE
> applications.  If you don't want to use a KDE default you can easily either
> go into settings and change the defaults, remove the package you don't want,
> etc."
>
>
>

To provide a purely anecdotal data point, what I use the KDE spin for
is to install a version of Fedora with the KDE desktop.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: getting kernel-devel added

2017-09-12 Thread Dan Horák 
On Tue, 12 Sep 2017 11:49:38 -0400
Matthew Miller  wrote:

> On Tue, Sep 12, 2017 at 11:35:08AM -0400, Ben Williams wrote:
> > case A) Students are using Fedora on windows in a VM (Vbox in this
> > case) for a class. they are required for said class to install the
> > guest additions. they are constantly running into errors that the
> > guest addidions will not build  (there install does not have
> > kernel-devel install.  They used the F26 release so now have the
> > release kernel and so they install sudo dnf install kernel-devel and
> > still have issues (kernel and kernel-devel versions do not match).
> 
> Isn't the solution here for the guest addons to require kernel-devel?

Isn't
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
going to fix all the problems?


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

Re: getting kernel-devel added

2017-09-12 Thread Eric Sandeen 
On 9/12/17 10:49 AM, Matthew Miller wrote:
> On Tue, Sep 12, 2017 at 11:35:08AM -0400, Ben Williams wrote:
>> case A) Students are using Fedora on windows in a VM (Vbox in this
>> case) for a class. they are required for said class to install the
>> guest additions. they are constantly running into errors that the
>> guest addidions will not build  (there install does not have
>> kernel-devel install.  They used the F26 release so now have the
>> release kernel and so they install sudo dnf install kernel-devel and
>> still have issues (kernel and kernel-devel versions do not match).
> 
> Isn't the solution here for the guest addons to require kernel-devel?

That was my thought as well, though the addons may be circumventing
the whole rpm/dnf mechanism for all I know.
 
>> Case B) third party video or wireless driver same issue no
>> kernel-devel, no wireless no internet == fix by sneakernet
> 
> Also same?

Well, if you need it for wireless, and you only have wireless, requiring
it doesn't help much if you can't retrieve it over your non-functioning
network card.  Still, I'm not sure that's a problem for Fedora to solve?

OTOH installing kernel-devel by default isn't too heavyweight, I think.

-Eric

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

Re: getting kernel-devel added

2017-09-12 Thread Matthew Miller 
On Tue, Sep 12, 2017 at 11:35:08AM -0400, Ben Williams wrote:
> case A) Students are using Fedora on windows in a VM (Vbox in this
> case) for a class. they are required for said class to install the
> guest additions. they are constantly running into errors that the
> guest addidions will not build  (there install does not have
> kernel-devel install.  They used the F26 release so now have the
> release kernel and so they install sudo dnf install kernel-devel and
> still have issues (kernel and kernel-devel versions do not match).

Isn't the solution here for the guest addons to require kernel-devel?

> Case B) third party video or wireless driver same issue no
> kernel-devel, no wireless no internet == fix by sneakernet

Also same?

-- 
Matthew Miller

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

Re: Testing graphical applications inside mock fails

2017-09-12 Thread Samuel Rakitničan 
Thank you for your detailed answer!

> Short answer:
> 
> # mknod /dev/dri/card0 c 226 0

The error messages about drm device are gone if I manually create the character 
file inside the chroot. However the original issue remains the same. Tried a 
GTK application easystroke however and that seems to work fine even without a 
drm device, so maybe it has to do something with Qt. The Qt application 
camotics gives a bunch of these messages.

X Error: BadAccess (attempt to access private resource denied) 10
  Extension:130 (MIT-SHM)
  Minor opcode: 1 (X_ShmAttach)
  Resource id:  0x131
X Error: BadShmSeg (invalid shared segment parameter) 128
  Extension:130 (MIT-SHM)
  Minor opcode: 5 (X_ShmCreatePixmap)
  Resource id:  0x280005f
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x2800060
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x2800060
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x2800060
...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

getting kernel-devel added

2017-09-12 Thread Ben Williams 

hello

This is an issue i am seeing with new users:

I was at a University installfest this weekend and this was the major 
issues for Endusers.


case A) Students are using Fedora on windows in a VM (Vbox in this case) 
for a class. they are required for said class to install the guest 
additions. they are constantly running into errors that the guest 
addidions will not build  (there install does not have kernel-devel 
install.  They used the F26 release so now have the release kernel and 
so they install sudo dnf install kernel-devel and still have issues 
(kernel and kernel-devel versions do not match).


Case B) third party video or wireless driver same issue no kernel-devel, 
no wireless no internet == fix by sneakernet



Both of these issues can be easily fixed by including kernel-devel in a 
group or by adding kernel-devel to all the Desktop Environment kickstarts.


To me this simple fix will help our new users and will not leave such a 
unfriendly feeling (and hopeful increase our contributor base down the road)


Ben

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

Re: Fedora 27 Beta blocker status mail #1

2017-09-12 Thread Peter Robinson 
On Tue, Sep 12, 2017 at 3:32 AM, Adam Williamson
 wrote:
> Hi folks! Time for an update on the Fedora 27 Beta status.
>
> tl;dr action summary
> 
>
> Accepted blockers
> -
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1489164
> ACTION: QA to test and karma update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-fee0766883
> then check whether backgrounds are fixed for all blocking desktops
> after compose run with update included.
>
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=1487867
> ACTION: QA to test and karma update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-a8b4e05ef3
>
> 3. https://bugzilla.redhat.com/show_bug.cgi?id=1487305
> ACTION: kernel team to provide a suitable update, ARM QA to test it
>
> 4. https://bugzilla.redhat.com/show_bug.cgi?id=1475570
> ACTION: anaconda and LVM folks to co-ordinate and provide a fix
>
> 5. https://bugzilla.redhat.com/show_bug.cgi?id=1170803
> ACTION: QA to confirm this is fixed already
>
> 6. https://bugzilla.redhat.com/show_bug.cgi?id=1483170
> ACTION: lvrabec to fix remaining SELinux denials during FreeIPA
> deployment
>
> Proposed blockers
> -
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1490072
> ACTION: QA to test and see how commonly encountered, desktop team to fix
>
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=1489862
> ACTION: QA to answer outstanding questions in bug
>
> Test coverage
> -
>
> QA to cover several missing tests (see below for details), stand by to
> test with new validation compose soon.
>
>
>
> Bug-by-bug detail
> =
>
> Accepted blockers
> -
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1489164 - distribution - NEW
>Fedora 27 Beta backgrounds must be different from Fedora 26
>
> This is kind of a tracker for all the work that's needed to get the
> backgrounds updated in all blocking desktops. We now have the package
> reviewed and submitted as an update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-fee0766883
> with the desktop-backgrounds changes included, but there may be
> other changes needed also. So at the least we need karma for that
> update, then we need to figure out what else needs to change to ensure
> at least Xfce, GNOME and KDE have the updated backgrounds.
>
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=1487867 - grub2 - ON_QA
>Wrong version on legacy variant (e.g. grub2-pc) Obsoletes:
>
> This is the bug that causes upgrades to choke on grub2 package
> dependencies. An update is available and just needs testing and karma -
> you should be able to test just by verifying that the issues no longer
> appear if you try upgrading with the updates-testing repo enabled.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-a8b4e05ef3
>
> 3. https://bugzilla.redhat.com/show_bug.cgi?id=1487305 - kernel - MODIFIED
>Raspberry Pi 3: run-initial-setup hangs
>
> Peter's done a build that ought to fix this, but not yet submitted an
> update - so we either need a new update created, or the existing update
> for kernel-4.13.0-1.fc27 edited to include the new build. Ideally we'd
> prefer a build with just what's in the frozen repos now plus the fix
> for this, but the 4.13.0-1.fc27 update has been in testing for a while
> and has +2 karma, so it probably works OK. However, there's another
> issue: both 4.13.0-1 and 4.13.1-301 were built with debugging enabled,
> and I think we usually ship Beta with debugging disabled. So we kinda
> need another build with debugging disabled, I think.

I think we usually leave debugging off once we branch letting rawhide
continue on down the debug route, must have slipped through the
cracks, have kicked off a 302 and will submit that as an update on
completion.

> 4. https://bugzilla.redhat.com/show_bug.cgi?id=1475570 - lvm2 - NEW
>Rescue mode fails while trying to access LVM volumes from existing install
>
> This is a failure of the installer's rescue mode when trying to mount
> LVM volumes from an existing Fedora install. There's no fix built yet,
> but there's some suggestion of a 'quick fix' that could be done on the
> anaconda side in the bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1475570#c13
> We need someone to take charge of deciding how to fix this, and...fix
> it.
>
> 5. https://bugzilla.redhat.com/show_bug.cgi?id=1170803 - python-blivet - ON_QA
>calls e2fsck on all ext volumes, provides no status indicator, and hangs 
> indefinitely if e2fsck doesn't exit
>
> This is almost certainly fixed, we just need someone to test and
> confirm with a system where the effect is obvious. The fix has actually
> broken filesystem resizing in most cases, but that technically blocks
> Final rather than Beta.
>
> 6. https://bugzilla.redhat.com/show_bug.cgi?id=1483170 - 
> selinux-policy-targeted - MODIFIED
>'map' denial for comm 'ns-slapd' path 
> '/run/dirsrv/slapd-DOMAIN-LOCAL.stats' (breaks FreeIPA deployment)
>
> The specific denial

Fedora 27 Beta blocker status mail #1

2017-09-12 Thread Adam Williamson 
Hi folks! Time for an update on the Fedora 27 Beta status.

tl;dr action summary


Accepted blockers
-

1. https://bugzilla.redhat.com/show_bug.cgi?id=1489164
ACTION: QA to test and karma update:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-fee0766883
then check whether backgrounds are fixed for all blocking desktops
after compose run with update included.

2. https://bugzilla.redhat.com/show_bug.cgi?id=1487867
ACTION: QA to test and karma update:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a8b4e05ef3

3. https://bugzilla.redhat.com/show_bug.cgi?id=1487305
ACTION: kernel team to provide a suitable update, ARM QA to test it

4. https://bugzilla.redhat.com/show_bug.cgi?id=1475570
ACTION: anaconda and LVM folks to co-ordinate and provide a fix

5. https://bugzilla.redhat.com/show_bug.cgi?id=1170803
ACTION: QA to confirm this is fixed already

6. https://bugzilla.redhat.com/show_bug.cgi?id=1483170
ACTION: lvrabec to fix remaining SELinux denials during FreeIPA
deployment

Proposed blockers
-

1. https://bugzilla.redhat.com/show_bug.cgi?id=1490072
ACTION: QA to test and see how commonly encountered, desktop team to fix

2. https://bugzilla.redhat.com/show_bug.cgi?id=1489862
ACTION: QA to answer outstanding questions in bug

Test coverage
-

QA to cover several missing tests (see below for details), stand by to
test with new validation compose soon.



Bug-by-bug detail
=

Accepted blockers
-

1. https://bugzilla.redhat.com/show_bug.cgi?id=1489164 - distribution - NEW
   Fedora 27 Beta backgrounds must be different from Fedora 26

This is kind of a tracker for all the work that's needed to get the
backgrounds updated in all blocking desktops. We now have the package
reviewed and submitted as an update:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-fee0766883
with the desktop-backgrounds changes included, but there may be
other changes needed also. So at the least we need karma for that
update, then we need to figure out what else needs to change to ensure
at least Xfce, GNOME and KDE have the updated backgrounds.

2. https://bugzilla.redhat.com/show_bug.cgi?id=1487867 - grub2 - ON_QA
   Wrong version on legacy variant (e.g. grub2-pc) Obsoletes:

This is the bug that causes upgrades to choke on grub2 package
dependencies. An update is available and just needs testing and karma -
you should be able to test just by verifying that the issues no longer
appear if you try upgrading with the updates-testing repo enabled.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a8b4e05ef3

3. https://bugzilla.redhat.com/show_bug.cgi?id=1487305 - kernel - MODIFIED
   Raspberry Pi 3: run-initial-setup hangs

Peter's done a build that ought to fix this, but not yet submitted an
update - so we either need a new update created, or the existing update
for kernel-4.13.0-1.fc27 edited to include the new build. Ideally we'd
prefer a build with just what's in the frozen repos now plus the fix
for this, but the 4.13.0-1.fc27 update has been in testing for a while
and has +2 karma, so it probably works OK. However, there's another
issue: both 4.13.0-1 and 4.13.1-301 were built with debugging enabled,
and I think we usually ship Beta with debugging disabled. So we kinda
need another build with debugging disabled, I think.

4. https://bugzilla.redhat.com/show_bug.cgi?id=1475570 - lvm2 - NEW
   Rescue mode fails while trying to access LVM volumes from existing install

This is a failure of the installer's rescue mode when trying to mount
LVM volumes from an existing Fedora install. There's no fix built yet,
but there's some suggestion of a 'quick fix' that could be done on the
anaconda side in the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1475570#c13
We need someone to take charge of deciding how to fix this, and...fix
it.

5. https://bugzilla.redhat.com/show_bug.cgi?id=1170803 - python-blivet - ON_QA
   calls e2fsck on all ext volumes, provides no status indicator, and hangs 
indefinitely if e2fsck doesn't exit

This is almost certainly fixed, we just need someone to test and
confirm with a system where the effect is obvious. The fix has actually
broken filesystem resizing in most cases, but that technically blocks
Final rather than Beta.

6. https://bugzilla.redhat.com/show_bug.cgi?id=1483170 - 
selinux-policy-targeted - MODIFIED
   'map' denial for comm 'ns-slapd' path '/run/dirsrv/slapd-DOMAIN-LOCAL.stats' 
(breaks FreeIPA deployment)

The specific denial initially reported here is fixed, but there are
still denials preventing FreeIPA server deployment working with the
latest selinux-policy that has reached stable (-280), so we need
Lukas to fix those. I have listed the remaining denials in this bug
and in #1488404.


Proposed blockers
-

1. https://bugzilla.redhat.com/show_bug.cgi?id=1490072 - gnome-shell - ASSIGNED
   Program terminated with signal SIGSEGV, Segmentation fault. #0 
0x7f16279aa6

Re: Testing graphical applications inside mock fails

2017-09-12 Thread Adam Jackson 
On Tue, 2017-09-12 at 12:35 +, Samuel Rakitničan wrote:
> Hi,
> 
> I am trying to test graphical application inside mock chroot
> environment as documented on Fedora wiki [1], but I am unable to do
> that successfully. In addition to that instructions I've installed
> mesa-dri-drivers and mesa-libGL inside the chroot as there were
> messages about missing files. But still no luck, some applications
> appear with an incomplete window, other ones without any. All
> applications that i have tested have a common error messages:
> 
> libGL error: failed to open drm device: No such file or directory
> libGL error: failed to load driver: i965
> 
> Is it possible to do that?

Short answer:

# mknod /dev/dri/card0 c 226 0

Long answer:

You're apparently trying to test the app inside the mock chroot by
having it display on an X server outside that chroot. When GL tries to
initialize it will ask the X server for the /dev node for the GPU, but
nothing inside the chroot has created it.

If all you need to test the application is to run some non-interactive
test suite, you may find xvfb-run(1) in the xorg-x11-server-Xvfb
package to be a better fit. This will create a virtual X server running
inside the chroot, detached from any hardware, and will use a software
GL driver if necessary.

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

Testing graphical applications inside mock fails

2017-09-12 Thread Samuel Rakitničan 
Hi,

I am trying to test graphical application inside mock chroot environment as 
documented on Fedora wiki [1], but I am unable to do that successfully. In 
addition to that instructions I've installed mesa-dri-drivers and mesa-libGL 
inside the chroot as there were messages about missing files. But still no 
luck, some applications appear with an incomplete window, other ones without 
any. All applications that i have tested have a common error messages:

libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: i965

Is it possible to do that?


[1] 
https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Testing_graphical_applications_inside_mock
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Raising requirement for application icons in GNOME Software

2017-09-12 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 01, 2017 at 08:12:22PM +0100, Richard Hughes wrote:
> Hi all,
> 
> At the moment the appstream-builder requires a 48x48px application
> icon[1] to be included in the AppStream metadata. I'm sure it's no
> surprise that 48x48 padded to 64x64 and then interpolated up to
> 128x128 (for HiDPI screens) looks pretty bad. For F28 and higher I'm
> going to raise the minimum size to 64x64 which I hope people realize
> is actually a really low bar. I'm not sure whether to mass file bugs
> or just try to contact maintainers directly.

I'd suggest
a) asking maintainers to provide 128x128 icons immediately
   (having two transitions is more painful than one, and the amount
of work required to get a bigger icon is the same)
b) provide a longer and softer transition period
   (open bugs now, but keep showing all the applications that have
small icons in F28. This way the user experience is not degraded.)

The list of packages is pretty big, so it'll certainly take a while
for all of them to be updated.

From the other branch in the thread:
> Most maintainers are not graphic artists. Moreover if they had available an
> higher resolution icon, they would already ship it.
>
> I also don't think that nagging upstream about these missing icons is
> really welcome - most of the times even upstream doesn't have a graphic
> artist available.
>
> I believe the correct way to solve this issue is that Fedora Design team
> (if available) provides new icons to upstream.

Often upstream has a source file from which the icon and graphics for
a website are derived. In those cases generating a larger icon is pretty
easy, and "nagging" upstream is the way to go.

Zbyszek

> Affected packages are:
> 
> abbayedesmorts-gpl
> alienarena
> antimicro
> ardour2
> armacycles-ad
> asylum
> atanks
> avogadro
> BlockOutII
> balsa
> banshee
> barrage
> bastet
> boswars
> btanks
> btbuilder
> COPASI-gui
> camorama
> cardpeek
> ccdciel
> celestia
> clanbomber
> colorful
> crawl-tiles
> crossfire-client
> crrcsim
> curblaster
> denemo
> dreampie
> dsi
> edb
> emacs-common-proofgeneral
> enigma
> escape
> flacon
> fontmatrix
> freedink-engine
> freedoom
> GLC_Player
> gdesklets
> geeqie
> geomorph
> gkrellm
> gnofract4d
> gnome-commander
> gonvert
> gpsim
> gramps
> groovy
> gtimelog
> gvrng
> gwget
> hdfview
> hercstudio
> hexglass
> hgview
> hitori
> hugin
> iapetal
> indistarter
> k3d
> key-mon
> kgpg
> kgraphviewer
> kolourpaint
> lbrickbuster2
> libreatlas
> lpf
> luminance-hdr
> Maelstrom
> mcomix
> megaglest-data
> monobristol
> moserial
> mtpaint
> netpanzer
> nogravity
> nut-nutrition
> okteta
> openstv
> ostrichriders
> overgod
> pdfshuffler
> peg-solitaire
> phoronix-test-suite
> pinball
> pingus
> plotdrop
> portecle
> pybliographer
> python3-tools
> qalculate-gtk
> qcomicbook
> qdirstat
> qgit
> qjackctl
> qsynth
> Ri-li
> rafkill
> rocksndiamonds
> scorched3d
> screengrab
> sfxr
> simple-ccsm
> sir
> slashem
> spectacle
> supertux
> tennix
> tilda
> tremulous
> tuxtype2
> tvtime
> tworld
> ufraw
> uqm
> uzbl-defaults
> valyriatear
> vavoom-*
> vdrift
> virtualplanet
> wammu
> xawtv
> xemacs
> xmedcon
> xmoto
> xpilot-ng
> xskat
> xzgv
> yoshimi
> 
> Ideas, flames, welcome.
> 
> Richard.
> 
> [1] 
> https://github.com/hughsie/appstream-scripts/blob/master/fedora/fedora-rawhide.sh#L9
> ___
> 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