On 08/24/2017 07:48 PM, Juan Orti Alcaine wrote:
2017-08-24 9:54 GMT+02:00 Juan Orti Alcaine :
Hi,
I'm getting failed builds [1] in rawhide and f27 because the macro
%py3_install fails when called with arguments. It was fine until f26.
The package is rhythmbox-ampache, and I call the macro lik
On Fri, Aug 25, 2017 at 08:24:30AM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Switch libidn-using applications to IDNA2008 =
> https://fedoraproject.org/wiki/Changes/IDNA2008
>
> Change owner(s):
> * Nikos Mavrogiannopoulos
> * Robert Scheck
>
> The proposed change is about deprec
= Proposed System Wide Change: Switch libidn-using applications to IDNA2008 =
https://fedoraproject.org/wiki/Changes/IDNA2008
Change owner(s):
* Nikos Mavrogiannopoulos
* Robert Scheck
The proposed change is about deprecating libidn, which supports
IDNA2003, and switch all applications using li
On Fri, 2017-08-25 at 06:59 +0200, Remi Collet wrote:
> Le 25/08/2017 à 03:31, Adam Williamson a écrit :
> > On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> > > On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > > > Sorry, of course we have to actually build 6.9.9-9. It looks like
>
Le 25/08/2017 à 03:31, Adam Williamson a écrit :
> On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
>> On 08/24/2017 11:36 AM, Adam Williamson wrote:
>>> Sorry, of course we have to actually build 6.9.9-9. It looks like
>>> you're on this already, thanks.
>>
>> I've also created update
On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > Sorry, of course we have to actually build 6.9.9-9. It looks like
> > you're on this already, thanks.
>
> I've also created updates in Bodhi. Please feel free to attach your builds to
On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote:
> On 08/24/2017 10:24 AM, Adam Williamson wrote:
> > As Remi said, the changes in 6.9.9 are far less significant than those
> > in 7.0.6. As several people pointed out, sending 7.x to stable releases
> > is clearly against the updates po
Rex Dieter wrote:
> Cheng Ye wrote:
>
>> Hi,
>> This is probably a simple packaging question.
>
> Yes, per SUBJECT, this is normal and not out of the ordinary.
Right. In particular, it happens if the package containing the library
libfoo.so.1 also contains an executable or another library link
Matthew Miller wrote:
> Core-Extras was a bad ideas because Core was developed inside Red Hat
> in a non-open way and did not allow community involvement beyond that
> of beta testing. Merging it all together was probably the only
> realistic way to fix that (and fixing that was absolutely the best
On Thu, 24 Aug 2017 21:51:59 +0200, Sandro Mani wrote:
> May well be mistaken, but doesn't ABRT work with coredumps, which you can't
> get on Windows systems?
OK, thanks for showing me the setup. I was still imagining running PE32
binaries by Wine, I did not realize there exist real Windows syste
On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote:
>
> I'll get an Epoch bump started... when it completes if you want to do
> rebuilds for
> F25/26 I'll work on F27+.
BTW, it occurred to me for F27+ it may be worth checking if each
project supports a less messy alternative, like Gra
Missing expected images:
Server dvd i386
Workstation live i386
Server boot i386
Kde live i386
Failed openQA tests: 29/137 (x86_64), 1/2 (arm)
ID: 133935 Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133935
ID: 133942 Test: x86_64 Server-dvd
On 24.08.2017 21:42, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote:
While I'm at it, my current technique for interpreting mingw stacktraces
produced without debuginfos is parsing the text and calling addr2line for
each stack frame. Is there a neater technique?
U
On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote:
> While I'm at it, my current technique for interpreting mingw stacktraces
> produced without debuginfos is parsing the text and calling addr2line for
> each stack frame. Is there a neater technique?
Unaware of. But then why you do not have t
On 24.08.2017 14:52, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote:
On 24.08.2017 14:18, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos
On Thu, 2017-08-24 at 11:28 -0700, Moez Roy wrote:
>
> A rebuild of affected packages would be required regardless, so it made
> more sense to just update it directly to v7 which has High Dynamic Range
> Imaging by default and more Pixel channels.
The problem is that 7.x makes *more*, and more si
On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > Sorry, of course we have to actually build 6.9.9-9. It looks like
> > you're on this already, thanks.
>
> I've also created updates in Bodhi. Please feel free to attach your builds to
On 08/24/2017 11:36 AM, Adam Williamson wrote:
Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.
I've also created updates in Bodhi. Please feel free to attach your builds to
it.
F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8
On Thu, Aug 24, 2017 at 11:12 AM, Michael Cronenworth
wrote:
> On 08/24/2017 11:36 AM, Adam Williamson wrote:
>
>> Sorry, of course we have to actually build 6.9.9-9. It looks like
>> you're on this already, thanks.
>>
>
> The build override has landed.
>
> Thanks,
> Michael
>
I transferred own
On 08/24/2017 11:36 AM, Adam Williamson wrote:
Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.
The build override has landed.
Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Thu, 24 Aug 2017 08:21:57 +0200
Tomas Tomecek wrote:
> We would need to develop a dedicated, non-trivial tooling to enable
> this functionality. And honestly, I can't even imagine how this
> could be even possible to implement for all ecosystems (compiled
> languages, interpreted languages).
With glibc 2.26 there's a new per-thread cache in malloc, which
improves malloc performance in general, and hopefully, specifically
for the apps which each of you are most concerned about. In the event
that you feel it doesn't help, or if you have other concerns about
malloc performance, there's
2017-08-24 9:54 GMT+02:00 Juan Orti Alcaine :
> Hi,
>
> I'm getting failed builds [1] in rawhide and f27 because the macro
> %py3_install fails when called with arguments. It was fine until f26.
>
> The package is rhythmbox-ampache, and I call the macro like this:
>
>
> %global py_install_args --no
On 08/24/2017 05:18 AM, Jan Kratochvil wrote:
> But the symbols take less space there as they are compressed. You can check
> how it looks like for Linux ELF binaries by:
> rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section
> .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz
On 24.8.2017 03:17, Scott Talbert wrote:
On Tue, 22 Aug 2017, Scott Talbert wrote:
Hi,
I was just trying to build a new package in Rawhide that built fine a
few days ago. The failure seems to be occurring because the python3
setuptools_scm module isn't being found. I'm using the new
pytho
On 08/24/2017 11:36 AM, Adam Williamson wrote:
Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.
Yes, I've issued builds. Once the buildroot override is available I'll send another
email.
___
devel mai
On Thu, 2017-08-24 at 09:27 -0700, Adam Williamson wrote:
> On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
> > On Thu, 24 Aug 2017 10:54:12 -0500
> > Michael Cronenworth wrote:
> >
> > > On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > > > Epoch bump? Why? The f25/f26 packages never even got t
On 08/24/2017 06:27 PM, Adam Williamson wrote:
> On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
>> On Thu, 24 Aug 2017 10:54:12 -0500
>> Michael Cronenworth wrote:
>>
>>> On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
Epoch bump? Why? The f25/f26 packages never even got to testing...
Ju
On 08/24/2017 05:48 PM, Kevin Fenzi wrote:
> I was going to look at f25/f26 for a 6.x update, but I haven't had any
> time to get to it. ;( Would need a bunch of rebuilds and waiting in
> testing a while so 3rd parties could see it and rebuild at the very least.
I think we're going to need an ABI
On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
> On Thu, 24 Aug 2017 10:54:12 -0500
> Michael Cronenworth wrote:
>
> > On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > > Epoch bump? Why? The f25/f26 packages never even got to testing...
> > > Just revert the commits, etc.
> >
> > I thought Ko
On Thu, 24 Aug 2017 10:54:12 -0500
Michael Cronenworth wrote:
> On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > Epoch bump? Why? The f25/f26 packages never even got to testing...
> > Just revert the commits, etc.
>
> I thought Koji did an NVR check? Won't let a lower version or is it
> only when
Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2017-08-25 16:00 UTC'
Links to all issues below ca
On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
Epoch bump? Why? The f25/f26 packages never even got to testing... Just
revert the commits, etc.
I thought Koji did an NVR check? Won't let a lower version or is it only when it's
been pushed?
___
devel mai
Le 24/08/2017 à 17:43, Michael Cronenworth a écrit :
> I'll get an Epoch bump started... when it completes if you want to do
> rebuilds for F25/26 I'll work on F27+.
I don't think epoch bump is needed
(package never go in the repo)
Remi
>
> Thanks,
> Michael
> _
On 08/24/2017 08:43 AM, Michael Cronenworth wrote:
> On 08/24/2017 10:24 AM, Adam Williamson wrote:
>> As Remi said, the changes in 6.9.9 are far less significant than those
>> in 7.0.6. As several people pointed out, sending 7.x to stable releases
>> is clearly against the updates policy. I'd agre
On 08/24/2017 08:19 AM, Adam Williamson wrote:
> On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote:
>> Le 24/08/2017 à 08:58, Adam Williamson a écrit :
>>> On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
Le 24/08/2017 à 02:32, Moez Roy a écrit :
> The soname bump requires pac
On 08/24/2017 10:24 AM, Adam Williamson wrote:
As Remi said, the changes in 6.9.9 are far less significant than those
in 7.0.6. As several people pointed out, sending 7.x to stable releases
is clearly against the updates policy. I'd agree we definitely must
revert to 6.x for F25 and F26 updates;
On Thu, 2017-08-24 at 09:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 09:25 AM, Remi Collet wrote:
> > I really think we have to revert to 6 in stable branch
> > (and perhaps even in F27, which is very close to feature freeze)
> >
> > - soname bump
> > - lot of removed API
> > - HDRI enabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2017-08-24 at 17:04 +0200, Remi Collet wrote:
> Hi,
>
> Since F27, for each package, we have a "debugsource" package.
>
> Question is about the repository layout
>
> For now these packages are available in the standard repository
>
> Ex:
On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote:
> Le 24/08/2017 à 08:58, Adam Williamson a écrit :
> > On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
> > > Le 24/08/2017 à 02:32, Moez Roy a écrit :
> > >
> > > > The soname bump requires packages that depend on it need to be rebuilt,
Hi,
Since F27, for each package, we have a "debugsource" package.
Question is about the repository layout
For now these packages are available in the standard repository
Ex:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/y/
yajl-2.1.0-8.f
Le 24/08/2017 à 16:47, Michael Cronenworth a écrit :
> On 08/24/2017 09:25 AM, Remi Collet wrote:
>> I really think we have to revert to 6 in stable branch
>> (and perhaps even in F27, which is very close to feature freeze)
>>
>> - soname bump
>> - lot of removed API
>> - HDRI enabled by default
>
Hi,
I suspect the confusion between group and module names will lead to strange
brittle special cases down the road and (worse) people being over-clever
building solutions that rely on those special cases (exactly like the
under-specified rpm update quirks which are being blamed nowadays).
Why
On 08/24/2017 09:25 AM, Remi Collet wrote:
I really think we have to revert to 6 in stable branch
(and perhaps even in F27, which is very close to feature freeze)
- soname bump
- lot of removed API
- HDRI enabled by default
The SONAME is changing in 6.9 as well so I'm not sure reverting is gre
Hello,
For some reason I fail to understand, a non-devel package is
conflicting with a devel package :-/
According to dnf it's the only explicit conflict for the package:
$ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64
pkgconfig(nspr) >= 4.16
Maybe someone confused Conflicts wi
Dne 24.8.2017 v 09:00 Marius Vollmer napsal(a):
My understanding from playing with Boltron is that "dnf install foo"
treats "foo" as a module name. "dnf install" can not install packages
The final solution will be:
dnf install foo - install rpm package
dnf module install foo - install modu
Dne 24.8.2017 v 13:58 Cheng Ye napsal(a):
Hi,
Making the builddir accessible for failed build would be helpful. Some test
suits will store log in a file in buildir without echoing anything else
helpful. Without access to builddir, it could be difficult to debug. However,
copying the builddi
Le 24/08/2017 à 14:05, Dan Horák a écrit :
> so I've applied a workaround [1] to get ImageMagick built on all arches
> again until we have a proper fix, it's in Rawhide now, feel free to
> apply it to other branches as well
I really think we have to revert to 6 in stable branch
(and perhaps even
On Thu, Aug 24, 2017 at 01:52:16PM +0200, Jan Kurik wrote:
> In the group we had the discussion were no strong opinions whether
> these milestones need to be early in the release cycle or just before
> the "Beta Freeze". As such, I would like to open a discussion and
> collect some opinions on the
On Thu, Aug 24, 2017 at 03:20:12AM +0200, Kevin Kofler wrote:
> This is exactly why the separate Core and Extras were such a PITA and why
> the Core-Extras Merge was done. Doing the opposite now is a BAD idea.
Core-Extras was a bad ideas because Core was developed inside Red Hat
in a non-open way
Thanks. It could be better if it can be documented somewhere in wiki.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Cheng Ye wrote:
> Hi,
> This is probably a simple packaging question.
Yes, per SUBJECT, this is normal and not out of the ordinary.
-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
Hi,
This is probably a simple packaging question. Sorry for the noise if the answer
already exists somewhere on the internet.
I am trying to package the IPC library. The built package installs (using dnf)
and functions correctly, but the java-cmu-ipc package's automatic requires and
provides in
On 24 August 2017 at 10:33, Peter Robinson wrote:
> > On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> >> Hello Fedora devels and users,
> >>
> >> more than three years ago, the same topic started discussion if we
> >> want
> >> this package in Fedora or not and how [1]. The discussion res
On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote:
> On 24.08.2017 14:18, Jan Kratochvil wrote:
> > On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
> > > I'm investigating why gdb returns so unreliable backtraces for mingw
> > > binaries without debuginfos,
> > They are perfectly reliabl
Hi Jan
On 24.08.2017 14:18, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos,
They are perfectly reliable. They just do not show the function names.
But those can be l
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
> I'm investigating why gdb returns so unreliable backtraces for mingw
> binaries without debuginfos,
They are perfectly reliable. They just do not show the function names.
But those can be looked up later from *-debuginfo.rpm.
...
> strip-d
On Thu, 24 Aug 2017 09:04:51 +0200
Dan Horák wrote:
> On Wed, 23 Aug 2017 22:16:40 -0500
> Michael Cronenworth wrote:
>
> > Hi all,
> >
> > An ImageMagick update (6.9 => 7.0) with an SONAME bump and other
> > breakage has been pushed to F25 and higher.
> >
> > First, the update introduces reg
Hi Richard,
On 08/23/2017 05:53 PM, Richard Kellner wrote:
my name is Richard Kellner and I am a Python developer. In my free time,
I am also a PyCon SK volunteer. Recently I have got this crazy idea to
submit some of my packages to Fedora, so here I am. I have just
submitted my first package fo
Hi,
Making the builddir accessible for failed build would be helpful. Some test
suits will store log in a file in buildir without echoing anything else
helpful. Without access to builddir, it could be difficult to debug. However,
copying the builddir from mock directory to somewhere accessibl
Hi everyone,
as you probably noted, one of the significant changes in F27 release
is the missing Alpha release. This is based on the "No More alphas"
[1] Change. The schedule for F27 release [2] has been put together
with the aim not to break any flow during the cycle and with intention
to make ob
On Thu, Aug 24, 2017 at 3:02 AM Marius Vollmer
wrote:
> My understanding from playing with Boltron is that "dnf install foo"
> treats "foo" as a module name. "dnf install" can not install packages
> anymore. So naively I assume that PackageKit will transparently start
> installing modules. (I
Hi
I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos, and noticed a big improvement if I change
strip-unneeded to strip-debug in mingw-find-debuginfo.sh. Currently,
mingw-find-debuginfo.sh does the following:
mingw-objcopy --only-keep-debug "$bi
Richard Hughes writes:
> On 24 August 2017 at 08:45, Marius Vollmer wrote:
>
>> One approach is just to put them all into the collection data:
>
> You can't have two components with the same ID inside a
> group with the same origin.
Okay, that was my understanding of the spec as well.
>> My p
On 24.8.2017 08:04, Pavel Raiskup wrote:
> On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote:
>> Do you use Copr for building packages for nightlies? For building packages
>> before pull request is merged?
>
> Yes, not particulary me -- but I helped to guys in pgjdbc project to
Pavel Raiskup wrote:
> Ok, I agree that Fedora needs modules for life-cycle separation.
I don't. I consider what you call "life-cycle separation" (I'd rather call
it "inconsistent EOLs") a bug rather than a feature.
This is yet another of those "features" that sound great on paper, but lead
to
On Thursday, August 24, 2017 3:20:12 AM CEST Kevin Kofler wrote:
> Adam Samalik wrote:
> > all their dependencies, we need to build them. But, for example, a pretty
> > commonly needed thing like autotools [3] has pretty crazy build
> > dependencies [4] including Java, gtk2, gtk3, erlang, X11, pyth
On Tue, Aug 22, 2017 at 3:33 AM, Yaakov Selkowitz
wrote:
>
> Then you should orphan it. If nobody takes it up, then it will be
> automatically retired.
>
I thought about it, but it's so hard to update it seems to me to better
retire and reduce the noise :-m
--
Ismael Olea
http://olea.org/
Dne 24.8.2017 v 04:10 Rudolf Kastl napsal(a):
Hey,
I am currently maintaining llvm trunk and mesa git snapshot repos for f25 and f26 at:
https://copr.fedorainfracloud.org/coprs/che.
One thing i would love to see is the ability to have a buildrepo and a release repo and beeing able to sync fro
> On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
>> Hello Fedora devels and users,
>>
>> more than three years ago, the same topic started discussion if we
>> want
>> this package in Fedora or not and how [1]. The discussion resulted
>> mostly in flames and in the removal of the dependency o
On 23/08/17 04:46 AM, Miroslav Suchý wrote:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For building packages
> before pull request is merged? Do you have your set up described
> somewhere? What is the name of your pr
On 24 August 2017 at 08:45, Marius Vollmer wrote:
> If appstream-builder finds two packages that both contain metainfo for
> the same component id, what does it do?
If I understand correctly, in appstream-builder it's an error, and the
"first encountered" component wins.
> What should it do? W
2017-08-22 5:17 GMT+02:00 Michal Novotny :
> Hello,
>
> we will have soon a planning meeting that should determine a more long-term
> strategy and bring us to a team agreement on what COPR currently is and what
> it should be in half a year or so.
>
> I would like to kindly ask for some input here
Hello Rudolf,
On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl wrote:
> Hey,
>
> I am currently maintaining llvm trunk and mesa git snapshot repos for f25
> and f26 at: https://copr.fedorainfracloud.org/coprs/che.
>
> One thing i would love to see is the ability to have a buildrepo and a
> release
Hi,
I'm getting failed builds [1] in rawhide and f27 because the macro
%py3_install fails when called with arguments. It was fine until f26.
The package is rhythmbox-ampache, and I call the macro like this:
%global py_install_args --no-glib-compile-schemas
%install
%py3_install %py_install_arg
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> I propose to keep AppStream metainfo data in packages, and map from
>> package names to module names during construction of the collection
>> data.
>
> Can you elaborate a bit? At the moment in Fedora we generate the
On Thursday, August 24, 2017 2:32:02 AM CEST Moez Roy wrote:
> On Mon, Jul 31, 2017 at 12:13 PM, Kevin Fenzi wrote:
> > ok, I rebuilt the following ones. The ones with F next to them failed to
> >
> > build:
> > autotrace-0.31.1-44.fc26.src.rpm
> > converseen-0.9.6.2-1.fc27.src.rpm
> > dmtx
Owen Taylor writes:
> The current expectation is that the only way that modules are going to
> show up in GNOME Software is when they are safely wrapped up as a
> Flatpak.
Ah, that's nice. If we follow the same line for Cockpit, we would only
show container images. This would certainly simplif
Le 24/08/2017 à 08:58, Adam Williamson a écrit :
> On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
>> Le 24/08/2017 à 02:32, Moez Roy a écrit :
>>
>>> The soname bump requires packages that depend on it need to be rebuilt, so
>>> I updated ImageMagick to 7.0.6-9.
>>
>>
>> Such a version bump
On 18 Aug 2017 4:42 pm, "Jakub Jelen" wrote:
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> Hello Fedora devels and users,
>
> more than three years ago, the same topic started discussion if we
> want
> this package in Fedora or not and how [1]. The discussion resulted
> mostly in flames
From 6f9f8dfc0e762c2ce44802b3119443ac919de853 Mon Sep 17 00:00:00 2001
From: Petr Písař
Date: Aug 24 2017 07:03:18 +
Subject: 0.28 bump
---
diff --git a/.gitignore b/.gitignore
index 756dc05..4e69ac4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Shell-Config-Generate-0.26.tar.gz
On Wed, 23 Aug 2017 22:16:40 -0500
Michael Cronenworth wrote:
> Hi all,
>
> An ImageMagick update (6.9 => 7.0) with an SONAME bump and other
> breakage has been pushed to F25 and higher.
>
> First, the update introduces regressions on s390x and ppc64 arches.
> - https://bugzilla.redhat.com/show
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> - Metainfo is in packages, but we need to be installing modules.
>
> How are we going to be installing modules in a modular-system?
> PackageKit is only going to be able to install packages so
> gnome-software will
On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
> Le 24/08/2017 à 02:32, Moez Roy a écrit :
>
> > The soname bump requires packages that depend on it need to be rebuilt, so
> > I updated ImageMagick to 7.0.6-9.
>
>
> Such a version bump in stable branch is not acceptable.
>
> ImageMagick
84 matches
Mail list logo
