On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
> It would also be nice if:
>
> PYTHON=/usr/bin/python3 %configure
>
> didn't (silently) do the wrong thing by default. For a long time we
> shipped a nbdkit-python3 package which was using python2, and that was
> found to be the ca
We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer. The apps include:
* albumart
* apitrace-gui
* appstream
* asylum
* audience
* bomber
* bovo
* calligra-braindump
* cer
Dne 5.1.2017 v 12:56 Richard Hughes napsal(a):
> As a reminder, you can validate AppData files using: appstream-util
> validate-relax file.appdata.xml
Just to clarify, according to the guidelines, the validation is a *MUST*:
https://fedoraproject.org/wiki/Packaging:AppData#app-data-validate_usa
On 01/05/2017 11:58 AM, Michael Schwendt wrote:
On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
It would also be nice if:
PYTHON=/usr/bin/python3 %configure
didn't (silently) do the wrong thing by default. For a long time we
shipped a nbdkit-python3 package which was using pyt
On Thu, Jan 5, 2017 at 1:56 PM, Richard Hughes wrote:
[...]
> * portecle
[...]
> If you want any suggestions or advice, I'm happy to help.
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 s
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 appear, and simply resizing/scaling
> the current one is not IMO an opti
Announcing the creation of a new nightly release validation test event
for Fedora 26 Rawhide 20170105.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
Let's close this up.
> > Idea #1: Do not block on optical media issues for Alpha and Beta releases
> > ~
Nobody argued against this since last time, so I'm going to propose criterion
adjustment on the test list.
> > Idea #2
= System Wide Change: Switch OpenLDAP from NSS to OpenSSL =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL
Change owner(s):
* Matus Honek
Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
cypto. OpenLDAP is going to be compiled with OpenSSL, instead.
== Detailed D
On Thu, Jan 05, 2017 at 03:41:56PM +0200, 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 appear, and simply resizing/scaling
> the current one is no
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
>
> Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
> cyp
On 01/05/2017 10:02 AM, 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
>>
>> Currently, OpenLDAP in
- Original Message -
> From: jfi...@fedoraproject.org
> To: "Development discussions related to Fedora"
>
> Sent: Wednesday, December 14, 2016 7:18:32 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
>
> I agree with Zbyzsek on this.
>
> What about to carry a tiny down-stream pa
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
> >
> > Cu
# 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 option.
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 st
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
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 runni
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
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 install_repository_nfs_gr
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 Win
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 con
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 co
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 we
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
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.
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 i
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.
[..
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 and hacks that are r
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 Fedora
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 is the official answer
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 ma
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?
Buildin
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 sp
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 depl
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 plat
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 into effectively a chroot w
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 to
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 wou
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
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 me and I am not sure
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 o
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 was necessary for a ve
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
parallel-installable
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 a
>> very long tim
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 don't think it's fai
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 wrote:
> For many years, Fedora h
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
> >> parallel-inst
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, they would in a con
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 reposi
On Thu, 05 Jan 2017 11:58:06 -0600
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 a very
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:
>> >> # Overview
>> >>
>> >> For many years,
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 ... enough so that Fedor
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. ;-)
>
> But seriously ... aren't ther
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 devel-le...
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 thin
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
> stuff and run it in
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 ca
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" process
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 comaintai
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 ma
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 marked as point of cont
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 a 64-bit deployment. H
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 so
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
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, in
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 f25
> 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 w
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 time in order
>> to
>
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 t
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 compiled to expect librar
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 breaking all sorts of thi
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 time in order
>> to
>
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 yet another change when t
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
>>> parallel-installable
>>> libraries in /usr/lib[64]
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 movement?
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 woul
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 appear, and simply resi
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, interestingly, it seems that "
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]
> == multi-
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
>> distrib
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
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
> prop
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 on a 64-bit deployment.
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 time in
> order to
>
85 matches
Mail list logo
