> On Wednesday, June 26, 2019, 02:42:29 AM EDT, Dan Horák
wrote:>
> what package is it?
fastbit. This evening I retired it in master since no upstream updates have
been issued since 02/2016.
https://src.fedoraproject.org/rpms/fastbit
The build problems are completely recent, nothing "
On Wed, 26 Jun 2019 05:33:24 + (UTC)
Philip Kovacs via devel wrote:
> > On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
> > wrote:
>
> > Please quantify: What is the byte size of the .s file?
>
> > First hint: give the virtual machine enough resources!
> > Either RAM, or "swap
On Wed, Jun 26, 2019 at 12:17 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
> > On Mon, Jun 24, 2019 at 23:17:30 -0500,
> > Justin Forbes wrote:
> > >
> > > It is not a violent cheat. It was proposed this way 2 year
> On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
> wrote:
> Please quantify: What is the byte size of the .s file?
> First hint: give the virtual machine enough resources!
> Either RAM, or "swap" (paging) space.
The .s got up to about 375M before that particular g++ compile proce
On 6/26/19 00:25 UTC, Philip Kovacs via devel wrote:
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)
files -- so large that any attempt to build them in memory (e.g. with -pipe)
causes memory exhaustion.
The only way I have found to reliably
On 6/25/19 2:52 PM, Paul Wouters wrote:
Note, it is a bit worrying that systemd depends on this package, which
wasn't updated in 5 years, and for which the upstream changelog mostly
states "bug fixes".
I don't see a problem with that. What do you expect to change in a
qrcode generator? Alth
Il giorno lun, 24/06/2019 alle 19.09 +0200, Igor Gnatenko ha scritto:
> Hi Guido,
>
> On Mon, Jun 24, 2019 at 6:59 PM Guido Aulisi
> wrote:
> > Hello,
> > I'm going to update zita-convolver library to version 4 in the next
> > weeks, it will be a rather slow job because of holidays :-)
> >
> > A
On Tue, Jun 25, 2019 at 7:15 PM Philip Kovacs via devel
wrote:
> I am finding that one of my c++ packages has compilation units that generate
> very large assembly (.s)
> files -- so large that any attempt to build them in memory (e.g. with -pipe)
> causes memory exhaustion.
> The only way I hav
I - and a people around me - have plenty of 32-bit hardware.
In case of e.g. volunteer youth work. When you need a dozen or two of
PCs where do you get them from?
They are those old machines you no longer use; the one your uncle gave
you when he bought new laptop; the friend's one that broke but y
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)files -- so large that any attempt to build them in
memory (e.g. with -pipe) causes memory exhaustion.The only way I have found to
reliably get the build to run to completion is by using -save-te
Am Dienstag, den 25.06.2019, 17:52 -0400 schrieb Paul Wouters:
> This was a mistake on my end. I thought I was the owner of the
> package, but I think I was only the owner of it back in el6. I assume
> systemd then wasn't depending on it. I saw a PR the other day, assumed
> it was to me as package
On Tue, 2019-06-25 at 17:45 +, Fedora compose checker wrote:
> Missing expected images:
>
> Atomichost raw-xz x86_64
> Atomichost qcow2 x86_64
>
> Compose FAILS proposed Rawhide gating check!
> 3 of 47 required tests failed, 4 results missing
> openQA tests matching unsatisfied gating require
On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
> On Mon, Jun 24, 2019 at 23:17:30 -0500,
> Justin Forbes wrote:
> >
> > It is not a violent cheat. It was proposed this way 2 years ago. At
> > the time a SIG was created to maintain i686 so that it could continue
> > as a secondary arch
This was a mistake on my end. I thought I was the owner of the package, but
I think I was only the owner of it back in el6. I assume systemd then
wasn't depending on it. I saw a PR the other day, assumed it was to me as
package owner, and saw no reason to not upgrade since it was long over due.
I d
On 25. 06. 19 23:30, mcatanz...@gnome.org wrote:
Let's ensure this at least doesn't happen for the same library again and again.
In [1], change SHOULD NOT -> MUST NOT.
That is unfortunately problematic, for various reasons discussed at FPC level,
however even if we do change this to MUST, it
On Tue, Jun 25, 2019 at 11:21 PM Miro Hrončok wrote:
>
> qrencode was bumped from 3.4.4 to 4.0.2.
>
> It has a bumped soname from libqrencode.so.3 to libqrencode.so.4.
This might be a good time to remind people that globbing out shared
libraries like this:
https://src.fedoraproject.org/rpms/qrenc
Let's ensure this at least doesn't happen for the same library again
and again.
In [1], change SHOULD NOT -> MUST NOT.
Require maintainers (or provenpackagers) to fix violations like [2]
when unannounced soname bumps occur.
(If anyone wants to write a script to detect such problems proacti
qrencode was bumped from 3.4.4 to 4.0.2.
It has a bumped soname from libqrencode.so.3 to libqrencode.so.4.
systemd once again cannot be installed and all my packages fail to resolve build
dependencies.
Please, announce those changes and coordinate!
--
Miro Hrončok
--
Phone: +420777974800
IRC:
Hi,
I can take python-pdfkit. Because business as usual.
Upstream is active and there's a new version provided on PyPi. No idea why this
package is orphaned.
Regards, Raphael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On Tue, Jun 25, 2019 at 8:45 PM Stephen Gallagher
wrote:
>
>
> On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
>> > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <
>> adamw...@fedoraproject.o
On 6/25/19 1:38 PM, nore...@fedoraproject.org wrote:
>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20190625.0
> Commit(x86_64):
> c50cc86ad7972f85853f1deafda3899eb86a0e5220c613744eed64320298716e
> Commit(aarch64):
> 0e82ac50808a1513cab1f8ad4c6262c091b1
On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson
wrote:
> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
> > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <
> adamw...@fedoraproject.org>
> > wrote:
> >
> > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> > > > But ... i
Missing expected images:
Atomichost raw-xz x86_64
Atomichost qcow2 x86_64
Compose FAILS proposed Rawhide gating check!
3 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 18/137 (x86_64), 3/23 (i
A new Fedora Atomic Host update is available via an OSTree update:
Version: 29.20190625.0
Commit(x86_64): c50cc86ad7972f85853f1deafda3899eb86a0e5220c613744eed64320298716e
Commit(aarch64):
0e82ac50808a1513cab1f8ad4c6262c091b19f39e3dfad8f22c2252aec38fd34
Commit(ppc64le):
72c06a8c8c18ff47ae9f7385a
On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
> On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson
> wrote:
>
> > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> > > But ... if it's not for different version streams, then what *is it*
> > for? 🤔
> > > (What about the plans
On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson
wrote:
> On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> >
> > But ... if it's not for different version streams, then what *is it*
> for? 🤔
> > (What about the plans to offer different versions of e.g. NodeJS via
> > streams? Is that wr
#fedora-meeting-3: Weekly Meeting of the Modularity Team
Meeting started by contyk at 15:00:00 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-3/20
Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190625.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 6/24/19 3:52 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 24, 2019 at 10:35:40AM -0700, Kevin Fenzi wrote:
>> On 6/24/19 10:00 AM, Justin Forbes wrote:
>>> On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
>>> wrote:
>>
>> ...snip...
>>
Maybe the Change could be renamed
On Mon, 24 Jun 2019 at 23:25, Ralf Corsepius wrote:
> On 6/21/19 7:26 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> >
> > == Summary ==
> > Stop building i686 kernels, reduce the i686 package to a
> > kernel-headers package that can be used to build
On 25. 06. 19 13:02, Miro Hrončok wrote:
Almost all of my packages started to fail in koschcei because of:
nothing provides libip4tc.so.0()(64bit) needed by
systemd-242-3.git7a6d834.fc31.x86_64
Please, coordinate better next time :(
The following packages probably need rebuilds:
collectd
co
https://fedoraproject.org/wiki/Changes/golang1.13
== Summary ==
Rebase of Golang package to upcoming version 1.13 in Fedora 31,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild)
On Tue, 2019-06-25 at 07:16 -0400, Nico Kadel-Garcia wrote:
> On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen
> wrote:
> > On 6/19/19 1:51 PM, Aleš Matěj wrote:
> > > > At this point, the drpm library is the only blocker for zstd
> > > > payloads,
> > > > since createrepo_c needs to be able to han
On Mon, Jun 24, 2019 at 23:17:30 -0500,
Justin Forbes wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At
the time a SIG was created to maintain i686 so that it could continue
as a secondary arch. They are inactive. See the post in the SIG there.
When a call for a status
On 25. 06. 19 13:31, Miro Hrončok wrote:
On 25. 06. 19 13:02, Miro Hrončok wrote:
Almost all of my packages started to fail in koschcei because of:
nothing provides libip4tc.so.0()(64bit) needed by
systemd-242-3.git7a6d834.fc31.x86_64
Please, coordinate better next time :(
The following pac
On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen wrote:
>
> On 6/19/19 1:51 PM, Aleš Matěj wrote:
> >
> >> At this point, the drpm library is the only blocker for zstd payloads,
> >> since createrepo_c needs to be able to handle zstd drpms.
> >
> > I looked into the drpm library and I should be abl
Almost all of my packages started to fail in koschcei because of:
nothing provides libip4tc.so.0()(64bit) needed by
systemd-242-3.git7a6d834.fc31.x86_64
Please, coordinate better next time :(
The following packages probably need rebuilds:
collectd
connman
iproute
keepalived
miniupnpd
perl-IP
On Thu, Jun 06, 2019 at 12:55:49PM +0200, Petr Stodulka wrote:
> My question is, do you have any related experience to the topic? I already
> had some exprience with death upstreams, but this is really new to me.
> As well, I am curious whether I did mistake when I switched to the
> upstream[1] reg
On 25. 06. 19 12:07, Pierre-Yves Chibon wrote:
On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote:
On 25. 06. 19 9:50, Pierre-Yves Chibon wrote:
I would say the scoping should happen (e.g. in copr) first, then we'll
know what the scope (and hence feasibility) of this change truly is.
On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote:
> On 25. 06. 19 9:50, Pierre-Yves Chibon wrote:
> > > > > > > I would say the scoping should happen (e.g. in copr) first, then
> > > > > > > we'll
> > > > > > > know what the scope (and hence feasibility) of this change truly
> > > > >
On 25. 06. 19 9:50, Pierre-Yves Chibon wrote:
I would say the scoping should happen (e.g. in copr) first, then we'll
know what the scope (and hence feasibility) of this change truly is.
What will the scoping actually tell us? If it tells us that X hundred packages
need to add BR for python3-tes
On Mon, Jun 24, 2019 at 9:32 PM Chris Adams wrote:
>
> Once upon a time, Kevin Fenzi said:
> > On 6/24/19 10:00 AM, Justin Forbes wrote:
> > > On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
> > > wrote:
> >
> > ...snip...
> >
> > >> Maybe the Change could be renamed to reflect the
On Mon, Jun 24, 2019 at 07:37:19PM -0400, Yaakov Selkowitz wrote:
> On Tue, 2019-06-25 at 00:26 +0200, Miro Hrončok wrote:
> > On 25. 06. 19 0:18, Yaakov Selkowitz wrote:
> > > On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote:
> > > > On 24. 06. 19 22:25, Yaakov Selkowitz wrote:
> > > > > On M
Hi, Ralf,
one of the goals of the change process (mailing list announcements and
discussion we have right here) is to identify various impacts of the
change and also to find better wording for it (including the title).
So you shouldn't feel cheated, just contribute your thoughts and
suggest the co
44 matches
Mail list logo
