is this update stuck? Ceph-14.2.3-1.fc32
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f5be50fd9 Two other ceph updatest submitted around the same time moved to testing okay. If it is stuck, can someone with appropriate privs please kick it. Thanks, -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
W dniu 10.09.2019 o 06:47, Raphael Groner pisze: > Hi, > >> My package requires libxslt. > > You're obviously not alone with this issue. The better question is *why* the > package as a commonly used library got orphaned, propably silently without > warning (at least I can not find any announcement, officially). > > Regards > Raphael https://bugzilla.redhat.com/show_bug.cgi?id=1738016 Best regards, Julian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
Hi, > My package requires libxslt. You're obviously not alone with this issue. The better question is *why* the package as a commonly used library got orphaned, propably silently without warning (at least I can not find any announcement, officially). Regards Raphael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 12:44:42 PM MST DJ Delorie wrote: > "vvs vvs" writes: > > > Ok, now I see that Fedora is just for activists. If I'm not one of > > them then I don't deserve any possibility to use it and should blame > > myself. Thanks for explaining it to me. > > > I think you're overreacting a bit, but there is some truth in this. > Fedora is created and maintained by the community. You are part of the > community. If enough of the community shares your needs, some fraction > of those will step up to do the work, and you all benefit. If your > needs aren't shared by enough of the community, either you need to do it > all yourself (or pay someone to act on your behalf), or your needs will > never get met. > > This has nothing to do with "deserve" or "blame" - it's just numbers. > Most people have switched to 64-bit, so most work is done for 64-bit, > even if not all the 64-bit users are also contributors. > > The 32-bit community has shrunk to the point where there aren't enough > contributors to keep the builds building and the fixes fixing, and there > are real problems backing up because of that, even if they don't affect > you personally. When there are enough problems and no contributors, > what other choice do we have? It's broken and nobody is fixing it. > > Thus comes the hard part of any project - put up or shut up. Harsh, but > it's the root of how things get done - they get done by people doing > them. Do or do not, there is no sit-on-the-mailing-list-and-hope. > > Back when I started the DJGPP project, I had to do everything myself. > The community grew and there were lots of contributors. Then the > community shrunk until we're back down to 2 people doing all the work. > Thus is the cycle of projects, but I don't complain that not enough > people are still using DOS :-) > > OTOH you won't hurt our feelings if you switch distros. Go where your > community is ;-) While most users on Intel/AMD based systems are now running x64 kernels, most proprietary software released for various GNU/Linux distros are 32 bit. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 1:00:51 PM MST Anderson, Charles R wrote: > On Mon, Sep 09, 2019 at 07:57:20PM -, vvs vvs wrote: > > > Well, thanks for sharing. > > > > I'm not complaining that nobody wants to fix things for me. I'm > > complaining because there is no possibility to fix things myself. After > > removing i686 repository I'm either should start building it myself or > > switch to another distribution. I'm not trying to hurt anyone's feelings, > > I just have no other choice. If there is no possibility to keep that > > repository than it's fine, but I was not convinced that there are other > > reasons for that decision aside bureaucratic ones and lack of empathy. If > > putting that repository on some optional host for anyone to be able to > > fix it themselves would severely harm the project then I was wrong all > > along and I'm really sorry. > > If you don't care about i686 not being "supported" but just want to have > access to the repositories so you can use/fix them yourself, then why don't > you just keep running Fedora 30 or 29 forever? The old bits will always be > there (moved to archive/ directory) and you can keep using them. Please do not suggest things like that. That would mean that security updates are not provided, bug fixes never make it in, and so on. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 12:09:49 PM MST vvs vvs wrote: > Ok, now I see that Fedora is just for activists. If I'm not one of them then > I don't deserve any possibility to use it and should blame myself. Thanks > for explaining it to me. Please don't let the hostilities of this list get to you, there are those of us in Fedora that want to help users like you. I'm one of them, and I'd be more than happy to step up to the plate and get to work on "supporting" x86 based systems. I've got systems shipping out to me now from my old location. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 11:58:08 AM MST vvs vvs wrote: > I would argue that it might be difficult to distinguish work needed to find > out if it was i686 specific when there already is similar bug on x86_64. > Also, it's difficult to rate bug importance for most users. As I've already > said that I was completely satisfied with the status quo and it was a big > surprise for me to discover that I just won't be able to upgrade to the > next version. Also, this discovery was purely accidental because there is > no announcements anywhere I could see. > Anyway, I would be prepared to fix things myself if such possibility was > given to me. But alas there is no choice now. Agreed, most bugs that affect x86 also support x64. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 8:36:45 AM MST vvs vvs wrote: > There is no either right or wrong stance here. We are discussing possible > alternatives to "just drop it" attitude. > What work should be done? Please, be more specific. Right now I'm running a > i686 userland and it works. If I would be able to build the whole > repository myself I'm pretty sure that most things will still work. If it > won't work I might try to fix it and contribute patches back. But without > that repository I can't even try it in the first place. > You are just pushing me and others away, so we should go use other > distributions which provide ready to run builds. And I'm not talking about > i686 *kernel* anywhere. We are talking about *userland* only. I'm running > 64-bit CPU all along, but I have limited memory. Others could use laptops > with restricted memory which would be a performance hit if they start using > x86_64 userland. > You are not providing any alternative but starting to build everything > ourselves or stop using Fedora and move elsewhere. There's no reason to drop x86 kernel builds either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: translucent gnome top bar gone in F31?
On Monday, September 9, 2019 8:51:48 AM MST Tomasz Torcz wrote: > On Mon, Sep 09, 2019 at 04:39:47AM -0700, John M. Harris Jr. wrote: > > > > > > > > > This is precisely the issue with GNOME entirely. It assumes the user > > > > shouldn't > > > > have a choice, that some designers know best. > > > > > > > > > > > > Yes, precisely *your* issue. I’d rather someone think for me as far as > > > defaults go and not give me a quest to set everything up just right > > > every time I install the DE. > > > > > > > > > Decisions such as this, inspired by the idea that *somebody* knows best, > > and it just works for everyone, are precisely why I won't be able to > > deploy RHEL 8 until KDE is available through EPEL or another repo. Heck, > > the only reason I can even run RHEL 8 on my test box is because I > > manually compiled KDE for it. > > This is incredibly common in GNOME, where people just make a decision and > > try to enforce it on the users. Things everyone hates, like moving the > > mouse into the top-left corner opening some weird menu, and the only way > > to disable it being third party software. (Something I've had to provide > > a fix by default for on my RHEL 7 deployments, where some of my users > > prefer GNOME), and where users request that I install gnome-tweak-tool > > for them so that they can make basic preference changes which just aren't > > available otherwise. > > > John, > > you personal opinions are not providing anything valuable in this > thread. This went offtopic too much, bordering on insults. > Please keep our mailling list productive and civilised. On a topic where the decision will be based entirely on opinions, I fail to see how opinions are not relevant. Further, nothing in that email is what I would describe as "uncivilized". I'm not asking people to necessarily agree with me, everyone is welcome to their own opinions, I simply provided mine and that of the users I work with. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 10:29:23 AM MST Bruno Wolff III wrote: > On Mon, Sep 09, 2019 at 14:52:07 -, > vvs vvs wrote: > > >May be there are more interested people that we know, but they are not > >reading that list. There will just be just every man for himself and > >Fedora has failed to recognize that. > >This requires time and effort too. Nobody will appear just by a miracle. I > >recognize that there is much less people interested in this architecture > >but it's much more than zero. > > I'm probably one of the few people still running Fedora on a machine that > uses i686, that can't use x86_64. The machine is around 15 years old and is > costly to get replacement parts for and I'm running out of spares. I was > supposed to replace the machine last month, but needed another month to > save up enough to buy the rest of the replacement. I've actually work with > upstream to get kernel bugs fixed for this machine. > > Unfortunately I run rawhide and things got shut down a little sooner > than I hoped, so I'm not getting updates right now and don't want to go > back to f30 with the short horizon for retirement (though I did grab an > f30 kernel). > > I don't think you are going to find many people who both run Fedora and > have to use i686. > > There is a cost to keeping things running on i686 and it doesn't look like > it is worth paying right now. And things are looking to get worse rather > than better. > > You have options. You can switch to another distro that will support i686 > for a while yet. Use f30 until it's EOL (or beyond if the machines are > isolated). Or maintain your own distro. The tools for Fedora are open, > so you could set up your own koji instance drawing from Fedora and applying > your fixes where needed. Getting started will probably be hard, but once > things are running you'll be OK until there is a key bug you can't get > fixed. There are at least 4 people in this thread alone that are running Fedora on x86 systems. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 6:42:35 AM MST Solomon Peachy wrote: > On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote: > > The system I'm sending this email from only has 4 GiB of memory in > > total. Does that mean that this system makes ASLR completely > > ineffective? Should this arch also be removed from Fedora, because of > > that? > > *Address Space* is not the same as *Physical Memory*. > > I suggest you educate yourself on the difference between the two, as > that distinction is perhaps the fundamental underpinning of memory > management. > > - Solomon I don't think you understand what I was getting at. Cheap joke, essentially. ASLR is only one part of the many layers of security in modern systems. It's not worth getting rid of support for one of the most popular architectures just because ASLR may be slightly less effective than on other architectures. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On Mon, Sep 09, 2019 at 11:49:17PM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via releng issues: > https://pagure.io/releng/issues > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-09-09.txt > grep it for your FAS username and follow the dependency chain. > > Package (co)maintainers Status > Change > > libxslt orphan, veillard 0 weeks ago My package requires libxslt. My understanding is that, this changed status '0 weeks ago' which means I have ~ 6 weeks to find a solution ... other than maintaining xslt ;P Is that right? Just trying to work out how much panic to feel ;P Tony. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-09-10 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
I filed an issue offering to take this and a few others. Sent from ProtonMail mobile \ Original Message On Sep 9, 2019, 7:31 PM, < mcatanz...@gnome.org> wrote: > > > > On Mon, Sep 9, 2019 at 4:49 PM, Miro Hrončok > <[mhron...@redhat.com][mhroncok_redhat.com]> > wrote: > > libxslt orphan, veillard 0 > > weeks ago > > Looks pretty important, any takers? > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > devel mailing list -- > [devel@lists.fedoraproject.org][devel_lists.fedoraproject.org] > To unsubscribe send an email to > [devel-le...@lists.fedoraproject.org][devel-leave_lists.fedoraproject.org] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > [https://fedoraproject.org/wiki/Mailing\_list\_guidelines][https_fedoraproject.org_wiki_Mailing_list_guidelines] > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > [mhroncok_redhat.com]: mailto:mhron...@redhat.com [devel_lists.fedoraproject.org]: mailto:devel@lists.fedoraproject.org [devel-leave_lists.fedoraproject.org]: mailto:devel-le...@lists.fedoraproject.org [https_fedoraproject.org_wiki_Mailing_list_guidelines]: https://fedoraproject.org/wiki/Mailing_list_guidelines signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On Tue, 2019-09-10 at 02:41 +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > openvswitch aconole, chrisw, orphan, 0 weeks ago > > tgraf, tredaell > > This one is a dependency of NetworkManager, so surely it should not go away. > (Or is the plan to drop support for it from NM?) So can either one of the > existing comaintainers or the NM team please pick this up before some script > retires the entire distro? :-) openQA also requires it, so I need it not to go away. I don't really want to maintain it as I'm certainly no kind of SDN expert, but if no- one else picks it up I probably will in the end. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora-Rawhide-20190909.n.1 compose check report
On Mon, 2019-09-09 at 14:14 +, Fedora compose checker wrote: > No missing expected images. > > Compose FAILS proposed Rawhide gating check! > 21 of 45 required tests failed, 19 results missing > openQA tests matching unsatisfied gating requirements shown with **GATING** > below > Unsatisfied gating requirements that could not be mapped to openQA tests: > MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default > MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default > > Failed openQA tests: 76/152 (x86_64), 1/2 (arm) So what happened here (actually, in 20190906.n.2, but it affected all composes since then) is that someone decided to re-draw the symbolic 'keyboard' icon. Again. I swear it's been tweaked like five times this year, I dunno why. Anyway, openQA happens to use that (with two other icons) to spot when it's at the anaconda main hub. So that was failing, which meant every single install test failed (except the text mode install one). I've updated the needles and re-run the 201909.n.1 tests, and now the results look a lot like 20190905.n.0: we've got 124 passes, 6 soft fails, 17 fails, and 7 skipped tests. I didn't rerun the tests for the three composes in the middle, it didn't seem super important. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
Miro Hrončok wrote: > openvswitch aconole, chrisw, orphan, 0 weeks ago > tgraf, tredaell This one is a dependency of NetworkManager, so surely it should not go away. (Or is the plan to drop support for it from NM?) So can either one of the existing comaintainers or the NM team please pick this up before some script retires the entire distro? :-) 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On Mon, Sep 9, 2019 at 4:49 PM, Miro Hrončok wrote: libxslt orphan, veillard 0 weeks ago Looks pretty important, any takers? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 3:35 PM, vvs vvs wrote: I didn't answered your other question because I've answered the same question several times already. Yes, I have a use cases where I'll get a severe performance hit if I was not careful. And this is related to available memory and swapping. And I can't afford losing yet another hundred megabytes for no particular reason. And I don't think that constantly upgrading my computer is the answer. I remember times when it was possible to install Red Hat Linux on a computer with 32 MB of RAM. Going in that direction I should do nothing but upgrade every now and then even though I don't want my computer to affect my activities that hard. And some people thought that Windows 95 was a memory hog! In all your emails, you have never said that you've tried to use a 64-bit userspace. You keep making this claim that if you did you would lose "another hundred megabytes", but have you actually tried it? You can still run Linux in an extremely limited amount of RAM. I do it all the time with openwrt. But do you really want to go back to the level of functionality you had back then? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 3:35 PM, vvs vvs wrote: > So, you are insisting that Koji just doesn't work without any assistance? And > that it's impossible to build a separate i686 repository without affecting > all others? We used to build secondary architectures separately, using koji-shadow to chase the primary builds. This had plenty of problems of its own. You can read a bit below, and maybe others can provide more history. https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3BO5E2XZ2D7BHK7GQXZB5S37AQIUN6YP/#ZYYG7RP754ONDU4T7DVFQ5U6YAXWSH55 > And that you can't exclude that architecture for a specific package? You can, but if everyone gets free license to ignore i686, I think it won't be long before you find yourself without some key packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
Elliott Sales de Andrade writes: > On Mon, 9 Sep 2019 at 18:02, David Sommerseth wrote: >> >> On 09/09/2019 23:49, Miro Hrončok wrote: >> > The following packages are orphaned and will be retired when they >> > are orphaned for six weeks, unless someone adopts them. If you know for >> > sure >> > that the package should be retired, please do so now with a proper reason: >> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life >> >> [...snip...] >> >> > dsommers: python-which >> >> This surprises me quite a lot. I have never been a package maintainer for >> this package. >> > > It's not saying you're a package maintainer for this package. It's > saying you'll be affected by its orphaning. > > Search for python-which and you'll see it's because python-ethtool > depends on it, and you maintain _that_. As Jason L Tibbitts III noted on IRC, the "culprit" here is dblatex, which depends on python2-which and since gcc depends on dblatex, that drags in nearly everything. There is a pretty simple short term fix for this though: dblatex upstream has been bundling python-which for over a decade, which is being reverted in the Fedora package. Since python-which is dead upstream, I see it as the lesser evil to not patch the bundling. Also, dblatex will probably go away anyway, as was noted previously on this list (it does not appear to be dead though, there has been a bugfix release less than an hour ago). Cheers, Dan 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Oh, brother... So, you are insisting that Koji just doesn't work without any assistance? And that it's impossible to build a separate i686 repository without affecting all others? And that you can't exclude that architecture for a specific package? If that's the case then it's very different from what I already knew. I didn't answered your other question because I've answered the same question several times already. Yes, I have a use cases where I'll get a severe performance hit if I was not careful. And this is related to available memory and swapping. And I can't afford losing yet another hundred megabytes for no particular reason. And I don't think that constantly upgrading my computer is the answer. I remember times when it was possible to install Red Hat Linux on a computer with 32 MB of RAM. Going in that direction I should do nothing but upgrade every now and then even though I don't want my computer to affect my activities that hard. And some people thought that Windows 95 was a memory hog! Honestly, I'm tired. And I don't think that arguing further will be of any help. I'm convinced that I really have no other choice but just use some Linux distribution that doesn't requires me to spend so much time explaining to everyone why I need things in my life to be the way I need it. And it reminds me about some guy who maintains some quite popular software. He used some old SUSE until he was forced to upgrade. After struggling with consequences he just bought Apple computer with Mac OS. He explained that he is just too old to waste so much time on unimportant things. I don't remember his name. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On 9/9/19 4:49 PM, Miro Hrončok wrote: libxslt orphan, veillard 0 weeks ago This is a big one... @Daniel, can you take it over as primary maintainer? Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On Mon, 9 Sep 2019 at 18:02, David Sommerseth wrote: > > On 09/09/2019 23:49, Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know for sure > > that the package should be retired, please do so now with a proper reason: > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > [...snip...] > > > dsommers: python-which > > This surprises me quite a lot. I have never been a package maintainer for > this package. > It's not saying you're a package maintainer for this package. It's saying you'll be affected by its orphaning. Search for python-which and you'll see it's because python-ethtool depends on it, and you maintain _that_. > > -- > kind regards, > > David Sommerseth -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On 09/09/2019 23:49, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life [...snip...] > dsommers: python-which This surprises me quite a lot. I have never been a package maintainer for this package. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 2:15 PM, vvs vvs wrote: I said it already several times, that I don't need volunteers to fix things for me! I just need an already built repository which I could just use and fix things myself if needed. But Fedora is refusing to provide such repository which was built automatically by Koji. I don't care if something was broken in that repository as long as I can access those binaries and fix them if needed. But that's just it, there is no automatically built repository. And when there is a problem with a package not building for i686, it breaks it for everyone. You also didn't answer the question from my previous email: Have you even tried running the 64-bit version to see if it really has the problems you think it will? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
And if I don't use those packages, then why should I be unable to use everything else just because there are some small problems? Especially because there are not much users of that architecture anyway. That happens all the time already and I see no big problem with that. If these packages affect another architecture that would be a problem for them, but I think that decoupling unsupported repositories should solve that problem. That would be good anyway for a number of reasons. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
And why people are not reading all the answers? That was a rhethorical question. I said it already several times, that I don't need volunteers to fix things for me! I just need an already built repository which I could just use and fix things myself if needed. But Fedora is refusing to provide such repository which was built automatically by Koji. I don't care if something was broken in that repository as long as I can access those binaries and fix them if needed. But no matter how frequently I repeat it, I'm always get answers that I'm insisting that somebody should work for me. No I'm not. If it's so difficult to keep that repository around, then it's just fine with me and I'll find another way. But that would be very unfortunate. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to deprecate clalsadrv
I'm going to deprecate clalsadrv, because it has been deprecated and replaced by zita-alsa-pcmi upstream. Nothing depends on it in rawhide: dnf --disablerepo='*' --enablerepo=rawhide --enablerepo=rawhide-source repoquery --whatdepends clalsadrv --alldeps reports only clalsadrv-devel-0:2.0.0-20.fc31.i686 clalsadrv-devel-0:2.0.0-20.fc31.x86_64 FAS account: tartina Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
And I thought that should be obvious, silly me. Just kidding. Of course I would do it if there were no better choice. I'm just struggling to find out if there is no other possibility whatsoever. There might be reasons why Fedora is just unable to keep it updated that I don't know. And of course I could use another repository provided by some other distribution. I'm just trying to find out what are my options. I would prefer to keep using modern Fedora unless I'm forced not to. Just in case. There is no reason to believe that I'm upset or frustrated. That's just a conversation which might get heated at a time for various reasons which are not directly related to the subject. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 12:47 PM, vvs vvs wrote: I don't even know anyone whom I could address. I'm already spent too much time on that list trying to convince everyone that I'm ready to take all the burden of using unsupported packages, but was told that it's against Fedora policies. What much could I do? Having read the thread, you seem to miss the point that's been repeatedly made: the packages occasionally fail to build, and someone has to fix them. That act, fixing packages when they don't build is the "support" that someone has to provide. You can't use packages that don't exist. They don't exist unless someone supports them. Therefore you can't use an unsupported package. It's not because policy forbids it, it's because they don't exist without the act of a human maintainer making them build (which is described as "supporting" the package.) Does that make sense? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 07:57:20PM -, vvs vvs wrote: > Well, thanks for sharing. > > I'm not complaining that nobody wants to fix things for me. I'm complaining > because there is no possibility to fix things myself. After removing i686 > repository I'm either should start building it myself or switch to another > distribution. I'm not trying to hurt anyone's feelings, I just have no other > choice. If there is no possibility to keep that repository than it's fine, > but I was not convinced that there are other reasons for that decision aside > bureaucratic ones and lack of empathy. If putting that repository on some > optional host for anyone to be able to fix it themselves would severely harm > the project then I was wrong all along and I'm really sorry. If you don't care about i686 not being "supported" but just want to have access to the repositories so you can use/fix them yourself, then why don't you just keep running Fedora 30 or 29 forever? The old bits will always be there (moved to archive/ directory) and you can keep using them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Well, thanks for sharing. I'm not complaining that nobody wants to fix things for me. I'm complaining because there is no possibility to fix things myself. After removing i686 repository I'm either should start building it myself or switch to another distribution. I'm not trying to hurt anyone's feelings, I just have no other choice. If there is no possibility to keep that repository than it's fine, but I was not convinced that there are other reasons for that decision aside bureaucratic ones and lack of empathy. If putting that repository on some optional host for anyone to be able to fix it themselves would severely harm the project then I was wrong all along and I'm really sorry. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
I don't even know anyone whom I could address. I'm already spent too much time on that list trying to convince everyone that I'm ready to take all the burden of using unsupported packages, but was told that it's against Fedora policies. What much could I do? As for using i686 userland just look above in that thread, where I've already explained that my memory is already stretched enough and I have not enough reasons to buy a new computer just because some OS requirements. You should understand that computers are not that important for many users. They have more important things in their life and using Fedora is just a convenience. I can switch to another distribution if there is no other choice, but the reasons for that decision are so obscure, that it required such a long thread just to find it out. Also, it's not very convincing for end users when they get a long description of bureaucratic reasons why they just can't use packages anymore that they were already using and that other distribution happily provide. I'm sorry if this caused a lot of traffic on this list, but I was not aware of that problem up to the last moment. And you can expect some other users like me to complain when they will be confronted with the fact. Just announcing it on the first page two years ago would have avoided that problem. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
"vvs vvs" writes: > Ok, now I see that Fedora is just for activists. If I'm not one of > them then I don't deserve any possibility to use it and should blame > myself. Thanks for explaining it to me. I think you're overreacting a bit, but there is some truth in this. Fedora is created and maintained by the community. You are part of the community. If enough of the community shares your needs, some fraction of those will step up to do the work, and you all benefit. If your needs aren't shared by enough of the community, either you need to do it all yourself (or pay someone to act on your behalf), or your needs will never get met. This has nothing to do with "deserve" or "blame" - it's just numbers. Most people have switched to 64-bit, so most work is done for 64-bit, even if not all the 64-bit users are also contributors. The 32-bit community has shrunk to the point where there aren't enough contributors to keep the builds building and the fixes fixing, and there are real problems backing up because of that, even if they don't affect you personally. When there are enough problems and no contributors, what other choice do we have? It's broken and nobody is fixing it. Thus comes the hard part of any project - put up or shut up. Harsh, but it's the root of how things get done - they get done by people doing them. Do or do not, there is no sit-on-the-mailing-list-and-hope. Back when I started the DJGPP project, I had to do everything myself. The community grew and there were lots of contributors. Then the community shrunk until we're back down to 2 people doing all the work. Thus is the cycle of projects, but I don't complain that not enough people are still using DOS :-) OTOH you won't hurt our feelings if you switch distros. Go where your community is ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
No, just a memory bound behavior. It will eat all memory that you throw on it and one gigabyte just for starters. After that it will start swapping but some careful optimization management can avoid that. But if it starts swapping there will be a major performance hit. And it isn't mission critical so I'm not inclined to take drastic measures just for that reason. I know that upgrading will cost me much more time and frustration. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Jekyll 4
https://fedoraproject.org/wiki/Changes/Jekyll4 == Summary == This Change will bring the latest version of Jekyll, 4.0.0 (or later), to fedora. It includes minor backwards-incompatible changes, but also brings a lot of clean-ups and bug fixes compared to the 3.8 branch. == Owner == * Name: [[User:Decathorpe| Fabio Valentini (decathorpe)]] * Email: decatho...@gmail.com == Detailed Description == I will update the Jekyll static page generator to version 4.0.0 (or later), which will also include new versions of some Jekyll plugins / components and other rubygem dependencies. == Benefit to Fedora == The Jekyll stack in fedora 32 will be the latest and greatest. == Scope == * Proposal owners: ** Update existing packages: *** rubygem-jekyll: 4.0.0 *** rubygem-jekyll-asciidoc: 3.0.0 *** rubygem-jekyll-sass-converter: 2.0.0 *** rubygem-minima: 2.5.1 ** Package new dependencies: *** rubygem-kramdown-parser-gfm *** rubygem-kramdown-syntax-coderay *** rubygem-sassc (DONE) *** rubygem-stringex It might also be necessary to update other packages as soon as new versions targeting Jekyll 4 are released (for example, jekyll-feed, jekyll-seo-tag, jekyll-toc, jekyll-watch gems). * Other developers: ** Update existing packages not owned by me: *** rubygem-kramdown: 2.1.0 * Release engineering: N/A * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Jekyll 4 includes some minor backwards-incompatible changes which made new features possible, as outlined in the [https://jekyllrb.com/news/2019/08/20/jekyll-4-0-0-released/ upstream announcement] and [https://github.com/jekyll/jekyll/blob/v4.0.0/History.markdown release notes]. Some themes might not yet be compatible with Jekyll 4.0.0+, but the default theme (minima) will be updated to a compatible version. == How To Test == I've prepared a [https://copr.fedorainfracloud.org/coprs/decathorpe/jekyll4/ COPR repository] with a first draft of all packages that are necessary for upgrading Jekyll to versions 4.0.0 and later, but the packages are still a "work in progress" and not necessarily complete yet. * Update jekyll to version 4.0.0 * Try to create a new jekyll site, try to build an existing site, etc. == User Experience == In general, the new release should be noticably faster than the 3.8 branch of Jekyll, and brings only minor backwards-incompatible changes that will probably not affect most users. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == * https://jekyllrb.com/news/2019/08/20/jekyll-4-0-0-released/ * https://github.com/jekyll/jekyll/blob/v4.0.0/History.markdown -- Ben Cotton He / Him / His Fedora Program Manager Red Hat 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables == Summary == This change will toggle the default firewalld backend from iptables to nftables. All of firewalld's primitives will use nftables while direct rules continue to use iptables/ebtables. == Owner == * Name: [[User:erig0| Eric Garver]] * Email: egar...@redhat.com == Detailed Description == Firewalld upstream has used nftables as the default backend for the past two minor releases. It is also the default in other distributions (e.g. RHEL-8). This change will bring Fedora in line with upstream. Using nftables bring many advantages. See firewalld's upstream [https://firewalld.org/2018/07/nftables-backend blog post]. It also highlights a few behavioral changes. == Benefit to Fedora == * Fewer firewall rules (rule consolidation) All of firewalld's primitives will use the same underlying firewall (nftables) instead of duplicating rules both in iptables and ip6tables. In nftables rules can match both IPv4 and IPv6 packets. This reduces the number of firewall rules by half. * firewalld's rules are namespaced With nftables firewalld's rules are isolated to a "firewalld" table. A separate firewall (or user) can create its own independent ruleset and firewalld will never touch it. * Netfilter upstream is focusing on nftables, not iptables == Scope == * Proposal owners: firewalld (erig0, Eric Garver) Currently the firewalld package has a Fedora downstream patch to hide the nftables backend. The only firewalld change required is to remove that patch from the package and rebuild. * Other developers: libvirt, podman, docker ** libvirt *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** podman *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** docker *** Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT. *** Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables. Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone). *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" (or firewalld-docker?) package that has the zone definition. This could be installed by default when docker is installed. * Policies and guidelines: No updated needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == When users are upgraded to firewalld with nftables enabled (f32) all their firewall rules will exist in nftables instead of iptables. All of firewalld's primitives (zones, services, ports, rich rules, etc.) are 100% compatible between backends. Users of direct rules may need to consider the [https://firewalld.org/2018/07/nftables-backend behavioral changes] that were announced upstream. Some are also highlighted here: * direct rules execute before _all_ firewalld rules ** This has been requested by users * packets dropped in iptables (or direct rules) will never be seen by firewalld * packets accepted in iptables (or direct rules) are still subject to firewalld's rules == How To Test == Testing should mostly be integration based. Firewalld upstream has a fairly comprehensive testsuite that covers functional testing. The following are packages known to integrate with firewalld. They should be tested with the nftables backend. * libvirt ** verify VMs with different network types (bridged, routed) have working network access ** newer version of libvirt should create and use a "libvirt" firewalld zone. Interfaces should be dynamically added to the zone. * podman ** verify podman adds container bridge interface to the "trusted" zone ** verify container still has network access * docker ** known to not work with the firewalld nftables backend out of the box ** verify new package docker-firewalld installs firewalld docker zone and has "docker0" interface added ** verify container still has network access * fail2ban-firewalld ** verify the direct rules added to firewalld by fail2ban still block traffic == User Experience == In general users shouldn't notice the change. Occasional a user will look at the iptables rule that firewalld generates. They'll now have to look at nftables instead. == Dependencies == * libvirt >= 5.1.0 * CNI >= 0.8.0 (used b
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 11:15 AM, vvs vvs wrote: BTW, that just means that Fedora is refusing to provide much needed services even to a people who are ready to accept most of that support burden themselves and I'm one of them. I don't understand how you keep completely missing the point. No one is "refusing" to provide services. Fedora is maintained by VOLUNTEERS. If there is no one interested in doing certain work, it doesn't get done. At this time there is no one interested in i686 that has the time to keep it going. It won't keep working if no one is involved. If you are going to keep insisting that other people have to do what you want, then please do find another distro. Have you even tried running the 64-bit version to see if it really has the problems you think it will? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
On Mon, May 20, 2019 at 4:33 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/fedora-change-wrangler > After working to implement this proposal over the summer, we have discovered two issues with the Taiga UI that make this proposal more annoying to community contributors than I'm willing to accept. The first is that each custom field requires a distinct click on the field's save button. Since the workflow makes heavy use of custom fields, this is annoying and could result in losing data. This is filed upstream: https://github.com/taigaio/taiga-front/issues/1029 The second is that custom fields are not available when creating issues. You have to create the issue and then edit it to set the custom fields. This is less bad, since most wiki-based change proposals are edited multiple times anyway, but along with the previous issue adds an extra level of annoyance. This is filed upstream: https://github.com/taigaio/taiga-front/issues/608 Both of these issues are avoided by submitting issues via the API. Manas (pac23), who spent this summer working on tooling for this proposal, included this functionality in the tool. However, I don't expect that all contributors will use the tool to submit change proposals. The current state of the web UI is sufficient to make this more annoying than I want the process to be. I still like the principles behind this proposal, and if the upstream issues are fixed (or if another suitable platform comes along), I will revisit it. In the meantime, we'll continue using the current wiki workflow. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
I don't have time to search for it right now, but there is a law which states that no matter how much resources you already get they will be stretched thin anyway. I did upgrades many times but every time it was proved that it still wasn't enough. It's a useless rat race. We have much more important things to do because life is too short. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 11:47 AM, Martin Kolman wrote: Yeah, I've recently switched an old Atom A330[0] based system[1] with 2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit based distro (after finding out it can actually run 64-bit code). It has been running just fine and actually feels a bit faster now. I had a similar experience. I setup a bunch of old P4 desktops for a school computer lab. Initially, I used a 32-bit install, but then I discovered that they actually supported 64-bit. A Mate desktop runs just fine in 2GB of RAM even with Firefox and Libreoffice. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 19:01:59 -, vvs vvs wrote: No, I don't think so. I'm using some (non Fedora related) applications which use every bit of available memory. It's a bit stressed just as it is, but losing additional couple of megabytes for no useful reason will be too much a hit. And I can't change their code, because that codebase is big and complex (as usual) and I just don't have enough time to do everything myself. Have you actually tested this? That is very odd behavior. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 07:09:49PM -, vvs vvs wrote: > Ok, now I see that Fedora is just for activists. If I'm not one of > them then I don't deserve any possibility to use it and should blame > myself. Thanks for explaining it to me. If I may quote from the landing page on https://getfedora.org/ "Fedora creates an innovative, free, and open source platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users." ... "Fedora Workstation is a polished, easy to use operating system for laptop and desktop computers, with a complete set of tools for developers and makers of all kinds." Using Fedora (or not) has always been your choice. Good day, - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Ok, now I see that Fedora is just for activists. If I'm not one of them then I don't deserve any possibility to use it and should blame myself. Thanks for explaining it to me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 07:01:59PM -, vvs vvs wrote: > No, I don't think so. I'm using some (non Fedora related) applications > which use every bit of available memory. It's a bit stressed just as > it is, but losing additional couple of megabytes for no useful reason > will be too much a hit. And I can't change their code, because that > codebase is big and complex (as usual) and I just don't have enough > time to do everything myself. Honestly, it sounds like your 12-year-old system is barely adequate for your needs, and even a minimally-newer system capable of holding more RAM would pay for itself pretty rapidly. (Unless you don't value your own time or stress levels..) - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: translucent gnome top bar gone in F31?
On 9/9/19 4:39 AM, John M. Harris Jr. wrote: on my RHEL 7 deployments, where some of my users prefer GNOME), and where users request that I install gnome-tweak-tool for them so that they can make basic preference changes which just aren't available otherwise. Just in case you aren't aware, gnome-tweak-tool is an official Gnome application intended for advanced users to adjust settings they didn't want to put in the control panel. It's not some third party application for adjusting secret settings that the Gnome developers wanted to hide. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 08:47:24PM +0200, Martin Kolman wrote: > Yeah, I've recently switched an old Atom A330[0] based system[1] with > 2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit > based distro (after finding out it can actually run 64-bit code). It > has been running just fine and actually feels a bit faster now. That's been my experience too; the architectural improvements for x86_64 over i686 yielded a noticable performance boost that more than offset the memory usage penalty of larger pointer sizes, even for traditionally-RAM-intensive stuff like cross-compiling. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
In the interests of not making this thread a bunch longer, I am just going to answer a number of things here in one place. On 9/7/19 11:44 AM, Victor V. Shkamerda wrote: > I totally agree with that view. Making such decisions without public > discussion is not respecting user's freedom of choice. And this list doesn't > count as a public discussion. Nobody will know about it outside a very closed > circle. If you don't know exact numbers or reasons why people still use that > architecture, then rushing to drastic measures just won't have enough > rationale and will be viewed as a lack of care. There was a lot of discussion on this list, in fesco tickets in fesco meetings, on phoronix, etc. I'm not sure what you mean by 'respecting users freedom of choice'. We cannot possibly provide all choices that anyone wants or thinks they want. Really it comes down to (in rough order of effectiveness): * Try and convince people doing the work to provide/continue to provide the thing you want, but realize that the people doing the work are under no obligation here, you need to convince them there is some reason they find compelling. * Offer to do some / part / all of the work, but realize here too you need to convince the people doing the work now that it's worth the time / resources to allow you to do the work (although this is a much better 'sell' than just convincing people. It's pretty clear that i686 is dwindling as an arch. It was pretty clear a few years ago when it was demoted to a alternative arch and the x86 sig was setup to try and work on issues that came up. No one really did so, so it's time to take the next steps. > What work should be done? Please, be more specific. Right now I'm > running a i686 userland and it works. If I would be able to build the > whole repository myself I'm pretty sure that most things will still > work. If it won't work I might try to fix it and contribute patches > back. But without that repository I can't even try it in the first place. Lets step back a step here. Why are you running a 32bit userspace? There's not really any advantage (and some disadvantages) to doing so. The koji buildroot repo will continue to be available if you want to copy something, but as far as work to be done to move back to distributing a i686 set of trees? I guess doing the release blocking tests on i686 at Beta and Final might be a good start, but thats a ton of work for one person... is there anyone else you have talked to that wants to do this? kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
No, I don't think so. I'm using some (non Fedora related) applications which use every bit of available memory. It's a bit stressed just as it is, but losing additional couple of megabytes for no useful reason will be too much a hit. And I can't change their code, because that codebase is big and complex (as usual) and I just don't have enough time to do everything myself. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
I would argue that it might be difficult to distinguish work needed to find out if it was i686 specific when there already is similar bug on x86_64. Also, it's difficult to rate bug importance for most users. As I've already said that I was completely satisfied with the status quo and it was a big surprise for me to discover that I just won't be able to upgrade to the next version. Also, this discovery was purely accidental because there is no announcements anywhere I could see. Anyway, I would be prepared to fix things myself if such possibility was given to me. But alas there is no choice now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, 2019-09-09 at 13:27 -0500, Bruno Wolff III wrote: > On Mon, Sep 09, 2019 at 18:06:02 -, > vvs vvs wrote: > > Yes, thanks. Sadly, I see that I have no choice but to switch to another > > distribution even though I'm using 64-bit > > CPU. It's just that the memory can't be upgraded and buying new computer > > just to keep running Fedora is not viable. > > It's 12 years old, is in good condition and I'm completely satisfied with > > its performance for my needs. I wonder > > what owners of thin terminals will do if they used Fedora, especially if > > there are many of them. The cost of > > upgrading some old terminals for some school can be too high. > > It is probably very rare for someone to have just enough memory for a system > to > run reasonably using i686, but tank when using x86_64. If there is some > key code that causes the problem, you might be able to rebuild that code to > use 32 bit addresses and save enough memory to make things work reasonably. Yeah, I've recently switched an old Atom A330[0] based system[1] with 2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit based distro (after finding out it can actually run 64-bit code). It has been running just fine and actually feels a bit faster now. [0] https://ark.intel.com/content/www/us/en/ark/products/35641/intel-atom-processor-330-1m-cache-1-60-ghz-533-mhz-fsb.html [1] https://ark.intel.com/content/www/us/en/ark/products/42491/intel-desktop-board-d945gclf2.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > based ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 06:23:18PM -, vvs vvs wrote: > But how do you now that I'm not fixed it myself and forgot to post on > that list? Or that I'm even just used to live with that bug and just > don't want to spend all my time chasing it? It's simple; if you (and everyone else) doesn't say anything in the public discusison channels, or generate _some_ sort of activity in other project channels (eg bugzilla, irc, whatever) then it is a perfectly reasonable assumption to make that you are not doing anything of general relevance to Fedora. > I'm pretty sure that I can point point out bugs in official Fedora > repository that were dormant for several years without any conclusion > and nobody dropped support for all those applications just for that > reason. Every Fedora release has packages dropped due to failures to compile or other problems that run afoul of packaging policies, with nobody stepping up to fix them. > Anyway, I'm not expecting that something will change because of that > discussion. It is just bad that the interests of users are of a lower > priority then some purely bureaucratic reasons. I'm sorry you feel that way. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 18:23:18 -, vvs vvs wrote: Anyway, I'm not expecting that something will change because of that discussion. It is just bad that the interests of users are of a lower priority then some purely bureaucratic reasons. It isn't happening because of bureaucratic reasons, but because not enough work is getting done to support i686, because people aren't volunteering to do it (and actually doing the work). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bodhi branched updates: how many days until stable - 3, 7, 14?
On 9/9/19 7:52 AM, Miro Hrončok wrote: > On 09. 09. 19 16:40, Fabio Valentini wrote: >> Did some policy change occur which I am not aware of, or is bodhi just >> misconfigured again for branched? > > https://pagure.io/fedora-infrastructure/issue/8161 > Turns out this was a typo in a variable. Should be fixed here soon. But note: prebeta and postbeta have different values, so the 3 days thing is only prebeta. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 18:06:02 -, vvs vvs wrote: Yes, thanks. Sadly, I see that I have no choice but to switch to another distribution even though I'm using 64-bit CPU. It's just that the memory can't be upgraded and buying new computer just to keep running Fedora is not viable. It's 12 years old, is in good condition and I'm completely satisfied with its performance for my needs. I wonder what owners of thin terminals will do if they used Fedora, especially if there are many of them. The cost of upgrading some old terminals for some school can be too high. It is probably very rare for someone to have just enough memory for a system to run reasonably using i686, but tank when using x86_64. If there is some key code that causes the problem, you might be able to rebuild that code to use 32 bit addresses and save enough memory to make things work reasonably. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
But how do you now that I'm not fixed it myself and forgot to post on that list? Or that I'm even just used to live with that bug and just don't want to spend all my time chasing it? I'm pretty sure that I can point point out bugs in official Fedora repository that were dormant for several years without any conclusion and nobody dropped support for all those applications just for that reason. Anyway, I'm not expecting that something will change because of that discussion. It is just bad that the interests of users are of a lower priority then some purely bureaucratic reasons. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Need package review to unretire fastbit (a C++ lib)
I am a little beyond the 8-week window for the "no-hassle" unretire, so I need a new review for the fastbit packagethat I retired a few months ago. It's already in the Fedora git tree. I have it building cleanly again and would liketo resurrect it. I have gone over the review items locally, so it should now be in good condition. Thanks in advance. Phil 1750501 – Package Review to unretire fastbit | | | | 1750501 – Package Review to unretire fastbit | | | ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 17:55:06 -, vvs vvs wrote: First of all thanks for the link. It just proves that the SIG's expectations were too high. If I understand it all correctly, the main reason to drop i686 repo was the mailing list inactivity? Is that right? So everyone interested in that architecture is now deprived from using it on Fedora because some formalities were not met? And if I have no time to participate in that list, I can't fix problems myself? Because without that repository I'm forced to use other distribution. There were announcements on other lists. This issue was brought to the development list a long time ago. New people didn't do enough. Just being on a mailing list doesn't make things get done. People needed to fix problems or at least facilitate getting them fixed, and not enough of that happened. So it isn't just a formallity causing the problem. You can still use f30 until about May. It looks like CentOS 7 can be used with i686, so you could probably use that a bit longer if you wanted to stick with a similar distro. Someone has to do the work and most of Fedora's work gets done by volunteers. If no one volunteers for something, then that thing is unlikely to get done. I was willing to do some work on i686 when I was forced to use it, but shortly I won't be using any i686 systems and will be spending what little time I use for Fedora on things that are more important and more practical for me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Thanks for the suggestion. But I'm sure that I don't need so much bureaucracy just to run my little errands. If that's how Fedora is operated, than it won't make much difference for me to just using another distribution. BTW, that just means that Fedora is refusing to provide much needed services even to a people who are ready to accept most of that support burden themselves and I'm one of them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 05:55:06PM -, vvs vvs wrote: > If I understand it all correctly, the main reason to drop i686 repo > was the mailing list inactivity? Is that right? So everyone interested > in that architecture is now deprived from using it on Fedora because > some formalities were not met? And if I have no time to participate in > that list, I can't fix problems myself? Because without that > repository I'm forced to use other distribution. No, i686 was dropped for the same reason there was no traffic on the mailing list -- Nobody was getting any of the necessary work done. For the better part of two years. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libb2-0.98.1 on Rawhide
Am 09.09.19 um 18:39 schrieb Antonio Trande: > New `libb2-0.98.1` will be released by 10 days on Rawhide. > Packages currently involved: > > $ repoquery --release rawhide --disablerepo=* --enablerepo=fedora-source > --enablerepo=updates-source --whatrequires libb2-devel > > Last metadata expiration check: 0:00:02 ago on lun 9 set 2019, 18:31:15. > > borgbackup-0:1.1.10-4.fc32.src Thank you very much for the heads up. I guess borgbackup will be fine - worst case we can fall back to bundling the libb2 version bundled with borg. Would you mind pinging me again when the new package is actually built in rawhide? I will run borg's test suite against the new libb2 then. The test suite is pretty comprehensive so this should be a good indicator if we need to fix something in borg. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Yes, thanks. Sadly, I see that I have no choice but to switch to another distribution even though I'm using 64-bit CPU. It's just that the memory can't be upgraded and buying new computer just to keep running Fedora is not viable. It's 12 years old, is in good condition and I'm completely satisfied with its performance for my needs. I wonder what owners of thin terminals will do if they used Fedora, especially if there are many of them. The cost of upgrading some old terminals for some school can be too high. Maintaining my own distribution is a little too much for me at the moment. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
First of all thanks for the link. It just proves that the SIG's expectations were too high. If I understand it all correctly, the main reason to drop i686 repo was the mailing list inactivity? Is that right? So everyone interested in that architecture is now deprived from using it on Fedora because some formalities were not met? And if I have no time to participate in that list, I can't fix problems myself? Because without that repository I'm forced to use other distribution. That's just... weird. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 14:52:07 -, vvs vvs wrote: May be there are more interested people that we know, but they are not reading that list. There will just be just every man for himself and Fedora has failed to recognize that. This requires time and effort too. Nobody will appear just by a miracle. I recognize that there is much less people interested in this architecture but it's much more than zero. I'm probably one of the few people still running Fedora on a machine that uses i686, that can't use x86_64. The machine is around 15 years old and is costly to get replacement parts for and I'm running out of spares. I was supposed to replace the machine last month, but needed another month to save up enough to buy the rest of the replacement. I've actually work with upstream to get kernel bugs fixed for this machine. Unfortunately I run rawhide and things got shut down a little sooner than I hoped, so I'm not getting updates right now and don't want to go back to f30 with the short horizon for retirement (though I did grab an f30 kernel). I don't think you are going to find many people who both run Fedora and have to use i686. There is a cost to keeping things running on i686 and it doesn't look like it is worth paying right now. And things are looking to get worse rather than better. You have options. You can switch to another distro that will support i686 for a while yet. Use f30 until it's EOL (or beyond if the machines are isolated). Or maintain your own distro. The tools for Fedora are open, so you could set up your own koji instance drawing from Fedora and applying your fixes where needed. Getting started will probably be hard, but once things are running you'll be OK until there is a key bug you can't get fixed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: alciregi
Il giorno lun, 09/09/2019 alle 19.02 +0200, alcir...@gmail.com ha scritto: > Hello. > My name is Alessio. > FAS: alciregi Welcome to Fedora... > I work as an unpretentious sysadmin, mostly as the "IT guy". > I've been a long-time user/administrator of *nix systems, starting > with > Red Hat Linux 6 in 1999. I've been a user of other distributions as > well. Yeah, just a user. > After some years of distro hopping, a couple of years ago I settled > down and now I use Fedora as my main workstation; in the same period > I > decided to start to contribute. I'm more or less active in other > areas > of the community (anything important). > Packaging has always been my dream, but since I'm not a developer I > never started to learn how to do it. > But now I'm interested in learning and do something useful. A good starting point: https://docs.fedoraproject.org/en-US/packaging-guidelines/ Also learning from other people's is very useful: https://src.fedoraproject.org/ Ciao Guido 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to unretire ladspa-swh-plugins
I'd like to unretire ladspa-swh-plugins in rahwide, f31 and f30, because it is a dependency of some packages I maintain: ams jamin It's a dependency of pulseeffects too. I will file a review request ASAP, I have already made a scratch build in rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=37562823 FAS account: tartina Ciao Guido 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: alciregi
Hello. My name is Alessio. FAS: alciregi I work as an unpretentious sysadmin, mostly as the "IT guy". I've been a long-time user/administrator of *nix systems, starting with Red Hat Linux 6 in 1999. I've been a user of other distributions as well. Yeah, just a user. After some years of distro hopping, a couple of years ago I settled down and now I use Fedora as my main workstation; in the same period I decided to start to contribute. I'm more or less active in other areas of the community (anything important). Packaging has always been my dream, but since I'm not a developer I never started to learn how to do it. But now I'm interested in learning and do something useful. Thanks. A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bodhi branched updates: how many days until stable - 3, 7, 14?
On Mon, Sep 9, 2019 at 4:52 PM Miro Hrončok wrote: > > On 09. 09. 19 16:40, Fabio Valentini wrote: > > Did some policy change occur which I am not aware of, or is bodhi just > > misconfigured again for branched? > > https://pagure.io/fedora-infrastructure/issue/8161 Ah, so I remembered correctly, and this seems to be broken again. Thanks for reporting it. Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 03:36:45PM -, vvs vvs wrote: > > What work should be done? Please, be more specific. Deja vu… please read https://pagure.io/fesco/issue/1737 (Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28) with all the links. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
vvs vvs píše v Po 09. 09. 2019 v 15:44 +: > I'm happy with any support no matter how it is defined. In fact I > didn't get very much support from Fedora either over more than 20 > years, so my expectations are quite low. You seem to have a rather narrow view of support. It's not just someone waiting for your email/phone call to help you with your issues, that's just a small part of software support, it's mostly making sure that bugs and primarily security issues get fixed and delivered to you (and believe me it's not such a sure thing among Linux distros), and if you've been using Fedora for 20 years, you have received a lot of that. And you fail to understand it's something the Fedora Project is currently not quite capable to deliver for x86. If you expect the Fedora Project to just build packages for x86 and throw them over the wall on users, then I'm sorry to disappoint you, but that's not how Fedora has ever worked and I hope it never will. So as others already suggested: if you want the x86 architecture back, revive the x86 SIG, gather enough volunteers, make sure you can meet expectations of support at least at the level of secondary architectures, create a proposal backed by enough committed volunteers, submit it to FESCo, and I'm pretty sure you'll have your beloved architecture back. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
libb2-0.98.1 on Rawhide
Hi all. New `libb2-0.98.1` will be released by 10 days on Rawhide. Packages currently involved: $ repoquery --release rawhide --disablerepo=* --enablerepo=fedora-source --enablerepo=updates-source --whatrequires libb2-devel Last metadata expiration check: 0:00:02 ago on lun 9 set 2019, 18:31:15. R-argon2-0:0.2.0-6.fc31.src borgbackup-0:1.1.10-4.fc32.src gtkhash-0:1.2-1.fc32.src -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x6e0331dd1699e4d7 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
No I didn't, but I must be sure that you speak on behalf of everyone before making my choices. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
So, if I'd start to use Debian i686 instead of Fedora or will use ARM32 device instead of ARM64 the world will be a safer place? Also, I was told that maintaining i686 Fedora code base myself would be fine, but in the same time I'm told that it's not acceptable from the safety point of view. Why I'm smelling a contradiction here? In short: the decision to drop i686 support is supported by contradicting statements, while at the same time if I want to be taken seriously, I should bring strong evidence. That's very objective discussion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 03:44:49PM -, vvs vvs wrote: > If there is something more relevant than freedom of choice, then there > is no point arguing further, because I value community relations over > any technical reasons. You seem to forget that "freedom of choice" also applies to those working on Fedora... - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages with broken dependencies on Python 3.7
swift-lang has been fixed with a patch and scratch builds on F32 build properly: https://koji.fedoraproject.org/koji/taskinfo?taskID=37348234 On 4 Sep 2019, at 17:39, Miro Hrončok wrote: Hello packagers! The following packages failed to build on Fedora 32 with Python 3.8 and they still require Python 3.7 on runtime. If the packages won't build with Python 3.8, they won't be installable, along with all their dependent packages, in Fedora 32. If there is an "actual" build failure, you should have already received a bug report blocking the tracking bug: https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON38&hide_resolved=1 If it is a dependency failure caused by an external factor (retired package, etc.) there should be a bugreport as well. However, if the package fails to resolve build dependencies only because some other package hasn't been rebuilt with Python 3.8, we have not opened a bug report (yet) to avoid duplication. If you see your package here and are blocked by another package, I recommend to see if the dependency isn't waiting for your help (e.g. the package maintainers haven't yet got time to look into this). Chances are, there is some undiscovered dependency loop as well. The Red Hat Python Maintenance team will gladly help with specific problems, but we will not fix all the packages ourselves. See also https://fedoraproject.org/wiki/Changes/Python3.8 Affected maintainers are bcced (except orphan, groups and maintainers usually disturbed by my spam). Maintainers by package: blender design-sw hobbes1069 ignatenkobrain kwizart luya roma s4504kr slaanesh certbot jhogarth nb clingo thofmann coccinelle rjones condor bbockelm bcotton eerlands matt matyas stevetraylen tstclair ttheisen valtri coreboot-utils lkundrak peter datagrepper ianweller ralph dee jspaleta spot dionaea rebus freecad hobbes1069 jkastner zultron gcc-python-plugindmalcolm jakub gdl orion gnucash notting gplugin ignatenkobrain graphite-api piotrp graphite-web jamielinux jsteffan piotrp kdevelop-python dvratil jgrulich minh libcec pbrobinson libpst carllibpst libunity rdieter mailman3 abompard matrix-synapse dcallagh jcline mraa pbrobinson ocrmypdf qulogic paraview deji orion sagitter player kwizart rmattes timn ttorling pocketsphinx mikep pybind11 jussilehtola python-APScheduler orphan python-OBD rathann python-Pympler rathann python-agate jujens python-agate-dbf jujens python-agate-excel jujens python-agate-sql jujens python-aioresponses gsauthof python-aiosmtpd abompard python-alchimia vpopovic python-anymarkup jchaloup orphan python-anymarkup-core jchaloup orphan python-astroML lupinix python-astroML-addons lupinix python-astropy-healpix lupinix python-astroscrappy lupinix python-asttokens zbyszek python-asynctest rathann python-behavechurchyard orphan python-beniget churchyard python-bz2file besser82 python-cartopy qulogic python-cattrsbrouhaha python-ccdproc lupinix python-certbot-apache jhogarth nb python-certbot-dns-cloudflare nb python-certbot-dns-cloudxns nb python-certbot-dns-digitalocean elyscape nb python-certbot-dns-dnsimple nb python-certbot-dns-dnsmadeeasy nb python-certbot-dns-gehirn elyscape python-certbot-dns-google elyscape nb python-certbot-dns-linode elyscape python-certbot-dns-luadns nb python-certbot-dns-nsone nb python-certbot-dns-ovh elyscape python-certbot-dns-rfc2136 logic nb python-certbot-dns-route53 elyscape nb python-certbot-dns-sakuracloud elyscape python-certbot-nginx jhogarth nb python-chaospy lbazan python-cheetah mikeb mskalick panovotn python-cliappsalimma python-crochet jcline python-csvkitjujens python-dask qulogic python-dbus-python-client-gen grover ignatenkobrain mulhern python-django-appconf mrunge python-django-pyscss mrunge python-elephant lbazan python-envisage orion python-epub athoscr python-flake8-import-order zbyszek python-gast churchyard python-gatspylupinix python-geoplot qulogic python-gfm thm python-gnocchiclient mrunge pkilambi python-grafyaml orphan python-imagehash fab python-inema gsauthof python-into-dbus-python grover ignatenkobrain ilgrad python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger python-jira ishcherb ralph stevetraylen python-joblibbesser82 ignatenkobrain sergiopr python-junit_xml jhogarth python-leveldb carlwgeorge python-libpysal qulogic python-logging-tree orphan ralph python-marshmallow-enum orphan python-mdp zbyszek python-missin
Re: translucent gnome top bar gone in F31?
On Mon, Sep 09, 2019 at 04:39:47AM -0700, John M. Harris Jr. wrote: > > > > > > This is precisely the issue with GNOME entirely. It assumes the user > > > shouldn't > > > have a choice, that some designers know best. > > > > > > Yes, precisely *your* issue. I’d rather someone think for me as far as > > defaults go and not give me a quest to set everything up just right > > every time I install the DE. > > > > Decisions such as this, inspired by the idea that *somebody* knows best, and > it just works for everyone, are precisely why I won't be able to deploy RHEL > 8 > until KDE is available through EPEL or another repo. Heck, the only reason I > can even run RHEL 8 on my test box is because I manually compiled KDE for it. > > This is incredibly common in GNOME, where people just make a decision and try > to enforce it on the users. Things everyone hates, like moving the mouse into > the top-left corner opening some weird menu, and the only way to disable it > being third party software. (Something I've had to provide a fix by default > for > on my RHEL 7 deployments, where some of my users prefer GNOME), and where > users request that I install gnome-tweak-tool for them so that they can make > basic preference changes which just aren't available otherwise. John, you personal opinions are not providing anything valuable in this thread. This went offtopic too much, bordering on insults. Please keep our mailling list productive and civilised. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
I'm happy with any support no matter how it is defined. In fact I didn't get very much support from Fedora either over more than 20 years, so my expectations are quite low. If there is something more relevant than freedom of choice, then there is no point arguing further, because I value community relations over any technical reasons. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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: 20190909.n.1 changes
OLD: Fedora-Rawhide-20190908.n.0 NEW: Fedora-Rawhide-20190909.n.1 = SUMMARY = Added images:1 Dropped images: 8 Added packages: 5 Dropped packages:21 Upgraded packages: 101 Downgraded packages: 0 Size of added packages: 88.39 MiB Size of dropped packages:12.09 MiB Size of upgraded packages: 740.83 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 25.93 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190909.n.1-sda.raw.xz = DROPPED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20190908.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190908.n.0.s390x.tar.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20190908.n.0.iso Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20190908.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190908.n.0.s390x.raw.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190908.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190908.n.0.s390x.qcow2 Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190908.n.0.s390x.vmdk = ADDED PACKAGES = Package: ghc-xdg-userdirs-0.1.0.2-1.fc32 Summary: Basic implementation of XDG user directories specification RPMs:ghc-xdg-userdirs ghc-xdg-userdirs-devel ghc-xdg-userdirs-doc ghc-xdg-userdirs-prof Size:621.00 KiB Package: golang-github-gorilla-csrf-1.6.0-1.fc32 Summary: Cross Site Request Forgery (CSRF) prevention middleware RPMs:golang-github-gorilla-csrf-devel Size:25.85 KiB Package: patat-0.8.2.3-1.fc32 Summary: Terminal-based presentations using Pandoc RPMs:patat Size:82.24 MiB Package: rust-dutree-0.2.9-1.fc32 Summary: Command line tool to analyze disk usage RPMs:dutree rust-dutree+default-devel rust-dutree-devel Size:5.35 MiB Package: rust-nix0.14-0.14.1-1.fc32 Summary: Rust friendly bindings to *nix APIs RPMs:rust-nix0.14+default-devel rust-nix0.14-devel Size:174.87 KiB = DROPPED PACKAGES = Package: publican-fedora-4.0-2.fc21 Summary: Publican documentation template files for fedora RPMs:publican-fedora publican-fedora-web Size:1.26 MiB Package: python-xmpp-0.5.0-0.22.rc1.fc31 Summary: Python library for easy scripting with Jabber RPMs:python2-xmpp Size:124.86 KiB Package: rubygem-CFPropertyList-2.3.3-7.fc31 Summary: Read, write and manipulate property lists as defined by Apple RPMs:rubygem-CFPropertyList rubygem-CFPropertyList-doc Size:320.38 KiB Package: rubygem-ascii_binder-0.1.15.1-2.fc31 Summary: An AsciiDoc-based system for authoring and publishing documentation RPMs:rubygem-ascii_binder rubygem-ascii_binder-doc Size:540.65 KiB Package: rubygem-fission-0.5.0-9.fc31 Summary: Command line tool to manage VMware Fusion VMs RPMs:rubygem-fission rubygem-fission-doc Size:377.73 KiB Package: rubygem-ldap_fluff-0.4.7-2.fc31 Summary: LDAP querying tools for Active Directory, FreeIPA and POSIX-style RPMs:rubygem-ldap_fluff rubygem-ldap_fluff-doc Size:294.71 KiB Package: rubygem-rails_warden-0.6.0-2.fc31 Summary: A gem that provides authentication via the Warden framework RPMs:rubygem-rails_warden rubygem-rails_warden-doc Size:261.60 KiB Package: rubygem-sitemap_generator-6.0.2-2.fc31 Summary: Easily generate XML Sitemaps RPMs:rubygem-sitemap_generator rubygem-sitemap_generator-doc Size:388.50 KiB Package: rubygem-warden-1.2.8-2.fc31 Summary: An authentication library compatible with all Rack-based frameworks RPMs:rubygem-warden rubygem-warden-doc Size:315.36 KiB Package: spring-ldap-1.3.1-20.fc31 Summary: Java library for simplifying LDAP operations RPMs:spring-ldap spring-ldap-javadoc Size:610.01 KiB Package: springframework-amqp-1.3.9-11.fc31 Summary: Support for Spring programming model with AMQP RPMs:springframework-amqp springframework-amqp-javadoc Size:553.17 KiB Package: springframework-batch-2.2.7-8.fc30 Summary: Tools for enterprise batch or bulk processing RPMs:springframework-batch springframework-batch-javadoc Size:1.73 MiB Package: springframework-data-commons-1.8.4-13.fc31 Summary: Interfaces between relational and non-relational data stores RPMs:springframework-data-commons springframework-data-commons-javadoc Size:759.13 KiB Package: springframework-data-jpa-1.6.6-8.fc30 Summary: Simplifies the development of creating a JPA-based data access layer RPMs:springframework-data-jpa springframework-data-jpa-javadoc Size:332.69 KiB Package: springframework-data-mongodb-1.5.2-11.fc31 Summary: MongoDB support
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
There is no either right or wrong stance here. We are discussing possible alternatives to "just drop it" attitude. What work should be done? Please, be more specific. Right now I'm running a i686 userland and it works. If I would be able to build the whole repository myself I'm pretty sure that most things will still work. If it won't work I might try to fix it and contribute patches back. But without that repository I can't even try it in the first place. You are just pushing me and others away, so we should go use other distributions which provide ready to run builds. And I'm not talking about i686 *kernel* anywhere. We are talking about *userland* only. I'm running 64-bit CPU all along, but I have limited memory. Others could use laptops with restricted memory which would be a performance hit if they start using x86_64 userland. You are not providing any alternative but starting to build everything ourselves or stop using Fedora and move elsewhere. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 02:41:15PM -, vvs vvs wrote: > OTOH, if Debian has resources to maintain the support for at least > next five years it means one of two things: either they have more > resources than Fedora, or something is wrong with your assessment. Or (3) Debian defines "support" quite differently than Fedora. > P.S. And what it's all supposed to do with "Linux is NOT about > choice"? This looks like just as an excuse to me for some other thing. s/some other/more relevant/ - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
- Original Message - > From: "vvs vvs" > To: devel@lists.fedoraproject.org > Sent: Monday, September 9, 2019 4:52:07 PM > Subject: Re: Fedora 31 System-Wide Change proposal (late): No i686 > Repositories > > May be there are more interested people that we know, but they are not > reading that list. There will just be just every man for himself and Fedora > has failed to recognize that. > > This requires time and effort too. Nobody will appear just by a miracle. I > recognize that there is much less people interested in this architecture but > it's much more than zero. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Providing some imaginary numbers and anecdotes as facts doesn't really help the "I am right, you are wrong" style of debating that is on going for some time in this thread. No, Fedora hasn't failed to recognize something, it's a community project. If noone is interested enough to step up and help with the effort, the work will never be done, simple as that. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
I will do whatever I can and it's not much for ANY architecture, x86_64 is not an exception. That's because I'm not very young and have a lot of other more important activities which is not related to computers. That said, I'm not expecting very much in return either. If it would somehow work on a level which was usual for RMS era it would be enough for me. I've used Linux on my own in many cases. The only thing that I expect from any Linux distribution is to just BUILD it for me. Because it's impossible to rebuild so many packages with my very limited resources. I'm not asking for full blow support, but leaving even semi-broken repository intact would be a great help for me and may be others who know from which side to use computers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bodhi branched updates: how many days until stable - 3, 7, 14?
On 09. 09. 19 16:40, Fabio Valentini wrote: Did some policy change occur which I am not aware of, or is bodhi just misconfigured again for branched? https://pagure.io/fedora-infrastructure/issue/8161 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
May be there are more interested people that we know, but they are not reading that list. There will just be just every man for himself and Fedora has failed to recognize that. This requires time and effort too. Nobody will appear just by a miracle. I recognize that there is much less people interested in this architecture but it's much more than zero. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Ok, if that's so hard then I'm apologize for not recognizing the pain. OTOH, if Debian has resources to maintain the support for at least next five years it means one of two things: either they have more resources than Fedora, or something is wrong with your assessment. I'd help with maintaining 32-bit userland as much as I can. But I'm afraid that's not much. From my point of view the only support I need is that damn thing worked most of the time. And there no more bugs in i686 userland than in x86_64 one. If you really need so much patching than I simply don't understand why it still works on other supported 32-bit arches all over the world, e.g. ARM. P.S. And what it's all supposed to do with "Linux is NOT about choice"? This looks like just as an excuse to me for some other thing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
bodhi branched updates: how many days until stable - 3, 7, 14?
Hi everybody, I seem to remember that bodhi updates for branched releases only required 3 days in testing until they could be pushed to stable. However, for fedora 31, the default (and minimum) is 7 days, and for critpath packages, the default (and minimum) 14 days, like for normal "released" fedora branches. Did some policy change occur which I am not aware of, or is bodhi just misconfigured again for branched? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intent to orphan dblatex (asciidoc dependency)
On Mon, Sep 9, 2019 at 7:16 AM Michael J Gruber wrote: > Okay, just quickly two good news: > > - Nikola Forró has a patch that got me much further, there's hope for a > working dblatex on py3! > - Upstream showed life signs, I'll try to coordinate (and get patches > upstreamed now or later once we have them ready). That is good news. Thanks for sticking with this. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 9/9/19 9:28 AM, vvs vvs wrote: Boy, am I glad you've said that. I was waiting for it. But looks like you are mistaken. First of all, it's not one, but at least two of them. Second, nobody else seems to be supporting your point. E-mails to this list don't get work done. Code commits get work done. Feel free to revive the x86 SIG and start building a i686 kernel and work with releng to re-enable the i686 repos. Continuing this discussion will be fruitless for you and the thousands of subscribers that are not replying to you. There's a reason no one is replying. They are not interested. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Boy, am I glad you've said that. I was waiting for it. But looks like you are mistaken. First of all, it's not one, but at least two of them. Second, nobody else seems to be supporting your point. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python-pyside2 SONAME bump (5.12.x->5.13.x)
I'm planning on building a new version of PySide2 as it contains a lot of bug fixes. Nothing appears to depend on it yet so shouldn't cause any issues and I want to get the latest release built before porting over freecad and the two consumers of PySide1. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20190909.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 21 of 45 required tests failed, 19 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 76/152 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-Rawhide-20190908.n.0): ID: 446050 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/446050 ID: 446051 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446051 ID: 446052 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/446052 ID: 446054 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/446054 ID: 446056 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/446056 ID: 446057 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/446057 ID: 446058 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/446058 ID: 446059 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/446059 ID: 446061 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446061 ID: 446067 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/446067 ID: 446084 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/446084 ID: 446085 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446085 ID: 446087 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/446087 ID: 446089 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446089 ID: 446102 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/446102 ID: 446104 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446104 ID: 446105 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/446105 ID: 446117 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/446117 ID: 446119 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/446119 ID: 446121 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/446121 ID: 446129 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/446129 ID: 446130 Test: x86_64 universal install_sata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446130 ID: 446132 Test: x86_64 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/446132 ID: 446134 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/446134 ID: 446135 Test: x86_64 universal install_sata **GATING** URL: https://openqa.fedoraproject.org/tests/446135 ID: 446136 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/446136 ID: 446137 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/446137 ID: 446138 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/446138 ID: 446139 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/446139 ID: 446140 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/446140 ID: 446141 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/446141 ID: 446142 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/446142 ID: 446143 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/446143 ID: 446144 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/446144 ID: 446145 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/446145 ID: 446146 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/446146 ID: 446148 Test: x86_64 universal install_european_language URL: https://openqa.fe
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote: > The system I'm sending this email from only has 4 GiB of memory in > total. Does that mean that this system makes ASLR completely > ineffective? Should this arch also be removed from Fedora, because of > that? *Address Space* is not the same as *Physical Memory*. I suggest you educate yourself on the difference between the two, as that distinction is perhaps the fundamental underpinning of memory management. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 compose report: 20190909.n.0 changes
OLD: Fedora-31-20190908.n.0 NEW: Fedora-31-20190909.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.26 MiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-31-20190909.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-31-20190909.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: publican-fedora-4.0-2.fc21 Summary: Publican documentation template files for fedora RPMs:publican-fedora publican-fedora-web Size:1.26 MiB = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 5:16:23 AM MST Vitaly Zaitsev via devel wrote: > On 9/9/19 1:47 PM, John M. Harris Jr. wrote: > > > ASLR has nothing to do with the wild claims made in that email, that > > having an x86 system will somehow taint or 'infect' other systems. > > Additionally, you don't need to run a 64 bit system to get ASLR. > > > i686 app has only 4 GB of virtual address space (2 GB for user-space and > 2 GB for kernel space), so ASLR is ineffective. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) The system I'm sending this email from only has 4 GiB of memory in total. Does that mean that this system makes ASLR completely ineffective? Should this arch also be removed from Fedora, because of that? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intent to orphan dblatex (asciidoc dependency)
Okay, just quickly two good news: - Nikola Forró has a patch that got me much further, there's hope for a working dblatex on py3! - Upstream showed life signs, I'll try to coordinate (and get patches upstreamed now or later once we have them ready). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS-UP]: Mercurial with Python3 on rawhide?
Seems evolve (tip) is not installable on python3: python3 setup.py install --user Traceback (most recent call last): File "setup.py", line 37, in version=get_version(), File "setup.py", line 15, in get_version return get_metadata()['__version__'] File "setup.py", line 10, in get_metadata execfile(fullpath, meta) NameError: name 'execfile' is not defined [nbecker@nbecker2 evolve]$ hg id 8a491546e81d (stable) tip On Sun, Sep 8, 2019 at 12:02 PM Neal Gompa wrote: > > On Tue, Aug 27, 2019 at 7:21 PM Petr Stodulka wrote: > > > > Hi guys, > > I apologize that I mystified you a little in my prefious email when I wrote > > that > > I resolved majority of problems. I looked at that closer today after 1.5w > > and > > found that I have been near the start of all troubles. My memory just washed > > that pain out. > > > > So I spend some time around and finally it looks that I am able to build at > > least > > something. I guess that all extensions (including hgk, chg) are pretty > > broken > > now as these will have to be build separately probably as well.. > > > > The patch with POC of the py2 & py3 packages is here: > > https://bugzilla.redhat.com/attachment.cgi?id=1608765 > > > > I think that the solution is pretty bad really (I mean, whole iday about > > py2 & py3 rpms is wrong and maybe should be created new component that > > will be conflicting with the mercurial - which should be ported to Py3 > > only). > > Such solution would be more clean I guess, with proper Provides/Obsoletes. > > > > I will be offline again since the wednesday's night. Hopefully it helps > > someone at least a little. > > > > I was speaking to the Octobus guys on IRC about this, and the issues > reported earlier about hg-git and evolve are fixed in the default > branch tip, just not in a release yet. Can you try pulling snapshots > for hg-git and evolve based on tip and see if the situation has > improved? > > I'd rather just have us yank Python 2 entirely from the Mercurial > stack. Barring that, it _is_ possible to make de-conflicted Python 2 > and Python 3 packages. I'd rather the Python 2 one be non-default no > matter what, since we *are* removing the Python 2 stack in Fedora 32, > full stop. > > If you need help with making less ugly versions of a py2+py3 packaging > of Mercurial, I'd be happy to help there. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! -- Those who don't understand recursion are doomed to repeat it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-31-20190909.n.0 compose check report
No missing expected images. Failed openQA tests: 4/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190908.n.0): ID: 445958 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/445958 Old failures (same test failed in Fedora-31-20190908.n.0): ID: 445922 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/445922 ID: 445957 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/445957 ID: 445960 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/445960 ID: 445963 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/445963 Soft failed openQA tests: 5/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20190908.n.0): ID: 445916 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/445916 Old soft failures (same test soft failed in Fedora-31-20190908.n.0): ID: 445938 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/445938 ID: 446028 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/446028 ID: 446030 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/446030 ID: 446035 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/446035 Passed openQA tests: 143/152 (x86_64) New passes (same test not passed in Fedora-31-20190908.n.0): ID: 445940 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/445940 ID: 446008 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/446008 ID: 446032 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/446032 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 0.21 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/445598#downloads Current test data: https://openqa.fedoraproject.org/tests/445930#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service Previous test data: https://openqa.fedoraproject.org/tests/445600#downloads Current test data: https://openqa.fedoraproject.org/tests/445932#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 2 services(s) added since previous compose: dbus-:1.5-org.freedesktop.problems@0.service loaded active running dbus-:1.5-org.freedesktop.problems@0.service, pcscd.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 0.75 to 0.49 Previous test data: https://openqa.fedoraproject.org/tests/445613#downloads Current test data: https://openqa.fedoraproject.org/tests/445945#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used mem changed from 701 MiB to 809 MiB System load changed from 1.64 to 1.16 Previous test data: https://openqa.fedoraproject.org/tests/445615#downloads Current test data: https://openqa.fedoraproject.org/tests/445947#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used mem changed from 820 MiB to 931 MiB System load changed from 0.55 to 0.22 Previous test data: https://openqa.fedoraproject.org/tests/445630#downloads Current test data: https://openqa.fedoraproject.org/tests/445962#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 1 MiB to 6 MiB Previous test data: https://openqa.fedoraproject.org/tests/445
Orphaned adapta-gtk-theme, adapta-backgrounds
Hello packagers, I've just orphaned both adapta-gtk-theme and adapta-backgrounds. The upstream project is more or less dead, since the main developer left after getting a lot of negative feedback for the release of a big refresh / redesign of the Adapta GTK theme (which was then reverted). The fedora package currently provides the last version of the theme *before* the redesign. I originally took over these packages because I used them myself, but since fedora 30 I'm using stock GNOME / Adwaita again, and so I don't have any use for them anymore. Additionally, since the last inkscape update (move to gtk3 and python3?), the theme assets rendering during the build process is now broken, and this would need to be fixed as well. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
* John M. Harris, Jr.: > ASLR has nothing to do with the wild claims made in that email, that > having an x86 system will somehow taint or 'infect' other > systems. Additionally, you don't need to run a 64 bit system to get > ASLR. I'm not saying that the analogy is appropriate, but it is just not true that 32-bit support is isolated. We will have to patch lots of code to support the new *_time64 system calls, and that will impact everyone, even for applications that are never run on 32-bit systems. (This assumes that we can magically fix the native linker issues on 32-bit architectures.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
