Fedora 28 Beta 1.3 compose check report
No missing expected images. Failed openQA tests: 1/137 (x86_64), 3/23 (i386), 1/2 (arm) ID: 213956 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/213956 ID: 213957 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/213957 ID: 213971 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/213971 ID: 214068 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/214068 ID: 214086 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/214086 Soft failed openQA tests: 11/137 (x86_64), 2/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 213933 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/213933 ID: 213934 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/213934 ID: 213935 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/213935 ID: 213941 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/213941 ID: 213998 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/213998 ID: 214021 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/214021 ID: 214038 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/214038 ID: 214053 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/214053 ID: 214055 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/214055 ID: 214076 Test: x86_64 AtomicWorkstation-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/214076 ID: 214077 Test: x86_64 AtomicWorkstation-dvd_ostree-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/214077 ID: 214082 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/214082 ID: 214083 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/214083 Passed openQA tests: 125/137 (x86_64), 18/23 (i386) Skipped openQA tests: 1 of 162 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
Dne 28.3.2018 v 19:55 Pierre-Yves Chibon napsal(a): > On Wed, Mar 28, 2018 at 07:34:51PM +0200, Vít Ondruch wrote: > >> And please rename this thread to "Gating packages in Fedora", because >> Rawhide should be just Fedora. > You do realize that there is already gating in place for stable releases > right? Yes I do. > So no this thread is specifically about rawhide. And I want the same gating for Rawhide. Just the timing should be different. V. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Fedocal] Reminder meeting : F28 Beta release Go/No-Go Meeting - 2nd round
Dear all, You are kindly invited to the meeting: F28 Beta release Go/No-Go Meeting - 2nd round on 2018-03-29 from 17:00:00 to 19:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Source: https://apps.fedoraproject.org/calendar/meeting/9017/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Re: Fedora 28 Candidate Beta-1.3 Available Now!
On Thu, 2018-03-29 at 02:48 +, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 28 Candidate Beta-1.3 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan This is the compose with (we hope) correct systemd fixes for Atomic Workstation boot. We're going to choose between 1.1 and 1.3 (and not shipping at all) at go/no-go tomorrow. It'd be great if we can get some testing on 1.3 - please focus on tests that involve systemd, and some package install / removal tests for packages with systemd services and things (as the changes are to scriptlets and triggers). 1.1 coverage is looking pretty good now - thanks a lot to all testers! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 28 Candidate Beta-1.3 Available Now!
According to the schedule [1], Fedora 28 Candidate Beta-1.3 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/28 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Base https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Server https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.3_Security_Lab All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-28/f-28-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 28 minimum memory requirement, review
Dropping packagekitd and gnome-software starting up on lives has helped quite a bit. Netinstall has zram.service enabled by default, so a zram swap device is automatically created during boot. This service exists on the live, but is disabled by default. If there could be a ConditionKernelCommandLine=rd.live.image then it would only enable on lives, and not when installed. Maybe it's a question for the anaconda folks. anaconda-core-27.20.4-6.fc27.x86_64 : Core of the Anaconda installer Filename: /usr/lib/systemd/system/zram.service Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Fri, Mar 09, 2018 at 10:20:12AM +0100, Pierre-Yves Chibon wrote: > On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote: > > I would like to kick off a general discussion about how we might gate > > packages in Rawhide. I think it would be nice to get something in place > > for the Fedora 29 timeframe. > > I was waiting to have some more time to work on it to kick off that > discussion. > This is cool as it means there are more people interested in having this :) > > > As one of the Bodhi contributors, I am inclined to suggest that we could > > use Bodhi on Rawhide, similar to how we use it for our stable/branched > > releases, with more relaxed rules (perhaps 1 day in testing or something > > simple). > > > > It may be possible to automate the process a bit to make it less heavy > > for developers, though there is some complication for multi-package > > updates (more on that in a bit). For simple package updates, we may be > > able to detect new commits on dist-git, and react to those by > > automatically starting a Koji build, and automatically filing a Bodhi > > update when that build is complete. I think that would be pretty nice, > > and pingou created a PoC[0] to do this about a year ago. > > > > Multi-package updates won't be so easy though. It's not uncommon for us > > to need to update packages together, and the above workflow would be > > problematic since it would result in updates with single packages in > > them rather than updates with multiple packages. Of course, buildroot > > overrides would be a problem too, since multi-package updates often > > depend on each other at build time too. > > > > We could create some way for packagers to indicate that a commit (or > > possibly even a whole repo) is not intended to be "autobuilt/updated". > > If the packager indicates this then their builds would go into a > > rawhide-pending (similar to what we do for f27 today). Once they have > > all their builds (and buildroot overrides) the way they want them, they > > can create the update. > > > > Another idea that was tossed around in some chats I had with people > > about this involved a system for packagers to use to create Koji side > > tags. Bodhi manages BuildRoot Overrides today (with expirations), so > > perhaps Bodhi could be expanded to also manage Koji side tags (also with > > expirations). I can't remember all the details about this approach or > > why it was suggested over the former approach, but I wanted to list it > > to invite others to chew on it and see if it could work. > > > > If you have other suggestions on how we might gate packages in Rawhide > > that are wildly different than the above, please feel free to share! > > I had a different idea in mind, basically try to keep the experience as close > as > what it is now. > for single package: > - packager commit > - packager build > - build is tagged into a specfic koji tag > - test are run on this tag > -> results go to src.fp.o > - if tests pass > - package is moved to another koji tag > - package is signed > - package is pushed to rawhide > - if tests do not pass > - do nothing > - if the user submits a waiver > - move the package to the next koji tag for signing it > If a packager does not want to run the tests, we could have a fedpkg build > --noci that would directly build the package in the koji tag used for signing > the package (useful for mass-rebuild for example) In the graphs, the red arrows are always full, i.e. signify manual steps. Is this an oversight, or are so many manual steps actually needed in that workflow? > for multi-package: > - packager requests a new side-tag (I'd propose via bodhi) > - packager build all the different packages in that side-tag > - packager asks for the side tag to be merged > - tests are run on all these packages Are those tests run will all the packages in the side-tag, or with each package separately installed onto current rawhide? I assume the first, but please clarify that. > -> results go to src.fp.o > --> We probably want to also report them on the bodhi request to merge the > tag as otherwise the packager will have to go through all the package > to > find the one(s) that failed > - if tests pass > -> cf above I see two advantages of the workflow with bodhi: - we can reuse existing reporting interfaces, for tests results, but also for user comments. In particular I expect that the integration of bodhi with greenwave and gating CI will keep changing and increasing, as required by updates for stable releases, and this would have to be duplicated in pagure, if bodhi is not used. Such features don't seem to be applicable to upstream pagure, but mostly to the src.fp.o, and it'll be an ongoing burden. - using bodhi updates gives some additional flexibility, for example we (in the future) could make the "push bodhi updates" step *non*-automatic, so that for example a
Re: Kernel updates breaking grub configuration with tuned
On Wed, Mar 28, 2018 at 2:00 PM, Christopher wrote: > On Wed, Mar 28, 2018 at 3:43 PM Chris Murphy > wrote: >> >> On Wed, Mar 28, 2018 at 12:58 PM, Christopher >> wrote: >> > So, I've been seeing this problem recently where every time I update the >> > Fedora kernel (currently F27), my grub configuration gets mangled. >> > >> > I have tuned installed, so it has installed /etc/grub.d/00_tuned, which >> > executes /etc/tuned/bootcmdline, which in turn spits out when >> > grub2-mkconfig >> > is run. >> >> What variant of Fedora are you using? I'm pretty sure only the atomic >> host variants are using grub2-mkconfig after a kernel update. >> Conventional Fedora products use grubby. >> >> What version of grubby do you have? When did you first notice the problem? >> > > It's not atomic. It's based on one of the cloud AMIs from F26 (HVM, GP2), > using grubby. I'm not sure how to trace it back to the original image I > used... I've created new AMIs since then with latest dnf updates. > > I noticed the problem after doing a DNF system-upgrade from F26 to F27 and > then subsequently installing tuned, and then after the next kernel update. > I've seen this for at least the last 4 kernel updates in Fedora 27 (at least > 3 of which involved being stuck at grub> until I finally figured out how to > fix the config file manually before rebooting) . > > Currently running fully up-to-date: > > grubby-8.40-8.fc27.x86_64 > kernel-core-4.15.12-301.fc27.x86_64 > tuned-2.9.0-1.fc27.noarch > > The following grub2 packages are installed: > > grub2-common-2.02-22.fc27.noarch > grub2-pc-2.02-22.fc27.x86_64 > grub2-pc-modules-2.02-22.fc27.noarch > grub2-tools-2.02-22.fc27.x86_64 > grub2-tools-efi-2.02-22.fc27.x86_64 > grub2-tools-extra-2.02-22.fc27.x86_64 > grub2-tools-minimal-2.02-22.fc27.x86_64 > > $ tuned-adm active > Current active profile: network-latency Looks like grubby doesn't handle ### BEGIN /etc/grub.d/00_tuned ### set tuned_initrd="" set tuned_params="skew_tick=1" ### END /etc/grub.d/00_tuned ### Offhand this seems like a weird way to insert a boot parameter. I wonder if it's effectively malforming the grub.cfg in a way that grubby then further messes up with each modification. I suggest creating a new clean grub.cfg with grub2-mkconfig, and then post that somewhere. Then run 'rpm -q --scripts -p $KERNEL_PACKAGE' then run each of the grubby commands from %post and %posttrans along with --debug and post the outputs of those somewhere along with the updated grub.cfg which should show the problem. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)
Tom Hughes wrote: > On 28/03/18 15:47, Peter Robinson wrote: > >> Personally I think the better question is why popplar has to break >> it's ABI so often? I mean it's not like the PDF spec is evolving that >> quickly, why is it so terrible and unstable that is has to change so >> much? I mean I'm sure I've seen java script implementations that have >> less churn than it! > > The soname seems to be bumped for every version, probably without > actually trying to analyse whether anything has actually changed. In fairness, poppler provides both stable/public APIs and an unstable/private(ish) one. One guess what texlive is using. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Re: Fedora 28 Candidate Beta-1.2 Available Now!
On Wed, 2018-03-28 at 09:18 -0700, Adam Williamson wrote: > On Wed, 2018-03-28 at 12:07 +, rawh...@fedoraproject.org wrote: > > According to the schedule [1], Fedora 28 Candidate Beta-1.2 is now > > available for testing. Please help us complete all the validation > > testing! For more information on release validation testing, see: > > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Heads up: this one is kinda DOA, there's no need to test it any > further. We can't reasonably ship it as Beta. > > There may be a 1.3 or we may just go with 1.1 (assuming no new blockers > emerge). > > Please continue testing 1.1 for now, there'll be another announcement > if we do a 1.3. I will revise the 'current' links to point back to 1.1 > and add a warning note to the 1.2 pages. Further heads-up: a 1.3 is running now, we'll make a choice between 1.1 and 1.3 (assuming nothing else comes up) at go/no-go tomorrow. Please continue testing 1.1 for now - the difference between 1.1 and 1.3 is small, so most tests will be valid regardless of which we pick. When 1.3 shows up, there will be an automated announcement mail, and it'd be good to get some tests run on it if we can, before tomorrow. 1.2 is entirely out of the running. :) Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel updates breaking grub configuration with tuned
On Wed, Mar 28, 2018 at 3:43 PM Chris Murphy wrote: > On Wed, Mar 28, 2018 at 12:58 PM, Christopher > wrote: > > So, I've been seeing this problem recently where every time I update the > > Fedora kernel (currently F27), my grub configuration gets mangled. > > > > I have tuned installed, so it has installed /etc/grub.d/00_tuned, which > > executes /etc/tuned/bootcmdline, which in turn spits out when > grub2-mkconfig > > is run. > > What variant of Fedora are you using? I'm pretty sure only the atomic > host variants are using grub2-mkconfig after a kernel update. > Conventional Fedora products use grubby. > > What version of grubby do you have? When did you first notice the problem? > > It's not atomic. It's based on one of the cloud AMIs from F26 (HVM, GP2), using grubby. I'm not sure how to trace it back to the original image I used... I've created new AMIs since then with latest dnf updates. I noticed the problem after doing a DNF system-upgrade from F26 to F27 and then subsequently installing tuned, and then after the next kernel update. I've seen this for at least the last 4 kernel updates in Fedora 27 (at least 3 of which involved being stuck at grub> until I finally figured out how to fix the config file manually before rebooting) . Currently running fully up-to-date: grubby-8.40-8.fc27.x86_64 kernel-core-4.15.12-301.fc27.x86_64 tuned-2.9.0-1.fc27.noarch The following grub2 packages are installed: grub2-common-2.02-22.fc27.noarch grub2-pc-2.02-22.fc27.x86_64 grub2-pc-modules-2.02-22.fc27.noarch grub2-tools-2.02-22.fc27.x86_64 grub2-tools-efi-2.02-22.fc27.x86_64 grub2-tools-extra-2.02-22.fc27.x86_64 grub2-tools-minimal-2.02-22.fc27.x86_64 $ tuned-adm active Current active profile: network-latency ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
asymptote segfaulting in rawhide/f28, maybe gcc issue?
I'm not sure if this is a gcc issue or not, but asymptote segfaults in some situations (which is causing the FTBFS, since it bootstraps itself with itself). I filed a bug upstream with the crash and gdb backtrace: https://github.com/vectorgraphics/asymptote/issues/62 If any gcc c++ people could look at it, I would appreciate it. It's one of the few FTBFS bugs I have left. ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel updates breaking grub configuration with tuned
On Wed, Mar 28, 2018 at 12:58 PM, Christopher wrote: > So, I've been seeing this problem recently where every time I update the > Fedora kernel (currently F27), my grub configuration gets mangled. > > I have tuned installed, so it has installed /etc/grub.d/00_tuned, which > executes /etc/tuned/bootcmdline, which in turn spits out when grub2-mkconfig > is run. What variant of Fedora are you using? I'm pretty sure only the atomic host variants are using grub2-mkconfig after a kernel update. Conventional Fedora products use grubby. What version of grubby do you have? When did you first notice the problem? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Kernel updates breaking grub configuration with tuned
So, I've been seeing this problem recently where every time I update the Fedora kernel (currently F27), my grub configuration gets mangled. I have tuned installed, so it has installed /etc/grub.d/00_tuned, which executes /etc/tuned/bootcmdline, which in turn spits out when grub2-mkconfig is run. ### BEGIN /etc/grub.d/00_tuned ### set tuned_initrd="" set tuned_params="skew_tick=1" ### END /etc/grub.d/00_tuned ### However, every time I update the F27 kernel, it mangles the params line, to something like: set tuned_params="skew_tick=1"=1"=1"=1"=1" The =1" can be repeated many times. (I saw it go up to something like a gigabyte once). I do not know if this is related to the "broken pipe" error I see during every kernel update, but it does seem to be a problem with tuned and grub configuration updates during postinstall for kernel-core. Every time this happens, I have to edit /etc/grub2.cfg (which points to '../boot/grub2/grub.cfg') to remove the extra =1" characters before I reboot. If I forget, the configuration file can't be read properly, and grub stops at the. grub> prompt (this is a big pain on AWS EC2, because I have to detach the drives and mount them elsewhere to fix, and then reattach). I have not seen the same problem on F27 where I run grub2-efi... I've only seen this in AWS EC2, which has grub2 installed in the MBR. I've tried to track this down to the post-install scripts, and grubby, and such, but I'm not really sure how all those tie together, and there's a lot of pieces. I did try to run shellcheck: [root@localhost ~]# shellcheck /usr/lib/kernel/install.d/* /etc/kernel/postinst.d/* /etc/grub.d/* /etc/tuned/bootcmdline It found a lot of things, but nothing stood out to me as obviously broken. I'm not sure whether to file a bug against tuned, the kernel, or grub2 (for failure to tolerate the config error), or if I should do more troubleshooting first. If more troubleshooting, I'm not sure where to start. Has anybody else seen this or know what I should try next? It does not appear to be a problem with F26. It's annoying to manually edit the grub configuration file every time I update my kernel... but currently, it's my only workaround. Thanks, Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New gdl segfaults with gcc 8 in antlr
I've just discovered that gdl appears to be segfaulting a lot now deep in the antlr c++ generated parser code with the switch to gcc 8. A bugzilla report would be nice. Run under gdb, report register contents and the instruction stream surrounding $pc, etc. Also any clues about the corresponding location in the source code. Is the SIGSEGV deterministic (reproducible every time) or random? Does memcheck (valgrind --track-origins=yes) complain? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
On Wed, Mar 28, 2018 at 09:58:13AM +0200, Florian Weimer wrote: > On 03/28/2018 06:10 AM, Kevin Fenzi wrote: > > So, is this hardware limitation something that is likely to affect other > > packages? Is there something we could look for in how they consume > > atomic types to tell? I would hate for us to ship something else that is > > subject to this problem. > > There is lots of fingerpointing, but no clear technical cause. > > We know that the (updated) i386 ABI is buggy in the sense that it does not > provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic), > and the Intel manual says that the CMPXCHG8B instructions provides atomicity > for 8-byte-aligned memory locations only. But it's not clear if this is the > cause of the observed problems. > > Note that while GCC produces broken code, this is actually an ABI bug, and > we cannot change struct layout rules for long long retroactively. Maybe we > could for _Atomic long long, but that would need a lengthy investigation, > and I strongly believe that everyone is better off if the time is spent on > improving 64-bit architectures. Does it mean that the bug was here for the last 23 years? And now this became a problem? -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
On 03/28/2018 04:46 PM, Stephen John Smoogen wrote: Just to be clear, when other 32 bit architectures don't support it.. if this code was attempted to be compiled on arm32 the compiler complains and errors? Generic 32-bit ARM does not have any 64-bit atomics at all. This is what I meant: You can't assume that 32-bit architectures have any form of 64-bit atomics. Making that assumption immediately makes your software non-portable. What that means for an application that uses them on i686 is hard to tell. Some algorithms are basically impossible to implement without 64-bit atomics. Others can just use locks as a fallback, perhaps with some loss in performance. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On 03/28/2018 12:46 PM, Vít Ondruch wrote: > And if you can do chain build in Rawhide, I can't see any reason why it > should not be possible for stable branch. It's more that it's tricky and not that it's impossible, because of the Koji buildroot. Packages built into Rawhide become part of the buildroot automatically, but packages build into f27 do not, until the package either goes stable or until a buildroot override is created. In either case, a koji chain-build will not work like it does on Rawhide, since Koji doesn't create buildroot overrides itself. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018 at 07:34:51PM +0200, Vít Ondruch wrote: > > > Dne 28.3.2018 v 19:06 Pierre-Yves Chibon napsal(a): > > On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote: > >>Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is > >>just subcase of multiplepkgs process. > > And because it is just a subcase, it can be simplified. > > > >>And if you can do chain build in Rawhide, I can't see any reason why it > >>should not be possible for stable branch. > > I'm not entirely sure where I spoke about that. > > You are proposing to use side tags for chain builds, which is not how > the things are done in stable branches, unless you are proposing the > same changes for stable branches. > > > > >>IOW the process for Rawhide should be as close to stable version as > >>possible. Using buildroot override for stable while using sidetags for > >>Rawhide does not make any sense. > > I believe we already discussed this and I provided some of the drawbacks > > this > > would have. > > It is sad you still see Rawhide as something completely different then > stable (and stabilizing) Fedoras. > > Rawhide should use the same process as > other branches. Only the built in timeouts should be different, e.g. by > default, the package should spent no time in testing etc. > > So go with buildroot overrides or sidetags, but use them everywhere. If > chainbuilds are testing of mutliple packages are important for Rawhide, > they are of the same importance for other branches. And again, this is an option, but that will affect the current workflow of all packagers. If we are fine with this then maybe it is doable but this needs to be acknowledged. > And please rename this thread to "Gating packages in Fedora", because > Rawhide should be just Fedora. You do realize that there is already gating in place for stable releases right? So no this thread is specifically about rawhide. Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
Dne 28.3.2018 v 19:06 Pierre-Yves Chibon napsal(a): > On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote: >>Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is >>just subcase of multiplepkgs process. > And because it is just a subcase, it can be simplified. > >>And if you can do chain build in Rawhide, I can't see any reason why it >>should not be possible for stable branch. > I'm not entirely sure where I spoke about that. You are proposing to use side tags for chain builds, which is not how the things are done in stable branches, unless you are proposing the same changes for stable branches. > >>IOW the process for Rawhide should be as close to stable version as >>possible. Using buildroot override for stable while using sidetags for >>Rawhide does not make any sense. > I believe we already discussed this and I provided some of the drawbacks this > would have. > > It is sad you still see Rawhide as something completely different then stable (and stabilizing) Fedoras. Rawhide should use the same process as other branches. Only the built in timeouts should be different, e.g. by default, the package should spent no time in testing etc. So go with buildroot overrides or sidetags, but use them everywhere. If chainbuilds are testing of mutliple packages are important for Rawhide, they are of the same importance for other branches. And please rename this thread to "Gating packages in Fedora", because Rawhide should be just Fedora. V. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote: >Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is >just subcase of multiplepkgs process. And because it is just a subcase, it can be simplified. >And if you can do chain build in Rawhide, I can't see any reason why it >should not be possible for stable branch. I'm not entirely sure where I spoke about that. >IOW the process for Rawhide should be as close to stable version as >possible. Using buildroot override for stable while using sidetags for >Rawhide does not make any sense. I believe we already discussed this and I provided some of the drawbacks this would have. Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is just subcase of multiplepkgs process. And if you can do chain build in Rawhide, I can't see any reason why it should not be possible for stable branch. IOW the process for Rawhide should be as close to stable version as possible. Using buildroot override for stable while using sidetags for Rawhide does not make any sense. Vít Dne 28.3.2018 v 12:52 Pierre-Yves Chibon napsal(a): > Good Morning Everyone, > > Based on the outcome of this discussion, I started trying to draw how the > process to update a package in rawhide would look like with rawhide being > gated > on tests. > > There are currently two proposals: > - one that does not involve bodhi updates > - one that does > > Both proposals have a different flow for single-package update and > multi-packages update. > > Here is what I came up with. > > Without bodhi: > - Single package update > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png > - Multi-packages update > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png > > With bodhi: > - Single package update > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png > - Multi-packages update > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png > > > Outside of this workflow things we know we want to have/keep working: > - Keep chain-build working > -> would one of the proposal facilitate that? > - Have a way to run tests against an entire side-tag before merging it > - Have a way to ask the tools to re-check greenwave's decision (so that false > negative can be waived and the process continued) > > > mizdebsk suggested on IRC two ideas which I think would be worth looking into > a little bit down the road once we got the basis done: > - new side-tag could be automatically generated from fedpkg build command > - packagers could define a list of packages that should be rebuilt in the > side-tag and when all of these packages have been successfully rebuilt, the > request to merge the side-tag is automatically created > This would allow to use chain-build and let the entire process be automated. > > > What do you think? > > > Pierre > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 Beta 1.2 compose check report
No missing expected images. Failed openQA tests: 6/137 (x86_64), 3/23 (i386), 1/2 (arm) ID: 213464 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/213464 ID: 213465 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/213465 ID: 213466 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/213466 ID: 213477 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/213477 ID: 213478 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/213478 ID: 213479 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/213479 ID: 213483 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/213483 ID: 213484 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/213484 ID: 213485 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/213485 ID: 213576 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/213576 Soft failed openQA tests: 7/137 (x86_64), 2/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 213441 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/213441 ID: 213442 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/213442 ID: 213443 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/213443 ID: 213449 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/213449 ID: 213506 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/213506 ID: 213529 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/213529 ID: 213546 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/213546 ID: 213561 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/213561 ID: 213563 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/213563 Passed openQA tests: 118/137 (x86_64), 18/23 (i386) Skipped openQA tests: 7 of 162 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
So, is this hardware limitation something that is likely to affect other packages? Is there something we could look for in how they consume atomic types to tell? I would hate for us to ship something else that is subject to this problem. <> The way I read some of the comments on the bugs in reviewing the code it seems it could just as well happen on any architecture, it's just easier to trigger (I explicitly steer clear of the term reproduce) on i686. A 64-bit atomic operation must have a memory operand that is 8-byte aligned. Not being 8-byte aligned is likely to cause problems on every architecture. In particular, if the 64-bit memory operand straddles a cache-line boundary (resides partly in one cache line and partly in the next cache line) then it may be impossible to guarantee atomic. The hardware will "try" anyway, but can produce bad results easily: double increment, total garbage, etc. If one part of the straddle is a cache hit but the other part is a miss, then chaos can result easily. https://bugzilla.redhat.com/show_bug.cgi?id=1544386#c26 and #c27 identify that alignof(long long) _in a struct_ is only 4 (and not 8) for GCC on i386. This is a mistake, perhaps in the ABI. Being aware of the deficiency, then GCC for i686 should detect badness at runtime: test $7,addr; beq OK; hlt OK: cmpxchg8b ... unless GCC can prove 8-byte aligned at compile time. The code in 389-ds-base that deals with parallelism is poor. It contains multiple problems with Memory Ordering, and needs extensive work even on 64-bit architectures. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Re: Fedora 28 Candidate Beta-1.2 Available Now!
On Wed, 2018-03-28 at 12:07 +, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 28 Candidate Beta-1.2 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan Heads up: this one is kinda DOA, there's no need to test it any further. We can't reasonably ship it as Beta. There may be a 1.3 or we may just go with 1.1 (assuming no new blockers emerge). 1.2 was an attempt to fix some issues in Atomic. It *did* fix them, but it's also broken in other cases. The changes made were to systemd, and the changes themselves included a couple of bugs we can't reasonably accept in the Beta. So 1.2 just isn't a viable candidate. Please continue testing 1.1 for now, there'll be another announcement if we do a 1.3. I will revise the 'current' links to point back to 1.1 and add a warning note to the 1.2 pages. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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 Self Contained Change: Stop building 389-ds-base on i686
>>> So, is this hardware limitation something that is likely to affect other >>> packages? Is there something we could look for in how they consume >>> atomic types to tell? I would hate for us to ship something else that is >>> subject to this problem. >> >> >> There is lots of fingerpointing, but no clear technical cause. >> >> We know that the (updated) i386 ABI is buggy in the sense that it does not >> provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic), >> and the Intel manual says that the CMPXCHG8B instructions provides atomicity >> for 8-byte-aligned memory locations only. But it's not clear if this is the >> cause of the observed problems. >> >> Note that while GCC produces broken code, this is actually an ABI bug, and >> we cannot change struct layout rules for long long retroactively. Maybe we >> could for _Atomic long long, but that would need a lengthy investigation, >> and I strongly believe that everyone is better off if the time is spent on >> improving 64-bit architectures. >> >> Applications should not use 64-bit atomics on i386. They are non-portable >> anyway because other 32-bit architectures (actually even the original i386) >> do not support them, so upstream needs alternatives anyway. >> > > Just to be clear, when other 32 bit architectures don't support it.. > if this code was attempted to be compiled on arm32 the compiler > complains and errors? I am wanting to make sure we don't have some > sort of silent snake in the other 32 bit architecture that i386 sort > of showed first? [If they use a different method on arm32, can they > use it on the i386? Or is there something about i386 not being really > i386 (aka i686 etc) that makes this impossible. ] The way I read some of the comments on the bugs in reviewing the code it seems it could just as well happen on any architecture, it's just easier to trigger (I explicitly steer clear of the term reproduce) on i686. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)
On 28/03/18 15:47, Peter Robinson wrote: Personally I think the better question is why popplar has to break it's ABI so often? I mean it's not like the PDF spec is evolving that quickly, why is it so terrible and unstable that is has to change so much? I mean I'm sure I've seen java script implementations that have less churn than it! The soname seems to be bumped for every version, probably without actually trying to analyse whether anything has actually changed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)
On Sat, Mar 24, 2018 at 9:07 AM, Tomasz Kłoczko wrote: > On 24 March 2018 at 03:14, Kevin Fenzi wrote: > [..] >>> BTW In situations like this is possible to observe how really bad idea >>> was building ALL Fedora +5.6k texlive* packages from single sec file. >> >> Except that is no longer the case. texlive-base only has ~120 or so >> subpackages for each arch and also most of the packages that are deps >> for other things. The larger 'texlive' package is now a noarch package >> that doesn't need to be rebuilt very often. > > Looking on texlive-base.spec I see ~180 packages but it is really > tiny/minor detail. > > $ grep ^%files texlive-base.spec -c; grep ^%package texlive-base.spec -c > 182 > 181 > > Good to know that (re)building all other ~5.5k texlive packages is > perfectly OK now .. > Rhetorical question: is it any and/or at least one good reason why > those ~180 texlive-base packages using ~350 source tar balls must be > (re)built always together? Personally I think the better question is why popplar has to break it's ABI so often? I mean it's not like the PDF spec is evolving that quickly, why is it so terrible and unstable that is has to change so much? I mean I'm sure I've seen java script implementations that have less churn than it! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
On 28 March 2018 at 03:58, Florian Weimer wrote: > On 03/28/2018 06:10 AM, Kevin Fenzi wrote: >> >> So, is this hardware limitation something that is likely to affect other >> packages? Is there something we could look for in how they consume >> atomic types to tell? I would hate for us to ship something else that is >> subject to this problem. > > > There is lots of fingerpointing, but no clear technical cause. > > We know that the (updated) i386 ABI is buggy in the sense that it does not > provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic), > and the Intel manual says that the CMPXCHG8B instructions provides atomicity > for 8-byte-aligned memory locations only. But it's not clear if this is the > cause of the observed problems. > > Note that while GCC produces broken code, this is actually an ABI bug, and > we cannot change struct layout rules for long long retroactively. Maybe we > could for _Atomic long long, but that would need a lengthy investigation, > and I strongly believe that everyone is better off if the time is spent on > improving 64-bit architectures. > > Applications should not use 64-bit atomics on i386. They are non-portable > anyway because other 32-bit architectures (actually even the original i386) > do not support them, so upstream needs alternatives anyway. > Just to be clear, when other 32 bit architectures don't support it.. if this code was attempted to be compiled on arm32 the compiler complains and errors? I am wanting to make sure we don't have some sort of silent snake in the other 32 bit architecture that i386 sort of showed first? [If they use a different method on arm32, can they use it on the i386? Or is there something about i386 not being really i386 (aka i686 etc) that makes this impossible. ] -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018 at 01:51:26PM +, Fabio Valentini wrote: >On Wed, Mar 28, 2018, 15:47 Pierre-Yves Chibon >wrote: > > On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote: > >Â Â One example where running tests against a single-package update > would be > >Â Â nice IMO would be for toolchain and base packages, for example, > updates to > >Â Â annobin or binutils, where the answer to "Does this update break > >Â Â compilation with GCC?" (which could be added as a test case) > would be > >Â Â vital in determining if the package should be pushed to rawhide > or not. > >Â Â Hope that makes it more clear what I meant by "it also would be > nice for > >Â Â single-package updates". > > I think I follow you there, what I don't follow is the difference > between this > and the build not landing in rawhide because it failed its tests. > > Or are you referring to: pre-commit testing, in other words pull-request > testing? > >No, that's not what I meant (although testing PRs would be nice for the >future, too). >I just wanted to express that gating rawhide updates depending on test >results is meaningful not only for the proposed merging of side-tags, but >also for single important packages. Ok then I think we're just agreeing :) It is what these diagrams are trying represent: the process of gating single package: https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
New gdl segfaults with gcc 8 in antlr
I've just discovered that gdl appears to be segfaulting a lot now deep in the antlr c++ generated parser code with the switch to gcc 8. Has anyone else run into similar issues? -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018, 15:47 Pierre-Yves Chibon wrote: > On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote: > >One example where running tests against a single-package update would > be > >nice IMO would be for toolchain and base packages, for example, > updates to > >annobin or binutils, where the answer to "Does this update break > >compilation with GCC?" (which could be added as a test case) would be > >vital in determining if the package should be pushed to rawhide or > not. > >Hope that makes it more clear what I meant by "it also would be nice > for > >single-package updates". > > I think I follow you there, what I don't follow is the difference between > this > and the build not landing in rawhide because it failed its tests. > > Or are you referring to: pre-commit testing, in other words pull-request > testing? > No, that's not what I meant (although testing PRs would be nice for the future, too). I just wanted to express that gating rawhide updates depending on test results is meaningful not only for the proposed merging of side-tags, but also for single important packages. Knowing if pushing annobin or binutils break compiling GCC before pushing > the > commit into the git repo? > So, opening a PR against annobin/binutils, running the tests and if they > pass > then push to the git repo and build in rawhide? > > If that's what you have in mind, this is definitively in the roadmap (PR > testing) but will be tracked separately from gating rawhide packages since > PR > testing will concern all branches not just rawhide. > > > Pierre > ___ > 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: Gating packages in Rawhide
On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote: >One example where running tests against a single-package update would be >nice IMO would be for toolchain and base packages, for example, updates to >annobin or binutils, where the answer to "Does this update break >compilation with GCC?" (which could be added as a test case) would be >vital in determining if the package should be pushed to rawhide or not. >Hope that makes it more clear what I meant by "it also would be nice for >single-package updates". I think I follow you there, what I don't follow is the difference between this and the build not landing in rawhide because it failed its tests. Or are you referring to: pre-commit testing, in other words pull-request testing? Knowing if pushing annobin or binutils break compiling GCC before pushing the commit into the git repo? So, opening a PR against annobin/binutils, running the tests and if they pass then push to the git repo and build in rawhide? If that's what you have in mind, this is definitively in the roadmap (PR testing) but will be tracked separately from gating rawhide packages since PR testing will concern all branches not just rawhide. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)
On 03/24/2018 05:07 AM, Tomasz Kłoczko wrote: > Rhetorical question: is it any and/or at least one good reason why > those ~180 texlive-base packages using ~350 source tar balls must be > (re)built always together? Legitimate answer: Those are the CTAN TeX components that either include (or are entirely) compiled binaries, and their immediate dependencies. It also happens to be the bare minimum environment for texlive. The binaries generated from the master source, but the surrounding TeX files (and docs) come from those other tarballs. I assure you, I have many many issues with the way that texlive upstream handles themselves, but it is what it is. ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
License tag change (EPL)
Hi Fedorans, If your package uses code under the Eclipse Public License, please take a moment and change the license tag to reflect the version. There are now two versions of the EPL, 1.0 and 2.0. Both are permitted in Fedora, neither is GPL compatible. You do not need to push an update solely to update the license tag, but correcting it in rawhide (and inheriting that change in any update to a stable branch) is greatly appreciated. Use: License: EPL-1.0 or License: EPL-2.0 as appropriate. Thanks, ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018, 14:51 Pierre-Yves Chibon wrote: > On Wed, Mar 28, 2018 at 11:16:35AM +, Fabio Valentini wrote: > >On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon > >wrote: > > Based on the outcome of this discussion, I started trying to draw > how > > the > > process to update a package in rawhide would look like with rawhide > > being gated > > on tests. > > > > There are currently two proposals: > > - one that does not involve bodhi updates > > - one that does > > > > Both proposals have a different flow for single-package update and > > multi-packages update. > > > > Here is what I came up with. > > > > Without bodhi: > > - Single package update > > Â https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png > > - Multi-packages update > > Â > > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png > > > > With bodhi: > > - Single package update > > Â > > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png > > - Multi-packages update > > Â > > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png > > > > Outside of this workflow things we know we want to have/keep > working: > > - Keep chain-build working > > Â -> would one of the proposal facilitate that? > > - Have a way to run tests against an entire side-tag before merging > it > > - Have a way to ask the tools to re-check greenwave's decision (so > that > > false > > Â negative can be waived and the process continued) > > > > mizdebsk suggested on IRC two ideas which I think would be worth > looking > > into > > a little bit down the road once we got the basis done: > > - new side-tag could be automatically generated from fedpkg build > > command > > - packagers could define a list of packages that should be rebuilt > in > > the > > Â side-tag and when all of these packages have been successfully > > rebuilt, the > > Â request to merge the side-tag is automatically created > > Â This would allow to use chain-build and let the entire process be > > automated. > > > > What do you think? > > > >Looking at your two(four) suggested workflows, they look very similar > - > >there's just bodhi sitting between components in the second case, > acting > >as a MITM, but not really adding anything useful compared to the case > >without bodhi (please correct me if I am wrong). > > They are quite close indeed. > > >So, just to state my opinion (with my packager hat on), I would > prefer the > >first case: without involving additional bodhi updates for rawhide > builds. > >Additionally, these workflows also closely resemble the current > workflows > >for submitting packages to rawhide, which is nice. > > That is also my take on it, but including bodhi has also some benefit, one > of > which is that test results for rawhide and stable releases end up there > instead > of having test results for rawhide in src.fp.o (and bodhi for the case of > multi-packages) vs bodhi for stable releases. > > That's true, but I'm not sure making the update process more complicated is worth the benefit of having test results in one place. > > >Whichever direction fedora will choose in the future, I think being > able > >to test single updates before tagging them to rawhide, and especially > >being able to run tests against whole side-tags > > I think being able to run tests on a side-tag before request for it to be > merged is a good feature, I am less sure about this for single-package. > Could you expand? > My take is that for single package: you build it, if tests pass it goes > into > rawhide (as today) if they fail, it doesn't go anywhere and as packager we > can > either fix the issue, waive their results and/or fix the test. > One example where running tests against a single-package update would be nice IMO would be for toolchain and base packages, for example, updates to annobin or binutils, where the answer to "Does this update break compilation with GCC?" (which could be added as a test case) would be vital in determining if the package should be pushed to rawhide or not. Hope that makes it more clear what I meant by "it also would be nice for single-package updates". > > Pierre > ___ > 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: Gating packages in Rawhide
On Wed, Mar 28, 2018 at 11:16:35AM +, Fabio Valentini wrote: >On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon >wrote: > Based on the outcome of this discussion, I started trying to draw how > the > process to update a package in rawhide would look like with rawhide > being gated > on tests. > > There are currently two proposals: > - one that does not involve bodhi updates > - one that does > > Both proposals have a different flow for single-package update and > multi-packages update. > > Here is what I came up with. > > Without bodhi: > - Single package update > Â https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png > - Multi-packages update > Â > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png > > With bodhi: > - Single package update > Â > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png > - Multi-packages update > Â > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png > > Outside of this workflow things we know we want to have/keep working: > - Keep chain-build working > Â -> would one of the proposal facilitate that? > - Have a way to run tests against an entire side-tag before merging it > - Have a way to ask the tools to re-check greenwave's decision (so that > false > Â negative can be waived and the process continued) > > mizdebsk suggested on IRC two ideas which I think would be worth looking > into > a little bit down the road once we got the basis done: > - new side-tag could be automatically generated from fedpkg build > command > - packagers could define a list of packages that should be rebuilt in > the > Â side-tag and when all of these packages have been successfully > rebuilt, the > Â request to merge the side-tag is automatically created > Â This would allow to use chain-build and let the entire process be > automated. > > What do you think? > >Looking at your two(four) suggested workflows, they look very similar - >there's just bodhi sitting between components in the second case, acting >as a MITM, but not really adding anything useful compared to the case >without bodhi (please correct me if I am wrong). They are quite close indeed. >So, just to state my opinion (with my packager hat on), I would prefer the >first case: without involving additional bodhi updates for rawhide builds. >Additionally, these workflows also closely resemble the current workflows >for submitting packages to rawhide, which is nice. That is also my take on it, but including bodhi has also some benefit, one of which is that test results for rawhide and stable releases end up there instead of having test results for rawhide in src.fp.o (and bodhi for the case of multi-packages) vs bodhi for stable releases. >Whichever direction fedora will choose in the future, I think being able >to test single updates before tagging them to rawhide, and especially >being able to run tests against whole side-tags I think being able to run tests on a side-tag before request for it to be merged is a good feature, I am less sure about this for single-package. Could you expand? My take is that for single package: you build it, if tests pass it goes into rawhide (as today) if they fail, it doesn't go anywhere and as packager we can either fix the issue, waive their results and/or fix the test. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)
On 03/24/2018 12:30 AM, Adam Williamson wrote: poppler was updated from 0.62.0-2 to 0.63.0-1 in Rawhide on 2018-03-23. This update bumped the soname from libpoppler.so.73 to libpoppler.so.74. This soname bump was not announced, as it is supposed to be. Hi, I'm sorry about that. I'll do the announcements from now on. Regards poppler has many dependencies. This is the list dtardon posted last time he correctly announced an soname bump: boomaga calligra cups-filters evas-generic-loaders gambas3 gdal gdcm inkscape kf5-kfilemetadata libreoffice okular pdf2djvu poppler-sharp texlive texworks These and their dependencies are now all broken. This may well break Rawhide composes until key dependencies are rebuilt. Once again, folks, *please* announce your soname bumps, and co-ordinate rebuilds. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 28 Candidate Beta-1.2 Available Now!
According to the schedule [1], Fedora 28 Candidate Beta-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/28 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.2_Security_Lab All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-28/f-28-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon wrote: > Good Morning Everyone, > Good morning! > Based on the outcome of this discussion, I started trying to draw how the > process to update a package in rawhide would look like with rawhide being > gated > on tests. > > There are currently two proposals: > - one that does not involve bodhi updates > - one that does > > Both proposals have a different flow for single-package update and > multi-packages update. > > Here is what I came up with. > > Without bodhi: > - Single package update > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png > - Multi-packages update > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png > > With bodhi: > - Single package update > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png > - Multi-packages update > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png > > > Outside of this workflow things we know we want to have/keep working: > - Keep chain-build working > -> would one of the proposal facilitate that? > - Have a way to run tests against an entire side-tag before merging it > - Have a way to ask the tools to re-check greenwave's decision (so that > false > negative can be waived and the process continued) > > > mizdebsk suggested on IRC two ideas which I think would be worth looking > into > a little bit down the road once we got the basis done: > - new side-tag could be automatically generated from fedpkg build command > - packagers could define a list of packages that should be rebuilt in the > side-tag and when all of these packages have been successfully rebuilt, > the > request to merge the side-tag is automatically created > This would allow to use chain-build and let the entire process be > automated. > > > What do you think? > > Looking at your two(four) suggested workflows, they look very similar - there's just bodhi sitting between components in the second case, acting as a MITM, but not really adding anything useful compared to the case without bodhi (please correct me if I am wrong). So, just to state my opinion (with my packager hat on), I would prefer the first case: without involving additional bodhi updates for rawhide builds. Additionally, these workflows also closely resemble the current workflows for submitting packages to rawhide, which is nice. Whichever direction fedora will choose in the future, I think being able to test single updates before tagging them to rawhide, and especially being able to run tests against whole side-tags, would be a huge improvement over the status quo, and would especially improve the stability and "composability" of rawhide (and would probably cut down on the notorious number of fedora release delays, as a result). Fabio > Pierre > ___ > 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: Orphaning ofono
I've built modem-manager-gui for F28, F27 and F26 and submitted the updates to bodhi. Thank you, Rex. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
Good Morning Everyone, Based on the outcome of this discussion, I started trying to draw how the process to update a package in rawhide would look like with rawhide being gated on tests. There are currently two proposals: - one that does not involve bodhi updates - one that does Both proposals have a different flow for single-package update and multi-packages update. Here is what I came up with. Without bodhi: - Single package update https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png - Multi-packages update https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png With bodhi: - Single package update https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png - Multi-packages update https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png Outside of this workflow things we know we want to have/keep working: - Keep chain-build working -> would one of the proposal facilitate that? - Have a way to run tests against an entire side-tag before merging it - Have a way to ask the tools to re-check greenwave's decision (so that false negative can be waived and the process continued) mizdebsk suggested on IRC two ideas which I think would be worth looking into a little bit down the road once we got the basis done: - new side-tag could be automatically generated from fedpkg build command - packagers could define a list of packages that should be rebuilt in the side-tag and when all of these packages have been successfully rebuilt, the request to merge the side-tag is automatically created This would allow to use chain-build and let the entire process be automated. What do you think? Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F29 Self Contained Change: Ansible python3 default
= Proposed Self Contained Change: Ansible python3 default = https://fedoraproject.org/wiki/Changes/Ansible_python3_default Owner(s): * Kevin Fenzi Ansible started out as a python2 only application, but in recent years a large amount of work has gone into porting things to python3. Last year, the Fedora ansible package started shipping a ansible-python3 allowing users to switch to python3 on the control host easily if they wished, but left the default as python2. Now in Fedora 29, the default will be switched and the python3 version will be the only version shipped. == Detailed description == The Fedora ansible package will be changed to default to python3 with the 'ansible' package. Note that this change is on the control host, you can control what python is used on target hosts via your inventory. You may continue to use python2 there, or use python3 as your target hosts require. == Scope == * Proposal owners: Modify ansible package (already done) * Other developers: N/A (not a System Wide Change) * Release engineering: #releng-7414 https://pagure.io/releng/7414 ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
On 03/28/2018 06:10 AM, Kevin Fenzi wrote: So, is this hardware limitation something that is likely to affect other packages? Is there something we could look for in how they consume atomic types to tell? I would hate for us to ship something else that is subject to this problem. There is lots of fingerpointing, but no clear technical cause. We know that the (updated) i386 ABI is buggy in the sense that it does not provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic), and the Intel manual says that the CMPXCHG8B instructions provides atomicity for 8-byte-aligned memory locations only. But it's not clear if this is the cause of the observed problems. Note that while GCC produces broken code, this is actually an ABI bug, and we cannot change struct layout rules for long long retroactively. Maybe we could for _Atomic long long, but that would need a lengthy investigation, and I strongly believe that everyone is better off if the time is spent on improving 64-bit architectures. Applications should not use 64-bit atomics on i386. They are non-portable anyway because other 32-bit architectures (actually even the original i386) do not support them, so upstream needs alternatives anyway. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Atomic 27-20180328.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
