On Sat, 2019-10-19 at 00:11 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Eh. I don't think it's a particularly bad hack at all. It's simple,
> > labelled, we know what it does, and it's inherently limited (it'll
> > never do anything outside of an upgrade to F31).
>
> That's exactly wha
Le ven. 18 oct. 2019 à 22:44, Robert-André Mauchin a écrit :
>
> On Friday, 11 October 2019 16:10:55 CEST you wrote:
> > Hello,
> >
> > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> > 2.0.0 to libdav1d.so.3.0.0.
> > I will be updating it next week on F31/32, consumer
Missing expected images:
Soas live x86_64
Failed openQA tests: 2/31 (x86_64)
ID: 472351 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/472351
ID: 472359 Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedorapr
On 19. 10. 19 0:30, Kevin Fenzi wrote:
Can I make a strong suggestion/plea here?
Could you meet with the folks working on rawhide multibuild gating and
confirm all that process works with your change and then modify your
change to just say 'requires multibuild rawhide gating' and only include
in
Can I make a strong suggestion/plea here?
Could you meet with the folks working on rawhide multibuild gating and
confirm all that process works with your change and then modify your
change to just say 'requires multibuild rawhide gating' and only include
in your change the things that are over/abo
Adam Williamson wrote:
> Eh. I don't think it's a particularly bad hack at all. It's simple,
> labelled, we know what it does, and it's inherently limited (it'll
> never do anything outside of an upgrade to F31).
That's exactly what makes this such a bad hack in my eyes. It "fixes" one
particular
3) We need to get the policy I described above written onto -stone
> tablets- the Packaging Guidelines and then we need to go and make any
> stream that isn't compliant with it a non-default stream.
>
Thank you. If we want to use default streams, then we indeed need a strict
policy on how they are
# F31 Blocker Review meeting
# Date: 2019-10-21
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 2 proposed Final blockers and 4 proposed Final freeze
exception to review, so let's have a Fedora 31 blocker review meeting
on Monday!
If you have time today,
Hi folks! I'm proposing we cancel the QA meeting for Monday. Once again
I don't think there's anything urgent right now and we're focused on F31
release testing right now (hopefully this will be the last week and
we'll sign off the release). There will be a blocker review meeting.
If you're aware
On Fri, 2019-10-18 at 16:25 -0400, Robbie Harwood wrote:
> Christopher Engelhard writes:
>
> > On 18.10.19 17:21, Robbie Harwood wrote:
> >
> > > While you're right that the solutions from source distros (i.e., NixOS
> > > and Gentoo) would be very hard to adapt, binary distros have also solved
On Fri, 2019-10-18 at 21:19 +0200, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > Actually:
> > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166
>
> Ewww! This kind of hacks should NEVER be accepted in a production
> distribution!
Eh. I don't think it's a particularly bad ha
On Friday, 11 October 2019 16:10:55 CEST you wrote:
> Hello,
>
> Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> 2.0.0 to libdav1d.so.3.0.0.
> I will be updating it next week on F31/32, consumers of these libraries
> (ffmpeg, xine-lib, vlc) will need to rebuild their p
On Fri, Oct 18, 2019 at 09:19:15PM +0200, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > Actually:
> > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166
>
> Ewww! This kind of hacks should NEVER be accepted in a production
> distribution!
>
> This hack will also NOT fix the i
Christopher Engelhard writes:
> On 18.10.19 17:21, Robbie Harwood wrote:
>
>> While you're right that the solutions from source distros (i.e., NixOS
>> and Gentoo) would be very hard to adapt, binary distros have also solved
>> this problem in different ways. I'm most familiar with Debian's
>> s
Hi Everyone,
Just an FYI, there was a dead link contained in the update - I send these
updates to both internal and external mailing list and that one was for
internal audiences only.
It was an internal briefing on CentOS Streams for staff that had missed the
public announcements and just contai
On Fri, Oct 18, 2019 at 09:13:22PM +0200, Kevin Kofler wrote:
> This would be a lot less of an issue if we were more actively promoting the
> respins that are already being done.
Yeah, this is a Fedora Council goal -- we'd like for that SIG to easily be
able to make them in infrastructure, and th
Miro Hrončok wrote:
> Actually:
> https://github.com/rpm-software-management/dnf-plugins-extras/pull/166
Ewww! This kind of hacks should NEVER be accepted in a production
distribution!
This hack will also NOT fix the issue for users like me who use dnf directly
rather than the system-upgrade pl
Adam Williamson wrote:
> The other issue is that it's *less bad* for a bad update to get out as
> a 0-day update than it is for it to be in the frozen compose set. Bugs
> that get baked into the live images or the installer are there forever.
> A bug that only goes out in an update can be replaced
We will try again for a 29 October release.
Action summary
Accepted blockers
-
1. distribution — Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed —
MODI
gmemusage is a tool to show memory usage per userspace application.
top can show low memory state.
I remember gmemusage from the SGI days and remember using it on Linux
too, but currently
yum whatprovides */gmemusage
claims there are No Matches Found. Where did you get your gmemusage from?
* Steve Grubb:
>> We certainly do not support building eBPF programs against glibc
>> headers. There is no eBPF port of glibc, after all.
>
> Suricata made it through the Debian/Ubuntu build systems. So, that
> leaves me trying to figure out how push this through ours since other
> distros did it
https://fedoraproject.org/wiki/Changes/OnDemandSideTags
see also:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4AS3PN23TOCBROA4RZN4TNDBZOP4VE2G/
= On-demand Side Tags =
== Summary ==
Allow on-demand side tags, and allow packagers to a) tag whatever rpms
as
On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote:
>
> > Or, even better (or worse): Sombody installs GIMP via GNOME
> > Software,
> >
> > and under the hood, dnf does its magic and installs gimp from the
> >
> > module, which might depend on another, even non-default module,
> > etc.
> >
On Friday, October 18, 2019 9:59:11 AM EDT Chris Adams wrote:
> Once upon a time, Tom Hughes said:
>
> > Well I imagine clang will define it when targetting x86_64 output
> > but in this case he is targetting BPF output instead.
> >
> > Adding -D__x86_64__ to the command line may be the quickest
Did you check the following?
https://patchwork.ozlabs.org/patch/870656/
https://code.forksand.com/oisf/suricata/commit/7906c521cdde5b1d0eb3ce379b8e343c3055653f
Iñaki
On Fri, 18 Oct 2019 at 15:22, Steve Grubb wrote:
>
> On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote:
> > * Steve
Hi everyone,
Welcome to the CPE team weekly project update mail!
*Background:** The Community Platform Engineering group is the Red Hat team
combining IT and release engineering from Fedora and CentOS. Our goal is to
keep core servers and services running and maintained, build releases, and
oth
On 18. 10. 19 17:48, Adam Williamson wrote:
On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
As things stand I'm reasonably confident we'll be able to Go next week,
I don't see a fix for the module upgrade path blocker in sight any time
soon.
There are three via
On 18.10.19 17:21, Robbie Harwood wrote:
> While you're right that the solutions from source distros (i.e., NixOS
> and Gentoo) would be very hard to adapt, binary distros have also solved
> this problem in different ways. I'm most familiar with Debian's
> solution (virtual packages[2], provides:,
Announcing the creation of a new nightly release validation test event
for Fedora 31 Branched 20191018.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 Fri, Oct 18, 2019 at 11:43 AM Randy Barlow
wrote:
>
> On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote:
> > Obviously we
> > can't use their code wholesale without migrating to APT, but as you
> > say,
> > the goal is to derive inspiration.
>
> But yeah as you say here, my original point
I would also like to throw my name in the pot for FOSDEM; it would be a
great time to share and promote the Fedora Amateur Radio Sig that has been
recently getting a makeover. I'd be glad to help with setup/tear-down as
well.
Geoff Marr
IRC: coremodule
On Fri, Oct 18, 2019 at 7:55 AM Igor Gnaten
On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > As things stand I'm reasonably confident we'll be able to Go next week,
>
> I don't see a fix for the module upgrade path blocker in sight any time
> soon.
There are three viable ones proposed in the bug, it's ju
On Fri, 2019-10-18 at 07:18 +, Leigh Scott wrote:
> > On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote:
> >
> > I mean, in the end it would be self-defeating, because the high chance
> > that it would introduce more problems would just mean we'd need to
> > freeze again for longer.
> >
>
On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote:
> Obviously we
> can't use their code wholesale without migrating to APT, but as you
> say,
> the goal is to derive inspiration.
I honestly think it should be on the table to consider switching to a
different packaging technology than rpm/dn
Stephen John Smoogen writes:
> On Thu, 17 Oct 2019 at 14:15, Randy Barlow
> wrote:
>
>> Or better, can we employ a solution that another distribution has
>> developed?
>
> Not without using their packaging system, their build system and their
> other design choices. Working out slots would mean
Hello Packagers,
As some of you might not have been aware, the Stewardship SIG has been
busy keeping the Java stack in fedora alive and working. We're now
left with 0 build failures on all current branches of fedora for our
235 packages, and no open FTBFS / FTI or known security issues.
We've als
On Fri, Oct 18, 2019 at 01:03:24PM +0200, Lukas Ruzicka wrote:
> Exactly ... this is what I believe, too. I think that Fedora users put
> Fedora on their desktops and laptops to be creative in many ways of
> creativity. Some make make music, some enhance pictures, some model in
> Blender, cut video
On Thu, Oct 17, 2019 at 11:02:51PM -0700, Adam Williamson wrote:
> We do tweak the release schedule every so often, right now the freeze
> periods are fairly long compared to the historical average. I do think
> that's given us a benefit in terms of how little slippage we've had for
> the last few
On 18/10/2019 14:59, Chris Adams wrote:
Once upon a time, Tom Hughes said:
Well I imagine clang will define it when targetting x86_64 output
but in this case he is targetting BPF output instead.
Adding -D__x86_64__ to the command line may be the quickest workaround
for now though.
Yes, but i
On Fri, Oct 18, 2019 at 11:48 AM Martin Stransky wrote:
>
> Folks,
>
> do you know if there's any reliable and widely available way how to
> measure memory usage on Linux by user space application (Firefox in this
> case) and detect low-memory state?
https://gitlab.freedesktop.org/hadess/low-memo
Once upon a time, Tom Hughes said:
> Well I imagine clang will define it when targetting x86_64 output
> but in this case he is targetting BPF output instead.
>
> Adding -D__x86_64__ to the command line may be the quickest workaround
> for now though.
Yes, but in my VERY limited understanding, a
I'm happy to help. Also I can get swag from Brno (though the flight
ticket might be more expensive).
I was there last year so I still remember how to do it more or less :)
On Wed, Oct 16, 2019 at 6:32 PM Brian (bex) Exelbierd
wrote:
>
> Hi All,
>
> I haven't heard anyone mention FOSDEM yet. Boo
On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote:
> On 10/17/19 2:35 PM, Adam Williamson wrote:
> > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > > > The one thing we are using default modular stre
On 18/10/2019 14:33, Chris Adams wrote:
Once upon a time, Steve Grubb said:
Not sure how to proceed. I suspect this will be a bigger problem as more
people start to take advantage of the eBPF facility.
I think the issue is that you are building with clang, not gcc. gcc
defines __x86_64__ by
On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote:
> On to, 17 loka 2019, Orion Poplawski wrote:
> > > > You could install the ipa-client package and enroll a system into IPA
> > > > from a
> > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed
> > > > for the
> > >
On Fri, Oct 18, 2019 at 2:37 PM Aniket Pradhan
wrote:
>
> Hello Ankur, Matthew and Brian!
>
> > > > Is there anyone interested in owning this? If so, can you put together
> > > > a
> > > > proposal for Mindshare?
>
> > They have a research track this year, so it'll be great to get some
> > Neuro
Once upon a time, Steve Grubb said:
> Not sure how to proceed. I suspect this will be a bigger problem as more
> people start to take advantage of the eBPF facility.
I think the issue is that you are building with clang, not gcc. gcc
defines __x86_64__ by default (on the appropriate systems of
No missing expected images.
Failed openQA tests: 4/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191017.n.0):
ID: 472059 Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/472059
ID: 472063 Test: x86_64 KDE-live-is
On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote:
> * Steve Grubb:
> > I am in the process of building a new version of suricata, an IDS
> > program that watches network traffic. It has a new module that uses eBPF
> > for high speed network packet categorization. When building, it us
17.10.2019, 17:15, "Stephen John Smoogen" :
> On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote:
>>
>
>> So, literally every word of this is wrong. The negative feedback is
>> not "overwhelming". It is approximately four noisy individuals, all of
>> whom have expressed zero interest in un
OLD: Fedora-31-20191017.n.0
NEW: Fedora-31-20191018.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 6
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
Hello Ankur, Matthew and Brian!
> > > Is there anyone interested in owning this? If so, can you put together a
> > > proposal for Mindshare?
> They have a research track this year, so it'll be great to get some
> NeuroFedora presence there.
I would love to represent Fedora and Neuro-Fedora at F
On 10/18/19 8:09 AM, J. Scheurich wrote:
gmemusage is a tool to show memory usage per userspace application.
top can show low memory state.
I remember gmemusage from the SGI days and remember using it on Linux
too, but currently
yum whatprovides */gmemusage
claims there are No Matches Found
do you know if there's any reliable and widely available way how to
measure memory usage on Linux by user space application (Firefox in
this case) and detect low-memory state?
gmemusage is a tool to show memory usage per userspace application.
top can show low memory state.
so long
MUFTI
__
This does not work for server components and is not generalizable. For
> example, you cannot have multiple versions of Samba running on the same
> system. You cannot have multiple versions of FreeIPA running on the same
> system either. These server components have requirements beyond package
> ins
On Thu, 2019-10-17 at 09:47 -0400, Stephen Gallagher wrote:
> On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote:
> > So it looks like I did not describe clearly enough what my proposed
> > enable_modules=0 flag would do. ("Disable all module code" was apparently
> > too vague.)
> >
> > How I thi
I'm not familiar with this topic, but I can point you to what WebKit
does:
https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/linux/MemoryPressureMonitor.cpp
https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/linux/MemoryPressureHandlerLinux.cpp
https://trac.webkit.o
Or, even better (or worse): Sombody installs GIMP via GNOME Software,
> and under the hood, dnf does its magic and installs gimp from the
> module, which might depend on another, even non-default module, etc.
> But then, what will happen when that module is EOL, and the user has
> never even intera
>
>
> I'm comfortable saying that most Fedora users are not installing the
> distro
> just to support one specific application, as one might with RHEL or
> CentOS,
> but to benefit from the Four Foundations of Fedora, in this case the most
> important ones being Freedom, Features and First.
>
Exac
On Thu, Oct 17, 2019 at 10:25 PM Sérgio Basto wrote:
> Hi,
> AFAIK , the logic is request an freeze exception , or next push will be
> just after F31 GA .
> I'd like have one unfreeze and push all packages that are waiting to be
> pushed to stable, when we have an NO-GO.
> I already made this req
On 18. 10. 19 11:22, Kevin Kofler wrote:
Adam Williamson wrote:
As things stand I'm reasonably confident we'll be able to Go next week,
I don't see a fix for the module upgrade path blocker in sight any time
soon.
Actually: https://github.com/rpm-software-management/dnf-plugins-extras/pull/1
Folks,
do you know if there's any reliable and widely available way how to
measure memory usage on Linux by user space application (Firefox in this
case) and detect low-memory state?
Thanks,
ma.
---
Hi Vicky, all,
our low-memory detec
On pe, 18 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
That's my point -- requiring parallel installability is not really a
MUST, especially in my area. You are driving this requirement as if
nothing else could solve your issues.
I am not. This is a strawman.
What I am saying is th
Alexander Bokovoy wrote:
> That's my point -- requiring parallel installability is not really a
> MUST, especially in my area. You are driving this requirement as if
> nothing else could solve your issues.
I am not. This is a strawman.
What I am saying is that modules on which other modules have
On Thu, Oct 17, 2019 at 8:09 AM Stephen Gallagher wrote:
>
> On Thu, Oct 17, 2019 at 7:53 AM Miro Hrončok wrote:
> > > That was a representative example. I came up with it at 11pm after a
> > > long day. Don't read too much into the specifics. The point was that
> > > builds may require newer or
Adam Williamson wrote:
> As things stand I'm reasonably confident we'll be able to Go next week,
I don't see a fix for the module upgrade path blocker in sight any time
soon.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
On to, 17 loka 2019, Orion Poplawski wrote:
You could install the ipa-client package and enroll a system into IPA from a
kickstart in RHEL 7 too.. Without modules. That's what I've deployed for the
environments I support, for example. Using a module is not required there.
That wasn't the point,
* Steve Grubb:
> I am in the process of building a new version of suricata, and IDS program
> that watches network traffic. It has a new module that uses eBPF for high
> speed
> network packet categorization. When building, it uses the following command:
>
> /usr/bin/clang -Wall -Iinclude -O2 \
On 2019-10-18 09:18, Leigh Scott wrote:
On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote:
I mean, in the end it would be self-defeating, because the high chance
that it would introduce more problems would just mean we'd need to
freeze again for longer.
So you get a working ISO for releas
On pe, 18 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
This does not work for server components and is not generalizable. For
example, you cannot have multiple versions of Samba running on the same
system. You cannot have multiple versions of FreeIPA running on the same
system either.
> On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote:
>
> I mean, in the end it would be self-defeating, because the high chance
> that it would introduce more problems would just mean we'd need to
> freeze again for longer.
>
So you get a working ISO for release then break it by releasing un
71 matches
Mail list logo
