No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20220211.0):
ID: 1126373 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220211.0):
ID: 1126389 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
Il 11/02/22 20:24, Kevin Fenzi ha scritto:
> On Fri, Feb 11, 2022 at 11:33:13AM +, Mattia Verga via devel wrote:
>> Il 11/02/22 12:20, Florian Weimer ha scritto:
>>> * Mattia Verga via devel:
>>>
Il 11/02/22 10:41, Miro Hrončok ha scritto:
> On 11. 02. 22 10:12, Mattia Verga via devel
Are the changelogs for packages supposed to be ordered newest-to-latest
or the reverse? Some packages have the changelog one way, some the other…
I find this confusing, because I always start thinking "is the version
bump wrong in the changelog"?
On Sat, Feb 12, 2022 at 08:25:22AM +, Fedora R
On 09/02/2022 08:03, Mattia Verga via devel wrote:
Just being paranoid here: do we have any policy / automatism for
disabling "power" users (in packager group or like) which have been
inactive for long time?
Some maintainers don't have recent commits or Koji builds because other
Fedora contrib
On 09/02/2022 18:04, Mattia Verga via devel wrote:
For example, if someone pulls from src.fedoraproject.org a list of users
in the packagers group which have been inactive for a long time, check
if their email is inactive and if it has been made available for
claiming, then they claim the email a
On 11/02/2022 07:54, Zbigniew Jędrzejewski-Szmek wrote:
With 1500+ unused accounts it is just*too easy*
for someone to find a way to access one of the accounts in an unauthorized
way.
What they can do with this? Pushing a new update for the foo-bar
package? We have Bodhi against this.
In pa
On 11/02/2022 10:41, Miro Hrončok wrote:
They might have never even logged into src.fedoraproject.org
You don't need to be logged into src.fedoraproject.org or
account.fedoraproject.org to maintain packages. You can simply make
commits and send them to Bodhi using CLI tools.
--
Sincerely,
On Sat, Feb 12, 2022 at 11:46 AM Vitaly Zaitsev via devel
wrote:
>
> On 09/02/2022 08:03, Mattia Verga via devel wrote:
> > Just being paranoid here: do we have any policy / automatism for
> > disabling "power" users (in packager group or like) which have been
> > inactive for long time?
>
> Some
On 12/02/2022 12:16, Fabio Valentini wrote:
That's not true. You need to log in to src.fedoraproject.org at least
*once* to get group memberships synced over (including "packager").
True. But only once.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On Sat, Feb 12, 2022 at 12:00:11PM +0100, Vitaly Zaitsev via devel wrote:
> On 11/02/2022 07:54, Zbigniew Jędrzejewski-Szmek wrote:
> > With 1500+ unused accounts it is just*too easy*
> > for someone to find a way to access one of the accounts in an unauthorized
> > way.
>
> What they can do with
On 12/02/2022 12:32, Zbigniew Jędrzejewski-Szmek wrote:
All packages are "equal":
any package can ship any file, and in fact any package can execute scripts
*as root* during installation.
True.
Thus, if you are able to create a build that
is submitted as an update (i.e. either build it for r
Il 12/02/22 12:20, Vitaly Zaitsev via devel ha scritto:
> On 12/02/2022 12:16, Fabio Valentini wrote:
>> That's not true. You need to log in to src.fedoraproject.org at least
>> *once* to get group memberships synced over (including "packager").
> True. But only once.
True, but even if the user i
OLD: Fedora-36-20220210.n.0
NEW: Fedora-36-20220212.n.0
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 6
Dropped packages:0
Upgraded packages: 187
Downgraded packages: 1
Size of added packages: 75.11 MiB
Size of dropped packages:0 B
Size of
On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel wrote:
> > Thus, if you are able to create a build that
> > is submitted as an update (i.e. either build it for rawhide, or build it
> > for other releases and create a bodhi update), this is enough to wreak
> > havoc at
> > least
On Friday, 28 January 2022 00:43:07 CET Robert-André Mauchin wrote:
> On 1/24/22 01:30, Robert-André Mauchin wrote:
>
> > Hi,
> >
> > So I have an annoying bug that started near the beginnings of F35.
> > My papirus-icon-theme became very slow to install:
> > https://bugzilla.redhat.com/show_bug.
No missing expected images.
Failed openQA tests: 17/229 (x86_64), 12/161 (aarch64)
New failures (same test not failed in Fedora-36-20220210.n.0):
ID: 1126517 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/1126517
ID: 1126700 Test: aarch64 Server-
ild of vtk succeeded [1], and it looks
like the compose of F36 succeeded [2].
Steve
[0] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/3476205/
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1915642
[2] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20
roject.org/compose/branched/Fedora-36-20220212.n.0/
Alright - it is getting even more strange. On another (later) copr run [3], we
have the fedora-36-x86_64 chroot failing because it got
vtk-9.1.0-5.fc36.x86_64, while the fedora-36-ppc64le chroot managed to get
vtk-9.1.0-6.fc36.ppc64le. That
On Sat, 2022-02-12 at 14:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel wrote:
> > > Thus, if you are able to create a build that
> > > is submitted as an update (i.e. either build it for rawhide, or build it
> > > for other release
Kevin Fenzi wrote:
> As a release engineer trying to get a rawhide compose, I do find this a
> big deal. (Another f37 compose just failed because of this issue).
Well, as I already pointed out more than once, the real issue there is that
the Rawhide compose fails due to a broken dependency. This
Bringing this subthread to devel@ since apparently this has a wide impact...
On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson wrote:
>
> > This is great new for Fedora because I think it means we can use the normal
> > Fedora tools for building ARM images to create UEFI bootable images without
>
> Bringing this subthread to devel@ since apparently this has a wide impact...
>
> On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson wrote:
> >
> > > This is great new for Fedora because I think it means we can use the
> > > normal Fedora tools for building ARM images to create UEFI bootable
> > >
Hello Rust packagers,
I have prepared an update of the entire GTK-RS stack to the latest version:
https://copr.fedorainfracloud.org/coprs/decathorpe/gtk-rs-0.15/monitor/
I am planning to update these packages in Fedora Rawhide and 36, just
like GTK-RS 0.14 was only pushed to Fedora 35 and Rawhide
24 matches
Mail list logo
