Schedule for Thursday's FPC Meeting (2020-07-30 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-07-30 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2020-07-30 09:00 PDT US/Pacific 2020-07-30 12:00 EDT --> US/Eastern <-- 2020-07-30 16:00 UTC UTC 2020-07-30 17:00 BST Europe/London 2020-07-30 18:00 CEST Europe/Berlin 2020-07-30 18:00 CEST Europe/Paris 2020-07-30 21:30 IST Asia/Calcutta New Day: Friday - 2020-07-31 00:00 HKT Asia/Hong_Kong 2020-07-31 00:00 +08 Asia/Singapore 2020-07-31 01:00 JST Asia/Tokyo 2020-07-31 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #977 Get new members? .fpc 977 https://pagure.io/packaging-committee/issue/977 #topic #1007 Golang pkg review exception to update a lot of packages .fpc 1007 https://pagure.io/packaging-committee/issue/1007 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-947 Deprecate Old Style Dependency Generators. https://pagure.io/packaging-committee/pull-request/947 #topic #pr-954 Prohibit use of `rpm` command from specfile. https://pagure.io/packaging-committee/pull-request/954 = New Pull Requests = #topic #pr-942 Recommend storing changelog entries in separate file. https://pagure.io/packaging-committee/pull-request/942 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On 7/29/20 6:09 PM, Jeff Law wrote:
On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.
Jeff
It's a work in progress[0].
As for cross-gcc and friends, the description notes those are for
building kernels only, is that not the case?
It shouldn't matter for cross-binutils and cross-gcc.
There's also some vanilla upstream / TI upstream compatibility weirdness
to consider...
That issue should be resolved by getting those patches upstreamed to the GCC
project. Your best contact point for that would be Jozef Lawrynowicz <
joze...@mittosystems.com>
Jeff
Great! I'll look into it, thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
On Wed, 2020-07-29 at 13:34 -0500, Richard Shaw wrote: > On Wed, Jul 29, 2020 at 3:36 AM Zdenek Dohnal > wrote: > > Hi all, > > > > > > > > first I would like to recommend you to try the steps here: > > > > > > > > https://vimhelp.org/vim_faq.txt.html#faq-2.5 > > > > > > > > it should help you find out where the problem can be. > > > > > > > > If you are able to reproduce the issue with the first step, please > > file > > > > a bug on bugzilla.redhat.com. > > I'll give it a try, but part of my frustration is that the behavior > changed after upgrading to Fedora 32, my .vimrc did not change, so at > a minimum my settings are likely being interpreted differently. is something like this https://github.com/vim/vim/issues/989 ? , i.e a problem in a specific syntax highlight , I got this one on python, I added to my .vimrc let g:python_recommended_style=0 > Thanks, > Richard > > ___devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
> On 7/29/20 4:40 PM, Jeff Law wrote:
> > ACK. I don't see msp430-development-tools in the standard fedora repos.
> > So I'll
> > leave it to you to fix the package in whatever repo it lives in.
> >
> > Also note, you may ultimately be better off getting msp430 added to the
> > cross-
> > {binutils,gcc} packages rather than creating a new package.
> >
> > Jeff
>
> It's a work in progress[0].
>
> As for cross-gcc and friends, the description notes those are for
> building kernels only, is that not the case?
It shouldn't matter for cross-binutils and cross-gcc.
>
> There's also some vanilla upstream / TI upstream compatibility weirdness
> to consider...
That issue should be resolved by getting those patches upstreamed to the GCC
project. Your best contact point for that would be Jozef Lawrynowicz <
joze...@mittosystems.com>
Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On 7/10/20 1:56 AM, Nicolas Mailhot via devel wrote: Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit : Yes, it's completely reasonable to not do it. It might seem like a big change on its own, but Btrfs has had native compression for 10+ years, and at least three years for most all of the workloads at Facebook. So it's quite safe. But it has been eating data as recently as 2018 [1] and the Debian wiki warns strongly against using compression that is dated for 2020 [2]. The project will already see a large number of new bugs thanks to the wider breadth of hardware, why throw in an additional variable when you can flip it on in six months anyway? Compression will increase the risk of data loss, because compression removes data duplication that could be used to reconstruct data in case of corruption. If you add duplication over compression to make it recovery-safe, the wins are not so good. How does that increase the risk? What data duplication is it removing? If your hard drive flips a bit in just about any file, you're not likely to fix it. System files can be replaced easily. Most user important files are already compressed anyway. .jpg, .ogg (.mp3), .odt, etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
On Wednesday, 29 July 2020 at 20:06, Vitaly Zaitsev via devel wrote: > On 29.07.2020 19:33, Brendan Early wrote: > > Can you please explain what you mean by conflicts? They are in > > completely different directories. > > Libqmatrixclient is a very old version of libquotient. Compatibility > packages should have compat- prefix. Not anymore. Please point to the relevant Packaging Guidelines entry if you think otherwise. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.
Jeff
It's a work in progress[0].
As for cross-gcc and friends, the description notes those are for
building kernels only, is that not the case?
There's also some vanilla upstream / TI upstream compatibility weirdness
to consider...
[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1350884
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable LTO for now ?
On Wed, 2020-07-29 at 20:39 +0100, Sérgio Basto wrote: > On Wed, 2020-07-29 at 12:19 -0500, Steven Munroe wrote: > > Jeff Law wrote: > > > > > For ppc64le is that the build was done with p8, but there is one > > > function (__builtin_altivec_vadub) that requires p9. This seems > > > like a package bug at first glance, not an LTO issue. > > > > Yup __builtin_altivec_vadub is POWER9_VECTOR only. > > > > For P8/6 use something like this: > > > > vmin = vec_min (a, b); > > vmax = vec_max (a, b); > > result = vec_sub (vmax, vmin); > > > > executes in 4 cycles. > > but why it built 18 day ago, opencv-4.3.0-7 [2], > with same source code and rpm spec [1] ? All kinds of possibilities and speculating wouldn't be terribly helpful here. What remains is that there's code in there that requires p9, but the build is specifying p8 only and thus you get an error. jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On Wed, 2020-07-29 at 14:24 -0500, Brandon Nielsen wrote:
> On 7/28/20 4:39 PM, Jeff Law wrote:
> > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
> > > > If this is a new failure (say in the last week), it could be an out
> > > > of memory
> > > > scenario. Try disabling LTO. The standard way to do that is
> > > >
> > > > %define _lto_cflags %{nil}
> > > >
> > > > In your %build stanza in the spec file.
> > > >
> > > > Heff
> > >
> > > I agree, it's almost certainly OOM because it says "fatal error:
> > > Killed." I've never seen that happen for any reason other than OOM.
> > I've seen it happen for a variety of reasons. Please test with LTO
> > disabled and
> > let me know if that helps.
> >
> > jeff
>
> Disabling LTO with '%define _lto_cflags %{nil}' fixed it.
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.
Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim wrote: > > I am experimenting now with various compression in Fedora and noticed > slowdowns with compression only for mock at this moment. On 4-core CPU > building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and > 'space_cache=v2' options enabled on HDD. Also, please include the exact kernel version in the bug report. Either the literal file name or the rpm - because we need to know if it's a debug enabled kernel. Fedora debug kernels enable CONFIG_LOCKDEP which slows down Btrfs dramatically more than other file systems. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim wrote: > > I am experimenting now with various compression in Fedora and noticed > slowdowns with compression only for mock at this moment. On 4-core CPU > building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and > 'space_cache=v2' options enabled on HDD. Is there anything else going on at the same time? Could you file a bug against the kernel and in the Assignee field, replace with fedora-kernel-bt...@fedoraproject.org and describe the setup with simple reproduce steps (as in, i never use mock) so the we can do some A/B testing? I have a ~9 year old core i7, and zstd:1 single thread throughput is definitely faster for both reads and writes than the SSD that's in it, let alone the original HDD that was in it. It should be faster with zstd:1 if anything. I expect a compile means 100% writes are new file writes and not many, if any at all, writes within a file. That is what would trigger autodefrag. Thanks, -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
I am experimenting now with various compression in Fedora and noticed slowdowns with compression only for mock at this moment. On 4-core CPU building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and 'space_cache=v2' options enabled on HDD. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
> > Can you please explain what you mean by conflicts? They are in > > completely different directories. > Libqmatrixclient is a very old version of libquotient. Compatibility > packages should have compat- prefix. - That is not a conflict. I do not understand what is conflicting. - Untagging is an inappropriate action to take. - 0.5.x (libqmatrixclient) is not "very old", it has been receiving updates and 0.6.x (libquotient) just had its first stable release last week. - I agree that adding the compat suffix is best practice, but I do not believe that it applies in this situation. When I introduced libqmatrixclient it was still stable and libquotient was only a beta. The policy that requires this is called "Multiple packages with the same base name" which is not the case in this situation. The name "libqmatrixclient" is also already indicative of the package's version. > Have you tried to build Git snapshots of Quaternion instead of regular > releases at least for Rawhide? Quaternion is under active development. I would prefer that a potentially broken version does not get branched. > This is okay then. But it should be obsoleted by libquotient. Send me an > email when you decide to do this. That is what I meant by that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable LTO for now ?
On Wed, 2020-07-29 at 12:19 -0500, Steven Munroe wrote: > Jeff Law wrote: > > > For ppc64le is that the build was done with p8, but there is one > > function (__builtin_altivec_vadub) that requires p9. This seems > > like a package bug at first glance, not an LTO issue. > > Yup __builtin_altivec_vadub is POWER9_VECTOR only. > > For P8/6 use something like this: > > vmin = vec_min (a, b); > vmax = vec_max (a, b); > result = vec_sub (vmax, vmin); > > executes in 4 cycles. but why it built 18 day ago, opencv-4.3.0-7 [2], with same source code and rpm spec [1] ? [1] https://src.fedoraproject.org/rpms/opencv/commits/master [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=47160403 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On 7/28/20 4:39 PM, Jeff Law wrote:
On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
If this is a new failure (say in the last week), it could be an out
of memory
scenario. Try disabling LTO. The standard way to do that is
%define _lto_cflags %{nil}
In your %build stanza in the spec file.
Heff
I agree, it's almost certainly OOM because it says "fatal error:
Killed." I've never seen that happen for any reason other than OOM.
I've seen it happen for a variety of reasons. Please test with LTO disabled and
let me know if that helps.
jeff
Disabling LTO with '%define _lto_cflags %{nil}' fixed it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On 29.07.2020 21:09, Kevin Fenzi wrote: > So, options then would be: > > * Ask some provenpackager to help you and build the dependent packages > in the side tag you made and push the update. > > * Mail the dependent package owners to build in the side tag you > created and/or ask them to give you commits so you can do so. > > At the very least ceph should be rebuilt to avoid breaking things. Understood. Thank you. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On Wed, Jul 29, 2020 at 07:18:26PM +0200, Vitaly Zaitsev via devel wrote: > On 29.07.2020 18:20, Kevin Fenzi wrote: > > can you do it in a side tag > > OK. Got it. > > > and coordinate rebuilds with dependent packages? > > I'm not a proven packager. I cannot rebuild all dependent packages > manually. I announced soversion bump on this list. So, options then would be: * Ask some provenpackager to help you and build the dependent packages in the side tag you made and push the update. * Mail the dependent package owners to build in the side tag you created and/or ask them to give you commits so you can do so. At the very least ceph should be rebuilt to avoid breaking things. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Jakub, On Wed, 2020-07-29 at 19:10 +0200, Jakub Jelinek wrote: > On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > > Yes, I think we have a winner! > > gas generates a tiny bit of debuginfo even if you don't supply -g. > > > > But... in 2.35 you can give the DWARF level you want. > > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > > dwarf_level is never set! And then gas will happily create an > > .debug_info section with DWARF CUs that have a version of zero (!). > > > > This, defaulting to version 4. Fixes it for me: > > Older as versions emitted DWARF 2, so wouldn't that be a better default > and let gcc pass --gdwarf-? to as if it detects support at compile time > depending on gcc's default dwarf version or -gdwarf-N option? Defaulting to dwarf_level = 2 in the patch should also work. But I think it is high time we defaulted all tools to DWARF version 4 these days. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard, On Wed, 2020-07-29 at 17:55 +0100, Richard W.M. Jones wrote: > On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > > This, defaulting to version 4. Fixes it for me: > > > > diff --git a/gas/as.c b/gas/as.c > > index 4c5881abd88..c2da78870ef 100644 > > --- a/gas/as.c > > +++ b/gas/as.c > > @@ -103,7 +103,7 @@ int verbose = 0; > > int flag_dwarf_cie_version = -1; > > > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > > -unsigned int dwarf_level = 0; > > +unsigned int dwarf_level = 4; > > > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; > > So if I understand the proposed fix correctly, we _don't_ need to pass > the -g option to gas? Or should we do that also? Currently passing -g to gas is a workaround. But IMHO it shouldn't be necessary. It isn't necessary with the patch above. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Xavier, On Wed, 2020-07-29 at 18:50 +0200, Xavier Leroy wrote: > If we need to add a directive to the generated assembly, or pass a `-g` > option to the assembler, or use `gcc -c -g` as the assembler, let us know > and we'll see what we can do. > > However, please keep backward compatibility in mind: from the Info manual > it looks like gas version 2.34 has no `-g` option and no directives to > control the generation of DWARF information. So there should be reasonable > defaults for gas 2.35 to behave roughly like gas 2.34. I think the change in binutils/gas 2.35 was supposed to be backward compatible. I am pretty sure it was just an oversight that the DWARF version (dwarf_level) was not set in the none -g case. Lets see what Nick (the binutils maintainer) says. My patch is just the first thing I came up with. I am sure there are other ways to fix this. Cheers, Mark > > But... in 2.35 you can give the DWARF level you want. > > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > > dwarf_level is never set! And then gas will happily create an > > .debug_info section with DWARF CUs that have a version of zero (!). > > > > This, defaulting to version 4. Fixes it for me: > > > > diff --git a/gas/as.c b/gas/as.c > > index 4c5881abd88..c2da78870ef 100644 > > --- a/gas/as.c > > +++ b/gas/as.c > > @@ -103,7 +103,7 @@ int verbose = 0; > > int flag_dwarf_cie_version = -1; > > > > /* The maximum level of DWARF DEBUG information we should > > manufacture. */ > > -unsigned int dwarf_level = 0; > > +unsigned int dwarf_level = 4; > > > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
On Wed, Jul 29, 2020 at 3:36 AM Zdenek Dohnal wrote: > Hi all, > > first I would like to recommend you to try the steps here: > > https://vimhelp.org/vim_faq.txt.html#faq-2.5 > > it should help you find out where the problem can be. > > If you are able to reproduce the issue with the first step, please file > a bug on bugzilla.redhat.com. > I'll give it a try, but part of my frustration is that the behavior changed after upgrading to Fedora 32, my .vimrc did not change, so at a minimum my settings are likely being interpreted differently. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review exchange
On Wednesday, 29 July 2020 18:13:26 CEST Qiyu Yan wrote: > Robert-André Mauchin 于2020年7月29日周三 上午3:43写道： > > > > > > > On Tuesday, 28 July 2020 07:56:52 CEST Qiyu Yan wrote: > > > > > Hello all! > > > > > > > > > > > > I am trying to package a golang program to fedora and found that I > > > need to bring those dependencies: > > > > > > > > > > > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861185 > > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861187 > > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861188 > > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861190 > > > > > > > > > > > > I think they will be trivial to review (go2rpm and fix all #FIXME > > > parts), can someone help me? > > > > > > > > > > All good, approved. > > Please consider adding 'go-sig' as a maintainer once you request the > > packages. And add them to Koschei too. > > Thanks, all done expect being to be added to go sig, and how do I add > those packages into go-sig package group in Koschei? > Thanks! It seems only the tag creator can add package to the tag en Koschei, which is inconvenient. I'll do it before F33 branching. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
On 2020-07-28 17:58, Sergio Belkin wrote: > Since a couple of years ago, I'm a happy user of neovim on Fedora :) I play with it now and then but have yet to switch completely. It's been long enough that I don't remember what my hangup was. If memory serves, it was the lack of gneovim or whatever it'd be called. There was MUCH to be liked however, I remember that much. John Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
On 29.07.2020 19:33, Brendan Early wrote: > Can you please explain what you mean by conflicts? They are in > completely different directories. Libqmatrixclient is a very old version of libquotient. Compatibility packages should have compat- prefix. > I am unaware of any policy that does not allow this, quaternion (by the > author of the library) has no release that can be built with libquotient > yet. Have you tried to build Git snapshots of Quaternion instead of regular releases at least for Rawhide? > I have been > planing to obsolete libQMatrixClient in favor of libquotient as soon as > quaternion has a version that can be built with libquotient. This is okay then. But it should be obsoleted by libquotient. Send me an email when you decide to do this. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
Vitaly, Can you please explain what you mean by conflicts? They are in completely different directories. I am unaware of any policy that does not allow this, quaternion (by the author of the library) has no release that can be built with libquotient yet. Untagging libQMatrixClient will break quaternion, I have been planing to obsolete libQMatrixClient in favor of libquotient as soon as quaternion has a version that can be built with libquotient. Regards, Brendan Early ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
On 29.07.2020 19:14, Kevin Fenzi wrote: > What exactly are the conflicts? Can you Obsolete/Provides whatever in > libquotient? libqmatrixclient is a very old version of libquotient (before the upstream decided to rename it). Both of them provides the same files (except of library versions). If someone still need it, it should have compat- prefix, I think. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable LTO for now ?
Jeff Law wrote: > For ppc64le is that the build was done with p8, but there is one > function (__builtin_altivec_vadub) that requires p9. This seems > like a package bug at first glance, not an LTO issue. Yup __builtin_altivec_vadub is POWER9_VECTOR only. For P8/6 use something like this: vmin = vec_min (a, b); vmax = vec_max (a, b); result = vec_sub (vmax, vmin); executes in 4 cycles. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On 29.07.2020 18:20, Kevin Fenzi wrote: > can you do it in a side tag OK. Got it. > and coordinate rebuilds with dependent packages? I'm not a proven packager. I cannot rebuild all dependent packages manually. I announced soversion bump on this list. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Duplicate package was reviewed
On Wed, Jul 29, 2020 at 06:41:57PM +0200, Vitaly Zaitsev via devel wrote: > Hello all. > > Duplicate package of libquotient - libqmatrixclient - was reviewed, > accepted and pushed to stable repositories. > > Not it cause conflicts. I guess you meant "Now" there? > > libqmatrixclient must be untagged and removed from all Fedora releases. We don't remove things from stable releases normally. What exactly are the conflicts? Can you Obsolete/Provides whatever in libquotient? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390 builds failing with "All mirrors were tried"
On Wed, Jul 29, 2020 at 10:25:24AM -0600, Jeff Law wrote: > On Wed, 2020-07-29 at 09:19 -0700, Kevin Fenzi wrote: > > On Wed, Jul 29, 2020 at 10:31:32AM -0400, Scott Talbert wrote: > > > On Wed, 29 Jul 2020, Richard W.M. Jones wrote: > > > > > > > libnbd failed in the mass rebuild. I kicked off a second build by > > > > hand, and it failed in the exact same way: > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058 > > > > > > > > DEBUG util.py:623: Downloading Packages: > > > > DEBUG util.py:621: Error: Error downloading packages: > > > > DEBUG util.py:621:Cannot download > > > > toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm: > > > > All mirrors were tried > > > > > > > > Is this a generic s390 problem of is there really something wrong with > > > > the ocaml-compiler-libs package? If it's generic then I guess this > > > > sort of error could be affecting a lot of other packages in the mass > > > > rebuild. > > > > > > Seems to be a generic s390x problem (with networking / connectivity?). At > > > least one of my packages failed in a similar was on s390x. > > > > Yes, the local to the s390x builders cache had issues last night. > > I disabled all builders and rebooted it, but likely it failed a lot of > > builds. > > > > Additionally, it seems like from time to time it just gets swamped. > > > > We are planning on resubmitting the failed builds after the mass rebuild > > is complete. Or you can feel free to resubmit any of yours that failed > > in this way before then. > > > > I already have some ideas on how to make the s390x setup more robust, > > but I'm not going to make changes in the middle of the mass rebuild, but > > hopefully that will help for the next one. > That reminds me. My local testing has shown that -flto=auto works reasonably > well and can help significantly with build times (it parallelizes the compiler > invocations that occur at link time). > > It'd planned to enable it after the mass rebuild, but I find myself wondering > if > I should go ahead and update redhat-rpm-config now so that the second pass > over > the packages will be faster. > > Thoughts? If all it does is parallelize, I'd say enable it anytime... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > Yes, I think we have a winner! > gas generates a tiny bit of debuginfo even if you don't supply -g. > > But... in 2.35 you can give the DWARF level you want. > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > dwarf_level is never set! And then gas will happily create an > .debug_info section with DWARF CUs that have a version of zero (!). > > This, defaulting to version 4. Fixes it for me: Older as versions emitted DWARF 2, so wouldn't that be a better default and let gcc pass --gdwarf-? to as if it detects support at compile time depending on gcc's default dwarf version or -gdwarf-N option? Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 10:56 AM Jerry James wrote: > No, it is just called like this: as -o hacha.o hacha.s. Anyway, "info > ld" claims that the -g flag is ignored. No, that was the old "info ld" that said that. The -g flag isn't even mentioned in the new binutils info page. But it is necessary. If I add -g to the "as" invocation, then dwarfdump is suddenly happy. Richard, it looks like we have to make sure the ocaml toolchain passes -g to as now. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:50:43PM +0200, Xavier Leroy wrote: > However, please keep backward compatibility in mind: from the Info manual > it looks like gas version 2.34 has no `-g` option and no directives to > control the generation of DWARF information. So there should be reasonable > defaults for gas 2.35 to behave roughly like gas 2.34. It might be that the info file is out of date (my copy of the info file doesn't even mention "as"!), but gas even back to 2.27 has the -g option: $ as --version GNU assembler version 2.27-43.base.el7 Copyright (C) 2016 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-redhat-linux'. $ echo 'nothing: ret' | as -g $ file a.out a.out: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped $ eu-readelf --debug-dump a.out DWARF section [ 6] '.debug_info' at offset 0x83: [Offset] [...lots of stuff...] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 10:51 AM Mark Wielaard wrote:
> I also tried to do a mockbuild locally, and that one succeeded.
> Don't know what is different from the koji buildroot :{
Run mock with --enablerepo=local.
> So ml depends on binutils gas to generate the actual debuginfo.
> I assume it gets called with: as -g
No, it is just called like this: as -o hacha.o hacha.s. Anyway, "info
ld" claims that the -g flag is ignored.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote: > > (Adding OCaml author) > > (Adding binutils/gas maintainer) > > > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote: > > > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote: > > I should probably add that I'm building these on my local machine > > which isn't completely updated to Rawhide. I'm not sure whether or > > not that will make a difference - I'm assuming _not_ for what the > > OCaml compiler generates (since I'm running the latest of that), but > > not sure about the rest of the toolchain. I'm using > > binutils-2.34-3.fc32.x86_64. > > Right. Same here. Dunno why mockbuild didn't pick up the 2.35 version, > but I think the bug is in that one. See below. > > > > > I also saved an asm file from one of them which may be helpful: > > > > > > > > http://oirase.annexia.org/tmp/hacha.s > > > > > > So ml depends on binutils gas to generate the actual debuginfo. > > > I assume it gets called with: as -g > > > Is there a way to see how exactly gas is called (with which arguments)? > > > > In fact it *isn't* passing -g to as: > > > > $ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o > > hacha.cmx hacha.ml -S -verbose > > + as -o 'hacha.o' 'hacha.s' > > > > Is this a problem? I sort of assumed that as would have nothing to do > > with generating debug information, beyond what is contained explicitly > > in the .s file itself. > > Yes, I think we have a winner! > gas generates a tiny bit of debuginfo even if you don't supply -g. > > But... in 2.35 you can give the DWARF level you want. > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > dwarf_level is never set! And then gas will happily create an > .debug_info section with DWARF CUs that have a version of zero (!). > > This, defaulting to version 4. Fixes it for me: > > diff --git a/gas/as.c b/gas/as.c > index 4c5881abd88..c2da78870ef 100644 > --- a/gas/as.c > +++ b/gas/as.c > @@ -103,7 +103,7 @@ int verbose = 0; > int flag_dwarf_cie_version = -1; > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > -unsigned int dwarf_level = 0; > +unsigned int dwarf_level = 4; > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; So if I understand the proposed fix correctly, we _don't_ need to pass the -g option to gas? Or should we do that also? I see that binutils gas back to at least 2.27 has a -g option Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
I got so focused on the other thread, I didn't pay attention to this one. On Wed, Jul 29, 2020 at 10:02 AM Richard W.M. Jones wrote: > It uses its own DWARF generator but everything is linked together > using standard binutils (via GCC). > > > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we > > can inspect it? > > I've uploaded the binary which I built on my own machine here: > > http://oirase.annexia.org/tmp/hacha.native > > plus some of the *.o files which went into it: > > http://oirase.annexia.org/tmp/myLexing.o > http://oirase.annexia.org/tmp/myStack.o > http://oirase.annexia.org/tmp/hacha.o > > I also saved an asm file from one of them which may be helpful: > > http://oirase.annexia.org/tmp/hacha.s As I noted in the other thread, simply running such a .s file through the as from binutils-2.35-3.fc33 then inspecting the output with dwarfdump shows the debuginfo is corrupted. Running the same .s file through the as from binutils-2.34.0-8.fc33, on the other hand, keeps dwarfdump happy. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Duplicate package was reviewed
Hello all. Duplicate package of libquotient - libqmatrixclient - was reviewed, accepted and pushed to stable repositories. Not it cause conflicts. libqmatrixclient must be untagged and removed from all Fedora releases. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi, On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote: > (Adding OCaml author) (Adding binutils/gas maintainer) > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote: > > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote: > I should probably add that I'm building these on my local machine > which isn't completely updated to Rawhide. I'm not sure whether or > not that will make a difference - I'm assuming _not_ for what the > OCaml compiler generates (since I'm running the latest of that), but > not sure about the rest of the toolchain. I'm using > binutils-2.34-3.fc32.x86_64. Right. Same here. Dunno why mockbuild didn't pick up the 2.35 version, but I think the bug is in that one. See below. > > > I also saved an asm file from one of them which may be helpful: > > > > > > http://oirase.annexia.org/tmp/hacha.s > > > > So ml depends on binutils gas to generate the actual debuginfo. > > I assume it gets called with: as -g > > Is there a way to see how exactly gas is called (with which arguments)? > > In fact it *isn't* passing -g to as: > > $ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o > hacha.cmx hacha.ml -S -verbose > + as -o 'hacha.o' 'hacha.s' > > Is this a problem? I sort of assumed that as would have nothing to do > with generating debug information, beyond what is contained explicitly > in the .s file itself. Yes, I think we have a winner! gas generates a tiny bit of debuginfo even if you don't supply -g. But... in 2.35 you can give the DWARF level you want. The problem with not supplying -g (or --gdwarf-[VERSION]) is that the dwarf_level is never set! And then gas will happily create an .debug_info section with DWARF CUs that have a version of zero (!). This, defaulting to version 4. Fixes it for me: diff --git a/gas/as.c b/gas/as.c index 4c5881abd88..c2da78870ef 100644 --- a/gas/as.c +++ b/gas/as.c @@ -103,7 +103,7 @@ int verbose = 0; int flag_dwarf_cie_version = -1; /* The maximum level of DWARF DEBUG information we should manufacture. */ -unsigned int dwarf_level = 0; +unsigned int dwarf_level = 4; #if defined OBJ_ELF || defined OBJ_MAYBE_ELF int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390 builds failing with "All mirrors were tried"
On Wed, 2020-07-29 at 09:19 -0700, Kevin Fenzi wrote: > On Wed, Jul 29, 2020 at 10:31:32AM -0400, Scott Talbert wrote: > > On Wed, 29 Jul 2020, Richard W.M. Jones wrote: > > > > > libnbd failed in the mass rebuild. I kicked off a second build by > > > hand, and it failed in the exact same way: > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058 > > > > > > DEBUG util.py:623: Downloading Packages: > > > DEBUG util.py:621: Error: Error downloading packages: > > > DEBUG util.py:621:Cannot download > > > toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm: > > > All mirrors were tried > > > > > > Is this a generic s390 problem of is there really something wrong with > > > the ocaml-compiler-libs package? If it's generic then I guess this > > > sort of error could be affecting a lot of other packages in the mass > > > rebuild. > > > > Seems to be a generic s390x problem (with networking / connectivity?). At > > least one of my packages failed in a similar was on s390x. > > Yes, the local to the s390x builders cache had issues last night. > I disabled all builders and rebooted it, but likely it failed a lot of > builds. > > Additionally, it seems like from time to time it just gets swamped. > > We are planning on resubmitting the failed builds after the mass rebuild > is complete. Or you can feel free to resubmit any of yours that failed > in this way before then. > > I already have some ideas on how to make the s390x setup more robust, > but I'm not going to make changes in the middle of the mass rebuild, but > hopefully that will help for the next one. That reminds me. My local testing has shown that -flto=auto works reasonably well and can help significantly with build times (it parallelizes the compiler invocations that occur at link time). It'd planned to enable it after the mass rebuild, but I find myself wondering if I should go ahead and update redhat-rpm-config now so that the second pass over the packages will be faster. Thoughts? jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ceph -> qemu -> lots failing in the mass rebuild
On Wed, 2020-07-29 at 09:16 -0700, Kevin Fenzi wrote: > On Wed, Jul 29, 2020 at 02:40:18PM +0100, Richard W.M. Jones wrote: > > qemu is uninstallable at the moment because ceph is uninstallable > > because fmt was upgraded from 6 to 7 in the middle of the build > > (resulting in an soname bump - it was announced). > > > > There are quite a few things failing in the mass rebuild as a result. > > > > I've kicked off a new build of ceph, and will follow up with qemu if > > that's necessary, but note that ceph takes ~ 24 hours to build, so > > it'll be a while ... > > We are planning on doing a resubmit on all the mass rebuild failures > after the mass rebuild is done. Obviously we should wait for this too. Thanks for doing that. I was trying to walk through the existing failures looking for LTO issues (and even found a few), but there's so much noise from the s390 and cmake issues that it doesn't seem worth the time until that second round of builds has started. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On Wed, Jul 29, 2020 at 05:01:08PM +0200, Vitaly Zaitsev via devel wrote: > On 29.07.2020 14:44, Richard W.M. Jones wrote: > > Was this package built and then untagged? > > We delayed the build due issues[1-3] with the sphinx/doxygen > documentation generator. As a workaround, we decided to temporary > disable documentation generation. > > When the issues will be resolved, we will enable it again. FYI, next time with a fmt soname bump... can you do it in a side tag and coordinate rebuilds with dependent packages? Thanks, kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390 builds failing with "All mirrors were tried"
On Wed, Jul 29, 2020 at 10:31:32AM -0400, Scott Talbert wrote: > On Wed, 29 Jul 2020, Richard W.M. Jones wrote: > > > libnbd failed in the mass rebuild. I kicked off a second build by > > hand, and it failed in the exact same way: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058 > > > > DEBUG util.py:623: Downloading Packages: > > DEBUG util.py:621: Error: Error downloading packages: > > DEBUG util.py:621:Cannot download > > toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm: > > All mirrors were tried > > > > Is this a generic s390 problem of is there really something wrong with > > the ocaml-compiler-libs package? If it's generic then I guess this > > sort of error could be affecting a lot of other packages in the mass > > rebuild. > > Seems to be a generic s390x problem (with networking / connectivity?). At > least one of my packages failed in a similar was on s390x. Yes, the local to the s390x builders cache had issues last night. I disabled all builders and rebooted it, but likely it failed a lot of builds. Additionally, it seems like from time to time it just gets swamped. We are planning on resubmitting the failed builds after the mass rebuild is complete. Or you can feel free to resubmit any of yours that failed in this way before then. I already have some ideas on how to make the s390x setup more robust, but I'm not going to make changes in the middle of the mass rebuild, but hopefully that will help for the next one. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
(Adding OCaml author)
On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> Hi Richard,
>
> On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> > On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > > Given these are .ml files I suspect it is not gcc, but some other
> > > code/DWARF generator issue. Maybe it does use the default
> > > (binutils)
> > > liker though?
> >
> > It uses its own DWARF generator but everything is linked together
> > using standard binutils (via GCC).
> >
> > > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so
> > > we
> > > can inspect it?
> >
> > I've uploaded the binary which I built on my own machine here:
> >
> > http://oirase.annexia.org/tmp/hacha.native
>
> This one looks OK.
>
> > plus some of the *.o files which went into it:
> >
> > http://oirase.annexia.org/tmp/myLexing.o
> > http://oirase.annexia.org/tmp/myStack.o
> > http://oirase.annexia.org/tmp/hacha.o
>
> And so do these.
I should probably add that I'm building these on my local machine
which isn't completely updated to Rawhide. I'm not sure whether or
not that will make a difference - I'm assuming _not_ for what the
OCaml compiler generates (since I'm running the latest of that), but
not sure about the rest of the toolchain. I'm using
binutils-2.34-3.fc32.x86_64.
> I also tried to do a mockbuild locally, and that one succeeded.
> Don't know what is different from the koji buildroot :{
>
> > I also saved an asm file from one of them which may be helpful:
> >
> > http://oirase.annexia.org/tmp/hacha.s
>
> So ml depends on binutils gas to generate the actual debuginfo.
> I assume it gets called with: as -g
> Is there a way to see how exactly gas is called (with which arguments)?
In fact it *isn't* passing -g to as:
$ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o
hacha.cmx hacha.ml -S -verbose
+ as -o 'hacha.o' 'hacha.s'
Is this a problem? I sort of assumed that as would have nothing to do
with generating debug information, beyond what is contained explicitly
in the .s file itself.
> One of the gas 2.35 features is:
>
> * Add --gdwarf-5 option to the assembler to generate DWARF 5 debug output
> (if such output is being generated). Added the ability to generate
> version 5 .debug_line sections.
>
> Which is the version that just hit fedora rawhide. Maybe that changed
> something about the gas -g output as well?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ceph -> qemu -> lots failing in the mass rebuild
On Wed, Jul 29, 2020 at 02:40:18PM +0100, Richard W.M. Jones wrote: > > qemu is uninstallable at the moment because ceph is uninstallable > because fmt was upgraded from 6 to 7 in the middle of the build > (resulting in an soname bump - it was announced). > > There are quite a few things failing in the mass rebuild as a result. > > I've kicked off a new build of ceph, and will follow up with qemu if > that's necessary, but note that ceph takes ~ 24 hours to build, so > it'll be a while ... We are planning on doing a resubmit on all the mass rebuild failures after the mass rebuild is done. Obviously we should wait for this too. qemu will need rebuilding after that. It was broken by the xen soname bump. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review exchange
Robert-André Mauchin 于2020年7月29日周三 上午3:43写道： > > On Tuesday, 28 July 2020 07:56:52 CEST Qiyu Yan wrote: > > Hello all! > > > > I am trying to package a golang program to fedora and found that I > > need to bring those dependencies: > > > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861185 > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861187 > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861188 > > - https://bugzilla.redhat.com/show_bug.cgi?id=1861190 > > > > I think they will be trivial to review (go2rpm and fix all #FIXME > > parts), can someone help me? > > > All good, approved. > Please consider adding 'go-sig' as a maintainer once you request the packages. > And add them to Koschei too. Thanks, all done expect being to be added to go sig, and how do I add those packages into go-sig package group in Koschei? > > Best regards, > > Robert-André > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, 28 Jul 2020 13:51:00 -0600 Chris Murphy wrote: > That information is stale. The feature page has been updated. > > man page contains: > >To disable a configuration file supplied by the vendor, the > recommended way is to place a symlink to /dev/null in the > configuration directory in /etc/, with the same filename as the vendor > configuration file. Thanks. > It's maybe easier to just 'dnf remove zram-generator-defaults' but > that is a Fedora specific instruction. After some thought, this is what I did after I posted the message. Makes sense, can't run if it isn't there. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard,
On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > Given these are .ml files I suspect it is not gcc, but some other
> > code/DWARF generator issue. Maybe it does use the default
> > (binutils)
> > liker though?
>
> It uses its own DWARF generator but everything is linked together
> using standard binutils (via GCC).
>
> > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so
> > we
> > can inspect it?
>
> I've uploaded the binary which I built on my own machine here:
>
> http://oirase.annexia.org/tmp/hacha.native
This one looks OK.
> plus some of the *.o files which went into it:
>
> http://oirase.annexia.org/tmp/myLexing.o
> http://oirase.annexia.org/tmp/myStack.o
> http://oirase.annexia.org/tmp/hacha.o
And so do these.
I also tried to do a mockbuild locally, and that one succeeded.
Don't know what is different from the koji buildroot :{
> I also saved an asm file from one of them which may be helpful:
>
> http://oirase.annexia.org/tmp/hacha.s
So ml depends on binutils gas to generate the actual debuginfo.
I assume it gets called with: as -g
Is there a way to see how exactly gas is called (with which arguments)?
One of the gas 2.35 features is:
* Add --gdwarf-5 option to the assembler to generate DWARF 5 debug output
(if such output is being generated). Added the ability to generate
version 5 .debug_line sections.
Which is the version that just hit fedora rawhide. Maybe that changed
something about the gas -g output as well?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-07-29)
= #fedora-meeting-2: FESCo (2020-07-29) = Meeting started by decathorpe at 14:00:24 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-29/fesco.2020-07-29-14.00.log.html . Meeting summary --- * Init Process (decathorpe, 14:00:52) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NHIKO64AWRW72LEOD3LMJ5E6FJT62CED/ Schedule (decathorpe, 14:05:34) * #2446 What to do with the 33 packagers/watchers who do not have a valid bugzilla account? (decathorpe, 14:06:01) * AGREED: APPROVED (P1: (+5, 0, -1); P2+P3: (+6, 0, -0)) (decathorpe, 14:23:30) * Next week's chair (decathorpe, 14:24:43) * ACTION: ngompa will chair next week's meeting (decathorpe, 14:27:51) * Open Floor (decathorpe, 14:28:05) * LINK: https://src.fedoraproject.org/rpms/postgresql/commits/master suggest 2 years of postgresql maintanance (mhroncok, 14:50:26) * ACTION: zbyszek to comment in PostgreSQL ticket with questions / missing details in Change Proposal (decathorpe, 14:59:20) * #2416 Update 3rd party repo policy (decathorpe, 15:00:59) * ACTION: everybody will read tickets and proposed docs changes and vote in ticket (decathorpe, 15:04:32) * Council is voting on an actual process for promoting deliverables to Edition status https://fedoraproject.org/wiki/Editions/Promotion_Process (bcotton, 15:06:11) Meeting ended at 15:16:25 UTC. Action Items * ngompa will chair next week's meeting * zbyszek to comment in PostgreSQL ticket with questions / missing details in Change Proposal * everybody will read tickets and proposed docs changes and vote in ticket Action Items, by person --- * zbyszek * zbyszek to comment in PostgreSQL ticket with questions / missing details in Change Proposal * **UNASSIGNED** * ngompa will chair next week's meeting * everybody will read tickets and proposed docs changes and vote in ticket People Present (lines said) --- * King_InuYasha (67) * decathorpe (59) * mhroncok (46) * zbyszek (39) * bcotton (25) * sgallagh (24) * nirik (24) * dcantrell (24) * zodbot (16) * pingou (6) * ignatenkobrain (0) * Conan_Kudo (0) * Eighth_Doctor (0) * cverna (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Wed, Jul 29, 2020 at 12:56 AM John M. Harris Jr wrote: > > On Tuesday, July 28, 2020 12:51:00 PM MST Chris Murphy wrote: > > On Tue, Jul 28, 2020 at 11:29 AM stan via devel > > wrote: > > > > > > > > > > > On Thu, 4 Jun 2020 16:30:07 -0400 > > > Ben Cotton wrote: > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > > > > > > > > > > How can it be disabled? > > > > > > > > > > > > > > > > Immediately: > > > > swapoff /dev/zram0 > > > > > > > > > > > > > > > > Permanently: > > > > rm /etc/systemd/zram-generator.conf > > > > > > > > > > > > I realize this is a really late reply, but I wanted to disable this > > > since it was never used, and when I looked at the man pages this > > > information was not in them. I think it should be. > > > > > > That information is stale. The feature page has been updated. > > > > man page contains: > > > >To disable a configuration file supplied by the vendor, the > > recommended way is to place a symlink to /dev/null in the > > configuration directory in /etc/, with the same filename as the vendor > > configuration file. > > > > > > It's maybe easier to just 'dnf remove zram-generator-defaults' but > > that is a Fedora specific instruction. > > Well, that'll just make it come back on upgrade, wouldn't it? No. I've updated the Upgrade and Compatibility section to reflect how upgrades will work. It's quite a bit more narrow in scope than the original proposal. https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Upgrade.2Fcompatibility_impact -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Rawhide] Need assistance to build Blender
Hello team, the recent change on Blender broke the cmake settings: https://download.copr.fedorainfracloud.org/results/luya/blender-egl/fedora-rawhide-x86_64/01586008-blender/ Could someone investigave the issue please? Thanks in advance. Also see the scratch result: https://koji.fedoraproject.org/koji/taskinfo?taskID=47730766 -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
On Wed, Jul 29, 2020 at 8:45 AM Eugene Syromiatnikov wrote: > On Wed, Jul 29, 2020 at 07:37:31AM -0500, Richard Shaw wrote: > > I'm working on fixing a package but I have to use scratch builds because > > the tests only pass when running on koji, not a local mock build. It > > produces several rpms which I'd like to download for testing purposes. > > > > Currently I have to go to the url of the scratch build and download them > > individually. Is there an easier way? > > koji download-task ? > I was still getting my morning coffee at the time so I'll blame it on that, but it would be nice if if was mentioned in the wiki. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote: > > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > > > with: > > > > > > error: Empty %files file > > > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > > > > > However it works when I build locally: > > > > > > $ rpm -qlp > > > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > > > [etc] > > > > > > There's an earlier error which occurs in the Koji build which doesn't > > > occur for me locally but looks related: > > > > > > Dwarf Error: wrong version in compilation unit header (is 0, should be > > > 2, 3, 4 or 5) [in module > > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > > > gdb-add-index: No index was created for > > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > > > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > > > > > Did something change with DWARF or gdb in Rawhide that we should be > > > aware of? Obviously these are not C code and OCaml has its own DWARF > > > generator. > > > > I think mjw is tracking something like this yesterday, but it was aarch64. > > I'm > > going to be offline for a couple hours, but you might want to reach out to > > him > > and see if there's any useful state (on cc) > > This looks unrelated to what I was looking at, which was indeed aarch64 > specific (but doesn't actually seem to be impacting the mass rebuild): > https://bugzilla.redhat.com/show_bug.cgi?id=1861423 > > The above happens if none of the debuginfo could be read at all, so no > source files could be extracted. > > Given these are .ml files I suspect it is not gcc, but some other > code/DWARF generator issue. Maybe it does use the default (binutils) > liker though? It uses its own DWARF generator but everything is linked together using standard binutils (via GCC). > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we > can inspect it? I've uploaded the binary which I built on my own machine here: http://oirase.annexia.org/tmp/hacha.native plus some of the *.o files which went into it: http://oirase.annexia.org/tmp/myLexing.o http://oirase.annexia.org/tmp/myStack.o http://oirase.annexia.org/tmp/hacha.o I also saved an asm file from one of them which may be helpful: http://oirase.annexia.org/tmp/hacha.s Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: DWARF version 0 unhandled
On Wed, Jul 29, 2020 at 7:12 AM Richard W.M. Jones wrote: > On Tue, Jul 28, 2020 at 08:58:22PM -0600, Jeff Law wrote: > > You might try without LTO. I'm just shooting in the dark, but LTO does > > have a > > significant impact on how we generate debuginfo as well as impacting the > > structure of the resultant debug info. > > > > While I haven't seen anything like what you've shown it can't hurt to at > > least > > see if LTO is playing a role here. > > I just started a new thread without seeing this one. We have a > similar problem for OCaml code which won't be LTO related: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5GDU2TDF7UKO73UFAV67IKQHDOBHHJYS/ Well, alt-ergo is OCaml code. As I pointed out in the initial email, the ocaml package had not yet been rebuilt during the mass rebuild, so the problem is not that the OCaml compiler got built with LTO. I did an alt-ergo build with strace to see what gets invoked. These are samples of the invocations of programs from the list of changed packages in my initial email: /usr/bin/as -o lib/util/config.o /tmp/camlasme3bb4e.s /usr/bin/gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard -fno-tree-vrp -ffunction-sections -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE -Wl,-E -o alt-ergo.opt -L/usr/lib64/ocaml/num -L/usr/lib64/ocaml/zarith -L/usr/lib64/ocaml/lablgtk2 -L/usr/lib64/ocaml/threads -L/usr/lib64/ocaml/zip -L/usr/lib64/ocaml/ocplib-simplex -L/usr/lib64/ocaml/psmt2-frontend -Llib/util -Llib/structures -Llib/reasoners -Llib/frontend -Ltools/text -Ltools/gui -Lparsers/why -Lparsers/smt2 -Lplugins/fm-simplex -L/usr/lib64/ocaml -Wl,-E /tmp/camlstartup506767.o /usr/lib64/ocaml/std_exit.o tools/text/main_text.o lib/frontend/parsers_loader.o parsers/smt2/psmt2_to_alt_ergo.o parsers/why/why_lexer.o parsers/why/why_parser.o lib/frontend/parsers.o lib/frontend/frontend.o lib/frontend/parsed_interface.o lib/frontend/typechecker.o lib/frontend/cnf.o lib/frontend/triggers.o lib/reasoners/sat_solver.o lib/reasoners/satml_frontend.o lib/reasoners/satml.o lib/reasoners/fun_sat.o lib/reasoners/sat_solver_sig.o lib/reasoners/theory.o lib/reasoners/ccx.o lib/reasoners/combine.o lib/reasoners/ite.o lib/reasoners/sum.o lib/reasoners/arrays.o lib/reasoners/bitv.o lib/reasoners/records.o lib/reasoners/arith.o lib/reasoners/intervalCalculus.o lib/reasoners/inequalities.o lib/reasoners/intervals.o lib/reasoners/use.o lib/reasoners/uf.o lib/reasoners/ac.o lib/reasoners/polynome.o lib/reasoners/instances.o lib/reasoners/matching.o lib/structures/profiling.o lib/structures/commands.o lib/structures/explanation.o lib/structures/satml_types.o lib/structures/formula.o lib/structures/literal.o lib/structures/fpa_rounding.o lib/structures/term.o lib/structures/typed.o lib/structures/errors.o lib/structures/parsed.o lib/structures/ty.o lib/structures/symbols.o lib/structures/exception.o lib/util/hstring.o lib/util/hconsing.o lib/util/loc.o lib/util/gc_debug.o lib/util/timers.o lib/util/iheap.o lib/util/vec.o lib/util/options.o lib/util/numbers.o lib/util/zarithNumbers.o lib/util/numsNumbers.o lib/util/lists.o lib/util/util.o lib/util/myZip.o lib/util/myDynlink.o lib/util/myUnix.o lib/util/emap.o lib/util/version.o lib/util/config.o /usr/lib64/ocaml/psmt2-frontend/psmt2Frontend.a /usr/lib64/ocaml/ocplib-simplex/ocplibSimplex.a /usr/lib64/ocaml/zip/zip.a /usr/lib64/ocaml/str.a /usr/lib64/ocaml/dynlink.a /usr/lib64/ocaml/unix.a /usr/lib64/ocaml/nums.a /usr/lib64/ocaml/zarith/zarith.a /usr/lib64/ocaml/stdlib.a -lcamlzip -lz -lcamlstr -lunix -lnums -lzarith -lgmp /usr/lib64/ocaml/libasmrun_pic.a -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl /usr/libexec/gcc/x86_64-redhat-linux/10/collect2 -plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper -plugin-opt=-fresolution=/tmp/ccB2PSiV.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -o alt-ergol.opt /usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/10/crtbeginS.o -L/usr/lib64/ocaml/num -L/usr/lib64/ocaml/zarith -L/usr/lib64/ocaml/lablgtk2 -L/usr/lib64/ocaml/threads -L/usr/lib64/ocaml/zip -L/usr/lib64/ocaml/ocplib-simplex -L/usr/lib64/oc
Re: Rebase of fmt to 7.0.0
On 29.07.2020 14:44, Richard W.M. Jones wrote: > Was this package built and then untagged? We delayed the build due issues[1-3] with the sphinx/doxygen documentation generator. As a workaround, we decided to temporary disable documentation generation. When the issues will be resolved, we will enable it again. [1]: https://github.com/sphinx-doc/sphinx/issues/8013 [2]: https://github.com/doxygen/doxygen/issues/7927 [3]: https://github.com/fmtlib/fmt/issues/1795 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390 builds failing with "All mirrors were tried"
On Wed, 29 Jul 2020, Richard W.M. Jones wrote: libnbd failed in the mass rebuild. I kicked off a second build by hand, and it failed in the exact same way: https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058 DEBUG util.py:623: Downloading Packages: DEBUG util.py:621: Error: Error downloading packages: DEBUG util.py:621:Cannot download toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm: All mirrors were tried Is this a generic s390 problem of is there really something wrong with the ocaml-compiler-libs package? If it's generic then I guess this sort of error could be affecting a lot of other packages in the mass rebuild. Seems to be a generic s390x problem (with networking / connectivity?). At least one of my packages failed in a similar was on s390x. Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable LTO for now ?
Disable LTO
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/5baaf4a99cc77572d3496a7000674098bef7ed68?branch=master
ср, 29 июл. 2020 г., 17:08 :
> Hello opencv [1] build also failed around LTO
> What is your advise ? What is your advice?
>
> Thanks,
>
> [1]
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48054416
>
>
> On 2020-07-27 23:46, notificati...@fedoraproject.org wrote:
> > Notification time stamped 2020-07-27 22:46:34 UTC
> >
> > From f4bac7efd3c251ffb64107bc2f522c1d3c829b5c Mon Sep 17 00:00:00 2001
> > From: Jeff Law
> > Date: Jul 27 2020 22:46:22 +
> > Subject: Disable LTO for now
> >
> >
> > ---
> >
> > diff --git a/apt.spec b/apt.spec
> > index a555b62..282ddc8 100644
> > --- a/apt.spec
> > +++ b/apt.spec
> > @@ -14,7 +14,7 @@
> >
> > Name: apt
> > Version:2.1.7
> > -Release:2%{?dist}
> > +Release:3%{?dist}
> > Summary:Command-line package manager for Debian packages
> >
> > License:GPLv2+
> > @@ -166,6 +166,10 @@ to package management with APT.
> > %autosetup -p1
> >
> > %build
> > +# This package fails its testsuite when LTO is enabled. It is not yet
> > clear if
> > +# this is an LTO issue or an issue with the package itself
> > +%define _lto_cflags %{nil}
> > +
> > %cmake -GNinja
> > %cmake_build
> >
> > @@ -308,6 +312,9 @@ exit 0
> > %doc %{_docdir}/%{name}-utils
> >
> > %changelog
> > +* Mon Jul 27 2020 Jeff law - 2.1.7-3
> > +- Disable LTO for now
> > +
> > * Mon Jul 27 2020 Fedora Release Engineering
> > - 2.1.7-2
> > - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
> >
> >
> >
> >
> https://src.fedoraproject.org/rpms/apt/c/f4bac7efd3c251ffb64107bc2f522c1d3c829b5c?branch=master
> >
> > --
> > You received this message due to your preference settings at
> >
> https://apps.fedoraproject.org/notifications/sergiomb.id.fedoraproject.org/email/49394
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi, On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote: > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > > with: > > > > error: Empty %files file > > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > > > However it works when I build locally: > > > > $ rpm -qlp > > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > > [etc] > > > > There's an earlier error which occurs in the Koji build which doesn't > > occur for me locally but looks related: > > > > Dwarf Error: wrong version in compilation unit header (is 0, should be 2, > > 3, 4 or 5) [in module > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > > gdb-add-index: No index was created for > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > > > Did something change with DWARF or gdb in Rawhide that we should be > > aware of? Obviously these are not C code and OCaml has its own DWARF > > generator. > > I think mjw is tracking something like this yesterday, but it was aarch64. > I'm > going to be offline for a couple hours, but you might want to reach out to him > and see if there's any useful state (on cc) This looks unrelated to what I was looking at, which was indeed aarch64 specific (but doesn't actually seem to be impacting the mass rebuild): https://bugzilla.redhat.com/show_bug.cgi?id=1861423 The above happens if none of the debuginfo could be read at all, so no source files could be extracted. Given these are .ml files I suspect it is not gcc, but some other code/DWARF generator issue. Maybe it does use the default (binutils) liker though? Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we can inspect it? Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > with: > > error: Empty %files file > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > However it works when I build locally: > > $ rpm -qlp > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > [etc] > > There's an earlier error which occurs in the Koji build which doesn't > occur for me locally but looks related: > > Dwarf Error: wrong version in compilation unit header (is 0, should be 2, > 3, 4 or 5) [in module > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > gdb-add-index: No index was created for > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > Did something change with DWARF or gdb in Rawhide that we should be > aware of? Obviously these are not C code and OCaml has its own DWARF > generator. I think mjw is tracking something like this yesterday, but it was aarch64. I'm going to be offline for a couple hours, but you might want to reach out to him and see if there's any useful state (on cc) Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable LTO for now ?
On Wed, 2020-07-29 at 14:13 +0100, ser...@serjux.com wrote: > Hello opencv [1] build also failed around LTO > What is your advise ? What is your advice? In general I want to have a very good indicator the issue is LTO related before I disable. THe build you referenced doesn't have any good indicators that LTO is the problem. For ppc64le is that the build was done with p8, but there is one function (__builtin_altivec_vadub) that requires p9. This seems like a package bug at first glance, not an LTO issue. I would try a ppc64le test build with and without LTO, my guess is both are going to fail with similar problems. For s390 I would guess that it got aborted -- there's nothing useful in the build.log. So I'd try an LTO test build of that. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390 builds failing with "All mirrors were tried"
libnbd failed in the mass rebuild. I kicked off a second build by hand, and it failed in the exact same way: https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058 DEBUG util.py:623: Downloading Packages: DEBUG util.py:621: Error: Error downloading packages: DEBUG util.py:621:Cannot download toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm: All mirrors were tried Is this a generic s390 problem of is there really something wrong with the ocaml-compiler-libs package? If it's generic then I guess this sort of error could be affecting a lot of other packages in the mass rebuild. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x chroots added to Copr
We know about this possibility, but we still want to try to use RHEL directly in Copr, as discussed here https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/43SHF6FAE6Z4QKKFOVRWIKQDT5SSA5RI/ Silvie Chlupova On Tue, Jul 28, 2020 at 9:16 PM R P Herrold wrote: > On Tue, 28 Jul 2020, Silvie Chlupova wrote: > > > Epel 7 isn't built for s390x architecture at all, so we don't have the > > needed mirrors to build against. It will not be enabled. > > The ClefOS 7 binaries include all of EPEL 7 and more > > http://download.sinenomine.net/clefos/epel7/ > > -- Russ herrold > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
On 29/07/2020 14:47, Richard Shaw wrote: > I couldn't find the capability within fedpkg or koji so for posterity > I came up with this: > > $ for rpm in $(lynx -dump -listonly > "https://koji.fedoraproject.org/koji/taskinfo?taskID=48063412"; | grep > "rpm$"); do curl -LO $rpm; done > > Thanks, > RIchard > > koji download-task 48063412 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
ceph -> qemu -> lots failing in the mass rebuild
qemu is uninstallable at the moment because ceph is uninstallable because fmt was upgraded from 6 to 7 in the middle of the build (resulting in an soname bump - it was announced). There are quite a few things failing in the mass rebuild as a result. I've kicked off a new build of ceph, and will follow up with qemu if that's necessary, but note that ceph takes ~ 24 hours to build, so it'll be a while ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned rubygem-fast_gettext
Hi, I have orphaned rubygem-fast_gettext, because I have no use for it, neither anything else depends on it. VĂt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
On Wed, Jul 29, 2020 at 3:31 PM Richard Shaw wrote: > > I'm working on fixing a package but I have to use scratch builds because the > tests only pass when running on koji, not a local mock build. It produces > several rpms which I'd like to download for testing purposes. > > Currently I have to go to the url of the scratch build and download them > individually. Is there an easier way? > > https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds > > didn't provide any help. Did you try "koji download-task foo" / "koji download-build foo"? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Disable LTO for now ?
Hello opencv [1] build also failed around LTO
What is your advise ? What is your advice?
Thanks,
[1]
https://koji.fedoraproject.org/koji/taskinfo?taskID=48054416
On 2020-07-27 23:46, notificati...@fedoraproject.org wrote:
Notification time stamped 2020-07-27 22:46:34 UTC
From f4bac7efd3c251ffb64107bc2f522c1d3c829b5c Mon Sep 17 00:00:00 2001
From: Jeff Law
Date: Jul 27 2020 22:46:22 +
Subject: Disable LTO for now
---
diff --git a/apt.spec b/apt.spec
index a555b62..282ddc8 100644
--- a/apt.spec
+++ b/apt.spec
@@ -14,7 +14,7 @@
Name: apt
Version:2.1.7
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Command-line package manager for Debian packages
License:GPLv2+
@@ -166,6 +166,10 @@ to package management with APT.
%autosetup -p1
%build
+# This package fails its testsuite when LTO is enabled. It is not yet
clear if
+# this is an LTO issue or an issue with the package itself
+%define _lto_cflags %{nil}
+
%cmake -GNinja
%cmake_build
@@ -308,6 +312,9 @@ exit 0
%doc %{_docdir}/%{name}-utils
%changelog
+* Mon Jul 27 2020 Jeff law - 2.1.7-3
+- Disable LTO for now
+
* Mon Jul 27 2020 Fedora Release Engineering
- 2.1.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
https://src.fedoraproject.org/rpms/apt/c/f4bac7efd3c251ffb64107bc2f522c1d3c829b5c?branch=master
--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/sergiomb.id.fedoraproject.org/email/49394
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
golang-github-logrusorgru-aurora license change
Hi, golang-github-logrusorgru-aurora changed license from WTFPL to Unlicense. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
koji download-task 415255 On 2020-07-29 13:37, Richard Shaw wrote: I'm working on fixing a package but I have to use scratch builds because the tests only pass when running on koji, not a local mock build. It produces several rpms which I'd like to download for testing purposes. Currently I have to go to the url of the scratch build and download them individually. Is there an easier way? https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds didn't provide any help. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help with reviewing a compiler toolchain
On 28/07/20 22:46 +0200, Andy Mender wrote: Dear Fedorians, I really need some help with a review of a GCC toolchain variant I've started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884 A Koji build of the most recent SRPM: https://koji.fedoraproject.org/koji/taskinfo?taskID=48035045 Some minor issues have been fixed already, but the toolchain seems quite complicated and frankly it went over my head :(. I'll take a look. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
On Wed, Jul 29, 2020 at 07:37:31AM -0500, Richard Shaw wrote: > I'm working on fixing a package but I have to use scratch builds because > the tests only pass when running on koji, not a local mock build. It > produces several rpms which I'd like to download for testing purposes. > > Currently I have to go to the url of the scratch build and download them > individually. Is there an easier way? koji download-task ? > https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds > > didn't provide any help. > > Thanks, > Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On Wed, Jul 29, 2020 at 01:44:34PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 07, 2020 at 04:56:40PM +0200, Vitaly Zaitsev via devel wrote: > > Hello all. > > > > Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next > > week. > > > > This will include soversion bump from 6 to 7. All dependent packages > > must be rebuilt. > > > > Please check your packages, because there are some breaking API changes: > > https://github.com/fmtlib/fmt/releases/tag/7.0.0 > > Was this package built and then untagged? > > It seems as if ceph was built yesterday, and it picked up > fmt 6.2.1: > > https://kojipkgs.fedoraproject.org//packages/ceph/15.2.4/10.fc33/data/logs/x86_64/root.log > > However it's not installable in the buildroot for qemu builds > because libfmt.so.6 isn't available: > > https://kojipkgs.fedoraproject.org//work/tasks/1162/4862/root.log Actually ignore that - I see the problem. fmt 7 was only built yesterday so some of the mass rebuild packages will have been built against 7 and others (like ceph) will have been built against 6. I've kicked off a rebuild of ceph which will hopefully fix it for librados2, but maybe other packages are out there which will depend on the wrong libfmt.so.6. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Download all build artifacts from a scratch build?
I couldn't find the capability within fedpkg or koji so for posterity I came up with this: $ for rpm in $(lynx -dump -listonly " https://koji.fedoraproject.org/koji/taskinfo?taskID=48063412"; | grep "rpm$"); do curl -LO $rpm; done Thanks, RIchard > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
RE: Query on upgrading the Fedora package
Hi Jonathan, Thanks for the info. Regards, Muneendra. -Original Message- From: Jonathan Wakely [mailto:jwak...@fedoraproject.org] Sent: Wednesday, July 29, 2020 5:16 PM To: Development discussions related to Fedora Cc: Muneendra Kumar M Subject: Re: Query on upgrading the Fedora package >I don't know what part of the procedure you're unclear about, so here's >a summary of the entire process from start to finish. > >Get the package sources: > >fedpkg clone fctxpd >cd fctxpd > >Now download the new upstream code. >Optionally verify the package was downloaded correctly by checking a >SHA or other hash. > >Open the fctxpd.spec file in your preferred editor. Update the various >versions (commit, snapshotdate etc.) and add a new entry to the >%changelog section. Save the file. > >Create a SRPM from the changed (but not committed spec file): Oops, this was meant to say: Create a SRPM from the changed (but not committed) spec file: >fedpkg srpm > >Run a scratch build in the koji build system: > >fedpkg scratch-build --srpm $(fedpkg verrel).src.rpm > >Wait for the results, check them, fix any problems. > >Once you have a working package, commit your changes to the spec file: > >fedpkg new-sources NEW-UPSTREAM-TARBALL.tar.gz fedpkg commit -c And your mail software seems to have lost a newline between these two commands: fedpkg new-sources NEW-UPSTREAM-TARBALL.tar.gz fedpkg commit -c > >And publish them: > >fedpkg push > >And do the real build: > >fedpkg build I should also say that these steps are not the _only_ way to do it (they're not even the way I would do it most of the time). But they should be a simple-to-follow sequence that is relatively hard to screw up. Use 'man fedpkg' to find out more about each step, and see these links for additonal background information: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ https://fedoraproject.org/wiki/Package_maintenance_guide https://fedoraproject.org/wiki/Package_update_HOWTO ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rebase of fmt to 7.0.0
On Tue, Jul 07, 2020 at 04:56:40PM +0200, Vitaly Zaitsev via devel wrote: > Hello all. > > Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next > week. > > This will include soversion bump from 6 to 7. All dependent packages > must be rebuilt. > > Please check your packages, because there are some breaking API changes: > https://github.com/fmtlib/fmt/releases/tag/7.0.0 Was this package built and then untagged? It seems as if ceph was built yesterday, and it picked up fmt 6.2.1: https://kojipkgs.fedoraproject.org//packages/ceph/15.2.4/10.fc33/data/logs/x86_64/root.log However it's not installable in the buildroot for qemu builds because libfmt.so.6 isn't available: https://kojipkgs.fedoraproject.org//work/tasks/1162/4862/root.log So that's all a bit odd ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Download all build artifacts from a scratch build?
I'm working on fixing a package but I have to use scratch builds because the tests only pass when running on koji, not a local mock build. It produces several rpms which I'd like to download for testing purposes. Currently I have to go to the url of the scratch build and download them individually. Is there an easier way? https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds didn't provide any help. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
El lun., 6 jul. 2020 a las 18:15, Samuel Sieb () escribió: > On 7/6/20 1:48 PM, Sergio Belkin wrote: > > At > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F > > it says: > > > > "Do not create swap partition/LV with default installations." > > I don't understand if it is a description or a prescription :)I mean, > > can coexist swap partition/LV and zram? > > Yes, zram is just a compressed block device in RAM and it's being used > here as swap. You can have multiple swap devices active at the same > time. That's what I'm currently using. I have a zram swap device and a > disk swap partition as overflow. But the plan is to avoid having any > swap on disk by default. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Thanks, event for the late answer :) For the record, I'm using zram as a swap device and I disabled the swap on disk. I have 16 GB of RAM and am using earlyoom on F32. There was only one several issue using a lot of apps and VirtualBox VM's. HTH -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: DWARF version 0 unhandled
On Tue, Jul 28, 2020 at 08:58:22PM -0600, Jeff Law wrote: > On Tue, 2020-07-28 at 16:26 -0600, Jerry James wrote: > > Here's a bit of fallout from the mass rebuild. The alt-ergo build failed: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1548139 > [ ... ] > You might try without LTO. I'm just shooting in the dark, but LTO does have a > significant impact on how we generate debuginfo as well as impacting the > structure of the resultant debug info. > > While I haven't seen anything like what you've shown it can't hurt to at least > see if LTO is playing a role here. I just started a new thread without seeing this one. We have a similar problem for OCaml code which won't be LTO related: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5GDU2TDF7UKO73UFAV67IKQHDOBHHJYS/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
No debugsource generated, weird DWARF errors
https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails with: error: Empty %files file /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list However it works when I build locally: $ rpm -qlp /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm /usr/src/debug/hevea-2.34-7.fc33.x86_64 /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml [etc] There's an earlier error which occurs in the Koji build which doesn't occur for me locally but looks related: Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4 or 5) [in module /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] gdb-add-index: No index was created for /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha gdb-add-index: [Was there no debuginfo? Was there already an index?] Did something change with DWARF or gdb in Rawhide that we should be aware of? Obviously these are not C code and OCaml has its own DWARF generator. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Query on upgrading the Fedora package
I don't know what part of the procedure you're unclear about, so here's a summary of the entire process from start to finish. Get the package sources: fedpkg clone fctxpd cd fctxpd Now download the new upstream code. Optionally verify the package was downloaded correctly by checking a SHA or other hash. Open the fctxpd.spec file in your preferred editor. Update the various versions (commit, snapshotdate etc.) and add a new entry to the %changelog section. Save the file. Create a SRPM from the changed (but not committed spec file): Oops, this was meant to say: Create a SRPM from the changed (but not committed) spec file: fedpkg srpm Run a scratch build in the koji build system: fedpkg scratch-build --srpm $(fedpkg verrel).src.rpm Wait for the results, check them, fix any problems. Once you have a working package, commit your changes to the spec file: fedpkg new-sources NEW-UPSTREAM-TARBALL.tar.gz fedpkg commit -c And your mail software seems to have lost a newline between these two commands: fedpkg new-sources NEW-UPSTREAM-TARBALL.tar.gz fedpkg commit -c And publish them: fedpkg push And do the real build: fedpkg build I should also say that these steps are not the _only_ way to do it (they're not even the way I would do it most of the time). But they should be a simple-to-follow sequence that is relatively hard to screw up. Use 'man fedpkg' to find out more about each step, and see these links for additonal background information: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ https://fedoraproject.org/wiki/Package_maintenance_guide https://fedoraproject.org/wiki/Package_update_HOWTO ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How do Fedora developers get access to devtoolset for testing.
On 29/07/20 10:23 +0200, Florian Weimer wrote: * Jonathan Wakely: It's not about devtoolset. Installing CentOS 7 RPMs on Fedora rawhide is outlandish. It won't work in general, because the CentOS RPMs have dependencies on CentOS packages, and Fedora has different versions. Steven has a point, though. For software not built by Red Hat, installing RPMs on Fedora works most of the time even if they have been packaged for the enterprise downstreams (or vice versa, sometimes the intended user base is not entirely clear). Yes, third-party packagers usually want to minimise the number of builds they have to do, and ship a package that works across as many versions of a distro as possible. e.g. they just provide an rpm and a .deb and those are expected to work on any RPM-based distro or any Debian-derived distro that is sufficiently recent, maybe with a .tar.gz containing a standalone binary for everything else that doesn't use rpm or dpkg. That's sometimes done via static linking, and/or bundling dependencies in the package. But packages from the Fedora and CentOS repos are generally specific to that distro, usually even a specific version of that distro. Each package can be (and usually is) rebuilt and re-packaged as needed for each distro release. We don't need to build it once and have it keep working on later releaases, because we have a separate repo for each release and we have build systems that rebuild everything. And we don't want to use static linking or bundling. So yes, that's a significant difference between third-party packages (minimise dependencies for portability) and packages from the distro's own repos (minimise bundling for maintainability and security). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
diffmark license corrected
I corrected diffmark license from "diffmark and GPLv2+ and (GPL+ or Artistic)" to "diffmark and (GPL+ or Artistic)". -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F33 Change proposal: DXVK as default wined3d backend on VK capable hardware (Self-Contained Change)
On Thursday, 23 July 2020 at 15:48, Frantisek Zatloukal wrote: > On Thu, Jul 23, 2020 at 2:18 PM Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: > > > Is Vulkan supported on AMD Radeon HD 7900 series (TAHITI)? Some > > sources I found say it is: > > > > https://vulkan.gpuinfo.org/listreports.php?devicename=AMD%20Radeon%20HD%207900%20Series > > but vulkaninfo just gives me an error despite my having > > mesa-vulkan-drivers installed. > > On this generation of GPUs, you'd need to use an AMDGPU driver instead of > RadeonSI to get Vulkan Support. You can do that by adding > 'radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 > amdgpu.cik_support=1' to your kernel cmdline. vulkaninfo shouldn't output > any errors after doing that. I don't want to use amdgpu driver yet, because it lacks hardware video decoding. See https://gitlab.freedesktop.org/drm/amd/-/issues/577 . Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How do Fedora developers get access to devtoolset for testing.
* Jonathan Wakely: > It's not about devtoolset. Installing CentOS 7 RPMs on Fedora rawhide > is outlandish. It won't work in general, because the CentOS RPMs have > dependencies on CentOS packages, and Fedora has different versions. Steven has a point, though. For software not built by Red Hat, installing RPMs on Fedora works most of the time even if they have been packaged for the enterprise downstreams (or vice versa, sometimes the intended user base is not entirely clear). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned unboundid-ldapsdk
Hi, following https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Orphaning_Procedure I'm notifying devel mailing list I orphaned unboundid-ldapsdk so that others have a chance to take over as maintainer. Thanks, Sandro Bonazzola ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
Hi all, first I would like to recommend you to try the steps here: https://vimhelp.org/vim_faq.txt.html#faq-2.5 it should help you find out where the problem can be. If you are able to reproduce the issue with the first step, please file a bug on bugzilla.redhat.com. Thank you in advance! On 7/29/20 7:52 AM, Tomasz Torcz wrote: > On Sat, Jul 25, 2020 at 08:21:53AM -0500, Richard Shaw wrote: >> After upgrading to Fedora 32 I've noticed when editing files, especially >> spec files that vim does some crazy jumps/indents that it didn't do before. >> >> Right now I'm pressing i to insert a line before a Requires: and when I hit >> enter it jumps to the next line (fine) but with 4 indents and one space... >> WTF? >> >> Anyone else seeing strange vim behavior? > I've noticed overzealous indent while editing yaml files. I wanted > to provide example when it turned out vim also _unindents_. This is > quite jarring. > > Example: edit a yaml file, write > #v+ > some: text > #v- > > Press ENTER, cursor goes to the next line, indented 2 space. Write more: > #v+ > some: text > write > #v- > > As soon as you put “:”, whole line gets _moved back_: > #v+ > some: text > write: more > #v- > > Ugh. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned rubygem-elasticsearch-api
Hi, following https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers... I'm notifying devel mailing list I orphaned rubygem-elasticsearch-api so that others have a chance to take over as maintainer. Thanks, Sandro Bonazzola ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned rubygem-elasticsearch
Hi, following https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Orphaning_Procedure I'm notifying devel mailing list I orphaned rubygem-elasticsearch so that others have a chance to take over as maintainer. Thanks, Sandro Bonazzola ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
