Re: Packaging question: Rebuild initramfs after adding to dracut.conf.d

[Qiyu Yan]

Eric Edens via devel  于 2021年2月4日周四
上午10:54写道：

> I'm working on a package that adds a configuration to dracut.conf.d. [1]
> To rebuild initramfs, upstream's spec file calls `dracut --force` in
> `%post` . [2]
>
> Questions:
> - Is it recommended that the RPM updates initramfs?

- If so, what's the recommended method?
>
I think this should be taken care of by kernel package via
%transfiletriggerin and transfiletriggerpostun, since there can be multiple
initramfs to be updated.

>
> As background, the RPM will be used in the Google Cloud kickstart [3]
> during image creation, but it will also be used to allow users to import
> existing installations to run on Google Cloud.
>
> What I've done so far:
> - Read through https://docs.fedoraproject.org/en-US/packaging-guidelines/
> - Search for example usages of `dracut`, `new-kernel-pkg`, and
> `installkernel` in http://src.fedoraproject.org/
>
> 1.
> https://github.com/GoogleCloudPlatform/guest-configs/blob/master/src/etc/dracut.conf.d/gce.conf
> 2.
> https://github.com/GoogleCloudPlatform/guest-configs/blob/master/packaging/google-compute-engine.spec#L82
> 3.
> https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base-gcp.ks
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

[Bug 1919731] Please build perl-XML-Stream for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2021-c5324b6008 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c5324b6008

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Kevin Kofler via devel]

Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
>> But it means that provenpackagers who want to bump and rebuild have to
>> actually manually look at another branch (rawhide-build).
> 
> No, why would they need to do that?

Because the whole point of the thread is that they need to bump and rebuild 
from a state that already builds. Otherwise, why would we add the CI to 
begin with?

> The question aside, they wouldn't be allowed to do that, anyway.

Surely they would be allowed to LOOK at the branch, and hopefully also to 
check it out (read only), otherwise why create that branch to begin with?

> The idea is that only CI can push there once there's a successful build
> from rawhide branch.

And that is exactly what makes the whole idea worthless. Provenpackagers 
need to bump the branch that actually builds and then push that to rawhide. 
This only works in a useful way if the branch that actually builds IS 
rawhide.

>> Plus, they will then need to revert rawhide to rawhide-build,
> 
> Again, why?

Because, by definition, rawhide-build compiles and rawhide might not.

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

Re: Reproducible builds

[Neal Gompa]

On Wed, Feb 3, 2021 at 4:51 PM Frédéric Pierret
 wrote:
>
> Hi,
>
> As discussed few weeks ago, I'm working on reproducible builds for Fedora. 
> I've submitted a request for review for new packages: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1924918. Notably, reprotest is a 
> striking tool to test reproduciblity by changing multiples build factors 
> (time, user, lang, etc.) and highlight differences (if exists) with 
> diffoscope (see https://salsa.debian.org/reproducible-builds/reprotest).
>
> On the same topic, I'm developing rpmreproduce (see 
> https://github.com/fepitre/rpmreproduce) which is very much work in progress. 
> This tool allows to rebuild a RPM with the same environment, packages 
> versions etc. This is in the continuity of a previous attempt 
> https://github.com/kholia/ReproducibleBuilds. Currently, it uses a 
> "buildinfo" file as input (see 
> https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles) but there is not 
> such file in Fedora (yet?). In Qubes OS, we use an original implementation 
> for RPM done at the occasion of Reproducible Builds summit: 
> https://github.com/QubesOS/qubes-builder-rpm/blob/master/scripts/rpmbuildinfo 
> or 
> https://raw.githubusercontent.com/fepitre/rpmreproduce/master/scripts/rpmbuildinfo
>  (latest dev/test version). This tool is in charge to download exact version 
> dependencies as specified in the buildinfo, create a local repository, 
> download the corresponding source RPM and then, rebuild it with mock and only 
> this locally created repository that reflects the original build environment.
>
> I take this opportunity to invite RPM devs to discuss about a possible 
> upstream implementation of buildinfo file format. For example, we could think 
> about having a buildinfo file automatically generated by rpmbuild as dpkg is 
> doing similarly in Debian. I would be happy to do the work for that.
>

The Koji build system already records buildinfo data in a slightly
different form, where build IDs are linked to all the inputs that
constructed the build environment as recorded by Koji itself. This
implicitly includes a definition of all the RPM macros that are inputs
for a build, too.

I would generally expect that information like this at the rpmbuild
level should probably be stored in the Source RPM. Since a Source RPM
is an atomic unit containing a build description and the inputs needed
to make the build work, it would make sense that more comprehensive
build environment data would go there. Source RPMs already contain
some rudimentary stuff, like the compiler build flags set in the build
environment during the package build time. It would make sense to
expand this to cover all inputs traditionally covered by the buildinfo
file in Debian.



-- 
真実はいつも一つ！/ 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

Packaging question: Rebuild initramfs after adding to dracut.conf.d

[Eric Edens via devel]

I'm working on a package that adds a configuration to dracut.conf.d. [1] To 
rebuild initramfs, upstream's spec file calls `dracut --force` in `%post` . [2]

Questions:
- Is it recommended that the RPM updates initramfs? 
- If so, what's the recommended method?

As background, the RPM will be used in the Google Cloud kickstart [3] during 
image creation, but it will also be used to allow users to import existing 
installations to run on Google Cloud.

What I've done so far:
- Read through https://docs.fedoraproject.org/en-US/packaging-guidelines/
- Search for example usages of `dracut`, `new-kernel-pkg`, and `installkernel` 
in http://src.fedoraproject.org/ 

1. 
https://github.com/GoogleCloudPlatform/guest-configs/blob/master/src/etc/dracut.conf.d/gce.conf
2. 
https://github.com/GoogleCloudPlatform/guest-configs/blob/master/packaging/google-compute-engine.spec#L82
3. https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base-gcp.ks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f1768ebc94   
opensmtpd-6.8.0p2-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e06cd0281c   
zabbix30-3.0.31-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e30a25d6d0   
chromium-88.0.4324.96-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4e3398c399   
libssh-0.7.7-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c09d7045f3   
seamonkey-2.53.6-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ba217a684f   
monitorix-3.13.1-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5ecfbfc6f6   
pngcheck-2.4.0-7.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6eebad70ee   
SDL2-2.0.14-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

python-oletools-0.56-3.el7
python-termcolor-1.1.0-24.el7
remmina-1.4.11-1.el7
tldr-1.2.0-3.el7

Details about builds:



 python-oletools-0.56-3.el7 (FEDORA-EPEL-2021-6531233d59)
 Tools to analyze Microsoft OLE2 files

Update Information:

- Weak Python 2.7 pyparsing requirement for EPEL 7 correctly - Add simple self-
test mechanism to detect future weaking mistakes

ChangeLog:

* Tue Feb  2 2021 Robert Scheck  - 0.56-3
- Weak Python 2.7 pyparsing requirement for EPEL 7 correctly
- Add simple self-test mechanism to detect future weaking mistakes
* Wed Jan 27 2021 Fedora Release Engineering  - 0.56-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild




 python-termcolor-1.1.0-24.el7 (FEDORA-EPEL-2021-b9e7c225f8)
 ANSI Color formatting for output in terminal

Update Information:

tldr and dependency python-termcolor for epel7

ChangeLog:


References:

  [ 1 ] Bug #1923250 - Request for Epel build
https://bugzilla.redhat.com/show_bug.cgi?id=1923250




 remmina-1.4.11-1.el7 (FEDORA-EPEL-2021-b0484adca5)
 Remote Desktop Client

Update Information:

Update to bugfix release 1.4.11:
https://gitlab.com/Remmina/Remmina/-/releases#v1.4.11

ChangeLog:

* Wed Feb  3 2021 Simone Caronni  - 1.4.11-1
- Update to 1.4.11.
* Wed Jan 27 2021 Fedora Release Engineering  - 
1.4.10-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1914503 - [abrt] remmina: Stream_Write_UINT32(): remmina killed by 
SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1914503




 tldr-1.2.0-3.el7 (FEDORA-EPEL-2021-b9e7c225f8)
 Simplified and community-driven man pages

Update Information:

tldr and dependency python-termcolor for epel7

ChangeLog:


References:

  [ 1 ] Bug #1923250 - Request for Epel build
https://bugzilla.redhat.com/show_bug.cgi?id=1923250


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

[Bug 1920120] perl-DateTime-TimeZone-2.47 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-TimeZone-2.47 |perl-DateTime-TimeZone-2.47
   |-1.fc34 |-1.fc34
   ||perl-DateTime-TimeZone-2.47
   ||-1.fc32
 Resolution|--- |ERRATA
Last Closed||2021-02-04 01:56:52



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-b079dc7e0c has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1916153] [RFE][EPEL8] Please build perl-IO-Capture for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-IO-Capture-0.05-34.el8
 Resolution|--- |ERRATA
Last Closed||2021-02-04 01:56:49



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2021-e18e35f006 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1924375] perl-JavaScript-Minifier-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-c3904984c0 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-c3904984c0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c3904984c0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1919731] Please build perl-XML-Stream for EPEL 8

[bugzilla]

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

Robert Scheck  changed:

   What|Removed |Added

 Depends On||1924943





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1924943
[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

Re: src.fedoraproject.org branch conversion status

[Tim Landscheidt]

Todd Zullinger  wrote:

> […]

> In case it's helpful (and not better documented elsewhere),
> it's possible to rename your existing local master branch to
> rawhide and adjust the upstream tracking branch.

> In a typical dist-git clone from the rpms tree, you'd do
> this:

> git fetch && git branch -m master rawhide && git branch -u origin/rawhide 
> rawhide

> The -u option is the short form of --set-upstream-to.

> That should make the switch relatively simple for folks, I
> hope.  It's easier than making a fresh clone, for me.

For simple cases, "git checkout rawhide && git branch -d
master" should also work.

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8

[bugzilla]

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

Robert Scheck  changed:

   What|Removed |Added

 Blocks|1919730 |1919731





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1919730
[Bug 1919730] Please build perl-Net-XMPP for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1919731
[Bug 1919731] Please build perl-XML-Stream for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1919730] Please build perl-Net-XMPP for EPEL 8

[bugzilla]

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

Robert Scheck  changed:

   What|Removed |Added

 Depends On|1924943 |





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1924943
[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1919730] Please build perl-Net-XMPP for EPEL 8

[bugzilla]

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

Robert Scheck  changed:

   What|Removed |Added

 Depends On||1924943





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1924943
[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8

[bugzilla]

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

Robert Scheck  changed:

   What|Removed |Added

 Blocks||1919730
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1919730
[Bug 1919730] Please build perl-Net-XMPP for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[Bug 1924943] New: Please build perl-HTTP-ProxyAutoConfig for EPEL 8

[bugzilla]

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

Bug ID: 1924943
   Summary: Please build perl-HTTP-ProxyAutoConfig for EPEL 8
   Product: Fedora EPEL
   Version: epel8
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-HTTP-ProxyAutoConfig
  Severity: medium
  Assignee: xav...@bachelot.org
  Reporter: redhat-bugzi...@linuxnetz.de
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-HTTP-ProxyAutoConfig for EPEL 8. It's a build- and run-time
dependency of perl-XML-Stream.

Version-Release number of selected component (if applicable):
perl-HTTP-ProxyAutoConfig-0.3-25.fc34

Actual results:
No perl-HTTP-ProxyAutoConfig in EPEL 8.

Expected results:
perl-HTTP-ProxyAutoConfig-0.3-25.el8 - or better ;-)

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
8 branch.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

Re: the-new-hotness is broken?

[Kevin Fenzi]

On Wed, Feb 03, 2021 at 05:41:27PM -0500, Elliott Sales de Andrade wrote:
> I just received 3 notifications that
> 
> > the-new-hotness saw an update for , but pkgdb says the maintainers 
> > are not interested in bugs being filed
> 
> but all packages have monitoring enabled.
> 
> Did something break with it? Maybe the branch name changes?

Indeed it did. Filed: 
https://github.com/fedora-infra/the-new-hotness/issues/318

on it. 

Looks like it looks for a 'master' branch to tell if a package is
retired or not. ;( 

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: src.fedoraproject.org branch conversion status

[Todd Zullinger]

[re-sending to devel instead of devel-announce, apologies if
this arrives twice.]

Kevin Fenzi wrote:
> Greetings everyone and thanks for your patience with us today.

Thank you Kevin and all the folks who help make such changes
happen relatively seamlessly. :)

> You will want to re-clone any repos you have that have changed, or pull
> changes and switch to the new branch.

In case it's helpful (and not better documented elsewhere),
it's possible to rename your existing local master branch to
rawhide and adjust the upstream tracking branch.

In a typical dist-git clone from the rpms tree, you'd do
this:

git fetch && git branch -m master rawhide && git branch -u origin/rawhide 
rawhide

The -u option is the short form of --set-upstream-to.

That should make the switch relatively simple for folks, I
hope.  It's easier than making a fresh clone, for me.

-- 
Todd
~
The surest sign that intelligent life exists elsewhere in the universe
is that it has never tried to contact us.
-- Bill Watterson (Calvin and Hobbes)


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: Reproducible builds

[Kevin Fenzi]

On Wed, Feb 03, 2021 at 10:50:43PM +0100, Frédéric Pierret wrote:
> Hi,
> 
> As discussed few weeks ago, I'm working on reproducible builds for Fedora. 
...snip...

I'll try and take a look at the tools mentioned when I get a chance, but
I wanted to just thank you for working on this. :) 

So, thanks!

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

the-new-hotness is broken?

[Elliott Sales de Andrade]

I just received 3 notifications that

> the-new-hotness saw an update for , but pkgdb says the maintainers 
> are not interested in bugs being filed

but all packages have monitoring enabled.

Did something break with it? Maybe the branch name changes?

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

src.fedoraproject.org branch conversion status

[Kevin Fenzi]

Greetings everyone and thanks for your patience with us today. 

Here's the current status of the branch conversion change: 
https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main

By namespace:

rpms: complete. 'rawhide' is now the default branch and
there's also a symref to 'main'. 

flatpaks: complete. 'stable' is the default/only branch. 

containers: complete. 'rawhide' is default, 'main' is a symref. 

modules: We converted this over, but after consulting with fesco we
backed it out. modules with 'master' branches should still have them,
net effect here should be 0. 

tests: We converted this to use 'rawhide' and a 'main' symref, but this
was probibly not desired, so we are consulting with fesco/test
maintainers on the desired state. Will update it in the next day or so
to the desired state. 

You will want to re-clone any repos you have that have changed, or pull
changes and switch to the new branch. 

If you run into any issues, please file a ticket:
https://pagure.io/fedora-infrastructure/new_issue

Thanks, 

kevin


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

src.fedoraproject.org branch conversion status

[Kevin Fenzi]

Greetings everyone and thanks for your patience with us today. 

Here's the current status of the branch conversion change: 
https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main

By namespace:

rpms: complete. 'rawhide' is now the default branch and
there's also a symref to 'main'. 

flatpaks: complete. 'stable' is the default/only branch. 

containers: complete. 'rawhide' is default, 'main' is a symref. 

modules: We converted this over, but after consulting with fesco we
backed it out. modules with 'master' branches should still have them,
net effect here should be 0. 

tests: We converted this to use 'rawhide' and a 'main' symref, but this
was probibly not desired, so we are consulting with fesco/test
maintainers on the desired state. Will update it in the next day or so
to the desired state. 

You will want to re-clone any repos you have that have changed, or pull
changes and switch to the new branch. 

If you run into any issues, please file a ticket:
https://pagure.io/fedora-infrastructure/new_issue

Thanks, 

kevin


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

Reproducible builds

[Frédéric Pierret]

Hi,

As discussed few weeks ago, I'm working on reproducible builds for Fedora. I've 
submitted a request for review for new packages: 
https://bugzilla.redhat.com/show_bug.cgi?id=1924918. Notably, reprotest is a 
striking tool to test reproduciblity by changing multiples build factors (time, 
user, lang, etc.) and highlight differences (if exists) with diffoscope (see 
https://salsa.debian.org/reproducible-builds/reprotest).

On the same topic, I'm developing rpmreproduce (see 
https://github.com/fepitre/rpmreproduce) which is very much work in progress. This tool 
allows to rebuild a RPM with the same environment, packages versions etc. This is in the 
continuity of a previous attempt https://github.com/kholia/ReproducibleBuilds. Currently, 
it uses a "buildinfo" file as input (see 
https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles) but there is not such file in 
Fedora (yet?). In Qubes OS, we use an original implementation for RPM done at the 
occasion of Reproducible Builds summit: 
https://github.com/QubesOS/qubes-builder-rpm/blob/master/scripts/rpmbuildinfo or 
https://raw.githubusercontent.com/fepitre/rpmreproduce/master/scripts/rpmbuildinfo 
(latest dev/test version). This tool is in charge to download exact version dependencies 
as specified in the buildinfo, create a local repository, download the corresponding 
source RPM and then, rebuild it with mock and only this locally created repository that 
reflects the original build environment.

I take this opportunity to invite RPM devs to discuss about a possible upstream 
implementation of buildinfo file format. For example, we could think about 
having a buildinfo file automatically generated by rpmbuild as dpkg is doing 
similarly in Debian. I would be happy to do the work for that.

Best regards,
Frédéric



OpenPGP_signature
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: newRepo taking a while this morning ...

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 03, 2021 at 11:56:50AM -0800, Kevin Fenzi wrote:
> On Wed, Feb 03, 2021 at 11:01:50AM +, Richard W.M. Jones wrote:
> > 
> > And in possibly related news, there seem to be a lot of side tags in 
> > Rawhide:
> > 
> >   $ koji list-tags | grep f34-build-side | wc -l
> >   145
> 
> Yeah, there sure are. ;( 
> 
> our monitor-gating script seems to leak them sometimes. ;( 
> I have cleaned all those up and we are down now to: 
> 
> ➜  ~ koji list-tags | grep f34-build-side | wc -l
> 114
> 
> I think we likely should put a timelimit on them. 
> I hate to do that, but I think we will need to. 
> 
> Look at all the > 200 day ones:
> 
> [old] f33-build-side-24903 (217 days, 13:50:54.931504)
>
> [old] f33-build-side-24835 (221 days, 16:09:22.895722)
>
> [old] f33-build-side-24603 (230 days, 16:20:56.654337)
>
> [old] f33-build-side-24795 (223 days, 6:18:59.621627)
> [old] f32-build-side-24797 (223 days, 5:07:06.514186)
> [old] f33-build-side-23996 (251 days, 16:01:43.714678)
>
> [old] f32-build-side-24456 (237 days, 23:26:28.711887)
>
> [old] f33-build-side-24671 (228 days, 22:08:52.637569)
>
> [old] f32-build-side-24639 (230 days, 4:08:59.236130)
> [old] f33-build-side-25147 (210 days, 5:01:29.497469)
> [old] f33-build-side-25167 (209 days, 8:27:58.035678)
> 
> (granted those are f32/f33). 
> 
> Would 30 days be workable? 

+1

> There's 117 of those, out of a total of 182.

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: newRepo taking a while this morning ...

[Kevin Fenzi]

On Wed, Feb 03, 2021 at 11:01:50AM +, Richard W.M. Jones wrote:
> 
> And in possibly related news, there seem to be a lot of side tags in Rawhide:
> 
>   $ koji list-tags | grep f34-build-side | wc -l
>   145

Yeah, there sure are. ;( 

our monitor-gating script seems to leak them sometimes. ;( 
I have cleaned all those up and we are down now to: 

➜  ~ koji list-tags | grep f34-build-side | wc -l
114

I think we likely should put a timelimit on them. 
I hate to do that, but I think we will need to. 

Look at all the > 200 day ones:

[old] f33-build-side-24903 (217 days, 13:50:54.931504)  
 
[old] f33-build-side-24835 (221 days, 16:09:22.895722)  
 
[old] f33-build-side-24603 (230 days, 16:20:56.654337)  
 
[old] f33-build-side-24795 (223 days, 6:18:59.621627)
[old] f32-build-side-24797 (223 days, 5:07:06.514186)
[old] f33-build-side-23996 (251 days, 16:01:43.714678)  
 
[old] f32-build-side-24456 (237 days, 23:26:28.711887)  
 
[old] f33-build-side-24671 (228 days, 22:08:52.637569)  
 
[old] f32-build-side-24639 (230 days, 4:08:59.236130)
[old] f33-build-side-25147 (210 days, 5:01:29.497469)
[old] f33-build-side-25167 (209 days, 8:27:58.035678)

(granted those are f32/f33). 

Would 30 days be workable? 
There's 117 of those, out of a total of 182.

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: Ars claims: Fedora 32 is sluggish

[Matthew Miller]

On Wed, Feb 03, 2021 at 10:53:32AM -0600, Michael Catanzaro wrote:
> Has anybody investigated Jim Salter's claims that Fedora 32 is slow
> to launch applications? Recent article:
> 
> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/
> 
> "in my experience, Fedora 32 is noticeably, demonstrably more
> sluggish to launch applications than Ubuntu is in general."

I genuinely wonder if this is due to the launch animation. I know that
subjectively for myself using the Impatience to triple the speed makes my
desktop feel more snappy.


-- 
Matthew Miller

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

Re: Boost 1.75.0 in rawhide, with soname change

[Michel Alexandre Salim]

On Wed, 2021-02-03 at 12:54 +, Jonathan Wakely wrote:
> On 29/01/21 10:06 -0800, Michel Alexandre Salim wrote:
> > On Mon, 2021-01-25 at 10:00 +, Jonathan Wakely wrote:
> > > Tom Rodgers completed the Boost 1.75.0 build for the change
> > > https://fedoraproject.org/wiki/Changes/F34Boost175
> > > and I've rebuilt most of the packages that depend on it.
> > > 
> > Some of the packages depending on Folly didn't get rebuilt, but
> > that's
> > fine, I've done an update that got all of them.
> 
> Sorry about that. Which ones?
> 
No worries!

> I rebuilt fb303, fbthrift and fbzmq, as well as folly itself. Those
> were the only ones I saw that actually depend on libboost_*.so
> libraries.
> 
> It's possible that other packages which only consume boost headers
> should be rebuilt (if they use a library like Folly that uses Boost
> types in its API) but rebuilding those packages is not typically done
> as part of a rebuild for a Boost update.
> 
> The list of packages that I attempted to rebuild is found using the
> first repoquery command at
> https://fedoraproject.org/wiki/Changes/F34Boost175#Dependencies
> 
> I see that fizz, wangle and watchman depend on Folly, but none of
> them
> has any declared dependency on Boost that I can see.
> 
An upcoming package that dcavalca is working on, mcrouter, failed to
build as such:
https://koji.fedoraproject.org/koji/taskinfo?taskID=60421150

Actually, looking at the logs, it's weird, looks like Boost 1.75 was
not available at the time the build was attempted?

https://kojipkgs.fedoraproject.org//work/tasks/1238/60421238/root.log

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: Ars claims: Fedora 32 is sluggish

[Stephen John Smoogen]

On Wed, 3 Feb 2021 at 14:13, Artem Tim  wrote:

> I did my own various tests on Ryzen (Zen 2) 4 month ago or so on Fedora
> 32/33 vs Clear Linux which known to be "fastest" distro and in almost all
> benchmarks Fedora was equal or even faster a little bit then Clear Linux.
> In rare cases Clear Linux was faster within the margin of error. Have no
> idea what they mean by "sluggish".
>

Sluggish can mean all kinds of things to different people so it is not a
useful metric term. Network latency, disk drive latency, and startup times
are the usual culprits. However other items like background colour and
font look and feel can give people the feeling something is 'sluggish' or
'slower' versus another system because a mouse will 'feel' like its slower
than in another due to human brain wiring than actual facts. As such, I
would just take it as a figure of speech which would need careful testing
to see what was going on before seeing what might be the cause.



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


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

Re: Ars claims: Fedora 32 is sluggish

[Artem Tim]

I did my own various tests on Ryzen (Zen 2) 4 month ago or so on Fedora 32/33 
vs Clear Linux which known to be "fastest" distro and in almost all benchmarks 
Fedora was equal or even faster a little bit then Clear Linux. In rare cases 
Clear Linux was faster within the margin of error. Have no idea what they mean 
by "sluggish".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ars claims: Fedora 32 is sluggish

[Fabio Valentini]

On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  wrote:
>
> Hi,
>
> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to
> launch applications? Recent article:
>
> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/
>
> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish
> to launch applications than Ubuntu is in general."
>
> Original article:
>
> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/
>
> Would be good to know, for starters, whether this difference is real
> and measurable.

I don't know if this helps as a data point, but until 32, Fedora
always "won" one of the bottom spots in Phronix distro comiparison
benchmarks.

However, starting with Fedora 33, at least on some hardware, we now
outperform Ubuntu 20.20, Manjaro, and even Clear Linux - at least on
average:
https://www.phoronix.com/scan.php?page=article=fedora-wins-tgl

Maybe I can provide some anecdata: In my experience, Ubuntu based VMs
always felt way more responsive and faster than Fedora based VMs (I
use them regularly to do QA for my Pantheon packages, since Fedora 2x
or so.) But today, cold booting a Fedora 33 or 34 VM is more than
twice as fast (~25s) compared to an Ubuntu based (elementary OS 5 /
ubuntu 18.04.x LTS) VM (~68s), and when launching Firefox after a cold
boot, Fedora 33 was almost exacty twice as fast (~25s vs. ~50s),
again. For both of those "tests", Fedora 32 was a bit slower than
either newer Fedora or elementary OS.

Even if those are not "scientific" measurements, I did not expect the
differences to be this big, but apparently, we're doing something
right. :)
Maybe switching on LTO by default did help - it was introduced with Fedora 33.

The "Fedora is slow and sluggish" review you linked specifically
mentions Fedora 32.
Apparently the author has not tried Fedora since (there's no review of
Fedora 33 on Ars Technica).
And I would be curious to see whether upgrading to Fedora 33 would
affect the result of the "launch Chromium snap" test in our favor ;)

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

Re: Ars claims: Fedora 32 is sluggish

[Nathanael D. Noblet]

On Wed, 2021-02-03 at 10:53 -0600, Michael Catanzaro wrote:
> Hi,
> 
> Has anybody investigated Jim Salter's claims that Fedora 32 is slow
> to 
> launch applications? Recent article:
> 
> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/
> 
> "in my experience, Fedora 32 is noticeably, demonstrably more
> sluggish 
> to launch applications than Ubuntu is in general."
> 
> Original article:
> 
> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/
> 
> Would be good to know, for starters, whether this difference is real 
> and measurable.

I haven't used Ubuntu in a long time. However I do know that I remember
creating Ubuntu VM a few years ago and was blown away at how fast it
went from grub to a desktop login compared to Fedora. Other than that
Fedora seems fast enough to me. Just a single datapoint...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Kevin Fenzi]

I filed: 

https://pagure.io/fesco/issue/2573

about this. 

We can revert what we need to, and sorry for the hassle again. 

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

[Bug 1924375] perl-JavaScript-Minifier-1.15 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-c3904984c0 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c3904984c0


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

Re: Jami (formerly Ring) P2P softphone packaging?

[Eike Rathke]

Hi,

On Wednesday, 2021-02-03 14:32:53 +0100, Kevin Kofler via devel wrote:

> But Jami itself depends on FFmpeg.

And I rather use a build from upstream repo with rpmfusion ffmpeg than
I'd be using a crippled build that ripped out ffmpeg.

https://jami.net/download-jami-linux/#open-modal-fedora-32
https://dl.jami.net/ring-nightly/fedora_33/ring-nightly.repo

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Kevin Fenzi]

On Wed, Feb 03, 2021 at 06:03:30PM +0100, Fabio Valentini wrote:
> 
> Note that the text on the Change page does not reflect what was
> actually approved by FESCo:
> https://pagure.io/fesco/issue/2519#comment-706518
> 
> For reference: Approve Change proposal to rename branch names from
> "master" to "main", except in dist-git-like repositories with branches
> matching fedora releases, where "rawhide" is preferred. Where the new
> default branch will be "rawhide", create symbolic refs from "main" to
> "rawhide".
> 
> So looking at the modules / tests namespaces (which are definitely not
> dist-git like), something went wrong here.

Well, "dist-git-like repositories with branches matching fedora
releases" wasn't obvious to me. If you didn't want modules or tests
namespaces, it would have been a lot more clear to say "excluding
modules or tests namespaces".

In any case modules did have master branches, and I thought we did want
to change those? for cases where you want to build a stream that has the
latest upstream changes. But you could always have called it main or
rawhide or whatever, but moving it now when we move everything else made
sense to me. 

Anyhow, we will get it sorted out... sorry for the confusion. 

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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Miro Hrončok]

On 03. 02. 21 16:10, Petr Lautrbach wrote:

Now we havehttps://src.fedoraproject.org/tests/selinux/  with default
branch "rawhide". "rawhide" doesn't make sense in this repo as it
contains tests used on all Fedora versions and also downstream Red Hat
Enterprise Linux.


Note that that depends. For some tests repos, they might have different content 
for rawhide and for the released branches, no?


Especially if you do https://pagure.io/fedora-ci/general/issue/106

--
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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Kevin Fenzi]

On Wed, Feb 03, 2021 at 05:50:30PM +0100, Petr Šplíchal wrote:
> On Wed, 3 Feb 2021 at 17:42, Petr Lautrbach  wrote:
> 
> > Petr Lautrbach  writes:
> >
> > > Kevin Fenzi  writes:
> > >
> > >> Greetings everyone.
> > >>
> > >> We finally have everything in place and hopefully tested to make the
> > >> switch tomorrow from master to rawhide/main branches for
> > >> src.fedoraproject.org.
> > >>
> > >> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> > >> will be moving all the branches over to rawhide/main. As soon as all
> > >> packages are done, we will be adjusting pdc/hooks/existing pr's.
> > >>
> > >> We will be sending an additional email once changes are complete and
> > >> hopefully any downtime will be limited.
> > >>
> > >> Once the change is completed you will want to checkout rawhide/main
> > >> instead of master and update/recreate any existing forks you have.
> > >>
> > >> See
> > >> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > >> for more information.
> > >>
> > >
> > > The page says "This Change will move many repositories (see below) to
> > > use a "main" branch as default." and "Not every namespace on dist-git
> > > has a rawhide version. For example: containers do not have/use rawhide.
> > > And having different default branches on different namespaces is not
> > > very appealing."
> > >
> > > Now we have https://src.fedoraproject.org/tests/selinux/ with default
> > > branch "rawhide". "rawhide" doesn't make sense in this repo as it
> > > contains tests used on all Fedora versions and also downstream Red Hat
> > > Enterprise Linux.
> > >
> > > Have I missed something?
> > >
> > > Petr
> >
> > I've tried to change it on my own:
> >
> > 1. create and push new branch "real-main"
> > 2. set "real-main" as default branch
> > 3.
> > ^&^ git push origin :rawhide
> > remote: Branch deletion is not allowed
> > remote: Denied push for ref 'refs/heads/rawhide' for user 'plautrba'
> > remote: All changes have been rejected
> > To ssh://pkgs.fedoraproject.org/tests/selinux.git
> >  ! [remote rejected]   rawhide (pre-receive hook declined)
> > error: failed to push some refs to 'ssh://
> > pkgs.fedoraproject.org/tests/selinux.git'
> >
> > 4. remove alias main -> rawhide at
> > https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab
> >
> > pagure reports: "Alias deleted"
> >
> > 5. refresh the setting page
> >
> > 6. Alias "main" is still there
> > https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab
> >
> > what now? revert changes back to misleading "rawhide"? use "master" as
> > it's directly referenced in tests we use in Red Hat and solve strange
> > default branch name later?
> >
> 
> In addition to fixing the "rawhide" name, would it be possible to provide a
> temporary symlink "master --> main"? At least in the fedora tests
> namespace? As Petr mentioned, we have a bunch of tests which are referenced
> using "master". All those tests are now broken. It would help us a lot if
> there would be a 1-2 month transition period during which both "master" and
> "main" would work until we fix the configs and tools, and get packages
> released. Thanks.
> 
> psss...

Hey, could you wait until we have finished even? 

We can get this sorted out, but everyone trying to push their own fixes
is just going to confuse things. :) 

So, sorry first off that I misread what was agreed to, I thought we
agreed to move everything (except flatpaks). 

So, from this I get that we should move tests from rawhide to 'main'. 

I'd really prefer not to do a master symref, but I suppose we could, as
long as we have a definite deadline to remove it.

I'll look and see if we can get this done. 

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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

[Matthew Almond via devel]

On Mon, 2020-12-21 at 11:28 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW 
> 
> 
> == Summary ==
> 
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
> decompression. RPM Copy on Write uses reflinking capabilities in
> btrfs, which is the default filesystem in Fedora 33.
> 

I've been communicating with the maintainer of RPM on the pull request
and it's become clear that this likely depends on the creation of a
public, supportable API for RPM. This is not achievable within the
window for Fedora 34, so I'm withdrawing the change for Fedora 34 at
this time. I will continue to work on this, and expect to re-submit for
Fedora 35.

Just a reminder for those interested: I'm giving a talk at CentOS Dojo
on this topic on Friday at 17:00 CET[2]

Regards, Matthew.

[1] 
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-772410935
[2] https://hopin.com/events/centos-dojo-fosdem
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F27->F33 + EFI + Xen boot error: "../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found."

[PGNet Dev]

F33 on EFI + Xen delays 30+ seconds, sometimes hangs, on boot @ grub2 error,

...
Loading Xen 4.14.1 ...
error: ../../grub-core/fs/fshelp.c:257:file  
`/EFI/fedora/x86_64-efi/module2.mod' not found.
Loading Linux 5.10.9-201.fc33.x86_64 ...
Loading initial ramdisk ...
error: ../../grub-core/fs/fshelp.c:257:file  
`/EFI/fedora/x86_64-efi/module2.mod' not found.
...

It's been reported/closed/ignored since, at least, F27 ~ 2017,

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

, and still occurs in current F33.

Not clear where the fix _needs_ to be -- grub2 &/or Xen pkgs.  But sed 
workarounds are a non-starter for production.

Can appropriate devs help get this addressed?

If not, that's fine too -- but can we at least get a clear statement that 
Xen@Fedoras's not going to be maintained, so we can make other arrangements?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Fabio Valentini]

On Wed, Feb 3, 2021 at 4:10 PM Petr Lautrbach  wrote:
>
> Kevin Fenzi  writes:
>
> > Greetings everyone.
> >
> > We finally have everything in place and hopefully tested to make the
> > switch tomorrow from master to rawhide/main branches for
> > src.fedoraproject.org.
> >
> > At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> > will be moving all the branches over to rawhide/main. As soon as all
> > packages are done, we will be adjusting pdc/hooks/existing pr's.
> >
> > We will be sending an additional email once changes are complete and
> > hopefully any downtime will be limited.
> >
> > Once the change is completed you will want to checkout rawhide/main
> > instead of master and update/recreate any existing forks you have.
> >
> > See
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > for more information.
> >
>
> The page says "This Change will move many repositories (see below) to
> use a "main" branch as default." and "Not every namespace on dist-git
> has a rawhide version. For example: containers do not have/use rawhide.
> And having different default branches on different namespaces is not
> very appealing."
>
> Now we have https://src.fedoraproject.org/tests/selinux/ with default
> branch "rawhide". "rawhide" doesn't make sense in this repo as it
> contains tests used on all Fedora versions and also downstream Red Hat
> Enterprise Linux.
>
> Have I missed something?

Note that the text on the Change page does not reflect what was
actually approved by FESCo:
https://pagure.io/fesco/issue/2519#comment-706518

For reference: Approve Change proposal to rename branch names from
"master" to "main", except in dist-git-like repositories with branches
matching fedora releases, where "rawhide" is preferred. Where the new
default branch will be "rawhide", create symbolic refs from "main" to
"rawhide".

So looking at the modules / tests namespaces (which are definitely not
dist-git like), something went wrong here.

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

Ars claims: Fedora 32 is sluggish

[Michael Catanzaro]

Hi,

Has anybody investigated Jim Salter's claims that Fedora 32 is slow to 
launch applications? Recent article:


https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/

"in my experience, Fedora 32 is noticeably, demonstrably more sluggish 
to launch applications than Ubuntu is in general."


Original article:

https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/

Would be good to know, for starters, whether this difference is real 
and measurable.


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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Petr Šplíchal]

On Wed, 3 Feb 2021 at 17:42, Petr Lautrbach  wrote:

> Petr Lautrbach  writes:
>
> > Kevin Fenzi  writes:
> >
> >> Greetings everyone.
> >>
> >> We finally have everything in place and hopefully tested to make the
> >> switch tomorrow from master to rawhide/main branches for
> >> src.fedoraproject.org.
> >>
> >> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> >> will be moving all the branches over to rawhide/main. As soon as all
> >> packages are done, we will be adjusting pdc/hooks/existing pr's.
> >>
> >> We will be sending an additional email once changes are complete and
> >> hopefully any downtime will be limited.
> >>
> >> Once the change is completed you will want to checkout rawhide/main
> >> instead of master and update/recreate any existing forks you have.
> >>
> >> See
> >> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >> for more information.
> >>
> >
> > The page says "This Change will move many repositories (see below) to
> > use a "main" branch as default." and "Not every namespace on dist-git
> > has a rawhide version. For example: containers do not have/use rawhide.
> > And having different default branches on different namespaces is not
> > very appealing."
> >
> > Now we have https://src.fedoraproject.org/tests/selinux/ with default
> > branch "rawhide". "rawhide" doesn't make sense in this repo as it
> > contains tests used on all Fedora versions and also downstream Red Hat
> > Enterprise Linux.
> >
> > Have I missed something?
> >
> > Petr
>
> I've tried to change it on my own:
>
> 1. create and push new branch "real-main"
> 2. set "real-main" as default branch
> 3.
> ^&^ git push origin :rawhide
> remote: Branch deletion is not allowed
> remote: Denied push for ref 'refs/heads/rawhide' for user 'plautrba'
> remote: All changes have been rejected
> To ssh://pkgs.fedoraproject.org/tests/selinux.git
>  ! [remote rejected]   rawhide (pre-receive hook declined)
> error: failed to push some refs to 'ssh://
> pkgs.fedoraproject.org/tests/selinux.git'
>
> 4. remove alias main -> rawhide at
> https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab
>
> pagure reports: "Alias deleted"
>
> 5. refresh the setting page
>
> 6. Alias "main" is still there
> https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab
>
> what now? revert changes back to misleading "rawhide"? use "master" as
> it's directly referenced in tests we use in Red Hat and solve strange
> default branch name later?
>

In addition to fixing the "rawhide" name, would it be possible to provide a
temporary symlink "master --> main"? At least in the fedora tests
namespace? As Petr mentioned, we have a bunch of tests which are referenced
using "master". All those tests are now broken. It would help us a lot if
there would be a 1-2 month transition period during which both "master" and
"main" would work until we fix the configs and tools, and get packages
released. Thanks.

psss...

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

[EPEL-devel] Re: EPEL whats version of RHEL will follow

[Troy Dawson]

On Wed, Feb 3, 2021 at 3:16 AM john tatt  wrote:
>
> Hi
> So if I understand well, an EPEL package could be have to be desinstalled 
> just because an update in Stream make it not compatible any more ?
> Strange
>

Yes and no
Yes - If you are running CentOS Stream, and don't have the epel-next
repo enabled.
No - If you are running RHEL, Rocky, Alma, or even CentOS Stream with
epel-next enabled.


>
> Le Mon Feb 01 2021 17:49:41 GMT+0100 (CET), Stephen John Smoogen 
>  a écrit :
>
>
>
>
> On Mon, 1 Feb 2021 at 11:00, Filip Bartmann  wrote:
>
> Hello,
> what version of RedHat will EPEL now follow? Centos Stream or oficial RedHat 
> and Rocky based on stable RHEL?
>
>
>
> The main EPEL packages have always been compiled against the official Red Hat 
> Enterprise Linux current package set. There is an initiative to have a set of 
> packages built against CentOS Stream to deal with .next issues we see when 
> RHEL updates from say 8.3 to 8.4.
>
>
>
>
> Thanks,
> Filip Bartmann
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

This has been fixed in fedpkg-1.40-4.fc33 - great stuff everyone!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

lazarus broken dep?

[Richard Shaw]

cqrlog is failing due to a dep issue with lazarus:

DEBUG util.py:444:  Error:
DEBUG util.py:444:   Problem: conflicting requests
DEBUG util.py:444:- nothing provides qt5pas-devel(x86-64) =
2.6-2001006.fc34 needed by lazarus-2.0.10-6.fc34.x86_64

But the lazarus build should be providing the package for itself...

It looks like a "rightmost" bump occurred just on the qt5pas-devel package?

lazarus-2.0.10-6.fc34.x86_64.rpm (info) (download)
qt5pas-2.6-2001006.*fc34.1.*x86_64.rpm (info) (download)
qt5pas-devel-2.6-2001006.fc34.1.x86_64.rpm (info) (download)
lazarus-debuginfo-2.0.10-6.fc34.x86_64.rpm (info) (download)
lazarus-debugsource-2.0.10-6.fc34.x86_64.rpm (info) (download)
qt5pas-debuginfo-2.6-2001006.fc34.1.x86_64.rpm (info) (download)

Weird.

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

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Petr Lautrbach]

Petr Lautrbach  writes:

> Kevin Fenzi  writes:
>
>> Greetings everyone. 
>>
>> We finally have everything in place and hopefully tested to make the
>> switch tomorrow from master to rawhide/main branches for
>> src.fedoraproject.org. 
>>
>> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
>> will be moving all the branches over to rawhide/main. As soon as all
>> packages are done, we will be adjusting pdc/hooks/existing pr's.
>>
>> We will be sending an additional email once changes are complete and
>> hopefully any downtime will be limited. 
>>
>> Once the change is completed you will want to checkout rawhide/main
>> instead of master and update/recreate any existing forks you have.
>>
>> See
>> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>> for more information. 
>>
>
> The page says "This Change will move many repositories (see below) to
> use a "main" branch as default." and "Not every namespace on dist-git
> has a rawhide version. For example: containers do not have/use rawhide.
> And having different default branches on different namespaces is not
> very appealing."
>
> Now we have https://src.fedoraproject.org/tests/selinux/ with default
> branch "rawhide". "rawhide" doesn't make sense in this repo as it
> contains tests used on all Fedora versions and also downstream Red Hat
> Enterprise Linux.
>
> Have I missed something?
>
> Petr

I've tried to change it on my own:

1. create and push new branch "real-main"
2. set "real-main" as default branch
3.
^&^ git push origin :rawhide   
remote: Branch deletion is not allowed
remote: Denied push for ref 'refs/heads/rawhide' for user 'plautrba'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/tests/selinux.git
 ! [remote rejected]   rawhide (pre-receive hook declined)
error: failed to push some refs to 
'ssh://pkgs.fedoraproject.org/tests/selinux.git'

4. remove alias main -> rawhide at
https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab

pagure reports: "Alias deleted"

5. refresh the setting page

6. Alias "main" is still there
https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab

what now? revert changes back to misleading "rawhide"? use "master" as
it's directly referenced in tests we use in Red Hat and solve strange
default branch name later?


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

[EPEL-devel] Re: EPEL whats version of RHEL will follow

[Matthew Miller]

On Wed, Feb 03, 2021 at 11:14:38AM +, john tatt wrote:
> So if I understand well, an EPEL package could be have to be desinstalled 
> just because an update in Stream make it not compatible any more ?

All changes landing in Stream are already approved to land in a RHEL minor
release. So this is no different from what happens with the status quo when
an update happens in a RHEL minor release which requires an EPEL package
change. 


-- 
Matthew Miller

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

Summary/Minutes from today's FESCo Meeting (2021-02-03) + in-ticket-approvals

[Zbigniew Jędrzejewski-Szmek]

= Meeting =

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-03/fesco.2021-02-03-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-03/fesco.2021-02-03-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-03/fesco.2021-02-03-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:16)

* #2558 F34 Change: Remove Guile Support From Toolchain  (zbyszek,
  15:04:33)
  * AGREED: REJECTED (+4, 2, -2)  (zbyszek, 15:25:55)

Please see the meeting notes for details.


* Next week's chair  (zbyszek, 15:27:37)
  * ACTION: mhroncok will chair the next meeting.  (zbyszek, 15:29:11)

* Open Floor  (zbyszek, 15:29:56)

Meeting ended at 15:51:18 UTC.

Action Items

* mhroncok will chair the next meeting.

People Present (lines said)
---
* King_InuYasha (63)
* zbyszek (50)
* sgallagh (39)
* mhroncok (37)
* nirik (29)
* decathorpe (22)
* zodbot (19)
* dcantrell (5)
* bcotton (4)
* Conan_Kudo (1)
* ignatenkobrain (0)
* Eighth_Doctor (0)
* cverna (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)

= Discussed and Voted in the Ticket =

#2567 F34 Change: Disable Python 2 Dist RPM Generators and Freeze Python 2 
Macros
https://pagure.io/fesco/issue/2567
APPROVED (+3, 0, 0)

#2568 F34 Change: GNOME 40
https://pagure.io/fesco/issue/2568
APPROVED (+5, 0, 0)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: CMake FindBoost module doesn't like boost 1.75

[Ian McInerney]

It looks like upstream CMake hasn't updated the FindBoost.cmake file they
bundle (
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindBoost.cmake#L1604).
I have opened an upstream issue with CMake at
https://gitlab.kitware.com/cmake/cmake/-/issues/21773 since this also
affects some of the projects I develop.

-Ian

On Wed, Feb 3, 2021 at 2:55 PM Richard Shaw  wrote:

> It tends to generate a lot of output around:
>
> CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:1204 (message):
>   New Boost version may have incorrect or missing dependencies and imported
>   targets
>
> Specifically for trying to build FreeCAD it KIND OF finds the libraries:
>
> -- Found Boost: /usr/include (found suitable version "1.75.0", minimum
> required is "1.55") found components: filesystem program_options regex
> system thread chrono date_time atomic
>
> But then later:
>
> CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:1204 (message):
>   New Boost version may have incorrect or missing dependencies and imported
>   targets
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindBoost.cmake:1326
> (_Boost_COMPONENT_DEPENDENCIES)
>   /usr/share/cmake/Modules/FindBoost.cmake:1935
> (_Boost_MISSING_DEPENDENCIES)
>   src/Mod/Path/libarea/CMakeLists.txt:20 (find_package)
> -- Found Boost: /usr/include (found version "1.75.0") found components:
> python39
> -- found Boost: 1_75
> -- boost-incude dirs are: /usr/include
> -- boost-python lib is:
> -- boost_LIBRARY_DIRS is: /usr/lib64
> -- Boost_LIBRARIES is: /usr/lib64/libboost_python39.so
>
> And then freecad (a fork testing vtk9 compatibility) fails with:
>
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::match_results<__gnu_cxx::__normal_iterator std::__cxx11::basic_string,
> std::allocator > >,
> std::allocator std::__cxx11::basic_string,
> std::allocator > > > >
> >::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator const*, std::__cxx11::basic_string,
> std::allocator > >,
> std::allocator std::__cxx11::basic_string,
> std::allocator > > > > > const&)'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::program_options::abstract_variables_map::operator[](std::__cxx11::basic_string std::char_traits, std::allocator > const&) const'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `vtable
> for boost::program_options::error_with_option_name'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::program_options::variables_map::variables_map()'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::program_options::error_with_option_name::what() const'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::re_detail_107500::verify_options(unsigned int,
> boost::regex_constants::_match_flags)'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `typeinfo
> for boost::program_options::error_with_option_name'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
> `boost::re_detail_107500::get_mem_block()'
> /usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `typeinfo
> for boost::regex_error
> ...
>
> But when FreeCADApp is actually linking
> only /usr/lib64/libboost_serialization.so is linked against.
>
> Full log:
>
>
> https://copr-be.cloud.fedoraproject.org/results/orion/vtk9.0/fedora-rawhide-aarch64/01938305-freecad/build.log.gz
>
> WTH!?!?! What a mess.
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1924375] perl-JavaScript-Minifier-1.15 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-JavaScript-Minifier-1.
   ||15-1.fc34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL whats version of RHEL will follow

[john tatt]

Hi
So if I understand well, an EPEL package could be have to be desinstalled just 
because an update in Stream make it not compatible any more ?
Strange 

Le Mon Feb 01 2021 17:49:41 GMT+0100 (CET), Stephen John Smoogen 
 a écrit :  
 
 

On Mon, 1 Feb 2021 at 11:00, Filip Bartmann  wrote:

Hello,
what version of RedHat will EPEL now follow? Centos Stream or oficial RedHat 
and Rocky based on stable RHEL?
 


The main EPEL packages have always been compiled against the official Red Hat 
Enterprise Linux current package set. There is an initiative to have a set of 
packages built against CentOS Stream to deal with .next issues we see when RHEL 
updates from say 8.3 to 8.4.

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



-- 
Stephen J Smoogen.

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

[Bug 1919731] Please build perl-XML-Stream for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2021-c5324b6008 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c5324b6008


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Petr Lautrbach]

Kevin Fenzi  writes:

> Greetings everyone. 
>
> We finally have everything in place and hopefully tested to make the
> switch tomorrow from master to rawhide/main branches for
> src.fedoraproject.org. 
>
> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> will be moving all the branches over to rawhide/main. As soon as all
> packages are done, we will be adjusting pdc/hooks/existing pr's.
>
> We will be sending an additional email once changes are complete and
> hopefully any downtime will be limited. 
>
> Once the change is completed you will want to checkout rawhide/main
> instead of master and update/recreate any existing forks you have.
>
> See
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> for more information. 
>

The page says "This Change will move many repositories (see below) to
use a "main" branch as default." and "Not every namespace on dist-git
has a rawhide version. For example: containers do not have/use rawhide.
And having different default branches on different namespaces is not
very appealing."

Now we have https://src.fedoraproject.org/tests/selinux/ with default
branch "rawhide". "rawhide" doesn't make sense in this repo as it
contains tests used on all Fedora versions and also downstream Red Hat
Enterprise Linux.

Have I missed something?

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

CMake FindBoost module doesn't like boost 1.75

[Richard Shaw]

It tends to generate a lot of output around:

CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:1204 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets

Specifically for trying to build FreeCAD it KIND OF finds the libraries:

-- Found Boost: /usr/include (found suitable version "1.75.0", minimum
required is "1.55") found components: filesystem program_options regex
system thread chrono date_time atomic

But then later:

CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:1204 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES)
  src/Mod/Path/libarea/CMakeLists.txt:20 (find_package)
-- Found Boost: /usr/include (found version "1.75.0") found components:
python39
-- found Boost: 1_75
-- boost-incude dirs are: /usr/include
-- boost-python lib is:
-- boost_LIBRARY_DIRS is: /usr/lib64
-- Boost_LIBRARIES is: /usr/lib64/libboost_python39.so

And then freecad (a fork testing vtk9 compatibility) fails with:

/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::match_results<__gnu_cxx::__normal_iterator,
std::allocator > >,
std::allocator,
std::allocator > > > >
>::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator,
std::allocator > >,
std::allocator,
std::allocator > > > > > const&)'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::program_options::abstract_variables_map::operator[](std::__cxx11::basic_string, std::allocator > const&) const'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `vtable for
boost::program_options::error_with_option_name'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::program_options::variables_map::variables_map()'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::program_options::error_with_option_name::what() const'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::re_detail_107500::verify_options(unsigned int,
boost::regex_constants::_match_flags)'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `typeinfo
for boost::program_options::error_with_option_name'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to
`boost::re_detail_107500::get_mem_block()'
/usr/bin/ld: ../../lib/libFreeCADApp.so: undefined reference to `typeinfo
for boost::regex_error
...

But when FreeCADApp is actually linking
only /usr/lib64/libboost_serialization.so is linked against.

Full log:

https://copr-be.cloud.fedoraproject.org/results/orion/vtk9.0/fedora-rawhide-aarch64/01938305-freecad/build.log.gz

WTH!?!?! What a mess.

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

[Bug 1924375] perl-JavaScript-Minifier-1.15 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|mmasl...@redhat.com,|
   |xav...@bachelot.org |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL whats version of RHEL will follow

[Miro Hrončok]

On 03. 02. 21 12:58, Miro Hrončok wrote:

On 03. 02. 21 12:14, john tatt wrote:

Hi
So if I understand well, an EPEL package could be have to be desinstalled just 
because an update in Stream make it not compatible any more ?


No.


Apologies, I've misread your email and I've mistaken "desinstalled" for "removed 
from EPEL repos". Disregard it.


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

Re: master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

On Wed, Feb 03, 2021 at 02:03:56PM +, Richard W.M. Jones wrote:
> I can't push to either "main" or "rawhide":

Never mind, I see from Kevin Fenzi's thread above why this has happened.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

On Wed, Feb 03, 2021 at 02:59:10PM +0100, Fabio Valentini wrote:
> Regarding the "f33" issue, that sounds like a fedpkg bug.

I filed a bug:

https://pagure.io/fedpkg/issue/427

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: master branch renaming and fedpkg clone -B

[Lubomír Sedlář]

Richard W.M. Jones píše v St 03. 02. 2021 v 13:53 +:
> $ fedpkg clone -B ocaml-ppx-hash
> Cloning into bare repository '/home/rjones/d/fedora/ocaml-ppx-
> hash/rpkg.git'...
> remote: Enumerating objects: 26, done.
> remote: Counting objects: 100% (26/26), done.
> remote: Compressing objects: 100% (23/23), done.
> remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
> Receiving objects: 100% (26/26), done.
> Resolving deltas: 100% (12/12), done.
> 
> $ ls ocaml-ppx-hash/
> f33
> 
> This is wrong isn't it?  Shouldn't either "main" or "rawhide"
> branch subdirectories have been created?

Good catch, that's a bug. This pull request should fix it:
https://pagure.io/fedpkg/pull-request/426

Lubomír

> See: https://src.fedoraproject.org/rpms/ocaml-ppx-hash/branches
> 
> Also I'm a bit confused about the difference between "main" and
> "rawhide" - which one should I use for development that happened on
> the old master branch?
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat 
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: 
> http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Miro Hrončok]

On 03. 02. 21 14:35, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 February 2021 at 14:24, Miro Hrončok wrote:

On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:

On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:

clime wrote:

So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?


I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e., if the CI build fails, check whether the built
commit is still the current HEAD, and trigger the revert only if it is,
otherwise defer the decision to the new HEAD's CI build), but if that is the
case, yes, it will definitely be deleted from the server. But it will still
be present in the maintainer's local checkout and can be trivially pushed
back together with a build fix.



Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?

Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a fast-forward merge) to a
"rawhide-build" branch.

That way you know that what's on the rawhide-build branch was able to
successfully build (at one time ... it might fail later due to changes
to other packages).

That avoids any automated (and possibly error prone) resets or reverts
on the branch that the maintainer pushed to.


+1, this is much cleaner and simpler. Obviously, that branch would have
to have permissions to only allow pushes from CI.


Suddenly, you have a branch to which:

  - maintainers push potentially broken content
  - provenpackagers push their bumps

How is this better than status quo?


I'm not sure I get your point. The new branch (rawhide-build) would
contain only content that built successfully from rawhide branch and
nobody except CI would be allowed to push it. Isn't that an improvement?


For who? As a provenpackager, I still cannot push to rawhide-build and I still 
need to deal with broken content in the rawhide branch.


--
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: master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

On Wed, Feb 03, 2021 at 02:59:10PM +0100, Fabio Valentini wrote:
> On Wed, Feb 3, 2021 at 2:54 PM Richard W.M. Jones  wrote:
> >
> > $ fedpkg clone -B ocaml-ppx-hash
> > Cloning into bare repository 
> > '/home/rjones/d/fedora/ocaml-ppx-hash/rpkg.git'...
> > remote: Enumerating objects: 26, done.
> > remote: Counting objects: 100% (26/26), done.
> > remote: Compressing objects: 100% (23/23), done.
> > remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
> > Receiving objects: 100% (26/26), done.
> > Resolving deltas: 100% (12/12), done.
> >
> > $ ls ocaml-ppx-hash/
> > f33
> >
> > This is wrong isn't it?  Shouldn't either "main" or "rawhide" branch
> > subdirectories have been created?
> >
> > See: https://src.fedoraproject.org/rpms/ocaml-ppx-hash/branches
> >
> > Also I'm a bit confused about the difference between "main" and
> > "rawhide" - which one should I use for development that happened on
> > the old master branch?
> >
> > Rich.
> 
> If everything is implemented as approved by FESCo, "rawhide" is the
> successor for "master", with "main" only being a symbolic reference
> pointing at "rawhide".
> 
> Regarding the "f33" issue, that sounds like a fedpkg bug.

I can't push to either "main" or "rawhide":

$ fedpkg push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 412 bytes | 412.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Unspecified ref refs/heads/rawhide is blocked
remote: Denied push for ref 'refs/heads/rawhide' for user 'rjones'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/ocaml-ppx-hash
 ! [remote rejected] rawhide -> rawhide (pre-receive hook declined)
error: failed to push some refs to 
'ssh://pkgs.fedoraproject.org/rpms/ocaml-ppx-hash'
Could not execute push: Failed to execute command.

(Pushing to "main" fails in a similar way)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

On Wed, Feb 03, 2021 at 01:53:49PM +, Richard W.M. Jones wrote:
> $ fedpkg clone -B ocaml-ppx-hash
> Cloning into bare repository 
> '/home/rjones/d/fedora/ocaml-ppx-hash/rpkg.git'...
> remote: Enumerating objects: 26, done.
> remote: Counting objects: 100% (26/26), done.
> remote: Compressing objects: 100% (23/23), done.
> remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
> Receiving objects: 100% (26/26), done.
> Resolving deltas: 100% (12/12), done.
> 
> $ ls ocaml-ppx-hash/
> f33
> 
> This is wrong isn't it?  Shouldn't either "main" or "rawhide" branch
> subdirectories have been created?
> 
> See: https://src.fedoraproject.org/rpms/ocaml-ppx-hash/branches
> 
> Also I'm a bit confused about the difference between "main" and
> "rawhide" - which one should I use for development that happened on
> the old master branch?

Also:

To ssh://pkgs.fedoraproject.org/rpms/ocaml-ppx-hash
 ! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 
'ssh://pkgs.fedoraproject.org/rpms/ocaml-ppx-hash'

I believe I'm using the latest of everything:

fedpkg-1.40-3.fc34.noarch
python3-fedora-1.1.1-2.fc34.noarch
python3-distro-1.5.0-5.fc34.noarch
python3-rpkg-1.62-2.fc34.noarch

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Fabio Valentini]

On Wed, Feb 3, 2021 at 12:42 PM Milan Crha  wrote:
>
> On Wed, 2021-02-03 at 15:26 +1000, David Airlie wrote:
> > Please test:
> >
> > mesa-21.0.0~rc3-2.fc34
> >
> > which I just built for rawhide.
>
> Hi,
> for what it's worth, it helped me with gdm, it opens now, but I cannot
> log in to "GNOME on Xorg", I'm immediately returned back to the gdm.
> Logging to "GNOME" (aka Wayland) works.

Can confirm, gdm and gnome/wayland works again, but all Xorg based
sessions are now even more broken, e.g. you're returned to gdm a
second after you enter your password.

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

Re: master branch renaming and fedpkg clone -B

[Fabio Valentini]

On Wed, Feb 3, 2021 at 2:54 PM Richard W.M. Jones  wrote:
>
> $ fedpkg clone -B ocaml-ppx-hash
> Cloning into bare repository 
> '/home/rjones/d/fedora/ocaml-ppx-hash/rpkg.git'...
> remote: Enumerating objects: 26, done.
> remote: Counting objects: 100% (26/26), done.
> remote: Compressing objects: 100% (23/23), done.
> remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
> Receiving objects: 100% (26/26), done.
> Resolving deltas: 100% (12/12), done.
>
> $ ls ocaml-ppx-hash/
> f33
>
> This is wrong isn't it?  Shouldn't either "main" or "rawhide" branch
> subdirectories have been created?
>
> See: https://src.fedoraproject.org/rpms/ocaml-ppx-hash/branches
>
> Also I'm a bit confused about the difference between "main" and
> "rawhide" - which one should I use for development that happened on
> the old master branch?
>
> Rich.

If everything is implemented as approved by FESCo, "rawhide" is the
successor for "master", with "main" only being a symbolic reference
pointing at "rawhide".

Regarding the "f33" issue, that sounds like a fedpkg bug.

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

master branch renaming and fedpkg clone -B

[Richard W.M. Jones]

$ fedpkg clone -B ocaml-ppx-hash
Cloning into bare repository '/home/rjones/d/fedora/ocaml-ppx-hash/rpkg.git'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (26/26), done.
Resolving deltas: 100% (12/12), done.

$ ls ocaml-ppx-hash/
f33

This is wrong isn't it?  Shouldn't either "main" or "rawhide" branch
subdirectories have been created?

See: https://src.fedoraproject.org/rpms/ocaml-ppx-hash/branches

Also I'm a bit confused about the difference between "main" and
"rawhide" - which one should I use for development that happened on
the old master branch?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
> Jonathan Wakely wrote:
> > Instead of force pushing or reverting anything in the rawhide branch,
> > why not just have two branches?
> > 
> > Maintainers commit to one branch, and if the build is successful that
> > branch is automatically merged (as a fast-forward merge) to a
> > "rawhide-build" branch.
> > 
> > That way you know that what's on the rawhide-build branch was able to
> > successfully build (at one time ... it might fail later due to changes
> > to other packages).
> > 
> > That avoids any automated (and possibly error prone) resets or reverts
> > on the branch that the maintainer pushed to.
> 
> But it means that provenpackagers who want to bump and rebuild have to 
> actually manually look at another branch (rawhide-build).

No, why would they need to do that? The question aside, they wouldn't be
allowed to do that, anyway. The idea is that only CI can push there once
there's a successful build from rawhide branch.

> Plus, they will then need to revert rawhide to rawhide-build,

Again, why?

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

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 03 February 2021 at 14:24, Miro Hrončok wrote:
> On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:
> > On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
> > > On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
> > > > clime wrote:
> > > > > So if some other maintainer pushes his work to the server meanwhile,
> > > > > this will just delete his work? Or what's the idea here?
> > > > 
> > > > I guess the safe thing to do would be to wait and see whether that 
> > > > commit
> > > > also fails to build (i.e., if the CI build fails, check whether the 
> > > > built
> > > > commit is still the current HEAD, and trigger the revert only if it is,
> > > > otherwise defer the decision to the new HEAD's CI build), but if that 
> > > > is the
> > > > case, yes, it will definitely be deleted from the server. But it will 
> > > > still
> > > > be present in the maintainer's local checkout and can be trivially 
> > > > pushed
> > > > back together with a build fix.
> > > 
> > > 
> > > Instead of force pushing or reverting anything in the rawhide branch,
> > > why not just have two branches?
> > > 
> > > Maintainers commit to one branch, and if the build is successful that
> > > branch is automatically merged (as a fast-forward merge) to a
> > > "rawhide-build" branch.
> > > 
> > > That way you know that what's on the rawhide-build branch was able to
> > > successfully build (at one time ... it might fail later due to changes
> > > to other packages).
> > > 
> > > That avoids any automated (and possibly error prone) resets or reverts
> > > on the branch that the maintainer pushed to.
> > 
> > +1, this is much cleaner and simpler. Obviously, that branch would have
> > to have permissions to only allow pushes from CI.
> 
> Suddenly, you have a branch to which:
> 
>  - maintainers push potentially broken content
>  - provenpackagers push their bumps
> 
> How is this better than status quo?

I'm not sure I get your point. The new branch (rawhide-build) would
contain only content that built successfully from rawhide branch and
nobody except CI would be allowed to push it. Isn't that an improvement?

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

Re: Jami (formerly Ring) P2P softphone packaging?

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:
> On 01.02.2021 19:49, Daniel Pocock wrote:
>> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
>> formerly known as Ring.
> 
> Electron framework is forbidden on Fedora due to ffmpeg usage and it
> cannot be built from sources without Internet access.
> 
> See also: https://fedoraproject.org/wiki/Electron

Are they actually using Electron now? I see a GTK/GNOME client and a Qt 
client, the latter with a warning that it is only tested on Windows, sadly.

But Jami itself depends on FFmpeg.

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

Re: Cfitsio soname bump

[Alejandro Álvarez Ayllón]

Hi Sergio,

Could you trigger a rebuild of ccfits, please? It seems it was rebuilt
against cfitsio 3.470, being uninstallable right now in rawhide.

Best regards,
Alejandro

El jue, 14 ene 2021 a las 1:17, Sergio Pascual ()
escribió:

> Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week.  This
> involves a soname bump.
>
> The affected packages are the following:
>
> CCfits
> LabPlot
> astrometry
> bes
> cpl
> elements-alexandria
> gdal
> healpix
> indi-gphoto
> kst
> kstars
> libindi
> luminance-hdr
> nightviewperl-Astro-FITS-CFITSIO
> phd2
> python-astropy
> python-fitsio
> python-healpy
> root
> siril
> skyviewer
> sourcextractor++
> ufraw
> vips
> wcslib
>
> Best regards, Sergio
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Panu Matilainen]

On 2/3/21 2:27 PM, Neal Gompa wrote:

On Wed, Feb 3, 2021 at 7:26 AM Panu Matilainen  wrote:


On 2/3/21 2:06 PM, Neal Gompa wrote:

On Wed, Feb 3, 2021 at 6:39 AM Miro Hrončok  wrote:


On 03. 02. 21 10:13, Panu Matilainen wrote:

Hey all,

Just woke up to the fact that F34 is about to be branched, and that we
originally planned to phase out BDB rpmdb support to read-only in Fedora 34 [1].

That's too close to comfort for me, and might be considered too late for other
reasons too. So a slight change of plans, lets postpone this to F35, and handle
this right away after F34 has been branched. Rpm >= 4.17 which is to be expected
later in F35 will not *have* read-write BDB support at all, so disabling it
early gives folks a little of leeway where things can still be temporarily
reverted if something unexpected breaks.

Should we file a separate system-wide change for this, or can we proceed on the
basis that this was already accepted as a part of the sqlite change [1]?


I'd say this is already accepted as a part of the sqlite change, but please open
a placeholder issue at https://pagure.io/fedora-docs/release-notes to make sure
we document this in the release notes of Fedora 35.



I'm not entirely sure why you think we need to postpone this, since

1) branching is the *early* part of the cycle, not the late part and
2) Koji is already doing bootstrap builds now, explicitly because of
BDB being dropped in Fedora 34.

We accepted the Fedora 33 Change with the premise you were going to
drop in Fedora 34. Reverting to enabling the rw BDB backend is pretty
straightforward, so I still suggest that you actually *still* do it
now and file a release note issue about it being dropped in F34.


Well, if we people actually *want* us to go ahead and axe it right now,
I'm not going to push back :D

The idea of postponing was to be, as ever, playing with safe with rpm
changes which are best dealt with long before branching point. But of
course you're right in that this is an easy thing to revert back if
things do go wrong.



I'd rather you do it now, please. It's not like you're ripping out
code from RPM right now, you're just flipping a switch off. :)

Now is as good of a time as any to figure out what's left to fix, if anything.


As you wish:

https://src.fedoraproject.org/rpms/rpm/c/1089af6b8a5cd5516e3243a5557551337b8c491d?branch=master
https://koji.fedoraproject.org/koji/taskinfo?taskID=61207763

https://pagure.io/fedora-docs/release-notes/issue/653

Ladies and gents, when that build lands it'll be a rather historical 
moment. Suse seems to have beaten us to disabling BDB in rpm (congrats 
to them on that), but nevertheless it's very much an end of an era in 
this distro family.


- Panu -

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Kevin Kofler via devel]

Jonathan Wakely wrote:
> Instead of force pushing or reverting anything in the rawhide branch,
> why not just have two branches?
> 
> Maintainers commit to one branch, and if the build is successful that
> branch is automatically merged (as a fast-forward merge) to a
> "rawhide-build" branch.
> 
> That way you know that what's on the rawhide-build branch was able to
> successfully build (at one time ... it might fail later due to changes
> to other packages).
> 
> That avoids any automated (and possibly error prone) resets or reverts
> on the branch that the maintainer pushed to.

But it means that provenpackagers who want to bump and rebuild have to 
actually manually look at another branch (rawhide-build). Plus, they will 
then need to revert rawhide to rawhide-build, which is not easily automated 
(and they cannot just reset and force-push, which would be the easy way, 
because the git hooks prevent that). So, compared to my proposal, your 
proposal pushes work away from automated infrastructure to packagers 
(breaking their mass rebuild scripts, which is the whole point of this 
thread), and makes it impossible to use force pushes (or at least 
impractical: how should the exception in the git hooks be implemented? 
Whereas exempting pushes submitted by the CI infrastructure would be 
straightforward).

Hence, I cannot see how your suggestion would be an improvement over mine.

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

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Mohan Boddu]

Hello everyone,

We are about to start the change process. As previously mentioned,
pushes to 'master' branch will be disabled, once we made the changes,
we will send another email at which point you need to run `git fetch
-p` or checkout 'rawhide' branch and you can start building packages
in the usual process you are accustomed to from the 'rawhide' branch.

On Tue, Feb 2, 2021 at 6:08 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> We finally have everything in place and hopefully tested to make the
> switch tomorrow from master to rawhide/main branches for
> src.fedoraproject.org.
>
> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> will be moving all the branches over to rawhide/main. As soon as all
> packages are done, we will be adjusting pdc/hooks/existing pr's.
>
> We will be sending an additional email once changes are complete and
> hopefully any downtime will be limited.
>
> Once the change is completed you will want to checkout rawhide/main
> instead of master and update/recreate any existing forks you have.
>
> See
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> for more information.
>
> Thanks,
>
> kevin
> ___
> devel-announce mailing list -- devel-announce@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Miro Hrončok]

On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:

On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:

clime wrote:

So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?


I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e., if the CI build fails, check whether the built
commit is still the current HEAD, and trigger the revert only if it is,
otherwise defer the decision to the new HEAD's CI build), but if that is the
case, yes, it will definitely be deleted from the server. But it will still
be present in the maintainer's local checkout and can be trivially pushed
back together with a build fix.



Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?

Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a fast-forward merge) to a
"rawhide-build" branch.

That way you know that what's on the rawhide-build branch was able to
successfully build (at one time ... it might fail later due to changes
to other packages).

That avoids any automated (and possibly error prone) resets or reverts
on the branch that the maintainer pushed to.


+1, this is much cleaner and simpler. Obviously, that branch would have
to have permissions to only allow pushes from CI.


Suddenly, you have a branch to which:

 - maintainers push potentially broken content
 - provenpackagers push their bumps

How is this better than status quo?

--
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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Mohan Boddu]

Hello everyone,

We are about to start the change process. As previously mentioned,
pushes to 'master' branch will be disabled, once we made the changes,
we will send another email at which point you need to run `git fetch
-p` or checkout 'rawhide' branch and you can start building packages
in the usual process you are accustomed to from the 'rawhide' branch.

On Tue, Feb 2, 2021 at 6:08 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> We finally have everything in place and hopefully tested to make the
> switch tomorrow from master to rawhide/main branches for
> src.fedoraproject.org.
>
> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> will be moving all the branches over to rawhide/main. As soon as all
> packages are done, we will be adjusting pdc/hooks/existing pr's.
>
> We will be sending an additional email once changes are complete and
> hopefully any downtime will be limited.
>
> Once the change is completed you will want to checkout rawhide/main
> instead of master and update/recreate any existing forks you have.
>
> See
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> for more information.
>
> Thanks,
>
> kevin
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
> On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
> > clime wrote:
> > > So if some other maintainer pushes his work to the server meanwhile,
> > > this will just delete his work? Or what's the idea here?
> > 
> > I guess the safe thing to do would be to wait and see whether that commit
> > also fails to build (i.e., if the CI build fails, check whether the built
> > commit is still the current HEAD, and trigger the revert only if it is,
> > otherwise defer the decision to the new HEAD's CI build), but if that is the
> > case, yes, it will definitely be deleted from the server. But it will still
> > be present in the maintainer's local checkout and can be trivially pushed
> > back together with a build fix.
> 
> 
> Instead of force pushing or reverting anything in the rawhide branch,
> why not just have two branches?
> 
> Maintainers commit to one branch, and if the build is successful that
> branch is automatically merged (as a fast-forward merge) to a
> "rawhide-build" branch.
> 
> That way you know that what's on the rawhide-build branch was able to
> successfully build (at one time ... it might fail later due to changes
> to other packages).
> 
> That avoids any automated (and possibly error prone) resets or reverts
> on the branch that the maintainer pushed to.

+1, this is much cleaner and simpler. Obviously, that branch would have
to have permissions to only allow pushes from CI.

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

Re: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Miro Hrončok]

On 03. 02. 21 13:51, Miro Hrončok wrote:

On 03. 02. 21 13:06, Neal Gompa wrote:

1) branching is the*early*  part of the cycle, not the late part and


I disagree.

Once we branch Fedora 34 from rawhide, we should stabilize it and not introduce 
braking changes to it. The change completion deadline is at branching. Hence 
branching of 34 is late part of the 34 development. Everything that happens 
after branching should be quality assurance, not development. (Yes, people will 
rush in changes until the beta freeze or even after, but they SHOULD be thinking 
about stabilization.)


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#before-updates-testing-activation 



Note that Fedora 34 branching is also the *earliest* part of Fedora 35 
development, so in fact your statement is technically half correct.


To clarify my previous email, it is a general statement about branching. It does 
not say we should (not) disable rpmdb write-support from Fedora 34 shortly 
before branching.


--
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: Boost 1.75.0 in rawhide, with soname change

[Jonathan Wakely]

On 29/01/21 10:06 -0800, Michel Alexandre Salim wrote:

On Mon, 2021-01-25 at 10:00 +, Jonathan Wakely wrote:

Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it.


Some of the packages depending on Folly didn't get rebuilt, but that's
fine, I've done an update that got all of them.


Sorry about that. Which ones?

I rebuilt fb303, fbthrift and fbzmq, as well as folly itself. Those
were the only ones I saw that actually depend on libboost_*.so
libraries.

It's possible that other packages which only consume boost headers
should be rebuilt (if they use a library like Folly that uses Boost
types in its API) but rebuilding those packages is not typically done
as part of a rebuild for a Boost update.

The list of packages that I attempted to rebuild is found using the
first repoquery command at
https://fedoraproject.org/wiki/Changes/F34Boost175#Dependencies

I see that fizz, wangle and watchman depend on Folly, but none of them
has any declared dependency on Boost that I can see.


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

Re: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Miro Hrončok]

On 03. 02. 21 13:06, Neal Gompa wrote:

1) branching is the*early*  part of the cycle, not the late part and


I disagree.

Once we branch Fedora 34 from rawhide, we should stabilize it and not introduce 
braking changes to it. The change completion deadline is at branching. Hence 
branching of 34 is late part of the 34 development. Everything that happens 
after branching should be quality assurance, not development. (Yes, people will 
rush in changes until the beta freeze or even after, but they SHOULD be thinking 
about stabilization.)


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#before-updates-testing-activation

Note that Fedora 34 branching is also the *earliest* part of Fedora 35 
development, so in fact your statement is technically half correct.


--
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: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed

[Jonathan Wakely]

On 03/02/21 12:24 -, Martin Gansser wrote:

you mean, this part of the patch can be removed ?

@@ -336,14 +331,14 @@
inline char_traits::char_type*
char_traits::move(char_type* s1, const char_type* s2, 
int_type
n)
{
-return (cxxtools::Char*)std::memmove(s1, s2, n * 
sizeof(cxxtools::Char));
+return
static_cast(std::memmove(static_cast(s1),
static_cast(s2), n * sizeof(cxxtools::Char)));   
}


inline char_traits::char_type*
char_traits::copy(char_type* s1, const char_type* s2, size_t
n)
{
-return (cxxtools::Char*)std::memcpy(s1, s2, n * 
sizeof(cxxtools::Char));
+return
static_cast(std::memcpy(static_cast(s1),
static_cast(s2), n * sizeof(cxxtools::Char)));
}



Yes, I think so.

With the operator= removed (or defined as default) the type is
trivially copyable, so it's OK to use memmove and memcpy on it. So you
shouldn't get any warnings about doing that.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Reading out the time zone on different architecures produces different results.

[Martin Gansser]

Thanks, I'll discuss it with upstream.

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

Re: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Neal Gompa]

On Wed, Feb 3, 2021 at 7:26 AM Panu Matilainen  wrote:
>
> On 2/3/21 2:06 PM, Neal Gompa wrote:
> > On Wed, Feb 3, 2021 at 6:39 AM Miro Hrončok  wrote:
> >>
> >> On 03. 02. 21 10:13, Panu Matilainen wrote:
> >>> Hey all,
> >>>
> >>> Just woke up to the fact that F34 is about to be branched, and that we
> >>> originally planned to phase out BDB rpmdb support to read-only in Fedora 
> >>> 34 [1].
> >>>
> >>> That's too close to comfort for me, and might be considered too late for 
> >>> other
> >>> reasons too. So a slight change of plans, lets postpone this to F35, and 
> >>> handle
> >>> this right away after F34 has been branched. Rpm >= 4.17 which is to be 
> >>> expected
> >>> later in F35 will not *have* read-write BDB support at all, so disabling 
> >>> it
> >>> early gives folks a little of leeway where things can still be temporarily
> >>> reverted if something unexpected breaks.
> >>>
> >>> Should we file a separate system-wide change for this, or can we proceed 
> >>> on the
> >>> basis that this was already accepted as a part of the sqlite change [1]?
> >>
> >> I'd say this is already accepted as a part of the sqlite change, but 
> >> please open
> >> a placeholder issue at https://pagure.io/fedora-docs/release-notes to make 
> >> sure
> >> we document this in the release notes of Fedora 35.
> >>
> >
> > I'm not entirely sure why you think we need to postpone this, since
> >
> > 1) branching is the *early* part of the cycle, not the late part and
> > 2) Koji is already doing bootstrap builds now, explicitly because of
> > BDB being dropped in Fedora 34.
> >
> > We accepted the Fedora 33 Change with the premise you were going to
> > drop in Fedora 34. Reverting to enabling the rw BDB backend is pretty
> > straightforward, so I still suggest that you actually *still* do it
> > now and file a release note issue about it being dropped in F34.
>
> Well, if we people actually *want* us to go ahead and axe it right now,
> I'm not going to push back :D
>
> The idea of postponing was to be, as ever, playing with safe with rpm
> changes which are best dealt with long before branching point. But of
> course you're right in that this is an easy thing to revert back if
> things do go wrong.
>

I'd rather you do it now, please. It's not like you're ripping out
code from RPM right now, you're just flipping a switch off. :)

Now is as good of a time as any to figure out what's left to fix, if anything.





--
真実はいつも一つ！/ 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-Rawhide-20210203.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

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

Failed openQA tests: 19/181 (x86_64), 13/123 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210201.n.1):

ID: 768624  Test: x86_64 Workstation-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/768624
ID: 768628  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/768628
ID: 768636  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/768636
ID: 768637  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/768637
ID: 768659  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/768659
ID: 768668  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/768668
ID: 768676  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/768676
ID: 768725  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/768725
ID: 768740  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/768740
ID: 768742  Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/768742
ID: 768777  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/768777
ID: 768827  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/768827
ID: 768831  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/768831
ID: 768833  Test: aarch64 universal install_package_set_minimal@uefi
URL: https://openqa.fedoraproject.org/tests/768833
ID: 768870  Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/768870

Old failures (same test failed in Fedora-Rawhide-20210201.n.1):

ID: 768616  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/768616
ID: 768639  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/768639
ID: 768692  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/768692
ID: 768757  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/768757
ID: 768760  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/768760
ID: 768763  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/768763
ID: 768780  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/768780
ID: 768783  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/768783
ID: 768784  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/768784
ID: 768837  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/768837
ID: 768845  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/768845
ID: 768846  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/768846
ID: 768856  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/768856
ID: 768874  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/768874
ID: 768876  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/768876
ID: 768892  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/768892
ID: 768893  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/768893

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

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

ID: 768779  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/768779

Old soft failures (same test soft failed in Fedora-Rawhide-20210201.n.1):

ID: 768574  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/768574
ID: 768579  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/768579
ID: 768675 

Re: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Panu Matilainen]

On 2/3/21 2:06 PM, Neal Gompa wrote:

On Wed, Feb 3, 2021 at 6:39 AM Miro Hrončok  wrote:


On 03. 02. 21 10:13, Panu Matilainen wrote:

Hey all,

Just woke up to the fact that F34 is about to be branched, and that we
originally planned to phase out BDB rpmdb support to read-only in Fedora 34 [1].

That's too close to comfort for me, and might be considered too late for other
reasons too. So a slight change of plans, lets postpone this to F35, and handle
this right away after F34 has been branched. Rpm >= 4.17 which is to be expected
later in F35 will not *have* read-write BDB support at all, so disabling it
early gives folks a little of leeway where things can still be temporarily
reverted if something unexpected breaks.

Should we file a separate system-wide change for this, or can we proceed on the
basis that this was already accepted as a part of the sqlite change [1]?


I'd say this is already accepted as a part of the sqlite change, but please open
a placeholder issue at https://pagure.io/fedora-docs/release-notes to make sure
we document this in the release notes of Fedora 35.



I'm not entirely sure why you think we need to postpone this, since

1) branching is the *early* part of the cycle, not the late part and
2) Koji is already doing bootstrap builds now, explicitly because of
BDB being dropped in Fedora 34.

We accepted the Fedora 33 Change with the premise you were going to
drop in Fedora 34. Reverting to enabling the rw BDB backend is pretty
straightforward, so I still suggest that you actually *still* do it
now and file a release note issue about it being dropped in F34.


Well, if we people actually *want* us to go ahead and axe it right now, 
I'm not going to push back :D


The idea of postponing was to be, as ever, playing with safe with rpm 
changes which are best dealt with long before branching point. But of 
course you're right in that this is an easy thing to revert back if 
things do go wrong.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed

[Martin Gansser]

you mean, this part of the patch can be removed ?

@@ -336,14 +331,14 @@
 inline char_traits::char_type*
 char_traits::move(char_type* s1, const char_type* s2, 
int_type
n)
 {
-return (cxxtools::Char*)std::memmove(s1, s2, n * 
sizeof(cxxtools::Char));
+return
static_cast(std::memmove(static_cast(s1),
static_cast(s2), n * sizeof(cxxtools::Char))); 
 }
 
 
 inline char_traits::char_type*
 char_traits::copy(char_type* s1, const char_type* s2, 
size_t
n)
 {
-return (cxxtools::Char*)std::memcpy(s1, s2, n * 
sizeof(cxxtools::Char));
+return
static_cast(std::memcpy(static_cast(s1),
static_cast(s2), n * sizeof(cxxtools::Char))); 
 }
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-34-20210203.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 3/16 (x86_64), 4/15 (aarch64)

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

ID: 768948  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/768948
ID: 768951  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/768951
ID: 768952  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/768952
ID: 768960  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/768960
ID: 768963  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/768963
ID: 768966  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/768966
ID: 768967  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/768967

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-20210202.0):

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

Passed openQA tests: 12/16 (x86_64), 11/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.30 to 0.11
Previous test data: https://openqa.fedoraproject.org/tests/768002#downloads
Current test data: https://openqa.fedoraproject.org/tests/768946#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.12 to 0.29
Previous test data: https://openqa.fedoraproject.org/tests/768017#downloads
Current test data: https://openqa.fedoraproject.org/tests/768961#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: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Neal Gompa]

On Wed, Feb 3, 2021 at 6:39 AM Miro Hrončok  wrote:
>
> On 03. 02. 21 10:13, Panu Matilainen wrote:
> > Hey all,
> >
> > Just woke up to the fact that F34 is about to be branched, and that we
> > originally planned to phase out BDB rpmdb support to read-only in Fedora 34 
> > [1].
> >
> > That's too close to comfort for me, and might be considered too late for 
> > other
> > reasons too. So a slight change of plans, lets postpone this to F35, and 
> > handle
> > this right away after F34 has been branched. Rpm >= 4.17 which is to be 
> > expected
> > later in F35 will not *have* read-write BDB support at all, so disabling it
> > early gives folks a little of leeway where things can still be temporarily
> > reverted if something unexpected breaks.
> >
> > Should we file a separate system-wide change for this, or can we proceed on 
> > the
> > basis that this was already accepted as a part of the sqlite change [1]?
>
> I'd say this is already accepted as a part of the sqlite change, but please 
> open
> a placeholder issue at https://pagure.io/fedora-docs/release-notes to make 
> sure
> we document this in the release notes of Fedora 35.
>

I'm not entirely sure why you think we need to postpone this, since

1) branching is the *early* part of the cycle, not the late part and
2) Koji is already doing bootstrap builds now, explicitly because of
BDB being dropped in Fedora 34.

We accepted the Fedora 33 Change with the premise you were going to
drop in Fedora 34. Reverting to enabling the rw BDB backend is pretty
straightforward, so I still suggest that you actually *still* do it
now and file a release note issue about it being dropped in F34.


-- 
真実はいつも一つ！/ 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

[EPEL-devel] Re: EPEL whats version of RHEL will follow

[Miro Hrončok]

On 03. 02. 21 12:14, john tatt wrote:

Hi
So if I understand well, an EPEL package could be have to be desinstalled just 
because an update in Stream make it not compatible any more ?


No.

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

Re: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed

[Jonathan Wakely]

On 31/01/21 10:00 -, Martin Gansser wrote:

The issue has now been resolved with this patch:

+++ include/cxxtools/char.h 2021-01-30 18:28:23.87739 +0100
@@ -68,9 +68,7 @@
typedef int32_t value_type;

//! Constructs a character with a value of 0.
-Char()
-: _value(0)
-{}
+Char() = default;

//! Constructs a character using the given char as base for the 
character value.
Char(char ch)
@@ -114,9 +112,6 @@
return Char(0);
}

-Char& operator=(const Char& ch)
-{ _value = ch._value; return *this; }
-


Ah, I was looking at the upstream code which has already removed that.


/**
 * @brief Returns the internal value (unsigned 32 bits) of this 
character.
 * @return The 32-bit-value of this character.
@@ -336,14 +331,14 @@
inline char_traits::char_type*
char_traits::move(char_type* s1, const char_type* s2, 
int_type n)
{
-return (cxxtools::Char*)std::memmove(s1, s2, n * 
sizeof(cxxtools::Char));
+return static_cast(std::memmove(static_cast(s1), 
static_cast(s2), n * sizeof(cxxtools::Char))); 
}


inline char_traits::char_type*
char_traits::copy(char_type* s1, const char_type* s2, 
size_t n)
{
-return (cxxtools::Char*)std::memcpy(s1, s2, n * 
sizeof(cxxtools::Char));
+return static_cast(std::memcpy(static_cast(s1), 
static_cast(s2), n * sizeof(cxxtools::Char)));


These changes seem unnecessary, and would only hide bugs.

After removing the non-trivial operator= there should be no more
warning about using memmove and memcpy on Char objects.


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

[Test-Announce] Fedora-IoT 34 RC 20210203.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 34 RC 20210203.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20210203.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20210203.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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

CPE Feedback Survey

[Ant Carroll]

Hey folks, Apologies for the delay in getting this out to you after the
start of the year. Hopefully you've noticed the changes to communication
since the results of the last survey we did in August. However, we know
this is ever changing, people join or become inactive and so want to ensure
we continue with making improvements that benefit us all. I'm here asking
for your help with this again [image: ] Here is a link to a very short
survey we've put together to learn how your experiences have been with the
CPE team since October 2020. If you could take the time (5mins max) to
complete it for us it would be hugely valuable as we work on this
continuous improvement - https://fedoraproject.limequery.com/4?lang=en
The survey will remain open until Feb 17th (23:59 UTC).
Cheers, Ant
-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com
M: +353876213163 IM: ancarrol
@redhatjobs    redhatjobs
 @redhatjobs


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Jonathan Wakely]

On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:

clime wrote:

So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?


I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e., if the CI build fails, check whether the built
commit is still the current HEAD, and trigger the revert only if it is,
otherwise defer the decision to the new HEAD's CI build), but if that is the
case, yes, it will definitely be deleted from the server. But it will still
be present in the maintainer's local checkout and can be trivially pushed
back together with a build fix.



Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?

Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a fast-forward merge) to a
"rawhide-build" branch.

That way you know that what's on the rawhide-build branch was able to
successfully build (at one time ... it might fail later due to changes
to other packages).

That avoids any automated (and possibly error prone) resets or reverts
on the branch that the maintainer pushed to.

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

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Milan Crha]

On Wed, 2021-02-03 at 15:26 +1000, David Airlie wrote:
> Please test:
> 
> mesa-21.0.0~rc3-2.fc34
> 
> which I just built for rawhide.

Hi,
for what it's worth, it helped me with gdm, it opens now, but I cannot
log in to "GNOME on Xorg", I'm immediately returned back to the gdm.
Logging to "GNOME" (aka Wayland) works.

I also noticed a huge CPU spike after confirming my password (when
logging into the Wayland), but it's probably unrelated to this thing.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Miro Hrončok]

On 03. 02. 21 10:13, Panu Matilainen wrote:

Hey all,

Just woke up to the fact that F34 is about to be branched, and that we 
originally planned to phase out BDB rpmdb support to read-only in Fedora 34 [1].


That's too close to comfort for me, and might be considered too late for other 
reasons too. So a slight change of plans, lets postpone this to F35, and handle 
this right away after F34 has been branched. Rpm >= 4.17 which is to be expected 
later in F35 will not *have* read-write BDB support at all, so disabling it 
early gives folks a little of leeway where things can still be temporarily 
reverted if something unexpected breaks.


Should we file a separate system-wide change for this, or can we proceed on the 
basis that this was already accepted as a part of the sqlite change [1]?


I'd say this is already accepted as a part of the sqlite change, but please open 
a placeholder issue at https://pagure.io/fedora-docs/release-notes to make sure 
we document this in the release notes of Fedora 35.


--
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: Reading out the time zone on different architecures produces different results.

[Richard W.M. Jones]

On Wed, Feb 03, 2021 at 09:20:37AM -, Martin Gansser wrote:
> Thanks for your help.
> 
> Perhaps you can help me with another problem that exists with the testsuite 
> on the ppc64le architecure [1] 
> 
> the error message is:
> serializationinfo::testRangeCheck: ASSERTION at serializationinfo-test.cpp:561
>   exception of type std::range_error expected in siValue(si)

558   if (std::numeric_limits::max() > static_cast(std::numeric_limits::max()))
559   {
560 si.setValue(static_cast(std::numeric_limits::max()) * 1.01);
561 CXXTOOLS_UNIT_ASSERT_THROW(siValue(si), std::range_error);

I'm not exactly sure what this code is doing, but I'm going to guess
it's confused that long double doesn't work like it does on x86-64.
On x86-64, long double is 80 bits, on ppc64le long double is, or is
going to be, 128 bits:
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition

Take it to upstream is my advice.

Rich.

> [1] https://kojipkgs.fedoraproject.org//work/tasks/8769/61188769/build.log
> 
> Regards
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

newRepo taking a while this morning ...

[Richard W.M. Jones]

And in possibly related news, there seem to be a lot of side tags in Rawhide:

  $ koji list-tags | grep f34-build-side | wc -l
  145

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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] Fedora 34 Rawhide 20210203.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 34 Rawhide 20210203.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
python-blivet - 20210131.n.0: python-blivet-3.3.2-1.fc34.src, 20210203.n.0: 
python-blivet-3.3.2-2.fc34.src
pyparted - 20210131.n.0: pyparted-3.11.7-1.fc34.src, 20210203.n.0: 
pyparted-3.11.7-2.fc34.src
pykickstart - 20210131.n.0: pykickstart-3.32-1.fc34.src, 20210203.n.0: 
pykickstart-3.32-2.fc34.src
lorax - 20210131.n.0: lorax-34.7-1.fc34.src, 20210203.n.0: lorax-34.7-2.fc34.src
pungi - 20210131.n.0: pungi-4.2.7-2.fc34.src, 20210203.n.0: 
pungi-4.2.7-3.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210203.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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: Reading out the time zone on different architecures produces different results.

[Martin Gansser]

Thanks for your help.

Perhaps you can help me with another problem that exists with the testsuite on 
the ppc64le architecure [1] 

the error message is:
serializationinfo::testRangeCheck: ASSERTION at serializationinfo-test.cpp:561
exception of type std::range_error expected in siValue(si)

[1] https://kojipkgs.fedoraproject.org//work/tasks/8769/61188769/build.log

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

Heads-up: dropping Berkeley DB rpmdb write-support in rawhide

[Panu Matilainen]

Hey all,

Just woke up to the fact that F34 is about to be branched, and that we 
originally planned to phase out BDB rpmdb support to read-only in Fedora 
34 [1].


That's too close to comfort for me, and might be considered too late for 
other reasons too. So a slight change of plans, lets postpone this to 
F35, and handle this right away after F34 has been branched. Rpm >= 4.17 
which is to be expected later in F35 will not *have* read-write BDB 
support at all, so disabling it early gives folks a little of leeway 
where things can still be temporarily reverted if something unexpected 
breaks.


Should we file a separate system-wide change for this, or can we proceed 
on the basis that this was already accepted as a part of the sqlite 
change [1]?


- Panu -

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

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Marius Schwarz]

Am 02.02.21 um 22:53 schrieb Matthew Miller:

On Tue, Feb 02, 2021 at 10:20:03PM +0100, Marius Schwarz wrote:

And worth repeating: lookit this nice new functionality...

sudo dnf offline-upgrade download
sudo dnf offline-upgrade reboot



# dnf offline-upgrade
Kein solcher Befehl: offline-upgrade. Bitte /usr/bin/dnf --help verwenden.
It could be a DNF plugin command, try: "dnf install
'dnf-command(offline-upgrade)'" (failed too)

and there is no seperate dnf package for this cmd, at least i can't
see one adhoc.

It is part of the system-upgrade plugin, so

   sudo dnf install 'dnf-command(system-upgrade)'

will do it. I've created a PR for the package to add the missing virtual
provides:

https://src.fedoraproject.org/rpms/dnf-plugins-extras/pull-request/2



The rawhide installation did not have that plugin, my F32 system had 
it.. FTR those have been missing:


 python3-dnf-plugin-system-upgrade
 python3-dnf-plugins-extras-common


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