On Mon, Aug 1, 2022 at 8:56 PM Miro Hrončok wrote:
> xs petersen
Thanks, I finally retired this one already.
Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
On Mon, Aug 01, 2022 at 03:43:39PM -0700, Kevin Fenzi wrote:
> On Mon, Aug 01, 2022 at 03:04:50PM +0200, Miro Hrončok wrote:
> > On 25. 07. 22 17:57, Kevin Fenzi wrote:
> > > 21713 builds have been tagged into f37, there is currently 1144 failed
> > > builds that need to be addressed by the package
On Mon, Aug 01, 2022 at 03:04:50PM +0200, Miro Hrončok wrote:
> On 25. 07. 22 17:57, Kevin Fenzi wrote:
> > 21713 builds have been tagged into f37, there is currently 1144 failed
> > builds that need to be addressed by the package maintainers. FTBFS bugs
> > will be filed shortly.
>
> Is there any
On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher
wrote:
> On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal
> wrote:
> >
> > Hi,
> >
> > Later today, I'll be starting with rebuilds of packages depending on
> icu. The rebuilds will take place in f37-build-side-55935 for all packages
> returned b
Looks like the License: field is limited to 70 characters if I am reading this
correctly:
https://github.com/rpm-software-management/rpm/blob/2b5b271b0e013c1b023df7f5775a59cb4078d5f5/docs/manual/spec.md#license
___
devel mailing list -- devel@lists.fedor
Next week, I will update the z3 package to version 4.10.2, which
entails an soname bump. I will rebuild opam, which is the only
package that depends on the library. Packages that use z3 via the
command line should not be affected adversely.
--
Jerry James
http://www.jamezone.org/
___
On Mon, 2022-08-01 at 18:13 +0200, Marek Kasik wrote:
> Hi,
>
> I plan to rebase poppler to 22.08.0 once it is available. The release
> usually happens at the beginning of month so I'm waiting for it now.
> Once it is ready, I'll build it in a side tag and will post it here.
> libreoffice
Th
On Mon, Aug 1, 2022 at 1:51 PM Maxwell G wrote:
>
> Do Callway > SPDX license changes where there's a clear mapping and no other
> additions or removals still have to be announced? That wasn't my
> understanding.
My understanding of this rule/expectation is that it does not have
anything direct
Marek Kasik wrote:
> I plan to rebase poppler to 22.08.0 once it is available. The release
> usually happens at the beginning of month so I'm waiting for it now.
> Once it is ready, I'll build it in a side tag and will post it here. I
> plan to merge the side tag with buildroot next week before bra
Do Callway > SPDX license changes where there's a clear mapping and no other
additions or removals still have to be announced? That wasn't my understanding.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
signature.asc
Description: PGP signature
___
On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal wrote:
>
> Hi,
>
> Later today, I'll be starting with rebuilds of packages depending on icu. The
> rebuilds will take place in f37-build-side-55935 for all packages returned by
> sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list attac
I am preparing to update a batch of packages’ License tags to SPDX, with
License field changes as reported below.
The License field for the agenda package will be updated from an
effective license “GPLv3+” to “GPL-3.0-or-later AND GPL-2.0-or-later AND
On Mon, 1 Aug 2022 at 12:38, Richard Fontana wrote:
> Björn Persson:
>
> > Does that also apply to licenses that explicitly say how they may be
> > combined? Are we supposed to write "GPL-3.0-or-later AND
> > GPL-2.0-or-later AND LGPL-3.0-or-later AND GPL-3.0-only" or do those
> > still combine i
Michael Catanzaro:
> Even that would be an unreasonable effort. I only look at the output of
> fedora-review's license check if the source project is small and the
> output looks readable. For any complex project, it's beyond what humans
> can plausibly handle.
I'm hoping we will soon provide s
Björn Persson:
> Does that also apply to licenses that explicitly say how they may be
> combined? Are we supposed to write "GPL-3.0-or-later AND
> GPL-2.0-or-later AND LGPL-3.0-or-later AND GPL-3.0-only" or do those
> still combine into GPL-3.0-only?
They don't "combine". The idea that they comb
> Am 31.07.22 um 18:57 schrieb Richard Fontana:
> I do not agree
> with this view and consider this decision not to be helpful.
>
> These licenses might not be "commonly used", but if they are used, these
> are the controversal ones, that need to be looked into, exactly because
> they "not commo
Hi,
I plan to rebase poppler to 22.08.0 once it is available. The release
usually happens at the beginning of month so I'm waiting for it now.
Once it is ready, I'll build it in a side tag and will post it here. I
plan to merge the side tag with buildroot next week before branching.
Packages
Kevin Kofler via devel wrote:
> Now you have to compare every word of the MIT license
> with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and
> then figure out which one it actually is. If it is even one of these and not
> some random mix of several variants (one sentence from
Stephen Smoogen writes:
> On Mon, 1 Aug 2022 at 07:45, Dusty Mabe wrote:
>
>>
>>
>> On 7/29/22 12:05, Peter Robinson wrote:
>> >> Looks like dnf makecache is uses a lot more memory, causing issues on
>> >> smaller systems/containers.
>> >>
>> >> F34:
>> >>
>> >> Metadata cache created.
>> >> 1.5
On Wed, Jul 20, 2022 at 4:24 PM Mamoru TASAKA
wrote:
> Vitaly Zaitsev via devel wrote on 2022/07/11 2:43:
> 0ad FTBFS on f37 due to different issue from fmt change - scratch build
> for F-37 shows virtualenv related
> issue - perhaps due to python3.11 changes, and scratch build for F-36
> shows s
Dne 01. 08. 22 v 14:55 Miro Hrončok napsal(a):
rubygem-coffee-rails jaruga, ruby-packagers-sig, vondruch
Dependency on coffee-rails is removed from Ruby on Rails since:
https://github.com/rails/rails/commit/4838c1716a0340137d858fab49bf460e23be5a4b
https://github.com/rails/rails/com
On Mon, Aug 1, 2022, at 6:51 AM, Kamil Paral wrote:
>
> I suppose Anaconda would have to be involved, detect encrypted partitions and
> provide a hint when the bootloader is created. It would be a static solution,
> far from ideal, but arguably better than the current state.
I think a GRUB pa
On Mon, Aug 1 2022 at 12:46:08 PM +0100, Daniel P. Berrangé
wrote:
I'm not saying a human would literally open each file manually. Tools
like 'licensecheck' can automate scanning and reporting from license
headers. Packagers should sanity check its output and examine any
cases
where it failed.
On 20/07/2022 16:22, Mamoru TASAKA wrote:
33 pkgs are now using fmt-9 (built successfully with some modification)
on rawhide tree
Only 1 package still uses fmt8 - 0ad .
I think I should retire fmt8 before the F37 is branched.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 25. 07. 22 17:57, Kevin Fenzi wrote:
21713 builds have been tagged into f37, there is currently 1144 failed
builds that need to be addressed by the package maintainers. FTBFS bugs
will be filed shortly.
Is there any place we can track the progress for this?
We need to link ~70 bugzillas to
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (next
week).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
The packages in
On Mon, 1 Aug 2022 at 07:45, Dusty Mabe wrote:
>
>
> On 7/29/22 12:05, Peter Robinson wrote:
> >> Looks like dnf makecache is uses a lot more memory, causing issues on
> >> smaller systems/containers.
> >>
> >> F34:
> >>
> >> Metadata cache created.
> >> 1.51user 0.15system 0:12.01elapsed 13%CPU
On Mon, Aug 01, 2022 at 01:28:03PM +0200, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > I do expect Fedora reviewers to do more than just look at a handful of
> > source files though. For any package review, the header of every source
> > file should checked. Random sampling is not
On 7/29/22 12:05, Peter Robinson wrote:
>> Looks like dnf makecache is uses a lot more memory, causing issues on
>> smaller systems/containers.
>>
>> F34:
>>
>> Metadata cache created.
>> 1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata
>> 162440maxresident)k
>> 144inputs+56outputs (
On Mon, Aug 1, 2022 at 4:28 AM Kevin Kofler via devel
wrote:
>
> Daniel P. Berrangé wrote:
> > I do expect Fedora reviewers to do more than just look at a handful of
> > source files though. For any package review, the header of every source
> > file should checked. Random sampling is not sufficie
Daniel P. Berrangé wrote:
> I do expect Fedora reviewers to do more than just look at a handful of
> source files though. For any package review, the header of every source
> file should checked. Random sampling is not sufficient to identify the
> exceptions which do occur often, and are not usuall
OLD: Fedora-Rawhide-20220731.n.1
NEW: Fedora-Rawhide-20220801.n.0
= SUMMARY =
Added images:0
Dropped images: 1
Added packages: 0
Dropped packages:48
Upgraded packages: 39
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:5.52 MiB
On Mon, Aug 01, 2022 at 12:44:13PM +0200, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > In order to perform the simplification that Fedora previously used, it
> > was neccessary to first know what the full license list was. From that
> > full list some elements could be eliminated i
Zammis Clark wrote:
> > It doesn't help that Microsoft does not embed the name of the party
> who submitted an UEFI driver for signing in the signature itself.
>
> Microsoft does do this; it's in an authenticated attribute with OID
> 1.3.6.1.4.1.311.2.1.12, aka "SPC_SP_OPUS_INFO_OBJID", it's doc
On Fri, Jul 29, 2022 at 2:32 PM Chris Murphy
wrote:
> On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote:
>
> Currently there is this (insufficient, of course):
>
> https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-be-booted-from-the-grub-boot-menu/20612
>
>
> Looks pre
Richard Fontana wrote:
> But also even license compatibility issues isolated to a particular
> package have mostly been ignored or treated as unimportant for a variety
> of practical, policy, interpretive and doctrinal reasons that are really
> not specific to Fedora but found in other LInux distri
Daniel P. Berrangé wrote:
> In order to perform the simplification that Fedora previously used, it
> was neccessary to first know what the full license list was. From that
> full list some elements could be eliminated if considered to be subsumed
> by another license in the list.
Uh no, it was suf
On 31/07/2022 20:42, Ralf Corsépius wrote:
Provocant question: Do you want contributors to contact redhat-legal in
such cases, as we were required to do in the early days of Fedora?
To me, this reads as a pretty nasty regression in Fedora's workflow,
which should be reconsidered/reverted.
+1
> It doesn't help that Microsoft does not embed the name of the party
who submitted an UEFI driver for signing in the signature itself.
Microsoft does do this; it's in an authenticated attribute with OID
1.3.6.1.4.1.311.2.1.12, aka "SPC_SP_OPUS_INFO_OBJID", it's documented as
part of Office do
On Sat, Jul 30, 2022 at 05:51:34PM +0200, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > New guidance on “effective license” analysis
> >
> >
> > Many software packages consist of code with different free and open
> > source licenses. Previou
Hi,
Later today, I'll be starting with rebuilds of packages depending on icu.
The rebuilds will take place in f37-build-side-55935 for all packages
returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
attached at the end of the message).
Please, if you're going to make changes
* Ralf Corsépius:
> Am 31.07.22 um 18:57 schrieb Richard Fontana:
>> There are so few non-legacy, today-commonly-used,
>> generally-accepted-as-FOSS licenses that are not viewed as
>> GPLv3-compatible that I think it might be better for Ansible to just
>> list those (the only one I can think of is
42 matches
Mail list logo
