Rebuild for gmic to latest stable release
Upstream released[0] new version of gmic nearly two months ago and bugzilla notified about the update[1]. Unfortunately I do not have proven packager privilege to do the change so is there anyone doing the update? Thanks in advance. Reference - [0] http://gmic.eu/download.shtml [1] https://bugzilla.redhat.com/show_bug.cgi?id=1321779 -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Summary/Minutes from last Friday's FESCo Meeting (2017-08-11)
=== #fedora-meeting: FESCO (2017-08-04) === Meeting started by jsmith at 16:05:59 UTC. The full logs are available athttps://meetbot.fedoraproject.org/fedora-meeting/2017-08-04/fesco.2017-08-04-16.05.log.html . Meeting summary --- * init process (jsmith, 16:06:05) * Follow-ups (jsmith, 16:09:06) * #1736 - Don't automatically close security bugs on Fedora EOL (jsmith, 16:09:16) * LINK: https://pagure.io/fesco/issue/1736 (jsmith, 16:09:16) * AGREED: #1736 - eol scripts will be adjusted to move keyword: security bugs to the next release and add a note that this was a security bug and should be checked to see if it's fixed in the next release (jsmith, 16:20:39) * #1737 - Proposal: i686 SIG needs to be functional by F27 release date (jsmith, 16:21:17) * LINK: https://pagure.io/fesco/issue/1737 (jsmith, 16:21:17) * AGREED: #1737 - Give the SIG two weeks to come up with their criteria and come back to FESCo for approval, and if they don't, drop i686 kernels for F28 (+1:8,+0:0,-1:0) (jsmith, 16:30:51) * #1744 - F27 System Wide Change: NSS signtool deprecation (jsmith, 16:31:14) * LINK: https://pagure.io/fesco/issue/1744 (jsmith, 16:31:14) * AGREED: #1744 - Reject as an F27 system-wide change, and accept as an F28 system-wide change (+1:8:+0:0,-1:0) (jsmith, 16:43:15) * #1745 - F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL (jsmith, 16:43:27) * LINK: https://pagure.io/fesco/issue/1745 (jsmith, 16:43:27) * AGREED: #1745 - Due to the short F27 cycle, we defer this until F28 and accept it for that release. Please land it as soon after branch as possible. (+1:8,+0:0,-1:0) (jsmith, 16:48:43) * #1747 - F27 System Wide Change: RPM 4.14 (jsmith, 16:48:57) * LINK: https://pagure.io/fesco/issue/1747 (jsmith, 16:48:58) * AGREED: #1747 -- This was already approved on 2017-07-21 (jsmith, 16:50:39) * #1749 - F27 Self Contained Change: VirtualBox Guest Integration (jsmith, 16:50:49) * LINK: https://pagure.io/fesco/issue/1749 (jsmith, 16:50:49) * AGREED: #1749 - FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until it is clear that there is a clear path they will be accepted upstream. (+1:8,+0:0,-1:0) (jsmith, 17:13:53) * #1750 - Decide if EOL is one month after release, four weeks, or something else (jsmith, 17:14:06) * LINK: https://pagure.io/fesco/issue/1750 (jsmith, 17:14:06) * LINK: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Schedule_Methodology (nirik, 17:17:55) * AGREED: $1750 - The use of "month" for marketing purposes is unnecessary. Let's say "four weeks" or "28 days" everywhere and have it done (+1:8,+0:0,-1:0) (jsmith, 17:24:01) * New business (jsmith, 17:24:10) * #1751 - Request to accept a Self Contained Change after deadline (jsmith, 17:24:24) * LINK: https://pagure.io/fesco/issue/1751 (jsmith, 17:24:24) * AGREED: #1751 Change is accepted (+1:8,+0:0,-1:0) (jsmith, 17:26:11) * #1690 - F27 Self Contained Changes (jsmith, 17:26:22) * LINK: https://pagure.io/fesco/issue/1690 (jsmith, 17:26:22) * Unified database for DNF (jsmith, 17:26:35) * LINK: https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF (jsmith, 17:26:35) * AGREED: Defer "Unified database for DNF" to F28 (+1:6,+0:0,-1:0) (jsmith, 17:43:50) * Authselect: new toold to replace authconfig (jsmith, 17:44:02) * LINK: https://fedoraproject.org/wiki/Changes/Authselect (jsmith, 17:44:02) * AGREED: "New tool to replace Authconfig" is rejected, as it's effectively just a new package. Repropose as a Change when it's time to replace authconfig (+1:7,+0:0,-1:0) (jsmith, 17:55:37) * New default cipher in OpenVPN (jsmith, 17:55:54) * LINK: https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN (jsmith, 17:55:54) * AGREED: "New default cipher in OpenVPN" is approved (+1:5,+0:0,-1:0) (jsmith, 18:00:50) * Chinese Serif Fonts (jsmith, 18:01:04) * LINK: https://fedoraproject.org/wiki/Changes/ChineseSerifFonts (jsmith, 18:01:04) * AGREED: "Chinese Serif Fonts" is approved (+1:6,+0:0,-1:0) (jsmith, 18:04:51) * libpinyin 2.1 (jsmith, 18:05:05) * LINK: https://fedoraproject.org/wiki/Changes/libpinyin2.1 (jsmith, 18:05:05) * AGREED: "libpinyin 2.1" is approved (+1:5,+0:1,-1:0) (jsmith, 18:11:09) * Platform Python Stack (jsmith, 18:11:22) * LINK: https://fedoraproject.org/wiki/Changes/Platform_Python_Stack (jsmith, 18:11:22) * AGREED: "Platform Python Stack" is approved (+1:6,+0:0,-1:0) (jsmith, 18:19:36) * OpenSSH Server Crypto Policy (jsmith, 18:20:01) * LINK: https://fedoraproject.org/wiki/Changes/OpenSSH_Server_Crypto_Policy (jsmith, 18:20:01) * AGREED: "OpenSSH Server Crypto Policy" is approved (+1:6,+0:0,-1:0) (j
Elections July/August 2017 to FESCo, Council, FAmSCo - Voting period has started
Hi, the Voting period of the currently running Fedora Elections has just started. Please vote for your candidates to Council [1], FAmSCo[2] and FESCo [3]. You can vote till August 14th, 2017 when the voting ends at 23:59:00 UTC. To help you to make the right decision we have published Fedora Magazine article [4] summarizing this elections and pointing to interviews with nominees we have published on Community Blog. It is definitely worth a look [4]. [1] https://admin.fedoraproject.org/voting/about/council-august-2017 [2] https://admin.fedoraproject.org/voting/about/famsco-august-2017 [3] https://admin.fedoraproject.org/voting/about/fesco-august-2017 [4] https://fedoramagazine.org/august-2017-elections/ Thanks for your support and happy voting. Regards, Jan -- 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: [Modularity]: Service levels and EOL expectations?
On Mon, Aug 7, 2017 at 3:59 PM Matthew Miller wrote: > On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote: > > I still don't see how this is going to work with a tree of Service Levels > > and Lifetimes. Any module can not give a SL greater than the lowest SL > and > > the shortest lifetime that any package in it is going to agree to. [EG > if I > > am packaging up a wordpress module and glibc is on a 18 month lifetime > but > > openssl is meh upstream always.. then unless I am going to maintain > openssl > > myself with its own fork... my module is going to be 'meh upstream > always'. > > If my module pulls in enough stuff to make it work, I am going to be > > dealing with the need of a lawyer to figure out which SL's and lifetimes > > are binding and what ones are not. > > Yeah, that would get crazy fast. The 6 month granularity proposal > should help *some*, and we should probably go into this carefully. > > For packages, the default is to have fNN branches with the implied 13 > month lifecycle and 6 month branch/update window. (Which means that > even nearing the end of the 13 month cycle, there's an overlapping > cycle going half a year longer.) > > The Arbitrary Branching proposal suggests not* do this for f28 > *automatically (but still allow it). Maybe (at first at least) we need > to say that if packagers want to do *other* cycles, they need to give > at least this "there's a version with an EOL at least 7 months off, and > if you hit it right there's a 13 month window" service level. (That > could be fulfilled by "there's one version that is expected to > continually update in a compatible way".) > > Packagers who don't want to deal with all this could just make the > "f28" branch, and packagers who instead want to do something else > longer or additional could.* > > Then, we could have an opt-in process (FESCo approval?) for packages > where the upstream changes too fast to support that. (These packages > are presumably problematic in Fedora currently _anyway_.) > > > * And "longer" sounds like more work, but in many cases it shouldn't > be. I maintain couple of small "leaf" utility programs which are > unlikely to change in a significantly incompatible way, and rather than > maintaining them across "rawhide, f29, f28, f27, el7" I'd like to > maintain just "devel" and "2.stable". > > But there's _definitely_ a lot still to work out here! > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org I guess I am not sure how this is different with modules than with Fedora today. We promise a 13 month lifecycle on openssl (and everything else) already. I think the difference here is only that the "position" is explicit. However, this is not the "real" point to my reply. I agree it is true that the lifecycle of a given *binary* is locked to the lifecycle of the module binaries it depends on. However. this does not necessarily mean that a *stream* is locked to the those lifecycles. In other words, wordpress doesn't expose glibc or openssl APIs to its consumers (to my knowledge ;) ). As a result, it is perfectly valid for the wordpress-4 stream to be built against base-runtime-f26 (brt) or base-runtime-f27 or both. If the lifecycle of base-runtime-f26 runs out, that doesn't mean wordpress-4's lifecycle has run out, it just means that the user must upgrade the base-runtime stream but their application that relies on the wordpress-4 API will continue to operate unchanged. I am not saying that updating a brt is not disruptive, but it should not require code changes to my-wp-app just a replacement of the underlying components. However, the disruption is just "dnf module enable brt-f27 && dnf update and reboot. You may, as a user, actually get new binaries in the wordpress-4-on-base-runtime-f27 configuration but the wordpress-4 is built from the same sources and, while not strictly the "same," for 99% of cases they will be. As we are able to increase the bundling of components, the 99% continues to add 9s after the decimal. At present, we must consume the openssl-1.1 branch in brt/shared-userspace because dnf/rpm can't tell that the binaries provided by different modules are functionally the same. However, as we improve that or find other methods around this problem (private namespacing, containers, rpathing, etc), we could have the openssl-1.1 sources in dist-git be included in multiple modules. When the openssl maintainer elects to add the openssl-1.2 stream, wordpress-4 could decide if it is appropriately backwards compatible for their use case and consume it (by changing their modulemd to point to the new stream). Langdon ___ 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-08-08 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
Re: BTRFS dropped by RedHat
On Mon, 2017-08-07 at 15:08 -0600, Chris Murphy wrote: > On Mon, Aug 7, 2017 at 2:52 PM, Adam Williamson > wrote: > > On Mon, 2017-08-07 at 14:46 -0600, Chris Murphy wrote: > > > On Fri, Aug 4, 2017 at 9:12 AM, Przemek Klosowski > > > wrote: > > > > The release notes for RHEL 7.4 announce that RedHat gave up on btrfs: > > > > > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html > > > > > > I see it as acknowledgment Btrfs is stable enough that it's > > > nonsensical to keep on calling it a technology preview, and also not > > > explicitly supporting it for paying customers. Red Hat doesn't have > > > the developers to support it, so it quite literally has no choice but > > > to deprecate it. > > > > Well, no, you're getting cause and effect mixed up, there. RH doesn't > > have btrfs developers on staff *because* RH, over time, has broadly > > come to the conclusion that btrfs isn't the storage tech it wants to > > roll with. It's not that RH can't support btrfs for paying customers > > because it has no btrfs devs, it's more that RH has decided it doesn't > > want to support btrfs for paying customers so it doesn't hire any btrfs > > devs. > > That's a rather stunning comment and now I want to know if that's true > or if it's just your personal speculation. It's my personal interpretation of what I've followed about RH's general position on btrfs. It's not 'official' in any sense (I'm obviously not in a position to say that, nor am I directly quoting or paraphrasing anyone who *is*). And if anyone more directly involved in RH storage tells you I'm wrong, I'm happy to defer to them. But I don't see why you'd say it's "stunning", I mean, it's pretty much in line with the observable facts (RH used to talk quite positively in public about btrfs, and employed at least a couple of people to work on it, who would continually propose it to become the Fedora default filesystem in the next release; this stopped happening a while back and now, at least AFAIK, we don't have anyone paid to work full-time on btrfs, and RH doesn't talk about a lot in public any more either). Again, all errors are my own. -- 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: BTRFS dropped by RedHat
On Mon, Aug 7, 2017 at 2:52 PM, Adam Williamson wrote: > On Mon, 2017-08-07 at 14:46 -0600, Chris Murphy wrote: >> On Fri, Aug 4, 2017 at 9:12 AM, Przemek Klosowski >> wrote: >> > The release notes for RHEL 7.4 announce that RedHat gave up on btrfs: >> > >> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html >> >> I see it as acknowledgment Btrfs is stable enough that it's >> nonsensical to keep on calling it a technology preview, and also not >> explicitly supporting it for paying customers. Red Hat doesn't have >> the developers to support it, so it quite literally has no choice but >> to deprecate it. > > Well, no, you're getting cause and effect mixed up, there. RH doesn't > have btrfs developers on staff *because* RH, over time, has broadly > come to the conclusion that btrfs isn't the storage tech it wants to > roll with. It's not that RH can't support btrfs for paying customers > because it has no btrfs devs, it's more that RH has decided it doesn't > want to support btrfs for paying customers so it doesn't hire any btrfs > devs. That's a rather stunning comment and now I want to know if that's true or if it's just your personal speculation. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BTRFS dropped by RedHat
On Mon, Aug 7, 2017 at 1:52 PM, Adam Williamson wrote: > Well, no, you're getting cause and effect mixed up, there. RH doesn't > have btrfs developers on staff *because* RH, over time, has broadly > come to the conclusion that btrfs isn't the storage tech it wants to > roll with. It's not that RH can't support btrfs for paying customers > because it has no btrfs devs, it's more that RH has decided it doesn't > want to support btrfs for paying customers so it doesn't hire any btrfs > devs. > Notwithstanding even if Redhat wanted it, the Btrfs folks admit that it isn't ready for Redhat's customer base. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BTRFS dropped by RedHat
On Mon, 2017-08-07 at 14:46 -0600, Chris Murphy wrote: > On Fri, Aug 4, 2017 at 9:12 AM, Przemek Klosowski > wrote: > > The release notes for RHEL 7.4 announce that RedHat gave up on btrfs: > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html > > I see it as acknowledgment Btrfs is stable enough that it's > nonsensical to keep on calling it a technology preview, and also not > explicitly supporting it for paying customers. Red Hat doesn't have > the developers to support it, so it quite literally has no choice but > to deprecate it. Well, no, you're getting cause and effect mixed up, there. RH doesn't have btrfs developers on staff *because* RH, over time, has broadly come to the conclusion that btrfs isn't the storage tech it wants to roll with. It's not that RH can't support btrfs for paying customers because it has no btrfs devs, it's more that RH has decided it doesn't want to support btrfs for paying customers so it doesn't hire any btrfs devs. -- 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: BTRFS dropped by RedHat
On Fri, Aug 4, 2017 at 9:12 AM, Przemek Klosowski wrote: > The release notes for RHEL 7.4 announce that RedHat gave up on btrfs: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html I see it as acknowledgment Btrfs is stable enough that it's nonsensical to keep on calling it a technology preview, and also not explicitly supporting it for paying customers. Red Hat doesn't have the developers to support it, so it quite literally has no choice but to deprecate it. In contrast, SUSE has had reliable atomic updates and rollbacks for two years, based on Btrfs, in both their enterprise and community distros. But they also have a bunch of upstream developers to support it. This is a gem. Consider this in-production scale example when deciding whether Btrfs is stable. https://www.spinics.net/lists/linux-btrfs/msg67308.html Facebook (and others) are making substantial and growing use of Btrfs in container deployments. https://www.spinics.net/lists/linux-btrfs/msg67885.html Good read on the Red Hat decision making sense for enterprise workloads, and where current Btrfs problems are located: https://www.spinics.net/lists/linux-btrfs/msg67940.html In the past 18 months, there were 100 Btrfs, 71 ext4, and 63 XFS contributors. There are thousands of line changes per kernel release cycle for Btrfs. It's in very active development, so Fedora people don't need to confuse business decisions related to support contracts, with what technologies Fedora should use. I mention here a basis for Fedora using Btrfs where it can earn its keep. https://pagure.io/atomic-wg/issue/306 On the bug front, I monitor all the fs lists and linux-raid@ and strictly speaking none are stable in that none are static unchanging targets. All of them are adding features, which then have some bugs and cause regressions in edge cases, and there's some fix cycles. I've been hit with file system bugs on multiple platforms over two decades, and right now I trust Btrfs for my data more than all except maybe ZFS and that's just because I had to flip a coin at some point, and now I know where the bodies are buried with Btrfs. Users have gotten hit with bugs with ZFS on Linux, and when it goes badly there's no fsck at all so you're just hosed. So yeah, bugs are annoying, file systems are hard, backsups are good. Enospc is largely solved on Btrfs, kernel 4.1 added automatic deallocation of empty block groups, and 4.8 added ticketed enospc infrastructure; there is still a super annoying significant minority (maybe bigger than just an edge case) that get sucked into micromanaging their file systems to avoid the remaining instances. That's an active discussion on linux-btrfs@ how to solve this with a user space policy rather than continuing to wait for a smarter deallocation/reuse block groups policy. Anyway this is definitely a lot better, it will continue to get better. The raid56 parity scrub bug is annoying, but the user was always in a net better position with Btrfs despite it than the same situation with md, lvm, or hardware RAID. The precondition is a data strip that's corrupt (not by Btrfs but just ordinary bad sector or other course in the stack) -> from there Btrfs detects this corruption during scrub, reconstructs good data from parity, passes good data to the application and overwrites good data to disk to fix the corruption, and then sometimes due to a race a wrong recomputation of parity happens which is then written to disk. So bad parity replaces good parity. But in that same scenario, md, lvm, and hardware raid propagate corrupt data to the application and if it's a parity overwrite rather than just a read only check for mismatches, bad parity is also written to disk. Back to Btrfs, a 2nd scrub fixes the problem; and during normal reads bad parity is a non-factor; if the stripe the bad parity strip is a part of is degraded (bad sector, failed drive) requiring reconstruction, yep you get bad reconstruction due to bad parity but Btrfs catches this due to data checksums and we get EIO not propagation of corrupt data to the application. OK this is probably long enough now. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Arbitrary Branching and solving the "Change Checkpoint? Better hit the gas!" problem
On Mon, Aug 7, 2017 at 7:34 AM Josh Boyer wrote: > On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller > wrote: > > Our Change process has the basic assumption that if a Change isn't > > working, we will be able to back out. But, in practice, when there are > > problems, we often find it that it's easiest to shrug and go forward, > > scrambling to fix problems in the change itself as well as any fallout. > > I won't say this is a _failure_ exactly — with the Change process, at > > least, we do have that checkpoint where we know the scramble is needed > > rather than waiting until the very last minute. But, especially if we > > are serious about a six-month schedule, it'd be _better_ if we could > > simply decide at the Change Checkpoints whether to include the feature > > at all. > > > > Arbitrary branching and Modularity give us a way to do this. We can, at > > any time, say "this release includes this set of modules" (see > > > https://docs.pagure.org/modularity/design/constructing/compose-distribution.html > > and > > > https://docs.pagure.org/modularity/design/constructing/back-together.html > ). > > > > I'm really liking what I'm seeing from the Boltron demo, questions > > about how to actually manage modules as an end user notwithstanding. If > > we can deliver this with minimal end-user disruption and yet give > > ourselves capabilities like this, it's a huge success. > > > > (Aside: This possibly involves what the Boltron walkthrough calls > > "system profiles". Modularity team! This isn't in the docs yet. Can you > > clarify?) > We haven't documented this yet because we have been working through the details of the how it should work. Basically, we need to provide a way, on the system, to define: a) what the "release" is. In other words, what did the Edition-WG decide should be *installed* by default and what should be *available* by default. For example, less version 487 should be installed, and httpd-2.4 should be available. b) how to "walk" the streams, hopefully automatically. In other words, if a user makes no changes, how does s/he move from foo:1 -> foo:1.1 (where "1" and "1.1" are different streams) vs foo:1 -> foo:2. And, in a related way, how can s/he choose *not* to follow the guidelines. For example, I am running a simple html website. I want to follow every upgrade to httpd that comes out, assuming it doesn't change it's configuration method (so, auto jump httpd2.4->httpd2.6). However, my php website should stick to httpd2.4.z. We think this needs a simple DSL kinda like python requirements, nodejs package, or even like rpm. We needed Boltron to make how this problem is expressed "real." I am glad the question is coming up ;) Please join us at the Modularity WG meeting[1] to discuss. [1]: https://apps.fedoraproject.org/calendar/modularity/ > > Hm. I agree entirely with you, but when reading this I thought of > another possibility. I think modularity gives people the option for a > rolling release, where we don't have to make release == "collection of > specific module versions". If that's one of the outcomes, then > Changes simply become "this module version is available". > > Exactly. See my "httpd for simple html" example above. You could choose to walk all new streams automatically. Or you could choose for just some things. However, you would know that everything individual module works as a unit before it it is declared deliverable. Rather than traditional rolling which just updates the pieces as soon as they are ready, irrelevant of the consumers being ready. Langdon > josh > ___ > 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: [Modularity]: Service levels and EOL expectations?
On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote: > I still don't see how this is going to work with a tree of Service Levels > and Lifetimes. Any module can not give a SL greater than the lowest SL and > the shortest lifetime that any package in it is going to agree to. [EG if I > am packaging up a wordpress module and glibc is on a 18 month lifetime but > openssl is meh upstream always.. then unless I am going to maintain openssl > myself with its own fork... my module is going to be 'meh upstream always'. > If my module pulls in enough stuff to make it work, I am going to be > dealing with the need of a lawyer to figure out which SL's and lifetimes > are binding and what ones are not. Yeah, that would get crazy fast. The 6 month granularity proposal should help *some*, and we should probably go into this carefully. For packages, the default is to have fNN branches with the implied 13 month lifecycle and 6 month branch/update window. (Which means that even nearing the end of the 13 month cycle, there's an overlapping cycle going half a year longer.) The Arbitrary Branching proposal suggests not* do this for f28 *automatically (but still allow it). Maybe (at first at least) we need to say that if packagers want to do *other* cycles, they need to give at least this "there's a version with an EOL at least 7 months off, and if you hit it right there's a 13 month window" service level. (That could be fulfilled by "there's one version that is expected to continually update in a compatible way".) Packagers who don't want to deal with all this could just make the "f28" branch, and packagers who instead want to do something else longer or additional could.* Then, we could have an opt-in process (FESCo approval?) for packages where the upstream changes too fast to support that. (These packages are presumably problematic in Fedora currently _anyway_.) * And "longer" sounds like more work, but in many cases it shouldn't be. I maintain couple of small "leaf" utility programs which are unlikely to change in a significantly incompatible way, and rather than maintaining them across "rawhide, f29, f28, f27, el7" I'd like to maintain just "devel" and "2.stable". But there's _definitely_ a lot still to work out here! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: i386 Xen PV support still needed?
On Mon, 7 Aug 2017, Paolo Bonzini wrote: On 01/08/2017 23:38, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 01 August 2017 at 14:19, Florian Weimer wrote: We still build a special glibc variant for Xen which avoids certain segment-relative accesses which are difficult to emulate with paravirtualization.. Is this still needed? Can we drop it? What is the performance difference between running a regular glibc under Xen vs. this special one? I believe there may still be some value in running Fedora in a Xen i686 guest VM. The performance difference was very significant, though like others I cannot really give a figure. However, it only applied if you were running in a 32-bit hypervisor. I think this set up is pretty much dead. Even though Amazon and others are using Xen and are still running paravirtualized guests, they're using 64-bit hypervisors. CCing Vitaly for confirmation. The 32-bit (x86) hypervisor was dropped in xen-4.3.0 and as xen-4.4.x and earlier are end-of-life, the workaround presumably isn't needed now if it was just with the 32-bit hypervisor. Michael Young ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20170807.n.0 compose check report
Missing expected images: Atomic qcow2 x86_64 Workstation live i386 Server boot i386 Atomic raw-xz x86_64 Kde live i386 Failed openQA tests: 23/137 (x86_64), 3/18 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20170806.n.0): ID: 127164 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/127164 Old failures (same test failed in Rawhide-20170806.n.0): ID: 127070 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/127070 ID: 127077 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/127077 ID: 127090 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/127090 ID: 127092 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/127092 ID: 127103 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/127103 ID: 127104 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/127104 ID: 127105 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/127105 ID: 127106 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/127106 ID: 127107 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/127107 ID: 127109 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/127109 ID: 127120 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/127120 ID: 127122 Test: x86_64 Atomic-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/127122 ID: 127124 Test: x86_64 Workstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/127124 ID: 127126 Test: x86_64 Workstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/127126 ID: 127158 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/127158 ID: 127160 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/127160 ID: 127162 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/127162 ID: 127163 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/127163 ID: 127165 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/127165 ID: 127167 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/127167 ID: 127168 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/127168 ID: 127202 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/127202 ID: 127203 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/127203 ID: 127218 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/127218 ID: 127219 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/127219 ID: 127220 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/127220 Soft failed openQA tests: 65/137 (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-20170806.n.0): ID: 127088 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/127088 ID: 127089 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/127089 ID: 127091 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/127091 ID: 127151 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/127151 ID: 127153 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/127153 ID: 127166 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/127166 ID: 127222 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/127222 Old soft failures (same test soft failed in Rawhide-20170806.n.0): ID: 127065 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/127065 ID: 127066 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/127066 ID: 127067 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/127067 ID: 127068 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedorapr
Re: [Modularity]: Service levels and EOL expectations?
On 7 August 2017 at 07:50, Matthew Miller wrote: > On Mon, Aug 07, 2017 at 07:38:44AM -0400, Josh Boyer wrote: > > > That way, users and admins aren't treated to an explosion of arbitrary > > > days where action is needed to stay on a current stream. Instead, they > > > can plan for annual upgrades as we do now. (I also expect the > > > "platform" module to follow the current Fedora release cycle, right?) > > I think that's short-selling users and admins ability to understand > > what is supported and how to deal with it. Rather than knee-capping > > modules, I think we should aim for a tool that easily informs users > > how long each module is supported for. Admins already deal with > > varying EOLs today on Enterprise products (e.g. RHEL is supported for > > 10 years, but some Openstack versions are supported for 1 and some are > > supported for 3). > > There's a big difference between "10 / 1 / 3 years" and "13 months / 18 > months / 17 weeks / 3 years / 7 months / 280 days / 42 weeks / 1 year / > 160 days / 12 days / 20 months / 13 months (3 months earlier than the > other 13 months, though) / 6 months". > > I think 6 months granularity should be enough; and it doesn't have to > be specifically tied to a given release cycle... it still could be 6, > 12, 18, 24, 30. > > I still don't see how this is going to work with a tree of Service Levels and Lifetimes. Any module can not give a SL greater than the lowest SL and the shortest lifetime that any package in it is going to agree to. [EG if I am packaging up a wordpress module and glibc is on a 18 month lifetime but openssl is meh upstream always.. then unless I am going to maintain openssl myself with its own fork... my module is going to be 'meh upstream always'. If my module pulls in enough stuff to make it work, I am going to be dealing with the need of a lawyer to figure out which SL's and lifetimes are binding and what ones are not. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: i386 Xen PV support still needed?
On 01/08/2017 23:38, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 01 August 2017 at 14:19, Florian Weimer wrote: >> We still build a special glibc variant for Xen which avoids certain >> segment-relative accesses which are difficult to emulate with >> paravirtualization.. >> >> Is this still needed? Can we drop it? > What is the performance difference between running a regular glibc under > Xen vs. this special one? I believe there may still be some value in > running Fedora in a Xen i686 guest VM. The performance difference was very significant, though like others I cannot really give a figure. However, it only applied if you were running in a 32-bit hypervisor. I think this set up is pretty much dead. Even though Amazon and others are using Xen and are still running paravirtualized guests, they're using 64-bit hypervisors. CCing Vitaly for confirmation. Paolo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
On Mon, Aug 07, 2017 at 11:46:34AM -0500, Dennis Gilmore wrote: > El lun, 07-08-2017 a las 16:35 +, Zbigniew Jędrzejewski-Szmek > escribió: > > On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > > > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.ht > > > ml > > > [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-fa > > > ilur > > > es.html > > > > Will the up-to-date status be tracked somehow? > > > The script that updates them is being run in screen in a while true > loop sleeping for 600 seconds between runs. so yes, they will be > updated. Oh, great. I just fixed all my packages, so I'll be happy to see the next iteration ;) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: heads up: poppler soname bump
On 08/05/2017 06:15 PM, Josh Boyer wrote: > On Sat, Aug 5, 2017 at 3:05 PM, Kevin Fenzi wrote: >> On 08/05/2017 11:45 AM, Zbigniew Jędrzejewski-Szmek wrote: >> >>> From #fedora-releng: >>> 18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close >>> to full... >>> 18:22 < sharkcz> nirik: done, thanks for the notice >>> >>> Maybe you should try again? >> >> That is the old secondary arch s390 koji, nothing to do with builds now >> in rawhide as s390 has been added into main koji. ;) > > I will buy you a beer the next time I see you if you stop calling it > s390. It's s390x. We don't build for old 31-bit weird mainframe > hardware, and we dropped multilib for it a while ago in Fedora, iirc. Sorry, I'll try and do better. :) The machine is named s390-koji and was made back when s390 was still being made. Sorry for any confusion. :) 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
Re: Mass rebuilds update
El lun, 07-08-2017 a las 16:35 +, Zbigniew Jędrzejewski-Szmek escribió: > On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.ht > > ml > > [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-fa > > ilur > > es.html > > Will the up-to-date status be tracked somehow? > The script that updates them is being run in screen in a while true loop sleeping for 600 seconds between runs. so yes, they will be updated. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html > [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-failur > es.html Will the up-to-date status be tracked somehow? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Planned Outage - Fedora Buildsystem Server reboots - 2017-08-08 21:00 UTC
There will be an outage starting at 2017-08-08 21: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-08-08 21:00 UTC' Reason for outage: We will be applying updates and rebooting servers into newer kernels. Fedora build related services may be up or down during the outage window. Affected Services: * pkgs.fedoraproject.org * koji * koshei * kojipkgs * mbs (module build service) * bodhi / updates * mdapi service Services not listed are not affected by this outage. Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6215 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: Mass rebuilds update
On 08/07/2017 08:14 AM, Florian Weimer wrote: > On 08/07/2017 04:35 PM, Dennis Gilmore wrote: >> We have now completed two mass rebuilds, The first one was the >> scheduled mass rebuild for Fedora 27 details are here[1] the second one >> was all archful packages due to the binutils bug[2] on ppc64le. The >> failures pages for the two rebuilds can be found here[3] and here[4] > > Have the builds from the second mass rebuild been tagged into the > rawhide buildroot? I don't see them there. They are slowly being added as they are signed... look at: koji list-tagged f27-pending and koji list-tag-history --tag=f27 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
Re: Mass rebuilds update
On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > Hi All, > > We have now completed two mass rebuilds, The first one was the > scheduled mass rebuild for Fedora 27 details are here[1] the second one > was all archful packages due to the binutils bug[2] on ppc64le. The > failures pages for the two rebuilds can be found here[3] and here[4] > > Please quickly clean up all build failures as the schedule[5] has us > branching next Tuesday, August the 15th and enabling Bodhi on August > the 29th, So expect to see a 27 branched compose in about a week from > now. > > Many Thanks > > Dennis > > [1] https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild > [2] https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html > [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-failur > es.html > [5] https://fedoraproject.org/wiki/Releases/27/Schedule There's a bunch of failures because of texlive: DEBUG util.py:439: Error: nothing provides libpoppler.so.67()(64bit) needed by texlive-xetex-bin-6:svn41091-35.20160520.fc27.1.x86_64. DEBUG util.py:439: nothing provides libpoppler.so.67()(64bit) needed by texlive-pdftex-bin-6:svn40987-35.20160520.fc27.1.x86_64 Would it be possible to somehow grep the build logs for that error and fire off automatic rebuilds of affected packages? It might trim the queue of failed builds quite a bit. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
On 08/07/2017 04:35 PM, Dennis Gilmore wrote: > We have now completed two mass rebuilds, The first one was the > scheduled mass rebuild for Fedora 27 details are here[1] the second one > was all archful packages due to the binutils bug[2] on ppc64le. The > failures pages for the two rebuilds can be found here[3] and here[4] Have the builds from the second mass rebuild been tagged into the rawhide buildroot? I don't see them there. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: debuginfo repository matching f27-build
On 08/07/2017 04:52 PM, Dennis Gilmore wrote: > El lun, 07-08-2017 a las 10:00 +0100, Peter Robinson escribió: >> On Mon, Aug 7, 2017 at 9:53 AM, Florian Weimer >> wrote: >>> On 08/01/2017 08:42 AM, den...@ausil.us wrote: There is no debug repos for the buildroot repos. >>> >>> Can we fix this, please? Or offer a tool like “dnf debuginfo- >>> install” >>> that gets the debuginfo directly from Koji, without a need for a >>> repository? >> >> Probably best to file a rel-eng ticket requesting it, reuquests/RFEs >> tend to get lost on lists > > It will need an upstream koji change to do. Best to file it there. Thanks. I filed: https://pagure.io/koji/issue/540 Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: one concrete idea for fedora
On Sun, 2017-08-06 at 10:06 -0400, Matthew Miller wrote: > On Sun, Aug 06, 2017 at 03:42:08AM +0100, Sérgio Basto wrote: > > I'm very sorry for my bad mood and I apologize. > > But what I want emphasize is that we are losing the concept of > > stability not just in Fedora, it is in many other projects, KDE for > > example, simply don't have any "stable" or LTS release or something > > like that, that is real stable and solid as rock. > > LTS and unchanging really isn't in Fedora's charter. But, we do want > releases to be solid for daily use, and it's true that a stream of > updates can detract from that. I really would like us to follow the > long-standing official updates policy > https://fedoraproject.org/wiki/Updates_Policy which says that updates > within a release should have minimal disruption. > > I know this is at odds with many developer and packager desire to > make > updated software available quickly, and I know there are a subset of > users who like this too. The Modularity initiative aims to make it > easy for us to do _both_. > > > For packages maintainers like me, that maintain packages in free > > time, > > we got more and more work and begins to become impossible maintain > > all > > packages correctly, we got lot of packages that aren't updated > > because > > people simple don't have time, so should be important, that some > > team > > take care of completely out-date packages, like, for example, > > gitlib > > [1], also maybe in wild changes like systemd, selinux, appdata, > > etc, > > the team help packagers on maintain his packages. > > I'm sorry, I'm not sure I understand what you're saying here. Do you > mean that it would be nice to have a team of people who would work to > update packages across the distro if there are big changes to core > packages? We actually have that, in the Proven Packagers team. See > the > "Mass package change proposal" for an example of this in action. yes , is that what I meant, I need help on selinux :) and webalizer ... Thanks , best regards. > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
El lun, 07-08-2017 a las 10:50 -0400, Matthew Miller escribió: > On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > > We have now completed two mass rebuilds, The first one was the > > scheduled mass rebuild for Fedora 27 details are here[1] the second > > one > > was all archful packages due to the binutils bug[2] on ppc64le. The > > failures pages for the two rebuilds can be found here[3] and > > here[4] > > How should we read these two lists? Do we need to check both, or does > one supercede the other? If your package is a noarch only package, you should read the first list, if your package is archful you should look for it in the second list. It is all a tad messy. Dennis > > Please quickly clean up all build failures as the schedule[5] has > > us > > branching next Tuesday, August the 15th and enabling Bodhi on > > August > > the 29th, So expect to see a 27 branched compose in about a week > > from > > now. > > Cool! > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: debuginfo repository matching f27-build
El lun, 07-08-2017 a las 10:00 +0100, Peter Robinson escribió: > On Mon, Aug 7, 2017 at 9:53 AM, Florian Weimer > wrote: > > On 08/01/2017 08:42 AM, den...@ausil.us wrote: > > > There is no debug repos for the buildroot repos. > > > > Can we fix this, please? Or offer a tool like “dnf debuginfo- > > install” > > that gets the debuginfo directly from Koji, without a need for a > > repository? > > Probably best to file a rel-eng ticket requesting it, reuquests/RFEs > tend to get lost on lists It will need an upstream koji change to do. Best to file it there. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote: > We have now completed two mass rebuilds, The first one was the > scheduled mass rebuild for Fedora 27 details are here[1] the second one > was all archful packages due to the binutils bug[2] on ppc64le. The > failures pages for the two rebuilds can be found here[3] and here[4] How should we read these two lists? Do we need to check both, or does one supercede the other? > Please quickly clean up all build failures as the schedule[5] has us > branching next Tuesday, August the 15th and enabling Bodhi on August > the 29th, So expect to see a 27 branched compose in about a week from > now. Cool! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Mass rebuilds update
Hi All, We have now completed two mass rebuilds, The first one was the scheduled mass rebuild for Fedora 27 details are here[1] the second one was all archful packages due to the binutils bug[2] on ppc64le. The failures pages for the two rebuilds can be found here[3] and here[4] Please quickly clean up all build failures as the schedule[5] has us branching next Tuesday, August the 15th and enabling Bodhi on August the 29th, So expect to see a 27 branched compose in about a week from now. Many Thanks Dennis [1] https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild [2] https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-failur es.html [5] https://fedoraproject.org/wiki/Releases/27/Schedule signature.asc Description: This is a digitally signed message part ___ 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: Introduction/looking for a sponsorship
On Mon, 2017-08-07 at 07:40 -0400, Matthew Miller wrote: > On Mon, Aug 07, 2017 at 02:36:45AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > Apparently, the way this is done in Debian [1] is that the program is > > > installed as /usr/bin/prename and provided as an alternative to the > > > util-linux version of /usr/bin/rename via the alternatives system. > > [...] > > Nah, please don't do that. This rename and that rename have different > > option syntax, so they are not interchangeable. We're better off just > > having a different name. > > Yeah. The Alternatives system should only be used in the very rare > cases where two different programs provide the same functionality and > drop-in equivalence to a reasonable level. And yet we are considering making /usr/bin/python user-configurable between two not-at-all-drop-in-equivalent binaries! Owen [ Sorry for the off-topic comment in this thread ] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Modularity]: Service levels and EOL expectations?
On Mon, Aug 07, 2017 at 07:38:44AM -0400, Josh Boyer wrote: > > That way, users and admins aren't treated to an explosion of arbitrary > > days where action is needed to stay on a current stream. Instead, they > > can plan for annual upgrades as we do now. (I also expect the > > "platform" module to follow the current Fedora release cycle, right?) > I think that's short-selling users and admins ability to understand > what is supported and how to deal with it. Rather than knee-capping > modules, I think we should aim for a tool that easily informs users > how long each module is supported for. Admins already deal with > varying EOLs today on Enterprise products (e.g. RHEL is supported for > 10 years, but some Openstack versions are supported for 1 and some are > supported for 3). There's a big difference between "10 / 1 / 3 years" and "13 months / 18 months / 17 weeks / 3 years / 7 months / 280 days / 42 weeks / 1 year / 160 days / 12 days / 20 months / 13 months (3 months earlier than the other 13 months, though) / 6 months". I think 6 months granularity should be enough; and it doesn't have to be specifically tied to a given release cycle... it still could be 6, 12, 18, 24, 30. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
> It is problem of FPC, see > https://bugzilla.redhat.com/show_bug.cgi?id=1475223. Thank you. Very insightful. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
>Stabs is a ancient debuginfo format that isn't supported by any/most modern >tools. Hm. But it seemed to worked fine as recently as July 25. >You should definitely see if [...] you can produce normal DWARF debuginfo. I edited the makefile to use a different compiler switch, and with DWARF debuginfo, the koji build completes just fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=21089412 Either way, I've read the Bugzilla ticket linked to by Igor and it seems that on i686, fpc defaults to stabs debuginfo, so using the "generate DWARF debuginfo" compiler switch is (currently) the preferred solution to the problem. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Introduction/looking for a sponsorship
On Mon, Aug 07, 2017 at 02:36:45AM +, Zbigniew Jędrzejewski-Szmek wrote: > > Apparently, the way this is done in Debian [1] is that the program is > > installed as /usr/bin/prename and provided as an alternative to the > > util-linux version of /usr/bin/rename via the alternatives system. [...] > Nah, please don't do that. This rename and that rename have different > option syntax, so they are not interchangeable. We're better off just > having a different name. Yeah. The Alternatives system should only be used in the very rare cases where two different programs provide the same functionality and drop-in equivalence to a reasonable level. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Modularity]: Service levels and EOL expectations?
On Sat, Aug 5, 2017 at 1:17 PM, Matthew Miller wrote: > > I'm looking at: > > https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs > > While not a part of the modulemd specification yet, modules will > eventually carry a Service Level (SL) value and an End of Life > (EOL) value. > > The work in Changes/ArbitraryBranching will enable packagers to > select independent SLAs and EOLs for both their rpm branches as > well as their module branches. Both of these values are associated > with the branch in a dist-git repo, but not with the modulemd or > spec file contained therein. > > Packagers will have to choose from a set of pre-defined SLs maintained by > Release Engineering. More info coming soon! > > Is there an active plan on figuring out these Service Levels? Is there > a ticket? Is there a specific person who owns this? I think we need at > least a preliminary understanding of what goes here for the F27 beta > (freeze on Sept. 9th, so... I guess by then?) > > I'm assuming "Service Levels" will include options like: > > * This module strives to be very stable and we will backport patches > > * This module tries to be stable but occasionally we may make breaking > changes with FESCo approval when it's the only option for a security > update (this matches the current Fedora updates policy at > https://fedoraproject.org/wiki/Updates_Policy#Security_fixes) > > * This module promises only a subset of functionality to remain the > same. For example, it will include a certain command line program but > doesn't promise that output of that program will aways be identical. > > * This is a development-stream module which makes no promises! (E.g, it is > Rawhide.) > > Is that the kind of thing others are expecting? Or was this to be more > like "security", "security+bugfix", "security+bugfix+enhancements"? > > *Or*, is it something like "best effort", "sig maintained", "core > critical path", "edition critical path", "spin critical path"? > > I can see the first idea (the * points above) as most useful to > end-users. The third idea is more useful for *us*. > > I'd also like to propose a policy for EOLs. I assume that some modules > will have undefined EOLs, and I think that's okay. There should be some > mechanism and rules for adding one (amount of notice expected, what to > do if we can't meet that expectation, how the tools will present the > addition of an EOL). When a specific EOL is given, though, I'd like a > rule which says that that EOL is aways a month after the planned > traditional Fedora release dates — so, June and November, basically. > (We could choose something like "The last Tuesday in June or November"; > I don't care specifically.) Also, EOL should be treated as a "no sooner > than" date, so if we slip the corresponding release, we could add a > week or two to the upcoming module EOLs. I kind of disagree with this. It's tying modules into a collection we call a release, which means having independent EOLs is essentially pointless. If we allow modules to help implement a rolling release, then they need independent module lifetimes. > That way, users and admins aren't treated to an explosion of arbitrary > days where action is needed to stay on a current stream. Instead, they > can plan for annual upgrades as we do now. (I also expect the > "platform" module to follow the current Fedora release cycle, right?) I think that's short-selling users and admins ability to understand what is supported and how to deal with it. Rather than knee-capping modules, I think we should aim for a tool that easily informs users how long each module is supported for. Admins already deal with varying EOLs today on Enterprise products (e.g. RHEL is supported for 10 years, but some Openstack versions are supported for 1 and some are supported for 3). josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Arbitrary Branching and solving the "Change Checkpoint? Better hit the gas!" problem
On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller wrote: > Our Change process has the basic assumption that if a Change isn't > working, we will be able to back out. But, in practice, when there are > problems, we often find it that it's easiest to shrug and go forward, > scrambling to fix problems in the change itself as well as any fallout. > I won't say this is a _failure_ exactly — with the Change process, at > least, we do have that checkpoint where we know the scramble is needed > rather than waiting until the very last minute. But, especially if we > are serious about a six-month schedule, it'd be _better_ if we could > simply decide at the Change Checkpoints whether to include the feature > at all. > > Arbitrary branching and Modularity give us a way to do this. We can, at > any time, say "this release includes this set of modules" (see > https://docs.pagure.org/modularity/design/constructing/compose-distribution.html > and > https://docs.pagure.org/modularity/design/constructing/back-together.html). > > I'm really liking what I'm seeing from the Boltron demo, questions > about how to actually manage modules as an end user notwithstanding. If > we can deliver this with minimal end-user disruption and yet give > ourselves capabilities like this, it's a huge success. > > (Aside: This possibly involves what the Boltron walkthrough calls > "system profiles". Modularity team! This isn't in the docs yet. Can you > clarify?) Hm. I agree entirely with you, but when reading this I thought of another possibility. I think modularity gives people the option for a rolling release, where we don't have to make release == "collection of specific module versions". If that's one of the outcomes, then Changes simply become "this module version is available". josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
On Mon, 2017-08-07 at 09:42 +, Artur Iwicki wrote:
> I maintain a package written in Pascal, which uses fpc for compiling. I
> noticed that recently, koji builds started failing on i686 and armv7hl due to
> the find-debuginfo script failing to, well, extract the debuginfo.
>
> Here's a link to a failed koji build (mass-rebuild by releng):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20981009
>
> On x86_64 and ppc64, the package builds fine. On i686 and armv7hl, this
> happens:
> > extracting debug info from
> > /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
>
> > Stabs debuginfo not supported:
> > /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
>
> > gdb-add-index: No index was created for
> > /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
>
> > gdb-add-index: [Was there no debuginfo? Was there already an index?]
>
> [ snip ]
> >RPM build errors:
>
> >error: Empty %files file
> >/builddir/build/BUILD/LD25-e5ecbe39b719f12a1268bcc641eae9ba364221c9/debugsourcefiles.list
This is still being discussed upstream:
http://lists.rpm.org/pipermail/rpm-maint/2017-August/006245.html
But I think the consensus is that it is a packaging bug.
It means that although you package contains native binaries there is no
correct DWARF produced so no corresponding source files have been found.
This is usually caused by a missing -g in the build flags or the native
compiler (fpc in your case I assume) not producing correct DWARF
debugging information.
> I thought this may be a bug with the package, but then I saw that koji builds
> for a new fpc-compiled package that I've been working on lately (not yet
> submitted for review) suffer the same problem. This one is worse, even, since
> find-debuginfo fails with a coredump.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21087076
> >extracting debug info from
> >/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>
> >extracting debug info from
> >/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
>
> >Stabs debuginfo not supported:
> >/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>
> >Stabs debuginfo not supported:
> >/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
That is definitely a bug in your package or the fpc compiler.
Stabs is a ancient debuginfo format that isn't supported by any/most
modern tools. You should definitely see if you can figure out how that
happened and how you can produce normal DWARF debuginfo.
> >dwz: dwz.c:1984: checksum_die: Assertion `((!op_multifile && !rd_multifile
> >&& !fi_multifile) || cu != die_cu (ref)) && (!op_multifile || cu->cu_chunk
> >== die_cu (ref)->cu_chunk)' failed.
>
> >/usr/lib/rpm/find-debuginfo.sh: line 518: 8822 Aborted
> >(core dumped) dwz $dwz_opts ${dwz_files[@]}
I am not sure exactly how this happened. It happens when handling a
Dwarf DW_FORM_ref_addr construct. You might have to report a bug report
against dwz with the files so we can track this down.
But note that this doesn't abort the build (maybe it should, but it
currently doesn't - it just means your DWARF debuginfo won't be
compressed).
The reason your build failed is the first issue of missing/incorrect
DWARF generation so that no source files could be found.
Cheers,
Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
On 2017-08-07, Pierre-Yves Chibon wrote: > Could you make two tickets of these? > https://pagure.io/fedora-infrastructure/issue/6208 https://pagure.io/fedora-infrastructure/issue/6209 -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2017-08-07 at 09:42 +, Artur Iwicki wrote:
> I maintain a package written in Pascal, which uses fpc for compiling.
> I noticed that recently, koji builds started failing on i686 and
> armv7hl due to the find-debuginfo script failing to, well, extract
> the debuginfo.
It is problem of FPC, see
https://bugzilla.redhat.com/show_bug.cgi?id=1475223.
>
> Here's a link to a failed koji build (mass-rebuild by releng):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20981009
>
> On x86_64 and ppc64, the package builds fine. On i686 and armv7hl,
> this happens:
> > extracting debug info from /builddir/build/BUILDROOT/colorful-1.3-
> > 3.fc27.arm/usr/bin/colorful
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/colorful-
> > 1.3-3.fc27.arm/usr/bin/colorful
> > gdb-add-index: No index was created for
> > /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> > gdb-add-index: [Was there no debuginfo? Was there already an
> > index?]
>
> [ snip ]
> > RPM build errors:
> > error: Empty %files file /builddir/build/BUILD/LD25-
> > e5ecbe39b719f12a1268bcc641eae9ba364221c9/debugsourcefiles.list
>
> I thought this may be a bug with the package, but then I saw that
> koji builds for a new fpc-compiled package that I've been working on
> lately (not yet submitted for review) suffer the same problem. This
> one is worse, even, since find-debuginfo fails with a coredump. https
> ://koji.fedoraproject.org/koji/taskinfo?taskID=21087076
> > extracting debug info from /builddir/build/BUILDROOT/peazip-6.4.1-
> > 3.fc27.i386/usr/bin/peazip-qt
> > extracting debug info from /builddir/build/BUILDROOT/peazip-6.4.1-
> > 3.fc27.i386/usr/bin/peazip-gtk
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/peazip-
> > 6.4.1-3.fc27.i386/usr/bin/peazip-qt
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/peazip-
> > 6.4.1-3.fc27.i386/usr/bin/peazip-gtk
> > dwz: dwz.c:1984: checksum_die: Assertion `((!op_multifile &&
> > !rd_multifile && !fi_multifile) || cu != die_cu (ref)) &&
> > (!op_multifile || cu->cu_chunk == die_cu (ref)->cu_chunk)' failed.
> > /usr/lib/rpm/find-debuginfo.sh: line 518: 8822
> > Aborted (core dumped) dwz $dwz_opts ${dwz_files[@]}
>
> I checked the build & updates status for fpc and there haven't been
> any updates to the package lately, so this definitely isn't a
> regression in the compiler.
> Have there been any recent changes to find-debuginfo that may be
> causing this?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmIR94ACgkQaVcUvRu8
X0yHixAArM9Gq0tGi5pcCIS7RszqMou571yGeQHSRS4ujEnO4DR9VlBJZJhfn1ko
ldLbX3n5rSAeZ45dCCPtJBmTcJUItMw57cSf1I8sbHDBN/GreDBdhojULySSLAqQ
VaPOoZUrptJqoUNQDECVAoULn0bef7rnCUchONTbvhtza6BjKp6kHJst54uHInxB
HxGjAUJKlpiGV0v0GQx6JgjCLdwUZg+AmSZZ7CiEWHiKCwI2XFgROEIX933gZdet
wTQDqIZ4TkySGKZ0N3yb5h/Sl8lnAvAolmTEUThOVRZgwo5ySyfSYh5yEr8emwjq
H3r6c7O8GCv8gtDrdPYYFhkywa+zN6xY4XWwPJiwU7ClKyxYl9ZcLUnhpBJznTpn
vQwe/a2s5yPxpxvR+GCP86wg1ZqYAK/8Brx/4ohEy6dCYu0T3agH++ah5w3S2qCh
to13zJo8b2M4GfmIwYEmfmt+aL1BEIpOjuU+nncFL+dhYS0uJHw6BClPiLj4BMEY
Kl1tR6P+WK7WOfdAo2iAwXaXCvmqv9idVx06o1b5yFh1CZtq0ivzw1rYHuVv3OBQ
OcmPxJ9OPTNYO806sZ/WmUCbN5lerNfkPBL8la+8FLpOHkLplQvRmpWzWxYVcL8k
DkQvXWtckzykTHvmBJWmR8OBX3sgikvdqJK9yd9toXAYssVFbHM=
=sSy9
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
find-debuginfo fails for fpc-compiled software on i686 and armv7hl
I maintain a package written in Pascal, which uses fpc for compiling. I noticed
that recently, koji builds started failing on i686 and armv7hl due to the
find-debuginfo script failing to, well, extract the debuginfo.
Here's a link to a failed koji build (mass-rebuild by releng):
https://koji.fedoraproject.org/koji/taskinfo?taskID=20981009
On x86_64 and ppc64, the package builds fine. On i686 and armv7hl, this happens:
> extracting debug info from
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> Stabs debuginfo not supported:
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> gdb-add-index: No index was created for
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> gdb-add-index: [Was there no debuginfo? Was there already an index?]
[ snip ]
>RPM build errors:
>error: Empty %files file
>/builddir/build/BUILD/LD25-e5ecbe39b719f12a1268bcc641eae9ba364221c9/debugsourcefiles.list
I thought this may be a bug with the package, but then I saw that koji builds
for a new fpc-compiled package that I've been working on lately (not yet
submitted for review) suffer the same problem. This one is worse, even, since
find-debuginfo fails with a coredump.
https://koji.fedoraproject.org/koji/taskinfo?taskID=21087076
>extracting debug info from
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>extracting debug info from
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
>Stabs debuginfo not supported:
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>Stabs debuginfo not supported:
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
>dwz: dwz.c:1984: checksum_die: Assertion `((!op_multifile && !rd_multifile &&
>!fi_multifile) || cu != die_cu (ref)) && (!op_multifile || cu->cu_chunk ==
>die_cu (ref)->cu_chunk)' failed.
>/usr/lib/rpm/find-debuginfo.sh: line 518: 8822 Aborted (core
>dumped) dwz $dwz_opts ${dwz_files[@]}
I checked the build & updates status for fpc and there haven't been any updates
to the package lately, so this definitely isn't a regression in the compiler.
Have there been any recent changes to find-debuginfo that may be causing this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
On Mon, Aug 07, 2017 at 08:19:55AM +, Petr Pisar wrote: > Related thing: Since the Pagure overhaul, e-mails about pushed commits > do not contain commit body (the diff). That makes the e-mail > notificition less helpfull for me. I'm more interrested in what changed > than that something changed. Is that a bug a or a feature? I think I just fixed this one in: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/436 Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: debuginfo repository matching f27-build
On Mon, Aug 7, 2017 at 9:53 AM, Florian Weimer wrote: > On 08/01/2017 08:42 AM, den...@ausil.us wrote: >> There is no debug repos for the buildroot repos. > > Can we fix this, please? Or offer a tool like “dnf debuginfo-install” > that gets the debuginfo directly from Koji, without a need for a repository? Probably best to file a rel-eng ticket requesting it, reuquests/RFEs tend to get lost on lists ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: debuginfo repository matching f27-build
On 08/01/2017 08:42 AM, den...@ausil.us wrote: > There is no debug repos for the buildroot repos. Can we fix this, please? Or offer a tool like “dnf debuginfo-install” that gets the debuginfo directly from Koji, without a need for a repository? With the more fine-grained debuginfo packages, those of us who need to debug bleeding-edge issues have to download a fairly large number of packages manually. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
On Mon, Aug 07, 2017 at 08:19:55AM +, Petr Pisar wrote: > On 2017-08-03, Pierre-Yves Chibon wrote: > > CC in Bugzilla > > -- > > > > Pagure over dist-git does not offer issue tracking. Issues for > > packages will continue to be tracked in Bugzilla. However, if you > > look at the watch options in a project in Pagure over dist-git, you > > will see there is an option to watch issues on the project. This > > mechanism will be used to retrieve the list of packagers to be CC'd on > > Bugzilla tickets. > > > > Note: there is a ticket open against Pagure to have the list of people > > watching the project available in the UI (it is currently only present > > in the API). > > > How can a package maintainer add a mailing list pseudo-user to > watachers? I talk about perl-sig pseudo-user forwarding all commits and > bug reports to perl-devel list. > > The API can only list watchers. The interractive web interface allows to > become a watcher. It does not allow to make another user a watcher. > > Related thing: Since the Pagure overhaul, e-mails about pushed commits > do not contain commit body (the diff). That makes the e-mail > notificition less helpfull for me. I'm more interrested in what changed > than that something changed. Is that a bug a or a feature? Could you make two tickets of these? Thanks, Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
On 2017-08-03, Pierre-Yves Chibon wrote: > CC in Bugzilla > -- > > Pagure over dist-git does not offer issue tracking. Issues for > packages will continue to be tracked in Bugzilla. However, if you > look at the watch options in a project in Pagure over dist-git, you > will see there is an option to watch issues on the project. This > mechanism will be used to retrieve the list of packagers to be CC'd on > Bugzilla tickets. > > Note: there is a ticket open against Pagure to have the list of people > watching the project available in the UI (it is currently only present > in the API). > How can a package maintainer add a mailing list pseudo-user to watachers? I talk about perl-sig pseudo-user forwarding all commits and bug reports to perl-devel list. The API can only list watchers. The interractive web interface allows to become a watcher. It does not allow to make another user a watcher. Related thing: Since the Pagure overhaul, e-mails about pushed commits do not contain commit body (the diff). That makes the e-mail notificition less helpfull for me. I'm more interrested in what changed than that something changed. Is that a bug a or a feature? -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
On Mon, Aug 07, 2017 at 02:09:51AM +0100, Peter Robinson wrote: > On Thu, Aug 3, 2017 at 4:21 PM, Pierre-Yves Chibon > wrote: > > New package and new branch request process > > -- > > > > PkgDB used to be the place where packagers could request a new branch or a > > new > > package to be added. > > The new package and branch processes will now rely on a project > > hosted on pagure.io where people can open a ticket to request additions. > > There is a CLI tool for packagers to use: fedrepo-req (already present > > in updates-testing) that opens the ticket for you in > > such a way that these requests can be automatically handled by release > > engineering. > > > > More information about this tool at: https://pagure.io/fedrepo_req > > What about retiring a package? "fedpkg retire" seems to be broken now. There was no official announcement that pagure over dist-git is now a thing because we only did the minimal required changes on Friday to avoid breaking things over the week-end when there are less people around to fix them. We know a number of scripts and cron jobs are currently either not working or working on old data (if they still hit pkgdb). Feel free to open a ticket on https://pagure.io/fedora-infrastructure/new_issue if you see something that is not working so we can track them, some of them will be quickly closed, some may take a little longer. Thanks, Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2017-08-07 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have anything super important for the agenda, and tomorrow is a vacation day at least in Canada and I think possibly in the US as well. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- 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-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 27 Rawhide 20170804.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 27 Rawhide 20170804.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20170729.n.1: pungi-4.1.17-1.fc27.src, 20170804.n.1: pungi-4.1.17-3.fc27.src parted - 20170729.n.1: parted-3.2-26.fc27.src, 20170804.n.1: parted-3.2-28.fc27.src pykickstart - 20170729.n.1: pykickstart-2.35-1.fc27.src, 20170804.n.1: pykickstart-2.37-1.fc27.src lorax - 20170729.n.1: lorax-27.4-1.fc27.src, 20170804.n.1: lorax-27.5-1.fc27.src python-blivet - 20170729.n.1: python-blivet-2.1.9-2.fc27.src, 20170804.n.1: python-blivet-2.1.9-3.fc27.src anaconda - 20170729.n.1: anaconda-27.19-1.fc27.src, 20170804.n.1: anaconda-27.19-2.fc27.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/27 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_User:Adamwill/NoMoreAlpha/Server https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170804.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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
