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/

[Test-Announce] Proposal to CANCEL: 2018-07-23 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
see anything urgent to discuss, so let's take the time off.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.
Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org/message/XLIAKPIIWTPP5T6MTVKXS4OEPHDQ7Q7A/
___
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/XLIAKPIIWTPP5T6MTVKXS4OEPHDQ7Q7A/

Re: Fedora crda To wireless-regdb Upgrade

[Jeff Johnson]

Package renaming using Obsoletes/Provides will be a problem *ONLY* if 
applications confuse the version of the package with the CRDB format version: 
these are intrinsically different versions even if there is a single package 
renaming event that is coincident with the CRDB format change.

Personally, I would add a CRDB format tracking version as a virtual Provides: 
CRDB-N = X:Y-Z where. all of {CRDB-N, X, Y, Z} are merely placeholders for 
whatever values seem natural and "appropriate". YMMV.
___
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/QELITCW6YH4EKS2HNPXZHNBFQRADZL57/

Fedora crda To wireless-regdb Upgrade

[John W. Linville]

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
and nearly silent upgrade for existing Fedora users. I will follow-up
with retiring the crda package itself a bit later. Other required
actions will include replacing any packaging references to the crda
package with an eq

Re: Resigning from LXQt maintainance

[Manas Mangaonkar]

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 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/ACSJAYHLUAB73GZTNQKI4A34MVVVPBPQ/

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

[Kevin Fenzi]

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

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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/PIIMITT7YAAYVPIF63UMFBXBHSZBL6FM/

Re: some trac plugins looking for point of contacts

[Kevin Fenzi]

On 07/19/2018 02:59 AM, Paul Howarth wrote:
> On Wed, 18 Jul 2018 12:41:53 -0700
> Kevin Fenzi  wrote:
> 
>> Hey all.
>>
>> I have:
>>
>> trac-bazaar-plugin
>> trac-git-plugin
>> trac-iniadmin-plugin
>> trac-mercurial-plugin
>> trac-ticketdelete-plugin
> 
> I took a look at trac-ticketdelete-plugin as I've had that on my system
> for a long time but it seems its functionality has long since been
> included in trac itself, so I removed the package from my system and all
> was well. It might be more appropriate to retire that one rather than
> orphan it.

Good call. I have done so now.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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/4Y37SWU3UAIDMRNG7J7YOMRW7NWQ5ZNV/

Intent to retire StarCluster and python-iptools

[Orion Poplawski]

I'm going to be retiring StarCluster and its dependency python-iptools
shortly.  Upstream is dead and I'm not using it.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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/LP2CFXA56ME5LVGBLLP63CC3YOBLSGT6/

Re: Resigning from LXQt maintainance

[Christian Dersch]

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

Re: Resigning from LXQt maintainance

[Manas Mangaonkar]

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 
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.or
> g/archives/list/devel@lists.fedoraproject.org/message/LVC3M4
> YRDS2PL73LQRCXMSQTIDT4IUDN/
>
___
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/

Re: dnf history - change in how rpmdb checksum is computed

[Jeff Johnson]

Use headerFormat() with a configurable format string to extract the package 
identifier item in the list that is check summed and have it both ways.

Why anyone wishes to preserve compatibility with yum's bloated history database 
in order to flip between two depsolvers is left to RH TAM's to explain to 
customers.
___
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/CT4KBPW6YAP6O6BJNU4UQQSHKGCR4I3Q/

Re: Auto-filing of FTBFS bugs gone wild

[Igor Gnatenko]

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.

IMHO, it is time to revert this Change.
>
> 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/74MREXEJMUSW33ZQ7JQQLZAF2GWW5T7M/
>
-- 

-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/NPCS37XQDX3RPWDWVPZPU2CAYIPF5KSJ/

Re: Auto-filing of FTBFS bugs gone wild

[Tomasz Torcz]

On Thu, Jul 19, 2018 at 05:48:24PM +0200, Miro Hrončok wrote:
> > 
> > If the FTBFS script has ran too early, all the FTBFS bugs need to be
> > closed and the FTBFS script has to be run again later.
> > 
> > If the automatic BuildRequires fixing script missed all these, then
> > I suggest that:
> > 
> > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> > 
> > Gets reverted for now and we again close all the FTBFS bugs and
> > rerun the script for them after doing a fresh build with the
> > buildroot restored as it was.
> 
> I know it is not comfortable, yet at this point reverting the change and
> doing another mass rebuild is IMHO more work than fixing the packages.

  Reverting this change is jsut re-adding gcc to buildroot.
Doing another mass rebuild is pointless.

-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
___
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/TYHSIIP3INGMYPTJTCAGPFPKMAKHKNJD/

Resigning from LXQt maintainance

[Christian Dersch]

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/

Re: Errors in compiling darktable subpackages

[Germano Massullo]

A user in darktable mailing list [1] said

"If you are using -specs=/usr/lib/rpm/redhat/redhat-hardened-ld at link
time, you also need to use
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 at compile time, and as
you are compiling and linking at the same time, you need either both, or
drop the -specs=/usr/lib/rpm/redhat/redhat-hardened-ld."

so I am starting investigating about redhat-hardened usage

[1]:
https://www.mail-archive.com/darktable-dev@lists.darktable.org/msg03229.html

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

Re: Auto-filing of FTBFS bugs gone wild

[Kevin Kofler]

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

IMHO, it is time to revert this Change.

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/74MREXEJMUSW33ZQ7JQQLZAF2GWW5T7M/

Re: Auto-filing of FTBFS bugs gone wild

[Kevin Kofler]

Miro Hrončok wrote:
> I know it is not comfortable, yet at this point reverting the change and
> doing another mass rebuild is IMHO more work than fixing the packages.

It may be more work for 1 or 2 rel-eng people, but it would save work for 
hundreds of affected maintainers and hence result in much less overall work 
for Fedora.

(Note that I am talking about PERMANENTLY reverting this Change.)

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/KOCDY26UDX254YO2LLBDX4NNWOKJ6KZV/

Re: audiofile package to become an orphan

[Kevin Kofler]

Germano Massullo wrote:
> If upstream is no longer maintaining it, in my opinion you should
> evaluate to remove it from Fedora repository:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

That will happen automatically if nobody picks it up.

For a library such as audiofile, it is NOT a good idea to retire it without 
at least first looking at applications still depending on it.

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/OLYMIJZML2SYMAFBQSTFTSETLBJDI56O/

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

[mcatanzaro]

On Sun, Jul 8, 2018 at 1:46 PM, Igor Gnatenko 
 wrote:
As per Changes/Remove GCC from BuildRoot, I'm going to automatically 
add BuildRequires: gcc and/or BuildRequires: gcc-c++ to packages 
which fail to build with common messages (like gcc: command not 
found, also autotools/cmake/meson are supported).


I just got four bug reports for Vala projects that are failing due to 
missing GCC:


https://bugzilla.redhat.com/show_bug.cgi?id=1603972
https://bugzilla.redhat.com/show_bug.cgi?id=1604143
https://bugzilla.redhat.com/show_bug.cgi?id=1604150
https://bugzilla.redhat.com/show_bug.cgi?id=1604352

The error message is:

configure: error: in `/builddir/build/BUILD/five-or-more-3.28.0':
configure: error: no acceptable C compiler found in $PATH

Michael
___
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/JXSGEMOEQNBOC6XJSU4A2E5YUEK5OLE5/

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

[Michal Novotny]

On Fri, Jul 20, 2018 at 10:45 AM Kamil Paral  wrote:

> On Fri, Jul 20, 2018 at 9:37 AM, Miro Hrončok  wrote:
>
>> On 20.7.2018 06:25, Michal Novotny wrote:
>>
>>> Hello,
>>>
>>> I am occasionally experiencing the following error in my day-to-day dnf
>>> use:
>>>
>>>  Failed to synchronize cache for repo 'fedora'
>>>
>>> or
>>>
>>>  Failed to synchronize cache for repo 'updates'
>>>
>>> I've had that happened even in local mock builds.
>>>
>>> Do you also experience this error upon dnf operations like `dnf install`
>>> or `dnf refresh` or in local mock builds?
>>>
>>>
>> Happened to me yesterday. And immediate rerun "fixed" it. Maybe we can
>> add some retrying to mock?
>>
>
> We see this quite frequently in Taskotron, because we execute thousands
> jobs a day. I had to add "retry" keyword to all ansible tasks that use the
> dnf module. The reason is that MirrorManager sometimes returns an HTTP 5xx
> error (but when you try again, it works fine).
>
> It would help if DNF retried failed network requests (5xx codes), that's
> the best place to fix this for everybody. Anybody cares enough to file a
> bug and link it here?
>

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.

clime
___
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/ZY4MPSHEIDSZHOFJGP7RPZRKOCLMGUY5/

Re: Again, please announce your so-name bumps!

[Fabio Valentini]

On Thu, Jul 19, 2018, 17:48 Rex Dieter  wrote:

> Christian Dersch wrote:
>
> > Hi all,
> >
> > please announce your so-name bumps *before* you push them. This time
> > LibRaw bumped its version
>
> I added explicit soname tracking there so hopefully it won't happen again
> (at least not by surprise),
>

Related to this (and the generally unusually high number of "unannounced
soname bumps" during the last few months), I opened a ticket to amend the
Packaging Guidelines, which could essentially prevent accidental soname
bumps in the future:

https://pagure.io/packaging-committee/issue/784

Fabio


>
> https://src.fedoraproject.org/rpms/LibRaw/c/7b3e5da5e27adb2872bb3a54dc0386e01cc77d0e
>
> -- rex
> ___
> 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/3ICMGY5KBI2ARQCCMCY4UXYXOCETKTCU/
>
___
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/AC2FNI4CNSODC7C7MSZ7KEA72PTUKMEF/

Re: python 2 retirement commo efforts

[Nico Kadel-Garcia]

Good numbers to provide, thanks. I've one thought for you.

On Wed, Jul 18, 2018 at 2:24 PM, R P Herrold  wrote:

> I did not try to structure and run a report to try to
> enumerate and count by dependencies.  Looking at the
> problem with such a statistic, as to 'upstream' 'keystone'
> packages will, I suspect, show that many of the dependencies
> almost certainly 'cluster around a few 'branch' packages
>
> -- Russ herrold

Numbers of dependencies are useful to report. I'd also expect "hot
spots" around packages that are simply incompatible with python 3, or
incompatible with python 2, due to the syntax differences between the
languages. That's not going to be solvable by merely updating .spec
files.

Hmm. Has anyone take a look at the "bdist_rpms" python tools,  used by
Python developers to build RPMS from their raw python code, to bring
it up to Fedora standards? Or py2pack? Getting those updated could
help.authors of new smf p;f python tools. follow new standards.
___
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/FTDGH4CVNQQNDCAW663F2CCTF6OBC6ZO/

Re: Auto-filing of FTBFS bugs gone wild

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jul 20, 2018 at 11:02:19AM +0200, Vít Ondruch wrote:
> Honestly, I think Koschei should be mandatory for every package or at
> least opt-out by default at this point.

+1

That said, we should be working to reduce false positives as much as possible.

Zbyszek
___
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/CTI5TAVX7GUB62CWUSV3ZUFMHXTMIUTM/

Re: Intel's Clear Linux optimizations

[Rajeesh K V]

On Thu, Jul 19, 2018 at 12:52 PM Manas Mangaonkar 
wrote:

> Can you give some more details as those would help Investigate the problem
> better.
>

What additional information would you like to know?

[P.S.: please avoid top-posting.]

-- 
Rajeesh
___
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/KKWUK7CVF46Z2VEUEGS5LPR5DT4XL4NH/

Re: dnf history - change in how rpmdb checksum is computed

[Daniel Mach]

On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa  wrote:

> On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé 
> wrote:
> >
> > On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> > > Hi everyone,
> > > The DNF team is currently reviewing DNF compatibility with YUM 3 and
> we'd
> > > like to get feedback on this one:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1120253
> > >
> > > rpmdb checksum is a checksum of all installed RPMs
> > > It has no cryptographical value, it's just an unique ID of RPMs on a
> system
> > > before and after each transaction and it's used in dnf history info
> and dnf
> > > history list.
> > > If checksums of 2 following transactions do not match, DNF indicates
> that.
> > > This happens if a user installs an RPM by hand via rpm command.
> > >
> > > Then `dnf history list` looks like:
> > >  2 | install bar | 2018-01-01 02:00 | Install|2  <
> > >  1 | install foo | 2018-01-01 01:00 | Install|7 >
> > > the "<" and ">" characters indicate discontinuity in rpmdb hashes
> > >
> > > Here's the question:
> > > DNF computes the checksum from RPM N-E:V-R.A
> > > while YUM computed it from E:N-V-R.A
> > >
> > > We'd like to change the behavior to be compatible with YUM again.
> > > This would create 1 discontinuity in rpmdb checksums in the history,
> > > because from that point a new algorithm will be used.
> > >
> > > Are there any concerns about such change?
> > > I believe that >90% users wouldn't notice anything as it's related to
> the
> > > history database only.
> >
> > What's the benefit in changing to be compatible with YUM as opposed
> > to stickin with current alogorithm ?
> >
> > Surely if we don't change it, even fewer users will notice that DNF's
> > behaviour is different from YUM's, since DNF has been the default for
> > many releases now.
> >
> > I could understand the motiviation to stay compatible with YUM if we
> > were only just about to switch Fedora from YUM to DNF, but time is
> > way in the past now. Shouldn't we optimize for the fact that DNF is
> > the more widely deployed & used tool, and thus not worry about
> > YUM compatibility in respect of the history DB ?
> >
>
> From my point of view, I considered YUM's rendering of the NEVRA to be
> very weird. Personally, I'd rather see us keep the DNF behavior for
> rendering NEVRA rather than switch to YUM's ENVRA.
>
> That's right, we definitely don't want to go back to ENVRA anywhere in the
UI or API.
The ENVRA format would be only an implementation detail in the function
that computes the checksum.
___
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/DUFU46D7NU3AFU3ZEP4ES6MJRIUVZD24/

Re: dnf history - change in how rpmdb checksum is computed

[Daniel Mach]

On Wed, Jul 18, 2018 at 5:13 PM, Ben Cotton  wrote:

> On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach  wrote:
>
> > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> > there will be continuity in used algorithm and history db checksums.
> > It's important to some enterprise customers to keep the history db in a
> good shape.
> > Fedora users don't care about that much in general.
> >
> This makes sense. Let me ask from another angle: does Fedora lose
> anything from not using the current dnf history algorithm (apart from
> the discontinuity when we switch)? Would it make sense to have that be
> a configurable option where Fedora defaults to the dnf model and RHEL
> defaults to the yum model or is it essentially a cosmetic difference?
>
To me, it's more a cosmetic difference and I don't think it deserves a
configurable option for switching the behavior.
It is more important to unify the behavior, document it and cover with
tests.
___
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/GGU7CFCTBGEVJOTD5TZFQTGS55P3NWUP/

Re: F29 Self-Contained Change: Basic FPGA Support

[Peter Robinson]

On Thu, Jul 19, 2018 at 6:40 PM, Justin Forbes  wrote:
>
>
> On Wed, Jul 18, 2018 at 4:26 PM, Ben Cotton  wrote:
>>
>> == Summary ==
>> A number of devices like Xilinx ZYNQ based devices such as the
>> 96boards Ultra96 and the Intel based UP² have onboard FPGAs. FPGA
>> manager is a vendor-neutral framework that has been upstream in the
>> kernel since 4.4. This is the initial support for FPGAs in Fedora
>> using open source vendor agnostic tools.
>>
>> == Owner ==
>> * Name: Peter Robinson
>> * Email: pbrobinson at fedora project dot org
>>
>> == Detailed Description ==
>>
>> The use of Artificial Intelligence and Machine Learning is growing.
>> There's a number types of compute power used to drive this, the
>> standard system CPU can handle basic work, but for more powerful needs
>> this workload gets moved to auxiliary processors such as GPGPU, FPGAs
>> or Neural Network processors. This will add initial support for FPGAs
>> in Fedora using the Linux Kernel support which currently supports
>> Altera,  Zynq, Lattice and other FPGAs. The use of FPGAs with Open
>> Source software is improving and this is the beginning of ensuring
>> that can be consumed in Fedora as easily as possible.
>>
>> == Benefit to Fedora ==
>>
>> The general purpose use of FPGAs is growing in the tech industry,
>> especially in AI and Machine Learning usecases for IoT and numerous
>> other places where special purpose workload acceleration is needed.
>> This will help developing these workloads on top of Fedora for use
>> across the distribution.
>>
>> == Scope ==
>> * Proposal owners: Kernel and userspace changes
>
>
> Is there a list of the proposed kernel changes anywhere?

Not yet, working on it, basically it will be enabling FPGA and the
associated options there.

>>
>>
>> * Other developers: N/A (not a System Wide Change)
>>
>> == Upgrade/compatibility impact ==
>> There is no impact to upgrades or platforms that don't contain FPGAs.
>>
>> == How To Test ==
>> Testing will require hardware with a supported FPGA. The initial
>> devices for this will be a 96boards Ultra96 or a UP² with a Altera
>> FPGA. Other devices will be supported and testing will be welcome.
>>
>> The process for testing will be linked to here.
>>
>> == User Experience ==
>> Currently the Fedora support for FPGAs is basically non existent.
>> There's currently a few open tools for specific FPGAs. This is the
>> beginning of improving this with the intention of having a uniform as
>> possible  user experience across FPGAs as is currently possible.
>>
>>
>> --
>> Ben Cotton
>> Fedora Program Manager
>> TZ=America/Indiana/Indianapolis
>> ___
>> 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/PNQJ3E4GC4AITL3VMJ5OVZK2MGW2TTLL/
>
>
>
> ___
> 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/LJ27WRBNUSTT47SA3SGQV7OOPHOWEJCB/
>
___
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/47SJ3XSHC3I2GW2Y3WCB25F5WK4ZOZKQ/

Re: Auto-filing of FTBFS bugs gone wild

[Vít Ondruch]

Honestly, I think Koschei should be mandatory for every package or at
least opt-out by default at this point.


Vít



Dne 20.7.2018 v 03:56 Dan Callaghan napsal(a):
> Excerpts from Miro Hrončok's message of 2018-07-19 17:48 +02:00:
>> I know it is not comfortable, yet at this point reverting the change 
>> and doing another mass rebuild is IMHO more work than fixing the 
>> packages.
> Also, let me take this opportunity to give Koschei a shout-out.
>
> I have it enabled on all my packages and the handful of packages which 
> Igor's script did not automatically fix for me, Koschei immediately told 
> me about. And I was able to fix them up earlier this week, before the 
> FTBFS bugs were filed.
>
> I strongly recommend everyone turns Koschei tracking on for all their 
> packages because it makes it quite easy to find problems like this.
>
> (Sadly, you do get a bit more noise when pushes something that breaks 
> the entire distro, but it's still worth it.)
>
>
>
> ___
> 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/7CUNCDCACGUZULT4QCDUIITUCXVGALOE/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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/QDACNMOAE6X6RP5AY763GWO25NAYDRX5/

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

[Kamil Paral]

On Fri, Jul 20, 2018 at 9:37 AM, Miro Hrončok  wrote:

> On 20.7.2018 06:25, Michal Novotny wrote:
>
>> Hello,
>>
>> I am occasionally experiencing the following error in my day-to-day dnf
>> use:
>>
>>  Failed to synchronize cache for repo 'fedora'
>>
>> or
>>
>>  Failed to synchronize cache for repo 'updates'
>>
>> I've had that happened even in local mock builds.
>>
>> Do you also experience this error upon dnf operations like `dnf install`
>> or `dnf refresh` or in local mock builds?
>>
>>
> Happened to me yesterday. And immediate rerun "fixed" it. Maybe we can add
> some retrying to mock?
>

We see this quite frequently in Taskotron, because we execute thousands
jobs a day. I had to add "retry" keyword to all ansible tasks that use the
dnf module. The reason is that MirrorManager sometimes returns an HTTP 5xx
error (but when you try again, it works fine).

It would help if DNF retried failed network requests (5xx codes), that's
the best place to fix this for everybody. Anybody cares enough to file a
bug and link it here?
___
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/O2WAIWGUJRFZ2KJ7ZVP4PFGOZKSZLIIS/

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

[Fabio Valentini]

On Fri, Jul 20, 2018 at 6:27 AM Michal Novotny  wrote:
>
> Hello,
>
> I am occasionally experiencing the following error in my day-to-day dnf use:
>
> Failed to synchronize cache for repo 'fedora'
>
> or
>
> Failed to synchronize cache for repo 'updates'
>
> I've had that happened even in local mock builds.

These errors are the primary reason for why copr builds fail for me.
It also sometimes happens locally in mock, and dnf, too.
So it probably really is a connection issue when getting the
mirrorlists or something?

Fabio

> Do you also experience this error upon dnf operations like `dnf install` or 
> `dnf refresh` or in local mock builds?
>
> Thank you
> clime
> ___
> 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/RPRS3I7QTMLGLYXXRP2R3EQE3G2R6MY6/
___
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/P6VQYM7GJT54SSAITCLA635L3TMEISXV/

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

[Miro Hrončok]

On 20.7.2018 06:25, Michal Novotny wrote:

Hello,

I am occasionally experiencing the following error in my day-to-day dnf use:

     Failed to synchronize cache for repo 'fedora'

or

     Failed to synchronize cache for repo 'updates'

I've had that happened even in local mock builds.

Do you also experience this error upon dnf operations like `dnf install` 
or `dnf refresh` or in local mock builds?




Happened to me yesterday. And immediate rerun "fixed" it. Maybe we can 
add some retrying to mock?


--
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/UXB2BNUIWCOWV4SDA5VUBWNV47GV5BE6/

Re: audiofile package to become an orphan

[Germano Massullo]

If upstream is no longer maintaining it, in my opinion you should
evaluate to remove it from Fedora repository:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
___
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/QUZUX75QA6ZGQHHMUQ5SFGULLXQ7RJG4/

Re: Errors in compiling darktable subpackages

[Germano Massullo]

On 7/19/18 10:15 PM, Fabio Valentini wrote:
> I used to get these errors too for some of my packages. It turned out
> that upstream made some mistakes in their CMakeLists.txt files:
> The errors were usually caused by some CMakeLists.txt file overriding
> the system-provided CFLAGS with something else, instead of only
> appending necessary flags.

Thank you for your hint.
I am also looking at OpenSUSE version of darktable spec file [1] but I
find it very difficult to read with all of those macros etc.

[1]:
https://build.opensuse.org/package/view_file/home:darix:darktable:master/darktable/darktable.spec?expand=1
___
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/S7QMBAPY6XPKGLK5SURP2KG3VSOCVZN7/