On Fri, 14 Aug 2020 at 01:08, Adam Williamson
wrote:
> On Thu, 2020-08-13 at 18:46 -0400, Chris wrote:
> > Hi guys,
> >
> > I'm going through the typical routine of pushing my repository up to EPEL
> > (fc33, fc32, fc31, and epel8)... all goes smoothly until this command:
> >
> > fedpkg update --
On Thu, 2020-08-13 at 17:10 -0700, Adam Williamson wrote:
> A new build of libreport was done for all releases today by mfabik:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592551
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592550
> https://koji.fedoraproject.org/koji/bu
A new build of libreport was done for all releases today by mfabik:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592551
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592550
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592524
https://koji.fedoraproject.org/koji/buildinf
On Thu, 2020-08-13 at 18:46 -0400, Chris wrote:
> Hi guys,
>
> I'm going through the typical routine of pushing my repository up to EPEL
> (fc33, fc32, fc31, and epel8)... all goes smoothly until this command:
>
> fedpkg update --type enhancement
>
> I get the following returned:
> Could not exe
On Wed, Aug 12, 2020 at 02:43:15PM +0200, Miro Hrončok wrote:
> On 12. 08. 20 14:39, Richard W.M. Jones wrote:
> > There is indeed no kernel package I can find that's tagged into
> > f34, but there is one tagged into f33:
> >
> >https://koji.fedoraproject.org/koji/buildinfo?buildID=1579426
> >
Hi guys,
I'm going through the typical routine of pushing my repository up to EPEL
(fc33, fc32, fc31, and epel8)... all goes smoothly until this command:
fedpkg update --type enhancement
I get the following returned:
Could not execute update: Could not generate update request: Unable to
create u
Hey All,
I would like to invite all of you to participate in the Kernel 5.8
Test week which is happening from 2020-08-17 to 2020-08-24. It's
fairly simple, head over to the wiki [0] and read in details about the
test week and simply run the test case mentioned in[1] and enter your
results.
As usu
We've branched, so let's start the weekly blocker status email yay
Action summary
Accepted blockers
-
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: abrt maintainers to make a
On 8/13/20 4:28 PM, Przemek Klosowski via devel wrote:
> On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:
>> I'll do something to disable it.
>
> Oh, just thougth I'd mention---what I'd do would be
>
> locate sadc <- hopefully this would return the location of the
> sadc binary, perhaps /
On 8/13/20 4:23 PM, Przemek Klosowski via devel wrote:
On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:
So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
/usr/lib64/sa/sadc) or some custom system activity data collection
so
On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:
I'll do something to disable it.
Oh, just thougth I'd mention---what I'd do would be
locate sadc <- hopefully this would return the location of the sadc
binary, perhaps /var/lib64/sa/sadc
rpm -qf /var/lib64/sa/sadc <- this will rep
On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:
So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
/usr/lib64/sa/sadc) or some custom system activity data collection
software that is locally installed at your site.
Thanks
On 8/13/20 4:05 PM, Przemek Klosowski via devel wrote:
> On 8/13/20 2:04 PM, Wells, Roger K. via devel wrote:
>> After some time, usually hours, the following four tasks in top are
>> running at 100%:
>> sadc
>> kworker/6:1+events_freezable
>> dmesg
>> systemd-journal
>
> So sadc is not part of cur
On 8/13/20 2:04 PM, Wells, Roger K. via devel wrote:
After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal
So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5
I have been working toward getting a "modern" cross compiling toolchain
included in Fedora[0] ever since mspgcc stopped working[1] 4 years ago.
Up until recently, my efforts have been almost entirely centered around
packaging TI / Mitto Systems' somewhat bespoke branch of GCC[2].
It has been s
On Thu, Aug 13, 2020 at 12:04 PM Wells, Roger K. via devel
wrote:
>
> Current kernel: 5.7.12-200.fc32.x86_64
> gnome desktop
> PC: Thinkpad X280, intel core i7, 8th gen
>
> After some time, usually hours, the following four tasks in top are
> running at 100%:
> sadc
What is this? I don't have it
Current kernel: 5.7.12-200.fc32.x86_64
gnome desktop
PC: Thinkpad X280, intel core i7, 8th gen
After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal
sometimes there are only three of these at 100% but usually f
> Do you have the latest appstream-data installed? I believe it went to
> stable a few days ago.
>
> Richard.
Turns out this was the problem. appstream-data had maybe lagged a little
behind, so the new BleachBit package didn't show up in Software right away. I
updated all system packages again
On Thu, Aug 13, 2020 at 09:23:35AM -0600, Jeff Law wrote:
> On Thu, 2020-08-13 at 11:13 -0400, Omair Majid wrote:
> > Jeff Law writes:
> >
> > > I can't help with the untagging, but I'm here if there's anything
> > > going wrong with the system tools that is ultimately affecting dotnet.
> >
> >
Once upon a time, Matthew Miller said:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Such %changelog has a very similar level of quality as all the generated
> > approaches, and we don't have to complicate our lives (or buildsystem).
> > Alternatively, we can teach build sys
> We also have an icon size requirement. The app needs to provide an icon
> that's at
> least 64x64 (or maybe even 128x128?).
The package does contain an icon, a 256×256 pixel PNG with a transparency
channel.
- https://github.com/bleachbit/bleachbit/blob/master/bleachbit.png
- Installed to /usr
Hello,
I have implemented the necessary changes in Pungi, the software that
creates Fedora compose. So this change has a potential of moving forward.
I have created 2 pull-requests for release engineering for this change:
https://pagure.io/pungi-fedora/pull-request/871
https://pagure.io/pung
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Such %changelog has a very similar level of quality as all the generated
> approaches, and we don't have to complicate our lives (or buildsystem).
> Alternatively, we can teach build systems to upload the git-log file
> somewhere, or
On Thu, 2020-08-13 at 11:13 -0400, Omair Majid wrote:
> Jeff Law writes:
>
> > I can't help with the untagging, but I'm here if there's anything
> > going wrong with the system tools that is ultimately affecting dotnet.
>
> Thanks.
>
> Just for context:
>
> .NET Core uses a bundled (and modifi
Jeff Law writes:
> I can't help with the untagging, but I'm here if there's anything
> going wrong with the system tools that is ultimately affecting dotnet.
Thanks.
Just for context:
.NET Core uses a bundled (and modified) copy of libunwind for unwinding
the stack. This version doesn't work
On Wed, Aug 12, 2020 at 12:28 PM Sergio Belkin wrote:
>
> Hi!
> I 've just had a problem using EarlyOOM + ZRAM. I haven't a disk-based swap
> partition.
> I was using mainly Zoom (desktop app) + Firefox + VirtualBox (Debian with 4GB
> of RAM), and EarlyOOM killed Zoom in the middle of a call :(
Pavel Raiskup wrote:
> Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
>
> https://forms.gle/Jgr13vtRkiUwLb6W6
The questionnaire itself is short, but understanding all the proposals
is considerable work. That's where TL;DR will happen.
> Let's stop requiring Release
On Thu, 2020-08-13 at 10:21 -0400, Omair Majid wrote:
> Hi,
>
> One of the recent builds produced for "dotnet3.1" for rawhide is broken
> on aarch64. It built successfully in koji, but produced aarch64 binaries
> that segfault on startup. A new build of dotnet3.1 requires a working
> older build.
On 8/13/20 3:17 PM, Fabio Valentini wrote:
On Thu, Aug 13, 2020 at 3:15 PM Ralf Corsepius wrote:
Hi,
A f33 build job, I launched a couple of hours ago, seems to hang on s390
https://koji.fedoraproject.org/koji/taskinfo?taskID=49204466
What am I supposed to do?
Ralf
Wait. It's not hanging
Hi,
One of the recent builds produced for "dotnet3.1" for rawhide is broken
on aarch64. It built successfully in koji, but produced aarch64 binaries
that segfault on startup. A new build of dotnet3.1 requires a working
older build. That means all recent builds of dotnet3.1 in Rawhide/F33 on
failed
On Thu, Aug 13, 2020 at 9:43 AM wrote:
>
> On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> > On Thu, 13 Aug 2020 at 08:58, Fabio Valentini
> > wrote:
> > > On Thu, Aug 13, 2020 at 2:16 PM wrote:
> > > > Hello everyone,
> > > >
> > > > Anaconda team has decided to deprecate use o
On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> On Thu, 13 Aug 2020 at 08:58, Fabio Valentini
> wrote:
> > On Thu, Aug 13, 2020 at 2:16 PM wrote:
> > > Hello everyone,
> > >
> > > Anaconda team has decided to deprecate use of Anaconda kernel
> > > boot
> > > parameters without '
On Thu, 13 Aug 2020 at 08:58, Fabio Valentini wrote:
>
> On Thu, Aug 13, 2020 at 2:16 PM wrote:
> >
> > Hello everyone,
> >
> > Anaconda team has decided to deprecate use of Anaconda kernel boot
> > parameters without 'inst.' prefix. As you may already know you can
> > specify Anaconda kernel boo
On Thu, Aug 13, 2020 at 3:15 PM Ralf Corsepius wrote:
>
> Hi,
>
> A f33 build job, I launched a couple of hours ago, seems to hang on s390
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49204466
>
> What am I supposed to do?
>
> Ralf
Wait. It's not hanging, it's not running yet.
Looking
Hi,
A f33 build job, I launched a couple of hours ago, seems to hang on s390
https://koji.fedoraproject.org/koji/taskinfo?taskID=49204466
What am I supposed to do?
Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
https://forms.gle/Jgr13vtRkiUwLb6W6
This is no change proposal but rather a result of my long-term curiosity
around the $Subject problem. I hope I marked the results public so the
results are visible to anyone.
--
On Thu, Aug 13, 2020 at 2:16 PM wrote:
>
> Hello everyone,
>
> Anaconda team has decided to deprecate use of Anaconda kernel boot
> parameters without 'inst.' prefix. As you may already know you can
> specify Anaconda kernel boot parameters both with and without 'inst.'
> prefix (e.g. 'inst.repo='
Hello everyone,
Anaconda team has decided to deprecate use of Anaconda kernel boot
parameters without 'inst.' prefix. As you may already know you can
specify Anaconda kernel boot parameters both with and without 'inst.'
prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
you us
Dne 13. 08. 20 v 12:41 Qiyu Yan napsal(a):
> Hello all,
>
> I have some problem with rpmdev-bumpspec recently.
>
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated according
On Thu, Aug 13, 2020 at 12:42 PM Qiyu Yan wrote:
>
> Hello all,
>
> I have some problem with rpmdev-bumpspec recently.
>
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated a
On Thu, 13 Aug 2020 18:41:23 +0800, Qiyu Yan wrote:
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpsp
Hello all,
I have some problem with rpmdev-bumpspec recently.
In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
use time+date in the changelog it generates[1], while the packaging
guidelines have not been updated accordingly[2], should the guideline
be updated to the rpmdev-bum
On Thu, 13 Aug 2020 at 08:29, Artur Iwicki wrote:
> We also have an icon size requirement.
Do you have the latest appstream-data installed? I believe it went to
stable a few days ago.
Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To
Hi everybody,
Still working through Java package update backlog, it looks like
Fernando Nasser / fnasser is no longer contributing to fedora. I have
opened this non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1868600
Looking at dist-git and koji, fnasser has not
Hi everybody,
Working through the Java packages that are in need of attention, I
came across glassfish-el and glassfish-servlet-api, which have
essentially been abandoned (in the latter case, the two co-maintainers
of the package were in fact already declared non-responsive last
year).
I filed th
We also have an icon size requirement. The app needs to provide an icon that's
at least 64x64 (or maybe even 128x128?). I vaguely remember there being a
discussion here on devel when the requirement was introduced.
I tried searching the wiki and the Packaging Guidelines and this is the only
pla
46 matches
Mail list logo
