Fedora Modules & Fedora 27 Server Edition (Changes)
OVERVIEW As the modularity work starts to enter Fedora with the Fedora 27 release, a typical Change Proposal did not seem to do justice on capturing the moving parts and dependencies for the work to successfully land. As a result, this document attempts to capture, at a high level, the goals and deliverables for F27. We are also providing links to the details to most aspects. Some of the details are still in progress and will change over the F26 lifecycle (e.g. which modules will be included for F27 Server). THE GOAL The Modularity and Server Working Groups plan, with the help of many other groups in Fedora, to deliver a fully modularized version of the Fedora Server Edition. As an equal and complementary goal, the tooling for module creation/development, deployment and automatic testing will be as simple and automated as possible. [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server) CAVEATS === - Although modularity allows for lifecycle changes, there is no plan for anything besides the normal 13 month lifecycle at this point. - Available content as modules will be less than a typical Server release - Only components that are a part of a module will be available - Any RPM that is a part of module will be available to be installed directly or in addition to the “install profile” install of the module ASPECTS TRACKED === - Infrastructure Changes/Improvements: - Bodhi: changes to support updating & tracking modules: [*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease) - Arbitrary branching: enables modules to versions bound to something other than Fedora release number: [*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching) - Bugzilla & ABRT module-awareness are still in progress - COPR: support for building modules has been added and will be improved over the F26 cycle - Automation (Freshmaker) - On Demand Compose Service (for testing and container rebuilds) - Greenwave: for policy/gating in Bodhi. User interactions take place in Bodhi. - Installation & System Management - Anaconda: still in progress - DNF: Work underway to support modules, additional features need to be added. Please report comments/features/bugs in the [*normal manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting). - Gnome Software: still in progress - Host & Platform module(s): Base components that provide the “operating system” aspects of Modular Fedora: [*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform), [*Content tracker*](https://github.com/fedora-modularity/hp) - Application modules ([*Content Tracking*](https://github.com/fedora-modularity/f27-content-tracking)): - TBD language modules (1 or more versions each) - TBD database modules (1 or more versions each) - TBD web server modules (1 or more versions each) - TBD utility server modules (1 or more versions each) - Applications as System Containers ([*Content Tracking*](https://github.com/fedora-modularity/f27-content-tracking)): - TBD system integrated containers - Module Guidelines and Processes: [*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123) - HowTos, Examples, and Tools for Modules: [*Website*](https://docs.pagure.org/modularity/) BENEFITS FOR USERS == - Content available in multiple streams - good examples needed - Software Collections done the right way - Languages, Databases - No visible change to dnf/yum unless you want to select non-default versions FURTHER DETAILS === - [*Bodhi Milestone*](https://github.com/fedora-infra/bodhi/milestone/4) for Modularity - Bodhi Changes [*Focus document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Bodhi) - Freshmaker Focus doc [*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker) - ODCS Focus doc [*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS) - Branching Focus doc [*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching) Langdon White Fedora Modularity Objective Lead ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Do we have any OCaml-written setuid binaries?
I'm fairly sure we don't have any setuid binaries written in OCaml. However I've no idea how we would go about mechanically checking this, hence why I'm asking here. OCaml 4.04.2 (23 Jun 2017): --- ### Security fix: - PR#7557: Local privilege escalation issue with ocaml binaries. (Damien Doligez, report by Eric Milliken, review by Xavier Leroy) CVE-2017-9772: Privilege escalation in OCaml runtime for SUID executables The environment variables CAML_CPLUGINS, CAML_NATIVE_CPLUGINS, and CAML_BYTE_CPLUGINS can be used to auto-load code into any ocamlopt-compiled executable or any ocamlc-compiled executable in ‘custom runtime mode’. This can lead to privilege escalation if the executable is marked setuid. Vulnerable versions: OCaml 4.04.0 and 4.04.1 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Retiring Packages with Broken Dependencies in branched (2017-06-26)
On Mon, Jun 26, 2017 at 07:02:25AM +, t...@fedoraproject.org wrote: > libguestfs (maintained by: rjones, agk, group::virtmaint-sig, mdbooth, > ptoscano) > libguestfs-1.36.4-1.fc26.src requires java-1.8.0-openjdk = > 1:1.8.0.131-5.b12.fc26, java-1.8.0-openjdk-devel = 1:1.8.0.131-5.b12.fc26 > libguestfs-java-1.36.4-1.fc26.i686 requires java-headless = > 1:1.8.0 So .. help us out here. Both java-headless and java-1.8.0-openjdk exist in Rawhide, with builds less than 2 weeks ago. 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: Retiring Packages with Broken Dependencies in branched (2017-06-26)
On Mon, Jun 26, 2017 at 8:56 AM, Richard W.M. Jones wrote: > On Mon, Jun 26, 2017 at 07:02:25AM +, t...@fedoraproject.org wrote: >> libguestfs (maintained by: rjones, agk, group::virtmaint-sig, mdbooth, >> ptoscano) >> libguestfs-1.36.4-1.fc26.src requires java-1.8.0-openjdk = >> 1:1.8.0.131-5.b12.fc26, java-1.8.0-openjdk-devel = 1:1.8.0.131-5.b12.fc26 >> libguestfs-java-1.36.4-1.fc26.i686 requires java-headless = >> 1:1.8.0 > > So .. help us out here. Both java-headless and java-1.8.0-openjdk > exist in Rawhide, with builds less than 2 weeks ago. I think it might be an explicit = in the version requires? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
orphaning proguard
Hi! I'm looking for new maintainers for proguard which I don't use myself anymore and for which I'm not the best maintainer! proguard https://admin.fedoraproject.org/pkgdb/package/rpms/proguard/ I just orphaned the package, feel free to take it! It will require some work as it does not currently build. Cheers, François ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Proposal to CANCEL: 2017-06-26 Fedora QA Meeting
Where is the the Blocker review meeting? Cheers, Sylvia On Sun, 2017-06-25 at 17:28 -0700, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting tomorrow. > There's nothing in particular to discuss at a meeting right now, so > far > as I know. If you're aware of anything, please do reply to this mail > and we can go ahead and run the meeting. > > We do have the blocker review meeting at 1600 UTC, so see you there! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . > net > http://www.happyassassin.net > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to test-announce-leave@lists.fedoraproje > ct.org > ___ > 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: Retiring Packages with Broken Dependencies in branched (2017-06-26)
On Mon, Jun 26, 2017 at 09:09:15AM +0100, Peter Robinson wrote: > On Mon, Jun 26, 2017 at 8:56 AM, Richard W.M. Jones wrote: > > On Mon, Jun 26, 2017 at 07:02:25AM +, t...@fedoraproject.org wrote: > >> libguestfs (maintained by: rjones, agk, group::virtmaint-sig, > >> mdbooth, ptoscano) > >> libguestfs-1.36.4-1.fc26.src requires java-1.8.0-openjdk = > >> 1:1.8.0.131-5.b12.fc26, java-1.8.0-openjdk-devel = 1:1.8.0.131-5.b12.fc26 > >> libguestfs-java-1.36.4-1.fc26.i686 requires java-headless = > >> 1:1.8.0 > > > > So .. help us out here. Both java-headless and java-1.8.0-openjdk > > exist in Rawhide, with builds less than 2 weeks ago. > > I think it might be an explicit = in the version requires? For runtime requires we only use: Requires: java-headless >= 1.5.0 The other requires quoted above are BuildRequires (see ‘.fc26.src’). In the spec file we have: BuildRequires: java-1.8.0-openjdk BuildRequires: java-1.8.0-openjdk-devel That seems to be the latest version of the JDK AFAICT. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
jplesnik pushed to perl-App-cpm (master). "0.900 bump"
From e4f5e2142bff0b1807654df42e400219c5f0ca3c Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: Mon, 26 Jun 2017 10:51:58 +0200
Subject: 0.900 bump
---
.gitignore| 1 +
perl-App-cpm.spec | 9 -
sources | 2 +-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 919a3fa..d4c2bb6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@
/App-cpm-0.302.tar.gz
/App-cpm-0.304.tar.gz
/App-cpm-0.350.tar.gz
+/App-cpm-0.900.tar.gz
diff --git a/perl-App-cpm.spec b/perl-App-cpm.spec
index ab4bc0f..ff06ff9 100644
--- a/perl-App-cpm.spec
+++ b/perl-App-cpm.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpm
-Version:0.350
+Version:0.900
Release:1%{?dist}
Summary:Fast CPAN module installer
License:GPL+ or Artistic
@@ -25,6 +25,9 @@ BuildRequires: perl(CPAN::Meta)
BuildRequires: perl(CPAN::Meta::Requirements)
BuildRequires: perl(CPAN::Meta::YAML)
BuildRequires: perl(Cwd)
+BuildRequires: perl(Digest::MD5)
+BuildRequires: perl(ExtUtils::Install)
+BuildRequires: perl(ExtUtils::InstallPaths)
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Copy::Recursive)
@@ -35,6 +38,7 @@ BuildRequires: perl(File::Temp)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(HTTP::Tiny) >= 0.055
# BuildRequires: perl(HTTP::Tinyish) >= 0.12
+BuildRequires: perl(IO::Handle)
# BuildRequires: perl(IO::Uncompress::Gunzip)
BuildRequires: perl(JSON::PP) >= 2.27300
BuildRequires: perl(List::Util)
@@ -92,6 +96,9 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Mon Jun 26 2017 Jitka Plesnikova - 0.900-1
+- 0.900 bump
+
* Mon Jun 12 2017 Jitka Plesnikova - 0.350-1
- 0.350 bump
diff --git a/sources b/sources
index 5b3dbcb..7df1296 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (App-cpm-0.350.tar.gz) =
eb101e7c7960e27d0e3b4cb1d457be8bbca46f7adbfde5d0bc51ca5edf94b2cef59409d242a9bf769d43c21095c0decaad2c1acae5b297b4d87a579fca5e
+SHA512 (App-cpm-0.900.tar.gz) =
3518c1b6a0b9e968baafc402e6f99c93d1f4d40dde3f4a5c01b6dda70a7e68db55570f7fc28aa6db19f42889ace813ef159fbd1bcc0f23d00ea700bf7cbfeabf
--
cgit v1.1
https://src.fedoraproject.org/cgit/perl-App-cpm.git/commit/?h=master&id=e4f5e2142bff0b1807654df42e400219c5f0ca3c
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
On Fri, Jun 23, 2017 at 10:40:25AM +0200, Vít Ondruch wrote:
>
>
> 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
My first and incorrect query revealed hundreds of packages
which made me think it was probably generated. Kamil pointed
out that were it the case, we could just fix the generator.
But given the actual number of packages is this low, they were
probably explicitly added by their maintainers. The few I
checked were like that, at least.
P
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Retiring Packages with Broken Dependencies in branched (2017-06-26)
Am 26.06.2017 um 09:02 schrieb t...@fedoraproject.org: htmlcleaner (maintained by: marcindulak, besser82, java-sig) htmlcleaner-2.2.1-6.fc21.noarch requires java-headless = 1:1.8.0 htmlcleaner-2.2.1-6.fc21.src requires java-devel = 1:1.8.0 htmlcleaner has been fixed and built [1] on all recent releases including Rawhide. Those successful builds have been submitted to updates-testing [2] recently. [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=16448 [2] https://bodhi.fedoraproject.org/updates/?packages=htmlcleaner ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
Dne 26.6.2017 v 11:56 Petr Šabata napsal(a):
> On Fri, Jun 23, 2017 at 10:40:25AM +0200, Vít Ondruch wrote:
>>
>> 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
> My first and incorrect query revealed hundreds of packages
> which made me think it was probably generated. Kamil pointed
> out that were it the case, we could just fix the generator.
>
> But given the actual number of packages is this low, they were
> probably explicitly added by their maintainers. The few I
> checked were like that, at least.
The fixing the generator and option (a) for the rest should be the way
forward IMO.
Vít
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: Retiring Packages with Broken Dependencies in branched (2017-06-26)
On Mon, Jun 26, 2017 at 08:56:20AM +0100, Richard W.M. Jones wrote: > On Mon, Jun 26, 2017 at 07:02:25AM +, t...@fedoraproject.org wrote: > > libguestfs (maintained by: rjones, agk, group::virtmaint-sig, mdbooth, > > ptoscano) > > libguestfs-1.36.4-1.fc26.src requires java-1.8.0-openjdk = > > 1:1.8.0.131-5.b12.fc26, java-1.8.0-openjdk-devel = 1:1.8.0.131-5.b12.fc26 > > libguestfs-java-1.36.4-1.fc26.i686 requires java-headless = > > 1:1.8.0 > > So .. help us out here. Both java-headless and java-1.8.0-openjdk > exist in Rawhide, with builds less than 2 weeks ago. According to https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NR6YEE577F5N22S6BII53LC5LIWFQMJZ/ the subpackage java-1.8.0-openjdk-openjfx has a broken dependency on openjfx. An update to fix this is currently pushed to stable so it should be all fine afaics: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e898ddd8ca ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer process for caillon, and retiring xchat
On Wed, Jun 14, 2017 at 03:19:52PM +, Debarshi Ray wrote: > I would like to initiate the non-responsive maintainer process [1] for > Christopher Aillon [2]. A long time ago, he used to be part of the > Fedora and Red Hat desktop teams. He is no longer around. He left > software development and was last seen living off the grid in Hawaii > [3]. Therefore I have jumped straight to the fourth step in the > aforementioned process. > > Here is a list of his packages: > https://admin.fedoraproject.org/pkgdb/packager/caillon/ > > I am particularly interested in xchat, which I want to retire right > after removing Chris as the point of contact for his packages. Filed: https://pagure.io/fesco/issue/1721 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: Modular Release
= Proposed System Wide Change: Modular Release = https://fedoraproject.org/wiki/Changes/ModularRelease Change owner(s): * Ralph Bean < rbean AT redhat DOT com > The build, release, distribution, and update changes associated with and required for the [Changes/Modular_Server] and [Changes/Host_and_Platform] Changes. == Detailed Description == === Preamble === This change is intended to cover the workflow and technical tooling aspects of a “modular” release for F27. There are other Changes that are not part of the scope of this Change, but which are related: * [[Changes/Modular_Server]] is a proposal to replace the Fedora Server edition with a modular release for F27. * [[Changes/Host_and_Platform]] deals with the content of what goes into the core of the modular release for Fedora Server (the Modular Server) in F27. This Change is about how we’re going to get those two other changes through the infra/build/release tooling. Client tooling is being worked on (I have seen some cool demos from the May-June timeframe. Ask about them!), but client tooling is not part of the scope of this Change proposal. Note that there currently are no proposals to replace either Fedora Workstation or Fedora Atomic with modular revisions. This means that here we cannot move to replace existing workflows wholesale, but have to look at maintaining the two flows (traditional and modular) in tandem, for at very least the F27 release cycle. (The [[Changes/ArbitraryBranching]] change is also related to this proposal, but not covered in any further detail here.) === Builds === Module builds for the F27 cycle will look much like they did for the F26 cycle. No major changes here. See the F26 Change document for details here, [[Changes/ModuleBuildService]] As soon as the FPC approves the [[Module:Guidelines]], we can open up the MBS for use by the general packager group. '''Dependencies:''' * We need the Modularity team to take the module guidelines to the FPC, work through them, and get an agreed-upon version approved. * We are indirectly dependent on release engineering to create some initial tags for bootstrapping the host and platform content. This should be referenced in that Change proposal. === Automation === Ok, I lied. One thing about builds will change: we’re going to automate rebuilds with [[Infrastructure/Factory2/Focus/Freshmaker]]. Module Rebuilds For '''F26''', if a packager wanted to update an rpm in a module, they would: * Patch the spec file of that rpm, commit, and push. * Switch to a checkout of the module that included that rpm, and run `mbs-build submit` which would kick off the appropriate builds. * If another module included that same rpm stream, and the packager forgot about it, then they’re just out of luck. For '''F27''', we’re working on a system to automate this. The workflow will be: * Patch the spec file of an rpm, commit, and push. * Watch the fireworks. The freshmaker daemon will notice the commit, then look up all modules that depend on that rpm stream. It will submit requests to the module-build-service to build those modules. We won’t have a nice UI for this for F27, but we will have a JSON API provided by freshmaker to query and find the list of module builds that were triggered as a result of your commit (or anyone else’s commits to any other packages). There are some exceptions here. We will have a site-wide policy configured for freshmaker to not do automated rebuilds for a blacklisted set of modules. This blacklist set must include the bootstrap module. It includes many thousands of rpm streams and an update to any one of them would cause a mass-rebuild of (nearly) every other module. This is too much, so we’ll instead rely on the bootstrap maintainers and release engineering to only request these rebuilds via MBS by hand. Container Rebuilds We're approaching container rebuilds in two phases: for short hand, we're calling them the "slow" flow and the "fast" flow. We'll do the [https://m.rit.edu/default/video/index?feed=youtube-reporter&id=QPHUTRnWrP4 slow flow] first for F27. The fast flow is a stretch goal for F27, but will more likely land in F28. In the '''slow flow''', we automatically kick off rebuilds of containers when rpms that previously went into those containers are '''shipped to the updates repo in Bodhi'''. The lag time here can be around a week to two weeks. Freshmaker will watch on fedmsg to find when those rpms make it to the master mirror and will kick off the appropriate builds. The container rebuild process should already be pulling from that repo; so we should be good to go. In the '''fast flow''', we automatically kick off rebuilds of containers when rpms that previously went into those containers are '''first added to an update in Bodhi'''. The lag time here can be quite fast. As soon as you make a specfile patch and the rpms get built, the update can be created which in turns triggers freshmaker to kick off containe
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Sun, Jun 25, 2017 at 01:44:43PM -0400, langdon wrote: > - Although modularity allows for lifecycle changes, there is no > plan for anything besides the normal 13 month lifecycle at this > point. So, this basically gives until November 2018 to figure out a way to handle longer lifecycles. :) > - Available content as modules will be less than a typical Server release > - Only components that are a part of a module will be available > - Any RPM that is a part of module will be available to be > installed directly or in addition to the “install profile” install > of the module Hmmm, so, if I want some random utility (let's say gcal, which I don't package, or calc, which I do) on my server, what are my options? Can I enable all general Fedora content in some way? Or do I need to make modules for each of these things or convince someone else to? Or is the expectation that such stuff would go into a container (which would draw from all of Fedora RPM content)? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
rpm debuginfo improvements for rawhide/f27
Hi packagers,
rawhide rpmbuild contains various debuginfo improvements that hopefully
will make various hacks in spec files redundant.
If you have your own way of handling debuginfo packages, calling
find-debuginfo.sh directly, need hacks for working around debugedit
limitations or split your debuginfo package by hand then please try out
rpmbuild in rawhide and read below for some macros you can set to tweak
debuginfo package generation.
If you still need hacks in your spec file because setting macros isn't
enough to get the debuginfo packages you want then please let us know.
Also please let us know about packages that need to set debuginfo rpm
macros to non-default values because they would crash and burn with the
default settings (best to file a bug against rpmbuild).
The improvements have been mainly driven by the following two change
proposals for f27 (some inspired by what other distros do):
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
The first is completely done and has been enabled by default for some
months now in rawhide. The second introduces two new macros to enable
separate debugsource and sub-debuginfo packages, but has not been
enabled by default yet. If people like the change and no bugs are found
(and fesco and releng agree) we can enable them for the f27 mass
rebuild.
If your package already splits debuginfo packages in a (common) source
package and/or sub-debuginfo packages, please try out the new macros
introduced by the second change. You can enable the standard splitting
by adding the following to your spec file:
%global _debugsource_packages 1
%global _debuginfo_subpackages 1
Besides the above two changes debuginfo packages can now (and are by
default in rawhide) build by running debug extraction in parallel. This
should speed up building with lots of binaries/libraries. If you do
invoke find-debuginfo.sh by hand you most likely will want to add
%{?_smp_mflags} as argument to get the parallel processing speedup.
If your package is invoking find-debuginfo.sh by hand also please take a
look at all the new options that have been added. Also note that almost
all options can be changed by setting (or undefining) rpm macros now.
Using the rpm macros is preferred over invoking find-debuginfo.sh
directly since it means you get any defaults and improvements that might
need new find-debuginfo.sh arguments automatically.
Here is an overview of various debuginfo rpm macros that you can define
undefine in your spec file with the latest rpmbuild:
#
# Should an ELF file processed by find-debuginfo.sh having no build ID
# terminate a build? This is left undefined to disable it and defined to
# enable.
#
%_missing_build_ids_terminate_build1
#
# Include minimal debug information in build binaries.
# Requires _enable_debug_packages.
#
%_include_minidebuginfo1
#
# Include a .gdb_index section in the .debug files.
# Requires _enable_debug_packages and gdb-add-index installed.
#
%_include_gdb_index1
#
# Defines how and if build_id links are generated for ELF files.
# The following settings are supported:
#
# - none
# No build_id links are generated.
#
# - alldebug
# build_id links are generated only when the __debug_package global is
# defined. This will generate build_id links in the -debuginfo package
# for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
# the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
# This is the old style build_id links as generated by the original
# find-debuginfo.sh script.
#
# - separate
# build_id links are generate for all binary packages. If this is a
# main package (the __debug_package global isn't set) then the
# build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
# a -debuginfo package (the __debug_package global is set) then the
# build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
#
# - compat
# Same as for "separate" but if the __debug_package global is set then
# the -debuginfo package will have a compatibility link for the main
# ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
%_build_id_links compat
# Whether build-ids should be made unique between package version/releases
# when generating debuginfo packages. If set to 1 this will pass
# --build-id-seed "%{VERSION}-%{RELEASE}" to find-debuginfo.sh which will
# pass it onto debugedit --build-id-seed to be used to prime the build-id
# note hash.
%_unique_build_ids 1
# Do not recompute build-ids but keep whatever is in the ELF file already.
# Cannot be used together with _unique_build_ids (which forces recomputation).
# Defaults to undefined (unset).
#%_no_recompute_build_ids 1
# Whether .debug files should be made unique between package version,
# release and architecture. If set to 1 this will pass
# --unique-debug-suffix "-%{VERSION}-%{RELEASE}.%{_arch} find-debuginfo.sh
# to create debugi
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 09:42:39AM -0400, Matthew Miller wrote: > On Sun, Jun 25, 2017 at 01:44:43PM -0400, langdon wrote: > > - Although modularity allows for lifecycle changes, there is no > > plan for anything besides the normal 13 month lifecycle at this > > point. > > So, this basically gives until November 2018 to figure out a way to > handle longer lifecycles. :) > > > > - Available content as modules will be less than a typical Server release > > - Only components that are a part of a module will be available > > - Any RPM that is a part of module will be available to be > > installed directly or in addition to the “install profile” install > > of the module > > Hmmm, so, if I want some random utility (let's say gcal, which I don't > package, or calc, which I do) on my server, what are my options? Can I > enable all general Fedora content in some way? Or do I need to make > modules for each of these things or convince someone else to? Or is the > expectation that such stuff would go into a container (which would draw > from all of Fedora RPM content)? The modular release is effectively a separate distro. While using single RPMs from traditional Fedora might work in most cases, I wouldn't recommend enabling the entire repository which also provides packages conflicting with (and possibly updating) those provided by modules. Creating logical modules would be the best approach here. Containers are also an option but someone needs to make them, too. P signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Retiring Packages with Broken Dependencies in branched (2017-06-26)
On 26.06.2017 09:02, t...@fedoraproject.org wrote: qgis volter, bruno, daveisfera, 162 weeks ago orion, rezso I've launched new qgis builds for rawhide and f26 disabling parallel build as a quick workaround for the build failure. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Proposal to CANCEL: 2017-06-26 Fedora QA Meeting
On Mon, Jun 26, 2017 at 10:26 AM, Silvia Sanchez wrote: > > Where is the the Blocker review meeting? > See the *other* email in test-announce :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 04:06:18PM +0200, Petr Šabata wrote: > > Hmmm, so, if I want some random utility (let's say gcal, which I don't > > package, or calc, which I do) on my server, what are my options? Can I [...] > The modular release is effectively a separate distro. > > While using single RPMs from traditional Fedora might work in > most cases, I wouldn't recommend enabling the entire repository > which also provides packages conflicting with (and possibly > updating) those provided by modules. > > Creating logical modules would be the best approach here. > Containers are also an option but someone needs to make them, too. So, would a "Random Command-Line Tools" module make sense? Sort of like the old "system-tools" comps group? That's a grab bag of stuff like screen, setserial, nmap, xdelta, htop, and a whole bunch more. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 4:49 PM, Matthew Miller wrote: > On Mon, Jun 26, 2017 at 04:06:18PM +0200, Petr Šabata wrote: >> > Hmmm, so, if I want some random utility (let's say gcal, which I don't >> > package, or calc, which I do) on my server, what are my options? Can I > [...] >> The modular release is effectively a separate distro. >> >> While using single RPMs from traditional Fedora might work in >> most cases, I wouldn't recommend enabling the entire repository >> which also provides packages conflicting with (and possibly >> updating) those provided by modules. >> >> Creating logical modules would be the best approach here. >> Containers are also an option but someone needs to make them, too. > > So, would a "Random Command-Line Tools" module make sense? Sort of like > the old "system-tools" comps group? That's a grab bag of stuff like > screen, setserial, nmap, xdelta, htop, and a whole bunch more. How do you come to a consensus on what people believe are must have/critical "Random Command-Line Tools" that "make sense"? I suspect everyone will have a differing opinion there. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: Host and Platform
= Proposed System Wide Change: Host and Platform = https://fedoraproject.org/wiki/Changes/Host_and_Platform Change owner(s): * Petr Šabata Host and Platform is an evolution of the Base Runtime module concept introduced in Fedora 26 Boltron, splitting the minimal system further into independent modules allowing for greater flexibility when composing and maintaining the base system. This change focuses on modular content structure; [[Changes/ModularRelease]] [ https://fedoraproject.org/wiki/Changes/ModularRelease ] deals with details regarding modular delivery. == Detailed Description == The end goal of this change is to provide the modular base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts. Being the successors of Base Runtime, the two new modules will include all the content Base Runtime does as well as content from additional Fedora 26 Boltron modules currently extending it. Additional system configuration & management services and utilities are expected to be part of the base system experience, making all the essential content available for installation from the base level modules that are enabled by default. === Implementation === The concept is defined by the following set of objectives and expectations: * Host and Platform are built and composed as modules, benefiting from all the modularity pipeline enhancements Factory 2.0 provides and are distributed with useful module metadata * The Host part should deliver hardware enablement components such as the kernel, bootloaders, firmware, possibly additional device drivers and components closely linked to these * The Platform part defines the operating system release and includes various base userspace components ranging from the C library and init system to system management & deployment tools, container runtime and possibly several services commonly considered to be part of the base system experience * The Host and Platform modules should be independent, making it possible to run the same Host with different Platforms and vice versa * Each of the two modules has its own life cycle, update cadence and versioning scheme * The Host can only be experienced through the Platform * The Platform part provides all the content needed to produce container base images; the Platform can therefore run without the Host in that scenario * Both modules are built in a shared, self-hosting buildroot (also known as the Bootstrap module) providing all the build time dependencies needed to build the Host and Platform as well as itself * While independent on the source level, given the shared build environment the modules' binaries are tightly coupled and the Host part therefore needs to be built for every supported Platform it's intended to be distributed with * The Platform module provides the minimal build environment for application level modules -- this means that modules built against a certain version of Platform are built using the Platform compiler; this doesn't affect what additional compilers are available to the end users, for example via additional application level modules === Modules === At minimum the group is going to deliver three modules, one of which being an implementation detail only that won't be part of the Host and Platform compose. * '''The Host''' includes the kernel, bootloaders, firmware, and components tightly coupled with any of these * '''The Platform''' includes the C standard library, the init system, basic system tools, filesystem and networking utilities, system Python runtime, system management and deployment tools such as dnf and anaconda, container runtime(s) and possibly additional system services and components necessary to provide a reasonable base system environment * '''The Bootstrap''' module includes a self-hosting package set needed to build the Host and Platform modules. Host and Platform are subsets of this module. The binaries are not part of the compose. This module is also part of Fedora 26 Boltron, defining the buildroot for Base Runtime and several other modules. Host and Platform modules might be implemented as simple modules or module stacks, depending on what provides more practical value. Given that the content of each will be bound by the same life cycle and update cadence, we don't expect to split them into sub-units unless necessary. The Host module might be a module stack from day one to simplify packaging of the UEFI bootloader. The Bootstrap module will be initially created by manually tagging traditional Fedora binaries into a special purpose, module-like tag. The module is self-hosting so that it can later rebuild itself, as well as serve as a base for building future releases, spins, and derived distributions. Unfortunately it's not possible to build the new Bootstrap module using the Fedora 26 Boltron version due to the introduction of a new architecture (s39
F27 System Wide Change: Modular Server
= Proposed System Wide Change: Modular Server = https://fedoraproject.org/wiki/Changes/Modular_Server Change owner(s): * Langdon White The Modularity Working Group, Factory 2.0, Base Runtime, and Server Working Group would like to propose using the modular infrastructure for creating and delivering the Fedora Server Edition for Fedora 27. While we are still working through some of the kinks leading up to the release of Fedora 26, we believe that the changes to the infrastructure and technology implementations will be available with sufficient time to harden the components in time for the 27 release. == Detailed Description == The modularity effort is fairly well known and significantly more information may be found on the Modularity Website [ https://docs.pagure.org/modularity/ ] or the YouTube Channel [ https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ ]. In short, modularity is attempting to disconnect the lifecycle of applications from 1) each other 2) the operating system while still maintaining the ease of use of a typical Linux Distro. This change proposal is to promote the work done in the Boltron Release (preview container image in advance of the F26 release) to Fedora mainline through the Fedora Server Edition. We will also be working with the community to complete the available content for Fedora Server Edition as modules. Other edition and spins will not change at this point; users who want to create a Fedora server (as opposed to capital-S Fedora Server) without Modularity can use one of these other spins, including the Fedora Cloud Base image, or else use the "everything netinst". == Scope == * Proposal owners: The Modularity WG, Factory 2.0, Base Runtime, and Server WG teams all have contributions to this effort. The work that each team is doing is significant and wide ranging. We are hoping to: - collect and incorporate feedback in to the system management experience of using modules (through dnf) - modularize a significant amount of the content available for Fedora Server (focusing on current Server roles) - define tools and best practices for implementing modules and keeping them up to date * Other developers: - Packagers are already working on modularizing applications; - the Modularity WG will provide like to support additional package maintainers in modularizing their applications * Release engineering: See [[Changes/ModularRelease]] [ https://fedoraproject.org/wiki/Changes/ModularRelease ] [ https://pagure.io/releng/issue/6852 ] * List of deliverables: This change replaces the Fedora 26 Server release-blocking deliverables with exactly the same things (DVDs and netinst images) but delivered via Modularity instead of the traditional process. Although we want to enable changes to module lifecycles over time, it is worth noting that this Change Proposal does NOT change the normal 13 month commitment for anything in the release. * Policies and guidelines: New guidelines are required, they are currently in Draft state and we will be collecting feedback to them during the F26 lifecycle for ratification prior to F27. - Fedora_Packaging_Guidelines_for_Modules [ https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules ] - Container:Guidelines [ https://fedoraproject.org/wiki/Container:Guidelines ] At this point there are no changes expected to existing guidelines * 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: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata wrote: > > The modular release is effectively a separate distro. > > While using single RPMs from traditional Fedora might work in > most cases, I wouldn't recommend enabling the entire repository > which also provides packages conflicting with (and possibly > updating) those provided by modules. > > Creating logical modules would be the best approach here. > Containers are also an option but someone needs to make them, too. > > P Perhaps I'm confused or have outdated information, but I thought I recalled reading plans to (at least initially) potentially throw all non-already-module'd packages into something like an "Everything" module so it continued to be installable? And then gradually migrate things out from it into modules. It seems like doing so would solve this problem. Many of the packages I maintain are essentially one-offs that I'm not convinced will ever belong in a specific module-- where would things like this end up? Ben Rosser ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 04:55:42PM +0100, Peter Robinson wrote: > >> Creating logical modules would be the best approach here. > >> Containers are also an option but someone needs to make them, too. > > So, would a "Random Command-Line Tools" module make sense? Sort of like > > the old "system-tools" comps group? That's a grab bag of stuff like > > screen, setserial, nmap, xdelta, htop, and a whole bunch more. > How do you come to a consensus on what people believe are must > have/critical "Random Command-Line Tools" that "make sense"? I suspect > everyone will have a differing opinion there. Absolutely; this module would contain these tools but not install them by default. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Planned Outage: fedora infrastructure cloud / copr reboots - 2017-06-26 21:00 UTC
There will be an outage starting at 2017-06-26 21:00 UTC, 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-26 21:00 UTC' Reason for outage: We will be applying updates and rebooting the fedorainfracloud. This will affect copr builds, frontend and backend as well as any other applications hosted in the cloud.fedoraproject.org or fedorainfracloud.org domains. Affected Services: copr: frontend, backend and builds. *.fedorainfracloud.org and cloud.fedoraproject.org development and test instances. fedora magazine (fedoramagazine.org) and community blog (communityblog.fedoraproject.org) Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6135 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: OpenPGP digital signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017, 12:06 Ben Rosser wrote: > On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata wrote: > > > > The modular release is effectively a separate distro. > > > > While using single RPMs from traditional Fedora might work in > > most cases, I wouldn't recommend enabling the entire repository > > which also provides packages conflicting with (and possibly > > updating) those provided by modules. > > > > Creating logical modules would be the best approach here. > > Containers are also an option but someone needs to make them, too. > > > > P > > Perhaps I'm confused or have outdated information, but I thought I > recalled reading plans to (at least initially) potentially throw all > non-already-module'd packages into something like an "Everything" > module so it continued to be installable? And then gradually migrate > things out from it into modules. > > It seems like doing so would solve this problem. > > Many of the packages I maintain are essentially one-offs that I'm not > convinced will ever belong in a specific module-- where would things > like this end up? > > Ben Rosser > We talked about this with the server wg and decided for F27 server we would try to avoid an "everything else" module and figure out how to solve this problem more nicely between now and release. We have multiple options here including : generating modules for everything, making an extra repo of stuff available, leaving non-modules out, and, finally, the everything else module. Definitely a recognized issue, but not sure we are decided on the answer (or answers). We would like the module guidelines to address the use cases with recommendations but it is tough to iron this out. Langdon ___ > 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: Directory permissions for games
Hans, can you check if the permissions in this spec file are correctly set, please? https://paste.fedoraproject.org/paste/5CP27jxdYtG9DY2FXO6X0A/raw Scratch builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=20188500 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On 06/26/2017 11:04 AM, Langdon White wrote: > We talked about this with the server wg and decided for F27 server we would > try to avoid an "everything else" module and figure out how to solve this > problem more nicely between now and release. We have multiple options here > including : generating modules for everything, making an extra repo of > stuff available, leaving non-modules out, and, finally, the everything else > module. So there is never going to be any mixing of modules and non modules? I would think another way to solve this issue might be to get dnf to prefer modules, but still operate on either rpms or modules, so if you ran 'dnf install tmux' it would look for a tmux module, if it finds it great, it uses that. If it doesn't then it looks for the rpm and uses that. Then if later you do 'dnf update' and there is now a tmux module it uninstalls the rpm and intalls the module, etc. > > Definitely a recognized issue, but not sure we are decided on the answer > (or answers). We would like the module guidelines to address the use cases > with recommendations but it is tough to iron this out. yeah, there definitely could be some complex interactions here, but I think it's important to have the ability to install local rpms or things that are not (yet) modularized. Unrelated question: We will still be making the server repo and netinstall so people can install the legacy server setup with rpms, right? kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20170626.n.0 compose check report
Missing expected images: Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 20/128 (x86_64), 2/18 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20170625.n.0): ID: 113193 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/113193 ID: 113212 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/113212 Old failures (same test failed in Rawhide-20170625.n.0): ID: 113182 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/113182 ID: 113183 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/113183 ID: 113184 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/113184 ID: 113204 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/113204 ID: 113207 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/113207 ID: 113208 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/113208 ID: 113210 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/113210 ID: 113211 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/113211 ID: 113215 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/113215 ID: 113221 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/113221 ID: 113223 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/113223 ID: 113225 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/113225 ID: 113226 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/113226 ID: 113233 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/113233 ID: 113235 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/113235 ID: 113236 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/113236 ID: 113240 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/113240 ID: 113241 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/113241 ID: 113242 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/113242 ID: 113297 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/113297 ID: 113318 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/113318 Soft failed openQA tests: 61/128 (x86_64), 13/18 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20170625.n.0): ID: 113171 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/113171 ID: 113270 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/113270 ID: 113271 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/113271 ID: 113273 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/113273 ID: 113274 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/113274 ID: 113275 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/113275 ID: 113276 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/113276 ID: 113277 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/113277 ID: 113279 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/113279 ID: 113280 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/113280 ID: 113281 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/113281 ID: 113296 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/113296 ID: 113311 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/113311 ID: 113313 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/113313 ID: 113314 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/113314 ID: 113315 Test: i386 universal install_blivet_software_raid
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 1:33 PM Kevin Fenzi wrote: > Unrelated question: We will still be making the server repo and > netinstall so people can install the legacy server setup with rpms, right? > > I don't know if we'll bother creating an actual Fedora Server netinstall, but we'll certainly still have the unbranded netinstall for the foreseeable future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote: > On 06/26/2017 11:04 AM, Langdon White wrote: > > > We talked about this with the server wg and decided for F27 server we would > > try to avoid an "everything else" module and figure out how to solve this > > problem more nicely between now and release. We have multiple options here > > including : generating modules for everything, making an extra repo of > > stuff available, leaving non-modules out, and, finally, the everything else > > module. > > So there is never going to be any mixing of modules and non modules? I > would think another way to solve this issue might be to get dnf to > prefer modules, but still operate on either rpms or modules, so if you > ran 'dnf install tmux' it would look for a tmux module, if it finds it > great, it uses that. If it doesn't then it looks for the rpm and uses that. > Then if later you do 'dnf update' and there is now a tmux module it > uninstalls the rpm and intalls the module, etc. This question is kinda like "so there is never going to be any mixing of Fedora and Mageia RPMs?". Module content is built separately and while the sources are often the same or close to what was used to build traditional composes, the modular content is not guaranteed to be 100% binary compatible. Enhancing dnf with a feature with a potential to unexpectedly explode users' systems doesn't sound like a reasonable thing to do. > > Definitely a recognized issue, but not sure we are decided on the answer > > (or answers). We would like the module guidelines to address the use cases > > with recommendations but it is tough to iron this out. > > yeah, there definitely could be some complex interactions here, but I > think it's important to have the ability to install local rpms or things > that are not (yet) modularized. That can be done. And if those local RPMs were built against the modular platform, even better. P > Unrelated question: We will still be making the server repo and > netinstall so people can install the legacy server setup with rpms, right? > > kevin > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On 06/26/2017 01:29 PM, Kevin Fenzi wrote: On 06/26/2017 11:04 AM, Langdon White wrote: We talked about this with the server wg and decided for F27 server we would try to avoid an "everything else" module and figure out how to solve this problem more nicely between now and release. We have multiple options here including : generating modules for everything, making an extra repo of stuff available, leaving non-modules out, and, finally, the everything else module. So there is never going to be any mixing of modules and non modules? I would think another way to solve this issue might be to get dnf to prefer modules, but still operate on either rpms or modules, so if you ran 'dnf install tmux' it would look for a tmux module, if it finds it great, it uses that. If it doesn't then it looks for the rpm and uses that. Then if later you do 'dnf update' and there is now a tmux module it uninstalls the rpm and intalls the module, etc. Essentially, this ^^ is exactly the plan. The DNF folks will have to weigh in on exactly how the priorities will work. I also would like to see some UX testing around your last point. As in, I am not sure the user gets what they expect if it replaces the tmux-rpm with the tmux-module without any hint. For example, even if we had an httpd module, mod_ssl may not be there in the default-install. However, it would still be available and we are trying to make it essentially "dnf install mod_ssl" (apologies if I am misremembering the exact package names) to add in that function. The modular aspect just indicates the stream the mod_ssl comes from, e.g. httpd 2.4 vs httpd 2.2. Apologies, but I was talking about "available in the Fedora Server repo". Specifically, we have a lofty goal that everything in that repo would have a module wrapped around it. We may not get there which triggers the choices above. Hopefully, that makes more sense. Langdon PS: the problems with communicating when you are very close to something for a long time. Definitely a recognized issue, but not sure we are decided on the answer (or answers). We would like the module guidelines to address the use cases with recommendations but it is tough to iron this out. yeah, there definitely could be some complex interactions here, but I think it's important to have the ability to install local rpms or things that are not (yet) modularized. Unrelated question: We will still be making the server repo and netinstall so people can install the legacy server setup with rpms, right? kevin ___ 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: Fedora Modules & Fedora 27 Server Edition (Changes)
On 26 June 2017 at 13:55, langdon wrote: > On 06/26/2017 01:29 PM, Kevin Fenzi wrote: >> >> On 06/26/2017 11:04 AM, Langdon White wrote: >> >>> We talked about this with the server wg and decided for F27 server we >>> would >>> try to avoid an "everything else" module and figure out how to solve this >>> problem more nicely between now and release. We have multiple options >>> here >>> including : generating modules for everything, making an extra repo of >>> stuff available, leaving non-modules out, and, finally, the everything >>> else >>> module. >> >> So there is never going to be any mixing of modules and non modules? I >> would think another way to solve this issue might be to get dnf to >> prefer modules, but still operate on either rpms or modules, so if you >> ran 'dnf install tmux' it would look for a tmux module, if it finds it >> great, it uses that. If it doesn't then it looks for the rpm and uses >> that. >> Then if later you do 'dnf update' and there is now a tmux module it >> uninstalls the rpm and intalls the module, etc. > > > Essentially, this ^^ is exactly the plan. The DNF folks will have to weigh > in on exactly how the priorities will work. I also would like to see some UX > testing around your last point. As in, I am not sure the user gets what they > expect if it replaces the tmux-rpm with the tmux-module without any hint. > Compared to the email from Petr Šabata that came out at the same time: Module content is built separately and while the sources are often the same or close to what was used to build traditional composes, the modular content is not guaranteed to be 100% binary compatible. === I am now even more confused.. are we even talking about the same things in these emails or different things with the same name? Because if there isn't 100% binary compatibility, I can't see how what you say above is possible. > Langdon > > PS: the problems with communicating when you are very close to something for > a long time. > Or that many people "see" how they are going to deliver the giant robot differently :) -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On 06/26/2017 01:44 PM, Petr Šabata wrote: On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote: On 06/26/2017 11:04 AM, Langdon White wrote: We talked about this with the server wg and decided for F27 server we would try to avoid an "everything else" module and figure out how to solve this problem more nicely between now and release. We have multiple options here including : generating modules for everything, making an extra repo of stuff available, leaving non-modules out, and, finally, the everything else module. So there is never going to be any mixing of modules and non modules? I would think another way to solve this issue might be to get dnf to prefer modules, but still operate on either rpms or modules, so if you ran 'dnf install tmux' it would look for a tmux module, if it finds it great, it uses that. If it doesn't then it looks for the rpm and uses that. Then if later you do 'dnf update' and there is now a tmux module it uninstalls the rpm and intalls the module, etc. This question is kinda like "so there is never going to be any mixing of Fedora and Mageia RPMs?". Module content is built separately and while the sources are often the same or close to what was used to build traditional composes, the modular content is not guaranteed to be 100% binary compatible. Petr, I think you are jumping to the worst case scenario version of this question. Specifically, that the "arbitrary rpms" in question here are coming from an arbitrary repo. Yes, your concerns are valid if we are adding in arbitrary stuff from arbitrary sources. However, like I said in my email which crossed in the ether, that doesn't mean we can't manipulate RPMs directly from DNF. We just don't want people pulling arbitrary rpms from non-modular sources. Enhancing dnf with a feature with a potential to unexpectedly explode users' systems doesn't sound like a reasonable thing to do. I think this is a matter of UX testing. If the tmux-rpm was silently replaced with the tmux-module it may be a good thing assuming it does what the user expects. I, personally, struggle with the "uninstall/reinstall" portion of this but if we could find a way to just add stream information without actually replacing the rpm, the user could just follow the "tmux-before-it-was-a-module" stream until they are ready to switch then be give the "real" module-stream options. Langdon Definitely a recognized issue, but not sure we are decided on the answer (or answers). We would like the module guidelines to address the use cases with recommendations but it is tough to iron this out. yeah, there definitely could be some complex interactions here, but I think it's important to have the ability to install local rpms or things that are not (yet) modularized. That can be done. And if those local RPMs were built against the modular platform, even better. P Unrelated question: We will still be making the server repo and netinstall so people can install the legacy server setup with rpms, right? kevin ___ 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote: > Apologies, but I was talking about "available in the Fedora Server > repo". Specifically, we have a lofty goal that everything in that > repo would have a module wrapped around it. We may not get there > which triggers the choices above. As Fedora stands today, of course, "the Fedora Server repo" means "all the stuff Fedora packages at all". At the extreme, even though we tell people that it's better to install Workstation or a desktop Spin if they want to add a GUI, you _can_ install GNOME or KDE on server. I don't think we need to support the extreme on Fedora Server (as an edition) in the future (although I think we should do what we can to allow community members to compose such a thing of their own if they want it). But, we should set a goal like 60% of packages which make sense in a server install available to modular server in F27, and 95% by F28. (Where those specific numbers are just made up.) That can be done by: - Every RPM that's not a library (or library-like) becomes a module. Like, basically everything in `dnf group info system-tools`, plus cowsay. - Lumping some of these tools logically into "network admin tools", "file archive/backup/sync", "benchmarking", or whatever. (This seems... hard to get right.) - Bigger split without real attempt to categorize, like "Random CLI tools" and "Random GUI tools" modules. - Gigantic "Everything Else!" module. - Allowing package installs from the unmodularized Fedora repository, and doing something fancy to avoid trouble. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25 backport dnf pretransaction done in dnf-1.1.10 & dnf-plugins-extras (example snapper.yp)
Hello Everyone,
I back ported the function pretransaction into dnf plugin from fedora 25,
because
I’ don’t wanna break the current system.
Source can be found at
https://copr.fedorainfracloud.org/coprs/andybe/BtrfsF25/
dnf-1.1.10-7.fc25.src.rpm
dnf-plugins-extras-0.0.12-6.fc25.src.rpm
0001-dnf-plugin-add-pretransaction.patch
diff --git a/dnf/base.py b/dnf/base.py
index eade03d..46e1e40 100644
--- a/dnf/base.py
+++ b/dnf/base.py
@@ -603,6 +603,8 @@ class Base(object):
for display_ in cb.displays:
display_.output = False
+self._plugins.run_pre_transaction()
+
logger.info(_('Running transaction'))
self._run_transaction(cb=cb)
timer()
diff --git a/dnf/plugin.py b/dnf/plugin.py
index c611cc3..0978db8 100644
--- a/dnf/plugin.py
+++ b/dnf/plugin.py
@@ -67,6 +67,9 @@ class Plugin(object):
def sack(self):
# :api
pass
+def pre_transaction(self):
+# :api
+pass
def transaction(self):
# :api
@@ -106,6 +109,7 @@ class Plugins(object):
run_sack = _caller('sack')
run_resolved = _caller('resolved')
+run_pre_transaction = _caller('pre_transaction')
run_transaction = _caller('transaction')
def unload(self):
diff --git a/doc/api_plugins.rst b/doc/api_plugins.rst
index e2e15ba..8845a3c 100644
--- a/doc/api_plugins.rst
+++ b/doc/api_plugins.rst
@@ -55,6 +55,10 @@ When DNF CLI runs it loads the plugins found in the paths
during the CLI's initi
Plugin can override this. This hook is called immediately after
:attr:`.Base.sack` is initialized with data from all the enabled repos.
+ .. method:: pre_transaction
+
+Plugin can override this. This hook is called just before transaction
execution. This means after a successful transaction test. RPMDB is locked
during that time.
+
.. method:: transaction
Plugin can override this. This hook is called immediately after a
successful transaction.
diff --git a/doc/api_vs_yum.rst b/doc/api_vs_yum.rst
index 65b6a35..7c421e6 100644
--- a/doc/api_vs_yum.rst
+++ b/doc/api_vs_yum.rst
@@ -37,7 +37,7 @@ Hook Number Yum hook DNF hook
``6````prereposetup``
``7````postreposetup`` ``sack``
``8````exclude````resolved``
-``9````preresolve``
+``9````preresolve`` ``pre_transaction
``10`` ``postresolve````resolved but no re-resolve``
``11`` ``pretrans``
``12`` ``postrans`` ``transaction``
dnf-plugins-extras-0.0.12
diff --git a/plugins/snapper.py b/plugins/snapper.py
index d0443b0..877be38 100644
--- a/plugins/snapper.py
+++ b/plugins/snapper.py
@@ -1,6 +1,7 @@
# creates snapshots via 'snapper'.
#
# Copyright (C) 2014 Igor Gnatenko
+# Copyright (C) 2017 Andreas Benzler
#
# This copyrighted material is made available to anyone wishing to use,
# modify, copy, or redistribute it subject to the terms and conditions of
@@ -31,17 +32,11 @@ class Snapper(dnf.Plugin):
def __init__(self, base, cli):
self.base = base
self.description = " ".join(sys.argv)
+self.snapper = None
+self.pre_id = None
-def transaction(self):
-if not len(self.base.transaction):
-return
-
-if dnfpluginsextras.is_erasing(self.base.transaction,
- "snapper"):
-return
try:
-bus = SystemBus()
-snapper = Interface(bus.get_object('org.opensuse.Snapper',
+self.snapper =
Interface(SystemBus().get_object('org.opensuse.Snapper',
'/org/opensuse/Snapper'),
dbus_interface='org.opensuse.Snapper')
except DBusException as e:
@@ -49,15 +44,37 @@ class Snapper(dnf.Plugin):
"snapper: " + _("connect to snapperd failed: %s"), e
)
return
+
+def pre_transaction(self):
+if not len(self.base.transaction):
+return
+
try:
+logger.debug("snapper:" + _("creating snapshot") + " (pre)"
+)
+self.pre_id = self.snapper.CreatePreSnapshot('root',
self.description, 'number', {})
logger.debug(
-"snapper: " + _("creating snapshot")
+"snapper: " + _("created snapshot %d"), self.pre_id
+)
+
+except DBusException as e:
+logger.critical(
+"snapper: " + _("creating snapshot failed: %s"), e
+)
+
+def transaction(self):
+if not len(self.base.transaction):
+return
+
+
+try:
+logger.debug("snapper:" + _("creating snapshot") + " (post)"
)
-snap = snapper.CreateSingleSnapshot("root", self.description,
-"number", {})
+post_id = self.snapper.
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 02:30:20PM -0400, Matthew Miller wrote: > That can be done by: [...] Ugh, got distracted and sent before really done. Are there other ways we're looking at? Which of these are the Modularity and Server WGs thinking? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-06-26 at 14:30 -0400, Matthew Miller wrote: > On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote: > > Apologies, but I was talking about "available in the Fedora Server > > repo". Specifically, we have a lofty goal that everything in that > > repo would have a module wrapped around it. We may not get there > > which triggers the choices above. > > As Fedora stands today, of course, "the Fedora Server repo" means > "all > the stuff Fedora packages at all". At the extreme, even though we > tell > people that it's better to install Workstation or a desktop Spin if > they want to add a GUI, you _can_ install GNOME or KDE on server. > > I don't think we need to support the extreme on Fedora Server (as an > edition) in the future (although I think we should do what we can to > allow community members to compose such a thing of their own if they > want it). But, we should set a goal like 60% of packages > which make sense in a server install available to modular server in > F27, and 95% by F28. (Where those specific numbers are just made up.) > > That can be done by: > > - Every RPM that's not a library (or library-like) becomes a > module. > Like, basically everything in `dnf group info system-tools`, plus > cowsay. > > - Lumping some of these tools logically into "network admin tools", > "file archive/backup/sync", "benchmarking", or whatever. (This > seems... hard to get right.) > > - Bigger split without real attempt to categorize, like "Random CLI > tools" and "Random GUI tools" modules. > > - Gigantic "Everything Else!" module. > > - Allowing package installs from the unmodularized Fedora > repository, > and doing something fancy to avoid trouble. This has been tried by AltLinux, they were using Group tag to organize packages into small repositories and after all they went back for one big repository because of cross-dependencies, questions where to put what and probably other problems. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllRYT8ACgkQaVcUvRu8 X0w6iA/9EeCA2B+I/NaLe+LIdr7gfAshyIsgIBJ6690QRmeqNNgv1RKkVuRfKEy8 NtEbp5NENAa9T5Z7PtcccDoWzkU14KMB/ECyzK5nkVd1La1DdDfpJSHpw8wTwD8+ P5setc4zkwxS0kEPA/Wxp1tw71VBhoHLFBcKBYd3/CW8/E7e/wcqfNW1hhHww1XD lMgBL0ISJynBuJuzRt2y0A9ymP96S7HN1Sy7nu5h+zV6ZS7IvdOviGKdrRgo0iOk Y8eHFmGtzAGLni/95rGVYHyZ0IIY+cLn1HLs23IPvoF8/Hz5FjjJkIkP22fw06No Ljy4SaL589e+dBPYRn+MFR2w1niAFOcOHATvnXqNpwbxlYv7CsjBEPv1o/+3BWQw PX7krNorSHo5wgw7ldA6leqp/aer8xz6Kc6v3MbV0p5ooCOn5kJLxFCLDnFbVOKe ogkfAVlW0RDEMMf/DoF4MfRoRTfGLBF72ALrm3BMtatxPZPpQECffsiAJ8jtjpei Gaps2ULlyrBu1kFbPsFXDe9mo4meLpiOH3ko5ZXHTZzTClaPlLHQMX39UD1YwcY8 N5KFDhXSsjmeSWOh4cVl0I8Gy3XBQ77DV9oTXaKMXgwCtQWPlHkkPhpWc/h/TOIM cb8a2wrRQTDUNem00r1oilDuimdaNO4Hb7RLZBkrOw94QhTXF38= =Hyrm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 02:19:42PM -0400, langdon wrote: > On 06/26/2017 01:44 PM, Petr Šabata wrote: > > On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote: > > > On 06/26/2017 11:04 AM, Langdon White wrote: > > > > > > > We talked about this with the server wg and decided for F27 server we > > > > would > > > > try to avoid an "everything else" module and figure out how to solve > > > > this > > > > problem more nicely between now and release. We have multiple options > > > > here > > > > including : generating modules for everything, making an extra repo of > > > > stuff available, leaving non-modules out, and, finally, the everything > > > > else > > > > module. > > > So there is never going to be any mixing of modules and non modules? I > > > would think another way to solve this issue might be to get dnf to > > > prefer modules, but still operate on either rpms or modules, so if you > > > ran 'dnf install tmux' it would look for a tmux module, if it finds it > > > great, it uses that. If it doesn't then it looks for the rpm and uses > > > that. > > > Then if later you do 'dnf update' and there is now a tmux module it > > > uninstalls the rpm and intalls the module, etc. > > This question is kinda like "so there is never going to be any > > mixing of Fedora and Mageia RPMs?". > > > > Module content is built separately and while the sources are > > often the same or close to what was used to build traditional > > composes, the modular content is not guaranteed to be 100% > > binary compatible. > Petr, I think you are jumping to the worst case scenario version of this > question. Specifically, that the "arbitrary rpms" in question here are > coming from an arbitrary repo. Yes, your concerns are valid if we are adding > in arbitrary stuff from arbitrary sources. However, like I said in my email > which crossed in the ether, that doesn't mean we can't manipulate RPMs > directly from DNF. We just don't want people pulling arbitrary rpms from > non-modular sources. Kevin specifically asked about mixing modular and non-modular content. Yes, you can manipulate RPMs directly. I'm not saying you cannot. > > Enhancing dnf with a feature with a potential to unexpectedly > > explode users' systems doesn't sound like a reasonable thing > > to do. > > I think this is a matter of UX testing. If the tmux-rpm was silently > replaced with the tmux-module it may be a good thing assuming it does what > the user expects. I, personally, struggle with the "uninstall/reinstall" > portion of this but if we could find a way to just add stream information > without actually replacing the rpm, the user could just follow the > "tmux-before-it-was-a-module" stream until they are ready to switch then be > give the "real" module-stream options. I'm not sure who would be doing mapping between random RPMs and modules that "replace" them. Sounds difficult, dangerous and not really doable at a large scale, especially if there are more variants of the same content available at the same time, which is one of our features. P > > Langdon > > > > > Definitely a recognized issue, but not sure we are decided on the answer > > > > (or answers). We would like the module guidelines to address the use > > > > cases > > > > with recommendations but it is tough to iron this out. > > > yeah, there definitely could be some complex interactions here, but I > > > think it's important to have the ability to install local rpms or things > > > that are not (yet) modularized. > > That can be done. And if those local RPMs were built against > > the modular platform, even better. > > > > P > > > > > Unrelated question: We will still be making the server repo and > > > netinstall so people can install the legacy server setup with rpms, right? > > > > > > kevin > > > > > > > > > > > > > > > ___ > > > 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 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 09:32:15PM +0200, Igor Gnatenko wrote: > This has been tried by AltLinux, they were using Group tag to organize > packages into small repositories and after all they went back for one > big repository because of cross-dependencies, questions where to put > what and probably other problems. The modularity tech covers the cross-dependencies problem in a new way. For some things, it's pretty clear that "yep, that's a module" is the way to go. (Like, the sort of stuff already building in modules — databases, webservers, language runtimes.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphaning python-cryptography
Hi, my taking python-cryptography was a mistake. I am really not interested in that package anymore and it seems that other people are stalled by my inactivity (see https://bugzilla.redhat.com/show_bug.cgi?id=1408730). Could somebody who cares more about it, take the package from me, please? Thank you, Matěj -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Don't anthropomorphize computers. They don't like it. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2017-06-27 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 26 Final Freeze
Hi all, Today, June 27th 2017, is an important day on the Fedora 26 schedule [1], with significant cut-offs. Today we have the Final Freeze [2]. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. [1] https://fedoraproject.org/wiki/Releases/26/Schedule [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/26/final/buglist Regards, Mohan Boddu ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaned Packages in rawhide (2017-06-25)
On Sun, 2017-06-25 at 00:01 +, t...@fedoraproject.org wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Package(co)maintainers Status Change > === > Pyrex orphan, alexl, caolanm, johnp,1 weeks ago > mbarnes, rhughes, rstrode, ssp, > xiphmont > gtkspellorphan, alexl, caillon, 1 weeks ago > caolanm, group::gnome-sig, > johnp, mbarnes, rhughes, > rstrode, ssp, xiphmont So, judging by the rest of this email (cut), the impact of these two going away (on both Rawhide and Branched) would be quite significant (Pyrex for the SoaS spin specifically, gtkspell for all kinds of things). Is anyone planning on taking care of these somehow? -- 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: Xulrunner - intent to remove from Fedora 24
On 01/26/2016 09:33 PM, Matthias Runge wrote: > On 26/01/16 14:10, Mikolaj Izdebski wrote: > >> pencil >> > pencil did not had any release for a longer time (although they directly > recommend downloading a fedora 19 package, the latest build made by the > package maintainer was 2 years ago for f20. > > Maybe it's time to retire it completely? I am package maintainer for pencil. I see some people around me still using pencil for their day job. I have just got updates from upstream developers. A new version of pencil has been released [1]. I uses Electron, instead of XULrunner. I am planning to update the package to keep pencil on the next Fedora releases. However, as I have checked on the wiki, Electron package [2] has not been officially put into Fedora repo. What should I do now? Any suggestions? -- Kind Regards, Truong Anh Tuan [1] https://github.com/evolus/pencil [2] https://fedoraproject.org/wiki/Electron 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: Fedora Modules & Fedora 27 Server Edition (Changes)
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote: > On 06/26/2017 01:29 PM, Kevin Fenzi wrote: > > On 06/26/2017 11:04 AM, Langdon White wrote: > > > > > We talked about this with the server wg and decided for F27 server we > > > would > > > try to avoid an "everything else" module and figure out how to solve this > > > problem more nicely between now and release. We have multiple options here > > > including : generating modules for everything, making an extra repo of > > > stuff available, leaving non-modules out, and, finally, the everything > > > else > > > module. > > So there is never going to be any mixing of modules and non modules? I > > would think another way to solve this issue might be to get dnf to > > prefer modules, but still operate on either rpms or modules, so if you > > ran 'dnf install tmux' it would look for a tmux module, if it finds it > > great, it uses that. If it doesn't then it looks for the rpm and uses that. > > Then if later you do 'dnf update' and there is now a tmux module it > > uninstalls the rpm and intalls the module, etc. > > Essentially, this ^^ is exactly the plan. The DNF folks will have to weigh > in on exactly how the priorities will work. I also would like to see some UX > testing around your last point. As in, I am not sure the user gets what they > expect if it replaces the tmux-rpm with the tmux-module without any hint. What exactly would be the difference between tmux.rpm and tmux.module.rpm? Would it be configure flags? Bundled libraries? Something else? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
