Re: Please update Darktable to latest stable on Fedora 33

[Luya Tshimbalanga]

On 2020-09-24 6:00 p.m., Erich Eickmeyer wrote:


This type of question really needs to be a bug report against the 
darktable package, not a conversation in this list. Looks like @madko 
is listed as the maintainer and @germano was the last person to build 
push an update, but neglected F33. Such oversight does not seem very good.

--
Erich Eickmeyer Fedora Jam Maintainer


I initially planned to file a bug report but it was already 
automatically done on 
https://bugzilla.redhat.com/show_bug.cgi?id=1863394 and 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=darktable&list_id=11382514&product=Fedora&product=Fedora%20EPEL


Rather than duplicating the ticket, asking a question for updates on the 
mailing list seems quicker. Maybe some proven packagers can land their 
hands addressing the bugs.


--
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: Please update Darktable to latest stable on Fedora 33

[Johannes Lips]

In defense of the maintainers, these build dates are right around f33 branching 
on August 11th, so perhaps that is the reason, why they've missed f33.

johannes
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Dominique Martinet]

Jan Kratochvil wrote on Thu, Sep 24, 2020:
> > That talk doesn't load for me, sorry if I ask something answered in
> > there.
> 
> I have added a title there now but the URL loads for me even in lynx+wget.

Yeah sorry it finally loaded after 10+ minutes, that was weird.

> Copy-pasted it at the bottom of this mail. I do not know the talk but TL;DR
> existing DWARF contains some dead DIEs - unused/deduplicated functions and 
> also
> -fdebug-types-section declarations/skeletons which can be removed or converted
> to direct DIE references respectively. That way one could reduce the size like
> DWZ does but without needing any new complicated support in DWARF consumers.

Ok, avoiding duplicate data makes sense there is quite a lot in there.

> That is orthogonal - that is one can add it to DWZ or -fdebug-types-section
> the same way. It would be for another Fedora Change proposal but I do not
> think it matters for F-33 as it already implements:
>   https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression

Good point. I did think of rpm size (double compression doesn't work
well and rpms use better compression than zlib) but not filesystem
compression.
Everyone won't benefit from that right away but I guess it makes sense.

> I haven't yet checked whether that applies to /usr/lib/debug/ by default.
> btrfs is using zstd which has better performance than zlib. I was considering
> adding an ELF section compression extension for zstd but with btrfs
> transparent compression that looks as not useful.

I don't have very much there but it does work well:
# compsize  /usr/lib/debug/
Processed 720 files, 2232 regular extents (2239 refs), 1 inline.
Type   Perc Disk Usage   Uncompressed Referenced  
TOTAL   32%   74M 229M 230M   
none   100%  644K 644K 644K   
zstd32%   73M 229M 229M   


> That 3.3% size reduction=advantage of DWZ against -fdebug-types-section is
> calculated for *-debuginfo.rpm (3.3% is for the whole distribution incl.
> binaries, for debug/ itself it is 6.35%). Also it is calculated for DWARF-4,
> F-34 will hopefully switch to DWARF-5 (which is smaller by 10-20%) but DWZ is
> not yet ported to DWARF-5 so it is impossible to compare -fdebug-types-section
> vs. DWZ size for DWARF-5.

Ok.
That definitely makes more sense to me, thanks for clarifying this.

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

Self Introduction: Ruki Wang

[Ruki Wang]

Hi, all!

I'm Ruki Wang, a full stack developer from China. I'm creator of @tboox
 and @xmake-io  Open
Source Groups. My Github: https://github.com/waruqi

I am developing xmake  now.

it's a lightweight cross-platform build utility based on Lua.

It uses xmake.lua to maintain project builds. Compared with
makefile/CMakeLists.txt, the configuration syntax is more concise and
intuitive. It is very friendly to novices and can quickly get started in a
short time. Let users focus more on actual project development.

It can compile the project directly like Make/Ninja, or generate project
files like CMake/Meson, and it also has a built-in package management
system to help users solve the integrated use of C/C++ dependent libraries.

I have made it into an rpm package and uploaded it to the copr repository.
https://copr.fedorainfracloud.org/coprs/waruqi/xmake/

I know, now I can install it with the following command.

sudo dnf copr enable waruqi/xmakesudo dnf install xmake


But what I want to know is how should I do next to submit my package to
fedora's official repository?
So that I can directly execute the following command to install the package
I uploaded.

sudo dnf install xmake


Thanks!

-- 

Ruki Wang
war...@gmail.com
https://github.com/waruqi
https://twitter.com/waruqi
___
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

Prodi Manajemen UMa

[Manajemen UMA]

http://manajemen.uma.ac.id/
___
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: Non-responsive maintainer: fedpop

[Carl George]

Pull request has been rebased and is ready to be merged.  Thanks for
your help with this Richard.

On Thu, Sep 24, 2020 at 6:59 PM Richard Shaw  wrote:
>
> On Thu, Sep 24, 2020 at 4:34 PM Carl George  wrote:
>>
>> I read the policy [0] as "major (bug | security) fixes", and the CVE
>> is only rated as moderate [1].  Should the policy be read as "(major
>> bug | any security) fixes"?  I am not opposed to building the update
>> on F31 as well.
>>
>> [0] 
>> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates
>> [1] https://access.redhat.com/security/cve/CVE-2020-13962
>
>
> I'm not worried about getting that nit-pickey... If it addresses a CVE that's 
> good enough for me.
>
> It looks like mumble was rebuilt for a new protobuf, can you update (rebase) 
> your pull request so it's mergeable?
>
> If you can do that fairly soon I'll try to make some time to merge it and 
> perform the builds and push new updates.
>
> 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



-- 
Carl George
___
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: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thu, Sep 24, 2020 at 4:02 pm, Michel Alexandre Salim 
 wrote:

On Thu, 2020-09-24 at 14:41 -0700, Erich Eickmeyer wrote:



 On Thu, Sep 24, 2020 at 2:39 pm, Luya Tshimbalanga <
 l...@fedoraproject.org > wrote:
 >
 > When upgrading from Fedora 32 to 33 beta, I notice Darktable is on
 > 3.0. 3.2.1-1.fc32. Will it be possible to push to the latest
 > version before Fedora 33 release?
 >

 Looks to me like whoever did the build forgot to do the bohdi update
 for 33, probably because it had branched just prior to that update.


Do we no longer do N-V-R checks when higher releases have older
packages than older releases?




I don't know what that means, but I almost always do my initial 
building in rawhide followed by builds and updates to all currently 
supported Fedora releases.


A cursory glance at https://src.fedoraproject.org/rpms/darktable shows 
that F32 and F31 indeed have a newer version of Darktable than F33. F33 
doesn't even have a build currently in testing, so I find this to be 
highly problematic that builds aren't getting pushed to F33.


This type of question really needs to be a bug report against the 
darktable package, not a conversation in this list. Looks like @madko 
is listed as the maintainer and @germano was the last person to build 
push an update, but neglected F33. Such oversight does not seem very 
good.


--
Erich Eickmeyer
Fedora Jam 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: Non-responsive maintainer: fedpop

[Richard Shaw]

On Thu, Sep 24, 2020 at 4:34 PM Carl George  wrote:

> I read the policy [0] as "major (bug | security) fixes", and the CVE
> is only rated as moderate [1].  Should the policy be read as "(major
> bug | any security) fixes"?  I am not opposed to building the update
> on F31 as well.
>
> [0]
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates
> [1] https://access.redhat.com/security/cve/CVE-2020-13962


I'm not worried about getting that nit-pickey... If it addresses a CVE
that's good enough for me.

It looks like mumble was rebuilt for a new protobuf, can you update
(rebase) your pull request so it's mergeable?

If you can do that fairly soon I'll try to make some time to merge it and
perform the builds and push new updates.

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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Mark Wielaard]

Hi,

Replying since I am mentioned by name in this proposal and it seems to
argue for removing a feature I am currently working on to make sure it
works correctly with GCC11 if it switches to producing DWARF5 by
default. The proposal seems based on some misunderstandings.

On Thu, Sep 24, 2020 at 11:59:44AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> 
> == Summary ==
> Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> not get widespread and the tool is not much maintained

As others pointed out dwz is widely used. It is used by almost every
distro in some form and even freedesktop.org flatpaks use dwz for
their debuginfo.

The upstream project is actively maintained. Even though there are
just 3 committers (including me) the project is still seeing ~2.5
commits a week (about 130 in a year).

> There exist several methods
> how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> started using DWZ tool (from [[Features/DwarfCompressor]]) while
> [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> Google implemented] the same goal in a different way called
> -fdebug-types-section.

Note that these methods are not in conflict. Both started out as GNU
extensions but have been standardized since.

> so its support is missing in tools like
> [https://lldb.llvm.org/ LLDB],

But you have been maintaining an out of tree patch for several years
to support partial units and supplemental files (both of which dwz
produces and are now standard DWARF). It would be good if you
upstreamed those patches.

> [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]

Note that normal dwarfdump as shipped with libdwarf-tools does support
both partial units and supplemental files (you do need to provide the
alt file with --file-tied=/path/to/alt-file which probably should be
done automatically).

> or binutils readelf.

binutils readelf is used as the main tool in the dwz testsuite. It
certainly supports both partial units and supplemental files. Also
note the the -wK (=follow-links) option [it isn't on by default, maybe
it should] that resolves alt links.

I don't know of any other tool which doesn't support either partial
units or supplemental files, since both are (now) standard DWARF.

> * DWZ disadvantage: DWZ requires 8x times more complicated (LoC count)
> support in consumers than -fdebug-types-section.

I have worked on support for both in various consumers and didn't find
one method more difficult to support than the other. Maybe debug-types
was actually more difficult. Because the representation changed from
separate section in DWARF4, to intermingled with other .debug_info
units in DWARF5. Making supporting objects that contained mixed
versions a bit of a pain.

> * DWZ disadvantage: DWZ cannot update LLVM .debug_names index which
> can be generated only by clang (it cannot be regenerated later for
> DWZ-compressed file)

dwz does support .gdb_index, the pre-standardized DWARF5 .debug_names
variant. gdb hasn't switched to supporting .debug_names yet and
.gdb_index does work with DWARF5. I don't think the gdb maintainers
would mind you adding .debug_names support if you believe it to be
better than .gdb_index.

> * DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has
> been blocking DWARF-5 for Fedora for 3.5 years and only after I have
> now proposed to drop DWZ Mark Wielaard has started porting DWZ to
> DWARF-5.

I have worked on DWARF5 support for various projects for the last
couple of years. Since it looks like GCC11 might switch to DWARF5 by
default I started added DWARF5 support to dwz. I started that earlier
this month after we had a discussion on DWARF5 at the virtual GNU
Tools Cauldron, I didn't know you were proposing to drop DWZ in
Fedora. You can follow the progress on the dwz mailinglist.
https://sourceware.org/pipermail/dwz/current/

> This proposed DWARF format was originally submitted already for Fedora
> 18 as [[Features/DebugTypesSections]].

Note that it isn't a different format, just an additional way to
represent some parts of DWARF. I have also proposed gcc would emit
debug-types by default and even discussed it two times at the GNU
Tools Cauldron. But I couldn't get buy-in from the GCC hackers that it
is a good idea. And I do think they have a point. It is a not very
flexible design with a somewhat high overhead (somewhat reduced in
DWARF5 by not making it part of a separate section). If you think it
really is a good idea to use them more broadly and by default then you
should probably start by getting consensus from the upstream gcc
developers that it should be enabled by default. I don't think it is
in conflict with also using dwz. But it will probably require some
extra work.

Cheers,

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

Re: Please update Darktable to latest stable on Fedora 33

[Michel Alexandre Salim]

On Thu, 2020-09-24 at 14:41 -0700, Erich Eickmeyer wrote:
> 
> 
> On Thu, Sep 24, 2020 at 2:39 pm, Luya Tshimbalanga <
> l...@fedoraproject.org> wrote:
> >   
> > When upgrading from Fedora 32 to 33 beta, I notice Darktable is on
> > 3.0. 3.2.1-1.fc32. Will it be possible to push to the latest
> > version before Fedora 33 release?
> >  
> 
> Looks to me like whoever did the build forgot to do the bohdi update
> for 33, probably because it had branched just prior to that update.
> 
Do we no longer do N-V-R checks when higher releases have older
packages than older releases?

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thu, Sep 24, 2020 at 2:39 pm, Luya Tshimbalanga 
 wrote:
When upgrading from Fedora 32 to 33 beta, I notice Darktable is on 
3.0. 3.2.1-1.fc32 
. Will 
it be possible to push to the latest version before Fedora 33 release?


Thanks

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer


Looks to me like whoever did the build forgot to do the bohdi update 
for 33, probably because it had branched just prior to that update.


--
Erich Eickmeyer
Fedora Jam 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

Please update Darktable to latest stable on Fedora 33

[Luya Tshimbalanga]

When upgrading from Fedora 32 to 33 beta, I notice Darktable is on 3.0. 
3.2.1-1.fc32 
. Will it 
be possible to push to the latest version before Fedora 33 release?


Thanks

--
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: Non-responsive maintainer: fedpop

[Carl George]

I read the policy [0] as "major (bug | security) fixes", and the CVE
is only rated as moderate [1].  Should the policy be read as "(major
bug | any security) fixes"?  I am not opposed to building the update
on F31 as well.

[0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates
[1] https://access.redhat.com/security/cve/CVE-2020-13962

On Thu, Sep 24, 2020 at 11:17 AM Ian McInerney  wrote:
>
> In your original email you said that this resolves CVE bug [1], which says in 
> it:
>
> "NOTE: this issue affects multiple supported versions of Fedora. While only 
> one tracking bug has been filed, please correct all affected versions at the 
> same time.  If you need to fix the versions independent of each other, you 
> may clone this bug as appropriate."
>
> That to me sounds like the CVE should be patched in F31 as well - so since 
> this update fixes it, the update would be suitable for F31.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1849735
>
> -Ian
>
> On Thu, Sep 24, 2020 at 5:01 PM Carl George  wrote:
>>
>> F32 is fine by me.  Based on the updates policy [0], I don't believe
>> this update qualifies under the "major bug fixes and security fixes"
>> restriction for the previous stable release.
>>
>> [0] 
>> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates
>>
>> On Wed, Sep 23, 2020 at 2:54 PM Richard Shaw  wrote:
>> >
>> > On Wed, Sep 23, 2020 at 2:42 PM Carl George  wrote:
>> >>
>> >> Yes, the patch is from an upstream pull request [0] that has already
>> >> been merged to the master branch [1] and is planned to be included in
>> >> their next release [2] (it's not part of the current 1.3.2 tag).  The
>> >> pull request includes a comment linking to said pull request, per the
>> >> packaging guidelines [3].  Mumble's traditional push-to-talk
>> >> functionality doesn't work under Wayland; this patch adds dbus calls
>> >> that can be mapped to keyboard shortcuts as a workaround.  I've built
>> >> it like this in COPR [4] and it's worked great for me so far.
>> >
>> >
>> > So next, question... Do builds need to be performed all the way back to 
>> > f31, or is f32 okay?
>> >
>> > 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
>>
>>
>>
>> --
>> Carl George
>> ___
>> 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



-- 
Carl George
___
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: `python3 setup.py build` step segfaults while building in mock for rawhide

[Ankur Sinha]

On Thu, Sep 24, 2020 14:22:04 -0600, Jerry James wrote:
> On Thu, Sep 24, 2020 at 2:08 PM Ankur Sinha  wrote:
> > AHA! Thanks! Could you list the steps you took to debug this please? I
> > didn't know quite where to start. XD
> >
> > Also, any reason why this happens on rawhide but not F33?
> 
> I'm afraid I have no idea why it is happening on Rawhide but not F33.
> Here are the steps:
> 
> - Download your spec and sources, make an SRPM, run mock, verify that
> the crash happens.
> - mock -r fedora-rawhide-x86_64 --enablerepo=fedora-debuginfo
> --install gdb gcc-gdb-plugin neuron-debuginfo
> - mock -r fedora-rawhide-x86_64 --shell
> - su - mockbuild
> - cd build/BUILD/netpyne-0.9.7
> - gdb /usr/bin/python3
> - run setup.py build --executable="/usr/bin/python3 -s"

Thanks very much, I'll tinker around and see what I can find.


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

rust-bytemuck license change: zlib -> zlib or ASL 2.0 or MIT

[Fabio Valentini]

The subject says it all ... with the update to rust-bytemuck 1.4.1,
the license changed from zlib only to zlib OR ASL 2.0 OR MIT. Since
this is less restrictive (and matches the rest of the Rust ecosystem
better), this is a good thing TM I guess :)

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

Re: `python3 setup.py build` step segfaults while building in mock for rawhide

[Jerry James]

On Thu, Sep 24, 2020 at 2:08 PM Ankur Sinha  wrote:
> AHA! Thanks! Could you list the steps you took to debug this please? I
> didn't know quite where to start. XD
>
> Also, any reason why this happens on rawhide but not F33?

I'm afraid I have no idea why it is happening on Rawhide but not F33.
Here are the steps:

- Download your spec and sources, make an SRPM, run mock, verify that
the crash happens.
- mock -r fedora-rawhide-x86_64 --enablerepo=fedora-debuginfo
--install gdb gcc-gdb-plugin neuron-debuginfo
- mock -r fedora-rawhide-x86_64 --shell
- su - mockbuild
- cd build/BUILD/netpyne-0.9.7
- gdb /usr/bin/python3
- run setup.py build --executable="/usr/bin/python3 -s"

HTH.  Regards,
-- 
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: `python3 setup.py build` step segfaults while building in mock for rawhide

[Ankur Sinha]

On Thu, Sep 24, 2020 13:41:36 -0600, Jerry James wrote:
> On Thu, Sep 24, 2020 at 1:08 PM Ankur Sinha  wrote:
> > I'm building a new python package. It's a pretty straightforward one,
> > and it builds fine in mock for F33, but not for rawhide. On rawhide, the
> > %py3_build step segfaults:
> 
> The crash is actually inside the neuron package.  

AHA! Thanks! Could you list the steps you took to debug this please? I
didn't know quite where to start. XD

Also, any reason why this happens on rawhide but not F33?

> GDB says:
> 
> #0  hoc_new_object (symtemp=0x0, v=0x565234f0)
> at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnoc/../oc/hoc_oop.c:471
> #1  0x7fffdf8925fd in nrnpy_pyobject_in_obj (
> po=<_FuncPtr(__name__='scatter_concentrations') at remote 0x7fffdeeea1c0>)
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_p2h.cpp:191
> #2  0x7fffdf88e921 in pyobject_in_objptr (
> po=<_FuncPtr(__name__='scatter_concentrations') at remote 0x7fffdeeea1c0>,
> op=)
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:320
> #3  hocobj_pushargs (Python Exception  value has
> been optimized out:
> s2free=,
> args=(1, <_FuncPtr(__name__='scatter_concentrations') at remote
> 0x7fffdeeea1c0>))
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:420
> #4  fcall (vself=vself@entry=0x7fffdef5ec60, vargs=vargs@entry=0x7fffdef56440)
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:673
> #5  0x7fffdf67cb02 in OcJumpImpl::fpycall (this=0x564d4cd0, f=
> 0x7fffdf88e5c0 , a=0x7fffdef5ec60, b=0x7fffdef56440)
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrniv/../ivoc/ocjump.cpp:218
> #6  0x7fffdf888f9d in hocobj_call (self=self@entry=0x7fffdef5ec60,
> args=args@entry=(1, <_FuncPtr(__name__='scatter_concentrations')
> at remote 0x7fffdeeea1c0>), kwrds=kwrds@entry=0x0)
> at 
> /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:774
> #7  0x77d8055f in _PyObject_MakeTpCall (tstate=0xda50,
> callable=, args=0x7fffdefb4b68,
> nargs=2, keywords=0x0)
> at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Objects/call.c:191
> #8  0x77d7d245 in _PyObject_VectorcallTstate (kwnames=0x0,
> nargsf=, args=0x7fffdefb4b68, callable=,
> tstate=)
> at 
> /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:116
> #9  _PyObject_VectorcallTstate (kwnames=0x0, nargsf=,
> args=0x7fffdefb4b68, callable=, tstate=)
> at 
> /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:103
> #10 PyObject_Vectorcall (kwnames=0x0, nargsf=,
> args=0x7fffdefb4b68, callable=)
> at 
> /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:127
> #11 call_function (kwnames=0x0, oparg=,
> pp_stack=, tstate=0xda50)
> at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:5044
> #12 _PyEval_EvalFrameDefault (tstate=, f=,
> throwflag=)
> at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:3459
> #13 0x77d76ac1 in _PyEval_EvalFrame (throwflag=0,
> f=Frame 0x7fffdefb49f0, for file
> /usr/lib64/python3.9/site-packages/neuron/rxd/rxd.py, line 61, in
>  (), tstate=0xda50)
> at 
> /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/internal/pycore_ceval.h:40
> #14 _PyEval_EvalCode (tstate=, _co=,
> globals=, locals=, args=,
> argcount=, kwnames=0x0, kwargs=0x0,
> kwcount=, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0,
> closure=0x0, name=0x0, qualname=0x0)
> at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:4299
> ...
> 
> followed by about 500 more stack frames.  The NULL systemp pointer is
> the immediate cause of the crash.
> -- 
> 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

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: `python3 setup.py build` step segfaults while building in mock for rawhide

[Jerry James]

On Thu, Sep 24, 2020 at 1:08 PM Ankur Sinha  wrote:
> I'm building a new python package. It's a pretty straightforward one,
> and it builds fine in mock for F33, but not for rawhide. On rawhide, the
> %py3_build step segfaults:

The crash is actually inside the neuron package.  GDB says:

#0  hoc_new_object (symtemp=0x0, v=0x565234f0)
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnoc/../oc/hoc_oop.c:471
#1  0x7fffdf8925fd in nrnpy_pyobject_in_obj (
po=<_FuncPtr(__name__='scatter_concentrations') at remote 0x7fffdeeea1c0>)
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_p2h.cpp:191
#2  0x7fffdf88e921 in pyobject_in_objptr (
po=<_FuncPtr(__name__='scatter_concentrations') at remote 0x7fffdeeea1c0>,
op=)
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:320
#3  hocobj_pushargs (Python Exception  value has
been optimized out:
s2free=,
args=(1, <_FuncPtr(__name__='scatter_concentrations') at remote
0x7fffdeeea1c0>))
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:420
#4  fcall (vself=vself@entry=0x7fffdef5ec60, vargs=vargs@entry=0x7fffdef56440)
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:673
#5  0x7fffdf67cb02 in OcJumpImpl::fpycall (this=0x564d4cd0, f=
0x7fffdf88e5c0 , a=0x7fffdef5ec60, b=0x7fffdef56440)
at 
/usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrniv/../ivoc/ocjump.cpp:218
#6  0x7fffdf888f9d in hocobj_call (self=self@entry=0x7fffdef5ec60,
args=args@entry=(1, <_FuncPtr(__name__='scatter_concentrations')
at remote 0x7fffdeeea1c0>), kwrds=kwrds@entry=0x0)
at /usr/src/debug/neuron-7.8.1-2.fc34.x86_64/src/nrnpython/nrnpy_hoc.cpp:774
#7  0x77d8055f in _PyObject_MakeTpCall (tstate=0xda50,
callable=, args=0x7fffdefb4b68,
nargs=2, keywords=0x0)
at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Objects/call.c:191
#8  0x77d7d245 in _PyObject_VectorcallTstate (kwnames=0x0,
nargsf=, args=0x7fffdefb4b68, callable=,
tstate=)
at 
/usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:116
#9  _PyObject_VectorcallTstate (kwnames=0x0, nargsf=,
args=0x7fffdefb4b68, callable=, tstate=)
at 
/usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:103
#10 PyObject_Vectorcall (kwnames=0x0, nargsf=,
args=0x7fffdefb4b68, callable=)
at 
/usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/cpython/abstract.h:127
#11 call_function (kwnames=0x0, oparg=,
pp_stack=, tstate=0xda50)
at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:5044
#12 _PyEval_EvalFrameDefault (tstate=, f=,
throwflag=)
at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:3459
#13 0x77d76ac1 in _PyEval_EvalFrame (throwflag=0,
f=Frame 0x7fffdefb49f0, for file
/usr/lib64/python3.9/site-packages/neuron/rxd/rxd.py, line 61, in
 (), tstate=0xda50)
at 
/usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Include/internal/pycore_ceval.h:40
#14 _PyEval_EvalCode (tstate=, _co=,
globals=, locals=, args=,
argcount=, kwnames=0x0, kwargs=0x0,
kwcount=, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0,
closure=0x0, name=0x0, qualname=0x0)
at /usr/src/debug/python3.9-3.9.0~rc2-1.fc34.x86_64/Python/ceval.c:4299
...

followed by about 500 more stack frames.  The NULL systemp pointer is
the immediate cause of the crash.
-- 
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Dominique Martinet]

Ben Cotton wrote on Thu, Sep 24, 2020:
> ** If the 3.3% size increase is a concern I can implement a different
> optimization ([https://whova.com/embedded/session/llvm_202010/1193947/
> talk (2)]) as a GCC post-processing phase which would require no
> changes in any DWARF consumers.

That talk doesn't load for me, sorry if I ask something answered in
there.


How does this relate to debuginfo compression such as passing
-Wl,--compress-debug-sections=zlib ?

I haven't tested on very relevant programs but on a single C file
(tested with vmtouch, compiled with f32's `gcc -g vmtouch.c` and
`gcc -g vmtouch.c -Wl,--compress-debug-sections=zlib`) I see a fairly
significant reduction in size:
after strip --only-keep-debug it goes down from 32K to 23K, that's 28%
down.

On a slighly bigger project (wlroots), with
LDFLAGS=-Wl,--compress-debug-sections=zlib meson builddir
and the same strip; I'm going from 1512 to 732k that's over 50%
reduction.


As far as I can see, gdb and lldb both support it just fine; and the
linux kernel builds with it if CONFIG_DEBUG_INFO_COMPRESSED is set so it
looks widespread enough.


If not related would it be worth using? Is support somehow still lacking?


Thanks,
-- 
Dominique
___
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

`python3 setup.py build` step segfaults while building in mock for rawhide

[Ankur Sinha]

Hello,

I'm building a new python package. It's a pretty straightforward one,
and it builds fine in mock for F33, but not for rawhide. On rawhide, the
%py3_build step segfaults:

/var/tmp/rpm-tmp.gZ2yVU: line 34: 2984190 Segmentation fault  (core dumped) 
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}" 
/usr/bin/python3 setup.py build --executable="/usr/bin/python3 -s"

The script referenced in the error (attached) looks fine. Would someone
have a clue about debugging this?

The spec is here[1]. The build log from the crashing build is also
attached.

[1] https://pagure.io/neuro-sig/python-netpyne/blob/master/f/python-netpyne.spec

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
#!/bin/sh

  RPM_SOURCE_DIR="/builddir/build/SOURCES"
  RPM_BUILD_DIR="/builddir/build/BUILD"
  RPM_OPT_FLAGS="-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection"
  RPM_LD_FLAGS="-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld "
  RPM_ARCH="x86_64"
  RPM_OS="linux"
  RPM_BUILD_NCPUS="8"
  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS
  RPM_DOC_DIR="/usr/share/doc"
  export RPM_DOC_DIR
  RPM_PACKAGE_NAME="python-netpyne"
  RPM_PACKAGE_VERSION="0.9.7"
  RPM_PACKAGE_RELEASE="1.fc34"
  export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
  LANG=C
  export LANG
  unset CDPATH DISPLAY ||:
  RPM_BUILD_ROOT="/builddir/build/BUILDROOT/python-netpyne-0.9.7-1.fc34.x86_64"
  export RPM_BUILD_ROOT
  
  PKG_CONFIG_PATH="${PKG_CONFIG_PATH}:/usr/lib64/pkgconfig:/usr/share/pkgconfig"
  export PKG_CONFIG_PATH
  CONFIG_SITE=${CONFIG_SITE:-NONE}
  export CONFIG_SITE
  
  set -x
  umask 022
  cd "/builddir/build/BUILD"
cd 'netpyne-0.9.7'
\
  CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\
  /usr/bin/python3 setup.py  build --executable="/usr/bin/python3 -s" 






  RPM_EC=$?
  for pid in $(jobs -p); do kill -9 ${pid} || continue; done
  exit ${RPM_EC}
Mock Version: 2.6
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs 
--target x86_64 --nodeps /builddir/build/SPECS/python-netpyne.spec'], 
chrootPath='/var/lib/mock/fedora-rawhide-x86_64/root'env={'TERM': 'vt100', 
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'C.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=[]unshare_net=TrueprintOutput=True)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target 
x86_64 --nodeps /builddir/build/SPECS/python-netpyne.spec'] with env {'TERM': 
'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'C.UTF-8'} and shell False
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1600905600
Wrote: /builddir/build/SRPMS/python-netpyne-0.9.7-1.fc34.src.rpm
Child return code was: 0
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb 
--target x86_64 --nodeps /builddir/build/SPECS/python-netpyne.spec'], 
chrootPath='/var/lib/mock/fedora-rawhide-x86_64/root'env={'TERM': 'vt100', 
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'C.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=[]unshare_net=TrueprintOutput=True)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target 
x86_64 --nodeps /builddir/build/SPECS/python-netpyne.spec'] with env {'TERM': 
'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'C.UTF-8'} and shell False
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1600905600
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.AQ2HfU
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf netpyne-0.9.7
+ /usr/bin/gzip -dc /builddir/build/SOURCES/netpyne-0.9.7.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd netpyne-0.9.7
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ rm -rf netpyne.egg-info
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.gZ2yVU
+ umask 022
+ cd /builddir/build/BUILD
+ cd netpyne-0.9.7
+ CFLAGS='-O2 

Re: Fedora 33 Beta is GO

[Greg Hellings]

On what date is that, again?

--Greg

On Thu, Sep 24, 2020 at 1:35 PM Ben Cotton  wrote:

> The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on
> Tuesday, 17 March 2020.
>
> For more information please check the Go/No-Go meeting minutes [2] or log
> [3].
>
> Thank you to everyone who has and still is working on this release!
> Subsequent schedule milestones[4] are unchanged. The Final Freeze
> begins on 6 October.
>
> [1] https://dl.fedoraproject.org/pub/alt/stage/33_Beta-1.3/
> [2]
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.html
> [3]
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.log.html
> [4] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-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-annou...@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 Beta is GO

[Dan Book]

On Thu, Sep 24, 2020 at 2:34 PM Ben Cotton  wrote:

> On Thu, Sep 24, 2020 at 2:31 PM Ben Cotton  wrote:
> >
> > The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on
> > Tuesday, 17 March 2020.
> >
> This, of course, should read Tuesday, 29 September 2020.
>

It really has been a long March hasn't it...

-Dan
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Thu, 24 Sep 2020 20:04:22 +0200, Stephen John Smoogen wrote:
> The original language of the proposal said no other distribution used DWZ,
> and that the format was not adopted and should be removed.

I have already updated the Wiki in the meantime based on new information from
this list:

https://fedoraproject.org/wiki/Changes/DebugInfoStandardization#Detailed_Description
--
Only some of Linux distributions use existing Fedora DWZ (known are
Fedora/CentOS/RHEL, SuSE OSes, OpenMandriva, maybe others?).
[...]
Debian and Ubuntu use neither -fdebug-types-section nor DWZ.
--


> The tool is not easily maintained,

I did not mention it there but it is true there are some longterm unfixed
bugs in DWZ so that it gives up on optimization of many builds:
error: Allocatable section after non-allocatable ones
  https://sourceware.org/bugzilla/show_bug.cgi?id=24251#c10
error: Couldn't find DIE referenced by DW_AT_abstract_origin
(maybe DWZ error or maybe compiler error: Unknown DWARF DW_OP_255)


Thanks,
Jan
___
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 Beta is GO

[Ben Cotton]

On Thu, Sep 24, 2020 at 2:31 PM Ben Cotton  wrote:
>
> The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on
> Tuesday, 17 March 2020.
>
This, of course, should read Tuesday, 29 September 2020.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[Test-Announce] Fedora 33 Beta is GO

[Ben Cotton]

The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on
Tuesday, 17 March 2020.

For more information please check the Go/No-Go meeting minutes [2] or log [3].

Thank you to everyone who has and still is working on this release!
Subsequent schedule milestones[4] are unchanged. The Final Freeze
begins on 6 October.

[1] https://dl.fedoraproject.org/pub/alt/stage/33_Beta-1.3/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.log.html
[4] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/test-annou...@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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Thu, 24 Sep 2020 20:10:45 +0200, Neal Gompa wrote:
> I do not feel that this is a valid premise either, since the reason
> for no dwz support in LLDB is because nobody contributed it.
> I'm slightly surprised that Red Hat's debuginfo engineers hadn't already
> contributed support for it into LLDB.

I have implemented the support for DWZ into LLDB, it is just off-trunk now:
https://people.redhat.com/jkratoch/dwz-2020-05-31/

https://copr.fedorainfracloud.org/coprs/jankratochvil/lldb/package/lldb-experimental/
dnf copr enable jankratochvil/lldb;dnf install 
lldb-experimental;lldb-experimental

The problem is that the support is complicated as it has to affect the whole
LLDB DWARF codebase (handling of each DIE type). That is the line based on my
patchset, it is exactly calculated:

https://fedoraproject.org/wiki/Changes/DebugInfoStandardization#Detailed_Description
DWZ disadvantage: DWZ requires 8x times more complicated (LoC count) 
support in consumers than -fdebug-types-section.

And all this support is needed despite almost nobody from LLDB/LLVM users
(Android, iOS, OSX, still AFAIK Ubuntu/Debian) uses DWZ.

So when DWZ brings almost no size benefits compared to much easier to support,
faster to compile and already better supported by existing consumers (*) why
not to switch to -fdebug-types-section?

(*) such as LLDB and LLVM binutils but DWZ strings are not decoded even for
example with binutils readelf


> I wonder if the reason for that was the mistaken impression that dwz wasn't
> broadly used.

From LLDB point of view users of DWZ-built Linux distros are counted in
millions, users of Android/iOS/OSX are counted in billions. :-)


Thanks for reply,
Jan
___
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: compat-openssl11 vs openssl1.1

[Yaakov Selkowitz]

On Wed, 2020-09-16 at 12:41 -0500, Michael Catanzaro wrote:
> On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce  wrote:
> > note that one of the dependencies is gnome-vfs2, itself a dependency
> > for libgnome, which is a dependency for another dozen packages.
> > 
> > All of them will likely go away because gnome-vfs2 is unlikely to be
> > changed.
> 
> I looked over the dependency tree here. The only significant apps we 
> would lose are Tomboy (obsoleted by Gnote), Banshee (unmaintained for a 
> long time with no attention to security bugs), and an old compatibility 
> version of Glade that can go away. Looks like some mono packages. I 
> would retire all of these.

IIRC glade2 and glade3 can be built --without-gnome to avoid those
deps.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat,
Inc.
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 24, 2020 at 2:04 PM Stephen John Smoogen  wrote:
>
>
>
> On Thu, 24 Sep 2020 at 13:44, Jan Kratochvil  
> wrote:
>>
>> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
>> > Then that certainly means that Ubuntu uses this too, since they reuse
>> > the dbgsym subpackage generation for the ddeb system they have now.
>>
>> I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
>> there:
>> https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
>> llvm-dwarfdump -color=0 
>> bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep 
>> DW_TAG_partial_unit
>>
>> This debuginfo package has been built 2020-09-15.
>>
>> (Besides that this proposal is not based on whether Debian uses DWZ or not.)
>
>
> The original language of the proposal said no other distribution used DWZ, 
> and that the format was not adopted and should be removed. So it comes across 
> that it is based on whether Debian, Ubuntu, etc use it.
>
> ```
> As the format did
> not get widespread and the tool is not much maintained it became
> burden to make existing debugging tools compatible with Fedora debug
> info.
> 
> Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> SuSE OSes) and so its support is missing in tools like
> [https://lldb.llvm.org/ LLDB],
> [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> or binutils readelf. -fdebug-types-section is used internally by
> Google (produced by clang). Debian does not store any debug info
> archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
>
> ```
>

For the record, the reason why it was hard to broaden adoption is that
the patch wasn't upstreamed into rpm itself until RPM 4.14's release:
https://rpm.org/wiki/Releases/4.14.0.html

That was only three years ago, and in the span of that time, it's gone
from only Fedora using it to almost everyone using it now.

> Just stick to the following:
>
> The tool is not easily maintained, and has become a burden to make existing 
> debugging tools, namely llvm, compatible with this method.
>
> Also expect that cross-distribution support is going to be important. No 
> distribution is an island entire of itself; and few 'customers' use just one 
> distribution. If a lot of distributions have been using this because Fedora 
> had been and it was easier to work out things.. then work is going to be 
> needed to get them to work together..
>

I do not feel that this is a valid premise either, since the reason
for no dwz support in LLDB is because nobody contributed it. I'm
slightly surprised that Red Hat's debuginfo engineers hadn't already
contributed support for it into LLDB. I wonder if the reason for that
was the mistaken impression that dwz wasn't broadly used.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Stephen John Smoogen]

On Thu, 24 Sep 2020 at 13:44, Jan Kratochvil 
wrote:

> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> > Then that certainly means that Ubuntu uses this too, since they reuse
> > the dbgsym subpackage generation for the ddeb system they have now.
>
> I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
> there:
> https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
> llvm-dwarfdump -color=0
> bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep
> DW_TAG_partial_unit
>
> This debuginfo package has been built 2020-09-15.
>
> (Besides that this proposal is not based on whether Debian uses DWZ or
> not.)
>

The original language of the proposal said no other distribution used DWZ,
and that the format was not adopted and should be removed. So it comes
across that it is based on whether Debian, Ubuntu, etc use it.

```
As the format did
not get widespread and the tool is not much maintained it became
burden to make existing debugging tools compatible with Fedora debug
info.

Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
SuSE OSes) and so its support is missing in tools like
[https://lldb.llvm.org/ LLDB],
[[llvm-dwarfdumphttps://
llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
or binutils readelf. -fdebug-types-section is used internally by
Google (produced by clang). Debian does not store any debug info
archives. Ubuntu uses neither -fdebug-types-section nor DWZ.

```

Just stick to the following:

The tool is not easily maintained, and has become a burden to make existing
debugging tools, namely llvm, compatible with this method.

Also expect that cross-distribution support is going to be important. No
distribution is an island entire of itself; and few 'customers' use just
one distribution. If a lot of distributions have been using this because
Fedora had been and it was easier to work out things.. then work is going
to be needed to get them to work together..

-- 
Stephen J Smoogen.
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> Then that certainly means that Ubuntu uses this too, since they reuse
> the dbgsym subpackage generation for the ddeb system they have now.

I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
there:
https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
llvm-dwarfdump -color=0 
bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep 
DW_TAG_partial_unit

This debuginfo package has been built 2020-09-15.

(Besides that this proposal is not based on whether Debian uses DWZ or not.)


Thanks,
Jan
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 24, 2020 at 1:13 PM Peter Pentchev  wrote:
>
> On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote:
> > On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> > >
> > > == Summary ==
> > > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> > > not get widespread and the tool is not much maintained it became
> > > burden to make existing debugging tools compatible with Fedora debug
> > > info.
> > >
> > > == Owner ==
> > > * Name: [[User:jankratochvil| Jan Kratochvil ]]
> > > * Email: jan.kratoch...@redhat.com
> > >
> > >
> > > == Detailed Description ==
> > >
> > > Debug info files *.debug contained in *-debuginfo.rpm are very big in
> > > general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
> > > while all its other files are only 75GB). There exist several methods
> > > how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> > > started using DWZ tool (from [[Features/DwarfCompressor]]) while
> > > [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> > > Google implemented] the same goal in a different way called
> > > -fdebug-types-section.
> > >
> > > Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> > > SuSE OSes) and so its support is missing in tools like
> > > [https://lldb.llvm.org/ LLDB],
> > > [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> > > or binutils readelf. -fdebug-types-section is used internally by
> > > Google (produced by clang). Debian does not store any debug info
> > > archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
> > >
> >
> > This is not true. Debian started producing -dbgsym packages and
> > putting them in a separate repository years ago:
> > https://wiki.debian.org/AutomaticDebugPackages
> >
> > dwz is used by virtually all RPM based distributions now, including
> > OpenMandriva (a clang-based distro). I know this because I implemented
> > it. :)
> >
> > I do not know whether Debian has started using dwz by default because
> > I haven't dug into how the -dbgsym package generation works in detail.
>
> Most of the packages that use recent versions of debhelper (the tool
> that automates many steps of the Debian packaging) have run dwz for
> the past couple of years. I do not have any statistics though.
>

Then that certainly means that Ubuntu uses this too, since they reuse
the dbgsym subpackage generation for the ddeb system they have now.

So it sounds like the underlying premise of this whole Change is
flawed, since everyone has been using dwz without telling the
dwz developers. :)




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Thu, 24 Sep 2020 19:01:17 +0200, Neal Gompa wrote:
> This is not true. Debian started producing -dbgsym packages and
> putting them in a separate repository years ago:
> https://wiki.debian.org/AutomaticDebugPackages
> 
> dwz is used by virtually all RPM based distributions now, including
> OpenMandriva (a clang-based distro). I know this because I implemented
> it. :)

Updated the Wiki, thanks.
https://fedoraproject.org/wiki/Changes/DebugInfoStandardization


> I do not know whether Debian has started using dwz by default because
> I haven't dug into how the -dbgsym package generation works in detail.

I do not see DWZ or -fdebug-types-section to be used for example in
bash-dbgsym_5.1~beta1-1_amd64.deb .


Jan
___
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: protobuf (3.13) update is coming to rawhide

[Adrian Reber]

On Mon, Sep 21, 2020 at 02:26:00PM +0200, Adrian Reber wrote:
> On Fri, Sep 18, 2020 at 08:23:40AM +0200, Adrian Reber wrote:
> > I will do a protobuf update in rawhide which comes, as always, with a
> > new SO version.
> > 
> > Before starting the builds in rawhide I will try it out first in COPR
> > and once that is done I will do the builds in rawhide in a side tag.
> > 
> > repoquery gives me a list of 53 dependent packages I have to rebuild.
> 
> Most of the dependent packages did rebuilt without a problem. The
> following 6 packages, however, did not rebuild successfully:
> 
> fawkes:
>   /builddir/build/BUILD/fawkes-1.3.0/src/libs/protobuf_comm/peer.cpp: In 
> member function 'void 
> protobuf_comm::ProtobufBroadcastPeer::handle_resolve(const 
> boost::system::error_code&, 
> boost::asio::ip::basic_resolver::iterator)':
>   /builddir/build/BUILD/fawkes-1.3.0/src/libs/protobuf_comm/peer.cpp:416:92: 
> error: '_1' was not declared in this scope
> 
> cockatrice:
>   
> /builddir/build/BUILD/Cockatrice-2020-03-20-Release-2.7.4/cockatrice/src/replay_timeline_widget.cpp:
>  In member function 'virtual void 
> ReplayTimelineWidget::paintEvent(QPaintEvent*)':
>   
> /builddir/build/BUILD/Cockatrice-2020-03-20-Release-2.7.4/cockatrice/src/replay_timeline_widget.cpp:53:18:
>  error: aggregate 'QPainterPath path' has incomplete type and cannot be 
> defined
> 
> mir:
>   In file included from 
> ../src/platforms/eglstream-kms/server/buffer_allocator.h:24,
>  from ../src/platforms/eglstream-kms/server/platform.cpp:22:
>   ../include/platform/mir/graphics/egl_extensions.h:105:9: error: 
> 'PFNEGLBINDWAYLANDDISPLAYWL' does not name a type
> 105 | PFNEGLBINDWAYLANDDISPLAYWL const eglBindWaylandDisplayWL;
> | ^~
>   ../include/platform/mir/graphics/egl_extensions.h:106:9: error: 
> 'PFNEGLQUERYWAYLANDBUFFERWL' does not name a type
> 106 | PFNEGLQUERYWAYLANDBUFFERWL const eglQueryWaylandBufferWL;
> | ^~
> 
> tflogger:
>   + /usr/bin/make -O -j2 V=1 VERBOSE=1
>   make: *** No targets specified and no makefile found.  Stop.
> 
> community-mysql:
>   Check of testcase failed for: x.resource_groups
> 
>   Completed: Failed 2/3880 tests, 99.95% were successful.
> 
>   Failing test(s): x.resource_groups
> 
> mapserver:
>   + /usr/bin/make -O -j2 V=1 VERBOSE=1
>   make: *** No targets specified and no makefile found.  Stop.
> 
> 
> All logs can be found at: 
> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-13/builds/
> 
> I will start the rebuilds in the next days in a rawhide side tag.

All rebuilds have finished in the side tag 'f34-build-side-30655'.

The number of failures is down to 4:

 * fawkes
 * knot
 * mapserver
 * mir

I will create the bodhi update tomorrow to get the side tag merged.

Adrian
___
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Peter Pentchev]

On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote:
> On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> >
> > == Summary ==
> > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> > not get widespread and the tool is not much maintained it became
> > burden to make existing debugging tools compatible with Fedora debug
> > info.
> >
> > == Owner ==
> > * Name: [[User:jankratochvil| Jan Kratochvil ]]
> > * Email: jan.kratoch...@redhat.com
> >
> >
> > == Detailed Description ==
> >
> > Debug info files *.debug contained in *-debuginfo.rpm are very big in
> > general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
> > while all its other files are only 75GB). There exist several methods
> > how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> > started using DWZ tool (from [[Features/DwarfCompressor]]) while
> > [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> > Google implemented] the same goal in a different way called
> > -fdebug-types-section.
> >
> > Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> > SuSE OSes) and so its support is missing in tools like
> > [https://lldb.llvm.org/ LLDB],
> > [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> > or binutils readelf. -fdebug-types-section is used internally by
> > Google (produced by clang). Debian does not store any debug info
> > archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
> >
> 
> This is not true. Debian started producing -dbgsym packages and
> putting them in a separate repository years ago:
> https://wiki.debian.org/AutomaticDebugPackages
> 
> dwz is used by virtually all RPM based distributions now, including
> OpenMandriva (a clang-based distro). I know this because I implemented
> it. :)
> 
> I do not know whether Debian has started using dwz by default because
> I haven't dug into how the -dbgsym package generation works in detail.

Most of the packages that use recent versions of debhelper (the tool
that automates many steps of the Debian packaging) have run dwz for
the past couple of years. I do not have any statistics though.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
>
> == Summary ==
> Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> not get widespread and the tool is not much maintained it became
> burden to make existing debugging tools compatible with Fedora debug
> info.
>
> == Owner ==
> * Name: [[User:jankratochvil| Jan Kratochvil ]]
> * Email: jan.kratoch...@redhat.com
>
>
> == Detailed Description ==
>
> Debug info files *.debug contained in *-debuginfo.rpm are very big in
> general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
> while all its other files are only 75GB). There exist several methods
> how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> started using DWZ tool (from [[Features/DwarfCompressor]]) while
> [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> Google implemented] the same goal in a different way called
> -fdebug-types-section.
>
> Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> SuSE OSes) and so its support is missing in tools like
> [https://lldb.llvm.org/ LLDB],
> [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> or binutils readelf. -fdebug-types-section is used internally by
> Google (produced by clang). Debian does not store any debug info
> archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
>

This is not true. Debian started producing -dbgsym packages and
putting them in a separate repository years ago:
https://wiki.debian.org/AutomaticDebugPackages

dwz is used by virtually all RPM based distributions now, including
OpenMandriva (a clang-based distro). I know this because I implemented
it. :)

I do not know whether Debian has started using dwz by default because
I haven't dug into how the -dbgsym package generation works in detail.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Non-responsive maintainer: fedpop

[Ian McInerney]

In your original email you said that this resolves CVE bug [1], which says
in it:

"NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time.  If you need to fix the versions independent of each other,
you may clone this bug as appropriate."

That to me sounds like the CVE should be patched in F31 as well - so since
this update fixes it, the update would be suitable for F31.

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

-Ian

On Thu, Sep 24, 2020 at 5:01 PM Carl George  wrote:

> F32 is fine by me.  Based on the updates policy [0], I don't believe
> this update qualifies under the "major bug fixes and security fixes"
> restriction for the previous stable release.
>
> [0]
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates
>
> On Wed, Sep 23, 2020 at 2:54 PM Richard Shaw  wrote:
> >
> > On Wed, Sep 23, 2020 at 2:42 PM Carl George  wrote:
> >>
> >> Yes, the patch is from an upstream pull request [0] that has already
> >> been merged to the master branch [1] and is planned to be included in
> >> their next release [2] (it's not part of the current 1.3.2 tag).  The
> >> pull request includes a comment linking to said pull request, per the
> >> packaging guidelines [3].  Mumble's traditional push-to-talk
> >> functionality doesn't work under Wayland; this patch adds dbus calls
> >> that can be mapped to keyboard shortcuts as a workaround.  I've built
> >> it like this in COPR [4] and it's worked great for me so far.
> >
> >
> > So next, question... Do builds need to be performed all the way back to
> f31, or is f32 okay?
> >
> > 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
>
>
>
> --
> Carl George
> ___
> 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: Non-responsive maintainer: fedpop

[Carl George]

F32 is fine by me.  Based on the updates policy [0], I don't believe
this update qualifies under the "major bug fixes and security fixes"
restriction for the previous stable release.

[0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates

On Wed, Sep 23, 2020 at 2:54 PM Richard Shaw  wrote:
>
> On Wed, Sep 23, 2020 at 2:42 PM Carl George  wrote:
>>
>> Yes, the patch is from an upstream pull request [0] that has already
>> been merged to the master branch [1] and is planned to be included in
>> their next release [2] (it's not part of the current 1.3.2 tag).  The
>> pull request includes a comment linking to said pull request, per the
>> packaging guidelines [3].  Mumble's traditional push-to-talk
>> functionality doesn't work under Wayland; this patch adds dbus calls
>> that can be mapped to keyboard shortcuts as a workaround.  I've built
>> it like this in COPR [4] and it's worked great for me so far.
>
>
> So next, question... Do builds need to be performed all the way back to f31, 
> or is f32 okay?
>
> 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



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

F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DebugInfoStandardization

== Summary ==
Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
not get widespread and the tool is not much maintained it became
burden to make existing debugging tools compatible with Fedora debug
info.

== Owner ==
* Name: [[User:jankratochvil| Jan Kratochvil ]]
* Email: jan.kratoch...@redhat.com


== Detailed Description ==

Debug info files *.debug contained in *-debuginfo.rpm are very big in
general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
while all its other files are only 75GB). There exist several methods
how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
started using DWZ tool (from [[Features/DwarfCompressor]]) while
[https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
Google implemented] the same goal in a different way called
-fdebug-types-section.

Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
SuSE OSes) and so its support is missing in tools like
[https://lldb.llvm.org/ LLDB],
[[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
or binutils readelf. -fdebug-types-section is used internally by
Google (produced by clang). Debian does not store any debug info
archives. Ubuntu uses neither -fdebug-types-section nor DWZ.

* DWZ advantage: On the whole Fedora distro it saves 3.3% (5GB of the
157GB distribution size)
** If the 3.3% size increase is a concern I can implement a different
optimization ([https://whova.com/embedded/session/llvm_202010/1193947/
talk (2)]) as a GCC post-processing phase which would require no
changes in any DWARF consumers.
* DWZ disadvantage: DWZ has currently less support across consumers
(LLDB, llvm-dwarfdump, binutils readelf)
* DWZ disadvantage: DWZ requires 8x times more complicated (LoC count)
support in consumers than -fdebug-types-section.
* DWZ disadvantage: DWZ cannot update LLVM .debug_names index which
can be generated only by clang (it cannot be regenerated later for
DWZ-compressed file)
* DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has
been blocking DWARF-5 for Fedora for 3.5 years and only after I have
now proposed to drop DWZ Mark Wielaard has started porting DWZ to
DWARF-5. It can be expected next DWARF extensions will remain
unsupported again. Even currently there is no plan to support DWARF-5
features used by clang which may need -fdebug-types-section for
clang-built binaries or no size optimization of clang-built debug info
at all.
* DWZ disadvantage: Compilation (linking) requires for C++ up to 2x as
big disk space (as DWZ is processing files after linker and DWZ is
incompatible with -fdebug-types-section)
* DWZ disadvantage: Compilation (linking) is slower

This proposed DWARF format was originally submitted already for Fedora
18 as [[Features/DebugTypesSections]].

== Benefit to Fedora ==
* Better compatibility with existing debugging and tracing tools,
primarily [https://lldb.llvm.org/ LLDB].
* Less resource-intensive rebuilds of C++ packages (in disk space,
memory requirements and compilation time).

== Scope ==
* Proposal owners: It affects all packages generating *-debuginfo.rpm,
that is compiled (not scripted) languages.
* Other developers: Report any possible debuginfo incompatibility (unexpected).
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: All the needed changes should be done in
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
package] can be then retired.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: The size differences are only for
*-debuginfo.rpm which is outside of scope of the listed objectives.


== Upgrade/compatibility impact ==
As *-debuginfo.rpm have to exactly match NVRA of its binary package
the compatibility is not relevant. Existing tools supporting DWZ will
still support the DWZ file format in packages which have not been
rebuilt.

== How To Test ==
The change will update
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config] by
[https://people.redhat.com/jkratoch/redhat-rpm-config-fdebug-types-section.patch
an -fdebug-types-section patch].

Then one can use rpmbuild to rebuild a package. For mock use
-a|--addrepo with modified redhat-rpm-config.rpm (with increased
NVRA). For packages already rebuilt in Koji nothing is needed.

Test programs like lldb and gdb if they still can print source code,
function parameters, variables etc.

One should also verify integrated testsuites of tools like clang,
lldb, gcc, binutils, gdb, elfutils or rpm are not regressing with the
-fdebug-types-section option.

One can also compare *.debug files built with/without DWZ and/or
-fdebug-types-section using
[https://src.fedoraproject.org/rpms/libabigail libabigail] utility
dwdiff but that will 

F34 Change proposal: Move deprecated bluetooth utilities to subpackage (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/BluetoothDeprecated

== Summary ==
Move deprecated bluez bluetooth utilities to a sub package to indicate
their status.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]

== Detailed Description ==

There's a number of utilities in the upstream bluez bluetooth package
that have long been deprecated with their functionality replaced by
the core bluetoothctl utility. They're no longer receiving updates and
at some point may be removed. Move these utilities to a dedicated sub
package to indicate their upstream support status.

== Benefit to Fedora ==

Users are aware of the status of the various bluez utilities and why
they may not support newer bluetooth functionality.

== Scope ==
* Proposal owners:
** Create a sub package for deprecated bluetooth utilities, that is
installed on upgrade, but not installed by default on new installs.

* Other developers:
** No impact

* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
The new sub package will be installed on upgrade if bluez is
installed, the deprecated utilities sub package will not be installed
by default on a new install but will be available in the package
repository.

== How To Test ==

Check the new package is installed on upgrade, check the new package
isn't installed for new installs

== User Experience ==

Users shouldn't notice any difference, these utilities aren't used by
standard bluetooth integration into desktops such as
mice/keyboards/audio. They are command line utilities and bluetoothctl
has superseded them and generally supports more functionality and
newer reversions of the bluetooth spec.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: N/A it's a straight fowrard packaging change.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No.
* Blocks product? No.

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
N/A


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: mock: rawhide: No such file or directory: '/var/lib/mock/fedora-rawhide-x86_64/root/etc/resolv.conf'

[Jun Aruga]

Thanks for the response!
After upgrading the mock to the latest version on Fedora 32, the issue
disappeared.

```
$ rpm -q mock
mock-2.3-1.fc32.noarch

$ sudo dnf upgrade mock

$ rpm -q mock
mock-2.6-1.fc32.noarch
```

-- 
Jun | He - His - Him
___
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

Fedora-Rawhide-20200924.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 9/181 (x86_64)

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

ID: 676470  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/676470
ID: 676493  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/676493
ID: 676529  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/676529
ID: 676554  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/676554
ID: 676588  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/676588
ID: 676590  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/676590
ID: 676597  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/676597
ID: 676600  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/676600
ID: 676601  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/676601

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

New soft failures (same test not soft failed in Fedora-Rawhide-20200923.n.0):

ID: 676456  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/676456

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

ID: 676410  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/676410
ID: 676429  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/676429
ID: 676469  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/676469
ID: 676489  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/676489
ID: 676492  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/676492
ID: 676506  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/676506
ID: 676519  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/676519
ID: 676540  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/676540

Passed openQA tests: 163/181 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200923.n.0):

ID: 676434  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/676434
ID: 676603  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/676603

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.10 to 0.31
Previous test data: https://openqa.fedoraproject.org/tests/674882#downloads
Current test data: https://openqa.fedoraproject.org/tests/676408#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.10 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/674892#downloads
Current test data: https://openqa.fedoraproject.org/tests/676418#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.27 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/674924#downloads
Current test data: https://openqa.fedoraproject.org/tests/676450#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 5 MiB to 4 MiB
1 packages(s) removed since previous compose: perl-macros
System load changed from 1.03 to 0.87
Previous test data: https://openqa.fedoraproject.org/tests/674927#downloads
Current test data: https://openqa.fedoraproject.org/tests/676453#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
1 packages(s) removed since previous compose: perl-macros
System load changed from 1.23 to 0.97
Average CPU usage changed from 32.60952381 to 10.40952381
Previous test data: https://openqa.fedoraproject.org/tests/674929#downloads
Current test data: https://openqa.fedoraproject.org/tests/676455#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 packages(s) removed since previous compose: perl-macros
System load changed from 0.97 to 1.21
Previous test data: https://openqa.fedoraproject.org/tests/674947#downloads
Current test data: https://openqa.fedoraproject.org/tests/676473#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load chang

Re: Easy Review Swaps For New Packages That Block Rust Stack Updates

[Jared K. Smith]

On Thu, Sep 24, 2020 at 5:59 AM Fabio Valentini 
wrote:

> I've been working through open bugs in the Rust stack for the past
> week, trying to contribute a few package updates. Some are, however,
> blocked by new dependencies that aren't packaged yet.
>
> These new packages are *very simple* and 99% automatically generated,
> so the reviews should be easy. Below is a numbered list of packages
> that are for review, which package updates they block, and how they
> depend on each other.
>

I've reviewed the bottom three or four, and will continue to work my way up
from the bottom as time permits today.


> I'll gladly review *simple* packages in return :)
>

I don't have any to exchange right now, but thanks for offering.

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

Fedora rawhide compose report: 20200924.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200923.n.0
NEW: Fedora-Rawhide-20200924.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  3
Dropped packages:0
Upgraded packages:   80
Downgraded packages: 0

Size of added packages:  6.80 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.73 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   149.02 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20200923.n.0-sda.raw.xz
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20200923.n.0-sda.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20200923.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: octave-flexiblas-3.0.0-1.fc34
Summary: FlexiBLAS API Interface for Octave
RPMs:octave-flexiblas
Size:316.26 KiB

Package: python-bokeh-2.2.1-3.fc34
Summary: Interactive plots and applications in the browser from Python
RPMs:python3-bokeh
Size:6.24 MiB

Package: rubygem-image_processing-1.11.0-1.fc34
Summary: High-level wrapper for processing images for the web with ImageMagick 
or libvips
RPMs:rubygem-image_processing rubygem-image_processing-doc
Size:257.25 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  AusweisApp2-1.20.2-3.fc34
Old package:  AusweisApp2-1.20.2-1.fc34
Summary:  Online identification with German ID card (Personalausweis)
RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
Size: 22.90 MiB
Size change:  -2.29 KiB
Changelog:
  * Wed Sep 23 2020 Bj??rn Esser  - 1.20.2-2
  - Use application specific OpenSSL config through a shell wrapper

  * Wed Sep 23 2020 Bj??rn Esser  - 1.20.2-3
  - Do not enable SHA384 ciphers in custom OpenSSL configuration


Package:  R-future-1.19.1-1.fc34
Old package:  R-future-1.18.0-2.fc33
Summary:  Unified Parallel and Distributed Processing in R for Everyone
RPMs: R-future
Size: 694.97 KiB
Size change:  24.45 KiB
Changelog:
  * Wed Sep 23 2020 Elliott Sales de Andrade  - 
1.19.1-1
  - Update to latest version (#1881627)


Package:  R-knitr-1.30-1.fc34
Old package:  R-knitr-1.29-1.fc34
Summary:  A General-Purpose Package for Dynamic Report Generation in R
RPMs: R-knitr
Size: 1.23 MiB
Size change:  9.25 KiB
Changelog:
  * Wed Sep 23 2020 Elliott Sales de Andrade  - 
1.30-1
  - Update to latest version (#1881633)


Package:  R-tinytex-0.26-1.fc34
Old package:  R-tinytex-0.25-2.fc33
Summary:  Helper Functions to Install and Maintain TeX Live, and Compile 
LaTeX Documents
RPMs: R-tinytex
Size: 127.42 KiB
Size change:  3.51 KiB
Changelog:
  * Wed Sep 23 2020 Elliott Sales de Andrade  - 
0.26-1
  - Update to latest version (#1881355)


Package:  R-withr-2.3.0-1.fc34~bootstrap
Old package:  R-withr-2.2.0-3.fc33
Summary:  Run Code 'With' Temporarily Modified Global State
RPMs: R-withr
Size: 219.33 KiB
Size change:  -5.01 KiB
Changelog:
  * Wed Sep 23 2020 Elliott Sales de Andrade  - 
2.3.0-1
  - Update to latest version (#1881624)


Package:  TeXmacs-1.99.13-5.fc34
Old package:  TeXmacs-1.99.12-2.fc32
Summary:  Structured WYSIWYG scientific text editor
RPMs: TeXmacs TeXmacs-devel texmacs-fedora-fonts
Size: 252.55 MiB
Size change:  -57.26 MiB
Changelog:
  * Fri Jul 17 2020 Jindrich Novy  - 1.99.13-1
  - update to 1.99.13

  * Mon Jul 27 2020 Fedora Release Engineering  - 
1.99.13-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Sat Aug 01 2020 Fedora Release Engineering  - 
1.99.13-3
  - Second attempt - Rebuilt for
https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Wed Sep 23 2020 Orion Poplawski  - 1.99.13-4
  - Use new cmake macros (FTBFS bz#1863124)

  * Wed Sep 23 2020 Orion Poplawski  - 1.99.13-5
  - Add patch for Qt 5.15 support


Package:  ara-1.5.1-2.fc34
Old package:  ara-1.4.3-1.fc33
Summary:  Records Ansible playbooks and makes them easier to understand and 
troubleshoot
RPMs: ara ara-doc python3-ara python3-ara-server python3-ara-tests
Size: 6.07 MiB
Size change:  93.48 KiB
Changelog:
  * Wed Sep 23 2020 David Moreau Simard  - 1.5.1-1
  - Update to latest upstream release
  - Add requirement on python3-cliff (new CLI client)

  * Wed Sep 23 2020 David Moreau Simard  - 1.5.1-2
  - Add missing requirement on pbr


Package:  argbash-2.10.0-1.fc34
Old package:  argbash-2.9.0-2.fc33
Summary:  Bash argument parsing code generator
RPMs: argbash
Size: 57.67 KiB
Size change:  645 B
Changelog:
  * Wed Sep 23 2020 Stephen Gallagher  - 2.10.0-1
  - Update to 2.10.0
  - Bugfixes
* argbash-init is able to handle empty string as the only argument without
  being puzzled.
* Error handling of script working

Fedora-Cloud-31-20200924.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 7/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: [External] Re: Lenovo P1G2 and P53 web sales updates

[Mark Pearson]

On 2020-09-24 6:10 a.m., Alexander Bokovoy wrote:

On to, 24 syys 2020, Mark Pearson wrote:

Hi Fedora community,






Do let me know any questions. Once again I apologise to all those who 
helped us on the way - the next round will go smoother.


Thank you for the update. Any news when the global availability of the
Linux login portal would actually happen? So far, the Linux portal is
only on US website...



Still working on that one too - no update yet. I'll definitely post here 
once I get an update.


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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

[Fabio Valentini]

On Thu, Sep 24, 2020 at 11:51 AM Luca BRUNO  wrote:
>
> On Mon, 14 Sep 2020 10:10:30 -0400
> Ben Cotton  wrote:
>
> > Following the general upwards trend in the Rust language's popularity,
> > more and more applications and services in fedora are written in Rust.
> > This includes some CoreOS services, PARSEC, some nice command line
> > tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of
> > the GNOME stack.

Hi Luca,
Thanks for your detailed feedback, I've responded to your questions below.

> As an upstream developer for most of those CoreOS projects, I wonder
> whether this proposal is going to make it even more complex to
> package applications on release branches, due to the network effect of
> dependencies.

I hope that this won't be the case, and I'll also invest time to
prevent this outcome, if at all possible.

> > ** ongoing effort: help package maintainers with merging changes from
> > rawhide (where appropriate) and creating compat packages (when
> > necessary) - this is made easier by the strong SemVer compatibility
> > guarantees of Rust crates
>
> In particular, it sounds like Fedora will try to:
>  * package most of crates.io libraries, now *one more time per each
>branch*

No. This is definitely out of scope.
I don't see a reason to package things that nothing in fedora depends
on, for example.
crates.io ships 47,039 crates today, but only a fraction of those are
actually packaged and / or required for fedora (today, 1225).

>  * align all applications to use the same dependency versions
>(possibly across release branches?)

This is also out of scope, because I don't think it would be possible.
The proposal text should make it pretty clear that release branches
should mostly follow rawhide in terms of source-only package updates,
and - if necessary - compat package creations. Binary packages already
follow the Update Policy, so nothing changes for those.

Essentially, all I want to change is that package dependencies won't
be broken as freely by pushing semver-incompatible version updates in
rawhide, at least not without creating the necessary compat packages
for older versions. My hope is that this will actually make it
*easier* to package Rust applications on both rawhide *and* on release
branches.

> Taking one of those projects as an example, Afterburn has (more or less)
> monthly releases[0], a bot keeping dependencies fresh[1], and ~200
> crates in its full set of transitive dependencies[2] (only a subset of which
> relevant for Fedora).
>
> [0] https://github.com/coreos/afterburn/releases
> [1] 
> https://github.com/coreos/afterburn/issues?q=label%3Adependencies+is%3Aclosed
> [2] https://github.com/coreos/afterburn/blob/master/Cargo.lock
>
> Now, these dependencies when packaged have to live with additional
> constraints from other applications, which may still be on older
> non-semver-compatible versions.
> Effectively this means that Fedora downgrades[4] those dependencies
> until all other packaged applications converge on a shared version
> (which is not guaranteed to happen, depending on relative velocity of
> different upstream projects).

I hope that dependency downgrades will happen less often, not more
often. I don't see a need for all dependent packages to converge on a
shared version, either, since I don't share the disdain for compat
packages some others do :D - so long as they're used in moderation,
and removed when no longer needed.

> [4] 
> https://src.fedoraproject.org/rpms/rust-afterburn/blob/master/f/afterburn-fix-metadata.diff
>
> The resulting composition has
>  1) never been tested by upstream CI.
>  2) may have re-introduced bugs patched by newer library versions
> (and seen as fixed by upstream CI).

I agree, this is not a good situation, and one that I hope this
proposal and the resulting changes will remedy, instead of making it
worse.

> I'm admittedly not a knowledgeable packager so I don't have a good
> alternative proposal to offer, but I wonder whether there is space for a
> different path where Fedora:
>  * doesn't have to re-package all of crates.io (especially not for each
>branch).

There's no need to re-package things for each branch. Most changes can
be "git merge"d.
This is how package updates are handled in fedora, Rust has only been
a weird special case in this regard ...

>  * doesn't try to align all applications on a single
>(major+minor) version of a library crate.

As explained above, this isn't the intention of this proposal.

>  * tries to stay closer to upstream-specified dependencies, handling
>those crates relative to the specific application.

I hope that this is actually the outcome of the proposed change.

>  * only package library crates whose logic needs to be functionally
>patched (affecting multiple applications), and selectively override
>only those in manifest/lockfile patches.

This is actually what I'm aiming for. If there are no *code changes*
necessary when updating a depe

Re: Lenovo P1G2 and P53 web sales updates

[Alexander Bokovoy]

On to, 24 syys 2020, Mark Pearson wrote:

Hi Fedora community,

Just wanted to drop a note to the community as I'm sure you're 
wondering where the P1G2 and P53 are with the web sales. It's been a 
frustrating experience and we've been working past issue after issue 
for weeks but it looks like we hit the wall today.


One of the major issues we've been fighting with the web sales is the 
lack of inventory. Covid (whilst also adding delays to the whole 
project) hit our supply chains and whilst I don't understand all the 
details the summary is we don't have enough components left to put 
these systems up on the web. You may have noticed the Windows systems 
have been pulled - this is not Linux specific.


We have looked at instead of doing full configuration as planned if we 
could put up a few fixed configurations instead and at least get 
something up for the short term but it seems that even that is not 
possible with the stock we have.


I know John Trapasso (who joined me at Nest) is still looking into 
other options. We believe we can make it so systems can be ordered by 
calling the phone support line - there they line are able to identify 
exactly which components are available and build the system with the 
Linux option. But it's not the same as having them up online and 
generally available as we'd planned for and wanted which is massively 
disappointing.


My sincere and complete apologies to the community. From my point of 
view it sucks as so much work and effort went into getting these 
platforms ready. Whilst I've learnt a lot about Lenovo process for the 
future platforms the key lesson (which with hindsight should have been 
obvious) is that trying to release something new towards the end of 
its lifecycle is a bad idea.I just wish someone had told me that 
back in February (there are so many things I wish I knew about in 
February but that's another story).


We have prioritized getting the P1G3 and the P15 (successor to the 
P53) done with Fedora - those are entering test very shortly and 
fingers, legs and eyes are crossed for a smooth passage. I've been 
using the P1G3 with Fedora33 preview and it's looking good. I can't 
give a date yet but we're moving as fast as we can on them.


I've seen some really positive reviews for the Fedora experience on 
the X1 Carbon 8 - I'm so glad that is up successfully and seems to be 
doing well. We are working on getting that out to the worldwide sites.


Do let me know any questions. Once again I apologise to all those who 
helped us on the way - the next round will go smoother.


Thank you for the update. Any news when the global availability of the
Linux login portal would actually happen? So far, the Linux portal is
only on US website...


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

Lenovo P1G2 and P53 web sales updates

[Mark Pearson]

Hi Fedora community,

Just wanted to drop a note to the community as I'm sure you're wondering 
where the P1G2 and P53 are with the web sales. It's been a frustrating 
experience and we've been working past issue after issue for weeks but 
it looks like we hit the wall today.


One of the major issues we've been fighting with the web sales is the 
lack of inventory. Covid (whilst also adding delays to the whole 
project) hit our supply chains and whilst I don't understand all the 
details the summary is we don't have enough components left to put these 
systems up on the web. You may have noticed the Windows systems have 
been pulled - this is not Linux specific.


We have looked at instead of doing full configuration as planned if we 
could put up a few fixed configurations instead and at least get 
something up for the short term but it seems that even that is not 
possible with the stock we have.


I know John Trapasso (who joined me at Nest) is still looking into other 
options. We believe we can make it so systems can be ordered by calling 
the phone support line - there they line are able to identify exactly 
which components are available and build the system with the Linux 
option. But it's not the same as having them up online and generally 
available as we'd planned for and wanted which is massively disappointing.


My sincere and complete apologies to the community. From my point of 
view it sucks as so much work and effort went into getting these 
platforms ready. Whilst I've learnt a lot about Lenovo process for the 
future platforms the key lesson (which with hindsight should have been 
obvious) is that trying to release something new towards the end of its 
lifecycle is a bad idea.I just wish someone had told me that back in 
February (there are so many things I wish I knew about in February but 
that's another story).


We have prioritized getting the P1G3 and the P15 (successor to the P53) 
done with Fedora - those are entering test very shortly and fingers, 
legs and eyes are crossed for a smooth passage. I've been using the P1G3 
with Fedora33 preview and it's looking good. I can't give a date yet but 
we're moving as fast as we can on them.


I've seen some really positive reviews for the Fedora experience on the 
X1 Carbon 8 - I'm so glad that is up successfully and seems to be doing 
well. We are working on getting that out to the worldwide sites.


Do let me know any questions. Once again I apologise to all those who 
helped us on the way - the next round will go smoother.


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

Easy Review Swaps For New Packages That Block Rust Stack Updates

[Fabio Valentini]

Hi everybody,

I've been working through open bugs in the Rust stack for the past
week, trying to contribute a few package updates. Some are, however,
blocked by new dependencies that aren't packaged yet.

These new packages are *very simple* and 99% automatically generated,
so the reviews should be easy. Below is a numbered list of packages
that are for review, which package updates they block, and how they
depend on each other.

1. rust-peg-runtime: https://bugzilla.redhat.com/show_bug.cgi?id=1879207
blocks 2. and rust-peg 0.6.3 update
2. rust-peg-macros: https://bugzilla.redhat.com/show_bug.cgi?id=1879209
blocks rust-peg 0.6.3 update
blocks rust-varlink_parser 4.0.4 update

3. rust-quick-xml: https://bugzilla.redhat.com/show_bug.cgi?id=1879692
blocks rust-feed-rs 0.4.0 update

4. rust-pure-rust-locales: https://bugzilla.redhat.com/show_bug.cgi?id=1879716
blocks rust-chrono 0.4.15 update

5. rust-const_fn: https://bugzilla.redhat.com/show_bug.cgi?id=1879888
blocks rust-time 0.2.21 update

6. rust-rusttype: https://bugzilla.redhat.com/show_bug.cgi?id=1880718
blocks 13
7. rust-palette_derive: https://bugzilla.redhat.com/show_bug.cgi?id=1880719
blocks 8
8. rust-palette: https://bugzilla.redhat.com/show_bug.cgi?id=1880720
blocks 13
9. rust-pathfinder_simd: https://bugzilla.redhat.com/show_bug.cgi?id=1880722
blocks 10, 12
10. rust-pathfinder_geometry:
https://bugzilla.redhat.com/show_bug.cgi?id=1880724
blocks 12
11. rust-freetype: https://bugzilla.redhat.com/show_bug.cgi?id=1880727
blocks 12
12. rust-font-kit: https://bugzilla.redhat.com/show_bug.cgi?id=1880728
blocks 13
13. rust-plotters: https://bugzilla.redhat.com/show_bug.cgi?id=1880729
blocks rust-criterion 0.3.3 update

14. rust-httpdate: https://bugzilla.redhat.com/show_bug.cgi?id=1880800
blocks rust-hyper 0.13.8 update

15. rust-cedarwood: https://bugzilla.redhat.com/show_bug.cgi?id=1880840
blocks 16
16. rust-jieba-rs: https://bugzilla.redhat.com/show_bug.cgi?id=1880841
blocks rust-elasticlunr-rs 2.3.9 update

17. rust-buf-min: https://bugzilla.redhat.com/show_bug.cgi?id=1881231
blocks rust-v_escape 0.12.1 update

18. rust-binfarce: https://bugzilla.redhat.com/show_bug.cgi?id=1881978
blocks rust-cargo-bloat 0.10.0 update

19. rust-spinning_top: https://bugzilla.redhat.com/show_bug.cgi?id=1881987
blocks rust-flume 0.9.0 update

I'll gladly review *simple* packages in return :)

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

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

[Luca BRUNO]

On Mon, 14 Sep 2020 10:10:30 -0400
Ben Cotton  wrote:

> Following the general upwards trend in the Rust language's popularity,
> more and more applications and services in fedora are written in Rust.
> This includes some CoreOS services, PARSEC, some nice command line
> tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of
> the GNOME stack.

As an upstream developer for most of those CoreOS projects, I wonder
whether this proposal is going to make it even more complex to
package applications on release branches, due to the network effect of
dependencies.

> ** ongoing effort: help package maintainers with merging changes from
> rawhide (where appropriate) and creating compat packages (when
> necessary) - this is made easier by the strong SemVer compatibility
> guarantees of Rust crates

In particular, it sounds like Fedora will try to:
 * package most of crates.io libraries, now *one more time per each
   branch*
 * align all applications to use the same dependency versions
   (possibly across release branches?)

Taking one of those projects as an example, Afterburn has (more or less)
monthly releases[0], a bot keeping dependencies fresh[1], and ~200
crates in its full set of transitive dependencies[2] (only a subset of which
relevant for Fedora).

[0] https://github.com/coreos/afterburn/releases
[1] 
https://github.com/coreos/afterburn/issues?q=label%3Adependencies+is%3Aclosed
[2] https://github.com/coreos/afterburn/blob/master/Cargo.lock

Now, these dependencies when packaged have to live with additional
constraints from other applications, which may still be on older
non-semver-compatible versions.
Effectively this means that Fedora downgrades[4] those dependencies
until all other packaged applications converge on a shared version
(which is not guaranteed to happen, depending on relative velocity of
different upstream projects).

[4] 
https://src.fedoraproject.org/rpms/rust-afterburn/blob/master/f/afterburn-fix-metadata.diff

The resulting composition has
 1) never been tested by upstream CI.
 2) may have re-introduced bugs patched by newer library versions
(and seen as fixed by upstream CI). 

I'm admittedly not a knowledgeable packager so I don't have a good
alternative proposal to offer, but I wonder whether there is space for a
different path where Fedora:
 * doesn't have to re-package all of crates.io (especially not for each
   branch).
 * doesn't try to align all applications on a single
   (major+minor) version of a library crate.
 * tries to stay closer to upstream-specified dependencies, handling
   those crates relative to the specific application.
 * only package library crates whose logic needs to be functionally
   patched (affecting multiple applications), and selectively override
   only those in manifest/lockfile patches.
 * takes a more relaxed approach on having multiple (major+minor)
   crate versions co-existing, as long as required by applications.

To be explicit: I'm aware of the cons of vendoring and I'm not asking
for that, but for exploring a model with an "application first" approach
and possibly less toiling on packaging efforts.

Ciao, Luca
___
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

Fedora-Cloud-32-20200924.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20200923.0):

ID: 676407  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/676407

Passed openQA tests: 6/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Building libjfxwebkit.so for openjfx

[Vitaly Zaitsev via devel]

On 24.09.2020 10:37, Nicolas De Amicis wrote:
> When I compile with cmake on my fedora 32, the .so has a size of 88 Mb
> but when I run with fedpkg --release f33 local the .so has a size of 2.2
> Gb! I don't understand why is so big and how to fix it!

88 Mb - stripped binary.
2.2 GB - non-stripped binary (incl. debug information).

This is absolutely normal. Rpmbuild will automatically strip all
binaries to -debuginfo subpackage on the final stage.

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

Building libjfxwebkit.so for openjfx

[Nicolas De Amicis]

Hello, I'm trying to build libjfxwebkit.so for openjfx 
(https://src.fedoraproject.org/rpms/openjfx). 
When I compile with cmake on my fedora 32, the .so has a size of 88 Mb but when 
I run with fedpkg --release f33 local the .so has a size of 2.2 Gb! I don't 
understand why is so big and how to fix it!
Here a snippet of %build section:
%build
#set openjdk11 for build
export JAVA_HOME=%{_jvmdir}/java-11-openjdk
export CFLAGS="${RPM_OPT_FLAGS}"
export CXXFLAGS="${RPM_OPT_FLAGS}" 
%mvn_build --skip-javadoc
%{cmake} -DPORT="Java" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
-DCMAKE_BUILD_TYPE=Release -DSHOW_BINDINGS_GENERATION_PROGRESS=1 
-DENABLE_EXPERIMENTAL_FEATURES=ON ./modules/javafx.web/src/main/native
%{cmake_build}
Thanks for help
Regards
Nicolas De Amicis
___
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: Need assistance for opensubdiv

[Luya Tshimbalanga]

Which some helps on a chat, it turned out an upstream bug in 
FindOpenCL.cmake which prompts to disable OpenCL support for the time being.



On 2020-09-23 5:57 p.m., Luya Tshimbalanga wrote:


Hello team,

As part to adhering the Fedora cmake guideline, opensubdiv oddly 
failed to build without a proper details. As I am unfamiliar with 
cmake debugging, here is the tail result:


- Found TBB: /usr/include (found suitable version "2020.3", minimum required is 
"4.0")
-- Found OpenGL: /usr/lib64/libOpenGL.so
CMake Error at cmake/FindOpenCL.cmake:189 (list):
   list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
   CMakeLists.txt:328 (find_package)


CMake Error at cmake/FindOpenCL.cmake:189 (list):
   list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
   CMakeLists.txt:328 (find_package)


CMake Error at cmake/FindOpenCL.cmake:189 (list):
   list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
   CMakeLists.txt:328 (find_package)


CMake Error at cmake/FindOpenCL.cmake:188 (list):
   list GET given empty list
Call Stack (most recent call first):
   CMakeLists.txt:328 (find_package)


CMake Error at cmake/FindOpenCL.cmake:189 (list):
   list GET given empty list
Call Stack (most recent call first):
   CMakeLists.txt:328 (find_package)


-- Found OpenCL: /usr/lib64/libOpenCL.so (found suitable version "12.", minimum required 
is "1.1")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found GLFW: /usr/include (found suitable version "3.3.2", minimum required is 
"3.0.0")
-- Found Doxygen: /usr/bin/doxygen (found suitable version "1.8.20", minimum required is 
"1.8.4") found components: doxygen dot
-- Found Docutils: /usr/bin/rst2html (found suitable version "0.16", minimum required is 
"0.9")
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.9", minimum required 
is "3")
-- Configuring incomplete, errors occurred!
See also 
"/builddir/build/BUILD/OpenSubdiv-3_4_3/x86_64-redhat-linux-gnu/CMakeFiles/CMakeOutput.log".
See also 
"/builddir/build/BUILD/OpenSubdiv-3_4_3/x86_64-redhat-linux-gnu/CMakeFiles/CMakeError.log".
error: Bad exit status from /var/tmp/rpm-tmp.m9Rf0v (%build)


RPM build errors:
 Bad exit status from /var/tmp/rpm-tmp.m9Rf0v (%build)


You can view the full details on 
https://download.copr.fedorainfracloud.org/results/luya/OpenSubdiv/fedora-33-x86_64/01682937-opensubdiv/


Opensubdiv is needed for Blender 2.90 series.

Thanks in advance.

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


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