Fedora testing-20180722.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)

New passes (same test did not pass in updates-20180721.0):

ID: 259328  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/259328
ID: 259329  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/259329
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUAIIBK3N6WZGMY5GGAO3ZY54ZOCYCFH/

[389-devel] 389 DS nightly 2018-07-22 - 88% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/07/22/report-389-ds-base-1.4.0.13-20180721git345221c.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/QMSGOK6DAZEF2BSIDXQXIHTFHA6KFTNK/

Fedora Rawhide-20180721.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/138 (x86_64), 22/24 (i386), 1/2 (arm)

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

ID: 259176  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/259176
ID: 259199  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/259199
ID: 259207  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/259207
ID: 259267  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/259267

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

ID: 259179  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/259179
ID: 259181  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/259181
ID: 259187  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/259187
ID: 259188  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/259188
ID: 259191  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/259191
ID: 259204  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/259204
ID: 259208  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/259208
ID: 259209  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/259209
ID: 259210  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/259210
ID: 259223  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/259223
ID: 259224  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/259224
ID: 259225  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/259225
ID: 259311  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/259311
ID: 259312  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/259312
ID: 259313  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/259313
ID: 259315  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/259315
ID: 259316  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/259316
ID: 259317  Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/259317
ID: 259318  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/259318
ID: 259319  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/259319
ID: 259320  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/259320
ID: 259321  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/259321
ID: 259322  Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/259322
ID: 259323  Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/259323
ID: 259324  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/259324
ID: 259325  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/259325
ID: 259327  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/259327

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

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

ID: 259192  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/259192
ID: 259246  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/259246
ID: 259248  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/259248
ID: 259249  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/259249
ID: 259276  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/259276
ID: 259281  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/259281
ID: 259286  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/259286
ID: 259314  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/259314
ID: 259326  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/259326

Old soft failures 

Re: [HEADS UP] Removal of GCC from the buildroot

[Andrew Lutomirski]

>>> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones  wrote:
>>>
>>> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote:
>>> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote:
>>> Does each build start with its own fresh VM?  Do you care about the
>>> data in that build VM if either qemu or the host crashes?  If the
>>> answers are 'Yes' and 'No' respectively to these questions then IMHO
>>> this is the ideal situation for cache=unsafe.
>>
>> The answers are 'No' and 'Not much'.
>>
>> 1. VMs are installed once and are running for week/months until they are
>> reinstalled. In the meantime guests and hosts are rebooted during
>> routine maintenance, to apply updates.
>
> In this case my preferred advice would be: DO NOT use cache=unsafe.
>
> We've only tested scenarios for very short-lived build or temporary
> VMs (for example when I was building RISC-V packages before we had
> Koji, I used a script which created a VM per build and there it made
> sense to use cache=unsafe).
>
> I do not think it's a good idea to be using this for VMs which are in
> any way long-lived as there could be unforeseen side effects which I'm
> not aware of and certainly have never tested.
>
>> 2. There would be no data loss in case of host or hypervisor crash.
>> Worst case, if guest operating system was corrupted sysadmins would need
>> to trigger VM install.
>
> Host crash => yes you'd definitely need to reinstall that VM.
>
> It's not a worst case, a host crash would near-definitely corrupt a VM
> that was ignoring flush requests.  It might even corrupt in an
> undetectable way (eg. throwing away data while leaving metadata
> intact).

Would it make sense to boot the builders with -snapshot and
cache=unsafe?  After all, during normal operation, they don’t need to
persist anything.

It might even be reasonable to reboot the VMs after every single build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EX4K4RQ6MUVLEHK6JWXDOZ7UCTSJUI6H/

Re: Auto-filing of FTBFS bugs gone wild

[Kevin Kofler]

Igor Gnatenko wrote:
> Unfortunately I can't fix this automagically.

You can. You just need to do more than one pass of fixing, instead of 
expecting other people to fix your breakage.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y4EJOR6AA2NPQWJ52RQZ37BLYE7GE5GY/

Re: Resigning from LXQt maintainance

[Manas Mangaonkar]

Hey,

So i recently began packaging like a month back so i had no idea this was a
thing,i will get back to you asap after checking the links and everything.

On Sat, 21 Jul 2018, 22:43 Christian Dersch, 
wrote:

> Hi again :) I don't see you in packager group in FAS (which is a
> requirement for lxqt-sig access to LXQt packages). So you need to be
> sponsored as a packager first to be able to build and maintain official
> Fedora packages, check
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> But a first step would be playing with LXQt and the new version in a
> personal copr to get familiar with it. Very useful resource is the build
> order provided by upstream:
> https://forum.lxqt.org/t/build-order-release-plan/292
>
> Greetings,
> Christian
>
>
> On 07/20/2018 07:44 PM, Manas Mangaonkar wrote:
>
> Yes i am already a packager,i can do this then
>
> On Fri, 20 Jul 2018, 21:30 Christian Dersch, 
> wrote:
>
>> Hi,
>>
>> are you already a packager? The work is mostly updating packages, besides
>> that one important part is the theming of LXQt (usage of Fedora wallpaper
>> etc.) and finally maintaining the live spin. Packaging is the most
>> important topic.
>>
>> Greetings,
>> Christian
>>
>>
>> On 07/20/2018 04:44 PM, Manas Mangaonkar wrote:
>>
>> I can give this a shot,My name is Manas i am a Computer Engineering
>> undergrad. I dont know if i have the skills require for this. Can you give
>> some more information regarding the job.
>> I started contributing recently to withing the past month or so,as of
>> today i am the creator and maintainer for intel optimized kernel for
>> fedora.
>>
>> On Fri, Jul 20, 2018 at 7:06 PM, Christian Dersch <
>> lupinix.fed...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> as some of you might have recognized, Fedora's LXQt is quite outdated
>>> (we have 0.11, current one for some weeks now is 0.13) and also needs some
>>> rework with respect to theming and the package set (upstream restructured
>>> packaging a bit with respect to common files). When I joined the Fedora
>>> LXQt effort, my job was the creation of the spin while other maintainers
>>> took care of most packages. Unfortunately the core packager left Fedora. I
>>> did the whole update once, but at that time it was mostly just about
>>> bumping the version and rediffing the patches. Also I had much more free
>>> time at that point.
>>>
>>> As I recognized that I also really need more time for work on my PhD
>>> stuff, I decided to resign from work on Fedora LXQt. Of course I will
>>> continue my work on Fedora's scientific packages including the Astronomy
>>> Lab, which is closely linked with my PhD stuff. Also my other contributions
>>> like acting as an ambassador will continue as before, so it is "just" about
>>> LXQt.
>>>
>>> If you're interested in picking Fedora LXQt up, let me know. Then I'll
>>> also give initial assistance of course. I already started some work on the
>>> update some weeks ago in copr
>>> https://copr.fedorainfracloud.org/coprs/lupinix/LXQt-0.13/ and
>>> https://pagure.io/lxqt-testing-copr This is missing the rework on
>>> themes etc., and I did not check all of the older patches. My intention of
>>> that move now is, that there should be still enough time for new
>>> maintainers to get everything up to date again for Fedora 29. Or (hopefully
>>> not :( ) to remove it if necessary.
>>>
>>> Greetings,
>>> Christian
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LVC3M4YRDS2PL73LQRCXMSQTIDT4IUDN/
>>>
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KYNCQWGWS7UBXZPPSKXUGI2T7I7H6OIE/
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IIL7KBV6CTUONAJTSNBSNAFIVWR3RYAO/
>>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Re: Fedora crda To wireless-regdb Upgrade

[Samuel Sieb]

On 07/21/2018 09:46 AM, Howard Howell wrote:

Your idea suffers from one thing... Who will build, maintain and ensure
that the database is accurate.  World RF spectrum is a tough nut.  It
flunctuates due to the birth and death of nations, ideology and
technology.  Moreover some of the standards are less standards than
suggestions.  Legally it is a minefield.


This database is not a new thing.  The only change here is how it is 
being stored and packaged for Fedora.  The kernel people manage the 
database and keep it up to date.  If you look on the linux-wireless 
mailing list you can see the occasional emails about updates to the 
database.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GL2Z64Z5H2LJ5TLYISIFGNOILFNIR47P/

Re: Auto-filing of FTBFS bugs gone wild

[Ralf Corsepius]

On 07/20/2018 03:58 PM, Igor Gnatenko wrote:

On Fri, Jul 20, 2018, 15:27 Kevin Kofler  wrote:


Igor Gnatenko wrote:

No one promised that I'm going to fix 100% of packages, I've fixed around
2k packages. What my regex couldn't catch -- please send me list of
packages, I will analyze them and try to fix as much as possible.


IMHO, it is unacceptable that you make a change breaking thousands of
packages and expect us to spend our time on fixing them or getting you to
fix them (and, as Hans pointed out, the latter likely takes MORE time
because of the communication overhead).



As I said previously (part which you quoted), I have fixed more than 2500
packages. I am pretty sure that the rest can be handled by maintainers.


Do you think this attitude of yours is acceptable?

IMHO, no.

You pushed out a change which obviously was insufficiently tested, 
though you told us you tested it, IIRC. Now you are forcing us to wipe 
up and clean up?


That said, the 2500 packages you are referring to might impress some 
readers, but it doesn't impress me, because it's obvious you missed huge 
classes of cases in your "testing".



IMHO, it is time to revert this Change.

ACK. This change was rushed out in an overly haste with insufficent testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TDDBQJDFJMV3NRN3CE5X7C2F4V3WPUIK/

What to BuildRequire for libstdc++.so __cxa_demangle?

[Mark Wielaard]

Hi,

The elfutils tools can demangle C++ symbols through the standard
_cxa_demangle interface. The elfutils tools are written in C and
so simply link with -lstdc++ to get access to __cxa_demangle.

There is a BuildRequires: libstdc++-devel in the elfutils.spec.
But it looks like that isn't enough anymore to pull in libstdc++.so
to build against.

It looks like that is provided through a symlink in gcc-c++.
Should the elfutils.spec just BuildRequires: gcc-c++ instead of
libstdc++-devel? Or is this a packaging/requires issue somewhere
else?

Thanks,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/25AHUHKLSC3PQYZJWLPKGKN7NIGD3MDS/

Re: Fedora crda To wireless-regdb Upgrade

[Howard Howell]

On Fri, 2018-07-20 at 14:47 -0400, John W. Linville wrote:
> A mostly "behind the scenes" aspect of the Linux wireless LAN
> (IEEE802.11) subsystem has changed upstream with some system-level
> effects. Replacing an existing package with a cleaner but
> functionally
> equivalent package is an attractive option, but there are questions
> regarding the update path, how signing the the regulatory database
> should be handled, and how to communicate these changes outward to
> the
> greater community.
> 
> BACKGROUND
> 
> Usage of Radio Frequency (RF) spectrum is generally regulated around
> the world. Even unlicensed use of RF spectrum (as with wireless LANs)
> is still subject to some level of local regulation. In order to
> support
> lawful use of wireless LAN technology with Linux around the world,
> the
> Linux kernel uses an externally maintained wireless regulatory
> database
> that encodes relevant information about known regulatory (i.e.
> legal/governmental) domains. The kernel makes use of this information
> in order to enforce wireless regulations for devices under its
> control,
> although some devices further apply their own limitations at the
> driver
> or firmware level as well.
> 
> For a long time, the Linux kernel relied on a piece of software known
> as the Central Regulatory Domain Agent (CRDA) to feed the kernel with
> regulatory information in response to UDEV events that indicate what
> regulatory domain's rules are to be enforced. Also, within Fedora,
> the
> setregdomain script runs when a wireless netdev is instantiated. By
> default this script attempts to relate a system’s TZ (i.e. Time Zone)
> setting to a corresponding country code, which is then used to set
> the
> wireless regulatory domain. The setregdomain script can also use
> alternate means to determine which regulatory domain to request, as
> detailed in the setregdomain.1 man page.
> 
> CRDA is maintained upstream in the crda git repository. The wireless
> regulatory database is maintained upstream in the wireless-regdb git
> repository. In Fedora, snapshots of both of the above repositories
> are
> built within the single crda RPM. This is done to enable build-time
> generation of a key used to sign the wireless-regdb database which is
> then embedded in the concurrently built crda binary in order to
> validate the integrity of the database at runtime.
> 
> As of about the upstream 4.15 version of Linux, the kernel's wireless
> developers had determined that future updates to the wireless
> regulatory database may require format changes that would be
> incompatible with the existing CRDA implementation. Further, Linux
> kernel changes over the years now enabled the kernel to load firmware
> images without requiring a userland helper like CRDA. So, the Linux
> kernel wireless developers implemented an in-kernel replacement for
> CRDA. This includes code to validate the wireless regulatory database
> against a signature that is built into the kernel itself.
> 
> SITUATION
> 
> At present, Fedora kernels are configured to use the in-kernel
> wireless
> regulatory database loader. If the database is not found or is not
> signed with the key built into the kernel, then boot time messages
> appear, creating the appearance of a problem. For now, there is no
> actual problem. Fedora systems continue to ship with CRDA, which
> continues to perform its original duties with no effective problem as
> of yet. The harmless "error" messages during boot are the only
> symptom.
> (NOTE: the latest Fedora CRDA package works around this issue,
> eliminating the spurious "error" messages at boot time.)
> 
> For now, there is no emergency. We could continue to ship CRDA as-is.
> My concern is that eventually, CRDA may no longer be a viable option
> for future regulatory database updates. In that case, it would seem
> to
> be better to change now than to do so in a rush later.
> 
> Also, replacing the combined CRDA/wireless-regdb "crda" package with
> a
> new "wireless-regdb" package removes a wart from our package
> collection
> and replaces it with a package that is simpler and easier to
> understand
> how it is built. That will be one less "why did they do that?" item
> hanging around in Fedora.
> 
> ACTION IN PROGRESS
> 
> I have created a wireless-regdb package for Fedora. It simply
> installs
> the wireless regulatory database binary into /usr/lib/firmware,
> alongside it's pre-existing detached signature. This package includes
> a
> version of the setregdomain script that is virtually identical to
> what
> is in the existing crda package. This package has been approved for
> Fedora, but I recently imported the SRPM to the Fedora repository.
> (htt
> ps://bugzilla.redhat.com/show_bug.cgi?id=1598921)
> 
> I have been testing with the above package for a couple of weeks, and
> the user experience is identical to using the crda solution. Given
> this
> success, I believe that the best option will be to push this package
> with Obsoletes 

Re: Resigning from LXQt maintainance

[Christian Dersch]

Hi again :) I don't see you in packager group in FAS (which is a
requirement for lxqt-sig access to LXQt packages). So you need to be
sponsored as a packager first to be able to build and maintain official
Fedora packages, check
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

But a first step would be playing with LXQt and the new version in a
personal copr to get familiar with it. Very useful resource is the build
order provided by upstream:
https://forum.lxqt.org/t/build-order-release-plan/292

Greetings,
Christian


On 07/20/2018 07:44 PM, Manas Mangaonkar wrote:
> Yes i am already a packager,i can do this then 
>
> On Fri, 20 Jul 2018, 21:30 Christian Dersch,  > wrote:
>
> Hi,
>
> are you already a packager? The work is mostly updating packages,
> besides that one important part is the theming of LXQt (usage of
> Fedora wallpaper etc.) and finally maintaining the live spin.
> Packaging is the most important topic.
>
> Greetings,
> Christian
>
>
> On 07/20/2018 04:44 PM, Manas Mangaonkar wrote:
>> I can give this a shot,My name is Manas i am a Computer
>> Engineering undergrad. I dont know if i have the skills require
>> for this. Can you give some more information regarding the job. 
>> I started contributing recently to withing the past month or
>> so,as of today i am the creator and maintainer for intel
>> optimized kernel for fedora. 
>>
>> On Fri, Jul 20, 2018 at 7:06 PM, Christian Dersch
>> mailto:lupinix.fed...@gmail.com>> wrote:
>>
>> Hi all,
>>
>> as some of you might have recognized, Fedora's LXQt is quite
>> outdated (we have 0.11, current one for some weeks now is
>> 0.13) and also needs some rework with respect to theming and
>> the package set (upstream restructured packaging a bit with
>> respect to common files). When I joined the Fedora LXQt
>> effort, my job was the creation of the spin while other
>> maintainers took care of most packages. Unfortunately the
>> core packager left Fedora. I did the whole update once, but
>> at that time it was mostly just about bumping the version and
>> rediffing the patches. Also I had much more free time at that
>> point.
>>
>> As I recognized that I also really need more time for work on
>> my PhD stuff, I decided to resign from work on Fedora LXQt.
>> Of course I will continue my work on Fedora's scientific
>> packages including the Astronomy Lab, which is closely linked
>> with my PhD stuff. Also my other contributions like acting as
>> an ambassador will continue as before, so it is "just" about
>> LXQt.
>>
>> If you're interested in picking Fedora LXQt up, let me know.
>> Then I'll also give initial assistance of course. I already
>> started some work on the update some weeks ago in copr
>> https://copr.fedorainfracloud.org/coprs/lupinix/LXQt-0.13/
>> and https://pagure.io/lxqt-testing-copr This is missing the
>> rework on themes etc., and I did not check all of the older
>> patches. My intention of that move now is, that there should
>> be still enough time for new maintainers to get everything up
>> to date again for Fedora 29. Or (hopefully not :( ) to remove
>> it if necessary.
>>
>> Greetings,
>> Christian
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> 
>> To unsubscribe send an email to
>> devel-le...@lists.fedoraproject.org
>> 
>> Fedora Code of Conduct:
>> https://getfedora.org/code-of-conduct.html
>> List Guidelines:
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LVC3M4YRDS2PL73LQRCXMSQTIDT4IUDN/
>>
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org 
>> 
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> 
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KYNCQWGWS7UBXZPPSKXUGI2T7I7H6OIE/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 

Re: Fedora crda To wireless-regdb Upgrade

[Kevin Kofler]

John W. Linville wrote:
> Is it acceptable to trust the upstream signature of the wireless
> regulatory database? Or do we need to use some sort of Fedora
> signature? If the latter, can it be a (semi-)permanent (e.g. per
> release) signature, which could be maintained in the kernel sources? Or
> must it be a per build signature? How can that be accommodated, other
> than through another combined package? (My personal preference is to
> simply trust the upstream signature that is already being built into
> the kernel.)

I think the only way to ship really Free Software is to disable the 
signature enforcement entirely.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IH7OCPEQCMPWKSBPOMM3BFBH63XD4PIK/

Re: Auto-filing of FTBFS bugs gone wild

[Ralf Corsepius]

On 07/21/2018 11:02 AM, Igor Gnatenko wrote:

On Sat, Jul 21, 2018 at 10:28 AM Julian Sikorski  wrote:



This means that  build failed on checking for gcc. There are some packages
where it checks for both gcc and g++ and then fails, but there are packages
where it fails after first.

Unfortunately I can't fix this automagically.


Right. The approach you seem to have applied, is unsuitable.

There also are cases which assume a "cc" to be unconditionally present.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2HG7KMKWU65IXRGUAU2PK2RCGDWWZWJW/

Re: Fedora crda To wireless-regdb Upgrade

[Nicolas Chauvet]

2018-07-20 20:47 GMT+02:00 John W. Linville :
[...]
> QUESTIONS
>
> Are there reasons to oppose the Obsolete/Provides upgrade path from
> crda to wireless-regdb? Would it be desirable to require users to
> manually intervene by installing wireless-regdb by hand? FWIW, I do not
> see any benefit from requiring any manual steps.

The main issue with Obsoletes/Provides of crda is that if any user
want to maintain a self compiled kernel < 4.15. Then this kernel will
suddenly loose wireless support whereas it was previously working.
This is also a problem if using various kernel version to bissect a
wireless regression.

What I would recommend instead is to :
- have everything set for wireless-regdb to be installed by default in
f29+ (comps,ks,package dependency).
- eventually obsoletes/provides crda only on f29+
- for fedora < 29 have crda to require wireless-regdb, so current
users will migrate to the new method. (that way they can even manually
remove crda  and keep wireless-regdb if they like to).

This doesn't seem that complicated to handle as a transition that way.

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZSJEE4E6RRPA2WTT5BXMY3Y5BCCCF7UV/

Re: Fedora crda To wireless-regdb Upgrade

[Peter Robinson]

On Fri, Jul 20, 2018 at 7:47 PM, John W. Linville  wrote:
> A mostly "behind the scenes" aspect of the Linux wireless LAN
> (IEEE802.11) subsystem has changed upstream with some system-level
> effects. Replacing an existing package with a cleaner but functionally
> equivalent package is an attractive option, but there are questions
> regarding the update path, how signing the the regulatory database
> should be handled, and how to communicate these changes outward to the
> greater community.
>
> BACKGROUND
>
> Usage of Radio Frequency (RF) spectrum is generally regulated around
> the world. Even unlicensed use of RF spectrum (as with wireless LANs)
> is still subject to some level of local regulation. In order to support
> lawful use of wireless LAN technology with Linux around the world, the
> Linux kernel uses an externally maintained wireless regulatory database
> that encodes relevant information about known regulatory (i.e.
> legal/governmental) domains. The kernel makes use of this information
> in order to enforce wireless regulations for devices under its control,
> although some devices further apply their own limitations at the driver
> or firmware level as well.
>
> For a long time, the Linux kernel relied on a piece of software known
> as the Central Regulatory Domain Agent (CRDA) to feed the kernel with
> regulatory information in response to UDEV events that indicate what
> regulatory domain's rules are to be enforced. Also, within Fedora, the
> setregdomain script runs when a wireless netdev is instantiated. By
> default this script attempts to relate a system’s TZ (i.e. Time Zone)
> setting to a corresponding country code, which is then used to set the
> wireless regulatory domain. The setregdomain script can also use
> alternate means to determine which regulatory domain to request, as
> detailed in the setregdomain.1 man page.
>
> CRDA is maintained upstream in the crda git repository. The wireless
> regulatory database is maintained upstream in the wireless-regdb git
> repository. In Fedora, snapshots of both of the above repositories are
> built within the single crda RPM. This is done to enable build-time
> generation of a key used to sign the wireless-regdb database which is
> then embedded in the concurrently built crda binary in order to
> validate the integrity of the database at runtime.
>
> As of about the upstream 4.15 version of Linux, the kernel's wireless
> developers had determined that future updates to the wireless
> regulatory database may require format changes that would be
> incompatible with the existing CRDA implementation. Further, Linux
> kernel changes over the years now enabled the kernel to load firmware
> images without requiring a userland helper like CRDA. So, the Linux
> kernel wireless developers implemented an in-kernel replacement for
> CRDA. This includes code to validate the wireless regulatory database
> against a signature that is built into the kernel itself.
>
> SITUATION
>
> At present, Fedora kernels are configured to use the in-kernel wireless
> regulatory database loader. If the database is not found or is not
> signed with the key built into the kernel, then boot time messages
> appear, creating the appearance of a problem. For now, there is no
> actual problem. Fedora systems continue to ship with CRDA, which
> continues to perform its original duties with no effective problem as
> of yet. The harmless "error" messages during boot are the only symptom.
> (NOTE: the latest Fedora CRDA package works around this issue,
> eliminating the spurious "error" messages at boot time.)
>
> For now, there is no emergency. We could continue to ship CRDA as-is.
> My concern is that eventually, CRDA may no longer be a viable option
> for future regulatory database updates. In that case, it would seem to
> be better to change now than to do so in a rush later.
>
> Also, replacing the combined CRDA/wireless-regdb "crda" package with a
> new "wireless-regdb" package removes a wart from our package collection
> and replaces it with a package that is simpler and easier to understand
> how it is built. That will be one less "why did they do that?" item
> hanging around in Fedora.
>
> ACTION IN PROGRESS
>
> I have created a wireless-regdb package for Fedora. It simply installs
> the wireless regulatory database binary into /usr/lib/firmware,
> alongside it's pre-existing detached signature. This package includes a
> version of the setregdomain script that is virtually identical to what
> is in the existing crda package. This package has been approved for
> Fedora, but I recently imported the SRPM to the Fedora repository. (htt
> ps://bugzilla.redhat.com/show_bug.cgi?id=1598921)
>
> I have been testing with the above package for a couple of weeks, and
> the user experience is identical to using the crda solution. Given this
> success, I believe that the best option will be to push this package
> with Obsoletes and Provides for crda. This will facilitate a painless
> 

Re: Auto-filing of FTBFS bugs gone wild

[Igor Gnatenko]

On Sat, Jul 21, 2018 at 10:28 AM Julian Sikorski  wrote:

> W dniu 19.07.2018 o 17:30, Zbigniew Jędrzejewski-Szmek pisze:
> > On Thu, Jul 19, 2018 at 05:15:47PM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> I've just got 20 bugs auto-filed against packages which I co-maintain
> >> and that is just for packages starting with the letter 'a'.
> >>
> >> A quick check shows that these are all caused by a missing
> >> BuildRequires on gcc / g++ related to:
> >>
> >> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> >>
> >> I'm not sure if this means that the FTBFS script has been run before
> >> all the automatic fixing which was planned for this was in place;
> >> or if this means that the automatic fixing missed many many
> >> packages, but either way something needs to happen here, the amount
> >> of work now being pushed onto packagers caused by:
> > The patches adding BR have already been pushed, but, as shown above,
> > they missed many cases. I think it's probably best to report the missed
> > ones to ignatenko.
> >
> > Zbyszek
>
> Two of my packages (mendafen and gnome-chemistry-utils) failed because
> the mass fix added gcc to BR whereas gcc-c++ was required.
>

This means that  build failed on checking for gcc. There are some packages
where it checks for both gcc and g++ and then fails, but there are packages
where it fails after first.

Unfortunately I can't fix this automagically.
-- 

-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AFKVCXBNJJSOWZ6X2GHGCSC4BB7JZQUK/

Re: Auto-filing of FTBFS bugs gone wild

[Julian Sikorski]

W dniu 19.07.2018 o 17:30, Zbigniew Jędrzejewski-Szmek pisze:
> On Thu, Jul 19, 2018 at 05:15:47PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> I've just got 20 bugs auto-filed against packages which I co-maintain
>> and that is just for packages starting with the letter 'a'.
>>
>> A quick check shows that these are all caused by a missing
>> BuildRequires on gcc / g++ related to:
>>
>> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
>>
>> I'm not sure if this means that the FTBFS script has been run before
>> all the automatic fixing which was planned for this was in place;
>> or if this means that the automatic fixing missed many many
>> packages, but either way something needs to happen here, the amount
>> of work now being pushed onto packagers caused by:
> The patches adding BR have already been pushed, but, as shown above,
> they missed many cases. I think it's probably best to report the missed
> ones to ignatenko.
> 
> Zbyszek

Two of my packages (mendafen and gnome-chemistry-utils) failed because
the mass fix added gcc to BR whereas gcc-c++ was required.

Best regards,
Julian

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RMRWUT2CSX7JAJLVT47PH6BE2TVYQ7MN/

[Bug 1605404] perl-Data-Structure-Util: FTBFS in Fedora rawhide

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Data-Structure-Util-0.
   ||16-13.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-21 03:02:20



--- Comment #4 from Emmanuel Seyman  ---
Fixed in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/5IU5UXN7RYAOV7WAXRHY5NKUSUCQK423/

[Bug 1605419] perl-Term-ReadLine-Gnu: FTBFS in Fedora rawhide

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Term-ReadLine-Gnu-1.35
   ||-10.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-21 03:01:51



--- Comment #4 from Emmanuel Seyman  ---
Fixed in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/WFYOY6QTSIMKJ7BG7TX6VXQBSW3OR63U/

[Bug 1605423] perl-WWW-Curl: FTBFS in Fedora rawhide

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-WWW-Curl-4.17-17.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-21 03:01:18



--- Comment #4 from Emmanuel Seyman  ---
Fixed in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ZSVELYBFP5KP4RWE3OYIFB4YYJKMKUWS/

Re: experiencing dnf Error: Failed to synchronize cache for repo 'fedora' or ''updates'

[Miro Hrončok]

On 20.7.2018 19:56, Kevin Fenzi wrote:

On 07/20/2018 03:55 AM, Michal Novotny wrote:



I actually already filed the respective bugs:

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

There is even PR:

https://github.com/rpm-software-management/dnf/pull/1109

that got blocked for an unknown reason and mainly unknown period.

I wanted to confirm that more people are experiencing this issue, that it's
not just some "local" network problem. The problem is that dnf does not
respect max_retries option for a repo when mirror manager is being
contacted. I have no idea why it hasn't been fixed yet given that it
affects basically all dnf users and it also quite significantly affects
building in Copr.


Thats a good workaround and we should do it, but I sure wish we could
track down when and why those sporadic 503's come from our mirrorlist
containers. ;(

Perhaps we could add further debugging and track it down. I'll see what
I can do...


Can we use something like Sentry? https://sentry.io/

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LOHAJWK4H5HBUTGYAE4KKGCNYZJHF3KB/