Re: small aarch64 home server
On Fri, 2022-09-16 at 23:02 +0200, Peter Boy wrote: > > > > Am 16.09.2022 um 13:43 schrieb Stephen Snow : > > > > Have you looked at the Khadis boards? They're available through > > Digikey > > canada at > > https://www.digikey.ca/en/products/filter/single-board-computers-sbcs-computer-on-module-com/933?s=N4IgjCBcoLQdIDGUBmBDANgZwKYBoQB7KAbRACYAGANgBYQBdAXxaA > > Their features are interesting, indeed, but wondering, nearly all > boards on the digikey page are marked as „obsolete“ and without a > price tag. > > And the not obsolete boards are not listed in 'arm-image-installer -- > supported‘ (or at least I can’t identify them on the output). > > Do you have practical experience with one of those boards? > No, sorry I do not. > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: small aarch64 home server
Hello Jiri, Have you looked at the Khadis boards? They're available through Digikey canada at https://www.digikey.ca/en/products/filter/single-board-computers-sbcs-computer-on-module-com/933?s=N4IgjCBcoLQdIDGUBmBDANgZwKYBoQB7KAbRACYAGANgBYQBdAXxaA They look quite a bit more capable than RPi IMO. Regards, Stephen On Fri, 2022-09-16 at 13:35 +0200, Jiri Vanek wrote: > Hello! > > Thanx a lot all for suggestions. Especially I did not know that there > is suggested set for running Fedora Server. > Yes, I will be running a Fedora on it, yes, I belive I wil share the > steps and thoughts, as this usually always hurt :) > > Most of the recomanded boards are very similar to rpi, which is just > week, and usb drives have its bugs. > > From those the librecomp and honeycomb looks quite promissing. > > I need to dig deeper:) Thanx a lot for recomandation, Some of the > models mentioned were never seen by me. > > J. > > On 9/14/22 11:04, Peter Robinson wrote: > > On Tue, Sep 13, 2022 at 7:51 PM Chris Adams > > wrote: > > > > > > I'd like to piggy-back - is there a Fedora well-supported board > > > that can > > > use the Pi-targeted hats? I stayed away from the Pi for a long > > > while, > > > because of the support problems, but it just seems like there's > > > so much > > > that's just made for Pis. > > > > HATs are hard, there's a lot of devices that claim to be compatible > > with the HAT interface but there's always caveats so it would > > depend > > very much on your usecase. > > > > P > > ___ > > 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 > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Live USB rescue mode, do we still have one? Does it work?
To maybe make a suggestion or two that would help in the case of rescue but also directing the newbie to a better more satisfying installation/recovery experience ... * Put Fedora Media writer on the get Fedora page as the preferred method of getting Fedora with the option to go directly to what you want if you know what you want. * Put the Live USB image as one of the preferred options listed by Media Writer along with the Editions * Put a rescue mode on the Live USB image, where it is logically needed and things are pretty much already there as has been stated by Brian. Stephen On Fri, 2022-05-27 at 12:26 -0500, Richard Shaw wrote: > On Fri, May 27, 2022 at 12:15 PM Robert Marcano via devel > wrote: > > On 5/27/22 12:52 PM, Brian C. Lane wrote: > > > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote: > > >> On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > > >>> > > >>> The rescue mode has always been on the traditional installer > > images, > > >>> not the lives. It's still there. > > >>> > > >> Unfortunately there is no rescue option on the Fedora Linux > > Workstation > > >> installer just the Server and the Everything. > > >> Is this a part of Anaconda or a different package in Fedora > > Linux? > > > > > > Rescue is an Anaconda feature: > > > > > > > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py > > > > > > > > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst > > > > > > It is not supported on live media since most of the steps just > > don't > > > make sense -- live already sets up the network and you should be > > able to > > > use the regular desktop tools to mount your existing partitions. > > > > > > > > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93 > > > > True, but the Live image needs something like a command like > > "fedora-prepare-rescue-image" or something like that that just do > > what > > the Fedora rescue option do and mount what it can find on > > /mnt/sysimage. > > > > The steps to mount a complete /mnt/sysimage are a more than a few > > and it > > could help a lot not needing to type many things that an untrained > > person could make a big mistake. > > > > +1000 from me. I always have to google how to bind mount everything > (dev, sys, proc) but that can easily be automated and should be. > > Assuming the root partition contains /etc/fstab, a script should be > able to handle this easily and abstract "everyday" users from the > complexity. > > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
Since I think this didn't make it to the list ... On Sat, 2022-05-28 at 11:54 +0200, Christopher Klooz wrote: > On 28/05/2022 00:34, Stephen Snow wrote: > > On Fri, 2022-05-27 at 09:52 -0700, Brian C. Lane wrote: > > > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote: > > > > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > > > > > The rescue mode has always been on the traditional installer > > > > > images, > > > > > not the lives. It's still there. > > > > > > > > > Unfortunately there is no rescue option on the Fedora Linux > > > > Workstation > > > > installer just the Server and the Everything. > > > > Is this a part of Anaconda or a different package in Fedora > > > > Linux? > > > Rescue is an Anaconda feature: > > > > > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py > > > > > > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst > > > > > > It is not supported on live media since most of the steps just > > > don't > > > make sense -- live already sets up the network and you should be > > > able > > > to > > > use the regular desktop tools to mount your existing partitions. > > > > > Sorry but how does someone with a disability navigate that? > > The rescue mode while maybe unnecessary for developers and those > > well > > verse in Fedora Linux, but the inexperienced and the disadvantged > > don't > > get any consideration by your statement. And in the case of this > > particular example I cited at the beginning, the person is having > > MUCH > > difficulty navigating the Live USB approach to rescuing their > > system. > > > > > > Stephen > > If it does not require too much effort to implement this: +1 for > adding > a rescue to workstation live images. > > On ask.fp you will find many users not sufficiently advanced for > doing > all this on their own. And explaining such things can consume a lot > of > time (and in the recent case, did not work at all). Quite sure this > can > be helpful for many. > > > > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93 > > > > > > Brian > > > > > > -- > > > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > > > ___ > > > 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 > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
Hello, I don't think this got through to the dev mail list, I'll forward it and add more comments. Thanks. Stephen On Sat, 2022-05-28 at 11:54 +0200, Christopher Klooz wrote: > On 28/05/2022 00:34, Stephen Snow wrote: > > On Fri, 2022-05-27 at 09:52 -0700, Brian C. Lane wrote: > > > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote: > > > > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > > > > > The rescue mode has always been on the traditional installer > > > > > images, > > > > > not the lives. It's still there. > > > > > > > > > Unfortunately there is no rescue option on the Fedora Linux > > > > Workstation > > > > installer just the Server and the Everything. > > > > Is this a part of Anaconda or a different package in Fedora > > > > Linux? > > > Rescue is an Anaconda feature: > > > > > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py > > > > > > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst > > > > > > It is not supported on live media since most of the steps just > > > don't > > > make sense -- live already sets up the network and you should be > > > able > > > to > > > use the regular desktop tools to mount your existing partitions. > > > > > Sorry but how does someone with a disability navigate that? > > The rescue mode while maybe unnecessary for developers and those > > well > > verse in Fedora Linux, but the inexperienced and the disadvantged > > don't > > get any consideration by your statement. And in the case of this > > particular example I cited at the beginning, the person is having > > MUCH > > difficulty navigating the Live USB approach to rescuing their > > system. > > > > > > Stephen > > If it does not require too much effort to implement this: +1 for > adding > a rescue to workstation live images. > > On ask.fp you will find many users not sufficiently advanced for > doing > all this on their own. And explaining such things can consume a lot > of > time (and in the recent case, did not work at all). Quite sure this > can > be helpful for many. > > > > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93 > > > > > > Brian > > > > > > -- > > > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > > > ___ > > > 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 > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
On Fri, 2022-05-27 at 13:13 -0400, Robert Marcano via devel wrote: > On 5/27/22 12:52 PM, Brian C. Lane wrote: > > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote: > > > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > > > > > > > > The rescue mode has always been on the traditional installer > > > > images, > > > > not the lives. It's still there. > > > > > > > Unfortunately there is no rescue option on the Fedora Linux > > > Workstation > > > installer just the Server and the Everything. > > > Is this a part of Anaconda or a different package in Fedora > > > Linux? > > > > Rescue is an Anaconda feature: > > > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py > > > > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst > > > > It is not supported on live media since most of the steps just > > don't > > make sense -- live already sets up the network and you should be > > able to > > use the regular desktop tools to mount your existing partitions. > > > > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93 > > True, but the Live image needs something like a command like > "fedora-prepare-rescue-image" or something like that that just do > what > the Fedora rescue option do and mount what it can find on > /mnt/sysimage. > > The steps to mount a complete /mnt/sysimage are a more than a few and > it > could help a lot not needing to type many things that an untrained > person could make a big mistake. > Agreed 100%! Stephen > > > > Brian > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
On Fri, 2022-05-27 at 09:52 -0700, Brian C. Lane wrote: > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote: > > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > > > > > > The rescue mode has always been on the traditional installer > > > images, > > > not the lives. It's still there. > > > > > Unfortunately there is no rescue option on the Fedora Linux > > Workstation > > installer just the Server and the Everything. > > Is this a part of Anaconda or a different package in Fedora Linux? > > Rescue is an Anaconda feature: > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py > > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst > > It is not supported on live media since most of the steps just don't > make sense -- live already sets up the network and you should be able > to > use the regular desktop tools to mount your existing partitions. > Sorry but how does someone with a disability navigate that? The rescue mode while maybe unnecessary for developers and those well verse in Fedora Linux, but the inexperienced and the disadvantged don't get any consideration by your statement. And in the case of this particular example I cited at the beginning, the person is having MUCH difficulty navigating the Live USB approach to rescuing their system. Stephen > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93 > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > On Wed, 2022-05-25 at 16:40 -0400, Stephen Snow wrote: > > Hello, > > I was doing my usual round of reading comments on ask.fp.o and came > > across an individual having difficulty getting their system > > (?back?) up > > and running, after update? > > This prompted me to open a discussion at > > https://discussion.fedoraproject.org/t/we-really-do-need-to-have-a-working-rescue-option-for-fedora-linux/39415 > > which also has a link to the original discussion on ask.fp.o if > > anyone > > is interested. > > I haven't used the live image system rescue option since almost > > forever > > , so I am assuming that it isn't working or is somehow difficult to > > use > > for this person, or maybe not an option anymore. > > I'm burning a F36WS installation with media writer to try out the > > rescue option, if it is still there. > > The rescue mode has always been on the traditional installer images, > not the lives. It's still there. > Unfortunately there is no rescue option on the Fedora Linux Workstation installer just the Server and the Everything. Is this a part of Anaconda or a different package in Fedora Linux? Regards, Stephen > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, 2022-05-26 at 14:07 -0400, Solomon Peachy wrote: > On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote: > > I am not talking about FLOSS vs non FLOSS, that's obvious. But > > bundled libs > > and properly tested / certified vs dynamic linking and less testing > > / no > > certification. > > I've been following this circular thread from the outset (And I do > make > use of Fedora's JDK packages), but one thing I don't recall seeing is > a > specific (or even general) example of the sort of failures/problems > that > have come from linking against system libraries vs just using the > bundled ones. > > Relatedly, I think it would also be very valuable to know if these > problems are mostly one-off (eg a major release of the jdk or > dependent > library lands in rawhide and breakage ensues), or occur throughout a > specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a > critical > security update which leads to a failure to pass TCK, or quarterly > java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to > fedora's > bundled library libfoo version) > I don't think that was the gist of it. I believe that it relates to the numbers of OpenJDK we carry, and the difficulty faced by the packagers of that to comply with packaging in Fedora's ecosystem when doing it. Libraries are bundled into jars not the source, etc... this all snowballs across what 4 version now supported? I don't remeber reading about unspecified TCK failures, just the workload as a result of our packaging requirements. > I mean, it's been strongly implied (if not outright stated) that > resolving these unspecified TCK failures, caused by using non-bundled > libraries, is the real burden, not the act of running the TCK for > each > build -- but is the TCK (or upstream JDK) really that _brittle_? > I built Netbeans for F36 Silverblue and when building it from source, it still uses maven repo to download binary tools (maven plugin's) to build with, this would be in violation of the packaging guidelines I think. So to package it I would need to also package all of those plugin's along side to support it in the Fedora Project ecosystem, just for the actual build process. Regards, Stephen Snow > - Solomon > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
So my take on the TCK is that Red Hat signed the OCTLA and Fedora Community get's to test their OpenJDK against it as a subequence. I didn't think Fedora the project, had any legal except what Red Hat provides, maybe I'm mistaken though so someone should clarify if they know for sure. Not only that, if we (Fedora Project) were the signatories, we would need auditing internally and externally to comply with requirements of the OCTLA from what I understand, which I imagine we do not have, nor want to entertain since it would require significant dedicated support likely. Basically anytime you use the TCK you need the paper trail. I still think the original proposal has some merrit at least of raisng the point of the workload required to maintain Fedora Lunix's java development stack. A rethink here would be good overall and really the technical build issues Jiri Vanik presented need to be overcome and should be the projects focus, not legal. Perhaps Fedora Project lead could discuss this with RH legal to get their perspective. I'm sure they're aware of the arrangement as it has been used by Fedora, and Fedora is not listed as signatory, and someone had to sign the agreement to get the TCK in the first place. >From that POV, to me as OpenJDK is still GPL3 released, and Fedora Project get's to use Red Hat's TCK to verify certification of compliance, so win win. Red Hat needs it for their own OpenJDK, which we no doubt have some involvement with, so again win win. Regards, Stephen Snow On Thu, 2022-05-26 at 11:38 -0400, Stephen Smoogen wrote: > > > On Thu, 26 May 2022 at 11:32, Kevin P. Fleming > wrote: > > On 5/26/22 11:06, Stephen Smoogen wrote: > > > 2. Are there ways that a non-TCK compliant version could be > > distributed? > > > > I would suggest phrasing that slightly differently: the version > > being > > distributed could very well be fully compliant (would pass the TCK > > if > > tested), but may not have been tested. > > > > > > > Yes, that goes into the my misunderstanding of what TCK is. Some > systems can only say they are 'compliant' if they are 'certified' and > anything else is 'fraudulent'. Others allow for 'complaint' and > 'certified' to be different. > > In either case, I should have clarified with 'certified'. > > > -- > > Kevin P. Fleming > > He/Him/His > > Principal Program Manager, RHEL > > Red Hat US/Eastern Time Zone > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Also, it may be good to take a look at what AdoptOpenJDK is doing with the Eclipse Foundation based Adoptium Project, specifically the Eclipse Temurin subproject https://projects.eclipse.org/proposals/eclipse-temurin-compliance which is going to handle the compliance requirements. In this scenerio the Eclipse Foundation is the license holder and the Adoptium project submits to the Temurin project to get certified. Maybe Fedora could use something similar with RH, who are signatories on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project. Just another thought on it. On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote: > On 26/05/2022 00:02, Demi Marie Obenour wrote: > > IANAL, but I believe APIs are not eligible for > > trademark protection, so Fedora would only need to change the stuff > > that is*not* part of the API. > > Yes. Google won a lawsuit against Oracle in the Supreme Court. > What law suit, and how does it apply to our situation? Regards, Stephen Snow > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
There sure seems to be confusion here around what exactly the TCK or JCK actually is. First off it is not a license. It is however a technical compatability certification which guarantees technical compatability between the different flavours of OpenJDK available out there, like RedHats (https://www.redhat.com/en/resources/build-of-openjdk-datasheet) Who signed the agreement (OTCLA) to get the TCK/JCK obviously The license aspect is found at https://openjdk.java.net/legal/OCTLA-JDK9+.pdf and is the agreement you sign to get access to the certification toolkit. Yes, everyone who distributes a version of OpenJDK does this, and I would think outside of hobby or education purposes, if you develop in Java you want this too. Regards, Stephen Snow On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote: > On 26/05/2022 00:02, Demi Marie Obenour wrote: > > IANAL, but I believe APIs are not eligible for > > trademark protection, so Fedora would only need to change the stuff > > that is*not* part of the API. > > Yes. Google won a lawsuit against Oracle in the Supreme Court. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
Thank you Sergio, This is a very useful file. Stephen On Wed, 2022-05-25 at 21:49 +0100, Sérgio Basto wrote: > > https://www.serjux.com/freedos_boot/Create-a-bootable-rescue.txt > > On Wed, 2022-05-25 at 16:40 -0400, Stephen Snow wrote: > > Hello, > > I was doing my usual round of reading comments on ask.fp.o and came > > across an individual having difficulty getting their system > > (?back?) > > up > > and running, after update? > > This prompted me to open a discussion at > > https://discussion.fedoraproject.org/t/we-really-do-need-to-have-a-working-rescue-option-for-fedora-linux/39415 > > which also has a link to the original discussion on ask.fp.o if > > anyone > > is interested. > > I haven't used the live image system rescue option since almost > > forever > > , so I am assuming that it isn't working or is somehow difficult to > > use > > for this person, or maybe not an option anymore. > > I'm burning a F36WS installation with media writer to try out the > > rescue option, if it is still there. > > > > Regards, > > Stephen > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > -- > Sérgio M. B. > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Live USB rescue mode, do we still have one? Does it work?
Thanks Adam I'll get that info to the user. And I thought it was still there and working, just haven't needed to use it in a vry long time. Stephen On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote: > On Wed, 2022-05-25 at 16:40 -0400, Stephen Snow wrote: > > Hello, > > I was doing my usual round of reading comments on ask.fp.o and came > > across an individual having difficulty getting their system > > (?back?) up > > and running, after update? > > This prompted me to open a discussion at > > https://discussion.fedoraproject.org/t/we-really-do-need-to-have-a-working-rescue-option-for-fedora-linux/39415 > > which also has a link to the original discussion on ask.fp.o if > > anyone > > is interested. > > I haven't used the live image system rescue option since almost > > forever > > , so I am assuming that it isn't working or is somehow difficult to > > use > > for this person, or maybe not an option anymore. > > I'm burning a F36WS installation with media writer to try out the > > rescue option, if it is still there. > > The rescue mode has always been on the traditional installer images, > not the lives. It's still there. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Live USB rescue mode, do we still have one? Does it work?
Hello, I was doing my usual round of reading comments on ask.fp.o and came across an individual having difficulty getting their system (?back?) up and running, after update? This prompted me to open a discussion at https://discussion.fedoraproject.org/t/we-really-do-need-to-have-a-working-rescue-option-for-fedora-linux/39415 which also has a link to the original discussion on ask.fp.o if anyone is interested. I haven't used the live image system rescue option since almost forever , so I am assuming that it isn't working or is somehow difficult to use for this person, or maybe not an option anymore. I'm burning a F36WS installation with media writer to try out the rescue option, if it is still there. Regards, Stephen ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:40 +0200, Fabio Valentini wrote: > On Wed, May 25, 2022 at 3:17 PM Jiri Vanek wrote: > > > > On 5/24/22 22:02, Fabio Valentini wrote: > > > Is this based on user requests, or is this only what you *think* > > > users > > > > I'm not sure what you mean - from above - what is based on > > mine/wider thinking > > Generally waht I wrote here it is based on judgmeent of about 10 > > people around OpenJDK pacages in Fedora. > > The equations above are based on realistic view and experience. Do > > you yo find some misscalcualtion above? > > > > I really appreciate you opinions, and would be happyt answer more > > precisely. > > Thank you for your response, I appreciate that you're engaging with > feedback here. > > The way I understood your last message, it seemed to me that you were > claiming that actual Fedora users are requesting that you ship so > many > different OpenJDK versions. > However, in this thread, I see the opposite - almost everybody is > asking you to consider dropping support for at least some non-default > OpenJDK versions, and nobody is advocating for keeping all of them. > So > my question was whether you have actual user feedback requesting that > so many different versions are available on Fedora. > > > > of OpenJDK on Fedora need? > > > Speaking for myself, I have never used anything other than the > > > default > > > "system JDK" for running Java applications on Fedora. > > > > Are you really sure? Many applications runtime requiter non system > > jdk, so they pull it in and use, and maybe you have not even > > noticed. > > Many develoeprs ahve installe dmany JDKS (in my case all from > > repos, unless I need to compile jimage) and the switch as needed. > > I'm quite sure, though I'm not using as many Java applications as I > used to. > The Minecraft "Java Edition" has always worked fine with the "system > / > default JDK", so I never needed to install another one. > And the JetBrains IDEs have bundled their own JDK for a while now, I > think, so I don't have to deal with those, either (and I wouldn't > even > want to mess with my main development environment to make it use > something other than the JDK it ships with). > > > > > > > What would you think about the following scenario: > > > > > > - Fedora X defaults to new OpenJDK LTS N > > > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the > > > change > > > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was > > > already > > > the default for one release > > > - do not backport OpenJDK n to Fedora X-1 and X-2 > > > - keep java-latest-openjdk, as you seen to need this for > > > bootstrapping > > > new OpenJDK releases > > > > This is possible solution. It will lower the TCK burden to aprox > > 3/5 with lost of most widely used JDKs from repositories. > > I'm open to this proposal. But the removal will hurt and way back > > will be much harder then swithing static builds back to dynamic. > > > > > > You could even drop java-latest-openjdk from all branches but > > > rawhide, > > > since it's only needed for bootstrapping there. > > > > Taht is very valid point. Cost is it will force huge number of > > uses to download 3rd party latest STS jdk. it is where all new > > features live. > > Are there really that many Fedora users who need and install > java-latest-openjdk? Do you have estimates of how many people do > this, > compared to how many users just use the default system JDK? > > > > This should pretty dramatically reduce the size of your test > > > matrix. > > > Applying the current numbers: > > > > > > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk > > > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case > > > the > > > default needs to be switched back), java-latest-openjdk > > > - Fedora 35: java-11-openjdk, java-latest-openjdk > > > > > > > it is a bit less then I wrote, - about 3/5 of current load but do > > yoreally wish to cut all those jdks from fedora? > > To me the static repacked build sill somehow seems as smaller evil > > then drop practically all interesting jdks out of distro. > > Yeah, why not? I'm asking whether it's actually worth your time to > keep them around. Given that there's probably limited userbase and > the > resources that are needed to keep them around, this is a valid > question, I think. Speaking for myself, I'd rather have the default, > integrated, system JDK be of the high quality it has been in Fedora, > rather than having many different, less-integrated versions around. > > > So here I need to rephrase your question - is it based on your's > > thinking or on what fedora users really needs? > > I think the oposite - they need all jdks which are around. Proeprly > > integrated with system. How they are built .. they do not care. > > If update to neewer Fedora wil lmake some older JDK disapear, or if > > need of new one will force me to update Fedora when I don't want or > > cant. I call it
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:03 +0200, Jiri Vanek wrote: > > > On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: > > On 24/05/2022 21:00, Jiri Vanek wrote: > > > I repeat what was told several times.We really do no t like this > > > change, especially in its full sound of one static build repacked > > > to all ive fedoras, but we have nto found a better way. > > > > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't > > need certified binaries. > We can not ship uncerified JDK. Sooner or later a swarm of lawyers > would appear. > 100%, though I am not one, I understand as much from the TCK itslef. > > All they need is a working and well packaged OpenJDK. > > > > From point of view of JDK, the jdk will remain working. From point > of JDK and generric java world the jdk will be even better. > From view of distributions standarts it will become weird misshape. > Serving it purpose in build root well, serving as system or > distribution jdk well. But yeah... all was said on this toppic > already:( > As a user of the JDK as Fedora Linux currently ships it, I can say I am very grateful for the efforts being made to accomodate it. > > 2. Reduce the number of OpenJDK branches in the repositories. I > > think the latest LTS version will be enough. > I have also suggested this, but in historical context JDK 6 hung around about 10 years longer than expected I think due in large part to the inertia built by it's prolific use in enterprise systems. This will undoubtably hold true for JDK 8 as well, since it is currently the preferred choice by most. Technically speaking WRT JDK releases, some fall by the wayside (jdk 9 and jdk 10 are two recent). > I wish it is so simple. Please see my reply to Kevin when I > enumerated, that we can not keep "jsut latest" lts. > > > Regards, Stephen Snow just some dude who can program ... whatever > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-18 at 14:39 +0200, Petr Pisar wrote: > V Wed, May 18, 2022 at 08:09:06AM -0400, Stephen Snow napsal(a): > > Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams > > wrote:(snip unrelated) ... > > > In this thread it was claimed (I believe by a packager) that TCK > > > is > > > important to Java users, but I haven't seen any users say that. > > > > > > I'm not a Java user... I had never heard of TCK. I just went > > > searching, > > > and I don't see anything right off that shows that Fedora's > > > OpenJDK is > > > certified in any way. How would I even know? > > > > > Below is the link to the JCK/TCK and to be able to use the OpenJDK > > name you > > must sign the agreement and then you get access to the JCK which is > > the > > certification test API. Then you get to run certification tests for > > every > > build, if I read the agreement correctly. > > https://openjdk.java.net/groups/conformance/JckAccess/ > > > Is that (OpenJDK) still a free software? I mean the rights to modify > and > redistribute? If it isn't, is it suitable for Fedora? Or is too big > to fail > like the case of Firefox which we cannot call Firefox if we patch it. > Sorry my bad, the agreement is for being a contributor to the Oracle Open Community at https://oca.opensource.oracle.com/ not licensing for redistribution. I am not in any way giving legal advice here, just providing the info I could find. I think this is still a necessary if you want to seriously have any Java development stack available to Fedora Linux users though. Otherwise, it is totally doable in a self supported way by each dev, and I'm sure they all know how to but, I really like the fact that my distribution provides this now, it works. Stephen > -- Petr > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-18 at 07:27 -0500, Chris Adams wrote: > Once upon a time, Stephen Snow said: > > Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams > > wrote:(snip unrelated) ... > > > In this thread it was claimed (I believe by a packager) that TCK > > > is > > > important to Java users, but I haven't seen any users say that. > > > > > > I'm not a Java user... I had never heard of TCK. I just went > > > searching, > > > and I don't see anything right off that shows that Fedora's > > > OpenJDK > > > is > > > certified in any way. How would I even know? > > > > > Below is the link to the JCK/TCK and to be able to use the OpenJDK > > name > > you must sign the agreement and then you get access to the JCK > > which is > > the certification test API. Then you get to run certification tests > > for > > every build, if I read the agreement correctly. > > https://openjdk.java.net/groups/conformance/JckAccess/ > > That's a list of organizations that have signed the agreement (which > notably for this discussion, does not include Fedora). But does include Redhat, which in this case obviously supports Fedora. > I don't see a > list of "passed the test", nor do I see something on the Fedora > packages > that says "passed the test". The claim was made that this test is > important for Java users, yet I can't find any indication that > Fedora's > (or anybody's for that matter) pass it. It's a licensing agreement effectively. It provides the distribution with early access toolkits and Technology Compatability Kits AFAIK from reading the licensing agreement. There is also some emphasis on being a good community member and contributing, but it looks like a purely legal intent being applied to technical compatability source code. > > Testing is great and important, but saying that users care about the > results of the testing is hard to understand when the test results > appear to be undocumented. > I would think the "Technical Compatability" benefit is self evident, even for "users". For one thing it helps continue the build once distribute anywhere slogan of Java, but it also gives a modicum of confidence to users that there is a "standard" being applied. So, from reading the info, the tests are likely part of the toolkit and you don't get to see the toolkit until you sign the papers. This seems sort of the antithesis of FOSS don't it? Regards, Stephen -- > Chris Adams > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams wrote:(snip unrelated) ... > In this thread it was claimed (I believe by a packager) that TCK is > important to Java users, but I haven't seen any users say that. > > I'm not a Java user... I had never heard of TCK. I just went > searching, > and I don't see anything right off that shows that Fedora's OpenJDK > is > certified in any way. How would I even know? > Below is the link to the JCK/TCK and to be able to use the OpenJDK name you must sign the agreement and then you get access to the JCK which is the certification test API. Then you get to run certification tests for every build, if I read the agreement correctly. https://openjdk.java.net/groups/conformance/JckAccess/ If I could just add one more thing to this discussion. I would like to point out Fedora's First foundation as applicable WRT the java ecosystem. Do we need OpenJDK 8? I mean I would think that Latest +1 in Rawhide, Latest and latest -1 on current Fedora Release, then latest and latest -1 and latest -2 on the due to eol at next release Fedora. I too use the system OpenJDK for java development, and the packaged ant and the packaged Maven, successfully and consistently on Fedora Linux for some years. Just yesterday I built the Netbeans IDE 13 using them in a toolbox container on my Silverblue box.All I had to install in the toolbox was java-17-openjdk-devel.x86_64 and ant from the Fedora Linux repos. I haven't had a need to use OpenJDK 8 in over two years now, and the last time I had to do anything with OpenJDK 11 was some 8 months ago. I don't have much Enterprise level development/support requirements so my use cases are sot like others, but the bulk of my java development is with OpenJDK 17 and with the packaged Fedora OpenJDK. If I remember the IDE exodus correctly, it was driven by issue overload on the part of upstream, in some cases I think those packaging for Fedora didn't get the attention needed to keep successfully packaging. I also think it was distro agnostic, meaning it happened everywhere. Hence flatpaks and snap apps. One more point, the reason I built Netbeans instead of using the Flatpak version available was it works better for me as a host package. The flatpak version has issue finding the system libraries which forces you to copy in multiple jar libraries for one. Thank you everyone who helps maintain the current offering of Java and tools. Regards, Stephen > -- > Chris Adams > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Do we have any policy for disabling inactive users
On Thu, 2022-02-17 at 19:22 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote: > > On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote: > > > On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote: > > > > Hello, > > > > I don't mean to jump in the midle here, and I am just tossing > > > > out > > > > an > > > > idea for consideration that doesn't address security issues > > > > pointed > > > > out > > > > really, but does discuss the non-responsive main maintainer. > > > > I note there is a difficulty in defining the criteria for > > > > determining > > > > when an (apparently) inactive packager should be removed from > > > > the > > > > packager group. Perhaps a different POV is required. What is > > > > the > > > > problem trying to be solved? Removal of inactive packagers? Or > > > > the > > > > demotion of said packager in favour for the one(s) who are > > > > supporting > > > > the package to be promoted to main. > > > > > > The former. The main issue here is a security concern: that the > > > accounts of dormant packagers could be taken over and used for > > > evil. > > > So > > > just shuffling the deckchairs of whether someone is a 'primary' > > > or > > > 'co' > > > maintainer on a given package doesn't help. As long as they are > > > allowed > > > to submit official builds of the package, the problem remains > > But wouldn't be possible to move their deckchair into a sandbox? > > That is what we are effectively doing. By removing them from > @packager, > they lose write access to packages. It is also very easy to undo. > In your approach, we'd do this package-by-package. That'd be more > complicated and harder to undo, and wouldn't really help with > the security concerns. > Thanks for the explanation, and I appreciate that I was naive potentially with my simplistic question and the complexity of doing packager rights on a per package basis does seem onerous. So if I understand it correctly this is a @packager group level demotion, so no longer a packager at all, but could be easily promoted to that status if need be in the future. That would seem to be a sensible approach. I would assume there is already a process to deal with accounts that may have been compromised. Stephen > Zbyszek > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: CVE's and older versions of software
On Wed, 2022-02-16 at 22:50 -0500, Demi Marie Obenour wrote: > On 2/16/22 18:05, Adam Williamson wrote: > > On Wed, 2022-02-16 at 14:20 -0500, Steven A. Falco wrote: > > > On 2/16/22 01:58 PM, Dan Horák wrote: > > > > On Wed, 16 Feb 2022 13:53:04 -0500 > > > > "Steven A. Falco" wrote: > > > > > > > > > There are some CVE's against KiCad that have been fixed in > > > > > the latest version, namely KiCad 6.0.2. I've built that for > > > > > F36 and Rawhide. > > > > > > > > > > I have not released KiCad 6.0.2 into Fedora 34 and 35, > > > > > because my understanding is that by policy, we don't > > > > > generally allow "major version" updates in stable Fedora > > > > > releases. Thus F34 and F35 still ship KiCad 5.1.12, which is > > > > > affected by the CVE's. > > > > > > > > > > I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I > > > > > have done so in the KiCad Copr repository. > > > > > > > > > > So, should this situation be an exception to the policy of > > > > > "no major version changes in a stable release"? > > > > > > > > as often, it depends :-) > > > > > > > > - what's the severity level of the CVEs? > > > > - does KiCad 6 come with substantial changes like UI redesign, > > > > compatibility issues with previous release, etc? > > > > > > The vulnerability is rated as "7.8 - > > > CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that > > > means. :-) > > > > > > Basically, attempting to read a malicious file can cause a buffer > > > overflow, and then execute malicious code. > > > > > > KiCad is not suid, so the risk would be to an individual user > > > rather than the whole system. > > As shown in https://xkcd.com/1200/, this is not a mitigation in > practice, because most Linux systems are single-user, which means > that > a user compromise is effectively equivalent to root compromise > > > > KiCad 6 does have UI changes and files it creates cannot be read > > > by KiCad 5 or earlier. > > > > > > I contacted upstream, and I know what patches form a part of the > > > solution, but they don't apply cleanly to KiCad 5. I might be > > > able to sort them out... > > > > The 'ideal' solution is to backport the security fix, yes. If > > you're > > not able to do this, or find anyone else who can do it for you, I > > guess > > it kinda becomes a judgment call whether fixing the security issue > > is > > "worth" the compatibility problems. I don't think we have a > > definite > > guide/policy to what to do if the optimal solution isn't practical, > > here? > > Security researcher here. My view is that there are some packages > for > which the release cycle needs to be that of upstream, even if Fedora > has a different one. Browser engines and the Linux kernel certainly > fall into that category, and complex desktop software such as KiCad > might as well. I would rather take the compatibility breakage a bit > early than have an insecure system. > Fedora Linux user here +1 on these comments by Demi Stephen Snow > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Very good, Thank you for further clarification. Stephen On Wed, 2022-02-16 at 18:18 +, Timothée Ravier wrote: > > I use Silverblue. How does this affect my ability to modify /etc in > > the > > opt-in scenario? Does rpm-ostree offer a method to modify /etc in > > that > > case? What if I want a mutable /var, like I currently have, does > > this > > change under this proposal? What is the value of this for the > > normal > > Fedora Linux user? > > Note that this is only about `/sysroot`, not `/` (root). Thus `/etc` > and `var` are still writable in all cases. > > > I don't know. I think not being able to boot into my previous > > deployments a visible change to my user experience. > > Once the new option has been set, you will have to append `rw` to the > kernel command line to previous deployments that were created before. > > We could also probably make this even more conservative and have it > only enabled once all your deployments have the new kernel option. > This should avoid the case where you can not bee an older deployment > anymore. > > The idea is to make the update happen in two steps: > - First add the `rw` kernel arguments, > - Then set up the `sysroot.readonly` option once all previous > deployments have the rw option. > > -- > Timothée Ravier > CoreOS engineer & Fedora Kinoite maintainer > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Thanks for your clarification Colin. Stephen On Wed, 2022-02-16 at 13:16 -0500, Colin Walters wrote: > > > On Wed, Feb 16, 2022, at 12:48 PM, Stephen Snow wrote: > > On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot > > > > > > == Summary == > > > > > > This change is about enabling an opt-in ostree feature that re- > > > mounts > > > `/sysroot` as read only to avoid accidental changes. > > > > > > Users and administrators are not expected to directly interact > > > with > > > the content available there and should instead use the interface > > > offered by rpm-ostree, GNOME Software or (soon) Plasma Discover > > > to > > > manage their system. > > > > > I use Silverblue. How does this affect my ability to modify /etc in > > the > > opt-in scenario? > > It doesn't; `/etc` is mounted writable. > > > Does rpm-ostree offer a method to modify /etc in that > > case? What if I want a mutable /var, like I currently have, does > > this > > change under this proposal? > > `/var` does not change either. > > > What is the value of this for the normal Fedora Linux user? > > The basic idea is that `/sysroot` is actually an ostree > implementation detail, and really nothing else should be writing to > it. > > Fedora CoreOS has worked this way for a long time; we just didn't > make the change in ostree by default out of conservatism. > > > See, that's an unwelcome thing IMO. > > I think actually the migration service could inject `rw` into all > bootloader entries actually. > > > I don't know. I think not being able to boot into my previous > > deployments a visible change to my user experience. > > The service adjusting all bootloader entries is the easy fix for > this. > > Or, TL;DR: Don't panic, no power is being removed and it's very > likely that no one will notice. > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Do we have any policy for disabling inactive users
On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote: > On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote: > > Hello, > > I don't mean to jump in the midle here, and I am just tossing out > > an > > idea for consideration that doesn't address security issues pointed > > out > > really, but does discuss the non-responsive main maintainer. > > I note there is a difficulty in defining the criteria for > > determining > > when an (apparently) inactive packager should be removed from the > > packager group. Perhaps a different POV is required. What is the > > problem trying to be solved? Removal of inactive packagers? Or the > > demotion of said packager in favour for the one(s) who are > > supporting > > the package to be promoted to main. > > The former. The main issue here is a security concern: that the > accounts of dormant packagers could be taken over and used for evil. > So > just shuffling the deckchairs of whether someone is a 'primary' or > 'co' > maintainer on a given package doesn't help. As long as they are > allowed > to submit official builds of the package, the problem remains But wouldn't be possible to move their deckchair into a sandbox? Stephen > . > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot > > == Summary == > > This change is about enabling an opt-in ostree feature that re-mounts > `/sysroot` as read only to avoid accidental changes. > > Users and administrators are not expected to directly interact with > the content available there and should instead use the interface > offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to > manage their system. > I use Silverblue. How does this affect my ability to modify /etc in the opt-in scenario? Does rpm-ostree offer a method to modify /etc in that case? What if I want a mutable /var, like I currently have, does this change under this proposal? What is the value of this for the normal Fedora Linux user? > == Owner == > > * Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš > Popela]], [[User:jkonecny| Jiří Konečný]] > * Email: si...@fedoraproject.org, tpop...@fedoraproject.org, > jkone...@redhat.com > * FESCo shepherd: [[User:Ngompa| Neal Gompa]] > ngo...@fedoraproject.org > > > == Detailed Description == > > On rpm-ostree based systems, the real root (the root directory of the > root partition on the disk) is mounted under the `/sysroot` path. By > default it contains the state of the system (the content of `var` and > `etc`) as well as the system versions themselves (each versioned copy > of `/usr`) in the ostree repository (`/ostree/repo`). > > This change is about enabling an opt-in ostree feature that re-mounts > `/sysroot` as read only to avoid accidental changes. > > Users and administrators are not expected to directly interact with > the content available there and should instead use the interface > offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to > manage their system. > > Example of issue: > https://github.com/fedora-silverblue/issue-tracker/issues/232 > > This change replicates for Fedora Silverblue/Kinoite what has been > done in Fedora CoreOS in a previous release. > > == Feedback == > > None so far. > > > == Benefit to Fedora == > > This will make Fedora Silverblue/Kinoite more robust to accidental > damage from users. > > == Scope == > * Proposal owners: > ** Work on the changes requires for new installations (potentially > Anaconda configuration changes) and support for in place updates for > existing installations (requires a two step process). > * Other developers: > ** Potential Anaconda changes required. > * Release engineering: N/A > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: N/A > > == Upgrade/compatibility impact == > > We will create a systemd unit that perform the updates in place for > existing systems. This will require a two step process (changing the > existing kernel arguments, and then enabling the ostree feature). > Once > the feature is enabled, user won't be able to rollback to previous > deployments where the kernel argument is not set. We will have to > clearly document that in the documentation for easier > troubleshooting. > See, that's an unwelcome thing IMO. > == How To Test == > > Only try the following if you are confortable debugging an un- > bootable > system and have made backups! > > `$ sudo rpm-ostree kargs --append-if-missing=rw` > > `$ sudo ostree config --repo=/sysroot/ostree/repo set > "sysroot.readonly" "true"` > > `$ sudo systemctl reboot` > > Note that you can not "rollback" to the previous deployment to undo > this change. You will have to boot into a Live ISO and edit the > config > file in the ostree repo to remove this config option. > > == User Experience == > > There should be no visible change in user experience. > I don't know. I think not being able to boot into my previous deployments a visible change to my user experience. > == Dependencies == > > Requires changes in Anaconda (maybe just config?) to set default > kargs > and property on ostree repo for new installations. > > == Contingency Plan == > > Revert the change before the release. > > == Documentation == > > N/A (not a System Wide Change) > > == Release Notes == > > TODO > Seems like there is lot's more todo. > Stephen > -- > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list --
Re: Do we have any policy for disabling inactive users
On Wed, 2022-02-16 at 17:38 +0100, Emmanuel Seyman wrote: > * Stephen Snow [16/02/2022 11:21] : > > > > Perhaps the automation should > > do > > just that, demote primary packager (from owner to co-maintainer) if > > inactive for over a year and promote the main supporter for the > > year to > > be the owner from co-maintainer. > > Can you define "main supporter"? > I was supposing in this case it is a FAS account user who is coincidentally a main packager or maintainer, and main supporter would be in this case a co-maintainer who is actively doing the maintanence instead (or maybe a FAS holder submitting PR solutions repeatedly?). Because, old accounts should be able to have reduced privileges after a certain period of inactivity I would think, but I am reluctant to advocate removing users simply for inactivity since that state can as easily change without notice to the communty necessarily. But maybe I miss the point of the original idea, since there also seems to be a tie in to how secure the build system is which to me is a different discussion, with some overlap of functional outcome. Stephen > Emmanuel > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Do we have any policy for disabling inactive users
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main. Perhaps the automation should do just that, demote primary packager (from owner to co-maintainer) if inactive for over a year and promote the main supporter for the year to be the owner from co-maintainer. Doesn’t something like that satisfy the inactivity requirement and also prevent alienating some packagers? Just bike shedding here. Stephen On Wed, 2022-02-16 at 11:48 +0100, Vitaly Zaitsev via devel wrote: > On 16/02/2022 11:32, Björn Persson wrote: > > Loss of an email address does not imply loss of a FAS passphrase, > > so in > > most cases they would just log in as usual. > > We're talking about potentially hacked accounts, right? If the hacker > has the password, they can easily restore this account. That's why we > need another way to verify maintainer's identity. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Wed, 2022-01-26 at 09:25 +, Roberto Sassu via devel wrote: > > ...snip > > If the users often make changes on their system, with high > privileges, > I agree that DIGLIM would simply cause too much overhead for > the configuration (every time the users make a change, they have > to whitelist their software). > Yeah that will definitely be a problem in my use cases. You know, if I wanted to have something interfere with my work, like Windows, I would just install Windows. Stephen > Roberto > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > Managing Director: Li Peng, Zhong Ronghua > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote: > With Windows 11, they're *mandatory*. Corporate policies now > effectively *require* TPM-based mechanisms *in addition* to classical > password or token-based multi-factor authentication. This certainly is not any reason to adopt this for Fedora. So far in my life with TPM, it has been an annoyance that I find refreshing not to have to even contemplate with my Fedora Linux installation. I see no benefit for the Fedora Community and the Fedora Project it supports to follow the lead of the proprietary driven objectives. The only obvious one that comes to mind is the recent announcements of it's inclusion on traditionally proprietary OS vendor supplied hardware. This wreaks of "for profit" motivation. Just my opinion on what I am reading here in the comments. Regards, Stephen Snow ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Question for election candidates: do you support allowing Fedora src-git repositories to be hosted on a proprietary software git forge?
> It's too late for the questionnaire, yes, but... too late to ask??? > > I mean... that would have been a good way to make sure everyone at > least > provided some answer, but I don't think we have (or should have) any > rule > against asking FESCo or Council people questions at other times. > > 100% Agree with that Stephen Snow > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hello Otto, I like the "Web based course" idea alot. I had thought of creating something as a pod of containerized parts of the whole to be used in a cloud server environment, or on a single machine and would be a reactive app, or collection of say. Anyway, I am very receptive to these ideas, the actual implementation I think we would need to sort out after we collective decide what it is that needs to be made, improved, dropped. I would like to start at it smaller per se', not try to get it all right at first. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Trying to take an orphaned package
On Sun, 2021-11-21 at 11:18 -0500, Matthew Miller wrote: -snip- > > I don't think we have a good process for the situation you're in. If > the > package you were interested in were entirely new, or if you were > reinstating > a package which wsa retired (the step beyond "orphan"), you'd file > and go > through the package review process in bugzilla, and at that point if > you > hadn't found a sponsor yet, the docs suggest that the sponsor's > ticketing > system is the next step. > So what I have figured out from the experiences of others who have shared with me is I can just do a PR for the fix I think will work for said package and submit it that way. Thus support in an unoffical capacity, which is entirely acceptable in my opinion, but it isn't a documented route nor a formal one, just one that works. > But without those first steps, how do you get there? > > Probably the most straightforward is to pick one of the other routes > -- ask > to become a co-maintainer of an existing package, or find something > new > you're interested in. Or, go through a number of code reviews for > similar > packages and get to know the folks who are working on those, at which > point > it should be easy to ask them personally to sponsor you. > I guess that is along the lines of what I was saying above and what others have suggested to me in the past on this topic. > I know this feels like kind of _a lot_, when you just want to help > out by > picking up something that's dropped. But the thing is, once you're in > the > pcakaging group, you have a lot of latitude to make a lot of > technical > decisions. It's not so much a matter of "do we trust you as a person" > as it > is "have you demonstrated that you understand a lot of the nuance and > complication of packaging and working in our environment." > Yeah so I get this without question and understand emphatically even. In what I do (Industrial Automation and Machine building) you can spend years doing the "same thing" differently each time. > If you'd prefer a less-heavy way to just make a package available, we > have > that too, in Copr. There, you can just get started and do it. Been thinking about that very thing for PLC4X maybe. > > > I do think we need to help build a greater pool of people with the > required > skills, time, and ability to mentor new packagers -- sponsorship with > support, not just as a checkbox. We've got some awesome folks who do > that, > but... it _is_ a special skill and _definitely_ time consuming. So > that's an > area I know we need to invest in. I still think a lot of what Mentors and Sponsors could be satisfied the applicant had a particular set of abilities if they had to get through some form of app based intruction and test possibly even broken down into the separate steps of packaging maintenance. With feedback to the newb and validation testing that would give at least a level of confidence to the community too. Let's be honest, we want involvement but all of us want a working Distro more than making it "easier" to get involved. And getting involved is what we're discussing here, whether me or others feeling like. To my way of thinking, it's not that the complexity is a deterent, normally the opposite for most technically oriented people AFAICT. It is really the lack of a map, which itself doesn't need to be a hand held journey, just sign posts. Maybe this is documentation, but I am really reluctant to just chalk it up to that entirely. So we are talking the same I think but from the opposite side of the discussion, and this does seem to be the way everyone feels when this topic comes up. > But... I hope the above helps explain how > things are now in practice. > > Yes, it is clear in some ways as to why it is done the way it is done WRT the packages themselves and the requirements of Fedora Linux, licensing included. What is not clear is how to get from the starting point most of us have. Which is not hired by RH, or not working at a company that specifically uses Fedora Linux as part of their business model. Don't take that wrong either, I entirely appreciate RH et al for their much needed support, as I would imagine the greater community does too. But I also appreciate the efforts of each and every non- business related contributor (ie they don't get paid directly to work on that thing for Fedora Linux), because quite frankly without them there likely wouldn't be a Fedora Linux and we'd just be running RHEL community, so not so delightedly near bleeding edge. In any case I will keep plugging away, maybe just try to get it to build and issue a PR with my solution. But it's currently orphaned with no maintainer AFAIK. Regards, Stephen > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: >
Re: Trying to take an orphaned package
On Sun, 2021-11-21 at 15:08 +, Tom Hughes wrote: > > That's why I gave a link to the old version from the wiki history > before it was replaced by a pointer to the new page. > It did help for some info. Thank you. > > > https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444 > > > > > > Basically you need to find somebody to sponsor you as a > > > packager - normally that happens as part of having your first > > > package review but obviously that doesn't work when you want > > > to take over an existing package. > > > > So you see what I was talking about so many (years?!?!) ago, then > > recently too on this list. It is a common thing it seems that once > > a > > person steps up to ask for sponsorship something seems to happen. I > > am > > struck by the first line of your response "You say you have "asked > > to > > become a packager" but what exactly do you mean by that?" Well, > > quite > > simply what I stated, but yet I am being questioned about my > > sincereity > > and credibility immediately. > > I wasn't questioning your credibility, I was just confused because > there's no formal place to lodge such a request as far as I know > other > than a review ticket blocking FE-SPONSOR which doesn't apply here. > > I was worried that you had filed some sort of request somewhere > that nobody was looking. > So maybe we have inadvertently found a crack in the process for onboarding package maintainers. > > So back to what I was trying to say in my conversation here about > > some > > tool for assessing the prospective newbies like me who want to help > > but > > need a sponsor, I was thinking of an app that tests your knowledge > > and > > the discussion went towards a generic test package to show > > packaging > > knowledge with, then make sponsoring come easier for sponsors. > > Because > > this seems to be really the crux of the matter, trust or lack of > > it. > > I'm not aware of any previous discussions. I was just answering > the questions you asked in your post today. > > Tom > Again, thank you for taking the time to respond. FWIW I recognize your name from RH and Fedora for some time, ie years, not trying to make anyone feel old but it is what it is. The previous discussion was around onbarding new package maintainers, and the impetus is directly related to the published orphaned packages, and trying to make them not be orphaned if needed still. There is a disconnect between the position taken in the documents around becoming a packager that seems to imply it is as easy as doing steps #1, #2, then #3, which it isn't. Also worth noting is that there is a "dummy onboarding package" that was started by someone on this list as a result of the conversation but I haven't found any continuation of the idea. Regards. Stephen ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Trying to take an orphaned package
On Sun, 2021-11-21 at 13:55 +, Tom Hughes wrote: -snip- > You say you have "asked to become a packager" but what exactly > do you mean by that? > I've asked to be sponsored before. > The official documentation on becoming a packager is here: > > https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ > Thanks read that back then. > But actually I think the old wiki version is much more useful > in explaining how things work, especially if you're not coming > at it from the position of submitting a new package: > And it tells me to read a document that doesn't apparently exist anymore. > https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444 > > Basically you need to find somebody to sponsor you as a > packager - normally that happens as part of having your first > package review but obviously that doesn't work when you want > to take over an existing package. > > Tom > So you see what I was talking about so many (years?!?!) ago, then recently too on this list. It is a common thing it seems that once a person steps up to ask for sponsorship something seems to happen. I am struck by the first line of your response "You say you have "asked to become a packager" but what exactly do you mean by that?" Well, quite simply what I stated, but yet I am being questioned about my sincereity and credibility immediately. The documentation referrals are good, but I have read the doc's and can read them while in process of doing tasks such as packaging, that's sort of what higher education is supposed to do for us, teach us how to research the technical aspects of whatever task we face. So back to what I was trying to say in my conversation here about some tool for assessing the prospective newbies like me who want to help but need a sponsor, I was thinking of an app that tests your knowledge and the discussion went towards a generic test package to show packaging knowledge with, then make sponsoring come easier for sponsors. Because this seems to be really the crux of the matter, trust or lack of it. And I really do want to help with this package since ti seems to be a dependency for some others and it is important to me to see Fedora Linux remain a usable distribution (entirely selfishly here). Regards; Stephen (FAS ID jakfr...@fedoraproject.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trying to take an orphaned package
Hello, So I am back here to ask again if I can take a package on that is currently orphaned as per https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/5FCP5OSV6XXFCAXN5KPKQFBCDLGJSRB6/ And I login with my FAS ID and cannot "Take" the package since I am not a packager. So I ask again what steps am I missing here? I want to take over packaging something that is about to be removed from Fedora Linux since it has been orphaned, I have signed the agreements, I have asked to become a packager, and this is actually the second package I am trying to take over. The package I am interested in taking/sharing maintaining with is https://src.fedoraproject.org/rpms/Java-WebSocket I think it is likely a maven plugin issue just looking at the root log. Thoughts? Regards, Stephen ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 - gedit
I cannot get Gedit to do this when I use it as a text editor, even for extended periods with intermittent thrashing, like loads of edits without a save, etc... It does sound almost hardware specific, maybe failing keyboard.? Stephen On Tue, 2021-11-09 at 12:49 -0800, Adam Williamson wrote: > On Tue, 2021-11-09 at 18:59 +0100, Michael J. Baars wrote: > > Hi Adam, > > > > I didn't install any update, apparently the update is already > > included with > > the release version of Fedora 35, because it won't install from the > > command > > line and the versions from the build match the versions from the > > release. > > This is a fresh installation of Fedora 35 Workstation, done the day > > before > > yesterday. > > > > So, with the updates INCLUDED instead of installed, the mouse > > pointer and > > the cursor (still) act strange when running gedit. When I try to > > move the > > mouse into position and click to move the cursor into position, for > > example > > to cut and past text, both OFTEN (say 50% of these attempts) end up > > on a > > completely different line number, sometimes even selecting some > > text in the > > process. > > > > The updates as provided by the build and as included in the release > > version > > of Fedora 35, do therefore not function as intended. > > > > Precise sequence of steps: > > 1) turn on computer > > 2) open text files from file manager > > 3) start editing > > > > Nothing more, nothing less, nothing out of the ordinary either. The > > problem > > had never reveiled itself on another one of my computers, which is > > still > > running Fedora 32 Workstation. It's definitely new, impossible to > > overlook, > > and impossible to ignore when your used to working with gedit as > > your > > default editor as I am. > > Thanks. So: > > 1. That update was not included in the release. The update was > created > on 2021-11-04, which is *after* the release happened (on 2021-11-02), > let alone when the release was signed off (2021-10-28) or actually > built (I think that was 2021-10-25). The release has gnome-shell- > 41.0- > 4.fc35 and mutter-41.0-4.fc35 . You can see this for yourself at > https://dl.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os/Packages/g/ > and > https://dl.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os/Packages/m/ > . This is just a note, as long as you have the updated versions and > have rebooted since installing them, it doesn't really matter where > you > got them. > > 2. The problem you are having is not the problem the update was > intended to fix. I know this because I was the person who noticed the > problem and backported the fix. That problem did not occur simply by > opening a file and editing it, it always involved switching focus > between the text editor and other windows. There are more details on > the bug the update actually fixes at > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4647 . The update > definitely did fix that problem, because I had it before and I don't > have it now. > > 3. The problem you're hitting now is not likely a general one, or > else > a lot more people would likely be complaining about it, given how > "impossible to overlook" (your words) it is. It's not happening to > me, > for instance. gedit behaves just fine for me. Unless anyone else can > reproduce it by just running gedit, we still need to figure out what > exactly in your configuration is triggering the problem. Maybe you > could record a video of it? That might show something that helps. > > Thanks! > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Wed, 2021-10-13 at 14:33 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 13 October 2021 at 13:08, Luna Jernberg wrote: > > You had to register at a website during the event, > > That I did. On August 7th, I received an e-mail with a promo code to > enter at https://coolstuff.redhat.com/promo/fedora which I did, but I > haven't heard from them since. > I got the confirmation of regsitration almost immediately after registering. > > got an email with > > tracking information from both Fedex and Red Hat > I got the email with tracking info two days prior to arrival of swag. but in between reg and ship, no communication. > Nothing yet. :( > > Regards, > Dominik > -- Hope it arrives for you soon, Stephen > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess > Irulan > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
Got mine the other day. It is really a lot of cool things Fedora. Thanks to the Sponsors of this years Nest. Looking forward to the release party in November! Stephen On Tue, 2021-10-12 at 13:29 +, Michael J Gruber wrote: > Today that special package for Nest participants arrived here. > Back then I thought: "Nice, a few stickers." Today, after opening the > package, I thought: "Woah!". [ No spoilers here ;) ] > > So, thanks to anyone who made possible Nest as well as this form of > community appreciation! > > [posting it here where I learned about Nest; feel free to redirect] > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote: --snip-- > So it > seems we are in agreement with the `dummy-onboarding-` prefix No, it should be something more appropriate like `entry-level-tutor-` or something equally as nuetrally offensive. Dummy is a very negative word with no value of positive connotations in the English language. regards, Stephen ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
> (snip) > You also need people who are good at documentation which frankly many > developers are not. Be it a history of 'the only true documentation > is > the code' to 'look its simple why didn't you just no one would think of and impossible to document without knowing why > it was chosen or used>. It's the most obvious choice? Too true, I personally have been doing systems integration goin on (oh god) 35 yrs, and the last bit of work (you know tha documents that prove you should get paid for the work) is the hardest for me. In fact I have spent a considerable amount of foundation work over the years to get templating and scripting in place for me to be able to automate as much of my documentation as possible. > It isn't that the developer is trying to be obtuse, I think it is how > the brain works for a lot of people. My autism makes it very hard for > me to communicate about code. I can think it, see it, dream it, but > once I get into 'word' mode I can't access it easily. And vice versa, > when I am in code mode, I am almost non-verbal and my emails get very > short and succinct (at least to me..).. Switch me over to word mode > and it takes me hours to be productive in code again. [I have to set > my emails and meetings in a block without working in much code.] My > social skills are also myopic.. I can work with people when I am in > word mode but I can not if I am in code mode beyond 'share code, get > reviewed, fix bugs, point out problems'. > Ditto, though I don't have to deal with an ASD, I stll find if I am at the top of my technical game and really performing, then my communication skills adjust to the berevity the thought mode enforces. > It takes a lot of work to document what I do, and when I am under > water with too many tasks/packages it can be a lot easier to just > make > it work versus doing that. I would like to say 'this is just me' but > when I have explained my problem to a lot of other developers there > are the nods of 'yep that is what it's like'. Getting a truly working > SIG together is a lot of emotional work that a lot of people don't > have the energy to deal with while also doing whatever they are > currently doing. > Honestly, this is another area maybe the community is lacking in right now, we don't seem to have as many "champions" taking the lead on running things like a java-sig. It really does require some organization skills and a marketing mindset. > Getting documentation is a full time job usually with someone who has > to have patience and persistence to get the information they need out > of the developers in code mode and also get the words down into a way > that someone who isn't a developer in code mode can read. > As it has been revealed repeatedly, documentation is an ongoing and ever demanding requirement that, since Fedora Linux release cadence is what it is, and the changes that come every release cycle, ensure a constant need and constant changes happening in those documents. Stephen > > > -- > Stephen J Smoogen. > I've seen things you people wouldn't believe. Flame wars in > sci.astro.orion. I have seen SPAM filters overload because of > Godwin's > Law. All those moments will be lost in time... like posts on a BBS... > time to shutdown -h 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
Hello,
(snip)
> However, we lack concepts on how to proceed after removing java-
> maint-sig. What consequences do we draw from the analyses?
>
> Emmanuel Seyman has made some suggestions, about 16 posts back.
> Thoughts on those? I posted on the java list some ideas some time ago
> ('Empowering Fedora Java’). Any comments on those?
>
I think the java-maint-sig should be shut down if it isn't actively
doing anything, and since the sentiment seems to be that there isn't a
real need for it. The only problem is I would be reluctant to offend
anyone who is a part of it by just arbitraily taking it down,
especially if they have been just quietly doing their part, and jsut
reluctant to talk about it for whatever reason.
>
There are members of the comunity who have spoken up here that are
actively contributing to java in Fedora Linux community.
So are the meetings being held with the java-sig? When are they? All of
us interested java community members should attend I think if we want
to offer an opinion or even just have something to say.
In my simple life and use of java, I find having a stable JDK and the
recent(ish) maven sufficient. Everything else is difficult to pin down
and I find alot of it is project dependant and changes based on that,
not based on the Distro I'm using. If I look at a commercially
available OS that is quite popular, they only package the JRE leaving
averything else up to the user WRT what they need for a dev stack.
Just my 2c worth
Stephen
>
> Peter
>
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hello Vit, I was one of those potential packagers who started a conversation here regarding the apparent dificulies experienced by some to varying degrees. In my simple non-packager perspective, There needs to be some tool used to help sponsors feel comfortable with the potential packagers capability and also for the packager to help them guage their own competence. (snip) > we were initially discussing that it could be useful to have some > package one can experiment with without being too much worried about > the > result. > > However, discussing this back and forth, we figured that it might > also > where new coming package maintainer could gradually gain experience > with > the packaging workflows. So the simplest tasks could be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this > current Fedora contributors might be interested to send such PR ;) > I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. > packager to be already sponsored and they could go through the whole > process themeselves just with some light guidance if needed. > > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines > could be refreshed suggesting/requesting to take these steps at some > point. > > Thoughts? > Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Looking forward to this progress, Stephen > > Vít > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: f35-backgrounds ready for review
Good answers On Thu, 2021-08-26 at 10:51 -0400, Stephen John Smoogen wrote: > On Thu, 26 Aug 2021 at 10:03, Stephen Snow wrote: > > > > From my user POV, > > I never understood why backgrounds were versioned specific to the > > release number of Fedora Linux in the first place. I mean, is it > > actually a separate repo each time? Wouldn't it make sense to just > > call > > it backgrounds? > > > > 1. we have 20+ years of history of theming desktops to a set of > packages. Size of downloads were usually kept small for a very long > time because downloading megabytes of images for backgrounds over > even > an 1.4 MB DSL was slow. > 2. In the Red Hat Linux days, you might be using fvwm2 in one > release, > enlightenment in another and sawmill in a third. Each one would need > to tweak things for that window manager. > 3. While we had moved away from this by early Fedora GNOME2, we had > still release names which themed the desktop. Combine that with 1 and > you have a want for smaller downloads of just a specific release > which > you could cherry pick by hand if you wanted an old one. [The blue Sun > one is my favorite still...] > 4. When we dropped release names and could allow larger download > sizes, you end up dealing with community dynamics which were buried > before as 1,2,3 trumped them. Some people really really hate some > backgrounds.. they don't want them on their system at all. Other > people love certain ones. Others want to keep old ones but then start > asking for updates so that they look nice on their hidef monitors > [Hello could someone update Blue Sun... ] > 5. Finally you have artist dynamics which match up with people > dynamics where they want to focus on a set of deliverables and not be > asked to update old images constantly (and you do have to tweak > them.. > monitor colour depth, size, and other things over time have made > older > images look bad unless you tweak the images.) > > > > Just asking > > > > Stephen > > > > On Thu, 2021-08-26 at 09:23 -0400, Matthew Miller wrote: > > > On Thu, Aug 26, 2021 at 08:40:49AM -0400, Link Dupont wrote: > > > > * fedora-backgrounds/f34 => fedora-backgrounds-34-1.fc34 > > > > * fedora-backgrounds/f35 => fedora-backgrounds-35-1.fc35 > > > > * fedora-backgrounds/f35 => fedora-backgrounds-35-2.fc35 > > > > But I must be missing something; this seems like its way too > > > > simple > > > > a solution. > > > > > > Well, the current solution -- or having subpackages -- lets you > > > install old > > > wallpaper on new systems. Since a lot of the old wallpaper is > > > _awesome_, > > > that's desirable. > > > > > > -- > > > Matthew Miller > > > > > > Fedora Project Leader > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to > > > devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://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 > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > > -- > Stephen J Smoogen. > I've seen things you people wouldn't believe. Flame wars in > sci.astro.orion. I have seen SPAM filters overload because of > Godwin's > Law. All those moments will be lost in time... like posts on a BBS... > time to shutdown -h 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/
Re: f35-backgrounds ready for review
From my user POV, I never understood why backgrounds were versioned specific to the release number of Fedora Linux in the first place. I mean, is it actually a separate repo each time? Wouldn't it make sense to just call it backgrounds? Just asking Stephen On Thu, 2021-08-26 at 09:23 -0400, Matthew Miller wrote: > On Thu, Aug 26, 2021 at 08:40:49AM -0400, Link Dupont wrote: > > * fedora-backgrounds/f34 => fedora-backgrounds-34-1.fc34 > > * fedora-backgrounds/f35 => fedora-backgrounds-35-1.fc35 > > * fedora-backgrounds/f35 => fedora-backgrounds-35-2.fc35 > > But I must be missing something; this seems like its way too simple > > a solution. > > Well, the current solution -- or having subpackages -- lets you > install old > wallpaper on new systems. Since a lot of the old wallpaper is > _awesome_, > that's desirable. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Hello Pavel, Thank you for your thoughts. It strikes me that perhaps what you're advising me to do, is likely what I was wanting to do in the first place. I certainly don't feel dissatisfied being a non-packager in Fedora land, and I am probably a bit guilty of exageration of the difficulties on the road to becoming a packager. Honestly, I am looking forward to setting up to do some testing for now. Thanks to everyone for taking the time to offer me the options available to become a packager, this is indeed a good part of why I enjoy being part of the community that is Fedora. Regards, Stephen On Mon, 2021-08-16 at 19:59 +0200, Pavel Valena wrote: > > > On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow > wrote: > > Hello Dan, > > Thank you for reaching out with your response. I have to admit, I > > was > > in a provocotive mood the other day. I had solved a problem for a > > customer that had been worked on unsuccessfully by a local > > competitor > > for three weeks. I was at that moment the master of my trade craft > > and > > in fully glory. I bought some beer to celebrate and the resulting > > email > > came out. So that is not to say I wasn't at least venting some > > portion > > of truth. Please bear with me as I have spent 6 decades walking > > upright, and sometimes I find laying the foundation of a > > conversation > > requires preparation. > > I have built RPM's and SRPM's according to RedHat specifications, I > > think using their tutorials. I have also built an unoffical flatpak > > of > > the IntelliJ IDE IDEA. So as for technical capability, I can read a > > manual as well as the next person. > > My thoughts were that the sponsoring, the proven packagers were > > supposed to be package mentors I thought originally, shouldn't > > happen > > until after sign up, and sign up is preconditioned by a basic CBT > > course with "build an RPM" test as final progression criteria for > > getting to ask for a sponsor. Not something inhibiting but just > > build a > > simple RPM to cover tha basic process. My reasoning is the process > > for > > getting onboarded should, like accepting a resume or CV from anyone > > at > > anytime, be an open door. In order to capatilize on numbers > > certainly > > but also to encourage the real potential individuals who can > > contribute > > technically, but are severely hampered by initial barriers. Even if > > the > > barriers are only perceived ones. The initial CBT I mentioned would > > be > > a way for someone like that to get a "free test". A sort of > > confidence > > boost that takes nothing but their time, and allows them to show > > they > > can do that part. Also, if they have difficulties doing a simple > > RPM, > > they could take some time to get that going and come back to try > > again. > > All of this can happen without the need for a sponsor getting > > involved > > until a minimum level of capability is ascertained, which should > > offload some time (for sponsors), though likely minimal I would > > guess. > > We could make it a badge. > > > > > Hello Stephen, > > I think this situation is very unfortunate and unintended. I think > you can do (or you can start doing it) what you came to do in Fedora, > without the "packager status". In general when you already have some > project / package in Fedora that you want to maintain, you can start > to work on it straight away, as a part of gaining your packager > status. That is, while receiving feedback /advice/ from sponsor. It's > a way to gain the actual skill to become a packager - I don't think > any robot/test can replace that. I don't think packaging is about > just doing builds, in a way "it works", but rather creating a good > spec file / good package that will last for years. > > Doing unofficial reviews for a package you want to get into Fedora, > or submitting a new package review request (if you want to get it to > Fedora), or re-review request (if you want to unorphan the package). > Creating PRs with an enhancement / or package upgrade. Last one you > can even do anonymously: > > > https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously > > All of the above are IMO examples of what packager does. There's no > reason to do something else - you can just start straight away with > what you intend to do, and get a "packager" status later. Or is there > an obstacle that you packager status for, to do anything meaningful > for you? > > I really hope there's a path to achieve what
Re: The Death of Java (packages)
Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge. On Thu, 2021-08-12 at 19:58 +, Dan Čermák wrote: > I'd also like to plug Jakub's new sponsor page: > https://docs.pagure.org/fedora-sponsors/all > > There you can find all currently active sponsors by language, > interest, etc. > I like the work Jakub did on the sponsor page. This is a good way to present them. > > Cheers, > > Dan As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux. As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems. Regards, Stephen > > On August 12, 2021 7:29:10 AM UTC, Felix Schwarz > wrote: > > Hi Stephen, > > > > thank you for your interest in contributing to Fedora. I can > > totally understand > > that the current policies may seem overwhelming so that becoming a > > packager > > might be seen as some kind of "elite" status. > > I think I would feel the same way if I didn't become a packager ~10 > > years ago. > > > > However I would like to emphasize Ben's point: > > > I think becoming a packager is not as complicated as you’ve > > > written. To > > > become a packager, you must convince a packager sponsor to > > > sponsor you. > > > That’s all; there is no rule about how to do the convincing. > > > > Maybe you do 1-2 package updates or fixes (pull request via > > src.fedoraproject.org) and check the Fedora wiki pages for a list > > of sponsors. > > Try contacting some of them directly after you verified they are > > still active > > (mailing list/src.fedoraproject.org). Also it helps usually if > > these sponsors > > are interested in the languages/tech stack which you tried to > > improve. > > > > That being said: Java in Fedora is one of the hardest areas to > > tackle. Several > > "high profile" packagers had to give up on that task (despite > > heroic efforts) > > because it is just too much for one person (or a small team). > > > > Part of the problem is that the Java upstream "culture" does not > > matches the > > processes of a traditional Linux distribution like Fedora. Lots of > > bundled > > dependencies, "secret" build processes and on top a huge number of > > small packages. > > > > I can understand that "keeping Eclipse
Re: The Death of Java (packages)
On Wed, 2021-08-11 at 18:44 +0200, Emmanuel Seyman wrote: > * Stephen Snow [11/08/2021 12:08] : > > > > > > Even tried the review route, which is also beset with arbitrary > > > > obstacles. > > > > > Wasn't able to download the build via the link provided. > > ??? > Building a package with mock will create the build in > /var/lib/mock/... > No download should be required. > Yup, my mistake, I was able to build. I'll try the process again by looking through the review's wanted list. Thanks for responding Stephen > Emmanuel > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Wed, 2021-08-11 at 14:20 +0200, Emmanuel Seyman wrote: > * Stephen Snow [11/08/2021 11:37] : > > > > I feel the frustration you are expressing, and would like to help, > > nut > > apparently I don't meet the Fedora Packaging standards. > > I'm curious as to what happened... Not sure what happened really, I had asked via this email list a few times over the past to become a package maintainer of a couple of orphaned java related packages, and got no response. I couldn't use the take button as it noted I didn't have the rights to do it (still that way on Pagure for me). > > > Even tried the review route, which is also beset with arbitrary > > obstacles. > Wasn't able to download the build via the link provided. > Again, what happened? Can you point us to those reviews? > > > I will keep trying because that is in my nature, but making joining > > the > > packaging group(s) a bit more open would go a long way to garnering > > more > > packagers IMO. > > What changes to the process would you like to see made? > Please see my repsonse to Vitaly. I think the barrier to getting into this should be far lower as regarding the following ... -New contributor asks for sponsorship, someone able to gives it -new contributor is now a packager and can "take" any orphaned package -new contributor fails as packager after one release cycle, times out for one more release cycle before allowed to try to contribute again. -or new contributor does well, with handholding, and continues the learning process - or they do great, and need no handholding, and take on more work load readily I really would like to point to how easy it is to become an editor of Fedora Magazine as an example of the ease with which contributors should be onboarded. As one more note from me on this, the packaging guidelines are an evolved document from years of best practices and failures. Maybe it is time to rethink the guidelines and particularly the entrance criteria to reflect today's Fedora Linux. Regards, Stephen > Emmanuel > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Okay, So to become a packager you have to - Get someone to sponsor you as a packager - Review existing packages for others - take over an orphaned package - introduce a package to Fedora Linux that needs to get approval to be packaged - some other criteria I forgot after reading so many linked documents I tried to "take" an orphaned package ... can't not a packager, so I tried to do a review, and even though I appear to be part of the group, I couldn't even access the review build because apparently I don't have the rights. My point is yes, it is requiring effort and it should but not to the extent of stonewalling contributions, and largely because the guidelines are confusing, it is a bit like reading a hand drawn map while driving IMO. So, back to orphaned packages, if a person from the community is signed up, signed the CA, the CoC, is a member of the appropriate groups, that person should be able to volunteer to take on orphaned packages, at least on a trila basis till they need no handholding. The deesire to contribute should be the bar to contribute is my point. If technical requirements are not being met, then they would be removed as packager and basically timed out for a specific time till they get the opportunity to try packaging again. However, if they succeed, then great for all, more contributors, less workload across the board. I understand that RPM packaging is a complex process, and creating Fedora Linux is a large task, but for new contributors how are they to learn the process, if the gate keepers are too efficient? Regards, and still hoping to be a packager someday Stephen On Wed, 2021-08-11 at 14:16 +0200, Vitaly Zaitsev via devel wrote: > On 11/08/2021 13:37, Stephen Snow wrote: > > making joining the packaging group(s) a bit more open would go a > > long way to garnering more packagers IMO > > New contributors must know at least the Fedora packaging guidelines. > This is the minimum barrier. > > use COPR. Simple and easy. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Hello Fabio, I was one of those community members to step up, or at least attempt to. What I found was an obstacle course instead of welcome to the packagers. I feel the frustration you are expressing, and would like to help, nut apparently I don't meet the Fedora Packaging standards. Even tried the review route, which is also beset with arbitrary obstacles. I will keep trying because that is in my nature, but making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [fedora-java] Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze
I would be willing to maintain at least a couple of those packages if someone is willing to be my sponsor, once the orphaning takes place of course. I do have more than a passing interest in Eclipse and java in Fedora and would like to help with the state of java in Fedora Linux. Regards, Stephen Snow FASID:jakfrost On Tue, 2021-08-10 at 18:00 +0200, Miro Hrončok wrote: > On 10. 08. 21 16:14, Aleksandar Kurtakov wrote: > > FWIW, it wasn't me who unorphaned packages - Mat (who was the > > maintainer) left > > my team and passed off his eclipse packages to me so probably this > > interfered > > with some automated procedure. > > Let's orphan them then? > > -- > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: x86_64-v2 in Fedora
Okay, So here comes another naive suggestion. The metrics that are desired are really innocuous content which should not risk anonymity, correct? Such things like BIOS/UEFI/?, CPU, Memory, installed edition or spin, when it was installed, optional packages, storage setup, etc... I presume. Why not create install time json file with desired info, which is available info at the time, show the user the content and ask for permission to transmit the file encrypted to . Or even make it a non-fungable file maybe, which gets generated at update time too with additional info like package diff etc... Instead of a tool say that is continuously on. Stephen Snow On Thu, 2021-06-17 at 13:10 -0700, Kevin Fenzi wrote: > On Thu, Jun 17, 2021 at 10:36:47AM -0500, Ron Olson wrote: > > Apologies in advance if this is laughable naïveté, but would a > > possible solution be to have a different repo for packages compiled > > against the latest-n-greatest architectures, and packagers could > > choose to include their packages in there, similar to EPEL? > > Packages in this hypothetical repo could be marked to replace > > existing ones via %obsoletes or some other mechanism; this would > > give the user the control to decide if he or she wants to switch to > > a “higher-performant” version and not have to rely on HW checks or > > telemetry. > > > > Just a thought. > > Sure, thats possible, however it would use a lot of resources. ;( > > * builder cpu cycles and disk > * mirror disk space > * buildsystem disk space > * mirroring BW > etc. > > and... the most important resource: everyone's time. If you have > multiple versions of your package you have to ask everyone in bug > reports which one they are using, you might not be able to duplicate > due > to lack of hardware, you have 2x as many things to worry about, etc. > > So, while thats very possible, I fear we don't have the resources to > do > it. (Nor do I think the benifits are worth it currently). > > kevin > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, 2021-03-10 at 10:21 -0500, Ben Cotton wrote: > ...[snip] > From the Community Blog post[1]: > > > Why not use “Fedora GNU+Linux” or some similar name? We want to be > > easy to say. The more words we add, the harder that is. And while > > GNU is an important part of Fedora Linux, there are many other > > packages that make Fedora Linux what it is. “Linux” is, for better > > or worse, the commonly-understood phrasing, so let’s just use that. > > [1] > https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-is-our-os/ I would have to agree with Matthew and Ben regarding the name. Fedora began as a collection of like minded individuals who took the effort to establish the four foudation prinicpals before assembling a working distribution which itself is focused around FLOSS and is very specific and firm about licensing requirements WRT what is allowed to ship as part of the official distro. This Fedora community took on a greater role than merely a linux distirbution, often times having a direct impact on the greater linux community in the process. For my part, it is in my own thoughts that I inherently differentiate between the distro and some other aspect of the Fedora Project, when using the same name for different aspects of Fedora Project/Community/Magazine/Discussion/etc... So calling the distro, in it's many official releases, Fedora-Linux at the code base level, so the ID that packages/apps should be using to verify OS, is just a programatic change that will have little to no affect in user level usage, and minimal affect for dev's. Naming things is what people do, and by clearly naming things we can easier differentiate between the various aspects of what constitutes the Fedora Ecosystem. Just my two cents worth. Stephen ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reminder: Upcoming summer time changes
On Wed, 2021-03-10 at 09:52 -0500, Ben Cotton wrote: > [snip] > A global list of time changes is available by country[2] and by > date[3], but here are a few highlights: > > 14 March — summer time begins in Canada, parts of Mexico, and the US Actually in Canada we have four seasons, so Springtime begins at or around Mar 20-22 depending upon the spring equinox. However, speaking specifically about the (dreaded) daylight savings time, yes we will move our clocks ahead on Mar 14 of this year, to "save" some of that precious daylight. Stephen > > > > [1] https://apps.fedoraproject.org/calendar/ > [2] https://www.timeanddate.com/time/dst/2021.html > [3] https://www.timeanddate.com/time/dst/2021a.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self introduction: Stephen Snow
Thank you, Now I have to review the orphaned pkg's. On Tue, 2021-02-09 at 18:25 +0100, Frédéric Pierret wrote: > > > Le 2/9/21 à 4:35 PM, Stephen Snow a écrit : > > Hello, > > > > I would like to start helping with maintaining a/some package(s). I > > have read the pre-requisite documents, did the RPM creation > > tutorial, > > and signed up to all the mailing lists. > > I am currently self employed providing industrial control services > > to > > some businesses in my area, which is the South Bruce Peninsula in > > Ontario Canada. I live in between Lake Huron to the west and > > Georgian > > Bay to the east. It is currently very cold here -10C, but not like > > out > > West (-49C in Saskatchewan). > > I am somewhat active in the Fedora community, most recently I am an > > editor and writer for Fedora Magazine. I am also a moderator on > > discussion.fp.o, where I try to help out when I can and generally > > enjoy > > the community interraction that is to be had there. I have also > > helped > > Silverblue project a bit with documentation in the past, and am an > > avid > > promoter of it as a very stable workstation alternative. > > In my day job, which I have been doing in one form or another since > > 1986, I have had to program or debug programs on a diverse range of > > control systems. As a result, I have been exposed to, and in many > > cases > > had to learn a number of different languages. The most relevant of > > which would be C/C++ and Java. In industrial settings it is > > commonly > > the standard C lib used, but periphery equipment such as thermal > > printers often would accept java code as well as basic if you were > > so > > inclined. In any case, there were also various Unix, Qnx, and > > eventually some Linux based control systems in use on the plant > > floors > > I visited. > > I would like to put my programming skills to use in the project > > where I > > can, perhaps staring with an orphaned package(s) since I have built > > RPM's and flatpaks too for that matter even before doing the > > tutorial. > > Thank you for taking the time to read this, and I look forward to > > helping out. > > > > Regards, > > Stephen Snow > > Hi Stephen, > > Welcome and enjoy to be around here on devel and packaging stuff :) > > Best, > Frédéric > ___ 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: Stephen Snow
Hello, I would like to start helping with maintaining a/some package(s). I have read the pre-requisite documents, did the RPM creation tutorial, and signed up to all the mailing lists. I am currently self employed providing industrial control services to some businesses in my area, which is the South Bruce Peninsula in Ontario Canada. I live in between Lake Huron to the west and Georgian Bay to the east. It is currently very cold here -10C, but not like out West (-49C in Saskatchewan). I am somewhat active in the Fedora community, most recently I am an editor and writer for Fedora Magazine. I am also a moderator on discussion.fp.o, where I try to help out when I can and generally enjoy the community interraction that is to be had there. I have also helped Silverblue project a bit with documentation in the past, and am an avid promoter of it as a very stable workstation alternative. In my day job, which I have been doing in one form or another since 1986, I have had to program or debug programs on a diverse range of control systems. As a result, I have been exposed to, and in many cases had to learn a number of different languages. The most relevant of which would be C/C++ and Java. In industrial settings it is commonly the standard C lib used, but periphery equipment such as thermal printers often would accept java code as well as basic if you were so inclined. In any case, there were also various Unix, Qnx, and eventually some Linux based control systems in use on the plant floors I visited. I would like to put my programming skills to use in the project where I can, perhaps staring with an orphaned package(s) since I have built RPM's and flatpaks too for that matter even before doing the tutorial. Thank you for taking the time to read this, and I look forward to helping out. Regards, Stephen Snow ___ 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
