If you're a Fedora package maintainer, we've got an exciting automation
solution for you!
At the beginning of the year, we announced a new feature called
pull_from_upstream that eases the process of bringing upstream releases
into Fedora. This feature can be easily configured directly in the dist-
> Hi,
>
> On Thu, Sep 14, 2023 at 11:12 PM Luya Tshimbalanga
>
> I don't see any reference to Python 3.12 there. The error is:
>
> In file included from /usr/include/epoxy/egl.h:46,
> from
> /builddir/build/BUILD/blender-3.6.2/intern/ghost/intern/GHOST_ContextEGL.hh:13,
>
On 9/14/23 15:50, Fabio Valentini wrote:
On Thu, Sep 14, 2023 at 2:42 PM Colin Walters wrote:
On Wed, Sep 13, 2023, at 1:44 PM, Matthew Miller wrote:
On Mon, Sep 11, 2023 at 09:20:09AM -0700, Adam Williamson wrote:
IIRC it was a condition of that proposal that we wind up on a hosted
version
What about hosted Gitea from gitea.com?
Gitea is fully open source, very popular in the self-hosting community and
their hosted offering would free up some of our precious infra team
resources.
Ondřej
Dne st 13. 9. 2023 19:45 uživatel Matthew Miller
napsal:
> On Mon, Sep 11, 2023 at 09:20:09AM
Hi all,
GNOME 45.0 upstream tarball date is this weekend and I'm coordinating
the downstream builds for F39 and rawhide.
A quick note where we are in the release schedule:
Fedora 39 Beta was declared GO yesterday and is going to ship with GNOME
45.beta. We have the 45.rc mega-update in Bodhi
(
W dniu 13.09.2023 o 17:53, Aoife Moloney pisze:
== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
changes and improvements over previous versions. For Fedora Linux, the
transition to KDE Plasma 6 will al
Am 15.09.23 um 07:43 schrieb Clement Verna:
At the risk of being controversial and a voice of the minority, I think
using GitHub would be beneficial for the Fedora project. In practice
already most of packagers have to use GitHub to collaborate with
upstream so it wouldn't be a tool to learn.
V Fri, Sep 15, 2023 at 09:22:46AM +0200, Laura Barcziova napsal(a):
> Once set up, here's how it works:
>
>-
>
>Upstream Release Monitoring creates a Bugzilla bug when new upstream
>versions are detected.
>-
>
>As a reaction to that, Packit:
>-
>
> automatically up
On Fri, 15 Sept 2023 at 11:37, Leon Fauster via devel <
devel@lists.fedoraproject.org> wrote:
> Am 15.09.23 um 07:43 schrieb Clement Verna:
>
> > At the risk of being controversial and a voice of the minority, I think
> > using GitHub would be beneficial for the Fedora project. In practice
> > alr
Ondřej Budai writes:
> What about hosted Gitea from gitea.com?
>
> Gitea is fully open source, very popular in the self-hosting community and
> their hosted offering would free up some of our precious infra team
> resources.
Gitea is ok from a UX perspective but it is still quite lacking from an
Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
automatically, but only a pull request is created in the particular
dist-git repo with the change of the *sources* reference. Once the PRs are
created, it is up to the maintainer to review these changes and, just after
that, mer
OLD: Fedora-Rawhide-20230914.n.0
NEW: Fedora-Rawhide-20230915.n.0
= SUMMARY =
Added images:2
Dropped images: 1
Added packages: 4
Dropped packages:0
Upgraded packages: 78
Downgraded packages: 0
Size of added packages: 563.07 KiB
Size of dropped packages:0
On Fri, Sep 15, 2023 12:53:21 +0200, Laura Barcziova wrote:
> Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> automatically, but only a pull request is created in the particular dist-git
> repo with the change of the sources reference. Once the PRs are created, it is
> up t
V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> automatically
Did you know that a license review must precede uploading to Fedora dist-git
lookaside cache? The reason is once the archive is uploaded, Fed
It might also be worth mentioning that both gitea and forgejo support
Github Actions [1][2]. I did not personally test them, but it might be
good for the familiarity and reuse of the maintained Github Actions
library. One missing thing are Github applications, but I don't think we
are using som
Hello maintainers!
Let me announce a new release of Mock v5.1 (the chroot build environment
manager for building RPMs).
Mock 5.1 further stabilizes the (now default) --use-bootstrap-image
feature, and adds a "fallback" mechanism which turns the feature OFF
if Podman can not be used. In case of t
Use whatever you like as I wont be migrating to the new infra!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/projec
OLD: Fedora-39-20230914.n.0
NEW: Fedora-39-20230915.n.0
= SUMMARY =
Added images:2
Dropped images: 4
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
Hi Petr,
we would like to avoid storing the archive in the lookaside cache before
approving but the problem is that the CI on the PR (mainly the scratch
build) does not work without the archive being in the lookaside cache
already. Once this becomes possible, we (=Packit) would be happy to do this
Vitaly Kuznetsov has offered https://github.com/rhboot/shim/pull/611
to fix the NVRAM entry generated by `add_boot_option(...)` in Shim's
`fallback.c`.
It is quite pervasive in that file to treat the size of the loaded
image arguments as `StrLen(arguments) * 2` (just search for
`StrLen(arguments)`
And maybe one more related note to this. We've been asked multiple
times to do auto-merges as well, but that's not really what we want to
do. We do want human approval during the process. (Automation can
suggest the change and once approved take care of the builds/updates,
but a single tool should
I was proposing some methods how to enable download of sources for e.g.
CI purposes here:
https://pagure.io/packaging-committee/issue/1132#comment-769233
But without too much success.
But of course, CI could also be improved to download the required
sources, if there is proper source URL.
On Fri, Sep 15, 2023 at 03:13:58PM +0200, Frantisek Lachman wrote:
> Hi Petr,
>
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cach
On Fri, 15 Sep 2023 15:13:58 +0200
Frantisek Lachman wrote:
> Hi Petr,
>
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cache
> a
Thanks Vít for the link!
I am honestly not sure how CI should do this (and don't want to be the
one who decides..;)
If CI does not need to have the source in the lookaside cache, Packit
does not need to store anything in the lookaside cache (that's a good
thing), but the maintainer can't be sure
On Fri, 15 Sep 2023 15:39:50 +0200
Frantisek Lachman wrote:
> Thanks Vít for the link!
>
> I am honestly not sure how CI should do this (and don't want to be the
> one who decides..;)
>
> If CI does not need to have the source in the lookaside cache, Packit
> does not need to store anything in
Thanks Dan and Daniel for the responses. You both are right. For our
defence, this is always setup by an existing Fedora user (=human).
I can't speak of rel-eng (and honestly don't know) how problematic
this "physical removal" on request is.
We can at least promote the licence check more
and provi
Thanks for working on this.
Are you certain that Blender failed to build in F39? As I reported in
[1], the build failure in question is due to openxr 1.0.29, which only
happened in F40.
Koschei remains green for F39[2], and there is a pending update rebuilt
against USD 23.08[3] (so please do
On Fri, 15 Sep 2023 16:02:04 +0200
Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
>
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal"
On Fri, Sep 15, 2023 at 04:02:04PM +0200, Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
>
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical rem
I quite like these checks but wouldn't it be better to have these as
part of Fedora CI? (Or any other CI system running on dist-git PRs?)
František
On Fri, Sep 15, 2023 at 4:13 PM Daniel P. Berrangé wrote:
> If you wanted to be especially helpful, perhaps Packit could compare
> the old and new t
Hello again,
just a quick update that Mock 5.1 has been deployed into Fedora Copr,
too. While on it, openSUSE Leap 15.3 is now EOL and 15.5 added.
Happy building!
Pavel
On pátek 15. září 2023 14:05:19 CEST Pavel Raiskup wrote:
> Hello maintainers!
>
> Let me announce a new release of Mock v5.1
Thanks for the info, Dan.
If this issue is not hit often,
I think it makes sense to ease the workflow for everyone
and go through this process if needed.
We can either inform people about how to do that
or do it for them.
(But sadly, we can't do the work of rel-eng.)
Otherwise, I think we can imp
Dne 15. 09. 23 v 13:18 Ankur Sinha napsal(a):
I guess it should be possible to make packit (or the-new-hotness?) run
licensecheck on the new sources and include that in the PR comment too,
perhaps also with a list of packages that depend on the one being
updated as an "impact check"?
It is almo
V Fri, Sep 15, 2023 at 03:13:22PM +0100, Daniel P. Berrangé napsal(a):
> I think it isn't too hard to make it acceptable, just stick a
> flag in the middle of your process that human has to acknowledge
> eg:
>
> 1. Release monitoring files the new BZ ticket (it already includes
> wording wa
Agree it should be in Fedora CI. Maybe it can be added to the Zuul CI,
or the default scratch build.
But to run Fedora CI, the source would need to be in the look-aside
cache. I think it would be ok that if the packit run is
pull_from_upstream that a licensecheck is run (after the spectool -g
On Fri, Sep 15, 2023 at 02:35:36PM +0100, Daniel P. Berrangé wrote:
> IIUC strictly speaking content must be validated for license compliance
> before it is present on any Fedora infrastructure. IOW, doing scratch
> builds in either Koji or Copr is also predicated on having permissible
> content un
Hello,
I started a build with `fedpkg build`, but after 43h and counting I
don‘t think it will finish anymore. Is there a way to terminate the
build? The build is
https://koji.fedoraproject.org/koji/taskinfo?taskID=106154761
Kai
___
devel mailing l
On Fri, 2023-09-15 at 16:02 +0200, Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
>
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" o
On Fri, 15 Sep 2023 19:01:07 +0200
"Kai A. Hiller" wrote:
> Hello,
>
> I started a build with `fedpkg build`, but after 43h and counting I
> don‘t think it will finish anymore. Is there a way to terminate the
> build? The build is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=10615476
"Kai A. Hiller" writes:
> Hello,
>
> I started a build with `fedpkg build`, but after 43h and counting I
> don‘t think it will finish anymore. Is there a way to terminate the
> build? The build is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=106154761
Look for this command:
dnf
One thing I find amusing about this list (which like some others is kind of a
long-running soap opera that happens to sometimes produce software as a side
effect) is that many times, I can see just two bits of information:
- The subject of the email
- The name of the person responding
And I bas
On Fri, Sep 15, 2023 at 1:28 PM Colin Walters wrote:
>
>
> My point is only partly about the HTML, but about the ecosystem surrounding
> it (CI is a really big one) but really the total user experience (account
> system, uptime, moving issues), etc.
>
> The bigger point I want to make here is th
On Fri, Sep 15, 2023, at 4:12 PM, Neal Gompa wrote:
> On Fri, Sep 15, 2023 at 1:28 PM Colin Walters wrote:
>>
>>
>> My point is only partly about the HTML, but about the ecosystem surrounding
>> it (CI is a really big one) but really the total user experience (account
>> system, uptime, moving
On Fri, Sep 15, 2023 at 8:23 PM Neal Gompa wrote:
> I will also point out the last time we followed RHEL into something,
> we got the modularity system. That itself is an indicator that
> inverting the relationship for decision-making is a bad idea.
In theory, I like the concept of modularity.
Adam Williamson wrote:
> Sure, it's not a problem *yet*. Microsoft is only just starting to
> crank up the enshittification machine...
Also in that vein, forced 2FA with no way to opt out:
https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2
Colin Walters wrote:
> Also of salient note, to the best of my knowledge the dist-git equivalent
> for Amazon Linux's isn't public.
Neither is the one for RHEL.
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
Kevin Kofler
___
d
Neal Gompa wrote:
> I am interested in learning where you're seeing screen sharing issues
> today.
Quoting myself from:
https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/7
I wrote there:
> As for screensharing on Wayland, that does not work with Falkon due
On 9/14/23 10:13, Adam Williamson wrote:
There is https://bugs.kde.org/show_bug.cgi?id=427060 and
https://bugs.kde.org/show_bug.cgi?id=449331 which is marked as a dupe
of it. Later comments on 427060 indicate some folks still have issues
with this.
My personal bugbear that I'd really like fixed
49 matches
Mail list logo
