Re: Fedora 29 Mass Rebuild
On 16.7.2018 20:05, Sérgio Basto wrote:
On Fri, 2018-07-13 at 10:42 +0200, Miro Hrončok wrote:
On 13.7.2018 10:38, Vascom wrote:
Hi.
As I see rebuild failed for all packages use %{__python} macro
because
it point to /usr/bin/python that removed from python2 package.
Need MassFix all these packages. Many of them not updated very long
time.
Please, only fix yours or those you care about.
Let the old cruft be FTBFS for a while to see if the maintainers care
or
not. We need to see how many legacy python stuff is in the distro
because it is needed and how many is there just because it
accidentally
works for 10 years without any changes.
Hello
After read this thread I think is about this scriptlet [1]
Please how I fixed this one [2] ?
Thanks
[1]
# Fix the shebangs so the package actually requires python2
sed -i -e 's@#! /usr/bin/env python@#!%{__python2}@g' \
gdesklets gdesklets-shell test-control.py ctrlinfo \
gdesklets-logview gdesklets-daemon
[2]
releng's gdesklets-0.36.3-32.fc29 failed to build
http://koji.fedoraproject.org/koji/buildinfo?buildID=1108914
That is: ./configure: line 13869: python: command not found
You need to locate a place where ambiguous python is called in the build
system.
I see:
configure
12316: for am_cv_pathless_PYTHON in python python2 python3 python3.0
python2.5 python2.4 python2.3 python2.2 python2.1 python2.0 none; do
12505:PYTHON_PREFIX=`python -c "import sys; print sys.prefix"`
configure.ac.nopyorbit
60:PYTHON_PREFIX=`python -c "import sys; print sys.prefix"`
configure.ac
60:PYTHON_PREFIX=`python -c "import sys; print sys.prefix"`
configure.ac.m4
61:PYTHON_PREFIX=`python -c "import sys; print sys.prefix"`
configure.ac.179
62:PYTHON_PREFIX=`python -c "import sys; print sys.prefix"`
shell/plugins/PackageInstaller/__init__.py
139:os.system("python %s --nomsg" % (s))
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PHG7YPQEMG5LW5F3PVL4KPOHKR3D6BHS/
Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries
(reposting due to mailing list issues) Florian Weimer writes: > On 07/10/2018 10:41 PM, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote: >>> On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote: > On 07/03/2018 10:13 AM, Jan Kurik wrote: >> = Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = >> https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries > >> OpenLDAP will not ship non-threaded version of libldap. Instead, >> libldap will be built with the same threading support as libldap_r. > > Why is this a system-wide change? Is it actually about linking > applications and libraries against libldap_r instead of libdap? No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name. >>> >>> I don't see that. The idea of the symbolic link is explicitly >>> rejected, which I think implies also the use of a copy. >> >> The way I understand this: >> right now there's two libraries: libldap_r (threaded) and libldap >> (nonthreaded) >> proposed state: two libraries: libldap_r (threaded) and libldap (threaded) >> So anything which links to libldap will continue to do that, but despite the >> name, libldap will really similar to libldap_r. > > Matus, would you please clarify what the plan is here? Thanks. Florian is right, the idea is to make changes to the source code (probably a downstream patch will be needed) such that the threaded library will be built twice, once with libldap soname and once with libldap_r soname, and the non-threaded libldap won't be shipped at all. The non-threaded version basically provides a subset of capabilities of the threaded version, which are additionally thread safe (i.e. mutexes). There shouldn't be really any noticeable change. Does this make sense? -- Matus Honek Associate Software Engineer Red Hat Czech ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YIZSDWWNUHYRUQAWJBX42PSHXABYYUUQ/
Re: Mass rebuild, mass Golang packages failures
- Original Message - > From: "Robert-André Mauchin" > To: devel@lists.fedoraproject.org, jca...@redhat.com > Cc: jchal...@redhat.com > Sent: Tuesday, July 17, 2018 2:34:49 PM > Subject: Mass rebuild, mass Golang packages failures > > Hello, > > > Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the > Golang > package containing a binary fail because the debuginfo are not generated: > > RPM build errors: > error: Empty %files file /builddir/build/BUILD/rclone-1.42/ > debugsourcefiles.list > Empty %files file /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list > Child return code was: 1 > > whereas it was working correctly before. > > Has anyone any idea what is causing this and how it can be fixed? We have been just discussing this at fedora-devel IRC. It seems that it is most probably caused by compress debug information that Go1.11 is now generating and rpm/debuginfo not understanding them. Adding -compressdwarf=false to the ldflags should workaround this. I will add it in to the gobuild macros so all packages that use it will pick it up automatically. ETA tomorrow. Thanks to sgallagh, mjw and most notably eclipseo who narrowed that down to the debug info compression and came up with the workaround. JC > > > Best regards, > > Robert-André > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SD5VRKOZZJC276PAUIFYB5VE2ZK2B7Q5/
Re: Intent to orphan Python 2
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis wrote: > > > - Original Message - >> From: "R P Herrold" >> To: "Development discussions related to Fedora" >> >> Sent: Monday, July 16, 2018 8:57:11 PM >> Subject: Re: Intent to orphan Python 2 >> >> On Mon, 16 Jul 2018, Miro Hrončok wrote: >> >> > On 23.3.2018 12:23, Petr Viktorin wrote: >> > > tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need >> > > to start dropping python2 packages now. >> >> tl;dr: --- that statement by itself overlooks the obvious. >> Not ALL packages become unsupported that first day of that >> year >> >> > > Python 2.7 will reach end of upstream support on 1st of January, 2020, >> > > after almost 10 years (!) of volunteer maintenance. >> >> Not to be too direct about this, but isn't the RHEL 6 primary >> maintenance date (through 2020 11 30) a closer maintenance >> depot to look at and to compare against ? >> > > I don't see how that relates to Fedora. Could you elaborate on what you mean? EPEL. Many of us use EPEL, with components from Fedora backported to our working environments. It's been an invaluable resource. Me? I just got a good look at openstack,, as well, which solved a *lot* of problems for me trying to bring some modules for communicating with proprietary data appliances into a RHEL environment. It's part of why so many Python modules have bothered to maintain Python 2 and Python 3 versions. >> Packages NOT in RHEL have a closer date, perhaps, but RHEL >> (next, assumedly 8, but ...) has not dropped yet. A >> subscription customer _should_ be migrating toward 7 at this >> point, but as this is not a costless thing, such migrations >> tend to be ... with a deliberate pace >> > > Agreed but yet again, this doesn't like something that would impact Fedora. A lot of us use Fedora as a testing ground for our commercial work for the more RHEL and CentOS, and a source of bleeding edge tools. Good open source work is usually open to supporting multiple environments, so it's worth a thought. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B6JMDJXD44BF3I7J5WKOTYRXYBJKVNXP/
Mass rebuild, mass Golang packages failures
Hello, Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the Golang package containing a binary fail because the debuginfo are not generated: RPM build errors: error: Empty %files file /builddir/build/BUILD/rclone-1.42/ debugsourcefiles.list Empty %files file /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list Child return code was: 1 whereas it was working correctly before. Has anyone any idea what is causing this and how it can be fixed? Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PK5PEKWE65UC5XQ6LTLSMATVPIISQKQS/
Re: Release criteria proposal: installing / removing software
On ma, 16 heinä 2018, Adam Williamson wrote:
On Thu, 2018-06-14 at 17:31 -0700, Adam Williamson wrote:
On Thu, 2018-06-14 at 19:25 -0400, Matthew Miller wrote:
> On Thu, Jun 14, 2018 at 03:47:25PM -0700, Adam Williamson wrote:
> > There's a footnote explaining that already:
>
> Ah, that clears it up. Thanks :)
>
> > as explained there, we actually *specifically* added this wording
> > because there was a bug with packages from modules being selected as
> > updates when the modules they were from weren't installed, and we felt
> > it was best to have the criterion explicitly cover this kind of
> > situation.
>
> Hmmm; this *could* apply to install, too -- for example, installing a
> package from a module that's not supposed to be enabled, or failing to
> from one that is.
Hum, that's a decent point. /me continues to cogitate
So, having cogitated, how about this wording?
Basic:
"The installed system must be able appropriately to install, remove,
and update software with the default console tool for the relevant
software type (e.g. default console package manager). This includes
downloading of packages to be installed/updated."
Beta:
"The installed system must be able appropriately to install, remove,
and update software with the default tool for the relevant software
type in all release-blocking desktops (e.g. default graphical package
manager). This includes downloading of packages to be
installed/updated."
Grammatically, this means the "appropriately" applies to all three
actions ("install, remove and update").
The footnote would read:
"Appropriately?
''Appropriately'' means that the relevant software mechanism(s) for any
given deployment must choose the software to be installed, updated or
removed in ways that are broadly in line with the user's intent and
typical expectations, and the project's intent as to which software
should be provided from which repositories etc.
To give a specific example of why this wording is included, there was
previously a case where newer package versions from modules were being
installed as 'updates' to systems which did not have those modules
installed, only the package with the same name from the non-modular
system repositories. This would be an example of 'inappropriate'
updating that violated this criterion. Other examples might include
installing packages from the wrong module stream, or failing to include
available updates from an enabled official repository."
Does that sound good to everyone? Thanks!
This looks good to me. "Appropriately" is a bit of odd word to choose
but what else? ;)
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XXNUVNX6MXDF4I3WGYB76AS3GBKY2E6G/
Re: Mass rebuild, mass Golang packages failures
On mardi 17 juillet 2018 14:34:49 CEST you wrote: > Hello, > > > Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the > Golang package containing a binary fail because the debuginfo are not > generated: > > RPM build errors: > error: Empty %files file /builddir/build/BUILD/rclone-1.42/ > debugsourcefiles.list > Empty %files file > /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list Child return code > was: 1 > > whereas it was working correctly before. > > Has anyone any idea what is causing this and how it can be fixed? > > > Best regards, > > Robert-André The problem seems to be caused by the compressing of debug info: https://github.com/golang/go/issues/11799 Disabling the compression with -ldflags=-compressdwarf=false seems to solve the issue. I don't know if this should be made default in %gobuild or if we ned to find a way to extract compressed debuginfo. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EEF5P4JS5HE25ISRQWAVIYAVRAB4PTLJ/
Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries
On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote: > Florian is right, the idea is to make changes to the source code > (probably a downstream patch will be needed) such that the threaded > library will be built twice, once with libldap soname and once with > libldap_r soname, and the non-threaded libldap won't be shipped at > all. > > The non-threaded version basically provides a subset of capabilities of > the threaded version, which are additionally thread safe > (i.e. mutexes). There shouldn't be really any noticeable change. > > Does this make sense? So can it happen that both the libraries will be loaded at the same time by a single process (one of them for example through libcurl)? Will everything work as expected in this case? Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZSJ5XRXEZAX5WTIJCQWPO3GU6SO3IZSV/
Reminder: Fedora 29 self-contained change deadline
Hello everyone, This is your reminder that the deadline for self-contained changes is 24 July 2018. The full Fedora 29 schedule is available at https://fedoraproject.org/wiki/Releases/29/Schedule Changes not marked with the "ChangeReadyForWrangler" category by the deadline will be moved to Fedora 30. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3FNHZBIXJMXLY3L7UI2BZLBCNUTESZ4/
Re: Release criteria proposal: installing / removing software
Try "expected" rather than "appropriately" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FBM3HOWXN7RF5LJ4M6J2HWESB3UT3L2H/
Re: Release criteria proposal: installing / removing software
On Tue, 2018-07-17 at 16:39 +, Jeff Johnson wrote: > Try "expected" rather than "appropriately" I think I prefer "appropriately". "Expected" only begs the question "what does that mean?" even more: expected by whom? (It also doesn't fit into the current grammatical structure of the draft, unless you write "Expectedly to install, update and remove...", which is hideous and no-one will understand it). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TLMPGEMMEELYWHRTD2BO7OZCILCN2CVL/
Re: Release criteria proposal: installing / removing software
On Tue, Jul 17, 2018 at 11:05 AM, Adam Williamson wrote: > On Tue, 2018-07-17 at 16:39 +, Jeff Johnson wrote: >> Try "expected" rather than "appropriately" > > I think I prefer "appropriately". "Expected" only begs the question > "what does that mean?" even more: expected by whom? (It also doesn't > fit into the current grammatical structure of the draft, unless you > write "Expectedly to install, update and remove...", which is hideous > and no-one will understand it). Expect is a word of probability. Appropriate is about ownership and that which is proper. One possible "expectation" is *shit should work for most people most of the time, users aren't all freaking out, while also not leaving a significant minority completely stranded* A more refined "expectation" is QA takes the lead on determining whether install/update/remove is working appropriately, taking into consideration all the limitations of Fedora infrastructure as well as reasonable user expectations. "Appropriate means that the relevant update mechanism(s) for any given deployment must apply the correct updates to the correct components, and not apply incorrect updates. To give a specific example of why this wording is included, there was previously a case where newer package versions from modules were being installed as 'updates' to systems which did not have those modules installed, only the package with the same name from the non-modular system repositories. This would be an example of 'inappropriate' updating that violated this criterion." "We expect that a given deployment will apply correct updates to components, and not apply incorrect updates." I think you can make expect or appropriate work equally well, the openendedness at first glance is really on "what do correct and incorrect" mean? But that's probably something that logic dictates the outcome of in straightforward fashion once you start doing the autopsy on the problem. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NW2CHSRPOCC7B4OGOCRPXBHG5RFEAAQB/
Re: Intent to orphan Python 2
On 17.7.2018 14:16, Nico Kadel-Garcia wrote: On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis wrote: - Original Message - From: "R P Herrold" To: "Development discussions related to Fedora" Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2 On Mon, 16 Jul 2018, Miro Hrončok wrote: On 23.3.2018 12:23, Petr Viktorin wrote: tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now. tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance. Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ? I don't see how that relates to Fedora. Could you elaborate on what you mean? EPEL. Many of us use EPEL, with components from Fedora backported to our working environments. It's been an invaluable resource. Me? I just got a good look at openstack,, as well, which solved a *lot* of problems for me trying to bring some modules for communicating with proprietary data appliances into a RHEL environment. It's part of why so many Python modules have bothered to maintain Python 2 and Python 3 versions. I hear you. I just don't understand what our action shall be according to you. Having python2 in Fedora might indeed be beneficial to old EPELs (and RHELs). But it shall not be an excuse to have thousands of modules packaged and supported because some of them might (or might not be) also present in EPEL. You can even use python3 in EPEL and call it a day. Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace Agreed but yet again, this doesn't like something that would impact Fedora. A lot of us use Fedora as a testing ground for our commercial work for the more RHEL and CentOS, and a source of bleeding edge tools. Good open source work is usually open to supporting multiple environments, so it's worth a thought. I (and now I'm speaking strictly for myself, other Fedora Python maintainers might have different opinion) won't spend my free time to maintain something I don't like just to support your commercial work. Will you? I don't have enough resources in my paid time to support Python 2 in Fedora **on the current scale**. That's what this topic was all about. Reduce the cruft, so we can keep it and support it in our paid time to support both commercial and non-commercial work. If not reduced, we cannot do that. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N772E3ATIRLKIFR6ZIA7CAU6PA6YVTFK/
Re: Release criteria proposal: installing / removing software
On Mon, 2018-07-16 at 17:32 -0700, Adam Williamson wrote: > > Basic: > > "The installed system must be able appropriately to install, remove, > and update software with the default console tool for the relevant > software type (e.g. default console package manager). This includes > downloading of packages to be installed/updated." > Just a small typo/grammar correction I think. "The installed system must be able to appropriately install, remove, and update.." just moved the 'to' infront of appropriately.. Apologies if that's a dumb thing to nit-pick. Otherwise looks good to me. -- Nathanael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LV3V7R5WKHJZYOGZ4BEIQIAJCXLL4SRW/
Re: Release criteria proposal: installing / removing software
On Tue, 2018-07-17 at 15:09 -0600, Nathanael D. Noblet wrote: > On Mon, 2018-07-16 at 17:32 -0700, Adam Williamson wrote: > > > > Basic: > > > > "The installed system must be able appropriately to install, remove, > > and update software with the default console tool for the relevant > > software type (e.g. default console package manager). This includes > > downloading of packages to be installed/updated." > > > > Just a small typo/grammar correction I think. > > "The installed system must be able to appropriately install, remove, > and update.." > > just moved the 'to' infront of appropriately.. Apologies if that's a > dumb thing to nit-pick. Otherwise looks good to me. This is the old English grammatical chestnut known as the "split infinitive" (or rather, in the case of my draft, the infinitive is intentionally *not* split). Both forms are used, and mean the same. The one I chose is sometimes considered the more 'classically' correct, and some stick-in-the-muds consider your form to be incorrect. Wikipedia has quite a good article on it: https://en.wikipedia.org/wiki/Split_infinitive I instinctively like the non-split form here because, to me, it emphasizes more clearly that "appropriately" applies to all three actions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QZ6L2K6BNSMDYNQBULMMFPB5W6PTN5P3/
Re: Release criteria proposal: installing / removing software
On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote: > I instinctively like the non-split form here because, to me, it > emphasizes more clearly that "appropriately" applies to all three > actions. To be clearer here, consider these options: "...to appropriately install, remove and update..." "...to install, remove and update appropriately..." "...appropriately to install, remove and update..." To me, it's at least possible that someone might read the first as if the "appropriately" applies only to the action "install", and the second as if the "appropriately" applies only to the action "update". The third, however, can't really be understood in any way *other* than with "appropriately" applying to all three actions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MB53OMLJECCQMXRC3KKQSXHFXCNENZBL/
Re: Intent to orphan Python 2
On 07/16/2018 11:15 AM, Miro Hrončok wrote: > This is just a reminder that nobody stepped up to maintain Python 2 > after 2020. We still need to start dropping python2 packages. > > What shall we do from here? File a Fedora System Wide Change Proposal > for Fedora 30 that nothing explicitly white-listed to require Python 2 > will be removed from Fedora? Can we even do that? How would you construct the whitelist? > For context - there are currently 708 leaf packages [1](above). > > Except several tools and applications, those are all modules that > nothing in Fedora depends on. If we remove some, others only required by > them will become leaf-packages as well. > > We also have 1220 py2 only packages out of which plenty are probably > unneeded modules as well, although we don't have the numbers. > > As stated in the above e-mail in March, we are willing to support > python2 for several (small number) of tools or apps. But we will not > support it for 3 thousands of unused, unknown modules. > > Python 2 will EOL in less than 1.5 year. Could we perhaps look at moving python2 and everything that wants to use it into a module? I think that might make it more clear that it's not part of base Fedora and when it goes eol in f32 we drop it? That would take a lot of effort and duplication tho. I don't think we want to drag this out too long... a clear call to drop all python2 in 31 (or I suppose f30) would be helpful and avoid some people dropping something other packages need, etc. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W46PNNICWCFUPPLBRBZNQF2MDJ2PKVMF/
Re: Intent to orphan Python 2
On 18.7.2018 00:03, Kevin Fenzi wrote: On 07/16/2018 11:15 AM, Miro Hrončok wrote: This is just a reminder that nobody stepped up to maintain Python 2 after 2020. We still need to start dropping python2 packages. What shall we do from here? File a Fedora System Wide Change Proposal for Fedora 30 that nothing explicitly white-listed to require Python 2 will be removed from Fedora? Can we even do that? How would you construct the whitelist? Maintainers of apps and tools would whitelist their packages and we would recursively track dependencies. But that was a bit sarcastic from me, because I don't believe this would ever work (hence the "Can we even do that?" part). For context - there are currently 708 leaf packages [1](above). Except several tools and applications, those are all modules that nothing in Fedora depends on. If we remove some, others only required by them will become leaf-packages as well. We also have 1220 py2 only packages out of which plenty are probably unneeded modules as well, although we don't have the numbers. As stated in the above e-mail in March, we are willing to support python2 for several (small number) of tools or apps. But we will not support it for 3 thousands of unused, unknown modules. Python 2 will EOL in less than 1.5 year. Could we perhaps look at moving python2 and everything that wants to use it into a module? I think that might make it more clear that it's not part of base Fedora and when it goes eol in f32 we drop it? That would take a lot of effort and duplication tho. That would be very painful and would request an extraordinary amount of manpower while gaining zero benefit (except that we would have the ability to drop it mid-realease). The drop can wait until that Fedora EOLs. I don't think we want to drag this out too long... a clear call to drop all python2 in 31 (or I suppose f30) would be helpful and avoid some people dropping something other packages need, etc. We can call for that but we know that it is not possible. There are Python 2 powered apps in Fedora that could seriously disturb the distro if dropped. To name a few: fedora-easy-karma fedora-packager fedora-review chromium nodejs datagrepper datanommer fedwatch gimp inkscape mercurial xen ... We want to keep them and we are able to maintain Python 2 for them (well, we would very much prefer to have them ported to Python 3 but we realize it's not always happening.) -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AZX2L65LO4W75GAXIAFE7IDOOGCWFMPX/
Re: Intent to orphan Python 2
On Tue, Jul 17, 2018 at 1:43 PM, Miro Hrončok wrote: > On 17.7.2018 14:16, Nico Kadel-Garcia wrote: >> >> On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis >> wrote: >>> >>> >>> >>> - Original Message - From: "R P Herrold" To: "Development discussions related to Fedora" Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2 On Mon, 16 Jul 2018, Miro Hrončok wrote: > On 23.3.2018 12:23, Petr Viktorin wrote: >> >> tl;dr: Unless someone steps up to maintain Python 2 after 2020, we >> need >> to start dropping python2 packages now. tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year >> Python 2.7 will reach end of upstream support on 1st of January, 2020, >> after almost 10 years (!) of volunteer maintenance. Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ? >>> >>> I don't see how that relates to Fedora. Could you elaborate on what you >>> mean? >> >> >> EPEL. Many of us use EPEL, with components from Fedora backported to >> our working environments. It's been an invaluable resource. Me? I just >> got a good look at openstack,, as well, which solved a *lot* of >> problems for me trying to bring some modules for communicating with >> proprietary data appliances into a RHEL environment. It's part of why >> so many Python modules have bothered to maintain Python 2 and Python 3 >> versions. > > > I hear you. I just don't understand what our action shall be according to > you. Having python2 in Fedora might indeed be beneficial to old EPELs (and > RHELs). But it shall not be an excuse to have thousands of modules packaged > and supported because some of them might (or might not be) also present in > EPEL. You can even use python3 in EPEL and call it a day. I was explaining why reasonable people involved in Fedora would care. I'm not saying never do it. It also happened with the perl 4 to perl 5 upgrade, for those of us who remember that, and when apache 1.x became httpd 2.x, and when Ruby updated to 2.x. Parallel support is possible and sometimes necessary. What's happening now with Python has been pretty good, and I applaud the maintainers who've been forwarding Python 2 modules and the occasionally messy but overall effective logic of building parallel python2 and python3 modules. Python 2 *does* need to be replaced as the default. And I think at some point the logic will need to be reversed, that "with_python2" becomes the flag needed for building those older package, instead of the current "with_python3". That is going to be a pain in the *fundament* to port. > I (and now I'm speaking strictly for myself, other Fedora Python maintainers > might have different opinion) won't spend my free time to maintain something > I don't like just to support your commercial work. Will you? I don't have > enough resources in my paid time to support Python 2 in Fedora **on the > current scale**. That's what this topic was all about. Reduce the cruft, so > we can keep it and support it in our paid time to support both commercial > and non-commercial work. If not reduced, we cannot do that. Your logic is sound. I publish patches to Fedora authors out of enlightened self interest for my paid work with RHEL and CentOS, and occasionally for the challenge of getting stuff into the bleeding edge systems. When RHEL 8 comes out, I hope it will be Python 3 based and I'll have the tools to mostly ignore Python 2, fostered by the good work happening in Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ABYLVXBWCMERLSXOUCORT5L5JR3ZWNEU/
Re: Release criteria proposal: installing / removing software
On Tue, Jul 17, 2018 at 3:53 PM, Adam Williamson wrote: > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote: >> I instinctively like the non-split form here because, to me, it >> emphasizes more clearly that "appropriately" applies to all three >> actions. > > To be clearer here, consider these options: > > "...to appropriately install, remove and update..." > "...to install, remove and update appropriately..." > "...appropriately to install, remove and update..." > > To me, it's at least possible that someone might read the first as if > the "appropriately" applies only to the action "install", and the > second as if the "appropriately" applies only to the action "update". > The third, however, can't really be understood in any way *other* than > with "appropriately" applying to all three actions. Use a colon. to appropriately: install, remove, and update... Unambiguous. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6Z2LVQRWUBW5Z6PPFAFOZKRIP6P5GMKO/
Intent to orphan js-jquery1 and js-jquery2
It is my intention to orphan js-jquery1 and js-jquery2. Does anybody want to take them over? These very old versions of jQuery have security issues that I do not have time nor expertise to maintain. Upstream's last patch for either of these occurred over 2 years ago. Everybody should be using jQuery 3 by now (js-jquery). Anything older is insecure and unsafe. Personally, I think they should be retired, but I don't know (or have time to check) to see if that would cause problems for anybody. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X72SSBJPOOVJZXSA76RHKHLXJQMOBCQ3/
Re: Release criteria proposal: installing / removing software
On Wednesday, July 18, 2018, Chris Murphy wrote: > On Tue, Jul 17, 2018 at 3:53 PM, Adam Williamson > wrote: > > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote: > >> I instinctively like the non-split form here because, to me, it > >> emphasizes more clearly that "appropriately" applies to all three > >> actions. > > > > To be clearer here, consider these options: > > > > "...to appropriately install, remove and update..." > > "...to install, remove and update appropriately..." > > "...appropriately to install, remove and update..." > > > > To me, it's at least possible that someone might read the first as if > > the "appropriately" applies only to the action "install", and the > > second as if the "appropriately" applies only to the action "update". > > The third, however, can't really be understood in any way *other* than > > with "appropriately" applying to all three actions. > > Use a colon. > > to appropriately: install, remove, and update... > > Unambiguous. > Just drop "appropriately" and replace it with a footnote. Then there is no need for all of this discussion and the text is easier to read (also installing the correct update falls into common sense hence for most people it will be clear even without reading the footnote). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z4XS4SEMLIR5FVNJ2F6MKGYF6BIN75L6/
