Re: oneapi-level-zero requires cloned spdlog-populate

[Frantisek Zatloukal]

Hey,

just FYI, this was/is in progress by me, you could've checked upstream PRs:
https://github.com/oneapi-src/level-zero/pull/149 and
https://github.com/oneapi-src/level-zero/pull/150 . It was pending on
https://src.fedoraproject.org/rpms/spdlog/pull-request/2 that was merged
pretty recently.

On Thu, May 23, 2024 at 4:46 AM Luya Tshimbalanga 
wrote:

> Thanks, report filed on
> https://github.com/oneapi-src/level-zero/issues/146.
>
> --
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM Packaging Ideas for Fedora 41

[Frantisek Zatloukal]

On Mon, May 13, 2024 at 3:42 PM Vít Ondruch  wrote:

>
> My point is that we can spent time maintaining llvm00 - llvm99 packages
> or we can spent time adjusting upstream projects to be compatible with
> the latest llvm.
>

There are many projects that require a fair amount of work to be ported to
newer llvm versions, take intel-igc for example (
https://github.com/intel/intel-graphics-compiler ) where there is now more
than a year long process to slowly get it to llvm 16 (yeah, that's not a
typo).

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unresponsive packagers: suanand and vponcova

[Frantisek Zatloukal]

vponcova left Red Hat, and I don't think she'll be continuing to maintain
the packages,

Adding mkolman to CC.

On Fri, May 3, 2024 at 10:57 AM Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> We have been emailing daily the following users to notify that the email
> they
> have set in FAS does not correspond to a valid bugzilla account.
> This is a requirement for Fedora packagers.
>
> Does someone know how to contact them?
>
> suanand - emailed since April 5th
>
> suanand is maintainer of rpms/gettext
> suanand is main admin of rpms/php-gettext-gettext
>   rpms/php-gettext-gettext co-maintainers: @petersen
> suanand has a bugzilla override on rpms/php-gettext-gettext
> suanand is main admin of rpms/php-gettext-languages
>   rpms/php-gettext-languages co-maintainers: @petersen
> suanand has a bugzilla override on rpms/php-gettext-languages
> suanand is maintainer of rpms/python-polib
> suanand is maintainer of rpms/python-tinydb
> suanand is maintainer of rpms/translate-toolkit
> suanand is maintainer of rpms/transtats-cli
> suanand is maintainer of rpms/zanata-python-client
>
> vponcova - emailed since February 26th
>
> vponcova is maintainer of rpms/anaconda
> vponcova is maintainer of rpms/pykickstart
> vponcova is maintainer of rpms/python-blivet
> vponcova is maintainer of rpms/python-dasbus
>
>
> Thanks for your help,
>
> Pierre
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Handling --enable-experimental-jit in Python 3.13

[Frantisek Zatloukal]

On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok  wrote:

> Hello Pythonistas,
>
> Python 3.13 has an experimental JIT compiler:
>
> https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler
>
> Enabling it is a configure (hence build-time) option.
>
> How do we handle this in Fedora?
>
> - We can keep it disabled, as it is experimental.
> - We can enable it, but be ready to revert if it causes problems.
> - We can add yet another build variant, but we already have 4 of those
> (regular, debug, freethreading, freethreading-debug), so I'd rather not
> make it
> 6 (or 8, if we include freethreading+jit combinations). I don't know yet
> if it
> would be co-installable.
>
> Opinions?
>

o/,
what about leaving it on in rawhide and reevaluating readiness for a proper
release around f42 branching based on how many bleeding (edge) kittens did
it eat?

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 40 Final Freeze

[Frantisek Zatloukal]

On Tue, Apr 2, 2024 at 12:39 PM Jakub Jelinek  wrote:

> sting->stable marked updates be still included in
> stable without having to go through the exception/blocker process?
>

I was told there would be one more stable push at the releng channel on
matrix.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: exiv2 and protobuf hard to do soname bump without turbulence

[Frantisek Zatloukal]

On Sat, Feb 10, 2024, 01:50 Sérgio Basto  wrote:

> "In order to update Exiv2, we need to know if this is okay to enable
> BMFF support. Patents have theorically expired and it is enabled by
> default in the latest version."
>
> until isn't clear by legal it should be disabled , if default is enable
> ,we should disable it and move on , it is not a show stopper
>

The problem in these cases is that if something has a chance that it's not
legally all right, it also needs to be removed from the source code,
disabling it just for the build isn't enough.

>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Frantisek Zatloukal]

On Fri, Feb 9, 2024 at 2:16 AM Sérgio Basto  wrote:

> MLT built [1] (with one workaround for GCC for x86_64).
>
> [1]
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-7b5199d4f6
>
>
Thanks a lot, krita rebuilt:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-324af7694e

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] libjpeg-turbo soname bump

[Frantisek Zatloukal]

Submitted as https://bodhi.fedoraproject.org/updates/FEDORA-2024-7ffec7b81f
.

Krita is FTI now in koji local repository due to mlt being FTBFS and FTI,
I'll resolve that once gcc gets fixed not to ICE during mlt build (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 ).

On Mon, Feb 5, 2024 at 5:15 PM Frantisek Zatloukal 
wrote:

> In a few days, I'll start with bumping libjpeg-turbo in rawhide from 2.1.4
> to 3.0.2 ( https://src.fedoraproject.org/rpms/libjpeg-turbo/pull-request/2
>  ).
>
> soname bump (0.2.0 to 0.3.0) is just for the turbojpeg consumers, libjpeg
> so stays the same - API and ABI compatible, it's a drop-in replacement.
>
> This would affect the following packages (All the consumers in rawhide
> currently build fine both with the old and the new version. Impact checked
> at
> https://copr.fedorainfracloud.org/coprs/frantisekz/turbojpeg-3/packages/
> ):
> dcm
> hyperhdr
> imv
> kf5-kwayland
> kf5-kwindowsystem
> krita
> libjpeg-turbo
> neatvnc
> opentoonz
> python-fslpy
> VirtualGL
> wayvnc
> weston
>
> If any of the maintainers would prefer to do the rebuild themselves,
> please do feel free to speak up, I'll send the side-tag id here before the
> rebuild starts. Otherwise, I'll handle all the rebuilds.
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Frantisek Zatloukal]

On Tue, Feb 6, 2024 at 3:55 PM Sérgio Basto  wrote:

> On Tue, 2024-02-06 at 15:43 +0100, Frantisek Zatloukal wrote:
> >
> >
> > On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto 
> > wrote:
> > > Mass rebuild finished and merge to rawhide [1].
> > > Packages player and MLT are already FTBFS on Rawhide so I didn't
> > > touch
> > > them .
> > >
> >
> >
> > mlt is now FTI, do you plan to introduce opencv-compat to resolve
> > that?
>
> I'm waiting for the gcc [1] fix, until then I think the best solution
> is not to update opencv.
>
> Best regards,
>
> [1]
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205


Sure, wfm, I'll just keep in mind to rebuild krita then which will get
doube-FTI'd after merging libjpeg-turbo (it currently is because of mlt
too).

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Frantisek Zatloukal]

On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto  wrote:

> Mass rebuild finished and merge to rawhide [1].
> Packages player and MLT are already FTBFS on Rawhide so I didn't touch
> them .


mlt is now FTI, do you plan to introduce opencv-compat to resolve that?


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rawhide] libjpeg-turbo soname bump

[Frantisek Zatloukal]

In a few days, I'll start with bumping libjpeg-turbo in rawhide from 2.1.4
to 3.0.2 ( https://src.fedoraproject.org/rpms/libjpeg-turbo/pull-request/2
 ).

soname bump (0.2.0 to 0.3.0) is just for the turbojpeg consumers, libjpeg
so stays the same - API and ABI compatible, it's a drop-in replacement.

This would affect the following packages (All the consumers in rawhide
currently build fine both with the old and the new version. Impact checked
at https://copr.fedorainfracloud.org/coprs/frantisekz/turbojpeg-3/packages/
):
dcm
hyperhdr
imv
kf5-kwayland
kf5-kwindowsystem
krita
libjpeg-turbo
neatvnc
opentoonz
python-fslpy
VirtualGL
wayvnc
weston

If any of the maintainers would prefer to do the rebuild themselves, please
do feel free to speak up, I'll send the side-tag id here before the rebuild
starts. Otherwise, I'll handle all the rebuilds.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] libavif soname bump

[Frantisek Zatloukal]

libavif-1.0.3 built in f40-build-side-82609. Proceeding with rebuilds...

On Thu, Jan 25, 2024 at 11:37 AM Frantisek Zatloukal 
wrote:

>
>
> On Thu, Jan 25, 2024 at 11:23 AM Richard W.M. Jones 
> wrote:
>
>> On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote:
>> > In about a week (after mass rebuild before branching), I'll start
>> > with bumping libavif in rawhide from 0.11.x to 1.0.3
>> > ( https://src.fedoraproject.org/rpms/ libavif/pull-request/2 ,
>> > soname bump from 15 to 16).
>>
>> I'm confused .. Wouldn't it be better to do this after branching?
>> Otherwise you're introducing an SONAME bump into the stabilising
>> Fedora 40.
>>
>
> I would prefer to have this in F40 too (not to block gamescope rebases
> (which do require libavif >= 1.0) there for the lifetime of the F40
> release), and, this isn't a big of a risky rebase in my opinion (there will
> be more impactful and riskier rebases coming far later in the cycle, such
> as LLVM rebase, again, in my opinion).
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: poppler soname bump in Rawhide soon

[Frantisek Zatloukal]

Also, at least efl is FTBFS now, so it can't be rebuilt, and you'll have to
make a poppler-compat package before merging this, if efl isn't fixed by
then.

On Tue, Jan 30, 2024 at 2:03 PM Sandro  wrote:

> On 30-01-2024 12:15, Michael J Gruber wrote:
> > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34:
> >> Hi,
> >>
> >> I plan to rebase poppler to 24.02.0 once it is released. It will be
> >> probably released this week and I would like to get it to rawhide before
> >> the branching together with rebuilds of dependent packages.
> >>
> >> I'll prepare the build in a side tag and will message relevant
> >> maintainers to rebuild their packages there.
> >>
> >> The packages which will need rebuilds:
> >>calligra
> >>gambas3
> >>gdal
> >>gdcm
> >>inkscape
> >>kf5-kitinerary
> >>libreoffice
> >>pdf2djvu
> >>scribus
> >
> > That list is surprisingly short. For example, poppler-glib requires a
> > specific poppler version, and via poppler-glib-devel that affects more
> > packages (zathura-pdf-poppler comes to my mind).
>
> How about:
>
> $ fedrq wrsrc -s poppler -F name
> LabPlot
> OpenSceneGraph
> R-pdftools
> abiword
> apvlv
> atril
> booksorg
> bookworm
> boomaga
> calibre
> calligra
> cantor
> claws-mail
> deepin-api
> deepin-file-manager
> diff-pdf
> diffoscope
> diffpdf
> docparser
> efl
> engauge-digitizer
> evince
> extractpdfmark
> fbida
> gambas3
> gdal
> gdcm
> geeqie
> gimagereader
> gimp
> gle
> gnome-commander
> graphviz
> gscan2pdf
> gsequencer
> gummi
> inkscape
> kbibtex
> kf5-kfilemetadata
> kf5-kitinerary
> kf6-kfilemetadata
> kile
> kitinerary
> krita
> ktikz
> latex2html
> libcupsfilters
> libppd
> libreoffice
> mat2
> okular
> pdf2djvu
> pdf2svg
> pdfgrep
> pdfpc
> pg_auto_failover
> photoqt
> poppler-sharp
> python-img2pdf
> python-paperwork-backend
> python-pdf2image
> python-pikepdf
> python3-poppler-qt5
> qcomicbook
> qpdfview
> qt5-qtwebengine
> qt6-qtwebengine
> rubygem-activestorage
> rubygem-asciidoctor-pdf
> rubygem-poppler
> scribus
> setzer
> tellico
> texmaker
> texstudio
> texworks
> tikzit
> tracker-miners
> tumbler
> vfrnav
> vips
> weston
> xournal
> xournalpp
> xreader
> yacreader
> zathura-pdf-poppler
>
> -- Sandro
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] libavif soname bump

[Frantisek Zatloukal]

On Thu, Jan 25, 2024 at 11:23 AM Richard W.M. Jones 
wrote:

> On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote:
> > In about a week (after mass rebuild before branching), I'll start
> > with bumping libavif in rawhide from 0.11.x to 1.0.3
> > ( https://src.fedoraproject.org/rpms/ libavif/pull-request/2 ,
> > soname bump from 15 to 16).
>
> I'm confused .. Wouldn't it be better to do this after branching?
> Otherwise you're introducing an SONAME bump into the stabilising
> Fedora 40.
>

I would prefer to have this in F40 too (not to block gamescope rebases
(which do require libavif >= 1.0) there for the lifetime of the F40
release), and, this isn't a big of a risky rebase in my opinion (there will
be more impactful and riskier rebases coming far later in the cycle, such
as LLVM rebase, again, in my opinion).

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rawhide] libavif soname bump

[Frantisek Zatloukal]

In about a week (after mass rebuild before branching), I'll start with
bumping libavif in rawhide from 0.11.x to 1.0.3 (
https://src.fedoraproject.org/rpms/libavif/pull-request/2 , soname bump
from 15 to 16). If I am not missing anything, it should mean ABI-only
change, so all the dependencies that aren't FTBFS should rebuild fine.
Should anything not build, I'll add a compat package not to cause any new
FTIs.

This would affect the following packages:
avif-pixbuf-loader
celestia-common
darktable
efl
gd
kf5-kimageformats
plasma-wallpapers-dynamic
python-imagecodecs
webkit2gtk4.0
webkit2gtk4.1
webkitgtk6.0
xpra

If any of the maintainers would prefer to do the rebuild themselves, please
do feel free to speak up, I'll send the side-tag id here before the rebuild
starts. Otherwise, I'll handle all the rebuilds.

I probably don't have to wait until the mass rebuild is finished, but doing
so will leave me with a calmer sleep.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads up: Flask and Werkzeug 3.0

[Frantisek Zatloukal]

I have been working on the Pull Requests for Flask and Werkzeug rebases
from 2.2.x versions to the 3.x in Fedora Rawhide. I am using the Werkzeug
PR as the base one to post comments.

Impact check is in the first comment:
https://src.fedoraproject.org/rpms/python-werkzeug/pull-request/16#

These packages have lots of dependencies, but If I am not missing anything
important, most of the breakage should've been resolved by now (or at least
with a fix proposed).

The changes in both of the projects are significant with lots of
deprecations, removals, cleanups, and improvements:

Werkzeug 2.3 :
https://werkzeug.palletsprojects.com/en/3.0.x/changes/#version-2-3-0
Werkzeug 3.0 :
https://werkzeug.palletsprojects.com/en/3.0.x/changes/#version-3-0-0

Flask 2.3 :
https://flask.palletsprojects.com/en/3.0.x/changes/#version-2-3-0
Flask 3.0 :
https://flask.palletsprojects.com/en/3.0.x/changes/#version-3-0-0

In any case, I'd like to land the rebase to 3.x early January. I hope I'll
have all the issues resolved by then. If something isn't ready, I'll try to
work on fixing the remaining issues and/or at least provide help to the
potentially affected maintainers.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Looking for a volunteer to automate the orphaned packages process

[Frantisek Zatloukal]

On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson 
wrote:

> I'm not sure I have time to take this, but glancing over it, I have a
> suggestion on how to further automate the release stuff.
>
> You can use Bodhi release date to determine the extant EPEL releases
> and the current Branched release. If you query
> https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
> get a bunch of data on releases (paginated, so either handle the pages
> or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
> instead).
>
> To get all current EPEL releases you'd do something like this:
>
> epels = {int(rel['version']) for rel in releases if
>  rel['state'] == 'current' and rel['id_prefix'] ==
> 'FEDORA-EPEL'}
>
> To find current Branched, you can do something like this:
>
> devrels = {int(rel['version']) for rel in releases if
>rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
> if len(devrels) > 1:
> branched = min(devrels)
> else:
> branched = None
>
> that logic should be safe as long as we don't change the release
> process. There is always one "pending" Fedora release - Rawhide. If
> there's more than one, there will be two, and the other one will be
> Branched.
>

Or, the "lazier" to implement alternative for this would be
https://packager-dashboard.fedoraproject.org/api/v1/releases :)

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can we squeeze coreutils-9.4 into Fedora 39?

[Frantisek Zatloukal]

On Wed, Aug 30, 2023 at 6:11 PM David Cantrell  wrote:

> I personally agree that this is enough of a change to warrant
> consideration for Fedora 39, but I want Fedora QA to weigh in.  At this
> point we have beta and final blockers and you can use this form to
> propose one:
>
> https://qa.fedoraproject.org/blockerbugs/propose_bug
>
>
>
Or, the most straightforward way would be to wait for 39 Beta (the freeze
ends by the Beta release) , and do a normal package bump to 9.4 in the f39
branch. You wouldn't need any exception or patch cherry pick for this.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: packager-dashboard not updating koschei build status

[Frantisek Zatloukal]

Hey,

Thanks for raising the issue. It has been addressed and all the dashboards
should now contain up2date data from koschei.

Longer answer: The problem was the enablement of EPEL 9 Next in koschei,
oraculum (the backend for the Packager Dashboard) isn't ready for these
kinds of releases and I had to add filtering of it:
https://pagure.io/fedora-qa/oraculum/c/aba10ef932ba894c2000851f4028f4402d6bbcdc?branch=master
.

On Tue, Jul 25, 2023 at 12:54 AM Mikel Olasagasti 
wrote:

> Hi all,
>
> I've multiple reports of FTBFS in the packager-dashboard, but I can
> see many of the packages are being built fine in koschei/koji.
>
> Is there a known issue on refreshing koschei data?
>
> Kind regards,
> Mikel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Frantisek Zatloukal]

On Thu, Jul 20, 2023 at 11:58 AM Peter Robinson 
wrote:

> On Thu, Jul 20, 2023 at 10:46 AM Miroslav Suchý  wrote:
> > "Only dead projects has stable API"
>
> You can evolve APIs with versioning to ensure backwards compatibility
> while also evolving the usecases.
>

Well, this is exactly the case, isn't it? You have dnf4/dnf5, all nice and
versioned.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

The side tag has been merged:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Thu, Jul 13, 2023 at 8:28 AM Remi Collet 
wrote:

> Hi,
>
> Le 12/07/2023 à 10:15, Frantisek Zatloukal a écrit :
> > I'd submitted the side-tag for merging to f39 base:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c
> > <https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c>
> >
> > There are a bunch of packages missing,
>
> I notice mongo-c-driver 1.24.1-2 is NOT in the update
>
> I just push and update to 1.24.2-1 there,
> but not launch any build.
>
> Can you take care of it, or tell me when icu73 will be in buildroot
>
>
Sure sure, thanks for letting me know, I'll handle this as a part of the
seide tag.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

FYI, postponing this to tomorrow, qt6 packages are unbuildable in rawhide
(unrelated to this change).

On Wed, Jul 12, 2023 at 10:33 AM Mamoru TASAKA 
wrote:

> Frantisek Zatloukal wrote on 2023/07/12 17:18:
> > On Wed, Jul 12, 2023 at 8:36 AM Mamoru TASAKA  >
> > wrote:
> >
> >> I am not the maintainer of brltty, but just adding "BR: gcc" makes
> >> brltty compile on all arches (against f39):
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=103255038
> >>
> >> I am not sure to what side-tag I should build brltty for now...
> >> (ocaml rebuild first, or ICU rebuild first)
> >>
> >>
> > Mhm, I can add BR: gcc there, but I'd love to know the reason it wasn't
> > there in the first place/why other architectures don't need that. Thanks
> > for finding that out!
>
> Because "BR: ocaml" pulls in gcc (ocaml explicitly has Requires: gcc),
> which is excluded on i686 just now due to ocaml being no longer supporting
> i686 on f39.
>
> >
> > I'll go ahead and merge the icu side as soon as gating tests allow, this
> > can be solved via dist-git push separately/pulled into the ocaml rebuild
> if
> > Richard would want.
> >
>
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Wed, Jul 12, 2023 at 8:36 AM Mamoru TASAKA 
wrote:

> I am not the maintainer of brltty, but just adding "BR: gcc" makes
> brltty compile on all arches (against f39):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=103255038
>
> I am not sure to what side-tag I should build brltty for now...
> (ocaml rebuild first, or ICU rebuild first)
>
>
Mhm, I can add BR: gcc there, but I'd love to know the reason it wasn't
there in the first place/why other architectures don't need that. Thanks
for finding that out!

I'll go ahead and merge the icu side as soon as gating tests allow, this
can be solved via dist-git push separately/pulled into the ocaml rebuild if
Richard would want.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

I'd submitted the side-tag for merging to f39 base:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c

There are a bunch of packages missing, these will be handled after the side
merge. If I didn't miss anything, all of the failures were FTBFS already.
Since we have libicu72 in the base repo already, the merging will not cause
FTI issues.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Tue, Jul 11, 2023 at 11:06 PM Richard W.M. Jones 
wrote:

> Yes I think it's better if you could proceed with brltty.
>
> Note I pushed a commit earlier today which excludes %{ix86} from the
> OCaml subpackage.  In OCaml 5 / Fedora 39 we are going to drop support
> for this architecture entirely.
>
> > - build bumped icu in your side-tag too, so brlapi rebuilt there
> > would be built both against new icu and new ocaml?
>
> I'm not sure whether or not this is necessary, but in any case don't
> worry as I will sort it out when doing the OCaml rebuild.
>
> Rich.
>

FYI, it seems brltty is failing anyway on i686, with:
configure: error: C compiler cannot create executables

( https://koji.fedoraproject.org/koji/taskinfo?taskID=103241186 )

Adding limb to CC.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Tue, Jul 11, 2023 at 10:56 PM Richard W.M. Jones 
wrote:

> I think the OCaml build will take a while.
>
> Is this related to the (concurrent) Perl rebuild?
>

No, the perl rebuild is separate from this. There shouldn't be any overlap,
afaik?

In such case, I guess I should:
- proceed with brlapi rebuild in my side-tag, merge that side-tag to the
f39 baserepo tomorrow morning
- build bumped icu in your side-tag too, so brlapi rebuilt there would be
built both against new icu and new ocaml?


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Tue, Jul 11, 2023 at 10:41 PM Jerry James  wrote:

>
> It looks like we haven't gotten to brltty yet in the OCaml builds.
> How long do you think it would be before you could merge your side
> tag?  If it won't be long, maybe we should wait for you.
>
> CCing Richard Jones, who is actually running the OCaml builds.
>
>
I was planning to do the initial merge (minus some long to build packages
like qt webkit/webengine, cross-depending on qtbase packages which also
depend on icu) tomorrow morning CET (in about 10 hours from now).


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

On Tue, Jul 11, 2023 at 9:47 PM Jerry James  wrote:

> > brltty
>
> This package is also being built in a side tag for the OCaml 5.0.0
> update, which is already ongoing.  Can you wait until the OCaml builds
> are done to build this one?  Otherwise, we're going to rebuild this
> poor package over and over to get all of its deps right.
>

Sure, task https://koji.fedoraproject.org/koji/taskinfo?taskID=103239771
canceled, will wait for ocaml rebuild. Unfortunately, I'd already
committed the bump to the dist-git repo (just release inc), hope that
doesn't mind!

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

Hi,

Later today, I'll be starting with rebuilds of packages depending on icu.
The rebuilds will take place in f39-build-side-69764 for all packages
returned by repoquery --whatrequires 'libicu*.so.72()(64bit)' (list cleaned
up, converted to source package names, attached at the end of the message).

Please, if you're going to make changes in affected packages before the
side tag gets merged, make the build in the said side tag. I expect to
merge the side tag asap with most of the affected packages built and then
continue building things that take longer to build (webkit/libreoffice)
later.

I am planning to merge the side tag twice, once before the bigger packages
are built (webkitgtk, and other "long to build" packages) to minimize time
in flight to reduce possible conflicts with work of other packagers.

For stuff that may fail to build, either due to newer icu or unrelated
issues, there is a libicu72 compat package already available in rawhide, so
that should take care of FTI issues that'd arise by merging the side tag.
I'll try to help the maintainers with fixing the issues.

I'll post updates to this thread as I progress with the bump.

Packages to be rebuilt (source names):
0ad
389-ds-base
bes
boost
brltty
calamares
calibre
ceph
cfdg
community-mysql
ctdb
cyrus-imapd
darktable
dee
deepin-editor
deepin-system-monitor
dino
dovecot
dovecot-fts-xapian
enchant2
evolution-data-server
freeciv
freerdp
geary
gnome-builder
gnome-text-editor
gnucash
gnustep-base
godot
godot
gspell
harfbuzz
ibus-qt
imv
kbibtex
kdb
kdeplasma-addons
konsole5
libcdr
libe-book
libical
libkiwix
liblcf
libmspub
libphonenumber
libqalculate
libqxp
libreoffice
libtoml
libtranslit
libvisio
libzim
libzmf
maim
mapnik
mongo-c-driver
mozjs102
mozjs91
msort
ncid
ncmpcpp
nuspell
opentrep
openttd
php
php-pecl-http
plasma-workspace
poedit
postfix
postgresql
prelude-lml
prosody
pyicu
python-mapnik
qt5-qtbase
qt5-qtlocation
qt5-qtwebengine
qt5-qtwebkit
qt6-qt5compat
qt6-qtbase
qt6-qtwebengine
R
R-Cairo
R-stringi
raptor2
rpminspect
samba
scribus
seamonkey
slop
strawberry
sword
tarantool
tepl
tesseract
texlive-base
tin
tracker
tracker-miners
unar
v8-314
vte291
webkitgtk
widelands
xalan-c
xfsprogs
xiphos
yaz
yaz
znc

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Frantisek Zatloukal]

On Thu, Jul 6, 2023 at 9:58 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 06/07/2023 21:32, Michael Catanzaro wrote:
> > As explained in the proposal document, we know that opt-in metrics are
> > not very useful because few users would opt in, and these users would
> > not be representative of Fedora users as a whole.
>
> Because Linux users care about their privacy.
>

In that case, the users can opt-out, if the aggregated telemetry doesn't
fit in their privacy framework.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to use llvm15 for building a package

[Frantisek Zatloukal]

On Wed, Jul 5, 2023 at 3:25 AM Luya Tshimbalanga 
wrote:

> I confirm I run the same issue once I properly set parameters for building
> on cmake (  -DLLVM_ROOT=%{_libdir}/llvm15 \
>-DLLVM_BC_GENERATOR='clang++' \).
>

I am not sure this is what you'd want to do anyway as you'll be mixing
clang16 and llvm15.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Frantisek Zatloukal]

On Tue, Jun 27, 2023 at 8:44 PM Tomáš Hrnčiar  wrote:

> python-redis cicku kevin maxamillion
>

I've filled https://src.fedoraproject.org/rpms/python-redis/pull-request/13
, that should get python-redis going and unstuck a bunch of packages
depending on it.

Just a note, the failure wasn't caused by Python 3.12, but redis 7.2 rebase
in rawhide.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Frantisek Zatloukal]

On Tue, May 9, 2023 at 2:22 PM Petr Pisar  wrote:

> I measured cached "dnf upgrade" (i.e. DNF4) on rawhide without and with
> the modular
> repository 5 times and the times are 1.022 vs. 1.090 seconds. I.e. 6.2%
> speedup.
>

Just a note here that the speedup might be a bit larger on released Fedora
versions as there are two modular repositories that'd get disabled: base
repo and updates repository, where rawhide has just one unified base and
updates.

Also (no raw data at hand), lower perf devices/SBCs can benefit even more
from this as repo parsing takes significantly longer time there than on
desktops/laptops.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: z3 soname bump

[Frantisek Zatloukal]

On Mon, Jan 16, 2023 at 3:31 PM Lukas Zaoral  wrote:

> Hi,
> there is no need to wait for klee. Unfortunately, the package cannot be
> build
> in Rawhide at the moment since the project cannot be built with LLVM 15 and
> the llvm14 compatibility package cannot be used with clang 15 (and clang14
> is
> a library only package).
>

Yeah, I am facing the same issues with parts of the Intel stack
(intel-graphics-compiler, intel-compute-runtime). Upstream generally adds
support for newer versions of llvm, but with a bit of delay causing missing
OpenCl (and oneAPI in near future) support from newest Fedora releases.
I've always managed to push upstream/backport patches for newer llvm/clang
just a bit before another llvm stack rebase.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP: icu 72 coming to rawhide

[Frantisek Zatloukal]

On Sat, Dec 31, 2022 at 2:30 PM Pete Walter  wrote:

> This is now done. The following 4 packages failed to rebuild. The rest of
> 102 packages built fine and are all rebuilt in rawhide.
>
> mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022
> mozjs91: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691025
> mozjs102: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691005
>

All mozjs* packages fixed and rebuilt!

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

duktape soname bump

[Frantisek Zatloukal]

I wish I could write that I am going to build duktape 2.7.0 which bumps the
soname. However, my brain kind of misfired and I didn't, for some reason,
announce this upfront. The changes are minor, ABI changing stuff, I've
taken care of rebuilding all the dependencies (main maintainers of those
are in BCC):
- gerbera
- libproxy
- polkit
- python-dukpy

I am terribly sorry if it caused any trouble. I'll pay far more attention
to announce bumps before next time!

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Frantisek Zatloukal]

On Mon, Dec 12, 2022 at 1:25 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> If Intel ships all these blobs in linux-firmware, then they have a good
> reason for this, don't they?
>

So newer linux-firmware can support older kernels, which isn't relevant for
Fedora (to a degree that might be relevant upstream).

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: wlroots 0.16 update announcement

[Frantisek Zatloukal]

>From gamescope perspective, a new release would require wlroot 0.16 (commit
is already present in master), so can you cc me whenever you do wlroot 0.16
in bodhi? I'd either backport the specific commit/or a new release and add
it to the update.

I'll handle rawhide when we have a new release or when you create the f37
update, whichever is sooner, I don't think we need to hurry there.

On Sun, Dec 4, 2022 at 5:26 AM Artem Tim  wrote:

> Thanks! labwc and wayfire updated for Rawhide [1]. Please ping when you
> consider new wlroots 0.16 mature enough and start updating it for f37.
>
> [1]:
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-9bac007398
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-1bbf74fbb8
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can we retire mozjs68 in rawhide?

[Frantisek Zatloukal]

Thanks for trying, fired off the build for real, passed too, mozjs68
retired from rawhide.

I'll add it to fedora-obsolete-packages too.

On Tue, Nov 29, 2022 at 12:20 PM Florian Weimer  wrote:

> * Frantisek Zatloukal:
>
> > Hey,
> >
> > yeah, I am looking forward to throwing it away, erlang-js was changed (
> > https://github.com/erlang-mozjs/erlang-mozjs/issues/6 ) to be built
> against the new mozjs,
> > but the build has failed, so repos still contain the old version (
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=2085927 ).
>
> Hmm, a scratch build just passed?
>
> […]
>   0 free  0 open  7 done  0 failed
>
> 94687227 build (rawhide, erlang-js-1.9.3-1.fc38.src.rpm) completed
> successfully
>
> So I guess we can build it for real and then go through the motions to
> retire mozjs68?
>
> Thanks,
> Florian
>
>

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can we retire mozjs68 in rawhide?

[Frantisek Zatloukal]

Hey,

yeah, I am looking forward to throwing it away, erlang-js was changed (
https://github.com/erlang-mozjs/erlang-mozjs/issues/6 ) to be built against
the new mozjs, but the build has failed, so repos still contain the old
version ( https://koji.fedoraproject.org/koji/buildinfo?buildID=2085927 ).

Anyhow, thanks for the heads up, Florian!

On Tue, Nov 29, 2022 at 11:34 AM Kalev Lember  wrote:

> On Tue, Nov 29, 2022 at 10:44 AM Florian Weimer 
> wrote:
>
>> I don't see anything depending on it in the RPM specs file archive.
>>
>> It looks like the configure script might get confused when building with
>> future C compilers which do not accept implicit function declarations,
>> and it's probably not worth porting this to C99.
>>
>
> According to my repoquery, erlang-js still uses mozjs68:
>
> $ dnf repoquery --whatrequires mozjs68 --disablerepo='*'
> --enablerepo=rawhide
> Fedora - Rawhide - Developmental packages for the next Fedora release
>
>  36 kB/s |  10 kB 00:00
> Fedora - Rawhide - Developmental packages for the next Fedora release
>
>  23 MB/s |  64 MB 00:02
> Last metadata expiration check: 0:00:13 ago on Tue 29 Nov 2022 11:18:22 AM
> CET.
> erlang-js-0:1.9.2-6.fc37.x86_64
> mozjs68-devel-0:68.12.0-8.fc37.i686
> mozjs68-devel-0:68.12.0-8.fc37.x86_64
>
> When it is time to retire mozjs68 (apparently not yet because of
> erlang-js, but hopefully soon :) ), please add mozjs68 to
> fedora-obsolete-packages because a lot of users probably still have it
> installed and it is going to get broken deps and break the update path as
> soon as icu gets updated in rawhide.
>
> --
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mesa in F37- vaapi support disabled for h264/h265/vc1

[Frantisek Zatloukal]

Hi,

since this mesa change (
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
) in F37 and rawhide, the mesa package lost support for vaapi accelerated
encoding and decoding of h264, h265 and decoding of vc1 (
https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).

It seems like a big regression from F36 for users with GPUs with open
source drivers (mainly AMD, maybe nVidia/other non x86...), that affects
common use-cases of Fedora Workstation, like watching videos, in-house game
streaming, attending online meetings and many more.

I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in
Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion
addon to alleviate the fallout in the short term?

Thanks!

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The R stack in Rawhide is on fire

[Frantisek Zatloukal]

Huge thanks to everybody who'd helped with resolving this!

I am deeply sorry about the issues I'd caused, this was the first time I
was rebuilding a bunch of packages in a side-tag and merging it back and I
didn't realize that this is something I should be cautious about. I'll
watch out for this and be more careful next time!


On Tue, Aug 2, 2022 at 7:46 PM Kalev Lember  wrote:

> On Tue, Aug 2, 2022 at 7:27 PM Miro Hrončok  wrote:
>
>> On 02. 08. 22 19:02, Iñaki Ucar wrote:
>> > To begin with, untag Frantisek's build from f37, please. Tom prepared
>> > the side tag to rebuild the packages there, but I believe he's not
>> > currently available...
>>
>> I've opened https://pagure.io/releng/issue/10943
>
>
> I went ahead and untagged the R build, from both f37 and eln. Can someone
> make sure to rebuild R once more in the side tag so that it has a higher
> release number than the build that was just untagged? Otherwise I am fairly
> sure it's going to cause issues when merging the tag (and this also ensures
> it's correctly rebuilt against the new icu).
>
> --
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 71.1

[Frantisek Zatloukal]

Hmm,

I am really sorry for this, I'd messed up a lot somehow.

I'll take a deeper look tomorrow morning, but from a quick look:
- webkit is now being built against the new icu, passed on i686 of
architectures, it'll hopefully be done before the next compose.
- brltty was FTBFS before, however, the issue looks like the fallout from
java/i386 [0]
- libtracker-sparql was built against the new icu before the side tag
merge, so that should be a transient issue?

[0]
https://koji.fedoraproject.org/koji/getfile?taskID=89758377=DEFAULT=build.log=-4000
File not found:
/builddir/build/BUILDROOT/brltty-6.5-5.fc37.i386/usr/lib/brltty/libbrlapi_java.so
File not found:
/builddir/build/BUILDROOT/brltty-6.5-5.fc37.i386/usr/lib/java/brlapi.jar

On Tue, Aug 2, 2022 at 4:04 PM Stephen Gallagher 
wrote:

> On Mon, Aug 1, 2022 at 6:04 PM Frantisek Zatloukal 
> wrote:
> >
> >
> >
> > On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher 
> wrote:
> >>
> >> On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Later today, I'll be starting with rebuilds of packages depending on
> icu. The rebuilds will take place in f37-build-side-55935 for all packages
> returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
> attached at the end of the message).
> >> >
> >> > Please, if you're going to make changes in affected packages before
> the side tag gets merged, make the build in the said side tag. I expect to
> merge the side tag with most of the affected packages built and then
> continue building things that take longer to build (webkit/libreoffice)
> later.
> >> >
> >> > For stuff that may fail to build, either due to newer icu or
> unrelated issues, there is a libicu69 compat package already available in
> rawhide, so that should take care of FTI issues that'd arise by merging the
> side tag. I'll try to help the maintainers with fixing the issues.
> >> >
> >> > I'll post updates to this thread as I progress with the bump.
> >> >
> >> > [0]
> >> ...
> >> > v8
> >
> >
> > Yeah, I did a bunch of manual editing/checking up in the list, this
> should actually be v8-314.
>
>
> Apparently this side-tag has been merged and it broke a lot of stuff
> in Rawhide/ELN:
>
> 2022-08-02 13:20:21 [ERROR   ] Dependency check failed:
> 2022-08-02 13:20:21 [ERROR   ]  Problem 1: package
> anaconda-install-img-deps-37.11-2.eln120.ppc64le requires brltty, but
> none of the providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> libicuuc.so.69()(64bit) needed by brltty-6.5-4.eln120.ppc64le
> 2022-08-02 13:20:21 [ERROR   ]  Problem 2: package
> anaconda-widgets-37.11-2.eln120.ppc64le requires
> libgdk-3.so.0()(64bit), but none of the providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - package
> anaconda-widgets-37.11-2.eln120.ppc64le requires
> libgtk-3.so.0()(64bit), but none of the providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - package
> gtk3-3.24.34-2.eln120.ppc64le requires
> libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
> installed
> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> libicui18n.so.69()(64bit) needed by
> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> libicuuc.so.69()(64bit) needed by
> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> 2022-08-02 13:20:21 [ERROR   ]  Problem 3: package
> nm-connection-editor-1.28.0-2.eln120.ppc64le requires
> libgdk-3.so.0()(64bit), but none of the providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - package
> nm-connection-editor-1.28.0-2.eln120.ppc64le requires
> libgtk-3.so.0()(64bit), but none of the providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - package
> gtk3-3.24.34-2.eln120.ppc64le requires
> libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
> installed
> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> libicui18n.so.69()(64bit) needed by
> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> libicuuc.so.69()(64bit) needed by
> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> 2022-08-02 13:20:21 [ERROR   ]  Problem 4: package
> anaconda-gui-37.11-2.eln120.ppc64le requires yelp, but none of the
> providers can be installed
> 2022-08-02 13:20:21 [ERROR   ]   - package
> anaconda-37.11-2.eln120.ppc64le requi

Re: [rawhide] ICU upgrade to 71.1

[Frantisek Zatloukal]

On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher 
wrote:

> On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal 
> wrote:
> >
> > Hi,
> >
> > Later today, I'll be starting with rebuilds of packages depending on
> icu. The rebuilds will take place in f37-build-side-55935 for all packages
> returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
> attached at the end of the message).
> >
> > Please, if you're going to make changes in affected packages before the
> side tag gets merged, make the build in the said side tag. I expect to
> merge the side tag with most of the affected packages built and then
> continue building things that take longer to build (webkit/libreoffice)
> later.
> >
> > For stuff that may fail to build, either due to newer icu or unrelated
> issues, there is a libicu69 compat package already available in rawhide, so
> that should take care of FTI issues that'd arise by merging the side tag.
> I'll try to help the maintainers with fixing the issues.
> >
> > I'll post updates to this thread as I progress with the bump.
> >
> > [0]
> ...
> > v8
>

Yeah, I did a bunch of manual editing/checking up in the list, this should
actually be v8-314.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing fmt library soversion bump

[Frantisek Zatloukal]

On Wed, Jul 20, 2022 at 4:24 PM Mamoru TASAKA 
wrote:

> Vitaly Zaitsev via devel wrote on 2022/07/11 2:43:
> 0ad FTBFS on f37 due to different issue from fmt change - scratch build
> for F-37 shows virtualenv related
> issue - perhaps due to python3.11 changes, and scratch build for F-36
> shows some rust(?) related error,
> which is beyond my knowledge currently.
>

The python 3.11 compat should work with
https://src.fedoraproject.org/rpms/mozjs78/blob/rawhide/f/0001-Python-Build-Use-r-instead-of-rU-file-read-modes.patch
which I'd made for mozjs78 which is what 0ad is currently using.


> Note that rawhide 0ad currently linked against boost1.76 - while rawhide
> boost is already 1.78,
> so 0ad is FTI even if fmt8 package is introduced anyway currently.
>
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[rawhide] ICU upgrade to 71.1

[Frantisek Zatloukal]

Hi,

Later today, I'll be starting with rebuilds of packages depending on icu.
The rebuilds will take place in f37-build-side-55935 for all packages
returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
attached at the end of the message).

Please, if you're going to make changes in affected packages before the
side tag gets merged, make the build in the said side tag. I expect to
merge the side tag with most of the affected packages built and then
continue building things that take longer to build (webkit/libreoffice)
later.

For stuff that may fail to build, either due to newer icu or unrelated
issues, there is a libicu69 compat package already available in rawhide, so
that should take care of FTI issues that'd arise by merging the side tag.
I'll try to help the maintainers with fixing the issues.

I'll post updates to this thread as I progress with the bump.

[0]
0ad
389-ds-base
bes
boost
brltty
calamares
calibre
ceph
cfdg
community-mysql
cyrus-imapd
darktable
dee
deepin-editor
deepin-system-monitor
dino
dovecot
dovecot-fts-xapian
enchant2
evolution-data-server
focuswriter
freeciv
freerdp
geary
gnome-text-editor
gnucash
gnustep-base
gspell
harfbuzz
ibus-qt
idzebra
imv
kbibtex
kdb
libcdr
libe-book
libical
libkiwix
liblcf
libmspub
libphonenumber
libqalculate
libqxp
libreoffice
libtoml
libtranslit
libvisio
libzmf
maim
mapnik
mongo-c-driver
mozjs68
mozjs91
msort
ncid
ncmpcpp
nuspell
opentrep
openttd
php
php-pecl-http
plasma-workspace
poedit
postfix
postgresql
prelude-lml
prosody
pyicu
python-mapnik
qt5-qtbase
qt5-qtlocation
qt5-qtwebengine
qt5-qtwebkit
qt6-qt5compat
qt6-qtbase
R
R-stringi
raptor2
rpminspect
samba
scribus
seamonkey
slop
sword
tarantool
tesseract
texlive
tin
tracker
tracker-miners
unar
v8
vte291
webkit2gtk3
widelands
xalan-c
xfsprogs
xiphos
yaz
yaz
zimlib
znc

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: python-redis 4.2.1

[Frantisek Zatloukal]

I am planning to build a new python-redis version in Rawhide/f37 (
https://src.fedoraproject.org/rpms/python-redis/pull-request/7# ).

The current f37 build 3.5.3 is pretty old. The upstream does a good job of
writing changelogs for anyone interested/affected:
https://github.com/redis/redis-py/releases

I've test-rebuilt all the packages which BR python-redis:
https://copr.fedorainfracloud.org/coprs/frantisekz/redis-4/builds/ ; the
only related failure is RediSearch (further explained in the linked PR),
the other failure is python-django, which is FTBFS in rawhide.

I'll handle all the rebuilds of packages BuildRequiring and Requiring
python-redis in a side-tag, I'll reply here with the exact side-tag once it
gets created if somebody wants to build their package there.

Apart from updating to the latest and freshest release, this will allow us
to start the el9 branch of python-redis with up-to-date version.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bugzilla - API Authentication changes

[Frantisek Zatloukal]

On Wed, Feb 9, 2022, 07:44 Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> So, I've updated review-stats container to run on F34 with
> python-bugzilla 3.2.0, but it still authenticate using
> username+password. Is that enough to avoid authentication errors and
> user ban or I need to change the authentication method?
>

>From what we've seen with Blockerbugs app (
https://pagure.io/fedora-qa/blockerbugs/issue/230 ;
https://pagure.io/fedora-qa/blockerbugs/issue/231 ) , it seems you won't be
able to use username+password at all and bugzilla api key will be the only
api-friendly method of auth. You can give it a shot with testing bugzilla:
https://bugzilla.stage.redhat.com/

The error text that Bugzilla throws back at us when trying to login with
username/pass is:

You have attempted to access the API either using an unsupported method or
> using one or more unsupported parameters. You must use the 'Authorization'
> header to authenticate to the API and you must remove all unsupported
> parameters from the query. The unsupported parameters are: Bugzilla_login,
> Bugzilla_password, Bugzilla_token, Bugzilla_api_key. See
> https://bugzilla.stage.redhat.com/docs/en/html/api/core/v1/general.html#authentication
> for details on using the 'Authorization' header. at
> /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Frantisek Zatloukal]

So, going over FTBFS bugs I've seen against bunch of my packages since the
mass rebuild, there is bunch of "undefined reference to
`std::type_info::operator==(std::type_info const&) const'" returned by ld,
affecting only armv7hl arch. The affected packages are: mozjs68, mozjs78,
mozjs91. I've tried to rebuild mozjs91 once again, but it failed the same
way: https://koji.fedoraproject.org/koji/taskinfo?taskID=82187552

Is there any way I can help?

Thanks!

On Wed, Jan 26, 2022 at 1:42 PM Jakub Jelinek  wrote:

> On Wed, Jan 26, 2022 at 01:36:43PM +0100, Jakub Jelinek wrote:
> > On Wed, Jan 26, 2022 at 01:29:37PM +0100, Dan Horák wrote:
> > > > > **Compilation error from a dependency header:**
> > > > >
> > > > > dependency “boost”: “# error "Never use  directly;
> include
> > > > >  instead."”, via
> > > > > boost/multiprecision/cpp_int/intel_intrinsics.hpp
> > > >
> > > > This is weird.
> > > > bmiintrin.h had:
> > > > #ifndef _X86GPRINTRIN_H_INCLUDED
> > > > # error "Never use  directly; include 
> instead."
> > > > #endif
> > > > in both gcc 11 and 12.  In fact, most of the more recent *intrin.h
> headers
> > > > want users to only use one of x86intrin.h, x86gprintrin.h or maybe
> > > > immintrin.h.
> > >
> > > this is being discussed in
> > > https://github.com/boostorg/multiprecision/issues/419
> >
> > Ah, ppc*, that indeed looks like a gcc bug.
>
> https://gcc.gnu.org/PR104239
>
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Frantisek Zatloukal]

On Tue, Jan 18, 2022 at 12:25 PM Jonathan Wakely  wrote:

> PR sent:
> https://github.com/intel/intel-graphics-compiler/pull/226
>

Thanks! Added a comment to that, works flawlessly!


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Frantisek Zatloukal]

On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:

> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>

While I was trying to rebuild some Intel components, i've encountered this
issue, which seems to be caused by libstdc. It affects
intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
however, since gcc/libstdc 12, I am hitting this:

/builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair') is ambiguous
  auto [i, isInserted] = LiveRangeMap.insert(LiveRangeMap_t::value_type(V,
0));
 ^  
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
= llvm::genx::LiveRange *, $2 = true]
  constexpr pair(const _T1& __a, const _T2& __b)
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
true]
   constexpr pair(_U1&& __x, __null_ptr_constant)
 ^
1 error generated.

I've tried to locally recompile clang and llvm against the new libstdc (as
it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being met),
but that didn't help. Maybe I am missing some library that needs to be
recompiled too. Anyhow, is this expected behavior?

The affected file is this one:
https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 builds failing for a while now

[Frantisek Zatloukal]

So, it seems it didn't come to my mind that builders might not have new
enough rpm to use rpm.open() which is available since rpm 4.17.0.

A fix for it (
https://src.fedoraproject.org/rpms/authselect/pull-request/15# ) has been
merged, old authselect untagged, the new build of authselect should
hopefully behave well now and builds of other packages should start working
soon (after the local repo gets updated).

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 builds failing for a while now

[Frantisek Zatloukal]

On Tue, Dec 28, 2021 at 5:58 PM Ian McInerney via devel <
devel@lists.fedoraproject.org> wrote:

> That is a different error during the transaction. The original warning I
> mentioned is in dbus-broker, and is only a warning (the RPM transaction
> continues with no error). The other two you have are in the authselect-libs
> package, and they appear to be caused by the change to using lua for the
> pre scriplets in
> https://src.fedoraproject.org/rpms/authselect/c/00f6a084f99e2a9ee9ceaaad3d4896e4bfc591dd?branch=rawhide.
> It is probably best to open a BZ against the authselect component with
> those errors.
>

No need to open bz, I am reading emails throughout the holidays :)

I am taking a look at it, and will try to make a PR asap, sorry for the
breakage. It is weird that it fails on rpm.open() though, if I've
understood the documentation correctly, it should be available anytime.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Voluntarily step back as co-maintainer?

[Frantisek Zatloukal]

On Wed, Nov 24, 2021 at 11:58 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Try removing yourself from ACL, i.e.:
> 1. Go to https://src.fedoraproject.org/rpms/glabels and login
> 2. Click on Settings tab
> 3. Click on Users & Groups
> 4. Click on the red "trash" icon next to your FAS name
>
>
I am afraid this won't work for commit rights, which seems it's what Maxim
has. I don't know about any other way than contacting somebody with higher
ACLs on that project or maybe creating an infra ticket (
https://pagure.io/fedora-infrastructure/issues ).


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Firefox Hardware acceleration & VA-API how-to

[Frantisek Zatloukal]

On Fri, Nov 12, 2021, 11:08 Florian Weimer  wrote:

> Why is libva-intel-driver not part of Fedora?
>
> Thanks,
> Florian
>

There are licensing / patent issues with the Intel driver. I am slowly
progressing with packaging the latest intel-media-driver (not the older
libva-intel-driver, and freed from patented stuff) into Fedora, but it'll
take some time and some upstream help / assistance.

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Qa-tools-sig] Orphaned packages looking for new maintainers​

[Frantisek Zatloukal]

On Mon, Nov 8, 2021 at 4:53 PM Miro Hrončok  wrote:

>
> python-pylibmcabompard, orphan, pjp1 weeks
> ago
>

Taken.


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?

[Frantisek Zatloukal]

Hi,

in testcloud (
https://pagure.io/testcloud/blob/master/f/testcloud/util.py#_100 ), I am
using adam's openqa nightlies.json for rawhide/branched:
https://openqa.fedoraproject.org/nightlies.json (this isn't a "stable api")

and https://getfedora.org/releases.json for stable releases.

For programmatically determining which are the current fedora releases, I
am using oraculum's
https://packager-dashboard.fedoraproject.org/api/v1/releases (this wouldn't
change nor break).

Hope it helped at least a bit!

On Tue, Oct 12, 2021 at 7:53 PM Neal Gompa  wrote:

> Hey all,
>
> I'm working on extending quickemu[1] to be able to easily spin up
> Fedora VMs, but our lack of a static URL formula for fetching ISOs
> makes this a bit difficult.
>
> Do we have some kind of API endpoint that has the necessary
> information for this? It'd be nice to be able to fetch some kind of
> JSON file with the necessary information so that tools can fetch it
> programmatically...
>
> Thanks in advance and best regards!
>
> [1]: https://github.com/wimpysworld/quickemu
>
> --
> 真実はいつも一つ！/ 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora Packager Dashboard - Contextual Package Calendars and more!

[Frantisek Zatloukal]

Hi,

In the past months, we've enabled "Contextual Package Calendars" on Fedora
Packager Dashboard .

In short, it shows you package-specific calendars, eg. If you maintain some
GNOME package, the Dashboard will show you the GNOME release schedule. This
currently works for GNOME and Python Interpreter package maintainers.

If you're interested in such a feature for other/your packages, I'd like to
ask you to take a look at https://pagure.io/package-calendars . The process
of adding an ical and connecting it to relevant packages is described in
the README.md and you can take a look at existing definitions for GNOME and
Python in calendars
 directory.

You can see the feature in action on my dashboard (GNOME) or churchyard's
dashboard (Python):
https://packager-dashboard.fedoraproject.org/user/frantisekz
https://packager-dashboard.fedoraproject.org/user/churchyard

To sum up some other news since the last posting about the dashboard:
- we have enabled FAS sign-in (you can find an option to do this in the
setting menu) so you can see private bugs
- we have added support for ABRT/Retrace data for your packages, you'll be
able to see if there are any issues at the Retrace server for your package
and see outlying problems explicitly

What we are working on:
- "Dashboard Builder" - you'll be able to compose your own dashboard from
multiple users and multiple packages and share a link to it between your
colleagues and co-maintainers
- API documentation - if you'd like to use the data from Packager Dashboard
in your apps/services, you can currently visit
https://packager-dashboard.fedoraproject.org/api/ and we will soon
provide some developer friendly documentation for it.

In the end, if you have more ideas, bug reports, please go ahead and file a
ticket on https://pagure.io/fedora-qa/packager_dashboard .


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F35 mass rebuild is finished

[Frantisek Zatloukal]

On Fri, Jul 30, 2021, 16:12 Florian Weimer  wrote:

> Does this change only impact source packages which use the %cmake3
> macro, or potentially more packages?
>

I've seen a similar failure with wine-dxvk Fedora package, which uses
meson/ninja.

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Frantisek Zatloukal]

On Wed, Jun 16, 2021 at 2:20 PM Florian Weimer  wrote:

> On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”.
> If x86-64-v2 shows up as “supported”, there is compatibile:
>
> | Subdirectories of glibc-hwcaps directories, in priority order:
> |   x86-64-v4
> |   x86-64-v3 (supported, searched)
> |   x86-64-v2 (supported, searched)
>
>
Hmm, I am wondering if we can't use output from that and gather this
information as a part of DNF Count Me?

We'll at least gather information about capabilities of Fedora users
hardware.


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Planned Outage - Blockerbugs - 2021-05-18 17:00 UTC

[Frantisek Zatloukal]

There will be an outage starting at 2021-05-18 17:00UTC,
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-05-18 17:00UTC'

Reason for outage:

Host upgrade from Fedora 32 to Fedora 33.

Affected Services:

https://qa.fedoraproject.org/blockerbugs/

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/9958

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
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

Planned Outage - Blockerbugs - 2021-05-18 17:00 UTC

[Frantisek Zatloukal]

There will be an outage starting at 2021-05-18 17:00UTC,
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-05-18 17:00UTC'

Reason for outage:

Host upgrade from Fedora 32 to Fedora 33.

Affected Services:

https://qa.fedoraproject.org/blockerbugs/

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/9958

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 

Best regards / S pozdravem,

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

Re: selinux-policy package versioning change

[Frantisek Zatloukal]

On Wed, Mar 31, 2021 at 9:04 AM Zdenek Pytela  wrote:

> The freeze is on Tuesday, the plan is Monday, or after GA if it fails for
> some reason.
>

Beware that bodhi is active for Fedora 34, so the update would need to
receive necessary karma to be actually pushed before the freeze (I think
the final pre-freeze push is happening around 2/3 PM CET on Tuesday?).


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora Packager Dashboard - Available for wide use to all packagers

[Frantisek Zatloukal]

Hi,

We'd like to announce that the Fedora Packager Dashboard passed the testing
period, was properly deployed inside Fedora Infrastructure, got fixes,
improvements and feature additions and is now available for widespread use
among all Fedora Packagers.

For those of you who didn’t hear about the Dashboard yet, It combines all
relevant information for package maintainers into one web application with
searching and both simple and advanced (regex based) filtering
possibilities. You’ll find things like open bug reports, updates,
overrides, FTBFS (from koschei and from Fedora Health Check by decathorpe)
and FTI reports, pull requests and orphan/retire warnings not only for your
packages directly, but even for packages you depend on. It’s designed to
make a packager's life easier and save our packagers some of their time. An
article showing it’s current features is available on Fedora Community
Blog: https://communityblog.fedoraproject.org/fedora-packager-dashboard/
. There
will also be a talk about the Dashboard on DevConf.cz 2021:
https://devconfcz2021.sched.com/event/gmLm/packager-dashboard-life-of-packager-made-easy
.

Dashboard itself is available: https://packager-dashboard.fedoraproject.org/

(the Dashboard is automatically pulling new data every 15 minutes, so you
can just leave it open in one of your browser tabs and don’t worry about
reloading it :) )

Fedora Packager Dashboard leverages caching in the Oraculum backend to
significantly speed-up loading times with comparison to querying all the
relevant resources separately. We, of course, can't cache the entire
Bugzilla, Pagure, Bodhi... so we only cache data for users who

visit Packager Dashboard at least once per 14 days. Please keep in mind
that the first load for a “new” user might take a while. Most of the data
sources are refreshed every hour.

You can use the Dashboard for individual accounts as well as for FAS groups.

While the testing period is behind us and we have everything properly
deployed, the work doesn’t end here. We have longer term plans for even
more stuff for the dashboard. On the top of our list currently sit support
for private bugs (visible after you authenticate with FAS), and contextual
schedules and calendars for packages you might be interested in (eg. Do you
maintain some Python packages? You might want to have a Python Release
Calendar on your dashboard.)

Feel free to provide ideas or bug reports at
https://pagure.io/fedora-qa/packager_dashboard or simply send an email
reply to this thread with all kinds of feedback.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
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

Fedora Packager Dashboard - Available for wide use to all packagers

[Frantisek Zatloukal]

Hi,

We'd like to announce that the Fedora Packager Dashboard passed the testing
period, was properly deployed inside Fedora Infrastructure, got fixes,
improvements and feature additions and is now available for widespread use
among all Fedora Packagers.

For those of you who didn’t hear about the Dashboard yet, It combines all
relevant information for package maintainers into one web application with
searching and both simple and advanced (regex based) filtering
possibilities. You’ll find things like open bug reports, updates,
overrides, FTBFS (from koschei and from Fedora Health Check by decathorpe)
and FTI reports, pull requests and orphan/retire warnings not only for your
packages directly, but even for packages you depend on. It’s designed to
make a packager's life easier and save our packagers some of their time. An
article showing it’s current features is available on Fedora Community
Blog: https://communityblog.fedoraproject.org/fedora-packager-dashboard/
. There
will also be a talk about the Dashboard on DevConf.cz 2021:
https://devconfcz2021.sched.com/event/gmLm/packager-dashboard-life-of-packager-made-easy
.

Dashboard itself is available: https://packager-dashboard.fedoraproject.org/

(the Dashboard is automatically pulling new data every 15 minutes, so you
can just leave it open in one of your browser tabs and don’t worry about
reloading it :) )

Fedora Packager Dashboard leverages caching in the Oraculum backend to
significantly speed-up loading times with comparison to querying all the
relevant resources separately. We, of course, can't cache the entire
Bugzilla, Pagure, Bodhi... so we only cache data for users who

visit Packager Dashboard at least once per 14 days. Please keep in mind
that the first load for a “new” user might take a while. Most of the data
sources are refreshed every hour.

You can use the Dashboard for individual accounts as well as for FAS groups.

While the testing period is behind us and we have everything properly
deployed, the work doesn’t end here. We have longer term plans for even
more stuff for the dashboard. On the top of our list currently sit support
for private bugs (visible after you authenticate with FAS), and contextual
schedules and calendars for packages you might be interested in (eg. Do you
maintain some Python packages? You might want to have a Python Release
Calendar on your dashboard.)

Feel free to provide ideas or bug reports at
https://pagure.io/fedora-qa/packager_dashboard or simply send an email
reply to this thread with all kinds of feedback.
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Frantisek Zatloukal]

On Wed, Feb 10, 2021 at 11:27 PM Debarshi Ray  wrote:

> Hey,
>
> I wanted to respond earlier, but it totally slipped my mind.
>
> We'd totally use releasestream in Toolbox for mapping the string
> "rawhide" to a numeric version:
> https://github.com/containers/toolbox/issues/646
>
> Cheers,
> Rishi
>

You (and anybody else, ofc :) ) can take a look at the packager dashboard
before Adam deploys releasestream. It exposes Fedora release information on
https://packager-dashboard.fedoraproject.org/api/v1/releases . It's  based
on fedfind, with some more logic and information processing in the
background.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Qa-tools-sig] Orphaned packages looking for new maintainers

[Frantisek Zatloukal]

On Mon, Feb 8, 2021 at 4:57 PM Miro Hrončok  wrote:

> python-flask-openid  orphan, pjp, sundaram 0 weeks
> ago
>

Taken. We still need that for blockerbugs, sigh.

It's dead upstream, replaced by oidc. I'll try to poke others depending on
this (eg. copr) once we finish migration and retire it once completed.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Beware: Querying a group's projects on src.fp.o and pagure.io currently broken

[Frantisek Zatloukal]

On Fri, Feb 5, 2021 at 6:01 PM Fabio Valentini  wrote:

> Hi everybody,
>
> Since the last pagure version was deployed, the API for querying a
> group's packages (api/0/group/foo?projects=true) was broken - it is
> now paginated, where before it was not:
>
> https://pagure.io/pagure/issue/5110
>
> Note that it does not return any error code, but instead just gives
> only the first 20 results instead of all of them.
>
> Additionally, the paginated query is currently broken, querying pages
> 2 and later returns zero results:
>
> https://pagure.io/pagure/issue/5111
>
> This is hopefully fixed quickly, as it is now impossible to query
> pagure for a group's packages / projects via the API.
>
> 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
>


Thanks for the email Fabio,
beware that the fedora packager dashboard (
https://packager-dashboard.fedoraproject.org/ ) is affected by this too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Frantisek Zatloukal]

On Tue, Feb 2, 2021 at 10:26 PM Marius Schwarz 
wrote:

> Am 02.02.21 um 21:58 schrieb Matthew Miller:
> > On Tue, Feb 02, 2021 at 12:36:36PM -0800, Kevin Fenzi wrote:
> >> landed (from koji) and gnome-shell did crash while upgrading. I did of
> >> course have the dnf running in a tmux session, but just a heads up for
> >> anyone upgrading via dnf live... your session may go away, so please use
> >> tmux/screen or offline updates.
> > And worth repeating: lookit this nice new functionality...
> >
> > sudo dnf offline-upgrade download
> > sudo dnf offline-upgrade reboot
> >
> >
> # dnf offline-upgrade
> Kein solcher Befehl: offline-upgrade. Bitte /usr/bin/dnf --help verwenden.
> It could be a DNF plugin command, try: "dnf install
> 'dnf-command(offline-upgrade)'" (failed too)
>
> and there is no seperate dnf package for this cmd, at least i can't see
> one adhoc.
>

It should be dnf-plugin-system-upgrade .

I think I've seen a response from the dnf team somewhere that they're aware
of this not great of an UX and will fix that somehow, I am not going to be
able to find that to quote I am afraid.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

[Frantisek Zatloukal]

There will be an outage starting at 2021-02-02 08:00 UTC,
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-02-02 08:00UTC'

Reason for outage:

Moving the project from its temporary server to the final, production
hosting.

Affected Services:

Fedora Packager Dashboard - you can use staging instance for the time
being: https://packager-dashboard.stg.fedoraproject.org/
Fedora Easy Karma - fast pre cached data from bodhi via oraculum won't be
available, the app automatically falls back to the old and slow data
fetching directly from Bodhi

Ticket Link: https://pagure.io/fedora-infrastructure/issue/9612

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

[Frantisek Zatloukal]

There will be an outage starting at 2021-02-02 08:00 UTC,
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-02-02 08:00UTC'

Reason for outage:

Moving the project from its temporary server to the final, production
hosting.

Affected Services:

Fedora Packager Dashboard - you can use staging instance for the time
being: https://packager-dashboard.stg.fedoraproject.org/
Fedora Easy Karma - fast pre cached data from bodhi via oraculum won't be
available, the app automatically falls back to the old and slow data
fetching directly from Bodhi

Ticket Link: https://pagure.io/fedora-infrastructure/issue/9612

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

[EPEL-devel] Re: [EPEL7] Celery stack update & Python 3 enablement

[Frantisek Zatloukal]

On Mon, Oct 5, 2020 at 7:09 PM Kevin Fenzi  wrote:

> How big are the changes between 4.2.2 and 4.3?
>

So, I finally got back to this, sorry for the late reply. After reading
through kombu 4.3 changelog [0], it seems the only truly breaking change is
in SQLAlchemy transport ( I can be wrong, of course) which would require
manual intervention in the database:

"Added an index to the Message table for the SQLAlchemy transport."


>From what I understand, using SQLAlchemy for celery/kombu is pretty niche
and documentation mentions and most applications around the world I was
able to find are using different backends for celery (RabbitMQ, Redis).

The plan will be to leave the upgraded stack for a long time in testing, I
was thinking about something like a month or two. I'll definitely send an
announcement once the stack is in testing repo and then (week or two)
before pushing it to epel stable.

[0] https://docs.celeryproject.org/projects/kombu/en/v4.3.0/changelog.html
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] [EPEL7] Celery stack update & Python 3 enablement

[Frantisek Zatloukal]

Hi,

I've recently begun maintaining celery stack in Fedora and Fedora EPEL.

I am in process of enabling python 3 builds of celery for EPEL 7, testing
copr (in working state with at least redis backend) is available here for
anyone interested:
https://copr.fedorainfracloud.org/coprs/frantisekz/celery_epel_py3/

I am also planning to update all parts of celery to the latest minor
versions while I am making packaging changes. python-(vine, amqp, celery)
are all fine with only tiny changes there, however, python-kombu is a
little bit more complicated.

Current kombu version in EPEL 7 is borked [0] and removed by the upstream
from pypi [1]. Long story short, they've accidentally released master
branch as kombu-4.2.2 in the past and that bad release is part of EPEL 7. I
can leave it as it is, or move to a proper, kombu 4.3 release.

>From what I understand, 3rd party applications/scripts/whatever should be
using celery and not kombu directly. Current celery version present  in
EPEL 7 works just fine with kombu 4.3 [2], I did some testing and haven't
hit any issues , it doesn't seem 3rd party applications using celery would
break/need any changes for newer kombu.

What are your opinions about this?

[0] https://github.com/celery/kombu/issues/966
[1] https://github.com/celery/kombu/issues/974
[2]
https://github.com/celery/celery/commit/1571d414461f01ae55be63a03e2adaa94dbcb15d


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Frantisek Zatloukal]

On Mon, Sep 21, 2020, 23:59 Dan Čermák 
wrote:

> Miro Hrončok  writes:
>
> > winetricksorphan, raphgro, tc010
> weeks ago
>
> Any particular reason why winetricks got orphaned?
>

Taken.

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

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Frantisek Zatloukal]

On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation media.
>
> == Owner ==
> * Name: [[User:bkhomuts|Bohdan Khomutskyi]]
> * Email: bkhom...@redhat.com
>
>
I think we should aim for faster installations and lower cpu usage (zstd),
not smaller ISO size (xz).

Saving 142 MBs isn't going to make a huge difference in download times
(disclaimer: I don't know how is the internet connection
speed in other areas, I have not that fast connection of 200mbps down
(slowest possible in my area), so 142 MB saving would make roughly 6
seconds difference myself).

On the other hand, saving minutes in the installation process (as seen with
zstd if I am reading the numbers correctly) is not only going to help users
with installation times, but also us, Fedora QA, with faster testing, both
manual and automated (OpenQA).

Also, (I am not a marketing expert) I think that having a faster
installation process with slightly larger download is going to make the
installation process feel faster and help Fedora perception.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Packager Dashboard available for testing

[Frantisek Zatloukal]

On Mon, Aug 17, 2020 at 10:36 PM Dan Čermák 
wrote:

> I know it has been a while since you sent around this email, but does
> the packaging dashboard expose the shown information via an API?


Hi,

it does. API for packager dashboard is provided by oraculum, which is
available here: https://packager.fedorainfracloud.org:5000/ (be sure to
have https there when accessing it) .

Packager Dashboard uses mostly the
https://packager.fedorainfracloud.org:5000/api/v1/packager_dashboard/ endpoint
(you add just user/group name to the end of the url).

Just be cautious that the api is not stable and is still evolving and
changing from time to time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 Change proposal: DXVK as default wined3d backend on VK capable hardware (Self-Contained Change)

[Frantisek Zatloukal]

On Thu, Jul 23, 2020 at 2:18 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Is Vulkan supported on AMD Radeon HD 7900 series (TAHITI)? Some
> sources I found say it is:
>
> https://vulkan.gpuinfo.org/listreports.php?devicename=AMD%20Radeon%20HD%207900%20Series
> but vulkaninfo just gives me an error despite my having
> mesa-vulkan-drivers installed.
>

On this generation of GPUs, you'd need to use an AMDGPU driver instead of
RadeonSI to get Vulkan Support. You can do that by adding
'radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1
amdgpu.cik_support=1' to your kernel cmdline. vulkaninfo shouldn't output
any errors after doing that.

The default driver for CGN 1.0 cards might be changed to AMDGPU in the
future.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Packager Dashboard available for testing

[Frantisek Zatloukal]

On Fri, Jun 26, 2020 at 12:10 AM Iñaki Ucar  wrote:

> Yesterday I fixed a FTBFS, but it's still showing in my dashboard. I
> suppose that it takes some time to update, but how long should I
> expect it to show there until I should suspect that there's some bug?
>
> Iñaki
>

Yeah, we are having some issues with server performance and dashboard is
missing some cache syncs.

I've fixed all profiles with the old cache on friday and we're going to
implement some better monitoring and workarounds early next week.

You can see last sync time in the bottom of the page and if it's older than
roughly 2-3 hours, there are some issues server side.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Packager Dashboard available for testing

[Frantisek Zatloukal]

On Tue, Jun 23, 2020 at 9:15 PM Artem Tim  wrote:

> It's awesome, but for some reason my profile not showing here. Just gray
> background. :(
> https://packager.fedorainfracloud.org/atim
>
>
There were some caching/data consistency issues on the server due to
overload, I've manually fixed your profile, should work now :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Frantisek Zatloukal]

On Fri, Jun 5, 2020 at 9:57 AM Kevin Kofler  wrote:

> Ben Cotton wrote:
> > == Summary ==
> > Fedora has historically forced packages to build with GCC unless the
> > upstream project for the package only supported Clang/LLVM.  This
> > change proposal replaces that policy with one where compiler selection
> > for Fedora follows the package's upstream preferences.
> >
> > == Owner ==
> > * Name: Jeff Law
> > * Email: l...@redhat.com
>
> I am opposed to this change. Chromium and Firefox build fine with GCC. I
> think that a distribution should be built with a consistent toolchain
> wherever possible.
>
> Last I checked, there were several reasons why GCC is preferred over
> Clang/LLVM in Fedora. And if that should ever change (or have changed
> already), then switching the systemwide default (reversing the rules,
> i.e.,
> using GCC only for those packages that do not build with Clang) should be
> envisioned. But as far as I know, that is not the case at this time,
> considering runtime performance, security features, etc.
>
> I do not see why we should allow yet another special case for Firefox, nor
> why we should let random packages make their own choice of compiler and
> risk
> running into hidden binary incompatibilities. We have a system compiler
> for
> a reason.
>

I don't think we should force Fedora Contributors (Packagers) to change/fix
their packages to compile with GCC if upstream decides, supports and tests
GCC. There are tons of gcc specific patches in chromium [0], there were
some issues in Firefox [1]. Apart from browsers, LibreOffice is going to
use LLVM/Clang from Release 7.0 too, so that would potentially be another
added work to LibreOffice packagers in the future.

I believe we should make packaging as easy as possible and allowing
packagers to work with compilers that have upstream support is a great way
to make their lives easier.

I don't know how much of an issue is currently
missing -fstack-clash-protection support LLVM, but if Mozilla distributes
official Firefox binaries without that flag, Google distributes Chrome
without it, I feel it's not a big deal.

[0]
https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_205
# To line 250
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1601707
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Frantisek Zatloukal]

I am +1 for this change, I don't have any numbers but from day-to-day
usage, both my systems seem far more responsive when swapping to zram
instead of swap.

On Fri, Jun 5, 2020 at 8:56 AM Kevin Kofler  wrote:

> I do not think it is safe to assume that zram is sufficient to completely
> replace disk swap. We do not know how much RAM is actually available on
> all
> users' machines, and the compressibility of RAM contents depends on the
> individual user's workloads.
>

I believe having zram as a high priority swap and then normal swap with
lower priority to be used when zram gets filled up might be an option too
(I am not saying we should go that route, just mentioning it's a
possibility).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Frantisek Zatloukal]

On Fri, Jun 5, 2020 at 9:11 AM Igor Raits 
wrote:

> Also we probably should mention that -fstack-clash-protection is not
> available in clang, so in theory binaries can be less secure due to
> that.
>

This seems to be worked on as per https://reviews.llvm.org/D68720?id=224102 (on
x86, I am not sure on what arches GCC supports -fstack-clash-protection ).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

[Frantisek Zatloukal]

On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely 
wrote:

> On 03/06/20 12:35 +0200, Till Hofmann wrote:
> >
> >
> >On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> >> ### C++  includes
> >>
> >> Several packages failed to build because they couldn't find C++
> >> Standard Library algorithms:
> >
> >> freeopcua: error: 'for_each' is not a member of 'std'
> >
> >I don't see a changelog entry (or a commit), did you only update the
> >changelog if the build was successful?
>
> Yes.
>
> >I'll fix this as soon as boost 1.73 shows up in rawhide.
>
> It's already there.


Just note that it is in Rawhide, but you might not get it in mock and/or
system update before next Rawhide compose. It is in buildroot however as
can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Urgently downgrade xorg-x11-drv-intel

[Frantisek Zatloukal]

On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov 
wrote:

> >>
> >> Is koji still fc31? My problematic rebuilds are obviously fc32.
> >
> >
> > All the scratch builds I spawned for this issue are for F32 of course.
>
> I am pondering a compiler bug. Your scratch builds are fine so it
> seems. What if you rebuild without koji on your desktop using shiny
> Fedora 32.
>

Are you using mock for local rebuilds? It should behave in the same way as
koji does...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Clang/LLVM mismatch in F32?

[Frantisek Zatloukal]

Thank you & Kevin for the quick fix! It is solved!

On Tue, Mar 17, 2020 at 7:23 PM Mohan Boddu  wrote:

> A short history of why it happened, when we lift the freeze, we check
> if all the packages that are in the stable tag are the latest builds,
> if not, we tag the latest builds into koji stable tag. We do this
> because, bodhi doesn't follow the latest build order while pushing
> updates, so, an older version gets tagged after the newer version if
> both updates are stuck during freeze.
>
> In this case, the nvr comparison failed since the release of rc1 is
> higher than the release of rc2.
>
> Anyway, this should be fixed now.
>
> On Tue, Mar 17, 2020 at 8:27 AM Michael Cronenworth 
> wrote:
> >
> > On 3/17/20 7:00 AM, Frantisek Zatloukal wrote:
> > >
> > > I am trying to rebuild mozjs68 in F32[0] (passed in rawhide just
> fine[1]), which
> > > buildrequires clang and llvm. However, clang and llvm versions
> mismatch in F32
> > > buildroot:
> > >
> > > clang   x86_64 10.0.0-0.2.*rc1*.fc32
> > > llvmx86_64 10.0.0-0.1.*rc2*.fc32
> > >
> > > which seems to cause errors like:
> > > DEBUG: | /usr/bin/clang: symbol lookup error:
> /lib64/libclang-cpp.so.10: undefined
> > > symbol: _ZN4llvm20CrashRecoveryContext11HandleCrashEv, version LLVM_10
> > >
> > > What is weird is that clang-10.0.0-0.1.rc2.fc32 is in F32 stable
> updates for some
> > > time already:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-7e1fca99b6
> > >
> > > Can anybody help me with this? Or should I wait for freeze lift later
> today?
> >
> > I suspect you're seeing the same issue I am trying to build wine for F32.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1814105
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Clang/LLVM mismatch in F32?

[Frantisek Zatloukal]

Hi,

I am trying to rebuild mozjs68 in F32[0] (passed in rawhide just fine[1]),
which buildrequires clang and llvm. However, clang and llvm versions
mismatch in F32 buildroot:

clang   x86_64 10.0.0-0.2.*rc1*.fc32
llvmx86_64 10.0.0-0.1.*rc2*.fc32

which seems to cause errors like:
DEBUG: | /usr/bin/clang: symbol lookup error: /lib64/libclang-cpp.so.10:
undefined symbol: _ZN4llvm20CrashRecoveryContext11HandleCrashEv, version
LLVM_10

What is weird is that clang-10.0.0-0.1.rc2.fc32 is in F32 stable updates
for some time already:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-7e1fca99b6

Can anybody help me with this? Or should I wait for freeze lift later today?

Thanks!

[0] https://koji.fedoraproject.org/koji/taskinfo?taskID=42556598
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1478228
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock inside docker

[Frantisek Zatloukal]

Hi,

adding "--no-bootstrap-chroot" wouldn't help?

On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans 
wrote:

> Hi,
>
> if I am trying to run mock inside docker, I am getting the following error:
> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
> ERROR: Command failed:
>  # /bin/mount -n --bind
> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>
> In the past I usually added --old-chroot to workaround that, but now
> this yields:
> ERROR: Command failed:
>  # /bin/mount -n -t tmpfs -o rprivate tmpfs
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>
> This mock 2.0 inside the f31 ("fedora:latest") container from this morning.
>
> Any idea how get mock working again?
>
> Christoph
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disabling Fedora 29 chroots in Copr

[Frantisek Zatloukal]

Got one about a day ago :)

On Tue, Feb 18, 2020 at 12:17 PM Jakub Kadlcik  wrote:

> I would like to ask you, can anyone with non Red Hat email confirm,
> that they get the notifications? The subject is
>
> > [Copr] upcoming deletion of outdated chroots in your projects
>
>
> Thank you,
> Jakub
>
>
> On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik 
> wrote:
> >
> > Hello,
> >
> > we have just disabled Fedora 29 chroots in Copr.
> >
> > According to the Fedora wiki [1], Fedora 29 reached the end of its life
> > on 2019-11-30 and therefore we are disabling it in Copr.
> >
> > That effectively means that from this moment, it is no longer possible
> > to submit builds for the following chroots:
> >
> > - fedora-29-x86_64
> > - fedora-29-i386
> > - fedora-29-ppc64le
> > - fedora-29-aarch64
> >
> > Additionally, according to Outdated chroots removal policy [2], Copr is
> > going to preserve existing build results in those chroots for another
> > 180 days and then automatically remove them unless you take an action
> > and prolong the chroots life span in your projects. Read more about this
> > feature in the  Copr - Removing outdated chroots blog post [3].
> >
> >
> > [1] https://fedoraproject.org/wiki/End_of_life
> > [2]
> https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
> > [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
> >
> > 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Frantisek Zatloukal]

On Fri, Jan 3, 2020 at 10:14 PM John M. Harris Jr 
wrote:

> Regardless, if this Change is accepted, it should probably be done on a
> per-
> spin basis. If the GNOME Spin wants this, that's one thing, but I don't
> believe this would be a good idea on servers.
>

Yes, and if you read the change wiki page mentioned in the announcement
email, it's meant only for Workstation:
https://fedoraproject.org/wiki/Changes/EnableEarlyoom#Scope

Restricted to Workstation edition, unless other editions/spins want to
> opt-in.
>

And to be precise, there is Fedora Workstation (Edition of Fedora) and then
there are other Spins. Workstation is not a spin :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Wed, Dec 18, 2019 at 1:37 AM John M. Harris Jr 
wrote:

> But it would mean that Fedora would potentially release with optical boot
> broken.


Yes, and it was said about a million times in all threads regarding this
change proposal.  There is no need to say it again and again.

Yes, it can result (probably won't in the foreseeable future) in broken
optical media boot. And yes, I still stand for this change proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson 
wrote:

> Still, we have F32 Beta coming up quite
> soon, we could potentially delay this feature and see how that goes -
> see if anyone besides RH Fedora QE staff shows up to run the tests...
>

We still can have optical media as non blocking, that doesn't prevent
anybody testing it and filling wiki page with results.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 9:05 PM John M. Harris Jr 
wrote:

> That was not brought up elsewhere in this thread. Who is considering this,
> and
> why? That would mean that a large portion of users would *not be able to
> install Fedora*.
>

Just note that I mean blocking by "supported". I am not talking about
dropping capability of installation from optical media. Might have been
slight misunderstanding and bad wording on my side. Also, I doubt that your
"large portion" is correct.


> UNetbootin has never been a supported method of creating USB media.
> Optical media is a supported installation method.
>

It doesn't matter what was or wasn't supported. WIth definition of what I
mean with "supported" above, if this proposal is accepted, UNetbootin
wouldn't be supported too differently than physical optical media. Users
would be able to report bugs with these methods and those bugs wouldn't be
release blocking.

Practically speaking, I'd say that adding the same warning as is in
UNetbootin section in Fedora Docs [0] to the Live CD section [1] would make
sense, but this is just an idea and probably out of scope of this thread.

[0]
https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/index.html#unetbootin
[1]
https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/index.html#proc_creating-and-using-live-cd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Fri, Dec 13, 2019 at 12:03 PM Miro Hrončok  wrote:

> Juts a random idea, not very thought-out:
>
> Could we keep optical media bugs reported by users as blocking, but not
> require
> it during validation testing?
>
>
> aka: Fedora QE would no longer have to verify optical media works.
> but: If a tester finds an optical media  bug, it is still blocking.
>
> That would still have 2 of the 3 listed benefits. The remaining benefit is
> arguable (is optical media a corner case? there are no corners on DVD).
>

It's not a bad idea. I'd still prefer to drop optical media criterion
completely, but your proposal is better than nothing, should mine be
rejected.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 7:52 PM John M. Harris Jr 
wrote:

>
> Not working means broken.
>

Part of this proposal is removing optical media from supported installation
methods.
>From your point of view, Fedora is broken right now because, for example,
it doesn't work from USB Media created by UNetbootin most of the time.
It'll be the same, optical media will get delisted from supported
installation methods, so Fedora wouldn't be broken if it doesn't work from
installation source created using an unsupported method/media .  Or, if
you don't agree with that, then it's already broken ;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 6:15 PM John M. Harris Jr 
wrote:

> On Sunday, December 15, 2019 10:02:19 AM MST alcir...@gmail.com wrote:
> > Hello all.
> > Sorry but as far as I can understand, and as stated in the proposal as
> > well by other people, the possibility to boot from optical media will
> > be not dropped.
> > Nobody is stating that we will prevent Fedora to boot from a DVD.
>
> This is a concern because it means that it's possible to ship a release
> with a
> broken installer image.
>

No, this doesn't mean it'd be possible to ship a release with broken
installer image. Just that it wouldn't need to work from CD/DVD doesn't
make it broken.


>
> The GNOME Spin has always gotten preferential treatment, and I don't see
> that
> changing. That is a discussion for another thread, but it's definitely an
> issue.
>

Similarly like others said for optical media testing, if you think it's an
issue, you're (or anybody else) more than welcome to help with validation
testing of other spins.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Thu, Dec 12, 2019 at 11:31 PM Adam Williamson 
wrote:

> On Thu, 2019-12-12 at 15:37 -0500, Ben Cotton wrote:
> >
> > == Scope ==
> > * Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate
> > we no longer block on optical media, change Validation Testing
> > Matrices
>
> I don't think this is quite right. The ReleaseBlocking page would
> likely not change, as the *images* themselves would remain release
> blocking, we just would no longer block on them working when written to
> physical optical media.
>
> Rather, as well as the Installation matrix, this would require changing
> the release criteria, specifically 'Supported media types' for this
> Final criterion:
>
>
> https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Release-blocking_images_must_boot
>
> Proposal updated to reflect Final Release Criteria page change. Thanks, as
for the  ReleaseBlocking page, there is "optical boot is release blocking"
column with "yes" for mentioned images, which would change to "no", should
this change be accepted.


> The proposal to drop the optical requirement entirely was first floated
> by Matthew Miller in September 2018 on test@ , and there is a long
> discussion thread following that proposal:
>
>
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/E5RJTWF6VZLQFWHB5IBAXBSQIB57SJSY/#E5RJTWF6VZLQFWHB5IBAXBSQIB57SJSY
>
> which may be helpful for context.
>
>
Link to the thread has been added to the proposal page.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Frantisek Zatloukal]

On Fri, Dec 13, 2019 at 9:28 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 12.12.2019 21:37, Ben Cotton wrote:
> > Proposal to make all Fedora optical media non-blocking. This means
> > we'd stop blocking on bugs found during the installation of Fedora
> > from optical media (like CDs and DVDs). This doesn't mean that
> > installation from optical media would stop working, just that the
> > Fedora Release wouldn't be blocked on any issues that can pop up in
> > Fedora installation using this method. Installation from USB devices
> > will remain blocking.
>
> I'm strongly against this change. There are still lots of working
> hardware that does not support booting from USB in UEFI mode (first wave
> of hardware with UEFI BIOS).
>
> Fedora should be installable on all supported hardware.
>
>
On Fri, Dec 13, 2019 at 3:19 AM Kevin Kofler  wrote:

> Ben Cotton wrote:
> > Proposal to make all Fedora optical media non-blocking. This means
> > we'd stop blocking on bugs found during the installation of Fedora
> > from optical media (like CDs and DVDs). This doesn't mean that
> > installation from optical media would stop working, just that the
> > Fedora Release wouldn't be blocked on any issues that can pop up in
> > Fedora installation using this method. Installation from USB devices
> > will remain blocking.
>
> I am against this Change. This is clearly a special case of Fedora not
> being
> installable at all on a significant subset of hardware. I do not think it
> is
> acceptable to ship it that way.
>
> This change is not aimed to make Fedora non-installable via CD/DVD. As
it's written in the proposal, *"This doesn't mean that installation from
optical media would stop working, just that the Fedora Release wouldn't be
blocked on any issues that can pop up in Fedora installation using this
method. " *

Also, if you care about Fedora being installable from CD or DVD, you might
want to help with testing. Bugs will be handled like any other bugs found
in Fedora. No one apart from Fedora QE Team members filled F31 Final
Validation Testing Matrix for optical media installation [0][1][2].

As for HW that does not support USB boot, there will always be some HW
without USB boot support caused probably by firmware bugs. However, the
vast majority of HW sold in last decade should support USB boot just fine.
Even desktop I had in 2004 supported USB boot...

This proposal would allow QE to focus more on areas which are exposed to
the majority of users instead of having to spend limited time and resources
by burning CDs and testing them just to make sure it works for fraction of
user base. I don't expect to suddenly have F32 released with broken boot
from optical media.

[0]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.3_Installation#Default_boot_and_install
[1]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.8_Installation#Default_boot_and_install
[2]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.9_Installation#Default_boot_and_install
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: gstreamer-plugins-base revival

[Frantisek Zatloukal]

On Fri, Nov 22, 2019 at 12:47 PM Leigh Scott 
wrote:

> > Please don't revive ancient, unmaintained, security-critical libraries
> > for use with proprietary software not distributed by Fedora
> Old gstreamer is used by a couple of ancient apps in fedora (banshee)
>

Banshee in Fedora is using new gstreamer, see:
https://src.fedoraproject.org/rpms/banshee/blob/master/f/banshee.spec#_98

I am not too happy about bringing such an old and unmaintained (in
upstream) package back to Fedora (it's latest release was in 2012), but
there isn't much that can be done about it if there is a maintainer.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Frantisek Zatloukal]

On Sat, Nov 9, 2019 at 8:31 AM Kevin Kofler  wrote:

> Sorry, but I'm with Vít there. If Python is running into toolchain
> limitations, the goal should be to work on improving the toolchain, not to
> add a hack with side effects (bloat, compatibility issues) to the Python
> package, a hack with which we will then get stuck with forever (because
> you
> admitted yourself that you do not intend it to be temporary).


How is statically linked libpython hack? It's just a different way to do
it, isn't it? And if toolchain needs some improving, fine, but why should
we have lower performance and keep waiting on it if there is a solution
available right now? Solution that's been tested and proven to work in
other high profile Distributions (Ubuntu, Debian).  And size increase? It's
so tiny, I can't imagine why should that matter at all.

Also, this is change to Python ecosystem in Fedora, it does not depend on
Ruby, Perl and others.

Anyhow, I am very much for this proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org