[Bug 1409275] perl-threads-shared-1.54 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1409275 --- Comment #8 from Fedora Update System --- perl-threads-shared-1.54-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. -- You are

ppisar pushed to perl-Net-HTTP (f24). "6.12 bump"

From b820decd0d128f408a393d0f8bf2e6d9a2b2ed9b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Fri, 6 Jan 2017 08:36:32 +0100 Subject: 6.12 bump --- .gitignore | 1 + perl-Net-HTTP.spec | 23 +++ sources| 2 +-

ppisar pushed to perl-Net-HTTP (f24). "Mandatory Perl build-requires added "

From eb91eeb6ccc09649b1bed8fb2604d1344fa4620a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Fri, 24 Jun 2016 10:08:51 +0200 Subject: Mandatory Perl build-requires added ---

ppisar pushed to perl-Net-HTTP (f25). "6.12 bump"

From 8cd091711a4403b90d4ddac80fbd9a6acab8fbd5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Fri, 6 Jan 2017 08:36:32 +0100 Subject: 6.12 bump --- .gitignore | 1 + perl-Net-HTTP.spec | 23 +++ sources| 2 +-

[Bug 1410277] perl-Net-HTTP-6.12 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1410277 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

ppisar pushed to perl-Net-HTTP (master). "6.12 bump"

From 8cd091711a4403b90d4ddac80fbd9a6acab8fbd5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Fri, 6 Jan 2017 08:36:32 +0100 Subject: 6.12 bump --- .gitignore | 1 + perl-Net-HTTP.spec | 23 +++ sources| 2 +-

[Bug 1410162] perl-PDL-2.17.0-1.fc26 FTBFS: tests segfaut on 64-bit PowerPC

https://bugzilla.redhat.com/show_bug.cgi?id=1410162 --- Comment #7 from Fedora Update System --- perl-PDL-2.16.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-75eb9845f8 -- You are receiving this mail

[Bug 1410162] perl-PDL-2.17.0-1.fc26 FTBFS: tests segfaut on 64-bit PowerPC

https://bugzilla.redhat.com/show_bug.cgi?id=1410162 --- Comment #6 from Fedora Update System --- perl-PDL-2.16.0-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-499e3ba8d4 -- You are receiving this mail

ppisar uploaded Net-HTTP-6.12.tar.gz for perl-Net-HTTP

5353f1c5914f90338f05342904224ff7998133e025de4389a68e9abf521040a1f9bb4c9b8c13f65bb014947fc3186c1d7e078a699f40a3edf5afed3a0da8746d Net-HTTP-6.12.tar.gz

[Bug 1410641] perl-XXX-0.31 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1410641 --- Comment #1 from Fedora Update System --- perl-XXX-0.31-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2964893414 -- You are receiving this mail

[Bug 1410641] perl-XXX-0.31 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1410641 Jitka Plesnikova changed: What|Removed |Added Status|NEW |MODIFIED

jplesnik pushed to perl-XXX (f25). "0.31 bump"

From 46b0fbfd252d680c6d2ad375b156544e6c67c8a0 Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Fri, 6 Jan 2017 08:21:41 +0100 Subject: 0.31 bump --- .gitignore| 1 + perl-XXX.spec | 7 +-- sources | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-)

jplesnik pushed to perl-XXX (master). "0.31 bump"

From 8e1930aaf429fd4850f026086ec706df70889a27 Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Fri, 6 Jan 2017 08:21:41 +0100 Subject: 0.31 bump --- .gitignore| 1 + perl-XXX.spec | 7 +-- sources | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-)

jplesnik uploaded XXX-0.31.tar.gz for perl-XXX

4da0d9cb065c4c6022559340136352c4366e77b2d5cf23f105723b320ebd6e02ddefb311fab9a9267e6500546d4061f2a669d00bc00f4524e8069c922bbc3aca XXX-0.31.tar.gz

ppisar pushed to perl-PDL (f25). "Correct changelog entry"

From 0eaf03433944321984ffd73ea6c4f78c7bdf19bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Fri, 6 Jan 2017 08:02:06 +0100 Subject: Correct changelog entry --- perl-PDL.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

ppisar pushed to perl-PDL (f24). "Disable fused multiply-add instructions on 64-bit PowerPC because of GSL (..more)"

From 8a19c6493abfdc97e8c2c9e6038a7ee0a3b66f8d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Thu, 5 Jan 2017 17:47:17 +0100 Subject: Disable fused multiply-add instructions on 64-bit PowerPC because of GSL Also remove -O0 -fsigned-char options that

ppisar pushed to perl-PDL (f25). "Disable fused multiply-add instructions on 64-bit PowerPC because of GSL (..more)"

From 5e553abc29c2f330474d275626afa3aaa7c9d86b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Thu, 5 Jan 2017 17:47:17 +0100 Subject: Disable fused multiply-add instructions on 64-bit PowerPC because of GSL Also remove -O0 -fsigned-char options that

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thursday, January 5, 2017, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher wrote: > > # Overview > > > > For many years, Fedora has supported multilib by carrying > parallel-installable > > libraries in /usr/lib[64]. This was necessary for a very long

Re: Proposal: Rethink Fedora multilib support

On Thursday, January 5, 2017, Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying > parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in > order to > support 32-bit applications running

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following Fedora EPEL 7 Security updates need testing: Age URL 669 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 431 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 150

[EPEL-devel] Fedora EPEL 6 updates-testing report

The following Fedora EPEL 6 Security updates need testing: Age URL 547 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031 python-virtualenv-12.0.7-1.el6 541 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 473

[EPEL-devel] Fedora EPEL 5 updates-testing report

The following Fedora EPEL 5 Security updates need testing: Age URL 788 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849 sblim-sfcb-1.3.8-2.el5 431 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516 mcollective-2.8.4-1.el5 403

Re: Proposal: Rethink Fedora multilib support (Take Two!)

Stephen Gallagher (sgall...@redhat.com) said: > The main reason for this is trying to simplify the module-building process. We > really don't want to attempt to build both arches within the same buildroot > for > most of the reasons we've established in this extended conversation. My first >

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On 01/05/2017 08:47 PM, Pavel Raiskup wrote: >> * Ship only one arch in the repositories and allow users to trivially >> enable the repositories for other arches through DNF if they have need. > > Hms, that's promising. I don't see any obvious issue here, only that > there might be packages that

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On 01/05/2017 07:20 PM, Josh Boyer wrote: >> * Switch to using the Debian style of multi-arch layout, which instead of >> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would >> include the emergence of a de-facto standard for system layout between the >> major >>

Re: Proposal: Rethink Fedora multilib support (Take Two!)

Stephen Gallagher wrote: > * Switch to using the Debian style of multi-arch layout, which instead of > /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this > would include the emergence of a de-facto standard for system layout > between the major distributions. [snip] > ==

Re: Applications with AppData and not visible in the software center

On Thu, Jan 5, 2017 at 6:56 AM, Richard Hughes wrote: > * tilp2 It turns out that I am very silly, and, when writing the appstream file for tilp2, never changed "comical.desktop" in the template here [1] to "tilp.desktop". ...whoops! I can, uh, fix that. However,

Re: Applications with AppData and not visible in the software center

On 05/01/17 05:52 AM, Richard Hughes wrote: > On 5 January 2017 at 13:41, Ville Skyttä wrote: >> This one has the too small icon "problem". It only has a 32x32 one, >> and with my (also wearing the Portecle upstream hat) graphical skills >> a new, better one simply will not

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote: > Two suggestions were raised as alternatives to the container approach: > > * Switch to using the Debian style of multi-arch layout, which instead of > /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this

Re: Proposal: Rethink Fedora multilib support

I'm wholeheartedly against this. I also view personally containers *just* as a thing to solve subset of real-world problems, but not a army knife for everything. IOW, enforcing users to use containers instead of multilib feature looks a bit hostile. Have other distros already done this

Re: 2017-01-05 @ 18:00 UTC - Outage for qadevel.cloud replacement (for real this time)

On Thu, 5 Jan 2017 10:42:09 -0700 Tim Flink wrote: > I realize this is a little last minute but persona has been completely > shut down now (so auth is no longer possible) and the last issue that > was preventing migration was taken care of yesterday. The outage is complete

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thu, Jan 5, 2017 at 7:20 PM, Josh Boyer wrote: > On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: >> On 01/05/2017 11:03 AM, Stephen Gallagher wrote: >>> # Overview >>> >>> For many years, Fedora has supported multilib by carrying >>>

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver wrote: > On 1/5/2017 9:12 AM, Jonathan Wakely wrote: >> >> On 05/01/17 09:56 -0700, Chris Murphy wrote: >>> >>> Teamviewer comes in an i686 only package for Fedora. So is there going >>> to be this interim approach, and then

[Bug 1410641] New: perl-XXX-0.31 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1410641 Bug ID: 1410641 Summary: perl-XXX-0.31 is available Product: Fedora Version: rawhide Component: perl-XXX Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher wrote: >> # Overview >> >> For many years, Fedora has supported multilib by carrying >> parallel-installable >> libraries in /usr/lib[64]. This was necessary for a very long

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 2:40 PM, Japheth Cleaver wrote: > I feel like if this happens it will hasten the day when those of us > primarily working in EL-variant land have to consider a need for a new, > EL-forward, RPM-based open source "community" OS. > > Fedora's role of

[Bug 1409626] Upgrade perl-Config-Model-TkUI to 1.359

https://bugzilla.redhat.com/show_bug.cgi?id=1409626 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA

[Bug 1409618] Upgrade perl-Config-Model to 2.097

https://bugzilla.redhat.com/show_bug.cgi?id=1409618 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thu, Jan 5, 2017 at 6:08 PM, Brendan Conoboy wrote: > On 01/05/2017 02:08 PM, Stephen Gallagher wrote: > [snip] >> >> == multi-arch layout == >> * Moving the locations of all of the system libraries would potentially >> still >> break third-party applications that were

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On 01/05/2017 02:08 PM, Stephen Gallagher wrote: [snip] == multi-arch layout == * Moving the locations of all of the system libraries would potentially still break third-party applications that were compiled to expect libraries to be in the /usr/lib[64] paths. This would be a similar problem to

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher wrote: >> # Overview >> >> For many years, Fedora has supported multilib by carrying >> parallel-installable >> libraries in /usr/lib[64]. This was necessary for a very long

Re: Are partial upgrades expected to work in rawhide?

> On 01/05/2017 08:19 PM, Lukas Slebodnik wrote: > > Even if we had this capability, I'm not sure if we would use it in > rawhide. It could considerably increase the size of the dependency > information. > You would remove "temporary versions" with official release. I know it's not ideal and

Re: Packages owned by epienbro (Packages now looking for new points of contact!)

Per https://pagure.io/fesco/issue/1661 I have orphaned their packages: Point of contact: rpms/mingw-SDL -- MinGW Windows port of SDL cross-platform multimedia library ( master f25 f24 epel7 ) rpms/mingw-SDL2 -- MinGW Windows port of SDL2 cross-platform multimedia library ( master

Proposal: Rethink Fedora multilib support (Take Two!)

On 01/05/2017 11:03 AM, Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in order to > support 32-bit applications running on a 64-bit deployment. However,

Re: Proposal: Rethink Fedora multilib support

On 1/5/2017 9:12 AM, Jonathan Wakely wrote: On 05/01/17 09:56 -0700, Chris Murphy wrote: Teamviewer comes in an i686 only package for Fedora. So is there going to be this interim approach, and then yet another change when they're expected to use FlatPak? That's a lot of changes... And are these

Re: Interpreting FAF reports

On Seg, 2017-01-02 at 19:21 +0100, jfi...@fedoraproject.org wrote: > Hi Sérgio, > > It depends on what is your goal. > > Do you want to fix the crash? > > > You can log in to FAF and check if there is a contact email or a comment. If there is not additional information, you can just wait until

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 11:03 AM, Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in order to > support 32-bit applications running on

Re: Packages owned by epienbro (Packages now looking for new points of contact!)

On Thu, 5 Jan 2017 13:45:56 -0600 Michael Cronenworth wrote: > On 01/02/2017 12:49 PM, Sandro Mani wrote: > > Given the sad news of the passing of Erik van Pienbroek, I suppose > > at this stage his packages should be orphaned. > > > > I've had a look at what packages he's

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 08:03 AM, Stephen Gallagher wrote: ## Disadvantages * If we eliminate multilib entirely, all applications that use 32-bit libs will have to either install a 32-bit host OS or install into a container. This may be a difficult transition for some users. * Mitigation: develop and

[Bug 1409275] perl-threads-shared-1.54 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1409275 --- Comment #7 from Fedora Update System --- perl-threads-2.12-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving

Re: Packages owned by epienbro

On 01/02/2017 12:49 PM, Sandro Mani wrote: Given the sad news of the passing of Erik van Pienbroek, I suppose at this stage his packages should be orphaned. I've had a look at what packages he's marked as point of contact in pkgdb [1], in particular the following are packages without

[Bug 1410162] perl-PDL-2.17.0-1.fc26 FTBFS: tests segfaut on 64-bit PowerPC

https://bugzilla.redhat.com/show_bug.cgi?id=1410162 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

ppisar pushed to perl-PDL (master). "Disable fused multiply-add instructions on 64-bit PowerPC because of GSL (..more)"

From 517834ea6133ddb47e76f2dcf573c62b99597ea8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Thu, 5 Jan 2017 17:47:17 +0100 Subject: Disable fused multiply-add instructions on 64-bit PowerPC because of GSL Also remove -O0 -fsigned-char options that

Re: Proposal: Rethink Fedora multilib support

On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote: > Which definitely changes how software is built. Containers also change the way software must be written in some cases, since they expect there to be one main process and don't expect that main process to interact with other "main"

Schedule for Friday's FESCo Meeting (2017-01-06)

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-01-06 16:00 UTC' Links to all issues below

Re: Proposal: Rethink Fedora multilib support

Once upon a time, M. Edward (Ed) Borasky said: > But seriously ... aren't there plenty of distros that support older 32-bit > hardware ... enough so that Fedora can draw a line in the sand and say, > Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other >

Re: Are partial upgrades expected to work in rawhide?

On 01/05/2017 08:19 PM, Lukas Slebodnik wrote: I think that we need to wait for https://bugzilla.redhat.com/show_bug.cgi?id=1320954 Even if we had this capability, I'm not sure if we would use it in rawhide. It could considerably increase the size of the dependency information. But I

Re: Are partial upgrades expected to work in rawhide?

I think that we need to wait for https://bugzilla.redhat.com/show_bug.cgi?id=1320954 But I think it still would be good to to at least rebuild images. LS ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 2:11 PM, M. Edward (Ed) Borasky wrote: > > > On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh wrote: > >> >> Well we will be retired at that point, and playing shuffle board. > > > Well, I'm retired *now* and I'm still a Fedora end-user.

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh wrote: > Well we will be retired at that point, and playing shuffle board. > Well, I'm retired *now* and I'm still a Fedora end-user. ;-) But seriously ... aren't there plenty of distros that support older 32-bit hardware ...

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 1:42 PM, Dennis Gilmore wrote: > On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote: >> On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: >> > On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote: >> >> #

Re: Proposal: Rethink Fedora multilib support

Stephen Gallagher wrote: > However, it still doesn't solve the problem that we have today, which is > that we have to do a lot of hacky shuffling around of packages in order to > take packages built in i686 and drop them onto the x86_64 repository. Then just have the users enable the 32-bit

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 01:36 PM, Stephen John Smoogen wrote: > On 5 January 2017 at 13:31, Daniel J Walsh wrote: >>> You just described a fundamental change to how people would need to >>> build 32-bit applications locally. They don't have to install a >>> VM/chroot to do that today,

Re: Proposal: Rethink Fedora multilib support

On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote: > On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: > > On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote: > >> # Overview > >> > >> For many years, Fedora has supported multilib by carrying

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh wrote: > > > On 01/05/2017 01:26 PM, Josh Boyer wrote: >> On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher >> wrote: >>> On 01/05/2017 11:17 AM, Tom Hughes wrote: On 05/01/17 16:03, Stephen Gallagher

Re: Proposal: Rethink Fedora multilib support

On 5 January 2017 at 13:31, Daniel J Walsh wrote: > >> You just described a fundamental change to how people would need to >> build 32-bit applications locally. They don't have to install a >> VM/chroot to do that today, they would in a containerized multilib >> solution. I

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: > On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote: >> # Overview >> >> For many years, Fedora has supported multilib by carrying >> parallel-installable libraries in /usr/lib[64]. This was necessary for

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 01:26 PM, Josh Boyer wrote: > On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher > wrote: >> On 01/05/2017 11:17 AM, Tom Hughes wrote: >>> On 05/01/17 16:03, Stephen Gallagher wrote: >>> For many years, Fedora has supported multilib by carrying

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher wrote: > On 01/05/2017 11:17 AM, Tom Hughes wrote: >> On 05/01/17 16:03, Stephen Gallagher wrote: >> >>> For many years, Fedora has supported multilib by carrying >>> parallel-installable >>> libraries in /usr/lib[64]. This

Re: F26 System Wide Change: pkgconf as system pkg-config implementation

Hello, Owen Taylor wrote: > I think it would be really helpful to know a bit more background - who > are the people developing pkgconf, how did the project start? I am one of the primary maintainers of pkgconf. It started initially, to provide a library interface for various tools to make use

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 11:28 AM, Christian Schaller wrote: > While most desktop applications have migrated to 64 bit at this point > there are > still many that hasn't. Steam for instance is still 32-bit afaict. So > doing a clean > cutover like this feel a bit to drastic to

Re: Proposal: Rethink Fedora multilib support

On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying > parallel-installable libraries in /usr/lib[64]. This was necessary for a > very long time in order to support 32-bit applications running on a 64-bit

2017-01-05 @ 18:00 UTC - Outage for qadevel.cloud replacement (for real this time)

I realize this is a little last minute but persona has been completely shut down now (so auth is no longer possible) and the last issue that was preventing migration was taken care of yesterday. I'm planning to take qadevel down (phabricator, some docs etc.) today so that I can finally replace it

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 05:25 PM, Stephen Gallagher wrote: Building of software shouldn't be changed at all in most cases. The main difference would be installation/deployment. The idea would be that instead of the 32-bit and 64-bit runtimes being installed directly in parallel on the base system, they

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 05, 2017 at 05:09:59PM +, Daniel P. Berrange wrote: > More work for the end user to keep their systems updated. Containers in > general are a retrograde step in this area, since instead of being able > todo a simple "dnf update" on the host and have everything updated, you > have

Re: Proposal: Rethink Fedora multilib support

On Jan 5, 2017 9:03 AM, "Jonathan Wakely" wrote:. The main > difference would be installation/deployment. The idea would be that > instead of > the 32-bit and 64-bit runtimes being installed directly in parallel on the > base > system, they would instead be installed

Re: Proposal: Rethink Fedora multilib support

On 05/01/17 09:56 -0700, Chris Murphy wrote: Teamviewer comes in an i686 only package for Fedora. So is there going to be this interim approach, and then yet another change when they're expected to use FlatPak? That's a lot of changes... And are these two approaches compatible with the other

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in order to > support 32-bit applications running on a 64-bit

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 05, 2017 at 11:56:28AM -0500, Stephen Gallagher wrote: > > It might be different if we could build 32-bit sub-packages in the 64-bit mock > environment, but the tools are *really* not equipped to handle that today (in > particular because Fedora doesn't do cross-compilation; we just

Re: Proposal: Rethink Fedora multilib support

On 05/01/17 11:25 -0500, Stephen Gallagher wrote: On 01/05/2017 11:17 AM, Tom Hughes wrote: Would this mean I had to do some special dance to enter a container environment in order to work with a 32 bit build rather than just telling our build scripts to use "gcc -m32" when compiling?

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 11:42 AM, Tom Hughes wrote: > On 05/01/17 16:38, Thorsten Leemhuis wrote: >> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: >>> [...] >>> ## Advantages >>> >>> * Simplification of build-tree creation. We wouldn't have to maintain the >>> lists >>> and hacks that are required to

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 5, 2017 at 9:19 AM, Stephen Gallagher wrote: > On 01/05/2017 11:15 AM, Michael Cronenworth wrote: >> On 01/05/2017 10:03 AM, Stephen Gallagher wrote: >>> * Do we need to care about 32-bit GUI applications on a 64-bit system? >>> Should we >>> decide that flatpak

Re: F26 System Wide Change: pkgconf as system pkg-config implementation

On Wed, 2017-01-04 at 09:20 +0100, Jan Kurik wrote: > = System Wide Change: pkgconf as system pkg-config implementation = > https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_i > mplementation > > Change owner(s): > * Igor Gnatenko > * Neal Gompa > > This change switches

Re: Proposal: Rethink Fedora multilib support

On Thu, 5 Jan 2017 16:42:25 + Tom Hughes wrote: > On 05/01/17 16:38, Thorsten Leemhuis wrote: > > Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: > >> [...] > >> ## Advantages > >> > >> * Simplification of build-tree creation. We wouldn't have to > >> maintain the lists

Re: Proposal: Rethink Fedora multilib support

On 05/01/17 16:38, Thorsten Leemhuis wrote: Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: [...] ## Advantages * Simplification of build-tree creation. We wouldn't have to maintain the lists and hacks that are required to make sure that multilib packages land in the correct repositories.

Re: Proposal: Rethink Fedora multilib support

On 05/01/17 16:25, Stephen Gallagher wrote: Building of software shouldn't be changed at all in most cases. The main difference would be installation/deployment. The idea would be that instead of the 32-bit and 64-bit runtimes being installed directly in parallel on the base system, they would

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 11:35 AM, Michael Cronenworth wrote: > On 01/05/2017 10:19 AM, Stephen Gallagher wrote: >> Are we certain that it couldn't be run from within a container, though? >> Possibly >> via a wrapper? > > I would have to investigate because I have never had a need to install a > container.

Re: Proposal: Rethink Fedora multilib support

Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: > [...] > ## Advantages > > * Simplification of build-tree creation. We wouldn't have to maintain the > lists > and hacks that are required to make sure that multilib packages land in the > correct repositories. > [...] Just wondering: Why don't

Re: Proposal: Rethink Fedora multilib support

On Thu, 5 Jan 2017, at 04:28 PM, Christian Schaller wrote: > While most desktop applications have migrated to 64 bit at this point > there are > still many that hasn't. Steam for instance is still 32-bit afaict. So > doing a clean > cutover like this feel a bit to drastic to me and I am not sure

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 10:19 AM, Stephen Gallagher wrote: Are we certain that it couldn't be run from within a container, though? Possibly via a wrapper? I would have to investigate because I have never had a need to install a container. I've never gotten on board the "container train." :) My main

Re: Proposal: Rethink Fedora multilib support

While most desktop applications have migrated to 64 bit at this point there are still many that hasn't. Steam for instance is still 32-bit afaict. So doing a clean cutover like this feel a bit to drastic to me and I am not sure we have the market power to 'force' vendors to quickly migrate to

Fedora Rawhide-20170105.n.0 compose check report

Missing expected images: Cloud_base qcow2 x86_64 Atomic qcow2 x86_64 Cloud_base raw-xz x86_64 Atomic raw-xz x86_64 Failed openQA tests: 15/103 (x86_64), 1/2 (arm) New failures (same test did not fail in Rawhide-20170104.n.0): ID: 53769 Test: x86_64 Server-dvd-iso

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 11:15 AM, Michael Cronenworth wrote: > On 01/05/2017 10:03 AM, Stephen Gallagher wrote: >> * Do we need to care about 32-bit GUI applications on a 64-bit system? >> Should we >> decide that flatpak is the official answer for such cases? > > I care. What impact would this have on

Re: Proposal: Rethink Fedora multilib support

On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote: > * Do we need to care about 32-bit GUI applications on a 64-bit system? Should > we > decide that flatpak is the official answer for such cases? The main thing that comes to mind is Wine. Perhaps PlayOnLinux could be made into a

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 11:17 AM, Tom Hughes wrote: > On 05/01/17 16:03, Stephen Gallagher wrote: > >> For many years, Fedora has supported multilib by carrying >> parallel-installable >> libraries in /usr/lib[64]. This was necessary for a very long time in order >> to >> support 32-bit applications

Re: Proposal: Rethink Fedora multilib support

On 05/01/17 16:03, Stephen Gallagher wrote: For many years, Fedora has supported multilib by carrying parallel-installable libraries in /usr/lib[64]. This was necessary for a very long time in order to support 32-bit applications running on a 64-bit deployment. However, in today's new container

Re: Proposal: Rethink Fedora multilib support

On 01/05/2017 10:03 AM, Stephen Gallagher wrote: * Do we need to care about 32-bit GUI applications on a 64-bit system? Should we decide that flatpak is the official answer for such cases? I care. What impact would this have on Wine? If users are unable to use 32-bit Windows apps, which are

Proposal: Rethink Fedora multilib support

# Overview For many years, Fedora has supported multilib by carrying parallel-installable libraries in /usr/lib[64]. This was necessary for a very long time in order to support 32-bit applications running on a 64-bit deployment. However, in today's new container world, there is a whole new

[Bug 347901] Port perl-IO-Socket-SSL to use NSS library for cryptography

https://bugzilla.redhat.com/show_bug.cgi?id=347901 Nikos Mavrogiannopoulos changed: What|Removed |Added Status|ASSIGNED|CLOSED

Re: F26 System Wide Change: Switch OpenLDAP from NSS to OpenSSL

On Thu, 2017-01-05 at 16:02 +0100, Tomasz Torcz wrote: > On Thu, Jan 05, 2017 at 03:55:41PM +0100, Jan Kurik wrote: > > = System Wide Change: Switch OpenLDAP from NSS to OpenSSL = > > https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL > > > > Change owner(s): > > * Matus Honek > > > >

  1   2   >