Re: Self Introduction: Attila Kovacs

[Mattia Verga via devel]

Il 22/05/24 6:13 PM, Attila Kovacs ha scritto:
> Hi!
>
Hi Attila and welcome to the Fedora community!

I myself am just an amateur astronomer trying to keep up packaging some 
useful software in Fedora, but I look forward in seeing SuperNOVAS 
packaged in our repositories. Don't hesitate to ask me if you have any 
question about packaging, I'm not a sponsor, but I can do a review of 
the package submission when ready.

Mattia

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

[Mattia Verga via devel]

Il 30/04/24 10:47 AM, Kevin Kofler via devel ha scritto:
> Miro Hrončok wrote:
>> If you wish to help, I guess you can send a pull request to the release
>> notes...
> Or Mattia could simply unretire and adopt the package.
>
Yeah, well... no! :-)

I've re-read the former discussion about pipenv being orphaned and why. 
I thought it was decided to drop pipenv because too much dependencies 
were bundled, but now that I re-read the thread I see it was because 
it's a nightmare to maintain because of too much bundled dependencies 
and too low workforce.

I do not have any more spare time to put in that effort myself, so I'll 
just live with "pip install --user pipenv" ;-)

I'll see to drop a note to F40 release notes, because even if I agree a 
change proposal was not required I think this could be an high impact 
change that python developers using Fedora need to know.

As a side note, I dream that one day someone will come out with a clever 
solution for packaging python stuff without the burden to package all 
needed dependencies... something like installing packaged dependencies 
with dnf plus automatically use a dedicated virtual environment and pip 
to install everything not already packaged in Fedora... well, it's just 
a dream!

Mattia

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

pipenv removal in F40

[Mattia Verga via devel]

I vaguely remember that pipenv retirement was briefly discussed here on 
the ML, yet I was surprised that F40 doesn't have pipenv anymore.

IMO, this would have been announced more prominently as a self contained 
change, as I expect more python developers to find out this too late. 
Also, the official guide on 
https://developer.fedoraproject.org/tech/languages/python/pipenv.html 
should have been updated as well.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Mattia Verga via devel]

Il 25/04/24 07:42, Jan Kolarik ha scritto:
> Hello everyone,
>
> We've prepared a side-tag for testing Rawhide with dnf5 as the default 
> package manager. Instructions for installing the packages from the 
> side-tag can be found at the following link [1].
>
> Please provide feedback in Bodhi or on this mailing list regarding the 
> use cases you're familiar with from the existing dnf command, and 
> share your experience with this new version.
>
> If there's no negative feedback regarding any critical functionality, 
> we plan to push the packages from the side-tag to Rawhide next week.
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
>
> Thanks,
> Jan

I'd also like to test it on a real F40 machine (I have been using mostly 
dnf5 commands in a F40 VM without issues during the latest months), is 
there maybe a COPR repo or something like which allows that?

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F41 Change Proposal: Change Compose Settings (system-wide)

[Mattia Verga via devel]

Il 26/03/24 10:41, Sirius via devel ha scritto:
> In days of yore (Tue, 26 Mar 2024), fedora-devel thus quoth:
>> In days of yore (Thu, 21 Mar 2024), Stephen Smoogen thus quoth:
>>> On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel <
>>> devel@lists.fedoraproject.org> wrote:
>>>
 Aoife Moloney wrote:
> The zstd compression type was chosen to match createrepo_c settings.
> As an alternative, we might want to choose xz,
 Since xz consistently compresses better than zstd, I would strongly
 suggest
 using xz everywhere to minimize download sizes. However:

> especially after zlib-ng has been made the default in Fedora and brought
> performance improvements.
 zlib-ng is for gz, not xz, and gz is fast, but compresses extremely poorly
 (which is mostly due to the format, so, while some implementations manage
 to
 do better than others at the expense of more compression time, there is a
 limit to how well they can do and it is nowhere near xz or even zstd) and
 should hence never be used at all.


>>> There are two parts to this which users will see as 'slowness'. Part one is
>>> downloading the data from a mirror. Part two is uncompressing the data. In
>>> work I have been a part of, we have found that while xz gave us much
>>> smaller files, the time to uncompress was so much larger that our download
>>> gains were lost. Using zstd gave larger downloads (maybe 10 to 20% bigger)
>>> but uncompressed much faster than xz. This is data dependent though so it
>>> would be good to see if someone could test to see if xz uncompression of
>>> the datafiles will be too slow.
>> Hi there,
>>
>> Ran tests with gzip 1-9 and xz 1-9 on a F41 XML file that was 940MiB.
> Added tests with zstd 1-19, not using a dictionary to improve it any
> further.
>
> Input File: f41-filelist.xml, Size: 985194446 bytes
>
> ZStd Level  1, 1.7s to compress, 6.46% file size,  0.6s decompress
> ZStd Level  2, 1.7s to compress, 6.34% file size,  0.7s decompress
> ZStd Level  3, 2.1s to compress, 6.26% file size,  0.7s decompress
> ZStd Level  4, 2.3s to compress, 6.26% file size,  0.7s decompress
> ZStd Level  5, 5.7s to compress, 5.60% file size,  0.6s decompress
> ZStd Level  6, 7.2s to compress, 5.42% file size,  0.6s decompress
> ZStd Level  7, 8.1s to compress, 5.39% file size,  0.6s decompress
> ZStd Level  8, 9.5s to compress, 5.31% file size,  0.6s decompress
> ZStd Level  9,10.4s to compress, 5.28% file size,  0.6s decompress
> ZStd Level 10,13.6s to compress, 5.26% file size,  0.6s decompress
> ZStd Level 11,18.4s to compress, 5.25% file size,  0.6s decompress
> ZStd Level 12,19.5s to compress, 5.25% file size,  0.6s decompress
> ZStd Level 13,30.9s to compress, 5.25% file size,  0.6s decompress
> ZStd Level 14,39.7s to compress, 5.23% file size,  0.6s decompress
> ZStd Level 15,56.1s to compress, 5.21% file size,  0.6s decompress
> ZStd Level 16,  1min58s to compress, 5.52% file size,  0.7s decompress
> ZStd Level 17,  2min25s to compress, 5.36% file size,  0.7s decompress
> ZStd Level 18,  3min46s to compress, 5.43% file size,  0.8s decompress
> ZStd Level 19, 10min36s to compress, 4.66% file size,  0.7s decompress
>
> So to save 5.2MB in filesize (lvl19 vs lvl15) the server have to spend
> eleven times longer compressing the file (and I did not look at resources
> like CPU or RAM while doing this). I am sure there are other compression
> mechanisms that can squeeze these files a bit further, but at what cost.
> If it is a once a day event, maybe a high compression ration is
> justifiable. If it has to happen hundreds of times per day - not so much.
>
>
> ## zstd
> function do_zstd()
> {
>let cl=1
>echo Input File: ${INPUTFILE}, Size: ${INPUTFILESIZE} bytes
>echo
>while [[ $cl -le 19 ]]
>do
>  echo ZStd compression level ${cl}
>  echo Time to compress the file
>  time zstd -z -${cl} ${INPUTFILE}
>  COMPRESSED_SIZE=$(ls -ln ${INPUTFILE}.zst | awk '{print $5}')
>  echo Compressed to
>  echo "scale=5
>  ${COMPRESSED_SIZE}/${INPUTFILESIZE}*100
>  "|bc
>  echo % of original
>  echo Time to decompress the file, output to /dev/null
>  time zstd -d -c ${INPUTFILE}.zst > /dev/null
>  rm -f ${INPUTFILE}.zst
>  let cl=$cl+1
>  echo
>done
> }
>
> --
> Kind regards,
>
> /S
> --

Also note that adding '-T0' to use all available cores of the CPU will 
greatly speed up the results with zstd.

However, all this talking about the optimal compression level, but in 
the end there's no way to set that to createrepo_c options, so ;-)

Mattia

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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Mattia Verga via devel]

Il 21/03/24 03:00, Kevin Kofler via devel ha scritto:

> Since xz consistently compresses better than zstd, I would strongly suggest
> using xz everywhere to minimize download sizes. However:
>
>> especially after zlib-ng has been made the default in Fedora and brought
>> performance improvements.
>
> zlib-ng is for gz, not xz, and gz is fast, but compresses extremely poorly
> (which is mostly due to the format, so, while some implementations manage to
> do better than others at the expense of more compression time, there is a
> limit to how well they can do and it is nowhere near xz or even zstd) and
> should hence never be used at all.

Yep, I've messed thing up. So, let's stick to use zstd, which is createrepo_c 
new default anyway.

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

Retiring Celestia from Fedora due to licensing issues

[Mattia Verga via devel]

After I requested [1] Celestia project upstream to better define 
licensing of all the textures and 3d models included in upstream data, 
it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
which is not permitted in Fedora.

Upstream is still working on specify exactly the licenses of each file 
and, maybe, in future will replace the problematic content with FOSS 
textures. However, since there's no ETA for those tasks and the main 
program cannot work by simply stripping out the problematic content, I 
am forced to retire Celestia from Fedora.

I will be following the procedure for completely removing a package [3], 
however there are a couple of things that I'd like to ask:

- should I wait for the flatpak maintainer to retire the flatpaks 
(celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
celestia-content)?
- do I need to ask releng to purge celestia sources from the lookaside 
cache as well?
-do the flatpaks need to be added to fedora-obsolete-packages (or 
something similar for flatpaks)?

Thanks
Mattia

[1] https://github.com/CelestiaProject/CelestiaContent/issues/138
[2] https://github.com/CelestiaProject/CelestiaContent/issues/147
[3] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Nonresponsive maintainer check for Scott Tsai

[Mattia Verga via devel]

Il 09/03/24 04:18, Nolan Poe ha scritto:
> Hello,
>
> Does anyone know how to contact Scott Tsai? He appears to still be listed as 
> the maintainer for verilator despite not being active (from what I can see) 
> for years. Does anyone know how to contact him?
>
> Non-responsive maintainer bug for scottt:
> https://bugzilla.redhat.com/show_bug.cgi?id=2268651
>
> Other seemingly unmaintained packages:
> https://src.fedoraproject.org/rpms/udis86
> https://src.fedoraproject.org/rpms/urjtag
>
> This is listed the first step of the Fedora Non-responsive package maintainer 
> policy:
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps

They're also listed as inactive packager: 
https://pagure.io/find-inactive-packagers/issue/1968

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Update gumbo-parser to 0.12.1/libgumbo SONAME bump

[Mattia Verga via devel]

On Friday, March 1st, 2024 at 20:27, Jason Tibbitts  wrote:

> 
> 
> > Adam Williamson adamw...@fedoraproject.org writes:
> 
> > Honestly, we could really use more automation here, but it's a fairly
> > hard thing to do reliably and there just isn't anybody specifically
> > tasked with it so it doesn't happen.
> 
> 
> So sure, we could use something but it doesn't have to start out as some
> complex fully automatic system. (Would be nice, but...)
> 
> Can we agree that we'd be at least half of the way there if we just had
> a well defined way to:
> 
> * Know what package depend on the one you're updating
> 
> * Easily bump and chain-build all of that in a side tag
> 
> Surely there's a reopquery or fedrq command line that will find at least
> most of what needs to be rebuilt. It doesn't have to be absolutely
> perfect but it can't be that hard to get close. I know there's a
> distinction between build and runtime dependencies and rich/conditional
> dependencies complicate things a bit, but those much smarter than I am
> must have already figured out how to get something that's at least
> somewhat useful.
> 
> Once you have the package list, maybe it needs some kind of sorting
> before you can just bump and chain-build things, but I think in many
> cases it doesn't. So, yes, a 100% tool would be really hard but the 80%
> tool really shouldn't be that bad, and almost any tool would really help
> people out.
> 

My idea was to write a Python script based on libdnf APIs and third party 
python modules to create a dependency tree of packages, so that also Mass 
Rebuilds can be run by the tree levels instead of alphabetically. However, I 
had no time to further develop the idea, as I also learn how to fetch data from 
libdnf (and if that is possible at all).

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

Inactive provenpackagers for the F41 cycle

[Mattia Verga via devel]

In accordance with FESCo policy[1], the following provenpackagers will
be submitted for removal in two weeks based on a lack of Koji builds
submitted in the last six months. If you received this directly, you
can reply off-list to indicate you should still be in the
provenpackager group.

Note that removal from this group is not a "punishment" or a lack of
appreciation for the work you have done. The intent of the process is
to ensure contributors with distro-wide package privileges are still
active and responsive. This process is done regularly at the branch
point in each release.

[1]
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status
Checked 130 provenpackagers
The following 12 provenpackagers have not submitted a Koji build since at least 
2023-08-15 00:00:00:
puiterwijk
rdieter
mbooth
xvitaly
bowlofeggs
caolanm
tibbs
hadess
hguemar
law
wtogami
steve--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Inactive packagers for the F40 cycle

[Mattia Verga via devel]

Per the "Inactive packagers policy" [1], I've run the script and detected 164 
inactive packagers. At the end of the email you can find the full list.

[1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/

I also need to apologize, as the first time I ran the script it missed the 
checks on mailing lists and bugzilla activities, so it opened a lot of 
unnecessary tickets...

Mattia

### Found 164 inactive packagers. ###
aarapov
achernya
acmnpv
alsadi
anishpatil
armbru
arthurbuliva
atkac
bagnara
bdperkin
benniej
bkearney
blackfile
brejoc
bressers
c4chris
carmenbianca
caspermeijn
conor117
ctwo0002
danw
davidcl
denis
dfan
digimer
djachimo
dkliban
dmoerner
ebaron
elisre
emoret
emunson
epvergara
ewalsh
fangq
filbranden
flaper87
fnecas
gchamoul
gferon
gicmo
gil
gilboa
harald
hardaker
honli
ibotty
ixs
izhar
jaltman
jamesread
jamesturner246
japokorn
jcollie
jeffreylauribose
jimbair
jjohnstn
jkang
jklimes
jmatthews
jortel
josmyers
josueneo
jscotka
jshort
jskala
jwhite
jwilson
kaboon
kapil1087
karm
kenjiro
kme
ksyz
laiot
lalatendu
lcts
lgs
lhrazky
liangwen12year
linuxdonald
linuxsystemroles
maci
marxin
matyas
mayorga
mbasti
mcepl
merlinm
mfabik
mfojtik
miguel7ra
mikedep333
milkice
milovidov
miminar
miyunari
mmraka
mrniranjan
munroesj52
mycae
mzeleny
nacho
njha
nknazeko
nmilosev
nnac123
nocnokneo
oden
ogutierrez
ohaessler
olem
osoukup
otubo
packagerbot
pawsa
petebuffon
pgampe
phuang
piotrp
pmkovar
portante
qwan
rdossant
renep
returntrip
rjmco
rluzynski
ruben
russellb
rvokal
rzinsly
samahaj
sanqui
saypaul
scottt
sdunnaga
shishz
shwetha
sijis
smakarov
snavin
sparks
spstarr
sseago
stephen144
sturivny
susmit
szeth
theyoyojo
tkasparek
treydock
tuju
txtoth
valentic
vanessakris
vbubela
volter
vstanek
wolfy
wwoods
xberry
yalgaer
yuvalturg--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Inactive provenpackagers for the F40 cycle

[Mattia Verga via devel]

I'm re-posting to @devel as I forgot that posting to @devel-announce is 
restricted:

In accordance with FESCo policy[1], the following provenpackagers will
be submitted for removal in two weeks based on a lack of Koji builds
submitted in the last six months. If you received this directly, you
can reply off-list to indicate you should still be in the
provenpackager group.

Note that removal from this group is not a "punishment" or a lack of
appreciation for the work you have done. The intent of the process is
to ensure contributors with distro-wide package privileges are still
active and responsive. This process is done regularly at the branch
point in each release.

[1]
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status
Checked 130 provenpackagers
The following 12 provenpackagers have not submitted a Koji build since at least 
2023-08-15 00:00:00:
puiterwijk
rdieter
mbooth
xvitaly
bowlofeggs
caolanm
tibbs
hadess
hguemar
law
wtogami
steve--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-02-19)

[Mattia Verga via devel]

Il 20/02/24 19:52, Mattia Verga via devel ha scritto:
> Il 19/02/24 23:26, Zbigniew Jędrzejewski-Szmek ha scritto:
>> On Mon, Feb 19, 2024 at 06:26:24PM +0000, Mattia Verga via devel wrote:
>>> Il 19/02/24 15:32, Zbigniew Jędrzejewski-Szmek ha scritto:
>>>> Following is the list of topics that will be discussed in the
>>>> FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
>>>> on Matrix.
>>>>
>>> Can you also clarify who should run the Inactive provenpackagers policy
>>> (which was scheduled to be run the past week [1]) and the Inactive
>>> packagers policy (scheduled for tomorrow)? Or decide if you don't want
>>> to run them anymore.
>>>
>>> For the past Fedora release I took care of both when I realized no one
>>> had run them. This time I'm asking just a little earlier...
>> We didn't get to this, because we spent 2.8h on the first two issues.
>> But I think nobody will object if you do this again… We do
>> want to run them as planned.
>>
>> Zbyszek
> Oh, ok. I'll start with the Inactive provenpackagers and I'll run the
> Inactive packagers as soon as I have enough time (the script usually
> takes 2-3 hours to complete).
>
> Mattia
>
FYI unfortunately, sending emails to @fedoraproject.org is 
currently broken [1]... My emails to affected provenpackagers were 
bounced back. I'll try to contact them directly looking to the email 
from noggin.

Mattia

[1] https://pagure.io/fedora-infrastructure/issue/11768


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Schedule for Monday's FESCo Meeting (2024-02-19)

[Mattia Verga via devel]

Il 19/02/24 23:26, Zbigniew Jędrzejewski-Szmek ha scritto:
> On Mon, Feb 19, 2024 at 06:26:24PM +0000, Mattia Verga via devel wrote:
>> Il 19/02/24 15:32, Zbigniew Jędrzejewski-Szmek ha scritto:
>>> Following is the list of topics that will be discussed in the
>>> FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
>>> on Matrix.
>>>
>> Can you also clarify who should run the Inactive provenpackagers policy
>> (which was scheduled to be run the past week [1]) and the Inactive
>> packagers policy (scheduled for tomorrow)? Or decide if you don't want
>> to run them anymore.
>>
>> For the past Fedora release I took care of both when I realized no one
>> had run them. This time I'm asking just a little earlier...
> We didn't get to this, because we spent 2.8h on the first two issues.
> But I think nobody will object if you do this again… We do
> want to run them as planned.
>
> Zbyszek

Oh, ok. I'll start with the Inactive provenpackagers and I'll run the 
Inactive packagers as soon as I have enough time (the script usually 
takes 2-3 hours to complete).

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Schedule for Monday's FESCo Meeting (2024-02-19)

[Mattia Verga via devel]

Il 19/02/24 15:32, Zbigniew Jędrzejewski-Szmek ha scritto:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
> on Matrix.
>
Can you also clarify who should run the Inactive provenpackagers policy 
(which was scheduled to be run the past week [1]) and the Inactive 
packagers policy (scheduled for tomorrow)? Or decide if you don't want 
to run them anymore.

For the past Fedora release I took care of both when I realized no one 
had run them. This time I'm asking just a little earlier...

Mattia

[1] https://fedorapeople.org/groups/schedule/f-40/f-40-pm-tasks.html


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

Re: Help with creating first PR for a package

[Mattia Verga via devel]

Il 18/02/24 02:52, Loren M. Lang ha scritto:
> After looking through the orphaned packages, I found one that looks like
> a good candidate for me to help with, python-cachelib, as this package
> is not that large and I am well-versed in Python.
>
> I've cloned it down and worked on bringing it more up-to-date. Now that
> I have something passing the test suite, I thought I'd file a PR and
> start a discussion. I forked the project on Pagure.io, but found that
> even with my own personal fork, I don't seem to have commit access to it
> without being in the Packagers group. Is that standard? I thought the
> point of the fork was to allow non-packagers to use the PR mechanism as
> an easy mechanism for sponsors to view proposals.
>
If I remember correctly previous replies about this issue, you need to 
use the https URL to push to your fork, ssh access only works for packagers.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package review ticket status change after approval

[Mattia Verga via devel]

Il 06/02/24 14:34, Zbigniew Jędrzejewski-Szmek ha scritto:
> On Mon, Jan 29, 2024 at 06:47:21PM +0000, Mattia Verga via devel wrote:
>> That said, I'd like to make a request and maybe make all reviewers aware
>> of a feature which was implemented some time ago. I've noticed many
>> reviewers change the ticket status from ASSIGNED to POST when they flag
>> the package as approved: I'd like to request to not do that.
> The reason for POST is that this allows the reviews that are "done"
> from the reviewer's side to be easily distinguished in a bugzilla
> listing. E.g. my reviews are [1], and then I only need to care about
> those with ASSIGNED.
>
> If we're not supposed to use POST, then please provide this
> functionality in some different form. (I think the suggestion
> from the other part of thread to use RELEASE_PENDING is better.)
>
Sure, the 'POST' usage has been inherited by the old review ticket 
status webpages. When I rewrite the code I used the same statuses, but I 
agree that it may have much more sense to use 'RELEASE_PENDING'. If 
there isn't any objection e.g. disrupting someone's else tool workflow, 
I can easily change that.

BTW, the ticket status is not changed automatically upon repository 
creation because I now realize there was an error in the code I 
submitted to toddlers. There is now a PR to fix that [1]

Mattia

[1]  https://pagure.io/fedora-infra/toddlers/pull-request/184

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

Bodhi 8.0.2 deployed to prod

[Mattia Verga via devel]

Hello folks,

we (well, mostly kevin) have just deployed Bodhi 8.0.2 in prod.
There are several changes in the background, but what can be of some 
interest for you, users and developers, are these points:

- Fixed “cannot access local variable ‘tags’” error when editing flatpak 
updates
- Sidetags in the dropdown of the new update form are now sorted 
alphabetically
- Usernames containing a "-" are now correctly matched when mentioning
- Build NVRs are added to the Bugzilla comment
- There should be no more Updates ejected from the composes that remain 
stuck in pending state due to wrong tags applied to their builds (or, 
better, they should be automatically pushed again after 48 hours)
- The webUI now allows unpushing Rawhide updates which fail gating tests
- The release timeline graph now uses logarithmic scale for better display
- The UpdateReadyForTesting message format is simplified, and the 
message is now published on update creation and edit with changed builds 
instead of push to testing
- JSON APIs now support quering Releases by multiple states, for example 
'?state=pending=frozen'
- added a get_critpath_components json endpoint to list critical path 
components configured for a Release
- Builds associated to unpushed updates can now be moved to other 
existing updates
- Release data now give information about the status of pre_beta and 
post_beta and of the first date of release
- Members of QA groups defined in configuration are now able to waive or 
trigger tests for any update, despite they’re packagers/provenpackagers 
or not
- Update notes are now converted to plaintext when printed in email or 
messages
- Releases can now inherit buildroot override tags from other releases 
by settings in Bodhi config file
- Settings for repodata and updateinfo can now be set by an external 
config file and no more hardcoded

For the full changelog between the previous deployed 7.2.2 version and 
the latest 8.0.2, please check 
https://fedora-infra.github.io/bodhi/8.0/user/release_notes.html

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package review ticket status change after approval

[Mattia Verga via devel]

Il 01/02/24 22:44, Fabio Valentini ha scritto:
> On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel
>  wrote:
> (snip)
>
>> That said, I'd like to make a request and maybe make all reviewers aware
>> of a feature which was implemented some time ago. I've noticed many
>> reviewers change the ticket status from ASSIGNED to POST when they flag
>> the package as approved: I'd like to request to not do that.
>>
>> The Package Review Tracker webpages make a distinction between packages
>> approved (fedora-review flag set to +) and packages approved AND being
>> built in Fedora. That distinction relies on the ticket status change to
>> POST, which is automatically set when the repository is created in src.fp.o.
> Hum ... am I missing something here?
>
> The bot that creates the dist-git repos does *NOT*, in fact, set the
> bug status to POST:
> https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5
>
> Fabio

Well... it should: https://pagure.io/fedora-infra/toddlers/pull-request/158

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Mattia Verga via devel]

Il 31/01/24 23:38, Alessandro Astone ha scritto:
> The "personal attack" is a consideration on the proposed maintainer of these 
> packages.
>
>> every effort in order to not to break things must be made.
> Then I cannot support these packages being added. It is putting additional 
> effort on the KDE-SIG up to once per every week; especially since we're at 
> the beginning of the Plasma 6 release cycle and releases are going to be 
> hectic.
> The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would 
> not be required.
> blogilo is as much of a non-release-blocking component as 
> plasma-workspace-x11 would be.
> --

There I was referring to stable releases. I assume you're not going to 
rebuild and push updates into stable releases once per week.

FWIW I am an happy user of Plasma on Wayland and don't need X11. 
However, Fedora is a community project, so the fact one don't care about 
a software doesn't mean they can stop someone else packaging it, as long 
as there someone interested in doing the work. If that means delaying 
updates by one week waiting for the other maintainers to rebuild their 
packages, we must allow that, as we do for all other cases.

I am also quite sure that things would be much more simple for both 
parties if -x11 guys would make use of COPR instead of building their 
packages in distgit. That way they can choose to rebuild the kde plasma 
common stack with the epoch bumped, so that anyone using the COPR 
repository will have that packages overwrite the Fedora ones, and build 
their -x11 with their "LTS" version. That way anyone using X11 will not 
see any breakage and they can choose to upgrade the base packages when 
they want/have free time.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Mattia Verga via devel]

 Messaggio originale 
31/01/24 22:27, Alessandro Astone  ha scritto:

>  I can support that.
>  
>  But am I supposed to ignore the fact that kkofler is already bullying the 
> KDE SIG into not breaking that one other package they maintain that 
> occasionally breaks on kde updates? See example: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
>  
>  Am I going to have to see kkofler rant in every plasma update that their 
> xorg stack breaks?
>  --

Firstly, let's not make personal attacks.

The reported example refers to an update submitted for a stable release, where 
every effort in order to not to break things must be made. Was that happened 
before the side-tag update was pushed? imo, saying "blogilo is dead upstream 
and you're the only one left using it" is not enough.

Mattia
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Mattia Verga via devel]

Il 30/01/24 13:47, Sérgio Basto ha scritto:
> Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>
> and I'm very upset
>
I tried to read all the backward discussion and, if I'm correct, the 
point is that having the -x11 packages in Fedora official repositories 
would make "official" that KDE maintainers would have to avoid breaking 
those packages when making upgrades and so that would need more work. 
Their proposal to have the -x11 packages in a specific COPR repository, 
which wouldn't be official, would avoid that extra work, which was one 
of the reason because they decided to drop X11.

The COPR solution seems better for me for both parties: kde-sig folks 
wouldn't have to bother with X11 anymore, while -x11 maintainers could 
avoid unexpected breakage by bumping Epoch of the package in COPR and 
rebuild the full KDE Plasma stack there.

However, if the breakage could happen only one way, e.g. a KDE Plasma 
update will possibly break -x11 packages, but no -x11 package could 
break the "official" Wayland implementation, I'm for allowing the -x11 
packages in the main repos. I see no other reason why FESCO should block 
-x11 packages in the main repo, if a software is under an allowed 
license and doesn't harm the main system we should not refuse its packaging.

Mattia

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

Package review ticket status change after approval

[Mattia Verga via devel]

Hello folks,

before all, I want to thank everyone putting their time in reviewing new 
package requests! That is a key task in distinguish Fedora among the 
other Linux distribution and ensure we have high quality packages in our 
repositories.

That said, I'd like to make a request and maybe make all reviewers aware 
of a feature which was implemented some time ago. I've noticed many 
reviewers change the ticket status from ASSIGNED to POST when they flag 
the package as approved: I'd like to request to not do that.

The Package Review Tracker webpages make a distinction between packages 
approved (fedora-review flag set to +) and packages approved AND being 
built in Fedora. That distinction relies on the ticket status change to 
POST, which is automatically set when the repository is created in src.fp.o.

I think that distinction can be useful to see all packages that were 
approved, but for some reason the submitter never asked for the 
repository to be created. So, if you also think that is useful and can 
change what it may have become a routine for you, just set the review 
flag accordingly without changing the ticket status.

BTW, for the future (if I find some spare time) I plan to change the 
interface of the Package Review Tracker webpages by moving from using 
colors to icons. That's because the colors are currently mutually 
exclusive i.e. whenever a ticket is marked NEEDSPONSOR, the green 
background will take precedence over all other descriptions. By using 
multiple icons, we can have better "visual categorization" (and, maybe, 
enhance the js filter). But before doing so, I'll make a preview of the 
change and post it here (or on Discussion) to get some feedback...

Thanks
Mattia

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

[Mattia Verga via devel]

Il 22/01/24 19:07, Stephen Gallagher ha scritto:
> tl;dr: Buildroot overrides should be restricted to releng members and
> packagers should use on-demand side-tags instead.
>
>
I'm fully in agreement with such proposal. Do note however that there's 
currently no way to restrict BRO usage in Bodhi, that's something that 
will need development.

I'd also like to propose to consider using side-tags together with 
temporary forks of Rawhide/release branches. That way, when a side-tag 
takes some time to completely rebuild a bunch of packages and fulfill 
its purpose, changes can be made to rawhide/stable branches without 
being impacted by any possible change introduced by the side-tag.

Mattia

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

[Mattia Verga via devel]

Il 22/01/24 19:39, blinxen ha scritto:
>   > I am unaware of any remaining use cases for buildroot overrides that
> are not covered by side tags
>
> One use case that I sometimes encounter is requiring a newer version for
> a dependency,
> that is submitted to Bodhi with a side-tag. Since the build is in a
> side-tag, I can't access it
> without building into that specific side-tag. Also I can't stop the
> Bodhi Update just to add my own
> build. In this case, I need to create a buildroot override to be able to
> build my package in my own side-tag.
>
> Sure, I can wait a couple of days for the update to land in stable but
> it's nice that I can also have a
> on-demand buildroot override that can speed things up.
> --

IMO, that's the perfect example of how buildroot overrides must NOT be 
used...

Say libfoo-1.0 is in a side-tag update. You use a BRO to build another 
package, or, maybe worse, someone who is not aware of the BRO you 
created build their package against libfoo-1.0, and those packages are 
submitted in different updates. If, for some reason, libfoo-1.0 update 
lands in stable after the other packages, or never lands because it is 
gated or is blocked by negative feedback, the other packages are getting 
broken when they're submitted to stable.

The purpose of side-tags is exactly to prevent such breakages.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updating wcslib in rawhide to 8.2.2 (with sidetag)

[Mattia Verga via devel]

Il 09/01/24 17:20, Sergio Pascual ha scritto:
> Hello, I have created the side tag f40-build-side-81054 to build
> packages depending on wcslib
>
> Build your package with:
> fedpkg build --target=f40-build-side-81054
>
> Affected:
> astrometry
> cpl
> kstars
> python3-astrometry
> python3-astropy
> siril
> sourcextractor++
> stellarsolver
>
> I have already built cpl and I'm building python-astropy now
>
I've rebuilt siril in the side-tag.

Astrometry rebuild failed because it requires python-astropy which is 
currently FTB with wcslib 8.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Mattia Verga via devel]

Il 28/12/23 18:25, Robert Marcano via devel ha scritto:
> On 12/28/23 12:58 PM, Chris Adams wrote:
>> Once upon a time, Aoife Moloney  said:
>>> Systemd will be modified to insert the additional directories into the
>>> `$PATH` environment variable (affecting all programs on the system)
>> Anything that depends on PATH entries is IMHO doomed to failure.  There
>> are way too many things that explicitly set PATH to "known" values (for
>> good and bad reasons) to be able to depend on extending it.  Heck, it
>> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>>
> Maybe replacing the /usr/bin related entries with a generic wrapper that
> launch the best binary from the per architecture directories.
>
> Note: This may affect a few programs that use argv[0] for something
> meaningful.
> --

I've got not much knowledge on this matter, anyway here's my 2c:

Since we're talking about a few packages that will gain from this change 
and that they're must be manually "enabled" to build with this feature, 
I'd prefer this kind of wrapper approach instead of changing the PATH 
globally.

Maybe a RPM macro could be provided for using in specfile where we want 
optimized binaries. Those binaries will be created like 'xz-x86-64-v2', 
'xz-x86-64-v3' and so on and all installed in /usr/bin. Then a 'xz' 
wrapper will call the appropriate executable based on what supported 
instruction set is detected available. And maybe in future we could have 
dnf to install the appropriate optimized subpackage binaries.

It may be much more complex than just injecting new PATHs, but I think 
it's more elegant and could be a shared mechanism with other linux 
distributions.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Synching user database from Fedora IPA to pagure

[Mattia Verga via devel]

Il 29/11/23 18:20, Kevin Fenzi ha scritto:
> On Tue, Nov 28, 2023 at 10:13:35AM +0000, Mattia Verga via devel wrote:
>> I'd like to start writing a script to synch users/groups from Fedora IPA
>> to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based
>> on Fedora accounts, but the Pagure user database is only updated when a
>> user login in Pagure.
> Yeah, there was a script for fas2:
> https://pagure.io/pagure-utility/blob/master/f/sync_fas_group_membership.py
> But I guess that would need to be ported to current.
>
>> That means that by searching for a user or looking group memberships in
>> Pagure we don't have an updated, real view of what we have in IPA. With
>> the old FAS system there used to be a synch script provided by
>> pagure-dist-git plugin, so I plan to use that as the base for a new
>> synch script from IPA.
>>
>> However, before digging in how (and if) is possible to add new users
>> using pagure libraries, I'd like to ask if it would be acceptable to
>> "copy" user data from one database to another (except passwords, which
>> remain in IPA only). We will need to pass username, full name, email and
>> group memberships from IPA to pagure.io/src.fp.o, which is what is done
>> when a user logs in for the first time.
>>
>> If that's not acceptable, I think I can just only update group
>> membership for users already in pagure database.
>>
>> Thoughts?
> There was some renewed interest in syncing things not long ago, at least
> for pagure.io groups. See:
>
> https://pagure.io/fedora-infra/toddlers/issue/177
>
> Note that that needs a upstream pending pr to be merged, a new release
> cut and us to update to it to get the api endpoint.
>
> kevin
> --

Nice, I wasn't aware this work was already nearly done... I'll drop some 
notes there.

Thanks
Mattia

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

Synching user database from Fedora IPA to pagure

[Mattia Verga via devel]

I'd like to start writing a script to synch users/groups from Fedora IPA 
to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based 
on Fedora accounts, but the Pagure user database is only updated when a 
user login in Pagure.

That means that by searching for a user or looking group memberships in 
Pagure we don't have an updated, real view of what we have in IPA. With 
the old FAS system there used to be a synch script provided by 
pagure-dist-git plugin, so I plan to use that as the base for a new 
synch script from IPA.

However, before digging in how (and if) is possible to add new users 
using pagure libraries, I'd like to ask if it would be acceptable to 
"copy" user data from one database to another (except passwords, which 
remain in IPA only). We will need to pass username, full name, email and 
group memberships from IPA to pagure.io/src.fp.o, which is what is done 
when a user logs in for the first time.

If that's not acceptable, I think I can just only update group 
membership for users already in pagure database.

Thoughts?

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 can I delete a rawhide Bodhi update?

[Mattia Verga via devel]

Il 23/11/23 21:11, Adam Williamson ha scritto:
> On Thu, 2023-11-23 at 20:40 +0100, Florian Weimer wrote:
>> * Mattia Verga via devel:
>>
>>> Il 23/11/23 16:40, Florian Weimer ha scritto:
>>>> I've got an update that I don't see pushed to stable.  How do I make
>>>> sure that doesn't happen?
>>>>
>>>> As it's for rawhide, I didn't create the Bodhi update, and I don't see
>>>> an option to delete it.
>>>>
>>> There's no option to delete Bodhi updates. It can only be done by
>>> hacking the database directly, but it is usually never necessary.
>>>
>>> I assume you're referring to
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2023-13783978e8. That
>>> update will never be pushed to stable, since it is gated by failed
>>> tests.
>> Half a dozen people can waive those tests, and there have been incorrect
>> waivers before. 8-/
>>
>> I just want to make sure the update  doesn't proceed because I'm not
>> entirely confident that the fix I have is logically correct.
> If we can get two more people to -1 it, Bodhi should obsolete/unpush it
> in response to that karma.
>
> As Mattia said, it's intentional that there's no option to *delete* an
> update. We don't want history to disappear. But it does seem like
> there's a workflow problem here. It would be useful for maintainers to
> have the ability to put an update in a state from which it cannot be
> pushed stable by karma or autopush (only by the maintainer or a
> provenpackager changing the state again). For regular release updates
> the maintainer can at least "unpush" them, though I'm not sure this
> fully achieves the goal. For Rawhide updates it looks like you can't
> even do that, which is awkward. I'd say it's probably worth filing a
> Bodhi issue for this...

That's weird: as a provenpackager I had the "edit" button available in 
the webUI, so I would assume that Florian as the update submitter should 
have it too. Anyway, despite not having the button for unpushing the 
update, I was able to do that by CLI.

I must say this is really a rare case when an automatic update which is 
gated by failing tests and stuck in testing, but I'll look to provide an 
unpush button in the web UI when this happens. It would have been nice 
to test if Florian had the power to unpush the update by CLI, 
unfortunately I already did so... maybe next time.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 can I delete a rawhide Bodhi update?

[Mattia Verga via devel]

Il 23/11/23 16:40, Florian Weimer ha scritto:
> I've got an update that I don't see pushed to stable.  How do I make
> sure that doesn't happen?
>
> As it's for rawhide, I didn't create the Bodhi update, and I don't see
> an option to delete it.
>
There's no option to delete Bodhi updates. It can only be done by 
hacking the database directly, but it is usually never necessary.

I assume you're referring to 
https://bodhi.fedoraproject.org/updates/FEDORA-2023-13783978e8. That 
update will never be pushed to stable, since it is gated by failed 
tests. Just do another build with a newer nvr and the old update will 
get obsoleted and it will stay in history to remind that particular nvr 
was broken.

Mattia

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Inactive packages removed from packager group

[Mattia Verga via devel]

Il 18/11/23 21:08, Kevin Fenzi ha scritto:
> Hi all,
>
> Today, 2023-11-18, we have removed inactive packagers
> from the packager group.
>
> This is in accordance with the FESCo policy on inactive packagers:
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
>
> If the removed user is 'main admin' for a package, this package
> will be orphaned. If there are co-maintainers for the package,
> one of them should take the role of 'main admin',
> by clicking "✋ Take" on
> `https://src.fedoraproject.org/rpms/`".
>
> Otherwise any packager may take the package while it's orphaned.
> After 6 weeks, the package will be retired.
> After another 8 weeks, a new review is needed to unretire it.
> see 
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
> for more details.
>
> More details available in https://pagure.io/fedora-infrastructure/issue/11621
>
> Packages that have been orphaned are:
>
Here it is the alphabetically ordered list of packages:

container/container-engine
container/docker
container/etcd
container/flannel
container/glusterfs
modules/X11-base
modules/cloud-init
modules/dhcp
modules/networking-base
modules/shared-userspace
modules/storage-devices
rpms/VirtualGL
rpms/apiextractor
rpms/appmenu-qt
rpms/arora
rpms/aspell-ar
rpms/aspell-he
rpms/bash-completion-extras
rpms/beefy-miracle-backgrounds
rpms/beefy-miracle-kde-theme
rpms/bidiv
rpms/bird
rpms/bluedevil
rpms/boinc-client
rpms/bugyou
rpms/bugyou_plugins
rpms/byobu
rpms/byzanz
rpms/cagibi
rpms/cairo
rpms/coin-or-lemon
rpms/colord-kde
rpms/constantine-backgrounds
rpms/constantine-kde-theme
rpms/copr-messaging
rpms/cpptoml
rpms/createrepo_c
rpms/cutter
rpms/desktop-backgrounds
rpms/dictd
rpms/dogtail
rpms/dosbox-staging
rpms/dovecot-fts-xapian
rpms/dropbear
rpms/drupal7-advanced_help
rpms/drupal7-auto_nodetitle
rpms/drupal7-calendar
rpms/drupal7-ckeditor
rpms/drupal7-date_ical
rpms/drupal7-email
rpms/drupal7-features
rpms/drupal7-feeds
rpms/drupal7-flexifilter
rpms/drupal7-footnotes
rpms/drupal7-google_analytics
rpms/drupal7-honeypot
rpms/drupal7-job_scheduler
rpms/drupal7-mediawiki_api
rpms/drupal7-module_filter
rpms/drupal7-panels
rpms/drupal7-pathauto
rpms/drupal7-rules
rpms/drupal7-site_map
rpms/drupal7-strongarm
rpms/drupal7-theme-adaptivetheme
rpms/drupal7-token
rpms/drupal7-views_bulk_operations
rpms/drupal7-views_slideshow
rpms/drupal7-webform
rpms/drupal7-workbench
rpms/drupal7-workbench_moderation
rpms/drupal7-xmlsitemap
rpms/echo-artist
rpms/ed
rpms/elementary-onboarding
rpms/emacs-evil
rpms/emacs-goto-chg
rpms/emacs-undo-tree
rpms/esc
rpms/f21-backgrounds
rpms/f22-backgrounds
rpms/fbf-mukti-fonts
rpms/fedwatch
rpms/fish
rpms/fontopia
rpms/fwknop
rpms/gball
rpms/gears-backgrounds
rpms/generatorrunner
rpms/ghc-X11-xft
rpms/ghc-crypto-cipher-types
rpms/glue-validator
rpms/gnome-video-arcade
rpms/gnudos
rpms/goddard-backgrounds
rpms/goddard-kde-theme
rpms/gogoc
rpms/golang-github-bruth-assert
rpms/golang-github-elithrar-simple-scrypt
rpms/golang-github-fatih-set
rpms/golang-github-kurin-blazer
rpms/golang-github-mattetti-filebuffer
rpms/golang-github-minio
rpms/golang-github-pkg-xattr
rpms/golang-github-restic-chunker
rpms/golang-github-tg-gosortmap
rpms/golang-github-vividcortex-mysqlerr
rpms/golang-github-xlab-handysort
rpms/golang-rsc-pdf
rpms/golang-vbom-util
rpms/golang-xorm
rpms/gosnake
rpms/groonga
rpms/groonga-normalizer-mysql
rpms/gtk-murrine-engine
rpms/gtksourceview5
rpms/heat-cfntools
rpms/heisenbug-backgrounds
rpms/herqq
rpms/hspell
rpms/hunspell-ar
rpms/ibus-bogo
rpms/ibus-unikey
rpms/ibutils
rpms/icaro
rpms/jovie
rpms/jsoncpp
rpms/kaccessible
rpms/kde-plasma-ihatethecashew
rpms/keychecker
rpms/kflickr
rpms/kio-ftps
rpms/kmag
rpms/kmousetool
rpms/kmouth
rpms/kstart
rpms/ktp-accounts-kcm
rpms/ktp-approver
rpms/ktp-auth-handler
rpms/ktp-common-internals
rpms/ktp-contact-list
rpms/ktp-filetransfer-handler
rpms/ktp-kded-integration-module
rpms/ktp-send-file
rpms/ktp-text-ui
rpms/kvkbd
rpms/laughlin-backgrounds
rpms/laughlin-kde-theme
rpms/layla-fonts
rpms/lcg-infosites
rpms/legofy
rpms/leonidas-backgrounds
rpms/leonidas-kde-theme
rpms/libass
rpms/libcap
rpms/libkcddb
rpms/libkcompactdisc
rpms/libldm
rpms/libmatroska
rpms/librepo
rpms/lovelock-backgrounds
rpms/lovelock-kde-theme
rpms/lua-argparse
rpms/mdk
rpms/mediawiki-SpecialInterwiki
rpms/multitail
rpms/nagios-plugins-bdii
rpms/ndisc6
rpms/neon-backgrounds
rpms/nfacct
rpms/notification-daemon-engine-nodoka
rpms/nvme-cli
rpms/ovirt-guest-agent
rpms/pairs
rpms/perl-Audio-Beep
rpms/perl-Authen-Krb5
rpms/perl-CDDB
rpms/perl-Catalyst-Model-LDAP
rpms/perl-Catalyst-Plugin-StackTrace
rpms/perl-Catalyst-View-JSON
rpms/perl-Getopt-Simple
rpms/perl-HTML-Prototype
rpms/perl-Hash-Diff
rpms/perl-MooseX-Role-Matcher
rpms/perl-Net-Google-AuthSub
rpms/perl-Net-Lite-FTP
rpms/perl-NetPacket-LLC
rpms/perl-NetPacket-SpanningTree
rpms/perl-Pod-Coverage-Moose
rpms/perl-Proc-Simple
rpms/perl-Task-Weaken
rpms/perl-Test-Script-Run

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

[Mattia Verga via devel]

Il 03/11/23 02:43, Neal Gompa ha scritto:
> * appstream-data needs to move its content from
> /usr/share/app-info/{xmls,icons} to /usr/share/swcatalog/{xml,icons}

I think this is the third time they change path. BTW, 'app-info' was the 
previous one, 0.16 used 'metainfo' [1], now 'swcatalog'... let's hope 
they're happy with this last name.

Mattia

[1] 
https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps

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

[Mattia Verga via devel]

Il 25/10/23 12:54, Tomas Hrcka ha scritto:
> This looks like a bug in bodhi.
>
Actually, it was done that way on purpose. The HTML rendered output 
shows frozen releases in the same table of pending releases by a hack, 
but for API purposes I just let the output being pedantic about the 
requested state value.

As wrote in another reply, you could query frozen releases with 
`?state=frozen`. If there is need to have a single query returns both 
pending and frozen, I suppose we could modify the input argument to 
accept a comma separated list of values, like `?state=pending,frozen`.

Mattia

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

Renaming python-jsonschema-spec to python-jsonschema-path

[Mattia Verga via devel]

Because of upstream name changed, I'm announcing the rename of 
python-jsonschema-spec to python-jsonschema-path in Rawhide and F39. 
Currently the consumers of python-jsonschema-spec are:

python-openapi-core
python-openapi-spec-validator

The change should be transparent to other packages, as the new package 
will provide proper Provides and Obsoletes tags. The former package will 
be retired.

Currently waiting for package review of the new package: 
https://bugzilla.redhat.com/show_bug.cgi?id=2244182

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: zlib-ng as a compat replacement for zlib

[Mattia Verga via devel]

Is there any chance we can have this drafted as a change request for F40?

Inviato da Proton Mail mobile

 Messaggio originale 
Il 19 Set 2023, 18:26, Daniel Alley ha scritto:

> Will this be posted soon? ___ 
> devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an 
> email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Trivial review swaps

[Mattia Verga via devel]

Hello folks,

I have a couple of trivial packages waiting for reviews:

- libahp-gt - Driver library for the AHP GT Controllers 
(https://bugzilla.redhat.com/show_bug.cgi?id=2237299)
- libahp-xc - Driver library for the AHP XC Correlators 
(https://bugzilla.redhat.com/show_bug.cgi?id=2237300)

I'd happy to swap reviews with anyone in need. Comments from new 
packagers in need of sponsorship are welcome (though I'm not a sponsor).

Thank you

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Contact attempt for the Inactive Packagers Policy for the F39 release cycle

[Mattia Verga via devel]

Please, if you have not received this email directly from me (not through the 
mailing list) and you are not listed in the affected username, there's no need 
to reply.

Thank you.

Mattia

Il 03/10/23 13:57, Adam Piasecki ha scritto:

> Hello,
>
> Yes - I would like my account to continue being listed in the `packager` 
> group, as I am eager to contribute to Fedora.
>
> Regards,
> Adam Piasecki.
>
> On Tue, 3 Oct 2023 at 04:23, jeff stewart  wrote:
>
>> Yes still interested in contributing to fedora
>>
>> On Thu, Sep 28, 2023, 9:06 AM Mattia Verga via devel 
>>  wrote:
>>
>>> 
>>> This email was sent both to the mailing list for raising awareness to
>>> the community and BCC directly to the affected users from which we need
>>> a reply. If you have received this email only from the mailing list, you
>>> can ignore the next part.
>>> 
>>>
>>> Hello,
>>>
>>> during our periodic check as per the "Inactive packagers policy" [1] we
>>> detected no activity from you as a packager, nor in other Fedora
>>> community places, like Bodhi or mailing lists.
>>>
>>> In order to reduce security risks from possible accounts hijacking we
>>> tried to contact you by tagging your username in the appropriate ticket
>>> within pagure.io repository [2], but your username is not registered
>>> there, so we cannot contact you in that way.
>>>
>>> Please, let us know if you're still intersted in participating in Fedora
>>> and if you still need your account to be listed in the packager group.
>>> You can reply here in the mailing list, so that your activity can be
>>> detected by the script, or just login in pagure.io with your Fedora
>>> account and reply to the ticket which refers to your username.
>>>
>>> Without any reply from you, one week after the release of F39 the
>>> `packager` group membership will be removed from your account and any
>>> package for which you are the main admin will be orphaned, so that
>>> co-maintainers can pick them up.
>>>
>>> [1]
>>> https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
>>> [2] https://pagure.io/find-inactive-packagers/issues
>>>
>>> Thank you.
>>>
>>> Mattia
>>>
>>> -
>>>
>>> This is the full list of usernames which cannot be reached by tag in
>>> pagure.io:
>>>
>>> gsgatlin
>>> dmarlin
>>> andriy
>>> buytenh
>>> jbernard
>>> shardy
>>> bhills
>>> lgao
>>> lgoncalv
>>> krionbsd
>>> rkennke
>>> angelonord
>>> athomas
>>> dmaley
>>> eglynn
>>> endur
>>> florencia
>>> mwringe
>>> rosslagerwall
>>> sgros
>>> tlavocat
>>> xinghong
>>> pcullen
>>> jshort
>>>
>>> -
>>>
>>> ___
>>> 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, report it: 
>>> https://pagure.io/fedora-infrastructure/new_issue
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/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
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Contact attempt for the Inactive Packagers Policy for the F39 release cycle

[Mattia Verga via devel]

This email was sent both to the mailing list for raising awareness to 
the community and BCC directly to the affected users from which we need 
a reply. If you have received this email only from the mailing list, you 
can ignore the next part.


Hello,

during our periodic check as per the "Inactive packagers policy" [1] we 
detected no activity from you as a packager, nor in other Fedora 
community places, like Bodhi or mailing lists.

In order to reduce security risks from possible accounts hijacking we 
tried to contact you by tagging your username in the appropriate ticket 
within pagure.io repository [2], but your username is not registered 
there, so we cannot contact you in that way.

Please, let us know if you're still intersted in participating in Fedora 
and if you still need your account to be listed in the packager group. 
You can reply here in the mailing list, so that your activity can be 
detected by the script, or just login in pagure.io with your Fedora 
account and reply to the ticket which refers to your username.

Without any reply from you, one week after the release of F39 the 
`packager` group membership will be removed from your account and any 
package for which you are the main admin will be orphaned, so that 
co-maintainers can pick them up.

[1] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2] https://pagure.io/find-inactive-packagers/issues

Thank you.

Mattia

-

This is the full list of usernames which cannot be reached by tag in 
pagure.io:

gsgatlin
dmarlin
andriy
buytenh
jbernard
shardy
bhills
lgao
lgoncalv
krionbsd
rkennke
angelonord
athomas
dmaley
eglynn
endur
florencia
mwringe
rosslagerwall
sgros
tlavocat
xinghong
pcullen
jshort

-

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

[Mattia Verga via devel]

Il 27/09/23 19:01, Stephen Gallagher ha scritto:
> On Wed, Sep 27, 2023 at 12:59 PM Ron Olson  wrote:
>> I mean this sincerely: Where is the excellent documentation? I admit that 
>> I’ve been frustrated that web searches leads me all over the place, 
>> sometimes the documentation is obsolete, or it’s someone’s blog post, etc. 
>> I’ve been surprised again and again there’s a macro for this or that which 
>> could have made the job much easier, but I had no idea until I asked here or 
>> in IRC.
>>
> The documentation he's referring to is the
> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
>
> Indeed, we probably should figure out a way to make that link more
> prominent on the Packaging Guidelines pages, though.

As I recently noticed because of a package of mine started to FTB, there 
are no defaults for CPPFLAGS and that env variable is not set 
automatically in each specfile section.

Is because it is useless to have some defaults set? (BTW I've fixed my 
package FTB by export CPPFLAGS = CXXFLAGS as I don't have any knowledge 
what to set there...)

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packaging guidelines - validation of AppStream metadata files

[Mattia Verga via devel]

Il 27/09/23 23:49, Neal Gompa ha scritto:
> On Wed, Sep 27, 2023 at 5:41 PM Kevin Fenzi  wrote:
>> On Wed, Sep 27, 2023 at 10:05:38AM -0400, Neal Gompa wrote:
>>> On Wed, Sep 27, 2023 at 9:48 AM Richard Hughes  wrote:
>>>> On Wed, 27 Sept 2023 at 13:23, Mattia Verga via devel
>>>>  wrote:
>>>>> Can't this script be moved to run in Openshift as cron-based?
>>>> Yes! In fact, that's what I proposed about a decade ago when I wanted
>>>> to include the data in the metadata like Debian does. I do think it
>>>> should be managed by someone in the rel-eng/infra team rather than me.
>>>>
>>> openSUSE and Mageia both do it this way too. If we move to running the
>>> script in infra, we should just make the switch to appending it to the
>>> repodata. When I helped Mageia set it up[1], we elected to compose it weekly
>>> and re-append the results for every repo push until the appstream
>>> repodata was regenerated.
>>>
>>> Also, our compose process *has* gotten faster over the past decade, so
>>> we may be able to do this at compose-time now.
>> Here's the old releng ticket about this (I think):
>> https://pagure.io/releng/issue/5721
>>
>> In addition to appstream data, there's the screenshots.
>>
>> I agree much has changed and we should revisit how best to do this
>> process.
>>
>> I'm not sure at all that it would be possible to do at compose-time...
>> composes are taking around 3.5-4hours and thats after I have done
>> a lot to speed them up, but might be worth some benchmarking
>> to see how much slower it would be. If we are going to go that route, we
>> should see if support could be added to pungi.
>>
>> Moving this from a package to in repodata would grow the repodata quite
>> a lot right?
>>
> It's additional repodata files, files that are not even downloaded by
> anything except PackageKit (currently). So the main repodata sizes
> don't change.
>
Perhaps we can mimic the bodhi-critpathcron pod and run the script 
within the bodhi openshift role once a week? I haven't looked in depth 
into the script, but I think we'll need to mount the archive from 
somewhere in network to avoid cloning the main mirror, run the script 
and then synch the output somewhere?

I'd suggest to avoid adding the step within pungi or bodhi-composer: 
Richard said it takes about an hour per release and I don't think we 
need to have it run at each compose (it would be nice, though, but we're 
now running it once per month and the world is still here). Also, 
bodhi-composer already does too much things and when a compose fails a 
lot of garbage is left behind (broken synch between update states in 
bodhi and koji builds tags), so better not add another possible failure 
point.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packaging guidelines - validation of AppStream metadata files

[Mattia Verga via devel]

Il 27/09/23 13:24, Richard Hughes ha scritto:
> On Tue, 26 Sept 2023 at 03:16, Neal Gompa  wrote:
>> So a stopgap solution was implemented: appstream-data. Richard Hughes
>> maintains a local mirror of the full Fedora repositories and generates
>> the appstream data from that using scripts[1] and extra data[2] to
>> produce the appstream-data package[3].
> That's a really good writeup, thanks. Note, I'm not the only person
> who can generate metadata, and I'd *love* someone to take over the
> task if they've got more time than me. We used to build the new
> metadata weekly, but it's slipped to monthly, if that frequently.
>
> The storage requirement of a "full mirror" is ~8G for centos and ~720G
> for Fedora -- and although NVMe is faster, I use an external HDD. You
> can also generate the metadata on laptop-class hardware -- it takes
> about an hour per release or an order of magnitude faster with fast
> NMVe and server class hardware. I've not tried to use
> appstream-compose yet, but it might work.
>
> Ideally this is something that could be picked up by release
> engineering, but I've fought that battle and lost each time. C'est la
> vie.
>
> Richard.

Can't this script be moved to run in Openshift as cron-based? Something 
like the Package Review Status app, although the storage requirements 
are totally different (but, maybe, there's a way to avoid cloning the 
mirror "locally" in Openshift and use a network mounted directory?).

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packaging guidelines - validation of AppStream metadata files

[Mattia Verga via devel]

Il 24/09/23 01:18, Neal Gompa ha scritto:
> On Sat, Sep 23, 2023 at 6:05 PM Michael Catanzaro  
> wrote:
>> On Sat, Sep 23 2023 at 10:26:48 PM +0200, Alexander Ploumistos
>>  wrote:
>>> Could someone involved
>>> with AppStream please provide some information? Shouldn't our
>>> documentation be changed to reflect these changes? Does the FPC need
>>> to decide on this?
>>   From upstream perspective: appstream-util is indeed obsolete. Upstream
>> software should stop using it and switch to appstreamcli instead.
>>
>> But as you've noticed, it seems Fedora isn't ready for that yet
> Ultimately, appstream-util's output is what matters since we use
> appstream-builder (from appstream-glib) to generate our AppStream
> metadata index. If it doesn't pass that tool, it doesn't show up.
>
If upstream switched to appstreamcli, what tool do they use to generate 
the index to not fail validation?
Can Fedora switch to that other tool?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Proposal: KDE Plasma 6 (System Wide)

[Mattia Verga via devel]

Il 15/09/23 11:25, Marcin Juszkiewicz ha scritto:
> W dniu 13.09.2023 o 17:53, Aoife Moloney pisze:
>
>> == Summary ==
>> KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
>> Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
>> changes and improvements over previous versions. For Fedora Linux, the
>> transition to KDE Plasma 6 will also include dropping support for the
>> X11 session entirely, leaving only Plasma Wayland as the sole offered
>> desktop mode.
> Which leaves us with "Numpad shortcuts don't work in wayland sessions"
> bug in KDE/Wayland:
>
> https://bugs.kde.org/show_bug.cgi?id=453423
>
> Someone in KDE decided to treat KEY_KP1 ("1" on numpad part of pc105
> keyboard) in same way as KEY_1 ("1" on alphanumeric part of pc105
> keyboard). Which breaks several setups where people use shortcuts with
> numpad keys (for me it is Meta+KP[1-9] to organize windows).
>
>
> This bug is one of reasons I am still on KDE/X11 rather than KDE/Wayland.
>
Interesting, see also what I reported about the decimal separator from 
the numpad not honouring the locale setting:

https://bugzilla.redhat.com/show_bug.cgi?id=2215739
https://bugs.kde.org/show_bug.cgi?id=449706
https://bugs.documentfoundation.org/show_bug.cgi?id=143540

So the whole numpad in kde-wayland doesn't work as expected. 
Unfortunately, it doesn't seem anyone cares because "can be worked 
around by using the other key". Hopefully, when everyone will be forced 
to Wayland and start reporting broken things, someone will look at that.

Mattia

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

[Mattia Verga via devel]

Il 13/09/23 11:58, Filip Janus ha scritto:

> Hi all,
> mkulik is the main admin of pg_auto_failover component, and I can't reach 
> him. So I would like to start the process of moving the main admin role to 
> me(I am an admin now but the default assignee is mkulik due to the main admin 
> role).
> Here is the mandatory BZ:
> https://bugzilla.redhat.com/show_bug.cgi?id=2238708
>
> -Filip-

Note that there's also an ongoing ticket for the inactive packagers policy:

https://pagure.io/find-inactive-packagers/issue/1673

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

[Mattia Verga via devel]

Il 11/09/23 15:08, Tomas Hrcka ha scritto:

> Sorry for the confusion with work that is already done,
> We can drop the critpath thanks Adam!
>
> As it goes for EoL and package retirement we for the past few releases we are 
> saving EOL date in bodhi.
> So getting EOL for specific release is not a problem once the release is out.
>
> For storing the orphaning reason and other potential metadata. We can store 
> some of it in git in form of notes on branches not necessarily in 
> pagure-disgit specific code-base.
>
> With toddlers i think the path is clear we need to use bodhi as a source of 
> truth about releases.
> Similar work as on toddlers will need to be done on mdapi
>
> For the compose metadata we can store the the json blobs on fedorapeople for 
> now and search for some stable place.
> --
>
> Tomas Hrcka
> fas: humaton
> libera.CHAT: jednorozec

To bring some more information from PDC into Bodhi, I'm working on a couple of 
PRs which will add the following information to Bodhi output:

- New Release property "released_on", to show the final release date of a 
release
- New Release property "setting_status", to show the status of the release 
between Branched and Final. This will use the 'pre-beta' / 'post-beta' settings 
in Bodhi with the meaning pre-beta=branched, post-beta=beta.
- New Bodhi json endpoint to provide the list of critpath components for each 
release (this is also available through a pagure repository, but I think it 
would be nice nonetheless)

Let me know if there's some other info which would be nice to migrate from PDC 
to Bodhi...

Mattia___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer check for Karsten Hopp (karsten)

[Mattia Verga via devel]

Il 09/09/23 02:09, Valter Sage ha scritto:
> Does anyone know how to contact Karsten Hopp (karsten)? This email is 
> part of the non-responsive maintainer process 
> (https://bugzilla.redhat.com/show_bug.cgi?id=2237962).
>
> The activity report at https://src.fedoraproject.org/user/karsten/ 
> shows no activity in the past year, and fedora-active-user reports:
>
> Last package update on bodhi:
>    2020-10-21 13:02:09 on package libcap-2.44-1.fc34
>
> A list of some other apparently-neglected bugs follows:
>
>     libcap: sole maintainer, new version available for almost three 
> years https://bugzilla.redhat.com/show_bug.cgi?id=1919609
>
>     dictd: FTBFS in Fedora rawhide/f39 
> https://bugzilla.redhat.com/show_bug.cgi?id=2225754
>
> I apologize in advance for any errors or omissions in this list.


Note that there is also an ongoing ticket for the inactive-packagers policy:

https://pagure.io/find-inactive-packagers/issue/1478

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Exclude i686 builders for noarch packages

[Mattia Verga via devel]

Il 07/09/23 06:11, Orion Poplawski ha scritto:
> I'm running into an issue where python-rpds-py excludes i686:
>
> # https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> # Also rust-rpds is not available on i686
> ExcludeArch:%{ix86}
>
> but then my python-nbformat build gets sent to an i686 builder and fails
> because python3-rpds-py is not available:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=105847966
>
> It seems annoying to have to propagate the ExcludeArch up the stack for
> this.
>
> Thoughts?
>
https://bugzilla.redhat.com/show_bug.cgi?id=2237647

rpds tests have just been fixed upstream for i686 and I will remove the 
ExcludeArch from it.

Mattia

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

Inactive provenpackagers policy for the f39 cycle

[Mattia Verga via devel]

This is a bit late on schedule, but...

In accordance with FESCo policy[1], the following provenpackagers will
be submitted for removal in two weeks based on a lack of Koji builds
submitted in the last six months. If you received this directly, you
can reply off-list to indicate you should still be in the
provenpackager group.

Note that removal from this group is not a "punishment" or a lack of
appreciation for the work you have done. The intent of the process is
to ensure contributors with distro-wide package privileges are still
active and responsive. This process is done regularly at the branch
point in each release.

[1] 
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status



Checked 132 provenpackagers
The following 10 provenpackagers have not submitted a Koji build since 
at least 2023-02-23 00:00:00:
puiterwijk
ajax
rdieter
ausil
pjones
hguemar
jwilson
law
wtogami
steve



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

[Mattia Verga via devel]

Il 30/08/23 22:02, Ben Cotton ha scritto:
> On Wed, Aug 30, 2023 at 2:47 PM Kevin Fenzi  wrote:
>> Might you be willing to also do the provenpackager one?
>> ( https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ )
>>
> For Mattia (or anyone else who wants to pick this up), you can see my
> SOP at 
> https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/inactive-provenpackagers/
>
Thank you, I'll read the steps above and send the notification ASAP. 
(not sure I can post to devel-announce, though)

Mattia

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

Inactive packager policy for the F39 cycle

[Mattia Verga via devel]

Hello folks,

I've started the "Inactive Packagers Policy" procedure [1] for the F39 
release cycle.

For each user detected as "inactive" a ticket was opened and the full 
list can be seen at [2]. In two weeks I'll post a comment in each ticket 
still open with a list of affected packages that possibly will get 
orphaned along with a list of affected co-maintainers.

If you're receiving this email directly (not through the mailing list) 
is because you're one of the affected packagers that never logged in 
into pagure.io with your Fedora Account, therefore the tagging mechanism 
cannot send you a notification. You can reply here if you don't want to 
log in into pagure.io.

For any other user reached by this email through the mailing list, 
please take a look at the list of user that cannot be tagged directly 
[3] to check if you know a way to reach them out.

Thank you
Mattia

[1] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2] 
https://pagure.io/find-inactive-packagers/issues?status=Open=inactive_packager_status=
[3] 
https://pagure.io/find-inactive-packagers/issues?status=Open=user_not_taggable_status=

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Tracker bug for approved change proposals

[Mattia Verga via devel]

Il 01/08/23 19:03, Fabio Valentini ha scritto:
> On Tue, Aug 1, 2023 at 7:00 PM Tulio Magno Quites Machado Filho
>  wrote:
>> I noticed that a few change proposals that have been approved still did
>> not get a bug tracker, e.g.: https://fedoraproject.org/wiki/Changes/LLVM-17
>>
>> As things have changed this release, I'm wondering if the process
>> changed.
>> Is the bug creation still in plan?
> As far as I know, yes. It's likely that just nobody has done it yet.
> I think we'll need to go through the "active" change proposals and
> need to figure out which steps are missing for which Changes.
>
> Fabio

There are also some change proposal which were submitted within 
schedule, but never got their Fesco ticket, like 
https://fedoraproject.org/wiki/Changes/LibreOffice_7.6

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 Change Proposal: LibreOffice 7.6 (Self-Contained)

[Mattia Verga via devel]

Il 22/07/23 22:31, Kevin Fenzi ha scritto:
> On Fri, Jul 21, 2023 at 04:31:01PM +0100, Aoife Moloney wrote:
>> https://fedoraproject.org/wiki/Changes/LibreOffice_7.6
>>
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will only be implemented if approved
>> by the Fedora Engineering Steering Committee.
>>
>> == Summary ==
>> Update LibreOffice suite to 7.6
>>
>>
>> == Owner ==
>> * Name: [[User:mattia| Mattia Verga]]
>> * Name: [[User:limb| Gwyn Ciesla ]]
>> * libreoffice-SIG
>> * Email: mattia.ve...@protonmail.com, gw...@protonmail.com
>>
>>
>>
>>
>> == Detailed Description ==
>> LibreOffice 7.6 is currently in Beta and the first stable release is
>> currently scheduled during F39 development. We aim to bring the latest
>> LibreOffice stable release in F39.
> When is the stable release scheduled for? ie, how does it align with
> fedora release milestones ? Perhaps add that here?
>
>
LO 7.6 will be branched upstream the next week (week 30) and the final 
release is scheduled by week 33 (Aug 14, 2023 - Aug 20, 2023). F39 Beta 
freeze is scheduled on Aug 22.

An effort building LO 7.6 in Fedora is ongoing in 
https://copr.fedorainfracloud.org/coprs/mattia/Libreoffice7.6testing/
We are hitting some test failures that need investigation.

To upgrade LO to 7.6 some components will need to be updated (mdds, 
libixion, liborcus). CCing the package maintainer (dtardon) here.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Mattia Verga via devel]

Since RHEL is made out from Centos Stream and Centos Stream is made out from 
Fedora ELN, can't Alma and Rocky branch directly from Fedora?
Can we collaborate in some way with those communities so that we support each 
other? I mean, like we have Fedora ELN and EPEL...

Inviato da Proton Mail mobile

 Messaggio originale 
Il 11 Lug 2023, 12:49, Kevin Kofler via devel ha scritto:

> Oracle has (finally – the community projects Rocky and Alma were much quicker 
> to react) made an announcement about the situation: 
> https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/
>  Kevin Kofler ___ devel mailing 
> list -- devel@lists.fedoraproject.org To unsubscribe send an email to 
> devel-le...@lists.fedoraproject.org Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List 
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List 
> Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: more distinct default bash prompt?

[Mattia Verga via devel]

Il 09/07/23 00:05, Leon Fauster via devel ha scritto:
> Am 08.07.23 um 22:44 schrieb Barry:
>>
>>> On 8 Jul 2023, at 19:56, Kushal Das  wrote:
>>>
>>> White background is a good choice for accessibility iirc.
>> Isn’t is contrast that matters not any particular background?
>
> On the contrary it helps, a white background helps the human visual
> system to distinguish patterns better then a black on do but this is
> just one aspect to prefer the one or the other ... :-)
>
I also like white background while reading things on a support using 
natural light, but when it comes to support using backlight I prefer 
black background as I found that to be less eye tiresome (I don't know 
what science/researches say about this, it's just my personal experience).

Anyway, I don't care about defaults as far as I can found the way to set 
back settings with ease.

Mattia

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

[Mattia Verga via devel]

Il 08/07/23 13:06, Vitaly Zaitsev via devel ha scritto:
> On 06/07/2023 18:10, Aoife Moloney wrote:
>> but the conversation about each change
>> will take place on Fedora Discussion at
>> https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320
> It looks like they've started moving replies they don't like to other
> threads to cover up the flow of resentment that comes naturally to them.
>
> That's why switching to Fedora Discussion from the mailing lists is a
> very bad idea: admins or RH staff can easily delete your comments or
> bury them in another threads.
>
Can we please stop implying malevolence every time we don't agree with 
something?

BTW in the spirit of openness, I've set up a poll (UNOFFICIAL) to 
clearly state community sentiment about enabling OPT-OUT metrics to FESCO:
https://discussion.fedoraproject.org/t/unofficial-poll-about-opt-out-metrics-proposal/85494

Just a simple question and a YES/NO reply.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Python 3.12 side tag merging today (and what to do)

[Mattia Verga via devel]

Il 04/07/23 16:51, Tomáš Hrnčiar ha scritto:

> Many packages only fail to build because their dependencies were not yet 
> rebuilt. Chances are, you will get an automated F39FailsToInstall bugzilla 
> soon, indicating your package fails to install. It would be really helpful if 
> you could find the missing dependency and mark the bugzilla for your package 
> depending on the bugzilla for the missing dep. We plan to do that as well, 
> but your help is crucial here.

Well, python-robosignatory build fails because tests are failing due to a 
broken python-crochet: the latter has been marked to have been built fine, 
however due to a really old version available in Fedora repositories, it will 
not work. Not sure why python-crochet tests have not failed, but the current 
version still has 'import imp' which were removed in python 3.12.

Maybe there are other packages depending on crochet affected as well.

Mattia___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SIG proposal: libreoffice-sig

[Mattia Verga via devel]

Greetings folks,
the libreoffice-sig is now live.
Anyone interested can join the `#libreoffice-sig:fedoraproject.org` matrix room 
for discussion. If you're a packager and like to help maintain LO and related 
packages, you can ask to join the 
https://accounts.fedoraproject.org/group/libreoffice-sig/ FAS group.

If you maintain a LO package or any dependency, you're invited to add commit 
(or admin) access for libreoffice-sig group to your package and change the 
default bugzilla assignee to libreoffice-sig group. This will make BZ emails be 
sent to the libreoffice-...@lists.fedoraproject.org mailing list which you're 
also encouraged to join (this list is set as private as the only purpose is for 
BZ related activity; for active discussions please use the matrix room).

That should be all, let me know if I have forgot something important.
Thanks to all for your work in supporting Libreoffice RPM packaging in Fedora!

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

[Mattia Verga via devel]

Il 20/06/23 17:31, Zbigniew Jędrzejewski-Szmek ha scritto:
>
> [1] https://src.fedoraproject.org/rpms/postgresql/pull-request/59
>
> Zbyszek

Isn't the package name required to match the name of specfile?

Mattia

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

[Mattia Verga via devel]

Il 19/06/23 08:26, Vitaly Zaitsev via devel ha scritto:
> On 18/06/2023 14:51, Sandro wrote:
>> Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb'
>> alias would fail since no changes have been pushed to dist-git for koji
>> to base a build on.
> Good catch. Thanks:
>
> alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg
> switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide
> && git push"
>
> --
> Sincerely,
> Vitaly Zaitsev (vit...@easycoding.org)

Nice, thanks.

I only need to find how to pass branch names to the alias, instead of 
hardcoding them. From a quick search I need to create a function in 
.bashrc rather than an alias.

Mattia

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

Releasing package updates in multiple Fedora releases

[Mattia Verga via devel]

For the 99% of packages I maintain I usually perform the same workflow 
when updating them:

1. Update spec and source in Rawhide
2. commit and push
3. fedpkg build
4. fedpkg switch-branch f*
5. git merge rawhide
6. push and fedpkg build

And repeat 4-5-6 for every f*/epel* branches where I want to push the 
update.

This is quite boring and time wasting... is there a more efficient way 
to use my packaging time? Do you think fedpkg can be enhanced to have a 
single command which makes 4-5-6 to all specified branches?

Mattia

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

[Mattia Verga via devel]

Il 17/06/23 11:50, Miro Hrončok ha scritto:
> On 13. 06. 23 14:02, Tomas Hrnciar wrote:
>> Hello,
>>
>> in order to deliver Python 3.12, we are running a coordinated rebuild in a 
>> side
>> tag.
>>
>> https://fedoraproject.org/wiki/Changes/Python3.12
>> 
>>
>> We anticipate starting this rebuildsometimethis week.
>>
>> If you see a "Rebuilt for Python 3.12" (or similar) commit in your package,
>> please don't rebuild it in regular rawhideor another rawhide side tag. If you
>> need to, please let us know, so we can coordinate.
>>
>> If you'd like to build apackageafter we already rebuilt it, you should be 
>> able
>> to build it in the side tag via:
>>
>> on branch rawhide:
>> $ fedpkg build --target=f39-python
>> $ koji wait-repo f39-python --build 
>>
>> Note that it will take a while before all the essential packages are rebuilt,
>> so don't expect all your dependencies to be available right away. Please, 
>> don't
>> attempt to build your package in the side tag before we do.
>> When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me
>> (thrnciar) or Miro (mhroncok) if you need to talk to us.
>>
>> Builds:
>> https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0
>>  
>> 
>>
>> Please avoid any potentially disturbing or major changes in Python packages
>> until the rebuild is over.
>>
>> Thanks. Let us know if you have any questions.
> Hey folks,
>
> apologies if you have missed our announcement, but I'd like to ask you not to
> build packages in rawhide if they have received a "Rebuilt for Python 3.12"
> commit. For details, see the announcement quoted above.
>
Sorry, I think I've messed things up.

I have pushed new builds of python-jsonschema-spec and 
python-openapi-spec-validator in Rawhide, then I realized there was the 
python 3.12 rebuild in progress, so I started a new build in f39-python 
for both packages, but then I realized again they were not part of the 
rebuild and canceled tasks...

Did I understand well that only packages which had received the "Rebuilt 
for Python 3.12" commit message need to be built inside the f39-python 
side-tag? All other packages can be built and don't need to wait?

Mattia

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

[Mattia Verga via devel]

I've filed the request to set up a libreoffice-sig: 
https://pagure.io/fedora-infrastructure/issue/11372

If I forgot something in the request, please correct it. I've also quickly set 
up a wiki page which can be enhanced in many ways... ;-)

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Issue with Rawhide docker image?

[Mattia Verga via devel]

Il 07/06/23 21:10, Adam Williamson ha scritto:
> On Wed, 2023-06-07 at 14:55 -0400, Daniel Walsh wrote:
>> On 6/7/23 13:31, Kevin Fenzi wrote:
>>> On Wed, Jun 07, 2023 at 07:19:32PM +0200, Iñaki Ucar wrote:
 On Wed, 7 Jun 2023 at 19:15, Kevin Fenzi  wrote:
> On Tue, Jun 06, 2023 at 12:30:56PM -0500, Chris Adams wrote:
>> Once upon a time, Clement Verna  said:
>>> Once https://github.com/docker-library/official-images/pull/14789 
>>> merges,
>>> the rawhide image on the DockerHub should be fixed too :-)
>> So... if it takes a manual process (including opening a PR), does it
>> really make sense to put Rawhide images on Dockerhub?
> Sadly, lots of people look there, but yeah... it's not great.
 Yeah, basically, because $VISIBILITY. Anyway this looks like something
 that could be easily automated via GH Actions.
>>> Any automation there would probibly need buy-in from docker folks,
>>> because if we filed a automated PR every day and a docker human had to
>>> review/merge it, they might not think thats a good way to spend their
>>> time.
>>>
>>> kevin
>>>
>> If people would just use Podman they would not have this issue.
>>
> The Bodhi CI (one of the affected cases) seems to actually support both
> docker and podman, but default to docker. Not sure why, I guess Mattia
> could say.

No idea... the CI stuff was present before I started messing with Bodhi. 
I think it was set up by CPE folks.

But... how does using podman would overcome the issue? As far as I know, 
`docker` command in fedora is just a wrapper which runs podman. Doesn't 
podman uses the same dockerfiles? Or maybe podman understands the 'FROM 
fedora:rawhide' differently than docker (doesn't point to docker hub as 
default)?

Mattia

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

[Mattia Verga via devel]

Il 06/06/23 21:16, Fabio Valentini ha scritto:
> On Tue, Jun 6, 2023 at 9:01 PM Gwyn Ciesla via devel
>  wrote:
>> I would honestly prefer ownership be transferred to the libreoffice -sig, of 
>> which I am more than happy to be a member.
> This is not possible, the "main admin" needs to be a person, and
> cannot be a group. However, the default assignee for BugZilla bugs
> *can* be overridden to be a group, which is basically the next best
> thing.
>
> In my experience (:sad java face:), what's needed to form a SIG that
> can maintain packages is:
>
> - requesting a FAS group *with* dist-git group
> - a private mailing list that will receive bugzilla email
> - a bugzilla account registered with the email address of this private
> mailing list
> - a Wiki page (though this is less important than it used to be)
> - (maybe I forgot something)
> (but fedora-infra people will also tell you what you need if you open a 
> ticket)
>
> Most SIGs also have IRC / Matrix channels or tracking projects on
> pagure, but these are all optional and can be added later.
>
> And I'm not sure how much time I can contribute, but I'd also like to
> help keep libreoffice RPMs available in Fedora. :)
>
> Fabio

Ok, as soon as I have some free time I'll file the request to 
fedora-infra and set up the wiki page. Unless someone beats me in time, 
I would not object that :-p

I was thinkink to use the mailing list address only for bugzilla 
purposes, since it would be private, and ask to set up a Discourse 
tag/section for project coordination. Thoughts?

As for admin privileges on the FAS group and ML, I'd like to ask 3-4 
people to be set up. @decathorpe, @limb, @sharkcz ? @caolanm and 
@sbergmann would you like to continue helping in your great work on LO 
packages outside RH assignment?

Mattia

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

SIG proposal: libreoffice-sig

[Mattia Verga via devel]

I'm forking this proposal off from the other thread, as it got buried 
under tons of posts.

Shall we set up a libreoffice-sig to coordinate and ensure that 
libreoffice and all dependencies are properly maintained and updated as 
RPMs? Are there enough users which, like me, don't like the idea to only 
have LO available as a flatpak from an external service like Flathub and 
would like to join forces to maintain it in RPM repos?

What it is needed to set up a SIG? A wiki page and a mailing list? And 
also a FAS group, I suppose?

BTW I've already seen a couple of hiccups which needs to be solved: the 
Bugzilla assignee of libreoffice package on src.fp.o is set to 
@sbergmann but I suppose it should now be changed to @limb? And, also, 
libreoffice 7.5.3 failed to build on Fedora Rawhide, so we now have LO 
3.5.3 on F38 and LO 3.5.2 on Rawhide.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Issue with Rawhide docker image?

[Mattia Verga via devel]

Il 05/06/23 22:12, Ron Olson ha scritto:
> Hey all, I am using docker and pulled the latest version of rawhide to 
> use interactively. Sitting in the container I ran `dnf -y update` and 
> got:
>
> Config error: Parsing file "/etc/dnf/dnf.conf" failed: Parsing file 
> '/etc/dnf/dnf.conf' failed: IniParser: Missing section header at line 1
>
> I stopped the container, deleted it, deleted the image, tried to pull 
> a fresh instance and got exactly the same issue. Suffice to say this 
> makes the container unusable.
>
> What's the protocol for informing the powers-that-be about this issue?
>
> Ron
See:
https://pagure.io/fedora-infrastructure/issue/11358
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LibreOffice packages

[Mattia Verga via devel]

Il 05/06/23 19:51, Roberto Ragusa ha scritto:
> On 6/5/23 19:13, Demi Marie Obenour wrote:
>
>> Are you willing to do the packaging work?  Asking upstream to create
>> packages for every distribution is not reasonable.
> I would never want upstream to do packaging, as experience teaches,
> they would certainly do it wrong.
> Packaging and integration is a job for the distribution; it is their
> added value. Otherwise, what's the meaning of a distribution, if
> the system is composed by a minimal booting image on which you
> add upstream generated blobs?
>
> Sorry, but the common "why do not do it yourself?" objection is not
> the correct way to address my point. As a "consumer" (even if,
> not paying) I am just expressing my idea about what I would like or not.
> The "producers" (Fedora/RH) can take note, or ignore the feedback.
> Their luck will, at the end of the day, depend on the merit of
> their choices.
> Anyway, yes, I've considered becoming a Fedora packager, I've started
> the process and then got discouraged by the abundant bureaucracy.
> And these kinds of threads do not help in regaining some enthusiasm in
> resuming the process.
>
> Regards.
>
Hey Roberto, let me know if there's something specific where I can help 
you in becoming a Fedora packager, if you're interested. It's a little 
hard at the beginning, but then you'll find out that once you get the 
basis it's really easy (if the software you're trying to package doesn't 
require some weird thing to be built, of course). Feel free to write me 
directly or to chat with me in Matrix (I'm not often in chat, though).

Mattia

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

[Mattia Verga via devel]

Il 05/06/23 17:00, Michael J Gruber ha scritto:
> I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to 
> be high maintenance, but co-admins welcome, of course. Similarly, feel free 
> to admin as co-admin to other hyphen-* in case something needs coordinations. 
> The language packages are basically a "cp" in "%install", though, and nothing 
> to build.

Yesterday I've taken hyphen-it, as well as mythes-it, and I've asked to 
be added as co-admin of hunspell-it.

I've also updated hyphen-it and mythes-it as the dictionaries were 
outdated. As far as I can see, every language points to different 
sources: I wonder if it would be easier to maintain if we switch to 
sources provided by LO at https://github.com/LibreOffice/dictionaries so 
that we'll have a single specfile and source tarball with multiple 
subpackages, one for each language.

The only problem is that in LO repository only the .dat file for 
thesaurus is provided, but the .idx file is missing. For italian 
language I had to generate the .idx file myself using 
http://proofingtoolgui.org/ and provide the sources in custom repository 
(https://pagure.io/dizionario_italiano). I couldn't find any CLI tool to 
do that.

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

[Mattia Verga via devel]

Il 02/06/23 09:22, Jiri Vanek ha scritto:
> Damn thats a long list.
>
>
Indeed. I can help and pick up a couple of packages, but what about the 
hunspell*, hyphen*, mythes*? I think those will require more work than 
what a volunteer packager can bring. Yet, I suspect dropping them will 
blow up quite a few things.

Shall we set up a libreoffice-sig to coordinate community efforts in LO 
packaging?

Mattia

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

[Mattia Verga via devel]

> If I understand the announcement correctly, future RHEL will not include 
> LibreOffice
> anymore. That’s the reason, why the maintainers have withdrawn.
> 
> 
> Instead of Flatpak I would prefer to pick up the software directly from the 
> project. LO
> provides a rpm. Maybe we have to change our packaging strategy and allow 
> „installation
> rpms“ that pick up an OSS project’s rpm and repack it with the proper system 
> integration.
> We had something like that for Java a decade ago.
> 
> That’s probably not an optimal solution, but IMO way better than yet another 
> re-packager.
> At least I would be willing to trust an OSS project more than some repackager.
> 

...or, maybe, discuss with upstream a possible collaboration where the official 
RPMs would become those built in Fedora infrastructure instead of using an 
external one.

Also, as a more general speaking, with the upcoming change which will make 
easier to produce flatpaks directly from RPMs without the need of making 
modules, we can become more attractive to upstreams, as they will have a single 
infrastructure for publishing both RPMs and Flatpaks. A bi-directional 
collaboration with upstream, especially those bigger and fully open source like 
LO, would be beneficial (I think) for both sides. Can Mindshare (or another 
Fedora team) see if this is achievable?

Mattia

> 
> Well, my lesson was years ago to drop Fedora desktop from my systems - too 
> bulky, too
> bloated, too unreliable for my liking. A nice toy, but nothing for serious 
> productive
> work.
> 
> 
> 
> --
> Peter Boy
> https://fedoraproject.org/wiki/User:Pboy
> PBoy(a)fedoraproject.org
> 
> Timezone: CET (UTC+1) / CEST /UTC+2)
> 
> Fedora Server Edition Working Group member
> Fedora Docs team contributor and board member
> Java developer and enthusiast
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LibreOffice packages

[Mattia Verga via devel]

Il 02/06/23 01:55, Sandro ha scritto:
>
> However, it surprises me that for a package, that is part of the
> deliverables of Fedora releases, no coordination effort was made to
> transition the package from Red Hat maintenance to Fedora maintenance. I
> would even go as far as that this should have been submitted as a change
> proposal, seeing that the package is in every (live) ISO Fedora ships.
>
> Instead the package is being dropped like a hot potato, without even the
> courtesy of an announcement beforehand [2].
>
I'm having a bad feeling about Fedora future lately, seeing all these RH 
withdrawals from the project.

I hope to be wrong. But could Fedora survive the day RH says goodbye? 
Shall we start thinking about having a structure (both government and 
financial) like libreoffice foundation?

BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy 
useless. Flatpaks just bundles what they need, free software or not 
(i.e. codecs support) so upstreams have no interest in find OSS solutions.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Mattia Verga via devel]

Il 30/05/23 20:37, Aoife Moloney ha scritto:
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
>
> This is the last step in
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> effort. Jdks in fedora are already static, and we repack portable
> tarball into rpms. Currently, the portbale tarball is built for each
> Fedora and Epel version. Goal here is to build each jdk
> (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
> repack in all live fedoras.
>
If I understand this correctly, this just means that java package built 
on Fedora x-2 will be tagged also in Fedora x-1, Fedora x and Rawhide. 
Am I correct?

If so, maybe the proposal needs a better wording rather than "repack in 
all live fedoras", as that sounds like RPMs are "repacked" in some way, 
but the truth is that the same RPM is made available in several Fedora 
repositories.

Mattia

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

[Mattia Verga via devel]

Il 30/05/23 22:15, Adam Williamson ha scritto:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-2b17e1e469 is stuck 
> because it was ejected from its initial push to testing,
> which means the 7 day push to stable timer never really kicks in
> (it needs to be *in testing* for seven days). It was supposedly left
> out of the push because it didn't have the right tag. It does seem to
> have the right tag now, at least, so I resubmitted it for testing. If
> that works, it should then go stable a week later.
>
This one was missing the f37-updates-candidate tag, I have manually 
tagged the build and resubmitted it to testing. The next compose should 
be the good one.

Mattia

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

[Mattia Verga via devel]

Il 30/05/23 22:15, Adam Williamson ha scritto:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-f563346d4d is
> similar, but this time it was ejected from its push *to stable* (not to
> testing), again allegedly for a missing tag. The builds have now
> actually been deleted(!), so that update can never be pushed as-is, I
> don't think. We would probably have to bump and rebuild both packages
> and edit the new builds into the update, then try pushing it again.
> CCing the maintainer of that one (Dan).

FEDORA-2022-f563346d4d can't be pushed to stable because the i3 build 
was superseded by FEDORA-2023-6e1ee729b9, but the older update was not 
obsoleted because it also has i3-gaps build which was not superseded by 
anything.

So, I think the update needs to be unpushed.

Mattia

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

[Mattia Verga via devel]

Il 29/05/23 23:33, Adam Williamson ha scritto:
> On Mon, 2023-05-29 at 12:20 -0700, Adam Williamson wrote:
>> On Mon, 2023-05-29 at 17:08 +, Leigh Scott wrote:
 Il 24/05/23 09:40, Jaroslav Mracek ha scritto:

 I've started to see failing tests upon Bodhi update submission like
 the
 following:

 Error:
    Problem: conflicting requests
     - nothing provides pkgconfig(lz4;pugixml;zlib) needed by
 libXISF-devel-0.2.5-1.fc39.x86_64 from brew-101573635

 Looks like multiple 'BuildRequires: pkgconfig()' are squashed to a
 single one and dnf5 can't understand them?

 Mattia
>>> The package is broken
>>>
>>> $ sudo dnf --enablerepo u*g install libXISF-devel
>>> Fedora 38 - x86_64 - Test Updates28 kB/s |  14 kB
>>> 00:00
>>> Fedora 38 - x86_64 - Test Updates   1.6 MB/s | 5.1 MB
>>> 00:03
>>> Last metadata expiration check: 0:00:08 ago on Mon 29 May 2023
>>> 18:06:51 BST.
>>> Dependencies resolved.
>>>
>>>   Problem: cannot install the best candidate for the job
>>>    - nothing provides pkgconfig(lz4;pugixml;zlib) needed by libXISF-
>>> devel-0.2.5-1.fc38.x86_64 from updates-testing
>> The dependency is auto-generated, it's not the packager's fault. I
>> suspect the ultimate cause is this upstream:
>>
>> https://gitea.nouspiro.space/nou/libXISF/commit/1c0d6e4e054f1c5ac461e6da3a63c5f7acaa0a28
>>
>> which causes the pkgconfig file to have this line:
>>
>> Requires.private: lz4;pugixml;zlib
>>
>> (you can see that line
>> in 
>> https://kojipkgs.fedoraproject.org//packages/libXISF/0.2.5/1.fc38/x86_64/libXISF-0.2.5-1.fc38.x86_64.rpm
>> ). That's what our dependency generator turns into
>> `pkgconfig(lz4;pugixml;zlib)`. I'll file an upstream issue.
> Upstream fixed this very quickly (thanks Dušan!) and I'm doing -2
> builds with the fix backported now. Will edit the updates.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
Thank you Adam!

Indeed, I should have looked into the problem more carefully before 
pointing my finger against dnf5.

Mattia

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

[Mattia Verga via devel]

Il 24/05/23 09:40, Jaroslav Mracek ha scritto:
> Hello,
>
> I have great news that the upcoming release of DNF5 will obsolete DNF 
> in rawhide (Fedora 39). The release is planned not before the end of 
> May.  The change was already announced in 
> https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5.
>
> Best regards
>
> Jaroslav Mracek

I've started to see failing tests upon Bodhi update submission like the 
following:

Error:
  Problem: conflicting requests
   - nothing provides pkgconfig(lz4;pugixml;zlib) needed by 
libXISF-devel-0.2.5-1.fc39.x86_64 from brew-101573635

Looks like multiple 'BuildRequires: pkgconfig()' are squashed to a 
single one and dnf5 can't understand them?

Mattia

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

[Mattia Verga via devel]

Il 27/05/23 11:56, Peter Oliver ha scritto:
>
> If we’re going to recommend migration to anything, shouldn’t it be enchant2?  
> Users would be able to configure their preferred spellchecking engine per 
> language (which I imagine is more important for some languages than others), 
> and we wouldn’t have to go through this again in the future if we 
> hypothetically decided that, say, Nuspell should replace Hunspell as our 
> default spellchecker.
>
+1 here. If we have to convince upstream to migrate to a different 
default spellchecker, I think it's better to push enchant2. If it is 
about having the package maintainer build their package against another 
spellchecker, hunspell is fine, but drop a note about enchant2 is preferred.

I'd also like to raise attention to what I think is a misleading Change 
Summary:

> Deprecating aspell package because it is no longer 
> Required/Buildrequired by any package in Fedora.
This is clearly not true, as the change is about migrating package to 
another spellchecker.

Mattia

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

[Mattia Verga via devel]

Il 26/05/23 19:39, Kevin Fenzi ha scritto:
> FESCo has been asked about creating company related groups.
> ( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
> ie, foocorp-sig / foocopr-packagers. These groups would then be used to
> help maintain packages that foocorp finds of interest/value.
> This would help companies manage the people they pay to contribute.
> It would allow them to more easily add/remove employees as time goes on
> instead of someone having to go and add/remove someone from a bunch of
> packages.

I'd like this to happen. While Fedora users are doing a great job in 
maintaining packages in their free time, I think having payed employees 
working on this can enhance package quality and overall Fedora stability 
in its whole. We just make sure no one is sponsored into packager group 
only because they are added to a company group... they still have to 
prove their understanding in Fedora packaging guidelines.

I'd say that these groups should be distinguished from SIGs by using a 
different suffix, i.e. 'foocorp-corp' for grouping by company interests 
in contrast to 'foo-sig' for grouping packages by specific 'foo' area or 
'foo' stack.

I would be however against having a group as main admin of packages. 
Groups can already be set as main POC for bugs and this is enough, IMO. 
The primary maintainer should be a real person, while a group can be set 
as admin of a package.

Mattia

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

[Mattia Verga via devel]

Il 24/05/23 21:19, Josh Boyer ha scritto:
> On Wed, May 24, 2023 at 2:55 PM Peter Boy  wrote:
>>
>>
>>> Am 24.05.2023 um 20:30 schrieb Chris Murphy :
>>>
>>> I'm pretty sure we no longer have a program manager?
>> What’s that about?
> Red Hat recently announced a round of layoffs[1] and the Fedora
> Program Manager role was impacted.
>
> Ben posted this blog: 
> https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/
>
> josh
>
> [1] https://www.redhat.com/en/blog/message-red-hat-associates-today

Wait, what?? Someone at RH wakes up in the morning and decides to cut 
one of the key roles (or better, THE) of Fedora community and this goes 
completely unannounced, unnoticed and without any backup plan?

I have seen other dumb decisions by RH about Fedora in the past, but I 
think this is the greatest one, both for Ben's role and for their person.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Mattia Verga via devel]

Il 13/05/23 03:04, Owen Taylor ha scritto:

> On Fri, May 12, 2023, 1:03 PM Mattia Verga via devel 
>  wrote:
>
>> Il 10/05/23 12:54, Aoife Moloney ha scritto:
>>> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
>>>
>>>
>> I've never tried to make a flatpak because I was scared by the need of
>> firstly build modules and I'm really happy to see this change moving on.
>>
>> However, there's something I can't understand: AFAIK, a flatpak is
>> platform independent, so a flatpak built on F39 can be installed on any
>> Fedora version or even on other Linux distributions... right?
>> So, why having all those "Fedora Containers" releases in Bodhi which
>> follow Fedora branches? Isn't just one Fedora Containers release enough?
>> What happens if one builds the same flatpak on multiple Fedora
>> Containers releases?
>> [infrastructure/new_issue](https://pagure.io/fedora-infrastructure/new_issue)
>
> The "F38 Flatpaks" release in Bodhi represents Flatpaks built with the F38 
> package set against the F8 runtime. But, yes, as you say we handle Flatpaks 
> as a single stream. Once we release Firefox into "F39 Flatpaks", everybody on 
> all releases gets that and we never do an update in "F38 Flatpaks" again.
>
> If updates *do* get pushed on multiple releases, last pushed wins. Might be 
> useful if we found that we pushed something to early or broken - but isn't 
> normal.

I was wondering if that was due to have the ability of building the flatpak 
against a specific runtime. I mean, as I understand how a flatpak works, a 
flatpak created from a koji build for f39 will be built against a specific 
runtime (say, KDE available in f39 stable tags), but when we build the same 
koji build for f40 we will be using a different runtime which may not be 
compatible... so still having a Fedora Containers 39 release will make the 
maintainer able to continue using the f39 runtime... I know I'm quite confused, 
aren't I?

If I search for fedora-toolbox updates in Bodhi, I now see there are multiple 
updates released alongside each others at the same time.

> But what if we had a single release instead?
>
> On a technical level, we rely on separate releases because Bodhi is using 
> that to know what koji tag to pull from. So to merge them, we'd probably need 
> a single dest tag in Koji as well. But would it be more convenient and less 
> confusing for packagers and users? Would there be any performance or UI 
> problems from having a release in Bodhi that extends indefinitely?

Would be simpler to have a single Koji dest tag which doesn't change alongside 
Fedora branches, so that packagers only have to remember that one? (provided 
that we don't want the ability to build multiple updates as discussed above)

From a Bodhi POV, I don't think there would be any problem in extending a 
release indefinitely... we currently have Fedora ELN running since 2020 and 
with something like 80K updates and nothing as blown up (yet...).

> In any case, a change to how we handle Flatpak releases in Koji could be done 
> separately from this change proposal :-)
>
> - Owen___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Mattia Verga via devel]

Il 10/05/23 12:54, Aoife Moloney ha scritto:
> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
>
>
I've never tried to make a flatpak because I was scared by the need of 
firstly build modules and I'm really happy to see this change moving on.

However, there's something I can't understand: AFAIK, a flatpak is 
platform independent, so a flatpak built on F39 can be installed on any 
Fedora version or even on other Linux distributions... right?
So, why having all those "Fedora Containers" releases in Bodhi which 
follow Fedora branches? Isn't just one Fedora Containers release enough? 
What happens if one builds the same flatpak on multiple Fedora 
Containers releases?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 drop 32bit support from the scientific Python stack

[Mattia Verga via devel]

There is already an ancient similar request upstream with some hints how to 
achieve that (it was to disable s390 buikders for noarch packages, though):
https://pagure.io/koji/issue/2229

Inviato da Proton Mail mobile

 Messaggio originale 
Il 5 Mag 2023, 18:19, Kevin Fenzi ha scritto:

> On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: > On 04. 05. 23 
> 23:58, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro 
> Hrončok wrote: > > > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > > > On Thu, 
> May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > > > Hello folks, 
> > > > > ...snip... > > > > > Would that be possible? > > > > I don't think it 
> currently is... but sounds like a reasonable RFE to > > > > koji to me. > > > 
> > > > > > The way koji handles noarch packages is that it builds them on all 
> > > > > arches, checks to make sure they are all the same and just picks one 
> to > > > > be the 'output' build. > > > This is true for noarch subpackages 
> of arched packages. > > > > > > For fully noarch packages, it just builds 
> them on one architecture. > > Yep. You are correct, sorry for confusing the 
> issue there. > > > > I still think it could be something that koji would let 
> us do. > > When Koji triggers a noarch build job, it somehow knows it can 
> select *any* > builder we have. Is this a matter of our configuration or 
> upstream code? As far as I can tell, upstream. I could be missing something, 
> but I think noarch tasks just get the 'default' channel and any builder from 
> any arch thats in it. > E.g. do I need to file an issue at pagure.io/koji or 
> infra or releng? Upstream pagure.io/koji. If I am missing something and we 
> can do it in config they should be able to tell us. ;) kevin 
> ___ devel mailing list -- 
> devel@lists.fedoraproject.org To unsubscribe send an email to 
> devel-le...@lists.fedoraproject.org Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List 
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List 
> Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: A new FMN will arrive this week

[Mattia Verga via devel]

Il 24/04/23 11:47, Aurelien Bompard ha scritto:
> Hi folks!
>
> The FMN replacement team has finished writing the new version of our
> notification system, and we are ready to deploy! We plan on deploying
> the new version on https://notifications.fedoraproject.org this week,
> we'll keep the old one around but move it to
> https://apps.fedoraproject.org/notifications-old, and redirect from
> https://apps.fedoraproject.org/notifications to the new place,
> notifications.fedoraproject.org.
>
I used to set the old FMN to send me a "daily or n messages" digest...
I've just realized that there is no such functionality in the new FMN!
Is that something that can be reconsidered?

Mattia

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

[Mattia Verga via devel]

Il 25/04/23 20:40, Adam Williamson ha scritto:
> On Tue, 2023-04-25 at 08:06 +0000, Mattia Verga via devel wrote:
>> I'm going to orphan python-simplemediawiki. Upstream is long time dead
>> and the github repository was archived in 2018.
>>
>> It was used by Bodhi backend to fetch TestCases information from Fedora
>> Wiki, but Bodhi 7.1 switched to python-pymediawiki. I cannot find any
>> other use in fedora infrastructure.
> FWIW, if you want to de-duplicate effort a bit and are only maintaining
> python-pymediawiki for this purpose, I maintain python-mwclient:
> https://src.fedoraproject.org/rpms/python-mwclient
> because python-wikitcms depends on it. We use python-wikitcms for
> creating and submitting results to the validation event pages on the
> wiki, so I'm tied into maintaining it as long as we're using the wiki
> for results. So possibly we could have Bodhi move to *that*, and drop
> python-pymediawiki.
>
> I'm also now a maintainer of mwclient upstream, since the original
> maintainer went inactive and I got roped in to help out...
>
> Of course, if you're happy maintaining/using pymediawiki, there's no
> need to switch, just thought I'd mention the possibility.

Thanks, I was not aware of mwclient. Indeed, I've packaged pymediawiki
just for Bodhi purposes, but as long as upstream is well maintained and
developed and no packaging problem arises, I'll continue with pymediawiki.

Mattia

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

Orphaning python-simplemediawiki

[Mattia Verga via devel]

I'm going to orphan python-simplemediawiki. Upstream is long time dead
and the github repository was archived in 2018.

It was used by Bodhi backend to fetch TestCases information from Fedora
Wiki, but Bodhi 7.1 switched to python-pymediawiki. I cannot find any
other use in fedora infrastructure.

infra-sig is listed as co-maintainer, let me know if you want me to
remove the group before orphaning the package.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: A new FMN will arrive this week

[Mattia Verga via devel]

Il 24/04/23 11:47, Aurelien Bompard ha scritto:
> Hi folks!
>
> The FMN replacement team has finished writing the new version of our
> notification system, and we are ready to deploy! We plan on deploying
> the new version on https://notifications.fedoraproject.org this week,
> we'll keep the old one around but move it to
> https://apps.fedoraproject.org/notifications-old, and redirect from
> https://apps.fedoraproject.org/notifications to the new place,
> notifications.fedoraproject.org.
>
> You will thus still be able to access the current FMN, and it will
> keep running until F39. Due to the difference in features, we can't
> import existing rules into the new system, so we encourage you to
> create new rules that suit you as soon as the new system is up and
> running.
>
> The change of URLs will happen with the planned outage set for
> 2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
>  for details.
>
> If you have issues with the new FMN, please open infra tickets at:
> https://pagure.io/fedora-infrastructure/new_issue
>
> We hope you will enjoy the simpler UI and faster processing speed that
> the new FMN brings.
>
> Cheers!
> Aurélien

Thank you, the new FMN is much cleaner and easier to use than the
previous version.

One thing it's not clear to me: are the rules processed sequentially
(first to match stop processing) or in parallel? I'd like to create two
rules, one for my packages and one for packages of a sig. Some of my
packages are also in that sig packages list. Will I receive double
notifications?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: It’s time to transform the Fedora devel list into something new

[Mattia Verga via devel]

Il 20/04/23 23:20, Matthew Miller ha scritto:
> It’s time to transform the Fedora devel list into something new
> ===
>
> ...
> Matthew Miller
> 
> Fedora Project Leader

I've tried to follow up all the replies this post has caused, but it
takes time to read in a foreign language and there are simply too many
posts to read them all, so I'll just go and give you some thoughts that
may have already been written by someone else.

- I'm not enthusiast of being forced to open a web browser to be noticed
about new posts. I'm aware there's a "mailing list" mode, but it's not
clear if it's perfectly usable or would be sub-optimal. I think it needs
to be tested.

- I'm also skeptical about having all mailing lists under one Discourse
category (I suppose it will be "Project Discussions") and use tags to
filter them. I think an high volume list such as devel should gone under
it's own category. Maybe for other low volumes lists which are specific
to groups or aspects can use the "tags" categorization.

- Another problem is that there are already too many tags available and
the tag description is not visible in the post submit form. I think a
new user would be confused what tag to use. I'm confused too, but that's
probably just me...

- The Discourse Android app is no use. So, again, browser on mobile or
mailing list mode.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: It’s time to transform the Fedora devel list into something new

[Mattia Verga via devel]

Il 23/04/23 17:01, Björn Persson ha scritto:
>
> You let the quarrel go this far before you even bothered to mention
> that? You're clearly not serious about selling the email features of
> Discourse.
>
> You're trying to convince email users that your preferred communication
> program is better than their preferred communication program. Users of
> various email programs are saying no, the program I have chosen works
> better for my needs. Do you also waste time trying to convince Emacs
> users to switch to Vi?
>
> Instead of trying to make everybody use the same Javascript program,
> what you should do is show how your preferred program implements the
> relevant standards to be interoperable with my preferred program, so
> that we can communicate while each using our respective programs. If
> it's not interoperable, then that's where the problem is.
>
I'm not enthusiast about this proposed change too, but let's not go
personal.

As I understand, it's not about Matthew personal preferences, it's about
maintaining mailing list running needs manpower which Fedora is running
out of. Switching to Discourse can probably relief some of the burden
from fedora-infra guys.

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Broken gcc 13.0.1-0.15.fc39 (missing )

[Mattia Verga via devel]

Il 23/04/23 11:17, Tomasz Kłoczko ha scritto:

> Hi,
>
> Looks like with latest gcc 31.0.1-0.15.fc39 many packages builds are failing 
> with:
>
> /usr/lib/gcc/x86_64-redhat-linux/13/include/immintrin.h:135:10: fatal error: 
> amxcomplexintrin.h: No such file or directory
> 135 | #include 
> | ^~~~
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

Today I was able to builda package that was previously failed, 
gcc-13.0.1-0.16.fc39 has fixed the problem in Rawhide.

Mattia___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SPDX Statistics - ZX Spectrum edition

[Mattia Verga via devel]

Il 23/04/23 11:09, Miroslav Suchý ha scritto:
>
> The list of packages needed to be converted is again here:
>
> https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt
>
> List by package maintainers is here
>
> https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt
>
>
I have updated some of my packages, but they're still listed there. I've
used "Update license tag to SPDX" in the changelog.

kpmcore and kde-partitionmanager were rebuilt after the update.

indistarter, libpasastro and libpasraw were not rebuilt after the change
(only updated in src).

python-pymediawiki is MIT (no change).

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RFC: No koji builds during mass branching and updates-testing enablement

[Mattia Verga via devel]

Il 22/04/23 23:46, Kevin Fenzi ha scritto:
> On Fri, Apr 21, 2023 at 09:03:11PM +0200, Fabio Valentini wrote:
>> On Thu, Mar 9, 2023 at 8:56 PM Kevin Fenzi  wrote:
>>> * Cancel all builds that are in progress. Maintainers can resubmit after
>>> the outage with the appropriate branches.
>>> * unpush all updates stuck in gating/pending? Is this too much?
>>> * do the branching steps, get everything in place, then open things on
>>> the hub.
>>>
>>> This is a lot more disruptive, but it's only for part of a day and I
>>> agree it's nicer to not have things to clean up.
>> Sorry for the long RTT. My email inbox is only now no longer looking
>> like a dumpster fire. :)
>>
>> It sounds like koji actually supports giving an outage message, so
>> that would be great.
>> Concerning the three steps listed above: I think they would make sense.
>> Maybe it could look like this:
>>
>> 1. lock down the koji hub
>> 2. cancel all builds that are still running (I think this could
>> exclude builds that are targeting stable branches?)
>> 3. unpush all Rawhide updates that are stuck (maybe adding a comment
>> to the bodhi update why it happened)
>> 4. do the mass branching steps (i.e. Rawhide == Fedora N+2, Branched
>> == Fedora N+1)
>> 5. unlock koji hub
>>
>> Parts of steps 2,3,4 could even happen with more granularity (I think
>> mass branching steps happen alphabetically for all packages? that
>> would give running builds more time to finish.).
> This seems doable. We should make sure it is as best we can, and then
> probibly announce it before the next mass branching so everyone knows to
> expect it. :)
>
> Hopefully this will prevent problems the next time...
>
> Adding Tomas here on cc
>
> kevin

Isn't simpler to schedule:

1. lock down Koji in  (stop accepting new builds,
possibly only for Rawhide)
2. let Koji finish running builds (assuming there are none which
requires more than 24h)
3. at  check any stuck Rawhide update in Bodhi
4. branch
5. unlock Koji

I think a 24h Koji outage is much clearer to users other than cancelling
their builds and unpushing their updates. Unless releng wants to take
note of those builds and updates and resubmit them after the mass
branching...

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: It’s time to transform the Fedora devel list into something new

[Mattia Verga via devel]

Il 21/04/23 17:37, Simo Sorce ha scritto:
> On Fri, 2023-04-21 at 10:44 -0400, Matthew Miller wrote:
>> On Thu, Apr 20, 2023 at 08:24:48PM -0500, Chris Adams wrote:
>>> Once upon a time, Matthew Miller  said:
 I am proposing that over the course of 2023, starting with the Changes
 process, we move Fedora development conversations from this mailing list to
 the Discourse-based Fedora Discussion.
>>> I feel this is a case of trading one group of people (email list users)
>>> for a different group of people (web forum users).
>> I don't think this is _really_ a "there are two kinds of people in the
>> world..." situation. Of course there are some people who have preferences
>> (strong or weak) for one or the other, and completely legitimate pros and
>> cons to each. But I don't want to "trade" anyone. I'd like to bring everyone
>> along.
>>
>>
>>> I have seen this
>>> done multiple times over the years, tried to follow a few times, and
>>> always dropped off fairly rapidly.  I'm solidly in the "email list
>>> users" group.
>> Is there anything which could be different this time which would make it
>> better for you?
> So I am trying to see how it works to follow those discussions via
> email (sorry this is the only way, following via web simply doesn't
> work for me).
>
> So I registered the account, added the email I want to get
> notifications at, and selected a few topics.
>
> First impressions.
>
> ...

Discourse docs say that it can be fully used like a mailing list, but it
mention a "mailing list" mode that I can't find in Fedora Discourse
profile preferences... is that feature available?

Mattia

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

[Mattia Verga via devel]

Il 17/04/23 17:39, Jakub Kadlcik ha scritto:
> Hello,
> per the Non-responsive maintainer policy
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers
>
> I am sending this email. We (copr-sig) would like to (co)maintain the
> python-flask-whooshee package but @rkuska can't give us permission
> because he lost access to his FAS account.
>
> We talked about this off-list, so this is basically just FYI for others.
>
> RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2042681
>
> Jakub

rksuska was removed from packagers some months ago:

https://pagure.io/find-inactive-packagers/issue/253

python-flask-whooshee was orphaned and is now taken by msuchy. I've
resetted the BZ ticket assignee to the default assignee (msuchy).

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Test upgrades from F37 to F38 - it will take you just a minute

[Mattia Verga via devel]

I've just tried a 'dnf system-upgrade' and got:

Errore: Errore test di transazione:
   il file /usr/lib64/libheif/libheif-libde265.so dell'installazione di
libheif-freeworld-1.15.1-4.fc38.x86_64 entra in conflitto con il file
del pacchetto libheif-hevc-1.15.1-2.fc37.1.x86_64
   il file /usr/lib64/libheif/libheif-x265.so dell'installazione di
libheif-freeworld-1.15.1-4.fc38.x86_64 entra in conflitto con il file
del pacchetto libheif-hevc-1.15.1-2.fc37.1.x86_64

I had to manually 'dnf remove libheif-hevc' to make system-upgrade works.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Change my new package name in src.fedoraporject.org ?

[Mattia Verga via devel]

Il 13/04/23 10:27, Miro Hrončok ha scritto:
>
> In http://bugzilla.redhat.com/2130607 the reviewer should have noted this and
> not approve the package.
>
Why? The "full lowercase naming" is no more a MUST:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_general_naming

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: purpose of dummy-test-package-* updates?

[Mattia Verga via devel]

Il 10/04/23 17:50, Kevin Fenzi ha scritto:
> On Mon, Apr 10, 2023 at 03:18:22PM +0000, Mattia Verga via devel wrote:
>> Il 10/04/23 17:01, Kevin Fenzi ha scritto:
>>> I've not seen any errors from it in a long while... but I'm not sure if
>>> thats because everything has been working or because it isn't erroring
>>> properly.
>>>
>>> Anyhow, I think we should/can adjust it to not make big changelogs...
>>>
>> Well, now the problem is no more, since Bodhi will handle such big
>> changelogs.
>>
>> Anyway, I'm not sure if it is working as expected, as updates are always
>> gated due to a failing test, so the next one will obsolete the older
>> (and that's why the changelog keeps growing).
> yeah, it deliberatly has a failed test so it can waive it and test that
> waiving works. Sadly, on looking, thats the problem. It tries to waive
> it but fails:
>
> 13:14:21 - Waiving test results for bodhi update
> Command `bodhi updates waive FEDORA-2023-47cf5a0c4b 'This is fine, we are 
> testing the workflow
> ' --debug --user packagerbot --password ` return code: `1`
> stdout:
> ---
> b'Waiving unsatisfied requirements: \n'
> stderr:
> ---
> b'Invalid request: Check your FAS username & password\n'
>
> So, auth isn't working right there.
>
I think authenticating with '--user --password' is not working anymore
since the client was migrated to OIDC [1] (bodhi 6)

Mattia

[1]
https://github.com/fedora-infra/bodhi/commit/32fa9f4fcd850558b8f9f024989dd151bb068452

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: purpose of dummy-test-package-* updates?

[Mattia Verga via devel]

Il 10/04/23 17:01, Kevin Fenzi ha scritto:
>
> I've not seen any errors from it in a long while... but I'm not sure if
> thats because everything has been working or because it isn't erroring
> properly.
>
> Anyhow, I think we should/can adjust it to not make big changelogs...
>
Well, now the problem is no more, since Bodhi will handle such big
changelogs.

Anyway, I'm not sure if it is working as expected, as updates are always
gated due to a failing test, so the next one will obsolete the older
(and that's why the changelog keeps growing).

Mattia

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

purpose of dummy-test-package-* updates?

[Mattia Verga via devel]

Hello,

I've recently introduced the cap of 10k characters in Bodhi updates
notes and made automatic updates avoid copying the RPM changelog in
notes if it's too big. This was causing some updates, especially those
created for `dummy-test-package-gloster` package [1], to clog Bodhi's
query replies.

But what's the purpose of these "dummy" updates on production? Does
anyone knows it? In the past there were other "dummy" packages
(dummy-test-package-rubino and dummy-test-package-crested) which are no
more created, while -gloster is still pushed by an automated bot. I
wonder if someone forgot to disable that bot...

Thanks
Mattia

[1]
https://bodhi.fedoraproject.org/updates/?packages=dummy-test-package-gloster

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Mattia Verga via devel]

Il 02/04/23 18:42, Fabio Valentini ha scritto:
> On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel
>  wrote:
>> Il 31/03/23 17:27, Florian Festi ha scritto:
>>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
>>>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>>>>> == Detailed Description ==
>>>>> RPM 4.19 contains various improvements over previous versions. Many of
>>>>> them are internal in nature such as moving from automake to cmake,
>>>>> improvements to the test suite, stripping copies of system functions,
>>>>> splitting translations into a separate project and more. There are
>>>>> still several user facing changes:
>>>>>
>>>>> * New rpmsort(8) utility for sorting RPM versions
>>>> Handy!
>>>>
>>>>> * x86-64 architecture levels (v2-v4) as architectures
>>>> Could you explain more what this means, exactly?
>>> No! But here is the commit:
>>>
>>>
>>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>>
>>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>>> about some x86_64 processors having additional capabilities.
>>>
>> Is there anyone who could provide some benchmarks to see if there are
>> significant performance improvements about using v2/v3/v3 versus plain
>> x86_64? If so, do you think we could drop building i686 by default (to
>> save some resources) and provide v2 (or v3, or v4) alongside x86_64?
> I don't think we can drop i686 as long as we need to support at least
> a subset of i686 for wine / steam / $your favourite 32-bit only
> third-party application.

Sure, I meant to change the current default of opting out i686 build
(ExcludeArch) to explicitly opting in only for required packages. I
think we're currently wasting resources by making needlessy builds on i686.

Those resources can possibly be spent on building v2/v3/v4 to enable
glibc-hwcaps as Dan pointed out OpenSuse is doing, but this is a
following step.

Mattia

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