Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"
To make this easy, I dug out an old script I had and cleaned it up. It's 'find-package-maintainers' and is available from https://pagure.io/fedora-misc-package-utilities Just feed it a list of source package names (on stdin or in a named file) and it will extract the owner lists from pkgdb for you and generate two lists mentioned. Thanks a lot, that is helpful. There is also a pkgdb2client [0] package that I've been looking into for this. [0] https://github.com/fedora-infra/packagedb-cli I also updated the "mass bug filing" page a bit and, since it was no longer just about bug filing, renamed it to https://fedoraproject.org/wiki/Mass_package_changes A redirect is of course in place so no links break. If anyone else has random packaging-related scripts like that (python or not) let me know and I'll give you access to that repository. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Golang 1.9
- Original Message - > From: "Tony Breeds" > To: devel@lists.fedoraproject.org > Sent: Thursday, June 22, 2017 2:03:44 AM > Subject: Re: F27 System Wide Change: Golang 1.9 > > On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote: > > > > > Along with the rebase I do propose to drop ppc64 from Go > > architectures(effectively disabling build of all packages adhering to > > draft Go packaging guidelines) as ppc64 port of "GC" is not feature > > complete(never were) and with Go 1.9 "GC" will be supporting only > > Power 8 and up. > > Just for clarity, you're ppc64le would remain supported. Correct? Yes. That is correct, JC > > ___ > 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: Golang 1.9
On Thu, 22 Jun 2017 07:17:33 -0400 (EDT) Jakub Cajka wrote: > > > > > - Original Message - > > From: "Tony Breeds" > > To: devel@lists.fedoraproject.org > > Sent: Thursday, June 22, 2017 2:03:44 AM > > Subject: Re: F27 System Wide Change: Golang 1.9 > > > > On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote: > > > > > > > > > Along with the rebase I do propose to drop ppc64 from Go > > > architectures(effectively disabling build of all packages > > > adhering to draft Go packaging guidelines) as ppc64 port of "GC" > > > is not feature complete(never were) and with Go 1.9 "GC" will be > > > supporting only Power 8 and up. > > > > Just for clarity, you're ppc64le would remain supported. Correct? > > Yes. That is correct, and we have already announced to the Fedora on Power community that situations like this might happen, so no one should be surprised. Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Tue, 2017-06-20 at 22:08 -0400, Neal Gompa wrote: > 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. we got debootstrap in Fedora :) [1] may you test it ? and report it via bugzilla or directly to me ... Best regards, [1] https://apps.fedoraproject.org/packages/debootstrap > 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 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Golang 1.9
On Thursday, 22 June 2017 at 13:17, Jakub Cajka wrote: > - Original Message - > > From: "Tony Breeds" > > To: devel@lists.fedoraproject.org > > Sent: Thursday, June 22, 2017 2:03:44 AM > > Subject: Re: F27 System Wide Change: Golang 1.9 > > > > On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote: > > > > > > > > > Along with the rebase I do propose to drop ppc64 from Go > > > architectures(effectively disabling build of all packages adhering to > > > draft Go packaging guidelines) as ppc64 port of "GC" is not feature > > > complete(never were) and with Go 1.9 "GC" will be supporting only > > > Power 8 and up. > > > > Just for clarity, you're ppc64le would remain supported. Correct? > > Yes. That is correct, Can you make sure that the Go packaging guidelines draft makes it into the official guidelines? Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, Jun 22, 2017 at 7:37 AM, Sérgio Basto wrote: > On Tue, 2017-06-20 at 22:08 -0400, Neal Gompa wrote: >> 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. > > we got debootstrap in Fedora :) [1] > may you test it ? and report it via bugzilla or directly to me ... > Yes, we do have debootstrap, but it can only build Debian-based systems. :) I want to be able to build a Fedora based one. 真実はいつも一つ！/ 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: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On 06/22/2017 0013Z, Neal Gompa wrote: Yes, we do have debootstrap, but it can only build Debian-based systems. :) I want to be able to build a Fedora based one. Please be specific, and give a concrete example of what should change. debootstrap takes a list of .debs and builds a root filesystem that contains them. febootstrap takes a list of .rpms and builds a root filesystem that contains them. In both cases the result contains some distro-specific metadata as files: the packaging data for maintenance of the system, which is implicit (are not files that are contained in some input .debs or .rpms.) In the case of Debian, the "extra" info is the apt metadata. In the case of Fedora, the "extra" info is the dnf/yum metadata. Anything else? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, Jun 22, 2017 at 9:29 AM, John Reiser wrote: > On 06/22/2017 0013Z, Neal Gompa wrote: >> >> Yes, we do have debootstrap, but it can only build Debian-based systems. >> :) >> >> I want to be able to build a Fedora based one. > > > Please be specific, and give a concrete example of what should change. > > debootstrap takes a list of .debs and builds a root filesystem that contains > them. > febootstrap takes a list of .rpms and builds a root filesystem that contains > them. > In both cases the result contains some distro-specific metadata as files: > the packaging data for maintenance of the system, which is implicit > (are not files that are contained in some input .debs or .rpms.) > In the case of Debian, the "extra" info is the apt metadata. > In the case of Fedora, the "extra" info is the dnf/yum metadata. > > Anything else? > debootstrap has the capability to utilize qemu-user-static to support constructing foreign arch rootfses. That means I can build an arm64, armhf, or ppc64el rootfs from an x86_64 host. As far as I know, febootstrap can't do this. The missing piece here is that I want to be able to construct a rootfs or an image for an architecture that *isn't* the same as my host machine. -- 真実はいつも一つ！/ 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: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, 22 Jun 2017 09:33:25 -0400 Neal Gompa wrote: > On Thu, Jun 22, 2017 at 9:29 AM, John Reiser > wrote: > > On 06/22/2017 0013Z, Neal Gompa wrote: > >> > >> Yes, we do have debootstrap, but it can only build Debian-based > >> systems. :) > >> > >> I want to be able to build a Fedora based one. > > > > > > Please be specific, and give a concrete example of what should > > change. > > > > debootstrap takes a list of .debs and builds a root filesystem that > > contains them. > > febootstrap takes a list of .rpms and builds a root filesystem that > > contains them. > > In both cases the result contains some distro-specific metadata as > > files: the packaging data for maintenance of the system, which is > > implicit (are not files that are contained in some input .debs > > or .rpms.) In the case of Debian, the "extra" info is the apt > > metadata. In the case of Fedora, the "extra" info is the dnf/yum > > metadata. > > > > Anything else? > > > > debootstrap has the capability to utilize qemu-user-static to support > constructing foreign arch rootfses. That means I can build an arm64, > armhf, or ppc64el rootfs from an x86_64 host. As far as I know, > febootstrap can't do this. > > The missing piece here is that I want to be able to construct a rootfs > or an image for an architecture that *isn't* the same as my host > machine. which is a non-trivial issue as rpm can have scriptlets ... Dan ___ 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> Thanks a lot, that is helpful. There is also a pkgdb2client [0] IS> package that I've been looking into for this. You could run that tool in a loop, parse the result and generate the report, I guess, but it's also rather trivial to just make the necessary API call directly and parse the returned JSON, which is what the tool I provided does. And of course, pkgdb is going away at some point in the relatively near future anyway, so anything written now is going to have to be rewritten anyway. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: > On Thu, Jun 22, 2017 at 9:29 AM, John Reiser wrote: >> On 06/22/2017 0013Z, Neal Gompa wrote: >>> >>> Yes, we do have debootstrap, but it can only build Debian-based systems. >>> :) >>> >>> I want to be able to build a Fedora based one. >> >> >> Please be specific, and give a concrete example of what should change. >> >> debootstrap takes a list of .debs and builds a root filesystem that contains >> them. >> febootstrap takes a list of .rpms and builds a root filesystem that contains >> them. >> In both cases the result contains some distro-specific metadata as files: >> the packaging data for maintenance of the system, which is implicit >> (are not files that are contained in some input .debs or .rpms.) >> In the case of Debian, the "extra" info is the apt metadata. >> In the case of Fedora, the "extra" info is the dnf/yum metadata. >> >> Anything else? >> > > debootstrap has the capability to utilize qemu-user-static to support > constructing foreign arch rootfses. That means I can build an arm64, > armhf, or ppc64el rootfs from an x86_64 host. As far as I know, > febootstrap can't do this. > > The missing piece here is that I want to be able to construct a rootfs > or an image for an architecture that *isn't* the same as my host > machine. For what purpose? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, Jun 22, 2017 at 9:55 AM, Josh Boyer wrote: > On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: >> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser wrote: >>> On 06/22/2017 0013Z, Neal Gompa wrote: Yes, we do have debootstrap, but it can only build Debian-based systems. :) I want to be able to build a Fedora based one. >>> >>> >>> Please be specific, and give a concrete example of what should change. >>> >>> debootstrap takes a list of .debs and builds a root filesystem that contains >>> them. >>> febootstrap takes a list of .rpms and builds a root filesystem that contains >>> them. >>> In both cases the result contains some distro-specific metadata as files: >>> the packaging data for maintenance of the system, which is implicit >>> (are not files that are contained in some input .debs or .rpms.) >>> In the case of Debian, the "extra" info is the apt metadata. >>> In the case of Fedora, the "extra" info is the dnf/yum metadata. >>> >>> Anything else? >>> >> >> debootstrap has the capability to utilize qemu-user-static to support >> constructing foreign arch rootfses. That means I can build an arm64, >> armhf, or ppc64el rootfs from an x86_64 host. As far as I know, >> febootstrap can't do this. >> >> The missing piece here is that I want to be able to construct a rootfs >> or an image for an architecture that *isn't* the same as my host >> machine. > > For what purpose? Well, it's part of a workflow to construct custom AArch64 images from an x86_64 PC. It's not generally feasible to do all the work on an SBC, and all the approaches I've found so far assume native arch for Fedora. In addition, it's a good gateway for being able to set up emulated build environments for foreign architectures in things like mock, so that the limitation of having real hardware can go away for people to test builds locally. It's a pretty huge deficiency to not have *something* for this purpose. -- 真実はいつも一つ！/ 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: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Wed, Jun 21, 2017 at 3:08 AM, Neal Gompa wrote: > 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? You can run a aarch64 emulated VM on x86_64, which won't be fast, but you can then use anaconda install or a kickstart to install into a VM raw disk. We also produce (currently unsupported) raw disk images aimed at aarch64 SBC images for F-26+ but we have some current bootloader issues so they're very much currently aimed at people that understand the low level bits of the bootloader/kernel for testing/fixing. IE if you have issues or don't understand that you get to keep both pieces (hoping to have those issues fixed RSN). What are you trying to achieve? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?
On Thu, Jun 22, 2017 at 3:03 PM, Neal Gompa wrote: > On Thu, Jun 22, 2017 at 9:55 AM, Josh Boyer wrote: >> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: >>> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser wrote: On 06/22/2017 0013Z, Neal Gompa wrote: > > Yes, we do have debootstrap, but it can only build Debian-based systems. > :) > > I want to be able to build a Fedora based one. Please be specific, and give a concrete example of what should change. debootstrap takes a list of .debs and builds a root filesystem that contains them. febootstrap takes a list of .rpms and builds a root filesystem that contains them. In both cases the result contains some distro-specific metadata as files: the packaging data for maintenance of the system, which is implicit (are not files that are contained in some input .debs or .rpms.) In the case of Debian, the "extra" info is the apt metadata. In the case of Fedora, the "extra" info is the dnf/yum metadata. Anything else? >>> >>> debootstrap has the capability to utilize qemu-user-static to support >>> constructing foreign arch rootfses. That means I can build an arm64, >>> armhf, or ppc64el rootfs from an x86_64 host. As far as I know, >>> febootstrap can't do this. >>> >>> The missing piece here is that I want to be able to construct a rootfs >>> or an image for an architecture that *isn't* the same as my host >>> machine. >> >> For what purpose? > > Well, it's part of a workflow to construct custom AArch64 images from > an x86_64 PC. It's not generally feasible to do all the work on an > SBC, and all the approaches I've found so far assume native arch for > Fedora. > > In addition, it's a good gateway for being able to set up emulated > build environments for foreign architectures in things like mock, so > that the limitation of having real hardware can go away for people to > test builds locally. > > It's a pretty huge deficiency to not have *something* for this purpose. We have the ability to run full virtual emulated machines using libvirt so there is *something* for this purpose and there has been for *quite* some time and it's been documented in the wiki for as long as it's been available: https://fedoraproject.org/wiki/Architectures/AArch64/F25/Installation#Install_with_QEMU ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
off-topic suggested reading: why containers really are revolutionary
I know that a lot of us in the Fedora world are from traditional IT backgrounds. From this point of view, can containers seem like just the latest buzzword in a long series of fads, and not really all that different from virtualization or various system-partitioning schemes of days past. This is a great short article about why this is really part of of a big revolution in IT operations; while it might be evolutionary, it's hit a tipping point really enabling something new - particularly with ochestrators like Kubernetes. https://container-solutions.com/dynamic-management-real-ops-disruptor/ This is part of a series, but this one in particular hit me as succinct and useful to understanding the future of IT, which is important to Fedora as we build a important layers of that future. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
coreutils /bin file dependencies
While playing with Base Runtime container base images we noticed that some packages couldn't be installed with coreutils-single due to their /bin file dependencies. Unlike the original coreutils package, coreutils-single doesn't provide the pre-UsrMove paths. Now there are at least two ways to resolve this. We either a) change all the packages that depend on /bin/* coreutils paths, or b) we add the respective /bin provides to coreutils-single. Reading the packaging guidelines[0], I'd lean towards "fixing" the coreutils subpackage, while the coreutils maintainers believe we should change packages that depend on obsolete paths. For the record, there appear to be only 25 binary packages that depend on /bin coreutils paths[1]; patching coreutils is also trivial[2]. I'm curious as to what other people think about both this specific case as well as how to solve these issues in general. Cheers, P [0] https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove_Fedora_Feature [1] https://paste.fedoraproject.org/paste/v-SDa5byzWT93OKPWZ~XKQ/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1463384#c1 signature.asc Description: 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: Kerberos KCM credential cache by default
Hey, 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 > > 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. > > [...] > > == Scope == > * Proposal owners: > SSSD developers will implement a KCM server. The deamon along with a > krb5.conf snippet will be packaged in a subpackage called `sssd-krb5`. > The interested variants of Fedora that would wish to opt in would add > the `sssd-krb5` subpackage to their compose. > > * Other developers: > None required Based on my past conversations with the Identity Management folks, I think we want this in Workstation. So we also need to support KCM caches in gnome-online-accounts for the GNOME integration. The upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=779140 Maybe we should also track it in Fedora? (One problem with the existing KEYRING caches is the lack of a notification API. The Kerberos integration in GNOME through gnome-online-accounts ends up having to poll the kernel's keyring every few seconds to find out about the state of credentials. In contrast, KCM is supposed to use D-Bus signals for notification, and in the past one could use inotify watches with FILE and DIR caches.) Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
lightdm-gtk segfaults on first login
Hello, I have been facing an issue with lightdm-gtk since I installed Fedora 25 (mate desktop) in my system. When I boot system and try login for the first time, lightdm-gtk segfaults and screen goes blacks for a second or so. Then lightdm-gtk re-appears asking for login credentials again. The second time I enter credentials, login is successful. dmesg - lightdm-gtk-gre[1143]: segfault at 10 ip 7fa3023fbf70 sp 7ffcf876f828 error 4 in libcairo.so.2.11400.8[7fa30238e000+122000] I filed a bug for same. Here: https://bugzilla.redhat.com/show_bug.cgi?id=1463847 Did anyone else had this issue? Is there a workaround for the same? It's really annoying to enter login credentials 2 times everytime when system boots. Thanks. Sent with [ProtonMail](https://protonmail.com) Secure Email.___ 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 Wed, Jun 21, 2017 at 12:27:47PM +1000, 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
> ```
There are two downsides to this kind of declaration:
- python2-runtimedep[12] will be used until the switch to python3 as
default is made, which might be very long. Instead, we would prefer
packages to use python3-runtimedep[12] to gradually push out python2.
- when the switch finally comes, such packages will suddenly switch
all at once, and such flag days are generally painful.
So instead, I think it'd preferable to introduce a global macro
%python_preferred_suffix (or a better name), that would evaluate
to '3' on all Fedora, and '' on EPEL [*]. The deps would then look as:
BuildRequires: python%{python_preferred_suffix}-builddep1
BuildRequires: python%{python_preferred_suffix}-builddep2
Requires: python%{python_preferred_suffix}-runtimedep1
Requires: python%{python_preferred_suffix}-runtimedep2
This would keep things unambiguous, but brief.
Zbyszek
[*] "preferred" in this case would be '3' if python3 deps are widely
available and expected to be used, and '' or '2' otherwise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: off-topic suggested reading: why containers really are revolutionary
On Thu, 22 Jun 2017 10:55:50 -0400 Matthew Miller wrote: > https://container-solutions.com/dynamic-management-real-ops-disruptor/ What strikes me about this is that containers sound like static linking on steroids. This seems like it would create a lot of redundancy on a standalone system. Where do the storage savings come from? And the container environment seems like it is a JIT compiler, to allow the application access to computing resources in a standardized way through an abstracted interface. That must have a cost in terms of execution speed. Can a container created on Fedora with Fedora tools run in any host environment that provides a container manager? For example, will a Fedora container run on Windows, and vice versa? Is the grand vision that everything is in the cloud, even for personal computing? How is data security ensured? It seems that if things run in the cloud, then at some point they are decrypted to get to the CPU, and thus vulnerable. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: off-topic suggested reading: why containers really are revolutionary
On Thu, Jun 22, 2017 at 01:09:35PM -0700, stan wrote: > > https://container-solutions.com/dynamic-management-real-ops-disruptor/ > What strikes me about this is that containers sound like static linking > on steroids. That's not entirely unfair. The important thing though is that these particular "steroids" enable a new way of systems management. >This seems like it would create a lot of redundancy on a > standalone system. Where do the storage savings come from? And the There's some redundancy, but common bits can be shared via layering. > container environment seems like it is a JIT compiler, to allow the > application access to computing resources in a standardized way through > an abstracted interface. That must have a cost in terms of execution > speed. In the case of Docker/OCI containers and similar, the common interface is "the Linux kernel". There is not a significant speed penalty. > Can a container created on Fedora with Fedora tools run in any host > environment that provides a container manager? For example, will a > Fedora container run on Windows, and vice versa? Assuming a new enough kernel, it's generally true that you can run containers from one distro on another. For example, CoreOS uses a Fedora-based container for systems management. Windows is a different story since it's ... not Linux ... but even that may change in the future with WSL. > Is the grand vision that everything is in the cloud, even for personal > computing? How is data security ensured? It seems that if things run > in the cloud, then at some point they are decrypted to get to the CPU, > and thus vulnerable. This is an orthogonal issue — you can certainly do all of this in your own data center if you like. (And I expect a lot of Fedora users will be using containers in this way.) But, speaking as a former sysadmin who has Seen Things, a well-managed public cloud enviroment (e.g. Amazon, GCE, Azure, Digital Ocean, etc.) is in a practical sense much less of a data security risk than running a local server room at any scale. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
On Thu, Jun 22, 2017 at 11:15 AM, Petr Šabata wrote: > While playing with Base Runtime container base images we noticed > that some packages couldn't be installed with coreutils-single > due to their /bin file dependencies. Unlike the original > coreutils package, coreutils-single doesn't provide the > pre-UsrMove paths. > > Now there are at least two ways to resolve this. We either > > a) change all the packages that depend on /bin/* coreutils > paths, or > b) we add the respective /bin provides to coreutils-single. > > Reading the packaging guidelines[0], I'd lean towards "fixing" > the coreutils subpackage, while the coreutils maintainers > believe we should change packages that depend on obsolete paths. > > For the record, there appear to be only 25 binary packages that > depend on /bin coreutils paths[1]; patching coreutils is also > trivial[2]. > > I'm curious as to what other people think about both this > specific case as well as how to solve these issues in general. > > Cheers, > P > I would just do option B. That way you're not breaking third-party packages, too. -- 真実はいつも一つ！/ 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: off-topic suggested reading: why containers really are revolutionary
On Thu, 22 Jun 2017 16:32:09 -0400 Matthew Miller wrote: Thanks for your insight. ___ 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 23 June 2017 at 04:07, Zbigniew Jędrzejewski-Szmek wrote:
> There are two downsides to this kind of declaration:
> - python2-runtimedep[12] will be used until the switch to python3 as
> default is made, which might be very long. Instead, we would prefer
> packages to use python3-runtimedep[12] to gradually push out python2.
> - when the switch finally comes, such packages will suddenly switch
> all at once, and such flag days are generally painful.
>
> So instead, I think it'd preferable to introduce a global macro
> %python_preferred_suffix (or a better name), that would evaluate
> to '3' on all Fedora, and '' on EPEL [*]. The deps would then look as:
>
> BuildRequires: python%{python_preferred_suffix}-builddep1
> BuildRequires: python%{python_preferred_suffix}-builddep2
> Requires: python%{python_preferred_suffix}-runtimedep1
> Requires: python%{python_preferred_suffix}-runtimedep2
>
> This would keep things unambiguous, but brief.
Miro suggested something similar (with %{py} as the macro spelling),
and it occurred to me that something like that could instead be made a
recommendation for people to use at the level of their own spec files
rather than something that Fedora provides by default. For example:
```
%if 0%{?el7} || 0%{?fedora} < 25
BuildRequires: python2-devel
%define py_prefix python
%else
BuildRequires: python3-devel
%define py_prefix python3
%endif
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```
That approach avoids my original concern about duplicating the
dependency lists, and it also means we would avoid replacing the
current "default Python" flag day with a new "preferred Python" flag
day. Instead, spec authors would be asked to declare explicitly in
their own spec file when they switched over to using Fedora's Python 3
stack rather than the Python 2 stack.
Which (as it turns out) is exactly what Iryna's original message
proposed, just with more explicit guidance on how to handle that
request in a relatively easy to maintain way :)
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
Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"
On 22 June 2017 at 12:54, Neal Gompa wrote: > On Wed, Jun 21, 2017 at 10:25 PM, Nick Coghlan wrote: >> 1. How to modify a package to explicitly declare it as "Python 2 only" >> (and the need for a "BuildRequires: epel-rpm-macros" to reliably get >> access to the versioned Python macros on EL systems) > > This is not necessary, as EPEL buildroot pulls it in automatically. EPEL itself does, but adding the build requires means that you'll get a dependency error if they're missing, rather than the cryptic "fg: job control not found" error that bash reports when RPM lets an unknown macro through to the shell. It also means that you just need to have EPEL enabled for a build to work, rather than making assumptions about the buildroot configuration. 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
Fedora 26-20170622.n.0 compose check report
No missing expected images. Failed openQA tests: 9/126 (x86_64), 1/2 (arm) New failures (same test did not fail in 26-20170621.n.0): ID: 111854 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/111854 ID: 111874 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/111874 ID: 111879 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/111879 ID: 111898 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/111898 ID: 111902 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/111902 ID: 111932 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/111932 Old failures (same test failed in 26-20170621.n.0): ID: 111871 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/111871 ID: 111872 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/111872 ID: 111887 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/111887 ID: 111943 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/111943 Soft failed openQA tests: 1/126 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 26-20170621.n.0): ID: 111835 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/111835 ID: 111836 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/111836 ID: 111888 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/111888 Passed openQA tests: 116/126 (x86_64), 22/24 (i386) New passes (same test did not pass in 26-20170621.n.0): ID: 111855 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/111855 ID: 111865 Test: x86_64 KDE-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/111865 ID: 111944 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/111944 Skipped openQA tests: 1 of 152 Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.02 to 0.14 Previous test data: https://openqa.fedoraproject.org/tests/111291#downloads Current test data: https://openqa.fedoraproject.org/tests/111816#downloads Installed system changes in test i386 Server-dvd-iso install_default: System load changed from 0.10 to 0.22 Previous test data: https://openqa.fedoraproject.org/tests/111311#downloads Current test data: https://openqa.fedoraproject.org/tests/111836#downloads Installed system changes in test i386 Everything-boot-iso install_default: System load changed from 0.00 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/111314#downloads Current test data: https://openqa.fedoraproject.org/tests/111839#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.83 to 1.12 Previous test data: https://openqa.fedoraproject.org/tests/111315#downloads Current test data: https://openqa.fedoraproject.org/tests/111840#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default: 1 packages(s) removed since previous compose: at 1 services(s) removed since previous compose: atd.service Used mem changed from 1094 MiB to 841 MiB Previous test data: https://openqa.fedoraproject.org/tests/111328#downloads Current test data: https://openqa.fedoraproject.org/tests/111853#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default@uefi: 1 packages(s) removed since previous compose: at 1 services(s) removed since previous compose: atd.service Previous test data: https://openqa.fedoraproject.org/tests/111331#downloads Current test data: https://openqa.fedoraproject.org/tests/111856#downloads Installed system changes in test i386 Workstation-boot-iso install_default: 1 packages(s) added since previous compose: fedora-workstation-backgrounds 1 packages(s) removed since previous compose: at 1 services(s) removed since previous compose: atd.service System load changed from 0.29 to 0.73 Average CPU usage changed from 2.86190476 to 16.25238095 Used mem changed from 599 MiB to 739 MiB Previous test data: https://openqa.fedoraproject.org/tests/111334#downloads Current test data: https://openqa.fedoraproject.org/tests/111859#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 1.98 to 0.92 Average CPU usage changed from 42.72380952 to 29.20952381 Previous test data: http
