Re: F24 GStreamer zero day
> On Thu, Nov 24, 2016 at 11:02:19AM -, Carlos Garnacho wrote: > > It doesn't seem to be -- I see Screen Lock, Location Services, Usage & > History, Purge Trash, and Problem Reporting. I have to to install > tracker-preferences to get a GUI for these settings, as far as I can > see. Oh, I said privacy, I meant search: Control-center > search > gear button The folders that are being indexed can be configured in that dialog. Cheers, Carlos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Upgrade path violations in F25
For the release of F25, has nobody run the upgrade path violations checker to warn packagers about any downgrades the dist update would perform? A missing zero day update [only available in updates-testing] for Claws Mail has hit users. Not great. And I hear there are other packages that get downgraded when upgrading to F25. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
On 25.11.2016 03:44, Kevin Kofler wrote: Sandro Mani wrote: AFAICS avogadro can still be built against eigen2, so sure, that would also be a plan. Not sure if reviving the package is better than bundling though, since eigen2 is completely unsupported upstream and its use not recommended [1]. I wouldn't want people starting to use the eigen2 package if it becomes available in the repos again. Another alternative would be to make an eigen32 compatibility package with 3.2. Yes, but again is it really worth the effort for just one dependent package? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Contact Björn Esser (Re: HEADS UP: eigen-3.3.0 update)
I've seen that the mails to shogun-ow...@fedoraproject.org aka fed...@besser82.io are bouncing back because the besser82.io domain isn't valid anymore. Does anyone know another way to contact him? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
line 1: udevadm: command not found
The root.log of F25 build jobs prints this late: DEBUG util.py:421: Running transaction DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: command not found DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: command not found DEBUG util.py:421: Running in chroot, ignoring request. Haven't done anything to examine it, but mention it in case somebody recognises which scriptlet it comes from. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F25 GNOME Shell notification locked up hard for some time
WTF? Noticed one notification about "File operations" in GNOME Shell, clicked on it, and the entire machine was frozen for maybe ten seconds. Mouse pointer couldn't be moved, keyboard input didn't work, couldn't switch to virtual console either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: line 1: udevadm: command not found
On 11/25/2016 01:17 PM, Michael Schwendt wrote: The root.log of F25 build jobs prints this late: DEBUG util.py:421: Running transaction DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: command not found DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: command not found DEBUG util.py:421: Running in chroot, ignoring request. Haven't done anything to examine it, but mention it in case somebody recognises which scriptlet it comes from. I don't what to exclude there could be several, but one exhibiting this issue is xorg-x11-drv-synaptics Reproducer: # mock -r fedora-25-x86_64 --clean # mock -r fedora-25-x86_64 --install xorg-x11-drv-synaptics ... Installing : xorg-x11-drv-synaptics-1.9.0-1.fc25.x86_64 33/33 /var/tmp/rpm-tmp.a3hQJY: line 1: udevadm: command not found ... Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: line 1: udevadm: command not found
On Fri, Nov 25, 2016 at 1:17 PM, Michael Schwendt wrote: > The root.log of F25 build jobs prints this late: > > DEBUG util.py:421: Running transaction > DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: command not > found > DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: command not > found > DEBUG util.py:421: Running in chroot, ignoring request. > > Haven't done anything to examine it, but mention it in case somebody > recognises > which scriptlet it comes from. it's standard thing which we did in %post for %udev_rules_update (or its plain version). We discussed this some time ago.. Nowadays systemd picks changes automatically, so no scriptlets are needed. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Fri, Nov 25, 2016 at 12:24:40PM +0100, Michael Schwendt wrote: > For the release of F25, has nobody run the upgrade path violations checker > to warn packagers about any downgrades the dist update would perform? > > A missing zero day update [only available in updates-testing] for Claws > Mail has hit users. Not great. And I hear there are other packages that > get downgraded when upgrading to F25. It seems like we should gate updates so that upgrade order is always preserved. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
- Original Message - > On 2016-11-17 07:43 AM, Stephen John Smoogen wrote: > > 2. The Fedora QA group has 1 mac mini which is very old and is only > > used for total install and not dual boot. It would not have found this > > issue. The Fedora QA group also has no one using Mac hardware day to > > day. > > This bit isn't quite true. We found the bug *on* that Mac Mini. I'm > worried it's not likely to find *other* bugs that people are likely to > encounter on the systems they actually want to run Fedora on (newer > laptops), but it did find this one. Newer Mac laptops don't have working keyboards or touchpads as they're not connected through USB internally. That's not Fedora's problem though. The problem is if the installer doesn't work when the pre-requisite hardware does. > The problem is that we didn't get around to running the test until the > day before the go/no-go. There's a lot of stuff to test, and anything > which only one person is likely to test is a risk. Frankly speaking, > given how humans work, things that involve digging some piece of > hardware you never touch out of a pile and hooking it up to a keyboard > and mouse and a monitor and power and network is quite likely to get > passed over in favour of something you can run in a VM. Especially if > it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my > desk... > > So, partly this is our fault because we could've tested this earlier and > didn't. But it's also the case that we really need more redundancy in as > much of the required testing as possible. Is there any continuous testing done on the images on the installer? Is it on real hardware? Is it possible to mock hardware setups? Comparing boot setups on working and non-working installations. I think it would be possible to do testing that didn't rely quite as much on manual testing, through regression testing on "mock" hardware (a hacked up VM with a test disk image), comparing the partition types after installation against a working setup, comparing the file lists in the boot partition, etc. I'm surprised that the Anaconda, and blivet developers aren't taking part of this conversation. I'd certainly like them to point out all the ways in which they're already doing what I mentioned, and showing how we could add more test cases. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
- Original Message - > On 17 November 2016 at 10:22, Bastien Nocera wrote: > > > > > > - Original Message - > > > >> No I am not asking for continuous testing. I am asking that if people > >> really care about the hardware support they get in the muck and do > >> just a little of the work in an organized fashion. Put together a Mac > >> SIG that focuses on getting the best experience on the hardware. Send > >> some QA people newer Macs. Otherwise how do people know that it is > >> really important to you versus "I have 4 minutes on the internet so I > >> can send a complaint email" important. Because at this point that is > >> all this looks like. > > > > So, I can't say that the problem is more systemic than what you describe > > without making it seem like I'm "sending a complaint email". Let me know > > if you want a list of hardware enablement I've done on Macs over the years. > > > > That was rude of me and I apologize. Dialing back my melodramatics.. I > will try to walk through my reasoning. > > 1. There was no proposal to drop Macs. Josh wasn't at the meeting but > said he would have argued for it at the meeting because he felt it was > too little too late. The other FESCO members seem to have disagreed > with him so it wouldn't have passed. If a proposal was made for it, it > would happen for Fedora 26 and not Fedora 25. But if the installer is (completely) broken, it might as well be dropped. Alas, it's not completely broken. > 2. The Fedora QA group has 1 mac mini which is very old and is only > used for total install and not dual boot. It would not have found this > issue. The testing should be switched to be a dual-boot test, as it's what Mac users are more likely to be using (and also a necessity for firmware upgrades). > The Fedora QA group also has no one using Mac hardware day to > day. This isn't a problem. There are people using Macs day-to-day, and they report bugs. The problem here, and I can't emphasise this enough, this problem is a systemic problem with the installer QA, specifically. Once the machine is installed, it's usually fairly straight forward to update packages, downgrade them, and fix hardware specific problems as long as the device can be booted, and a sufficient amount of hardware is working. The installer not working, especially when it's a last minute problem, it becomes a blocker. Do we need a different schedule for installer development? > 3. Out of the people who on this thread said they have Apple hardware, > at least 2 have tested Fedora 25 but they both did in a way that would > not have hit the bug but could have been work arounds IF (and ONLY IF) > it had gone out. I'm pretty sure there's plenty more folks using Fedora on Macs and testing it than just 2. Again, it shows that the problem is making sure the installer works. Dogfooding for the rest of the system is done. There are hardware-specific bug reports being done. > 4. Of the people who did have Macs but didn't test, most of them > seemed to have assumed that someone else was testing it for them OR > they didn't know how to test OR they didn't use dual boot so would not > have tested it. Given that I use my hardware for development (in this case, hardware enablement), I don't really have the time to constantly wipe and reinstall the system to test rawhide installers. I guess that most folks that already have Fedora installed on their machines will simply upgrade the system. > 5. Various people think that users of Mac hardware is the group Fedora > should focus on but they don't seem to be talking with each other > enough to say how. IMO, making sure the installer works and the bootloader is correctly installed would be enough. After that, we can rely on testers from a number of groups, whether Fedora Mac users, upstream users, etc. > So to me this says that a Macintosh Special User Group would be a > useful tool to answer 2 through 4. They could better find someone who > can rotate through the Fedora QA group to answer 2. They can also work > out what pathways may need to be tested. The people in 3 who are > testing can help the people in 4 also spread out the work. They can > also say which Mac hardware is a good fit for Fedora and which one > isn't. This can better aim people who are coming in but end up with > say some particular hardware from going in and trashing their computer > when it would not have worked without expert help. > > Does that sound better than my over the top original rant? It's better, but I don't think that the problem lies in the QA team, although some things could be done better there. The main problem to me seems to be that the installer sees too little testing, or too little testing when big changes occur, or not a wide enough breadth of testing scenarios, at the development stage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedorapro
Re: Fedora on Macs, removing the release criterion
- Original Message - > The reality is that QA is thinly spread in general. Making this > blocker "about Macs" is a misleading conclusion, there's a grain of > truth in it, but it's mistaking the forest for the trees. Next time > there's a release blocking bug, it'll just be something else. It's not "about Macs", it's about the installer and its dependencies. There are other release blocking bugs, and certainly Live images that don't work are embarrassing, but not being able to install the system is as bad as it gets. FWIW, an application included in the Live image that crashes on startup but has a 0-day update scheduled is a much smaller problem than not being able to boot the installer, or the installer working as expected. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
- Original Message - > For that sort of comparison then comparing Macs to any other consumer > desktop is not possible and is its own category of hardware. I can buy > 2-3 equivalent memory/cpu/video ASUS systems for a Macbook. Coo, we might need new computers for the GNOME events box. Can you point me to the 250$ equivalent for those: http://www.apple.com/mac-mini/specs/ ? [1] > They may > not be as well engineered or as pretty but they are functional and do > allow me to change out memory and disks much more easily than a Mac. > Does that mean we shouldn't compare them for working? If we can't then > we really need to make this a focus early on in a release with people > wanting it helping out.. They work well enough. We have people doing work upstream and downstream trying to make them work better. Except that we don't spend our time continuous testing the installer on hardware that we might only have one model of. [1]: I hate those "the Macs are too expensive/proprietary/whatever" comments. Cool, don't buy them, don't use them, but there are plenty of other crapola hardware to go around in the non-Mac computers we support, and you just don't see the amount of work done upstream for the undocumented ACPI devices to make a single button work on your laptop. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F25 GNOME Shell notification locked up hard for some time
sorry about that. Could you please report the bug at bugzilla.gnome.org/ Thanks. On Fri, Nov 25, 2016 at 1:53 PM, Michael Schwendt wrote: > WTF? > > Noticed one notification about "File operations" in GNOME Shell, clicked > on it, and the entire machine was frozen for maybe ten seconds. Mouse > pointer couldn't be moved, keyboard input didn't work, couldn't switch > to virtual console either. > ___ > 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
Fedora rawhide compose report: 20161125.n.0 changes
OLD: Fedora-Rawhide-20161124.n.0 NEW: Fedora-Rawhide-20161125.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 81 Downgraded packages: 0 Size of added packages: 727.01 KiB Size of dropped packages:0.00 B Size of upgraded packages: 1.15 GiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 26.85 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20161125.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: mingw-openal-soft-1.17.2-1.fc26 Summary: Open Audio Library RPMs:mingw32-openal-soft mingw64-openal-soft Size:744460 bytes = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: awscli-1.11.21-1.fc26 Old package: awscli-1.11.10-1.fc26 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 912362 bytes Size change: -5416 bytes Changelog: * Thu Nov 24 2016 Fabio Alessandro Locati - 1.11.21-1 - Update to 1.11.21 Package: bsh-2.0-2.b6.fc26 Old package: bsh-1.3.0-36.fc26 Summary: Lightweight Scripting for Java RPMs: bsh bsh-javadoc bsh-manual Dropped RPMs: bsh-demo bsh-utils Size: 1188034 bytes Size change: -9084 bytes Changelog: * Thu Nov 24 2016 Michael Simacek - 0:2.0-1.b6 - Update to upstream version 2.0.b6 * Thu Nov 24 2016 Michael Simacek - 0:2.0-2.b6 - Install into expected location Package: cinnamon-screensaver-3.2.6-1.fc26 Old package: cinnamon-screensaver-3.2.3-1.fc26 Summary: Cinnamon Screensaver RPMs: cinnamon-screensaver cinnamon-screensaver-unsupported Size: 1634286 bytes Size change: -29556 bytes Changelog: * Thu Nov 24 2016 leigh scott - 3.2.6-1 - update to 3.2.6 release Package: clamsmtp-1.10-18.fc26 Old package: clamsmtp-1.10-17.fc24 Summary: A SMTP virus scanning system RPMs: clamsmtp Size: 295112 bytes Size change: -7988 bytes Changelog: * Thu Nov 24 2016 Nathanael Noblet - 1.10-18 - updated readme url links - Fixes Bug #1322048 Package: cockpit-125-1.fc26 Old package: cockpit-124-1.fc26 Summary: A user interface for Linux servers RPMs: cockpit cockpit-bridge cockpit-doc cockpit-docker cockpit-kubernetes cockpit-machines cockpit-networkmanager cockpit-ostree cockpit-pcp cockpit-selinux cockpit-shell cockpit-sosreport cockpit-storaged cockpit-subscriptions cockpit-ws Size: 20744888 bytes Size change: 3135242 bytes Changelog: * Thu Nov 24 2016 Stef Walter <> - 125-1 - Cockpit is now properly translatable - Display OSTree signatures - New expandable views for storage devices - No longer offer to format read-only block devices - Use stored passphrases for LUKS devices properly - Start testing on RHEL 7.3 - More strict about transport channels a bridge accepts - System shutdown can be scheduled by date Package: console-setup-1.154-1.fc26 Old package: console-setup-1.152-1.fc26 Summary: Tools for configuring the console using X Window System key maps RPMs: console-setup Size: 1093318 bytes Size change: 164 bytes Changelog: * Thu Nov 24 2016 Vitezslav Crhonek - 1.154-1 - Update to latest upstream version Resolves: #1394588 Package: cpphs-1.20.1-2.fc26 Old package: cpphs-1.20.1-1.fc25 Summary: A liberalised C pre-processor for Haskell RPMs: cpphs ghc-cpphs ghc-cpphs-devel Size: 3810640 bytes Size change: 22384 bytes Changelog: * Fri Nov 25 2016 Jens Petersen - 1.20.1-2 - drop the modified BSD license since it is unmodified binary only - remove LGPL license file from the base package Package: crawl-0.19.1-1.fc26 Old package: crawl-0.19.0-1.fc26 Summary: Roguelike dungeon exploration game RPMs: crawl crawl-common-data crawl-tiles crawl-tiles-data Size: 53420732 bytes Size change: 11020 bytes Changelog: * Thu Nov 24 2016 Antonio Trande 0.19.1-1 - Update to 0.19.1 (bz#1398298) Package: crontabs-1.11-13.20150630git.fc26 Old package: crontabs-1.11-12.20150630git.fc24 Summary: Root crontab files used to schedule the execution of programs RPMs: crontabs Size: 23962 bytes Size change: -748 bytes Changelog: * Thu Nov 24 2016 Tom Mr??z - 1.11-13.20150630git - use Recommends to pull in cronie (#1269172) Package: devscripts-2.16.9-1.fc26 Old package: devscripts-2.16.8-1.fc26 Summary: Scripts for Debian Package maintainers RPMs: devscripts devscripts-checkbashisms devscripts-compat Size: 3233356 bytes Size change: -10352 bytes Changelog: * Thu Nov 24 2016 Sandro Mani - 2.16.9-1 - Update to 2.16.9 Package: djview4-4.10.6-4.fc26 Old package: djview4-4.10.6-3.fc25 Summary: DjVu viewer RPMs: djview4 djview4-plugi
Re: line 1: udevadm: command not found
On Sex, 2016-11-25 at 14:14 +0100, Igor Gnatenko wrote: > On Fri, Nov 25, 2016 at 1:17 PM, Michael Schwendt m> wrote: > > > > The root.log of F25 build jobs prints this late: > > > > DEBUG util.py:421: Running transaction > > DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: > > command not found > > DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: > > command not found > > DEBUG util.py:421: Running in chroot, ignoring request. > > > > Haven't done anything to examine it, but mention it in case > > somebody recognises > > which scriptlet it comes from. > it's standard thing which we did in %post for %udev_rules_update (or > its plain version). > > We discussed this some time ago.. Nowadays systemd picks changes > automatically, so no scriptlets are needed. from https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/P7NHGIP3VKWOMVHET5QMEPYMQWVIWO56/#WKVJXBRCQM3HVCBGZWNSD55OFAHZTTXY That would be great, but someone who knows all of the details would need to actually provide a draft. > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On 25 November 2016 at 14:15, Matthew Miller wrote: > On Fri, Nov 25, 2016 at 12:24:40PM +0100, Michael Schwendt wrote: >> For the release of F25, has nobody run the upgrade path violations checker >> to warn packagers about any downgrades the dist update would perform? >> >> A missing zero day update [only available in updates-testing] for Claws >> Mail has hit users. Not great. And I hear there are other packages that >> get downgraded when upgrading to F25. > > It seems like we should gate updates so that upgrade order is always > preserved. > > This is an unfortunate downside of the present freeze process to an extent ... During beta we have updates-testing enabled by default (and disable this at RC IIRC) but with the freeze in place this prevents anything moving to stable of course. This means during the beta the effect of the freeze isn't really noticed. This does make things a bit more stable for the upgrade testing (and with regards to OP there's too many packages to test everything like that which is why QA have a strictly scoped upgrade test scenario) If we gate in the way you imply though Matthew that means no updates for $current will flow during the final freeze for $next unless they have a $next freeze exception ... which could potentially be bad, or at the least just add a lot of red tape otherwise with everything requesting FE status "to preserve upgrade path" or similar. I'm honestly not sure what the best option here is ... push all of updates-testing to stable for the new release at GA? That would "solve" this but makes the actual upgrade potentially not what was tested... that said the bodhi 'gate' for $next is only 3 days after which, as soon as freeze is lifted, anything pending a stable push will go anyway... Perhaps any package that has a EVR in $previous where there is a matching (or higher) in testing for the incoming release should automatically be pushed stable to preserve the upgrade path? That also seems risky ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20161125.n.0 compose check report
Missing expected images: Workstation live i386 Kde live x86_64 Kde raw-xz armhfp Workstation live x86_64 Kde live i386 Failed openQA tests: 12/79 (x86_64), 3/15 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20161124.n.0): ID: 49751 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49751 ID: 49753 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49753 ID: 49754 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49754 ID: 49755 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49755 ID: 49816 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/49816 ID: 49822 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/49822 ID: 49825 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/49825 ID: 49843 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/49843 ID: 49844 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/49844 Old failures (same test failed in Rawhide-20161124.n.0): ID: 49756 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/49756 ID: 49769 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/49769 ID: 49782 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/49782 ID: 49803 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/49803 ID: 49817 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/49817 ID: 49820 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/49820 ID: 49834 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/49834 Passed openQA tests: 64/79 (x86_64), 12/15 (i386) New passes (same test did not pass in Rawhide-20161124.n.0): ID: 49799 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/49799 Skipped openQA tests: 1 of 96 -- 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: F24 GStreamer zero day
On Fri, 2016-11-25 at 01:46 +0100, Lars Seipel wrote: > What does that mean, exactly? Does it pass the downloaded file to > xdg-open or equivalent? "or equivalent" -- it uses Gio and not xdg-open > Just because you clicked on a link on some > website, no matter the file type and association involved? Seriously? Actually there is a list of "safe" MIME types in Epiphany, and the file is only opened if shared-mime-info thinks it's of a "safe" type. It *should* be hard to exploit shared-mime-info, so that's fine... but the safe list is pretty big and nobody has been maintaining it. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On 11/25/2016 04:36 PM, James Hogarth wrote: On 25 November 2016 at 14:15, Matthew Miller wrote: On Fri, Nov 25, 2016 at 12:24:40PM +0100, Michael Schwendt wrote: For the release of F25, has nobody run the upgrade path violations checker to warn packagers about any downgrades the dist update would perform? A missing zero day update [only available in updates-testing] for Claws Mail has hit users. Not great. And I hear there are other packages that get downgraded when upgrading to F25. It seems like we should gate updates so that upgrade order is always preserved. This is an unfortunate downside of the present freeze process to an extent ... I'm honestly not sure what the best option here is ... IMHO, it would be best to launch the "post-release" package process the very moment the freeze becomes active. I.e. * Before the freeze, packages would go "updates-testing" -> "main" * During the freeze, packages would go "updates-testing" -> "updates" with rel-eng cherry-picking individual packages from "updates" and move them to "main" to compose the "release". * After the release, packages would go "updates-testing" -> "updates" as before. This would allow packagers to continue their works in all phases of release preparations without lockouts, delays and upgrade path violations. It would also avoid the usual "flood of updates", commonly Fedora experiences in early post release weeks. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On 25 November 2016 at 09:27, Bastien Nocera wrote: > > > - Original Message - >> On 2016-11-17 07:43 AM, Stephen John Smoogen wrote: >> > 2. The Fedora QA group has 1 mac mini which is very old and is only >> > used for total install and not dual boot. It would not have found this >> > issue. The Fedora QA group also has no one using Mac hardware day to >> > day. >> >> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm >> worried it's not likely to find *other* bugs that people are likely to >> encounter on the systems they actually want to run Fedora on (newer >> laptops), but it did find this one. > > Newer Mac laptops don't have working keyboards or touchpads as they're > not connected through USB internally. That's not Fedora's problem though. > The problem is if the installer doesn't work when the pre-requisite > hardware does. > >> The problem is that we didn't get around to running the test until the >> day before the go/no-go. There's a lot of stuff to test, and anything >> which only one person is likely to test is a risk. Frankly speaking, >> given how humans work, things that involve digging some piece of >> hardware you never touch out of a pile and hooking it up to a keyboard >> and mouse and a monitor and power and network is quite likely to get >> passed over in favour of something you can run in a VM. Especially if >> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my >> desk... >> >> So, partly this is our fault because we could've tested this earlier and >> didn't. But it's also the case that we really need more redundancy in as >> much of the required testing as possible. > > Is there any continuous testing done on the images on the installer? Is it > on real hardware? Is it possible to mock hardware setups? Comparing > boot setups on working and non-working installations. > > I think it would be possible to do testing that didn't rely quite as much > on manual testing, through regression testing on "mock" hardware (a hacked > up VM with a test disk image), comparing the partition types after > installation > against a working setup, comparing the file lists in the boot partition, > etc. > > I'm surprised that the Anaconda, and blivet developers aren't taking part > of this conversation. I'd certainly like them to point out all the ways in > which they're already doing what I mentioned, and showing how we could > add more test cases. I am actually not surprised at all. This thread has been another soul-sucking, why the heck do I do anything with Fedora type thread. After this email I am not paying any more attention to anything on this thread either. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
For the release of F25, has nobody run the upgrade path violations checker to warn packagers about any downgrades the dist update would perform? A missing zero day update [only available in updates-testing] for Claws Mail has hit users. Not great. And I hear there are other packages that get downgraded when upgrading to F25. >>> >>> >>> It seems like we should gate updates so that upgrade order is always >>> preserved. >>> >>> >> >> This is an unfortunate downside of the present freeze process to an extent >> ... > > >> I'm honestly not sure what the best option here is ... > > > IMHO, it would be best to launch the "post-release" package process the very > moment the freeze becomes active. We do, the first updates to stable were done Friday night/Sat morning before the release. I did another one on the Sunday and I believe there was one done on the Monday too. > I.e. > > * Before the freeze, packages would go > "updates-testing" -> "main" > > * During the freeze, packages would go > "updates-testing" -> "updates" > with rel-eng cherry-picking individual packages from "updates" and move them > to "main" to compose the "release". No, once the release is signed off everything goes to updates. As soon as we know the release is gold we do a freeze break request to update bodhi configs and start the push process for f25-updates. > * After the release, packages would go > "updates-testing" -> "updates" > as before. > > This would allow packagers to continue their works in all phases of release > preparations without lockouts, delays and upgrade path violations. > It would also avoid the usual "flood of updates", commonly Fedora > experiences in early post release weeks. So we already do pretty much what you outline above. I started the first push to f25-updates on the Friday before the release. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On 11/25/2016 05:51 PM, Peter Robinson wrote: So we already do pretty much what you outline above. I started the first push to f25-updates on the Friday before the release. I think, we are talking past each other. You seem to be referring to "the freeze" in terms of the final release push, while I am talking about what you'd probably call alpha or beta stage. Actually, I am referring to the stage of the release preparations, when rel-eng stops pushing packages from "update-testing" to "main". This stage, in case of f25, has taken ca. 3-4 weeks (IIRC). During this stage, many fc25 updates stalled in updates-testing, while their fc23/fc24/rawhide counterparts had been pushed into "main" => broken update paths. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
On Fri, 25 Nov 2016 03:19:49 +0100 Kevin Kofler wrote: > Peter Robinson wrote: > > Well the koji web interface itself doesn't use authentication > > anymore, from a fedpkg PoV there's a lot of complexity with http(s) > > because it could be proxied or NATed (worst is CG-NAT) so the same > > connection from the same laptop might not even come via the same > > IP. Basically what you're describing is exactly what kerberos > > solves, tokens to authenticate various different connections. > > My point is, just use SSH instead of HTTP(S) as the transport. You > could even tunnel HTTP over an SSH tunnel after you let SSH > authenticate the other end, if you really need an HTTP API. (Not much > point in using HTTPS over the already encrypted SSH.) Do you know of any applications at all that use this? Is there any python code available to setup such authentication? Kerberos is used all over the place by lots and lots of groups and has had many years of auditing and actually you know, exists. > > A lot of companies and data security standards explicitly disallow > > ssh keys because of the fact it's client side pass phrases with no > > way to enforce a policy so there's no way to tell even if the key > > has a passphrase. > > And that is what I like about SSH. :-) I decide the level of security > I actually need for my key, not somebody else. Which is fine up until the point someone compromises your machines and uses your access to mess up everyone else. > And we already trust SSH authentication for access to dist-git, so I > don't see why it would not be good enough for Koji as well. Because it would require a bunch of coding and then we would be a special little snowflake. > > Personally I'd like to see eventually the move to kerberos to > > replace ssh- keys as it's easier to enforce a minimum policy and > > manage. > > Kinit just takes a password, automating it to pick the password from > any password store or even a plaintext file and then run > automatically on startup and automatically renew expired tickets is > not that hard. It will just be a minor annoyance until one of us > writes the automation tool, and do nothing to enforce any kind of > policy on us. No need to invent all this again, you can just use a keytab. > The infrastructure really needs to work for us, not against us. I'm happy to work with anyone to improve things. That said, we don't have a bunch of developers sitting around waiting to implement people's ideas, so sometimes we have to say "sorry, no" or "sorry, we can't do that now, but happy to look at it again later". I think kerberos is a very good improvement over the current setup. I hope (most)everyone else does too. kevin pgpa7Ms69n76c.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
>> So we already do pretty much what you outline above. I started the >> first push to f25-updates on the Friday before the release. > > I think, we are talking past each other. > > You seem to be referring to "the freeze" in terms of the final release push, > while I am talking about what you'd probably call alpha or beta stage. > > Actually, I am referring to the stage of the release preparations, when > rel-eng stops pushing packages from "update-testing" to "main". > > This stage, in case of f25, has taken ca. 3-4 weeks (IIRC). > During this stage, many fc25 updates stalled in updates-testing, while their > fc23/fc24/rawhide counterparts had been pushed into "main" => broken update > paths. Yes, but they will be resolved before GA ships assuming the maintainers have pushed them stable. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Fabio Valentini (decathorpe)
Hello, Fabio. Welcome to Fedora community! On Thursday, 24 November 2016 at 22:34, Fabio Valentini wrote: > Here goes my introduction as a new (or aspiring) package maintainer for > fedora. > > I have been using fedora as my daily driver OS for some years now (I > think starting with f18 or f19). Also, I have been learning to build > RPM packages for some time, too - some of you may be familiar with my > elementary-stable/nightly and/or syncthing COPR repositories. > > And now I decided the time has come to begin submitting my elementary > packages for review :) I am already in frequent contact with the > upstream developers, who have - most of the time - been really helpful > with fixing issues of portability and compatibility with fedora. Excellent! Having good relationship with our upstreams is invaluable and - as you probably know - part of our core values. > My first review request can be found at [1]. Great, I'll take a look. Could you do some non-binding reviews of other packages awaiting reviews in the meantime? Two should be enough. > To give some more background about myself: > > I am currently studying Computer Science and Chemistry at the > University of Innsbruck / Austria (and yes, my native language is > German). I have some experience writing C and Java code (mostly > because of University courses) and have taught myself some Python, > too. I am also currently undergoing the "functional programming > treatment" (with OCaml). Excellent, we have a number of chemistry-related packages in Fedora already, as well as quite a few maintainers in this area. You're welcome to join the SciTech SIG: https://fedoraproject.org/wiki/Category:SciTech_SIG > Probably the project that I am most proud of (aside from packaging / > my COPR repositories) is a simple, configurable and modular build tool > for automatically constructing RPM packages (written in python3): > kentauros (you can find it on github) - but it is far from finished > yet (although I am already heavily using it for stable and automagic > nightly builds for my COPR repositories). Cool! Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
On Friday, 25 November 2016 at 12:58, Sandro Mani wrote: > > > On 25.11.2016 03:44, Kevin Kofler wrote: > > Sandro Mani wrote: > > > AFAICS avogadro can still be built against eigen2, so sure, that would > > > also be a plan. Not sure if reviving the package is better than bundling > > > though, since eigen2 is completely unsupported upstream and its use not > > > recommended [1]. I wouldn't want people starting to use the eigen2 > > > package if it becomes available in the repos again. > > Another alternative would be to make an eigen32 compatibility package with > > 3.2. > Yes, but again is it really worth the effort for just one dependent package? Probably not. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
2016-11-25 17:37 GMT+01:00 Stephen John Smoogen : > On 25 November 2016 at 09:27, Bastien Nocera wrote: >> >> >> - Original Message - >>> On 2016-11-17 07:43 AM, Stephen John Smoogen wrote: >>> > 2. The Fedora QA group has 1 mac mini which is very old and is only >>> > used for total install and not dual boot. It would not have found this >>> > issue. The Fedora QA group also has no one using Mac hardware day to >>> > day. >>> >>> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm >>> worried it's not likely to find *other* bugs that people are likely to >>> encounter on the systems they actually want to run Fedora on (newer >>> laptops), but it did find this one. >> >> Newer Mac laptops don't have working keyboards or touchpads as they're >> not connected through USB internally. That's not Fedora's problem though. >> The problem is if the installer doesn't work when the pre-requisite >> hardware does. >> >>> The problem is that we didn't get around to running the test until the >>> day before the go/no-go. There's a lot of stuff to test, and anything >>> which only one person is likely to test is a risk. Frankly speaking, >>> given how humans work, things that involve digging some piece of >>> hardware you never touch out of a pile and hooking it up to a keyboard >>> and mouse and a monitor and power and network is quite likely to get >>> passed over in favour of something you can run in a VM. Especially if >>> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my >>> desk... >>> >>> So, partly this is our fault because we could've tested this earlier and >>> didn't. But it's also the case that we really need more redundancy in as >>> much of the required testing as possible. >> >> Is there any continuous testing done on the images on the installer? Is it >> on real hardware? Is it possible to mock hardware setups? Comparing >> boot setups on working and non-working installations. >> >> I think it would be possible to do testing that didn't rely quite as much >> on manual testing, through regression testing on "mock" hardware (a hacked >> up VM with a test disk image), comparing the partition types after >> installation >> against a working setup, comparing the file lists in the boot partition, >> etc. >> >> I'm surprised that the Anaconda, and blivet developers aren't taking part >> of this conversation. I'd certainly like them to point out all the ways in >> which they're already doing what I mentioned, and showing how we could >> add more test cases. > > I am actually not surprised at all. This thread has been another > soul-sucking, why the heck do I do anything with Fedora type thread. > After this email I am not paying any more attention to anything on > this thread either. > I kind of fail to see how this thread is "soul-sucking", but then again there are lots of things I don't understand. But anyway, it is sad that you feel this way about Fedora. /Andreas > > -- > Stephen J Smoogen. > ___ > 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: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto: >> I think it would be nice to make a discussion even for non Python >> packages, so we can elaborate a sort of vademecum that a packager >> could show to upstreams when there is a collaboration between them. >> >> Have a nice day > Most upstream developers are happy to work with segregating > components. A few... such as the awscli python package manager. > use cfode with very bleeding edge and destabilizing dependencies. Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to the upstream (Federico Capoano), in order to make the work easier for both us and him? Thank you [1]: https://github.com/interop-dev/django-netjsongraph [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Contact Björn Esser (Re: HEADS UP: eigen-3.3.0 update)
Hi Sandro, I've contacted him via Facebook and told him that you're trying to contact him. I think he'll response soon. Greetings, Christian On 11/25/2016 01:00 PM, Sandro Mani wrote: > I've seen that the mails to shogun-ow...@fedoraproject.org aka > fed...@besser82.io are bouncing back because the besser82.io domain > isn't valid anymore. Does anyone know another way to contact him? > ___ > 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: Upgrade path violations in F25
James Hogarth wrote: > This is an unfortunate downside of the present freeze process to an extent > ... Another main source of this issue is autokarma. IMHO, autokarma should NEVER be used (and should be dropped from Bodhi entirely), because it inherently breaks upgrade paths. (The solution for that would be to group the updates across releases and use one global karma value to trigger the pushes for all releases, but FESCo vetoed that approach. As long as this is not done for political reasons, autokarma will remain totally unsafe and unusable.) Unfortunately, the Bodhi developers are almost forcing everyone to use autokarma by not fixing these web UI bugs for over a month: https://github.com/fedora-infra/bodhi/issues/1032 https://github.com/fedora-infra/bodhi/issues/1033 (and note that #1033 is about a non-working fix for the almost 10-month-old #772 – they took 8½ months to deploy a non-functional "fix") and not supporting editing existing updates from the CLI: https://github.com/fedora-infra/bodhi/issues/1125 If people were ensuring that manual pushes are actually workable again, and if we would then start strongly discouraging (or ideally outright banning) autokarma, we would NOT have as many broken upgrade paths. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Fri, 2016-11-25 at 18:38 +0100, Ralf Corsepius wrote: > On 11/25/2016 05:51 PM, Peter Robinson wrote: > > > So we already do pretty much what you outline above. I started the > > first push to f25-updates on the Friday before the release. > > I think, we are talking past each other. > > You seem to be referring to "the freeze" in terms of the final release > push, while I am talking about what you'd probably call alpha or beta stage. > > Actually, I am referring to the stage of the release preparations, when > rel-eng stops pushing packages from "update-testing" to "main". That only stops at the Final freeze point. After Final freeze, only freeze exception / blocker bug fixes are pushed to what you call 'main'. Before that, all updates go to 'main' when pushed 'stable' by Bodhi. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Fri, 2016-11-25 at 21:09 +0100, Kevin Kofler wrote: > > If people were ensuring that manual pushes are actually workable again, and > if we would then start strongly discouraging (or ideally outright banning) > autokarma, we would NOT have as many broken upgrade paths. It's worth remembering that upgrade path breakage really isn't that big of a deal these days. dnf-system-upgrade has done a distro-sync (not 'upgrade') for several releases now, and the instructions for upgrading directly with dnf similarly instruct you to do a distro-sync. So most upgrade path 'issues' really just aren't that big of a problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera wrote: > > But if the installer is (completely) broken, it might as well be dropped. > Alas, it's not completely broken. Unwieldy, perhaps. It's kinda hard to argue that the installer needs to be this complicated, that Fedora (mainly QA) has to put in so much effort into the installer each cycle testing for bugs in new features and also regressions. > >> 2. The Fedora QA group has 1 mac mini which is very old and is only >> used for total install and not dual boot. It would not have found this >> issue. > > The testing should be switched to be a dual-boot test, as it's what > Mac users are more likely to be using (and also a necessity for firmware > upgrades). The firmware angle is a very good point. Ostensibly the firmware could be downloaded, extracted and placed on the FAT32 volume (that Fedora doesn't use) in the proper location, and NVRAM pointed to that firmware file, and the firmware will consume it and thereby update the firmware, without needing macOS. But the path of least resistance is having a minimal macOS installed, even if it's not otherwise used. > >> The Fedora QA group also has no one using Mac hardware day to >> day. > > This isn't a problem. There are people using Macs day-to-day, and they report > bugs. The problem here, and I can't emphasise this enough, this problem is > a systemic problem with the installer QA, specifically. Automated testing is problematic because it's not really possible to virtualize Macs. The various guides for using kvm to virtualize macOS actually use BIOS firmware, not UEFI, and one of several hacked up bootloaders (e.g. Chameleon) is use to fake out XNU into booting on non-Apple hardware. On these systems, there is no EFI System partition of either the FAT32 or HFS+ variety, so it wouldn't test the installer behavior we need to test. I don't know what work would be needed to get Beaker to help do baremetal installations of Fedora on Mac hardware, and if that is sufficiently not fakey that it'd be a valid test. So for now it's a manual test. And as the installer regressions can come at any time, it's a lot of manual testing, and in this particular case it's not enough to just test if the install media boots, and the installer launches, an installation writing to the drive must be done. > Once the machine is installed, it's usually fairly straight forward to > update packages, downgrade them, and fix hardware specific problems as long > as the device can be booted, and a sufficient amount of hardware is working. > > The installer not working, especially when it's a last minute problem, > it becomes a blocker. Do we need a different schedule for installer > development? I'm pretty confident this bug was in Rawhide before F25 branch. I'm also pretty confident, looking at the Mac I use for testing, that the small HFS+ volume Anaconda creates and uses as an EFI system partition only on Macs, was already present for each of the tests I did, and that's why I never ran into the problem. It looks virtually certain I did not in fact have completely free space for the installations, everything but the three Apple creates partitions (FAT32 ESP, macOS main volume, macOS recovery volume), and the Fedora HFS+ ESP were deleted, but the presence of that one Fedora HFS+ ESP was seemingly enough for me to not hit the bug. So it can't be proven that this is a case of insufficient testing; it's a case of testing that was imprecise or was just not thorough. Possibly there should be a single Mac test case that asks for a very explicit setup, with instructions on how to get to that state using a path of least resistance, to just test the most minimal "get from A to B" path, instead of 2-3 or more ways to get there. So at least we have the most common and simple path tested, and flagged earlier on in the release cycle that it hasn't been tested. > It's better, but I don't think that the problem lies in the QA team, > although some things could be done better there. > > The main problem to me seems to be that the installer sees too little > testing, or too little testing when big changes occur, or not a wide > enough breadth of testing scenarios, at the development stage. I had no idea macefi stuff was touched. If I'd known this, I'd probably have been more skeptical and vigilant how I was testing, instead of becoming more trusting of the installer (and more complacent of its, in my opinion, inevitable betrayal) - but that's rather circular logic on my part. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, 2016-11-25 at 13:53 -0700, Chris Murphy wrote: > On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera wrote: > > > > > But if the installer is (completely) broken, it might as well be dropped. > > Alas, it's not completely broken. > > Unwieldy, perhaps. It's kinda hard to argue that the installer needs > to be this complicated, that Fedora (mainly QA) has to put in so much > effort into the installer each cycle testing for bugs in new features > and also regressions. > > > > > > > 2. The Fedora QA group has 1 mac mini which is very old and is only > > > used for total install and not dual boot. It would not have found this > > > issue. > > > > The testing should be switched to be a dual-boot test, as it's what > > Mac users are more likely to be using (and also a necessity for firmware > > upgrades). > > The firmware angle is a very good point. But you were wrong in the first place. We *do* test dual boot installs on that Mac, when we test anything on it. As I said already. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, 2016-11-25 at 09:26 -0500, Bastien Nocera wrote: > > > 2. The Fedora QA group has 1 mac mini which is very old and is only > > used for total install and not dual boot. It would not have found this > > issue. > > The testing should be switched to be a dual-boot test, as it's what > Mac users are more likely to be using (and also a necessity for firmware > upgrades). Chris was incorrect about this. When we actually do have time to run Mac tests, we test dual boot installs. > > The Fedora QA group also has no one using Mac hardware day to > > day. > > This isn't a problem. There are people using Macs day-to-day, and they report > bugs. The problem here, and I can't emphasise this enough, this problem is > a systemic problem with the installer QA, specifically. > Once the machine is installed, it's usually fairly straight forward to > update packages, downgrade them, and fix hardware specific problems as long > as the device can be booted, and a sufficient amount of hardware is working. > > The installer not working, especially when it's a last minute problem, > it becomes a blocker. Do we need a different schedule for installer > development? This was a 'last minute bug' in the sense that we *found* it at the last minute. It was not a 'last minute bug' in the sense that it was *introduced* at the last minute. The bug was in fact introduced to blivet master almost exactly a year ago: https://github.com/rhinstaller/blivet/commit/368a4db6141c7fdcb31ed45fe6be207ccc08ad30 If you're operating under the belief that there is some sort of pell- mell development process involved here, then you're off-base. That is not the case. The developers are in fact quite conservative about the level of change they pull into Branched - more conservative than the Fedora policies require. > Given that I use my hardware for development (in this case, hardware > enablement), I don't really have the time to constantly wipe and reinstall > the system to test rawhide installers. I guess that most folks that already > have Fedora installed on their machines will simply upgrade the system. Yes. This is exactly the point I argued way down-thread. It is true to say that not many people test the installer on Macs. Some people initially argued that we could take this to mean not many people *use* Fedora on Macs, but I'd argue that's not true. The truth, I believe, is that a reasonable number of people run Fedora on Macs - enough to be worth caring about - but very few people test the installer on Macs. This is an issue specific to Macs, rather than a 'systemic problem with installer development'. > The main problem to me seems to be that the installer sees too little > testing, or too little testing when big changes occur, or not a wide > enough breadth of testing scenarios, at the development stage. This is true only in the sense that, let's be honest, it applies to almost every piece of code ever. No-one ever tests *everything*. But in fact we probably test the installer more than we test almost anything else. It is also, unfortunately, an inherently incredibly complex codebase with more codepaths than almost anything else, many of which are not trivial to exercise. Like this one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, 2016-11-25 at 09:27 -0500, Bastien Nocera wrote: > > > The problem is that we didn't get around to running the test until the > > day before the go/no-go. There's a lot of stuff to test, and anything > > which only one person is likely to test is a risk. Frankly speaking, > > given how humans work, things that involve digging some piece of > > hardware you never touch out of a pile and hooking it up to a keyboard > > and mouse and a monitor and power and network is quite likely to get > > passed over in favour of something you can run in a VM. Especially if > > it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my > > desk... > > > > So, partly this is our fault because we could've tested this earlier and > > didn't. But it's also the case that we really need more redundancy in as > > much of the required testing as possible. > > Is there any continuous testing done on the images on the installer? Is it > on real hardware? Is it possible to mock hardware setups? Comparing > boot setups on working and non-working installations. I don't know what you mean by "the images on the installer", and I don't know precisely what you mean by "mock hardware setups". Mock what about them, in what way, exactly? To take the specific example we're starting from here, if you mean 'can we fake up something like an OS X dual boot install on a virtual machine', the answer is kinda yes, but it's not entirely straightforward. I actually did this in order to test my fix for the bug, but as well as faking up a disk layout that approximated an OS X install, I had to patch anaconda to think the system was a Mac (I just sabotaged that check to always return True) and provide that patch as an anaconda updates.img. Otherwise anaconda would've known the system wasn't a Mac and wouldn't have hit the right code path. > I think it would be possible to do testing that didn't rely quite as much > on manual testing, through regression testing on "mock" hardware (a hacked > up VM with a test disk image), comparing the partition types after > installation > against a working setup, comparing the file lists in the boot partition, > etc. We do rather a lot of automated testing of the installer, in fact: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20161125.n.0&groupid=1 is a current Rawhide test run (missing some tests as some images are missing) https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=25&groupid=1&build=Fedora-25-20161115.0 is the Fedora 25 Final automated test run (with all tests) Those tests are run on every 'nightly' Branched and Rawhide compose, and on all 'candidate' Branched composes. (We also run the Atomic ostree installer test on the two-week Atomic nightlies). Reports from these tests are mailed to this list every day, under the title "Compose check report". I frequently reply to them with details about the bugs the tests found. We could, of course, do a lot *more* of this testing. Just personally I've got a list of about 30 things I want to add to the test set. But there's only two and a half people working on the openQA tests, and we have other stuff to do as well. And of course we have to monitor the tests that *are* run, investigate the bugs they discover, file them, and follow up on them. I should probably note some RH inside baseball at this point: there's a general theme in RH at present that people would like to have less divergence between Fedora and RHEL testing processes, specifically it would be nice to have some of the testing that RH's release test team does on RHEL builds done on Fedora builds too. Most of those tests run on Beaker; Fedora technically has a Beaker instance but it's not sufficiently set up for us to be able to actually run the tests RH has on it yet. That whole 'oh just get Fedora a Beaker setup, shouldn't be hard right?!' problem is dumped on tflink's lap at present. Like everyone else, he has a million other things to do and that one isn't his highest priority, and he also keeps getting roadblocked on it by things that are out of his control, AIUI. Once we have a usable Beaker instance we can try importing some of RH's tests to it and setting them up to run on Fedora, though I would be *utterly* unsurprised if that turns out to be a lot more work than it sounds like. We currently run all openQA tests on virtual machines. openQA *does* in fact have the necessary bits to run tests on bare metal - SUSE does this - but we don't do that and haven't investigated the possibility in detail yet. Fedora's openQA instances are in PHX, so it'd a
Re: Fedora on Macs, removing the release criterion
On Fri, Nov 25, 2016 at 1:59 PM, Adam Williamson wrote: > On Fri, 2016-11-25 at 13:53 -0700, Chris Murphy wrote: >> On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera wrote: >> >> > >> > But if the installer is (completely) broken, it might as well be dropped. >> > Alas, it's not completely broken. >> >> Unwieldy, perhaps. It's kinda hard to argue that the installer needs >> to be this complicated, that Fedora (mainly QA) has to put in so much >> effort into the installer each cycle testing for bugs in new features >> and also regressions. >> >> >> > >> > > 2. The Fedora QA group has 1 mac mini which is very old and is only >> > > used for total install and not dual boot. It would not have found this >> > > issue. >> > >> > The testing should be switched to be a dual-boot test, as it's what >> > Mac users are more likely to be using (and also a necessity for firmware >> > upgrades). >> >> The firmware angle is a very good point. > > But you were wrong in the first place. We *do* test dual boot installs > on that Mac, when we test anything on it. As I said already. I never said or previously suggested the tests aren't predicated on dual boot. What I just did today, is reply to someone else making that assertion without correcting it. I know the installation tests are dual boot, following a restore of macOS. But my understanding is the Mac Mini isn't generally running macOS; it's running Fedora. Unless that system run Mac OS and any update notifications for firmware updates are responded to and then applied to the system, it's not getting firmware updates. It's pretty unlikely missing firmware updates are going to affect Fedora testing, but... -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote: > I know the installation tests are > dual boot, following a restore of macOS. Um. But *you* are the person who wrote: "2. The Fedora QA group has 1 mac mini which is very old and is only used for total install and not dual boot. It would not have found this issue." -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson wrote: > On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote: >> I know the installation tests are >> dual boot, following a restore of macOS. > > Um. But *you* are the person who wrote: > > "2. The Fedora QA group has 1 mac mini which is very old and is only > used for total install and not dual boot. It would not have found this > issue." That was Not Me. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y2H2PXK63EALDXDCBII45OMOBZDNG4HY -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On 25 November 2016 at 17:17, Chris Murphy wrote: > On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson > wrote: >> On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote: >>> I know the installation tests are >>> dual boot, following a restore of macOS. >> >> Um. But *you* are the person who wrote: >> >> "2. The Fedora QA group has 1 mac mini which is very old and is only >> used for total install and not dual boot. It would not have found this >> issue." > > That was Not Me. > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y2H2PXK63EALDXDCBII45OMOBZDNG4HY > It was me, and I was wrong on that and other points in this email. At some point my authoring of that point was removed from the thread so it got misattributed to Chris. [I am only responding here to qualify that I was the problem here.] > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, 2016-11-25 at 15:17 -0700, Chris Murphy wrote: > On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson > wrote: > > On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote: > > > I know the installation tests are > > > dual boot, following a restore of macOS. > > > > Um. But *you* are the person who wrote: > > > > "2. The Fedora QA group has 1 mac mini which is very old and is only > > used for total install and not dual boot. It would not have found this > > issue." > > That was Not Me. Ah, sorry, you're right. I was misled by the quoting... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Sex, 2016-11-25 at 17:55 +, Peter Robinson wrote: > > > > > > > > So we already do pretty much what you outline above. I started > > > the > > > first push to f25-updates on the Friday before the release. > > I think, we are talking past each other. > > > > You seem to be referring to "the freeze" in terms of the final > > release push, > > while I am talking about what you'd probably call alpha or beta > > stage. > > > > Actually, I am referring to the stage of the release preparations, > > when > > rel-eng stops pushing packages from "update-testing" to "main". > > > > This stage, in case of f25, has taken ca. 3-4 weeks (IIRC). > > During this stage, many fc25 updates stalled in updates-testing, > > while their > > fc23/fc24/rawhide counterparts had been pushed into "main" => > > broken update > > paths. > Yes, but they will be resolved before GA ships assuming the > maintainers have pushed them stable. I liked the "post-release" idea but in other terms, in 3-4 weeks we got more than 500 packages sent to updates stable, IMHO we should push it to base and respin again, test it for 3 or 4 days and do GA , or maybe more simple after respin it and call it release N.1 (25.1) . I believe in last 4 week before GA, packages send to stable are bug fixes or not core packages etc, if test goes wrong we may postpone the GA. Every release we got always tones of updates in day 0, on upgrades and non-live versions everyone will update the computer , if we use netinstall iso already include updates, only live versions could have breaks , but shouldn't be a better live version with the 500 packages updated ? Last time that we talk about this, the strongest argument was no man power to test 2 versions, ok so before begging test the new version , give it a spin of stability on release version , that is my idea. Cheers, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Sat, 2016-11-26 at 02:24 +, Sérgio Basto wrote: > Every release we got always tones of updates in day 0, on upgrades and > non-live versions everyone will update the computer , if we use > netinstall iso already include updates, only live versions could have > breaks , but shouldn't be a better live version with the 500 packages > updated ? If we were going to do this, there would be no point having a freeze in the first place. It'd be absurd to have a freeze, then cut release images that ignored it. The reason for the freeze is to ensure that *the install / deployment processes themselves* are known quantities. Even if you do a network install, the code in the installer environment itself is the release- frozen code. It deploys updated packages, but the installer itself does not *use* them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On 11/25/2016 06:55 PM, Peter Robinson wrote: So we already do pretty much what you outline above. I started the first push to f25-updates on the Friday before the release. I think, we are talking past each other. You seem to be referring to "the freeze" in terms of the final release push, while I am talking about what you'd probably call alpha or beta stage. Actually, I am referring to the stage of the release preparations, when rel-eng stops pushing packages from "update-testing" to "main". This stage, in case of f25, has taken ca. 3-4 weeks (IIRC). During this stage, many fc25 updates stalled in updates-testing, while their fc23/fc24/rawhide counterparts had been pushed into "main" => broken update paths. Yes, but they will be resolved before GA ships assuming the maintainers have pushed them stable. I do not understand. I feel, we still are talking about different subjects. AFAICT, this did not happen with fc25. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On 11/25/2016 09:44 PM, Adam Williamson wrote: On Fri, 2016-11-25 at 18:38 +0100, Ralf Corsepius wrote: On 11/25/2016 05:51 PM, Peter Robinson wrote: So we already do pretty much what you outline above. I started the first push to f25-updates on the Friday before the release. I think, we are talking past each other. You seem to be referring to "the freeze" in terms of the final release push, while I am talking about what you'd probably call alpha or beta stage. Actually, I am referring to the stage of the release preparations, when rel-eng stops pushing packages from "update-testing" to "main". That only stops at the Final freeze point. After Final freeze, only freeze exception / blocker bug fixes are pushed to what you call 'main'. OK. This is the harmful stage, I am talking about. I think this stage is fundamentally flawed and needs to be redesigned. To provide so detail about this harm: I have been trying to push a package chain consisting of 2 new packages, which are required to update a 3 package, to Fedora: The first package hit "the freeze". It took ~3 weeks to make it to fc25 stable. The second package could not be built before the first packages was in fc25. It was build when the freeze was lifted, summing up to an overall delay in order of 4-5 weeks. IIRC, the 2nd package is stuck in updates-testing. Of course the fc23/fc24 have been release. Before that, all updates go to 'main' when pushed 'stable' by Bodhi. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Sat, 2016-11-26 at 06:26 +0100, Ralf Corsepius wrote: > I have been trying to push a package chain consisting of 2 new > packages, > which are required to update a 3 package, to Fedora: > > The first package hit "the freeze". It took ~3 weeks to make it to > fc25 > stable. The second package could not be built before the first > packages > was in fc25. It was build when the freeze was lifted, summing up to > an > overall delay in order of 4-5 weeks. IIRC, the 2nd package is stuck > in > updates-testing. Perhaps using Bodhi's buildroot override system could help with this problem: https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upgrade path violations in F25
On Sat, 2016-11-26 at 06:09 +0100, Ralf Corsepius wrote: > > I do not understand. I feel, we still are talking about different subjects. > > AFAICT, this did not happen with fc25. There was a 0-day update push well before F25 was released. Any remaining upgrade path issues aren't caused by the freeze, they're just the normal cases caused by the 24 update getting more karma or whatever. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
