Self Introduction: Andreas Maier

[Andreas R Maier]

Hello,
I am a maintainer of some Python packages on Pypi, including the 'pywbem' 
package. The pywbem package is in Fedora (as 'pywbem') and in some other Linux 
distributions. For version 1.0.0 of pywbem, we have created two new Python 
packages 'nocaselist' and 'nocasedict' on Pypi, providing a case-insensitive 
list and dictionary, respectively. The two new packages stand on their own and 
are independent of the pywbem package.
Obviously, the two new packages are not in Fedora, and that currently prevents 
the pywbem package in Fedora to be upgraded to the latest version. After 
discussing this matter with the Fedora package maintainer of pywbem, my pywbem 
co-maintainer and I are willing to become long-term package maintainers for the 
two new packages in Fedora.
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Copr package build fails on python-nocaselist package

[Andreas R Maier]

Hi,
I am new to building packages, and I'm trying to build a new package 
'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking the 
SRPM file because it cannot cd into the directory it assumes got unpacked:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6rjfBt
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf nocaselist-1.0.2
+ /usr/bin/gzip -dc /builddir/build/SOURCES/nocaselist-1.0.2.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd nocaselist-1.0.2
/var/tmp/rpm-tmp.6rjfBt: line 39: cd: nocaselist-1.0.2: No such file or 
directory
I have configured copr to point to the Git repo and spec file.

The same spec file builds fine on Koji.

Spec file: 
https://github.com/pywbem/nocaselist/blob/andy/fedora-packaging/packaging/fedora/python-nocaselist.spec
 

Failing Copr build: 
https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build/1672638/
 

Successful Koji build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=51713400 


What am I doing wrong here?

Thanks for any help
Andy


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

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

[Bohdan Khomutskyi]

Hello Zbyszek,

> You haven't really answered the "why" part: why is it so important to
save 50MB? And why is the effect on QA less important?

From my perspective, the storage on the installation medium should be 
efficiently used. Even though the optimization is just 50MiB, it is an 
optimization.


And this optimization is transparent in terms of content.

> And why is the effect on QA less important?

The QA team is only one group of users. We should rather orient at end 
users, and the way those users install Fedora.



On 15/09/2020 12:03, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Sep 15, 2020 at 11:18:04AM +0200, Bohdan Khomutskyi wrote:

Hello everyone,

Thanks for sharing your ideas and comments about this change.

Thanks to Mohan Boddu, I got RawHide DVD and netinstall images of
RawHide with the optimization features enabled. Those test composes
are available at the following locations:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/
(Plain SquashFS)

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200908.n.1/compose/Server/x86_64/iso/
(Plain SquashFS and different xz compression options)

To select images from the test composes, I applied a patch from
https://github.com/rhinstaller/anaconda/pull/2829, so you can
download and run those images yourself to test the change:

https://drive.google.com/drive/folders/1tGsoqFMg2A6dQZHfuQNb9uDqYu9XEiPI

The result of benchmark will supplement already available data I
previously posted for Fedora Live images at
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS

As a reminder, there are 2 levels for this optimization:

1. Making the SquashFS filesystem on the DVD plain (i.e. without
embedded EXT4 inside it) -- has the suffix plain-xz-128k.iso

This sounds excellent. We should get both better time and space efficiency.


2. In addition to #1, using a different compression parameters for
the SquashFS filesystem on the installation medium -- has the suffix
plain-xz-1M.iso

And this ones trades times for space. Considering that the space
difference is only ~50 MB, I don't think it's worth it, for all the
reasons outlined before.

You haven't really answered the "why" part: why is it so important to
save 50MB? And why is the effect on QA less important?

Zbyszek



I propose to apply both of optimizations, using the highest possible
compression ratio supported by SquashFS. The highest compression
ratio in SquashFS corresponds to xz level 1 (out of 9 available
presets).

Making the first change will reduce both x86-64 Boot and the x86-64
DVD ISO by approximately 24 MiB. With both changes combined, the
reduction of size will be 70 MiB.

Because the SquashFS filesystem on the Live installation medium is
of bigger size, storage savings on the Live images are even higher
(I documented it in
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS)

On 05/09/2020 12:43, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:

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

...

Based on the results above, I'd suggest selecting the following
''optimal configuration'': XZ algorithm, with block size of 1MiB and
without BCJ filter (plain xz -b 1M, without -Xbcj x86).
On the right, you can see the impact of the compression algorithms on
installation time.

As can be seen from the picture on the right hand side, selecting
'plain xz -b 1M configuration' has minimal impact on the installation
time and CPU usage during the installation. The compression will
result in +6.51% or, in real terms, +24.94s additional installation
time, compared to the savings of 142 MiB on the installation media,
== Benefit to Fedora ==
* Reduction of the installation media size and the cost of storing and
distributing Fedora.
* Reduction of the CPU usage at build time. Depending on which
compression parameters chosen.

Hi Bohdan,

I think there's a misalignment of priorities.

My evaluation is the following: users won't care. The image size difference
is not big enough for people to notice. OTOH, slower installation will
impact QA and VM installations. We're doing more and more automated
installations and tests, and this change impacts those tests negatively.


This increase in installation time will be compensated by the change
in the installer:https://github.com/rhinstaller/anaconda/pull/2292

This PR is very interesting. But it seems that the more we optimize
things, the more slow decompression will be noticable. I.e. in some
way, right now, the slow decompression is obscured by the slow IO
speed, multiple levels of block device, or slow processing of the
uncompressed data. Any time the input or output speed is improved,
slow compression will be more of a bottleneck. So the approach of
increasing XZ compression levels has bad perspectives.


--
Bohdan Khomutskyi
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To

Re: Shouldn't we have process for removing old packages?

[Petr Pisar]

On Thu, Sep 17, 2020 at 09:09:51PM +0200, Vít Ondruch wrote:
> Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a):
> > Well, many maintainers don't touch packages that keep working and don't
> > need updates or bugfixes.
> 
> That is perfectly fine and I expect that in such cases, the maintainer
> would step up and responded to BZ, explained situation and intentions,
> everything would be documented and we could move on. But maintainers
> also does not touch packages, because the keep building and that is
> different situation.
>
I think that nagging maintainers with "Do you want to keep your package in
Fedora" question is too burdensome for the maintainers and a disservice for
the users.

> > So, if we know the package doesn't work, we
> > should file a bug on it. If not, I am not sure if we should try and
> > remove such packages. 
> 
> Just out of curiosity, I filed this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1880144
> 
> I used to see a lot of similar packages in Ruby land. Nowadays, they are
> finally gone, because somebody used the non-responsive maintainer policy
> in the end. But I don't want to use non-responsive maintainer policy,
> because I think some package does not serve it purpose anymore.
> 
How exactly does a presence of that package offend you? That relengs have to
rebuild it twice a year? That you have to download the few kilobytes in
repodata? That when you change Ruby packaging standards, you have to patch the
spec file?

I think that a package should be removed for a real issue that it causes. Not
because of its age.

> Actually, maintaining 200 packages myself, it might happen that some of
> them are in zombie state. I would not mind if they were called out via
> this process.
> 
Then start with yourself. Go and file bugs for your 200 packages. Then review
whether they are used by Fedora users. Be ware that Fedora packager is not
a Fedora user. And then close the bugs or retire the packages. And then come
and tell us how much fruitful it was and how much productive you were.

If you feel exhausted by maintaingin the 200 packages, then orphan them.
Fedora already has a process for dealing with unmaintained packages.
A spoiler: Eventually they will be removed from the distribution.

-- Petr


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

Re: Shouldn't we have process for removing zombie packages?

[Vít Ondruch]

Dne 18. 09. 20 v 10:24 Petr Pisar napsal(a):
> On Thu, Sep 17, 2020 at 09:09:51PM +0200, Vít Ondruch wrote:
>> Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a):
>>> Well, many maintainers don't touch packages that keep working and don't
>>> need updates or bugfixes.
>> That is perfectly fine and I expect that in such cases, the maintainer
>> would step up and responded to BZ, explained situation and intentions,
>> everything would be documented and we could move on. But maintainers
>> also does not touch packages, because the keep building and that is
>> different situation.
>>
> I think that nagging maintainers with "Do you want to keep your package in
> Fedora" question is too burdensome for the maintainers and a disservice for
> the users.


This is not about nagging maintainer for the purpose of nagging them.


>
>>> So, if we know the package doesn't work, we
>>> should file a bug on it. If not, I am not sure if we should try and
>>> remove such packages. 
>> Just out of curiosity, I filed this bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1880144
>>
>> I used to see a lot of similar packages in Ruby land. Nowadays, they are
>> finally gone, because somebody used the non-responsive maintainer policy
>> in the end. But I don't want to use non-responsive maintainer policy,
>> because I think some package does not serve it purpose anymore.
>>
> How exactly does a presence of that package offend you?


Maybe because I am maintainer of ruby and rubygem-sinatra and I do care
if packages which depends on them keep working? And just FTR, I came to
rubygem-sinatra-rabbit checking that rubygem-haml is broken. Please note
that I am not maintainer of that package, but I do care about Ruby in
Fedora in general.


> That relengs have to
> rebuild it twice a year? That you have to download the few kilobytes in
> repodata? That when you change Ruby packaging standards, you have to patch the
> spec file?
>
> I think that a package should be removed for a real issue that it causes. Not
> because of its age.


I agree, and "old" was not the best term. "zombie" is much better
probably. I used that term right in the first paragraph of the original
email. It already got lost here. I update the subject to be more clear.


>
>> Actually, maintaining 200 packages myself, it might happen that some of
>> them are in zombie state. I would not mind if they were called out via
>> this process.
>>
> Then start with yourself. Go and file bugs for your 200 packages. Then review
> whether they are used by Fedora users. Be ware that Fedora packager is not
> a Fedora user. And then close the bugs or retire the packages. And then come
> and tell us how much fruitful it was and how much productive you were.
>
> If you feel exhausted by maintaingin the 200 packages, then orphan them.
> Fedora already has a process for dealing with unmaintained packages.
> A spoiler: Eventually they will be removed from the distribution.


You get it wrong. I feel exhausted seeing again and again packages which
are very likely broken, serving no purpose. I feel exhausted seeing that
these packages pull in dependency chains which are not possible to be
updated or removed due to them.


Vít




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

Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

[Petr Pisar]

On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> So: RH Java packagers, what if you build these packages as non-modular
> (maybe using some scripting to make it happen at the same time as modular
> builds?) and add a readme explaining their maintenance state?

Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
directory? That won't work, because nobody looks there.

Either the package should be moved into a separate repository that an end user
have to explicitly enable and later can inspect an origin of the package with
"dnf info $PACKAGE", or the package should not be distributed at all. Pungi
tool that produces the distribution composes supports it. It's only a matter
of configuration.

(Or we can invent a new RPM tag for a support level of the package.)

-- Petr


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

Fedora-Cloud-32-20200918.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Copr package build fails on python-nocaselist package

[Robert-André Mauchin]

On Friday, 18 September 2020 09:19:48 CEST Andreas R Maier wrote:
> Hi,
> I am new to building packages, and I'm trying to build a new package
> 'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking
> the SRPM file because it cannot cd into the directory it assumes got
> unpacked: Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6rjfBt
> + umask 022
> + cd /builddir/build/BUILD
> + cd /builddir/build/BUILD
> + rm -rf nocaselist-1.0.2
> + /usr/bin/gzip -dc /builddir/build/SOURCES/nocaselist-1.0.2.tar.gz
> + /usr/bin/tar -xof -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd nocaselist-1.0.2
> /var/tmp/rpm-tmp.6rjfBt: line 39: cd: nocaselist-1.0.2: No such file or
> directory I have configured copr to point to the Git repo and spec file.
> 
> The same spec file builds fine on Koji.
> 
> Spec file:
> https://github.com/pywbem/nocaselist/blob/andy/fedora-packaging/packaging/f
> edora/python-nocaselist.spec
>  fedora/python-nocaselist.spec> Failing Copr build:
> https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build/1
> 672638/
>  1672638/> Successful Koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=51713400
> 
> 
> What am I doing wrong here?
> 
> Thanks for any help
> Andy

The archives in your SRPM are different:
 - on COPR the root directory of your archive is python-%{srcname}-%{version}
 - on Koji the root directory of your archive is %{srcname}-%{version}

To download the true original archive from Pypi, use "spectool -g *.spec" in 
the directory that contains your SPEC file.
Then open the archive and see that the root of the archive is named %
{srcname}-%{version} , like on Koji.
To regenerate the SRPM, use: fedpkg --release f34 srpm in the directory that 
contains your SPEC file.

Mini review:

 - %{?python_enable_dependency_generator} not needed anymore, it's the 
default.

 - %{python3} setup.py build → %py3_build

 - Not needed: rm -rf %{buildroot}

 - env PYTHONPATH=%{buildroot}/%{python3_sitelib} \
%{python3} setup.py install -O1 --skip-build --root %{buildroot}

   → %py3_install

 - The Python provide macro is not mandatory anymore on Rawhide and F33, but 
below F33, you should add: %py_provides python3-%{srcname} to the python3-%
{srcname} subpackage.

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

Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

[Dominik 'Rathann' Mierzejewski]

On Friday, 18 September 2020 at 11:22, Petr Pisar wrote:
> On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> > So: RH Java packagers, what if you build these packages as non-modular
> > (maybe using some scripting to make it happen at the same time as modular
> > builds?) and add a readme explaining their maintenance state?
> 
> Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
> directory? That won't work, because nobody looks there.

I do. :)

What about https://src.fedoraproject.org/rpms//blob/master/f/README.md ?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Copr package build fails on python-nocaselist package

[Andreas R Maier]

Thanks for the quick help and for the mini-review.

I have updated the spec file as recommended, except for the %py_provides macro 
because COPR
did not like that when running the rpkg command:

Running: rpkg srpm --outdir /tmp/copr-rpmbuild-vtejek5l --spec 
/tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist/packaging/fedora/python-nocaselist.spec

cmd: ['rpkg', 'srpm', '--outdir', '/tmp/copr-rpmbuild-vtejek5l', '--spec', 
'/tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist/packaging/fedora/python-nocaselist.spec']
cwd: /tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist
rc: 0
stdout: Wrote: /tmp/copr-rpmbuild-vtejek5l/python-nocaselist.spec
stderr: error: line 34: Unknown tag: %py_provides python3-nocaselist
can't parse specfile

With the changed spec file (without %py_provides), the situation is still that 
Koji succeeds and
COPR fails with the same error as before:
Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=51724144 

COPR: 
https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build/1673307/
 


I understand what you said about the difference in the archives in the SRPM 
files, but I'm afraid
I don't quite understand how I can influence how COPR obtains the archive. In 
fact, even after
looking at the log files I don't understand where it gets the archive from.

In COPR, I am defining the package to be built from SCM, with rpkg for building 
the SRPM:
https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/package/python-nocaselist/
 

Is that the way to do it?

Also, as far as I'm concerned we do not necessarily need to get the COPR build 
to succeed,
as long as I can get the package review started by pointing to a Koji build. 
Please let me know.

Andy

> Begin forwarded message:
> 
> From: Robert-André Mauchin 
> Subject: Re: Copr package build fails on python-nocaselist package
> Date: 18. September 2020 at 11:34:31 CEST
> To: Development discussions related to Fedora 
> Reply-To: Development discussions related to Fedora 
> 
> 
> On Friday, 18 September 2020 09:19:48 CEST Andreas R Maier wrote:
>> Hi,
>> I am new to building packages, and I'm trying to build a new package
>> 'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking
>> the SRPM file because it cannot cd into the directory it assumes got
>> unpacked: Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6rjfBt
>> + umask 022
>> + cd /builddir/build/BUILD
>> + cd /builddir/build/BUILD
>> + rm -rf nocaselist-1.0.2
>> + /usr/bin/gzip -dc /builddir/build/SOURCES/nocaselist-1.0.2.tar.gz
>> + /usr/bin/tar -xof -
>> + STATUS=0
>> + '[' 0 -ne 0 ']'
>> + cd nocaselist-1.0.2
>> /var/tmp/rpm-tmp.6rjfBt: line 39: cd: nocaselist-1.0.2: No such file or
>> directory I have configured copr to point to the Git repo and spec file.
>> 
>> The same spec file builds fine on Koji.
>> 
>> Spec file:
>> https://github.com/pywbem/nocaselist/blob/andy/fedora-packaging/packaging/f
>> edora/python-nocaselist.spec
>> > 
>> fedora/python-nocaselist.spec> Failing Copr build:
>> https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build/1 
>> 
>> 672638/
>> > 
>> 1672638/> Successful Koji build:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=51713400 
>> 
>> > >
>> 
>> What am I doing wrong here?
>> 
>> Thanks for any help
>> Andy
> 
> The archives in your SRPM are different:
> - on COPR the root directory of your archive is python-%{srcname}-%{version}
> - on Koji the root directory of your archive is %{srcname}-%{version}
> 
> To download the true original archive from Pypi, use "spectool -g *.spec" in 
> the directory that contains your SPEC file.
> Then open the archive and see that the root of the archive is named %
> {srcname}-%{version} , like on Koji.
> To regenerate the SRPM, use: fedpkg --release f34 srpm in the directory that 
> contains your SPEC file.
> 
> Mini review:
> 
> - %{?python_enable_dependency_generator} not needed anymore, it's the 
> default.
> 
> - %{python3} setup.py build → %py3_build
> 
> - Not needed: rm -rf %{buildroot}
> 
> - env PYTHONPATH=%{buildroot}/%{python3_sitelib} \
>%{python3} setup.py install -O1 --skip-build --root %{buildroot}
> 
>   → %

Re: Shouldn't we have process for removing zombie packages?

[Petr Pisar]

On Fri, Sep 18, 2020 at 10:42:00AM +0200, Vít Ondruch wrote:
> This is not about nagging maintainer for the purpose of nagging them.
>
Filing the requests en mass is exactly nagging for nagging. But

> I feel exhausted seeing again and again packages which are very likely
> broken,

if the package is broken, then file a bug. That's a completely different
case.

> serving no purpose.

That's a strong assertion. I hope that you know that a non-existance is not
getting proved by claiming "I think there is none". But again, if you don't
like the package, file a bug with the explanation why you think it should be
removed.

> I feel exhausted seeing that these packages pull in dependency chains which
> are not possible to be updated or removed due to them.
>
If you need to update the dendency, then update the dependency and report
a bug against the then broken package. See openssl package for an example.

All I want to say that these issues should be handled case by case. There
should be a reason for each of them and the bug report should be tailored to
that case. But pushing the work of a responsible bug report from the reporter
to the assignee is wrong.

-- Petr


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

[Bug 1880129] perl-Log-Log4perl-1.53 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Log4perl-1.53-1.fc
   ||34
 Resolution|--- |RAWHIDE
Last Closed||2020-09-18 10:36:35




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Packaging (node?)JS components that bundle lots of (node?)JS deps

[Ankur Sinha]

On Thu, Sep 17, 2020 13:31:27 +0100, Ankur Sinha wrote:
> 

> I can refer to
> the package-lock.json file to get version info of the bundled libs I
> find, I guess?
> 

Quick update: this is what I've gone for at the moment. I've parsed the
package-lock.json file to get a list of the bundled modules with their
versions, and I've checked the license for each one individually and
included all that info in the spec.

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


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

Fedora rawhide compose report: 20200918.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200917.n.0
NEW: Fedora-Rawhide-20200918.n.0

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

Size of added packages:  20.24 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.10 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200917.n.0.iso
Image: Cloud_Base vmdk x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20200917.n.0.x86_64.vmdk
Image: Cloud_Base vmdk aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20200917.n.0.aarch64.vmdk

= ADDED PACKAGES =
Package: 3mux-1.0.1-1.fc34
Summary: Terminal multiplexer inspired by i3
RPMs:3mux golang-github-aaronjanse-3mux-devel
Size:8.74 MiB

Package: fuzza-0.6.0-3.fc34
Summary: TCP fuzzing tool to test for remote buffer overflows
RPMs:fuzza python3-fuzza
Size:37.40 KiB

Package: gammastep-2.0.2-1.fc34
Summary: Adjusts the color temperature of your screen according to time of day
RPMs:gammastep gammastep-indicator
Size:881.33 KiB

Package: golang-github-aaronjanse-pty-1.1.14-1.fc34
Summary: Go package for using unix pseudo-terminals
RPMs:golang-github-aaronjanse-pty-devel
Size:20.42 KiB

Package: golang-github-chromedp-0.5.3-2.fc34
Summary: Drive browsers supporting the Chrome DevTools Protocol
RPMs:golang-github-chromedp golang-github-chromedp-devel
Size:100.87 KiB

Package: golang-github-mozillazg-pinyin-0.18.0-2.fc34
Summary: Tools and Golang library to convert Chinese characters to Pinyin
RPMs:golang-github-mozillazg-pinyin golang-github-mozillazg-pinyin-devel
Size:5.96 MiB

Package: golang-github-npat-efault-poller-2.0.0-1.fc34
Summary: An epoll(7)-based file-descriptor multiplexer
RPMs:golang-github-npat-efault-poller-devel
Size:24.16 KiB

Package: nwg-launchers-0.3.4-1.fc34
Summary: GTK-based launchers for sway and other window managers
RPMs:nwg-launchers
Size:1.05 MiB

Package: python-accuweather-0.0.10-1.fc34
Summary: Python wrapper for getting data from AccuWeather servers
RPMs:python3-accuweather
Size:20.71 KiB

Package: python-ephem-3.7.7.1-4.fc34
Summary: Compute positions of the planets and stars
RPMs:python-ephem-doc python3-ephem
Size:3.29 MiB

Package: python-spnego-0.1.1-2.fc34
Summary: Windows Negotiate Authentication Client and Server
RPMs:python3-spnego
Size:148.76 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Lmod-8.4.5-1.fc34
Old package:  Lmod-8.4.4-1.fc34
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.06 MiB
Size change:  1.00 KiB
Changelog:
  * Thu Sep 17 2020 Orion Poplawski  - 8.4.5-1
  - Update to 8.4.5


Package:  OpenIPMI-2.0.29-1.fc34
Old package:  OpenIPMI-2.0.28-7.fc34
Summary:  IPMI (Intelligent Platform Management Interface) library and tools
RPMs: OpenIPMI OpenIPMI-devel OpenIPMI-lanserv OpenIPMI-libs 
OpenIPMI-perl python3-openipmi
Size: 7.08 MiB
Size change:  6.41 KiB
Changelog:
  * Thu Sep 17 2020 Josef dk??  - 2.0.29-1
  - New upstream release 2.0.29 (#1846675)


Package:  ProDy-1.10.10-10.fc34
Old package:  ProDy-1.10.10-10.fc33
Summary:  Application for protein structure, dynamics and sequence analysis
RPMs: python3-ProDy
Size: 6.79 MiB
Size change:  -2.15 KiB

Package:  R-readxl-1.3.1-8.fc34
Old package:  R-readxl-1.3.1-7.fc33
Summary:  Read Excel Files
RPMs: R-readxl
Size: 3.48 MiB
Size change:  322 B
Changelog:
  * Fri Sep 18 2020 Elliott Sales de Andrade  - 
1.3.1-8
  - rebuilt for libxls


Package:  anaconda-34.5-1.fc34
Old package:  anaconda-34.4-1.fc34
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel
Size: 21.19 MiB
Size change:  147.28 KiB
Changelog:
  * Thu Sep 17 2020 Martin Kolman  - 34.5-1
  - Fix the combo box for an URL type of additional repositories (#1879127)
(vponcova)
  - Add DBus support for the ostreesetup kickstart command (vponcova)
  - Create the structure for RPM OSTree configuration (vponcova)
  - Create the RPM OSTree source module (vponcova)
  - Create the RPM OSTree module (vponcova)
  - network: clone connections from intramfs to persistent config (rvykydal)
  - network: set addr-gen-mode of Anaconda default connections to eui64
(rvykydal)
  - network: default to addr-gen-mode eui64 (rvykydal)
  - network: do not reset ipv6.addr-gen-mode in tui network configuration
(rvykydal)
  - network: get hwadddr when binding to mac more robustly (rvykydal)
  - Improve the error dialog for

Fedora-Cloud-31-20200918.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 7/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 18, 2020 at 09:31:59AM +0200, Bohdan Khomutskyi wrote:
> Hello Zbyszek,
> 
> > You haven't really answered the "why" part: why is it so important to
> save 50MB? And why is the effect on QA less important?
> 
> From my perspective, the storage on the installation medium should
> be efficiently used. Even though the optimization is just 50MiB, it
> is an optimization.
> 
> And this optimization is transparent in terms of content.
> 
> > And why is the effect on QA less important?
> 
> The QA team is only one group of users. We should rather orient at
> end users, and the way those users install Fedora.

Sorry, but that argument is not convincing. *Everything* we do has to
strike a balance. Making testing harder or slower also has an impact
on *users* — the stuff that they get will be less well tested.

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

Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

[Petr Pisar]

On Fri, Sep 18, 2020 at 12:21:15PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 18 September 2020 at 11:22, Petr Pisar wrote:
> > On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> > > So: RH Java packagers, what if you build these packages as non-modular
> > > (maybe using some scripting to make it happen at the same time as modular
> > > builds?) and add a readme explaining their maintenance state?
> > 
> > Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
> > directory? That won't work, because nobody looks there.
> 
> I do. :)
> 
> What about https://src.fedoraproject.org/rpms//blob/master/f/README.md ?
> 
Do you think that package users consult dist-git before reporting a bug?
I think the idea with a template in Bugzilla was better.

Moreover that file was supposed to display a source package description on all
possible places (and originally was supposed to automatically updated from SRPM
packages, but that was never implemented).

At the end a packager can put the notice into %description of the spec file.
I sometimes document there how the files are distributed among the subpcackages.

-- Petr


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

Re: Shouldn't we have process for removing zombie packages?

[Vít Ondruch]

Dne 18. 09. 20 v 12:37 Petr Pisar napsal(a):
> On Fri, Sep 18, 2020 at 10:42:00AM +0200, Vít Ondruch wrote:
>> This is not about nagging maintainer for the purpose of nagging them.
>>
> Filing the requests en mass is exactly nagging for nagging.


This might be misunderstanding, but I have never proposed filling
request en mass. I have proposed to have process to remove package when
somebody is in doubt it provides any value.


>  But
>
>> I feel exhausted seeing again and again packages which are very likely
>> broken,
> if the package is broken, then file a bug. That's a completely different
> case.
>
>> serving no purpose.
> That's a strong assertion. I hope that you know that a non-existance is not
> getting proved by claiming "I think there is none". But again, if you don't
> like the package, file a bug with the explanation why you think it should be
> removed.
>
>> I feel exhausted seeing that these packages pull in dependency chains which
>> are not possible to be updated or removed due to them.
>>
> If you need to update the dendency, then update the dependency and report
> a bug against the then broken package. See openssl package for an example.
>
> All I want to say that these issues should be handled case by case. There
> should be a reason for each of them and the bug report should be tailored to
> that case.


I agree with that and proposing that once the bug is filled, there
should be a way for the reporter to finish the job what the reporting of
bug starts. So your worries are not justified.


Vít


> But pushing the work of a responsible bug report from the reporter
> to the assignee is wrong.
>
> -- Petr
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: btrfs and default page sizes (4k vs 64k)

[Josh Boyer]

On Wed, Sep 16, 2020 at 10:44 AM Neal Gompa  wrote:
>
> On Wed, Sep 16, 2020 at 10:32 AM Eric Sandeen  wrote:
> >
> > On 9/15/20 7:29 PM, Neal Gompa wrote:
> > > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler  
> > > wrote:
> > >>
> > >> Daniel Pocock wrote:
> > >>> One issue I've come across is that a btrfs filesystem can only be used
> > >>> on hosts with the same page size as the host that created the filesystem
> > >>
> > >> Ewww! That alone should disqualify btrfs as a default file system!
> > >>
> > >> Why does a file system depend on the kernel page size? The kernel page 
> > >> size
> > >> is an internal implementation detail of the kernel, whereas a file system
> > >> ought to be a stable interchange format that is compatible across all
> > >> machines.
> > >>
> > >> It is unfortunate that this showstopper was not mentioned when the 
> > >> switch to
> > >> btrfs by default was proposed.
> >
> > I'm not sure that it would have been deemed any more important than other
> > concerns which were raised at the time, TBH.
> >
> > > I hate to break it to you, but this problem is not just in
> > > filesystems, it's in basically everything in the kernel. And we've had
> > > variations of problems like this for years (endianness, page size,
> > > pointer size, single bit vs multi-bit booleans, etc.). I've personally
> > > been bitten by all of these issues in some way. This comes from the
> > > fact that there's no such thing as "internal implementation detail of
> > > the kernel" by design. This is the "joy" of the monorepo "design"
> > > where everything leaks into everything else.
> >
> > That's simply not accurate.  Handling 32/64 bit interfaces, endianness, etc
> > are long-solved problems.  Longstanding lack of design or support for
> > sub-page block support in a filesystem is not /at all/ the same thing.
> >
> > Are there occasional endianness bugs, pointer size bugs, etc?  Sure.
> > But that's different from "We did not design this."
> >
>
> Almost every filesystem was not originally designed for mixing page
> sizes, endianness, etc. These issues *have* been fixed over time, for
> sure. But it is not worth it for me or anyone else to go into a blame
> game. Is it unfortunate that Btrfs didn't have that? Sure. Did I know
> this was a problem? No, because I have no access to POWER systems,
> like almost everyone else here. And ARM, the other architecture we
> have, does not use 64K page sizes in Fedora (though it does in RHEL,
> and that is pretty much considered a mistake there, as it didn't take
> off, caused interop and performance issues, and added complexity where
> it was unneeded).
>
> > > This didn't become a serious problem until Red Hat made the
> > > unfortunate (though not realized at the time) mistake of switching to
> > > 64k pages for ARM and POWER. We got that change in Fedora for POWER
> > > but not ARM. It has led to all kinds of unfortunate problems that are
> > > gradually being worked on and fixed upstream.
> >
> > Sub-page block support in filesystems is not a wild, esoteric, unexpected
> > feature.
> >
> > It's something that is generally available in nearly every other widely used
> > Linux filesystem.  It's not accurate to suggest that this is some unexpected
> > side effect of page size choice, or that 64k pages were somehow a "mistake"
> > now that this btrfs compatibility issue has been made more obvious.
> >
> > btw, Fedora has shipped kernels with 64k pages for almost a decade:
> >
> > commit 737c9c7da818f1da0bdf3f6a0dda5c38a3cba769
> > Author: Josh Boyer 
> > Date:   Fri Sep 9 11:21:22 2011 -0400
> >
> > Change to 64K page size for ppc64 kernels (rhbz 736751)
> >
>
> I am aware that we shipped them for a long time. They are a mistake
> for many other reasons unrelated to Btrfs. Regardless, the choice was
> made and things have been fixed over time for it. There is already a
> patch set being reviewed[1] for the first stage of mixed page support.

Apropos of nothing else in this thread, I love that I can continue my
trend of "everything bad in Fedora comes from Josh" :)

64k pages have significant performance advantages on large memory
machines and with specific workloads.  Is that worth the hassle and
complexity for using a page size that doesn't match the de facto
standard?  For the people that run those workloads, yes.  For Fedora,
probably not.  At the time of that decision ppc64 was a secondary
architecture with a lot of participation from IBM, which is naturally
focused more on server class workloads (and the bug is clear that we
didn't switch ppc32 because it makes no sense for that class of
hardware).

On the ppc64le architecture there has been significant benefit to
keeping the page size the same between Fedora and RHEL.  Up until
relatively recently it was almost exclusively server class hardware
still.  Some of the more recent offerings from IBM are smaller
configs, and the Talos machines are squarely aimed at developer
workstations.  If you'd like to revisi

Re: jbig2dec 0.19

[Anna Khaitovich]

Hi Michael,

> Given how previous updates went I intend to try a side-tag now.

+1 for side-tag approach. The only question I have is who is going to
coordinate those updates? For example, I already have an update for gs 9.53
for Rawhide prepared, should I create the side-tag, or should I wait until
you do it and just add gs to this tag?

Thanks in advance,

Anna Khaitovich
Software Engineer
Red Hat, R&D Platform
#brno, #infrastructure-services, #TFT


On Thu, Sep 17, 2020 at 3:39 PM Michael J Gruber 
wrote:

> There is a new version of jbig2dec which the new version of ghostscript
> requires. Given how previous updates went I intend to try a side-tag now.
> If you think your package is affected then please follow the discussion at:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1877889
>
> Also, if there are better ways to coordinate package builds across
> disjoint packager groups I'm open to suggestions. (jbig2dec does not
> version ABI properly, upstream wants it like that and has new checks which
> counteract ABI stability patches)
>
> Cheers
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 20/181 (x86_64)

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

ID: 670225  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/670225
ID: 670258  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/670258
ID: 670332  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/670332

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

ID: 670183  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/670183
ID: 670184  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/670184
ID: 670187  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/670187
ID: 670188  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/670188
ID: 670189  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/670189
ID: 670190  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/670190
ID: 670191  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/670191
ID: 670202  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/670202
ID: 670218  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/670218
ID: 670229  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/670229
ID: 670237  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/670237
ID: 670263  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/670263
ID: 670273  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/670273
ID: 670284  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/670284
ID: 670298  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/670298
ID: 670306  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/670306
ID: 670325  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/670325

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

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

ID: 670154  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/670154
ID: 670173  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/670173

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

ID: 670200  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/670200
ID: 670233  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/670233
ID: 670236  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/670236
ID: 670250  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/670250

Passed openQA tests: 155/181 (x86_64)

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

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

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 184 MiB to 208 MiB
Previous test data: https://openqa.fedoraproject.org/tests/668764#downloads
Current test data: https://openqa.fedoraproject.org/tests/670152#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 186 MiB to 209 MiB
System load changed from 0.09 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/668765#downloads
Current test data: https://openqa.fedoraproject.org/tests/670153#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.26 to 0.15
Previous test data: https://openqa.fedoraproject.org/tests/668774#downloads
Current test data: https://openqa.fedoraproject.org/tests/670162#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 140 MiB to 

Fedora-IoT-34-20200918.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-IoT-34-20200917.0):

ID: 670448  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/670448

Passed openQA tests: 15/16 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Copr package build fails on python-nocaselist package

[Robert-André Mauchin]

On Friday, 18 September 2020 12:24:21 CEST Andreas R Maier wrote:
> Thanks for the quick help and for the mini-review.
> 
> I have updated the spec file as recommended, except for the %py_provides
> macro because COPR did not like that when running the rpkg command:
> 
> Running: rpkg srpm --outdir /tmp/copr-rpmbuild-vtejek5l --spec
> /tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist/packaging/fedora/pyth
> on-nocaselist.spec
> 
> cmd: ['rpkg', 'srpm', '--outdir', '/tmp/copr-rpmbuild-vtejek5l', '--spec',
> '/tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist/packaging/fedora/pyt
> hon-nocaselist.spec'] cwd:
> /tmp/copr-rpmbuild-vtejek5l/obtain-sources/nocaselist
> rc: 0
> stdout: Wrote: /tmp/copr-rpmbuild-vtejek5l/python-nocaselist.spec
> stderr: error: line 34: Unknown tag: %py_provides python3-nocaselist
> can't parse specfile
> 
> With the changed spec file (without %py_provides), the situation is still
> that Koji succeeds and COPR fails with the same error as before:
> Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=51724144
>  COPR:
> https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build/1
> 673307/
>  1673307/>
> 
> I understand what you said about the difference in the archives in the SRPM
> files, but I'm afraid I don't quite understand how I can influence how COPR
> obtains the archive. In fact, even after looking at the log files I don't
> understand where it gets the archive from.
> 
> In COPR, I am defining the package to be built from SCM, with rpkg for
> building the SRPM:
> https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/package
> /python-nocaselist/
>  e/python-nocaselist/> Is that the way to do it?
> 
> Also, as far as I'm concerned we do not necessarily need to get the COPR
> build to succeed, as long as I can get the package review started by
> pointing to a Koji build. Please let me know.
> 
> Andy
> 
> > Begin forwarded message:
> > 
> > From: Robert-André Mauchin 
> > Subject: Re: Copr package build fails on python-nocaselist package
> > Date: 18. September 2020 at 11:34:31 CEST
> > To: Development discussions related to Fedora
> >  Reply-To: Development discussions related
> > to Fedora > 
> > On Friday, 18 September 2020 09:19:48 CEST Andreas R Maier wrote:
> >> Hi,
> >> I am new to building packages, and I'm trying to build a new package
> >> 'python-nocaselist' on Copr, and it fails in the %prep stage when
> >> unpacking
> >> the SRPM file because it cannot cd into the directory it assumes got
> >> unpacked: Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6rjfBt
> >> + umask 022
> >> + cd /builddir/build/BUILD
> >> + cd /builddir/build/BUILD
> >> + rm -rf nocaselist-1.0.2
> >> + /usr/bin/gzip -dc /builddir/build/SOURCES/nocaselist-1.0.2.tar.gz
> >> + /usr/bin/tar -xof -
> >> + STATUS=0
> >> + '[' 0 -ne 0 ']'
> >> + cd nocaselist-1.0.2
> >> /var/tmp/rpm-tmp.6rjfBt: line 39: cd: nocaselist-1.0.2: No such file or
> >> directory I have configured copr to point to the Git repo and spec file.
> >> 
> >> The same spec file builds fine on Koji.
> >> 
> >> Spec file:
> >> https://github.com/pywbem/nocaselist/blob/andy/fedora-packaging/packaging
> >> /f
> >> edora/python-nocaselist.spec
> >>  >> g/
> >>  >> ng/> fedora/python-nocaselist.spec> Failing Copr build:
> >> https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/build
> >> /1
> >>  >> ld/1> 672638/
> >>  >> d/
> >>  >> ld/> 1672638/> Successful Koji build:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=51713400
> >> 
> >>  >> >
> >> 
> >> What am I doing wrong here?
> >> 
> >> Thanks for any help
> >> Andy
> > 
> > The archives in your SRPM are different:
> > - on COPR the root directory of your archive is
> > python-%{srcname}-%{version} 
> > - on Koji the root directory of your archive
> > is %{srcname}-%{version}
> > 
> > To download the true original archive from Pypi, use "spectool -g *.spec"
> > in the directory that contains your SPEC file.
> > Then open the archive and see that the root of the archive is named %
> > {srcname}-%{version} , like on Koji.
> > To regenerate the SRPM, use: fedpkg --release f34 srpm in the directory
> > that contains your SPEC file.
> > 
> > Mini review:
> > 

Proposed Project for GSoC - Unintrusive Synchronized Authorship Web Application

[Akashdeep Dhar]

Hi folks,

Akashdeep/t0xic0der here. I would love to hear what you think about a project 
that I am proposing for Fedora's representation in this year's Google Summer of 
Code. Take a look at the following excerpt which was taken from the proposition 
I wrote (Check issue https://pagure.io/mentored-projects/issue/85 of 
mentored-projects for the entire content and the conversation regarding it).



- There has been this web application I have been building a functional 
prototype for, which allows for synchronized authorship of documents in an 
unintrusive manner. The project is called Syngrafias.

- To explain this in a better way, people who have used Google Docs for editing 
documents collaboratively know how the changes made to the document are 
actively synchronized to all the collaborators during the time of editing. 
Syngrafias does that but with a much more distributive approach to it - as here 
the changes made in the document in the absence of the other user would not be 
synchronized, thereby seamlessly creating (say) a fork of the same document. 
([See the attached image 
collabnt.png](https://raw.githubusercontent.com/t0xic0der/syngrafias/master/pictures/collabnt.png))

- The unintrusiveness in the document editing can be better explained if I draw 
parallelism with Jupyterlab. Just like in Jupyterlab, we have distinctive cells 
here for editing text. It is a simple mechanism but with much greater 
functionality as it allows you to selectively share the parts of the document 
you want collaborators to edit and rearrange the parts of the document by 
simply using a drag-n-drop operation. I have added in Summernote for WYSIWYG 
editing for each cell. ([See the attached image 
opendocs.png](https://raw.githubusercontent.com/t0xic0der/syngrafias/master/pictures/opendocs.png))

- Of course, there is activity tracking so any change in the document title, 
cell title or cell content gets logged and activities like cell creation and 
removal are synchronized across all connected clients. The way I see it, this 
project can bring about radical positive changes to the way Fedora's project 
documentation are worked upon collaboratively. Also, if I simply replace 
Summernote with CodeMirror - this can even be used for collaboratively editing 
code snippets on-the-go. ([See the attached image 
activlog.png](https://raw.githubusercontent.com/t0xic0der/syngrafias/master/pictures/activlog.png))

- With 57 commits as of the time of writing the idea description, the project 
is only getting started and only the bare functionalities of the project are 
complete. You can find the repository 
[here](https://github.com/t0xic0der/syngrafias), the usage instructions 
[here](https://github.com/t0xic0der/syngrafias/wiki/Usage) and the screenshots 
[here](https://github.com/t0xic0der/syngrafias/wiki/Screenshots). There are 
tons that we can expand upon if this ends up becoming a project for GSoC. I 
would very much love for you folks to try out the project, let know what you 
think about it and your valuable suggestions for it to become a GSoC project - 
if it can. I would be obliged.



The reason why I wish to propose this (outside) project for Fedora's GSoC 
representation is because it has the potential to be a project assisting the 
distro/community (e.g. Bodhi and Mote) by making the process of documentation 
creation much more efficient and conveniently collaborative (as compared to the 
Pagure and Antora-bound method that we use right now). Do note that the project 
(I believe) aims to complement the tried-and-tested systems in place as of now 
with the features it has (and plans to have).

The way I see it - the project I am proposing here can complement to Antora's 
functioning by cutting down on the mandated build times to generate a preview 
(as we have a WYSIWYG feature) and deferred collaboration (highly subjective 
though as active synchronization would mostly benefit only those who are living 
at the same timezone and decide to work together for the same time). I cannot 
emphasize enough  how beneficial it can be to try out the project prototype to 
understand how capable the project can be. You can find the [project 
page](https://github.com/t0xic0der/syngrafias) and the [project 
wiki](https://github.com/t0xic0der/syngrafias/wiki) links here. (or drop a 
response expressing willingness for a demonstration and maybe, we can schedule 
a video meet ;-))

As the proposed project marks a departure from the kinds of project that were 
used to be proposed for GSoC, it would be vital for me to know what you think 
about the proposed idea and the likeliness of adoption of the ideas stated in 
the project. How effective do you think it can be (if it can be selected as a 
GSoC project) and what can be done to make it better?

Thanks in advance. Looking forward to your responses.

Yours faithfully,
Akashdeep Dhar
___
devel mailing list -- devel@lists.fedoraproject.org
To

Re: btrfs and default page sizes (4k vs 64k)

[Daniel Pocock]

On 16/09/2020 21:29, Josef Bacik wrote:
> On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote:
>> On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
>>> At the time we tied the fs blocksize to the
>>> page size, because it was unlikely that a user would mkfs a fs on one
>>> arch
>>> and move it over to another arch.
>>
>> But one doesn't need "another arch" for page size to change; many
>> architectures (arm, mips, powerpc, sparc, to name a few) support multiple
>> page sizes.
> 
> Sure, but again you are not likely to change page size for an existing
> system. The decision early on was to forgo this particular ability for
> simplicity, and then we would revisit the decision later on.  It's been
> a while and there's still not been enough demand to justify the work
> until recently.  Thanks,


This is messy but important

Is it possible for Fedora to offer two flavours of the kernel package,
like Debian?  There, I created a -4k flavour so it builds two kernel
packages, one with 4k and the other with 64k.  They can both be
installed on the same machine and one or the other selected in the grub
menu on each boot.  Either can mount an ext4 root but obviously they
can't share the same btrfs root, only the one that created it can mount
that root.

Once an alternative kernel is available, people need an installer/rescue
ISO including that kernel.  This may mean making both permutations
available as different installer ISOs, or including two kernels in the
same ppc64el

Installer logic: If somebody is using ANY non-4k page size, on any
architecture, it would be useful to display a pop-up window with a
warning about btrfs before they create their root filesystem.  This will
save a lot of trouble for people.  They might not realize there is a
problem until they've been using the system for a few days and then they
have to reinstall it again.

Finally, if both page sizes are available, it is desirable to do a build
of every package for every page size.  Some packages appear to sense the
page size at compile time and assume it will always be the same at
runtime.  This is unfortunate.  Maybe reproducible builds techniques can
be used to build each package on two different page sizes, detect if the
binary differs and if so, suggest checking for hard-coded page size.

Regards,

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

Re: btrfs and default page sizes (4k vs 64k)

[Neal Gompa]

On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock  wrote:
>
>
>
> On 16/09/2020 21:29, Josef Bacik wrote:
> > On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote:
> >> On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
> >>> At the time we tied the fs blocksize to the
> >>> page size, because it was unlikely that a user would mkfs a fs on one
> >>> arch
> >>> and move it over to another arch.
> >>
> >> But one doesn't need "another arch" for page size to change; many
> >> architectures (arm, mips, powerpc, sparc, to name a few) support multiple
> >> page sizes.
> >
> > Sure, but again you are not likely to change page size for an existing
> > system. The decision early on was to forgo this particular ability for
> > simplicity, and then we would revisit the decision later on.  It's been
> > a while and there's still not been enough demand to justify the work
> > until recently.  Thanks,
>
>
> This is messy but important
>
> Is it possible for Fedora to offer two flavours of the kernel package,
> like Debian?  There, I created a -4k flavour so it builds two kernel
> packages, one with 4k and the other with 64k.  They can both be
> installed on the same machine and one or the other selected in the grub
> menu on each boot.  Either can mount an ext4 root but obviously they
> can't share the same btrfs root, only the one that created it can mount
> that root.
>
> Once an alternative kernel is available, people need an installer/rescue
> ISO including that kernel.  This may mean making both permutations
> available as different installer ISOs, or including two kernels in the
> same ppc64el
>
> Installer logic: If somebody is using ANY non-4k page size, on any
> architecture, it would be useful to display a pop-up window with a
> warning about btrfs before they create their root filesystem.  This will
> save a lot of trouble for people.  They might not realize there is a
> problem until they've been using the system for a few days and then they
> have to reinstall it again.
>
> Finally, if both page sizes are available, it is desirable to do a build
> of every package for every page size.  Some packages appear to sense the
> page size at compile time and assume it will always be the same at
> runtime.  This is unfortunate.  Maybe reproducible builds techniques can
> be used to build each package on two different page sizes, detect if the
> binary differs and if so, suggest checking for hard-coded page size.
>

I think all of this effort required is why we probably *won't* do that.

I would be interested in seeing what kind of performance differences
there are between 4K page sizes and 64K page sizes, but I don't
particularly want to make ppc64le change back to 4K page sizes, simply
because there's not much point to it. POWER systems are still largely
unavailable to people and that's not going to change anytime soon.

As for a warning, I do not have the cycles to do that. As it stands,
if I'm going to put my limited contributing energy into something,
it'd probably be to help upstream fix the problem with non-4K page
sizes in the first place. Since you're interested in this problem,
perhaps you could help upstream with testing the patches and writing
code to fix this? Especially since it sounds like you have hardware
and use-cases to test this with.





-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 21st September

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting next week on
Monday 21 September at 1300UTC in #fedora-neuro on IRC (Freenode). The
meeting is a public meeting, and open for everyone to attend.

https://webchat.freenode.net/?channels=#fedora-neuro

The channel is bridged to Telegram, so you can also join us there on the
@NeuroFedora group:
https://t.me/NeuroFedora

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 next Mon'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting&iso=20200921T13&p1=1440&ah=1

The meeting will be chaired by @ankursinha. The agenda for the meeting
is:

- New introductions and roll call.
- Tasks from last week's meeting:
  
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2020-09-07-13.07.html
- Open Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Open bugs check: https://tinyurl.com/neurofedora-bugs
- CompNeuro lab compose status check for F33/F34.
- Neuroscience query of the week.
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

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


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

Fedora 33 compose report: 20200918.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200917.n.0
NEW: Fedora-33-20200918.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  3
Dropped packages:47
Upgraded packages:   104
Downgraded packages: 126

Size of added packages:  10.30 MiB
Size of dropped packages:1.04 GiB
Size of upgraded packages:   1.20 GiB
Size of downgraded packages: 1.49 GiB

Size change of upgraded packages:   -33.96 MiB
Size change of downgraded packages: -243.92 MiB

= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-33-20200918.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: jaf-1.2.1-3.module_f33+7821+c2c8f5c9
Summary: JavaBeans Activation Framework
RPMs:jaf jaf-javadoc
Size:149.62 KiB

Package: tracker3-3.0.0-1.fc33
Summary: Desktop-neutral metadata database and search tool
RPMs:libtracker-sparql3 tracker3 tracker3-devel tracker3-doc
Size:5.54 MiB

Package: tracker3-miners-3.0.0-2.fc33
Summary: Tracker miners and metadata extractors
RPMs:tracker3-miners
Size:4.61 MiB


= DROPPED PACKAGES =
Package: OpenEXR-2.3.0-6.module_f33+10160+805b0fb5
Summary: A high dynamic-range (HDR) image file format
RPMs:OpenEXR OpenEXR-devel OpenEXR-doc OpenEXR-libs
Size:15.87 MiB

Package: SDL-1.2.15-45.module_f33+10160+805b0fb5
Summary: A cross-platform multimedia library
RPMs:SDL SDL-devel SDL-static
Size:3.57 MiB

Package: SDL_image-1.2.12-25.module_f33+10160+805b0fb5
Summary: Image loading library for SDL
RPMs:SDL_image SDL_image-devel
Size:274.37 KiB

Package: adobe-mappings-cmap-20171205-9.module_f33+10160+805b0fb5
Summary: CMap resources for Adobe's character collections
RPMs:adobe-mappings-cmap adobe-mappings-cmap-deprecated 
adobe-mappings-cmap-devel
Size:2.01 MiB

Package: adobe-mappings-pdf-20180407-7.module_f33+10160+805b0fb5
Summary: PDF mapping resources from Adobe
RPMs:adobe-mappings-pdf adobe-mappings-pdf-devel
Size:675.69 KiB

Package: atkmm-2.24.3-6.module_f33+10160+805b0fb5
Summary: C++ interface for the ATK library
RPMs:atkmm atkmm-devel atkmm-doc
Size:1.20 MiB

Package: boost-1.73.0-7.module_f33+10160+805b0fb5
Summary: The free peer-reviewed portable C++ source libraries
RPMs:boost boost-atomic boost-b2 boost-build boost-chrono boost-container 
boost-context boost-contract boost-coroutine boost-date-time boost-devel 
boost-doc boost-doctools boost-examples boost-fiber boost-filesystem 
boost-graph boost-iostreams boost-locale boost-log boost-math boost-nowide 
boost-numpy3 boost-program-options boost-python3 boost-random boost-regex 
boost-serialization boost-stacktrace boost-static boost-system boost-test 
boost-thread boost-timer boost-type_erasure boost-wave
Size:300.20 MiB

Package: cairomm-1.12.0-13.module_f33+10160+805b0fb5
Summary: C++ API for the cairo graphics library
RPMs:cairomm cairomm-devel cairomm-doc
Size:1.17 MiB

Package: dbus-glib-0.110-10.module_f33+10160+805b0fb5
Summary: GLib bindings for D-Bus
RPMs:dbus-glib dbus-glib-devel
Size:959.45 KiB

Package: exiv2-0.27.3-4.module_f33+10160+805b0fb5
Summary: Exif and Iptc metadata manipulation library
RPMs:exiv2 exiv2-devel exiv2-doc exiv2-libs
Size:12.80 MiB

Package: flatpak-rpm-macros-33-1.module_f33+10159+5494a6e5
Summary: Macros for building RPMS for flatpaks
RPMs:flatpak-rpm-macros
Size:53.29 KiB

Package: flatpak-runtime-config-33-1.module_f33+10159+5494a6e5
Summary: Configuration files that live inside the flatpak runtime
RPMs:flatpak-runtime-config
Size:57.67 KiB

Package: gd-2.3.0-3.module_f33+10160+805b0fb5
Summary: A graphics library for quick creation of PNG or JPEG images
RPMs:gd gd-devel gd-progs
Size:1.03 MiB

Package: geocode-glib-3.26.2-2.module_f33+10160+805b0fb5
Summary: Geocoding helper library
RPMs:geocode-glib geocode-glib-devel
Size:649.20 KiB

Package: ghostscript-9.52-8.module_f33+10160+805b0fb5
Summary: Interpreter for PostScript language & PDF
RPMs:ghostscript ghostscript-core ghostscript-doc ghostscript-gtk 
ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing 
ghostscript-x11 libgs libgs-devel
Size:23.92 MiB

Package: glew-2.1.0-8.module_f33+10160+805b0fb5
Summary: The OpenGL Extension Wrangler Library
RPMs:glew glew-devel libGLEW
Size:2.32 MiB

Package: glibmm24-2.64.2-4.module_f33+10160+805b0fb5
Summary: C++ interface for the GLib library
RPMs:glibmm24 glibmm24-devel glibmm24-doc
Size:11.36 MiB

Package: gnome-online-accounts-3.37.90-1.module_f33+10160+805b0fb5
Summary: Single sign-on framework for GNOME
RPMs:gnome-online-accounts gnome-online-accounts-devel
Size:3.13 MiB

Package: google-droid-fonts-20200215-8.module_f33+10160+805b0fb5
Summary: A set of general-purpose font families released by Google as part of 
Android
RPMs:google-droid-fonts-all google-droid-sans-fonts 
google-droid-

Re: btrfs and default page sizes (4k vs 64k)

[Daniel Pocock]

On 18/09/2020 14:34, Neal Gompa wrote:
> On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock  wrote:
>>
>>
>>
>> On 16/09/2020 21:29, Josef Bacik wrote:
>>> On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote:
 On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
> At the time we tied the fs blocksize to the
> page size, because it was unlikely that a user would mkfs a fs on one
> arch
> and move it over to another arch.

 But one doesn't need "another arch" for page size to change; many
 architectures (arm, mips, powerpc, sparc, to name a few) support multiple
 page sizes.
>>>
>>> Sure, but again you are not likely to change page size for an existing
>>> system. The decision early on was to forgo this particular ability for
>>> simplicity, and then we would revisit the decision later on.  It's been
>>> a while and there's still not been enough demand to justify the work
>>> until recently.  Thanks,
>>
>>
>> This is messy but important
>>
>> Is it possible for Fedora to offer two flavours of the kernel package,
>> like Debian?  There, I created a -4k flavour so it builds two kernel
>> packages, one with 4k and the other with 64k.  They can both be
>> installed on the same machine and one or the other selected in the grub
>> menu on each boot.  Either can mount an ext4 root but obviously they
>> can't share the same btrfs root, only the one that created it can mount
>> that root.
>>
>> Once an alternative kernel is available, people need an installer/rescue
>> ISO including that kernel.  This may mean making both permutations
>> available as different installer ISOs, or including two kernels in the
>> same ppc64el
>>
>> Installer logic: If somebody is using ANY non-4k page size, on any
>> architecture, it would be useful to display a pop-up window with a
>> warning about btrfs before they create their root filesystem.  This will
>> save a lot of trouble for people.  They might not realize there is a
>> problem until they've been using the system for a few days and then they
>> have to reinstall it again.
>>
>> Finally, if both page sizes are available, it is desirable to do a build
>> of every package for every page size.  Some packages appear to sense the
>> page size at compile time and assume it will always be the same at
>> runtime.  This is unfortunate.  Maybe reproducible builds techniques can
>> be used to build each package on two different page sizes, detect if the
>> binary differs and if so, suggest checking for hard-coded page size.
>>
> 
> I think all of this effort required is why we probably *won't* do that.
> 
> I would be interested in seeing what kind of performance differences
> there are between 4K page sizes and 64K page sizes, but I don't
> particularly want to make ppc64le change back to 4K page sizes, simply
> because there's not much point to it. POWER systems are still largely
> unavailable to people and that's not going to change anytime soon.

It looks like a lot of packages are impacted by this issue, it is not
just btrfs

Examples that I already experienced personally:

- Firefox, especially things involving media content, like WebRTC

- Nouveau

Both of those were fixed without any recompiling, just using the same
Firefox and Nouveau binaries on a 4k kernel.

> As for a warning, I do not have the cycles to do that. As it stands,
> if I'm going to put my limited contributing energy into something,
> it'd probably be to help upstream fix the problem with non-4K page
> sizes in the first place. Since you're interested in this problem,
> perhaps you could help upstream with testing the patches and writing
> code to fix this? Especially since it sounds like you have hardware
> and use-cases to test this with.


In the 10 years since the 64k page size was selected, a lot of things
still haven't been patched.  People who buy these workstations don't
necessarily have the bandwidth to fix all that.  It feels like we're
being pushed to fix stuff like that in other people's code when we could
just use a 4k page size and not worry about it.

It is a chicken-and-egg problem: people might be deterred from using the
platform if they keep hearing reports that Firefox doesn't work.  From
my experience, Firefox is working and it is working better with the 4k
page size kernel that I compiled.

It looks like interest in the platform will increase too: FSF recently
certified it as Respects Your Freedom.  Vikings[1], in Germany, are
making plans to distribute it in Europe.  Overall, the machines are very
nice for developers.  Given the amount of parallelism in the
architecture, a small development or support team could share one of
these machines between 2 to 4 people in a multi-seat configuration.

Regards,

Daniel

1. https://vikings.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-U

Self Introduction: Matthew H.

[proletarius101 via devel]

Hi,

My name is Matthew H. and I'm an open source enthusiast. I've contributed to 
[RSSHub](https://github.com/DIYgod/RSSHub) (a RSS feed baker), 
[Island](https://github.com/oasisfeng/island/) (a Work-profile based container 
manager on Android), [Surgio](https://github.com/geekdada/surgio/) (a proxy 
rule generator), etc. Now I'm planning to help package 
[Hydroxide](https://github.com/emersion/hydroxide).

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

Fedora-33-20200918.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 7/181 (x86_64)

New failures (same test not failed in Fedora-33-20200917.n.0):

ID: 670514  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/670514
ID: 670540  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/670540
ID: 670626  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/670626

Old failures (same test failed in Fedora-33-20200917.n.0):

ID: 670495  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/670495
ID: 670500  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/670500
ID: 670503  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/670503
ID: 670541  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/670541

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

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

ID: 670545  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/670545
ID: 670548  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/670548

Old soft failures (same test soft failed in Fedora-33-20200917.n.0):

ID: 670466  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/670466
ID: 670485  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/670485
ID: 670512  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/670512
ID: 670525  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/670525
ID: 670562  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/670562
ID: 670575  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/670575
ID: 670596  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/670596

Passed openQA tests: 165/181 (x86_64)

New passes (same test not passed in Fedora-33-20200917.n.0):

ID: 670546  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/670546
ID: 670547  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/670547
ID: 670549  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/670549
ID: 670550  Test: x86_64 Silverblue-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/670550
ID: 670551  Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/670551
ID: 670552  Test: x86_64 Silverblue-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/670552
ID: 670553  Test: x86_64 Silverblue-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/670553
ID: 670554  Test: x86_64 Silverblue-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/670554
ID: 670555  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/670555

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 36 MiB to 22 MiB
3 packages(s) added since previous compose: libtracker-sparql3, tracker3, 
tracker3-miners
Previous test data: https://openqa.fedoraproject.org/tests/669136#downloads
Current test data: https://openqa.fedoraproject.org/tests/670509#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used mem changed from 806 MiB to 1001 MiB
Used swap changed from 32 MiB to 29 MiB
3 packages(s) added since previous compose: libtracker-sparql3, tracker3, 
tracker3-miners
Average CPU usage changed from 29.55714286 to 14.3667
Previous test data: https://openqa.fedoraproject.org/tests/669138#downloads
Current test data: https://openqa.fedoraproject.org/tests/670511#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 778 MiB to 925 MiB
Used Swap grew from 0 to 13 MiB
Average CPU usage changed from 7.03809524 to 33.2
Previous test data: https://openqa.fedoraproject.org/tests/669155#downloads
Current test data: https://openqa.fedoraproject.org/tests/670528#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 0.78 to 1.10
Previous test data: https://openqa.

Re: Self Introduction: Matthew H.

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 18, 2020 at 01:13:04PM +, proletarius101 via devel wrote:
> Hi,
> 
> My name is Matthew H. and I'm an open source enthusiast. I've contributed to 
> [RSSHub](https://github.com/DIYgod/RSSHub) (a RSS feed baker), 
> [Island](https://github.com/oasisfeng/island/) (a Work-profile based 
> container manager on Android), [Surgio](https://github.com/geekdada/surgio/) 
> (a proxy rule generator), etc. Now I'm planning to help package 
> [Hydroxide](https://github.com/emersion/hydroxide).
> 
> Good to know everyone.


Hi Matthew,

welcome to Fedora.

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

Re: btrfs and default page sizes (4k vs 64k)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> I'm annoyed in general that we still have problems like this, and I'm
> even more annoyed that I basically have no way to even test or deal
> with these things. We *still* do not have packager test machines, so I
> can't even figure out how to craft a workaround if there is one (and I
> suspect one is possible).

We do: 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers.
There's one ppc64le on that list.

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

Re: btrfs and default page sizes (4k vs 64k)

[Neal Gompa]

On Fri, Sep 18, 2020 at 10:07 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> > I'm annoyed in general that we still have problems like this, and I'm
> > even more annoyed that I basically have no way to even test or deal
> > with these things. We *still* do not have packager test machines, so I
> > can't even figure out how to craft a workaround if there is one (and I
> > suspect one is possible).
>
> We do: 
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers.
> There's one ppc64le on that list.
>

They were all down, last I checked a month ago. But it seems like the
ppc64le one is back online now. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20200918.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64)

New failures (same test not failed in Fedora-IoT-33-20200917.2):

ID: 670772  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/670772
ID: 670775  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/670775

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

Old soft failures (same test soft failed in Fedora-IoT-33-20200917.2):

ID: 670761  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/670761

Passed openQA tests: 13/16 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.33 to 0.17
Previous test data: https://openqa.fedoraproject.org/tests/669542#downloads
Current test data: https://openqa.fedoraproject.org/tests/670762#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

[David Cantrell]

On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:

On Fri, Sep 11, 2020 at 11:01:00AM -0700, Adam Williamson wrote:

If one of the issues here can be stated as "we want buildroot-only
packages because we don't want to maintain those packages to a high
standard", it is demonstrably a viable choice within Fedora to just
*not maintain those packages to a high standard*. Maybe we wish it
wasn't the case, but this is a thing that happens all the time. We have


YES. In fact, *labeling* this is explicitly one of the things I wanted from
modularity. I have a slide about this in one of my talks even, although I
can't find it right now. The upshot is: packagers care about the software
they want to run, and package up and maintain deps either because they want
to do the right thing and be helpful -- or because they have to.

I mean, some of y'all like to maintain and keep obscure dependency packages
up to date just for their own sake, and that's *awesome* -- but we just
can't hold everyone to that standard. At least, not if we want more than a
few dozen packagers. So the *idea* was that modularity would let anyone
express "I need these packages as dependencies, but I don't have the cycles
to maintain them" -- not because that's an awesome situation, but because
it's the reality and the status quo for a lot of things.


Burying build-only dependencies in a module adds more work in the long
run.  If something-doc-tool is a build dep for a module and is now
part of that module, it's visibility is decreased to other package
maintainers that may want to use it.  Being able to find it now puts
the burden of having detailed knowledge of every module in the
distribution as well as the distribution itself on all package
maintainers.  And then if they find it, how can they use it since it's
part of a module as a build only dep.  Can it become part of another
module?  Say it can, now work has to be coordinated among the package
maintainers using something-doc-tool as a build dep so they don't
duplicate work.  The net gain here is that we have avoiding exposing
something-doc-tool as a package that users can install?  Why?

As stated elsewhere on the thread, to achieve what you're describing
is much easier in other ways.  I don't know why we haven't explored
creating an additional repo of shared build deps or even just "rawer"
packages that maybe don't get the maintenance attention that other
packages do.  We already know that goes on, but the packages are just
part of the main repo.  So instead of classifying them collectively
and keeping them open for shared and collaborative maintenance, we
want to make them hidden build deps in modules?

New community members looking to become package maintainers... if we
had a grouping of packages in need of care that were only build deps
for other packages, the barrier to entry is less daunting if you know
that you won't have a million users.

TL;DR modularity decreases component visibility and works against open
collaboration.


So: RH Java packagers, what if you build these packages as non-modular
(maybe using some scripting to make it happen at the same time as modular
builds?) and add a readme explaining their maintenance state? I think that'd
be preferable to where we are now, and it gets us to the next thing:

* you could still help update and maintain these as time and inclination
 allows without feeling pressure, and...

* rather than needing to do duplicative work all alone, the stewardship SIG
 could focus on serious security issues and high-priority bugs in this
 package set.

That way, the application ecosystem would be available, the build deps would
be there, and, actually, because of the collaboration, you wouldn't need to
feel guilty about package maintenance state.


What am I missing with this?


I think this is on the right path.  Shared ownership and collaboration
is a good way forward for these types of packages.

If I am using a package as a build dep and find it's outdated or
broken in some way, I can fix it and send a PR in Pagure to update it.
The maintainer can review and merge that or at least start a
discussion with me on the why and how of the change.  I haven't had to
take complete ownership of that package, but just spent the time to
fix the problem I saw.  For packages in a less than bleeding edge
ultra stable state, my main concern is that they are functional rather
than latest version.  I suspect many of us also prefer that for build
deps in most cases.

Maybe in addition to a per-package README, a broader communication of
this process to the community as well as providing a link to open bug
queries for packages would be useful for work similar to the "kernel
janitors" type work for the kernel.  Lots of stuff has to be done on
an ongoing basis and everyone can chip in from time to time.  We could
consider a standard doc name like "MAINT" or something in the package
that describes the specifics regarding maintenance in Fedora.

Thanks,

-

Re: jbig2dec 0.19

[Michael J Gruber]

Thanks for the input.
I don't mind learning how to do this ;)
Just to confirm that I picked the right path (from various I found documented):

fedpkg request-side-tag --base-tag rawhide
fedpkg build --target=

.. and wait for all of us to the builds, before using:
bodhi updates new --from-tag

Should we do this for {f33,f32}-candidate in parallel (and bodhi update in 
proper sequence)? 

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

Re: Kubernetes Development SIG

[Ivan Chavero]

Sounds great!

I would like to participate as user and developer

Cheers,
Iván

On Tue, Sep 15, 2020 at 7:45 AM Leonardo Rossetti 
wrote:

> Hello all,
>
> I would like to present a Kubernetes Development SIG.
>
> I initially thought of an "operator SIG" but I think a wider SIG about
> programming components and services with Kubernetes APIs and internal
> components made more sense (inspired by the "Programming Kubernetes" book).
>
> I am using some of the fields/titles described in this document [1] as the
> proposal template.
>
> Proposal Name
> 
>
> SIG: Kubernetes Development
>
> Summary
> ===
>
> A SIG for people interested in using, developing, extending kubernetes for
> Fedora components and services.
>
> Owner
> =
>
> Name: Leonardo Rossetti (lrossett)
> Email: lross...@redhat.com
>
> Benefit to Fedora
> =
>
> Development Experience and Learning
> 
>
> A place to exchange and discuss kubernetes development design and patterns.
>
> Extending kubernetes is not that straightforward so this SIG would be a
> good place to learn more about it.
>
> Kubernetes can be extended in the following areas:
>
> * Kubectl Plugins
> * Custom API Servers
> * Custom Controllers / Operators
>
> Operator Development
> ---
>
> The Operator SDK [3] is the shining new framework when developing custom
> kubernetes controllers nas has become a popular tool for packaging and
> deploying applications in kubernetes.
>
> Some Fedora services and components could leverage the usage of an
> operator (as we are doing with MBBOX [2]) but other services could be
> deployed via operators as well and even the mbbox operator could be split
> into smaller operators.
>
> Kubernetes DevOps
> ---
>
> The SIG could also be a place for sysadmins and ops engineers to discuss
> the challenges, practices and tooling of monitoring, deploying and running
> operators, api servers and other related kubernetes components in
> production.
>
> [1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
> [2] - https://github.com/fedora-infra/mbbox
> [3] - https://github.com/operator-framework/operator-sdk
>
> --
>
> Leonardo Rossetti
>
> Senior Software Engineer,
>
> Red Hat 
>
> lross...@redhat.com
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kubernetes Development SIG

[Abhiram Kuchibhotla]

Count me in too!

Regards,
Abhiram K

On Fri, 18 Sep, 2020, 10:54 pm Ivan Chavero,  wrote:

> Sounds great!
>
> I would like to participate as user and developer
>
> Cheers,
> Iván
>
> On Tue, Sep 15, 2020 at 7:45 AM Leonardo Rossetti 
> wrote:
>
>> Hello all,
>>
>> I would like to present a Kubernetes Development SIG.
>>
>> I initially thought of an "operator SIG" but I think a wider SIG about
>> programming components and services with Kubernetes APIs and internal
>> components made more sense (inspired by the "Programming Kubernetes" book).
>>
>> I am using some of the fields/titles described in this document [1] as
>> the proposal template.
>>
>> Proposal Name
>> 
>>
>> SIG: Kubernetes Development
>>
>> Summary
>> ===
>>
>> A SIG for people interested in using, developing, extending kubernetes
>> for Fedora components and services.
>>
>> Owner
>> =
>>
>> Name: Leonardo Rossetti (lrossett)
>> Email: lross...@redhat.com
>>
>> Benefit to Fedora
>> =
>>
>> Development Experience and Learning
>> 
>>
>> A place to exchange and discuss kubernetes development design and
>> patterns.
>>
>> Extending kubernetes is not that straightforward so this SIG would be a
>> good place to learn more about it.
>>
>> Kubernetes can be extended in the following areas:
>>
>> * Kubectl Plugins
>> * Custom API Servers
>> * Custom Controllers / Operators
>>
>> Operator Development
>> ---
>>
>> The Operator SDK [3] is the shining new framework when developing custom
>> kubernetes controllers nas has become a popular tool for packaging and
>> deploying applications in kubernetes.
>>
>> Some Fedora services and components could leverage the usage of an
>> operator (as we are doing with MBBOX [2]) but other services could be
>> deployed via operators as well and even the mbbox operator could be split
>> into smaller operators.
>>
>> Kubernetes DevOps
>> ---
>>
>> The SIG could also be a place for sysadmins and ops engineers to discuss
>> the challenges, practices and tooling of monitoring, deploying and running
>> operators, api servers and other related kubernetes components in
>> production.
>>
>> [1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
>> [2] - https://github.com/fedora-infra/mbbox
>> [3] - https://github.com/operator-framework/operator-sdk
>>
>> --
>>
>> Leonardo Rossetti
>>
>> Senior Software Engineer,
>>
>> Red Hat 
>>
>> lross...@redhat.com
>> 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: btrfs and default page sizes (4k vs 64k)

[Kevin Fenzi]

On Fri, Sep 18, 2020 at 10:08:46AM -0400, Neal Gompa wrote:
> On Fri, Sep 18, 2020 at 10:07 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> > > I'm annoyed in general that we still have problems like this, and I'm
> > > even more annoyed that I basically have no way to even test or deal
> > > with these things. We *still* do not have packager test machines, so I
> > > can't even figure out how to craft a workaround if there is one (and I
> > > suspect one is possible).
> >
> > We do: 
> > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers.
> > There's one ppc64le on that list.
> >
> 
> They were all down, last I checked a month ago. But it seems like the
> ppc64le one is back online now. :)

The aarch64/armv7 ones are still down, but we got a vm elsewhere for ppc64le. 
The x86_64 ones should all be up and working. 

kevin


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

Re: btrfs and default page sizes (4k vs 64k)

[Steven Munroe]

The correct solution for userland is getpagesize() from .

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

Re: btrfs and default page sizes (4k vs 64k)

[Michael Catanzaro]

On Fri, Sep 18, 2020 at 1:33 pm, Steven Munroe  
wrote:

The correct solution for userland is getpagesize() from .

This API has been there a long time.


Some software requires that the page size be known at compile time, 
e.g. WebKit's JavaScriptCore. Therefore getpagesize() is really not 
good enough.


We could use getpagesize() to test the page size at compile time, but 
it would fail if cross-compiling, so instead we just hardcode guesses 
in the code. For aarch64 RHEL has some hacky patch that can never go 
upstream to change the page size.


I don't have much good to say about this situation.

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

Re: Self Introduction: Matthew H.

[Michel Alexandre Salim]

Hi Matthew,

On Fri, 2020-09-18 at 13:13 +, proletarius101 via devel wrote:
> Hi,
> 
> My name is Matthew H. and I'm an open source enthusiast. I've
> contributed to RSSHub (a RSS feed baker), Island (a Work-profile
> based container manager on Android), Surgio (a proxy rule generator),
> etc. Now I'm planning to help package Hydroxide. 
> 
As someone who runs Island for privacy reasons, thank you for your
contributions there!

And welcome to Fedora :)

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


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 blocker status

[Ben Cotton]

We're getting close! I'm going to make Adam request an RC next week
whether he likes it or not. :-)

Action summary


Accepted blockers
-
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — VERIFIED
ACTION: none

2. dbus-broker — login stuck when changing users repeatedly (log out,
log in a different one) — ON_QA
ACTION: QA to test if FEDORA-2020-5b486e191b improves the behavior

3. libpreport — bugs can't be reported: "No matching actions found for
this event" — VERIFIED
ACTION: none

4. abrt — Can't report a crash (even with local processing) due to
"Could not resolve host: retrace.fedoraproject.org" — NEW
ACTION: abrt maintainers to diagnose and fix issue
ACTION: msuchy to finish bringing retrace server back online

Proposed blockers
-

1. anaconda — a metalink repository can't be added using UI — ON_QA
ACTION: QA to verify FEDORA-2020-e1d834c1ef fixes the issue

2. NetworkManager — systemd-resolved.service not work with DNS server
placed behind VPN (openconnect) — NEW
ACTION: NetworkManager maintainers to determine future behavior of
default routes when VPN server pushes some routes

3. pki-core — Running ipa-server-install fails in step [1/30]:
configuring certificate server instance — ON_QA
ACTION: reporter to verify that this is happening in F33

Bug-by-bug detail
=

Accepted blockers
-
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — VERIFIED
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33

This appears to be fixed with FEDORA-2020-444a3363f0, which causes BZ
1878317. That may block getting this fix in.

2. dbus-broker — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — ON_QA
login stuck when changing users repeatedly (log out, log in a different one)

User processes linger after logout which blocks logging in when
another user has logged in between the two sessions. Or when the
second user logs back in. Or when a single user logs in repeatedly. An
update to kf5-baloo (FEDORA-2020-5b486e191b) address part of the
issue, but it's likely that this is a many-fix problem.

3. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1873029 — VERIFIED
bugs can't be reported: "No matching actions found for this event"

This appears to be fixed with FEDORA-2020-444a3363f0, which causes BZ
1878317. That may block getting this fix in.

4. abrt  https://bugzilla.redhat.com/show_bug.cgi?id=1878317 — NEW
Can't report a crash (even with local processing) due to "Could not
resolve host: retrace.fedoraproject.org"

Since the retrace server is still offline, abrt should fall back to
local processing. It does not. As an unprivileged user, skipping the
report_uReport step results in chmod errors and behavior like BZ
1873029. As root, it core dumps. We're in general agreement that if
either online or local processing works, that's good enough for beta.
Ticket for retrace server is
https://pagure.io/fedora-infrastructure/issue/9060

Proposed blockers
-

1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=1879127 — ON_QA
a metalink repository can't be added using UI

Adding a metalink repository to the installer incorrectly modifies the
URL. FEDORA-2020-e1d834c1ef contains a potential fix (Adam has a ISO
at 
https://www.happyassassin.net/temp/00669088-FEDORA-2020-e1d834c1ef-netinst-x86_64.iso).
This bug is accepted as a freeze exception even if it doesn't get
enough votes for blocker status.

2. NetworkManager — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
(openconnect)

The scope of this bug has narrowed to the point where a revote
indicates it's probably no longer a blocker. We may consider using
only the static "Use this connection..." property instead of that
*and* pushed routes to determine if the VPN is full-tunnel. Currently
if the server pushed any routes, the openconnect plugin tells
NetworkManager not to add a default route.

3. pki-core — https://bugzilla.redhat.com/show_bug.cgi?id=1878616 — ON_QA
Running ipa-server-install fails in step [1/30]: configuring
certificate server instance

Installation fails in Rawhide (only?). The package updates that appear
to be causing the problem never made it into F33.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FedoraRespin-32-updates-20200918.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce live x86_64

Failed openQA tests: 2/37 (x86_64)

ID: 670965  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/670965
ID: 670992  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/670992

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

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

Passed openQA tests: 33/37 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 blocker status

[Adam Williamson]

On Fri, 2020-09-18 at 16:10 -0400, Ben Cotton wrote:
> 4. abrt  https://bugzilla.redhat.com/show_bug.cgi?id=1878317 — NEW
> Can't report a crash (even with local processing) due to "Could not
> resolve host: retrace.fedoraproject.org"
> 
> Since the retrace server is still offline, abrt should fall back to
> local processing. It does not.

This is not quite an accurate description. If you get to the actual
backtrace generation action, fallback from the remote server to local
processing *does* work. The problem is that report_uReport tries to run
*before you ever reach that stage*, and report_uReport can only work if
retrace.fedoraproject.org is up and accepting reports. There's no
fallback for report_uReport.

Arguably, it failing should be non-fatal, but it seems like it's fatal.

>  As an unprivileged user, skipping the
> report_uReport step results in chmod errors and behavior like BZ
> 1873029. As root, it core dumps.

For me, anyway. Would be good if others could confirm.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora EOL wrt new dist-git branches (and my confusion)

[Miro Hrončok]

Hello,

As many of you know, Fedora has an EOL policy that roughly tl;drs to:

"Fedora N goes to End of Life 4 weeks after Fedora N+2 Final Release (GA)."

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle

The document also says:

> Branches for new packages in the SCM are not allowed for distribution X after
> the Fedora X+2 release and new builds are no longer allowed.

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL.29

I've recently discovered that for 10+ years, this was interpreted as:

 1. at release of Fedora N+2, new dist-git branches for N are no longer allowed
 2. 4 weeks later, Fedora N is EOL

https://pagure.io/releng/issue/9759#comment-687136

When I was told this, I found it very surprising. Mostly because we usually only 
ever announce the actual EOL deadline and I've never seen an announcement that 
says: "From now on, no new packages for Fedora N are possible."


But also because it doesn't really make sense to me. I can imagine a case when a 
bug in Fedora N can be fixed by adding a new package (for example when we 
accidentally introduce a new dependency) and I don't understand why this should 
not be possible between Fedora N+2 release and Fedora N EOL. Understandably many 
packagers might decide to WONTFIX at that point ("It's going EOL in couple weeks 
anyway"), but if they choose to fix, we should allow them to do so.


Similarly, before Fedora N  is EOL, it is considered supported, and a need to 
introduce a new package to a supported Fedora version IMHO is valid, regardless 
of the approaching EOL.


So, my question is: Should we fix the document to describe the long standing 
practice more understandably, or should we change the practice to allow new 
dist-git branches until the actual EOL?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: btrfs and default page sizes (4k vs 64k)

[David Howells]

Neal Gompa  wrote:

> This didn't become a serious problem until Red Hat made the
> unfortunate (though not realized at the time) mistake of switching to
> 64k pages for ARM and POWER. We got that change in Fedora for POWER
> but not ARM. It has led to all kinds of unfortunate problems that are
> gradually being worked on and fixed upstream.

There have been arches in the kernel that didn't support a 4K page size.  FRV,
for example, only supported 16K pages.  I don't know if any of the
"non-regular" arches still in the kernel have similar constraints.

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

Re: Fedora EOL wrt new dist-git branches (and my confusion)

[Ben Cotton]

On Fri, Sep 18, 2020, 17:03 Miro Hrončok  wrote:

>
> So, my question is: Should we fix the document to describe the long
> standing
> practice more understandably, or should we change the practice to allow
> new
> dist-git branches until the actual EOL?
>

I'm in favor of allowing new branches until the actual EOL, with the
expectation that it will be a pretty rare occurrence. We shouldn't preclude
ourselves from providing support to a supported release.

If it turns out to be an undue burden, we should adjust the
policy accordingly.

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

Re: jbig2dec 0.19

[Michael J Gruber]

Please build in the side-tag to pick up the new jbig2dec/mupdf:

fedpkg build --target=f34-build-side-30401

I guess we need to coordinate how far this gets merged down (f33, f32).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kubernetes Development SIG

[Jorge Gallegos]

Count me in :)

On Tue, Sep 15, 2020 at 10:45:07AM -0300, Leonardo Rossetti wrote:
> Hello all,
> 
> I would like to present a Kubernetes Development SIG.
> 
> I initially thought of an "operator SIG" but I think a wider SIG about
> programming components and services with Kubernetes APIs and internal
> components made more sense (inspired by the "Programming Kubernetes" book).
> 
> I am using some of the fields/titles described in this document [1] as the
> proposal template.
> 
> Proposal Name
> 
> 
> SIG: Kubernetes Development
> 
> Summary
> ===
> 
> A SIG for people interested in using, developing, extending kubernetes for
> Fedora components and services.
> 
> Owner
> =
> 
> Name: Leonardo Rossetti (lrossett)
> Email: lross...@redhat.com
> 
> Benefit to Fedora
> =
> 
> Development Experience and Learning
> 
> 
> A place to exchange and discuss kubernetes development design and patterns.
> 
> Extending kubernetes is not that straightforward so this SIG would be a
> good place to learn more about it.
> 
> Kubernetes can be extended in the following areas:
> 
> * Kubectl Plugins
> * Custom API Servers
> * Custom Controllers / Operators
> 
> Operator Development
> ---
> 
> The Operator SDK [3] is the shining new framework when developing custom
> kubernetes controllers nas has become a popular tool for packaging and
> deploying applications in kubernetes.
> 
> Some Fedora services and components could leverage the usage of an operator
> (as we are doing with MBBOX [2]) but other services could be deployed via
> operators as well and even the mbbox operator could be split into smaller
> operators.
> 
> Kubernetes DevOps
> ---
> 
> The SIG could also be a place for sysadmins and ops engineers to discuss
> the challenges, practices and tooling of monitoring, deploying and running
> operators, api servers and other related kubernetes components in
> production.
> 
> [1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
> [2] - https://github.com/fedora-infra/mbbox
> [3] - https://github.com/operator-framework/operator-sdk
> 
> -- 
> 
> Leonardo Rossetti
> 
> Senior Software Engineer,
> 
> Red Hat 
> 
> lross...@redhat.com
> 

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


-- 
"So, will the Andover party have a cash bar?"
"No, there's free beer."
"Uh-oh, Stallman's gonna be pissed..."
-- overheard at the Bazaar, 1999


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

[Test-Announce] Proposal to CANCEL: 2020-09-21 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
have much for the agenda, and I actually won't be available to run the
meeting either. If there is a desire to have the meeting, someone else
can volunteer to run it :)

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] 2020-09-21 @ 16:00 UTC - Fedora 33 Blocker Review Meeting

[Adam Williamson]

# F33 Blocker Review meeting
# Date: 2020-09-21
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 4 proposed Beta blockers, 4 proposed Beta freeze
exceptions and 3 proposed Final blockers to review, so we'll have a
Fedora 33 blocker review meeting on Monday. Unfortunately I'm not going
to be around to run it, but fortunately Ben Cotton has stepped up to do
it. Thanks Ben!

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

** NEW ** - you can also now vote on bugs outside of review meetings!
For the Fedora 33 cycle we enabled a new voting system and have been
using it pretty heavily. If you look at the bug list in the blockerbugs
app, you'll see links labeled "Vote!" next to all proposed blockers and
freeze exceptions. Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet.

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F33 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kubernetes Development SIG

[Vipul Siddharth]

On Tue, Sep 15, 2020 at 8:26 PM Sumantro Mukherjee 
wrote:

>
>
> On Tue, Sep 15, 2020 at 7:15 PM Leonardo Rossetti 
> wrote:
>
>> Hello all,
>>
>> I would like to present a Kubernetes Development SIG.
>>
>> Love the Idea, Leo!
count me in :)

-- 
Vipul Siddharth
He/His/Him
Fedora | CentOS CI Infrastructure Team @ Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org