devel December 2016

devel@lists.fedoraproject.org

217 participants
258 discussions

Kernel 4.9 rebase plans
by Laura Abbott 13 Jan '17

13 Jan '17

Hi, Kernel 4.9 was officially released yesterday, December 11. This kernel is being built for rawhide today. The plan for bringing this kernel into F24/F25 is going to follow roughly the same schedule as in the past. This means pushing the new rebase when we think it's stable enough. In the past, this has happened around the .2 stable release (so 4.9.2 in this case). Given the holidays, this won't be happening until 2017 but we'll be monitoring closely. I'll update with more information once it gets closer. As always, please let us know if you have any questions. Thanks, Laura

1 2

Re: Packages FTBFS with Python 3.6
by Igor Gnatenko 13 Jan '17

13 Jan '17

On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok <mhroncok(a)redhat.com> wrote: > Hi all, > We've recently tried to rebuild all Python packages with Python 3.6. > However, we currently have bunch of packages that simply fail to build. > > As the list contains >200 packages, it would be very helpful, if you > (package maintainers) could help us solve the issues, as we cannot go one by > one to investigate the issue. > > I've attached the list of failed packages (failed.txt). You can search Koji > to find out, what went wrong. Sometimes, it's just missing dependency. That > dependency should be on this list as well. If it is not, maybe we lost it, > please tell us if that's the case. Maybe the dependency is circular and > something needs to be bootstrapped. If you need provenpackager powers, let > me know. I've fixed python-smartcols and python-behave.. Attaching current rawhide/koji packages which depend on python 3.5 instead of 3.6 still. -- -Igor Gnatenko

6 13

future of official optical media support in Fedora
by Kamil Paral 13 Jan '17

13 Jan '17

Now that Fedora 25 is out of the door, I'd like to start a discussion about the future of officially-supported (meaning rigorously tested) optical media for future Fedora releases. Since I'm QA, I'm mainly interested in changes to our release criteria [1]. Let's start by saying I'm not asking for completely dropping optical media support. Even though hardware incapable of booting from USB is getting increasingly rare, I understand that there are still valid use cases from optical media, like pressing a bulk of DVDs for a very small price and handing it out at events or sending them into developing countries (that's how I started with Linux, after all, ~15 years ago). However, the world has moved on since then, I wonder whether some changes in decreasing the importance of optical media could be appropriate. All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time. So, I wonder whether Fedora as a project thinks about de-emphasizing optical media a bit, and if it does, I'd make appropriate changes even in our QA processes. Here are a couple of ideas that I consider could be likely to happen in future Fedora releases. Idea #1: Do not block on optical media issues for Alpha and Beta releases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In my guesstimation, the intersection between people able and willing to test pre-releases and people not able to boot from USB or PXE is getting very small. My reasoning for this is: a) PCs unable to boot from USB are becoming rare. They are probably only (or mostly) very old i386 machines. b) Users testing pre-releases usually have above-average technical skills and/or are technical enthusiasts, who tend to own newer hardware. c) We now have Fedora Media Writer for all major operating systems, which can burn the image onto a flash drive with a nice simple user interface, so even people who can boot from both optical drive and USB and used to prefer optical drive (because it was simpler for them) should be covered now with our super-easy USB writing tool. Implementing this idea doesn't mean optical media would immediately get broken for Alphas and Betas. We would still care about such issues (it would be needed for Final, if nothing else) and we would still test it from time to time during the whole cycle (even though not that frequently - we would rely more on community involvement, e.g. similar to alternative architectures). But we wouldn't block the Alpha/Beta release on these issues, just the Final release. Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a bolder variant of the previous idea and can be done separately or combined with it. It makes optical media functionality not guaranteed even for Final release, but just for certain Fedora flavors or image types for which it makes sense (not all of them). Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them: * Workstation Live + netinst * KDE Live * Server DVD + netinst * Everything netinst What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that. Second idea would be netinst media. They require good network access, so there's no point in shipping them to developing countries, and I can hardly imagine giving them away at events. They are targeted at more professional audience, which is likely to use more modern hardware. We could make an exception of Everything netinst, which is universal and could be used for cases where Live images don't work (netinst can use text mode in case of severe graphical issues even with safe graphics mode on, or perhaps on ultra-low memory configurations). What do you think? Does it make sense, or is it too early for such a change? (CCing test list, but let's keep the discussion in a single list only, i.e. devel) [1] https://fedoraproject.org/wiki/Fedora_Release_Criteria [2] https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Installation#D…

18 70

BuildRequires on obsoleted packages provided by Python
by Charalampos Stratakis 11 Jan '17

11 Jan '17

Hello all, While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it. I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead. Here is a github commit with these changes from a testing repo: https://github.com/fedora-python/python2-spec/commit/dfdd96e653d65ce6835955… And a list of the provided packages and the affected ones Distutils: None python-sqlite: cas yum python-ctypes: drobo-utils glusterfs-extra-xlators glusterfs-geo-replication python-smbios python-hashlib: pyrpkg python-uuid: dpm-server-mysql oz python2-celery python-argparse: R2spec catkin diskimage-builder euca2ools fedora-review feedstail gfal2-util glacier-cli grin hash-slinger imagefactory instack libstoragemgmt nordugrid-arc-nagios-plugins os-apply-config os-cloud-confic os-collect-confic os-net-config pyrpkg python-amqpclt python-catkin_pkg python-catkin_tools python-cloudservers python-gear python-novaclient python-postman python-requestbuilder python-rosdistro python-rospkg python-sparklines python2-oslo-config repo_manager rpkg vdsm Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages. The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well). Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat

9 11

Strange koji failures
by Christopher 10 Jan '17

10 Jan '17

Hi, I occasionally get this strange failure in koji. Sometimes this happens with a good package build, and I can just re-submit it without changing anything, and it works fine. Is this a known issue? For example, from https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log: sh: /usr/bin/python: No such file or directory warning: Could not canonicalize hostname: buildvm-14.phx2.fedoraproject.org -- Christopher

13 29

SSL: CERTIFICATE_VERIFY_FAILED
by gil 08 Jan '17

08 Jan '17

Hi i get : $ KRB5_TRACE=/dev/stdout kinit gil(a)FEDORAPROJECT.ORG [2285] 1482484266.902495: Getting initial credentials for gil(a)FEDORAPROJECT.ORG [2285] 1482484266.902725: Sending request (194 bytes) to FEDORAPROJECT.ORG [2285] 1482484266.902911: Resolving hostname id.fedoraproject.org [2285] 1482484267.583802: TLS certificate name matched "id.fedoraproject.org" [2285] 1482484267.800894: Sending HTTPS request to https 209.132.181.16:443 [2285] 1482484268.32078: Received answer (270 bytes) from https 209.132.181.16:443 [2285] 1482484268.32097: Terminating TCP connection to https 209.132.181.16:443 [2285] 1482484268.33672: Response was not from master KDC [2285] 1482484268.33717: Received error from KDC: -1765328359/Additional pre-authentication required [2285] 1482484268.33774: Processing preauth types: 136, 19, 2, 133 [2285] 1482484268.33782: Selected etype info: etype aes256-cts, salt "<\dUU>-'9OMNb")7", params "" [2285] 1482484268.33786: Received cookie: MIT Password for gil(a)FEDORAPROJECT.ORG: [2285] 1482484284.346052: AS key obtained for encrypted timestamp: aes256-cts/9D63 [2285] 1482484284.346102: Encrypted timestamp (for 1482484284.235522): plain 301AA011180F32303136313232333039313132345AA1050203039802, encrypted 9440A234EB9CA0BDC41D60BF4F08AB1ABE4890F15918ABD1305E93775D2FBF81946C7AD58A68B4019244A1B4A6E8F5F31D3759FD58842F1D [2285] 1482484284.346124: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [2285] 1482484284.346131: Produced preauth for next request: 133, 2 [2285] 1482484284.346150: Sending request (289 bytes) to FEDORAPROJECT.ORG [2285] 1482484284.346186: Resolving hostname id.fedoraproject.org [2285] 1482484284.918643: TLS certificate name matched "id.fedoraproject.org" [2285] 1482484285.136809: Sending HTTPS request to https 209.132.181.16:443 [2285] 1482484285.382621: Received answer (781 bytes) from https 209.132.181.16:443 [2285] 1482484285.382646: Terminating TCP connection to https 209.132.181.16:443 [2285] 1482484285.383957: Response was not from master KDC [2285] 1482484285.384015: Processing preauth types: 19 [2285] 1482484285.384022: Selected etype info: etype aes256-cts, salt "<\dUU>-'9OMNb")7", params "" [2285] 1482484285.384027: Produced preauth for next request: (empty) [2285] 1482484285.384036: AS key determined by preauth: aes256-cts/9D63 [2285] 1482484285.384505: Decrypted AS reply; session key is: aes256-cts/0AE8 [2285] 1482484285.384523: FAST negotiation: available [2285] 1482484285.384539: Initializing KEYRING:persistent:1000:1000 with default princ gil(a)FEDORAPROJECT.ORG [2285] 1482484285.384571: Storing gil(a)FEDORAPROJECT.ORG -> krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG in KEYRING:persistent:1000:1000 [2285] 1482484285.384865: Storing config in KEYRING:persistent:1000:1000 for krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG: fast_avail: yes [2285] 1482484285.384908: Storing gil(a)FEDORAPROJECT.ORG -> krb5_ccache_conf_data/fast_avail/krbtgt\/FEDORAPROJECT.ORG\@FEDORAPROJECT.ORG@X-CACHECONF: in KEYRING:persistent:1000:1000 [2285] 1482484285.384946: Storing config in KEYRING:persistent:1000:1000 for krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG: pa_type: 2 [2285] 1482484285.384956: Storing gil(a)FEDORAPROJECT.ORG -> krb5_ccache_conf_data/pa_type/krbtgt\/FEDORAPROJECT.ORG\@FEDORAPROJECT.ORG@X-CACHECONF: in KEYRING:persistent:1000:1000 $ koji build --scratch --arch-override x86_64 rawhide /home/gil/springframework/springframework-3.2.18-1.fc26.src.rpm SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) $ klist -e Ticket cache: KEYRING:persistent:1000:1000 Default principal: gil(a)FEDORAPROJECT.ORG Valid starting Expires Service principal 23/12/2016 10:11:32 24/12/2016 10:11:07 host/koji.fedoraproject.org(a)FEDORAPROJECT.ORG renew until 30/12/2016 10:11:07, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 23/12/2016 10:11:25 24/12/2016 10:11:07 krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG renew until 30/12/2016 10:11:07, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 $ fedora-cert -v Verifying Certificate cert expires: 2017-05-26 Traceback (most recent call last): File "/usr/bin/fedora-cert", line 85, in <module> main(opts) File "/usr/bin/fedora-cert", line 63, in main fedora_cert.verify_cert() File "/usr/lib/python2.7/site-packages/fedora_cert/__init__.py", line 69, in verify_cert revoked = crl.get_revoked() File "/usr/lib/python2.7/site-packages/OpenSSL/crypto.py", line 1921, in get_revoked revoked_stack = self._crl.crl.revoked AttributeError: '_cffi_backend.CData' object has no attribute 'crl' what's wrong? thanks in advance regards .g

9 20

Packagers - Flag day 2016 Important changes
by Dennis Gilmore 07 Jan '17

07 Jan '17

Greetings. As previously announced, releng has made a number of changes as part of it's 2016 "flag day". All package maintainers will want to make sure they have updated to the following package versions (some may be in testing as of this email): python-cccolutils-1.4-1 fedpkg-1.26-2 fedora-packager-0.6.0.0-1 pyrpkg-1.47-3 koji-1.11.0-1 Please also see the following links for up to date information: https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 The following changes were made: * koji and the source lookaside were changed to use kerberos authentication instead of ssl certificates. All maintainers will need to: kinit YOUR-FAS-ACCOUNTNAME(a)FEDORAAPROJECT.ORG to get a valid kerberos TGT and be able to authenticate to koji and the lookaside upload cgi. See the general kerberos information at: https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication for more details. Additionally, via GSSAPI many browsers allow you to seamlessly login to any of our ipsilon using applications simply by clicking on the login button ( bodhi, fedorahosted trac, elections, fedocal, mailman3, etc) * koji now uses a well known cert for https. * pkgs.fedoraproject.org now redirects to https://src.fedoraproject.org and that uses a well known cert. Please correct any links you use to use https://src.fedoraproject.org for packages spec and patch files. * rawhide builds now land in the f26-pending tag, where they are signed and then added to the f26 tag for compose in the next rawhide compose. This allows rawhide packages to be fully signed as well as a point where automated QA can take place in the future. * packages "sources" files now use sha512 by default instead of md5. You will need the fedpkg update in order to create and use these new checksums. Questions or concerns as always welcome at #fedora-admin on irc.freenode.net or tickets at https://pagure.io/fedora-infrastructure. _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

38 104

F26 System Wide Change: Golang 1.8
by Jan Kurik 07 Jan '17

07 Jan '17

= Proposed System Wide Change: Golang 1.8 = https://fedoraproject.org/wiki/Changes/golang1.8 Change owner(s): * Jakub Čajka <jcajka AT redhat DOT com> Rebase of Golang package to upcoming version 1.8 in Fedora 26, including rebuild of all dependent packages. == Detailed Description == Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang 1.8 is schedule to be released in Feb. Due to current nature of Go packages, rebuild of dependent package will be required to pick up the changes. == Scope == * Proposal owners: Rebase golang package in f26, help with resolving possible issues found during package rebuilds. * Other developers: fix possible issues * Release engineering: As there is scheduled mass-rebuild, nothing should be required. * 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

5 12

Interpreting FAF reports
by Florian Weimer 05 Jan '17

05 Jan '17

Any idea what this is about? https://retrace.fedoraproject.org/faf/reports/1154372/ To me that looks like a combination of several factors. First of all, the backtrace generation likely used incorrect debuginfo data because the backtrace is impossible. Stack corruption is unlikely to yield a relatively consistent backtrace—iconv and gconv match up, only the nscd and sunrpc functions in the middle do not make sense. I got lucky and build ID 25ea1fd961cb2f5a38172614365bd4c1aacb01a6 refers to the current version of /usr/lib64/gconv/ISO8859-1.so, so I could do the disassembly manually. The crash is in the gconv function, at address 0xb50: b44: 49 39 d5 cmp %rdx,%r13 b47: 72 2a jb b73 <gconv+0x3e3> b49: 48 89 d3 mov %rdx,%rbx b4c: 48 83 c0 01 add $0x1,%rax b50: 0f b6 50 ff movzbl -0x1(%rax),%edx b54: 48 39 c5 cmp %rax,%rbp b57: 89 53 fc mov %edx,-0x4(%rbx) b5a: 75 e4 jne b40 <gconv+0x3b0> b5c: 41 bb 04 00 00 00 mov $0x4,%r11d b62: e9 1a ff ff ff jmpq a81 <gconv+0x2f1> b67: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) Experimentation with GDB shows that this is in the part which converts from ISO-8859-1, and it is the load from the input buffer. A crash at this point is impossible because we have a bounds check in the gconv implementation framework before this load. However, iconv (the command) maps the input file, and something is truncating that file, causing the SIGBUS error. This is just how mmap works in POSIX, unfortunately. Is there a way to discover who is submitting these crash reports and what they are trying to do? I wonder if we should remove the mmap from the iconv command, so that we would not crash in this case. Florian

5 7

Koji builders' specs
by Pavel Raiskup 04 Jan '17

04 Jan '17

Hi all, where is documented what system/hw is used on (primary) Koji builders? I'm interested in memory, storage, filesystem, host operating system, guest operating system (if those are VMs), etc. The only thing I was able to find is version of mock in the log output. FWIW, I'd like to reproduce hang in gnulib's test-lock [1] test case. Unless I'm able to reproduce that somehow, I'll disable the test for the time being (done in 'coreutils' and I guess elsewhere, too). [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779 Thanks, Pavel

6 13

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