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
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
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
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
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
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 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 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
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
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]
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
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
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 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
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
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
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):
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 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 ...
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):
>
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
#fedora-meeting-3: Weekly Meeting of the Modularity Team
Meeting started by contyk at 15:00:00 UTC. The full logs are available
at
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
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 <
>>
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
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,
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
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
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:
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
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
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
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
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
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
> 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
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 :-)
> >
> >
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
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?
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1723904
Bug ID: 1723904
Summary: perl-FFI-CheckLib-0.25 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-FFI-CheckLib
Keywords: FutureFeature, Triaged
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2019-06-26 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. Agenda is in the
https://bugzilla.redhat.com/show_bug.cgi?id=1723962
Bug ID: 1723962
Summary: perl-Test-Refcount-0.09 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Test-Refcount
Keywords: FutureFeature, Triaged
https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/26/report-389-ds-base-1.4.1.4-20190625git71138c0.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://bugzilla.redhat.com/show_bug.cgi?id=1723904
--- Comment #3 from Fedora Update System ---
FEDORA-2019-441dc1a4d8 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-441dc1a4d8
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=1723904
--- Comment #2 from Fedora Update System ---
FEDORA-2019-622d40ab09 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-622d40ab09
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=1724012
Bug ID: 1724012
Summary: ack-3.0.1 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: ack
Keywords: FutureFeature, Triaged
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=1724012
--- Comment #1 from Upstream Release Monitoring
---
One or more of the new sources for this package are identical to the old
sources. It's likely this package does not use the version macro in its Source
URLs. If possible, please update the
https://bugzilla.redhat.com/show_bug.cgi?id=1723904
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
Hi all,
I've been very unwell since my return to Australia, so if there is anything
urgent you need to me took at please contact me directly to notify me - I'm not
looking at pagure this week. Sorry about this :(
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE
53 matches
Mail list logo
