Fedora-Atomic 27-20180411.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
Re: updates in stable branches introducing new dependencies
For fetaures, that are optional, weak dependencies is the best solution I can think of. Even when "Recommends" is used, which means it will try to pull the dependency as well, if not said specifically opted-out. > 2 considerations: > * is the user experience significantly affected? > * is the size implications significant? > As far as I can tell, the answer to both is generally no. For everything else, besides opt features, plugins, ... , I totally agree with the nice short answer from Rex. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Tue, Apr 10, 2018 at 1:57 PM, Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > Arguably, the current stable updates policy is against this > > https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases : > > [...] Updates should aim to fix bugs, and not introduce features, [...] > > you snipped off what I consider relevant here: "... particularly when those > features would materially affect the user or developer experience" > > > Is this a legitimate issue or am I making storm in a teacup here? > > Ever-increasing package sizes and dependency bloat do seem to be > > a popular topic these days. > > 2 considerations: > * is the user experience significantly affected? > * is the size implications significant? > > As far as I can tell, the answer to both is generally no. > > -- rex > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On ti, 10 huhti 2018, Todd Zullinger wrote: James Hogarth wrote: On Wed, 11 Apr 2018, 00:59 Todd Zullinger, wrote: Red Hat announced today that Ansible was being deprecated from the extras channel. Their advice is that those who have "previously installed Ansible and its dependencies from the Extras channel are advised to enable and update from the Ansible Engine channel, or uninstall the packages as future errata will not be provided from the Extras channel." https://access.redhat.com/errata/RHSA-2018:1075 Given that, I believe it is reasonable to see ansible return to EPEL. This was discussed in previous EPEL meetings a bit, so I'm sure it was known to at least some of the folks involved. Cheers for the info. It wasn't mentioned on the devel list, I didn't see it in the 7.5 release notes and it was still in extras when I checked a short while ago. In that case yes I agree it makes total sense to return to epel7 I wonder why they dropped it when the whole point of them bringing it in to begin with was for Satellite and Tower to have it in the standard RHEL repos. Seems so pointless to have only had one release there! Indeed, it was a bit strange. Perhaps someone with more insight into the rationale can comment. I have no particular knowledge of things, but maybe keeping a fast moving project like ansible in even the RHEL extras channel was a problem. Maybe the plan with the move to the "Ansible Engine" channel is to work closer with subscribers on migrating from version to version. And non-subscribers can just follow it in EPEL. I'd be interested in hearing more about the change, though I suspect those who know more either aren't on these lists or can't say more than Red Hat's advisory has already. I'm not in Ansible engineering or product management so take this with a grain of salt. My understanding is that cadence of Ansible releases and its aggressiveness in API changes makes it a bit less suitable to follow a traditional RHEL 7 release cadence. A separate product channel allows them to update packages at own cadence. I wonder how re-packaging for CentOS targets could happen with this approach and probably moving it back to EPEL7 is indeed something that makes more sense. -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: updates in stable branches introducing new dependencies
On Wednesday, 11 April 2018 at 10:35, Michal Schorm wrote: > For fetaures, that are optional, weak dependencies is the best solution I > can think of. > Even when "Recommends" is used, which means it will try to pull the > dependency as well, if not said specifically opted-out. That's fine. The optional dependency can be uninstalled afterwards or not installed at all if you have install_weak_deps set to false. > > 2 considerations: > > * is the user experience significantly affected? > > * is the size implications significant? > > As far as I can tell, the answer to both is generally no. > > For everything else, besides opt features, plugins, ... , I totally agree > with the nice short answer from Rex. So, you think the maintainers should be free to add any new dependencies without any announcement or explanation as long as it doesn't "materially affect the user or developer experience"? I actually have nothing against adding new features, even in stable branches, but I do object to lack of communication about those. 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
Re: [EPEL-devel] Ansible in EL7
On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger wrote: > James Hogarth wrote: >> I was under the impression that as of 2.4.0 in EL7 we removed ansible >> from EPEL7 since Red Hat included it in their extras repo, and EPEL >> policy is not to conflict. >> >> I was surprised just now to see ansible 2.5.0 on a test centos system, >> when it wasn't in extras, and on a little bit of a search found: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b >> >> Of course this is a bit of an issue for CentOS/RHEL users that have >> need for the Red Hat ansible as they have been upgraded, and RH will >> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then) >> to ensure they get it from the right repo. >> >> With a branch retirement shouldn't this have been blocked in koji? > > Red Hat announced today that Ansible was being deprecated > from the extras channel. Their advice is that those who > have "previously installed Ansible and its dependencies from > the Extras channel are advised to enable and update from the > Ansible Engine channel, or uninstall the packages as future > errata will not be provided from the Extras channel." > > https://access.redhat.com/errata/RHSA-2018:1075 > > Given that, I believe it is reasonable to see ansible return > to EPEL. This was discussed in previous EPEL meetings a > bit, so I'm sure it was known to at least some of the folks > involved. There probably should be an announcement sent to the epel announce list then it gets to a wider audience so more people know this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Release rpkg-1.53
Dne 11.4.2018 v 04:34 Chenxiong Qi napsal(a): > This is the first version delivering Python 3 package, which is > python3-rpkg. Thanks Miro Hrončok for making the patch. Is it possible to rename the source package to python-rpkg? (I will happily do the package review). Because we have source package rpkg, which does have pythonX-rpkg, and no binary of /usr/bin/rpkg. And then we have (currently under package review) source package rpkg-util, which create binary package rpkg, which provides /usr/bin/rpkg I guess that it can confuse some people. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fw: fedmsg notification
On Mon, Apr 09, 2018 at 01:28:02PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 09 April 2018 at 13:20, Pierre-Yves Chibon wrote: > [...] > > Finally the reason this has not been correctly announced is that we are > > still > > investigating the capacity of the system and the pipeline to check if it can > > handle the load of all the package in Fedora, but as said, the pipeline is > > already sending messages to the production bus, thus this behavior :( > > The obvious thing to do is to stop sending these messages to the > production bus until fedmsg_meta is updated and the update pushed to > production. Why hasn't this been done already? The basic answer is that I didn't have the hand to do it. So instead I released a new fedmsg-meta-fedora-infrastructure with support for these messages and deployed it in production. Messages about the allpackages pipeline should now make some sense :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On Wed, 11 Apr 2018, 10:05 Peter Robinson, wrote: > On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger wrote: > > James Hogarth wrote: > >> I was under the impression that as of 2.4.0 in EL7 we removed ansible > >> from EPEL7 since Red Hat included it in their extras repo, and EPEL > >> policy is not to conflict. > >> > >> I was surprised just now to see ansible 2.5.0 on a test centos system, > >> when it wasn't in extras, and on a little bit of a search found: > >> > >> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b > >> > >> Of course this is a bit of an issue for CentOS/RHEL users that have > >> need for the Red Hat ansible as they have been upgraded, and RH will > >> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then) > >> to ensure they get it from the right repo. > >> > >> With a branch retirement shouldn't this have been blocked in koji? > > > > Red Hat announced today that Ansible was being deprecated > > from the extras channel. Their advice is that those who > > have "previously installed Ansible and its dependencies from > > the Extras channel are advised to enable and update from the > > Ansible Engine channel, or uninstall the packages as future > > errata will not be provided from the Extras channel." > > > > https://access.redhat.com/errata/RHSA-2018:1075 > > > > Given that, I believe it is reasonable to see ansible return > > to EPEL. This was discussed in previous EPEL meetings a > > bit, so I'm sure it was known to at least some of the folks > > involved. > > There probably should be an announcement sent to the epel announce > list then it gets to a wider audience so more people know this. > Especially if EPEL7 now has a clash with an optional repo that is available to all subscribers... There are priority or exclude filters people will need to add to their yum repository configurations that they may not be otherwise aware of if they want the "official Red Hat" build of it etc etc > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK
This is a late proposal for F28 release, mostly to spread awareness of the availability of java-openjdk 10 in Fedora. It is not closely tied to the F28 release however it would be good to have this in the formal F28 scope. That is the reason, why after a discussion with the Change owner, this is announced as a Self Contained Change Proposal. = Proposed Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK = https://fedoraproject.org/wiki/Changes/java-openjdk-10 Owner(s): * Jiri Vanek OpenJDK have release cadence of 6 months. but 3/4 of them are Short Term Supported for 6 months only. This package is designed to harbore them. Currently it is build on openJDK 10. LTSs (next is 11) will go as separate packages. See announcement: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html See java SIG plans: https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf == Detailed description == JDK10 is next major release of Java platform. It is bringing many cool improvements - http://openjdk.java.net/projects/jdk/10/ and is landing to your Fedora. Where it will be maintained for f27 and newer. Unluckily, it is STS (short term support) version. Between individual LTS will be always several STS. Again, please See announcement: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html and See java SIG plans: https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf . So this is rolling release of all STSs to come. Its fate during the release of fresh LTS is yet to be decided. You will always be allowed to install Used LTS in fedora build root, alongside with latest STS via alternatives. == Scope == * Proposal owners: This is isolated change. The maintainers of OpenJDK in Fedora must build the binaries, and keep them working. Still, to keep this rolling release will be soem packaging challenge. Lets see this when JDK12 (or maybe already 11) come out. * Other developers: Should slowly start to check theirs packages against JDK10 * Release engineering: #7433 - https://pagure.io/releng/issue/7433 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On 04/10/2018 11:05 PM, James Hogarth wrote: > At this point, no offense to Nirik and the maintenance he does on the > package, I'm actually tempted to just grab it from upstream directly at > https://releases.ansible.com/ansible/rpm/ Feel free. Do whatever you feel is best for you. > > At least then I can get consistency with selection of stable, preview or > nightly ... I don't really understand what you mean here... EPEL is going to pushing stable releases... with 2 weeks in testing. With 2.5.x upstream is going to try and do minor releases every 2-3weeks with all bugfixes that are landed then. EPEL will package those. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy wrote: > I'm not in Ansible engineering or product management so take this with a > grain of salt. My understanding is that cadence of Ansible releases and > its aggressiveness in API changes makes it a bit less suitable to follow > a traditional RHEL 7 release cadence. A separate product channel allows > them to update packages at own cadence. > > I wonder how re-packaging for CentOS targets could happen with this > approach and probably moving it back to EPEL7 is indeed something that > makes more sense. Wouldn't a separate RHEL channel for a separate product, such as ansible, mean a separate channel for CentOS to avoid precisely this confusion? Mixing it into EPEL and having it on a separate RHEL channel would be *bad* for anyone who activates that separate channel. They'd have to filter it out of EPEL to ensure that the streams don't get crossed on any updates from Red Hat. I understand that this is one of the main reasons EPEL never carries packages that overlap with RHEL published software. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On 11 April 2018 at 15:02, Nico Kadel-Garcia wrote: > On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy > wrote: > >> I'm not in Ansible engineering or product management so take this with a >> grain of salt. My understanding is that cadence of Ansible releases and >> its aggressiveness in API changes makes it a bit less suitable to follow >> a traditional RHEL 7 release cadence. A separate product channel allows >> them to update packages at own cadence. >> >> I wonder how re-packaging for CentOS targets could happen with this >> approach and probably moving it back to EPEL7 is indeed something that >> makes more sense. > > Wouldn't a separate RHEL channel for a separate product, such as > ansible, mean a separate channel for CentOS to avoid precisely this > confusion? Mixing it into EPEL and having it on a separate RHEL > channel would be *bad* for anyone who activates that separate channel. > They'd have to filter it out of EPEL to ensure that the streams don't > get crossed on any updates from Red Hat. I understand that this is one > of the main reasons EPEL never carries packages that overlap with RHEL > published software. The official EPEL policy with regards to conflicts is here: https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F So technically, we aren't against policy here... it is a confusing situation that will require careful config to get the "correct" ansible for RHEL users though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On 11 April 2018 at 10:02, Nico Kadel-Garcia wrote: > On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy > wrote: > >> I'm not in Ansible engineering or product management so take this with a >> grain of salt. My understanding is that cadence of Ansible releases and >> its aggressiveness in API changes makes it a bit less suitable to follow >> a traditional RHEL 7 release cadence. A separate product channel allows >> them to update packages at own cadence. >> >> I wonder how re-packaging for CentOS targets could happen with this >> approach and probably moving it back to EPEL7 is indeed something that >> makes more sense. > > Wouldn't a separate RHEL channel for a separate product, such as > ansible, mean a separate channel for CentOS to avoid precisely this > confusion? Mixing it into EPEL and having it on a separate RHEL > channel would be *bad* for anyone who activates that separate channel. > They'd have to filter it out of EPEL to ensure that the streams don't > get crossed on any updates from Red Hat. I understand that this is one > of the main reasons EPEL never carries packages that overlap with RHEL > published software. It is a lot more nuanced than that. EPEL builds packages that do not overlap with the following channels: rhel-7-server-extras-rpms/ rhel-7-server-optional-rpms/ rhel-7-server-rpms/ rhel-ha-for-rhel-7-server-rpms/ rhel-server-rhscl-7-rpms/ These are chosen because they were the base set originally and other channels which might be available can have items which conflict with each other. This means that EPEL can conflict with somethings inside of "RHEL" but so can things are in "RHEL". > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Package Joplin - FLOSS todo/notes app with NextCloud integration
Hi, I saw Joplin[1], which recently got NextCloud integration[2], is not packaged in Fedora. Maybe one could do so? Best regards, rugk [1] https://joplin.cozic.net/ [2] https://nextcloud.com/blog/mobile-note-taking-with-your-private-cloud-announcing-joplinnextcloud-integration/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 compose report: 20180411.n.0 changes
OLD: Fedora-28-20180410.n.1 NEW: Fedora-28-20180411.n.0 = SUMMARY = Added images:0 Dropped images: 3 Added packages: 5 Dropped packages:1 Upgraded packages: 93 Downgraded packages: 0 Size of added packages: 11.45 MiB Size of dropped packages:9.25 MiB Size of upgraded packages: 904.27 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -80.53 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: AtomicHost raw-xz ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180410.n.1.ppc64le.raw.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-28-20180410.n.1.s390x.tar.xz Image: AtomicHost qcow2 ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180410.n.1.ppc64le.qcow2 = ADDED PACKAGES = Package: R-deldir-0.1.14-1.fc28 Summary: Delaunay Triangulation and Dirichlet (Voronoi) Tessellation RPMs:R-deldir Size:1.39 MiB Package: ghc-cabal-helper-0.8.0.2-1.fc28 Summary: Simple interface to some of Cabal's configuration state, mainly used by ghc-mod RPMs:ghc-cabal-helper ghc-cabal-helper-devel Size:4.14 MiB Package: mypaint-brushes-1.3.0-1.fc28 Summary: Brushes to be used with the MyPaint library RPMs:mypaint-brushes mypaint-brushes-devel Size:2.32 MiB Package: python-cookiecutter-1.6.0-2.fc28 Summary: CLI utility to create projects from templates RPMs:python-cookiecutter-doc python2-cookiecutter python3-cookiecutter Size:1.62 MiB Package: python-pycares-2.3.0-2.fc28 Summary: Python interface for c-ares RPMs:python-pycares-doc python2-pycares python3-pycares Size:1.98 MiB = DROPPED PACKAGES = Package: mozjs17-17.0.0-22.fc28 Summary: JavaScript interpreter and libraries RPMs:mozjs17 mozjs17-devel Size:9.25 MiB = UPGRADED PACKAGES = Package: Zim-0.68-1.fc28 Old package: Zim-0.67-4.fc28 Summary: Desktop wiki & notekeeper RPMs: Zim Size: 1.82 MiB Size change: 4.43 KiB Changelog: * Mon Apr 02 2018 Robin Lee - 0.68-1 - Update to 0.68 Package: authselect-0.4-1.fc28 Old package: authselect-0.3.2-1.fc28 Summary: Configures authentication and identity sources from supported profiles RPMs: authselect authselect-compat authselect-devel authselect-libs Size: 808.26 KiB Size change: 10.87 KiB Changelog: * Mon Apr 09 2018 Pavel B??ezina - 0.4-1 - rebasing to 0.4 Package: cargo-0.26.0-2.fc28 Old package: cargo-0.25.0-1.fc28 Summary: Rust's package manager and build tool RPMs: cargo cargo-doc Size: 15.70 MiB Size change: 406.24 KiB Changelog: * Mon Apr 02 2018 Josh Stone - 0.26.0-1 - Update to 0.26.0. * Mon Apr 02 2018 Josh Stone - 0.26.0-2 - Use an HTML redirect for docs instead of the dir-symlink replacement. Package: certbot-0.23.0-1.fc28 Old package: certbot-0.22.2-1.fc28 Summary: A free, automated certificate authority client RPMs: certbot python2-certbot python3-certbot Size: 994.80 KiB Size change: 1.86 KiB Changelog: * Thu Apr 05 2018 Eli Young - 0.23.0-1 - Update to 0.23.0 (#1563899) Package: containerd-1.0.3-1.fc28 Old package: containerd-1.0.1-1.fc28 Summary: An industry-standard container runtime RPMs: containerd Size: 68.05 MiB Size change: 132.57 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 1.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Apr 04 2018 Carl George - 1.0.3-1 - Latest upstream Package: criu-3.8.1-1.fc28 Old package: criu-3.7-5.fc28 Summary: Tool for Checkpoint/Restore in User-space RPMs: crit criu criu-devel python2-criu Size: 3.12 MiB Size change: 47.42 KiB Changelog: * Wed Mar 14 2018 Adrian Reber - 3.8-1 - Update to 3.8 * Thu Mar 22 2018 Adrian Reber - 3.8-2 - Bump release for COPR * Tue Apr 03 2018 Adrian Reber - 3.8.1-1 - Update to 3.8.1 Package: datagrepper-0.9.3-1.fc28 Old package: datagrepper-0.9.1-2.fc28 Summary: A webapp to query fedmsg history RPMs: datagrepper Size: 116.24 KiB Size change: 24 B Changelog: * Mon Mar 12 2018 Ralph Bean - 0.9.3-1 - new version Package: datanommer-commands-0.7.2-1.fc28 Old package: datanommer-commands-0.7.0-3.fc28 Summary: Console commands for datanommer RPMs: datanommer-commands Size: 30.40 KiB Size change: 636 B Changelog: * Thu Mar 01 2018 Iryna Shcherbina - 0.7.0-4 - Update Python 2 dependency declarations to new packaging standards (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3) * Wed Apr 04 2018 Ralph Bean - 0.7.1-1 - new version * Wed Apr 04 2018 Ralph Bean - 0.7.2-1 - Convert to python3. Package: ddgr-1.4-1.fc28 Old package: ddgr-1.2-1.fc28 Summary: DuckDuckGo from the terminal RPMs:
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
Hi Miro, what to do with packages that can not be ported to python3? For instance ecryptfs-utils … an orphan process will also orphan some dependencies like ecryptfs-simple etc. And therefore sirikali is going to loose some of its features that are available by help from ecryptfs tools. RFE ecryptfs-utils: Add a Python 3 subpackage - https://bugzilla.redhat.com/1458602 Regards, Raphael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
Miro Hrončok wrote: > This is important for those who like to maintain a single spec for > everything. Previously, there have been messages on the devel list that > encouraged people to change the python3 conditional from "if fedora" to > "if fedora or rhel > 7" [5]. Please make a note that it will not be that > simple, because you'll also need to add conditionals for python2, see > for example already mentioned [3] or [4]. Well, python2 could simply be branched for EPEL. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
> "RG" == Raphael Groner writes: RG> what to do with packages that can not be ported to python3? Can anything really not be ported to python3? I suppose if there was something which messed with the internals of the python interpreter in some way then that would potentially never be portable to python3, but instances of that should be quite rare. If the software is dead upstream, or upstream truly does not want to port to python2, nobody wants to do the port or the Fedora maintainer simply does not wish to carry patches to make things work with python3 and python2 is no longer in the distribution then... what else can be done besides dropping the software? Eventually all Linux distributions will have to do the same, or will have to carry (or share) the burden of maintaining the python2 interpreter. Software which requires python2 will become increasingly difficult to use and I imagine that most authors would want to see their software ported rather than have it become increasingly difficult to use without the user having to build or obtain their own python2 interpreter. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Atomic 27-20180411.1 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 28-20180411.n.0 compose check report
No missing expected images. Failed openQA tests: 4/137 (x86_64), 5/23 (i386), 1/2 (arm) ID: 220589 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/220589 ID: 220592 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/220592 ID: 220604 Test: x86_64 Server-dvd-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/220604 ID: 220634 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/220634 ID: 220635 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/220635 ID: 220649 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/220649 ID: 220689 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/220689 ID: 220734 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/220734 ID: 220743 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/220743 ID: 220746 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/220746 Soft failed openQA tests: 8/137 (x86_64), 2/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 220599 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/220599 ID: 220612 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/220612 ID: 220613 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/220613 ID: 220653 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/220653 ID: 220657 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/220657 ID: 220659 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/220659 ID: 220673 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/220673 ID: 220690 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/220690 ID: 220696 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/220696 ID: 220719 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/220719 Passed openQA tests: 125/137 (x86_64), 16/23 (i386) Skipped openQA tests: 1 of 162 -- 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
Re: New gdl segfaults with gcc 8 in antlr
On 03/28/2018 12:56 PM, John Reiser wrote: >> I've just discovered that gdl appears to be segfaulting a lot now deep in >> the antlr c++ generated parser code with the switch to gcc 8. > > A bugzilla report would be nice. Run under gdb, report register contents > and the instruction stream surrounding $pc, etc. Also any clues > about the corresponding location in the source code. > > Is the SIGSEGV deterministic (reproducible every time) or random? > Does memcheck (valgrind --track-origins=yes) complain? It's entirely reproducible. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1566242 with what I can glean. I don't understand the backtrace though. Seems like a destructor is getting called when initializing a class variable. Very strange to me, but I'm no C++ expert. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [EPEL-devel] Re: Ansible in EL7
On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen wrote: > On 11 April 2018 at 10:02, Nico Kadel-Garcia wrote: >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy >> wrote: >> >>> I'm not in Ansible engineering or product management so take this with a >>> grain of salt. My understanding is that cadence of Ansible releases and >>> its aggressiveness in API changes makes it a bit less suitable to follow >>> a traditional RHEL 7 release cadence. A separate product channel allows >>> them to update packages at own cadence. >>> >>> I wonder how re-packaging for CentOS targets could happen with this >>> approach and probably moving it back to EPEL7 is indeed something that >>> makes more sense. >> >> Wouldn't a separate RHEL channel for a separate product, such as >> ansible, mean a separate channel for CentOS to avoid precisely this >> confusion? Mixing it into EPEL and having it on a separate RHEL >> channel would be *bad* for anyone who activates that separate channel. >> They'd have to filter it out of EPEL to ensure that the streams don't >> get crossed on any updates from Red Hat. I understand that this is one >> of the main reasons EPEL never carries packages that overlap with RHEL >> published software. > > It is a lot more nuanced than that. EPEL builds packages that do not > overlap with the following channels: > > > rhel-7-server-extras-rpms/ > rhel-7-server-optional-rpms/ > rhel-7-server-rpms/ > rhel-ha-for-rhel-7-server-rpms/ > rhel-server-rhscl-7-rpms/ > > These are chosen because they were the base set originally and other > channels which might be available can have items which conflict with > each other. This means that EPEL can conflict with somethings inside > of "RHEL" but so can things are in "RHEL". EPEL is a default, critical requirement for many tools, including Chef and mock. Many environments running RHEL or CentOS 6 could not be used without EPEL's plethora of useful tools. RHEL channels can conflict with each other because they are enabled on an individual host, case by case basis. I think, from old experiences, that having *anything* in EPEL that overlaps with any RHEL published channel is begging for pain. It may cause pain to current RHEL ansible users, but I think that the EPEL package needs to be renamed to something like "ansible25" to avoid conflicts with the RHEL channel. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libqalculate soname change
Since 2.4.0 is out, soname change will be to libqalculate.so.16. I will submit pull requests for the affected packages. I might miss F28. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Help with strict-aliasing warning
I'm getting: /builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp: In function 'void lib::linkimage(EnvT*)': /builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp:159:36: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (BaseGDL* &) dynFun[count_fun] = ^ (BaseGDL*) dlsym(module[count], entryName.c_str()); dynFun is defined as: BaseGDL*(*dynFun[MAXNDLL/2])( EnvT* e); This is all beyond me. Missing the function pointer argument specification? Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2018-04-12 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-04-12 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2018-04-12 09:00 PDT US/Pacific 2018-04-12 12:00 EDT --> US/Eastern <-- 2018-04-12 16:00 UTC UTC 2018-04-12 17:00 BST Europe/London 2018-04-12 18:00 CEST Europe/Berlin 2018-04-12 18:00 CEST Europe/Paris 2018-04-12 21:30 IST Asia/Calcutta New Day: Friday - 2018-04-13 00:00 HKT Asia/Hong_Kong 2018-04-13 00:00 +08 Asia/Singapore 2018-04-13 01:00 JST Asia/Tokyo 2018-04-13 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #691 noarch *sub*packages with arch-specific dependencies .fpc 691 https://pagure.io/packaging-committee/issue/691 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #694 Packaging guidelines for application independence .fpc 694 https://pagure.io/packaging-committee/issue/694 #topic #702 C/C++ guidelines should say using clang needs an exception .fpc 702 https://pagure.io/packaging-committee/issue/702 #topic #708 Allocating a static uid and gid for openvswitch .fpc 708 https://pagure.io/packaging-committee/issue/708 #topic #710 Ruby packaging guidelines update .fpc 710 https://pagure.io/packaging-committee/issue/710 #topic #713 Forward-looking conditionals by default .fpc 713 https://pagure.io/packaging-committee/issue/713 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #715 Separately building package documentation .fpc 715 https://pagure.io/packaging-committee/issue/715 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #723 Guidelines for handling deprecated dependencies during review .fpc 723 https://pagure.io/packaging-committee/issue/723 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 = New business = #topic #761 Modernize R guidelines .fpc 761 https://pagure.io/packaging-committee/issue/761 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://pagure.io/packaging-committee , 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
Re: Fw: fedmsg notification
Hi Pierre, Pierre-Yves Chibon wrote: > On Mon, Apr 09, 2018 at 01:28:02PM +0200, Dominik 'Rathann' Mierzejewski > wrote: >> On Monday, 09 April 2018 at 13:20, Pierre-Yves Chibon wrote: >> [...] >>> Finally the reason this has not been correctly announced is that we are >>> still >>> investigating the capacity of the system and the pipeline to check if it can >>> handle the load of all the package in Fedora, but as said, the pipeline is >>> already sending messages to the production bus, thus this behavior :( >> >> The obvious thing to do is to stop sending these messages to the >> production bus until fedmsg_meta is updated and the update pushed to >> production. Why hasn't this been done already? > > The basic answer is that I didn't have the hand to do it. > So instead I released a new fedmsg-meta-fedora-infrastructure with support for > these messages and deployed it in production. > Messages about the allpackages pipeline should now make some sense :) Is this deployed in production? I just pushed some changes to a fork on src.fedoraproject.org and recieved an email for each commit that looked like this: Subject: fedmsg notification Notification time stamped 2018-04-12 04:23:01 UTC https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/upstream-fedora-pipeline-trigger/detail/upstream-fedora-pipeline-trigger/11044/pipeline/ If there's a change from what Michael reported, I can't see what it is. :) I suspect this shouldn't be triggering at all for forks, which I believe two open infrastructure tickets cover: https://pagure.io/fedora-infrastructure/issue/6575 https://pagure.io/fedora-infrastructure/issue/6791 For non-forks, I think it would also be ideal to not fire this off for each commit but rather once per push. Thanks, -- Todd ~~ I have never let my schooling interfere with my education. -- Mark Twain (1835-1910) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2018-04-13)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting 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-04-13 15:00 UTC' NOTE: we discussed moving the meeting one hour earlier, but there wasn't enough support for this, so the meeting time is unchanged. Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1877 large number of packages FTBFS in F28 .fesco 1877 https://pagure.io/fesco/issue/1877 #topic #1874 Package Anki has a Non-responsive Maintainer .fesco 1874 https://pagure.io/fesco/issue/1874 #topic #1872 Disable Test Gating requirements until more UI is enabled .fesco 1872 https://pagure.io/fesco/issue/1872 #topic #1868 Change the Changes template .fesco 1868 https://pagure.io/fesco/issue/1868 = New business = #topic #1878 Please change "Everything" directory to something less inaccurately comprehensive .fesco 1878 https://pagure.io/fesco/issue/1878 #topic #1876 Please orphan all LXQt packages / nonresponsive maintainer heliocastro .fesco 1876 https://pagure.io/fesco/issue/1876 = 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
