Fedora 26-20170623.n.0 compose check report
No missing expected images. Failed openQA tests: 5/128 (x86_64), 1/2 (arm) New failures (same test did not fail in 26-20170622.n.0): ID: 112254 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/112254 ID: 112290 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/112290 Old failures (same test failed in 26-20170622.n.0): ID: 112312 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/112312 ID: 112314 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/112314 ID: 112329 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/112329 ID: 112385 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/112385 Soft failed openQA tests: 3/128 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in 26-20170622.n.0): ID: 112316 Test: x86_64 Atomic-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/112316 ID: 112317 Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/112317 Old soft failures (same test soft failed in 26-20170622.n.0): ID: 112275 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/112275 ID: 112276 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/112276 ID: 112330 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/112330 Passed openQA tests: 120/128 (x86_64), 22/24 (i386) New passes (same test did not pass in 26-20170622.n.0): ID: 112294 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/112294 ID: 112311 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/112311 ID: 112321 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/112321 ID: 112340 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/112340 ID: 112344 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/112344 ID: 112374 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/112374 Skipped openQA tests: 1 of 154 Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.14 to 0.43 Previous test data: https://openqa.fedoraproject.org/tests/111816#downloads Current test data: https://openqa.fedoraproject.org/tests/112256#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 1.12 to 0.76 Previous test data: https://openqa.fedoraproject.org/tests/111840#downloads Current test data: https://openqa.fedoraproject.org/tests/112280#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.97 to 1.17 Previous test data: https://openqa.fedoraproject.org/tests/111841#downloads Current test data: https://openqa.fedoraproject.org/tests/112281#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default: System load changed from 0.32 to 0.51 Average CPU usage changed from 3.22380952 to 15.55714286 Used mem changed from 841 MiB to 1108 MiB Previous test data: https://openqa.fedoraproject.org/tests/111853#downloads Current test data: https://openqa.fedoraproject.org/tests/112293#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default@uefi: System load changed from 0.42 to 0.63 Previous test data: https://openqa.fedoraproject.org/tests/111856#downloads Current test data: https://openqa.fedoraproject.org/tests/112296#downloads Installed system changes in test i386 Workstation-live-iso install_default: System load changed from 1.10 to 0.45 Average CPU usage changed from 20.82380952 to 3.47619048 Previous test data: https://openqa.fedoraproject.org/tests/111857#downloads Current test data: https://openqa.fedoraproject.org/tests/112297#downloads Installed system changes in test i386 Workstation-boot-iso install_default: System load changed from 0.73 to 0.60 Used mem changed from 739 MiB to 637 MiB Previous test data: https://openqa.fedoraproject.org/tests/111859#downloads Current test data: https://openqa.fedoraproject.org/tests/112299#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 0.92 to 1.49 Previous test data: https://openqa.fedoraproject.org/tests/111860#downloads Current test data: https://openqa.fedoraproject.org/tests/112300#downloads Ins
Outage of Build Systems 2017-06-24 16:00 UTC
There will be an outage starting at 2017-06-24 16:00UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2017-06-24 16:00 UTC Reason for outage: There have been some performance problems with the backend switches. These need an update from juniper and a reboot and possible debugging. Affected Services: pkgs.fedoraproject.org koji koshei kojipkgs pkgdb bodhi / updates mdapi service Services not listed are not affected by this outage. Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6131 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ 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)?
/*Adam Williamson*/ wrote on Fri, 23 Jun 2017 12:45:07 -0700: On Fri, 2017-06-23 at 09:06 -0400, Neal Gompa wrote: You have run into the purest form of open source, the "scratch your own itch" case. You want to be able to do things that cannot be done today, and nobody else is working on it. It seems like you have a really good foundation for what needs to be done, so perhaps you could start a project to work towards what you need? If you publicize it, you might even get some contributors to join you. I'll be honest, I have been thinking about it... Maybe I'll have something soonish. ;) Did you actually check yet whether virt-builder is sufficient for your purposes? I'd say the difference is comparable to the difference of containers vs VMs: sometimes you need user-land of another arch, but do not want to run a full VM. For example, it can be used to compile for another arch. So, you might want to build a rootfs with compiler & libraries (but not a complete system image with kernel & ...). As an example, you might refer to rootfs tarballs used for scratchbox to compile for different architectures. Actually, as Fedora does NOT provide cross compilers (e.g. to build user land ARM applications under x86_64), it can be used to provide 'The Fedora Approach to Cross Compiling'. To create a minimal rootfs with ARM compilers & libraries which can be used using qemu to run ARM GCC in the rootfs to build your packages. This is actually how I do cross-compiling in Fedora: I grab a Fedora ARM image, install qmeu-user binaries on the host, copy qemu ARM binary into the rootfs (even bind-mounting /lib64 before I know we have qemu static binaries in Fedora!), patch its DNF to work fine under qemu, install required software using 'chroot dnf install ...', bind mounting the source directory, chrooting to the rootfs and build the software. I've always preferred using scratchbox or the above method to compile ARM binaries rather than using a full VM, which plays much nicer on my pretty-old laptop! :) Regards, Hedayat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
On Fri, 2017-06-23 at 05:55 -0400, Charalampos Stratakis wrote: > Many people do that and find it convenient, but I don't see how > maintaining the same SPEC file for different distros is less of a > maintenance burden > than having a different SPEC for each distro/branch you want to > support. It makes it much easier to quickly make a change across all branches; you just make the change on master and merge it to all other branches. If each branch diverges from the others you have to cherry pick, and often the cherry pick will not work cleanly (due to the changelog and EVR differing, if nothing else) and you'll have to reconcile it. Giant pain in the ass. > And clearly, Fedora has diverged too much from any RHEL/epel > buildroots currently, so keeping the same SPEC is even harder, I do it for quite a lot of packages and haven't really had much trouble at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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 Fri, 2017-06-23 at 09:06 -0400, Neal Gompa wrote: > > > You have run into the purest form of open source, the "scratch your > > own itch" case. You want to be able to do things that cannot be done > > today, and nobody else is working on it. It seems like you have a > > really good foundation for what needs to be done, so perhaps you could > > start a project to work towards what you need? If you publicize it, > > you might even get some contributors to join you. > > > > I'll be honest, I have been thinking about it... Maybe I'll have > something soonish. ;) Did you actually check yet whether virt-builder is sufficient for your purposes? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] 2017-06-26 @ 1600 UTC ** Fedora Blocker Review
# F26 Blocker Review meeting # Date: 2017-06-26 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Time for some more blocker review! We got last week off, so we've had a bit of a backlog show up. Currently there are 7 proposed blockers and one proposed FE. If you have any time between now and the meeting Monday, please take a look through the list. It canbe found here: https://qa.fedoraproject.org/blockerbugs/ We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F26 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria // Mike -- Fedora QA ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: How to make a package multilib
Tomas Mraz wrote: > Hi all, > > the package p11-kit-trust needs to be multilib because it contains > PKCS#11 .so object used for access to trusted CA certificate store. > However because this package is a PKCS#11 module and not a regular > shared library there is no p11-kit-trust-devel package which would mark > it automatically as multilib. Is there a way how to mark the package > multilib explicitly? Adding Requires: p11-kit-trust%{?_isa} to another > multilib package apparently did not help. I would expect the adding Requires: to fix it, but you will have to wait for the next (rawhide) compose for the new stuff to get added. Because, if it doesn't get added, then there will be broken deps (or... were there broken deps?). -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Rsyslog log format change proposal
> logcheck → needs to be checked It will break by this change. I was not able to make it work on two machines. My system is cursed and containers does not have such logs at all. Going to check on fresh VM. However I was able to dive in the code and check how it works. It is basically big collection of regexps, lot of them looks like this: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ smartd\[[0-9]+\]: Device: [...] So this would break when there will be different than traditional format. Going to check whether problems I encountered are on my side only... and then ask maintainer of this package whether we would like to change it, make it use journal or something else. Regards Roman ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2017-06-23)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2017-06-23 16:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1690 Self Contained Changes (Java system/command setting) .fesco 1690 https://pagure.io/fesco/issue/1690 #topic #1715 F27 System Wide Change: Rsyslog log format change proposal .fesco 1715 https://pagure.io/fesco/issue/1715 = New business = #topic #1619 System Wide Change: perl Package to Install Core Modules .fesco 1619 https://pagure.io/fesco/issue/1619 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. F27 System Wide Change: Rsyslog log format change proposal ___ 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 Fri, Jun 23, 2017 at 8:58 AM, Josh Boyer wrote: > On Fri, Jun 23, 2017 at 8:22 AM, Neal Gompa wrote: >> On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones >> wrote: >>> On Thu, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote: On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: > 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? >>> >>> I don't know what Neal is up to, but some uses for a debootstrap-like >>> tool include: >>> >>> * Creating chroots, eg. for confinement of daemons, or testing >>> your code under different distros/versions. >>> >>> * Installing the distribution. Mount a new disk on /tmp/sysroot and >>> run debootstrap /tmp/sysroot, then either unmount the disk and use >>> it to boot a new machine, or run a VM on this disk, or pivot-root >>> into the new distro. >>> >>> * Building containers. >>> >>> There are two subcases, the cross-architecture sub-case (host arch != >>> chroot arch) and the non-root sub-case (run debootstrap as non-root). >>> >>> The non-root sub-case is useful for testing, or any case where you >>> don't want to run stuff as root for security / integrity reasons. The >>> difficult part is setting the right owner/mode on new files. >>> >>> The cross-architecture sub-case is useful where you want to install >>> the distro as above, but for a different architecture. >>> >>> The presence of RPM scripts makes this really hard to do in general. >>> Debootstrap concatenates all the applicable scripts into "init" script >>> which you're supposed to run on first boot in the new environment >>> (where presumably your CPU is able to run them). I don't think this >>> is possible for RPM scripts which are more complex. >>> >>> My opinion is that all RPM scripts should go away, to be replaced by >>> declarative metadata about what users/groups/services/etc are required >>> by the RPM, and it would be up to RPM to execute the right set of >>> commands to bring the system into line with the requirements of the >>> installed packages. >>> >> >> Basically, I want to do *all* of these cases, where host arch != rootfs arch. >> >> I'm trying to set up foreign arch containers to do test and >> development, across multiple distributions/versions. In addition, I'd >> like to be able to set up package builders for foreign arches without >> having to have real hardware everywhere. For some architectures I'm >> working with, real hardware is not practical. >> >> I'd also like to be able to create highly custom image structures for >> foreign architectures from my host machine. This is important for >> making bootable images for weird SBCs and things like that. >> >> As for the scripts thing, I believe the way that debootstrap handles >> that is that the udebs (special debs for install environments) are >> unpacked to provide a minimal script run environment to execute >> apt+dpkg, and then qemu-user-static is configured for the environment, >> and debootstrap then uses the actual rootfs' apt to keep going. That >> allows for most of the basic stuff to actually work correctly. The >> same basic approach is also used by SUSE's OBS for setting up foreign >> arch builder environments[1] (Preinstall and VMinstall directives do >> not run scriptlets, just unpack things). > > You have run into the purest form of open source, the "scratch your > own itch" case. You want to be able to do things that cannot be done > today, and nobody else is working on it. It seems like you have a > really good foundation for what needs to be done, so perhaps you could > start a project to work towards what you need? If you publicize it, > you might even get some contributors to join you. > I'll be honest, I have been thinking about it... Maybe I'll have something soonish. ;) -- 真実はいつも一つ!/ 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: Nonresponsive maintainer: attempting to contact kanarip
On 23 June 2017 at 12:33, Haïkel wrote: > 2017-06-23 12:39 GMT+02:00 James Hogarth : >> Hi, >> >> Has anyone heard from kanarip or able to contact him? >> >> I've been attempting to contact for this bug: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1223593 >> >> If there's no response in one week an issue will be filed with FESCo >> following the nonrepsonsive maintainer policy to review the ownership >> status of the packages. >> >> For ruby maintainers please note that this has a significant impact on >> you, if you want to keep track of this, as he owns puppet, rubygems >> and ruby ... >> >> https://admin.fedoraproject.org/pkgdb/packager/kanarip/ >> > > You're making it sound like Puppet is unmaintained which is not accurate. > There are many comaintainers and provenpackagers working on it. > Indeed it has been updated, though facter which it depends on has not, but the point being following our processes ... should there be deemed a need for a mass orphaning of his packages then someone needs to pick it up. In addition whilst he maintains POC for it as the "owner" the default assignee of bugs goes to him ... If ruby and puppet maintainers didn't notice the orphaning as a result... then they would be at risk of (temporary) retirement which could cause confusion for a bit, rather than notifying and sorting it all out at once :) ___ 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 Fri, Jun 23, 2017 at 8:22 AM, Neal Gompa wrote: > On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones wrote: >> On Thu, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote: >>> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: >>> > 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? >> >> I don't know what Neal is up to, but some uses for a debootstrap-like >> tool include: >> >> * Creating chroots, eg. for confinement of daemons, or testing >> your code under different distros/versions. >> >> * Installing the distribution. Mount a new disk on /tmp/sysroot and >> run debootstrap /tmp/sysroot, then either unmount the disk and use >> it to boot a new machine, or run a VM on this disk, or pivot-root >> into the new distro. >> >> * Building containers. >> >> There are two subcases, the cross-architecture sub-case (host arch != >> chroot arch) and the non-root sub-case (run debootstrap as non-root). >> >> The non-root sub-case is useful for testing, or any case where you >> don't want to run stuff as root for security / integrity reasons. The >> difficult part is setting the right owner/mode on new files. >> >> The cross-architecture sub-case is useful where you want to install >> the distro as above, but for a different architecture. >> >> The presence of RPM scripts makes this really hard to do in general. >> Debootstrap concatenates all the applicable scripts into "init" script >> which you're supposed to run on first boot in the new environment >> (where presumably your CPU is able to run them). I don't think this >> is possible for RPM scripts which are more complex. >> >> My opinion is that all RPM scripts should go away, to be replaced by >> declarative metadata about what users/groups/services/etc are required >> by the RPM, and it would be up to RPM to execute the right set of >> commands to bring the system into line with the requirements of the >> installed packages. >> > > Basically, I want to do *all* of these cases, where host arch != rootfs arch. > > I'm trying to set up foreign arch containers to do test and > development, across multiple distributions/versions. In addition, I'd > like to be able to set up package builders for foreign arches without > having to have real hardware everywhere. For some architectures I'm > working with, real hardware is not practical. > > I'd also like to be able to create highly custom image structures for > foreign architectures from my host machine. This is important for > making bootable images for weird SBCs and things like that. > > As for the scripts thing, I believe the way that debootstrap handles > that is that the udebs (special debs for install environments) are > unpacked to provide a minimal script run environment to execute > apt+dpkg, and then qemu-user-static is configured for the environment, > and debootstrap then uses the actual rootfs' apt to keep going. That > allows for most of the basic stuff to actually work correctly. The > same basic approach is also used by SUSE's OBS for setting up foreign > arch builder environments[1] (Preinstall and VMinstall directives do > not run scriptlets, just unpack things). You have run into the purest form of open source, the "scratch your own itch" case. You want to be able to do things that cannot be done today, and nobody else is working on it. It seems like you have a really good foundation for what needs to be done, so perhaps you could start a project to work towards what you need? If you publicize it, you might even get some contributors to join you. 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 Fri, Jun 23, 2017 at 08:22:59AM -0400, Neal Gompa wrote: > As for the scripts thing, I believe the way that debootstrap handles > that is that the udebs (special debs for install environments) are > unpacked to provide a minimal script run environment to execute > apt+dpkg, and then qemu-user-static is configured for the environment, > and debootstrap then uses the actual rootfs' apt to keep going. That > allows for most of the basic stuff to actually work correctly. The > same basic approach is also used by SUSE's OBS for setting up foreign > arch builder environments[1] (Preinstall and VMinstall directives do > not run scriptlets, just unpack things). Fair enough, this must have changed since I last looked at this (which was a really long time ago). This does sound like a better approach too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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 Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones wrote: > On Thu, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote: >> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: >> > 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? > > I don't know what Neal is up to, but some uses for a debootstrap-like > tool include: > > * Creating chroots, eg. for confinement of daemons, or testing > your code under different distros/versions. > > * Installing the distribution. Mount a new disk on /tmp/sysroot and > run debootstrap /tmp/sysroot, then either unmount the disk and use > it to boot a new machine, or run a VM on this disk, or pivot-root > into the new distro. > > * Building containers. > > There are two subcases, the cross-architecture sub-case (host arch != > chroot arch) and the non-root sub-case (run debootstrap as non-root). > > The non-root sub-case is useful for testing, or any case where you > don't want to run stuff as root for security / integrity reasons. The > difficult part is setting the right owner/mode on new files. > > The cross-architecture sub-case is useful where you want to install > the distro as above, but for a different architecture. > > The presence of RPM scripts makes this really hard to do in general. > Debootstrap concatenates all the applicable scripts into "init" script > which you're supposed to run on first boot in the new environment > (where presumably your CPU is able to run them). I don't think this > is possible for RPM scripts which are more complex. > > My opinion is that all RPM scripts should go away, to be replaced by > declarative metadata about what users/groups/services/etc are required > by the RPM, and it would be up to RPM to execute the right set of > commands to bring the system into line with the requirements of the > installed packages. > Basically, I want to do *all* of these cases, where host arch != rootfs arch. I'm trying to set up foreign arch containers to do test and development, across multiple distributions/versions. In addition, I'd like to be able to set up package builders for foreign arches without having to have real hardware everywhere. For some architectures I'm working with, real hardware is not practical. I'd also like to be able to create highly custom image structures for foreign architectures from my host machine. This is important for making bootable images for weird SBCs and things like that. As for the scripts thing, I believe the way that debootstrap handles that is that the udebs (special debs for install environments) are unpacked to provide a minimal script run environment to execute apt+dpkg, and then qemu-user-static is configured for the environment, and debootstrap then uses the actual rootfs' apt to keep going. That allows for most of the basic stuff to actually work correctly. The same basic approach is also used by SUSE's OBS for setting up foreign arch builder environments[1] (Preinstall and VMinstall directives do not run scriptlets, just unpack things). More info on OBS prjconf directives: http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.build_config.html The same basic approach is probably doable for a debootstrap-like tool for Fedora. [1]: https://build.opensuse.org/project/prjconf/Fedora:26 -- 真実はいつも一つ!/ 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, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote: > On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa wrote: > > 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? I don't know what Neal is up to, but some uses for a debootstrap-like tool include: * Creating chroots, eg. for confinement of daemons, or testing your code under different distros/versions. * Installing the distribution. Mount a new disk on /tmp/sysroot and run debootstrap /tmp/sysroot, then either unmount the disk and use it to boot a new machine, or run a VM on this disk, or pivot-root into the new distro. * Building containers. There are two subcases, the cross-architecture sub-case (host arch != chroot arch) and the non-root sub-case (run debootstrap as non-root). The non-root sub-case is useful for testing, or any case where you don't want to run stuff as root for security / integrity reasons. The difficult part is setting the right owner/mode on new files. The cross-architecture sub-case is useful where you want to install the distro as above, but for a different architecture. The presence of RPM scripts makes this really hard to do in general. Debootstrap concatenates all the applicable scripts into "init" script which you're supposed to run on first boot in the new environment (where presumably your CPU is able to run them). I don't think this is possible for RPM scripts which are more complex. My opinion is that all RPM scripts should go away, to be replaced by declarative metadata about what users/groups/services/etc are required by the RPM, and it would be up to RPM to execute the right set of commands to bring the system into line with the requirements of the installed packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1464403] perl-5.26.0-393.fc27 FTBFS on x86_64 since glibc-2.25.90-7.fc27.x86_64: uni/package.t and ../cpan/Unicode-Collate/t/illegalp.t tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1464403 Florian Weimer changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |DUPLICATE Last Closed||2017-06-23 08:09:46 --- Comment #4 from Florian Weimer --- perl needs rebuilding. *** This bug has been marked as a duplicate of bug 1464244 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-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 06:29:38AM -0700, John Reiser wrote: > febootstrap takes a list of .rpms and builds a root filesystem that contains > them. febootstrap [if you're talking about the tool I wrote 8 years ago] is obsolete. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Nonresponsive maintainer: attempting to contact kanarip
2017-06-23 12:39 GMT+02:00 James Hogarth : > Hi, > > Has anyone heard from kanarip or able to contact him? > > I've been attempting to contact for this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1223593 > > If there's no response in one week an issue will be filed with FESCo > following the nonrepsonsive maintainer policy to review the ownership > status of the packages. > > For ruby maintainers please note that this has a significant impact on > you, if you want to keep track of this, as he owns puppet, rubygems > and ruby ... > > https://admin.fedoraproject.org/pkgdb/packager/kanarip/ > You're making it sound like Puppet is unmaintained which is not accurate. There are many comaintainers and provenpackagers working on it. Regards, H. > Regards, > > James > ___ > 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: Nonresponsive maintainer: attempting to contact kanarip
Dne 23.6.2017 v 12:39 James Hogarth napsal(a): > Hi, > > Has anyone heard from kanarip or able to contact him? > > I've been attempting to contact for this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1223593 > > If there's no response in one week an issue will be filed with FESCo > following the nonrepsonsive maintainer policy to review the ownership > status of the packages. > > For ruby maintainers please note that this has a significant impact on > you, if you want to keep track of this, as he owns puppet, rubygems > and ruby ... I'm not afraid he would not show up ... But I'd gladly pickup the ruby* packages, since he does not maintain single of them. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Nonresponsive maintainer: attempting to contact kanarip
Hi, Has anyone heard from kanarip or able to contact him? I've been attempting to contact for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1223593 If there's no response in one week an issue will be filed with FESCo following the nonrepsonsive maintainer policy to review the ownership status of the packages. For ruby maintainers please note that this has a significant impact on you, if you want to keep track of this, as he owns puppet, rubygems and ruby ... https://admin.fedoraproject.org/pkgdb/packager/kanarip/ Regards, James ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Packages stuck in f27-pending
What reasons would there be for some old packages (one going back to 5th June) being stuck in f27-pending and not getting tagged into f27? https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=427&order=-build_id&latest=1 Seems not to be blockage in the signing queue as other packages are going through OK. Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
Many people do that and find it convenient, but I don't see how maintaining the same SPEC file for different distros is less of a maintenance burden than having a different SPEC for each distro/branch you want to support. And clearly, Fedora has diverged too much from any RHEL/epel buildroots currently, so keeping the same SPEC is even harder, not mentioning of course that it's a recipe for disaster for automation tools like rebase-helper or things like targeted mass rebuilds (e.g. when python/ruby/perl are rebased so all the respective packages have to be rebuilt) etc. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Mark Wielaard" To: "Igor Gnatenko" Cc: "Development discussions related to Fedora" Sent: Friday, June 23, 2017 10:57:11 AM Subject: Re: coreutils /bin file dependencies On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: > On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > > On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: > > > For the record, there appear to be only 25 binary packages that > > > depend on /bin coreutils paths[1]; > > > > I just took a quick look at the systemtap package. It has: > > > > # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer > > # distributions, /bin/mktemp comes from the 'coreutils' package. To > > # avoid a specific RHEL[45] Requires, we'll do a file-based require. > > Requires: /bin/mktemp > > > > On RHEL5 the mktemp package only provides a /bin/mktemp and > > no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be > > changed for Fedora of course. But it might be that there are other > > packages that share a spec file between RHEL and Fedora and have a > > /bin > > instead of /usr/bin Requires for this reason. > RHEL[45] is dead, so feel free to drop this. Also polluting spec file > with conditionals (or any other things) for unsupported/unrelated > distros just create problems. I won't argue about this particular case. RHEL4/5 is indeed pretty old and I wouldn't mind dropping support for it. But in general I like it when my spec files just work for building packages across Fedora/RHEL/SoftwareCollections even if that requires a few conditionals. For example I maintain valgrind and have it setup so that I can use the same spec file to build for "regular" Fedora, but also do a copr build for older Fedora or CentOS [1]. And the same spec file can be used to build the Developer Toolset software collection. It makes sure that there is a way to get the latest upstream (and backports) make it to different users. Which, in my experience, creates a better package for everybody since bug fixes are shared. Cheers, Mark [1] https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-and-centos/ ___ 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: coreutils /bin file dependencies
On Friday, June 23, 2017 10:57:11 Mark Wielaard wrote: > On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: > > > On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > > > > > On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: > > > > > > > For the record, there appear to be only 25 binary packages that > > > > depend on /bin coreutils paths[1]; > > > > > > > > > I just took a quick look at the systemtap package. It has: > > > > > > # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer > > > # distributions, /bin/mktemp comes from the 'coreutils' package. To > > > # avoid a specific RHEL[45] Requires, we'll do a file-based require. > > > Requires: /bin/mktemp > > > > > > On RHEL5 the mktemp package only provides a /bin/mktemp and > > > no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be > > > changed for Fedora of course. But it might be that there are other > > > packages that share a spec file between RHEL and Fedora and have a > > > /bin > > > instead of /usr/bin Requires for this reason. > > > > RHEL[45] is dead, so feel free to drop this. Also polluting spec file > > with conditionals (or any other things) for unsupported/unrelated > > distros just create problems. > > > I won't argue about this particular case. RHEL4/5 is indeed pretty old > and I wouldn't mind dropping support for it. > > But in general I like it when my spec files just work for building > packages across Fedora/RHEL/SoftwareCollections even if that requires a > few conditionals. For example I maintain valgrind and have it setup so > that I can use the same spec file to build for "regular" Fedora, but > also do a copr build for older Fedora or CentOS [1]. And the same spec > file can be used to build the Developer Toolset software collection. It > makes sure that there is a way to get the latest upstream (and > backports) make it to different users. Which, in my experience, creates > a better package for everybody since bug fixes are shared. I really appreciate that you take this approach. It helps me a lot when I debug something as I often want to build a Fedora package on RHEL or vice versa. However, it is not what Petr's question was about... He is not asking whether we should remove the /bin/* provides from the coreutils package. He is asking whether we should now introduce them into the coreutils-single package, too. If you are experimenting with packages mixed across distributions, it is unlikely that you have coreutils-single installed. The coreutils-single package is intended for use in Fedora-based containers where you have up2date version of software. On regular installations of Fedora, users will continue to use the coreutils package, which already has these /bin/* provides. Kamil > Cheers, > > Mark > > [1] > https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-an > d-centos/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
Dne 23.6.2017 v 10:57 Mark Wielaard napsal(a): > On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: >> On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: >>> On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: For the record, there appear to be only 25 binary packages that depend on /bin coreutils paths[1]; >>> I just took a quick look at the systemtap package. It has: >>> >>> # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer >>> # distributions, /bin/mktemp comes from the 'coreutils' package. To >>> # avoid a specific RHEL[45] Requires, we'll do a file-based require. >>> Requires: /bin/mktemp >>> >>> On RHEL5 the mktemp package only provides a /bin/mktemp and >>> no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be >>> changed for Fedora of course. But it might be that there are other >>> packages that share a spec file between RHEL and Fedora and have a >>> /bin >>> instead of /usr/bin Requires for this reason. >> RHEL[45] is dead, so feel free to drop this. Also polluting spec file >> with conditionals (or any other things) for unsupported/unrelated >> distros just create problems. > I won't argue about this particular case. RHEL4/5 is indeed pretty old > and I wouldn't mind dropping support for it. > > But in general I like it when my spec files "my spec files" - this is the main issue. All the conditionals are fine as long as the .spec files are really yours. During Ruby mass rebuilds, I have to deal with quite some packages which are not my and they even might be more or less abandoned. In this case the conditionals are troublesome, because I want to fix Rawhide, possibly rebase the package, but I don't really want to test if I break the package on other places (especially since EPEL packages might be created once and then never updated on purpose). Vít > just work for building > packages across Fedora/RHEL/SoftwareCollections even if that requires a > few conditionals. For example I maintain valgrind and have it setup so > that I can use the same spec file to build for "regular" Fedora, but > also do a copr build for older Fedora or CentOS [1]. And the same spec > file can be used to build the Developer Toolset software collection. It > makes sure that there is a way to get the latest upstream (and > backports) make it to different users. Which, in my experience, creates > a better package for everybody since bug fixes are shared. > > Cheers, > > Mark > > [1] > https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-and-centos/ > ___ > 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: coreutils /bin file dependencies
On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: > On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > > On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: > > > For the record, there appear to be only 25 binary packages that > > > depend on /bin coreutils paths[1]; > > > > I just took a quick look at the systemtap package. It has: > > > > # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer > > # distributions, /bin/mktemp comes from the 'coreutils' package. To > > # avoid a specific RHEL[45] Requires, we'll do a file-based require. > > Requires: /bin/mktemp > > > > On RHEL5 the mktemp package only provides a /bin/mktemp and > > no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be > > changed for Fedora of course. But it might be that there are other > > packages that share a spec file between RHEL and Fedora and have a > > /bin > > instead of /usr/bin Requires for this reason. > RHEL[45] is dead, so feel free to drop this. Also polluting spec file > with conditionals (or any other things) for unsupported/unrelated > distros just create problems. I won't argue about this particular case. RHEL4/5 is indeed pretty old and I wouldn't mind dropping support for it. But in general I like it when my spec files just work for building packages across Fedora/RHEL/SoftwareCollections even if that requires a few conditionals. For example I maintain valgrind and have it setup so that I can use the same spec file to build for "regular" Fedora, but also do a copr build for older Fedora or CentOS [1]. And the same spec file can be used to build the Developer Toolset software collection. It makes sure that there is a way to get the latest upstream (and backports) make it to different users. Which, in my experience, creates a better package for everybody since bug fixes are shared. Cheers, Mark [1] https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-and-centos/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
Dne 22.6.2017 v 17:15 Petr Šabata napsal(a): > 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]; What is the source of this /bin dependencies? Are they autogenerated or maintainers are using R: /bin/someutil (where they should be using %{_bindir}/someutil)? Vít > 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 > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > On Thu, 2017-06-22 at 17:15 +0200, 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]; > > I just took a quick look at the systemtap package. It has: > > # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer > # distributions, /bin/mktemp comes from the 'coreutils' package. To > # avoid a specific RHEL[45] Requires, we'll do a file-based require. > Requires: /bin/mktemp > > On RHEL5 the mktemp package only provides a /bin/mktemp and > no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be > changed for Fedora of course. But it might be that there are other > packages that share a spec file between RHEL and Fedora and have a > /bin > instead of /usr/bin Requires for this reason. RHEL[45] is dead, so feel free to drop this. Also polluting spec file with conditionals (or any other things) for unsupported/unrelated distros just create problems. > > Cheers, > > Mark > > > [1] https://paste.fedoraproject.org/paste/v-SDa5byzWT93OKPWZ~XKQ/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllMzUgACgkQaVcUvRu8 X0yBNw//ZFIdWFuxY3vqQ5dsR30z6sQW1WYpV8tD9IqY1JwD+SVIYlCr0xXFnV3d K2f4a5ix2nqGMLrFharz9n3KqQk7oOSuS/YgPUtywJPmupaYCtPA7LohYqf6uDgI YhDYDhy1qcYgqTVm2twoG17v6HkO+qu4AQDl5AeHG5Tz/NvIhDyiZH9CFXf2JT+G BevsvxllMxOo5H00ohykpIVakc5JKPWSulNsr6jYm5MDQ5qnxDR3tXAB+K3KZj3z VHvVq0Rpakwcqc4gtJI3/iJhSiHxbNgF1b5nz9hK7Wx059Sd+8hMNRMwkUXN4F7u Gf99qWfrgj4L0yUym0tKLFafiBLAzX1lRsAMVwtygSGokNhzMwV34bUR5WcO7wFf cdM8k1LFA8axToBYQfog2z6DJo5jXk95EMoJXZ04Rm98x2U/bLszJVrF/xZRGnQ7 SwgKzPRrS2WTQ3EPuJElPMfvarTJKjrV9pHP2+oMcVZvhFZs5hh2fMSVmRH+IcYa brEmOJ+GiuAUWvg4gZi3e7Pdtf+FPrZl5uZJDPLXWxkNa2IPE4ficQDAufnxp/1l h2PWvaSTbI2UHALIaA5NY9mWAlKPu8GjdF1Tavgzfw6qCjEXcw0IlCSnE06a5+uk zf5GDvz0fGY76sVaDhj43KPDSGHPfJJO9CA8u9hdRFF0k6blX3M= =92b2 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 Self Contained Change: Remove krb5-appl
= Proposed Self Contained Change: Remove krb5-appl = https://fedoraproject.org/wiki/Changes/Remove_krb5-appl Change owner(s): * Robbie Harwood (rharwood) Remove src:krb5-appl (produces packages krb5-appl-clients and krb5-appl-servers) from the distribution. == Detailed Description == 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. == Scope == * Proposal owners: To implement this Change proposal. * Other developers: N/A (not a System Wide Change) * Release engineering: https://pagure.io/releng/issue/6854 * 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) -- 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
Re: coreutils /bin file dependencies
On Thu, 2017-06-22 at 17:15 +0200, 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]; I just took a quick look at the systemtap package. It has: # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer # distributions, /bin/mktemp comes from the 'coreutils' package. To # avoid a specific RHEL[45] Requires, we'll do a file-based require. Requires: /bin/mktemp On RHEL5 the mktemp package only provides a /bin/mktemp and no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be changed for Fedora of course. But it might be that there are other packages that share a spec file between RHEL and Fedora and have a /bin instead of /usr/bin Requires for this reason. Cheers, Mark > [1] https://paste.fedoraproject.org/paste/v-SDa5byzWT93OKPWZ~XKQ/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org