Re: F27 System Wide Change: Kerberos KCM credential cache by default
On Wed, Jun 21, 2017 at 08:23:10AM +0200, Jakub Hrozek wrote: > On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote: > > On 06/20/2017 02:45 PM, Jakub Hrozek wrote: > > > On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote: > > > > On 06/20/2017 04:21 AM, Jakub Hrozek wrote: > > > > > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: > > > > > > Hi, > > > > > > > > > > > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > > > > > > > = System Wide Change: Kerberos KCM credential cache by default = > > > > > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > > > > > "The design is described in more detail on the SSSD wiki." > > > > > > > > > > > > It is not, the link redirects to a page about fedorahosted.org > > > > > > retirement. > > > > > Sorry, your are right, I fixed the link (this feature was submitted > > > > > during f-26 timeframe when fh.o was still up and I forgot to change > > > > > the > > > > > links when I re-submitted the feature..) > > > > > > > > > > The correct link is: > > > > > https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html > > > > > > > > > > > > Change owner(s): > > > > > > > * Jakub Hrozek > > > > > > > > > > > > > > Default to a new Kerberos credential cache type called KCM which > > > > > > > is > > > > > > > better suited for containerized environments and provides a better > > > > > > > user experience in the general case as well. > > > > > > I wonder what is the relation to the daemon of the same name ansd > > > > > > similar purpose distributed with Heimdal > > > > > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. > > > > > > Will they be compatible? > > > > > Yes, more or less. The wire protocol is the same and I used MIT client > > > > > libraries with Heimdal server bit during development. Not all server > > > > > commands are implemented, only the subset that MIT client implements. > > > > > > > > > > There are some features supported by Heimdal but not supported yet by > > > > > SSSD's > > > > > KCM, like renewals, but those will be added. There are some features > > > > > we > > > > > chose to explicitly not add (or not enable by default), like listing > > > > > all > > > > > ccaches known to KCM server by root. > > > > > > > > > > Hopefully the sssd upstream design page would help.. > > > > > > > > > > > Will code be shared? > > > > > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We > > > > > also want to support multiple 'storage back ends' for the ccaches, > > > > > while > > > > > Heimdal only stores the ccaches in memory. > > > > > ___ > > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > How will I access this feature inside of a container? > > > Bind-mount the KCM server socket into the container. > > > > > > > If there is a leaked > > > > socket into the container, what kind of access control is built into > > > > your > > > > server to prevent root inside of one container effecting/accessing the > > > > credentials of different containers? > > > Well, UID of the peer accessing the socket is the access control key right > > > now. Unlike Heimdal's KCM, root doesn't have any special powers (with > > > Heimdal's KCM, root can list any ccache, with our implementation, only > > > that of UID 0). > > > > > > Do you have a different suggestion? > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > I would want an SELinux check added to it, to allow us to keep the caches > > separate, based on SELinux. This would mean you would need to have an > > SELinux label associated with each cache. btw I filed https://pagure.io/SSSD/sssd/issue/3434 to track this > > > > I would also be careful about capabilities. > > > > The bottom line with this is if I have two different containers creating > > keyrings, how does you cache differentiate the the keyrings from each other. > > If I am in container1 and I do a kinit, and it container2, I can use the > > keyring, that is a HUGE security violation. > > Well, isn't the kernel KEYRING: cache (which we default to..) working > exactly this way at the moment? > > With the KCM deamon, you at least selectively mount the KCM socket into > the containers where you /want/ to share the ccache based on the peer > UID. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Kerberos KCM credential cache by default
On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote: > On 06/20/2017 02:45 PM, Jakub Hrozek wrote: > > On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote: > > > On 06/20/2017 04:21 AM, Jakub Hrozek wrote: > > > > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: > > > > > Hi, > > > > > > > > > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > > > > > > = System Wide Change: Kerberos KCM credential cache by default = > > > > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > > > > "The design is described in more detail on the SSSD wiki." > > > > > > > > > > It is not, the link redirects to a page about fedorahosted.org > > > > > retirement. > > > > Sorry, your are right, I fixed the link (this feature was submitted > > > > during f-26 timeframe when fh.o was still up and I forgot to change the > > > > links when I re-submitted the feature..) > > > > > > > > The correct link is: > > > > https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html > > > > > > > > > > Change owner(s): > > > > > > * Jakub Hrozek > > > > > > > > > > > > Default to a new Kerberos credential cache type called KCM which is > > > > > > better suited for containerized environments and provides a better > > > > > > user experience in the general case as well. > > > > > I wonder what is the relation to the daemon of the same name ansd > > > > > similar purpose distributed with Heimdal > > > > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. > > > > > Will they be compatible? > > > > Yes, more or less. The wire protocol is the same and I used MIT client > > > > libraries with Heimdal server bit during development. Not all server > > > > commands are implemented, only the subset that MIT client implements. > > > > > > > > There are some features supported by Heimdal but not supported yet by > > > > SSSD's > > > > KCM, like renewals, but those will be added. There are some features we > > > > chose to explicitly not add (or not enable by default), like listing all > > > > ccaches known to KCM server by root. > > > > > > > > Hopefully the sssd upstream design page would help.. > > > > > > > > > Will code be shared? > > > > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We > > > > also want to support multiple 'storage back ends' for the ccaches, while > > > > Heimdal only stores the ccaches in memory. > > > > ___ > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > How will I access this feature inside of a container? > > Bind-mount the KCM server socket into the container. > > > > > If there is a leaked > > > socket into the container, what kind of access control is built into your > > > server to prevent root inside of one container effecting/accessing the > > > credentials of different containers? > > Well, UID of the peer accessing the socket is the access control key right > > now. Unlike Heimdal's KCM, root doesn't have any special powers (with > > Heimdal's KCM, root can list any ccache, with our implementation, only > > that of UID 0). > > > > Do you have a different suggestion? > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > I would want an SELinux check added to it, to allow us to keep the caches > separate, based on SELinux. This would mean you would need to have an > SELinux label associated with each cache. > > I would also be careful about capabilities. > > The bottom line with this is if I have two different containers creating > keyrings, how does you cache differentiate the the keyrings from each other. > If I am in container1 and I do a kinit, and it container2, I can use the > keyring, that is a HUGE security violation. Well, isn't the kernel KEYRING: cache (which we default to..) working exactly this way at the moment? With the KCM deamon, you at least selectively mount the KCM socket into the containers where you /want/ to share the ccache based on the peer UID. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"
On Tue, Jun 20, 2017 at 10:27 PM, Nick Coghlan wrote:
> On 20 June 2017 at 12:44, Nick Coghlan wrote:
>> On 20 June 2017 at 02:49, Przemek Klosowski
>> wrote:
>>> It seems to me that there are two kinds of Python packages affected by this
>>> issue: some track the evolution of the ecosystem and make sure they work
>>> with both Python 2 and 3, while the others assume a specific environment,
>>> and expect the user to conform to that. What I dislike about this proposal
>>> is that it imposes on the first kind: their package name needs to change,
>>> presumably to 'pyton3-xxx' even though the package might work with python2
>>> as well. This sounds like penalizing the good behavior.
>>
>> It's also an annoyingly difficult policy to comply with for anyone
>> attempting to maintain RHEL/CentOS/EPEL compatible packages that will
>> use Py2 in those contexts and Py3 in Fedora.
>
> It was pointed out to me that my description of this problem wasn't
> entirely clear, so here's a more concrete example that hopefully
> clarifies the problem I see with the current policy wording.
>
> Specifically, the issue I see is that given the current policy
> wording, dependency declarations like the following would *not* be
> policy compliant for Python packages in Fedora 27+, even though
> they're entirely unambiguous about the Python version they expect to
> get:
>
> ```
> %if 0%{?el7} || 0%{?fedora} < 27
> BuildRequires: python2-devel
> %else
> BuildRequires: python3-devel
> %endif
> BuildRequires: python-builddep1
> BuildRequires: python-builddep2
> Requires: python-runtimedep1
> Requires: python-runtimedep2
> ```
>
> Such specifications would instead need to be written as:
>
> ```
> %if 0%{?el7} || 0%{?fedora} < 27
> BuildRequires: python2-devel
> BuildRequires: python2-builddep1
> BuildRequires: python2-builddep2
> Requires: python2-runtimedep1
> Requires: python2-runtimedep2
> %else
> BuildRequires: python3-devel
> BuildRequires: python3-builddep1
> BuildRequires: python3-builddep2
> Requires: python3-runtimedep1
> Requires: python3-runtimedep2
> %endif
> ```
>
> Requiring such as an approach has the unfortunate effect of making the
> spec file both harder to read (since it's less obvious that the
> packager's intent is to just use whichever Python version handles the
> default package provides on the target OS), and harder to maintain
> (since every dependency has to be listed twice).
>
> By contrast, if an explicit "BuildRequires: python3-devel" on F27+ is
> taken as an affirmative statement that the package is ready for the
> switch of the unqualifed dependencies to Python 3, then the only
> packages that would have to change anything are those that currently
> have an unqualified dependency on "BuildRequires: python-devel".
>
> Packagers in the latter situation would then have to do one of two things:
>
> 1. If their package actually works on Python 3, change their
> pythonX-devel dependency to be Fedora version dependent (while leaving
> other dependency declarations unchanged):
>
> ```
> %if 0%{?fedora} < 27
> BuildRequires: python2-devel
> %else
> BuildRequires: python3-devel
> %endif
> ```
>
> 2. If their package still genuinely requires Python 2, update all of
> their dependency declarations accordingly:
>
> ```
> BuildRequires: python2-devel
> BuildRequires: python2-builddep1
> BuildRequires: python2-builddep2
> Requires: python2-runtimedep1
> Requires: python2-runtimedep2
> ```
If we constrain ourselves to RHEL, then we're screwed until at least
2024. I personally do not see this as a strong enough reason to not
fix our Python packaging globally. If anything, this should be an
incentive for Red Hat engineers to actually fix their Python packages
to match Fedora or at least have the necessary provides the shim both
ways.
One thing I've observed as our biggest failing is that we do a very
bad job of actually rationalizing our own packages to match our
guidelines, for spurious reasons like this, where mistakes that make
it to RHEL dog us in Fedora forever. That's not only dumb, it's
dangerous, as it makes it very hard for us to make our distribution
better and more consistent.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"
On 20 June 2017 at 12:44, Nick Coghlan wrote:
> On 20 June 2017 at 02:49, Przemek Klosowski
> wrote:
>> It seems to me that there are two kinds of Python packages affected by this
>> issue: some track the evolution of the ecosystem and make sure they work
>> with both Python 2 and 3, while the others assume a specific environment,
>> and expect the user to conform to that. What I dislike about this proposal
>> is that it imposes on the first kind: their package name needs to change,
>> presumably to 'pyton3-xxx' even though the package might work with python2
>> as well. This sounds like penalizing the good behavior.
>
> It's also an annoyingly difficult policy to comply with for anyone
> attempting to maintain RHEL/CentOS/EPEL compatible packages that will
> use Py2 in those contexts and Py3 in Fedora.
It was pointed out to me that my description of this problem wasn't
entirely clear, so here's a more concrete example that hopefully
clarifies the problem I see with the current policy wording.
Specifically, the issue I see is that given the current policy
wording, dependency declarations like the following would *not* be
policy compliant for Python packages in Fedora 27+, even though
they're entirely unambiguous about the Python version they expect to
get:
```
%if 0%{?el7} || 0%{?fedora} < 27
BuildRequires: python2-devel
%else
BuildRequires: python3-devel
%endif
BuildRequires: python-builddep1
BuildRequires: python-builddep2
Requires: python-runtimedep1
Requires: python-runtimedep2
```
Such specifications would instead need to be written as:
```
%if 0%{?el7} || 0%{?fedora} < 27
BuildRequires: python2-devel
BuildRequires: python2-builddep1
BuildRequires: python2-builddep2
Requires: python2-runtimedep1
Requires: python2-runtimedep2
%else
BuildRequires: python3-devel
BuildRequires: python3-builddep1
BuildRequires: python3-builddep2
Requires: python3-runtimedep1
Requires: python3-runtimedep2
%endif
```
Requiring such as an approach has the unfortunate effect of making the
spec file both harder to read (since it's less obvious that the
packager's intent is to just use whichever Python version handles the
default package provides on the target OS), and harder to maintain
(since every dependency has to be listed twice).
By contrast, if an explicit "BuildRequires: python3-devel" on F27+ is
taken as an affirmative statement that the package is ready for the
switch of the unqualifed dependencies to Python 3, then the only
packages that would have to change anything are those that currently
have an unqualified dependency on "BuildRequires: python-devel".
Packagers in the latter situation would then have to do one of two things:
1. If their package actually works on Python 3, change their
pythonX-devel dependency to be Fedora version dependent (while leaving
other dependency declarations unchanged):
```
%if 0%{?fedora} < 27
BuildRequires: python2-devel
%else
BuildRequires: python3-devel
%endif
```
2. If their package still genuinely requires Python 2, update all of
their dependency declarations accordingly:
```
BuildRequires: python2-devel
BuildRequires: python2-builddep1
BuildRequires: python2-builddep2
Requires: python2-runtimedep1
Requires: python2-runtimedep2
```
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
Hey all, I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for aarch64 (similar to debootstrap with "debootstrap --arch arm64 "), but I can't seem to find any. I recall that we added qemu-user-static back in Fedora 24 for the purpose of being able to support this kind of thing, but do we have anything that leverages it to be able to enable this? Thanks in advance, -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 26-20170620.n.0 compose check report
No missing expected images. Failed openQA tests: 8/128 (x86_64), 4/24 (i386), 1/2 (arm) New failures (same test did not fail in 26-20170618.n.0): ID: 110629 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/110629 ID: 110632 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/110632 ID: 110633 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/110633 ID: 110637 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/110637 ID: 110646 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/110646 ID: 110647 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/110647 ID: 110648 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/110648 ID: 110650 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/110650 ID: 110685 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/110685 ID: 110701 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/110701 ID: 110737 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/110737 Old failures (same test failed in 26-20170618.n.0): ID: 110683 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/110683 ID: 110719 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/110719 Soft failed openQA tests: 3/128 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 26-20170618.n.0): ID: 110610 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/110610 ID: 110611 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/110611 ID: 110651 Test: x86_64 Atomic-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/110651 ID: 110652 Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/110652 ID: 110684 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/110684 Passed openQA tests: 117/128 (x86_64), 18/24 (i386), 1/2 (arm) New passes (same test did not pass in 26-20170618.n.0): ID: 110615 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/110615 ID: 110616 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/110616 ID: 110617 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/110617 ID: 110618 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/110618 ID: 110619 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/110619 ID: 110620 Test: x86_64 Workstation-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/110620 ID: 110621 Test: x86_64 Workstation-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/110621 ID: 110622 Test: x86_64 Workstation-live-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/110622 ID: 110623 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/110623 ID: 110624 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/110624 ID: 110625 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/110625 ID: 110626 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/110626 ID: 110627 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/110627 ID: 110630 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/110630 ID: 110635 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/110635 ID: 110636 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/110636 ID: 110638 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/110638 ID: 110639 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/110639 ID: 110640 Test: x86_64 KDE-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/110640 ID: 110641 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/110641 ID: 110642 Test:
Re: F27 System Wide Change: Parallel Installable Debuginfo
> "MW" == Mark Wielaard writes: MW> I believe this has always been a hidden directory name that is MW> expected to be called that way by various tools. I don't recall having seen it before, and I've been doing packaging work for a very long time. The confusion about rpmlint complaints started when this change hit rawhide. If it really is historical, we're through such a sea change with the way debuginfo is being done now that we should fix things to not require a hidden directory. It's simply a bad idea. "Fixing" rpmlint to complain about such things isn't really the right answer, since the complaints are valid. _ J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Kerberos KCM credential cache by default
On 06/20/2017 02:45 PM, Jakub Hrozek wrote: On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote: On 06/20/2017 04:21 AM, Jakub Hrozek wrote: On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: Hi, On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: = System Wide Change: Kerberos KCM credential cache by default = https://fedoraproject.org/wiki/Changes/KerberosKCMCache "The design is described in more detail on the SSSD wiki." It is not, the link redirects to a page about fedorahosted.org retirement. Sorry, your are right, I fixed the link (this feature was submitted during f-26 timeframe when fh.o was still up and I forgot to change the links when I re-submitted the feature..) The correct link is: https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html Change owner(s): * Jakub Hrozek Default to a new Kerberos credential cache type called KCM which is better suited for containerized environments and provides a better user experience in the general case as well. I wonder what is the relation to the daemon of the same name ansd similar purpose distributed with Heimdal http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. Will they be compatible? Yes, more or less. The wire protocol is the same and I used MIT client libraries with Heimdal server bit during development. Not all server commands are implemented, only the subset that MIT client implements. There are some features supported by Heimdal but not supported yet by SSSD's KCM, like renewals, but those will be added. There are some features we chose to explicitly not add (or not enable by default), like listing all ccaches known to KCM server by root. Hopefully the sssd upstream design page would help.. Will code be shared? No, the Heimdal deamon relies on internal Heimdal API quite a bit. We also want to support multiple 'storage back ends' for the ccaches, while Heimdal only stores the ccaches in memory. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org How will I access this feature inside of a container? Bind-mount the KCM server socket into the container. If there is a leaked socket into the container, what kind of access control is built into your server to prevent root inside of one container effecting/accessing the credentials of different containers? Well, UID of the peer accessing the socket is the access control key right now. Unlike Heimdal's KCM, root doesn't have any special powers (with Heimdal's KCM, root can list any ccache, with our implementation, only that of UID 0). Do you have a different suggestion? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org I would want an SELinux check added to it, to allow us to keep the caches separate, based on SELinux. This would mean you would need to have an SELinux label associated with each cache. I would also be careful about capabilities. The bottom line with this is if I have two different containers creating keyrings, how does you cache differentiate the the keyrings from each other. If I am in container1 and I do a kinit, and it container2, I can use the keyring, that is a HUGE security violation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Parallel Installable Debuginfo
On Tue, 2017-06-20 at 14:12 -0400, Matthew Miller wrote: > On Tue, Jun 20, 2017 at 01:08:17PM -0500, Jason L Tibbitts III wrote: > > JK> * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a > > JK> symlink to the main ELF file. > > JK> * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug > > JK> which is a symlink to the .debug ELF file. > > JK> * The .debug files under /usr/lib/debug/ with file path names > > JK> mirroring the main ELF file paths under / with .debug added. > > > Please do not use a hidden directory for this. There is no reason for > > it, and it only adds confusion and rpmlint complaints that packagers > > can't control at all. > > I don't know if there are any advantages to a hidden directory here, > but... at the very least we should fix rpmlint to not give errors, as > part of this change. I believe this has always been a hidden directory name that is expected to be called that way by various tools. The origin of the name probably hidden somewhere in history. BTW there is a bug and a patch for rpmlint to not complain about it already: https://bugzilla.redhat.com/show_bug.cgi?id=1431408 Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 26 compose report: 20170620.n.0 changes
OLD: Fedora-26-20170619.n.0 NEW: Fedora-26-20170620.n.0 = SUMMARY = Added images:28 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 30 Downgraded packages: 0 Size of added packages: 38.48 KiB Size of dropped packages:0.00 B Size of upgraded packages: 640.23 MiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 24.30 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-26-20170620.n.0.iso Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-26-20170620.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-26-20170620.n.0.iso Image: LXDE live i386 Path: Spins/i386/iso/Fedora-LXDE-Live-i386-26-20170620.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-26-20170620.n.0.iso Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-26-20170620.n.0.iso Image: KDE live i386 Path: Spins/i386/iso/Fedora-KDE-Live-i386-26-20170620.n.0.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-26-20170620.n.0.iso Image: Design_suite live i386 Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-26-20170620.n.0.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-26-20170620.n.0.iso Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-26-20170620.n.0.iso Image: LXQt live i386 Path: Spins/i386/iso/Fedora-LXQt-Live-i386-26-20170620.n.0.iso Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-26-20170620.n.0.iso Image: Workstation live x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-26-20170620.n.0.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-26-20170620.n.0.iso Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-26-20170620.n.0.iso Image: Mate live i386 Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-26-20170620.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-26-20170620.n.0.iso Image: Python_Classroom live i386 Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-26-20170620.n.0.iso Image: Robotics live i386 Path: Labs/i386/iso/Fedora-Robotics-Live-i386-26-20170620.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-26-20170620.n.0.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-26-20170620.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-26-20170620.n.0.iso Image: Xfce live i386 Path: Spins/i386/iso/Fedora-Xfce-Live-i386-26-20170620.n.0.iso Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-26-20170620.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-26-20170620.n.0.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-26-20170620.n.0.iso Image: Games live i386 Path: Labs/i386/iso/Fedora-Games-Live-i386-26-20170620.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: waiverdb-0.1.1-2.fc26 Summary: Service for waiving results in ResultsDB RPMs:waiverdb Size:39402 bytes = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Zim-0.67-0.rc2.1.fc26 Old package: Zim-0.65-4.fc26 Summary: Desktop wiki & notekeeper RPMs: Zim Size: 1901642 bytes Size change: 91728 bytes Changelog: * Tue Jun 06 2017 Oliver Haessler - 0.66-1 - Update to 0.66 * Wed Jun 07 2017 Oliver Haessler - 0.66-2 - added patch for "Fix for logger missing in newfs" to allow build of 0.66 on Fedora/RHEL (will be fixed in 0.67) * Wed Jun 14 2017 Robin Lee - 0.67-0.rc2.1 - Update to 0.67-rc2 Package: audit-2.7.7-1.fc26 Old package: audit-2.7.6-1.fc26 Summary: User space tools for 2.6 kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel audit-libs-python audit-libs-python3 audit-libs-static Size: 4773812 bytes Size change: 14928 bytes Changelog: * Fri Jun 16 2017 Steve Grubb 2.7.7-1 - New upstream bugfix release Package: datovka-4.8.3-1.fc26 Old package: datovka-4.8.2-1.fc26 Summary: A free graphical interface for Czech Databox (Datov?? schr??nky) RPMs: datovka Size: 7169600 bytes Size change: 32332 bytes Changelog: * Wed Jun 14 2017 Jaroslav ??karvada - 4.8.3-1 - New version Resolves: rhbz#1461411 Package: electrum-2.8.3-1.fc26 Old package: electrum-2.8.2-1.fc26 Summary: A lightweight Bitcoin Client RPMs: electrum Size: 1271998 bytes Size change: 32100 bytes Changelog: * Tue Jun 13 2017 Jonny Heggheim - 2.8.3-1 - new version Package: erlang-19.3.6-1.fc26 Old package: erlang-19.3.4-1.fc26 Summary: General-purpo
Re: F27 System Wide Change: Kerberos KCM credential cache by default
On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote: > On 06/20/2017 04:21 AM, Jakub Hrozek wrote: > > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: > > > Hi, > > > > > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > > > > = System Wide Change: Kerberos KCM credential cache by default = > > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > > "The design is described in more detail on the SSSD wiki." > > > > > > It is not, the link redirects to a page about fedorahosted.org > > > retirement. > > Sorry, your are right, I fixed the link (this feature was submitted > > during f-26 timeframe when fh.o was still up and I forgot to change the > > links when I re-submitted the feature..) > > > > The correct link is: > > https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html > > > > > > Change owner(s): > > > > * Jakub Hrozek > > > > > > > > Default to a new Kerberos credential cache type called KCM which is > > > > better suited for containerized environments and provides a better > > > > user experience in the general case as well. > > > I wonder what is the relation to the daemon of the same name ansd > > > similar purpose distributed with Heimdal > > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. > > > Will they be compatible? > > Yes, more or less. The wire protocol is the same and I used MIT client > > libraries with Heimdal server bit during development. Not all server > > commands are implemented, only the subset that MIT client implements. > > > > There are some features supported by Heimdal but not supported yet by SSSD's > > KCM, like renewals, but those will be added. There are some features we > > chose to explicitly not add (or not enable by default), like listing all > > ccaches known to KCM server by root. > > > > Hopefully the sssd upstream design page would help.. > > > > > Will code be shared? > > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We > > also want to support multiple 'storage back ends' for the ccaches, while > > Heimdal only stores the ccaches in memory. > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > How will I access this feature inside of a container? Bind-mount the KCM server socket into the container. > If there is a leaked > socket into the container, what kind of access control is built into your > server to prevent root inside of one container effecting/accessing the > credentials of different containers? Well, UID of the peer accessing the socket is the access control key right now. Unlike Heimdal's KCM, root doesn't have any special powers (with Heimdal's KCM, root can list any ccache, with our implementation, only that of UID 0). Do you have a different suggestion? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan krb5-appl*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jun 20, 2017 at 2:10 PM Robbie Harwood wrote: Hi, I am orphaning krb5-appl in Fedora in the hopes that it will be retired. These packages will likely be officially deprecated upstream soon, and probably should not be used in most cases anyway. It contains legacy kerberized utilities, like rsh. There are no packages which depend them. There have been no changes to this package in Fedora since 2013, and no new capabilities upstream since 2010 when it branched from the mainline krb5 distribution. I would strongly prefer that these be allowed to fade away in order to further discourage their use in keeping with what other distributions have done. Thanks, - --Robbie (krb5 maintainer) Sounds to me like rather than orphaning and waiting for retirement, this would be a candidate for an F27 Change Proposal where we kill it off explicitly. (This has the added bonus of providing precedent for saying "no" if someone decided to try to resurrect this package.) -BEGIN PGP SIGNATURE- Version: Mailvelope v1.7.2 Comment: https://www.mailvelope.com wkYEAREIABAFAllJZm0JEHolVWI2uqOjAACU7QCgl1EDScxCk7W3o7elYeJ0 mm0He1MAnRJQaRNu1wGNJsXC8l+bh/QiC47I =YWDG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Parallel Installable Debuginfo
On Tue, Jun 20, 2017 at 01:08:17PM -0500, Jason L Tibbitts III wrote: > JK> * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a > JK> symlink to the main ELF file. > JK> * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug > JK> which is a symlink to the .debug ELF file. > JK> * The .debug files under /usr/lib/debug/ with file path names > JK> mirroring the main ELF file paths under / with .debug added. > Please do not use a hidden directory for this. There is no reason for > it, and it only adds confusion and rpmlint complaints that packagers > can't control at all. I don't know if there are any advantages to a hidden directory here, but... at the very least we should fix rpmlint to not give errors, as part of this change. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Intent to orphan krb5-appl*
Hi, I am orphaning krb5-appl in Fedora in the hopes that it will be retired. These packages will likely be officially deprecated upstream soon, and probably should not be used in most cases anyway. It contains legacy kerberized utilities, like rsh. There are no packages which depend them. There have been no changes to this package in Fedora since 2013, and no new capabilities upstream since 2010 when it branched from the mainline krb5 distribution. I would strongly prefer that these be allowed to fade away in order to further discourage their use in keeping with what other distributions have done. Thanks, --Robbie (krb5 maintainer) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Parallel Installable Debuginfo
I know the boat has sailed on this and no amount of complaining will help at this point, but I want to make sure this gets on the record wherever this feature is proposed. > "JK" == Jan Kurik writes: JK> * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a JK> symlink to the main ELF file. JK> * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug JK> which is a symlink to the .debug ELF file. JK> * The .debug files under /usr/lib/debug/ with file path names JK> mirroring the main ELF file paths under / with .debug added. Please do not use a hidden directory for this. There is no reason for it, and it only adds confusion and rpmlint complaints that packagers can't control at all. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: Decouple system java setting from java command setting
Hi, Frankly, the proposed change seems a great way to accumulate technical debt at a rapid pace, by helping apps to specify various legacy or proprietary Java variants, and postponing taking into account openjdk changes indefinitely. That's more or less what the proprietary unixes did till the whole house of cards collapsed under the weight of long overdue migration needs. IIRC the whole alternative system already lets an app specify a specific java version and producer (at least it did in JPackage time). What it does not let people do is to pretend an app is java-version and java-producer agnostic when it isn't. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /usr/bin/qemu-kvm symlink
On Sat, Jun 17, 2017 at 05:25:18PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > I was told [1] that /usr/bin/qemu-kvm is obsolete, and that the right > thing is to use 'qemu-system-x86_64 -enable-kvm', [...] As Dan says, use libvirt. However I want to point out that the advice above is also wrong: The ‘-enable-kvm’ option is obsolete, and that command would only work if you were emulating x86_64, which is by no means the only architecture which supports KVM. Really you should use libvirt rather than trying to formulate qemu command lines. > 2. wouldn't it make sense to convince upstream to provide /usr/bin/qemu-kvm >which would mean "provide accelerated emulation of current architecture"? Possibly, but what many people want is "be as fast as you can but don't break if KVM isn't available", which is provided by the ‘-machine accel=kvm:tcg’ option, or by using libvirt capabilities to discover what acceleration and emulation options are available on the current host. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Liberation fonts plan
De: "pravin d s" >On 20 June 2017 at 18:42, Matthew Miller wrote: >> On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: >> >- In Fedora we will have both packages liberation2-fonts and >> >liberation-fonts >> De: "pravin d s" >On 20 June 2017 at 18:42, Matthew Miller wrote: >> On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: >> >- In Fedora we will have both packages liberation2-fonts and >> >liberation-fonts >> >> Will the actual fonts have different names? >> >I am planning to have same fonts name, so one can simply install other >packages and replace the existing one. Frankly, if the rift is deep enough there's no hope of producing a Liberation version that satisfies everyone, it would be better to have to different family names, with fontconfig substitution rules that make each one a valid replacement for the other if it's not installed on the system. The fontconfig rules will keep software happy and the different names will force humans to take a choice instead of talking past one another like is the case right now. Regards, -- Nicolas Mailhot >> Will the actual fonts have different names? >> >I am planning to have same fonts name, so one can simply install other >packages and replace the existing one. Frankly, if the rift is deep enough there's no hope of producing a Liberation version that satisfyes everyone, it would be better to have to different family names, with fontconfig substitution rules that make each one a valid replacement for the other if it's not installed on the system. The fontconfig rules will keep software happy and the different names will force humans to take a choice instead of talking past one another like is the case right now. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On Tue, Jun 20, 2017 at 10:55:04PM +0530, pravin@gmail.com wrote: > > This seems likely to lead to user confusion. Any chance of making the > > old one "Liberation Classic" or something like that? > I liked the idea. With this case we can have both fonts installed same time > on the system. As long as it's not a huge amount of extra work for you! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On 20 June 2017 at 22:37, Matthew Miller wrote: > On Tue, Jun 20, 2017 at 06:46:31PM +0530, pravin@gmail.com wrote: > > > On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: > > > >- In Fedora we will have both packages liberation2-fonts and > > > >liberation-fonts > > > Will the actual fonts have different names? > > I am planning to have same fonts name, so one can simply install other > > packages and replace the existing one. > > This seems likely to lead to user confusion. Any chance of making the > old one "Liberation Classic" or something like that? > I liked the idea. With this case we can have both fonts installed same time on the system. Regards, Pravin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On Tue, Jun 20, 2017 at 06:46:31PM +0530, pravin@gmail.com wrote: > > On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: > > >- In Fedora we will have both packages liberation2-fonts and > > >liberation-fonts > > Will the actual fonts have different names? > I am planning to have same fonts name, so one can simply install other > packages and replace the existing one. This seems likely to lead to user confusion. Any chance of making the old one "Liberation Classic" or something like that? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"
> "IS" == Iryna Shcherbina writes: IS> The packages that violate the above-mentioned policies are being IS> tracked in portingdb [3] and we plan to start filling bugs soon. Before doing that, please post a list of packages and their maintainers to the devel list. Preferably you would post two lists: one in the form: packageowner1 owner2 owner2 And another in the form owner package1 package2 package3 This makes it easy for packagers to trivially see if they have any work to do without having to wrestle with what could potentially be a large number of bugzilla tickets which are more annoying than useful. The message with these lists should also include reasonably complete information about what they need to do. Not just a pile of links, though you should of course include links in case someone wants to read further. IS> Since that's a lot of bugs to file (more than 1000) , we IS> encourage all maintainers to fix the packages they maintain. That will go faster if you don't waste people's time filing a load bugs and instead give people at least a couple of weeks to see their name on a list and get things fixed up. A few extra minutes spent generating a useful and complete report can save a lot of time for busy packagers and potentially save some ill will as well. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Augusto Caringi
Hi everyone, My name is Augusto Caringi and I'd like to introduce myself. I'm a Brazilian Software Engineer currently living in Brno, Czech Republic, working at Red Hat in the Core Services/Databases team. My first Linux installation was a Red Hat 4.2 in 1997, since then I have been using/working with Linux and Open Source Software one way or another in the last 20 years. Before joining Red Hat I worked writing network daemons and embedded software (closed source) mainly programming in C/C++ and Python. I also have experience as a Computer Science lecturer. My first Fedora package is ProxySQL: https://bugzilla.redhat.com/show_bug.cgi?id=1457929 I'm looking forward to contribute more to the Fedora Project. Thank you! -- Augusto Caringi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Upgrade of Ardour to latest version
I'm going to upgrade ardour5 to the latest upstream version 5.10, starting with rawhide, f26, f25 and f24. Guido Aulisi signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On 20 June 2017 at 18:42, Matthew Miller wrote: > On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: > >- In Fedora we will have both packages liberation2-fonts and > >liberation-fonts > > Will the actual fonts have different names? > I am planning to have same fonts name, so one can simply install other packages and replace the existing one. - Pravin > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On Tue, Jun 20, 2017 at 06:35:24PM +0530, pravin@gmail.com wrote: >- In Fedora we will have both packages liberation2-fonts and >liberation-fonts Will the actual fonts have different names? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Liberation fonts plan
On Tue, Jun 20, 2017 at 9:05 AM, pravin@gmail.com wrote: > Hi All, > >Presently as you know, we have liberation-2 and liberation 1.07.4. i am > maintaining both in single git repo. [1] > > I am thinking to create different project for liberation2, reasons as > follows > > liberation 2 - It initially forked from google-croscore-fonts and now > independent development is happening. > liberation 1 - Though shapes are same, liberation 1 has bytecode hinting > instruction, many users like it. > Problem: Few users want to use liberation 1 and few users want to use > liberation 2. > Having different project for both will help for independant development and > also users can switch as per interest. > One can obsolete to other. > In Fedora we will have both packages liberation2-fonts and liberation-fonts > > Let me know - feedback and suggestions. Copr for liberation2 [2] > > Background information on Wiki. [3] > > Thanks, > Pravin > I'm okay with anything that leads to us having all the fonts! And there have been people asking why Fedora (the originator of the fonts in question) doesn't have the latest version of the fonts. If this fixes that, I'll be pleased. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Liberation fonts plan
Hi All, Presently as you know, we have liberation-2 and liberation 1.07.4. i am maintaining both in single git repo. [1] I am thinking to create different project for liberation2, reasons as follows - liberation 2 - It initially forked from google-croscore-fonts and now independent development is happening. - liberation 1 - Though shapes are same, liberation 1 has bytecode hinting instruction, many users like it. - Problem: Few users want to use liberation 1 and few users want to use liberation 2. - Having different project for both will help for independant development and also users can switch as per interest. - One can obsolete to other. - In Fedora we will have both packages liberation2-fonts and liberation-fonts Let me know - feedback and suggestions. Copr for liberation2 [2] Background information on Wiki. [3] Thanks, Pravin 1. https://pagure.io/liberation-fonts 2. https://copr.fedorainfracloud.org/coprs/pravins/liberation2 3. https://en.wikipedia.org/wiki/Liberation_fonts ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Kerberos KCM credential cache by default
On 06/20/2017 04:21 AM, Jakub Hrozek wrote: On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: Hi, On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: = System Wide Change: Kerberos KCM credential cache by default = https://fedoraproject.org/wiki/Changes/KerberosKCMCache "The design is described in more detail on the SSSD wiki." It is not, the link redirects to a page about fedorahosted.org retirement. Sorry, your are right, I fixed the link (this feature was submitted during f-26 timeframe when fh.o was still up and I forgot to change the links when I re-submitted the feature..) The correct link is: https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html Change owner(s): * Jakub Hrozek Default to a new Kerberos credential cache type called KCM which is better suited for containerized environments and provides a better user experience in the general case as well. I wonder what is the relation to the daemon of the same name ansd similar purpose distributed with Heimdal http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. Will they be compatible? Yes, more or less. The wire protocol is the same and I used MIT client libraries with Heimdal server bit during development. Not all server commands are implemented, only the subset that MIT client implements. There are some features supported by Heimdal but not supported yet by SSSD's KCM, like renewals, but those will be added. There are some features we chose to explicitly not add (or not enable by default), like listing all ccaches known to KCM server by root. Hopefully the sssd upstream design page would help.. Will code be shared? No, the Heimdal deamon relies on internal Heimdal API quite a bit. We also want to support multiple 'storage back ends' for the ccaches, while Heimdal only stores the ccaches in memory. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org How will I access this feature inside of a container? If there is a leaked socket into the container, what kind of access control is built into your server to prevent root inside of one container effecting/accessing the credentials of different containers? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: Enable TRIM pass down to encrypted disks
= System Wide Change: Enable TRIM pass down to encrypted disks = https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt Change owner(s): * Vratislav Podzimek * Ondrej Kozina Override kernel default for dm-crypt mappings of LUKS1 encrypted volumes via flag put in /etc/crypttab file. This change should affect only newly created encrypted storage based on LUKS1 format during installation. == Detailed Description == User base of Fedora distribution with SSDs grows steadily and while the argument for kernel default setting not to enable the discard is still strong one it doesn't change the fact that vast majority of users (with SSDs) doesn't want to sacrifice better performance of drive with discard/trim enabled for the sake of secrecy. We're not speaking encrypted data security here and double emphasize on it! Only the fact that blank filesystem on top of dm-crypt device with discard enabled may create well visible patterns in ciphertext device below on SSDs. For LUKS1 metadata format we don't have a space to store the new default in metadata and therefore we can't flip the default for new LUKS1 devices being formated via libcryptsetup or cryptsetup utility. Changing the kernel default is of the table due to risk of data corruption with some TrueCrypt configurations involving hidden volumes. For rotational devices the cost of enabled discard is negligible == Scope == * Proposal owners: This change despite being system wide change due to overriding legacy default is quite small and easy to manage. * Other developers: Very minor change in python-blivet. Basically we just need to store discard keyword in /etc/crypttab lines related to new partitions created during installation process. * Release engineering: N/A * List of deliverables: N/A * Policies and guidelines: Add short information in documentation we're changing long term default and copy the reasoning there. * Trademark approval: N/A -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fwd: Node.js v8.x in Fedora
-- Forwarded message -- From: Zuzana Svetlikova Date: Mon, Jun 19, 2017 at 5:48 PM Subject: Node.js v8.x in Fedora To: devel@lists.fedoraproject.org Cc: nod...@lists.fedoraproject.org Hi everyone, as there is nothing stopping us now, the nodejs package in Rawhide will soon be updated to Node.js v8.x. It also comes with npm@5 and new V8. Note that upstream has made a lot of changes and your projects/packages might have some issues. I'll update nodejs in rawhide next week, if you wish to try it out sooner, it's already built here: https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/ Zuzka ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: Separate Subpackage and Source Debuginfo
= System Wide Change: Separate Subpackage and Source Debuginfo = https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo Change owner(s): * Mark Wielaard * Neal Gompa Allow to install just the debuginfo for a subpackage and/or without the source files. The debuginfo packages are huge because they contain debuginfo and all sources for all subpackages. Being able to install only the debuginfo for the subpackage that is installed reduces the size that needs to be downloaded to analyze, trace, profile or debug a program or core file. Some tracing and profiling tools don't need the actual source files to provide stack traces or insert probes. So installing the debugsources should be optional. == Detailed Description == Currently both the .debug files and the source files of all subpackages are included in a debuginfo package. This creates huge debuginfo packages with a lot of data that might not be relevant to the user/developer. By splitting out the sources (found under /usr/src/debug) and the .debug file for the separate binaries of the subpackages (under /usr/lib/debug) the amount of data a developer/user needs to install to trace, profile or debug will be greatly reduced. Other distributions (notably Suse) already split their debuginfo packages this way. We will take those patches (https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsubpkg.diff) and integrate them into rpm upstream. This will involve two steps: - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/8 - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/10 This depends on some of the cleanups introduced by the ParallelInstallableDebuginfo change. We can either make this work with the current dnf debuginfo-install plugin by providing a meta package that matches the main-debuginfo package which depends on all sub- and source-debuginfo packages. Or we work with the dnf hackers to make dnf debuginfo-install work with sub-debuginfo packages. A couple of packages already have hand-written sub-debuginfo packages (notably the kernel, glibc and gcc). We will work with those packages to adopt the new standard approach. Release engineering needs to be involved to see if any changes are necessary for adding the sub-debuginfo/debugsources packages to the repodata. == Scope == * Proposal owners: Patches against rpm upstream need to be integrated as outlined in the Detailed Description. * Other developers: Upstream rpm and dnf maintainers have to review the proposed patches. If accepted the package maintainers will have to decide whether those patches can be backported for the next fedora release. Packages that now split their debuginfo packages by hand might want to change their package to adopt the new (standard) approach. Once all changes are in a package debuginfo needs to be regenerated before it becomes sub-package/source split. * Release engineering: Needs to be discussed. In theory no changes apart from those listed above are needed. But release engineering might know whether any changes are necessary for adding the sub-debuginfo/debugsources packages to the repodata. * List of deliverables: N/A (Still Unknown) * Policies and guidelines: No changes, the debuginfo related rpm macros won't change. They will just start producing sub-package debuginfo and debugsources packages once all changes are in place. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: Parallel Installable Debuginfo
= System Wide Change: Parallel Installable Debuginfo = https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo Change owner(s): * Mark Wielaard debuginfo packages can be installed in parallel to make it easier to trace, profile and observe what programs are doing or to debug when they have crashed. That way debugging, tracing or profiling programs can be done independent of whether they are 32bit, 64bit, a slightly newer or older version than currently installed or even from a different architecture. == Detailed Description == Currently only one version of a debuginfo package can be installed for a given package. Even on a multi-lib system you cannot install the 64-bit and 32-bit versions of a debuginfo package in parallel (technically you sometimes can, because of RPM file coloring, the 64bit version of the .debug files win over the 32bit version - causing lots of confusion). But there are various situation where having multiple versions of the debuginfo package installed help with tracing, profiling, debugging and/or crash analysis (see the Benefit to Fedora section below). There are various things provided by a debuginfo file that might conflict preventing parallel installation of different versions: * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a symlink to the main ELF file. * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug which is a symlink to the .debug ELF file. * The .debug files under /usr/lib/debug/ with file path names mirroring the main ELF file paths under / with .debug added. * The source files under /usr/src/debug/-/ They can be made non-conflicting in the following ways: * The main build-id file should not be in the debuginfo file, but in the main package (this was always a problem since the package and debuginfo package installed might not match). If we want to make usr/lib/debug/ a network resource then we will need to move the symlink to another location (maybe /usr/lib/.build-id). Unfortunately this means a change will be necessary for debuginfo consumers to that depend on the old location. We could keep the old symlink and point it to the new location to work around it. But I will audit the consumers to see which depend on it and discuss if we can have a new standard location. * build-ids are globally unique identifiers. They will be different across arches. But might match between minor releases if the exact same ELF image is produced. The linker will get an option to hash in the full nvr to make sure all build-ids are always fully unique. * The .debug file names will be changed to main ELF file name-vr.debug. This name will also be set in the .gnu_debuglink section of the main file by changing the options given to eu-strip in the rpm find-debuginfo.sh script. * The source files will be moved under /usr/src/debug/--./. This needs changes to the rpm debugedit program which rewrites the DWARF source file information. These changes will make all files in any debuginfo file unique so they don't conflict when installed in parallel. There should be no changes necessary to programs (gdb, perf, valgrind, systemtap, systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids or .gnu_debuglink to lookup DWARF debug information and source references for tracing, profiling and debugging. It would be good to tweak dnf debuginfo-install to know about parallel installable debuginfo packages and maybe have an easy option to install the debuginfo for a core file or for the packages running in a container. Alternative solutions currently rejected: * Move main ELF image build-id file under /usr/lib/.build-id/xx/...yyy when moving into main pages. Because existing programs probably depend on the link being under /usr/lib/debug/. * Since when the build-id is identifical also the ELF file is identical we could mark all build-id.debug files as replacable in the rpm. It isn't clear that works for symlinks though (but we could reverse the symlink direction from debug file to build-id file). And currently you can identify the exact package nvr installed given just one build-id. That would be impossible if multiple packages could contain the same build-id/ELF image file. * Do away with the old .gnu_debuglink way of accessing files under /usr/lib/debug and just not install .debug files and only support build-id based debug lookups. Because it isn't clear build-ids are 100% available and all programs work with build-id lookups instead through .gnu_debuglink names. * Move the .debug files under a subdir like the sources. /usr/lib/debug/--./. This cannot easily be expressed in .gnu_debuglink, which officially only allows a basename. == Scope == * Proposal owners: Patches have been developed against rpm debugedit to accept a hash value to seed the build-id calculation, rewrite source paths (currently source paths can only be smaller, this change might create larger paths) and the rpm find-debuginfo.sh script to change the paths, symlinks and
Re: F27 Self Contained Change: Decouple system java setting from java command setting
On 06/20/2017 10:48 AM, Jiri Vanek wrote: > There are may reasons to not to do this change. At least not to do this > as it is specified. I would like to hear your reasons. > Where is best place to discus? Discussion already started at > java-proj...@redhat.com.[1] Fedora devel list is the right place for that. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: Decouple system java setting from java command setting
On 06/16/2017 06:44 PM, Dennis Gilmore wrote: > I would like to see some details on how this is going to be > implemented. It is going to be implemented by updating javapackages-tools package in Fedora 27 to new upstream release, which includes this change: https://github.com/fedora-java/javapackages/pull/44/commits/a05123ba74a0693ef116f718eb7326213bb94b75 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: Decouple system java setting from java command setting
There are may reasons to not to do this change. At least not to do this as it is specified. Where is best place to discus? Discussion already started at java-proj...@redhat.com.[1] Please advice, J. [1] http://post-office.corp.redhat.com/archives/java-project/2017-June/date.html On 06/08/2017 03:55 PM, Jan Kurik wrote: = Proposed Self Contained Change: Decouple system java setting from java command setting = https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting Change owner(s): * Michael Simacek * Mikolaj Izdebski Alternatives can be used to specify which Java installation should be the default for the system. Currently, changing the default java command causes not only a change to the /usr/bin/java symlink, but also affects the which runtime is used for system installed Java applications. We propose introduction of separate setting for system-wide java applications. == Detailed Description == Fedora allows parallel installation of multiple Java runtime environments and it uses alternatives mechanism to allow the user to switch between them. JDK packages provide a set of alternatives symlinks for it's executables. The java symlink is used to determine the java command (/usr/bin/java), but also determines which runtime environment is used to run system-wide Java applications installed from RPMs, such as maven or eclipse. While in theory different Java runtime environments are drop-in replacements for each other, in practice some of the applications may stop working properly. Users usually install alternative JDKs in order to run their own applications and don't expect that changing the java command will have effect on the system applications. By introducing a separate setting for system-wide java, we would avoid this problem. We propose specifying default Java runtime for RPM-managed applications in /etc/java/java.conf (this is already possible, but not currently used). Administrators would still be able to override the system default if they need to. == Scope == * Proposal owners: Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf * Other developers: N/A (not a System Wide Change) * Release engineering: https://pagure.io/releng/issue/6831 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Kerberos KCM credential cache by default
On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote: > Hi, > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > > = System Wide Change: Kerberos KCM credential cache by default = > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > "The design is described in more detail on the SSSD wiki." > > It is not, the link redirects to a page about fedorahosted.org > retirement. Sorry, your are right, I fixed the link (this feature was submitted during f-26 timeframe when fh.o was still up and I forgot to change the links when I re-submitted the feature..) The correct link is: https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html > > > Change owner(s): > > * Jakub Hrozek > > > > Default to a new Kerberos credential cache type called KCM which is > > better suited for containerized environments and provides a better > > user experience in the general case as well. > > I wonder what is the relation to the daemon of the same name ansd > similar purpose distributed with Heimdal > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. > Will they be compatible? Yes, more or less. The wire protocol is the same and I used MIT client libraries with Heimdal server bit during development. Not all server commands are implemented, only the subset that MIT client implements. There are some features supported by Heimdal but not supported yet by SSSD's KCM, like renewals, but those will be added. There are some features we chose to explicitly not add (or not enable by default), like listing all ccaches known to KCM server by root. Hopefully the sssd upstream design page would help.. > Will code be shared? No, the Heimdal deamon relies on internal Heimdal API quite a bit. We also want to support multiple 'storage back ends' for the ccaches, while Heimdal only stores the ccaches in memory. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Kerberos KCM credential cache by default
Hi, On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > = System Wide Change: Kerberos KCM credential cache by default = > https://fedoraproject.org/wiki/Changes/KerberosKCMCache "The design is described in more detail on the SSSD wiki." It is not, the link redirects to a page about fedorahosted.org retirement. > Change owner(s): > * Jakub Hrozek > > Default to a new Kerberos credential cache type called KCM which is > better suited for containerized environments and provides a better > user experience in the general case as well. I wonder what is the relation to the daemon of the same name ansd similar purpose distributed with Heimdal http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html. Will they be compatible? Will code be shared? P. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
