Re: Updates to mathematical software
Hi Jerry, You're doing a good job. Thanks. Are you plan update Octave to 4.4.0? -- Best regards, Vasiliy Glazov ср, 1 авг. 2018 г. в 12:25, Paul Howarth : > Hi Jerry, > > On Tue, 31 Jul 2018 19:09:02 -0600 > Jerry James wrote: > > > On Tue, May 29, 2018 at 4:36 AM Paul Howarth > > wrote: > > > On Mon, 28 May 2018 21:03:34 -0600 > > > Jerry James wrote: > > > > It looks like the giac, Macaulay2, and sagemath stacks are the > > > > only pari consumers. There is also a pending update to clisp > > > > that will bring its pari integration back; that has been missing > > > > for a few years. And sure enough, I've got my fingers in all of > > > > those pies. :-) I'm happy to take pari off of your hands if you > > > > want to hand it over. > > > > > > OK, done. Have fun! > > > > Are you also the maintainer of the pari-elldata, pari-galdata, > > pari-galpol, and pari-seadata packages? If so, I might as well take > > those, too. An update to pari-galpol is needed for the latest version > > of pari. > > I've now given these to you too. Enjoy :-) > > Paul. > ___ > 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/72G6WRZ3Z7B5TD4PHKTAC2Y2W4IVCIAX/ > ___ 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/JSY7ET6U4OCNNDHMTII5CGY4J4RIKA43/
Re: lazy loading of filelists.xml to speed up dnf
On 08/06/2018 04:42 PM, Jeff Johnson wrote: Whether dnf does what yum does misses the point: Lazy downloading of file dependencies did not work then and does not work now. Here's why: The fundamental decision made by depsolvers is what packages are "newer" and need to be upgraded. When _ANY_ commonly used package has a file dependency outside of the paths chosen to be delivered in primary.xml, then _ALL_ file dependencies need to be downloaded in order to find the package that contains the path so that the upgrade decision based on "newer" can be determined by the depsolver. [[snip]] What about using pre-processed bloom filters to restrict downloading to a smaller set of information that still covers the files and packages that are relevant to each specific depsolve? Hash each filename to a bit position < 128, OR together the words for all files in a package. 16 bytes/pkg * 60,000 packages in Fedora is ~1MB. Partition the filelist.xml info into a couple hundred groups of a couple hundred packages each. (Assignment of packages to groups can be improved using learning by experience.) Download the relevant groups, or perform an online query of a database of package ==> filelist. It might be possible to reduce network traffic by a factor 10: 5MB instead of 47MB. ___ 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/WAMMTGEBFA4HJONXWEJP35BBTH2OIX2F/
Fedora testing-20180807.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso install_default: Filesystem for mount /sysroot changed from /dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root to /dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root System load changed from 0.14 to 0.33 Previous test data: https://openqa.fedoraproject.org/tests/263465#downloads Current test data: https://openqa.fedoraproject.org/tests/263467#downloads Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso install_default@uefi: Filesystem for mount /sysroot changed from /dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root to /dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root Previous test data: https://openqa.fedoraproject.org/tests/263466#downloads Current test data: https://openqa.fedoraproject.org/tests/263468#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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/VAEIOTSRP46WUWWA26NZL3LFU7EGOOJB/
License change for rust-slab
rust-slab-0.4.1-1.fc29 has changed its license from "MIT or ASL 2.0" to just MIT. The upstream change is here: https://github.com/carllerche/slab/pull/49 ___ 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/FPGLAYNVHRHYTWTAE4G6ZXJOUVNRI34O/
Fedora updates-20180806.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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/7XG65JXBIFYFZJAV44UQT3PMGJVTGPHD/
Re: lazy loading of filelists.xml to speed up dnf
Whether dnf does what yum does misses the point: Lazy downloading of file dependencies did not work then and does not work now. Here's why: The fundamental decision made by depsolvers is what packages are "newer" and need to be upgraded. When _ANY_ commonly used package has a file dependency outside of the paths chosen to be delivered in primary.xml, then _ALL_ file dependencies need to be downloaded in order to find the package that contains the path so that the upgrade decision based on "newer" can be determined by the depsolver. Without explicit packaging policy -- and tools to verify -- forbidding all file dependencies outside of the magical paths preselected to be included in primary.xml, then filelist.xml will surely **AGAIN** be downloaded **ALL** the time. Since every depsolver has chosen to implement the magical paths in code rather than sharing a list of file patterns permitted somehow, then this cycle will be repeated again and again. The new usage case of /usr/libexec, and the older usage case of /bin vs /usr/bin indicates that history is repeating itself. TL;DR Magic file path patterns implemented in code and lazy loading of filelist.xml "just in case" will never succeed. Even if you Get It Right! for Fedora (and CentOS) packaging policy, there will be issues with custom 3rd party and end-user repositories that do not conform to the magical paths chosen. It is also very not surprising that there are very few file dependencies remaining in Fedora after several jihads (and policy) to eliminate file dependencies in Fedora packages. Another jihad (and tighter policy) cannot solve the problem of custom non-policy-conformance in custom repositories, no matter what. ___ 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/KAOMH4Z2NMRZKIMXYP7DYBY3B7BN3AVM/
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2018-08-07 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/DDXMG5MHEANEKQBGAKTI23ZMMZQEVKKO/
Re: %{valgrind_arches}
On Sun, Aug 5, 2018 at 5:52 PM, Jeff Johnson wrote:> Try > > ... > %check > %ifarch ppc64 ppc64p7 You no longer need ppc64p7 as it's been killed off as of F-26 > exit 0 > %endif > ... > > My comments apply to the rest of what you appear to be proposing everywhere. > ___ > 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/BF5MQ4HNFZPYAJC7MAC7EMB2LNAH7PG4/ ___ 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/Q37JULZPNOV5UMJDL5BFE4P3UULPMULK/
Re: Why are we shipping debug builds of pythons?
On Monday, 06 August 2018 at 18:29, Jan Kratochvil wrote:
> On Mon, 06 Aug 2018 17:30:02 +0200, David Malcolm wrote:
> > On Mon, 2018-08-06 at 13:15 +0200, Jan Kratochvil wrote:
> > > That confirms the whole OS "Checked Build" variant would solve even this
> > > problem.
> >
> > Jan: In my view, it's not a problem, it's a feature. An OS-wide
> > change wouldn't turn on "--with-pydebug" for Python, unless it was
> > directly coded into the specfile.
>
> Packages would be recommended to turn on such flags for that variant of OS,
> such as for example for glib2:
> --enable-debug --enable-gc-friendly --disable-mem-pools
> etc.
> At least this is what IIUC Microsoft does for their Checked Build.
>
>
> > The change to the ABI is due to two new fields with the base struct for
> > python objects.
>
> That is not a problem for a Checked Build OS as all the packages are compiled
> for the different ABI.
If there is a clear packaging guideline and a macro framework in-place
i.e.:
%bcond_with checked_build
[...]
%configure
[...]
%if %{with checked_build}
--enable-debug --enable-gc-friendly --disable-mem-pools
%endif
Or even just:
%global checked_build_configure_opts --enable-debug --enable-gc-friendly
--disable-mem-pools
[...]
%configure_checked (which would do something like the above)
then all packages that support this can be built twice, automatically.
There should probably be some special generated Provides and Requires,
too, I guess.
It would still require significant effort to support this in koji and
composes. I'm not sure how useful that would be in general, but you're
welcome to propose a system-wide change and work on this.
Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion 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://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/6FVCMFJZPPYQELBRH7Q5I4I3WA2BNC52/
Re: %{valgrind_arches}
W dniu 05.08.2018 o 16:36, Jeff Johnson pisze:
> So you are recommending using 14 lines (with comments) of spec file
> goop that uses 2 %ifarch build section tests in order to set/unset a
> macro.
>
> There's further baggage in spec files needed to add a BR, pass an
> option to configure, add libraries to link, etc
Spec files are often wrote in 'I do not know other archs than x86' way.
I remember going through valgrind support for aarch64 few years ago
where changes to upstream valgrind were simple but all those packages
where %{valgrind_archs} was done in "%ifarch x86_64 i686" way required
patching and then patching...
From what I remember there is no architecture supported by Fedora
without Valgrind support. We got rid of s390 (32bit) and risc-v does not
count yet.
___
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/NJJBWIIHZDXNHL67YK7QV7RY7YNLIMUV/
pgadmin3 & pgadmin4 - No/Non-Responding Maintainer
Fedora is now on postgresql 10.x. pgadmin3 stopped being supported with postgresql 9.5. pgadmin4 isn't packaged in the repositories. Hence, Fedora no longer has a gui for postgresql. Is the maintainer here that we could get help with this? If not, is there anyone willing to rise to the challenge? Status: Itamar Reis Peixoto helped update all the prerequisite packages (thanks), but there is still no pgadmin4 package in the repositories. https://bugzilla.redhat.com/show_bug.cgi?id=1352188 https://bugzilla.redhat.com/show_bug.cgi?id=1380826 Joseph D. Wagner ___ 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/5VMWKIXDFIHZLNWXTOTA54DB4XBR52IS/
Re: lazy loading of filelists.xml to speed up dnf
On Mon, Aug 06, 2018 at 07:52:03PM +0200, Robert-André Mauchin wrote: > On lundi 6 août 2018 18:36:07 CEST Zbigniew Jędrzejewski-Szmek wrote: > > Hi dnf and libsolv developers, > > > > this mail is a continuation of an FPC [1] and a FESCo [2] tickets. > > > > A proposal was made is to disallow packages in Fedora from using file > > deps, and to optimize dnf to not load filelists.xml. File deps would > > still be supported, because external packages and users want to use > > them, but they would not be allowed for distro packages. > > > Do we have an idea how any packages currently use filedeps? From one of the tickets: https://pagure.io/packaging-committee/issue/714#comment-464348 > In rawhide today, there are 490 different file reqs. Of these, 79 > are in /bin or /sbin, 323 are in /usr/bin or /usr/sbin, and 25 are > in /etc. The remaining 64 are: [...] Zbyszek ___ 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/5OHXFFALWODBHS4E3FHLYCIN6WQCNQDC/
Re: lazy loading of filelists.xml to speed up dnf
On lundi 6 août 2018 18:36:07 CEST Zbigniew Jędrzejewski-Szmek wrote: > Hi dnf and libsolv developers, > > this mail is a continuation of an FPC [1] and a FESCo [2] tickets. > > A proposal was made is to disallow packages in Fedora from using file > deps, and to optimize dnf to not load filelists.xml. File deps would > still be supported, because external packages and users want to use > them, but they would not be allowed for distro packages. > Do we have an idea how any packages currently use filedeps? ___ 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/7SXXVRASIQWLJQOUJWYX7T3RZV6XGTQV/
lazy loading of filelists.xml to speed up dnf
Hi dnf and libsolv developers, this mail is a continuation of an FPC [1] and a FESCo [2] tickets. A proposal was made is to disallow packages in Fedora from using file deps, and to optimize dnf to not load filelists.xml. File deps would still be supported, because external packages and users want to use them, but they would not be allowed for distro packages. Not downloading or loading filelists.xml which are required for file deps would provide significant bandwidth savings (~47 MB compressed) and noticeable runtime savings (~10s at dnf startup) in many common cases. So this is something that is worth exploring, but it's not clear if it is at all feasible. It seems that dnf would need to support loading filelists.xml lazily. In the mailing list discussions, some people said that this would be hard, some people said that it would be possible… What is the situation here? IIUC, dnf would need to restart the resolution of a transaction mid-flight once it encounters a file dep, which would require support across the different layers. If Fedora commits to making use of this, would it be possible to implement this in dnf? What kind of changes would be required? [1] https://pagure.io/packaging-committee/issue/714 [2] https://pagure.io/fesco/issue/1955 Zbyszek, on behalf of FESCo (but not that this writeup is based on my understanding, so all errors are mine.) ___ 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/BRX7BAAFUS4HCRDN4J243FFBSECEFNTV/
Re: Why are we shipping debug builds of pythons?
On Mon, 06 Aug 2018 17:30:02 +0200, David Malcolm wrote: > On Mon, 2018-08-06 at 13:15 +0200, Jan Kratochvil wrote: > > That confirms the whole OS "Checked Build" variant would solve even this > > problem. > > Jan: In my view, it's not a problem, it's a feature. An OS-wide > change wouldn't turn on "--with-pydebug" for Python, unless it was > directly coded into the specfile. Packages would be recommended to turn on such flags for that variant of OS, such as for example for glib2: --enable-debug --enable-gc-friendly --disable-mem-pools etc. At least this is what IIUC Microsoft does for their Checked Build. > The change to the ABI is due to two new fields with the base struct for > python objects. That is not a problem for a Checked Build OS as all the packages are compiled for the different ABI. Jan ___ 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/WOIBNF2ELBQYTQZDO4BAC2HMYJBDO4K2/
Re: Why are we shipping debug builds of pythons?
On 08/06/2018 11:22 AM, David Malcolm wrote: On Sat, 2018-08-04 at 22:25 +0200, Miro Hrončok wrote: Hi, an interesting discussion came up in the Python Maint team recently, about not shipping python3-debug and python2-debug. On the Chesterton's fence principle [0], I'd would like to know why are we building and shipping them before we have a discussion about their removal to save build time and remove packaging cruft. Anyone has an idea? Those packages are meant to debug Python, yet all people I know who do that, build they own Python for that purpose (often from the master branch). I tracked down the introduction of the python-debug package in this commit [1] by David Malcolm (CCed) @ 8 years ago, added in Fedora 14 shortly before upgrade to 2.7. Yet the commit message lacks rationale. [0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence [1] https://src.fedoraproject.org/rpms/python/c/f020abd35954981b383884105 dad425ba9c6637a Python's --with-pydebug adds lots of checking that's useful when developing *extension modules*, as well as debugging Python itself. This checking breaks ABI (due to adding nodes for a doubly-linked list of all objects into the base PyObject struct). The reason I added these packages to Fedora was to make Fedora a more attractive OS for people developing Python extension modules (given that Debian did, and we didn't, at the time). If you're trying to track down a reference leak in some module, having to build your own Python feels like an unnecessary hurdle (IMHO). FWIW as a Python extension author and maintainer I have taken advantage of these deubg builds, it's very useful. If you're developing at the level of CPython you probably also have the skill to build your own version but why? -- John Dennis ___ 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/RUHMQLAZTZGRG7Z5CLRO72ZGWPSQVIF5/
Re: Why are we shipping debug builds of pythons?
On Mon, 2018-08-06 at 13:15 +0200, Jan Kratochvil wrote: > On Mon, 06 Aug 2018 10:57:31 +0200, Petr Viktorin wrote: > > On 08/05/18 14:01, Jan Kratochvil wrote: > > > That is all together messy. This is why Microsoft has their debug > > > build of > > > their whole OS - Windows - called Checked Build: > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/devte > > > st/checked-and-free-build-differences > > > > The main issue with --with-pydebug is that it changes the ABI, i.e. > > all > > extensions need to be re-built specifically for it (and debug > > extensions > > outside the standard library aren't usually packaged in Fedora). > > That makes > > it much less useful than if it just used less optimizations. Petr: IMHO, it's much *more* useful: it checks for leaked objects, which is the most painful issue to deal with when debugging Python extensions. That was my motivation for adding it. > > That confirms the whole OS "Checked Build" variant would solve even > this > problem. Jan: In my view, it's not a problem, it's a feature. An OS-wide change wouldn't turn on "--with-pydebug" for Python, unless it was directly coded into the specfile. The change to the ABI is due to two new fields with the base struct for python objects. Dave ___ 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/HJGZIFX56BJAAUKOHTQSMHGOPI6WE7S3/
Re: Why are we shipping debug builds of pythons?
On Sat, 2018-08-04 at 22:25 +0200, Miro Hrončok wrote: > Hi, > > an interesting discussion came up in the Python Maint team recently, > about not shipping python3-debug and python2-debug. > > On the Chesterton's fence principle [0], I'd would like to know why > are > we building and shipping them before we have a discussion about > their > removal to save build time and remove packaging cruft. > > Anyone has an idea? Those packages are meant to debug Python, yet > all > people I know who do that, build they own Python for that purpose > (often > from the master branch). > > I tracked down the introduction of the python-debug package in this > commit [1] by David Malcolm (CCed) @ 8 years ago, added in Fedora 14 > shortly before upgrade to 2.7. Yet the commit message lacks > rationale. > > [0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence > [1] > https://src.fedoraproject.org/rpms/python/c/f020abd35954981b383884105 > dad425ba9c6637a Python's --with-pydebug adds lots of checking that's useful when developing *extension modules*, as well as debugging Python itself. This checking breaks ABI (due to adding nodes for a doubly-linked list of all objects into the base PyObject struct). The reason I added these packages to Fedora was to make Fedora a more attractive OS for people developing Python extension modules (given that Debian did, and we didn't, at the time). If you're trying to track down a reference leak in some module, having to build your own Python feels like an unnecessary hurdle (IMHO). FWIW, I use it myself in gcc-python-plugin, which is built 4 times (for Python 2 vs 3, optimized vs debug). Dave ___ 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/OLAMAEBXNUXXOHSNSV6562OADEK4EM27/
Re: [HEADS UP] mercurial rebase for F29
I have no bandwidth to work on this in the next several weeks, so if anyone else would like to take the lead that would be very helpful. On Mon, Aug 6, 2018 at 7:05 AM Petr Stodulka wrote: > Hi folks, > we want to do rebase of mercurial for F29 before beta freeze yet. Currently > we have version v4.4.2 which is already old. Few days ago there have been > release new stable version v4.7. But many applications would be broken > because > of changed API (as it is with every bump of minor version). From this > point, > I would like to do rebase to v4.5.3 (or v4.6) as I believe that apps with > living upstream (and which requires mercurial) are already compatible with > those versions of mercurial. After the F29 will be branched, we will do > rebase > to v4.7 in rawhide so there will be enough time to fix any issues because > of > changes in the new version. > > Here is the list of components that depends on mercurial: > - git-cinnabar > - gitifyhg > - git-remote-hg > - golang > - gwsmhg > - hg-git > - hgsubversion > - hgsvn > - hgview > - python-anyvc > - python-hgapi > - python-hghooks > - python-vcstools > - python-wstool > - pyvcs > - qct > - rabbitvcs > - rbm > - tortoisehg > - trac-mercurial-plugin > > Please give me a note in case you have troubles with this rebase now. I > would > like to do in few days. Add POCs into Cc. > > Cheers, > > -- > Petr Stodulka > Core Services (In-place upgrades and migrations) > IRC nicks: pstodulk, skytak > Red Hat > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4GEAF2CDUAW2BOHUIJRC47BMBNZNI4VS/
[HEADS UP] mercurial rebase for F29
Hi folks, we want to do rebase of mercurial for F29 before beta freeze yet. Currently we have version v4.4.2 which is already old. Few days ago there have been release new stable version v4.7. But many applications would be broken because of changed API (as it is with every bump of minor version). From this point, I would like to do rebase to v4.5.3 (or v4.6) as I believe that apps with living upstream (and which requires mercurial) are already compatible with those versions of mercurial. After the F29 will be branched, we will do rebase to v4.7 in rawhide so there will be enough time to fix any issues because of changes in the new version. Here is the list of components that depends on mercurial: - git-cinnabar - gitifyhg - git-remote-hg - golang - gwsmhg - hg-git - hgsubversion - hgsvn - hgview - python-anyvc - python-hgapi - python-hghooks - python-vcstools - python-wstool - pyvcs - qct - rabbitvcs - rbm - tortoisehg - trac-mercurial-plugin Please give me a note in case you have troubles with this rebase now. I would like to do in few days. Add POCs into Cc. Cheers, -- Petr Stodulka Core Services (In-place upgrades and migrations) IRC nicks: pstodulk, skytak Red Hat 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/ZFAZYEBHT3KM3JODS7XB37PINHHMZHNV/
Re: Golang SIG for Fedora
I think we already have tools for that. What I expect with the SIG is something that could improve the Go Packaging best practices listed in https://fedoraproject.org/wiki/PackagingDrafts/Go On Mon, Aug 6, 2018 at 9:10 AM, Vitor Ramos wrote: > I think that we can mature in the first moment the SIG, and in other moment, > channels, groups, and subjects in another moment. An approach about the taiga > is about the development of Tools that contemplate the Golang in Fedora > Project? > ___ > 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/SSY4GJ36T6LSVEWLOWHE5QP2BP4Q2HVZ/ ___ 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/TF6NM4E6DHHW6NO6TUGDF44IPHFW3VG4/
Re: Schedule for Monday's FESCo Meeting (2018-08-06)
On 6.8.2018 15:25, Jared K. Smith wrote: If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly I'd appreciate if you could please also discuss https://pagure.io/fesco/issue/1965 as it is time sensitive. I can attend the meeting as well. Thanks. -- 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/PZ3H43RKQ3EL35WFRFU6XM7LNUBVF6TV/
Looking for new maintainer for FreeCAD
I really like having a real 3D CAD program on Fedora but unfortunately with the 0.17 release there are multiple issues that need to be addressed and I just don't have time time, or frankly the expertise, to deal with them. FreeCAD has a lot of dependencies and bundles some of them which I have unbundled, but with the new release it doesn't like the versions (or the forks) that are in Fedora such as smesh and OCE. Here's all the links for the history of the problems... smesh: The version of smesh in fedora is version 6 and is provided by this fork: https://github.com/tpaviot/smesh/issues/55 With issues: https://github.com/tpaviot/smesh/issues/46 https://github.com/tpaviot/smesh/issues/55 If there was a source of smesh 7 compatible with OCE 0.18 that might work. There is also smesh 8 but it can't build with OCE 0.18... My attempts to get help from the forum: https://forum.freecadweb.org/viewtopic.php?f=4&t=28003 https://forum.freecadweb.org/viewtopic.php?f=4&t=28229 https://forum.freecadweb.org/viewtopic.php?f=4&t=29248 Any takers? Thanks, Richard FAS: hobbes1069 ___ 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/5XKGOL3QWPIVJPNVIRLUEMMGGGTAVVSM/
Schedule for Monday's FESCo Meeting (2018-08-06)
(Apologies for the late announcement.) Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-08-06 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #1953 F29 Change: Basic FPGA support https://pagure.io/fesco/issue/1953 DECISION (+6,0) #1954 F29 Change: GnuTLS enables TLS 1.3 by default https://pagure.io/fesco/issue/1954 DECISION (+6,0) = Followups = #topic #1935 [Security] Remove packages which has a consistent bad security record from the distribution .fesco 1935 https://pagure.io/fesco/issue/1935 = New business = #topic #1394 F29 Self Contained Change: Minishift Spin .fesco 1394 https://pagure.io/fesco/issue/1394 #topic #1955 Let's get rid of filedeps (FESCo edition) .fesco 1955 https://pagure.io/fesco/issue/1955 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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/4F4CBQY44N2AYVLZHSXURQ3VFRWZIAIL/
Re: Golang SIG for Fedora
I think that we can mature in the first moment the SIG, and in other moment, channels, groups, and subjects in another moment. An approach about the taiga is about the development of Tools that contemplate the Golang in Fedora Project? ___ 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/SSY4GJ36T6LSVEWLOWHE5QP2BP4Q2HVZ/
Re: Include qt5pas subpackage to lazarus package
Thanks. пн, 6 авг. 2018 г. в 14:55, Artur Iwicki : > I asked Igor Gnatenko and Neal Gompa, as they're both experienced > packagers, of their opinion and they said that introducing a new package > this way is ok. I will merge the PR today in the evening or sometime > tomorrow. > > A.I. > ___ > 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/C4VLPBHSBSAF6VRCAZ72O7QOHR5FP6GY/ > ___ 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/2HW4EEMW6B2BK4USDU7UAYNFD6K2LPKN/
Re: Why are we shipping debug builds of pythons?
On Mon, 06 Aug 2018 10:57:31 +0200, Petr Viktorin wrote: > On 08/05/18 14:01, Jan Kratochvil wrote: > > That is all together messy. This is why Microsoft has their debug build of > > their whole OS - Windows - called Checked Build: > > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/checked-and-free-build-differences > > The main issue with --with-pydebug is that it changes the ABI, i.e. all > extensions need to be re-built specifically for it (and debug extensions > outside the standard library aren't usually packaged in Fedora). That makes > it much less useful than if it just used less optimizations. That confirms the whole OS "Checked Build" variant would solve even this problem. Jan ___ 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/LFTRUAGMLOFIZIRLG7UL2D2KG3LVKOIX/
Re: Include qt5pas subpackage to lazarus package
I asked Igor Gnatenko and Neal Gompa, as they're both experienced packagers, of their opinion and they said that introducing a new package this way is ok. I will merge the PR today in the evening or sometime tomorrow. A.I. ___ 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/C4VLPBHSBSAF6VRCAZ72O7QOHR5FP6GY/
Re: %{valgrind_arches}
On Sun, 2018-08-05 at 15:55 -0700, Samuel Sieb wrote:
> On 08/05/2018 01:13 PM, Florian Weimer wrote:
> > There already is such a macro, %{valgrind_arches}, but it may not
> > accurately reflect the suitability of the run-time behavior of valgrind
> > on a particular architecture. For example, the undefinedness tracking
> > might not be sufficiently accurate for the testsuite of a specific
> > package, so running the testsuite under valgrind gives false positives.
>
> So the original post is only to be used for specific exceptional cases?
Yes, Florian was just being very thorough.
We noticed packages disabled valgrind support on different
architectures for 2 different reasons.
It was disabled based on which architectures the package thought
valgrind was available for. If you just need to enable/disable valgrind
support because of this then please just use the %{valgrind_arches}
macro instead of hardcoding an architecture list in your package. The
macro will be updated whenever valgrind gets support for a new
architecture (or if an architecture is not longer completely supported,
it will be removed from this macro).
Secondly there might be a bug in valgrind on a particular architecture
that is triggered by something specific in the package. In that case
please use the construct Florian suggested to enable support based on
the %{valgrind_arches} macro with some package specific exception for
that particular architecture. And please file a bug against valgrind,
so it might get fixed.
Cheers,
Mark
___
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/QLI3DS7ACNRL4ZB5XTA5KO4MICKISTPB/
Re: Library ABI change
On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote: > recently serd library changed its ABI adding 1 function without > bumping the soname. There's totally normal. It merely added to its ABI - it didn't change existing ABI so nothing will break. soname change is only for when the library deleted a symbol, or changed API contract of an existing symbol. > I think adding one function should not be a problem for depending > packages, what do you think about it? Correct, there's no problem. At the very most applications using the new API would want to explicitly require a particular version of the library RPM Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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/6AFMFKGUBAZG5P52WR3JQKESKNUHCVYX/
Re: Library ABI change
On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote:
> Hi,
> recently serd library changed its ABI adding 1 function without
> bumping the soname.
> I think adding one function should not be a problem for depending
> packages, what do you think about it?
The change is backwards compatible, so programs linked with the older
library will run without issue with the newer library. But programs
linked with the newer library might crash when run with the older
library (if the program uses the new symbol, it will fail during
symbol resolution).
Looking at serd, it does not use versioned symbols [1], so there's
nothing to tell rpm that a package compiled against the newer lib
cannot be installed with the older lib [*]. If the new package is just
in rawhide, it's probably OK to assume that packages will be updated
at the same time. However, if serd were to be updated in released
Fedora, and then some depend package was rebuild against the new serd
and an update was released for it, users might install just that
update without updating serd, and the app could then crash at
startup. So serd should not be updated in F28 or lower without additional
precautions.
[1] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
[2] I'm out of my depth here, and would love for somebody who understands
this to fill in the details:
I see three types of libraries:
- libraries that use symbol versioning like libsystemd. Then each new symbol
that is added get's it's own version, and this translates into generated
Provides:
$ /usr/lib/rpm/elfdeps -P /usr/lib64/libsystemd.so.0.19.0
libsystemd.so.0(LIBSYSTEMD_209)(64bit)
libsystemd.so.0(LIBSYSTEMD_211)(64bit)
...
libsystemd.so.0()(64bit)
That is clear, because then dependent packages require a specific version,
e.g. $ rpm -qR xtide | grep systemd
libsystemd.so.0()(64bit)
libsystemd.so.0(LIBSYSTEMD_209)(64bit)
- libraries that use just a single-number so-version. Then rpmdeps generates
Provides based on DT_SONAME.
serd seems to fall into this category, because
it is linked as
[11/13] Linking build/libserd-0.so
['/usr/lib64/ccache/gcc', '-shared', '-Wl,-h,libserd-0.so.0',
'src/byte_source.c.3.o', 'src/env.c.3.o', 'src/n3.c.3.o', 'src/node.c.3.o',
'src/reader.c.3.o', 'src/string.c.3.o', 'src/uri.c.3.o', 'src/writer.c.3.o',
'-o/var/tmp/serd/serd-0.30.0/build/libserd-0.so', '-Wl,-Bstatic',
'-Wl,-Bdynamic', '-lm']
$ rpm -qP serd | grep libserd
libserd-0.so.0
libserd-0.so.0()(64bit)
- but then there are libraries which use major-minor-patchlevel versioning,
as described in https://autotools.io/libtool/version.html.
But afaics, only the major number, i.e. the so-version finds reflection
in the executables which link to this library, and there's also no difference
in Provides.
For example:
$ cat a_out.c
int main() {return 0;}
$ gcc -Wall a_out.c -o a_out -lmikmod
$ /usr/lib/rpm/elfdeps -R ./a_out | grep mikmod
libmikmod.so.3()(64bit)
So libmikmod has a minor-patchlevel version of .3.0, but seemingly no use is
made
of this. Am I missing something?
Zbyszek
___
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/BGMXR2F57A5RYYXTPFYCEJALCXAYWHGH/
Re: [Test-Announce] Proposal to CANCEL: 2018-08-06 Fedora QA Meeting
Fine for me. Go to sleep Adam. On 6 August 2018 at 07:16, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting tomorrow (today?), > as no-one seemed to have anything urgent for the agenda in response to > my other mail. So, I get to sleep in! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to test-announce-leave@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/test- > annou...@lists.fedoraproject.org/message/XQFTE7RITNIAID2KHVZ6JPWPSYYIDZ6N/ > ___ > 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/XQFTE7RITNIAID2KHVZ6JPWPSYYIDZ6N/ > ___ 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/2RN4AZP5GWJ7LZF3HPCXWEQUFYBBHHGS/
Re: Why are we shipping debug builds of pythons?
On 08/05/18 14:01, Jan Kratochvil wrote:
On Sun, 05 Aug 2018 13:39:58 +0200, Charalampos Stratakis wrote:
Here we are referring to the python2-debug or python3-debug builds, which
are just extra python builds that are compiled with the --with-pydebug flag
Not just --with-pydebug:
--
%if %{with debug_build}
BuildPython debug \
"--without-ensurepip --with-pydebug" \
"-O0"
%endif # with debug_build
BuildPython optimized \
"--without-ensurepip %{optimizations_flag}" \
""
--
Many packages have their *-debug variants. And then some packages (like
kernel) switch even their standard builds to debug mode but only in Rawhide.
Despite all that the *-debug package one occasionally needs is then missing
and one still has to build it locally.
That is all together messy. This is why Microsoft has their debug build of
their whole OS - Windows - called Checked Build:
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/checked-and-free-build-differences
The main issue with --with-pydebug is that it changes the ABI, i.e. all
extensions need to be re-built specifically for it (and debug extensions
outside the standard library aren't usually packaged in Fedora). That
makes it much less useful than if it just used less optimizations.
___
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/4E32NGEBSVXDBVFP5UOMSKADV3EU2GAU/
Re: python-pip license changed (and clarified)
On 6.8.2018 00:59, Nico Kadel-Garcia wrote: On Tue, Jul 31, 2018 at 12:19 PM, Miro Hrončok wrote: On 31.7.2018 18:15, Jun Aruga wrote: 9.0.x -> 10.0.x then 18.0? https://github.com/pypa/pip/blob/master/NEWS.rst Switch to a Calendar based versioning scheme. Oh they changed the versioning rule. See also https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/S7FE45Y76MBIXU7QE75FTZSPEPLIIWOH/ Interesting stuff. Is anyone working with py2pack to update it to more modern Fedora RPM structures? Would it help? Help with what? -- 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/6MW7M2KEGX4GSHAP6YXFADGHOI374QSX/
Library ABI change
Hi, recently serd library changed its ABI adding 1 function without bumping the soname. I think adding one function should not be a problem for depending packages, what do you think about it? Guido fas account: tartina ___ 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/TOJ2PS33R6C4LUJY6FBKXUEVNJZ5W64H/
