Re: Fedora Lifecycles: imagine longer-term possibilities
We, as a distro, just take a different approach. To be bleeding edge requires to have releases often. That allow us to manage changes like GCC, OpenSSL and so on quickly. Struggling with upstream who don't adapt, can't adapt or don't want to adapt at the same speed. (And OpenSSL patch isn't something you'd want to write for serveral pojects you maintain ...) That is what make us different distro with its own user base. Want the very same but LTS system? try CentOS. Or RHEL. -- Speaking for myslef, the trouble is to keep up with the system wide changes even as a maintainer. The MariaDB package for example: In just last two years it went though 4 major releases - from 10.0 to 10.3. I put a big effort into dividing server and client part, changing packages layout and build dependency tree (for packages which need MariaDB). MariaDB also re-writtent the whole client library, huge change again. Than OpenSSL, new GCC, python 2 removal ... With so much changing, imagine the anguish of upgrades. Last half a year I tried to make COPR repositories for each major release (10.1-10.3) for every Fedora version (F27+). Worked well with "15 minutes of best effort" rule. Not sure if anybody used it though. Now I can slowly abadon the COPR thanks to modules which does the trick. However all of the problems remained, while I should put more energy and time into it. * Rebuild 10.1 with new OpenSSL? don't think so ... * Change package layout to undo some changes in releases that don support it? not compatible with the rest of the OS ... * Use release with old client library in Fedora version adjusted to new one? breaks literaly everything ... It's like "give me another folk working full time on it and I still don't believe we could solve all of this". What I wanted to express by this message is the fact, prolonging software support time in Fedora means *a lot* of low-level work TBD. I can maintain it either "bleeding edge style", geting users new features literally ASAP, or "LTS style" defend the database from any update to not break anything, bugfix and security fix only. (I'm doing it for RHEL after all). But not both. That would require wide matrix of versions adapted to every change, update and feature or not adapted at all (or just to some of them); depending on whether the specific user pick LTS version or evolving one. Looked for a solution for over a year. Not finding any. I keep saying RHEL & CentOS are our LTS versions. Wishing good luck to your search. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat -- On Wed, Nov 14, 2018 at 12:37 AM Matthew Miller wrote: > > > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some random > Tuesday with a rolling release. Second, we have some things like Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. Second, there are people who really could be happily running > Fedora but since we don't check the tickbox, they don't even look at us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:
Re: could Fedora please reverse its policy re End-Of-Life
On Tue, Nov 13, 2018 at 9:14 PM steve schooler wrote: > > > I am currently using Fedora 26. When I first heard of your (new) End-Of-Life > policy, I hoped that the Fedora developer community would be so inundated > with complaints that the policy would be reversed. Instead however, the > policy is being continued with Fedora 27. > This policy is not new. Our EOL policy has been this way for the entire existence of the project (15 years!). Fedora releases are effectively supported until the release after next, plus one month. That usually equates to 13 months per release (give or take a month or two). Instead of supporting releases longer, we've elected to specifically work towards making upgrades painless, so that it's not necessary to stay on a particular release for the full length, and upgrading is encouraged and well-supported. If there's a problem with an upgrade, please feel free to file a bug report in our bug tracker: https://bugz.fedoraproject.org. As a final note: This is not the correct list for these kind of inquiries. In the future, please discuss on our user support mailing list: https://lists.fedoraproject.org/admin/lists/users.lists.fedoraproject.org/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: could Fedora please reverse its policy re End-Of-Life
steve schooler wrote: > I am currently using Fedora 26. When I first heard of your (new) > End-Of-Life policy, That policy is not new. It has been like that for years, and before that the lifetime was even shorter. > If you agree but need to first alleviate current burdens, then I suggest > revamping your management of spins. Personally, my > Fedora26-Cinnamon-spin-install _failed_. Further, the problem was > _immediately_ alleviated by my abandoning the spin, installing the > _vanilla_ Fedora 26, and then _manually_ installing Cinnamon. My rig has > _no_ _video_ _card_; I use the mobo's onboard video. The real issue that you have is that that happened. Why did installing from Cinnamon fail whereas installing Cinnamon after installing Fedora worked? If it was a driver issue fixed in an update, then you should simply install from the latest respin of the Cinnamon Spin, including all the updates: https://dl.fedoraproject.org/pub/alt/live-respins/ The fact that your GPU is an onboard IGP is irrelevant. Driver issues can happen with IGPs and with dedicated GPUs just alike. > I see _no_ _reason_ why the Fedora development community can't _replace_ > ALL OF ITS SPINS with user installation documents (instructions) the > appropriate messages in the gui presented to the user at the end of the > installation process. Why would I want to install the whole GNOME that I don't use just to be able to install the desktop environment I actually use after the fact? That just does not make any sense whatsoever. > Fedora's End-Of-Life policy be _changed_ from 13 months to 37 months. Fedora never had such a long lifetime, and it is just not practical. It would mean supporting 7 releases at once! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
could Fedora please reverse its policy re End-Of-Life
This email is a hail mary pass. I posted the following message to the Fedora forum: https://ask.fedoraproject.org/en/question/129083/could-fedora-please-reverse-its-policy-re-end-of-life/ Part of the _closing_ response was for me to redirect the message to a fedora.org mailing list. No joy attempting to access the fedora.org webpage, so I googled "fedora org mailing list". This mailing list _seems_ to be the most pertinent. If this query is mis-directed, please either re-direct it or email me the correct email address or fedora org forum. Note: I originally sent this message as an email and received an email response to post the message as a new thread, here. The remainder of this email is my opinion. I am currently using Fedora 26. When I first heard of your (new) End-Of-Life policy, I hoped that the Fedora developer community would be so inundated with complaints that the policy would be reversed. Instead however, the policy is being continued with Fedora 27. I recognize that since Fedora is FREE, the developers face an enormous burden. However, I suspect that many will feel as I do that it is an onerous user-burden to have to frequently upgrade/re-install. Further, forum-technical-support, regardless of how timely and incisive, doesn't compensate for the user-burden. If you agree but need to first alleviate current burdens, then I suggest revamping your management of spins. Personally, my Fedora26-Cinnamon-spin-install _failed_. Further, the problem was _immediately_ alleviated by my abandoning the spin, installing the _vanilla_ Fedora 26, and then _manually_ installing Cinnamon. My rig has _no_ _video_ _card_; I use the mobo's onboard video. Internet-researching, I found that others had a similar experience. I think that it is _not_ _practical_ for the Fedora development community to try to anticipate all of the anomalies caused by unusual hardware or drivers. I see _no_ _reason_ why the Fedora development community can't _replace_ ALL OF ITS SPINS with user installation documents (instructions) + the appropriate messages in the gui presented to the user at the end of the installation process. Naturally, you would want these "gui messages" _preserved_ as part of the installation, so that the "sleepy-user-installer" could be later directed to them as a forum query response. Furthermore, the spin strategy that I am proposing transfers the _responsibility_ of the "spin install" (e.g. manually installing Cinnamon atop Fedora) where it _belongs_ (e.g. with the Cinnamon developers org). Naturally, the "spin org" would expect that its developers would work _with_ the Fedora developers to resolve anomalies. I advocate that this strategy be extended to _all_ spins, and that Fedora's End-Of-Life policy be _changed_ from 13 months to 37 months. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, 13 Nov 2018 at 19:27, Matthew Miller wrote: > > > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some random > Tuesday with a rolling release. Second, we have some things like Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. Second, there are people who really could be happily running > Fedora but since we don't check the tickbox, they don't even look at us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > There are a lot of possibilities, but it is also that "something that lasts for 36-48 months" probably means something different to everyone involved. To some set it means "Whatever was shipped on Day0 had only better get backported fixes and maybe, maybe minor updates", to others it means "well it shouldn't have any major api/abi updates in those 36-48 months.. " to the "so this just means it should be a rolling update as long as everything always works or resets easily". Is this conversation completely blue-sky or are there boundaries we should watch out for so we aren't arguing over "well why not make Fedora a rebuild of Debian using a deb2rpm tool since they already are LTS" and other people saying why not -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Lifecycles: imagine longer-term possibilities
Hi everyone! Let's talk about something new and exciting. Since its first release fifteen years ago, Fedora has had a 13-month lifecycle (give or take). That works awesomely for many cases (like, hey, we're all here), but not for everyone. Let's talk about how we might address some of the users and use cases we're missing out on. When I talk to people about this, I often get "hey, you should do LTS or go to rolling releases.” As I've said before, on the surface that's a weird thing to say, since the actual user impact of those two different things is mostly _opposite_. So, digging in, it often really means "I don't want the pain and fear of big OS upgrades". We've addressed that in several ways: first, making upgrades better. (Thanks everyone who has worked on that.) A Fedora release-to-release update is normally not much more trouble than you might get some random Tuesday with a rolling release. Second, we have some things like Fedora Atomic Host and upcoming Fedora CoreOS and IoT which both implement a rolling stream on top of the Fedora release base. And finally, there's the coming-someday plans for gating Rawhide, making that a better proposition for people who really want to live on the edge. But there are some good cases for a longer lifecycle. For one thing, this has been a really big blocker for getting Fedora shipped on hardware. Second, there are people who really could be happily running Fedora but since we don't check the tickbox, they don't even look at us seriously. I'd love to change these things. To do that, we need something that lasts for 36-48 months. So, what would this look like? I have some ideas, but, really, there are many possibilities. That's what this thread is for. Let's figure it out. How would we structure repositories? How would we make sure we're not overworked? How would we balance this with getting people new stuff fast as well? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Rawhide-20181113.n.0 compose check report
On Tue, 2018-11-13 at 15:00 +, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 90/142 (x86_64), 24/24 (i386), 1/2 (arm) > > New failures (same test did not fail in Rawhide-20181112.n.0): Pretty much every failure today was caused by: https://bugzilla.redhat.com/show_bug.cgi?id=1649531 some fairly innocuous-looking memory leak fixes in kbd somehow result in no characters being shown on consoles. You can only see the cursor, and color codes. Everything *works*, you just can't *see* it. This breaks just about every openQA test as they all try to switch to a console and do something at some point or other, and expect to be able to 'see' what they're typing. For now I've done a new kbd with the changes dropped, and a new Rawhide is running. We've been fighting constantly to get a more-or-less fully working Rawhide compose out for the last week or two, I'm hoping this one will finally do the trick. -- 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 release retrospective
Hi all, Due to requests from folks on the North America west coast, I've changed the time of the retrospective to 11am Eastern (1600 UTC). The meeting will still be in https://meet.jit.si/GuiltyCherriesSearchLoyally with notes taken in #fedora-meeting-2 (this is a change). I apologize for the short notice. Here are topics that I have received. Please let me know if there are other topics you want to see discussed. * Unannounced changes to core packages * "Go" decision despite bugs with updates -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow wrote: > > On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote: > > It wasn't a random rebase. A FESCo ticket was submitted and > > approved[1]. However, there was a miscommunication that led to the > > DNF > > team not being aware it happened. > > > > [1]: https://pagure.io/fesco/issue/2009 > > This was not approved - there was a -1 vote and so it was planned to be > discussed in the next meeting. I commented the ticket, but I will copy my response here: there was no single -1 within a week after opening a ticket so to my knowledge the ticket was approved. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Tue, Nov 13, 2018 at 7:49 PM Peter Robinson wrote: > > On Mon, Nov 12, 2018 at 3:35 PM Jaroslav Mracek wrote: > > > > Hello everyone, > > > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > > and 29. This release could affect not only libsolv users, but also libdnf, > > PackageKit, microdnf, or dnf related applications. > > I would like to ask everyone for intensive testing and reporting any issues > > concerning the rebase. > > How did this this happen? It's kind of strange that people weren't > aware this was happening, what is some auto "git merge master" > mistake. It's a fairly big problem to "accidentally" rebase to a major > new release and not realise it was happening, especially on something > so core as core updates infrastructure. What sort of things are you > going to put in place to ensure random rebases don't just happen > again? It is not random rebase, there was even FESCo ticket. > Peter > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Mon, Nov 12, 2018 at 4:45 PM Jaroslav Mracek wrote: > > Hello everyone, > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > and 29. This release could affect not only libsolv users, but also libdnf, > PackageKit, microdnf, or dnf related applications. libdnf, PK, microdnf and dnf **are** libsolv users. > I would like to ask everyone for intensive testing and reporting any issues > concerning the rebase. There is nothing in Fedora which is using any of functionality which was changed in incompatible way (except for zypper which we handled carefully with Neal Gompa in the same update). If there won't be SONAME change, it would be released as 0.6.36 and no one would notice any changes after rebase. > Thanks a lot for your help > > Jaroslav > on behalf of DNF team > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote: > It wasn't a random rebase. A FESCo ticket was submitted and > approved[1]. However, there was a miscommunication that led to the > DNF > team not being aware it happened. > > [1]: https://pagure.io/fesco/issue/2009 This was not approved - there was a -1 vote and so it was planned to be discussed in the next meeting. 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Tue, Nov 13, 2018 at 1:42 PM Peter Robinson wrote: > > On Mon, Nov 12, 2018 at 3:35 PM Jaroslav Mracek wrote: > > > > Hello everyone, > > > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > > and 29. This release could affect not only libsolv users, but also libdnf, > > PackageKit, microdnf, or dnf related applications. > > I would like to ask everyone for intensive testing and reporting any issues > > concerning the rebase. > > How did this this happen? It's kind of strange that people weren't > aware this was happening, what is some auto "git merge master" > mistake. It's a fairly big problem to "accidentally" rebase to a major > new release and not realise it was happening, especially on something > so core as core updates infrastructure. What sort of things are you > going to put in place to ensure random rebases don't just happen > again? It wasn't a random rebase. A FESCo ticket was submitted and approved[1]. However, there was a miscommunication that led to the DNF team not being aware it happened. [1]: https://pagure.io/fesco/issue/2009 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Mon, Nov 12, 2018 at 3:35 PM Jaroslav Mracek wrote: > > Hello everyone, > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > and 29. This release could affect not only libsolv users, but also libdnf, > PackageKit, microdnf, or dnf related applications. > I would like to ask everyone for intensive testing and reporting any issues > concerning the rebase. How did this this happen? It's kind of strange that people weren't aware this was happening, what is some auto "git merge master" mistake. It's a fairly big problem to "accidentally" rebase to a major new release and not realise it was happening, especially on something so core as core updates infrastructure. What sort of things are you going to put in place to ensure random rebases don't just happen again? Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 29.20181113.0
On Tue, Nov 13, 2018 at 10:14 PM wrote: > > A new Fedora Atomic Host update is available via an OSTree update: > > Version: 29.20181113.0 > Commit(x86_64): > 89bfa708d349a5856cc5cd3be441c07e1f96d0be2aa97e2b676f6004e7f6abed > Commit(aarch64): > d0e58aa379b37a39fd5e29b8d87d747b5a3a6aeaef91de751f7abd39fbbe2d51 > Commit(ppc64le): > d8c4215c936a5e064dc4f1c9dbde5f08f77535995a7b3eddfed1fe2bad784a45 > > > We are releasing images from multiple architectures but please note > that x86_64 architecture is the only one that undergoes automated > testing at this time. > > Existing systems can be upgraded in place via e.g. `atomic host upgrade`. > > Corresponding image media for new installations can be downloaded from: > > https://getfedora.org/en/atomic/download/ > > Alternatively, image artifacts can be found at the following links: > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0.aarch64.qcow2 > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0.aarch64.raw.xz > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20181113.0.iso > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0.ppc64le.qcow2 > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0.ppc64le.raw.xz > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20181113.0.iso > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0.x86_64.qcow2 > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0.x86_64.raw.xz > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20181113.0.x86_64.vagrant-libvirt.box > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20181113.0.x86_64.vagrant-virtualbox.box > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20181113.0.iso > > Respective signed CHECKSUM files can be found here: > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0-aarch64-CHECKSUM > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20181113.0-aarch64-CHECKSUM > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0-ppc64le-CHECKSUM > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20181113.0-ppc64le-CHECKSUM > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0-x86_64-CHECKSUM > > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20181113.0-x86_64-CHECKSUM > > For direct download, the "latest" targets are always available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest > https://getfedora.org/atomic_raw_x86_64_latest > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest > https://getfedora.org/atomic_dvd_ostree_x86_64_latest > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest > https://getfedora.org/atomic_raw_aarch64_latest > https://getfedora.org/atomic_dvd_ostree_aarch64_latest > > ppc64le: > https://getfedora.org/atomic_qcow2_ppc64le_latest > https://getfedora.org/atomic_raw_ppc64le_latest > https://getfedora.org/atomic_dvd_ostree_ppc64le_latest > > Filename fetching URLs are available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest_filename > https://getfedora.org/atomic_raw_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename > https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest_filename > https://getfedora.org/atomic_raw_aarch64_latest_filename > https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filenam
Re: Ursa Major (modules in buildroot) enablement
Dne 05. 11. 18 v 16:22 Justin Forbes napsal(a): > It > is possible that some of this could be alleviated with a fairly simple > change to mock. There is no need for a change in Mock. Mock can consume modules for looong time. You can put in mock config something like: # This is executed just before 'chroot_setup_cmd'. config_opts['module_enable'] = ['list', 'of', 'modules'] config_opts['module_install'] = ['module1/profile', 'module2/profile'] This will enable and install the module in buildroot and make the RPMs available in buildroot. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Atomic Host Two Week Release Announcement: 29.20181113.0
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20181113.0 Commit(x86_64): 89bfa708d349a5856cc5cd3be441c07e1f96d0be2aa97e2b676f6004e7f6abed Commit(aarch64): d0e58aa379b37a39fd5e29b8d87d747b5a3a6aeaef91de751f7abd39fbbe2d51 Commit(ppc64le): d8c4215c936a5e064dc4f1c9dbde5f08f77535995a7b3eddfed1fe2bad784a45 We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time. Existing systems can be upgraded in place via e.g. `atomic host upgrade`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Alternatively, image artifacts can be found at the following links: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20181113.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20181113.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20181113.0.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20181113.0.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20181113.0.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20181113.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20181113.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20181113.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20181113.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20181113.0-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20181113.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20181113.0-x86_64-CHECKSUM For direct download, the "latest" targets are always available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest https://getfedora.org/atomic_raw_x86_64_latest https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest https://getfedora.org/atomic_dvd_ostree_x86_64_latest aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest https://getfedora.org/atomic_raw_aarch64_latest https://getfedora.org/atomic_dvd_ostree_aarch64_latest ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest https://getfedora.org/atomic_raw_ppc64le_latest https://getfedora.org/atomic_dvd_ostree_ppc64le_latest Filename fetching URLs are available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest_filename https://getfedora.org/atomic_raw_x86_64_latest_filename https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest_filename https://getfedora.org/atomic_raw_aarch64_latest_filename https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest_filename https://getfedora.org/atomic_raw_ppc64le_latest_filename https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam
[Modularity] Working Group IRC meeting minutes (2018-11-13)
= #fedora-meeting-3: Weekly Meeting of the Modularity Working Group = Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-11-13/modularity_wg.2018-11-13-15.04.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2018-11-13/modularity_wg.2018-11-13-15.04.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-11-13/modularity_wg.2018-11-13-15.04.log.html Meeting summary --- * Roll Call (nils, 15:04:39) * Agenda (nils, 15:05:33) * [asamalik] Module lifecycles (nils, 15:06:14) * [asamalik] Stream default changes & Fedora Changes (nils, 15:06:27) * [asamalik] Stream branch ownership for packages & modules (nils, 15:06:50) * [ignatenkobrain/sgallagh] How do we keep rawhide sane? (re: forcing people to latest modules) (nils, 15:07:33) * Module lifecycles (nils, 15:08:17) * LINK: https://pagure.io/modularity/issue/112 (asamalik, 15:08:35) * This is a follow-up of a recent (well, a month ago?) threads on the Devel list about how we define and manage module lifecycles, containing a proposal and input from those threads in it (asamalik, 15:10:02) * Stream default changes & Fedora Changes (nils, 15:14:48) * LINK: https://pagure.io/modularity/issue/114 (nils, 15:15:40) * Likely the least complex topic of the four we have today. I have a very short proposal there, already two +1's from bcotton and sgallagh (asamalik, 15:16:11) * we'll give it more time for people to give their +1's and -1's on this one (asamalik, 15:25:14) * Stream branch ownership for packages & modules (nils, 15:25:54) * LINK: https://pagure.io/modularity/issue/115 (nils, 15:26:03) * A specific proposal regarding stream branch ownership. Already includes some input from recent (a month ago?) discussion about managing module lifecycles on the Devel list. (asamalik, 15:26:59) * How do we keep rawhide sane? (re: forcing people to latest modules) (reprise) (nils, 15:44:15) * LINK: https://pagure.io/modularity/issue/108 (nils, 15:44:37) * we'll continue the discussion in the ticket (asamalik, 15:51:35) Meeting ended at 15:54:52 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * asamalik (73) * nils (44) * zodbot (19) * langdon (18) * contyk (12) * sgallagh (6) * ignatenkobrain (2) * bcotton (2) * mikedep333 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Monday's FESCo Meeting (2018-11-12)
On Sat, 2018-11-10 at 12:41 -0500, Randy Barlow wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > irc.freenode.net. We did not reach quorum yesterday, so the meeting was canceled. 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20181113.n.0 compose check report
No missing expected images. Failed openQA tests: 90/142 (x86_64), 24/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20181112.n.0): ID: 308260 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/308260 ID: 308266 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/308266 ID: 308267 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/308267 ID: 308272 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308272 ID: 308273 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308273 ID: 308274 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308274 ID: 308275 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/308275 ID: 308276 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/308276 ID: 308277 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308277 ID: 308287 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308287 ID: 308290 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308290 ID: 308291 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/308291 ID: 308294 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/308294 ID: 308295 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308295 ID: 308296 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/308296 ID: 308301 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/308301 ID: 308307 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/308307 ID: 308310 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/308310 ID: 308311 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308311 ID: 308313 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308313 ID: 308314 Test: x86_64 Silverblue-dvd_ostree-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/308314 ID: 308321 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/308321 ID: 308323 Test: x86_64 universal install_multi URL: https://openqa.fedoraproject.org/tests/308323 ID: 308324 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/308324 ID: 308325 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/308325 ID: 308326 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/308326 ID: 308327 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/308327 ID: 308330 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/308330 ID: 308331 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/308331 ID: 308333 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/308333 ID: 308335 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/308335 ID: 308337 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/308337 ID: 308339 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/308339 ID: 308340 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/308340 ID: 308341 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/308341 ID: 308342 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/308342 ID: 308347 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/308347 ID: 308348 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/308348 ID: 308349 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/308349 ID: 308350 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/308350 ID: 308351 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/308351 ID: 308352 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/test
Re: Orphaning/Intent to orphan the entire pulp stack
On Tue, 13 Nov 2018 at 09:39, Patrick Creech wrote: > > On Tue, 2018-11-13 at 07:56 +0100, Miro Hrončok wrote: > > On 12. 11. 18 22:37, Patrick Creech wrote: > > > The pulp team is orphaning the pulp 2 stack in fedora's repositories. > > > > > > The upstream project is focusing the majority of it's development efforts > > > on pulp 3, and is removing fedora support for the pulp 2 line. > > > > > > This will also assist other package's transitions to python 3 only, as > > > there have been cases where pulp prevented them from dropping python 2 in > > > fedora. > > > > If you orphan it, but not retire it, it won't help much. > > Ah, I was under the (possibly incorrect?) assumption that orphaning was the > beginning step in retiring? > > The resources I saw really only said that to retire it had to be orphaned, or > at least that's what I gleaned from those articles. > > Thoughts on how to proceed, since a good portion are already 'orphaned', and > the rest are waiting on action from the other 'owner' > It is usually correct when you have software which can be kept up by someone else. If the code is dead and to be replaced by another.. then retiring is correct. > > > Packages being orphaned: > > > - pulp > > > - pulp-rpm > > > - pulp-puppet > > > - pulp-ostree > > > - pulp-docker > > > - pulp-python > > > - python-crane > > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20181113.n.0 changes
OLD: Fedora-Rawhide-20181112.n.0 NEW: Fedora-Rawhide-20181113.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 9 Dropped packages:1 Upgraded packages: 173 Downgraded packages: 1 Size of added packages: 93.32 MiB Size of dropped packages:495.07 KiB Size of upgraded packages: 2.36 GiB Size of downgraded packages: 39.55 MiB Size change of upgraded packages: 111.49 MiB Size change of downgraded packages: 13.37 KiB = ADDED IMAGES = Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20181113.n.0.aarch64.raw.xz Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20181113.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20181113.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: mod_psgi-0.0.1-0.1.20120822git9732348.fc30 Summary: Apache httpd plugin for handling PSGI applications RPMs:mod_psgi Size:150.62 KiB Package: perl-Net-IMAP-Client-0.9505-1.fc30 Summary: IMAP client library for Perl RPMs:perl-Net-IMAP-Client Size:52.38 KiB Package: php-doctrine-event-manager-1.0.0-1.fc30 Summary: Simple PHP event system RPMs:php-doctrine-event-manager Size:11.63 KiB Package: php-doctrine-persistence-1.0.1-1.fc30 Summary: Doctrine Persistence abstractions RPMs:php-doctrine-persistence Size:29.78 KiB Package: php-doctrine-reflection-1.0.0-1.fc30 Summary: Additional reflection functionality RPMs:php-doctrine-reflection Size:15.26 KiB Package: python-fsleyes-0.26.4-1.fc30 Summary: FSLeyes, the FSL image viewer RPMs:python-fsleyes-doc python3-fsleyes Size:32.49 MiB Package: python-indexed_gzip-0.8.7-1.fc30 Summary: Fast random access of gzip files in Python RPMs:python3-indexed_gzip Size:1.97 MiB Package: python-pybids-0.6.5-2.gite35ced6.fc30 Summary: Interface with datasets conforming to BIDS RPMs:python-pybids-doc python3-pybids Size:9.14 MiB Package: rofi-1.5.1-6.fc30 Summary: A window switcher, application launcher and dmenu replacement RPMs:rofi rofi-devel rofi-devel-doc rofi-themes Size:49.46 MiB = DROPPED PACKAGES = Package: lekhonee-0.7-17.fc29 Summary: A blog client RPMs:lekhonee lekhonee-lib Size:495.07 KiB = UPGRADED PACKAGES = Package: CuraEngine-1:3.5.1-1.fc30 Old package: CuraEngine-1:3.4.1-1.fc30 Summary: Engine for processing 3D models into G-code instructions for 3D printers RPMs: CuraEngine Size: 4.19 MiB Size change: 125.09 KiB Changelog: * Mon Nov 12 2018 Miro Hron??ok - 0:3.5.1-2 - Update to 3.5.1 (#1644323) * Mon Nov 12 2018 Miro Hron??ok - 1:3.5.1-1 - Fix the error in epoch/release Package: almanah-0.11.1-22.fc30 Old package: almanah-0.11.1-21.fc29 Summary: Application for keeping an encrypted diary RPMs: almanah Size: 1.57 MiB Size change: -28.11 KiB Changelog: * Mon Nov 12 2018 Milan Crha - 0.11.1-22 - Rebuilt for evolution-data-server soname bump Package: android-file-transfer-3.7-1.fc30 Old package: android-file-transfer-3.6-1.fc30 Summary: Reliable Android MTP client with minimalist UI RPMs: android-file-transfer Size: 2.18 MiB Size change: 1.56 KiB Changelog: * Mon Nov 12 2018 Marek Blaha - 3.7-1 - New upstream release 3.7 Package: bird-2.0.2-2.fc30 Old package: bird-1.6.3-8.fc29 Summary: BIRD Internet Routing Daemon RPMs: bird bird-doc Dropped RPMs: bird6 Size: 2.37 MiB Size change: -1.27 MiB Changelog: * Mon Nov 12 2018 Stanislav Kozina - 2.0.2-1 - update to 2.0.2 (#1524385) * Mon Nov 12 2018 Stanislav Kozina - 2.0.2-2 - Run bird under bird user and group rather than root (#1397574) Package: blosc-1.14.4-1.fc30 Old package: blosc-1.14.3-1.fc29 Summary: High performance compressor optimized for binary data RPMs: blosc blosc-bench blosc-devel Size: 506.22 KiB Size change: -19.14 KiB Changelog: * Mon Nov 12 2018 Zbigniew J??drzejewski-Szmek - 1.14.4-1 - Update to latest version (#1609768) Package: buildah-1.5-6.dev.gitfb2b2bd.fc30 Old package: buildah-1.5-5.dev.git9add3c8.fc30 Summary: A command line tool used for creating OCI Images RPMs: buildah Size: 23.43 MiB Size change: -84 B Changelog: * Tue Nov 13 2018 Lokesh Mandvekar (Bot) - 1.5-6.dev.gitfb2b2bd - autobuilt fb2b2bd Package: caribou-0.4.21-13.fc30 Old package: caribou-0.4.21-12.fc29 Summary: A simplified in-place on-screen keyboard RPMs: caribou caribou-antler caribou-devel caribou-gtk2-module caribou-gtk3-module python3-caribou Dropped RPMs: python2-caribou Size: 1.34 MiB Size change: -102.91 KiB Changelog: * Mon Nov 12 2018 Miro Hron??ok - 0.4.21-13 - Remove python2 subpackage (#1628174) Package: cinnamon-4.0.1-1.fc30 Old package: cinnamon-4.0.0-1.fc30 Summary
Re: Orphaning/Intent to orphan the entire pulp stack
> Thoughts on how to proceed, since a good portion are already 'orphaned', and > the rest are waiting on action from the other 'owner' I did a little more digging this morning, and found the retire steps. I have retired on master the same packages listed below. Apologies for the confusion. > > > Packages being orphaned: > > > - pulp > > > - pulp-rpm > > > - pulp-puppet > > > - pulp-ostree > > > - pulp-docker > > > - pulp-python > > > - python-crane ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning/Intent to orphan the entire pulp stack
On Tue, 2018-11-13 at 07:56 +0100, Miro Hrončok wrote: > On 12. 11. 18 22:37, Patrick Creech wrote: > > The pulp team is orphaning the pulp 2 stack in fedora's repositories. > > > > The upstream project is focusing the majority of it's development efforts > > on pulp 3, and is removing fedora support for the pulp 2 line. > > > > This will also assist other package's transitions to python 3 only, as > > there have been cases where pulp prevented them from dropping python 2 in > > fedora. > > If you orphan it, but not retire it, it won't help much. Ah, I was under the (possibly incorrect?) assumption that orphaning was the beginning step in retiring? The resources I saw really only said that to retire it had to be orphaned, or at least that's what I gleaned from those articles. Thoughts on how to proceed, since a good portion are already 'orphaned', and the rest are waiting on action from the other 'owner' > > Packages being orphaned: > > - pulp > > - pulp-rpm > > - pulp-puppet > > - pulp-ostree > > - pulp-docker > > - pulp-python > > - python-crane > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream tip wanted: CI service for Big Endian acrhes
I just created the topic on Travis community page. https://travis-ci.community/t/multiarch-testing-tips/862 Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
> Please do not drag Go into this if you want to handwave Go away > problems. Yes modules will be useful in Go but only to blow away in EPEL > the rotten Go codebase RHEL ships. > > But anyway, since you referred to GO. > > Go is the perfect example of why bundling as a general approach does not > work and does not scale. In case you haven't noticed years of bundling > Go side has resulted in such a deep widespread rot Google is scrambling > to write a Go v2 language version that will force Go projects to version > and update. > > All the people that claim bundling allows “using a slightly older > version” (implying it's a good safe maintained older version) are lying > through their teeth. Yes it allows doing that but that's not how people > use it. And it does not matter if you bundle via self-provided windows > DLLS, containers, flatpacks, modules or rhel versions. > > Bundling basically allows reusing third party code blindly without any > form of audit or maintenance. You take third party code, you adapt your > code to its current API, and you forget about it. > > You definitely *not* check it for security legal or other problems, you > definitely *not* check regularly if CVEs or updates have been released, > you definitely *not* try to maintain it yourself. Any bundler dev that > tells you otherwise lies. The average bundler dev will tell you “Look at > my wonderful up to date award-wining modern code, security problems? Ah, > that, not my code, I bundle it, not my problem”. > > It is however a *huge* problem for the people on the receiving end of > the resulting software, static builds or not. Static builds do not add > missing new features or fix security holes. They just remove the shared > libs that could be used by the sysadmin use to track them. And since > malware authors do not bother identifying how software was compiled, > before attempting to exploit it, static builds do not hinder them the > slightest. > > While trying to improve Go packaging in Fedora by myself I found serious > old security issues in first-class Go code. First-class as in benefiting > from huge publicised ongoing dev investments from major companies like > Google, Red Hat or Microsoft. It’s not hard, you do not even need to > write Go code, just take the bundled pile of components those bundle, > and read the upstream changelog of those components for later versions. > You will hit pearls like “emergency release because of *** CVE”. Or > “need to change the API to fix a race in auth token processing”. And the > answer of the projects that bundled a previous state of this code was > never “we have a problem” or “we have fixed it some other way” but “go > away, we haven’t planned to look or touch this code before future>”. > > And, again, I’m no Go dev, or dev in general, I didn’t even try any form > of systematic audit, that was just the bits jumping to attention when I > hit API changes and had to look at the code history to try to figure > when they occurred. The day any bundled codebase is subjected to the > kind of herd security research java was some years ago and CPUs are > today sparks are going to fly all over the place. > > And this is a natural phenomenon trivial to explain. Maintaining old > code versions is hard. Upstreams are not interested in supporting you. > You have to redo their work by yourself, while forbidding yourself API > changes (if you were ready to accept them you wouldn't have bundled in > the first place). And modern code is so deeply interdependent, freeze > one link in the dependency web and you get cascading effects all other > the place. You quickly end up maintaining old versions of every single > link in this web. If you try to do it seriously, you effectively have to > fork and maintain the whole codebase. IE all the no-support problems of > barebones free software, with none of the community friends help that > should come with it. > > That's what RH tries to do for EL versions. It takes a *huge* dev > investment to do in a semi-secure no-new features way. And after a > decade, RH just dumps the result, because even with all those efforts, > it reaches terminal state and has no future. > > There is only one way to maintain cheaply lots of software components > that call each other all over the place. That’s to standardise on the > latest stable release of each of them (and when upstream does not > release, the latest commit). And aggressively port everything to the > updates of those versions when they occur. If you are rich, maintain a > couple of those baselines, maximum. flatpackers do not say otherwise > with their frameworks (except I think they deeply underestimate the > required framework scope). > > And sure, every once in a while, porting takes consequent effort, it can > not be done instantaneously, devs are mobilized elsewhere, etc. That's > when you use targeted compat packages, to organise the porting effort, > to push the bits already ported while keeping t
[modularity] Contribute to Modularity architecture discussions
Just to make sure this reaches all interested parties, we have some important discussions about Modularity going on in Pagure tickets: Distribution Upgrades (reaching decision) — Handling modules, streams, and defaults during major distribution upgrades. * Tracker: https://tree.taiga.io/project/modularity-wg/epic/27 * Discussion: https://pagure.io/modularity/issue/108 Module Lifecycles in General (proposal) — The general concept of defining and managing module lifecycles. * Tracker: https://tree.taiga.io/project/modularity-wg/epic/3 * Discussion: https://pagure.io/modularity/issue/112 Defaults & Fedora Changes (proposal) — Communicating major changes in the distribution introduced by new module stream defaults. * Tracker: https://tree.taiga.io/project/modularity-wg/epic/35 * Discussion: https://pagure.io/modularity/issue/114 Branch Ownership (proposal) — Making sure that package and module owners are clearly defined and relevant processes are in place. * Tracker: https://tree.taiga.io/project/modularity-wg/epic/4 * Discussion: https://pagure.io/modularity/issue/115 Cheers! Adam -- Adam Šamalík --- Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Golang review swaps
On Mon, Nov 12, 2018 21:05:19 +0100, Robert-André Mauchin wrote: > Hi, Hi Robert, > i need help reviewing these packages: > > - golang-contrib-opencensus-exporter https://bugzilla.redhat.com/ > show_bug.cgi?id=1649059 > - golang-github-census-instrumentation-opencensus-proto https:// > bugzilla.redhat.com/show_bug.cgi?id=1649058 > > There are simple Golang packages, I'll swap with anything in exchange. > I'll take them both up. Would you be able to review python-brian2 in exchange please? https://bugzilla.redhat.com/show_bug.cgi?id=1649127 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
