Awesome!
On 1/8/20 10:09 AM, Artem Tim wrote:
vokoscreenNG packaged now. Nice to have such app available in official repos.
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a
F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21
vokoscreenNG packaged now. Nice to have such app available in official repos.
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a
F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21
___
devel mailing list --
Hi,
Thank you Igor for your review.
On Thu, Jan 2, 2020 at 10:52 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:
> I think it would be useful to mention in the change page that
> langpacks-core-* already depend on "good quality font". If that is
> already there, I apologize.
>
>
I
Once upon a time, Dave Dykstra said:
> And whoever maintains RPM Fusion would have to ensure somehow that all
> users of the rpm update within 30 days ... Seriously, I don't think
> anybody can put the data up on a server with no per-user authentication
> without violating the license.
Not
On Fri, 2019-12-13 at 17:13 -0800, Adam Williamson wrote:
> On Fri, 2019-12-13 at 11:17 -0800, Adam Williamson wrote:
> > It...*could* also work for non-candidate (i.e. nightly) Pungi 4
> > composes that have been garbage collected by retrieving the info from
> > PDC, but this thread has made me
https://pagure.io/389-ds-base/pull-request/50808
https://pagure.io/389-ds-base/issue/50790
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To
#8506 Planned Outage - Fedoraproject.org - 2020-01-15 21:00 UTC
Opened a day ago by smooge. Modified a day ago
Open
Planned Outage - Fedoraproject.org - 2020-01-15 21:00 UTC
There will be an outage starting at 2020-01-15 21:00UTC,
which will last approximately 4 hours.
To convert UTC to your
8505 Planned Outage - Fedora Build Systems - 2020-01-14 21:00 UTC
Opened a day ago by smooge. Modified 2 minutes ago
Open
Planned Outage - Fedora Build Systems - 2020-01-14 21:00 UTC
There will be an outage starting at 2020-01-14 21:00 UTC,
which will last approximately 4 hours.
To convert UTC
#8504 Planned Outage - Fedora Staging - 2020-01-13 21:00 UTC
Opened a day ago by smooge. Modified 4 hours ago
Open
There will be an outage starting at 2020-01-13 21:00UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
On Tue, Jan 7, 2020 at 1:48 PM Mark Otaris wrote:
>
> I intended to demonstrate that cgroups can be used to cause the kernel OOM
> killer to react appropriately and fast enough, implying that replacing the
> OOM killer is not necessary and that replacing it by a userspace OOM killer
> that does
I intended to demonstrate that cgroups can be used to cause the kernel OOM
killer to react appropriately and fast enough, implying that replacing the
OOM killer is not necessary and that replacing it by a userspace OOM killer
that does not account for cgroups can be undesirable. The exact same
https://pagure.io/389-ds-base/pull-request/50807
--
389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Sun, Jan 5, 2020, at 12:08 PM, Chris Murphy wrote:
> I've pretty much concluded Fedora is best off dropping the nested ext4
> in favor of plain squashfs, and using zstd.
Fedora CoreOS already uses zstd for squashfs:
And whoever maintains RPM Fusion would have to ensure somehow that all
users of the rpm update within 30 days ... Seriously, I don't think
anybody can put the data up on a server with no per-user authentication
without violating the license.
Dave
On Tue, Jan 07, 2020 at 05:31:48PM +0100, Kevin
On Tue, Jan 7, 2020 at 4:21 PM Kevin Kofler wrote:
> Kamil Paral wrote:
> > Well for the general user, everything is one-time. One download, one
> write
> > to USB, one install. Saving a minute in one step and adding it to a
> > different step doesn't really matter, it's the same sum overall
https://bugzilla.redhat.com/show_bug.cgi?id=1788685
Bug ID: 1788685
Summary: perl-autodie-2.30 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-autodie
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=1788685
--- Comment #1 from Upstream Release Monitoring
---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/P/PJ/PJF/autodie-2.30.tar.gz to
./autodie-2.30.tar.gz
--
You are receiving
On Tue, Jan 7, 2020 at 12:51 PM Nicolas Mailhot via devel
wrote:
>
> Yes, it worked because it was a press-friendly “fairy tale” story, not
> because of the cash spent on marketing (or because of the quality of
> the marketed product).
>
It's both, though. Having a good story is part of the
https://bugzilla.redhat.com/show_bug.cgi?id=1788680
Bug ID: 1788680
Summary: perl-Future-0.43 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Future
Keywords: FutureFeature, Triaged
Chris Murphy wrote:
> Even at 8% bigger it would be worth it. And probably 16%.
I disagree. We need to stop treating bloat like a feature.
And please see my other replies for why this is a particularly bad tradeoff
in this particular case.
> Gaining additional features, like on the fly
Gary Buhrmaster wrote:
> While not exactly the same, the measured increase in size
> by the Arch community for their packaging by moving from
> xz to zstd was ~0.8% (and gaining a huge reduction in CPU
> utilization at the decompress end).
I don't know what xz settings Arch was using, but in the
Chris Murphy wrote:
> It's untenable to consider ISO size alone. It is a legitimate concern, but
> it can't be reasonable to soak every single CPU, times thousands. You're
> willing to exchange less download time for longer install time and higher
> energy demand, but there are quite a lot of
Brian C. Lane wrote:
> Yes, according to the manpage it supports xattrs.
Does that include file capabilities and ACLs?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Hello Ankur,
Hello Community,
During the holidays I read a lot about the responsibilities and how to
build and maintain a package in Fedora and EPEL. I understand that many
people rely on the quality of packages maintained for a large time. And
that's the reason why I have to step down.
On 07. 01. 20 19:26, Fabian Affolter wrote:
Hi all,
I see more and more projects moving to use pyproject.toml and poetry.
They still are publishing tarballs at PyPI but they often miss the
documentation and/or the tests.
What is the approach to deal with upstream project which are using
On Tue, Jan 07, 2020 at 09:56:21AM +0100, Kevin Kofler wrote:
> Brian C. Lane wrote:
> > I agree with Chris here, I think we should make the switch to plain
> > squashfs unless someone can come up something dramatic that it will
> > break :)
>
> Does SquashFS support all the advanced features
On 2020-01-07 9:05 a.m., Petr Pisar wrote:
> On 2020-01-07, Digimer wrote:
>> I'm trying to create a local repo of an offline collection of systems.
>> When I try to install, I get:
>>
>>
>> No available modular metadata for modular package 'foo.arch', it cannot
>> be installed on the
Damian Ivanov wrote:
> Qt 5.14 is out since November.
According to:
https://wiki.qt.io/Qt_5.14_Release
final release was not until Dec 12.
Patience grasshopper.
-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Hi all,
I see more and more projects moving to use pyproject.toml and poetry.
They still are publishing tarballs at PyPI but they often miss the
documentation and/or the tests.
What is the approach to deal with upstream project which are using
poetry? Simply use PyPI as source?
Kind regards,
On Tue, Jan 7, 2020 at 9:58 AM Gary Buhrmaster
wrote:
>
> On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote:
>
> > I think increasing the size of the live images, also affecting the download
> > time and the time to write the image to media (even USB sticks are not
> > instant), to get a
On Tue, 2020-01-07 at 11:20 -0700, Chris Murphy wrote:
> On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote:
> > On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> > > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > > > I've pretty much concluded Fedora is best off
On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote:
>
> On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > > I've pretty much concluded Fedora is best off dropping the nested ext4
> > > in favor of plain squashfs, and
On 1/3/20 3:08 PM, Petr Viktorin wrote:
> The "python-sig" FAS group [3] is something slightly different. It's
> confusingly named (IIRC only groups with "-sig" in their name can get
> some permissions). It's there for people who want to fix Python-related
> issues in all the packages. Something
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote:
> Hi Kevin,
>
> I just noticed we didn't finish discussing the package rename proposal
> in related releng issue[1]:
>
> On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote:
> [...]
> > To change the status quo, two measures are
On Tue, Jan 07, 2020 at 09:19:47AM -0600, Michael Catanzaro wrote:
> On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote:
> >Try it. With a memory limit,
> >
> >podman run --rm -it --memory=1G fedora bash -c 'dnf install -y
> >stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm
> >100'
On Tue, 7 Jan 2020 at 19:03, Matthew Miller wrote:
>
> Red Hat has also always invested its marketing dollars in _product_; the
> sponsorship of Fedora is _mostly_ from an engineering side. I'd *like* to
> get more for these wider efforts, but in a very real way that Red Hat
> investment is like
On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > I've pretty much concluded Fedora is best off dropping the nested ext4
> > in favor of plain squashfs, and using zstd. It's not required to do
> > both, but the benefit is
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2020-01-08 from 18:00:00 to 19:00:00 GMT
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the
following:
#meetingname EPEL
#topic
On Tue, Jan 07, 2020 at 06:48:05PM +0100, Nicolas Mailhot via devel wrote:
> IBM could waste 10 times the money in marketing with less results, “Big
> Blue spending loads of cash” is not a coverage-worthy story.
Although to be clear if anyone from IBM is reading: _we'll take it_. :)
--
Matthew
On Tue, Jan 07, 2020 at 11:37:28AM -0600, Joe Doss wrote:
> > If anyone has a handy generous multi-millionaire up their sleeve,
> > please call Matt. :)
> *coughs* Red Hat...
Red Hat *does* contribute millions of dollars to Fedora annually in time,
hardware, and of course literal money.
Le mardi 07 janvier 2020 à 18:37 +0100, Clement Verna a écrit :
>
>
> On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel <
> devel@lists.fedoraproject.org> wrote:
> > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit :
> > >
> > > I'm far from having a satisfactory response to that,
On Di, 07.01.20 09:27, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - oomd currently polls some parameters in time intervals too,
> > still. They are working on getting rid of that too, so that
> > everything is event based
On Tue, Jan 07, 2020 at 09:33:55AM -0800, Adam Williamson wrote:
> > They had good marketing in the form of a billionaire publicly showering
> > cash around “in the public interest”. The press (especially the non-
> > technical press) loves this kind of story. Unfortunately, it’s not
> > something
On Tue, 2020-01-07 at 11:37 -0600, Joe Doss wrote:
> On 1/7/20 11:33 AM, Adam Williamson wrote:
> > If anyone has a handy generous multi-millionaire up their sleeve,
> > please call Matt. :)
>
> *coughs* Red Hat...
I *did* say "generous"
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:
> Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit :
> >
> > I'm far from having a satisfactory response to that, but I see two
> > fronts here. First, marketing. How does Ubuntu managed to be
On 1/7/20 11:33 AM, Adam Williamson wrote:
> If anyone has a handy generous multi-millionaire up their sleeve,
> please call Matt. :)
*coughs* Red Hat...
Joe
--
Joe Doss
j...@solidadmin.com
pEpkey.asc
Description: application/pgp-keys
___
devel
> > On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote:
> > > For me, the main challenge Fedora faces is **positioning**.
> > >
> > > Let me explain: (I don't have numbers but) in my (limited) experience,
> > > when seasoned sysadmins need to launch a new system, they usually
> > > think
On Tue, 2020-01-07 at 18:20 +0100, Nicolas Mailhot via devel wrote:
> Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit :
> > I'm far from having a satisfactory response to that, but I see two
> > fronts here. First, marketing. How does Ubuntu managed to be so
> > popular among
Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit :
>
> I'm far from having a satisfactory response to that, but I see two
> fronts here. First, marketing. How does Ubuntu managed to be so
> popular among less-experienced Linux users? I'm not sure, but I
> suspect that good marketing has
Hi everybody,
I've orphaned 5 packages that were previously maintained by the
Stewardship SIG, but which are now no longer required by any fedora
package:
- jboss-transaction-1.2-api
- jettison
- jetty-artifact-remote-resources
- jetty-assembly-descriptors
- jetty-test-policy
It should be safe
On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote:
> I think increasing the size of the live images, also affecting the download
> time and the time to write the image to media (even USB sticks are not
> instant), to get a one-time installation speedup is a very bad tradeoff.
While not exactly
It's untenable to consider ISO size alone. It is a legitimate concern, but it
can't be reasonable to soak every single CPU, times thousands. You're willing
to exchange less download time for longer install time and higher energy
demand, but there are quite a lot of other uses occurring that
https://bugzilla.redhat.com/show_bug.cgi?id=1783301
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
Vitaly Zaitsev via devel wrote:
> In this case geolite2 packages can be moved to RPM Fusion.
It would have to be in the nonfree section, and everything depending on it
directly or indirectly would also have to move from Fedora to RPM Fusion
nonfree.
Kevin Kofler
On 07.01.2020 16:16, Kevin Kofler wrote:
> To me, it looks crystal clear that the new licensing conditions are not
> acceptable for Fedora.
In this case geolite2 packages can be moved to RPM Fusion.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Tue, 7 Jan 2020 at 16:38, Matthew Miller wrote:
>
> On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote:
> > For me, the main challenge Fedora faces is **positioning**.
> >
> > Let me explain: (I don't have numbers but) in my (limited) experience,
> > when seasoned sysadmins need to
https://bugzilla.redhat.com/show_bug.cgi?id=1783301
--- Comment #1 from Xavier Bachelot ---
https://pagure.io/releng/fedora-scm-requests/issue/21108
https://pagure.io/releng/fedora-scm-requests/issue/21109
--
You are receiving this mail because:
You are on the CC list for the bug.
I asked the same thing.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JKYCD27AXOSZWVRQWOJ4NFNM7NNGM6SQ/#JKYCD27AXOSZWVRQWOJ4NFNM7NNGM6SQ
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Tue, Jan 7, 2020 at 8:55 AM Chris Murphy wrote:
>
> On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote:
> >
> > > For now, kernel developers have made it clear they do not care about
> > > user space responsiveness. At all. Their concern with kernel
> > > oom-killer is strictly with keeping
https://bugzilla.redhat.com/show_bug.cgi?id=1135626
Xavier Bachelot changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote:
>
> > For now, kernel developers have made it clear they do not care about
> > user space responsiveness. At all. Their concern with kernel
> > oom-killer is strictly with keeping the kernel functioning.
>
> This is false. The stated purpose of
https://bugzilla.redhat.com/show_bug.cgi?id=1783301
Xavier Bachelot changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
> On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote:
>
> Implicit in this is the idea that value should be captured at a secondary
> distribution
> layer. Implicit in this is the idea that distribution forks *need* to
> happen. But they
> don't.
>
> In fact, everyone here can work upstream
On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote:
> For me, the main challenge Fedora faces is **positioning**.
>
> Let me explain: (I don't have numbers but) in my (limited) experience,
> when seasoned sysadmins need to launch a new system, they usually
> think "Debian" as something
On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
wrote:
- oomd currently polls some parameters in time intervals too,
still. They are working on getting rid of that too, so that
everything is event based via PSI. Given their own focus on servers
it's not a primary goal, but still a
On Mon, Jan 06, 2020 at 08:27:41PM -0500, Neal Gompa wrote:
> At the minimum, democratizing Koji would make it easier for Teams to
> build their own stuff using any of the tools supported by Koji... Then
> it's a question of documentation of how to make custom media and
> describing things like
Dne 07. 01. 20 v 14:19 Tom Hughes napsal(a):
> On 07/01/2020 13:06, Fabio Valentini wrote:
>
>> - ruby is weird, packaging gems is a bit of a chore, upstream has many
>> knobs to fiddle with to make distro packaging hard (for example, not
>> including test sources in .gem files seems to be a
Neal Gompa writes:
> RPM does not use libffi at all.
My bad.. rpmbuild, through it's use of gdb, which requires python, which
requires libffi. So my naive use of mock to try to build a new version
of libffi and all of it's dependencies fail.
> That said, it's quite easy to do a
> rebuild of
Kamil Paral wrote:
> Well for the general user, everything is one-time. One download, one write
> to USB, one install. Saving a minute in one step and adding it to a
> different step doesn't really matter, it's the same sum overall (unless
> you pay considerable money for the extra downloaded
On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote:
Try it. With a memory limit,
podman run --rm -it --memory=1G fedora bash -c 'dnf install -y
stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100'
will use CPU but keep your system responsive. Without the memory limit
(this
Dave Dykstra wrote:
> I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages
> (e.g. geolite2-city-20191217) each month in order to distribute the free
> maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened
> down on the license for these data distributions
On Tue, Jan 07, 2020 at 01:13:02PM +0100, Florian Weimer wrote:
> > In support of that, I'd like to also have that page steer people into
> > tooling for creating new spins —- and I'd like to see us invest in and
> > rebuild the spin creation processes. (Particularly, I'd like spin releases
> > to
On Tue, Jan 7, 2020 at 11:23 am, Kamil Paral wrote:
In your example you forget that swap needs to filled almost to full
for early-oom to start reacting. That takes time during which the
system responsibility is abysmal. The UX difference happens only
after you've already suffered through a
On Tue, Jan 7, 2020 at 10:09 am, Benjamin Berg
wrote:
Even if that is the case, on F31 (with GNOME 3.34.2) we do place most
user processes into separate scopes[1]. This is not perfect, because
it
currently only affects processes launched by gnome-shell, gnome-
settings-daemon and
On Tue, Jan 07, 2020 at 02:28:46PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 07, 2020 at 03:18:16PM +0100, Pierre-Yves Chibon wrote:
> > On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote:
> > > Just to add my 2¢ here: I have experience with packaging stuff from
> > >
Le mardi 07 janvier 2020 à 14:06 +0100, Fabio Valentini a écrit :
>
> Conclusion: Some things could and should be improved
Yes, there are lots of shades of gray.
All recent package managers allow downloading stuff for use (or they'd
have no users).
Some manage to build things.
Some manage
On Tue, Jan 07, 2020 at 03:18:16PM +0100, Pierre-Yves Chibon wrote:
> On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote:
> > Just to add my 2¢ here: I have experience with packaging stuff from
> > many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and
> > with various
On Mon, 6 Jan 2020 at 18:28, Matthew Miller wrote:
>
> Hi everyone! Since it's a new year and a new decade [*], it seems like a
> good time to look forward and talk about what we want the Fedora Project to
> be in the next five and even ten years. How do we take the awesome
> foundation we have
On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote:
> Just to add my 2¢ here: I have experience with packaging stuff from
> many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and
> with various build systems (autotools, meson, CMake, etc.). The
> packaging burden is
On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote:
>
> I'd love to find a way to directly integrate the likes of gem, npm
> etc directly into our packaging rather than us having to repackage
> everything by hand but I just don't see any way of doing it without
> compromising what we do to the
On 2020-01-07, Digimer wrote:
> I'm trying to create a local repo of an offline collection of systems.
> When I try to install, I get:
>
>
> No available modular metadata for modular package 'foo.arch', it cannot
> be installed on the system
>
>
I guess the 'foo.arch' name is made up
On Tue, 7 Jan 2020 at 13:58, Miro Hrončok wrote:
>
> [...]
>
> For me, an ultimate success would be if upstream projects would actually use
> Fedora-family distros in their CI testing. And I don't mean that they would
> use
> Copr or packit to package RPM packages, or that they deploy their own
On Tue, 7 Jan 2020 at 13:28, Neal Gompa wrote:
>
> On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote:
> >
> > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
> > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
> > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
> > > >
>
FWIW, I am investigating the geolite2 license situation with Red Hat.
Thanks,
Tom
On Mon, Jan 6, 2020 at 4:45 PM Dave Dykstra wrote:
> I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages
> (e.g. geolite2-city-20191217) each month in order to distribute the free
> maxmind
On 07. 01. 20 14:32, Martin Kolman wrote:
On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote:
For me, an ultimate success would be if upstream projects would actually use
Fedora-family distros in their CI testing. And I don't mean that they would use
Copr or packit to package RPM packages,
On Tue, Jan 7, 2020 at 8:34 AM Martin Kolman wrote:
>
> On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote:
> > On 07. 01. 20 13:17, Neal Gompa wrote:
> > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote:
> > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
> > > > > Dne 06. 01.
On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote:
> On 07. 01. 20 13:17, Neal Gompa wrote:
> > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote:
> > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
> > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
> > > > > Le
On Tue, Jan 7, 2020 at 2:18 PM Miro Hrončok wrote:
>
> On 07. 01. 20 14:06, Fabio Valentini wrote:
> > - python / pypi works great for %build and %install, but until testing
> > with tox is automated in packaging macros, %check has to be specified
> > manually since upstream projects do different
On 07/01/2020 13:06, Fabio Valentini wrote:
- ruby is weird, packaging gems is a bit of a chore, upstream has many
knobs to fiddle with to make distro packaging hard (for example, not
including test sources in .gem files seems to be a common practice),
there's no canonical way of running test
On 07. 01. 20 14:06, Fabio Valentini wrote:
- python / pypi works great for %build and %install, but until testing
with tox is automated in packaging macros, %check has to be specified
manually since upstream projects do different things there.
generate_buildrequires also works nicely here.
No missing expected images.
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 7/155 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-Rawhide-20200106.n.0):
ID: 507832 Test: x86_64 KDE-live-iso desktop_printing
URL:
On Tue, Jan 7, 2020 at 1:31 PM Tom Hughes wrote:
>
> On 07/01/2020 12:22, Miroslav Suchý wrote:
> > Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
> >> The thing is that no matter how much you can manage to automate the
> >> creation of spec files for a given ecosystem, and I've never seen one
> >>
On 07. 01. 20 13:17, Neal Gompa wrote:
On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote:
On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
Handling those checks is where the
On Tue, Jan 07, 2020 at 12:30:25PM +, Tom Hughes wrote:
> On 07/01/2020 12:22, Miroslav Suchý wrote:
> >Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
> >>The thing is that no matter how much you can manage to automate the
> >>creation of spec files for a given ecosystem, and I've never seen one
Tom Hughes writes:
> On 07/01/2020 12:22, Miroslav Suchý wrote:
>> Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
>>> The thing is that no matter how much you can manage to automate the
>>> creation of spec files for a given ecosystem, and I've never seen one
>>> where the typical spec file
On 07/01/2020 12:22, Miroslav Suchý wrote:
Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
The thing is that no matter how much you can manage to automate the
creation of spec files for a given ecosystem, and I've never seen one
where the typical spec file doesn't need some manual tweaking, you
Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
> The thing is that no matter how much you can manage to automate the
> creation of spec files for a given ecosystem, and I've never seen one
> where the typical spec file doesn't need some manual tweaking, you
> are still going to hit the fundamental
On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote:
>
> On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
> > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
> > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
> > >
> > > > Handling those checks is where the packaging toil is
* Matthew Miller:
> In support of that, I'd like to also have that page steer people into
> tooling for creating new spins —- and I'd like to see us invest in and
> rebuild the spin creation processes. (Particularly, I'd like spin releases
> to be decoupled from the main OS release, and for those
On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
> Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
> > Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
> >
> > > Handling those checks is where the packaging toil is (that is, as long
> > > as Fedora is a deployment project). It is
1 - 100 of 133 matches
Mail list logo
