Re: python-mne: testing stuck in koji
I think I will get the same results... But I will try. On Sun, Dec 6, 2015, 8:51 AM Dan Horák wrote: > On Sun, 06 Dec 2015 03:52:56 + > Igor Gnatenko wrote: > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=12011291 > > > > I've tried to resubmit build many times, but it stuck on one of > > tests. How I can debug this problem? It works perfectly on my laptop > > in mock. > > I would try to replicate the koji build environment as close as > possible - be the host F-23, same kernel version (listed in root.log), > use the same repo for resolving build dependencies > (baseurl=http://koji.fedoraproject.org/repos/f24-build/551296/i386) and > the same arch (i686). It must behave the same then :-) > > > Dan > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
Am 06.12.2015 um 04:26 schrieb Kevin Kofler: Mathieu Bridon wrote: Note that packages installed by PackageKit are not marked as installed, so dnf always thinks it can remove them. This makes "autoremove" completely unsuitable for end users and totally inappropriate as a default (and the only suggestion we can give them is to NEVER use dnf, only PackageKit or yum-deprecated) the bug here is "PackageKit" which in the meantime luckily can be removed entirely again on F23 while with F22/F23 it was a dependency for KDE packages signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Reproducible Builds for Fedora (a reboot)
Hi, In 2013, I worked very briefly on enabling reproducible builds for Fedora, https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/ After attending the "Reproducible Builds World Summit" recently, I am inspired again to help out in getting this done. https://reproducible-builds.org/docs/ has lot of excellent information on getting reproducible builds, and why it is important. I found the following presentations to be excellent in understanding the subject, https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15.pdf https://mikem.fedorapeople.org/Talks/flock-2015-koji-reproducibility/#/ Also, https://github.com/kholia/ReproducibleBuilds has scripts, and documentation to help in getting reproducible builds for Fedora. Dhiru -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20151206 changes
Compose started at Sun Dec 6 05:15:02 UTC 2015 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [calibre] calibre-2.45.0-1.fc24.i686 requires qt5-qtbase(x86-32) = 0:5.5.1 [dansguardian] dansguardian-2.10.1.1-15.fc22.i686 requires libclamav.so.6(CLAMAV_PUBLIC) dansguardian-2.10.1.1-15.fc22.i686 requires libclamav.so.6 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [fcitx-qt5] fcitx-qt5-1.0.4-3.fc24.i686 requires qt5-qtbase(x86-32) = 0:5.5.1 [fedfind] fedfind-1.6.2-2.fc24.noarch requires python2-cached_property [gammaray] gammaray-qt5-2.3.0-4.fc24.i686 requires qt5-qtbase(x86-32) = 0:5.5.1 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch r
Re: python-mne: testing stuck in koji
On Sun, 06 Dec 2015 08:40:27 +, Igor Gnatenko wrote: > I think I will get the same results... But I will try. As a last resort, some proof-reading could lead to something. Afterall, the "Done 3 out of 2" output in build.log asks for an investigation. The output for "elapsed/finished/remaining", does it come from the same package or an external testsuite framework? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
yum: Critical path update in testing for 4 months?
Usually I don't dig too deep but I saw a "critical path" update for yum on F22 (which should be using dnf anyway). So why is a critical path update with +10 karma still in testing? (I know how, there's no auto push to stable based on karma for this update) Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Am 06.12.2015 um 15:30 schrieb Richard Shaw: Usually I don't dig too deep but I saw a "critical path" update for yum on F22 (which should be using dnf anyway). So why is a critical path update with +10 karma still in testing? (I know how, there's no auto push to stable based on karma for this update) that's the reason that it did not happen automatically but what is the reason for maintainers building updates without the intention to push them? bodhi should punish maintaines with daily mails when a package has enough karma or has reached the time to get pushed even without karma so that the maintainer has a good reason for push it or decide to delete it (with a very good reason) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski wrote: > Since the old proposal to have the bootloader automatically enumerate > boot options never went anywhere, can we do the next best thing? > > Specifically, these days grub2-mkconfig appears to produce output > that's functionally identical to what grubby generates. Can we switch > new-kernel-pkg to just regenerate the grub2 config using > grub2-mkconfig instead of using grubby? > > Debian has worked like this forever, and IMO it's superior in pretty > much all respects. There are already nice config hooks for making > custom changes, and they're a lot more reliable than trusting grubby > to do what you expect it to do. Well mkconfig can produce a configuration that does not actually work when grub2 itself gets updated (in which case the bootloader does not get rewritten). Until this is fixed grub2-mkconfig is dangerous and should not be used. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20151206 compose check report
Missing expected images: Cloud disk raw i386 Cloud_atomic disk raw x86_64 Kde disk raw armhfp Kde live i386 Cloud disk raw x86_64 Kde live x86_64 No images in this compose but not Rawhide 20151205 Images in Rawhide 20151205 but not this: Mate live i386 Design_suite live x86_64 Design_suite live i386 Failed openQA tests: 3 of 52 ID: 443 Test: x86_64 universal server_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/443 ID: 433 Test: x86_64 universal server_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/433 ID: 423 Test: x86_64 universal server_delete_partial URL: https://openqa.fedoraproject.org/tests/423 Passed openQA tests: 49 of 52 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 6, 2015 at 7:05 AM, drago01 wrote: > On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski wrote: >> Since the old proposal to have the bootloader automatically enumerate >> boot options never went anywhere, can we do the next best thing? >> >> Specifically, these days grub2-mkconfig appears to produce output >> that's functionally identical to what grubby generates. Can we switch >> new-kernel-pkg to just regenerate the grub2 config using >> grub2-mkconfig instead of using grubby? >> >> Debian has worked like this forever, and IMO it's superior in pretty >> much all respects. There are already nice config hooks for making >> custom changes, and they're a lot more reliable than trusting grubby >> to do what you expect it to do. > > Well mkconfig can produce a configuration that does not actually work > when grub2 itself gets updated (in which case the bootloader does not > get rewritten). > Until this is fixed grub2-mkconfig is dangerous and should not be used. I have never seen this happen on any distro. In any event, even if there's a case in which mkconfig screws up, Fedora is unlikely to be able to install in the first place. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora Rawhide 20151206 compose check report
On Sun, 2015-12-06 at 16:14 +, Fedora compose checker wrote: > Missing expected images: > > Cloud disk raw i386 > Cloud_atomic disk raw x86_64 > Kde disk raw armhfp > Kde live i386 > Cloud disk raw x86_64 > Kde live x86_64 > > No images in this compose but not Rawhide 20151205 > > Images in Rawhide 20151205 but not this: > > Mate live i386 > Design_suite live x86_64 > Design_suite live i386 > > Failed openQA tests: 3 of 52 > > ID: 443 Test: x86_64 universal server_shrink_ext4 > URL: https://openqa.fedoraproject.org/tests/443 So, this is a curious one: actually a couple of yesterday's tests hit this, too, then I restarted them and they ran fine. It seems like there's some kind of issue in anaconda which occasionally causes it to crash - you can see the anaconda trace in this screenshot: https://openqa.fedoraproject.org/tests/443/modules/_boot_to_anaconda/steps/14 It doesn't seem associated with any particular test or action, I don't think, it was different tests which failed each time, but I'll have to look a bit closer. General openQA tip: on the 'Logs & Assets' tab you can find a sped-up video of the test, so you can see the crash happening. > ID: 433 Test: x86_64 universal server_delete_partial@uefi > URL: https://openqa.fedoraproject.org/tests/433 > ID: 423 Test: x86_64 universal server_delete_partial > URL: https://openqa.fedoraproject.org/tests/423 These are actually test bugs. The test is intended to delete the *first* partition, but the needle isn't carefully enough constructed, and the test can actually wind up deleting the *second* partition. When that happens, the post-install check - which mounts /dev/vda2 and looks for a file, to make sure it wasn't touched - obviously fails. > Passed openQA tests: 49 of 52 -- 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 http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 6, 2015 at 6:20 PM, Andrew Lutomirski wrote: > On Sun, Dec 6, 2015 at 7:05 AM, drago01 wrote: >> On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski wrote: >>> Since the old proposal to have the bootloader automatically enumerate >>> boot options never went anywhere, can we do the next best thing? >>> >>> Specifically, these days grub2-mkconfig appears to produce output >>> that's functionally identical to what grubby generates. Can we switch >>> new-kernel-pkg to just regenerate the grub2 config using >>> grub2-mkconfig instead of using grubby? >>> >>> Debian has worked like this forever, and IMO it's superior in pretty >>> much all respects. There are already nice config hooks for making >>> custom changes, and they're a lot more reliable than trusting grubby >>> to do what you expect it to do. >> >> Well mkconfig can produce a configuration that does not actually work >> when grub2 itself gets updated (in which case the bootloader does not >> get rewritten). >> Until this is fixed grub2-mkconfig is dangerous and should not be used. > > I have never seen this happen on any distro. In any event, even if > there's a case in which mkconfig screws up, Fedora is unlikely to be > able to install in the first place. No that has nothing to do with the installation process. The events are: 1) You install Fedora -- grub2-mkconfig creates a config that matches the bootloader 2) The grub package gets updated / upgraded --- grub2-mkconfig is no longer guaranted to generate a config file that works with the grub that is actually installed (i.e you'd have to rerun grub2-install to be sure). Yes in most of the cases that works but it is fragile and therefore dangerous to do that by default. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 06, 2015 at 06:25:09PM +0100, drago01 wrote: > >> Well mkconfig can produce a configuration that does not actually work > >> when grub2 itself gets updated (in which case the bootloader does not > >> get rewritten). > >> Until this is fixed grub2-mkconfig is dangerous and should not be used. > > > > I have never seen this happen on any distro. In any event, even if > > there's a case in which mkconfig screws up, Fedora is unlikely to be > > able to install in the first place. > > No that has nothing to do with the installation process. > > The events are: > > 1) You install Fedora -- grub2-mkconfig creates a config that matches > the bootloader > 2) The grub package gets updated / upgraded --- grub2-mkconfig is no > longer guaranted to generate a config file that works with the grub > that is actually installed (i.e you'd have to rerun grub2-install to > be sure). > > Yes in most of the cases that works but it is fragile and therefore > dangerous to do that by default. Can you list specific cases? It sounds awfully theoretical. -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 15:50:10 +0100, Reindl Harald wrote: > but what is the reason for maintainers building updates without the > intention to push them? There are maintainers, who dislike a lot of things related to the release processes. They consider bodhi a pain to use. They would prefer doing things differently, with less work, and more like fire'n'forget as how they do it within Rawhide. That's also the reason why they release another update while the previous update has not been pushed yet. And bodhi still cannot handle that case and sometimes pushes an older package after a newer package. If what I've read somewhere is true, it isn't easy to fix in bodhi (or koji) for reasons I don't know. > bodhi should punish maintaines with daily mails when a package has > enough karma or has reached the time to get pushed even without karma so > that the maintainer has a good reason for push it or decide to delete it > (with a very good reason) History has shown that attempts at "punishing" maintainers with so-called "nagmails" doesn't lead to anything good. Automated systems have a bad habit of sending nagmails when the human knows better. Then the human decides to filter out the annoying mails. Fedora's release process is poor and misdesigned and full of problems. Currently I have two security fixes, which are two months old. Nobody does the needed testing. The karma isn't reached. Nobody ensures that they enter the stable updates repo even with 0 karma. Meanwhile, F21 has reached end-of-life without anyone making sure to do a last push of security fixes for it. If I had not released any fixes, nobody would have reminded me. In other cases, there have been CVE tickets in bugzilla filed by the security team from Red Hat with nobody working on fixes for Fedora, not even sending reminders. We need more thinking humans to make the right decisions. Look at the age of updates in the updates-testing reports! This is crap 2.0. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Bodhi front page after login
When I log in at https://bodhi.fedoraproject.org/ the new web ui greets me with a huge wall of uninteresting statistics, such as * the activity of other update submitters, * this week's top testers * latest updates in need of testing Why doesn't it greet me with my own updates anymore? Some have been four months old and haven't received any testing. Perhaps that also means I should retire those packages as well, if there is not even a single user to give feedback on them. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz wrote: > On Sun, Dec 06, 2015 at 06:25:09PM +0100, drago01 wrote: >> >> Well mkconfig can produce a configuration that does not actually work >> >> when grub2 itself gets updated (in which case the bootloader does not >> >> get rewritten). >> >> Until this is fixed grub2-mkconfig is dangerous and should not be used. >> > >> > I have never seen this happen on any distro. In any event, even if >> > there's a case in which mkconfig screws up, Fedora is unlikely to be >> > able to install in the first place. >> >> No that has nothing to do with the installation process. >> >> The events are: >> >> 1) You install Fedora -- grub2-mkconfig creates a config that matches >> the bootloader >> 2) The grub package gets updated / upgraded --- grub2-mkconfig is no >> longer guaranted to generate a config file that works with the grub >> that is actually installed (i.e you'd have to rerun grub2-install to >> be sure). >> >> Yes in most of the cases that works but it is fragile and therefore >> dangerous to do that by default. > > Can you list specific cases? It sounds awfully theoretical. I got bitten by it before so its not theoretical ... unfortunately I do not remember the exact versions. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Am 06.12.2015 um 19:52 schrieb Michael Schwendt: Currently I have two security fixes, which are two months old. Nobody does the needed testing. The karma isn't reached. Nobody ensures that they enter the stable updates repo even with 0 karma. Meanwhile, F21 has reached end-of-life without anyone making sure to do a last push of security fixes for it. If I had not released any fixes, nobody would have reminded me. In other cases, there have been CVE tickets in bugzilla filed by the security team from Red Hat with nobody working on fixes for Fedora, not even sending reminders. We need more thinking humans to make the right decisions. Look at the age of updates in the updates-testing reports! This is crap 2.0 that may all be true - BUT i have zero understanding for cases where i make a distr-upgrade, start as usually "fedora-easy-karma" and find a ton of "this package could be pushed to stable if the maintainer wishes" candidates and for "There are maintainers, who dislike a lot of things related to the release processes. They consider bodhi a pain to use. They would prefer doing things differently, with less work, and more like fire'n'forget as how they do it within Rawhide" than frankly what's the point of prepare a update when one don't care about it? it's not a matter of like or disklike - it's a point of responsibility signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bodhi front page after login
Am 06.12.2015 um 20:06 schrieb Michael Schwendt: When I log in at https://bodhi.fedoraproject.org/ the new web ui greets me with a huge wall of uninteresting statistics, such as * the activity of other update submitters, * this week's top testers * latest updates in need of testing Why doesn't it greet me with my own updates anymore? Some have been four months old and haven't received any testing. Perhaps that also means I should retire those packages as well, if there is not even a single user to give feedback on them "if there is not even a single user to give feedback on them" is a jerk reaction - the majority of users don't have updates-testing enabled and just wait for stable updates taht said from someone who is most of the time in the top 5 testers as long nobody breaks fedora-easy-karma signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 19:52:05 +0100 Michael Schwendt wrote: > On Sun, 6 Dec 2015 15:50:10 +0100, Reindl Harald wrote: > > > but what is the reason for maintainers building updates without the > > intention to push them? > > There are maintainers, who dislike a lot of things related to the > release processes. They consider bodhi a pain to use. They would > prefer doing things differently, with less work, and more like > fire'n'forget as how they do it within Rawhide. Perhaps. But you are speculating that this is the case here. Unless you have talked to the maintainer and thats what they told you? I think it far more likely that this is due to: https://github.com/fedora-infra/bodhi/issues/372 which was/is a bug around the migration from bodhi1 to bodhi2 where some updates lost their setting of auto karma. If not that, then perhaps the maintainer wanted to be careful with this update for some reason and so wanted to push it manually. The only way to know for sure would be to ask. > That's also the reason why they release another update while the > previous update has not been pushed yet. And bodhi still cannot > handle that case and sometimes pushes an older package after a newer > package. If what I've read somewhere is true, it isn't easy to fix in > bodhi (or koji) for reasons I don't know. There's a possible fix for this that landed in the last bodhi update. It has to do with bodhi passing a bunch of packages to koji to tag, and koji does not promise the order they will be tagged in. So, bodhi has to know which is "newer" and split the operation up. > > bodhi should punish maintaines with daily mails when a package has > > enough karma or has reached the time to get pushed even without > > karma so that the maintainer has a good reason for push it or > > decide to delete it (with a very good reason) I think daily nag mails are over the top and anoying. > History has shown that attempts at "punishing" maintainers with > so-called "nagmails" doesn't lead to anything good. Automated systems > have a bad habit of sending nagmails when the human knows better. > Then the human decides to filter out the annoying mails. > > Fedora's release process is poor and misdesigned and full of problems. I'm sorry to hear you say so. Do you have any ideas to improve things? Or would you prefer to continue to be a ray of sunshine when others ask for ideas? > Currently I have two security fixes, which are two months old. Nobody > does the needed testing. The karma isn't reached. Nobody ensures that > they enter the stable updates repo even with 0 karma. Perhaps you could solicit testers? Either upstream people or on the test list or on irc? > Meanwhile, F21 > has reached end-of-life without anyone making sure to do a last push > of security fixes for it. We did do a last push. Just blindly pushing all security updates (if they were ready or not) isn't a particularly good idea IMHO. > If I had not released any fixes, nobody > would have reminded me. In other cases, there have been CVE tickets > in bugzilla filed by the security team from Red Hat with nobody > working on fixes for Fedora, not even sending reminders. We need more > thinking humans to make the right decisions. Look at the age of > updates in the updates-testing reports! This is crap 2.0. Yeah, the Fedora security sig has actually been ramping up trying to deal with these. Perhaps you could offer your assistance there? kevin pgpMAQaqjN5r2.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bodhi front page after login
On Sun, 6 Dec 2015 20:17:37 +0100 Reindl Harald wrote: > Am 06.12.2015 um 20:06 schrieb Michael Schwendt: > > When I log in at https://bodhi.fedoraproject.org/ the new web ui > > greets me with a huge wall of uninteresting statistics, such as > > > > * the activity of other update submitters, > > * this week's top testers > > * latest updates in need of testing > > > > Why doesn't it greet me with my own updates anymore? Because other folks find the overall status more interesting? You can find all your updates under the 'profile' tab. You could even set a bookmark to this page. > > Some have been four months old and haven't received any testing. > > Perhaps that also means I should retire those packages as well, > > if there is not even a single user to give feedback on them > > "if there is not even a single user to give feedback on them" is a > jerk reaction - the majority of users don't have updates-testing > enabled and just wait for stable updates Also people who do have updates-testing enabled could well not provide any positive feedback and only -1 things that they notice are wrong. kevin pgpbgV8O4uHHD.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bodhi front page after login
On Sun, 6 Dec 2015 20:17:37 +0100, Reindl Harald wrote: > "if there is not even a single user to give feedback on them" is a jerk > reaction - the majority of users don't have updates-testing enabled and > just wait for stable updates That only proves that the updates release process is flawed. The karma based system only works for packages where enough testers spend points to reach the pos/neg karma threshold. If nobody gives feedback on a test update: - This could mean that none of the (few?) testers has evaluated the test update. - This could also mean that no tester knows _how to test_ the update. Or nobody cares? Nobody asks either? The bug reporter is still affected, bug has worked around the bug? => Doesn't make the maintainer happy. - And it could also mean that the test update is fine, provided that it got installed and used on testers' machines without the testers being aware of it. It is _not_ safe to assume, however, that an untested update is fine. It has happened before that changes in dependencies caused simple rebuilds to break badly. As far as I know, bodhi posts to bugzilla tickets about test updates. Unfortunately, it does that too early with a first notification. Bug reporters read the mail, try to apply the update, but it is not available for download. It has not been pushed, and even when the second notification tells it has been pushed, it has not arrived on mirrors. For the case of 0 karma after months, where is the option to request an automatic push to stable based on a minimum number of days rather than a karma threshold? Else updates-testing is just some "punishment" for maintainers of packages with no active testers. > taht said from someone who is most of the time in the top 5 testers as > long nobody breaks fedora-easy-karma Fine, fine. Still, if a maintainer sets NEEDINFO in bugzilla and doesn't receive any response by a bug reporter, it's too easy to forget a ticket completely, especially if a test update has been released already. Nagmails don't fix that, if the person in NEEDINFO state doesn't respond. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Some comps cleanup
Re: https://bugzilla.redhat.com/show_bug.cgi?id=1284183 I have removed a bunch of packages that have been orphaned/retired from comps, but there's still more to be done there. There's also a number of packages that have changed name that should get updated. Perhaps someone would care to write a checker script here? Check each package in comps, make sure it is no retired/orphaned/missing and of those look for packages that now provide that name? kevin pgpTC3zpjNXX_.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 6, 2015 at 8:05 AM, drago01 wrote: > On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski wrote: >> Since the old proposal to have the bootloader automatically enumerate >> boot options never went anywhere, can we do the next best thing? >> >> Specifically, these days grub2-mkconfig appears to produce output >> that's functionally identical to what grubby generates. Can we switch >> new-kernel-pkg to just regenerate the grub2 config using >> grub2-mkconfig instead of using grubby? >> >> Debian has worked like this forever, and IMO it's superior in pretty >> much all respects. There are already nice config hooks for making >> custom changes, and they're a lot more reliable than trusting grubby >> to do what you expect it to do. > > Well mkconfig can produce a configuration that does not actually work > when grub2 itself gets updated (in which case the bootloader does not > get rewritten). Hypothetically on BIOS systems, a GRUB core.img [1] could become stale over time, and an upgraded grub-mkconfig could introduce an incompatible format change, but that's really unlikely and wouldn't be intentional. This isn't possible on UEFI. Any update of grub2-efi means the core.img is replaced with a generically built one (that's also signed by a Fedora key for the purposes of supporting UEFI Secure Boot). > Until this is fixed grub2-mkconfig is dangerous and should not be used. That's such an overstatement as to be wrong. Pretty much all other distributions have been doing this for a long time to no ill effect. On a BIOS computer, a Fedora upgrade (fedup or dnf-plugin-system-upgrade) will lack generation of a new core.img, where a new installation will have a new core.img (and new grub.cfg). So there's a risk of problems due to core.img becoming increasingly stale with successful upgrades rather than reinstalls. But since grubby is responsible for modifying rather than replacing grub.cfg with grub-mkconfig, it's probably less of a concern than the lack of bug and security fixes going into the core.img. [1] The code embedded into the MBR gap, or BIOSBoot partition; a.k.a. GRUB legacy terminology was stage 2 bootloader. It's created and embedded by the grub2-install command; which is unnecessary (and arguably deprecated) on UEFI systems. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 20:15:20 +0100, Reindl Harald wrote: > BUT i have zero understanding for cases where i > make a distr-upgrade, start as usually "fedora-easy-karma" and find a > ton of "this package could be pushed to stable if the maintainer wishes" > candidates You need to talk to the individual maintainers to find out. Some have seen the nagmail they got from bodhi, but as they have set a low karma threshold of 1 or 2 for the update, they wait for a +1 from testers. And then the update would be published _automatically_. Others disable those nagmails to begin with, since they only increase the "spam" in all the cases where you really want to see feedback from somebody before pushing an update. It doesn't work well, if bug reporters wait for updates to appear in the stable updates repo only to discover that the fix doesn't work or that something else is broken. The bug reporter will be the first to complain. > and for "There are maintainers, who dislike a lot of things related to > the release processes. They consider bodhi a pain to use. They would > prefer doing things differently, with less work, and more like > fire'n'forget as how they do it within Rawhide" than frankly what's the > point of prepare a update when one don't care about it? it's not a > matter of like or disklike - it's a point of responsibility This is cheap talk, and you shift responsibility to be a one-sided thing placed on the maintainers' shoulders only. Bug reporters, who enter something in bugzilla, but cannot be talked to, are not responsible either. And as you are not a package maintainer at Fedora, it could be that you underestimate the amount of burden/bureaucracy that's considered unnecessary by many packagers. There are so many updates where the maintainer publishes an update confidently, but it still depends on external factors, such as QA and critpath policies, unannounced changes in deps, and the maintainer also must remember each and every detail of any Updates policy there may be -- if the only goal is to get out a fix asap. One big problem here is that it's necessary to baby-sit an update for too long and monitor its way into the repos, or else it may never find its way out - and in some corner-cases, updates have been lost actually. ;-) Odd as it may be, when I searched for my updates in the bodhi web ui, I also discovered updates that were four months old already. I don't think this has ever happened to me with the old bodhi. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
Am 06.12.2015 um 21:06 schrieb Chris Murphy: On Sun, Dec 6, 2015 at 8:05 AM, drago01 wrote: Hypothetically on BIOS systems, a GRUB core.img [1] could become stale over time, and an upgraded grub-mkconfig could introduce an incompatible format change, but that's really unlikely and wouldn't be intentional. This isn't possible on UEFI. Any update of grub2-efi means the core.img is replaced with a generically built one (that's also signed by a Fedora key for the purposes of supporting UEFI Secure Boot). the world don't turn around UEFI Until this is fixed grub2-mkconfig is dangerous and should not be used. That's such an overstatement as to be wrong. Pretty much all other distributions have been doing this for a long time to no ill effect. he told you he was personally affected [1] The code embedded into the MBR gap, or BIOSBoot partition; a.k.a. GRUB legacy terminology was stage 2 bootloader. It's created and embedded by the grub2-install command; which is unnecessary (and arguably deprecated) on UEFI systems. and you are going to change existing systems running for many years and surivived all dist-upgrades to UEFI *without* reinstall or lose /boot redundancy by RAID1? grub2-install needs to be manually done on all 4 drives frankly my current workstations where installed with F14 and RAID1 for /boot as well as RAID10 for anything else, they support UEFI but i gave up with Anaconda, now they happily run Fedora 23 with dist-upgrades and will as long some jerk decides to kill BIOS support or i die the same applies to more than 30 production servers installed with Fedora 9 years ago and currentyl on F22 on top of VMware - fine, Vmware now supports UEFI too - but tell me *one valid* reason to change them! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
On Sun, Dec 6, 2015 at 12:11 PM, drago01 wrote: > On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz wrote: >> Can you list specific cases? It sounds awfully theoretical. > > I got bitten by it before so its not theoretical ... unfortunately I > do not remember the exact versions. I'm willing to bet it happened during the GRUB 2 beta era, when Fedora carried multiple works-in-progress of GRUB 1.9x where the grub.cfg format was in flux, and grubby also had some problems dealing with those changes. It's also possible it happened when Fedora's GRUB introduced linuxefi/initrdefi and linux16/initrd16 which GRUB upstream don't have; so your core.img didn't understand those commands while the grub2-mkconfig produced grub.cfg would have. So yeah it's possible, but it's also unintended. And the same problem could happen whether grubby modifies grub.cfg or grub-mkconfig replaces it. The way this works on UEFI obviates the problem by always replacing grubx64.efi (which contains core.img) anytime the grub2 package is updated. There's no equivalent to this on BIOS computers that won't piss off some significant(ly vocal) minority, but there's still a sane argument for the default behavior rewriting core.img anytime the grub package is updated: and the start of that argument is that reinstalling the bootloader manually is esoteric, and users shouldn't have to know such esoteric things to get their computer to boot or be secure. The reality is that anyone multibooting has to have ninjitsu level bootloader knowledge anyway, so I'd burden those people with managing exceptions rather than single boot users (or even dual boot Fedora+OSX or Fedora+Windows). -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Include Fritzing in electronic-lab.
This seems reasonable to me. It looks like a good first step might be to open a bugzilla against the comps component? https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups This was also a good reminder that I've been slow to get the latest Fritzing release out; rawhide has 0.9.2b now, and updates are waiting on karma for F23 and F22: https://bodhi.fedoraproject.org/updates/FEDORA-2015-1d7ed921c3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-83ec70a406 On Sat, Dec 5, 2015 at 9:27 AM, Kiara Navarro < sophiekovalev...@fedoraproject.org> wrote: > As I'm not sure what are the steps to get this done I prefer to ask to the > devel list. > > Currently, we have Fritzing [1] package in our repos which a software > related to electronics and I think that should be part of the electronic > lab group. > > Is there a posibility to include it into the comps.xml file? > > Thanks in advance, > > [1] https://admin.fedoraproject.org/pkgdb/package/fritzing/ > > -- > *Kiara Navarro* > *Fedora Project Contributor * > > *GPG-KEY*: A81DB1D8 > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: switching from grubby to grub2-mkconfig
Am 06.12.2015 um 21:22 schrieb Chris Murphy: So yeah it's possible, but it's also unintended. And the same problem could happen whether grubby modifies grub.cfg or grub-mkconfig replaces it that's wrong because grubby *clones* the last recent entry with all it's parameters and don't touch other boot entrie snor the rest of the configuration signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Include Fritzing in electronic-lab.
Hi there: I'll fill up a ticket to bugzilla in order to get Fritzing into the group. Thanks in advance, 2015-12-06 15:24 GMT-05:00 Ed Marshall : > This seems reasonable to me. It looks like a good first step might be to > open a bugzilla against the comps component? > > > https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups > > This was also a good reminder that I've been slow to get the latest > Fritzing release out; rawhide has 0.9.2b now, and updates are waiting on > karma for F23 and F22: > > https://bodhi.fedoraproject.org/updates/FEDORA-2015-1d7ed921c3 > https://bodhi.fedoraproject.org/updates/FEDORA-2015-83ec70a406 > > > On Sat, Dec 5, 2015 at 9:27 AM, Kiara Navarro < > sophiekovalev...@fedoraproject.org> wrote: > >> As I'm not sure what are the steps to get this done I prefer to ask to >> the devel list. >> >> Currently, we have Fritzing [1] package in our repos which a software >> related to electronics and I think that should be part of the electronic >> lab group. >> >> Is there a posibility to include it into the comps.xml file? >> >> Thanks in advance, >> >> [1] https://admin.fedoraproject.org/pkgdb/package/fritzing/ >> >> -- >> *Kiara Navarro* >> *Fedora Project Contributor * >> >> *GPG-KEY*: A81DB1D8 >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> > > > > -- > Ed Marshall > Felix qui potuit rerum cognoscere causas. > http://esm.logic.net/ > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- *Kiara Navarro* *Fedora Project Contributor * *GPG-KEY*: A81DB1D8 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Am 06.12.2015 um 21:20 schrieb Michael Schwendt: And as you are not a package maintainer at Fedora, it could be that you underestimate the amount of burden/bureaucracy that's considered unnecessary by many packagers explain me the burden/bureaucracy in the countless cases where "fedora-easy-karma" shows the status "this update has reached... and can be pushed to stable when the maintainer wishes" other then just press the button signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Robert Buchholz
I'm joining in to help maintain letsencrypt, with a focus on EPEL. jhogarth, who maintains letsencrypt and python-acme, is mentoring me on these packages. kevin has been so kind as to sponsor my joining of the packagers group. I've been a developer with the Gentoo project a while back (2006-2011) and since used Fedora and CentOS, but haven't gotten beyond the stage of reporting the occasional bug. Let's change that. Cheers, Robert -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 12:40:45 -0700, Kevin Fenzi wrote: > Perhaps. But you are speculating that this is the case here. > Unless you have talked to the maintainer and thats what they told you? I'm not speculating as I didn't claim I know the reason why this particular Yum update is stuck. I answered to the general question "what is the reason for maintainers building updates without the intention to push them?". Knowing that some maintainers believe the release bureaucracy sucks can be helpful in understanding [some of] the background. I still talk to other packages from time to time, and I have learned to be careful when doing that, because some find it easier to complain about various things in a private conversation (and leave the project silently) instead of voicing their opinion in one of Fedora's public places. > I think it far more likely that this is due to: > https://github.com/fedora-infra/bodhi/issues/372 > which was/is a bug around the migration from bodhi1 to bodhi2 where > some updates lost their setting of auto karma. > > If not that, then perhaps the maintainer wanted to be careful with this > update for some reason and so wanted to push it manually. > > The only way to know for sure would be to ask. Four months is a long time even for an update that is at karma 10 already. Even if it's Yum, which has been broken before by updates that have been rushed out too soon. If it fixes any bugs, waiting four months for the fixes to get out is too long. [And a minor update to some fonts package is pushed faster and more frequently. ;-)] More strange, if it's an update that's at karma 0 after four months. Bodhi forgetting about autokarma cannot be an issue in that case. It's only a lack of testers and a lack of _another method_ to publish such updates _automatically_ based on submitter's early request. > > Fedora's release process is poor and misdesigned and full of problems. > > I'm sorry to hear you say so. > > Do you have any ideas to improve things? Or would you prefer to > continue to be a ray of sunshine when others ask for ideas? What's needed is software developers and policy makers to agree that some areas are problematic, and to agree on ideas and an agenda. To agree that the karma system is flawed and things like testers ignoring past votes and overriding another's -1 with their own +1 should not be possible. If people in Fedora leadership positions don't consider broken upgrade paths a problem, and the developers of update release tools don't consider them problematic either, not much will happen about such issues, for example. Users will continue to run into downgrades, unresolvable deps, or runtime breakage. And then there are all those ideas where the only response will be that patches will be accepted, with the ideas never making it onto a todo list/agenda. > > Currently I have two security fixes, which are two months old. Nobody > > does the needed testing. The karma isn't reached. Nobody ensures that > > they enter the stable updates repo even with 0 karma. > > Perhaps you could solicit testers? Either upstream people or on the > test list or on irc? Perhaps Fedora is just not popular enough? How many layers of extra work do you ask for? Imagine that a fix is from upstream or has been applied and released upstream already. What extra testing and baby-sitting is needed at Fedora's side even for entirely new packages? Remember the period when packagers voted +1 on their own updates. There still is no way to do that *officially*. It is still assumed that packagers test their own update (even if they don't do that in Rawhide, uh-oh!), but they cannot ask for it to be pushed automatically after X days other than based on that karma threshold that won't be reached for some packages ever. > > Meanwhile, F21 > > has reached end-of-life without anyone making sure to do a last push > > of security fixes for it. > > We did do a last push. Just blindly pushing all security updates (if > they were ready or not) isn't a particularly good idea IMHO. Has the security team done anything at all to even push any other security updates for F21 not blindly? I mean, Fedora packagers receive all those security related tracker ticket bugzilla spam where the security team changes ticket fields again and again, but nobody cares that the released fixes find their way onto the Fedora User's installations? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Future of the Linux upstream tracker
Hello, Some of you may have noticed that the service for analysis of ABI changes in Linux libraries is not available any more: http://upstream-tracker.org/ The archive from 21 July 2015 is still available and supported by ROSA team: http://upstream.rosalinux.ru/ But ... Good news everyone! I've spent about a half-year to implement an open-source alternative of the tool from scratch and I'm glad to inform you that it's finally ready and available at: https://github.com/lvc/abi-tracker So everyone can set up their own ABI tracker for the interested libraries. The reports and architecture of the tool are much better than the old ones. Also I've set up a new small upstream tracker for the core Linux libraries (glibc, openssl, freetype, Qt, etc.) here: http://abi-laboratory.pro/tracker/ Enjoy! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Am 06.12.2015 um 22:29 schrieb Michael Schwendt: What's needed is software developers and policy makers to agree that some areas are problematic, and to agree on ideas and an agenda. To agree that the karma system is flawed and things like testers ignoring past votes and overriding another's -1 with their own +1 should not be possible really? i have seen more than once a -1 from somebody because *his* bug was not fixed by the update but others where - in that case *it is not* a regression and there is no point for -1 if i would get 1$ for every update which got a +1 from me while it did not fixed for me annyoing bugs *just because* they where *no regression* in *that* build i would be rich! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 22:37:57 +0100, Reindl Harald wrote: > i have seen more than once a -1 from somebody because *his* bug was not > fixed by the update but others where - in that case *it is not* a > regression and there is no point for -1 The Fedora Updates System is a place where to let out one's frustration related to broken software/packages. I had hoped that it would be obvious that I refer to the case where somebody had voted -1 for a problem introduced by the update, but later testers didn't read the comments and voted +1 nevertheless up to the point of triggering an automatic push to stable. It's covered by the guidelines: https://fedoraproject.org/wiki/QA:Update_feedback_guidelines Every -1 by somebody ought to stop autokarma based pushes and require somebody to review the update ticket and decide whether to mask the -1. If a new kernel fails for one tester, it would be wrong to push it to stable only because it works for three other testers. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 6 Dec 2015 21:47:24 +0100, Reindl Harald wrote: > > And as you are not a package maintainer at Fedora, it could be that you > > underestimate the amount of burden/bureaucracy that's considered > > unnecessary by many packagers > > explain me the burden/bureaucracy in the countless cases where > "fedora-easy-karma" shows the status "this update has reached... and can > be pushed to stable when the maintainer wishes" other then just press > the button Let me try. Not specific to the Yum update you refer to in the original post, and I don't know for how many updates the "autokarma" and critpath settings have been lost upon migration to bodhi 2. => There are some strange status messages in some of the tickets, such as very late +1 critpath votes. Packager spends time on preparing an update for multiple dist targets, test them locally, builds them within koji and waits for the builds to become available in bodhi. Packager submits the update and related bugzilla ticket numbers in bodhi and either keeps the default karma threshold or adjusts it. For non-critpath updates, some packagers enter a threshold of +1/-1 to reduce testing requirements, but a single pet peeve reporter, who votes -1 due to a problem that exists for a much longer time already, can cause the update to be withdrawn automatically. So, some packagers go with +1/-3 for example, requiring a +1 from a single tester while still making it possible to pull the update, if breakage is found by three testers. After adding the updates to bodhi, packager wants to be done and wants to move on to other tasks, since the update would be pushed automatically *if* testers gave the required number of +1. Some of the votes could come from the bug reporters, who are notified about the update inside their bugzilla tickets. [I've pointed out that they are notified too early.] [Packager knows that if an update for an older dist is published earlier than an update for the current dist, this can lead to breaking dist upgrades. Disabling karma based auto-pushing currently is the only way to avoid that. More work, and reoccuring tasks to do manually aren't good.] However, since the packager wanted to rely on karma based auto-pushing, the email notification "This update has reached X days in testing and can be pushed to stable now if the maintainer wishes" may come too early, especially if the karma level has not been reached. The packager would need to load the bodhi page linked in each of the notifications and decide again whether to push manually without waiting for testers. Does the packager want to push manually at that point? Sometimes. Not always. You expect packagers to review all their bodhi tickets everytime they receive a nagmail from bodhi, and then to decide again whether to wait for testers or whether to push manually without any prior feedback. That doesn't scale for everyone. The list of active updates inside the web ui can grow easily, too. Let's say you start reviewing your updates for F23. You decide to push an update after 14 days and 0 karma, because you want to get it out as quickly as policies allow. You must not forget the corresponding update for F22. It has received a +1 and a -1 but has not reached -3 yet to unpush it automatically. It may have been a better idea to unpush the updates for all dists manually upon receiving the -1. But then what's the point of a -3 threshold? And it also requires you to pay attention to every bodhi mail you receive and take action immediately, or else the messages about later votes and status changes may pile up quickly. While waiting for updates to be pushed, the packager also needs to be careful not to submit further updates. Bodhi used to be able to obsolete older test updates automatically, which may be the wrong thing to do in all cases (the new update may not be as good as the current one and may require increased testing). What would some packagers prefer? A way to append updates into a queue and _be done_ unless a tester intervenes, and if all goes well, the update gets published either after positive feedback from a minimum number of testers _or_ after a grace period of N days sitting in updates-testing. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Am 06.12.2015 um 23:50 schrieb Michael Schwendt: You expect packagers to review all their bodhi tickets everytime they receive a nagmail from bodhi, and then to decide again whether to wait for testers or whether to push manually without any prior feedback. That doesn't scale for everyone. The list of active updates inside the web ui can grow easily, too yes, i expect this when i am able to follow all fedora and 7 other mailing-lists including bodhi-mails and give karma and review 100-400 mail samples for bayes-training every day besides my daily jobs as the only sysadmin for more than 30 Fedora based servers, a few test-servers, 4 fedora-based routers and get my *really* dayjob as software developer done at the same time yes i expect that someone is able just read his mails and push a button on a list in a webinterface signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Mon, 7 Dec 2015 00:08:37 +0100, Reindl Harald wrote: > yes i expect that someone is able just read his mails and push a button > on a list in a webinterface The productivity loss that's caused by people wading through email folders every day is subject to studies. Plus, by the time the first nagmail from bodhi is opened and read (after filtering), the update may have been pushed already. Or the nagmail is sent too early. Publishing ready-to-ship updates is a reoccuring task that asks for more automation. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 2015-12-06 at 19:52 +0100, Michael Schwendt wrote: > On Sun, 6 Dec 2015 15:50:10 +0100, Reindl Harald wrote: > > > but what is the reason for maintainers building updates without the > > intention to push them? > > There are maintainers, who dislike a lot of things related to the release > processes. They consider bodhi a pain to use. They would prefer doing > things differently, with less work, and more like fire'n'forget as how > they do it within Rawhide. That doesn't really add up. Auto-karma is the *default* in Bodhi. The maintainer had to take specific action to disable it. If they want things to be fire-and-forget, why disable auto-karma? > Currently I have two security fixes, which are two months old. Nobody > does the needed testing. The karma isn't reached. If they're two months old, they can certainly be pushed with 0 karma. The longest *any* update for *any* distro has to wait before it can be pushed without karma is 2 weeks. > Nobody ensures that > they enter the stable updates repo even with 0 karma. Meanwhile, F21 > has reached end-of-life without anyone making sure to do a last push > of security fixes for it. I've never understood why the idea of a 'last push of security fixes' for an EOL release makes any sense. It's *EOL*. It doesn't matter if there's a last-day push or not: everyone should stop using it the next day, end of story. That's what EOL means. -- 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 http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Sun, 06 Dec 2015 16:02:42 -0800, Adam Williamson wrote: > On Sun, 2015-12-06 at 19:52 +0100, Michael Schwendt wrote: > > On Sun, 6 Dec 2015 15:50:10 +0100, Reindl Harald wrote: > > > > > but what is the reason for maintainers building updates without the > > > intention to push them? > > > > There are maintainers, who dislike a lot of things related to the release > > processes. They consider bodhi a pain to use. They would prefer doing > > things differently, with less work, and more like fire'n'forget as how > > they do it within Rawhide. > > That doesn't really add up. What doesn't add up? > Auto-karma is the *default* in Bodhi. The > maintainer had to take specific action to disable it. If they want > things to be fire-and-forget, why disable auto-karma? Nobody said that they do that. I refer to things bodhi cannot do today. Keeping default karma settings is the closest thing to fire'n'forget, except if karma threshold will not be reached. > > Nobody ensures that > > they enter the stable updates repo even with 0 karma. Meanwhile, F21 > > has reached end-of-life without anyone making sure to do a last push > > of security fixes for it. > > I've never understood why the idea of a 'last push of security fixes' > for an EOL release makes any sense. It's *EOL*. It doesn't matter if > there's a last-day push or not: everyone should stop using it the next > day, end of story. That's what EOL means. It need not happen on the "last day". It could have happened a month before release. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
Adam Williamson wrote: > I've never understood why the idea of a 'last push of security fixes' > for an EOL release makes any sense. It's *EOL*. It doesn't matter if > there's a last-day push or not: everyone should stop using it the next > day, end of story. That's what EOL means. Realistically, some people will still be running EOL releases for months if not years. They should not, but they do. Getting at least the last pending security updates out before turning the pipes off for good should be a priority. It means they'd at least not be affected by those security issues, only by the later ones. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Robert Buchholz
On 12/06/2015 02:13 PM, Robert Buchholz wrote: I'm joining in to help maintain letsencrypt, with a focus on EPEL. jhogarth, who maintains letsencrypt and python-acme, is mentoring me on these packages. kevin has been so kind as to sponsor my joining of the packagers group. I've been a developer with the Gentoo project a while back (2006-2011) and since used Fedora and CentOS, but haven't gotten beyond the stage of reporting the occasional bug. Let's change that. Excellent. Welcome. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Some comps cleanup
On Sun, Dec 6, 2015 at 12:59 PM, Kevin Fenzi wrote: > Perhaps someone would care to write a checker script here? > > Check each package in comps, make sure it is no > retired/orphaned/missing and of those look for packages that now > provide that name? It would be good to also check for dangling references inside comps. For example, in the servers category, the grouplist includes clustering, but there is no clustering group definition to be found. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Future of the Linux upstream tracker
Review request submitted: https://bugzilla.redhat.com/show_bug.cgi?id=1288930 Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yum: Critical path update in testing for 4 months?
On Mon, 2015-12-07 at 02:07 +0100, Michael Schwendt wrote: > On Sun, 06 Dec 2015 16:02:42 -0800, Adam Williamson wrote: > > > On Sun, 2015-12-06 at 19:52 +0100, Michael Schwendt wrote: > > > On Sun, 6 Dec 2015 15:50:10 +0100, Reindl Harald wrote: > > > > > > > but what is the reason for maintainers building updates without the > > > > intention to push them? > > > > > > There are maintainers, who dislike a lot of things related to the release > > > processes. They consider bodhi a pain to use. They would prefer doing > > > things differently, with less work, and more like fire'n'forget as how > > > they do it within Rawhide. > > > > That doesn't really add up. > > What doesn't add up? We were talking about a yum update that had been sitting around for four months, with +10 karma. Your theory about why this kind of thing happens doesn't match the facts of that situation: the update submitter actually had to take specific action to make it so the update wouldn't get pushed. If they were just 'fire'n'forget', the update would already have gone stable weeks ago. -- 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 http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Direct messages
I just want to know what happened to direct messages about issues with packages. When builds fail i.e. during mass rebuilds I have a message about it. If for some reasons dependencies tree was broken (in rawhide, i.e., it is occurs) I have a message about it. If one of dependencies was retired I have... nothing. Yes, I'm not reading messages in devel@ with "Orphan" title careful. I missed that one of dependencies (which still have a comaintainer, btw) was orphaned. How could I know? And now a receive a mail that one of my packages SUDDENlY retired. I could go through unretire process anyway but I think it is something that is completely wrong. Dmitrij S. Kryzhevich -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
python-pyo license change: GPLv3 → LGPLv3+
python-pyo-0.7.7-1.fc24 changes license from GPLv3 to LGPLv3+. Eduardo -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Direct messages
On Mon, Dec 07, 2015 at 11:29:32AM +0600, Dmitrij S. Kryzhevich wrote: > I just want to know what happened to direct messages about issues with > packages. > > When builds fail i.e. during mass rebuilds I have a message about it. > If for some reasons dependencies tree was broken (in rawhide, i.e., it is > occurs) I have a message about it. > > If one of dependencies was retired I have... nothing. Yes, I'm not reading > messages in devel@ with "Orphan" title careful. I missed that one of > dependencies (which still have a comaintainer, btw) was orphaned. How could > I know? And now a receive a mail that one of my packages SUDDENlY retired. > > I could go through unretire process anyway but I think it is something that > is completely wrong. Would you like to share the name of this package maybe? Pierre -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Scalability of FE-DEADREVIEW
Dne 4.12.2015 v 08:25 James Hogarth napsal(a): > The question on my mind is how useful is that when you reach that number of > things blocking it? Who in their right mind > is going to check one of the thousand or so packages marked blocking that as > a place to start packaging? That's not even > pondering what the bugzilla limits for this likely are before it goes poof... I suppose it does not matter. I never done the query in this direction "Let look what is blocking FE-DEADREVIEW...". I rather used opposite direction: either "Lookup some bz, hmmm it is blocking FE-DEADREVIEW..." or "Give me some list of Package Reviews sans those blocking FE-DEADREVIEW". In this case I really does not care how much bugs are under FE-DEADREVIEW. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
