Oh look, that's my copr. No complaints here! :)
(I'd have taken it myself, but didn't know if I'd have time to commit to it if
it broke.)
--
Ed Marshall
Felix qui potuit rerum cognoscere causas.
https://esm.logic.net/
September 27, 2024 at 8:31 AM, "Clemens Lang" mailto:cll...@redhat.com?to
On čtvrtek 26. září 2024 15:35:27, SELČ Pavel Raiskup wrote:
> Hello maintainers!
>
> I'm glad to announce the release of Mock v5.7, the chroot build
> environment manager for building RPMs!
>
> This update introduces a new mode for "hermetic" builds, a new
> `--scrub-all-chroots` option to help
On Fri, Sep 27, 2024 at 5:50 AM Michael J Gruber wrote:
>
> Am Fr., 27. Sept. 2024 um 11:33 Uhr schrieb Florian Weimer
> :
> >
> > Do you see any problems if glibc starts using /usr/etc/services if
> > /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc
> > and so on. It's a
Dne 27. 09. 24 v 4:01 odp. Ben Beasley napsal(a):
The list of packages without SPDX, packages-without-spdx-final-maintainers.txt, seems suspicious. It has quite a few
packages I maintain that seem perfectly fine to me.
NiaAML-GUI has:
# SPDX
License: MIT
and a commit/ch
> Out of curiosity, where do you use it?
I used it for the hare package I was working on:
https://copr.fedorainfracloud.org/coprs/dridi/harelang/packages/
I have locally removed the bootstrap step but haven't had enough spare
time since to realign the sample of packages I was working with.
Drid
> > NiaAML-GUI warning: valid as old and new and no changelong entry, please
> > check
python-funcparserlib was probably still showing up for the same
reason, I just went through a review again and this time added a
changelog entry.
Dridi
--
___
devel
OLD: Fedora-41-20240926.n.0
NEW: Fedora-41-20240927.n.0
= SUMMARY =
Added images:11
Dropped images: 2
Added packages: 2
Dropped packages:0
Upgraded packages: 83
Downgraded packages: 0
Size of added packages: 205.48 KiB
Size of dropped packages:0 B
Size of
Hi just for update. I've created the script and it seems to be working
correctly.
https://github.com/rhinstaller/localed-x11-sync
Now, I need:
- create a user systemd service
- package that to Fedora
- enable this package in livesys-scripts on fedora-kickstarts
Best Regards,
Jirka
On 17. 09.
Hi,
I’m planning to unorphan dovecot-fts-xapian.
Upstream seems to be maintained, I have the latest version building locally,
and I’m also apparently not the only person interested given there’s a recent
COPR [1] for it.
Unless somebody complains, I’ll build new versions later today.
[1]:
Once upon a time, Michal Konecny said:
> release-monitoring.org never added packages from Fedora
> automatically. If they are there somebody else must have already add
> them. There was an idea to integrate release-monitoring.org to
> package
> workflow, but this was never implemented.
>
> You ne
On Fri, 2024-09-27 at 13:13 +0200, Fabio Valentini wrote:
> Hi all,
>
> It's that time of the year again - pointing out packages that are at
> a
> lower version in Fedora 41 (branched) than Fedora 40 (stable).
> For those that are just obviously missing unintentionally, I plan to
> submit the miss
On Fri, Sep 27, 2024 at 4:23 PM Sérgio Basto wrote:
>
> On Fri, 2024-09-27 at 13:13 +0200, Fabio Valentini wrote:
> > Hi all,
> >
> > It's that time of the year again - pointing out packages that are at
> > a
> > lower version in Fedora 41 (branched) than Fedora 40 (stable).
> > For those that are
I second Ben's findings, all of my packages have been migrated with a
commit message saying "Review the License tag according to the SPDX
standard" and with an added "# SPDX" comment if there was no change of
the string. The automation should not report any of those.
Karolina
On 9/27/24 16:01
Hello Łukasz,
On Fri, Sep 27, 2024 at 1:16 PM Łukasz Posadowski
wrote:
>
> I tried to rewrite SPEC from Feora 40 and build it for fun. And it's no
> fun. (-:
I was almost certain.
> CentOS 10 is missing quite a few dependencies in EPEL. RHEL 9 has almost
> all of them, with the exception of py
On 27. 09. 24 13:13, Fabio Valentini wrote:
- gimp3-0:2.99.19^20240916gitca9d57a417-1.fc40 >
gimp3-0:2.99.19^20240824git74bbe26918-2.fc41
Looks like Fedora 41 has an older snapshot.
The package was retired in Rawhide, but not in Fedora 41, so the fact
that it's still in Fedora 41 is likely unint
The list of packages without SPDX,
packages-without-spdx-final-maintainers.txt, seems suspicious. It has
quite a few packages I maintain that seem perfectly fine to me.
NiaAML-GUI has:
# SPDX
License: MIT
and a commit/changelog in its history entitled “Clarify that Licens
On Fri, Sep 27, 2024 at 8:30 AM Richard W.M. Jones wrote:
>
> We wanted to build pesign so we can automatically trigger RISC-V
> builds, since for some reason (I guess related to this) it hasn't been
> built for f42 & f41. But ...
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=124051163
We wanted to build pesign so we can automatically trigger RISC-V
builds, since for some reason (I guess related to this) it hasn't been
built for f42 & f41. But ...
https://koji.fedoraproject.org/koji/taskinfo?taskID=124051163
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people
On Fri, Sep 27, 2024 13:13:15 GMT, Fabio Valentini wrote:
>
> - nest-0:3.8-1.fc40 > nest-0:3.7-5.fc41
>
> Package was updated to 3.8 on Rawhide, Fedora 40, and 39, but Fedora
> 41 was missed.
>
> - python-rstcheck-core-0:1.2.1-1.fc40 > python-rstcheck-core-0:1.1.1-5.fc41
>
> This one was update
Hi all,
It's that time of the year again - pointing out packages that are at a
lower version in Fedora 41 (branched) than Fedora 40 (stable).
For those that are just obviously missing unintentionally, I plan to
submit the missing builds and bodhi updates later today.
As for those updates that are
Announcing the creation of a new nightly release validation test event
for Fedora 41 Branched 20240927.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
On 2024-09-20 at 03:27 +0200, Alexander Ploumistos wrote:
> Hello,
>
> Would anyone be interested in building and maintaining input-remapper
> in EPEL?
> I got a request for that earlier today[1], but as I wrote in the bug
> report, I haven't been using RHEL for a while now and I haven't kept
> u
* Colin Walters:
> On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote:
>> Do you see any problems if glibc starts using /usr/etc/services if
>> /etc/services does not exist?
>
> Please avoid having projects unconditionally read `/usr/etc`
> because on ostree based systems `/usr/etc/services`
Am Fr., 27. Sept. 2024 um 11:33 Uhr schrieb Florian Weimer :
>
> Do you see any problems if glibc starts using /usr/etc/services if
> /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc
> and so on. It's already used on openSUSE, apparently.
>
> And alternative proposal was to
Hot news:
- I am going through "neither Callaway nor SPDX" license formulas. I submitted dozens PR for your packages. And beside
obvious typos or partial conversion I see cases where maintainers use SPDX id of license. This is not enough the license
id must have SPDX id **and** must be on fedor
On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote:
> Do you see any problems if glibc starts using /usr/etc/services if
> /etc/services does not exist?
Please avoid having projects unconditionally read `/usr/etc`
because on ostree based systems `/usr/etc/services` will always
exist; we use
Do you see any problems if glibc starts using /usr/etc/services if
/etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc
and so on. It's already used on openSUSE, apparently.
And alternative proposal was to use /usr/share/services (which I really
dislike), or /usr/share/nss/ser
27 matches
Mail list logo
