devel December 2016

devel@lists.fedoraproject.org

217 participants
258 discussions

F24 GStreamer zero day
by Michael Catanzaro 01 Dec '16

01 Dec '16

Hi, Is anybody working on fixing [1]? The exploit is a little impractical in that it only works if you have not updated any F24 base packages except GStreamer, but we should still fix it. I don't see any GStreamer updates in bodhi yet. Michael [1] http://arstechnica.com/security/2016/11/elegant-0day-unicorn-underscores-se…

18 45

Bodhi problems?
by Juan Orti Alcaine 01 Dec '16

01 Dec '16

I can't push to stable a couple of updates. Is there any known problem with Bodhi? https://bodhi.fedoraproject.org/updates/FEDORA-2016-fa485c1c95 https://bodhi.fedoraproject.org/updates/FEDORA-2016-eae6ba26e4 -- Juan Orti https://apuntesderootblog.wordpress.com/ GPG: 61F0 8272 6882 BCA6 3A35 88F6 B630 4B72 DEEB D08B

2 1

static linking a library
by Neal Becker 01 Dec '16

01 Dec '16

Mercurial upstream is asking about a compression library zstd. Specifically: https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-November/0… I believe the proposed solution here: https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-December/0… which is to statically link the library to the mercurial executable would also raise issues? A special exception to the statically linked binary would be required? Thanks, Neal

2 1

Creating an new update is failing
by Steve Dickson 01 Dec '16

01 Dec '16

Hello, I'm trying to create a new update and I'm getting this error: Builds : Unable to create update. Parent instance is not bound to a Session; lazy load operation of attribute 'release' cannot proceed The build looks fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=821471 Any ideas what the problem is? tia, steved.

7 9

Base Runtime prototype build and numerous FTBFS issues
by Petr Šabata 01 Dec '16

01 Dec '16

Hi! during the Tuesday's Modularity WG meeting I was talking about the status of the Base Runtime prototype build and the package build failures we encountered during our latest attempt. The meeting log is here: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-11… In short: To bootstrap the Modularity infra (yeah, it's still not done) we took a (fairly large) set of packages directly from Fedora 25 RC3 and put them all in one, self-hosting module, currently misleadingly labeled as base-runtime. The next step was to rebuild this set using only the packages in it, preferrably twice, to prove it works, produces the same, reproducible builds (or as close as we can get) and to save us from sudden, unexpected breakage later when we need to touch components deep in the [build] dependency chain. (Since this is a common question: No, the final Base Runtime module, or the Generational Core stack it is part of, won't be self-hosting and we won't be shipping the entire set we're currently working with under that name.) We attempted to rebuild 2943 SRPMs and encountered 152 failures. The reasons vary and include undiscovered conditional build dependencies, undeclared build or runtime dependencies in combination with recent buildroot and other package dependency chains changes, packages no longer being compatible with their updated dependencies, random hangs or non-deterministic, randomly failing test suites, to name a few. Some but not all of those affect, and can be reproduced in, the traditional Fedora release, too, and fixing these issues is not only crucial for the upcoming modular Fedora 26 Server but will benefit the standard Fedora release as well. We'll be working on resolving these failures during the upcoming few weeks -- via FTBFS bug reports or immediate fixes in the most trivial cases. We'll use the following tracker bug for this purpose: https://bugzilla.redhat.com/show_bug.cgi?id=1400162 For the curious, the logs are here: https://psabata.fedorapeople.org/f25rc3-failures/ And the modulemd input for this build is here: http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/base-r… If you maintain some of these FTBFS'd packages, feel free to fix them even before we get to you! :) Just, please, let us know if you do. Finally, some quick test instructions: Make sure your package builds in F25 and Rawhide. If it does, check whether it also builds in mock using this configuration file: https://paste.fedoraproject.org/494173/ If it works there as well, chances are it's fine. Thank you in advance, P

3 2

urw-fonts: Versioning Mess
by David Kaspar [Dee'Kej] 01 Dec '16

01 Dec '16

Hello guys, I took over the maintenance of urw-fonts to update them to the latest version (ghostscript and other packages needs them). However, there are several problems in versioning of it, and I would like to discuss future steps for the package. The current problems: * our urw-fonts are kind of old (~2 years), and ghostscript is unable to build without latest version correctly (unless I patch it, and it would still cause ghostscript crashes for some instances AFAIK) * according to git log the urw-fonts in Fedora should be based on version 1.10, but the source code archive indicates version 1.07 pre-release (1.06 in fact, if we check the source code) * the NVR of urw-fonts does not correlate to this at all - urw-fonts-2.4-22.fc24.noarch * we obtain the source archive from Artifex (aka upstream responsible for ghostscript), nowadays they are no longer using the X.Y.Z versioning system. Instead, they have created a separate git repository for it, and are doing "snapshot based" releases... Their latest release is: urw-base35-20160926.zip * I asked them if they could go back to X.Y.Z versioning system, here's what Chris Liddell replied: "If you check the versions in the font files, you'll see why I switched to the release dates. For several releases they never changed from 1.10, and with the latest release, they're back to 1.00. Since this is how URW++ release them to us, there's not a huge amount we can do." * and as you can see above, they also changed the name from 'urw-fonts' to 'urw-base35' because of this As you can see, the versioning of urw-fonts is total mess right now, and I would like to bring back some order to it, but I don't want it to backfire on me because of how URW++ tends to version their fonts... Here's my proposed solution to this: - create a new package for urw-fonts which would obsolete the current urw-fonts - choose a similar name to the new package - 'urw-base35-fonts' or similar And either... 1) stick to URW++ based versioning - this would mean (at the moment) Version == 1.0 and adding snapshot == 20160926 (YYYYMMDD as described in https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages) 2) or map the X.Y.Z versioning to YYYYMMDD from upstream - IOW - X == Year, Y == Month, Z == Day (based on the snapshot date in the name of the source archive) 3) or set the Version to some constant (35 for example) and just use the snapshot to distinguish between older and newer releases. I am affraid that I would pick option 1) it could pose problems in the future again, because there's not guarantee that URW++ will follow sane versioning. So, personally, I would choose 2) or 3). There's also one more option, and that is to base the package on upstream's git repository and the snapshot scheme, because we would be using snapshot string in the package name anyway. And it would also solve one more issue that upstream is not shipping license files in the archive. (I have already contacted to correct this.) What are you thoughts, guys? Anyone has a better idea how to solve this mess? Or which option would you recommend? Thank you in advance for all your ideas. Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.

5 8

MongoDB 3.4-compatiable clients report user agent
by Petr Pisar 01 Dec '16

01 Dec '16

To whom may it concern, MongoDB clients started to report implementation identification to a server <https://github.com/mongodb/specifications/blob/master/source/mongodb-handsh…>. It includes operating system and MongoDB driver name and version. Although the shared data are modest and, in my opinion, do not divulge any sensitive information, I'd like to make Fedora community aware about this practice. -- Petr

1 0

Soon retirement of zeromq2 and zeromq3
by Thomas Spura 01 Dec '16

01 Dec '16

Hi all, zeromq2 and zeromq3 were additional/compat packages that made it possible to ship multiple versions of zeromq (namely the old versions 2 and 3). These days, they don't get any bugfixes anymore and the version 4 should be used were possible. There should have been enough time to port all dependant packages to zeromq-4 and I like to retire these packages. The current dependencies are: # dnf repoquery --whatrequires zeromq2 --alldeps perl-ZMQ-LibZMQ2-0:1.09-7.fc23.x86_64 perl-ZeroMQ-0:0.23-11.fc23.x86_64 zeromq2-devel-0:2.2.0-14.fc23.i686 zeromq2-devel-0:2.2.0-14.fc23.x86_64 # dnf repoquery --whatrequires zeromq3 --alldeps perl-ZMQ-LibZMQ3-0:1.19-3.fc23.x86_64 zeromq3-devel-0:3.2.5-3.fc23.i686 zeromq3-devel-0:3.2.5-3.fc23.x86_64 The maintainer of perl-ZMQ-LibZMQ* should be aware of this [1,2] and is also in CC. Feel free to take over the zeromq2 and zeromq3 packages, otherwise I'll retire it next week. Best, Thomas [1] https://bugzilla.redhat.com/show_bug.cgi?id=1165554 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1165555

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2016