Re: rpcgen?
On 01/10/2018 04:20 AM, Ian Kent wrote: Note that the plan is that the new package will provide rpcgen, so you can just use BuildRequires: rpcgen and you'll get the new package once it becomes available. What can I do in the meantime to build autofs in Rawhide? You can use rpcgen today, it's provided by glibc-rpcgen, but the package providing it will change. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ISC DHCP license change notificcation
Hello, Internet Systems Consortium, has changed license of DHCP from ISC to MPL 2.0 [1] since 4.4.0 (which will land rawhide soon). [1] https://www.isc.org/blogs/isc-dhcp-moves-to-mpl-2-0-license/ -- Pavel Zhukov Software Engineer IRC: landgraf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Jan 09 14:41, Pierre-Yves Chibon wrote: > On Tue, Jan 09, 2018 at 02:29:38PM +0100, Dan Horák wrote: > > On Tue, 9 Jan 2018 11:03:28 +0100 > > Pierre-Yves Chibon wrote: > > > > > Dear all, > > > > > > The Fedora Infrastructure team has had a jenkins instance running at > > > jenkins.fedorainfracloud.org for a little while now. This instance was > > > maintained on a best-effort basis though and we often had outage and > > > issues when upgrading it. > > > Originally the jenkins master was running on RHEL using the RPMs > > > provided by upstream jenkins. When jenkins became available in > > > Fedora, we switched our master to be Fedora using the RPMs from > > > Fedora. However, nowadays Jenkins is no longer packaged for Fedora, > > > our jenkins master is therefore outdated. > > > > > > On the other side of the fence, with our dear friends from CentOS, is > > > a brand new, shiny and well supported Jenkins instance. > > > So we thought it may be good to leverage the CentOS infrastructure to > > > alleviate our infrastructure and maintenance. > > > > > > We are currently working on setting up a Jenkins master in > > > ci.centos.org that would be dedicated to projects ran in pagure.io. > > > It needs a small change to pagure.io and some work on the CentOS side > > > but nothing hard and we expect to be able to migrate the first > > > volunteer projects by early next week. > > > > do you plan to use the dynamically provisioned workers like the > > current CentOS CI or will it use the static workers like the Fedora > > Jenkins? > > My understanding is to start with static workers as we have now in Fedora to > ease the migration (no config change needed) and work from there to migrate to > dynamically provisioned workers as the rest of CentOS CI does. > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org That's correct, we'll do static agents that match existing Jenkins labels (EL6, EL7, F25, F25-ppc64le, and F26). Longer term, we'll work 1:1 with job owners to migrate to dynamic provisioning. --Brian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Jan 09 09:25, Adam Williamson wrote: > On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote: > > Dear all, > > > > The Fedora Infrastructure team has had a jenkins instance running at > > jenkins.fedorainfracloud.org for a little while now. This instance was > > maintained on a best-effort basis though and we often had outage and issues > > when > > upgrading it. > > Originally the jenkins master was running on RHEL using the RPMs provided by > > upstream jenkins. When jenkins became available in Fedora, we switched our > > master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins > > is no > > longer packaged for Fedora, our jenkins master is therefore outdated. > > > > On the other side of the fence, with our dear friends from CentOS, is a > > brand > > new, shiny and well supported Jenkins instance. > > So we thought it may be good to leverage the CentOS infrastructure to > > alleviate > > our infrastructure and maintenance. > > > > We are currently working on setting up a Jenkins master in ci.centos.org > > that > > would be dedicated to projects ran in pagure.io. > > It needs a small change to pagure.io and some work on the CentOS side but > > nothing hard and we expect to be able to migrate the first volunteer > > projects by > > early next week. > > > > Once the first migrations have happened and the first rough edges have been > > smoothed we will be announcing an official retirement date for > > jenkins.fedorainfracloud.org and migrate all the projects hosted there to > > ci.centos.org, and of course help with the potential questions raising from > > this. > > Will there be a standard / automated migration path for projects that > have followed documented steps to implement a CI workflow through this > Jenkins instance, like these: > > https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html > > ? Thanks! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org The plan is to automatically import the existing job configs from jenkins.fedorainfracloud to the new tenant in ci.centos.org Changing the Build trigger in the repo settings to point at the new instance -may, or may not- be a manual step, but there will be, at the very least, a documented procedure for that. The goal here is to, first get a supported jenkins instance available, try a migration of a 'friendly' project (thanks Pingou for volunteering!) and then work out the procedures for retirement. -- Brian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On 09/01/18 23:31, Florian Weimer wrote: > On 01/09/2018 03:32 PM, Steve Dickson wrote: >> >> >> On 01/09/2018 06:10 AM, Richard W.M. Jones wrote: >>> >>> https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 >>> says: >>> >>> "Packages which need rpcgen will have to add BuildRequires: >>> libtirpc-devel to their spec files." >>> >>> but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. >> Nor will it... There is going to be a new package call rpcsvc-proto >> that will contain the rpcgen command along with other things >> like header files... There is the upstream git tree: >> http://github.com/thkukuk/rpcsvc-proto >> >> Here is the Review Request for the package, if interested. >> https://bugzilla.redhat.com/show_bug.cgi?id=1532364 > > Note that the plan is that the new package will provide rpcgen, so you can > just use > > BuildRequires: rpcgen > > and you'll get the new package once it becomes available. What can I do in the meantime to build autofs in Rawhide? Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build
On 10 January 2018 at 11:30, Jason L Tibbitts III wrote: > In the end I just can't shake the notion that it's bad to have some > random non-python-related environment variable basically breaking > python. Aye, I think you've hit on the main problem: if this is keyed off RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora provided Python, even if those builds aren't otherwise required to abide by Fedora's policy settings. With a dedicated environment variable instead, that could look something like: PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning Then either Koji can take care of setting that (and including it in the mock configs it generates), or else it can be included in some of the Fedora specific RPM setup. Cheers, Nick. P.S. Using a dedicated environment variable would have the advantage of allowing anyone else that *also* wanted to look for and remove unqualified references to Python 2 to set it. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build
> "JK" == Jan Kurik writes: JK> Python 2, when called as python or /usr/bin/python at RPM build time JK> (as identified by the RPM_BUILD_ROOT environment variable), will JK> print a deprecation warning to stderr. (Any program invoked during JK> build that invokes /usr/bin/python will cause this warning as well.) I applaud the effort and think the idea is a good one. However, I'm vaguely uneasy about hanging this off of the seemingly unrelated RPM_BUILD_ROOT. My initial idea was to simply decide on another variable to use such as AMBIGUOUS_PYTHON_VERSION_WARNING, and then set that in our rpm configuration. (Most likely in %__build_pre, which is defined by the macros in the rpm package, not redhat-rpm-config.) But it occurs to me that in the end this has the same result; you get complaints even if you're building non-Fedora packages (where our guidelines don't apply). It's just that the involved variable is slightly more obvious. I guess if we did that Python would only need to check one environment variable, but that's not really much of a concern. It would also mean that "unset RPM_BUILD_ROOT" would never occur to someone as a potential solution. In the end I just can't shake the notion that it's bad to have some random non-python-related environment variable basically breaking python. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
On Tue, Jan 09, 2018 at 11:06:11PM +0100, Casper wrote: > I will miss the next mass-rebuild because of your shitty mind Hey. Please remember the Fedora friends foundation — and our code of conduct. Directing this kind of comment at another contributor is not okay. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[testing] community-mysql update needs testing!
Hello, I'm in a hurry for this update to get to the stable repository, however it contains OpenSSL update, which should be tested by many more users, to be sure. All karma - positive or neagitve - will be welcomed! https://bodhi.fedoraproject.org/updates/FEDORA-2018-b7b2c36b14 Thanks! -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
Casper wrote: > I will miss the next mass-rebuild because of your shitty mind The mass rebuild cannot happen with your incompatible package because many packages indirectly depend on systemd. At the very least, systemd needs to be rebuilt against the new qrencode. And systemd itself drags in systemd as a build dependency, then it cannot be built at all without either something providing libqrencode.so.3 or building a systemd without qrencode support BEFORE the bumped qrencode. Also, missing the mass rebuild is not a reason to panic, anything depending on libqrencode.so.3 will have to be rebuilt anyway. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build
Jan Kurik wrote: > Currently in Fedora (package names, executable names, etc.), python > means Python 2. > We would like to change it to mean Python 3, but to do that, we need > to free it of the current meaning. > This means explicitly using either "python2" or "python3" throughout > Fedora. Are you sure that this is worth the pain? Unsuffixed qmake is still the Qt 3 QMake (not even Qt 4), unsuffixed kde-config is still the KDE 3 kde-config (not even KDE 4), etc., for backwards compatibility. I think changing the meaning of "python" is unhelpful and counterproductive. Sure, without this change, more and more users will eventually end up with not having an unsuffixed "python" installed at all, but IMHO that's better than silently changing its meaning. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
On Tue, 2018-01-09 at 23:06 +0100, Casper wrote: > no kidding, it's a critpath, and one day it will be updated in > development branch (which is called "Rawhide"). > > you want a rendez-vous or what ? There's a process you're meant to follow: https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master "For updates to rawhide packages, Maintainers SHOULD: ... * A WEEK IN ADVANCE, notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them. * Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this." I don't know if enough things depend on qrencode for it to be worth setting up a buildsystem tag to do the rebuilds, but the first of those two points *certainly* applies to your case. Rather than notifying at the time you did the rebuild, you should have sent out a mail a week in advance. Ideally it would be best to co-ordinate with the maintainers of dependent packages so that builds of the library and the dependencies land in the same compose and there is no breakage - certainly for something as critical as systemd, without which nothing works at all. Rawhide is a development release, but that doesn't mean that it's OK to just break it whenever you like. We are trying to keep Rawhide at consistent Alpha quality (that's what the previous cycle's "No More Alphas" Change was about). That certainly involves making sure the init system always works. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS
Providing privacy and security for DNS! (especially after dnscrypt is discontinued now). It would be nice to have this in Fedora. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby GitHub: https://github.com/getdnsapi/stubby For distro status see: https://repology.org/metapackage/stubby/versions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
HEADS UP - Changes to Ghostscript package in F28
Hello guys! :) Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally... I would like to inform you that Ghostscript package has received proper cleanup in accordance to Fedora Packaging Guidelines (FPG), and comments from upstream were also incorporated into the changes. The aim was to simplify the package maintenance, to bring the Fedora's Ghostscript package as close as possible to upstream's vanilla build, to completely debundle the Ghostscript package of software/resources that we already have available (packaged) in Fedora, and to transform the layout of subpackages to be more sane and granular... The changes are described more in detail below: * libijs -- the IJS library has been debundled and is now provided as a separate package: https://src.fedoraproject.org/rpms/libijs * libgs -- new separate package, created from Ghostscript's shared library. It contains all necessary files for other software/packages that are build upon Ghostscript's functionality. * libgs-devel -- new separate subpackage, for development purposes or Fedora's build process. The 'ghostscript-devel' is still provided for now as a virtual subpackage. ->> This particular change will allow packages depending on Ghostscript functionality (like evince for example) to only require 'libgs', instead of requiring almost the whole Ghostscript (and thus pulling in files that many users don't want/need or might even never use). * ghostscript -- is no longer a metapackage. It's a regular package instead, and it contains Ghostscript's binaries as well as some typical conversion scripts people are used to (and expect to have installed together with Ghostscript by default). * ghostscript-tools-fonts -- new subpackage that contains 3 scripts that are useful only for people who are working with AFM, PFB or PFA files (conversions usually). * ghostscript-tools-printing -- new subpackage that contains only utilities for formatting and printing text files using either Ghostscript, or BubbleJet, DeskJet, DeskJet 500, & LaserJet printers. ->> These subpackages contain files that only a small amount of people will ever need. Having them in a separate subpackages will avoid polluting users' filesystem after fresh F28+ installations. * ghostscript-core -- has became an empty metapackage for upgrade purposes. It will be removed once Fedora 28 is EOL, and all other packages has updated their specfiles to require correct subpackages. ->> This metapackage makes sure that upgrade from old package layout to new package layout should be smooth (tested in F27). * LPR setup scripts are no longer being shipped. In case people still need those, then 'ghostscript-tools-lpr' will be created for it. * examples/ from 'ghostscript-doc' are no longer shipped. * Documentation and resources paths no longer contain version string inside of them. * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use Ghostscript's default choice for rendering of CJK glyphs, which is Google Droid Sans Fallback font. In case this proves insufficient, the conf.d/ folder support will be re-established. ->> This change is still being discussed with Peng Wu and Akira Tagoh. So far, we have agreed to this change, but I will be ready to revert it in case people depending on printing CJK-based texts will have any problems. In case the Ghostscript's default functionality would prove to be sufficent and work OK, then the 'ghostscript-chinese' package could be retired as a result. ->> For now, we are also waiting for rebase of 'google-droid-fonts' for Ghostscript to have the latest version of Droid Sans Fallback font and thus the latest CJK glyphs coverage. * Symbolic links for direct resources locations have been added to speedup Ghostscript's startup time. * Ghostscript's search path was updated to include only fonts locations, which will be used only as a backup (in case of broken symbolic links). ->> This change is a preferred method (advised) from upstream. * Ghostscript itself (as a whole) has been completely debundled (to a point where it still makes sense). It newly requires these packages: https://src.fedoraproject.org/rpms/adobe-mappings-cmap https://src.fedoraproject.org/rpms/adobe-mappings-pdf https://src.fedoraproject.org/rpms/libijs https://src.fedoraproject.org/rpms/urw-base35-fonts https://src.fedoraproject.org/rpms/google-droid-fonts ->> I will send additional separate e-mails to this mailing list tomorrow to inform others of availability of some of these packages. * As a result of debundling, 'poppler-data' is no longer a requirement for Ghostscript, and it is no longer necessary to do a rebuild of 'poppler-data' when Ghostscript is rebased. ---
Re: Security updates and batched pushes
Kevin Fenzi wrote: > […] I really don't understand why we do this "batched" thing to begin with. >>> To reduce the constant flow of updates that are very minor or affect >>> very few mixed in with the major updates that affect lots of people and >>> are urgent. >> But the users were already able to opt to update only weekly. So why force a >> fixed schedule on them? > To save all the Fedora users in the world from having to update metadata > for minor changes. Since there's a hourly dnf makecache every user in > the world pulls down new metadata ever time we update a repo. If we > update a repo for some minor enhancements it means everyone in the world > has to pay for that. If we just push all those out every tuesday and > don't update those unless there's something urgent we save everyone a > lot of bandwith and us computing time/resources. > […] BTW, are there technical reasons why the metadata is updated en bloc and not incrementally like for example delta RPMs, or is it just that nobody bothered to implement something like that yet for metadata? Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
first, thanks for your remarks. the build has been untagged (thanks for releng reactivity), so it won't be a melodramatic movie about rawhide which is broken... oh wait! look the mass-rebuild showing the point of its nose... seriously. I will miss the next mass-rebuild because of your shitty mind no kidding, it's a critpath, and one day it will be updated in development branch (which is called "Rawhide"). you want a rendez-vous or what ? Sérgio Basto a écrit : > On Tue, 2018-01-09 at 21:12 +0100, Igor Gnatenko wrote: > > On Tue, 2018-01-09 at 20:37 +0100, Casper wrote: > > > Dear Fedora Devops, > > > > > > qrencode (critpath) package has been updated in rawhide branch. > > > > > > Major change: > > > from: libqrencode.so.3.4.4 > > > to: libqrencode.so.4.0.0 > > > > > > If you need to report any issue: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1510097 > > > > > > Koji build: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494 > > > > > > Many packages requires libqrencode (systemd, etc...) so take care > > > about compatibility breakage. > > > > Does it mean that maintainers of those packages should take care of > > them or > > will you? > > > > Sending email when you **broke** all builds in rawhide is pretty > > bad... > > nothing provides libqrencode.so.3()(64bit) needed by systemd-236- > 1.fc28.aarch64 > > seems to me pretty serious > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 x509 C.A.: https://dl.casperlefantom.net/pub/root.pem Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote: > On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote: > >>= System Wide Change: Make authselect default tool instead of authconfig = > >>https://fedoraproject.org/wiki/Changes/AuthselectAsDefault > > > >Does this change do anything to reduce the number of files in /etc > >that do not contain local configuration? PAM is currently one of the > >worst offenders, with /etc/pam.d full of "configuration" files. > > No. The files must stay since it would require changes in pam itself > and that is out of scope of authselect. Each file corresponds to > individual pam service and is read when pam_start(service_name, ...) > is called. > > >Elsewhere in the thread /usr/share/authselect/custom is metioned as > >directory for admin config. That's OK-ish, as long as you also allow > >a directory in /etc for the same purpose. /usr must be allowed to be > >immutable. > > Would /usr/local be OK as well? /usr/local is special. Packages are not allowed to put stuff there [1], and it is instead an alternate install location that is under the control of the administrator. It seems reasonable to support authselect configuration located there. /usr/share/authselect and /etc/authselect are the two main locations that should be supported, and /usr/local/share/autselect would be an additional option. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Disable a package for Fedora 26
Jonny Heggheim wrote: > I think the best solution, based on my knowledge and available time, is > to upgrade Fedora 26 to the latest upstream. So please do that then. The sooner, the better. > The fixes from upstream are spread on several commits and releases. That is also the case with, e.g., Firefox, whose maintainers also always upgrade rather than backporting. So I think you will be best off upgrading your package too. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Planned Outage - Taskotron update - 2018-01-09 @ 22:00 UTC
Apologies on not announcing this farther ahead of time. There will be an outage starting at 2018-01-09 22:00:00 UTC, which will last 4-6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-01-09 22:00:00 UTC' Reason for outage: We are upgrading the hosts which run the services required for Taskotron. This will not affect resultsdb as this will be upgraded at a later date. Affected Services: taskotron.fedoraproject.org Contact Information: Please join #fedora-admin or #fedora-noc on irc.freenode.net pgp9xEPsN64z7.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
Matthew Miller wrote: > Also, I think everyone in this discussion on _this_ list who would like > updates faster should probably be using updates-testing. Or at least > _looking_ at updates-testing. You can always pull individual updates > from there on a per-package basis, and doing this helps everyone else. I want tested updates faster. I don't want untested updates. I also don't think it would be a productive use of my time to go through all testing updates every day to see which ones are batched for stable. This is something that could easily be automated by software (i.e., by having Bodhi push the updates to a fast track repository), why should I be doing this by hand? What I do normally do is read the update notes of every update that I am about to apply. This is also a reason why I hate the batching, because the batches are huge and painful to check through. I prefer more frequent smaller pushes that I can easily read through. But what I can definitely tell you is that most updates do not contain enough information in the update notes to really know their impact, so using that as a basis for applying or not applying some update from updates-testing is not going to scale either. By the way, the reason I did not voice these complaints in the thread initially announcing this change is that I was both too angry and too busy at that time to come up with a polite reply, and besides, the change was already implemented when announced anyway. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
Kevin Fenzi wrote:
> You also don't want updates-testing to even exist right?
That is not true. I want to leave the decision whether and for how long an
update needs to be tested to the package maintainer instead of enforcing
minimum testing requirements in the software, because the software can never
understand the exact context. Removing updates-testing entirely is not what
I want! But this is unrelated to the current issue of artificially delaying
updates that satisfy all the criteria for being pushed to stable.
> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.
So to save people the download, you make a change that totally defeats the
point of dnf checking for updates every hour to begin with?
> If we update a repo for some minor enhancements it means everyone in the
> world has to pay for that. If we just push all those out every tuesday and
> don't update those unless there's something urgent we save everyone a
> lot of bandwith and us computing time/resources.
This does not work in practice because there are always updates that are not
batched.
> There are definitely more days when there are no updates for a
> particular repo now. Of course there would be even more if you (or those
> who do likewise) wouldn't skip batched, but probibly we need to explain
> why more clearly.
Are there really? The last couple days, there were basically daily pushes
with around 2 updates each.
The batching only makes the daily pushes smaller and not empty, which does
not help at all for reducing repodata download size, because there are still
no repodata deltas implemented.
> because it would be a ton more infrastructure and resources.
Really? Bodhi composes (or triggers the compose of, let's please not discuss
the technical details down to that level) 2 repositories per release at each
push, of which one (updates-testing) already works pretty much the way the
fast track repository would work (updates transit there, but leave again
when they reach the next level). How would adding a third level require a
ton more resources? It would just need some small changes to the Bodhi
implementation ("pushes to batched" would have to be actually pushed, to the
fast track repository) and could otherwise use all the existing mirroring
infrastructure. And users would be able to opt in to getting stable updates
without batching. And even if those users keep the regular repodata
downloads enabled, the downloads for fast track would still be much smaller
than the repodata downloads for all of stable. And having fast track
available would also reduce the proportion of updates that skip batched. (I
know I would think twice about skipping batched for my updates if I knew
that the users have a way to opt out of the batching. Right now, I don't
even consider using batched.)
I see only advantages of such an approach, for minimal infrastructure costs.
Almost everything you need is already there!
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: GCC8
On Tue, Jan 09, 2018 at 07:50:10PM +, Stephen Gallagher wrote: > > Well, true, but then just like every year, we'll wind up doing a lot of > > the spadework of fixing things to build with the new GCC. And probably > > at first some critical things will fail to build and that'll mess up > > the stability of the distro for a couple of weeks. I guess if everyone > > else is still loving that grind, hey. > > > > > This is the cost of being "First". Fedora has long enjoyed a tight coupling > with the GCC upstream. It's a symbiosis: they use our mass-rebuild to help > identify any issues before GCC goes stable and in turn Fedora gets to have > the newest compiler features before anyone else. To be fair, Ubuntu (or Debian or both, dunno) has already performed test mass rebuilds with GCC 8 prerelease some time ago and OpenSUSE usually performs them roughly at the same time as we do. We are likely the first one or one of the first ones to deploy it as a stable compiler in the distro and it is mutually beneficial both for the distro and for GCC. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
On Tue, 2018-01-09 at 21:12 +0100, Igor Gnatenko wrote: > On Tue, 2018-01-09 at 20:37 +0100, Casper wrote: > > Dear Fedora Devops, > > > > qrencode (critpath) package has been updated in rawhide branch. > > > > Major change: > > from: libqrencode.so.3.4.4 > > to: libqrencode.so.4.0.0 > > > > If you need to report any issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=1510097 > > > > Koji build: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494 > > > > Many packages requires libqrencode (systemd, etc...) so take care > > about compatibility breakage. > > Does it mean that maintainers of those packages should take care of > them or > will you? > > Sending email when you **broke** all builds in rawhide is pretty > bad... nothing provides libqrencode.so.3()(64bit) needed by systemd-236- 1.fc28.aarch64 seems to me pretty serious > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide
On Tue, 2018-01-09 at 18:28 +0100, Till Hofmann wrote: > > On 01/09/2018 05:53 PM, Sérgio Basto wrote: > > Packages remaining to rebuild: > > digikam > > fawkes > > kf5-libkface > > nomacs > > player > > simon > > > > Provenpackager request for: > > Do fedpkg build in fawkes master [3] > > [3] > > https://src.fedoraproject.org/rpms/fawkes/commits/master > > > > > That won't help because fawkes ist still FTBFS after the last > protobuf > bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093 I need more one help from provenpackager merge and build player [1] from what I see to build fawkes, you just need rebuild player. I had confused the deps around package player but all builds correctly on copr [2] [1] https://src.fedoraproject.org/rpms/player/pull-request/1 [2] https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/builds/ > Regards, > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-01-09 at 20:37 +0100, Casper wrote: > Dear Fedora Devops, > > qrencode (critpath) package has been updated in rawhide branch. > > Major change: > from: libqrencode.so.3.4.4 > to: libqrencode.so.4.0.0 > > If you need to report any issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1510097 > > Koji build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494 > > Many packages requires libqrencode (systemd, etc...) so take care > about compatibility breakage. Does it mean that maintainers of those packages should take care of them or will you? Sending email when you **broke** all builds in rawhide is pretty bad... - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpVIh8ACgkQaVcUvRu8 X0xSsg/9Fh6ZI3szUCJsnhUlqm9NIomkMirw5N2iDhMoa+eHZAInJGymsV4yFL3D zWXYLh9NbX3rZRlLT3uRRLpl/Vhbw2pB/5TkQhiIfyYcCE1XvktJk7gkxNPewOUj c2mrHaclfc44IMtwrnELJK0A8dfdjp9dwWn8A9gLfTU+mrSE49p3PcYTNtWRVBGD DJXUZASBDqZIRR0tzQ6/5rLRktLoQ7g2UCUVcQzHEY+wdX3Vv0wdwJv8TCZ+yh/l dJZQvtbls0GqM46g3riiK5x5y5osV1YbDaJVPwOdorLMPlCCaF3sbtlEqMdGPqy1 +VTUz1dul6p6u2OIwFAK47XL2Z5tnahKKBxT4dqQBJD4iQkf/oGylQvsQBAEJEB9 JjTdhsiFnQYPdJQprzF3sIncj5CwOyB+7cQQPKsjngsbtRhT0wMRFVP10g+CSlYh F/0AAwfIprfGtBtnhaG3DK+H2W2bsUJCvZz0rtqDr3xMC07BQs4dOMNBtRsqCrW0 CLCHxadBWr2WF3X3R17335IpTQ4kVyCU3Ezu/HanvKOWF6gad/2NRuAc2f2oPG/j RZ9UNBaD1Rl32QdBmuY9KYz/4qnuZzfq2qAAqTvm+t4w6NmN5sVm1Rzb8h9FtkAn GTF3R5LmZSzJjtdMW31XA5Hxic04s7lkI0xtFt5TahucQgzSwR8= =GMzm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: GCC8
On Tue, Jan 9, 2018 at 12:58 PM Adam Williamson wrote: > On Tue, 2018-01-09 at 18:45 +0100, Jakub Jelinek wrote: > > On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote: > > > The timing on this looks a bit awkward when compared with the current > > > schedule, which has the Beta going out in March and Final early in May: > > > > > > https://fedoraproject.org/wiki/Releases/28/Schedule > > > > > > That would appear to mean we'd have to do a mass rebuild with a pre- > > > release GCC, or do a mass rebuild between Beta and Final, or suddenly > > > introduce a new compiler post-Beta, potentially meaning that we need to > > > rebuild something to fix a blocker bug quite late in the release and > > > discover that the new GCC which has suddenly appeared causes problems > > > with building it. None of those sound like great options to me. > > > > Mass rebuild with a prerelease version of the compiler, like every year > at > > least in the past 10 years in Fedora. > > Well, true, but then just like every year, we'll wind up doing a lot of > the spadework of fixing things to build with the new GCC. And probably > at first some critical things will fail to build and that'll mess up > the stability of the distro for a couple of weeks. I guess if everyone > else is still loving that grind, hey. > This is the cost of being "First". Fedora has long enjoyed a tight coupling with the GCC upstream. It's a symbiosis: they use our mass-rebuild to help identify any issues before GCC goes stable and in turn Fedora gets to have the newest compiler features before anyone else. Realistically, since Fedora is the first real-world exercise of new GCC, if we waited for the upstream stable release, it would be exactly as it is now. Fedora would hit all the same issues and GCC would have to release updates to fix them for us. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HUP] [critpath] Upgrade soname version of qrencode in Rawhide
Dear Fedora Devops, qrencode (critpath) package has been updated in rawhide branch. Major change: from: libqrencode.so.3.4.4 to: libqrencode.so.4.0.0 If you need to report any issue: https://bugzilla.redhat.com/show_bug.cgi?id=1510097 Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494 Many packages requires libqrencode (systemd, etc...) so take care about compatibility breakage. best regards, -- GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 x509 C.A.: https://dl.casperlefantom.net/pub/root.pem Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr dependency rebuild with circular dependencies
Thanks Nicolas. That makes sense. Would you advise that the compatibility package remains in rawhide after the mass rebuild? Best, James. On Tue, 2018-01-09 at 20:06 +0100, nicolas.mail...@laposte.net wrote: > Hi, > > Regardless of the build infra, you will need to create a compat > package with the old lib version to make it available during > bootstraping > > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- James Paul Turner Freenode / Fedora: jamesturner246 The Arpra Project: https://github.com/jamesturner246/arpra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Disable a package for Fedora 26
Hi Kevin, thanks for your feedback. On 01/09/2018 11:36 AM, Kevin Kofler wrote: > … if you can't do the backport in a reasonable time frame (This > vulnerability is very critical, since it allows remote money stealing!), the > recommendation is to just upgrade to the latest upstream immediately (i.e., > your first option). E.g., this (just upgrade to the latest version, even if > there are breaking changes) is also how Firefox handles security updates. > > Upgrading vs. backporting is always a tradeoff. Upgrading keeps you closer > to upstream, backporting means fewer unexpected changes for users of stable > releases. There are instances of both in Fedora, depending on what changed > in the new upstream release and/or how hard it is to backport the security > fixes to the old release. I think the best solution, based on my knowledge and available time, is to upgrade Fedora 26 to the latest upstream. The fixes from upstream are spread on several commits and releases. > This (your third option) is the worst possible option. It is better to just > push the new version, which is surely better than nothing (and also better > than doing nothing and letting websites steal the user's money). I agree, this is the most user unfriendly, but better than loosing money. Jonny ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: Avoid /usr/bin/python in RPM build
= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build = https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build Change owner(s): * Petr Viktorin * Miro Hrončok Deprecate, and later disable, running /usr/bin/python (as opposed to /usr/bin/python3 or /usr/bin/python2) during RPM build. Changes will be driven by Python SIG, but a few packages may fail to build (with the failure message providing an easy workaround). == Detailed Description == === Motivation === Currently in Fedora (package names, executable names, etc.), python means Python 2. We would like to change it to mean Python 3, but to do that, we need to free it of the current meaning. This means explicitly using either "python2" or "python3" throughout Fedora. This is a multi-release effort tracked in Python SIG's "Finalizing Fedora Switch to Python3" document. This page describes a very focused subset of it. Renaming packages (and associated changes to, for example, "Requires:" directives) is relatively straightforward, but making all Fedora-provided code avoid /usr/bin/python (as opposed to /usr/bin/python2) is both harder to achieve and harder to keep track of. We would like to start deprecating /usr/bin/python (as opposed to /usr/bin/python2) at RPM build time. RPM build is a controlled environment: changes to it will not be felt by end users, breakages are almost immediately visible, and output of Koji builds can be nicely tracked and analyzed. === Specification === Python 2, when called as python or /usr/bin/python at RPM build time (as identified by the RPM_BUILD_ROOT environment variable), will print a deprecation warning to stderr. (Any program invoked during build that invokes /usr/bin/python will cause this warning as well.) A new Taskotron check will be implemented to look for this warning and fail if it's found. We will look at the Taskotron results and work with packagers to switch to update the affected packages. (We'll look at the results to determine if we'll use automated pull requests, mass bug filing, or something else.) The warning itself may cause some packages to fail to build, for example if a test relies on exact stderr contents. For these cases, it will be possible to turn the warning off using an environment variable, but we ask packagers that use of this workaround is tracked in Bugzilla. See Opt-Out below. After all packages that BuildRequire python2 are re-built with this check passing, python will be switched to fail after printing the message. The warning will not be effective if stderr output is hidden. So, after switching /usr/bin/python to fail, some packages may start failing to build. We will work with the packagers to fix these. (We'll look at results from the "warnings phase" to see how proactive we'll need to be here.) The warning text will be: DEPRECATION WARNING: python2 invoked with /usr/bin/python. Use /usr/bin/python3 or /usr/bin/python2 /usr/bin/python will be removed or switched to Python 3 in the future. If you cannot make the switch now, please follow instructions at https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out (Using the Wiki link allows us to easily revise the instructions.) === Quick Opt-Out === In case switching to /usr/bin/python2 or /usr/bin/python3 is non-trivial, do these two things: * Set the environment variable DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling /usr/bin/python * File a Bugzilla, and make it block our tracking bug (XXX - link) All such bugs will need to be fixed before we make /usr/bin/python fail hard. == Scope == * Proposal owners: Patch python2, write the Taskotron check, deal with warnings and failures. * Other developers: Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM build time (with help from Proposal owners if needed). Also tools that are invoked during build time of other packages that themselves use /usr/bin/python will need to be fixed. * Release engineering: #7257: https://pagure.io/releng/issue/7257 Note: Depending on the timing, separate targeted rebuilds may be needed, but we can do these as Proven Packagers, no side-tags are required * List of deliverables: N/A * Policies and guidelines: Already existing "packages in Fedora ... MUST call the proper executable for the needed python major version directly, either /usr/bin/python2 or /usr/bin/python3 as appropriate" from Packaging:Python#Multiple_Python_Runtimes * 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: Copr dependency rebuild with circular dependencies
Hi, Regardless of the build infra, you will need to create a compat package with the old lib version to make it available during bootstraping Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Can't capture vmcore?
I'm getting kernel panics in a VM that functions as a hypervisor, the moment I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is annoying, of course, so I try to be a good citizen and file a bug. For some reason though, I cannot get the core dumped. I get a core fine with sysrq, but not with this actual panic. I've followed [1] to set up kdump and crash, but everytime I trigger the crash and see my VM reboot, I see an empty /var/crash afterwards. As was able to get the vmcore written to /var/crash on in a RHEL7 guest, I'm starting to suspect a bug, but I'm unsure. Any pointers on how to debug this? [1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Copr dependency rebuild with circular dependencies
Hi all. Apologies for cross-posting, but I am running out of ideas. Suppose one updates libmpfr in a copr repository, which bumps the soname. Both GCC and libmpc depend on libmpfr, and so must be rebuilt, but neither GCC nor libmpc can be rebuilt without an existing libmpc, which, in turn, depends on the old soname version of the recently updated libmpfr. Can somebody please advise the best way to go in cases like these? Is a copr mass rebuild even the right solution for this, or should one really be using a side tag in koji? - though it is unclear to me what difference that will make. Happy to provide more info. All the best, James. -- James Paul Turner Freenode / Fedora: jamesturner246 The Arpra Project: https://github.com/jamesturner246/arpra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
REMINDER: January 2018 Elections: Nomination & Campaign period in progress
This is just a reminder that tomorrow on 2018-Jan-10 at 23:59:59 UTC we will close the Nomination window of January 2018 Elections. Please check the nomination pages [1][2][3] and apply, if you are interested to work in FESCo, Council or Mindshare teams. [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] https://fedoraproject.org/wiki/Council/Nominations [3] https://fedoraproject.org/wiki/Mindshare/Nominations Regards, Jan On Wed, Jan 3, 2018 at 9:16 AM, Brian Exelbierd wrote: > Today we are starting the Nomination & Campaign period during which > we accept nominations to the "steering bodies" of the following teams: > > * FESCo (Engineering) (5 seats) [1] > * Fedora Council (2 seats) [2] > * Mindshare (2 seats) [3] > > This period is open until 2018-Jan-10 at 23:59:59 UTC. > > The nominees can already start preparing their answers for > questions in the Election Questionnaire. The questions can > be found in the template files[4], however this election > features a new way to submit questionnaires. > > Nominees submit their questionnaire answers via a private > Pagure issue[5]. The Election Wrangler or their backup will > publish the interviews to the Community Blog [6] on the > first day of the Voting period (2018-Jan-17). > > Please note that the interview is mandatory for all nominees. > Nominees not having their interview ready by end of the > Interview period (2018-Jan-15) will be disqualified and removed > from the election. Nominees may submit their interview answers > immediately and may edit them until the end of the interview period. > > Nominees are encouraged to begin their interview answers as > soon as they accept their nomination. > > The full schedule of the January 2018 Elections is available on the > Elections wiki page [8]. > > [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > [2] https://fedoraproject.org/wiki/Council/Nominations > [3] https://fedoraproject.org/wiki/Mindshare/Nominations > [4] > https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-January > [5] https://pagure.io/fedora-project-schedule/issues > [6] http://communityblog.fedoraproject.org/ > [8] https://fedoraproject.org/wiki/Elections > > regards, > > bex > -- > Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com > Fedora Community Action & Impact Coordinator > Backup Election Wrangler > @bexelbie | http://www.winglemeyer.org > ___ > ambassadors mailing list -- ambassad...@lists.fedoraproject.org > To unsubscribe send an email to ambassadors-le...@lists.fedoraproject.org -- 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: F28 System Wide Change: Binutils version 2.29.1
On 09/01/18 16:16 +0100, Tomasz Torcz 👁️ wrote: > On Tue, Jan 09, 2018 at 12:11:31PM +0100, Jan Kurik wrote: >> = System Wide Change: Binutils version 2.29.1 = >> https://fedoraproject.org/wiki/Changes/BINUTILS2291 >> >> Change owner(s): >> * Nick Clifton >> >> Rebase the binutils package from version 2.29 to version 2.29.1. This >> will bring in the bug-fixes from the 2.29.1 point release, but not add >> any new features. >> > >> Change the source parameter in the binutils.spec rpm and adjust the >> local patches to take account of the bugs that are now already fixed. > > I'm a bit perplexed by this change. It looks like minor version > update, in such case it need no to be announced so widely. > On the other hand, you are changing the source. According to the > guidelines, changing source requires re-review. > So why this is a system-wide change? I think I have something to add here as if no other package, libqb was quite affected with the former change of binutils 2.28 -> 2.29 coming to Fedora 27: https://bugzilla.redhat.com/show_bug.cgi?id=1478089 + binutils bug: https://bugzilla.redhat.com/show_bug.cgi?id=1477354 (TL;DR eventually, libqb adopted measures to overcome changed visibility of some symbols, binutils didn't go back in its behaviour) In parallel, there was a separate discussion directly with upstream: https://lists.gnu.org/archive/html/bug-binutils/2017-08/msg00195.html which resulted in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f399679112df997c1416f7993eaac0f5fd76c144 that is part of 2.29.1 and which actually forced an existing prototype of the libqb fix to be refined once more because, suddenly, some new configure-time checks were to loose to detect the necessity to apply said measures (while they were working fine with 2.29 alone). So I can attest this change has a merit (compare with unannounced 2.29 change that hit libqb hard), even though it's not expected the number of packages relying on some rather obscure linker features (that are hence not under constant coverage) will be notable. But keep in mind that a single broken package can spoil some other, dependent packages, as was the case with libqb. Thanks for playing it considerately now, Nick. -- Jan (Poki) pgpQVdHIQl60o.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild & system wide changes)
Greetings! Today, on 2018-Jan-09, we have reached Fedora 28 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild & system wide changes) [1]. At this point, only Self Contained Changes will be accepted for Fedora 28. Any Change Proposal requiring mass rebuild or a System wide Change should be scheduled for a later Fedora release. Self Contained Changes are still accepted until 2018-Jan-30, as published in the F28 schedule [1]. On 2018-Feb-20 is planned "Change Checkpoint Completion deadline (testable)" where all Changes should be implemented and testable. [1] https://fedoraproject.org/wiki/Releases/28/Schedule Regards, Jan -- 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: Security updates and batched pushes
On 01/08/2018 10:53 AM, Kevin Kofler wrote: > Kevin Fenzi wrote: >> Well, if this firefox update was urgent, shouldn't it have been marked >> urgent? > > Urgency is always in the eye of the beholder. I as a user consider all > security updates "urgent", and in addition, I want ALL updates as soon as > they passed testing no matter whether they actually are urgent. You also don't want updates-testing to even exist right? > >>> I really don't understand why we do this "batched" thing to begin with. >> >> To reduce the constant flow of updates that are very minor or affect >> very few mixed in with the major updates that affect lots of people and >> are urgent. > > But the users were already able to opt to update only weekly. So why force a > fixed schedule on them? To save all the Fedora users in the world from having to update metadata for minor changes. Since there's a hourly dnf makecache every user in the world pulls down new metadata ever time we update a repo. If we update a repo for some minor enhancements it means everyone in the world has to pay for that. If we just push all those out every tuesday and don't update those unless there's something urgent we save everyone a lot of bandwith and us computing time/resources. >> To save users downloads of repodata. > > This does not work in practice because there is almost always at least one > urgent update that requires downloading the whole repodata. (And also > because maintainers are free to skip batched without giving a reason. I > always do this because I consider batching a disservice to my users.) There are definitely more days when there are no updates for a particular repo now. Of course there would be even more if you (or those who do likewise) wouldn't skip batched, but probibly we need to explain why more clearly. ...snip... >> I would be very much against additional repos like this. > > Why? It would allow you to keep the server-side batching while still > allowing those users like me to opt out of it. And the repodata download > size for fast track would be minimal if updates that went out to stable get > removed from fast track. because it would be a ton more infrastructure and resources. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: NIS switching to new libnsl to support IPv6
= System Wide Change: NIS switching to new libnsl to support IPv6 = https://fedoraproject.org/wiki/Changes/NISIPv6 Change owner(s): * Matej Muzila * Honza Horak This system-wide change covers the switch of NIS components to the new client side implementation in order to support IPv6, while detaching libnsl and nss_nis packages, previously bundled together with glibc. == Detailed Description == glibc bundles the client part of NIS, while this implementation is not compatible with IPv6, due to the way addresses are represented. NIS upstream added NIS support for the server and client tools, but for being able to use this feature, the libnsl and nss_nis needs to be rebased to the new version. Since NIS has been part of glibc for long time and it doesn't seem to be necessary (especially given the NIS is an obsoleted technology for years), it is better to detach those two packages and deliver them as a separate library. This change is also related to Sun RPC Removal Change [https://fedoraproject.org/wiki/Changes/SunRPCRemoval]. == Scope == * Proposal owners: Provide the NIS client implementation as separate packages, and adjust the glibc packaging to remove the nss_nis subpackage, the NIS header files, and move libnsl to a new subpackage. * Other developers: Packages which used to depend on the libnsl library from glibc will need to add BuildRequires: libnsl2-devel. * Release engineering: #7256: https://pagure.io/releng/issue/7256 * List of deliverables: N/A * Policies and guidelines: N/A (not needed for this Change; covered by the existing Packaging Guidelines) * 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: F28 System Wide Change: GCC8
On Tue, 2018-01-09 at 18:45 +0100, Jakub Jelinek wrote: > On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote: > > The timing on this looks a bit awkward when compared with the current > > schedule, which has the Beta going out in March and Final early in May: > > > > https://fedoraproject.org/wiki/Releases/28/Schedule > > > > That would appear to mean we'd have to do a mass rebuild with a pre- > > release GCC, or do a mass rebuild between Beta and Final, or suddenly > > introduce a new compiler post-Beta, potentially meaning that we need to > > rebuild something to fix a blocker bug quite late in the release and > > discover that the new GCC which has suddenly appeared causes problems > > with building it. None of those sound like great options to me. > > Mass rebuild with a prerelease version of the compiler, like every year at > least in the past 10 years in Fedora. Well, true, but then just like every year, we'll wind up doing a lot of the spadework of fixing things to build with the new GCC. And probably at first some critical things will fail to build and that'll mess up the stability of the distro for a couple of weeks. I guess if everyone else is still loving that grind, hey. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
On Tue, 2018-01-09 at 11:28 -0500, Matthew Miller wrote: > On Tue, Jan 09, 2018 at 05:17:40PM +0100, Martin Kolman wrote: > > As mentioned by jkonecny, we have updated the change page, including > > the contingency plan. > > Thanks -- that's much more clear. And I see the deadline has been moved > back to a week before Final Freeze. Sounds good to me assuming QA feels > comfortable with this. It sounds fairly workable to me, yeah. I can foresee perhaps we're not successful in keeping the fallback branch 100% up to the criteria, but at least it should be fairly close and only cause a short delay to bring things up to scratch if we have to use it. Thanks to Martin and the team for adjusting the proposal. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Change owner(s): * Björn Esser * Florian Weimer There are plans to remove libcrypt from glibc, so we should have a replacement. == Detailed Description == Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement. It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra. The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt. == Scope == * Proposal owners: - Apply needed packaging changes to glibc - Review, import and build libxcrypt for Fedora 28 * Other developers: Test their applications using one of the following interfaces for unexpected changes in functionality: - crypt() - crypt_r() - encrypt() - encrypt_r() - fcrypt() - setkey() - setkey_r() Release engineering: #7160 https://pagure.io/releng/issue/7160 none expected * Policies and guidelines: N/A (not needed for this 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: F28 System Wide Change: GCC8
On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote: > The timing on this looks a bit awkward when compared with the current > schedule, which has the Beta going out in March and Final early in May: > > https://fedoraproject.org/wiki/Releases/28/Schedule > > That would appear to mean we'd have to do a mass rebuild with a pre- > release GCC, or do a mass rebuild between Beta and Final, or suddenly > introduce a new compiler post-Beta, potentially meaning that we need to > rebuild something to fix a blocker bug quite late in the release and > discover that the new GCC which has suddenly appeared causes problems > with building it. None of those sound like great options to me. Mass rebuild with a prerelease version of the compiler, like every year at least in the past 10 years in Fedora. > Is there significant enough benefit from the new GCC to outweigh all > these potential negative impacts to it going stable between our Beta > and Final releases? Yes. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
On Tue, 2018-01-09 at 11:13 +, Richard W.M. Jones wrote: > On Mon, Jan 08, 2018 at 12:59:20PM -0500, Martin Langhoff wrote: > > I have two VMs, or OS states I can `rpm -qa` on. Is there a script to > > diff the output of the two listings, and then query the package > > changelogs to generate an overall OS-wide changelog? > > > > Use case: I generated an F26 OVA image using imagefactory 30 days ago, > > then I generated a new F26 image today. I'd export rpm -qa listings > > from both, and then get a changelog showing all the package updates, > > expecting to see the kernel package with the recent CVEs fixed. > > > > Does such a tool exist? > > virt-inspector can show the differences in packages installed > between two VMs (run it once on each VM and diff the output). > > For more sophisticating diffing, use virt-diff: > > http://libguestfs.org/virt-diff.1.html I think the interesting part of the request is the combination of *first* getting the information on what package NEVRs differ between the two, *then* generating a selective changelog from that list (i.e. if you know one instance has foo-2.0-1 and the other has foo-2.1-3, including only the changes between foo-2.0-1 and foo-2.1-3 in the changelog). I can think of lots of ways to do the first and there are probably lots of existing implementations of it, but doing the second is rather less common AFAIK. The closest existing tool to this that I can think of is the one used to generate the daily compose reports, which is the `compose-changelog` tool in this repo: https://pagure.io/compose-utils that may be of interest to the original poster. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: GCC8
On Tue, 2018-01-09 at 12:11 +0100, Jan Kurik wrote: > = System Wide Change: GCC8 = > https://fedoraproject.org/wiki/Changes/GCC8 > > Change owner(s): > * Jakub Jelínek > > Switch GCC in Fedora 28 to 8.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 29. > > > == Detailed Description == > GCC 8 is currently in stage3, will move to stage4 on January 14th, in > prerelease state with only regression bugfixes and documentation fixes > allowed. The release will happen probably in the middle of April. We > are working on scratch gcc rpms and will perform a test mass rebuild. The timing on this looks a bit awkward when compared with the current schedule, which has the Beta going out in March and Final early in May: https://fedoraproject.org/wiki/Releases/28/Schedule That would appear to mean we'd have to do a mass rebuild with a pre- release GCC, or do a mass rebuild between Beta and Final, or suddenly introduce a new compiler post-Beta, potentially meaning that we need to rebuild something to fix a blocker bug quite late in the release and discover that the new GCC which has suddenly appeared causes problems with building it. None of those sound like great options to me. Is there significant enough benefit from the new GCC to outweigh all these potential negative impacts to it going stable between our Beta and Final releases? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On Mon, 2018-01-08 at 12:21 -0500, Steve Dickson wrote: > Hello, > > Is it a problem for a package to pull from two different > upstream tar balls? Basically have > > Source0: http://server.com/package1/package1.tar > Source1: http://server.com/package2/package2.tar > > Then I would, by hand, untar Source1 into Source0 directory. Just to state something explicitly that others have mentioned in passing: you do not have to do this by hand, RPM provides extensive support for this kind of scenario. Maximum RPM is still the best doc I know of for this kind of stuff: http://ftp.rpm.org/max-rpm/s1-rpm-specref-macros.html Specifically, you'll want to look at -b and -a, and the examples of how each is used. As others have said, this isn't *necessarily* "a problem" and there are several cases of existing packages that do it, but without further details, no-one can give you an informed opinion on whether it makes sense to do things this way in your specific case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide
On 01/09/2018 05:53 PM, Sérgio Basto wrote: > Packages remaining to rebuild: > digikam > fawkes > kf5-libkface > nomacs > player > simon > > Provenpackager request for: > Do fedpkg build in fawkes master [3] > [3] > https://src.fedoraproject.org/rpms/fawkes/commits/master > That won't help because fawkes ist still FTBFS after the last protobuf bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093 Regards, Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote: > Dear all, > > The Fedora Infrastructure team has had a jenkins instance running at > jenkins.fedorainfracloud.org for a little while now. This instance was > maintained on a best-effort basis though and we often had outage and issues > when > upgrading it. > Originally the jenkins master was running on RHEL using the RPMs provided by > upstream jenkins. When jenkins became available in Fedora, we switched our > master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins is > no > longer packaged for Fedora, our jenkins master is therefore outdated. > > On the other side of the fence, with our dear friends from CentOS, is a brand > new, shiny and well supported Jenkins instance. > So we thought it may be good to leverage the CentOS infrastructure to > alleviate > our infrastructure and maintenance. > > We are currently working on setting up a Jenkins master in ci.centos.org that > would be dedicated to projects ran in pagure.io. > It needs a small change to pagure.io and some work on the CentOS side but > nothing hard and we expect to be able to migrate the first volunteer projects > by > early next week. > > Once the first migrations have happened and the first rough edges have been > smoothed we will be announcing an official retirement date for > jenkins.fedorainfracloud.org and migrate all the projects hosted there to > ci.centos.org, and of course help with the potential questions raising from > this. Will there be a standard / automated migration path for projects that have followed documented steps to implement a CI workflow through this Jenkins instance, like these: https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html ? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide
Packages remaining to rebuild:
digikam
fawkes
kf5-libkface
nomacs
player
simon
Provenpackager request for:
Merge and fedpkg build [1] and [2] in master branch.
Do fedpkg build in fawkes master [3]
[1]
https://src.fedoraproject.org/rpms/nomacs/pull-request/1
[2]
https://src.fedoraproject.org/rpms/simon/pull-request/1
[3]
https://src.fedoraproject.org/rpms/fawkes/commits/master
Best regards,
On Sun, 2017-12-31 at 19:56 +, Sérgio Basto wrote:
> On Sat, 2017-12-23 at 15:23 +, Sérgio Basto wrote:
> > Hello.
> > I'm going submit opencv 3.1 in rawhide to fix a lots of CVE(s) [1]
> > and
> > new feature also have a new module with compatibly with mlt
> > TBH I though/expect someone from RedHat take care of it .
> >
> > I will send more new after the submit about broken deps and proven
> > packages required
> >
> > dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
> > opencv\* --alldeps --qf "%{sourcerpm} %{repoid}"
> >
> > OpenImageIO-1.7.17-2.fc28.src.rpm rawhide
> > YafaRay-3.3.0-3.fc28.src.rpm rawhide
> > digikam-5.7.0-3.fc28.src.rpm rawhide
> > fawkes-1.0.1-13.fc28.src.rpm rawhide
> > frei0r-plugins-1.6.1-2.fc27.src.rpm rawhide
> > gmic-1.7.2-5.fc27.src.rpm rawhide
> > libfreenect-0.5.5-2.fc27.src.rpm rawhide
> > mlt-6.5.0-0.6.20171114git73bfefd.fc28.src.rpm rawhide
> > mrpt-1.4.0-5.fc28.src.rpm rawhide
> > nomacs-3.6.1-5.fc28.src.rpm rawhide
> > opencv-3.2.0-13.fc28.src.rpm rawhide
> > os-autoinst-4.5-1.20171220git25191d5.fc28.src.rpm rawhide
> > php-facedetect-1.1.0-9.fc28.src.rpm rawhide
> > player-3.1.0-4.fc27.src.rpm rawhide
> > shogun-6.0.0-5.fc27.src.rpm rawhide
> > simarrange-0.0-12.20170309git3300eb5.fc27.src.rpm rawhide
> > simon-0.4.1-11.fc27.src.rpm rawhide
> > siril-0.9.7-1.fc28.src.rpm rawhide
> >
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=1484397
> >
>
> A new repoquery [1], the previous one just work when we don't have
> brokendeps (I think) , brokendeps calculated with script in attach :
>
> digikam
> fawkes
> frei0r-plugins
> gmic
> kf5-libkface
> libfreenect
> mlt
> mrpt
> nomacs
> OpenImageIO
> os-autoinst
> php-facedetect
> player
> simarrange
> simon
> siril
> YafaRay
>
>
> Packages remaining to rebuild:
>
> digikam
> fawkes
> gmic
> kf5-libkface
> nomacs
> OpenImageIO
> os-autoinst
> player
> simon
>
> [1]
> dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
> "libopencv*" --alldeps --srpm --quiet | sed 's|\(-[^-
> ]\+\)\{2\}.src||'
> > sort -u
>
> Happy new year
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
On Tue, Jan 09, 2018 at 05:17:40PM +0100, Martin Kolman wrote: > As mentioned by jkonecny, we have updated the change page, including > the contingency plan. Thanks -- that's much more clear. And I see the deadline has been moved back to a week before Final Freeze. Sounds good to me assuming QA feels comfortable with this. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
On Mon, 2018-01-08 at 09:01 -0500, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote: > > Yep - basically, there will be no "old" and "new, DBUS/modular" > > Anaconda, the plan is to turn the current Anaconda to the new one one > > step at a time. > > > > This should allow us to fix bugs as usual and handle any unforeseen > > modularization issues early on one-by-one as they show up. > > It sounds like there actually isn't a contingency plan as such. Do you > think that this could all be reverted on Final Freeze day if we would > decide it's not working out? If not, let's not call that a contingency. > > I'm not saying we shouldn't do this, but let's be honest with > ourselves. If the contingency plan is "None: we'll have to hold up the > release for fixes if it's not ready", the Change plan should say that. As mentioned by jkonecny, we have updated the change page, including the contingency plan. The idea is that we will kreate a fallback branch just before we enable the first modularization changes and keep the fallback branch functional by backporting critical fixes and blockers. The master branch (and after branching the f28-branch) will host the incremental modularization work and will be used for Rawhide/F28 Anaconda builds. If everything works fine, the fallback branch will not be needed and will be discontinued after F28 GA. If we need to activate the contingency plan, we will switch F28 Anaconda builds to the fallback branch, effectively falling back to the non-modularized code for the F28 timeframe. > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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
Claiming a retired package: gcin
Hi, Based on the claiming guideline[1], I am writing to claim the package gcin. The package gcin was retired because previous maintainer cicku was not responsive at that time[2]. Since I hear this package is still useful for some users, I updated the spec file and filed a review request here[3]. Thanks. [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4LK26PNK22QTNVSZ26KWIFA5G4SXUHWC/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1532696 -- Ziqian SUN (Zamir) GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability
On Tue, Jan 09, 2018 at 08:44:50AM -0600, Justin Forbes wrote: > > Does this mean we should do a mass rebuild once those patches have > > landed? We have a mass rebuild scheduled for Jan 31st (basically three > > weeks from now). Is that too soon? > I do not have an answer to this just yet. I mean theoretically yes, > retpoline goes into GCC, packages are changed to use the features, and > a mass rebuild happens. More likely retpoline goes into gcc, and a > subset of important packages are rebuilt to utilize it. As for timing, > no clue. When I asked Jakub about retpoline for Fedora gcc, he said > the patches hadn't even been posted to the gcc list for review yet. > That has now happened, but I haven't been following the review on that > end yet. I am hoping to get some more answers on retpoline over the > next couple of days. Thanks. I hate to say this, because I really value predictable releases, but we should at least put delaying the mass rebuild for this into consideration, depending on what the GCC and security teams say. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Enabling smoother upgrades in the face of multilib compose changes
On 01/09/2018 03:16 PM, Igor Gnatenko wrote: So after all I would file bug against DNF to automatically mark all packages from non-primary arch (given they are non-noarch) as allowuinstall. I don't really understand what you wrote. I doubt there is an automated solution without packaging changes because DNF does not know that both glibc-headers are equivalent, so both could have been installed deliberately, and removing one automatically would be wrong. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On 01/09/2018 03:32 PM, Steve Dickson wrote: On 01/09/2018 06:10 AM, Richard W.M. Jones wrote: https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 says: "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel to their spec files." but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. Nor will it... There is going to be a new package call rpcsvc-proto that will contain the rpcgen command along with other things like header files... There is the upstream git tree: http://github.com/thkukuk/rpcsvc-proto Here is the Review Request for the package, if interested. https://bugzilla.redhat.com/show_bug.cgi?id=1532364 Note that the plan is that the new package will provide rpcgen, so you can just use BuildRequires: rpcgen and you'll get the new package once it becomes available. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote: = System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault Does this change do anything to reduce the number of files in /etc that do not contain local configuration? PAM is currently one of the worst offenders, with /etc/pam.d full of "configuration" files. No. The files must stay since it would require changes in pam itself and that is out of scope of authselect. Each file corresponds to individual pam service and is read when pam_start(service_name, ...) is called. Elsewhere in the thread /usr/share/authselect/custom is metioned as directory for admin config. That's OK-ish, as long as you also allow a directory in /etc for the same purpose. /usr must be allowed to be immutable. Would /usr/local be OK as well? Zbyszek ___ 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: F28 Self Contained Change: Anaconda modularization
Hi all, Based on the feedback we modified the change: * There is a more formal contingency plan in place. * Contingency deadline is moved one week earlier. * Detailed description contains explanation of what we want to achieve for F28. We don't aim to have everything in F28. * It is System Wide Change now. Thank you all for your feedback, Jirka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Binutils version 2.29.1
On Tue, Jan 09, 2018 at 12:11:31PM +0100, Jan Kurik wrote: > = System Wide Change: Binutils version 2.29.1 = > https://fedoraproject.org/wiki/Changes/BINUTILS2291 > > Change owner(s): > * Nick Clifton > > Rebase the binutils package from version 2.29 to version 2.29.1. This > will bring in the bug-fixes from the 2.29.1 point release, but not add > any new features. > > Change the source parameter in the binutils.spec rpm and adjust the > local patches to take account of the bugs that are now already fixed. I'm a bit perplexed by this change. It looks like minor version update, in such case it need no to be announced so widely. On the other hand, you are changing the source. According to the guidelines, changing source requires re-review. So why this is a system-wide change? -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability
On Mon, Jan 8, 2018 at 7:27 PM, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 04:49:44PM -0600, Justin Forbes wrote: >> combination of the 2. Unfortunately both have external requirements. >> Retpoline requires GCC patches, and microcode updates for some CPUs. >> IBRS requires microcode updates. While RHEL has done quite a bit of > > Does this mean we should do a mass rebuild once those patches have > landed? We have a mass rebuild scheduled for Jan 31st (basically three > weeks from now). Is that too soon? > I do not have an answer to this just yet. I mean theoretically yes, retpoline goes into GCC, packages are changed to use the features, and a mass rebuild happens. More likely retpoline goes into gcc, and a subset of important packages are rebuilt to utilize it. As for timing, no clue. When I asked Jakub about retpoline for Fedora gcc, he said the patches hadn't even been posted to the gcc list for review yet. That has now happened, but I haven't been following the review on that end yet. I am hoping to get some more answers on retpoline over the next couple of days. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On 01/09/2018 06:10 AM, Richard W.M. Jones wrote: > > https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 > says: > > "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel > to their spec files." > > but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. Nor will it... There is going to be a new package call rpcsvc-proto that will contain the rpcgen command along with other things like header files... There is the upstream git tree: http://github.com/thkukuk/rpcsvc-proto Here is the Review Request for the package, if interested. https://bugzilla.redhat.com/show_bug.cgi?id=1532364 steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Enabling smoother upgrades in the face of multilib compose changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-01-09 at 15:05 +0100, Florian Weimer wrote: > On 01/09/2018 03:01 PM, Igor Gnatenko wrote: > > Well, from my user perspective I think they are supported "as long as it > > works". The multilib generation is very hacky/tricky. > > > > I would open a ticket for releng to fix such issues. > > I don't think there is anything wrong with the composes. It is not > necessary to install glibc-headers.i686 and glibc-headers.x86_64 in > parallel. It's just that those who have done so in the past are now > stuck with the i686 package. This is easy to play with.. repo system 0 testtags #>=Pkg: foo 1 1 i686 #>=Pkg: foo 1 1 x86_64 #>=Pkg: wine 1 1 x86_64 #>=Req: foo repo available 0 testtags #>=Pkg: foo 2 1 x86_64 system x86_64 rpm system poolflags implicitobsoleteusescolors solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes job update all packages [forcebest] result transaction,problems #>problem f47534b4 info cannot install both foo-2-1.x86_64 and foo-1-1.x86_64 #>problem f47534b4 solution 0fb8e991 allow foo-1-1.i686@system #>problem f47534b4 solution 14ee0c1c allow foo-1-1.x86_64@system #>problem f47534b4 solution 4d28f814 erase foo-1-1.i686@system #>upgrade foo-1-1.x86_64@system foo-2-1.x86_64@available nextjob job update all packages [forcebest] job allowuninstall pkg foo-1-1.i686@system result transaction,problems #>erase foo-1-1.i686@system #>upgrade foo-1-1.x86_64@system foo-2-1.x86_64@available So after all I would file bug against DNF to automatically mark all packages from non-primary arch (given they are non-noarch) as allowuinstall. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpUzr0ACgkQaVcUvRu8 X0yt8w/9GrJ0nbo1/UUZb2o/7ekFltni7i26qq7YvWM2WkAz1xsrtVVpti2rz8Ee pX/LeNn4vyrwts4S5v+z3KtOsfhDQWzCwTwa76sSqB+Hket4MrrcD64ILJvCQ4cx dNZ4qOQglFZJ69Jz1f9NbcBnMp5/98YohkoavWP+f17MofIXBEP0vS5SwD/OPGpa /CL+C2L6tWjtY+b3z5+zzwQNDFsRaYMOtVRq/0Xy/wWSFSqp/c+t7ZsWylQplO4v N7ALCTpO3kx3XnTWc1BIiHN4HlvwB8O3/u2xDFMSv7ltP76e5W0Tq30xqg1ITPlg cHQ/rT/BMQizYFGLk+GyXcWJ2l3JdRoGDdeiCdBS1lAYU20xW/AqS3RXg3mhjSiM AniyT2yusTf4C8v0FbdukOOtaXVCOssX/mVD96bTijUmAt7ThsPHxMHp+sl+KGzZ lEiLNFDSY4a8UlBlAPLDwvw0j0F7uw6lfHLO1tz0fOYq73wjMAlGtXceDC1T/Z01 MV4eWqpWtF/egc/FvAnJkJACzF6ocn+NzbEzoho/DeER8s7+H/NVoPN6r4YZyro/ j7IIpiVIF0ruWVjoPNhMqmHRs1ziN2wfDGEw4ZHWQq3817EPVbhW8Bna6CdTBMB/ 1xPYVBwBa7SOOMUCIVDNX9/t9PFI/LjvC9H/k8452XCwsYzdKNU= =JP+8 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
- Original Message - > From: "Florian Weimer" > To: "Development discussions related to Fedora" > , "Charalampos Stratakis" > > Sent: Tuesday, January 9, 2018 12:30:39 PM > Subject: Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc > > On 01/09/2018 11:32 AM, Charalampos Stratakis wrote: > > Python is currently being addressed upstream [0] and the fix will be > > backported soon to fedora's packages. > > > > [0]https://github.com/python/cpython/pull/5137 > > Has this been tested on OpenSUSE or Gentoo (I think either has already > fully made the transition)? > > I'm asking we still have some NIS bits sticking around, and we need to > remove° them as well for the transition to an IPv6-capable NIS. > > ° As usual, we'll keep support existing binaries. > > Thanks, > Florian > It seems that there was a previous bug report about the same issue for gentoo [0][1]. Python doesn't actually fail to build, it's that it utilizes those headers to build a specific module (which is not really used nowadays). And upstream is in favor of deprecating the module that requires those headers. [0] https://bugs.python.org/issue32007 [1] https://bugs.gentoo.org/631488 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Enabling smoother upgrades in the face of multilib compose changes
On 01/09/2018 03:01 PM, Igor Gnatenko wrote: Well, from my user perspective I think they are supported "as long as it works". The multilib generation is very hacky/tricky. I would open a ticket for releng to fix such issues. I don't think there is anything wrong with the composes. It is not necessary to install glibc-headers.i686 and glibc-headers.x86_64 in parallel. It's just that those who have done so in the past are now stuck with the i686 package. This is not releng issue #4048, it's different. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: OpenLDAP defaults to use only Shared System Certificates
= System Wide Change: OpenLDAP defaults to use only Shared System Certificates = https://fedoraproject.org/wiki/Changes/OpenLDAPdefaultSharedSystemCertificates Change owner(s): * Matus Honek In order to go forward with adoption of SharedSystemCertificates [1] after this change OpenLDAP clients and server will default to use only the system-wide certificates store. == Detailed Description == Currently, OpenLDAP defaults to trust CA certificates located in /etc/openldap/certs. In order to comply with SharedSystemCertificates [1] we will remove the default explicit configuration options that point to /etc/openldap/certs. Therefore, OpenLDAP will let its crypto library (OpenSSL) load the default CA certificates as described in the SharedSystemCertificates [1] description. For a convenience, where possible, configuration files will contain a commentary with an explanation of the new behaviour. == Scope == * Proposal owners: change of default shipped configuration. * Other developers: check your application trusts whom you want it to trust * Release engineering: https://pagure.io/releng/issue/7252 * List of deliverables: N/A * Policies and guidelines: None. * Trademark approval: None. (not needed for this Change). [1] https://fedoraproject.org/wiki/Features/SharedSystemCertificates -- 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
F28 System Wide Change: OpenLDAP without Non-threaded Libraries
= System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries Change owner(s): * Matus Honek OpenLDAP will not ship non-threaded versions of its libraries. Instead, it will link these to their threaded counterparts. == Detailed Description == After this change the non-threaded versions of OpenLDAP libraries will not be shipped any more. Instead, these file will rather symlink to their threaded representatives (i.e. libldap -> libldap_r, etc.). This has been previously discussed in [Bugzilla] and other distributions where this change already happened. Upstream still supports non-threaded versions of their libraries as these might be used on processors where threads are not supported. However, when these two versions happen to be loaded at the same time (as discussed about Curl in the Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065]) symbol names overlap which may result in unpredictable behaviour. As the most convenient solution arises the one proposed hereby. == Scope == * Proposal owners: update SPEC file so that some files are not shipped and replaced with appropriate symlinks. * Other developers: None. Issues should not occur. * Release engineering: https://pagure.io/releng/issue/7253 * List of deliverables: N/A * Policies and guidelines: None. * Trademark approval: (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
F28 System Wide Change: IBus Unicode Typing
= System Wide Change: IBus Unicode Typing = https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing Change owner(s): * Takao Fujiwara IBus core provides an Emoji dialog which users can type emoji annotations and output the emoji character using IBus (E.g. Typing "football" shows U+26BD). The proposal is the dialog also supports to type Unicode names (E.g. Typing "copyright sign" shows U+00A9). == Detailed Description == IBus core provides an Emoji dialog and it can be launched with Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji` command is available for GNOME desktop [1]. Users can select an emoji in emoji lists on the emoji dialog or type an emoji annotation in an input entry on the emoji dialog and output the selected emoji using IBus. The proposal is that emoji dialog also supports to type Unicode names in the input entry and output the selected Unicode character. E.g. Typing "copyright sign" shows U+00A9 [1] because gnome-shell has its owned keyboard indicator instead of /usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji dialog and the emoji implementation is under the consideration in GNOME. == Scope == * Proposal owners: IBus core will include the dictionary of Unicode names * Other developers: N/A * Release engineering: https://pagure.io/releng/issue/7255 * List of deliverables: N/A * Policies and guidelines: N/A * Trademark approval: N/A -- 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
F28 System Wide Change: Fedora 28 Boost 1.66 upgrade
= System Wide Change: Fedora 28 Boost 1.66 upgrade = https://fedoraproject.org/wiki/Changes/F28Boost166 Change owner(s): * Jonathan Wakely This change brings Boost 1.66.0 to Fedora 28. This will mean F28 ships with a recent upstream Boost release. == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is one of explicit Boost non-goals, this entails rebuilding of all dependent packages. This has also always entailed yours truly assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. Such care is to be expected this time around as well. The equivalent changes for previous releases were Fedora 22 Change and Fedora 23 Change and Fedora 24 Change and Fedora 26 Change and Fedora 27 Change. == Scope == * Proposal owners: - Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) - Request a "f28-boost" build system tag (discussion): https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost - Build boost into that tag (take a look at the build #606493 for inspiration) - Post a request for rebuilds to fedora-devel - Work on rebuilding dependent packages in the tag. - When most is done, re-tag all the packages to rawhide - Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Release engineering: #7254 https://pagure.io/releng/issue/7254 * List of deliverables: All deliverables will include updated Boost packages * Policies and guidelines: Apart from scope, this is business as usual, so no policies, no guidelines. * 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: Enabling smoother upgrades in the face of multilib compose changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-01-09 at 13:06 +0100, Florian Weimer wrote: > Changes in the Fedora releng dropped glibc-headers.i686 from the x86_64 > compose after the Fedora 26 release. This is not in itself a problem > (glibc-devel.i686 is fine if its dependency is matched by > glibc-headers.x86_64). However, I have received a report that an > installed glibc-headers.i686 package prevents upgrades to newer glibc > versions. This might be true because dnf doesn't allow erasing of packages unless -- allowerasing is passed. > Are cross-architecture Obsoletes: supported in any way? Is there a > recommended way to deal with this situation? Well, from my user perspective I think they are supported "as long as it works". The multilib generation is very hacky/tricky. I would open a ticket for releng to fix such issues. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpUyzQACgkQaVcUvRu8 X0x/7Q//UbjNfPPuEn5Q3yIpkh8jS8udOXF7qermUcvJ8+DHLG45yj2/81Snv8k4 zrXmtPGRGcQo+oGN5dz8DojjnF5oTGwseFoT9ZIrHRoJEdtNAJMWuBgrQyx/DlkY 8F1GFt8ZHm72TiYAzUlLzAn2A6W62RSmWKNyKYheoFIwIbgRstJm8KNwxDmnuORP sf+PMM91hqep3nIiYE/rbXBtviZjIwSKRNDrJ6ZvE908hdCHJS99fMVp1Iq0P77j orcCrgVfJg19rfS8trA0OO5hMNwi66SQRNKwSUAHjdeZTFq/cduXzgu0Z1nrG2j6 tY3kc6645dINFyzNyoYDRah+GEBpmkWQsBoww3LQm3k0Y9+mVfeRhc+mw3xoo5W/ nBpTsG9f+2KbDX1EWCmv9KLbvMAmnu5TOMTD/oH839N3HI83WH3BF2dl5B1qC3+p 85ri4jVbd1P3mWUCnoljnWkGeq84bphTgioidB4Hl+EXkOvVmfr+X7ECXomWgNDt s6NMUR9pmMWk4Z5LQA+gcd5TXiXITjh1W1wvxA1czbhXj8LKep9BTHwtb7Z8vyeJ 1CC0xfwrILnzYjz3QGhUhFxwDYr5yXa+NYszQrEcJECsVz+lxuKixNEk1bnCCsbz f+8+s+GoIA4/OeUqv77p4jlX4Vhg3uYYi39wqE7AB7C+AD2iAxo= =iqJf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Enabling smoother upgrades in the face of multilib compose changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 2018-01-09 at 14:12 +0100, Björn 'besser82' Esser wrote:
> Am Dienstag, den 09.01.2018, 13:06 +0100 schrieb Florian Weimer:
> > Changes in the Fedora releng dropped glibc-headers.i686 from the
> > x86_64
> > compose after the Fedora 26 release. This is not in itself a
> > problem
> > (glibc-devel.i686 is fine if its dependency is matched by
> > glibc-headers.x86_64). However, I have received a report that an
> > installed glibc-headers.i686 package prevents upgrades to newer
> > glibc
> > versions.
> >
> > Are cross-architecture Obsoletes: supported in any way? Is there a
> > recommended way to deal with this situation?
> >
> > Thanks,
> > Florian
>
> You can do it like this in glibc-headers:
>
> %ifarch x86_64
> Obsoletes: glibc-headers(x86-32) < %{current E-V-R}
> %endif
Obsoletes work by package names, not by provides. This won't work.
Not adding "self-obsoletes" in DNF is for reason.
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpUyswACgkQaVcUvRu8
X0yL/Q//eNlwQSGhezRzEGgnl5e4Z4T+6JF/x0xBtdxPogJny3eOnt5kKPR7oPfF
jabu73/w0QpDVSxcy0wPyRQiVTD7KgLTi7AOYKEWO+NDnTG75a5orDj9FbSBtxUH
6S0IgYGIg9GQi04T9eI01wq3PWL44roHqCETFlf8/zf5cDFp520RIpSDFhpH2b/n
tz/VQydhvIbWLcv5qD1V9m+zPx17e2z/Pw+stqVPIOK7VzQyWgijilh91YkD4C40
pyxGjo1LfActcMzI2+qiif1uvIRxe2bHuHYsj6E7YG2NYlGw2Il34ox2QwWups9t
JnHx/tNbzIUtWSr/xmf+8DYhEeOZjnnle4QRkwuTrZh+bUAybKN40Y2uNz31HyVI
9PxtaTy09QMDadjOHgvMZvCVwebQOKPkaZVB7pk4E5MzD8ZQcD7b3zpLm2YNDE72
YKuE2TW+KR9Py1zjPuTMygkVTklJ5mmpowmli56JygK2VLsVOTDS4D+I1HeG5ANh
DxwPe6x7o3SurxMBvSsVZBkOom1ZjVO15yOwvnfBNL8EvIyD7TOyKCayqzSVihsM
lryoGBmBrKJKYjmIpGBQK2CqVv/Fv1pwrE01mog979vrRsIzZzZlA+OLXoYRCrGn
f//gnWQcNbskFNqB6B4kq73hADG2JrswkPZ5ej4+DBiGSet+6OQ=
=BqiG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Tue, Jan 09, 2018 at 11:03:28AM +0100, Pierre-Yves Chibon wrote: > On the other side of the fence, with our dear friends from CentOS, is > a brand new, shiny and well supported Jenkins instance. So we thought > it may be good to leverage the CentOS infrastructure to alleviate our > infrastructure and maintenance. +1 -- let's collaborate and share resources and effort wherever we can. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
On Tue, Jan 09, 2018 at 02:17:43AM +, Peter Robinson wrote: > I thought for some reason that all updates marked as security were > automatically urgent, maybe I'm misremembering, but if not it might be > good to do that as a RFE that way all security updates go out non > batched. There was some discussion. There are plenty of updates which have some security implication but which aren't really urgent. I'd rather them stay described as non-urgent security updates than people start not calling them security updates. When they _are_ important to get to users quickly, they should be marked that way. But that's always a tradeoff -- more time in testing gives more of a chance to find regressions or other probems. Also, I think everyone in this discussion on _this_ list who would like updates faster should probably be using updates-testing. Or at least _looking_ at updates-testing. You can always pull individual updates from there on a per-package basis, and doing this helps everyone else. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Tue, Jan 09, 2018 at 02:29:38PM +0100, Dan Horák wrote: > On Tue, 9 Jan 2018 11:03:28 +0100 > Pierre-Yves Chibon wrote: > > > Dear all, > > > > The Fedora Infrastructure team has had a jenkins instance running at > > jenkins.fedorainfracloud.org for a little while now. This instance was > > maintained on a best-effort basis though and we often had outage and > > issues when upgrading it. > > Originally the jenkins master was running on RHEL using the RPMs > > provided by upstream jenkins. When jenkins became available in > > Fedora, we switched our master to be Fedora using the RPMs from > > Fedora. However, nowadays Jenkins is no longer packaged for Fedora, > > our jenkins master is therefore outdated. > > > > On the other side of the fence, with our dear friends from CentOS, is > > a brand new, shiny and well supported Jenkins instance. > > So we thought it may be good to leverage the CentOS infrastructure to > > alleviate our infrastructure and maintenance. > > > > We are currently working on setting up a Jenkins master in > > ci.centos.org that would be dedicated to projects ran in pagure.io. > > It needs a small change to pagure.io and some work on the CentOS side > > but nothing hard and we expect to be able to migrate the first > > volunteer projects by early next week. > > do you plan to use the dynamically provisioned workers like the > current CentOS CI or will it use the static workers like the Fedora > Jenkins? My understanding is to start with static workers as we have now in Fedora to ease the migration (no config change needed) and work from there to migrate to dynamically provisioned workers as the rest of CentOS CI does. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire jenkins.fedorainfracloud.org
On Tue, 9 Jan 2018 11:03:28 +0100 Pierre-Yves Chibon wrote: > Dear all, > > The Fedora Infrastructure team has had a jenkins instance running at > jenkins.fedorainfracloud.org for a little while now. This instance was > maintained on a best-effort basis though and we often had outage and > issues when upgrading it. > Originally the jenkins master was running on RHEL using the RPMs > provided by upstream jenkins. When jenkins became available in > Fedora, we switched our master to be Fedora using the RPMs from > Fedora. However, nowadays Jenkins is no longer packaged for Fedora, > our jenkins master is therefore outdated. > > On the other side of the fence, with our dear friends from CentOS, is > a brand new, shiny and well supported Jenkins instance. > So we thought it may be good to leverage the CentOS infrastructure to > alleviate our infrastructure and maintenance. > > We are currently working on setting up a Jenkins master in > ci.centos.org that would be dedicated to projects ran in pagure.io. > It needs a small change to pagure.io and some work on the CentOS side > but nothing hard and we expect to be able to migrate the first > volunteer projects by early next week. do you plan to use the dynamically provisioned workers like the current CentOS CI or will it use the static workers like the Fedora Jenkins? Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Enabling smoother upgrades in the face of multilib compose changes
Am Dienstag, den 09.01.2018, 13:06 +0100 schrieb Florian Weimer:
> Changes in the Fedora releng dropped glibc-headers.i686 from the
> x86_64
> compose after the Fedora 26 release. This is not in itself a
> problem
> (glibc-devel.i686 is fine if its dependency is matched by
> glibc-headers.x86_64). However, I have received a report that an
> installed glibc-headers.i686 package prevents upgrades to newer
> glibc
> versions.
>
> Are cross-architecture Obsoletes: supported in any way? Is there a
> recommended way to deal with this situation?
>
> Thanks,
> Florian
You can do it like this in glibc-headers:
%ifarch x86_64
Obsoletes: glibc-headers(x86-32) < %{current E-V-R}
%endif
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Enabling smoother upgrades in the face of multilib compose changes
Changes in the Fedora releng dropped glibc-headers.i686 from the x86_64 compose after the Fedora 26 release. This is not in itself a problem (glibc-devel.i686 is fine if its dependency is matched by glibc-headers.x86_64). However, I have received a report that an installed glibc-headers.i686 package prevents upgrades to newer glibc versions. Are cross-architecture Obsoletes: supported in any way? Is there a recommended way to deal with this situation? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: The GNU C Library version 2.27
On 01/09/2018 12:15 PM, Richard W.M. Jones wrote: This is more of an upstream question, but will this bring along RISC-V support? I'm not sure if it will make the cut. There's still some doubt about the correct system call interface for clone. We can perhaps make a case for retroactively adding it with the GLIBC_2.27 symbol version after the release. I think we did something similar for ppc64le. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On Tue, Jan 09, 2018 at 12:28:35PM +0100, Florian Weimer wrote: > On 01/09/2018 12:10 PM, Richard W.M. Jones wrote: > > > >https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 > >says: > > > > "Packages which need rpcgen will have to add BuildRequires: > > libtirpc-devel to their spec files." > > > >but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. > > Sorry, this was a C&P error, it should be “rpcgen”. Oh I see, the new package is called rpcgen. Got it, thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On Tue, Jan 09, 2018 at 12:28:35PM +0100, Florian Weimer wrote: > On 01/09/2018 12:10 PM, Richard W.M. Jones wrote: > > > >https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 > >says: > > > > "Packages which need rpcgen will have to add BuildRequires: > > libtirpc-devel to their spec files." > > > >but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. > > Sorry, this was a C&P error, it should be “rpcgen”. I'm confused ...? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
On 01/09/2018 11:32 AM, Charalampos Stratakis wrote: Python is currently being addressed upstream [0] and the fix will be backported soon to fedora's packages. [0]https://github.com/python/cpython/pull/5137 Has this been tested on OpenSUSE or Gentoo (I think either has already fully made the transition)? I'm asking we still have some NIS bits sticking around, and we need to remove° them as well for the transition to an IPv6-capable NIS. ° As usual, we'll keep support existing binaries. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpcgen?
On 01/09/2018 12:10 PM, Richard W.M. Jones wrote: https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 says: "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel to their spec files." but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. Sorry, this was a C&P error, it should be “rpcgen”. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
On 01/09/2018 11:00 AM, Petr Pisar wrote: On 2018-01-05, Florian Weimer wrote: perl-PDL-2.18.0-4.fc27.src.rpm [...] This is based on relatively current Fedora rawhide/x86_64 and reflects which currently uses svc_/clnt_/xdr_ symbols from glibc. It does not indicate whether these packages can use libtirpc or have bundled replacements. How exactly these xdr_ symbols changed? They are compat symbols, so existing binaries can still reference them. The perl-PDL situation is yet a bit more complex. Rebuilding it with the new glibc succeeds because the xdr_ symbols actually come from HDF, which only provides a static library. Our ld does not default to “-z defs”, so SD.so contains an undefined symbol references to xdr_enum and similar symbols. This reference is unversioned, so the glibc dynamic linker will still bind it to the base symbol version in glibc (e.g., xdr_enum@GLIBC_2.2.5). This is certainly not the right behavior. I'm asking around what can be done about it. I can detect this situation statically based on ELF symbol analysis, but I would prefer if we can make builds to fail instead. Unversioned references to versioned symbols cause problems again and again, so we really need to avoid them. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: The GNU C Library version 2.27
On Tue, Jan 09, 2018 at 12:11:36PM +0100, Jan Kurik wrote: > = System Wide Change: The GNU C Library version 2.27 = > https://fedoraproject.org/wiki/Changes/GLIBC227 > > Change owner(s): > * Carlos O'Donell > > Switch glibc in Fedora 28 to glibc version 2.27. > > > == Detailed Description == > The GNU C Library version 2.27 will be released at the beginning of > February 2018; we have started closely tracking the glibc 2.27 > development code in Fedora Rawhide and are addressing any issues as > they arise. Given the present schedule Fedora 28 will branch after the > GLIBC 2.27 upstream release. However, the mass rebuild schedule means > Fedora 28 will mass rebuild (if required) just after GLIBC 2.27 > upstream freezes ABI for release, so careful attention must be paid to > any last minute ABI changes. > > This change also includes the following changes: > * glibc collation update and sync with cldr > https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_with_cldr > * SunRPC Removal https://fedoraproject.org/wiki/Changes/SunRPCRemoval This is more of an upstream question, but will this bring along RISC-V support? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
On Mon, Jan 08, 2018 at 12:59:20PM -0500, Martin Langhoff wrote: > I have two VMs, or OS states I can `rpm -qa` on. Is there a script to > diff the output of the two listings, and then query the package > changelogs to generate an overall OS-wide changelog? > > Use case: I generated an F26 OVA image using imagefactory 30 days ago, > then I generated a new F26 image today. I'd export rpm -qa listings > from both, and then get a changelog showing all the package updates, > expecting to see the kernel package with the recent CVEs fixed. > > Does such a tool exist? virt-inspector can show the differences in packages installed between two VMs (run it once on each VM and diff the output). For more sophisticating diffing, use virt-diff: http://libguestfs.org/virt-diff.1.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: Add-On Modularity
= System Wide Change: Add-On Modularity = https://fedoraproject.org/wiki/Changes/F28AddonModularity Change owner(s): * Stephen Gallagher * Langdon White == Detailed Description == Beginning in Fedora 28, Fedora will provide a new set of repositories for software and updates with alternative versions from those shipped in the default release. Please see Modularity is Dead, Long Live Modularity! [https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/] for an in-depth description of the plan. == Scope == * Proposal owners The feature owners need to provide a set of reference modules and module-streams that can be composed into the new repository. The set of available packages can and should increase over time as other packagers start taking advantage of it. * Other developers - Developers who wish to offer multiple streams of software in Fedora will need to update their packaging process to take advantage of the new dist-git branching features to allow them to build the same version across multiple releases of Fedora. - Developers who are not interested in doing this at this time will not need to make any changes. When co-maintainers of a packages have different interests, they will need to coordinate. - MirrorManager will need an update to know about the new modular repos. * Release engineering Ticket #7227 https://pagure.io/releng/issue/7227 This Change will require considerable interaction with Release Engineering and the Factory 2.0 teams. New Modular Repositories (one under release, one under updates, one under updates-testing) Stream Expansion from Factory 2.0 Automatic creation of basic modules https://pagure.io/modularity/issue/97 Default streams tagged into base Work will be tracked in Taiga — links to specific items to come. * List of deliverables Affects several release blocking deliverables. There will be an additional `fedora-repos-modular` package that will be installed by default on some Editions/Spins (each WG or SIG will need to make their own decision on whether to ship modules enabled by default). * Policies and guidelines Yes. Some guidelines are already available at https://fedoraproject.org/wiki/Module:Guidelines, however we have plans in place to vastly simplify the process, which should make packagers' lives much easier. * 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
F28 System Wide Change: GCC8
= System Wide Change: GCC8 = https://fedoraproject.org/wiki/Changes/GCC8 Change owner(s): * Jakub Jelínek Switch GCC in Fedora 28 to 8.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 29. == Detailed Description == GCC 8 is currently in stage3, will move to stage4 on January 14th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. We are working on scratch gcc rpms and will perform a test mass rebuild. == Scope == All packages should be rebuilt with the new gcc once it hits f28, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots. * Proposal owners: Build gcc in f28, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin, odb). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-8/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. * Release engineering: PR#7249: https://pagure.io/releng/issue/7249 Mass rebuild requested for F28. * Policies and guidelines: No policies need to be changed -- 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
F28 System Wide Change: The GNU C Library version 2.27
= System Wide Change: The GNU C Library version 2.27 = https://fedoraproject.org/wiki/Changes/GLIBC227 Change owner(s): * Carlos O'Donell Switch glibc in Fedora 28 to glibc version 2.27. == Detailed Description == The GNU C Library version 2.27 will be released at the beginning of February 2018; we have started closely tracking the glibc 2.27 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 28 will branch after the GLIBC 2.27 upstream release. However, the mass rebuild schedule means Fedora 28 will mass rebuild (if required) just after GLIBC 2.27 upstream freezes ABI for release, so careful attention must be paid to any last minute ABI changes. This change also includes the following changes: * glibc collation update and sync with cldr https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_with_cldr * SunRPC Removal https://fedoraproject.org/wiki/Changes/SunRPCRemoval == Scope == * Proposal owners: Update glibc to 2.27 from tested upstream release. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 28 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated. * Release engineering: #7249 : https://pagure.io/releng/issue/7249 The Fedora Toolchain team is responsible for ensuring that Fedora Rawhide stabilizes ABI before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by glibc or other components, the Fedora Toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of glibc to fix any last minute ABI changes. A mass rebuild has been requested. * List of deliverables: NA * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: 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
F28 System Wide Change: Binutils version 2.29.1
= System Wide Change: Binutils version 2.29.1 = https://fedoraproject.org/wiki/Changes/BINUTILS2291 Change owner(s): * Nick Clifton Rebase the binutils package from version 2.29 to version 2.29.1. This will bring in the bug-fixes from the 2.29.1 point release, but not add any new features. == Detailed Description == Switch the binutils package from being based on the 2.29 release of the FSF binutils to being based on the 2.29.1 release. This release was a collection of important bug fixes over the 2.29 release, but no new features were introduced. == Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed. * Other developers: In theory none - the change should be completely transparent. In practice since the binutils are part of the C/C++ compiler toolchain there is the possibility that the change introduces a new bug which affects other packages. * Release engineering: https://pagure.io/releng/issue/7251 * List of deliverables: Just the binutils packages. * Policies and guidelines: No updates needed. * 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
rpcgen?
https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864 says: "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel to their spec files." but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
Dne 8.1.2018 v 18:21 Steve Dickson napsal(a): > Hello, > > Is it a problem for a package to pull from two different > upstream tar balls? Basically have > > Source0: http://server.com/package1/package1.tar > Source1: http://server.com/package2/package2.tar > > Then I would, by hand, untar Source1 into Source0 directory. > > Before do the work I want to make sure I'm not > breaking violating any package rules. I did look > around and didn't see anything addressing this. > > If this is kosher, are there any examples of other > packages doing this... https://src.fedoraproject.org/rpms/rubygem-ancestry/blob/master/f/rubygem-ancestry.spec Source0 is upstream gem Source1 is git snapshot with tests which are not in gem. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Disable a package for Fedora 26
Jonny Heggheim wrote:
> We just pused a urgent security update for Electrum for Fedora 27 and
> rawhide, Fedora 26 is still affected.
>
> All versions of Electrum is affected by this bug, Fedora 26 still runs
> an older version because of big changes in Electrum 3.0 and an updated
> version of a dependency.
>
> So I see 3 options:
Note: I reordered the options below for commenting:
> * Create a patch for the version running on Fedora 26. Will take time
> to make the patch and test on Fedora 26.
This (your second option) is what the stable update guidelines recommend
doing in such a case ("big changes in Electrum 3.0") if possible, but…
> * Upgrade to latest version for Fedora 26. Will take time to update and
> might brake something else.
… if you can't do the backport in a reasonable time frame (This
vulnerability is very critical, since it allows remote money stealing!), the
recommendation is to just upgrade to the latest upstream immediately (i.e.,
your first option). E.g., this (just upgrade to the latest version, even if
there are breaking changes) is also how Firefox handles security updates.
Upgrading vs. backporting is always a tradeoff. Upgrading keeps you closer
to upstream, backporting means fewer unexpected changes for users of stable
releases. There are instances of both in Fedora, depending on what changed
in the new upstream release and/or how hard it is to backport the security
fixes to the old release.
> * Make an update that disables Electrum, include only a README or
> someting like that. Will make users confused.
This (your third option) is the worst possible option. It is better to just
push the new version, which is surely better than nothing (and also better
than doing nothing and letting websites steal the user's money).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
- Original Message - > From: "Florian Weimer" > To: devel@lists.fedoraproject.org > Sent: Friday, January 5, 2018 10:12:50 PM > Subject: Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc > > On 01/05/2018 09:42 PM, Simo Sorce wrote: > > On Fri, 2018-01-05 at 21:09 +0100, Florian Weimer wrote: > >> On 01/05/2018 08:10 PM, Yaakov Selkowitz wrote: > >> > >>> Please be aware that not all RPC-dependent packages are "aware" of > >>> libtirpc yet. Notably, KDE's NFS kioslaves (in kdebase3, kde-runtime, > >>> and kio-extras) would need to be patched to use libtirpc. Without such, > >>> the packages would rebuild, but without NFS support. > >> > >> Understood. There are other packages affected in similar ways. But we > >> have announced the transition roughly ten years ago, and it's clear that > >> we can't finish it simply by begging maintainers. Sorry. > > > > Do you have a list of affected packages ? > > python2-2.7.14-4.fc28.src.rpm > python26-2.6.9-10.fc28.src.rpm > python3-3.6.3-4.fc28.src.rpm > python33-3.3.7-2.fc28.src.rpm > python34-3.4.7-2.fc28.src.rpm > python35-3.5.4-2.fc28.src.rpm > python37-3.7.0-0.1.a2.fc28.src.rpm Python is currently being addressed upstream [0] and the fix will be backported soon to fedora's packages. [0] https://github.com/python/cpython/pull/5137 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On 2018-01-08 17:21, Steve Dickson wrote: Hello, Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0: http://server.com/package1/package1.tar Source1: http://server.com/package2/package2.tar Then I would, by hand, untar Source1 into Source0 directory. Before do the work I want to make sure I'm not breaking violating any package rules. I did look around and didn't see anything addressing this. If this is kosher, are there any examples of other packages doing this... dovecot does this, the "other" tarball being dovecot-pigeonhole. Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Intent to retire jenkins.fedorainfracloud.org
Dear all, The Fedora Infrastructure team has had a jenkins instance running at jenkins.fedorainfracloud.org for a little while now. This instance was maintained on a best-effort basis though and we often had outage and issues when upgrading it. Originally the jenkins master was running on RHEL using the RPMs provided by upstream jenkins. When jenkins became available in Fedora, we switched our master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins is no longer packaged for Fedora, our jenkins master is therefore outdated. On the other side of the fence, with our dear friends from CentOS, is a brand new, shiny and well supported Jenkins instance. So we thought it may be good to leverage the CentOS infrastructure to alleviate our infrastructure and maintenance. We are currently working on setting up a Jenkins master in ci.centos.org that would be dedicated to projects ran in pagure.io. It needs a small change to pagure.io and some work on the CentOS side but nothing hard and we expect to be able to migrate the first volunteer projects by early next week. Once the first migrations have happened and the first rough edges have been smoothed we will be announcing an official retirement date for jenkins.fedorainfracloud.org and migrate all the projects hosted there to ci.centos.org, and of course help with the potential questions raising from this. Thanks for your understanding, Pierre - For the Fedora Infrastructure Team Brian Stinson - For the Ci.CentOS.org Team ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
On 2018-01-05, Florian Weimer wrote: > perl-PDL-2.18.0-4.fc27.src.rpm [...] > This is based on relatively current Fedora rawhide/x86_64 and reflects > which currently uses svc_/clnt_/xdr_ symbols from glibc. It does not > indicate whether these packages can use libtirpc or have bundled > replacements. > How exactly these xdr_ symbols changed? The perl-PDL uses xdr_int, xdr_long and similar symbols. They are provided even with the latest glibc-2.26.9000-37.fc28. The affected perl-PDL's shared library successfully resolves all symbols. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28
Hi Richard, On Sat, 2018-01-06 at 11:27 +, Richard W.M. Jones wrote: > I noticed as a side effect of compiling GCC for riscv64 that RISC-V's > GCC doesn't support -fstack-clash-protection. Do you know what is > involved to add it? From a naive point of view I don't understand > why this feature depends on architecture at all. Sorry, I don't know the precise details on the gcc side. I believe it is architecture dependent because it depends on the exact calling conventions and how specific call instructions that manipulate the stack. gcc wants the stack probes to be as efficient as possible. So it only explicitly lowers the stack and inserts probes if absolutely necessary. That is also why there were originally subtle issues around no-return functions (because their calling conventions are different and so gcc couldn't rely on the stack pointer already being lowered and/or arguments having been pushed on it already). Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fwd: Broken dependencies: redhat-rpm-config
On Jan 9, 2018 08:40, "Panu Matilainen" wrote: Started getting these bogus broken deps emails after merging a request to depend on gcc conditionally. Is the broken dependencies check done with yum era repoclosure still, or...? I am getting 200+ emails everyday with such "broken" deps for all Rust packages :) Yes, spam-o-matic (script which generates this) is yum-based. IIRC there was releng ticket to fix this. - Panu - Forwarded Message Subject: Broken dependencies: redhat-rpm-config Date: Tue, 9 Jan 2018 01:30:25 + (UTC) From: build...@fedoraproject.org To: redhat-rpm-config-ow...@fedoraproject.org redhat-rpm-config has broken dependencies in the rawhide tree: On x86_64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On armhfp: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On ppc64le: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On aarch64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On ppc64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On s390x: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On i386: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) Please resolve this as soon as possible. ___ 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
