Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Sérgio Basto]

On Wed, 2022-05-04 at 17:01 +0200, Ondrej Nosek wrote:
> Hi all,
> 
> A few months ago fedpkg introduced a change which avoids downloading
> source files (from dist-git) that are not used in the specfile and
> therefore downloading them would be wasting of resources and time.
> The original request was opened here [1] and implemented here [2].
> The logic is part of the command "fedpkg sources" and currently can't
> be disabled manually. The logic parses specfile, but doesn't do a
> deep analysis, so it is doesn't always right.
> 
> Recently we got a request for opt-in implementation of this. It means
> you should actively use some argument (ie. --skip-unused) to avoid
> downloading unused sources. The requestor points out that it broke
> the original functionality and it is not possible to add any extra
> arguments into the complicated release process (RHEL kernel).

where is this request ? I can't find it 

Thank you 

> 
> On the other hand, opt-out (--download-unused) has (I think) a
> significantly higher impact on saving resources (time and network
> capacity). Of course, it doesn't have to be implemented as an extra
> argument, there might be a different (maybe not so clean) solution
> for such projects.
> 
> What do you think about it?
> 
> I added into a loop (bcc) names who already were involved in this in
> a past (on the Fedora devel mailing list)
> 
> Thanks, Ondrej
> 
> [1] https://pagure.io/rpkg/issue/559
> [2] https://pagure.io/rpkg/pull-request/564
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Linux Standard Base (LSB)

[Sérgio Basto]

Hi,

we have a proposal to drop redhat-lsb , shouldn't we try to keep it ? 

redhat-lsb still in version 4 when LSB 5.0 was released June 3, 2015.

https://bugzilla.redhat.com/show_bug.cgi?id=2076968
https://src.fedoraproject.org/rpms/redhat-lsb


Best regards,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Contributor Tee Shirt Giveaway

[Sérgio Basto]

On Fri, 2022-04-22 at 13:04 +0530, Vipul Siddharth wrote:
> On Fri, Apr 22, 2022 at 12:49 PM Leigh Scott
>  wrote:
> > 
> > Why post something that has expired?
> Hi leigh, When I shared the email, the giveaway was still active :)
> given it was just for 24 hours, It had to expire after some time
> (This
> is mentioned in the blog)
> I definitely could have highlighted in the email as well!
> Hope it was useful to some

I managed to order mine yesterday 😀️

> > ___
> > 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
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> -- 
> Vipul Siddharth
> He/His/Him
> Fedora | CentOS CI Infrastructure Team
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc + llvm + annobin mess in f36-updates-testing

[Sérgio Basto]

On Sat, 2022-04-09 at 12:48 +0200, Fabio Valentini wrote:
> Hi all,
> 
> Looks like there's a little bit of a mess around LLVM 14 / GCC /
> annobin updates brewing in f36-updates-testing.
> 
> Right now, there's *two* updates in "testing" state that contain
> builds of annobin:
> 
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-c43760a865
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-3dd2ddf4ab

annobin-10.59-2.fc36 is about to go to stable , but we are in freeze
time

annobin-10.62-1.fc36 is in testing , this is the normal behavior 


> The first one was a rebuild of annobin for LLVM 14. The second one
> was
> an update to new versions of annobin and GCC. The second one has a
> newer version of annobin, but it hasn't been built against LLVM 14,
> because that's still in "testing".
> 
> The second one was also en route to be pushed to stable first. I have
> revoked this request, because if the LLVM 14 update would've been
> pushed to stable later than the GCC update, the older build of
> annobin
> would've superseded the one built against newer GCC, resulting in the
> wrong annobin build (older and not rebuilt against newer GCC) being
> pushed to stable in the end
> 
> Can somebody sort this out please? Right now, the LLVM 14 update
> *could* be pushed to stable as-is (I think), but the GCC+annobin
> update needs at least its annobin build removed, then rebuild the
> annobin against the pending LLVM 14 update, and then have that new
> new
> annobin build added ...
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Move existing build into side tag?

[Sérgio Basto]

On Tue, 2022-04-05 at 22:34 -0500, Richard Shaw wrote:
> On Tue, Apr 5, 2022 at 10:04 PM Neal Gompa 
> wrote:
> > On Tue, Apr 5, 2022 at 11:01 PM Richard Shaw 
> > wrote:
> > >
> > > Google has failed me, how do I go about moving an existing build
> > into a side tag I just created?
> > >
> > 
> > koji tag-build  
> > 
> 
> 
> Thanks, there's so many options in koji I wasn't sure which was the
> right one.


I use `koji move-build`

for example 
koji move-build epel8-testing-candidate epel8-build-side-52356
ImageMagick-6.9.12.44-1.el8 


> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

Hi, 

ImageMagick 6.9.12.x have a bunch security fixes since 6.9.10.x .
I'd like update ImageMagick (IM) on epel8 with soname bump .
ImageMagick-6.9.10 last version, have almost 2 years and keep it and
just pull security patches, it would have a lot more work in my
opinion.

so in  epel8-build-side-52356 repo (sidetag) we got now 
ImageMagick-6.9.12.44-1.el8 

I will rebuild these 24 packages [1] calculated
with find_unblocked_orphans.py from
https://pagure.io/releng/blob/main/f/scripts [2] 


Best regards, 


[1] 
Depending packages (epel8) (24): conky-manager converseen darktable
digikam dvdauthor ettercap gnokii keepass latex2rtf lyx mediainfo
openbabel perl-GD-SecurityImage perl-PAR-Packer playonlinux
purple-discord putty stb stellarium tango-icon-theme w3m
xemacs-packages-extra xfig xforms 

[2]
./find_unblocked_orphans.py --release epel8 --skip-orphans --max_deps 0
ImageMagick

conky-manager (maintained by: orphan)
conky-manager-2.3.4-11.el8.x86_64 requires ImageMagick = 6.9.10.86-
1.el8

converseen (maintained by: marionline)
converseen-0.9.8.1-1.el8.src requires ImageMagick-c++-devel =
6.9.10.86-1.el8, ImageMagick-devel = 6.9.10.86-1.el8
converseen-0.9.8.1-1.el8.x86_64 requires libMagick++-
6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)

darktable (maintained by: asn, germano, kalev, madko)
darktable-tools-noise-3.8.0-5.el8.x86_64 requires ImageMagick =
6.9.10.86-1.el8

digikam (maintained by: dvratil, kde-sig, kwizart, nucleo, rdieter,
than, tuxbrewr, vjancik)
digikam-6.4.0-4.el8.src requires ImageMagick-c++-devel = 6.9.10.86-
1.el8, ImageMagick-devel = 6.9.10.86-1.el8
digikam-6.4.0-4.el8.x86_64 requires libMagick++-6.Q16.so.8()(64bit),
libMagickCore-6.Q16.so.6()(64bit)
digikam-libs-6.4.0-4.el8.x86_64 requires libMagick++-
6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)

dvdauthor (maintained by: hobbes1069, sergiomb)
dvdauthor-0.7.2-14.el8.src requires ImageMagick-devel = 6.9.10.86-1.el8
dvdauthor-0.7.2-14.el8.x86_64 requires libMagickCore-
6.Q16.so.6()(64bit)

ettercap (maintained by: limb)
ettercap-0.8.3.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8

gnokii (maintained by: limb, robert, snirkel)
gnokii-0.6.31-29.el8.src requires ImageMagick = 6.9.10.86-1.el8

keepass (maintained by: mavit, tpokorra)
keepass-2.45-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

latex2rtf (maintained by: cicku, yselkowitz)
latex2rtf-2.3.18-4.el8.src requires ImageMagick = 6.9.10.86-1.el8
latex2rtf-2.3.18-4.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

lyx (maintained by: jamatos, rdieter)
lyx-2.3.6-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

mediainfo (maintained by: ivanromanov, vascom)
mediainfo-21.09-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

openbabel (maintained by: alexpl, jussilehtola, rathann, sagitter,
scitech_sig)
openbabel-3.1.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8

perl-GD-SecurityImage (maintained by: eseyman)
perl-GD-SecurityImage-1.75-4.el8.noarch requires perl(Image::Magick)
perl-GD-SecurityImage-1.75-4.el8.src requires perl(Image::Magick)

perl-PAR-Packer (maintained by: jplesnik, ppisar)
perl-PAR-Packer-1.052-2.el8.src requires ImageMagick = 6.9.10.86-1.el8

playonlinux (maintained by: robert)
playonlinux-4.4-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

purple-discord (maintained by: xvitaly)
purple-discord-0-33.20210928gitb7ac723.el8.src requires ImageMagick =
6.9.10.86-1.el8

putty (maintained by: jskarvad, olysonek, zaniyah)
putty-0.76-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

stb (maintained by: churchyard, music)
stb-0-0.7.20211022gitaf1a5bc.el8.src requires /usr/bin/convert

stellarium (maintained by: limb, s4504kr)
stellarium-0.20.1-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

tango-icon-theme (maintained by: cottsay, mavit)
tango-icon-theme-0.8.90-24.el8.src requires ImageMagick-devel =
6.9.10.86-1.el8

w3m (maintained by: pnemade, robert)
w3m-img-0.5.3-50.git20210102.el8.x86_64 requires ImageMagick =
6.9.10.86-1.el8

xemacs-packages-extra (maintained by: jjames, stevetraylen)
xemacs-packages-extra-20191207-1.el8.src requires ImageMagick =
6.9.10.86-1.el8

xfig (maintained by: jwrdegoede, stevetraylen)
xfig-3.2.7b-3.el8.src requires ImageMagick = 6.9.10.86-1.el8

xforms (maintained by: rdieter, robert)
xforms-1.2.4-14.el8.src requires ImageMagick = 6.9.10.86-1.el8

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Troubleshooting building Swift on Fedora, take 2; assembly language is not my friend

[Sérgio Basto]

On Mon, 2022-03-28 at 16:43 -0500, Ron Olson wrote:
> Hey all-
> I’m unable to build Swift on Fedora 36 and Rawhide while it does
> build on F35. I’ve been able to condense the entire issue down to the
> following sample code that demonstrates the problem:
> nothing.S:
> #define ASM_TYPE_FUNCTION(symbol) .type symbol, %function
> #define ASM_SIZE(symbol) .size symbol, .-symbol
> #define ASM_SYMBOL(symbol) symbol
> #define ASM_WRAPPER_NAME(symbol) _interceptor##symbol
> .comm _ZN14__interception10real_vforkE,8,8
> .globl ASM_WRAPPER_NAME(vfork)
> ASM_TYPE_FUNCTION(ASM_WRAPPER_NAME(vfork))
> ASM_WRAPPER_NAME(vfork):
> // Commenting out the line below makes it work
> call *_ZN14__interception10real_vforkE(%rip)
> ASM_SIZE(vfork)
> And compiling this code with:
> clang++ -fPIC -shared ./nothing.S
> Results in the error:
> /usr/bin/ld: /tmp/fun-1b3a0d.o: warning: relocation against
> _ZN14__interception10real_vforkE' in read-only section .text'
> /usr/bin/ld: /tmp/fun-1b3a0d.o: relocation R_X86_64_PC32 against
> symbol `_ZN14__interception10real_vforkE' can not be used when making
> a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: bad value


https://bugzilla.redhat.com/show_bug.cgi?id=1304277#c3

"relocation R_X86_64_PC32 against undefined symbol" happens when
LDFLAGS are set with hardening and CFLAGS not .

maybe is an effect
of https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck have
you tried %undefine _auto_set_build_flags ?
 

> The issue is that I’m explicitly passing -fPIC but it seems to either
> be ignored or overridden somehow. I’m not well versed on assembly to
> make any kind of educated guess about what might be the
> problem/solution so I’m hoping someone more familiar might be able to
> shed some light on the issue.
> Thanks!
> Ron
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nodejs-electron

[Sérgio Basto]

On Sun, 2022-03-27 at 14:52 -0400, Neal Gompa wrote:
> On Sun, Mar 27, 2022 at 2:42 PM Sérgio Basto  wrote:
> > 
> > On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote:
> > > On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel
> > > wrote:
> > > > On 27/02/2022 08:23, Andreas Schneider wrote:
> > > > 
> > > > > You don't have to. You can point electron builder to your
> > > > > system
> > > > > electron
> > > > > and
> > >  it will use that. Then you just do not package the electron files.
> > > > > All you need is the resources directory.
> > > > 
> > > > 
> > > > You must run electron-builder on Fedora Koji. Pre-built packages
> > > > are
> > > > not
> > > > allowed.
> > > 
> > > You should not package electron at all with your package! You
> > > should
> > > use the
> > > nodejs-electron in the distribution and just point it to the
> > > sources to
> > > load:
> > > 
> > > cat <%{buildroot}%{_bindir}/signal-desktop
> > > #!/bin/sh
> > > export NODE_ENV=production
> > > 
> > > exec %{_bindir}/electron %{_libdir}/%{name}/resources/app.asar
> > > "\$@"
> > > EOF
> > > chmod +x %{buildroot}%{_bindir}/signal-desktop
> > 
> > I started build electron on copr [1]
> > 
> > I built ffmpeg , nodejs-electron, element-web and element-desktop 
> > for
> > Fedora 34 and 35 successfully element-web fails on F36+
> > 
> > I rebuilt ffmpeg-free from Fedora to F35 and F34
> > after I used
> > https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
> > https://build.opensuse.org/package/show/devel:languages:javascript/element-web
> > https://build.opensuse.org/package/show/home:sergiomb/element-desktop
> > 
> > 
> > build on electron took 11 hours on x64 and 15 hours in aarch , is
> > almost a build o chromium , which make me wonder if we can't use a
> > chromium as a library
> > https://www.electronjs.org/blog/electron-internals-building-chromium-as-a-library
> > 
> 
> libchromiumcontent hasn't been a thing in a *very* long time. It was
> merged into Electron in Electron 4.0 (which was years ago!) and it's
> all built as one runtime environment binary.
> 
> But, one thing that could be done to simplify things would be to ship
> a chromium-src-devel package in the chromium package that electron
> could pull in. That would tightly couple the chromium and electron
> packages, but it would mean that improvements we make to the chromium
> package would be easily consumed by electron...
> 

yes, I think that should be the path and and I'd love see that done ,
also for other projects like nwjs (node-webkit) 
https://github.com/nwjs/nw.js , doesn't make sense to me build chromium
all the times , mainly because chromium takes hours and hours to build
and consumes a lot and a lot of resources.  

> I'm not sure we *want* to do that, but I have seen that done before
> for Electron packaging...
> 
> 
> -- 
> 真実はいつも一つ！/ 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nodejs-electron

[Sérgio Basto]

On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote:
> On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel
> wrote:
> > On 27/02/2022 08:23, Andreas Schneider wrote:
> > 
> > > You don't have to. You can point electron builder to your system
> > > electron
> > > and
>  it will use that. Then you just do not package the electron files.
> > > All you need is the resources directory.
> > 
> > 
> > You must run electron-builder on Fedora Koji. Pre-built packages are
> > not 
> > allowed.
> 
> You should not package electron at all with your package! You should
> use the 
> nodejs-electron in the distribution and just point it to the sources to
> load:
> 
> cat <%{buildroot}%{_bindir}/signal-desktop
> #!/bin/sh
> export NODE_ENV=production
> 
> exec %{_bindir}/electron %{_libdir}/%{name}/resources/app.asar "\$@"
> EOF
> chmod +x %{buildroot}%{_bindir}/signal-desktop

I started build electron on copr [1]  

I built ffmpeg , nodejs-electron, element-web and element-desktop  for
Fedora 34 and 35 successfully element-web fails on F36+ 

I rebuilt ffmpeg-free from Fedora to F35 and F34 
after I used
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
https://build.opensuse.org/package/show/devel:languages:javascript/element-web
https://build.opensuse.org/package/show/home:sergiomb/element-desktop


build on electron took 11 hours on x64 and 15 hours in aarch , is
almost a build o chromium , which make me wonder if we can't use a
chromium as a library
https://www.electronjs.org/blog/electron-internals-building-chromium-as-a-library


[1] https://copr.fedorainfracloud.org/coprs/sergiomb/electrons/monitor/
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nodejs-electron

[Sérgio Basto]

On Mon, 2022-03-21 at 15:56 +0100, Andreas Schneider wrote:
> On Saturday, March 19, 2022 7:01:46 AM CET Sérgio Basto wrote:
> > On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote:
> > 
> > > On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel
> > > wrote:
> > > 
> > > > On 27/02/2022 08:23, Andreas Schneider wrote:
> > > > 
> > > > 
> > > > > You don't have to. You can point electron builder to your
> > > > > system
> > > > > electron
> > > > > and
> > > 
> > >  it will use that. Then you just do not package the electron files.
> > > 
> > > > > All you need is the resources directory.
> > > > 
> > > > 
> > > > 
> > > > You must run electron-builder on Fedora Koji. Pre-built packages
> > > > are
> > > > not 
> > > > allowed.
> > > 
> > > 
> > > You should not package electron at all with your package! You
> > > should
> > > use the 
> > > nodejs-electron in the distribution and just point it to the
> > > sources to
> > > load
> > 
> > 
> > OK, we may not need electron-builder :D, I also mention electron-
> > builder more to explain how my element-desktop rpm was generated . 
> > 
> > so lets pack element-desktop , I found this 
> > 
> > https://build.opensuse.org/package/view_file/openSUSE:Factory/element-deskto
> > p/element-desktop.spec
>  
> > have we nodejs-electron available on copr ? if not, may I put it
> > there
> > or have we legal constraints ? 
> > 
> > Thanks. 
> 
> I'm building nodejs-electron for rawhide here:
> 
> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron


may I put nodejs-electron on copr  or have we any legal constraints ? 



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nodejs-electron

[Sérgio Basto]

On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote:
> On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel
> wrote:
> > On 27/02/2022 08:23, Andreas Schneider wrote:
> > 
> > > You don't have to. You can point electron builder to your system
> > > electron
> > > and
>  it will use that. Then you just do not package the electron files.
> > > All you need is the resources directory.
> > 
> > 
> > You must run electron-builder on Fedora Koji. Pre-built packages are
> > not 
> > allowed.
> 
> You should not package electron at all with your package! You should
> use the 
> nodejs-electron in the distribution and just point it to the sources to
> load

OK, we may not need electron-builder :D, I also mention electron-
builder more to explain how my element-desktop rpm was generated . 

so lets pack element-desktop , I found this 

https://build.opensuse.org/package/view_file/openSUSE:Factory/element-desktop/element-desktop.spec

have we nodejs-electron available on copr ? if not, may I put it there
or have we legal constraints ? 

Thanks. 

> :
> 
> cat <%{buildroot}%{_bindir}/signal-desktop
> #!/bin/sh
> export NODE_ENV=production
> 
> exec %{_bindir}/electron %{_libdir}/%{name}/resources/app.asar "\$@"
> EOF
> chmod +x %{buildroot}%{_bindir}/signal-desktop
> 
> 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> Leigh Scott kirjoitti 9.3.2022 klo 18.15:
> > > Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
> > > Crossfire and freedroidrpg are games, so "is it needed?" and
> > > "does it
> > > have a replacement?" are not good questions to ask. A better
> > > question
> > > would be "does anybody want to play it?". Games do not really ever
> > > become obsolete, each is a unique experience and cannot be replaced
> > > by a
> > > "modern alternative to X with more features".
> > > 
> > > Personally, I have never played either of these games, and I
> > > suspect I
> > > will not ever play them. Retiring them is probably not a great loss
> > > to
> > > Fedora. But, if there is no pressing reason, security issue, lack
> > > of
> > > maintainer or such, to retire the compatibility lib, I would prefer
> > > to
> > > keep all the games that somebody is willing to maintain.
> > > 
> > > 
> > > Otto
> > 
> > Both those games don't use gtk+-devel.
> 
> Thank you for looking that up, and even more for fixing the packages.

Continuing I brought the corrections to Fedora 36 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-db793ad26c

Now only 4 packages more gtk1+ depends on glib 

Depending packages (rawhide) (5): bubblemon gtk+ manedit xconvers
xvattr

Depending on: glib (5), 

bubblemon (maintained by: sham1)
bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

seems that can be build with gtk2
https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-plugins/bubblemon/bubblemon-1.46-r3.ebuild

xvattr (maintained by: ppisar, thias)
gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)

seems xvattr can be build with gtk2 
http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps


manedit (maintained by: pali)
manedit-1.2.1-27.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

(manedit have replacment with https://tracker.debian.org/pkg/gmanedit

xconvers (maintained by: hobbes1069)
xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

still only available on aur and Fedora 
https://repology.org/project/xconvers/versions 

> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem with cmake 3.23.0

[Sérgio Basto]

On Wed, 2022-03-16 at 07:17 -0700, Thomas Rodgers wrote:
> One more package that FTBFS due to CMake issues -
> 
> grive2: FTBFS # Error: /builddir/build/BUILD/grive2-0.5.1/redhat-
> linux-build is not a directory

remove the dot and I bet that will work 


> 
> On Mon, Mar 14, 2022 at 2:22 PM Thomas Rodgers 
> wrote:
> > 
> > 
> > 
> > On Mon, Mar 14, 2022 at 4:37 AM Jonathan Wakely
> >  wrote:
> > > On Fri, 4 Mar 2022 at 14:26, Steven A. Falco
> > >  wrote:
> > > > 
> > > > There is a new FTBFS for KiCad [1].  I filed an issue with
> > > > KiCad
> > > [2] and got a comment from the project leader:
> > > > 
> > > >       This looks like cmake issue to me. For some reason cmake
> > > > is
> > > creating an incorrect build folder:
> > > > 
> > > >       -- Build files have been written to:
> > > /builddir/build/BUILD/kicad-6.0.2
> > > > 
> > > >       so the build command:
> > > > 
> > > >       + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> > > > 
> > > >       cannot find the redhat-linux-build folder that was passed
> > > > on
> > > the cmake command line.
> > > > 
> > > > In the last successful build, we have: 
> > > 
> > > > 
> > > >     -- Build files have been written to:
> > > /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
> > > >     + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> > > > 
> > > > For some reason, the build file directory has changed:
> > > > 
> > > > Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-
> > > build
> > > > Failure case: /builddir/build/BUILD/kicad-6.0.2
> > > > 
> > > > Is this a bug in cmake or did something in RPM macros change?
> > > 
> > > Whatever it is seems to have broken a number of packages,
> > > including
> > > 
> > > FlightCrew, csdiff, libphonenumber, ledger, blas
> > > 
> > > Those are just the ones that need to be rebuilt for a new Boost
> > > and
> > > so
> > > were tested by Tom Rodgers, there are probably a lot more that he
> > > didn't find.
> > > 
> > > The ones I've checked all do "%cmake ." or "%cmake some_dir"
> > > 
> > > Some fail during the %cmake step, and some fail during
> > > %cmake_build.
> > > 
> > > 
> > 
> > 
> > These are the CMake related issues I've encountered thus far -
> > 
> > FlightCrew: FTBFS #  CMake Error: The source directory
> > "/builddir/build/BUILD/FlightCrew-0.9.1/build" does not appear to
> > contain CMakeLists.txt.
> > csdiff: FTBFS # Make Error: The source directory
> > "/builddir/build/BUILD/csdiff-2.2.0/x86_64-redhat-linux-gnu" does
> > not appear to contain CMakeLists.txt.
> > ledger: FTBFS # Error: /builddir/build/BUILD/ledger-3.2.1/redhat-
> > linux-build is not a directory
> > liblas: FTBFS # Error: /builddir/build/BUILD/libLAS-
> > d76a061f33a69a36ab116cd939c5d444b301efd8/redhat-linux-build is not
> > a directory
> > 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: undefined symbol `__libc_stack_end' in F36/Rawhide

[Sérgio Basto]

Hello,

On Thu, 2022-03-10 at 09:36 +0100, Florian Weimer wrote:
> * Ron Olson:
> 
> > Building swiftlang on F36/Rawhide results in a a failure that,
> > boiled down to its essence, appears to be:
> > 
> > /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32
> > against undefined symbol `__libc_stack_end' can not be used when
> > making a shared object; recompile with -fPIC
> > 
> > It compiles fine on 35 so I’m guessing glibc has been updated; a
> > bunch of web searching hasn’t come up with any useful suggestions,
> > the one ancient Bugzilla ticket I found was not resolved.
> > 
> > Any suggestions on what to do about this?
> 
> How is __libc_stack_end declared in the sources?  This could be a
> Clang
> bug or a bug in the source package.

by coincidence rawhide compose doomed since 20220309 (...) , i.e. maybe
this is a serious thing and someone need to look what is happening to
rawhide composes 



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Tue, 2022-03-08 at 16:01 +, Leigh Scott wrote:
> > On Mon, 07 Mar 2022 10:29:02 -0600
> > Michael Catanzaro  > 
> > 
> > I'm not unwilling to retire them, I just want their users to be
> > retired
> > first so I don't leave a bunch of broken dependencies behind.
> > 
> > Paul.
> 
> dillo, alsa-tools, gnubg,  and tilda don't rely on glib or gtk+, the
> package maintainers have made mistakes.

Hi Leigh ,
yes , it looks like glib-devel is not needed , I'm curious , how do you
find these mistakes ? 

Thank you 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Wed, 2022-03-09 at 08:20 +0200, Otto Urpelainen wrote:
> Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?
> > 
> > Depending packages (rawhide) (20): crossfire crossfire-client
> > crossfire-maps
> > freedroidrpg

> Crossfire and freedroidrpg are games, so "is it needed?" and "does it
> have a replacement?" are not good questions to ask. 

ok , IMO games don't have replacement , unless we have the same game in
other platform . 

> A better question
> would be "does anybody want to play it?". 

yes 

> Games do not really ever 
> become obsolete, each is a unique experience and cannot be replaced
> by a 
> "modern alternative to X with more features".
> 
> Personally, I have never played either of these games, and I suspect
> I 
> will not ever play them. Retiring them is probably not a great loss
> to 
> Fedora. But, if there is no pressing reason, security issue, lack of 
> maintainer or such, to retire the compatibility lib, I would prefer
> to 
> keep all the games that somebody is willing to maintain.
> 
> 
> Otto
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Tue, 2022-03-08 at 01:41 +0100, Kevin Kofler via devel wrote:
> Michael Catanzaro wrote:
> > The maintainer is unwilling to retire them.
> > 
> > I think we should ask FESCo to force them to be retired. It's
> > confusing
> > to have ancient versions of the packages in the distro, and they will
> > stick around forever if not.
> 
> I do not see why we would want to force removing working, maintained 
> packages from the distribution. That is a major disservice to users and
> basically a "screw you" to the maintainer. Whom does that help?
> 
> GLib 1 and GTK+ 1 are compatibility libraries. It is their whole
> purpose to 
> "stick around forever", at least as long as somebody is willing to
> maintain 
> them. They are needed to keep legacy applications working.
> 
> If FESCo wants to get involved at all (I do not really see any need for
> them 
> to intervene in the first place), I ask FESCo to affirm that a
> compatibility 
> library can remain in the distribution as long as it is maintained and
> to 
> ask people to refrain from posting unhelpful threads such as this one.
> 
> Nobody is asking you to maintain those packages, so I do not see why
> you 
> need to care at all about their existence.


Quote from the first email of this thread 

"any of these packages is needed ? or haven't replacement ?  " 



>     Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem with cmake 3.23.0

[Sérgio Basto]

Hi,

On Fri, 2022-03-04 at 18:07 +0100, Kamil Dudka wrote:
> On Friday, March 4, 2022 4:17:01 PM CET Sérgio Basto wrote:
> > I think you missed the 
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> 
> When the change landed, I had to fix all my packages to build although
> they 
> had been using out of source builds since the beginning.  Now I have to
> fix 
> them again.  Maintaining a spec file that works on RHEL-7..9 and on all
> supported releases of Fedora is more and more difficult for no good
> reason
> but I am not giving it up for now:
> 
> https://github.com/csutils/csdiff/commit/df8d918c
> https://github.com/csutils/csdiff/commit/9ec45f67
> 

I would have to waste some time to understand your commits, but at
first glance they are not correct, I would also have to analyze how the
macros are going on el7, I think cmake3 macros from epel-7 already
assumed all this. 

I advise anyone to carefully read the wiki page.
We have two options, or keep the directories, or remove the all
directories, from the build.
if we don't want to change anything we can use Martin's solution that
is add:
%global __cmake_in_source_build 1

otherwise we should not use any directory and use:

%undefine __cmake_in_source_build 


Best regards, 


> Kamil
> 
> 

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

Hi, 
In resume glib still required for 20 packages  [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ? 

Thanks 

 [1]
Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools
bubblemon crossfire crossfire-client crossfire-maps dillo
freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda
xconvers xdialog xvattr


Package   (co)maintainersStatus Change
==
glib  pghmcfc, rdieter   229 weeks ago

The following packages require above mentioned packages:
Depending on: glib (20), status change: 2017-10-10 (229 weeks ago)
bubblemon (maintained by: sham1)
bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

gnubg (maintained by: limb)
gnubg-1:1.06.001-14.fc35.src requires glib-devel = 1:1.2.10-64.fc36

gtk+ (maintained by: pghmcfc, rdieter)
gtk+-1:1.2.10-98.fc36.i686 requires libglib-1.2.so.0, libgmodule-
1.2.so.0
gtk+-1:1.2.10-98.fc36.src requires glib-devel = 1:1.2.10-64.fc36
gtk+-1:1.2.10-98.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)
gtk+-devel-1:1.2.10-98.fc36.i686 requires glib-devel(x86-32) =
1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10
gtk+-devel-1:1.2.10-98.fc36.x86_64 requires glib-devel(x86-64) =
1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10

xvattr (maintained by: ppisar, thias)
gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)

hikari (maintained by: fnux, sway-sig)
hikari-2.3.3-2.fc36.src requires glib-devel = 1:1.2.10-64.fc36

librcc (maintained by: ivanromanov)
librcc-gtk+-0.2.12-20.fc36.i686 requires libgdk-1.2.so.0, libglib-
1.2.so.0, libgmodule-1.2.so.0, libgtk-1.2.so.0
librcc-gtk+-0.2.12-20.fc36.x86_64 requires libgdk-1.2.so.0()(64bit),
libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit), libgtk-
1.2.so.0()(64bit)

manedit (maintained by: pali)
manedit-1.2.1-27.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

tilda (maintained by: hannes, laxathom)
tilda-1.5.4-4.fc36.src requires glib-devel = 1:1.2.10-64.fc36

xconvers (maintained by: hobbes1069)
xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

xdialog (maintained by: konradm)
xdialog-2.3.1-30.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

alsa-tools (maintained by: perex, timj)
alsa-tools-1.2.5-3.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36
alsa-tools-firmware-1.2.5-3.fc36.x86_64 requires alsa-firmware = 1.2.4-
6.fc36

crossfire-client (maintained by: limb)
crossfire-client-1.75.2-2.fc36.src requires gtk+-devel = 1:1.2.10-
98.fc36

dillo (maintained by: aarem, atim)
dillo-3.0.5-14.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36

freedroidrpg (maintained by: limb)
freedroidrpg-1.0-0.fc37.rc2.8.src requires gtk+-devel = 1:1.2.10-
98.fc36

libstroke (maintained by: jhogarth, sophiekovalevsky)
libstroke-0.5.1-45.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36

alsa-firmware (maintained by: perex, timj)
alsa-firmware-1.2.4-6.fc36.noarch requires alsa-tools-firmware = 1.2.5-
3.fc36

crossfire (maintained by: limb)
crossfire-client-images-1.71.0-21.fc36.x86_64 requires crossfire-client
= 1.75.2-2.fc36

fvwm (maintained by: jhogarth, mcermak, pertusus, peter)
fvwm-2.6.9-7.fc36.src requires libstroke-devel = 0.5.1-45.fc36
fvwm-2.6.9-7.fc36.x86_64 requires libstroke.so.0()(64bit)

crossfire-maps (maintained by: limb)
crossfire-maps-1.71.0-12.fc36.noarch requires crossfire = 1.71.0-
21.fc36

NsCDE (maintained by: dcavalca)
NsCDE-1.4-2.fc36.src requires fvwm = 2.6.9-7.fc36
NsCDE-1.4-2.fc36.x86_64 requires fvwm = 2.6.9-7.fc36

Affected (co)maintainers
aarem: glib
atim: glib
dcavalca: glib
fnux: glib
hannes: glib
hobbes1069: glib
ivanromanov: glib
jhogarth: glib
konradm: glib
laxathom: glib
limb: glib
mcermak: glib
pali: glib
perex: glib
pertusus: glib
peter: glib
pghmcfc: glib
ppisar: glib
rdieter: glib
sham1: glib
sophiekovalevsky: glib
sway-sig: glib
thias: glib
timj: glib

Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools
bubblemon crossfire crossfire-client crossfire-maps dillo
freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda
xconvers xdialog xvattr


FTBFS (rawhide) (1): glib


FTBFS (rawhide) (depended on) (1): glib


FTBFS (rawhide) (not depended on) (0):

--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py

Report finished at 2022-03-07 16:01:58 UTC
Addresses (24): pghm...@fedoraproject.org, rdie...@fedoraproject.org,
sh...@fedoraproject.org, l...@fedoraproject.org,
ppi...@fedoraproject.org, th...@fedoraproject.org,
f...@fedoraproject.org, sway-...@fedoraproject.org,
ivanroma...@fedoraproject.org, p...@fedoraproject.org,
han...@fedoraproject.org, laxat...@fedoraproject.org

Re: Problem with cmake 3.23.0

[Sérgio Basto]

On Fri, 2022-03-04 at 16:04 +0100, Michal Schorm wrote:
> On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto  wrote:
> > The fix is just remove "\  ." (the dot) on %cmake
> 
> That isn't a fix, that's a workaround for a broken CMake - atleast
> that I believe, as you can read in that BZ.
> I haven't found anything on CMake upstream that would suggest such
> change is needed, I found the contrary.
> 

> And even if this change would be actually intended, it would be nice
> from the CMake maintainer to announce it.


I think you missed the 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
(Targeted release: Fedora 33 ) and
https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/


My deduction also came from here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IGQFBIEBMFHIAHY45SKF5MXOJP43TVQS/

i.e. the builds that still aren't completely out of the source (i.e.
have the dot), can have (new) problems, one solution is make the build
out of the source as recommended  on
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds


Best regards, 

> On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto  wrote:
> > 
> > On Fri, 2022-03-04 at 09:26 -0500, Steven A. Falco wrote:
> > > There is a new FTBFS for KiCad [1].  I filed an issue with KiCad
> > > [2]
> > > and got a comment from the project leader:
> > > 
> > >  This looks like cmake issue to me. For some reason cmake is
> > > creating an incorrect build folder:
> > > 
> > >  -- Build files have been written to:
> > > /builddir/build/BUILD/kicad-
> > > 6.0.2
> > > 
> > >  so the build command:
> > > 
> > >  + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> > > 
> > >  cannot find the redhat-linux-build folder that was passed on
> > > the
> > > cmake command line.
> > > 
> > > In the last successful build, we have:
> > > 
> > >    -- Build files have been written to:
> > > /builddir/build/BUILD/kicad-
> > > 6.0.2/redhat-linux-build
> > >    + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> > > 
> > > For some reason, the build file directory has changed:
> > > 
> > > Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
> > > Failure case: /builddir/build/BUILD/kicad-6.0.2
> > > 
> > > Is this a bug in cmake or did something in RPM macros change?
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781
> > > [2] https://gitlab.com/kicad/code/kicad/-/issues/11043
> > > 
> > 
> > The fix is just remove "\  ." (the dot) on %cmake
> > in line
> > https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec#_92
> > 
> > 
> > 
> > 
> > >     Steve
> > > ___
> > > 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
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> > 
> > --
> > Sérgio M. B.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem with cmake 3.23.0

[Sérgio Basto]

On Fri, 2022-03-04 at 09:26 -0500, Steven A. Falco wrote:
> There is a new FTBFS for KiCad [1].  I filed an issue with KiCad [2]
> and got a comment from the project leader:
> 
>  This looks like cmake issue to me. For some reason cmake is
> creating an incorrect build folder:
> 
>  -- Build files have been written to: /builddir/build/BUILD/kicad-
> 6.0.2
> 
>  so the build command:
> 
>  + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> 
>  cannot find the redhat-linux-build folder that was passed on the
> cmake command line.
> 
> In the last successful build, we have:
> 
>    -- Build files have been written to: /builddir/build/BUILD/kicad-
> 6.0.2/redhat-linux-build
>    + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> 
> For some reason, the build file directory has changed:
> 
> Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
> Failure case: /builddir/build/BUILD/kicad-6.0.2
> 
> Is this a bug in cmake or did something in RPM macros change?
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781
> [2] https://gitlab.com/kicad/code/kicad/-/issues/11043
> 

The fix is just remove "\  ." (the dot) on %cmake 
in line
https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec#_92




> Steve
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nodejs-electron

[Sérgio Basto]

On Fri, 2022-02-25 at 08:02 -0500, Neal Gompa wrote:
> On Fri, Feb 25, 2022 at 4:54 AM Andreas Schneider 
> wrote:
> > 
> > Hello!
> > 
> > Over the past 8 month, I've been working on getting Electron [1]
> > built on
> > Fedora. Yesterday I was finally able to do the first working build
> > for Fedora
> > Rawhide [2]. This was possible because we finally have ffmpeg [3] in
> > Fedora.
> > My use for Electron is that I want to run signal-desktop [4] on
> > Fedora. You
> > can get electron and signal-packages packages for it at [5].
> > 
> > Is there interest to bring nodejs-electron into Fedora and if yes,
> > would
> > someone be interested to maintain it? I don't have the time to
> > maintain it but
> > I'm happy to help as a co-maintainer.
> > 
> 
> I think this is probably one of those things that would be worth
> forming a SIG on. An Electron SIG could help with Electron and all
> Electron-based applications that come into Fedora.
> 

I built and use element-desktop (
https://github.com/vector-im/element-desktop#readme ) on my desktop , I
spent 2 or 3 days on hacking the build , at the end I build an rpm with
electon-builder ... conclusion we may need also pack electon-builder.

I think we can join these talks on Node.js SIG (Node.js on Fedora
 ).  

I'd like pack at least nativefier, element-desktop, jitsi-meet-
electron, but I'm skeptical that it works with ffpmeg-free ...  

Learn and use nodejs-packaging-bundler, maybe is one solution which was
talked on Node.js SIG
https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/44SXBQO74IZSYQNDT7DGYZYIVOD6KXMS/
BTW UnitedRPMs also have a electron package
https://github.com/UnitedRPMs/electron , it may help, I don't know, 
and jitsi-meet-electron
https://github.com/UnitedRPMs/jitsi-meet-electron which need network
enabled to download sources while is building the package ... 

Best regards,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Devtoolset for epel7 for build in Copr

[Sérgio Basto]

On Fri, 2022-02-25 at 02:43 +0300, Dmitry Butskoy wrote:
> Sérgio Basto wrote:
> > On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote:
> > > Miroslav Suchý wrote:
> > > > > Second, the alternate Springdale Linux repo
> > > > > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ s
> > > > > ee
> > > > > ms
> > > > > to have all the ones (which are provided in sources by RedHat),
> > > > > but
> > > > > cannot be used in Copr. Springdale provides devtoolset-3-
> > > > > elfutils
> > > > > there, and it in some strange way  badly correlates with the
> > > > > initial
> > > > > Copr build environment (even before the rpmbuild process
> > > > > starts).
> > > > > Some python2 module cannot find libelf.so.1 ...
> > > > 
> > > > That is because it is SCL package. It installs the library to
> > > > 
> > > > /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1
> > > > 
> > > > You have to run
> > > > 
> > > >    scl enable devtools-3 $COMMAND
> > > > 
> > > But where to run it exactly?
> > > 
> > yes is not easy find an example unfortunately , first line of %build
> 
> %build is in the .spec file. It is readed after the start of the build.
> The start of the build is performed after the "bootstrap" stage. At
> this 
> stage "yum install" creates an initial environment. Probably I'm wrong 
> -- 

Sorry this thread have different topics, after reading it . 

 libelf.so.1: cannot open shared object file: No such file , should we
a mixup of devtools set , you just can Buildrequires one devtool set 

Second llvm-toolset-11.0 is only available on RedHat EL 7 , that is why
koji builds seamonkey which uses RHEL 7 and copr  don't, it uses Centos
7

Third, search on goggle I found that is also available on Scientific
Linux 7
http://rpm.pbone.net/results_srodzaj_1_search_libLLVM-11.so%28%29%2864bit%29.html


> could you pls look at:
> > Start: yum install
> > There was a problem importing one of the Python modules
> > required to run yum. The error leading to this problem was:
> > 
> >     libelf.so.1: cannot open shared object file: No such file or
> > directory
> fragment in the correspond log: 
> https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz
>  
> ?
> 
> IOW: there is no "yum install" in the .spec file. So where to run 
> "scl-enable ..." to take it effect before that "yum install" ?
> 
> 
> ~buc
> 
> 
> 
> 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Devtoolset for epel7 for build in Copr

[Sérgio Basto]

On Fri, 2022-02-25 at 02:43 +0300, Dmitry Butskoy wrote:
> Sérgio Basto wrote:
> > On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote:
> > > Miroslav Suchý wrote:
> > > > > Second, the alternate Springdale Linux repo
> > > > > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/
> > > > >  see
> > > > > ms
> > > > > to have all the ones (which are provided in sources by
> > > > > RedHat),
> > > > > but
> > > > > cannot be used in Copr. Springdale provides devtoolset-3-
> > > > > elfutils
> > > > > there, and it in some strange way  badly correlates with the
> > > > > initial
> > > > > Copr build environment (even before the rpmbuild process
> > > > > starts).
> > > > > Some python2 module cannot find libelf.so.1 ...
> > > > 
> > > > That is because it is SCL package. It installs the library to
> > > > 
> > > > /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1
> > > > 
> > > > You have to run
> > > > 
> > > >    scl enable devtools-3 $COMMAND
> > > > 
> > > But where to run it exactly?
> > > 
> > yes is not easy find an example unfortunately , first line of
> > %build
> 
> %build is in the .spec file. It is readed after the start of the
> build. 
> The start of the build is performed after the "bootstrap" stage. At
> this 
> stage "yum install" creates an initial environment. Probably I'm
> wrong 

. /opt/rh/devtoolset-9/enable

before cd mozilla 

instead `source scl_source enable devtoolset-9`

> -- could you pls look at:
> > Start: yum install
> > There was a problem importing one of the Python modules
> > required to run yum. The error leading to this problem was:
> > 
> >     libelf.so.1: cannot open shared object file: No such file or
> > directory
> fragment in the correspond log: 
> https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz
>  
> ?
> 
> IOW: there is no "yum install" in the .spec file. So where to run 
> "scl-enable ..." to take it effect before that "yum install" ?
> 
> 
> ~buc
> 
> 
> 
> 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Devtoolset for epel7 for build in Copr

[Sérgio Basto]

On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote:
> Miroslav Suchý wrote:
> > 
> > > 
> > > Second, the alternate Springdale Linux repo 
> > > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ see
> > > ms
> > > to have all the ones (which are provided in sources by RedHat),
> > > but 
> > > cannot be used in Copr. Springdale provides devtoolset-3-elfutils
> > > there, and it in some strange way  badly correlates with the
> > > initial 
> > > Copr build environment (even before the rpmbuild process starts).
> > > Some python2 module cannot find libelf.so.1 ...
> > 
> > 
> > That is because it is SCL package. It installs the library to
> > 
> > /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1
> > 
> > You have to run
> > 
> >   scl enable devtools-3 $COMMAND
> > 
> 
> But where to run it exactly?
> 

yes is not easy find an example unfortunately , first line of %build 

see this example : 
https://src.fedoraproject.org/rpms/mkvtoolnix/blob/4400f88779be30d35d909545b76346dc218c24d4/f/mkvtoolnix.spec#_76


> It seems it happens on some early stage (so I cannot alter anything in 
> the .spec file).
> 
> Could anybody look into the prolem log: 
> https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz
>  
> ?
> 
> 
> ~buc
> 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Mon, 2022-02-14 at 11:28 +, Sérgio Basto wrote:
> On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> > The time had to come, when two packages would generate the same
> > hash.
> > 
> > I was hit by:
> > ---
> > Error: Transaction test error:
> >   file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> > conflicts between attempted installs of discord-0.0.16-
> > 1.fc35.x86_64
> > and skypeforlinux-8.79.0.95-1.x86_64
> > ---
> > some time ago but since neither is a package maintained by Fedora
> > Project maintainers, no one gave a damn about the core of the
> > issue.
> > That time, I got one of the apps as a Flatpak instead, but not all
> > packages have such workarounds at hand.
> 
> yeah , thank you for reminder these cases (with electron apps)
> 
> we fixed with `%global debug_package %{nil}`

is fixed with %global _build_id_links none


> > --
> > 
> > Michal Schorm
> > Software Engineer
> > Core Services - Databases Team
> > Red Hat
> > 
> > --
> > 
> > On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok 
> > wrote:
> > > 
> > > Hey,
> > > apparently some ELF files are identical between Fedora's pypy3.7-
> > > libs and
> > > pypy3.8-libs packages.
> > > 
> > > On Fedora 34, this leads to installation conflict:
> > > 
> > > Error: Transaction test error:
> > >    file /usr/lib/.build-
> > > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > > 
> > > As reported in https://bugzilla.redhat.com/2053880
> > > 
> > > I've read all the previous discussion about this on Fedora devel
> > > list, but I
> > > still have no idea what should I do to prevent this conflict.
> > > 
> > > Moving the files to a common component seems like a bad idea
> > > given
> > > it's not
> > > "two packages bundle the same thing" but rather "two packages
> > > built
> > > in a
> > > different way".
> > > 
> > > I see this:
> > > 
> > > https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
> > > 
> > > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> > > 
> > > I suppose I could pass in %{NAME} as well, right?
> > > 
> > > What are the side effects for changing the seed like this?:
> > > 
> > > %global __

Re: Packaging scrcpy with a precompiled APK dependency.

[Sérgio Basto]

On Wed, 2022-02-16 at 17:57 -0300, Diego Herrera wrote:
> Hi. I was checking if the scrcpy software [1] could get packaged, but
> to continue I need to know how to package an APK package file. For
> context, this project consists on a Linux client and an Android
> server app that is uploaded as an APK package by the client to an
> Android device using adb to share the Android device screen.
> 
> The project provides the sources to build that APK file, but it
> depends on gradle and the Android SDK to build it. Even if we revive
> the gradle package, I doubt that we can package the Android SDK since
> it requires it's own set of licenses and I don't think that
> everything complies to the policies. I also don't know if there is a
> way to compile the APK without those dependencies.
> 
> On the other hand, the project also provides the precompiled APK that
> can get directly added to the package (that's how other distros
> package this software), but I doubt that adding a binary package
> complies with Fedora's policies even if its not used on the same
> Fedora machine.
> 
> Another idea that I thought of was to patch the program or add a
> script that downloads the APK on the first run and save it on
> userspace. Technically you are not packaging the binary, but in my
> opinion it's just a roundabout way to get the same result.
> 
> Is any of these approaches viable from a policy perspective? Is there
> a better way to do this? Or should I desist on packaging this project
> on Fedora for now?
> 
> [1] https://github.com/Genymobile/scrcpy

you got several packages 
from  https://repology.org/project/scrcpy/versions
https://fedora.pkgs.org/34/rpm-sphere-x86_64/scrcpy-1.19-1.x86_64.rpm.html


in copr 
https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=scrcpy
https://copr.fedorainfracloud.org/coprs/useidel/scrcpy/
https://copr.fedorainfracloud.org/coprs/sixgd/scrcpy/
https://copr.fedorainfracloud.org/coprs/zeno/scrcpy/

etc


> Best regards.
> 
> --
> Diego Herrera C.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Sun, 2022-02-13 at 14:11 +0100, Miro Hrončok wrote:
> Hey,
> apparently some ELF files are identical between Fedora's pypy3.7-libs
> and 
> pypy3.8-libs packages.
> 
> On Fedora 34, this leads to installation conflict:
> 
> Error: Transaction test error:
>    file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> 
> As reported in https://bugzilla.redhat.com/2053880
> 
> I've read all the previous discussion about this on Fedora devel
> list, but I 
> still have no idea what should I do to prevent this conflict.
> 
> Moving the files to a common component seems like a bad idea given
> it's not 
> "two packages bundle the same thing" but rather "two packages built
> in a 
> different way".
> 
> I see this:
> 
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
> 
> %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> 
> I suppose I could pass in %{NAME} as well, right?


yes , I like your solution , as talked in previous messages we have a
long historical of .build-id file conflicts , which we should prevent 


> What are the side effects for changing the seed like this?:
> 
> %global __debug_install_post \
>  
> %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-
> seed%s+"',
> rpm.expand('--build-id-seed "%{NAME}-')))}
> 
> 
> Actually, should RPM pass %{NAME} by default? Or at least have a
> macro I could 
> redefine in a less cryptic and fragile way?
> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedora-packaging] Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Tue, 2022-02-15 at 15:46 +0100, Miro Hrončok wrote:
> On 15. 02. 22 15:31, Sérgio Basto wrote:
> > On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
> > > On 14. 02. 22 10:34, Michal Schorm wrote:
> > > > The time had to come, when two packages would generate the same
> > > > hash.
> > > > 
> > > > I was hit by:
> > > > ---
> > > > Error: Transaction test error:
> > > >     file/usr/lib/.build-
> > > > id/34/feaa549462e8818baa0629ce11da344465882b
> > > > conflicts between attempted installs of discord-0.0.16-
> > > > 1.fc35.x86_64
> > > > and skypeforlinux-8.79.0.95-1.x86_64
> > > > ---
> > > > some time ago but since neither is a package maintained by
> > > > Fedora
> > > > Project maintainers, no one gave a damn about the core of the
> > > > issue.
> > > > That time, I got one of the apps as a Flatpak instead, but not
> > > > all
> > > > packages have such workarounds at hand.
> > > 
> > > That's because they both ship the same electron binary.
> > 
> > Right , so ? two package can't ship the same binary on Fedora ?
> 
> I never said that. What I meant is that that problem is known and I
> need to 
> help with a different problem.

I was being ironic, I didn't want to say that either, sorry. 

But I think the root of the problem is the same,  .build-id hash be the
same is not a coincidence .

Also we have old bug reports about .build-id hash conflicts , IIRC .


Best regards,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedora-packaging] Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
> On 14. 02. 22 10:34, Michal Schorm wrote:
> > The time had to come, when two packages would generate the same
> > hash.
> > 
> > I was hit by:
> > ---
> > Error: Transaction test error:
> >    file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> > conflicts between attempted installs of discord-0.0.16-
> > 1.fc35.x86_64
> > and skypeforlinux-8.79.0.95-1.x86_64
> > ---
> > some time ago but since neither is a package maintained by Fedora
> > Project maintainers, no one gave a damn about the core of the
> > issue.
> > That time, I got one of the apps as a Flatpak instead, but not all
> > packages have such workarounds at hand.
> 
> That's because they both ship the same electron binary.

Right , so ? two package can't ship the same binary on Fedora ? 


> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to
> packaging-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/packag...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> The time had to come, when two packages would generate the same hash.
> 
> I was hit by:
> ---
> Error: Transaction test error:
>   file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.

yeah , thank you for reminder these cases (with electron apps)

we fixed with `%global debug_package %{nil}`


> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
> 
> On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok 
> wrote:
> > 
> > Hey,
> > apparently some ELF files are identical between Fedora's pypy3.7-
> > libs and
> > pypy3.8-libs packages.
> > 
> > On Fedora 34, this leads to installation conflict:
> > 
> > Error: Transaction test error:
> >    file /usr/lib/.build-
> > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >    file /usr/lib/.build-
> > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > 
> > As reported in https://bugzilla.redhat.com/2053880
> > 
> > I've read all the previous discussion about this on Fedora devel
> > list, but I
> > still have no idea what should I do to prevent this conflict.
> > 
> > Moving the files to a common component seems like a bad idea given
> > it's not
> > "two packages bundle the same thing" but rather "two packages built
> > in a
> > different way".
> > 
> > I see this:
> > 
> > https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
> > 
> > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> > 
> > I suppose I could pass in %{NAME} as well, right?
> > 
> > What are the side effects for changing the seed like this?:
> > 
> > %global __debug_install_post \
> > 
> > %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> > id%-seed%s+"',
> > rpm.expand('--build-id-seed "%{NAME}-')))}
> > 
> > 
> > Actually, should RPM pass %{NAME} by default? Or at least have a
> > macro I could
> > redefine in a less cryptic and fragile way?
> > 
> > --
> > Miro Hrončok
> > --
> > Phone: +420777974800
> > IRC: mhroncok
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://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
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> ___
> 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://

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Sérgio Basto]

./find_unblocked_orphans.py --max_deps 1 --skip-orphans jasper

Depending on: jasper (30), 
DevIL (maintained by: jwrdegoede)
DevIL-1.7.8-38.fc36.i686 requires libjasper.so.4
DevIL-1.7.8-38.fc36.src requires jasper-devel = 2.0.33-2.fc36
DevIL-1.7.8-38.fc36.x86_64 requires libjasper.so.4()(64bit)
DevIL-ILUT-1.7.8-38.fc36.i686 requires libjasper.so.4
DevIL-ILUT-1.7.8-38.fc36.x86_64 requires libjasper.so.4()(64bit)

GraphicsMagick (maintained by: ixs, rdieter)
GraphicsMagick-1.3.36-6.fc36.i686 requires libjasper.so.4
GraphicsMagick-1.3.36-6.fc36.src requires jasper-devel = 2.0.33-2.fc36
GraphicsMagick-1.3.36-6.fc36.x86_64 requires libjasper.so.4()(64bit)

ImageMagick (maintained by: kalev, luya, remi, sergiomb, troycurtisjr)
ImageMagick-1:6.9.12.37-1.fc36.src requires pkgconfig(jasper) = 2.0.33

LibRaw (maintained by: dchen, hobbes1069, limb)
LibRaw-0.20.2-5.fc36.i686 requires libjasper.so.4
LibRaw-0.20.2-5.fc36.src requires pkgconfig(jasper) = 2.0.33
LibRaw-0.20.2-5.fc36.x86_64 requires libjasper.so.4()(64bit)

OpenImageIO (maintained by: hobbes1069)
OpenImageIO-2.3.12.0-1.fc36.src requires jasper-devel = 2.0.33-2.fc36

OpenSceneGraph (maintained by: smani)
OpenSceneGraph-3.6.5-2.fc36.src requires jasper-devel = 2.0.33-2.fc36
OpenSceneGraph-libs-3.6.5-2.fc36.i686 requires libjasper.so.4
OpenSceneGraph-libs-3.6.5-2.fc36.x86_64 requires
libjasper.so.4()(64bit)

darktable (maintained by: asn, germano, kalev, madko)
darktable-3.8.0-7.fc36.src requires libjasper-devel = 2.0.33-2.fc36

dcraw (maintained by: jridky, nphilipp)
dcraw-9.28.0-13.fc36.src requires jasper-devel = 2.0.33-2.fc36
dcraw-9.28.0-13.fc36.x86_64 requires libjasper.so.4()(64bit)

digikam (maintained by: dvratil, kde-sig, kwizart, nucleo, rdieter,
than, tuxbrewr, vjancik)
digikam-7.5.0-2.fc36.src requires pkgconfig(jasper) = 2.0.33
digikam-libs-7.5.0-2.fc36.i686 requires libjasper.so.4
digikam-libs-7.5.0-2.fc36.x86_64 requires libjasper.so.4()(64bit)

eccodes (maintained by: jdekloe)
eccodes-2.24.0-2.fc36.src requires jasper-devel = 2.0.33-2.fc36
eccodes-2.24.0-2.fc36.x86_64 requires libjasper.so.4()(64bit)
eccodes-devel-2.24.0-2.fc36.x86_64 requires jasper-devel(x86-64) =
2.0.33-2.fc36

g2clib (maintained by: jdekloe, orion, scitech_sig)
g2clib-1.6.3-3.fc36.src requires jasper-devel = 2.0.33-2.fc36
g2clib-devel-1.6.3-3.fc36.i686 requires jasper-devel(x86-32) = 2.0.33-
2.fc36
g2clib-devel-1.6.3-3.fc36.x86_64 requires jasper-devel(x86-64) =
2.0.33-2.fc36

gdal (maintained by: alexlan, devrim, jmlich, neteler, oliver, orion,
pali, praiskup, smani, volter)
gdal-3.4.1-4.fc36.src requires jasper-devel = 2.0.33-2.fc36
gdal-java-3.4.1-4.fc36.x86_64 requires libjasper.so.4()(64bit)
gdal-libs-3.4.1-4.fc36.i686 requires libjasper.so.4
gdal-libs-3.4.1-4.fc36.x86_64 requires libjasper.so.4()(64bit)

gegl04 (maintained by: jridky, nphilipp)
gegl04-0.4.34-2.fc36.i686 requires libjasper.so.4
gegl04-0.4.34-2.fc36.src requires pkgconfig(jasper) = 2.0.33
gegl04-0.4.34-2.fc36.x86_64 requires libjasper.so.4()(64bit)

gimp (maintained by: jridky, nphilipp, zdohnal)
gimp-2:2.10.30-1.fc36.1.src requires jasper-devel = 2.0.33-2.fc36

grads (maintained by: deji)
grads-2.0.2-39.fc36.x86_64 requires libjasper.so.4()(64bit)

grib_api (maintained by: jdekloe, orion)
grib_api-1.27.0-13.fc36.i686 requires libjasper.so.4
grib_api-1.27.0-13.fc36.src requires jasper-devel = 2.0.33-2.fc36
grib_api-1.27.0-13.fc36.x86_64 requires libjasper.so.4()(64bit)
grib_api-devel-1.27.0-13.fc36.i686 requires jasper-devel(x86-32) =
2.0.33-2.fc36
grib_api-devel-1.27.0-13.fc36.x86_64 requires jasper-devel(x86-64) =
2.0.33-2.fc36

gstreamer1-plugins-bad-free (maintained by: swt2c, uraeus, wtaymans)
gstreamer1-plugins-bad-free-1.20.0-1.fc36.src requires jasper-devel =
2.0.33-2.fc36

kdelibs (maintained by: dvratil, jgrulich, jreznik, kde-sig, kkofler,
rdieter, than)
kdelibs-6:4.14.38-30.fc36.i686 requires libjasper.so.4
kdelibs-6:4.14.38-30.fc36.src requires pkgconfig(jasper) = 2.0.33
kdelibs-6:4.14.38-30.fc36.x86_64 requires libjasper.so.4()(64bit)

kdelibs3 (maintained by: jreznik, kkofler, rdieter, than)
kdelibs3-3.5.10-114.fc36.i686 requires libjasper.so.4
kdelibs3-3.5.10-114.fc36.src requires jasper-devel = 2.0.33-2.fc36
kdelibs3-3.5.10-114.fc36.x86_64 requires libjasper.so.4()(64bit)

kf5-kimageformats (maintained by: dvratil, jgrulich, kde-sig, rdieter,
than)
kf5-kimageformats-5.90.0-2.fc36.src requires jasper-devel = 2.0.33-
2.fc36

kopete (maintained by: jreznik, kde-sig, nucleo, rdieter, than)
kopete-21.12.2-1.fc36.src requires pkgconfig(jasper) = 2.0.33

libicns (maintained by: hobbes1069, musuruan, xavierb)
libicns-0.8.1-23.fc36.i686 requires libjasper.so.4
libicns-0.8.1-23.fc36.src requires jasper-devel = 2.0.33-2.fc36
libicns-0.8.1-23.fc36.x86_64 requires libjasper.so.4()(64bit)

ncl (maintained by: orion, scitech_sig)
ncl-6.6.2-25.fc36.x86_64 requires libjasper.so.4()(64bit)

netpbm (maintained by: jridky, phracek)
netpbm-10.97.00-2.fc36.src requires jasper-devel = 2.0.33-2.fc36
netpbm

Re: Bodhi and "update ejected from the push" errors

[Sérgio Basto]

On Sat, 2022-01-29 at 11:12 -0800, Kevin Fenzi wrote:
> On Sat, Jan 29, 2022 at 05:38:42PM +, Mattia Verga via devel
> wrote:
> > Recently we're having some (a lot) of errors about updates stuck in
> > Bodhi with errors like "update ejected from the push because Cannot
> > find
> > relevant tag...".
> > 
> > I tried to fix some of them myself, and relengs folks are also on
> > this.
> > But since there are so many, I'll post here how to fix yourself.
> > 
> > If your Bodhi update is stuck in the "Pending" state, please make
> > sure
> > that all the builds inside the update are tagged in the release
> > candidate tag (which is typically something like
> > 'f35-updates-candidate'). You can check that by clicking on the
> > build(s)
> > name(s) in the right column on the update page.
> > 
> > If any build in the update is not properly tagged, you must
> > manually tag
> > it with something like:
> > 
> > koji tag-build f35-updates-candidate build-0.1.2-1.fc35
> > 

Hi, 

Trying to help out here, please check this 2 pages (1), seems the
builds with 2 weeks, were not fixed by the maintainers (yet), could you
fix them ? 

Thank you 

(1)
https://bodhi.fedoraproject.org/updates/?search=&status=pending&page=2

https://bodhi.fedoraproject.org/updates/?search=&status=pending&page=3


> > (obviously you need koji cli to be installed on your system and you
> > need
> > to be authenticated with kerberos)
> > 



> > After all the builds in the update are tagged you can push the update
> > to
> > testing. If you just push the update without all the builds properly
> > tagged, you'll get another "update ejected from the push" the next
> > Bodhi
> > composer run.
> > 
> > For updates stuck in the "Testing" state, the quickest solution is to
> > unpush the update with the button in Bodhi web interface and then
> > re-submit it to testing.
> > 
> > Mattia
> 
> Thanks for that post mattia! 
> 
> I'll note that I am pretty convinced this is caused by the koji
> duplicate tagging issue, so I have downgraded the koji hubs back to
> 1.26.1 until the bug can get sorted out upstream. 
> 
> Hopefully that means things will go back to normal as we fix the
> already
> mistagged things now. 
> 
> kevin
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced .so version bump: glew

[Sérgio Basto]

Compose of f36 still have glew-2.1.0-11.fc36 maybe we can move it to a
side tag and start the rebuilds

Depending packages (66): FlightGear FlightGear-Atlas
OpenColorIO OpenImageIO SFML amanith astromenace avogadro2
avogadro2-libs blender bzflag calligra cegui cegui06 cloudcompare
colobot ddnet dreamchess eigen3 enblend endless-sky freedroidrpg
freewrl gambas3 gource hedgewars hugin hyperrogue kalzium kicad
linphone logstalgia mangohud megaglest meshlab mupen64plus ogre
openclonk opencolorio1 opencsg openmsx openscad opensubdiv
osgearth paraview pcl pioneer pocl prusa-slicer pymol quesoglc
root rss-glx schroedinger scorched3d scummvm sdljava sdrpp slop
supertux supertuxkart toped vdrift vtk widelands wxmacmolplt

depending on: glew (66)
FlightGear (maintained by: bellet)
FlightGear-2020.3.12-1.fc36.src requires glew-devel = 2.1.0-11.fc36
FlightGear-2020.3.12-1.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

FlightGear-Atlas (maintained by: bellet)
FlightGear-Atlas-0.5.0-0.74.cvs20141002.fc36.src requires glew-devel =
2.1.0-11.fc36
FlightGear-Atlas-0.5.0-0.74.cvs20141002.fc36.x86_64 requires
libGLEW.so.2.1()(64bit)

OpenColorIO (maintained by: hobbes1069)
OpenColorIO-2.1.1-2.fc36.src requires glew-devel = 2.1.0-11.fc36
OpenColorIO-tools-2.1.1-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

OpenImageIO (maintained by: hobbes1069)
OpenImageIO-2.3.12.0-1.fc36.src requires glew-devel = 2.1.0-11.fc36

SFML (maintained by: pranvk, sonkun, wtaymans)
SFML-2.5.1-10.fc36.src requires glew-devel = 2.1.0-11.fc36

amanith (maintained by: spot)
amanith-0.3-48.fc36.i686 requires libGLEW.so.2.1
amanith-0.3-48.fc36.src requires glew-devel = 2.1.0-11.fc36
amanith-0.3-48.fc36.x86_64 requires libGLEW.so.2.1()(64bit)
amanith-devel-0.3-48.fc36.i686 requires glew-devel = 2.1.0-11.fc36
amanith-devel-0.3-48.fc36.x86_64 requires glew-devel = 2.1.0-11.fc36

astromenace (maintained by: limb)
astromenace-1.4.2-3.fc36.src requires glew-devel = 2.1.0-11.fc36

avogadro2 (maintained by: sagitter)
avogadro2-1.95.1-5.fc36.src requires glew-devel = 2.1.0-11.fc36

avogadro2-libs (maintained by: sagitter)
avogadro2-libs-1.95.1-6.fc36.i686 requires libGLEW.so.2.1
avogadro2-libs-1.95.1-6.fc36.src requires pkgconfig(glew) = 2.1.0
avogadro2-libs-1.95.1-6.fc36.x86_64 requires libGLEW.so.2.1()(64bit)
avogadro2-libs-devel-1.95.1-6.fc36.i686 requires glew-devel(x86-32) =
2.1.0-11.fc36
avogadro2-libs-devel-1.95.1-6.fc36.x86_64 requires glew-devel(x86-64) =
2.1.0-11.fc36

blender (maintained by: design-sw, ignatenkobrain, kwizart, luya, roma,
s4504kr, slaanesh)
blender-1:3.0.0-2.fc36.src requires pkgconfig(glew) = 2.1.0
blender-1:3.0.0-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

bzflag (maintained by: jmakey)
bzflag-2.4.22-3.fc36.src requires glew-devel = 2.1.0-11.fc36
bzflag-2.4.22-3.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

calligra (maintained by: kde-sig, rdieter)
calligra-3.2.1-16.fc36.src requires pkgconfig(glew) = 2.1.0

cegui (maintained by: bruno, jwrdegoede, timn)
cegui-0.8.7-23.fc36.i686 requires libGLEW.so.2.1
cegui-0.8.7-23.fc36.src requires glew-devel = 2.1.0-11.fc36
cegui-0.8.7-23.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

cegui06 (maintained by: bruno, jwrdegoede)
cegui06-0.6.2-37.fc36.src requires glew-devel = 2.1.0-11.fc36
cegui06-0.6.2-37.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

cloudcompare (maintained by: churchyard)
cloudcompare-2.9.1-17.fc36.src requires pkgconfig(glew) = 2.1.0

colobot (maintained by: suve)
colobot-0.2.0-1.fc36.src requires glew-devel = 2.1.0-11.fc36
colobot-0.2.0-1.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

ddnet (maintained by: sergiomb)
ddnet-15.8.1-2.fc36.src requires pkgconfig(glew) = 2.1.0
ddnet-15.8.1-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

dreamchess (maintained by: raphgro)
dreamchess-0.3.0-0.12.20180601git.fc36.src requires glew-devel = 2.1.0-
11.fc36
dreamchess-0.3.0-0.12.20180601git.fc36.x86_64 requires
libGLEW.so.2.1()(64bit)

eigen3 (maintained by: rmattes, smani)
eigen3-3.4.0-4.fc36.src requires glew-devel = 2.1.0-11.fc36

enblend (maintained by: bpostle)
enblend-4.2-22.fc36.src requires glew-devel = 2.1.0-11.fc36

endless-sky (maintained by: linkdupont)
endless-sky-0.9.14-3.fc36.src requires glew-devel = 2.1.0-11.fc36
endless-sky-0.9.14-3.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

freedroidrpg (maintained by: limb)
freedroidrpg-1.0-0.fc36.rc2.7.src requires glew-devel = 2.1.0-11.fc36
freedroidrpg-1.0-0.fc36.rc2.7.x86_64 requires libGLEW.so.2.1()(64bit)

freewrl (maintained by: spot, stevetraylen)
freewrl-4.3.0-11.20200221gite99ab4a.fc36.src requires glew-devel =
2.1.0-11.fc36

gambas3 (maintained by: spot)
gambas3-3.16.3-5.fc36.src requires glew-devel = 2.1.0-11.fc36
gambas3-gb-opengl-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit)
gambas3-gb-opengl-glsl-3.16.3-5.fc36.x86_64 requires
libGLEW.so.2.1()(64bit)
gambas3-gb-opengl-sge-3.16.3-5.fc36.x86_64 requires
libGLEW.so.2.1()(64bit)
gambas3-gb-sdl-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit)

gource (maint

No response to pull request , should I use proven packager power ?

[Sérgio Basto]

Should I merge [1] and update the package  ? the security bugs are
opened since September [2] ...

https://src.fedoraproject.org/rpms/python-rencode/pull-request/1


https://bugzilla.redhat.com/show_bug.cgi?id=2003753
https://bugzilla.redhat.com/show_bug.cgi?id=2003754 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

some errors found [was:] what is wrong with this conditional scriptlet on rpm.spec

[Sérgio Basto]

On Wed, 2021-11-03 at 18:41 +, Sérgio Basto wrote:
> On Wed, 2021-11-03 at 14:26 -0400, Ben Beasley wrote:
> > I don’t know where to find documentation for operator precedence in
> > RPM 
> > conditional expressions, but it looks like “!” binds more tightly
> > than 
> > “>=”, so
> > 
> >  > %if ! 0%{?rhel} >= 8
> > 
> > is grouped as
> > 
> >  > %if (! 0%{?rhel}) >= 8
> > 
> > which becomes, on Fedora:
> > 
> >  > %if (! 00) >= 8
> > 
> >  > %if 1 >= 8
> > 
> > and therefore evaluates false.
> > 
> > Writing
> > 
> >  > %if ! (0%{?rhel} >= 8)
> > 
> > seems to do what you want, as would:
> 
> yes is exactly what I'm missing 
> 
> Thank you 
> 
> 
> >  > %if 0%{?rhel} < 8
> > 
> 
> the logic doesn't fail , but it is trick because includes {?fedora}
> 

I mean attention on use of "less then" (<) because is tricky, all
Fedora releases are included by "%if 0%{?rhel} < 8" 

if we only want rhel and rhel < 8 , the correct is  

%if 0%{?rhel} && 0%{?rhel} < 8

and the negation is (all but epel7) 

%if ! (0%{?rhel} && 0%{?rhel} < 8)


I found some specs in Fedora is this kind of errors (two are related
with imageMagick) 

https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+file:.*\.spec%24+![^\(]%3F0+[%3E%3C%3D]&patternType=regexp&case=yes
not all 64 results are wrong I only confirmed 9.

https://sourcegraph.com/src.fedoraproject.org/rpms/wsjtx/-/blob/wsjtx.spec?L60
https://sourcegraph.com/src.fedoraproject.org/rpms/wmdocker/-/blob/wmdocker.spec?L17
https://sourcegraph.com/src.fedoraproject.org/rpms/qt5-qtbase/-/blob/qt5-qtbase.spec?L376
https://sourcegraph.com/src.fedoraproject.org/rpms/pstoedit/-/blob/pstoedit.spec?L26
https://sourcegraph.com/src.fedoraproject.org/rpms/ocaml-fileutils/-/blob/ocaml-fileutils.spec?L72
https://sourcegraph.com/src.fedoraproject.org/rpms/mrbs/-/blob/mrbs.spec?L15
https://sourcegraph.com/src.fedoraproject.org/rpms/mrpt/-/blob/mrpt.spec?L59
https://sourcegraph.com/src.fedoraproject.org/rpms/klog/-/blob/klog.spec?L27
https://sourcegraph.com/src.fedoraproject.org/rpms/inkscape/-/blob/inkscape.spec?L43


> > On 11/3/21 14:09, Sérgio Basto wrote:
> > > Hi,
> > > 
> > > I just notice build in mock or koji this scriptlet [1] on a build
> > > for
> > > Fedora gives me "is rhel 8 or 9" , what I'm missing ?
> > > 
> > > 
> > > Thank you
> > > 
> > > [1]
> > > %if ! 0%{?rhel} >= 8
> > > echo "is not rhel >= 8"
> > > %else
> > > echo "is rhel 8 or 9"
> > > %endif
> > > 
> > ___
> > 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
> > Do not reply to spam on the list, report it:  
> > https://pagure.io/fedora-infrastructure
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: search among all spec files

[Sérgio Basto]

On Tue, 2022-02-01 at 01:03 +0100, Germano Massullo wrote:
> Good day. I have to search gcc-toolset among all Fedora packages specs 
> files, in order to read some example of usage.
> Is that possible? For example cloning the whole git repository.
> 

also you got sourcegraph 
https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+file:.*%5C.spec%24+%5ELicense:+MIT&patternType=regexp&case=yes

reference:
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/J4I74HDXAX2UWCVEMGUAICEKCMLXW5B3/

--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ppc64le build failures in the mass rebuild

[Sérgio Basto]

On Mon, 2022-01-31 at 15:06 +, Mark E. Fuller wrote:
> My spec for cantera currently has an "excludearch" for ppc64le since
> the rawhide builds were failing - should I drop this allow for the
> releng tools to automatically find and rebuild it?

I'm not from releng team , I don't know if releng will do it or not, I
just suggest ...
But anyway, if you got a successful build, the script won't work ,
because just find packages that don't have any successful build since
the mass rebuild started, so in your case, you have to do yourself .

I suggest that you edit your spec and try a scratch build in koji just
on ppc64le arch with : 

fedpkg scratch-build --srpm --arch=ppc64le



> Thanks
> 
> 31 Jan 2022 16:47:07 Sérgio Basto :
> 
> > On Mon, 2022-01-31 at 13:36 +0100, Dan Horák wrote:
> > > On Mon, 31 Jan 2022 12:04:08 +
> > > Sérgio Basto  wrote:
> > > 
> > > > On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote:
> > > > > Hi,
> > > > > 
> > > > > as there are still a number of ppc64le build failures from
> > > > > the mass
> > > > > rebuild, please make the FTBFS bugs block the "PPCTracker" so
> > > > > we
> > > > > know
> > > > > about them.
> > > > > 
> > > > > Here is what we know so far
> > > > > - segfaulting ICE with "during RTL pass: final" or not being
> > > > > able
> > > > > to
> > > > > assemble the sources, those should be fixed in gcc-12.0.1-
> > > > > 0.3.fc36,
> > > > > so
> > > > > a rebuild should fix them
> > > > 
> > > > In resume, I think all failed builds , should be resubmitted
> > > > again.
> > > 
> > > it already happened in the 2nd run of the mass rebuild, I am
> > > mentioning
> > > it here mainly for completeness and in case someone will still
> > > hit it.
> > > 
> > 
> > yes I'm talking about a 3rd run , since is just resubmit the builds
> > that still failing , in https://pagure.io/releng we have the script
> > find_failures.py that can do that job ...
> > 
> > 
> > > 
> > > Dan
> > > 
> > > > 
> > > > 
> > > > > - issues with "__LDBL_REDIR1_DECL", they are caused by the
> > > > > bundled
> > > > > gnulib not being compatible with the installed glibc, a fix
> > > > > is to
> > > > > replace the bundled cdefs.h with more recent one
> > > > > (
> > > > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/cdefs.h;h=44d3826bca9f6f84f862acf1035408a587fac71d;hb=HEAD
> > > > > ),
> > > > > seen eg in lftp
> > > > > (https://bugzilla.redhat.com/show_bug.cgi?id=2045780)
> > > > > or dhcpd-pools
> > > > > (https://bugzilla.redhat.com/show_bug.cgi?id=2045310)
> > > > > 
> > > > > - various "long double" related issues, some might be fixed
> > > > > by
> > > > > building
> > > > > in proper order, but some will need further investigation, a
> > > > > corner
> > > > > case in libffi should be fixed in
> > > > > https://src.fedoraproject.org/rpms/libffi/pull-request/6
> > > > > 
> > > > > - various "vector" related issues/ICE, for example in cantera
> > > > > or
> > > > > mame
> > > > > 
> > > > > - libtool de-duplicating internal libs, when it shouldn't,
> > > > > like
> > > > > /usr/bin/ld: /usr/lib/gcc/ppc64le-redhat-
> > > > > linux/12/libgcc.a(float128-
> > > > > ifunc.o):
> > > > > (.data+0x0): undefined reference to
> > > > > `__parse_hwcap_and_convert_at_platform',
> > > > > this is a generic problem, a fix is proposed in
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2047389
> > > > > and workaround is
> > > > > https://src.fedoraproject.org/rpms/codeblocks/c/c8f36775a26f79d598e886a82460d1453871af20?branch=rawhide
> > > > > 
> > > > > - something else?
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Dan
> > > > >

Re: ppc64le build failures in the mass rebuild

[Sérgio Basto]

On Mon, 2022-01-31 at 13:36 +0100, Dan Horák wrote:
> On Mon, 31 Jan 2022 12:04:08 +
> Sérgio Basto  wrote:
> 
> > On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote:
> > > Hi,
> > > 
> > > as there are still a number of ppc64le build failures from the mass
> > > rebuild, please make the FTBFS bugs block the "PPCTracker" so we
> > > know
> > > about them.
> > > 
> > > Here is what we know so far
> > > - segfaulting ICE with "during RTL pass: final" or not being able
> > > to
> > > assemble the sources, those should be fixed in gcc-12.0.1-0.3.fc36,
> > > so
> > > a rebuild should fix them
> > 
> > In resume, I think all failed builds , should be resubmitted again.
> 
> it already happened in the 2nd run of the mass rebuild, I am mentioning
> it here mainly for completeness and in case someone will still hit it.
> 

yes I'm talking about a 3rd run , since is just resubmit the builds
that still failing , in https://pagure.io/releng we have the script
find_failures.py that can do that job ... 


> 
> Dan
> 
> > 
> > 
> > > - issues with "__LDBL_REDIR1_DECL", they are caused by the bundled
> > > gnulib not being compatible with the installed glibc, a fix is to
> > > replace the bundled cdefs.h with more recent one
> > > (
> > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/cdefs.h;h=44d3826bca9f6f84f862acf1035408a587fac71d;hb=HEAD
> > > ),
> > > seen eg in lftp
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=2045780)
> > > or dhcpd-pools
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=2045310)
> > > 
> > > - various "long double" related issues, some might be fixed by
> > > building
> > > in proper order, but some will need further investigation, a corner
> > > case in libffi should be fixed in
> > > https://src.fedoraproject.org/rpms/libffi/pull-request/6
> > > 
> > > - various "vector" related issues/ICE, for example in cantera or
> > > mame
> > > 
> > > - libtool de-duplicating internal libs, when it shouldn't, like
> > > /usr/bin/ld: /usr/lib/gcc/ppc64le-redhat-
> > > linux/12/libgcc.a(float128-
> > > ifunc.o):
> > > (.data+0x0): undefined reference to
> > > `__parse_hwcap_and_convert_at_platform',
> > > this is a generic problem, a fix is proposed in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2047389
> > > and workaround is
> > > https://src.fedoraproject.org/rpms/codeblocks/c/c8f36775a26f79d598e886a82460d1453871af20?branch=rawhide
> > > 
> > > - something else?
> > > 
> > > 
> > > Thanks,
> > > 
> > > 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
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> > 
> > -- 
> > Sérgio M. B.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ppc64le build failures in the mass rebuild

[Sérgio Basto]

On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote:
> Hi,
> 
> as there are still a number of ppc64le build failures from the mass
> rebuild, please make the FTBFS bugs block the "PPCTracker" so we know
> about them.
> 
> Here is what we know so far
> - segfaulting ICE with "during RTL pass: final" or not being able to
> assemble the sources, those should be fixed in gcc-12.0.1-0.3.fc36,
> so
> a rebuild should fix them

In resume, I think all failed builds , should be resubmitted again. 


> - issues with "__LDBL_REDIR1_DECL", they are caused by the bundled
> gnulib not being compatible with the installed glibc, a fix is to
> replace the bundled cdefs.h with more recent one
> (
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/cdefs.h;h=44d3826bca9f6f84f862acf1035408a587fac71d;hb=HEAD
> ),
> seen eg in lftp (https://bugzilla.redhat.com/show_bug.cgi?id=2045780)
> or dhcpd-pools (https://bugzilla.redhat.com/show_bug.cgi?id=2045310)
> 
> - various "long double" related issues, some might be fixed by
> building
> in proper order, but some will need further investigation, a corner
> case in libffi should be fixed in
> https://src.fedoraproject.org/rpms/libffi/pull-request/6
> 
> - various "vector" related issues/ICE, for example in cantera or mame
> 
> - libtool de-duplicating internal libs, when it shouldn't, like
> /usr/bin/ld: /usr/lib/gcc/ppc64le-redhat-linux/12/libgcc.a(float128-
> ifunc.o):
> (.data+0x0): undefined reference to
> `__parse_hwcap_and_convert_at_platform',
> this is a generic problem, a fix is proposed in
> https://bugzilla.redhat.com/show_bug.cgi?id=2047389
> and workaround is
> https://src.fedoraproject.org/rpms/codeblocks/c/c8f36775a26f79d598e886a82460d1453871af20?branch=rawhide
> 
> - something else?
> 
> 
> Thanks,
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: -D_FORTIFY_SOURCE not defined errors

[Sérgio Basto]

On Sat, 2022-01-29 at 09:56 +0100, Jakub Jelinek wrote:
> On Sat, Jan 29, 2022 at 04:03:06PM +1000, Bob Hepple wrote:
> > One of my packages, stable for a long time, is now getting exotic
> > errors in rawhide such as
> > 
> > -D_FORTIFY_SOURCE not defined
> > -D_GLIBCXX_ASSERTIONS not defined
> > 
> > Yesterday I saw (somewhere in here) that those errors are fixed in
> > the
> > latest annobin.
> > 
> > Should I just wait for that fix to land in koji? If so, how long?
> 
> It was fixed yesterday.
> Are you sure your builds were against
> gcc-12.0.1-0.3.fc36 annobin-10.51-2.fc36
> and not an older version of annobin?

But rawhide compose of last 2 days failed , so new annobin is not in
buildroot  and this problem will still happen on copr for example 

> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intent to retire w3c-markup-validator, perl-HTML-Tidy, tidyp

[Sérgio Basto]

On Tue, 2022-01-25 at 09:54 +, Paul Howarth wrote:
> Hello all,
> 
> I'm the Fedora maintainer of the perl-HTML-Tidy package and its
> underlying library, tidyp.
> 
> The upstream maintainer of these packages has now stopped work on
> tidyp, and has archived the upstream repository in a read-only state:
> https://github.com/petdance/tidyp
> 
> He has also stopped work on HTML-Tidy, and is working on HTML-Tidy5
> instead.
> 
> Since I no longer use this software myself, I'm intending to stop
> maintaining it in Fedora. The only package I can find in Fedora that
> depends on perl-HTML-Tidy is w3c-markup-validator; I have contacted
> Nathanael, the maintainer of w3c-markup-validator, and since he no
> longer uses that package, it would seem like the best thing to do
> would
> be to retire all three packages.
> 

perl(HTML::Tidy) is optional for w3c-markup-validator [1] I'd like
maintain w3c-markup-validator package in Fedora at least for sometime ,
I was looking for a tool like this for some time 


https://src.fedoraproject.org/rpms/w3c-markup-validator/blob/rawhide/f/w3c-markup-validator.spec#_33


> If any other packager has an interest in any of these packages, let
> us
> know and we can transfer ownership of them over to you. Otherwise,
> they'll be retired at the start of February, before Fedora 36 is
> branched.
> 
> Regards, Paul.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.1-0.3.fc36 now in rawhide

[Sérgio Basto]

On Thu, 2022-01-27 at 11:09 +0100, Jakub Jelinek wrote:
> On Thu, Jan 27, 2022 at 10:32:22AM +0100, Thomas Haller wrote:
> > On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> > > A new gcc with most importantly the https://gcc.gnu.org/PR104172
> > > bug (that caused a lot of ppc64le failures) fixed and various
> > > other
> > > fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
> > > for C++23 etc.) is now in rawhide.
> > > 
> > > Can rel-eng please retry all FTBS builds that failed on ppc64le?
> > 
> > it appears to me, that this breaks build of NetworkManager:
> >    https://koji.fedoraproject.org/koji/taskinfo?taskID=81998774
> > 
> > 
> >   checking if gcc supports flag -fno-strict-aliasing in envvar
> > CFLAGS... yes
> >   checking if gcc supports flag -flto -flto-partition=none in
> > envvar CFLAGS... no
> >   configure: error: Link Time Optimization -flto is not supported.
> >   error: Bad exit status from /var/tmp/rpm-tmp.FQqAFe (%build)
> 
> Apparently it was annobin (although it passed the test done during
> gcc.spec
> testing, apparently it was incompatible again).
> Florian has rebuilt it, so please just retry.


Maybe we should resubmit again all failed builds ... 

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.1-0.3.fc36 now in rawhide

[Sérgio Basto]

On Thu, 2022-01-27 at 00:46 +, Sérgio Basto wrote:
> On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > A new gcc with most importantly the https://gcc.gnu.org/PR104172
> > bug (that caused a lot of ppc64le failures) fixed and various other
> > fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
> > for C++23 etc.) is now in rawhide.
> > 
> 
> opencv [1] seems is fixed, I'm testing an scratch build only on ppc64le
> [2] 

the scratch build is here:

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


> 
> [1] 
> https://github.com/opencv/opencv/issues/21465
> 
> [2] 
> `fedpkg scratch-build --arch=ppc64le`
> 
> 
> > Can rel-eng please retry all FTBS builds that failed on ppc64le?
> > 
> > Thanks
> > 
> > Jakub
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.1-0.3.fc36 now in rawhide

[Sérgio Basto]

On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> Hi!
> 
> A new gcc with most importantly the https://gcc.gnu.org/PR104172
> bug (that caused a lot of ppc64le failures) fixed and various other
> fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
> for C++23 etc.) is now in rawhide.
> 

opencv [1] seems is fixed, I'm testing an scratch build only on ppc64le
[2] 

[1] 
https://github.com/opencv/opencv/issues/21465

[2] 
`fedpkg scratch-build --arch=ppc64le`


> Can rel-eng please retry all FTBS builds that failed on ppc64le?
> 
> Thanks
> 
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

about abidiff Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Sun, 2022-01-23 at 10:56 +0100, Vitaly Zaitsev via devel wrote:
> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
> 
> abidiff automatic test found no ABI changes between 8.0 and 8.1.

Since early 2021 at least
https://sourceware.org/bugzilla/show_bug.cgi?id=27275 I notice
fedabipkgdiff doesn't produce any results . 

But by reactions of the developers seems that all was working without
problems, yesterday finally found the problem
https://bugzilla.redhat.com/show_bug.cgi?id=1811602#c3

also wiki page is outdate ... 
https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abipkgdiff#Comparing_RPMs


Best regards, 
> -- 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Mon, 2022-01-17 at 14:36 +, Sérgio Basto wrote:
> On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote:
> > On 17/01/2022 15:00, Ben Beasley wrote:
> > > dependency “json”: https://github.com/nlohmann/json/issues/3138
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2041187
> > 
> 
> Rawhide compose doomed again [1] :( , I still haven't the results of 
> koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc-
> 12.0.0-0.4 [2] 
> 


Build with gcc-12.0.0-0.5 not fixed the error related with altivec 

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



> 
> [2]
> https://koschei.fedoraproject.org/package/opencv?collection=f36
> 
> [1]
> https://kojipkgs.fedoraproject.org/compose/rawhide/
> 
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote:
> On 17/01/2022 15:00, Ben Beasley wrote:
> > dependency “json”: https://github.com/nlohmann/json/issues/3138
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2041187
> 

Rawhide compose doomed again [1] :( , I still haven't the results of 
koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc-
12.0.0-0.4 [2] 


[2]
https://koschei.fedoraproject.org/package/opencv?collection=f36

[1]
https://kojipkgs.fedoraproject.org/compose/rawhide/


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Non-responsive maintainer - melmorabity

[Sérgio Basto]

Add him in CC 

2021-12-20 is not long ago (IMO) 


On Tue, 2022-01-11 at 13:43 +, Andrew Bauer wrote:
> In accordance with the Fedora non-responsive maintainer policy, I am
> attempting to contact
> Mohamed ElMorabity a.k.a. melmorabity.
> 
> Does anyone know how to contact this package maintainer?
> 
> This is in reference to these open bugs with perl-XML-TreeBuilder:
> https://bugzilla.redhat.com/show_bug.cgi?id=1466166
> https://bugzilla.redhat.com/show_bug.cgi?id=1756170
> https://bugzilla.redhat.com/show_bug.cgi?id=2030421
> 
> Non-responsive bug has been filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=2039316
> 
> Output from fedora-active-user:
> 
> Last login in FAS:
>    melmorabity 2021-04-22
> 
> Last action on koji:
>    Mon, 13 Dec 2021 tag_package_owners entry created by bodhi [still
> active]
> 
> Last package update on bodhi:
>    2021-12-20 02:11:34 on package nicotine+-3.2.0-1.fc34
> 
> Last actions performed according to fedmsg:
> 
>   - upstream-release-monitoring commented on RHBZ#2037504 'cppmyth-
> 2.14.4 is available' on 2022-01-10 04:41:22
>   - upstream-release-monitoring commented on RHBZ#2037504 'cppmyth-
> 2.14.4 is available' on 2022-01-10 04:41:22
>   - upstream-release-monitoring updated 'short_desc' on RHBZ#2037504
> 'cppmyth-2.14.4 is available' on 2022-01-10 04:41:22
>   - upstream-release-monitoring commented on RHBZ#2037504 'cppmyth-
> 2.14.3 is available' on 2022-01-09 01:58:27
>   - upstream-release-monitoring commented on RHBZ#2037504 'cppmyth-
> 2.14.3 is available' on 2022-01-09 01:49:56
>   - upstream-release-monitoring updated 'short_desc' on RHBZ#2037504
> 'cppmyth-2.14.3 is available' on 2022-01-09 01:49:56
>   - upstream-release-monitoring updated nothing? (likely bugzilla
> sent us a buggy message) on RHBZ#2037504 'cppmyth-2.14.3 is
> available' on 2022-01-09 01:49:56
>   - upstream-release-monitoring commented on RHBZ#2037504 'cppmyth-
> 2.14.3 is available' on 2022-01-09 01:49:56
>   - oz...@protonmail.com commented on RHBZ#2015039 '[abrt] gnome-
> tweaks: set_active(): tweak...' on 2022-01-07 07:05:37
>   - oz...@protonmail.com updated 'cc' on RHBZ#2015039 '[abrt] gnome-
> tweaks: set_active(): tweak...' on 2022-01-07 07:05:37
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump of libre2

[Sérgio Basto]

On Mon, 2022-01-10 at 13:00 +0100, Robert-André Mauchin wrote:
> On 1/9/22 03:29, Kevin Fenzi wrote:
> > On Sat, Jan 08, 2022 at 11:56:04PM +0900, Mamoru TASAKA wrote:
> > > Miro Hrončok wrote on 2022/01/08 20:05:
> > > > On 08. 01. 22 11:39, Miro Hrončok wrote:
> > > > > The re2 package was updated today in Rawhide and bumped
> > > > > soname from libre2.so.0a to libre2.so.9.
> > > > > 
> > > > > https://src.fedoraproject.org/rpms/re2/c/dafa514
> > > > > 
> > > > > Seven packages are broken:
> > > > > 
> > > > > dnsdist: https://bugzilla.redhat.com/show_bug.cgi?id=2038544
> > > > fails to build, not sure if re2 related
> > > 
> > > There is at least a fault on new re2, filed:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2038572
> > > 
> > > > > frr: https://bugzilla.redhat.com/show_bug.cgi?id=2038545
> > > > depends on grpc
> > > > 
> > > > > grpc: https://bugzilla.redhat.com/show_bug.cgi?id=2038546
> > > > fails to build due to another unrelated fails to install bug
> > > > 
> > > > > qt5-qtwebengine:
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2038551
> > > > fails to build, re2 related
> > 
> > Just FYI, the qt5-qtwebengine breakage is breaking rawhide composes
> > starting today. ;(
> > 
> > kevin
> > 
> 
> The qt5-qtwebengine does not rebuild with the new libre2. The re2 in
> the 
> chromium source code is from 2019-10-15, but we copy headers file
> from 
> the system version:
> 
> %if 0%{?use_system_re2}
> # http://bugzilla.redhat.com/1337585
> # can't just delete, but we'll overwrite with system headers to be on
> the safe side
> cp -bv /usr/include/re2/*.h
> src/3rdparty/chromium/third_party/re2/src/re2/
> %endif
> 
> so it breaks with the new version.
> 
> The qt5-qtwebengine build does not seem to detect system re2 too:
> 
> Running configuration tests...
> ...
> Checking for re2... no
> ...
> Done running configuration tests.


please untag the builds and do a side tag ? that the way we do the
things now 



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)

[Sérgio Basto]

a big BTW when /etc/init.d/network will be removed or migrate to
systemd scripts ? 

rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
%{name}\n"

packge = initscripts-10.09-1.fc34.src.rpm
sub-package = network-scripts



On Wed, 2022-01-05 at 09:05 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
> 
> == Summary ==
> Do not not include NetworkManager support for legacy network
> configuration files by in new installations.
> 
> == Owner ==
> * Name: [[User:Lkundrak| Lubomir Rintel]]
> * Email: 
> 
> * Name: Ana Cabral
> * Email: 
> 
> * Name: [[User:Thaller| Thomas Haller]]
> * Email: 
> 
> == Detailed Description ==
> Long ago, network was configured using "network" service.
> It was essentially a set of shell scripts, that sourced snippets of
> configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> files").
> The ifcfg files compatible with the legacy network service were kept
> when NetworkManager was intruduced.
> 
> As the NetworkManager feature set was expanding beyond what the legacy
> network service could support,
> the ifcfg files written by NetworkManager could no longer be
> guarranteed to be compatible.
> NetworkManager eventually gained support for connection types
> completely unknown to the legacy network service
> and ended up using a more streamlined configuration file format for
> those, known as keyfile.
> 
> NetworkManager's use of various configuration files is, in fact,
> configurable and extensible with plugins.
> Prior to Fedora 33, NetworkManager by default was configured to enable
> both ifcfg files and keyfiles, with the former taking precedence when
> possible.
> The precedence changed in
> [
> https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> Fedora 33] to perfer keyfile.
> 
> The precedence has an effect when a network connection profile is
> created.
> Once the connection profile exists, NetworkManager is unable to
> convert the profile to a different configuration backend.
> This makes it necessary for NetworkManager to support the same feature
> set in all configuration backend.
> Given the complexities stemming from historical legacy of ifcfg files
> not being designed (or documented) in a
> particularly forward-looking way, this has been a huge and complex
> effort with all the downsides:
> The ifcfg support code is huge (130K lines, not counting the enormous
> test suite) and has constantly been a source of bugs.
> 
> == Benefit to Fedora ==
> This change removes a body of code that has a large cost in terms of
> bugs and maintenance at questionable benefit.
> 
> It slightly reduces the default installation size.
> 
> == Scope ==
> * Proposal owners: Split the ifcfg plugin into a subpackage package.
> Make sure the ifcfg plugin stays on upgrades. Provide a migration
> tool.
> 
> * Other developers: N/A
> 
> * Release engineering: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> 
> * Alignment with Objectives: N/A
> 
> == Upgrade/compatibility impact ==
> For the time being the ifcfg plugin is kept around, albeit in a
> sub-package that's not included in new installations.
> The appropriate RPM tags will ensure the sub-package with the ifcfg
> plugin will be installed on upgrades.
> A migration tool will be provided for users who'd like to remove the
> legacy package from their systems after upgrade.
> 
> == How To Test ==
> N/A.
> The keyfiles are used by default in Fedora 33 already, so any problem
> with them would've already been spotted.
> 
> == User Experience ==
> Regular users will not notice anything.
> Users of old installations with ifcfg files will get the new
> sub-package on upgrade.
> New systems will default to use keyfiles, which is not something
> regulars user would notice.
> 
> System integrators and administrators might use tools that drop in
> ifcfg files during automated installations (e.g. via kickstart or a
> configration management tool).
> They will need to update their tools -- convert the ifcfg files to
> keyfiles or include the ifcfg sub-package.
> 
> == Dependencies ==
> N/A
> 
> == Contingency Plan ==
> * Contingency mechanism: If it turns out we can't drop support for
> ifcfg files by default, we can either fold the ifcfg sub-package back
> into the main NetworkManager package or make sure it is included in
> new installations (via comps change).
> * Contingency deadline: Any time.
> * Blocks release? No.
> 
> == Documentation ==
> We'll need to write the documentation for the migration tool.
> Perhaps also something the sysadmins wondering why their ifcfg files
> don't work anymore could find and refer to.
> 
> TODO: Update this once it's done.
> 
> == Release Notes ==
> We'll need to include a paragraph about this in the release notes.
> 
> TODO: Update this with the actual release note text.
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> __

Re: List of packages with problematic license

[Sérgio Basto]

On Sat, 2022-01-01 at 11:11 +0100, Miroslav Suchý wrote:
> I am processing results of license-validate audit, but it takes
> longer...
> So I am providing raw results of what I have. If you are maintainer one
> of these packages you may expect either BZ report or Pagure PR for your
> package in upcoming days/weeks.
> In the attachment you will find more details (albeit not super human
> friendly).
> The list likely contains lots of false positives. And it is missing
> packages I already reported.
> Miroslav
> 
> hibernate-jpa-2.0-api.spec 

Testing rpm-specs/hibernate-jpa-2.0-api.spec
No terminal defined for 'E' at line 1 col 2

 EPL and BSD

What is the problem with this one ? 


>  hibernate-jpa-2.1-api.spec 
>  hunspell-pt.spec 
>  iptables.spec 
>  ipxe.spec 
>  iucode-tool.spec 
>  jbosscache-support.spec 
>  jboss-jaxrs-2.0-api.spec 
>  jsmath-fonts.spec 
>  kdevelop-pg-qt.spec 
>  knot-resolver.spec 
>  knot.spec 
>  libprelude.spec 
>  librhsm.spec 
>  libva-intel-hybrid-driver.spec 
>  libvarlink.spec 
>  lttng-ust.spec 
>  lumina-desktop.spec 
>  lvm2.spec 
>  man-pages-l10n.spec 
>  Mayavi.spec 
>  midori.spec 
>  mingw-LibRaw.spec 
>  mingw-libunistring.spec 
>  mingw-python-certifi.spec 
>  mlir.spec 
>  mono.spec 
>  mono.spec 
>  mpdecimal.spec 
>  mxml.spec 
>  nodejs-tape.spec 
>  ogre.spec 
>  opencascade.spec 
>  openjfx.spec 
>  openjfx8.spec 
>  pacemaker.spec 
>  paho-c.spec 
>  passwdqc.spec 
>  pcs.spec 
>  perl-BSSolv.spec 
>  perl-Date-HolidayParser.spec 
>  perl-Exporter-Tidy.spec 
>  perl-PDF-API2.spec 
>  perl-PDF-Builder.spec 
>  perl-qooxdoo-compat.spec 
>  perl-Regexp-Pattern-DefHash.spec 
>  perl-Regexp-Pattern.spec 
>  perl-RPC-XML.spec 
>  perl.spec 
>  perl.spec 
>  perl-TermReadKey.spec 
>  perl-Test-Command-Simple.spec 
>  perl-Text-Aligner.spec 
>  php-manual-en.spec 
>  phpMyAdmin.spec 
>  pidgin-sipe.spec 
>  pidgin-sipe.spec 
>  pokerth.spec 
>  ProDy.spec 
>  proj.spec 
>  python-coverage.spec 
>  python-pathspec.spec 
>  python-pyface.spec 
>  python-pygit2.spec 
>  python-resolvelib.spec 
>  python-restfly.spec 
>  python-Traits.spec 
>  python-traitsui.spec 
>  python-userpath.spec 
>  qmmp.spec 
>  qt5-qtfeedback.spec 
>  rachota.spec 
>  rizin.spec 
>  rubygem-webrick.spec 
>  rust-ambient-authority.spec 
>  rust-base100.spec 
>  rust-cap-primitives.spec 
>  rust-cap-rand.spec 
>  rust-cap-std.spec 
>  rust-cranelift-bforest.spec 
>  rust-cranelift-codegen-meta.spec 
>  rust-cranelift-codegen-shared.spec 
>  rust-cranelift-codegen.spec 
>  rust-cranelift-entity.spec 
>  rust-cranelift-frontend.spec 
>  rust-cranelift-native.spec 
>  rust-cranelift-wasm.spec 
>  rust-file-per-thread-logger.spec 
>  rust-fs-set-times.spec 
>  rust-io-lifetimes.spec 
>  rust-posish.spec 
>  rust-rav1e.spec 
>  rust-regalloc.spec 
>  rust-target-lexicon.spec 
>  rust-tpm2-policy.spec 
>  rust-unsafe-io.spec 
>  rust-wasmparser.spec 
>  rust-wasmtime-cache.spec 
>  rust-wasmtime-environ.spec 
>  rust-wasmtime-fiber.spec 
>  rust-wasmtime-types.spec 
>  rust-wast.spec 
>  rust-wat.spec 
>  sblim-cim-client.spec 
>  sblim-cim-client2.spec 
>  sblim-cmpi-devel.spec 
>  sblim-cmpi-devel.spec 
>  sblim-cmpi-fsvol.spec 
>  sblim-cmpi-network.spec 
>  sblim-cmpi-nfsv3.spec 
>  sblim-cmpi-nfsv4.spec 
>  sblim-cmpi-params.spec 
>  sblim-cmpi-sysfs.spec 
>  sblim-cmpi-syslog.spec 
>  sblim-sfcCommon.spec 
>  sblim-smis-hba.spec 
>  sblim-testsuite.spec 
>  scantailor.spec 
>  singularity.spec 
>  smc-tools.spec 
>  spec-version-maven-plugin.spec 
>  star.spec 
>  strace.spec 
>  stun.spec 
>  subscription-manager.spec 
>  subscription-manager.spec 
>  sunpinyin.spec 
>  surgescript.spec 
>  surgescript.spec 
>  surgescript.spec 
>  sympa.spec 
>  tcmu-runner.spec 
>  texlive-base.spec 
>  texlive-base.spec 
>  texlive.spec 
>  texlive.spec 
>  texlive.spec 
>  texlive.spec 
>  texlive.spec 
>  texlive.spec 
>  tlog.spec 
>  uboot-tools.spec 
>  virtualbox-guest-additions.spec 
>  wwl.spec 
>  yakuake.spec 
>  ydotool.spec 
>  zfs-fuse.spec 
>  4diac-forte.spec
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedorap

orphaned some java packages : jakarta-saaj, jakarta-xml-ws , jmock

[Sérgio Basto]

Hi,
I just orphaned some java packages : 
- jakarta-saaj
- jakarta-xml-ws
- jmock 

Lack of time and nothing depend on it 

Happy new year ! 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: intend to orphan jctools

[Sérgio Basto]

jctoosl has been transferred to pwouters 


On Wed, 2021-12-29 at 21:14 -0500, Paul Wouters wrote:
> You can add me as comaintainer or assign the package to me. If any of
> the others affected reply as well, please add them too. More
> maintainers is better 😀
> 
> Paul
> 
> Sent using a virtual keyboard on a phone
> 
> > On Dec 29, 2021, at 20:22, Sérgio Basto  wrote:
> > 
> > JFYI (your redhat email failed)
> > 
> >  Forwarded Message 
> > From: Sérgio Basto 
> > To: Fedora devel 
> > Cc: java-devel , Paul Wouters
> > 
> > Subject: intend to orphan jctools
> > Date: Wed, 29 Dec 2021 22:53:53 +
> > 
> > Hi,
> > 
> > I'd like orphan jctools , because it is a FTBFS on rawhide (F36) 
> > The only direct dependency is log4j [1] if someone want take it,
> > let me
> > know , and I will transfer the ownership .
> > 
> > Thank you,  
> > 
> > 
> > [1] 
> > Depending on: jctools (4), status change: 2021-04-26 (35 weeks ago)
> > log4j (maintained by: pwouters)
> > log4j-2.15.0-1.fc36.src requires mvn(org.jctools:jctools-core) =
> > 3.3.0
> > 
> > jericho-html (maintained by: terjeros)
> > jericho-html-3.3-21.fc35.src requires log4j = 2.15.0-1.fc36
> > 
> > jglobus (maintained by: ellert)
> > jglobus-2.1.0-24.fc36.src requires mvn(log4j:log4j) = 2.15.0
> > jglobus-ssl-proxies-2.1.0-24.fc36.noarch requires mvn(log4j:log4j)
> > =
> > 2.15.0
> > 
> > ditaa (maintained by: terjeros)
> > ditaa-0.10-14.fc35.noarch requires jericho-html = 3.3-21.fc35
> > ditaa-0.10-14.fc35.src requires jericho-html = 3.3-21.fc35
> > 
> > Affected (co)maintainers
> > ellert: jctools
> > pwouters: jctools
> > sergiomb: jctools
> > terjeros: jctools
> > 
> > Depending packages (rawhide) (4): ditaa jericho-html jglobus log4j
> > -- 
> > Sérgio M. B.
> > 
> > -- 
> > Sérgio M. B.

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Koji notifications arriving days late

[Sérgio Basto]

On Fri, 2021-12-31 at 12:19 +0100, Fabio Valentini wrote:
> Yup, my IRC notifications are often delayed by days, as well, making
> them ... very much less useful.


I second this 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Sérgio Basto]

On Wed, 2021-12-29 at 12:57 -0500, Neal Gompa wrote:
> On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer
>  wrote:
> > 
> > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote:
> > > On 29/12/2021 16:01, Ben Cotton wrote:
> > > > Currently, the RPM databases is located in `/var`. Let's move it
> > > > to
> > > > `/usr`. The move is already under way in rpm-ostree-based
> > > > installations, and in (open)SUSE.
> > > 
> > > It will break FHS compatibility. /usr must contain read-only data.
> > 
> > 
> > If /usr really is read-only, then it probably doesn't matter where
> > the
> > rpmdb is, since packages can't be installed (generally).
> > 
> > Moreover, for systems where /usr is read-only and/or shared
> > (especially
> > stateless systems), having the rpmdb on /usr seems like the most
> > rational place for it, if one expects to be able to use rpm to query
> > the
> > package list.  Otherwise, there is an implicit coupling of /usr and
> > /var/lib/rpmdb that requires two mounts rather than one.
> 
> Bingo. It's generally accepted that the RPM database changes when the
> system state changes. And if the system state is not allowed to
> change, the rpmdb should not either. The bigger problem is that having
> the RPM database in /var makes it much harder to correctly implement a
> boot-to-snapshot scheme for Fedora Linux that reasonably maintains
> system state properly once /var is carved out. 

you just need change to change the default --dbpath of rpm [1] , i.e, I
suggest instead change default location of rpm , change the dbpath
configuration for the atomic images, is just one idea . 

[1]
man rpm 
--dbpath DIRECTORY
Use the database in DIRECTORY rather than the default path /var/lib/rpm


> The reason that /var
> *isn't* carved out by default with our Btrfs configuration is because
> of the RPM database. Once the RPM database is moved, it becomes
> possible to split /var into its own subvolume and make it trivial to
> configure a full boot-to-snapshot system leveraging the technologies
> we have available to us.
> 
> 
> 
> -- 
> 真実はいつも一つ！/ 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

intend to orphan jctools

[Sérgio Basto]

Hi,

I'd like orphan jctools , because it is a FTBFS on rawhide (F36) 
The only direct dependency is log4j [1] if someone want take it, let me
know , and I will transfer the ownership .

Thank you,  


[1] 
Depending on: jctools (4), status change: 2021-04-26 (35 weeks ago)
log4j (maintained by: pwouters)
log4j-2.15.0-1.fc36.src requires mvn(org.jctools:jctools-core) = 3.3.0

jericho-html (maintained by: terjeros)
jericho-html-3.3-21.fc35.src requires log4j = 2.15.0-1.fc36

jglobus (maintained by: ellert)
jglobus-2.1.0-24.fc36.src requires mvn(log4j:log4j) = 2.15.0
jglobus-ssl-proxies-2.1.0-24.fc36.noarch requires mvn(log4j:log4j) =
2.15.0

ditaa (maintained by: terjeros)
ditaa-0.10-14.fc35.noarch requires jericho-html = 3.3-21.fc35
ditaa-0.10-14.fc35.src requires jericho-html = 3.3-21.fc35

Affected (co)maintainers
ellert: jctools
pwouters: jctools
sergiomb: jctools
terjeros: jctools

Depending packages (rawhide) (4): ditaa jericho-html jglobus log4j
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: HEADS UP: Update to tesseract-5.0.0 in rawhide

[Sérgio Basto]

On Sun, 2021-12-19 at 21:49 +0900, Mamoru TASAKA wrote:
> Sandro Mani wrote on 2021/12/15 20:15:
> > 
> > On 15.12.21 11:11, Michael J Gruber wrote:
> > > Are you planning to bring these to F35, as well?
> > > Tesseract-5.0.0  appears to be mostly a bugfix release along with
> > > some other improvements, so I dunno (and haven't tested so far -
> > > the heads up was a few hours before the push).
> > 
> > Since it brings along a soname bump, I wasn't planning on building
> > it for stable releases.
> > 
> > Sandro
> 
> Note that with tesseract-5.0.0-3.fc36 "Switch back to autotools"
> changes,
> soname changed from "libtesseract.so.5.0.0()(64bit)" (in -1.fc36) to
> "libtesseract.so.5()(64bit)" .
> As the dependent packages were built with -1.fc36, now all dependent
> packages again need rebuilding
> (especially currently opencv-contrib-0:4.5.4-7.fc36.x86_64 is broken
> for now).
> 
> I was going to rebuild at least opencv, however currently s390x
> builder seems unhealthy...
> https://pagure.io/fedora-infrastructure/issue/10431
> 

OK thank you ( by rebuild opencv ) 

> Regards,
> Mamoru
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: xorg-x11-server maintenance

[Sérgio Basto]

*** It is multiple versions behind upstream (Fedora has 1.20.11,
upstream has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1,
21.1.2), and has open CVE issues attached to it. *** 



On Fri, 2021-12-17 at 12:21 +0100, Fabio Valentini wrote:
> Hi all,
> 
> With the recent updates to use a standalone xwayland package, the
> "classic" xorg-x11-server package seems to have fallen into disrepair.
> It is multiple versions behind upstream (Fedora has 1.20.11, upstream
> has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and
> has open CVE issues attached to it.
> 
> A BugZilla query for the xorg-x11-server package reveals a worrying
> state of things, with bugs not being touched in ages, and the
> xgl-maint account that is the "main admin" and bugzilla assignee for
> multiple xorg-related packages has a *deactivated BugZilla* account,
> so NEEDINFO requests etc. don't work (no idea what else doesn't work,
> I suppose maintainers won't get bug emails either, if their bugzilla
> account doesn't work ...). Does it count as "non-responsive
> maintainer", if the maintainer doesn't have an active BugZilla
> account? :)
> 
> I know that Wayland is the default on many Fedora Editions / Spins,
> but some of us plebs still rely on X11 / X.org sessions and it would
> be great to have the X server package updated. For a
> security-sensitive component like the X server, this is a worrying
> state of things.
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: wxGTK-devel vs wxGTK3-devel

[Sérgio Basto]

On Mon, 2021-12-13 at 08:53 -0500, Steven A. Falco wrote:
> On 12/12/21 06:21 PM, Scott Talbert wrote:
> > On Sun, 12 Dec 2021, Steven A. Falco wrote:
> > 
> > > I also noticed that python3-wxpython4 appears to require the 3.0
> > > branch, so that might be what is causing both 3.0 and 3.1 of wxGTK
> > > to be dragged in:
> > > 
> > > $ rpm -q --requires python3-wxpython4
> > > ...
> > > libwx_baseu-3.0.so.0()(64bit)
> > > ...
> > > 
> > > Is there a version of python3-wxpython4 that uses 3.1?  I really
> > > don't want both wxGTK versions in the build.
> > 
> > Yes, there is.  However, the latest version bundles its own non-
> > release copy of wxWidgets, and I don't believe it can be (easily)
> > built unbundled with the current release of wxWidgets 3.1.  So that's
> > why I have been holding off packaging it.  That, plus the 3.1.x
> > variant of wxWidgets is a development release and not API/ABI
> > stable.  Perhaps it's worth reconsidering if there's a new release of
> > wxPython that can use the latest released wxWidgets 3.1.x.
> 
> Thanks very much for the reply, Scott.
> 
> I'm not sure how critical it is to KiCad to make the switch, but I'll
> ask.  I believe that the KiCad Mac, Windows, and Flatpack builds have
> already made the switch, but I don't know if the KiCad team make their
> own builds of wxWidgets / wxpython.
> 
> Do you have a feel for when the 3.1 branch might stabilize enough to
> create a Fedora package?

BTW from this thread
https://sourceforge.net/p/dvdstyler/discussion/318795/thread/b40e1d871f/#84aa

wxWidgets 3.1 isn't available in many distributions (debian, Ubuntu,
archlinux, gentoo) and will never be packaged because 3.1 is a
development version...

https://trac.wxwidgets.org/wiki/Roadmap 

Best regards, 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​​

[Sérgio Basto]

On Mon, 2021-12-06 at 11:17 +, Mat Booth wrote:
> On Mon, 6 Dec 2021 at 10:43, Richard W.M. Jones 
> wrote:
> > 
> > On Mon, Dec 06, 2021 at 11:21:34AM +0100, Miro Hrončok wrote:
> > > Full report available at:
> > > https://churchyard.fedorapeople.org/orphans-2021-12-06.txt
> > > grep it for your FAS username and follow the dependency chain.
> > 
> > Could we get rid of the limit
> > 
> >   "Too many dependencies for wsdl4j, not all listed here"
> > 
> > in the long reports?  I don't really care how big that text file is
> > in
> > my browser.
> > 
> > > For human readable dependency chains,
> > > see https://packager-dashboard.fedoraproject.org/
> > > For all orphaned packages,
> > > see https://packager-dashboard.fedoraproject.org/orphan
> > 
> > This is nicer, not sure if I've seen this before.
> > 
> > Looks like the main breakage is:
> > 
> >   mingw-nsis -> scons -> fop -> tomcat -> wsdl4j
> > 
> > That gets increasingly weird.  NSIS is an installer builder for
> > Windows (fine), scons is a Python-based build system (also fine),
> > fop is a documentation formatting tool, tomcat is an application
> > server (!)
> > 
> > So I wonder why a Python-based build system relies on a Java-based
> > application server.
> > 
> 
> Well, for whatever reason, upstream fop contains a servlet
> implementation (which requires an app server) but we don't even build
> or ship this servlet in our fop package.
> 
> I removed an unnecessary BR on 'servlet' from the fop package:
> https://src.fedoraproject.org/rpms/fop/c/fba0361894999fbf17c8672e96d4dc95cc06314f?branch=rawhide
> 
> Does that add more sanity to the dep chain?

from https://churchyard.fedorapeople.org/orphans.txt [1] now seems just
tomcat needs directly wsdl4j 

[1]
Depending on: wsdl4j (10), status change: 2021-12-02 (0 weeks ago)
tomcat (maintained by: coolsvap, csutherl, gzaronikas, huwang,
van)
tomcat-1:9.0.55-1.fc36.src requires wsdl4j = 1.6.3-21.fc35




-- 
> Mat Booth
> http://fedoraproject.org/get-fedora
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Sérgio Basto]

On Mon, 2021-12-06 at 12:12 -0500, Matthew Miller wrote:
> On Mon, Dec 06, 2021 at 11:59:05AM +0000, Sérgio Basto wrote:
> > Correct me, if I'm wrong, people to avoid put password in every
> > sudo
> > command, modify sudo to not ask password .  And this behavior is a
> > big
> > hole of security , if user is compromised, attacker will have root
> > access for free. 
> 
> I imagine some people do that, but it's certainly not the default.

well I'm asking if is not a common behavior ? 

> Users could also configure their systems to allow an empty root
> password.
> They also shouldn't do that.
> 
> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Sérgio Basto]

On Wed, 2021-12-01 at 21:40 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Dec 01, 2021 at 09:29:43AM -0600, Brandon Nielsen wrote:
> > On 11/29/21 1:33 PM, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda
> > > 
> > > = Users are administrators by default in the installer GUI =
> > > 
> > > == Summary ==
> > > 
> > > The Anaconda installer GUI will have the administrative rights
> > > checkbox on the User screen ticked by default.
> > > 
> > > == Owner ==
> > > 
> > > * Name: [[User:Vladimirslavik| Vladimir Slavik]]
> > > * Email: vsla...@redhat.com
> > > 
> > > 
> > > == Detailed Description ==
> > > 
> > > Currently, the Anaconda installer GUI presents an unticked
> > > checkbox
> > > "Make this user administrator" on the user setup screen by
> > > default.
> > > This means users have to discover the control, understand its
> > > meaning,
> > > and consciously decide to change the value from the default one.
> > > 
> > 
> > [Snip]
> > 
> > I find this wording confusing, and I've been using Linux for at
> > least 15
> > years now. I think if we're making changes to reduce user confusion
> > we may
> > want to change the wording as well?
> > 
> > Perhaps a better wording would be "Grant user administrator
> > privileges
> > (allow sudo)"? Something to make it clear the resulting user isn't
> > root, but
> > can act as root.

Correct me, if I'm wrong, people to avoid put password in every sudo
command, modify sudo to not ask password .  And this behavior is a big
hole of security , if user is compromised, attacker will have root
access for free. 




> +1. The explanation can be even longer: maybe "(e.g. allow sudo as
> root,
> access to all logs, and other administrative actions)". If you're
> finding
> the existing wording unclear, many other people are most likely too.
> 
> Zbyszek
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​​

[Sérgio Basto]

On Mon, 2021-12-06 at 11:17 +, Mat Booth wrote:
> On Mon, 6 Dec 2021 at 10:43, Richard W.M. Jones 
> wrote:
> > 
> > On Mon, Dec 06, 2021 at 11:21:34AM +0100, Miro Hrončok wrote:
> > > Full report available at:
> > > https://churchyard.fedorapeople.org/orphans-2021-12-06.txt
> > > grep it for your FAS username and follow the dependency chain.
> > 
> > Could we get rid of the limit
> > 
> >   "Too many dependencies for wsdl4j, not all listed here"
> > 
> > in the long reports?  I don't really care how big that text file is
> > in
> > my browser.
> > 
> > > For human readable dependency chains,
> > > see https://packager-dashboard.fedoraproject.org/
> > > For all orphaned packages,
> > > see https://packager-dashboard.fedoraproject.org/orphan
> > 
> > This is nicer, not sure if I've seen this before.
> > 
> > Looks like the main breakage is:
> > 
> >   mingw-nsis -> scons -> fop -> tomcat -> wsdl4j
> > 
> > That gets increasingly weird.  NSIS is an installer builder for
> > Windows (fine), scons is a Python-based build system (also fine),
> > fop is a documentation formatting tool, tomcat is an application
> > server (!)
> > 
> > So I wonder why a Python-based build system relies on a Java-based
> > application server.
> > 
> 
> Well, for whatever reason, upstream fop contains a servlet
> implementation (which requires an app server) but we don't even build
> or ship this servlet in our fop package.
> 
> I removed an unnecessary BR on 'servlet' from the fop package:
> https://src.fedoraproject.org/rpms/fop/c/fba0361894999fbf17c8672e96d4dc95cc06314f?branch=rawhide
> 
> Does that add more sanity to the dep chain?

Since is a new package we need to wait for a new "Fedora rawhide
compose" , we got an email notification  on devel mailing list with
subject: Fedora rawhide compose report: mmdd.n.0 changes

after that, we can check
https://churchyard.fedorapeople.org/orphans.txt 
the first line have the date of the report, (timezone is CET (central
European time))

Best regards 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: jpegxl soname bump

[Sérgio Basto]

On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote:
> F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did
> the buildroot go through?
> (This conflicts with heif from rpmfusion, which I can't complain
> about here, of course.)

yes , buildroot go through , rpmfusion packages are fixed just need to
be published in repos 


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Sérgio Basto]

On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> On 12/2/21 15:08, Sérgio Basto wrote:
> > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > or
> > /lib/ld-2.33.so ?
> 

rephrasing my question : 

 What is the difference of /usr/bin/ld.so  for /lib64/ld-2.33.so or
/lib/ld-2.33.so ? 





> The lib64 one is 64-bit and the lib one is 32-bit.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Sérgio Basto]

On Thu, 2021-12-02 at 19:38 +0100, Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.  Today, ld.so
> can
> be used to activate preloading, for example.  Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocesses—something is that exactly what is needed.
> There is also some useful diagnostic output in --help,
> --list-diagnostics.
> 
> Having ld.so as a real command (instead of just a manual page) makes
> the
> name architecture-agnostic.  This discourages from hard-coding
> non-portable paths such as /lib64/ld-linux-x86-64.so.2 in scripts that
> require specific functionality offered by such an explicit loader
> invocation.

I didn't understood . What is the difference for /lib64/ld-2.33.so or
/lib/ld-2.33.so ? 


> Do you see a problem with installing /usr/bin/ld.so?
> 
> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
> 
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Sérgio Basto]

On Wed, 2021-12-01 at 14:39 +0100, Lennart Poettering wrote:
> On Di, 30.11.21 15:57, Adam Williamson (adamw...@fedoraproject.org)
> wrote:
> 
> > On Tue, 2021-11-30 at 22:39 +0000, Sérgio Basto wrote:
> > > On Tue, 2021-11-30 at 16:03 -0500, Matthew Miller wrote:
> > > > On Tue, Nov 30, 2021 at 11:13:19AM +, Sérgio Basto wrote:
> > > > > I don't use sudo , and I'm against the use of sudo  , Fedora
> > > > > tradition
> > > > > do things as root .
> > > > 
> > > > I hope we don't! Doing things with least required privilege is
> > > > an
> > > > important
> > > > security principle, one which was actually pioneered here with
> > > > the
> > > > usermode/consolehelper tools and then policykit and dbus
> > > > helpers for
> > > > GUI
> > > > applications. And we've been putting people in `wheel` by
> > > > default and
> > > > configuring sudo in the corresponding way since... F15, I
> > > > think.
> > > 
> > > yes , I mean be administrator with sudo (more than like in
> > > Debian, is
> > > like in Ubuntu) and do commands like `sudo dnf` I guess  .
> > > As subject says "Users are administrators" and use sudo to
> > > execute all
> > > kind of administration, I prefer do `su -` and execute the
> > > commands,
> > > that what I meant by "I don't use sudo" .
> > 
> > You know you can just do "sudo su" if you prefer that style, right?
> 
> So you transition to root one way, and then transition again to root
> from there? What's the point of that? We must go deeper?
> 
> "sudo -s" is what you are looking for: one transition only, and you
> get a shell.

I usually use "sudo -i" 


> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Sérgio Basto]

On Tue, 2021-11-30 at 16:03 -0500, Matthew Miller wrote:
> On Tue, Nov 30, 2021 at 11:13:19AM +0000, Sérgio Basto wrote:
> > I don't use sudo , and I'm against the use of sudo  , Fedora
> > tradition
> > do things as root .
> 
> I hope we don't! Doing things with least required privilege is an
> important
> security principle, one which was actually pioneered here with the
> usermode/consolehelper tools and then policykit and dbus helpers for
> GUI
> applications. And we've been putting people in `wheel` by default and
> configuring sudo in the corresponding way since... F15, I think.

yes , I mean be administrator with sudo (more than like in Debian, is
like in Ubuntu) and do commands like `sudo dnf` I guess  .
As subject says "Users are administrators" and use sudo to execute all
kind of administration, I prefer do `su -` and execute the commands,
that what I meant by "I don't use sudo" .


> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Sérgio Basto]

I don't use sudo , and I'm against the use of sudo  , Fedora tradition
do things as root .


On Mon, 2021-11-29 at 14:33 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda
> 
> = Users are administrators by default in the installer GUI =
> 
> == Summary ==
> 
> The Anaconda installer GUI will have the administrative rights
> checkbox on the User screen ticked by default.
> 
> == Owner ==
> 
> * Name: [[User:Vladimirslavik| Vladimir Slavik]]
> * Email: vsla...@redhat.com
> 
> 
> == Detailed Description ==
> 
> Currently, the Anaconda installer GUI presents an unticked checkbox
> "Make this user administrator" on the user setup screen by default.
> This means users have to discover the control, understand its
> meaning,
> and consciously decide to change the value from the default one.
> 
> However, computer usage by individuals is heavily skewed towards
> single user machines where the (sole) user has administrative powers
> over the machine by invoking `sudo`. This has been always reflected
> by
> the design of the screen, which allows only a single user to be
> created. The GNOME first time setup also creates a single user - and
> makes them an administrator without asking.
> 
> The proposed change merely changes the default GUI state to be in
> line
> with this expectation.
> 
> Further, this change of defaults complements the default for root
> account. The redesign of root setup screen in Fedora 35 makes it
> clear
> that root should be left locked. This change makes it clear that the
> user should be the administrator. Together, these defaults will let
> the user satisfy all user account options by filling in nothing more
> than the user name and the password (twice to confirm).
> 
> 
> == Benefit to Fedora ==
> 
> One less footgun in the installer for entry-level users. They will be
> able to rely on defaults and achieve the expected outcome.
> 
> == Scope ==
> 
> * Proposal owners: Isolated change - adjust Anaconda code to do so as
> suggested here. Low effort.
> * Other developers: No changes needed.
> * Release engineering: Different defaults ''could'' impact installer
> testing. [https://pagure.io/releng/issues #Releng issue number]
> * Policies and guidelines: N/A
> * Trademark approval: N/A
> * Alignment with Objectives: None.
> 
> == Upgrade/compatibility impact ==
> 
> No impact. Installation implies teardown of previous system,
> including users.
> 
> == How To Test ==
> 
> Start Anaconda installer for the Server variant, open the user setup
> screen, "Make this user administrator" is checked = pass.
> 
> Should be variant / spin / hardware agnostic, with the caveat that
> the
> presence of user screen is configurable, so in many cases the screen
> is not reachable.
> 
> Kickstart installs are not affected.
> 
> == User Experience ==
> 
> Users installing Fedora will no longer be forced to spend time
> deciding how to arrange the administrative powers (they, root, both?)
> and configuring that. They will be able to fill in user name and
> password and the default configuration will be valid. They can give
> in
> to the power of defaults.
> 
> For users that want to configure the system differently from the
> majority use case, the controls to do so are still as they were, only
> the defaults are different.
> 
> For those installing Fedora manually often, muscle memory for user
> screen will break, as the checkbox will no longer have to be toggled.
> 
> == Dependencies ==
> 
> None.
> 
> == Contingency Plan ==
> 
> Any Fedora QA and OpenQA changes reflecting this will have to be
> reverted. Other than that, there is no technical or process
> requirement for this change, so no impact. The change does not happen
> and previous defaults remain.
> 
> * Contingency mechanism: N/A
> * Contingency deadline: N/A
> * Blocks release? No
> 
> == Documentation ==
> 
> * https://github.com/rhinstaller/anaconda/pull/3719
> 
> == Release Notes ==
> 
> In the User spoke, the "Make this user administrator" checkbox is now
> checked by default. This improves installation experience for users
> who do not know and need to rely on the default values to guide them.
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedor

Re: How I test RPM Conditionals ? in shell command line

[Sérgio Basto]

On Mon, 2021-11-29 at 15:08 +0100, Vitaly Zaitsev via devel wrote:
> On 29/11/2021 14:57, Jun Aruga wrote:
> > Did you find a better alternative syntax?
> 
> Now I'm using the following:
> 
> %global enable_foo 1
> 
> %if %{enable_foo}
> ...
> %endif


I use %bcond , with %bcond we can manipulate mock builds with --with ou
--without .
In my opinion the most confuse of %bcond is not have %without tag . I
think that is address here : 
https://github.com/rpm-software-management/rpm/pull/1520

Thank you, 
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How I test RPM Conditionals ? in shell command line

[Sérgio Basto]

yes it works for me thank you 

On Mon, 2021-11-29 at 13:25 +, Artur Frenszek-Iwicki wrote:
> Not sure if there's a way to test a conditional by itself, but if
> it's somewhere in a spec file,
> you can use "rpmspec --parse $FILE" to see what the spec looks like
> after it's parsed
> and all the conditionals have been evaluated.
> 
> A.FI.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How I test RPM Conditionals ? in shell command line

[Sérgio Basto]

Sorry , I want to test RPM Conditionals generally like 

%if !0%{?fedora} < 22
echo yes
%endif

%if ! 0%{?rhel} < 8
echo yes
%endif

%if !0%{?fedora}%{?rhel} || 0%{?fedora} >= 15 || 0%{?rhel} >= 7
echo yes
%endif 




On Mon, 2021-11-29 at 14:22 +0100, Jun Aruga wrote:
> You can use `%bcond_with foo` (foo is not set as "false") or
> `%bcond_without foo` (foo is set as "true") syntax.
> 
> ```
> %bcond_without foo # foo is set as true
> 
> %if %{with foo}
>   echo 1
> %else
>   echo 0
> %endif
> ```
> 
> Then run `mock --with foo *.rpm` or `mock --without foo *.rpm` for the
> SRPM file.
> 
> Jun
> 
> An example using the %bcond macros.
> https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm.spec
> 
> On Mon, Nov 29, 2021 at 2:03 PM Sérgio Basto  wrote:
> > 
> > Hi,
> > 
> > How I can check RPM Conditionals [1], for example How I can check
> > what
> > is the result of:
> > 
> > %if 1
> >   echo 1;
> > %else
> >   echo 0;
> > %endif
> > 
> > Best regards,
> > 
> > [1]
> > https://rpm-packaging-guide.github.io/#rpm-conditionals
> > 
> > 
> > --
> > Sérgio M. B.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> -- 
> Jun | He - 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

How I test RPM Conditionals ? in shell command line

[Sérgio Basto]

Hi,

How I can check RPM Conditionals [1], for example How I can check what
is the result of: 

%if 1 
  echo 1; 
%else 
  echo 0; 
%endif 

Best regards,

[1]
https://rpm-packaging-guide.github.io/#rpm-conditionals 


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GitHub source URLs not working

[Sérgio Basto]

On Fri, 2021-11-26 at 14:37 -0500, Susi Lehtola wrote:
> Hi,
> 
> 
> I am experiencing problems updating packages employing GitHub source
> URLs. For instance,
> 
> $ spectool -g python-pyscf.spec
> Downloading:
> https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz
> Download failed:
> 404 Client Error: Not Found for url:
> https://codeload.github.com/pyscf/pyscf/tar.gz/v2.0.1/pyscf-2.0.1
> -   0.0 B Elapsed Time: 0:00:00
> 
> 
> 
> The URLs used to work. Has anyone else noticed the same problem?

already reported here (4 hours ago) : 
https://github.com/github/feedback/discussions/8149


> -- 
> Susi Lehtola
> Fedora Project Contributor
> jussileht...@fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] ImageMagick side-tag for f34

[Sérgio Basto]

Many thanks , side-tag submitted to bodhi 

https://bodhi.fedoraproject.org/updates/FEDORA-2021-b58af96f33


On Fri, 2021-11-26 at 12:44 +0900, Mamoru TASAKA wrote:
> Sérgio Basto wrote on 2021/11/22 21:49:
> > Hi,
> > 
> > ImageMagick 6.9.12.30 have more security fixes and it was built on
> > Rawhide and F35
> > Now I think we also should update F34 since we have a bunch of
> > security
> > fixes  .
> > So I prepared f34-build-side-48004 so please use
> > fedpkg build --target=f34-build-side-48004 to build your package for
> > Fedora 34 .
> > 
> > 
> > `dnf repoquery  --whatrequires "libMagick*" --qf "%{reponame}
> > %{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
> > 
> > fedora autotrace
> > fedora chafa
> > fedora converseen
> > fedora digikam
> > fedora dmtx-utils
> > fedora dvdauthor
> > fedora eom
> > fedora ImageMagick
> > fedora kxstitch
> > fedora pfstools
> > fedora php-pecl-imagick
> > fedora psiconv
> > fedora q
> > fedora R-magick
> > fedora rss-glx
> > fedora rubygem-rmagick
> > fedora synfig
> > fedora synfigstudio
> > fedora vdr-scraper2vdr
> > fedora vdr-skinelchihd
> > fedora vdr-skinnopacity
> > fedora vdr-tvguide
> > fedora vips
> > fedora WindowMaker
> > rpmfusion-free libopenshot
> > rpmfusion-free xine-lib
> > 
> 
> On Fedora side, all rebuilt.
> 
> $ for f in ImageMagick-libs ImageMagick-c++ ; do dnf repoquery --
> repo=koji-34-build-side-48004 -q --qf '%{sourcerpm}' --whatrequires $f
> ; done | sort -f | uniq | cat -n
>   1 autotrace-0.31.1-62.fc34.src.rpm
>   2 chafa-1.2.1-6.fc34.src.rpm
>   3 converseen-0.9.9.2-2.fc34.src.rpm
>   4 digikam-7.3.0-4.fc34.src.rpm
>   5 dmtx-utils-0.7.6-9.fc34.1.src.rpm
>   6 dvdauthor-0.7.2-16.fc34.src.rpm
>   7 eom-1.26.0-1.fc34.1.src.rpm
>   8 ImageMagick-6.9.12.31-1.fc34.src.rpm
>   9 kxstitch-2.1.1-6.fc34.src.rpm
>  10 pfstools-2.1.0-17.fc34.1.src.rpm
>  11 php-pecl-imagick-3.5.0-1.fc34.1.src.rpm
>  12 psiconv-0.9.8-36.fc34.src.rpm
>  13 q-7.11-44.fc34.src.rpm
>  14 R-magick-2.7.3-2.fc34.src.rpm
>  15 rss-glx-0.9.1.p-50.fc34.src.rpm
>  16 rubygem-rmagick-4.2.3-5.fc34.src.rpm
>  17 synfig-1.4.0-1.fc34.1.src.rpm
>  18 synfigstudio-1.4.0-3.fc34.src.rpm
>  19 vdr-scraper2vdr-1.0.11-14.20190128gitd9f6cb4.fc34.1.src.rpm
>  20 vdr-skinelchihd-0.5.0-7.fc34.src.rpm
>  21 vdr-skinnopacity-1.1.8-1.fc34.1.src.rpm
>  22 vdr-tvguide-1.3.5-1.fc34.1.src.rpm
>  23 vips-8.11.3-1.fc34.1.src.rpm
>  24 WindowMaker-0.95.9-7.fc34.src.rpm
> 
> https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=48004&order=-build_id&latest=1
> 
> Regards,
> Mamoru

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: qemu (was: Re: Orphaned packages looking for new maintainers​)

[Sérgio Basto]

On Mon, 2021-11-22 at 14:44 +0100, Miro Hrončok wrote:
> On 22. 11. 21 14:11, Richard W.M. Jones wrote:
> > On Mon, Nov 22, 2021 at 01:12:28PM +0100, Miro Hrončok wrote:
> > > Full report available at:
> > > https://churchyard.fedorapeople.org/orphans-2021-11-22.txt
> > > grep it for your FAS username and follow the dependency chain.
> > 
> > A lot of virt and filesystem packages are shown in the report, but
> > I
> > think it seems to be a mistake.
> > 
> > For example qemu:
> > 
> >   qemu (maintained by: berrange, bonzini, crobinso, dwmw2,
> > ehabkost, jforbes, lkundrak, quintela, rjones, virtmaint-sig)
> >    qemu-2:6.1.0-10.fc36.src requires glusterfs-api-devel =
> > 10.0-1.fc36
> > 
> > This is provided by libgfapi-devel which appears to exist still. 
> 
> It exists, but it is from the glusterfs package, which is also
> included in the 
> report. The dependency is transitive (and in this case, indirect,
> because only 
> glusterfs-ganesha is impacted).
> 
> > So I think this line is wrong.
> 
> That is a matter of perspective. If nobody does anything, qemu will
> be removed 
> from the distribution in ~1 year:
> 
> 1. ipmitool will be retired in 6 weeks

and why ipmitool was orphaned ? it was built successfully , its
maintain upstream ... 


> 2. fence-agents-ipmilan will fail to install
> 3. fence-agents will be orphaned in 8 weeks
> 4. fence-agents will be retired in 6 weeks
> 5. pcs will fail to build
> 6. pcs will be orphaned in 8 weeks
> 7. pcs will be retired in 6 weeks
> 8. glusterfs-ganesha will fail to install
> 9. glusterfs will orphaned in 8 weeks
> 10. glusterfscs will be retired in 6 weeks
> 11. qemu will fail to build and qemu-block-gluster will fail to
> install
> 13. qemu will be orphaned in 8 weeks
> 14. qemu will be retired in 6 weeks
> 
> This line of events is very long and can be stopped at any point by
> fixing at 
> least one package or dropping a dependency somewhere or removing a no
> longer 
> wanted subpackage.
> 
> Hence, technically, the danger to qemu is minimal. But the chain is
> there. 
> Especially the build time only transitive dependencies behave like
> this.
> 
> > Does the tool which generates the report
> > follow provides in other packages?
> 
> Yes.
> 
> > 
> >    qemu-block-gluster-2:6.1.0-10.fc36.x86_64 requires
> > libgfapi.so.0()(64bit), libgfapi.so.0(GFAPI_3.4.0)(64bit),
> > libgfapi.so.0(GFAPI_3.5.0)(64bit), libgfapi.so.0(GFAPI_6.0)(64bit)
> > 
> > These are provided by libgfapi0, see below.  This seems like a
> > different kind of mistake from above.
> 
> Same thing.
> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] ImageMagick side-tag for f34

[Sérgio Basto]

Hi,

ImageMagick 6.9.12.30 have more security fixes and it was built on
Rawhide and F35 
Now I think we also should update F34 since we have a bunch of security
fixes  .
So I prepared f34-build-side-48004 so please use 
fedpkg build --target=f34-build-side-48004 to build your package for
Fedora 34 . 


`dnf repoquery  --whatrequires "libMagick*" --qf "%{reponame} 
%{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`

fedora autotrace
fedora chafa
fedora converseen
fedora digikam
fedora dmtx-utils
fedora dvdauthor
fedora eom
fedora ImageMagick
fedora kxstitch
fedora pfstools
fedora php-pecl-imagick
fedora psiconv
fedora q
fedora R-magick
fedora rss-glx
fedora rubygem-rmagick
fedora synfig
fedora synfigstudio
fedora vdr-scraper2vdr
fedora vdr-skinelchihd
fedora vdr-skinnopacity
fedora vdr-tvguide
fedora vips
fedora WindowMaker
rpmfusion-free libopenshot
rpmfusion-free xine-lib



Best regards,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: xorg-macros

[Sérgio Basto]

On Fri, 2021-11-19 at 18:06 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Nov 19, 2021 at 01:57:12PM +, Globe Trotter via devel
> wrote:
> > I opened the following:
> > 
> > https://pagure.io/releng/issue/10396
> > 
> > I am not quite sure what happens after this, so I thought that I
> > would mention this here.
> 
> The package needs to go through re-review, because it was retired for
> more than 8 weeks. See
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
>  .
> 

indeed since package was orphan just in latest release , we should be
allowed to take it without re-review , i.e. I think 8 weeks still a
very short time and should be one release which is about 26 weeks or 6
months . 

> Zbyszek
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Reduce number of packages that are built for i686

[Sérgio Basto]

On Thu, 2021-11-18 at 16:27 +0100, Fabio Valentini wrote:
> On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto  wrote:
> > 
> > Hi,
> > another subject that can be related
> > 
> > In thread "I think we should stop building i686 packages we're not
> > shipping" we are alerted for builds for i686 that aren't publish .
> > Following the tip , I found some packages that we aren't shipped are
> > needed to allow mock start the buildroot for example tar-1.34-
> > 2.fc35.i686.rpm, tar is only available on koji local repo (1).
> > 
> > I think we should have all i686 packages, that are needed to start a
> > buildrooot, published. i.e. available on x86_64 repos. To allow mock
> > build i686 packages without need to access to internal koji local
> > repo
> > (which may not be public) .
> 
> This would break all sorts of things.
> 
> It's also not compatible with the current packaging guidelines,
> because packages must not conflict with each other unless they have an
> explicit Conflicts tag and a good reason to do so. in this case,
> tar.x86_64 and tar.i686 would conflict with each other (both providing
> /usr/bin/tar, among other files), so that's out of the question.
> 
> That's exactly the reason why complex heuristics are applied to which
> i686 packages are allowed into the x86_64 repositories as "multilib"
> packages.

I think that is the way, only multilib package should build for i686 ,
and all packages that we need to start a build (buildroot) should be
multilib . 

As is it done on RPMFusion, multilib packages have a special koji
target that is set on rfpkg [1] and maybe this need to be set on a
configuration file somewhere , I'd like that you give me suggestions,
thank you. 

[1]
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L194

> > But for packages that aren't shipped , I agree not build for i686, we
> > already got the concept of multilib package and only multilib
> > packages
> > should be build for i686 , I think.
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review request for oclock package (orphaned since F35)

[Sérgio Basto]

On Sat, 2021-11-20 at 04:46 +, Globe Trotter via devel wrote:
> Hi,
> 
> As the name says, this is a review request for the orphaned package
> oclock. I find that the old spec file from F34 complies without errors
> and so would like to maintain it.  But first, I need a review. Could
> someone please help review the package? 
> 

Hi, 

Give you some context 
https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
https://bugzilla.redhat.com/show_bug.cgi?id=1867220
https://bugzilla.redhat.com/show_bug.cgi?id=1951346

you still have xclock and you can build it on copr ( for example
https://copr.fedorainfracloud.org/coprs/build/2980373
) 

About package review you need do something like [1]
you may use fedora-create-review  [2] you will need 
bugzilla api-key [3] .

But do you really think we should have oclock package on Fedora ? 

Best regards, 

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

[2]
fedora-create-review biglybt.spec biglybt-2.8.0.0-1.fc36.src.rpm --user
sergiomb 

[3]
cat ~/.config/fedora-create-review
[fedora-create-review]
upload_target = fedorapeople.org:public_html/@pkgname@
bugzilla_username = sergio email
bugzilla_api_key =

> Thanks,
> aa...@fedoraproject.org.

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Reduce number of packages that are built for i686

[Sérgio Basto]

On Thu, 2021-11-18 at 16:27 +0100, Fabio Valentini wrote:
> On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto 
> wrote:
> > 
> > Hi,
> > another subject that can be related
> > 
> > In thread "I think we should stop building i686 packages we're not
> > shipping" we are alerted for builds for i686 that aren't publish .
> > Following the tip , I found some packages that we aren't shipped
> > are
> > needed to allow mock start the buildroot for example tar-1.34-
> > 2.fc35.i686.rpm, tar is only available on koji local repo (1).
> > 
> > I think we should have all i686 packages, that are needed to start
> > a
> > buildrooot, published. i.e. available on x86_64 repos. To allow
> > mock
> > build i686 packages without need to access to internal koji local
> > repo
> > (which may not be public) .
> 
> This would break all sorts of things.
> 
> It's also not compatible with the current packaging guidelines,
> because packages must not conflict with each other unless they have
> an
> explicit Conflicts tag and a good reason to do so. in this case,
> tar.x86_64 and tar.i686 would conflict with each other (both
> providing
> /usr/bin/tar, among other files), so that's out of the question.

no it want , we just can't install tar.i686 and tar.x86_64

and `dnf install tar` just install tar.x86_64



> That's exactly the reason why complex heuristics are applied to which
> i686 packages are allowed into the x86_64 repositories as "multilib"
> packages.
> 
> > But for packages that aren't shipped , I agree not build for i686,
> > we
> > already got the concept of multilib package and only multilib
> > packages
> > should be build for i686 , I think.
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Reduce number of packages that are built for i686

[Sérgio Basto]

Hi, 
another subject that can be related

In thread "I think we should stop building i686 packages we're not
shipping" we are alerted for builds for i686 that aren't publish .
Following the tip , I found some packages that we aren't shipped are
needed to allow mock start the buildroot for example tar-1.34-
2.fc35.i686.rpm, tar is only available on koji local repo (1).

I think we should have all i686 packages, that are needed to start a
buildrooot, published. i.e. available on x86_64 repos. To allow mock
build i686 packages without need to access to internal koji local repo
(which may not be public) . 

But for packages that aren't shipped , I agree not build for i686, we
already got the concept of multilib package and only multilib packages
should be build for i686 , I think. 



(1)
https://kojipkgs.fedoraproject.org/repos/f35-build/latest/i386/pkglist




On Tue, 2021-11-16 at 20:47 +0100, Fabio Valentini wrote:
> Hi everybody,
> 
> The announcement of the Change proposal to drop armv7 support with F37
> has reminded me of something that I wanted to ask about some time ago:
> How we could work towards reducing the number of packages we build for
> i686.
> 
> Our current approach, which is to "build everything but ship almost
> nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
> very wasteful of computing and storage resources, as well as a burden
> on maintainers of big packages, which frequently run up against limits
> of 32-bit architectures.
> 
> I think it should be possible to figure out a way to limit the number
> of packages that need to be built for the common multilib usecases
> (Wine + Steam ... am I forgetting something?), and just ... not build
> anything else for i686.
> 
> This would probably involve the following steps:
> 
> 1. determine the packages that need to be built on i686 for common
> multilib scenarios
> 2. determine recursive install-time and build-time dependencies of
> those packages
> 3. if necessary, update this list with any new build-or install-time
> dependencies that are added to the package set
> 
> As for how to implement this, I'm not sure about the details yet
> (which is why I'm sending this as an RFC and not filing a Change
> proposal yet).
> 
> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this. I have a vague idea:
> 
> - include the list of packages to be built ... somewhere (maybe in the
> default buildroot?)
> - if a package name matches a list entry, build it on i686. if it
> doesn't, then don't.
> 
> As for the second step, I'm not sure how to do that yet - does
> injecting ExcludeArch headers at SRPM build time in koji work, maybe
> with some RPM macro that's included in every package anyway? Or could
> we somehow influence the chroots that builds in koji are launched for?
> Then the spec or SRPM wouldn't even have to be modified.
> 
> As I said, I'm not sure about the details yet, but we should be able
> to figure out a way to do this, and make building Fedora packages less
> wasteful. Consider this my "request for comments". :)
> 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Sérgio Basto]

On Thu, 2021-11-11 at 11:08 +0100, Andreas Schneider wrote:
> On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via
> devel 
> wrote:
> > On 10/11/2021 09:44, Andreas Schneider wrote:
> > 
> > > I'm sorry, but didn't we talk about electron and you're pointing
> > > to
> > > vscode?
> > 
> > My previous message was:
> > 
> > 
> > > Electron core packaging is a quite trivial task (Arch Linux and
> > > Debian have already done this), but what about Electron
> > > applications
> > > (VS Code for example)?
> > 
> > By the way, which Electron app do you want to package?
> 
> I'm packaging Signal-Desktop completely built from source.
> 
> https://build.opensuse.org/package/show/network:im:signal/

https://build.opensuse.org/project/show/network:im:signal


https://build.opensuse.org/package/view_file/network:im:signal/signal-desktop/prepare_vendor.sh




-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Action required: Account system IRC pointer reset

[Sérgio Basto]

On Wed, 2021-11-10 at 17:50 +0100, Vitaly Zaitsev via devel wrote:
> On 10/11/2021 17:03, Dominik 'Rathann' Mierzejewski wrote:
> > Be warned that none of the Matrix clients currently available in
> > Fedora
> > repositories (nheko, neochat, pidgin via purple-matrix) can handle
> > SSO
> > authentication like the one required to login to fedora.im (Home
> > Server
> > is fedora.ems.host).
> 
> Both NeoChat and nheko works fine with Fedora SSO. Enter your Fedora 
> MatrixID and press the "Login with SSO" button.
> 

I'm using element-desktop-1.7.29-
1.x86_64 https://github.com/vector-im/element-desktop#readme

some thing like [1] I end up using electron-build to build the rpm and
install it and after [2] I could start the application . Sorry I lost
my history commands but be ware I took some days to figure out how I
build it all, but not expect more than one Electron app. 

[2] 
cp ./deploys/element-v1.7.29/config.sample.json
~/.config/Element/config.json fix it for me


Also we have nativefier solution [3] 

[3] 
git clone g...@github.com:nativefier/nativefier.git
cd nativefier
npm install
node lib/cli.js https://app.element.io/
cd Element-linux-x64/
./Element


[1]
you need  git clone g...@github.com:vector-im/element-desktop.git

and git clone g...@github.com:vector-im/element-web.git

cd element-desktop ; ln -s ../element-web/webapp
cd ../element-web
"some yarns like " 
 yarn run
yarn asar-webapp
yarn run fetch
cd ../element-desktop/
yarn build



> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Sérgio Basto]

On Mon, 2021-11-08 at 10:12 +0100, Andreas Schneider wrote:
> Hi,
> 
> there are several packages in the distribution which require FFMPEG 
> (libavformat, libavcodec, etc.), one of them being chromium. The
> package could 
> be created in a way that you can easily replace it with a version from 
> rpmfusion to get to the full encoder/decoder set including H264 etc.
> 
> This is working fine with openSUSE and packages from Packman.
> 
> https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg


Also Debian have ffmpeg package 

you may try :
dget https://deb.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_4.4.1-1.dsc

cd ffmpeg-4.4.1/debian
vi README.Debian
etc 

> The Packman version always has a higher release version than the one in
> the 
> distribution.
> 
> I'm interested in this, as I try to package electron for Fedora. The
> big 
> problem is the included ffmpeg. With openSUSE I can just use the system
> ffmpeg, with Fedora I have to do some source code voodoo which I really
> would 
> like to avoid.
> 
> 
> Thanks for considering!
> 
> 
> Best regards
> 
> 
> Andreas
> 
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​

[Sérgio Basto]

On Mon, 2021-11-08 at 16:52 +0100, Miro Hrončok wrote:
> platform  orphan, sergiomb 4
> weeks ago

I took it because is needed by libcec , I was already maintainer of the
package 

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Possibly off topic: Slack will discontinue packaging for Fedora

[Sérgio Basto]

as root 
dnf install dpkg 
dpkg --force-depends -i slack-desktop-4.21.1-amd64.deb
desktop-file-install ./usr/share/applications/slack.desktop 

works for me ,

is a "standalone" package we can check with :
dpkg-deb --fsys-tarfile slack-desktop-4.21.1-amd64.deb | tar tf - 



On Thu, 2021-11-04 at 20:35 -0400, JT wrote:
> As someone who has to use Slack for work, this is disappointing, but
> at least there is still a flatpak for Slack:
> https://www.flathub.org/apps/details/com.slack.Slack
> 
> On Thu, Nov 4, 2021 at 8:24 PM Gordon Messmer
>  wrote:
> > https://slack.com/help/articles/115002037526-System-requirements-for-using-Slack
> > 
> > "Note: Starting March 1, 2022, Slack will no longer support Fedora
> > Linux 
> > distributions."
> > 
> > I don't know if that's of interest to Fedora, as an organization,
> > but
> > on 
> > the off-chance that it is: Is anyone in a position to ask someone
> > at 
> > Slack about that decision?  And whether there's anything that
> > Fedora
> > can 
> > do to make publishing that package more feasible?
> > ___
> > 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
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: what is wrong with this conditional scriplet on rpm.spec

[Sérgio Basto]

On Wed, 2021-11-03 at 14:26 -0400, Ben Beasley wrote:
> I don’t know where to find documentation for operator precedence in
> RPM 
> conditional expressions, but it looks like “!” binds more tightly
> than 
> “>=”, so
> 
>  > %if ! 0%{?rhel} >= 8
> 
> is grouped as
> 
>  > %if (! 0%{?rhel}) >= 8
> 
> which becomes, on Fedora:
> 
>  > %if (! 00) >= 8
> 
>  > %if 1 >= 8
> 
> and therefore evaluates false.
> 
> Writing
> 
>  > %if ! (0%{?rhel} >= 8)
> 
> seems to do what you want, as would:

yes is exactly what I'm missing 

Thank you 


>  > %if 0%{?rhel} < 8
> 

the logic doesn't fail , but it is trick because includes {?fedora}



> On 11/3/21 14:09, Sérgio Basto wrote:
> > Hi,
> > 
> > I just notice build in mock or koji this scriptlet [1] on a build
> > for
> > Fedora gives me "is rhel 8 or 9" , what I'm missing ?
> > 
> > 
> > Thank you
> > 
> > [1]
> > %if ! 0%{?rhel} >= 8
> > echo "is not rhel >= 8"
> > %else
> > echo "is rhel 8 or 9"
> > %endif
> > 
> ___
> 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
> Do not reply to spam on the list, report it:  
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

what is wrong with this conditional scriplet on rpm.spec

[Sérgio Basto]

Hi, 

I just notice build in mock or koji this scriptlet [1] on a build for
Fedora gives me "is rhel 8 or 9" , what I'm missing ?  


Thank you 

[1]
%if ! 0%{?rhel} >= 8
echo "is not rhel >= 8"
%else
echo "is rhel 8 or 9"
%endif

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] ImageMagick-6.9.12.28

[Sérgio Basto]

On Wed, 2021-11-03 at 23:43 +0900, Mamoru TASAKA wrote:
> Sérgio Basto wrote on 2021/11/03 0:59:
> > Please build your packages for F35 in f35-build-side-47231
> > 
> > or maybe we should request help of an proven packager
> > 
> > Thank you
> > 
> > 
> > 
> > On Sun, 2021-10-31 at 22:02 +, Sérgio Basto wrote:
> > > On Sun, 2021-10-31 at 22:56 +0100, Fabio Valentini wrote:
> > > > On Sun, Oct 31, 2021 at 10:44 PM Luya Tshimbalanga
> > > >  wrote:
> > > > > 
> > > > > Hello team,
> > > > > 
> > > > > ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as
> > > > > 35-build-side-47231.
> > > > 
> > > > Sorry, I am confused. Did you mean to say the update and rebuilds
> > > > for
> > > > rawhide are *finished* and you're starting the process for f35
> > > > now?
> > > 
> > > yes, we are asking to build all packages for F35 in f35-build-side-
> > > 47231
> > > 
> > > I did it for dvdauthor
> > > 
> > > cd ../dvdauthor
> > > git pull
> > > git checkout f35
> > > git merge rawhide
> > > git push
> > > fedpkg build --target=f35-build-side-47231
> > > 
> > > Thank you
> > > 
> > > > Otherwise, the side tag name does not match "updated [...] on
> > > > Rawhide
> > > > and got side tag as [f]35-build-side-x".
> > > > 
> > > > > For my understanding, the following packages
> > > > > (including those from RPM Fusion) may need a rebuild based on
> > > > > these
> > > > > dependencies:
> > > > > 
> > > > > `dnf repoquery  --whatrequires "libMagick*" --qf "%{reponame}
> > > > > %{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
> > > > > 
> > > > > fedora autotrace
> > > > > fedora chafa
> > > > > fedora converseen
> > > > > fedora digikam
> > > > > fedora dmtx-utils
> > > > > fedora dvdauthor
> > > > > fedora eom
> > > > > fedora ImageMagick
> > > > > fedora kxstitch
> > > > > fedora pfstools
> > > > > fedora php-pecl-imagick
> > > > > fedora psiconv
> > > > > fedora q
> > > > > fedora R-magick
> > > > > fedora rss-glx
> > > > > fedora rubygem-rmagick
> > > > > fedora synfig
> > > > > fedora synfigstudio
> > > > > fedora vdr-scraper2vdr
> > > > > fedora vdr-skinelchihd
> > > > > fedora vdr-skinnopacity
> > > > > fedora vdr-tvguide
> > > > > fedora vips
> > > > > fedora WindowMaker
> > > > > rpmfusion-free libopenshot
> > > > > rpmfusion-free xine-lib
> > > > > 
> > > > > Please use f35-build-side-47231 side-tag to build your package,
> > > > > and
> > > > > I
> > > > > (or my co-maintainer) am intending to merge in F35 repository
> > > > > in
> > > > > about a
> > > > > week.
> > > > 

> > > > Given that Fedora 35 is now officially *stable*, and ImageMagick
> > > > not
> > > > being a leaf package, such a disruptive update would require
> > > > FESCo
> > > > exception to the Updates Policy.
> > > > If you want to file a ticket for such an exception, it would be
> > > > great
> > > > if people could verify that this is actually the *complete* list
> > > > of
> > > > packages that need to be rebuilt (and that they indeed *can* be
> > > > rebuilt without issues on F35), so that there is no negative
> > > > fallout
> > > > from broken dependencies on a stable release.
> > > > 
> > > > Fabio
> 
> All the above packages on Fedora are now rebuilt:
> 
>   for f in ImageMagick-libs ImageMagick-c++ ; do dnf repoquery --quiet
> --repo=koji-35-build-side-47231 --qf '%{sourcerpm}' --whatrequires $f ;
> done | sort -f | uniq | cat -n
>   1 autotrace-0.31.1-62.fc35.src.rpm
>   2 chafa-1.2.1-6.fc35.src.rpm
>   3 converseen-0.9.9.2-2.fc35.src.rpm
>   4 digikam-7.3.0-2.fc35.src.rpm
>   5 dmtx-utils-0.7.6-9.fc35.1.src.rpm
>   6 dvdauthor-0.7.2-16.fc35.src.rpm
>   7 eom-

Re: [HEADS UP] ImageMagick-6.9.12.28

[Sérgio Basto]

Please build your packages for F35 in f35-build-side-47231

or maybe we should request help of an proven packager 

Thank you 



On Sun, 2021-10-31 at 22:02 +, Sérgio Basto wrote:
> On Sun, 2021-10-31 at 22:56 +0100, Fabio Valentini wrote:
> > On Sun, Oct 31, 2021 at 10:44 PM Luya Tshimbalanga
> >  wrote:
> > > 
> > > Hello team,
> > > 
> > > ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as
> > > 35-build-side-47231.
> > 
> > Sorry, I am confused. Did you mean to say the update and rebuilds for
> > rawhide are *finished* and you're starting the process for f35 now?
> 
> yes, we are asking to build all packages for F35 in f35-build-side-
> 47231
> 
> I did it for dvdauthor 
> 
> cd ../dvdauthor
> git pull
> git checkout f35
> git merge rawhide
> git push
> fedpkg build --target=f35-build-side-47231
> 
> Thank you 
> 
> > Otherwise, the side tag name does not match "updated [...] on Rawhide
> > and got side tag as [f]35-build-side-x".
> > 
> > > For my understanding, the following packages
> > > (including those from RPM Fusion) may need a rebuild based on these
> > > dependencies:
> > > 
> > > `dnf repoquery  --whatrequires "libMagick*" --qf "%{reponame}
> > > %{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
> > > 
> > > fedora autotrace
> > > fedora chafa
> > > fedora converseen
> > > fedora digikam
> > > fedora dmtx-utils
> > > fedora dvdauthor
> > > fedora eom
> > > fedora ImageMagick
> > > fedora kxstitch
> > > fedora pfstools
> > > fedora php-pecl-imagick
> > > fedora psiconv
> > > fedora q
> > > fedora R-magick
> > > fedora rss-glx
> > > fedora rubygem-rmagick
> > > fedora synfig
> > > fedora synfigstudio
> > > fedora vdr-scraper2vdr
> > > fedora vdr-skinelchihd
> > > fedora vdr-skinnopacity
> > > fedora vdr-tvguide
> > > fedora vips
> > > fedora WindowMaker
> > > rpmfusion-free libopenshot
> > > rpmfusion-free xine-lib
> > > 
> > > Please use f35-build-side-47231 side-tag to build your package, and
> > > I
> > > (or my co-maintainer) am intending to merge in F35 repository in
> > > about a
> > > week.
> > 
> > Given that Fedora 35 is now officially *stable*, and ImageMagick not
> > being a leaf package, such a disruptive update would require FESCo
> > exception to the Updates Policy.
> > If you want to file a ticket for such an exception, it would be great
> > if people could verify that this is actually the *complete* list of
> > packages that need to be rebuilt (and that they indeed *can* be
> > rebuilt without issues on F35), so that there is no negative fallout
> > from broken dependencies on a stable release.
> > 
> > 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
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] ImageMagick-6.9.12.28

[Sérgio Basto]

On Sun, 2021-10-31 at 22:56 +0100, Fabio Valentini wrote:
> On Sun, Oct 31, 2021 at 10:44 PM Luya Tshimbalanga
>  wrote:
> > 
> > Hello team,
> > 
> > ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as
> > 35-build-side-47231.
> 
> Sorry, I am confused. Did you mean to say the update and rebuilds for
> rawhide are *finished* and you're starting the process for f35 now?

yes, we are asking to build all packages for F35 in f35-build-side-
47231

I did it for dvdauthor 

cd ../dvdauthor
git pull
git checkout f35
git merge rawhide
git push
fedpkg build --target=f35-build-side-47231

Thank you 

> Otherwise, the side tag name does not match "updated [...] on Rawhide
> and got side tag as [f]35-build-side-x".
> 
> > For my understanding, the following packages
> > (including those from RPM Fusion) may need a rebuild based on these
> > dependencies:
> > 
> > `dnf repoquery  --whatrequires "libMagick*" --qf "%{reponame}
> > %{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
> > 
> > fedora autotrace
> > fedora chafa
> > fedora converseen
> > fedora digikam
> > fedora dmtx-utils
> > fedora dvdauthor
> > fedora eom
> > fedora ImageMagick
> > fedora kxstitch
> > fedora pfstools
> > fedora php-pecl-imagick
> > fedora psiconv
> > fedora q
> > fedora R-magick
> > fedora rss-glx
> > fedora rubygem-rmagick
> > fedora synfig
> > fedora synfigstudio
> > fedora vdr-scraper2vdr
> > fedora vdr-skinelchihd
> > fedora vdr-skinnopacity
> > fedora vdr-tvguide
> > fedora vips
> > fedora WindowMaker
> > rpmfusion-free libopenshot
> > rpmfusion-free xine-lib
> > 
> > Please use f35-build-side-47231 side-tag to build your package, and
> > I
> > (or my co-maintainer) am intending to merge in F35 repository in
> > about a
> > week.
> 
> Given that Fedora 35 is now officially *stable*, and ImageMagick not
> being a leaf package, such a disruptive update would require FESCo
> exception to the Updates Policy.
> If you want to file a ticket for such an exception, it would be great
> if people could verify that this is actually the *complete* list of
> packages that need to be rebuilt (and that they indeed *can* be
> rebuilt without issues on F35), so that there is no negative fallout
> from broken dependencies on a stable release.
> 
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange mock chainbuild issue: package has incorrect checksum

[Sérgio Basto]

On Sun, 2021-10-31 at 14:50 +0100, Julian Sikorski wrote:
> W dniu 20.10.2021 o 20:09, Julian Sikorski pisze:
> > W dniu 29.09.2021 o 10:08, Julian Sikorski pisze:
> > > W dniu 28.09.2021 o 09:32, Julian Sikorski pisze:
> > > > W dniu 22.09.2021 o 21:07, Julian Sikorski pisze:
> > > > > Am 22.09.21 um 19:38 schrieb Fabio Valentini:
> > > > > > On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski 
> > > > > >  wrote:
> > > > > > > 
> > > > > > > W dniu 21.09.2021 o 23:12, Richard W.M. Jones pisze:
> > > > > > > > On Tue, Sep 21, 2021 at 10:16:17PM +0200, Julian Sikorski
> > > > > > > > wrote:
> > > > > > > > > W dniu 21.09.2021 o 11:00, Richard W.M. Jones pisze:
> > > > > > > > > > On Mon, Sep 20, 2021 at 11:45:39AM -0600, Jerry James
> > > > > > > > > > wrote:
> > > > > > > > > > > On Mon, Sep 20, 2021 at 10:49 AM Julian Sikorski 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > > my local kernel rebuilds have started failing for
> > > > > > > > > > > > no apparent 
> > > > > > > > > > > > reason - I
> > > > > > > > > > > > was using a similar command successfully for
> > > > > > > > > > > > several months.
> > > > > > > > > > > > /mnt/openmediavault is a samba share. This is
> > > > > > > > > > > > what gets 
> > > > > > > > > > > > output into the log:
> > > > > > > > > > > 
> > > > > > > > > > > [snip]
> > > > > > > > > > > 
> > > > > > > > > > > > /mnt/openmediavault/kernel/results/fedora-34-
> > > > > > > > > > > > x86_64/pesign-113-16.fc35/pesign-113-
> > > > > > > > > > > > 16.fc34.x86_64.rpm:
> > > > > > > > > > > > 
> > > > > > > > > > > > (39, fsync failed: Permission denied)
> > > > > > > > > > > 
> > > > > > > > > > > I suspect that  is the real problem, and the
> > > > > > > > > > > incorrect 
> > > > > > > > > > > checksum is
> > > > > > > > > > > a result of not being able to read or write the
> > > > > > > > > > > filesystem. 
> > > > > > > > > > > Can you
> > > > > > > > > > > verify correct ownership and permissions on every
> > > > > > > > > > > directory in 
> > > > > > > > > > > that
> > > > > > > > > > > path?
> > > > > > > > > > 
> > > > > > > > > > If fsync(2) failed then that would be happening after
> > > > > > > > > > the file
> > > > > > > > > > descriptor was open, so it wouldn't be filesystem
> > > > > > > > > > permissions but
> > > > > > > > > > probably SELinux.
> > > > > > > > > > 
> > > > > > > > > > Rich.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I am seeing no errors in setroubleshoot and setting
> > > > > > > > > selinux to
> > > > > > > > > permissive does not help either. Can it be the selinux
> > > > > > > > > of the
> > > > > > > > > bootstrapped instance, and if so, how can I control it?
> > > > > > > > > There is
> > > > > > > > > nothing obvious in the logs of the host:
> > > > > > > > 
> > > > > > > > AFAIK mock only ever uses one kernel (the host) so
> > > > > > > > disabling SELinux
> > > > > > > > on the host rules out my SELinux theory.
> > > > > > > > 
> > > > > > > > Rich.
> > > > > > > > 
> > > > > > > This is all super strange. If I delete the pesign result
> > > > > > > dir, it is
> > > > > > > built without issues. Moreover, repodata folder is also
> > > > > > > created, with
> > > > > > > the sha256 checksum in the file matching the one of the
> > > > > > > pesign 
> > > > > > > rpm. What
> > > > > > > is odd though, is that even after mock fails, gedit is
> > > > > > > claiming that
> > > > > > > repomd.xml and the data file extracted from primary.xml.gz
> > > > > > > keep 
> > > > > > > changing
> > > > > > > on disk. Can it be some odd system clock issue between my
> > > > > > > desktop 
> > > > > > > an my NAS?
> > > > > > 
> > > > > > Oh my, that filesystem is mounted over a network? What
> > > > > > filesystem is
> > > > > > backing that directory? SMB? NFS?
> > > > > > I assume that the issue you're seeing is caused by something
> > > > > > like "NFS
> > > > > > doesn't support the fsync call properly" ...
> > > > > > 
> > > > > > Fabio
> > > > > > 
> > > > > It is a local network samba share, from a host running armbian
> > > > > and 
> > > > > openmediavault. This used to work until last week or so, which
> > > > > is 
> > > > > why I am starting to suspect some strange clock problem. I have
> > > > > tried rebooting the NAS but it did not help.
> > > > > 
> > > > > Best regards,
> > > > > Julian
> > > > 
> > > > I have now managed to generate logs on the NAS, see attached.
> > > > There 
> > > > are two errors which stand out: NT_STATUS_NO_EAS_ON_FILE and 
> > > > NT_STATUS_ACCESS_DENIED later. Does this give any indication as
> > > > to 
> > > > what might be happening?
> > > > 
> > > > Best regards,
> > > > Julian
> > > 
> > > I have been investigating this further. When building from a
> > > different 
> > > client, I am getting most interesting results:
> > > 
> > > $ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
> > > fedora-34-x86_64 goffice/goffice-0.10.49-1.fc36.src.rpm 
> > > gnumeric/gnumeric-1.12.49-1.

Re: [Rawhide] ImageMagick-6.9.12-26 available

[Sérgio Basto]

On Wed, 2021-10-27 at 23:33 -0700, l...@fedoraproject.org wrote:
> 
> 
> On 2021-10-27 10:21 a.m., "Antonio T. sagitter"
>  wrote:
> > Use a side-tag 
> > (https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages
> > ),
> > please.
> 
> Done. 
> '''
> Side tag 'f36-build-side-47153' (id 47153) created.
> Use 'fedpkg build --target=f36-build-side-47153' to use it.
> Use 'koji wait-repo f36-build-side-47153' to wait for the build repo
> to be generated.
> '''

I think we can close this side tag .
Should be something like : 

bodhi updates new --from-tag --notes "Update to 6.9.12-27 (#2017126)" -
-user  f36-build-side-47153

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Rawhide] ImageMagick-6.9.12-26 available

[Sérgio Basto]

On Tue, 2021-10-26 at 16:42 -0700, Luya Tshimbalanga wrote:
> Hello team,
> 
>   I would like to let you know ImageMagick-6.9.12-26 recently landed 
> upstream.

Hello , when you update from 6.9.11 to 6.9.12, we need rebuild all
depended packages because we got one soname bump and packages won't
will give us rpm broken dependencies on dnf update 

I propose do a side-tag to update from 6.9.11 to 6.9.12 on F35 since
ImageMagick should have been updated a long time ago and it was tested
on rawhide .

I know is a exception to guidelines , but wait more 6 months for end
users have ImageMagick update is a bad alternative ... 


> Learning from the previous experiences, I or my co-maintainer are 
> planning to commit and build this package for Rawhide only in about a
> week, so the following maintainers of the respective packages will
> need 
> to get in sync:
> 
> NsCDE
> a2ps
> anyremote
> c-graph
> caja-image-converter
> chordpro-abc
> conky-manager
> darktable-tools-noise
> devedeng
> dvd-slideshow
> epix
> fbida
> ffmulticonverter
> freewrl
> geeqie
> gscan2pdf
> gyazo
> jumpnbump-menu
> latex2rtf
> libpst
> lives
> lyx
> mediawiki
> mtpaint
> nautilus-image-converter
> nemo-image-converter
> perl-Graphics-TIFF-tests
> perl-PDF-API2-tests
> perl-PDF-Builder-tests
> perl-Panotools-Script
> playonlinux
> rubygem-mini_magic
> rubygem-rmagick
> shutter
> texlive-graphicxpsd
> variety
> vfrnav-utils
> w3m-img
> wdune
> 
> 
> The scratch-build is successful on 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77869076 meaning 
> proven packagers are welcome to commit the changes.  Let know if
> anyone 
> has a question.
> 
> Regards,
> 
> -- 
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package owner required for ImageMagick

[Sérgio Basto]

Hi, I remember a few years ago an imageMagick upgrade , we made one 
compat-ImageMagick693 [1] and after a few days the packages was not
needed anymore . 
I propose do the same , do one compat-ImageMagick6.9.12 and after
upgrade ImageMagick to 7 ... 


[1] 
https://bodhi.fedoraproject.org/updates/?packages=compat-ImageMagick693


On Tue, 2021-10-26 at 10:47 +, Michael J Gruber wrote:
> Sounds as if we need to keep ImageMagick 6.x for legacy reasons as long
> as it's safe to do so, but instead of switching to 7.x at some point,
> switching to GraphicsMagick is at most as much work if not less, but
> more future-proof?
> 
> [Judging from the current state of upstreams which is subject to
> change, of course.]
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fwd: Converting montserrat spec to new version

[Sérgio Basto]

Hi Luya 

I'm sending this email to packaging Mailing List ...

I'm also facing problems with some fonts packages, 
see this error [3].

How I convert %_font_pkg ? from
https://pkgs.rpmfusion.org/cgit/nonfree/lpf-mscore-fonts.git/tree/mscore-fonts.spec.in

Thank you . 

[3]
warning: This package uses obsolete macros that will go away soon.
Please convert to the spec templates provided by fonts-rpm-templates!


 Forwarded Message 
From: Luya Tshimbalanga 
Reply-To: Development discussions related to Fedora

To: Development discussions related to Fedora

Subject: Converting montserrat spec to new version
Date: Fri, 8 Oct 2021 22:07:59 -0700

Hello team,

I started converting the current julietaula-montserrat-fonts spec to
the 
new version [1] using ibm-plex-fonts as template [2], but struggled to 
understand the functionality.

Here is an example below:

--

BuildArch:  noarch
%global fontpkgname julietaula-montserrat
%global fontconf 61-%{fontpkgname}

# Override versioning to sync with upstream
Epoch:        1
Version:    7.222
Release:    %autorelease
URL:        https://github.com/JulietaUla/Montserrat

%global foundry julietaula
%global fontlicense OFL
%global fontlicenses    OFL.txt
%global fontdocsex  %{fontlicenses}

%global fontfamily1  Montserrat
%global fontsummary1 Sans-serif typeface inspired from 
Montserrat area
%global fonts1   *.otf
%global fontdescription1 %{expand:
A typeface inspired by signs around the Montserrat area \
of Buenos Aires, Argentina.}

%global fontfamily2  MontserratAlternates
%global fontsummary2 Sans-serif typeface inspired from 
Montserrat area
%global fonts2   *.otf
%global fontdescription1 %{expand:
A typeface inspired by signs around the Montserrat area \
of Buenos Aires, Argentina.}



Source0: %{url}/archive/v%{version}.tar.gz#/Montserrat-
%{version}.tar.gz
Source1:    %{name}-fontconfig.conf
Source2:    %{name}-alternates-fontconfig.conf
Source3:    %{fontpkgname}.metainfo.xml
Source4:    %{fontpkgname}-alternates.metainfo.xml

BuildArch:    noarch
BuildRequires:    fontpackages-devel
BuildRequires:    libappstream-glib
Requires:    fontpackages-filesystem

# Reset the old date based versioning
Obsoletes:    %{name} < 1:%{version}-%{release}


%description
%{common_description}

%package common
Summary:  Common files for %{name}
Requires: fontpackages-filesystem

%description common
%{common_description}
This package consists of files used by other %{name} packages.

%package    -n %{fontpkgname}
Summary:    Base version of the Montserrat area inspired typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fo

As noticed, two subpackaged webfonts are listed because they are 
required from the landing page for Fedora Apache. I

ntpkgname}
%{common_description}
This package provide the base fonts.

%package     -n %{fontpkgname}-alternates-fonts
Summary:    A Montserrat area inspired typeface family alternate
version
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-alternates-fonts
%{common_description}
This package provide an alternate version of the fonts.

%package    -n %{fontpkgname}-base-web-fonts
Summary:    Web fonts version of the Montserrat area inspired typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-base-web-fonts
%{common_description}
This package include essential web fonts.

%package    -n %{fontpkgname}-extra-web-fonts
Summary:    Extra web fonts version of the Montserrat area inspired
typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-extra-web-fonts
%{common_description}
This package includes extra web fonts.

%prep
%autosetup -c

%build
%fontbuild

%install
%fontinstall
install -m 0644 -p Montserrat-%{version}/fonts/webfonts/*.woff 
%{buildroot}%{_fontdir}
install -m 0644 -p Montserrat-%{version}/fonts/webfonts/*.woff2 
%{buildroot}%{_fontdir}

install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
     %{buildroot}%{_fontconfig_confdir}

# Install Montserrat fonts
install -m 0644 -p %{SOURCE1} \
     %{buildroot}%{_fontconfig_templatedir}/%{fontconf}.conf

# Install MontserratAlternates fonts
install -m 0644 -p %{SOURCE2} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}-alternates.conf

for fconf in %{fontconf}.conf \
      %{fontconf}-alternates.conf ; do
     ln -s %{_fontconfig_templatedir}/$fconf \
     %{buildroot}%{_fontconfig_confdir}/$fconf
done

# Add AppStream metadata file, Repeat for every font family
install -Dm 0644 -p %{SOURCE3} \
%{buildroot}%{_datadir}/metainfo/%{fontpkgname}.metainfo.xml
install -Dm 0644 -p %{SOURCE4} \
%{buildroot}%{_datadir}/metainfo/%{fontpkgname}-alternates.metainfo.xml

%check
appstream-util validate-relax --non

Re: Stability of armv7hl builders

[Sérgio Basto]

On Wed, 2021-10-20 at 15:22 +0200, Iñaki Ucar wrote:
I asked this in another thread, but maybe this is related to [1]? How
do we disable just link-time parallelism?

[1] 
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/bc8fa85e907d4b2b88760da8d23c9e17663c44fa?branch=rawhide

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PAUC23XC6JP2BFJWWYDRWN7TNSCC6ALJ/#SFBGJGSMSQL6UN7UVWLTH3EA4Z5PQBQV


On Wed, 20 Oct 2021 at 15:15, Jakub Jelinek  wrote:
> 
> Hi!
> 
> I've been trying to build gcc in rawhide and f35 for more than a week
> now,
> but haven't succeeded due to instability of the armv7hl builders.
> E.g. the
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117620
> build succeeded on all but armv7hl in less than 22 hours (on aarch64
> even took less than 5 hours), but armv7hl kept rebooting or whatever
> (impossible to find out from the logs) 8 times, see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117797
> Buildroots list.
> Eventually I've cancelled that build after 151 hours, disabled
> LTO on armv7hl (for GCC bootstrap) and am building now
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518894
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518968
> but those again show total time of ~ 21 hours, but armv7hl task times
> of 1.5 and 10 hours, so the f35 build was retried already 2 times and
> f36
> once.
> 
> Any recent kernel changes on the boxes, or is there any way to find
> out
> what's going on with them, whether it oopses, OOMs or something else?
> 
> In late August the package built just fine and took ~ 27 hours to
> build on
> armv7hl.
> 
>     Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Iñaki Úcar
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ImageMagick update

[Sérgio Basto]

On Sat, 2021-10-16 at 06:39 +0900, Mamoru TASAKA wrote:
> Michael Catanzaro wrote on 2021/10/16 0:37:
> > On Fri, Oct 15 2021 at 10:22:36 AM +0200, Remi Collet <
> > fed...@famillecollet.com> wrote:
> > > Sorry, but such update, with soname change is not acceptable in
> > > stable
> > > branches.
> > 
> > Hi Luya,
> > 
> > Please note that soname changes are allowed in rawhide only after a
> > one-week notice period. Since you did not give other maintainers
> > notice, everything that depends on ImageMagick is now likely broken
> > in rawhide
> > 
> 
> Can we untag rawhide new ImageMagick, create side tag and move new
> ImageMagick to side tag?
> 

I Like the idea , is it possible ? 

> Regards,
> Mamoru
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure