Re: Noarch package with arched tests

[Björn 'besser82' Esser]

Am 26.02.2017 um 23:13 schrieb Susi Lehtola:

Hi,


I've packaged pybind11 which is a seamless interface between Python 
and C++11. This is a headers-only package, which would make it 
noarch... However, it also carries a testsuite, which - of course - is 
important to run on all architectures.


Is there some nifty trick to trick the build system to build the 
package on all arches simultaneously while making the headers package 
noarch?


If there were any binaries produced by the package, this would be 
easily accomplished, but I don't think there's any sense in shipping 
e.g. the testsuite just to make the headers noarch.


(Of course, should pybind11 develop a runtime library, then 
pybind11-devel would also include symlinks to the library, making it 
no longer a noarch package!)


Since you would build it like any python-package (python2 / python3 
sub-packages), it's pretty easy to run the testsuite on all arches: 
Simply move the "BuildArch: noarch" from the main-package to all 
sub-packages.


Example:

# This package ships no binaries, thus no debuginfo is available.
%global debug_package %{nil}


Name: python-pybind11
…
BuildRequires: …
# No BuildArch here!!!

%package -n python2-pybind11
…
BuildArch: noarch

…

%package -n python3-pybind11
…
BuildArch: noarch

…

%check
#Run tests here.


This will make the package be build on all arches, but simply generate 
noarch-packages.


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

Re: ABRT complaints

[Miroslav Suchý]

Dne 25.2.2017 v 17:04 Michael Catanzaro napsal(a):
> I'm wondering if ABRT is still actively-developed since one of the main
> developers left Red Hat recently.

Yes. It is still actively developed. You are welcome to read our blog where we 
post news about ABRT:
  https://abrt.github.io/

> I have a few complaints that have
> been annoying me for some time:

I understand you. There is plenty of space for improvements. However we have 
limited resources. And various priorities.

Our priorities for upcoming months/weeks are:
* integrate with Cockpit so sysadmin can easily see and report crashes 
happening on server.
* integrate with OpenShift so management node is aware of crashes in containers.
* and some tasks for RH internal ABRT server for customers.

Better heuristics for guessing sensitive data and duplicate bugs is very very 
non-trivial task. And we are unable to
make improvements here in matter of weeks. So please be patient or even better 
- send some patches.

Yet, I thank you for those 3 uses-cases, I will share them with other team 
members.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Martin Gansser]

on fedora the build process of vdr-epg-daemon fails with this message:

make install-systemd
make[1]: Entering directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
cat contrib/epgd.service | sed s:"":"/usr/bin":g | sed 
s:"":"mariadb.service":g | sed s:"":"/usr/lib64/epgd":g | 
install -C -D /dev/stdin 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
chmod a+r 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
cat contrib/epghttpd.service | sed s:"":"/usr/bin":g | install -C -D 
/dev/stdin 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
chmod a+r 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
systemctl daemon-reload
Failed to connect to bus: No such file or directory
make[1]: Leaving directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
make[1]: *** [Makefile:121: install-systemd] Error 1
make: *** [Makefile:97: install] Error 2

rpm spec file:
http://pkgs.fedoraproject.org/cgit/rpms/vdr-epg-daemon.git/tree/vdr-epg-daemon.spec

# for now i removed systemctl daemon-reload from Makefile
sed -i -e 's|systemctl daemon-reload||' Makefile

Is there any other solution ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Florian Weimer]

On 02/27/2017 10:32 AM, Martin Gansser wrote:

on fedora the build process of vdr-epg-daemon fails with this message:

make install-systemd
make[1]: Entering directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
cat contrib/epgd.service | sed s:"":"/usr/bin":g | sed s:"":"mariadb.service":g | sed 
s:"":"/usr/lib64/epgd":g | install -C -D /dev/stdin 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
chmod a+r 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
cat contrib/epghttpd.service | sed s:"":"/usr/bin":g | install -C -D 
/dev/stdin 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
chmod a+r 
/builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
systemctl daemon-reload
Failed to connect to bus: No such file or directory
make[1]: Leaving directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
make[1]: *** [Makefile:121: install-systemd] Error 1
make: *** [Makefile:97: install] Error 2


This is an upstream makefile bug.  Preparing an installation tree should 
not attempt to reload or restart system daemons.  In a mock chroot, this 
does not work because typically, systemd is not running inside the chroot.


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

Re: Touchpad pointer accel - testers required, scratch build available

[Piotr Popieluch]

On Fri, Feb 24, 2017 at 12:35 AM, Peter Hutterer 
wrote:

> I've been playing with touchpad pointer acceleration in libinput again and
> finally found something I'm happy with. Most notably it has a wide range of
> configurable speed settings, from "tar" to "speed-skating ring". Please
> give
> this scratch build a test and let me know how you go:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245
>
>
After installing it feels more accurate with small movements, which is an
improvement. On both versions the acceleration could be larger for me, I
cannot move the pointer from one corner of the screen to the opposite one
with one finger movement. The touchpad speed slider in mouse and touchpad
settings is on max already.

This is on a Dell XPS 13 9360 with HiDPI screen.

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

Re: Fedora rawhide compose report: 20170225.n.0 changes

[Alexander Bokovoy]

On la, 25 helmi 2017, Fedora Rawhide Report wrote:

[freeipa]
freeipa-client-4.4.3-5.fc26.aarch64 requires /usr/libexec/system-python2

This dependency is auto-generated by a build system in Rawhide. There is
no explicit dependency in FreeIPA that leads to this.

We have bug https://bugzilla.redhat.com/show_bug.cgi?id=1426847 which I
now moved to python2 folks.

As it stands, this bug prevents FreeIPA from being installable in
Rawhide.

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

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Martin Gansser]

> On 02/27/2017 10:32 AM, Martin Gansser wrote:
> 
> This is an upstream makefile bug.  Preparing an installation tree should 
> not attempt to reload or restart system daemons.  In a mock chroot, this 
> does not work because typically, systemd is not running inside the chroot.
> 
> Florian

The developer told me the following: ( 
https://projects.vdr-developer.org/issues/2476#note-3 )
If you are in normal environment, you get without a reload after systemd always 
messages that a reload still pending.
Is there a flag, for example, 'DO_NOT_RELOAD_INIT_SYSTEM', which is given for 
the build in an installation tree? Or how do you recognize that you are in an 
installation tree? Primarily, the "make install" is designed for live 
environments.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Florian Weimer]

On 02/27/2017 11:49 AM, Martin Gansser wrote:

On 02/27/2017 10:32 AM, Martin Gansser wrote:

This is an upstream makefile bug.  Preparing an installation tree should
not attempt to reload or restart system daemons.  In a mock chroot, this
does not work because typically, systemd is not running inside the chroot.

Florian


The developer told me the following: ( 
https://projects.vdr-developer.org/issues/2476#note-3 )
If you are in normal environment, you get without a reload after systemd always 
messages that a reload still pending.
Is there a flag, for example, 'DO_NOT_RELOAD_INIT_SYSTEM', which is given for the build 
in an installation tree? Or how do you recognize that you are in an installation tree? 
Primarily, the "make install" is designed for live environments.


A set DESTDIR variable should be a good approximation to that.

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

Re: Noarch package with arched tests

[Kevin Kofler]

Susi Lehtola wrote:
> I've packaged pybind11 which is a seamless interface between Python and
> C++11. This is a headers-only package, which would make it noarch...
> However, it also carries a testsuite, which - of course - is important
> to run on all architectures.

Since Koji builds noarch packages on a random architecture, it will 
eventually hit all of them (law of large numbers). So I do not see this as a 
valid reason to make a package arch-dependent. The fact that there is a 
testsuite at all is already more testing than required.

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

Re: Noarch package with arched tests

[Ralf Corsepius]

On 02/26/2017 11:13 PM, Susi Lehtola wrote:

Hi,


I've packaged pybind11 which is a seamless interface between Python and
C++11. This is a headers-only package, which would make it noarch...


Cf. the "Packaging Header Only Libraries" section in the FPG.

These are required NOT to be noarched.


However, it also carries a testsuite, which - of course - is important
to run on all architectures.


This is one reason for the requirement mentioned above.

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

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Martin Gansser]

> On 02/27/2017 11:49 AM, Martin Gansser wrote:
> 
> A set DESTDIR variable should be a good approximation to that.
> 
> Florian
You mean something like here: ?

https://github.com/libreswan/libreswan/blob/master/initsystems/systemd/Makefile

installsystemdservice:
@mkdir -p $(SYSTEMDDIR)
$(INSTALL) $(INSTCONFFLAGS) $(SYSTEMDFILE) $(SYSTEMDDIR)
@if test $(SYSTEMDDIR) = ${UNITDIR} ; then \
systemctl --system daemon-reload ; \
fi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf group and dnf group list diff ?

[Honza Silhan]

Hi,

it seems like a bug.

Can you please report a bug here [1], include whole output of `dnf
group`, `dnf group summary`, `dnf list` and `cat
/var/lib/dnf/groups.json`?


Thanks,
Honza

[1] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf

On Fri, Feb 24, 2017 at 8:18 PM, Catalin  wrote:
> [root@localhost mythcat]# dnf group
> Last metadata expiration check: 0:28:47 ago on Fri Feb 24 13:27:40 2017.
> Installed Groups: 3
> Available Groups: 33
> [root@localhost mythcat]# dnf group list
> told me are more than 3 installed
>
> this is a error or bug ?
>
> ___
> 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: dnf group and dnf group list diff ?

[Cătălin George Feștilă]

no, is not my job

2017-02-27 14:23 GMT+02:00 Honza Silhan :

> Hi,
>
> it seems like a bug.
>
> Can you please report a bug here [1], include whole output of `dnf
> group`, `dnf group summary`, `dnf list` and `cat
> /var/lib/dnf/groups.json`?
>
>
> Thanks,
> Honza
>
> [1] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf
>
> On Fri, Feb 24, 2017 at 8:18 PM, Catalin  wrote:
> > [root@localhost mythcat]# dnf group
> > Last metadata expiration check: 0:28:47 ago on Fri Feb 24 13:27:40 2017.
> > Installed Groups: 3
> > Available Groups: 33
> > [root@localhost mythcat]# dnf group list
> > told me are more than 3 installed
> >
> > this is a error or bug ?
> >
> > ___
> > 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

Re: dnf group and dnf group list diff ?

[Jean-Baptiste Holcroft]

Le 2017-02-27 14:21, Cătălin George Feștilă a écrit :

no, is not my job



Outstanding! You just made my day :)
Seriously, the best way to fix the issue is to have the impacted user 
involved to provide necessary data and to confirm the solution works and 
remove unnecessary actors.
If you say: "fix it, but I don't care", nobody will do it... It probably 
isn't the job of anyone from the devel mailing list to fill this bug, 
but if you do so, you might find someone who has the responsibility to 
fix it (and talking about DNF, most probably a full time developer).


vă mulțumesc pentru înțelegere
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf group and dnf group list diff ?

[Michal Schorm]

I also wanted to write something simmilar.

but I checked Catalin, he uses Fedora for year (atleast) and he already
filed a buch of bugs

.
So I let it be as just a joke.

However I fully agree with you, Jean. :)



On Mon, Feb 27, 2017 at 2:45 PM, Jean-Baptiste Holcroft <
jean-bapti...@holcroft.fr> wrote:

> Le 2017-02-27 14:21, Cătălin George Feștilă a écrit :
>
>> no, is not my job
>>
>>
> Outstanding! You just made my day :)
> Seriously, the best way to fix the issue is to have the impacted user
> involved to provide necessary data and to confirm the solution works and
> remove unnecessary actors.
> If you say: "fix it, but I don't care", nobody will do it... It probably
> isn't the job of anyone from the devel mailing list to fill this bug, but
> if you do so, you might find someone who has the responsibility to fix it
> (and talking about DNF, most probably a full time developer).
>
> vă mulțumesc pentru înțelegere
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 

Michal Schorm
Core Services - Databases Team
mail: msch...@redhat.com
Brno-IRC: mschorm
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Kevin Puertas

[Charalampos Stratakis]

Welcome!

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Kevin Puertas Ruiz" 
To: devel@lists.fedoraproject.org
Sent: Saturday, February 25, 2017 4:46:11 PM
Subject: Self Introduction: Kevin Puertas

Hi, Im Kevin Puertas, an Spanish lover of technologies and Linux, and
trying to contribute to the world
For experience, with a friend we have some open source projects in
gitlab.com/JKANetwork
Im trying to submit a package to Fedora that is missing yet, notepadqq
https://bugzilla.redhat.com/show_bug.cgi?id=1426844

Thanks
___
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: dnf group and dnf group list diff ?

[Alexander Ploumistos]

On Mon, Feb 27, 2017 at 3:21 PM, Cătălin George Feștilă
 wrote:
> no, is not my job

That's cute.
Whose "job" is it then?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Florian Weimer]

On 02/27/2017 01:16 PM, Martin Gansser wrote:

On 02/27/2017 11:49 AM, Martin Gansser wrote:

A set DESTDIR variable should be a good approximation to that.

Florian

You mean something like here: ?

https://github.com/libreswan/libreswan/blob/master/initsystems/systemd/Makefile

installsystemdservice:
@mkdir -p $(SYSTEMDDIR)
$(INSTALL) $(INSTCONFFLAGS) $(SYSTEMDFILE) $(SYSTEMDDIR)
@if test $(SYSTEMDDIR) = ${UNITDIR} ; then \
systemctl --system daemon-reload ; \
fi


I suppose $(SYSTEMDDIR) (make variable) has DESTDIR applied, but 
${UNITDIR} (shell variable) does not?  Yes, then this is what I had in mind.


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

integrity verification for virtio-win driver archive

[Stefan Pietsch]

Dear developers,

I would appreciate having some checksum files for the virtio-win driver
archives located here:

https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/


Thanks!

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

Re: systemctl daemon-reload causes message "Failed to connect to bus: No such file or directory"

[Martin Gansser]

> On 02/27/2017 01:16 PM, Martin Gansser wrote:
> 
> I suppose $(SYSTEMDDIR) (make variable) has DESTDIR applied, but 
> ${UNITDIR} (shell variable) does not?  Yes, then this is what I had in mind.
> 
> Thanks,
> Florian
Problem solved, thanks.

-   systemctl daemon-reload
+   ifeq ($(DESTDIR),)
+   systemctl daemon-reload
+   endif
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25 compose report: changes

[Fedora Branched Report]

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

Re: initial-setup accepts weak passwords

[Martin Kolman]

On Sun, 2017-02-26 at 13:42 +, jcol...@redhat.com wrote:
> Hi,
> 
> The initial-setup just after the installation of Fedora 25 (or any
> version) accepts weak passwords for root and the other users created
> after the installation. I tried the password 'a' and it accepted
> without any strict verification. Found this in Fedora 25, but I think
> it is the same for all versions, including Rawhide.s a bug ?
I have just installed Fedora 25 & latest Rawhide (netinst image) with
the KDE Environment, so that Initial Setup shows up (Gnome Initial
Setup shows up for the Fedora Workstation environment) after reboot.

In both cases Initial Setup shows up after the installation and
provides just the option to create a user.

Next I've tried to use "a" as password:
- Initial Setup tells me the password is weak
- I have to press done twice to confirm I'm OK with such a weak
password

This behavior looks quite correct to me - the user it told the password
is bad & has to confirm using it. 

Also there has bee no option to set root password in Initial Setup. Are
you possibly using a kickstart with "firstboot --enable --reconfig"[0]
? That switches Initial Setup into reconfig mode where it *is* possible
 to set a root password in it. The reconfig mode is also used by the
Fedora ARM images.

[0] http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#fir
stboot


> 
> Thanks,
> Jos Collin
> ___
> 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: dnf group and dnf group list diff ?

[Cătălin George Feștilă]

sorry, my message came from this reasons:
1. I'm new into devel list and development under Fedora.
2. is a common issue under Fedora update by real developers how works with
dnf.
3. I find something into google search about hidden groups but I'm not sure
that is true into this bug.
into last few years Fedora come with many users accounts so
I'm wary at first indications of the reasons above.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Arm Support In FMW

[Adam Williamson]

On Tue, 2017-02-21 at 09:30 +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Arm Support In FMW =
> https://fedoraproject.org/wiki/Changes/ArmSupportInFmw
> 
> Change owner(s):
> * Martin Bříza 
> 
> Fedora Media Writer will gain the ability to write ARM images to SD
> cards and other portable media.
> 
> 
> == Detailed Description ==
> With ARM (ARMv7A) being one of the primary architectures of Fedora, we
> should support writing the images to bootable media for devices with
> this architecture.
> 
> This means Fedora Media Writer will have to list the ARM images, offer
> their download and be able to unpack them reliably (as they're shipped
> LZMA-compressed - .xz). Memory card support should be improved,
> especially in terms of reading drive information - many SD card
> drivers report wrong names, sizes and media presence.
> 
> This will come along with many more features in FMW, such as
> fullscreen screenshot preview, automatic FMW update check on Windows
> and Mac, better reliability and performance improvements.
> 
> 
> 
> == Scope ==
> * Proposal owners:
> Implementation of this Change
> 
> * Other developers:
> N/A (not a System Wide Change)
> 
> * Release engineering:
> N/A

> * List of deliverables:
> N/A (not a System Wide Change)

> * Policies and guidelines:
> N/A (not a System Wide Change)
> 
> * Trademark approval:
> N/A (not needed for this Change)

So this is another case where the 'system-wide' / 'self-contained'
split doesn't really work. This doesn't affect the functioning of
anyone's existing installed system, but it clearly has implications for
the wider project: if this becomes the 'official' delivery mechanism
for ARM users, that'll require changes to the download pages. And while
the Change page says " How To Test - N/A (not a System Wide Change)",
clearly this *will* need testing, especially before we make it the
primary delivery mechanism.
-- 
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

Fedora Rawhide-20170227.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Server dvd i386
Xfce raw-xz armhfp
Server boot i386
Atomic raw-xz x86_64

Failed openQA tests: 10/107 (x86_64), 1/2 (arm)

ID: 57880   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/57880
ID: 57881   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/57881
ID: 57899   Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/57899
ID: 57907   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/57907
ID: 57925   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/57925
ID: 57951   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/57951
ID: 57956   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/57956
ID: 57978   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/57978
ID: 57983   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/57983
ID: 57984   Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/57984
ID: 57986   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/57986

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

ID: 57874   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/57874
ID: 57875   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/57875
ID: 57876   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/57876
ID: 57877   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/57877
ID: 57879   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/57879
ID: 57889   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/57889
ID: 57895   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/57895
ID: 57896   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/57896
ID: 57927   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/57927
ID: 57928   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/57928
ID: 57930   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/57930
ID: 57931   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/57931
ID: 57933   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/57933
ID: 57934   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/57934
ID: 57935   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/57935
ID: 57936   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/57936
ID: 57937   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/57937
ID: 57938   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/57938
ID: 57939   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/57939
ID: 57940   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/57940
ID: 57941   Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/57941
ID: 57942   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/57942
ID: 57943   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/57943
ID: 57944   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/57944
ID: 57945   Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/57945
ID: 57946   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/57946
ID: 57947   Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/57947
ID: 57948   Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/57948
ID: 57949   Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/57949
ID: 57950   Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/57950
ID: 57953   Test: x86_6

Re: F26 Self Contained Change: Arm Support In FMW

[Martin Bříza]

On Mon, 27 Feb 2017 17:56:24 +0100, Adam Williamson  
 wrote:



On Tue, 2017-02-21 at 09:30 +0100, Jan Kurik wrote:

= Proposed Self Contained Change: Arm Support In FMW =
https://fedoraproject.org/wiki/Changes/ArmSupportInFmw

Change owner(s):
* Martin Bříza 

Fedora Media Writer will gain the ability to write ARM images to SD
cards and other portable media.


== Detailed Description ==
With ARM (ARMv7A) being one of the primary architectures of Fedora, we
should support writing the images to bootable media for devices with
this architecture.

This means Fedora Media Writer will have to list the ARM images, offer
their download and be able to unpack them reliably (as they're shipped
LZMA-compressed - .xz). Memory card support should be improved,
especially in terms of reading drive information - many SD card
drivers report wrong names, sizes and media presence.

This will come along with many more features in FMW, such as
fullscreen screenshot preview, automatic FMW update check on Windows
and Mac, better reliability and performance improvements.



== Scope ==
* Proposal owners:
Implementation of this Change

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
N/A



* List of deliverables:
N/A (not a System Wide Change)



* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)


So this is another case where the 'system-wide' / 'self-contained'
split doesn't really work. This doesn't affect the functioning of
anyone's existing installed system, but it clearly has implications for
the wider project: if this becomes the 'official' delivery mechanism
for ARM users, that'll require changes to the download pages. And while
the Change page says " How To Test - N/A (not a System Wide Change)",
clearly this *will* need testing, especially before we make it the
primary delivery mechanism.


Yeah, you're right.
I'm intending this as a smaller change that will just make this  
functionality available. However, I don't mean to push this as a primary  
way how to ship Fedora ARM images - there are some specifics that the tool  
won't handle before F26 (and maybe ever), like resizing the partitions  
after writing it and maybe some hardware-specific cases.
Regarding the test cases, these will be necessary, yes. I'm going to add  
them as an optional part of the FMW verification matrix.

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

Re: F26 Self Contained Change: Arm Support In FMW

[Adam Williamson]

On Mon, 2017-02-27 at 18:22 +0100, Martin Bříza wrote:
> 
> Yeah, you're right.
> I'm intending this as a smaller change that will just make this  
> functionality available. However, I don't mean to push this as a primary  
> way how to ship Fedora ARM images - there are some specifics that the tool  
> won't handle before F26 (and maybe ever), like resizing the partitions  
> after writing it and maybe some hardware-specific cases.
> Regarding the test cases, these will be necessary, yes. I'm going to add  
> them as an optional part of the FMW verification matrix.

Thanks for the info on scope, if this is only intended as a feature
addition for now, it does reduce the impact on other teams for sure. We
can certainly still put together some validation tests and/or a test
day if it would be helpful, though.
-- 
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

VMware and Linux 4.10

[Dominik Kucher]

Hi!

Works VMware with Linux 4.10 out of the box?


-- 

Dominik Kucher




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

Re: Fresh-built Fedora CANT boot !

[Dominik Kucher]

Linux try to boot

check the log files and post it to the list


Am 2017-02-26 um 23:58 schrieb مصعب الزعبي:
>
> Hi all
>
>
> Three days ago , I can build Fedora ISO and it's ran without problems.
>
>
> Today I build it successfully but can't boot !!
>
> http://207.244.97.131/%D9%84%D9%82%D8%B7%D8%A9%20%D8%B4%D8%A7%D8%B4%D8%A9%20%D9%85%D9%86%202017-02-27%2001-52-02.png
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 

Dominik Kucher




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

Re: policy on changes in or introduction of new dependencies

[Richard W.M. Jones]

On Wed, Feb 22, 2017 at 10:53:01PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Dear Fedora developers,
> there have been a number of examples where an update in a stable branch
> brought in new dependencies and in significant numbers. The most recent
> case was discussed on this list even today:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BVUZWJYW2UVO53EZ2G2ALAQPU5PLDJZR/
> 
> I opened a ticket with FESCo to clarify the Updates Policy:
> https://pagure.io/fesco/issue/1682
> 
> In particular, I propose:
> * Mandating that all dependency changes in package updates must be
>   mentioned in the package's %changelog and justified.
> 
> * Mandating that all dependency changes in package updates in a stable
>   release MUST be mentioned in bodhi update release notes and justified.

Why does the packager have to do this, when bodhi itself could read
the before/after dependencies and fill in those details?

Rich.

> * Adding this to 
> https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
>   * Avoid updates that introduce any new dependencies
> 
> Thoughts?
> 
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: initial-setup accepts weak passwords

[Richard W.M. Jones]

On Sun, Feb 26, 2017 at 01:42:41PM -, jcol...@redhat.com wrote:
> Hi,
> 
> The initial-setup just after the installation of Fedora 25 (or any version) 
> accepts weak passwords for root and the other users created after the 
> installation. I tried the password 'a' and it accepted without any strict 
> verification. Found this in Fedora 25, but I think it is the same for all 
> versions, including Rawhide. Is this a bug ?

For the sake of those of us who install throwaway VMs for testing
all the time, please don't change this behaviour.  If people want
to use stupid passwords, let them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Noarch package with arched tests

[Susi Lehtola]

On 02/27/2017 03:36 AM, Ralf Corsepius wrote:

On 02/26/2017 11:13 PM, Susi Lehtola wrote:

Hi,


I've packaged pybind11 which is a seamless interface between Python and
C++11. This is a headers-only package, which would make it noarch...


Cf. the "Packaging Header Only Libraries" section in the FPG.

These are required NOT to be noarched.


Thanks, I just landed on that section myself!
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: policy on changes in or introduction of new dependencies

[Dan Horák]

On Mon, 27 Feb 2017 18:15:32 +
"Richard W.M. Jones"  wrote:

> On Wed, Feb 22, 2017 at 10:53:01PM +0100, Dominik 'Rathann'
> Mierzejewski wrote:
> > Dear Fedora developers,
> > there have been a number of examples where an update in a stable
> > branch brought in new dependencies and in significant numbers. The
> > most recent case was discussed on this list even today:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BVUZWJYW2UVO53EZ2G2ALAQPU5PLDJZR/
> > 
> > I opened a ticket with FESCo to clarify the Updates Policy:
> > https://pagure.io/fesco/issue/1682
> > 
> > In particular, I propose:
> > * Mandating that all dependency changes in package updates must be
> >   mentioned in the package's %changelog and justified.
> > 
> > * Mandating that all dependency changes in package updates in a
> > stable release MUST be mentioned in bodhi update release notes and
> > justified.
> 
> Why does the packager have to do this, when bodhi itself could read
> the before/after dependencies and fill in those details?

right, let the machines do the work

or even ask/let the maintainer to confirm the changes as intentional
before going on with the update


Dan
 
> Rich.
> 
> > * Adding this to
> > https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
> >   * Avoid updates that introduce any new dependencies
> > 
> > Thoughts?
> > 
> > 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
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones Read my programming and
> virtualization blog: http://rwmj.wordpress.com libguestfs lets you
> edit virtual machines.  Supports shell scripting, bindings from many
> languages.  http://libguestfs.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

New automated test coverage: openQA tests of critical path updates

[Adam Williamson]

Hi folks!

I am currently rolling out some changes to the Fedora openQA deployment
which enable a new testing workflow. From now on, a subset of openQA
tests should be run automatically on every critpath update, both on
initial submission and on any edit of the update.

For the next little while, at least, this won't be incredibly visible.
openQA sends out fedmsgs for all tests, so you can sign up for FMN
notifications to learn about these results. They'll also be
discoverable from the openQA web UI - https://openqa.fedoraproject.org
. The results are also being forwarded to ResultsDB, so they'll be
visible via ResultsDB API queries and the ResultsDB web UI. But for
now, that's it...I think.

Our intent is to set up the necessary bits so that these results will
show up in the Bodhi web UI alongside the results for relevant
Taskotron tests. There's an outside possibility that Bodhi is actually
already set up to find these results in ResultsDB, in which case
they'll just suddenly start showing up in Bodhi - we should know about
that soon enough. :) But most likely Bodhi will need a bit of a tweak
to find them. This is probably a good thing, because we need to let the
tests run for a while to find out how reliable they are, and if there's
an unacceptable number of false negatives/positives. Once we have some
info on that and are happy that we can get things sufficiently reliable
for the results to be useful, we'll hook up the Bodhi integration.

The tests that are run are most of the tests that, on the 'compose
test' workflow, get run on the Server DVD and Workstation Live images
after installation. Between them they do a decent job of covering basic
system functionality. They also cover FreeIPA server and client setup,
and Workstation browser (Firefox) and terminal functionality. So
hopefully, if your critpath update completely breaks one of those basic
workflows, you'll find out about it before pushing it stable.

At present it looks like the Workstation tests may sometimes fail
simply because the base install gets stuck during boot for some reason;
I'm going to look into that this week. In testing so far the Server
tests seem fairly reliable, but I want to gather data from a few days
worth of test runs to see how those look. Once we start sending results
to Bodhi, I'll try and write up some basic instructions on how to
interpret and debug openQA test results; QA folks will also be
available in IRC and by email for help with this, of course.

You can see sample runs on Server:
https://openqa.stg.fedoraproject.org/tests/overview?groupid=1&build=FEDORA-2017-376ae2b92c&version=25&distri=fedora
and Workstation:
https://openqa.stg.fedoraproject.org/tests/overview?version=25&distri=fedora&build=FEDORA-2017-87896dfb59&groupid=1
the 'desktop_notifications_live' failure is a stale bit of data - that
test isn't actually run any more because obviously it makes no sense in
this context, but because it got run one time in early development,
openQA continues to show it for that update (it won't show for any
*other* update). The `desktop_update_graphical` fail is a good example
of the kind of issue I'll have to look into this week: it seems to have
failed because of an intermittent crasher bug in PackageKit, rather
than an issue in the update. We'll have to look at skipping known-
unreliable tests, or marking them somehow so you know the deal in
Bodhi, or automatically re-running them, or things along those lines.
-- 
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

Re: integrity verification for virtio-win driver archive

[Richard W.M. Jones]

On Mon, Feb 27, 2017 at 04:15:12PM +0100, Stefan Pietsch wrote:
> Dear developers,
> 
> I would appreciate having some checksum files for the virtio-win driver
> archives located here:
> 
> https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
> 

(CC to Cole)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: policy on changes in or introduction of new dependencies

[Adam Williamson]

On Mon, 2017-02-27 at 18:15 +, Richard W.M. Jones wrote:
> > * Mandating that all dependency changes in package updates in a stable
> >    release MUST be mentioned in bodhi update release notes and justified.
> 
> Why does the packager have to do this, when bodhi itself could read
> the before/after dependencies and fill in those details?

Bodhi could *list* them, but unless it got rather a lot smarter, it
couldn't *justify* them. ;)
-- 
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

-Wno-format vs. -Werror=format-security

[Jakub Jelinek]

Hi!

As you might know, redhat-rpm-config is adding -Wall -Werror=format-security
into $RPM_OPT_FLAGS/%{optflags} by default.
I've recently fixed a bug #1425825 where -Wall -Werror=format-security -Wall
or -Wall -Werror=format-security -Wformat etc. actually disabled the
-Wformat-security warning (unlike -Wall -Wformat-security -Wall etc. that
behaved as intended before).
Now, this change might have a consequence on some packages, in particular
e.g. if you append -Wno-format to the standard optflags in some Makefile,
you might get errors because -Wno-format doesn't disable the explicitly
specified suboptions like -Wformat-security and having -Wformat-security
enabled and -Wno-format is an error.  The fix is if you really need
to add -Wno-format, also add -Wno-format-security to cancel the default
-Werror=format-security provided by redhat-rpm-config.

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

Re: F26 Self Contained Change: Arm Support In FMW

[Peter Robinson]

>>> = Proposed Self Contained Change: Arm Support In FMW =
>>> https://fedoraproject.org/wiki/Changes/ArmSupportInFmw
>>>
>>> Change owner(s):
>>> * Martin Bříza 
>>>
>>> Fedora Media Writer will gain the ability to write ARM images to SD
>>> cards and other portable media.
>>>
>>>
>>> == Detailed Description ==
>>> With ARM (ARMv7A) being one of the primary architectures of Fedora, we
>>> should support writing the images to bootable media for devices with
>>> this architecture.
>>>
>>> This means Fedora Media Writer will have to list the ARM images, offer
>>> their download and be able to unpack them reliably (as they're shipped
>>> LZMA-compressed - .xz). Memory card support should be improved,
>>> especially in terms of reading drive information - many SD card
>>> drivers report wrong names, sizes and media presence.
>>>
>>> This will come along with many more features in FMW, such as
>>> fullscreen screenshot preview, automatic FMW update check on Windows
>>> and Mac, better reliability and performance improvements.
>>>
>>>
>>>
>>> == Scope ==
>>> * Proposal owners:
>>> Implementation of this Change
>>>
>>> * Other developers:
>>> N/A (not a System Wide Change)
>>>
>>> * Release engineering:
>>> N/A
>>
>>
>>> * List of deliverables:
>>> N/A (not a System Wide Change)
>>
>>
>>> * Policies and guidelines:
>>> N/A (not a System Wide Change)
>>>
>>> * Trademark approval:
>>> N/A (not needed for this Change)
>>
>>
>> So this is another case where the 'system-wide' / 'self-contained'
>> split doesn't really work. This doesn't affect the functioning of
>> anyone's existing installed system, but it clearly has implications for
>> the wider project: if this becomes the 'official' delivery mechanism
>> for ARM users, that'll require changes to the download pages. And while
>> the Change page says " How To Test - N/A (not a System Wide Change)",
>> clearly this *will* need testing, especially before we make it the
>> primary delivery mechanism.
>
>
> Yeah, you're right.
> I'm intending this as a smaller change that will just make this
> functionality available. However, I don't mean to push this as a primary way
> how to ship Fedora ARM images - there are some specifics that the tool won't
> handle before F26 (and maybe ever), like resizing the partitions after
> writing it and maybe some hardware-specific cases.
> Regarding the test cases, these will be necessary, yes. I'm going to add
> them as an optional part of the FMW verification matrix.

It would be nice if you also engaged with myself or the ARM SIG in
general too from both an implementation details PoV and a QA.

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

Re: Stuck maxima builds on aarch64

[Jerry James]

On Sat, Feb 25, 2017 at 1:12 PM, Jerry James  wrote:
> I fixed the mass rebuild FTBFS errors for clisp and ecl yesterday, and
> started a build of maxima due to changes in both clisp and ecl.
> Something is afoot.

Is there anybody here who can take a look at this?  The dnf
transaction is apparently still stuck on aarch64, 3 days later:

https://koji.fedoraproject.org/koji/taskinfo?taskID=18041410

Thank you,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

non-responsive maintainer for python-mimeparse

[Carl George]

Per the non-responsive maintainer policy [1], I would like to bring attention 
to a bug for python-mimeparse [2].  Does anyone know how to contact the 
maintainer jkaluza?

[1]: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1339379

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

Re: Noarch package with arched tests

[Björn 'besser82' Esser]

Am 27.02.2017 um 12:36 schrieb Ralf Corsepius:

On 02/26/2017 11:13 PM, Susi Lehtola wrote:

Hi,


I've packaged pybind11 which is a seamless interface between Python and
C++11. This is a headers-only package, which would make it noarch...


Cf. the "Packaging Header Only Libraries" section in the FPG.

These are required NOT to be noarched.


This is a Python-package from pypi, not a header only lib…  I don't see 
any reason for forcing the built binary packages to be archful… There is 
no configuration or anything going on in setup.py; it even drops all 
flies in %pythonX_sitelib.





However, it also carries a testsuite, which - of course - is important
to run on all architectures.


This is one reason for the requirement mentioned above.


That reason doesn't even make sense, since we can generate noarch'ed 
sub-packages from an archful package.


Can you elaborate a bit more about your statement, you made made without 
even looking at the sources, please?



Ralf


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

Re: Stuck maxima builds on aarch64

[Kevin Fenzi]

On Mon, 27 Feb 2017 14:28:14 -0700
Jerry James  wrote:

> On Sat, Feb 25, 2017 at 1:12 PM, Jerry James 
> wrote:
> > I fixed the mass rebuild FTBFS errors for clisp and ecl yesterday,
> > and started a build of maxima due to changes in both clisp and ecl.
> > Something is afoot.  
> 
> Is there anybody here who can take a look at this?  The dnf
> transaction is apparently still stuck on aarch64, 3 days later:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=18041410
> 
> Thank you,

Hey. I looked at this a few weeks ago... but I don't recall all the
details so I wanted to look more closely at it again before I replied. 

However, I have not had time since your orig email on saturday to do
so.

I'll try and look soon, but I'm afraid you will need some patience. 

kevin


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

Re: Self Introduction: Stephen Kitt

[Haïkel]

2017-02-23 18:48 GMT+01:00 Stephen Kitt :
> Hi everyone,
>
> As part of the "join the package collection maintainers" process, I'd like to
> introduce myself — I've just submitted my first review request
> (https://bugzilla.redhat.com/show_bug.cgi?id=1426333).
>
> I'm a long-standing free software user and packager, in the Debian world
> (https://qa.debian.org/developer.php?login=skitt). My packaging interests
> cover a wide spectrum, from games and emulators to toolchains and random
> interesting pieces of software. Some of you might have seen me at Devconf
> where I gave a presentation contrasting the processes for joining Debian and
> Fedora as a packaging contributor
> (https://www.youtube.com/watch?v=pGQFZPA6r8w). I work for Red Hat but
> packaging isn't a big part of my day job (although the request above is
> submitted using my @redhat.com account — it's for OpenDaylight, which is what
> I work on).
>
> I'm looking forward to adding some interesting software to Fedora!
>
> Regards,
>
> Stephen


Hi Stephen,

Welcome to see you here :)
Knowing Stephen afk, I trust him as a FOSS hacker and keen expert in (Debian)
packaging so I'm willing to sponsor him.

Regards,
H.

> ___
> 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

Builds not hitting rawhide

[Susi Lehtola]

Hi,


it seems there's a snag in the rawhide buildroot update. My F24 and F25 
buildroot overrides went into action ages ago, but rawhide still doesn't 
have a package I built hours ago.


I notice that according to
https://fedoraproject.org/wiki/Releases/26/Schedule

f26 is supposed to branch tomorrow from rawhide, is the problem I'm 
describing related to this?

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reviews Weekly

[nobody]

Start Date: 2017-02-20 10:08:01.321938
End Date: 2017-02-27 10:08:01.321938

Piotr Popieluch : 5

https://bugzilla.redhat.com/show_bug.cgi?id=1424859 nodejs-encodeurl
https://bugzilla.redhat.com/show_bug.cgi?id=1364230 
nodejs-loud-rejection
https://bugzilla.redhat.com/show_bug.cgi?id=1347899 
nodejs-fill-range
https://bugzilla.redhat.com/show_bug.cgi?id=1305718 nodejs-preserve
https://bugzilla.redhat.com/show_bug.cgi?id=1364156 
nodejs-parse-glob


Tom Hughes : 3

https://bugzilla.redhat.com/show_bug.cgi?id=1415438 nodejs-vasync
https://bugzilla.redhat.com/show_bug.cgi?id=1415437 
nodejs-safe-json-stringify
https://bugzilla.redhat.com/show_bug.cgi?id=1413295 nodejs-mv


Athos Ribeiro : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1425934 python-mtg
https://bugzilla.redhat.com/show_bug.cgi?id=1424632 python-iso3166


Neal Gompa : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1332306 libcxxabi
https://bugzilla.redhat.com/show_bug.cgi?id=1425190 
switchboard-plug-bluetooth


Raphael Groner : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1415331 enjarify
https://bugzilla.redhat.com/show_bug.cgi?id=1402445 myman


Remi Collet : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1424721 
php-maennchen-zipstream-php
https://bugzilla.redhat.com/show_bug.cgi?id=1360482 nextcloud


Zbigniew Jędrzejewski-Szmek : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1410953 python3-cffi
https://bugzilla.redhat.com/show_bug.cgi?id=1423390 prewikka


Charalampos Stratakis : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1391457 
python-netjsonconfig


Christian Dersch : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1425203 
python-speedtest-cli


Germano Massullo : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1123579 rubygem-colorize


Igor Gnatenko : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1395947 pydbus


Lameire Alexis : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1424634 python-iso-639


Patrick Huang : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1426516 
takari-smart-builder


Pavel Raiskup : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1421150 Request:


Petr Pisar : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1421582 
perl-namespace-sweep


Rex Dieter : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1422714 yank


Simone Caronni : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1403600 YafaRay


Tomas Tomecek : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1421856 etcd-container


Tony Asleson : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1425898 nvmetcli


leigh scott : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1424851 xplayer-plparser



Completed Review Requests: 31
This report was generated by bz-review-report.py.
The original source is available at: 
https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Test instances for Fedora Package Maintainers

[Kevin Fenzi]

Greetings. 

I've just finished setting up a new group of test machine instances for
package maintainers in the Fedora Infrastructure Private Cloud.
They now include ppc64 and ppc64le instances. 
(We hope to add aarch64 before too long). 

These instances should be faster and closer to repositories than
previous test instances, and require no special ssh config to use. 

Please see: 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
for more details and access information on all the available instances. 

These instances can help maintainers duplicate problems or gather
information from Fedora versions they may not have handy. 

Hope they help, 

kevin


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

Re: Builds not hitting rawhide

[Kevin Fenzi]

On Mon, 27 Feb 2017 16:29:03 -0800
Susi Lehtola  wrote:

> Hi,
> 
> 
> it seems there's a snag in the rawhide buildroot update. My F24 and
> F25 buildroot overrides went into action ages ago, but rawhide still
> doesn't have a package I built hours ago.
> 
> I notice that according to
> https://fedoraproject.org/wiki/Releases/26/Schedule
> 
> f26 is supposed to branch tomorrow from rawhide, is the problem I'm 
> describing related to this?

No. It's due to signing getting behind. :( 

* The ghc side tag was tagged in and needed signing (270 builds)

* The sign bridge crashed with a "MemoryError" and a weird kernel
  trace. Not sure what caused that, and it was rebooted/restarted, but
  was down for a ~30min or something. 

* I've been trying to sign f26 with the new f27 key (so after
  tomorrow's branching both f26 branch and f27 rawhide will be all
  signed). I've been keeping to small batches (1 package at a time
  basically) but I'm sure it's slowing down normal signing some. 

It looks like it's catching up... but still not there. ;( 

kevin


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

Re: Fedora Rawhide-20170227.n.0 compose check report

[Adam Williamson]

On Mon, 2017-02-27 at 17:25 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Atomic qcow2 x86_64

There seems to be some sort of problem in pungi-make-ostree:
https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log

DEBUG util.py:435:  + pungi-make-ostree tree 
--repo=/mnt/koji/compose/atomic/rawhide/ 
--log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2
 
--treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json
 
--extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
DEBUG util.py:435:  Traceback (most recent call last):
DEBUG util.py:435:File "/usr/bin/pungi-make-ostree", line 15, in 
DEBUG util.py:435:  ostree.main()
DEBUG util.py:435:File 
"/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line 85, in main
DEBUG util.py:435:  func()
DEBUG util.py:435:File 
"/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line 95, in run
DEBUG util.py:435:  repos = extra_source_repos + [{'name': 
'source_repo_from', 'baseurl': source_repo_from}]
DEBUG util.py:435:  TypeError: unsupported operand type(s) for +: 'NoneType' 
and 'list'

> Server dvd i386

Several i386 image composes still failing for the reason Kevin noted
recently:
dnf.exceptions.Error: Will not install a source rpm package 
(docker-anaconda-addon-0.4-4.fc26.src).

> Xfce raw-xz armhfp

Looks a bit odd:
https://kojipkgs.fedoraproject.org//work/tasks/1563/18091563/root.log
DEBUG util.py:435:  Unable to create appliance : Failed to find package 
'firefox' : no package matched: firefox
Is there an ARM-specific issue with the firefox package?

> Server boot i386
> Atomic raw-xz x86_64

See above.

> Failed openQA tests: 10/107 (x86_64), 1/2 (arm)
> 
> ID: 57880 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
> URL: https://openqa.fedoraproject.org/tests/57880

This is some kinda transient test fail, I think (openQA clicked in the
wrong place or the click got lost or something).

> ID: 57881 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/57881

This is now failing because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1405790
freeipa-client and freeipa-server can't be installed due to dep issues
with certmonger, and certmonger rebuild is failing.

> ID: 57899 Test: x86_64 Workstation-live-iso desktop_terminal
> URL: https://openqa.fedoraproject.org/tests/57899
> ID: 57907 Test: x86_64 Workstation-live-iso desktop_update_graphical
> URL: https://openqa.fedoraproject.org/tests/57907

These two failed because gnome-color-manager unexpectedly asked for
access to the system location immediately upon login, which the test
can't cope with:
https://bugzilla.gnome.org/show_bug.cgi?id=779343
We could adjust the test, but the GNOME behaviour seems odd, so waiting
for input from the devs on whether it's a bug.

> ID: 57925 Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/57925

We never get any video output from this test, with a 10 minute (IIRC)
boot timeout. pwhalen reports there's a showstopper with ARM atm
related to module loading:
https://bugzilla.redhat.com/show_bug.cgi?id=1422634
that may be causing this, or it may be something else.

> ID: 57951 Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/57951

This broke between 20170208 and 20170214, my best guess at what
happened is in the new bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1427359

> ID: 57956 Test: x86_64 universal install_software_raid@uefi
> URL: https://openqa.fedoraproject.org/tests/57956

This is an openQA console typing fail (sigh, still happens
occasionally). Test actually worked fine.

> ID: 57978 Test: x86_64 universal install_cyrillic_language
> URL: https://openqa.fedoraproject.org/tests/57978

Still https://bugzilla.redhat.com/show_bug.cgi?id=1413813 . If that
doesn't get any attention soon I may have to make the test work around
it to cover the rest of the test case...

> ID: 57983 Test: x86_64 universal install_rescue_encrypted
> URL: https://openqa.fedoraproject.org/tests/57983
> ID: 57984 Test: x86_64 universal install_rescue_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/57984

Still https://bugzilla.redhat.com/show_bug.cgi?id=1376638 . Looks like
there's now a PR to fix this, but it is not yet merged.

> ID: 57986 Test: x86_64 Workstation-live-iso 
> desktop_notifications_postinstall
> URL: https://openqa.fedoraproject.org/tests/57986

This is a hard fail caused by the same SELinux alert that causes all

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-02-28 from 15:00:00 to 16:00:00 UTC
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us [per video](https://meet.jit.si/fedora-modularity) or on 
[IRC](irc://chat.freenode.net/#fedora-modularity): #fedora-modularity on 
[FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5219/

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

Re: policy on changes in or introduction of new dependencies

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 24, 2017 at 04:51:42PM +, Daniel P. Berrange wrote:
> On Fri, Feb 24, 2017 at 04:24:16PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
> > > On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> > > > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> > > >  wrote:
> > > > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> > > > 
> > > > > I have nothing against delivering latest and greatest software to our
> > > > > users and this proposal is not against that goal, either. However,
> > > > > package maintainers are not supposed to simply take what upstream
> > > > > releases and pass it on to the users without considering the impact.
> > > > 
> > > > I think that may be the differing of opinions in this discussion as I
> > > > don't think there is a definitive answer. Some packagers believe that
> > > > whatever upstream requires to get the software is what happens, other
> > > > packagers believe that it isn't. Many packagers just want the XYZ
> > > > package to be there so they can build the thing they really care about
> > > > so if the upstream needed ten new dependencies.. we add 10 new
> > > > dependencies.
> > 
> > And that's fine. Just don't make me jump through hoops to find out why.
> > One sentence in the changelog or a pointer to upstream release notes is
> > all I'm asking for. That and a little bit of consideration if such an
> > update is really necessary in a stable release. Surely that's not much
> > to ask. Or is it?
> 
> I question how useful that is going to be in practice. Realistically the
> RPM changelog is going to say little more than
> 
> "Added new dependancy libfoo.so"
> 
> which isn't really adding any value IMHO. Explaining why a dependancy was
> added is useful, but that needs packagers to potentally understand the
> upstream app decision in significant detail, and such an explanation is
> often not simple enough to explain in a useful level of detail in an
> RPM changelog. Unless you want long paragraphs of text in the RPM changelog
> which IMHO would not be appropriate.

I think the opposite might also be true (I guess it depends on the
package), where it's fairly obvious to anyone concerned, i.e. both
packagers and users, why a dependency is added. E.g. I recently added
enjarify as dependency of diffoscope, with the update message "Add
newly packaged enjarify as diffoscope dep". If you know what difoscope
does, it should be pretty clear that this adds support for one more
archive type. And if tar suddenly grows a dep on liblz4 or libsnappy
or whatever, I wouldn't expend more than a few words.

That said, legible high-level update notes are a thing we should be
striving for in general.

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

Re: Test instances for Fedora Package Maintainers

[Jerry James]

On Mon, Feb 27, 2017 at 6:33 PM, Kevin Fenzi  wrote:
> I've just finished setting up a new group of test machine instances for
> package maintainers in the Fedora Infrastructure Private Cloud.
> They now include ppc64 and ppc64le instances.
> (We hope to add aarch64 before too long).

This is really great news.  Thanks a lot for setting that up.
-- 
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: Stuck maxima builds on aarch64

[Jerry James]

On Mon, Feb 27, 2017 at 3:15 PM, Kevin Fenzi  wrote:
> Hey. I looked at this a few weeks ago... but I don't recall all the
> details so I wanted to look more closely at it again before I replied.
>
> However, I have not had time since your orig email on saturday to do
> so.
>
> I'll try and look soon, but I'm afraid you will need some patience.

No worries.  I didn't realize the git branching was going on when I
sent that.  I will be patient.  Thanks, Kevin.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

New Release: fedpkg-1.28

[Chenxiong Qi]

Hello Fedora Devs,

You might have known that a new release of fedpkg-1.28 has been 
available and in the Bodhi update now. It fixes bug 1425913[1].


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

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

Re: Fedora Rawhide-20170227.n.0 compose check report

[Alexander Bokovoy]

On ma, 27 helmi 2017, Adam Williamson wrote:

On Mon, 2017-02-27 at 17:25 +, Fedora compose checker wrote:

Missing expected images:

Atomic qcow2 x86_64


There seems to be some sort of problem in pungi-make-ostree:
https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log

DEBUG util.py:435:  + pungi-make-ostree tree 
--repo=/mnt/koji/compose/atomic/rawhide/ 
--log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2
 
--treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json
 
--extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
DEBUG util.py:435:  Traceback (most recent call last):
DEBUG util.py:435:File "/usr/bin/pungi-make-ostree", line 15, in 
DEBUG util.py:435:  ostree.main()
DEBUG util.py:435:File 
"/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line 85, in main
DEBUG util.py:435:  func()
DEBUG util.py:435:File 
"/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line 95, in run
DEBUG util.py:435:  repos = extra_source_repos + [{'name': 
'source_repo_from', 'baseurl': source_repo_from}]
DEBUG util.py:435:  TypeError: unsupported operand type(s) for +: 'NoneType' 
and 'list'


Server dvd i386


Several i386 image composes still failing for the reason Kevin noted
recently:
dnf.exceptions.Error: Will not install a source rpm package 
(docker-anaconda-addon-0.4-4.fc26.src).


Xfce raw-xz armhfp


Looks a bit odd:
https://kojipkgs.fedoraproject.org//work/tasks/1563/18091563/root.log
DEBUG util.py:435:  Unable to create appliance : Failed to find package 
'firefox' : no package matched: firefox
Is there an ARM-specific issue with the firefox package?


Server boot i386
Atomic raw-xz x86_64


See above.


Failed openQA tests: 10/107 (x86_64), 1/2 (arm)

ID: 57880   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/57880


This is some kinda transient test fail, I think (openQA clicked in the
wrong place or the click got lost or something).


ID: 57881   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/57881


This is now failing because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1405790
freeipa-client and freeipa-server can't be installed due to dep issues
with certmonger, and certmonger rebuild is failing.

No, freeipa-client has dependency on /usr/libexec/system-python2 which
is not provided by anything, it seems. I rebuilt freeipa yesterday and
it again got this dependency even though nothing is explicitly requiring
or mentioning it in the code and the spec file. Looks like real issue is
somewhere in Python infra in Rawhide.


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