DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released
DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released. [1] This major version update of DNF brings many user experience improvements and underlying code changes. This release has been focused on improving yum compatibility and fixes over 60 bugs. Because this release is not fully compatible with previous DNF-1 [2] it has been released only in rawhide. Authors of dnf plugins will need to check compatibility of their plugins [3]. More information in release notes [4]. [1] http://dnf.baseurl.org/2016/12/20/dnf-2-0-0-and-dnf-plugins-core-1-0-0-has-been-released/ [2] http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html [3] http://dnf.readthedocs.io/en/latest/use_cases.html#plugins-cli-api [4] http://dnf.readthedocs.io/en/latest/release_notes.html#release-notes -- Michael Mráka Software Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cross-compiler support?
Igor Gnatenko wrote: > > Well there is gcc-arm-linux-gnu for example but that's for kernels per > > description > Didn't see it before... But looks like it doesn't work either: > /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory > /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory > /usr/bin/arm-linux-gnu-ld: cannot find -lc > /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory Yeah - it's intended for building kernels (though it can build anything that provides its own userspace). There are a number of reasons I *don't* provide userspaces: (0) I build cross-compilers for 20-ish arches (note that not all kernel arches are actually supported by upstream gcc and binutils). (1) No single upstream C library supports all the arches I can build a cross-compiler for, so I would have to include multiple C libraries in the SRPM and build some arches differently to others. Some I won't be able to bootstrap at all without an old or hacked version of a C library. (2) Do I bootstrap-build a single config for each arch or several configs? What one or ones do I pick? Note that not all configs of a single arch are necessarily supported by the same C library (consider MMU vs NOMMU). Further note that each bootstrap increases the build footprint and installation footprint - and at some point the package will become unbuildable. IMHO, it shouldn't be necessary for the compiler to know anything about the C library... David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: [...] > I would like to see us stop pushing non security updates to updates from > updates-testing entirely and do it in monthly batches instead. we would push > daily security fixes and updates-testing. However this would make atomic > host > 2 week releases much less useful, as there would be no updates except for > once > a month. You gave just one disadvantage of this proposal and no advantages at all. Why do you think the above is a good idea? I, for one, do not like waiting a month to get bug fixes that are not security-related. We are not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes available as soon as they're ready is valuable (even if you choose to wait before installing them). Also, as was pointed out elsewhere in this subthread, updates get tested only after they're released to stable very often, so it's also valuable to get the feedback earlier rather than in a month. 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: cross-compiler support?
On 12/19/2016 11:59 PM, Igor Gnatenko wrote: > Hi, > > I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs There's also two mingw cross compilers: mingw32-gcc and mingw64-gcc. Not sure if that's what you were looking for :) -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
dnf error during upgrade that changes a directory into a symlink
Hi all,
I have a package that contains a subdirectory which is changed to a
symlink in the next release. When I upgrade, I get the following error:
Error: Transaction check error:
file /usr/share/symlinktest/dir/subdir from install of
symlinktest-1-2.fc25.x86_64 conflicts with file from package
symlinktest-1-1.fc25.x86_64
The first version (1-1) of the spec file contains:
mkdir -p \
%{buildroot}/%{_datadir}/%{name}/dir/subdir
ln -s \
%{_datadir}/%{name}/testfile %{buildroot}/%{_datadir}/%{name}/dir/subdir
which is changed in 1-2 to:
mkdir -p \
%{buildroot}/%{_datadir}/%{name}/dir/
ln -s \
%{_datadir}/%{name}/testfile %{buildroot}/%{_datadir}/%{name}/dir/subdir
As you can see, in the second case, the subdir is not created anymore,
and thus %{_datadir}/%{name}/dir becomes a symlink to
%{_datadir}/%{name}/testfile. In other words, instead of having the
symlink in dir/subdir, dir/subdir is now a symlink itself.
I'm not sure what to make out of this. How can a file conflict with a
file of the same package (but previous version)? Is this a dnf issue?
Removing the old version and then installing the new version works fine.
I've attached both versions of the spec file. You can also find them on
pagure: https://pagure.io/symlinktest
Any hints are welcome.
Thanks,
Till
Name: symlinktest
Version:1
Release:1%{?dist}
Summary:Test to move symplinks
License:WTFPL
URL:https://fedoraproject.org
%description
Test what happens if you move a symlink between versions.
%prep
%build
echo "test" > testfile
%install
mkdir -p %{buildroot}/%{_datadir}/%{name}
install -m 0644 -p testfile %{buildroot}/%{_datadir}/%{name}
mkdir -p %{buildroot}/%{_datadir}/%{name}/dir/subdir
ln -s %{_datadir}/%{name}/testfile %{buildroot}/%{_datadir}/%{name}/dir/subdir
%files
%{_datadir}/*
%changelog
* Mon Dec 19 2016 Till Hofmann
- Initial package
Name: symlinktest
Version:1
Release:2%{?dist}
Summary:Test to move symplinks
License:WTFPL
URL:https://fedoraproject.org
%description
Test what happens if you move a symlink between versions.
%prep
%build
echo "test" > testfile
%install
mkdir -p %{buildroot}/%{_datadir}/%{name}
install -m 0644 -p testfile %{buildroot}/%{_datadir}/%{name}
mkdir -p %{buildroot}/%{_datadir}/%{name}/dir/
ln -s %{_datadir}/%{name}/testfile %{buildroot}/%{_datadir}/%{name}/dir/subdir
%files
%{_datadir}/*
%changelog
* Mon Dec 19 2016 Till Hofmann - 1-2
- move symlink one dir up
* Mon Dec 19 2016 Till Hofmann
- Initial package
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf error during upgrade that changes a directory into a symlink
On 20/12/16 12:15, Till Hofmann wrote: I have a package that contains a subdirectory which is changed to a symlink in the next release. When I upgrade, I get the following error: Error: Transaction check error: file /usr/share/symlinktest/dir/subdir from install of symlinktest-1-2.fc25.x86_64 conflicts with file from package symlinktest-1-1.fc25.x86_64 Replacing a directory needs special lua scriptlet hackery: https://fedoraproject.org/wiki/Packaging:Directory_Replacement Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf error during upgrade that changes a directory into a symlink
On Tue, Dec 20, 2016 at 7:20 AM, Tom Hughes wrote: > On 20/12/16 12:15, Till Hofmann wrote: > >> I have a package that contains a subdirectory which is changed to a >> symlink in the next release. When I upgrade, I get the following error: >> >> Error: Transaction check error: >> file /usr/share/symlinktest/dir/subdir from install of >> symlinktest-1-2.fc25.x86_64 conflicts with file from package >> symlinktest-1-1.fc25.x86_64 > > > Replacing a directory needs special lua scriptlet hackery: > > https://fedoraproject.org/wiki/Packaging:Directory_Replacement > I'm not completely sure about this, but I think using Obsoletes in the successive version is supposed make RPM handle "internal" file conflicts properly, too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf error during upgrade that changes a directory into a symlink
On 20.12.2016 13:20, Tom Hughes wrote: > On 20/12/16 12:15, Till Hofmann wrote: > >> I have a package that contains a subdirectory which is changed to a >> symlink in the next release. When I upgrade, I get the following error: >> >> Error: Transaction check error: >> file /usr/share/symlinktest/dir/subdir from install of >> symlinktest-1-2.fc25.x86_64 conflicts with file from package >> symlinktest-1-1.fc25.x86_64 > > Replacing a directory needs special lua scriptlet hackery: > > https://fedoraproject.org/wiki/Packaging:Directory_Replacement > Ah, that explains it, thanks Tom! Regards, Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf error during upgrade that changes a directory into a symlink
On 12/20/2016 01:15 PM, Till Hofmann wrote: Hi all, I have a package that contains a subdirectory which is changed to a symlink in the next release. When I upgrade, I get the following error: Error: Transaction check error: file /usr/share/symlinktest/dir/subdir from install of symlinktest-1-2.fc25.x86_64 conflicts with file from package symlinktest-1-1.fc25.x86_64 This is a classical rpm-packaging trap ;) Any hints are welcome. In short: This is a case rpm can't handle properly. One common way to work around this is to resort to lua-scripts: c.f. https://fedoraproject.org/wiki/Packaging:Guidelines#Replacing_a_symlink_to_a_directory_or_a_directory_to_any_type_file and https://fedoraproject.org/wiki/Packaging:Directory_Replacement BTW: The origin of this isn't dnf, it's rpm. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf error during upgrade that changes a directory into a symlink
On 20.12.2016 13:25, Neal Gompa wrote: > On Tue, Dec 20, 2016 at 7:20 AM, Tom Hughes wrote: >> On 20/12/16 12:15, Till Hofmann wrote: >> >>> I have a package that contains a subdirectory which is changed to a >>> symlink in the next release. When I upgrade, I get the following error: >>> >>> Error: Transaction check error: >>> file /usr/share/symlinktest/dir/subdir from install of >>> symlinktest-1-2.fc25.x86_64 conflicts with file from package >>> symlinktest-1-1.fc25.x86_64 >> >> >> Replacing a directory needs special lua scriptlet hackery: >> >> https://fedoraproject.org/wiki/Packaging:Directory_Replacement >> > > I'm not completely sure about this, but I think using Obsoletes in the > successive version is supposed make RPM handle "internal" file > conflicts properly, too. > > I tested this by adding: Obsoletes: symlinktest < 1-2 But I still get the same error, so I guess that doesn't work and the scriptlet is really needed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cross-compiler support?
On Di, 2016-12-20 at 09:28 +, David Howells wrote: > Igor Gnatenko wrote: > > > > Well there is gcc-arm-linux-gnu for example but that's for kernels per > > > description > > Didn't see it before... But looks like it doesn't work either: > > /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory > > /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory > > /usr/bin/arm-linux-gnu-ld: cannot find -lc > > /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory > > Yeah - it's intended for building kernels (though it can build anything that > provides its own userspace). FYI: they also work great for building qemu firmware. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Making use of the new Fedora Container capabilities
Hi all, So a couple of questions I'd like clarity on surrounding this... I see that we just need a Dockerfile in dist-git and fedpkg container-build can work from the existing git repo but is this intended to be supported or do we need to provide a fresh review request and then only build from the dist-git docker namespace, rather than rpm? Where there is no existing lower layer that would be useful (eg httpd+mod_php+mod_ssl) is it permitted to have a container that installs httpd, mod_php and mod_ssl for a PHP based application? What is considered acceptable for volumes specified in the dockerfile? Anywhere data or config is expected? How should we provide instructions on how to run the container? Just a readme.md in dist-git? Actually include something in the container? Is an entrypoint of ["/sbin/init"] permitted to make use of systemd for handling zombies and service unit files? This of course would then limit the container to docker hosts that have oci-systemd-hook to work properly if so, but massively simplifies things for services. As a real world example I'd like to get out there I'm testing out a container in the Fedora build infrastructure for owncloud. Here's what I was playing with last night: http://pkgs.fedoraproject.org/cgit/rpms/owncloud.git/tree/Dockerfile Here's the task from koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=16992119 Does the --scratch option actually do anything, as it doesn't seem reflected in that build? That particular build can be tested and run by: docker run -d -P candidate-registry.fedoraproject.org/f25/owncloud:rawhide-docker-candidate-20161220120656 on any docker host that has the systemd oci hook. It would be very useful to be able to provide some sort of upfront readme/document that lists volumes used to persistence etc to aid updates in future mapping to the same (named?) volume. I think we need some of this detail added to the container build guidelines for review reasons. James ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
scanmem lincese changes from GPLv2+ to GPLv3+ and LGPLv3+
Since 0.16 libscanmem is LGPLv3+ and the rest is GPLv3+. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 10:32 +0100, Dominik 'Rathann' Mierzejewski wrote: > You gave just one disadvantage of this proposal and no advantages at > all. Why do you think the above is a good idea? I, for one, do not > like > waiting a month to get bug fixes that are not security-related. We > are > not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes > available as soon as they're ready is valuable (even if you choose to > wait before installing them). Also, as was pointed out elsewhere in > this > subthread, updates get tested only after they're released to stable > very > often, so it's also valuable to get the feedback earlier rather than > in > a month. Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of batched updates is we reduce the risk of releasing botched updates. If we batch the updates together and release them all at once, possibly with new installation media, then that's something that we can QA, and that reduces the risk of a botched update. Last year we released several botched hawkey/hif updates (I lost count, but I think it was three total?) that broke PackageKit updates, so nontechnical users who don't know command line foo to recover their systems got stuck forever, never to receive an update again. Ideally that would never happen. Delaying updates by a couple of weeks seems like a small price to reduce this risk. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of batched updates is we reduce the risk of releasing botched updates. If we batch the updates together and release them all at once, possibly with new installation media, then that's something that we can QA, and that reduces the risk of a botched update. Surely it's more likely that it just delays the discovery of the botched update? The only way it reduces the risk of releasing a botched update is the the updates somehow get more testing just by staying in the testing channel longer. Which makes the question whether botched updates happen because not enough people use testing, or because there are enough people using it but they don't have enough time to spot the problems before the updates get pushed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Koji builders' specs
Hi all, where is documented what system/hw is used on (primary) Koji builders? I'm interested in memory, storage, filesystem, host operating system, guest operating system (if those are VMs), etc. The only thing I was able to find is version of mock in the log output. FWIW, I'd like to reproduce hang in gnulib's test-lock [1] test case. Unless I'm able to reproduce that somehow, I'll disable the test for the time being (done in 'coreutils' and I guess elsewhere, too). [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779 Thanks, Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Making use of the new Fedora Container capabilities
On Tue, Dec 20, 2016 at 01:00:32PM +, James Hogarth wrote: > I see that we just need a Dockerfile in dist-git and fedpkg > container-build can work from the existing git repo but is this > intended to be supported or do we need to provide a fresh review > request and then only build from the dist-git docker namespace, rather > than rpm? Ooh. That's probably an oversight. The intention is for these to be in the new namespace. > Where there is no existing lower layer that would be useful (eg > httpd+mod_php+mod_ssl) is it permitted to have a container that > installs httpd, mod_php and mod_ssl for a PHP based application? We're still working this out. For now, I think it's a judgement call, and we can figure out how we want to standardize from there. If something seems really basic and doesn't exist yet (like httpd + mod_ssl), it's probably good to work on creating that as an underlying layer, since it'll be so useful to so many other things. > What is considered acceptable for volumes specified in the dockerfile? > > Anywhere data or config is expected? > > How should we provide instructions on how to run the container? > > Just a readme.md in dist-git? Actually include something in the container? These are all great questions. :) > Is an entrypoint of ["/sbin/init"] permitted to make use of systemd > for handling zombies and service unit files? > > This of course would then limit the container to docker hosts that > have oci-systemd-hook to work properly if so, but massively simplifies > things for services. I think it _should_ be permitted, but we need metadata and naming standards to make it clear. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote: > Trying to make this idea a little more concrete. Here's two suggestions > for how it might work. These are strawman ideas -- please provide > alternates, poke holes, etc. And particularly from a QA and rel-eng > point of view. Both of these are not taking modularity into account in > any way; it's "how we could do this with our current distro-building > process". > > Option 1: Big batched update > > 1. Release F26 according to schedule > https://fedoraproject.org/wiki/Releases/26/Schedule > > 2. At the beginning of October, stop pushing non-security updates > from updates-testing to updates > > 3. Bigger updates (desktop environment refreshes, etc.) allowed into > updates-testing at this time. > > 4. Mid-October, freeze exceptions for getting into updates-testing > even. > > 5. Test all of that together in Some Handwavy Way for serious > problems and regressions. > > 6. Once all good, push from updates-testing to updates at end of > October or beginning of November. > [..] I'm lost. I'm against prolonging delays before pushes from updates-testing to updates if there's given karma, even for non-security stuff. If that's not enough, we should shape the karma-process. > Option 2: Branching! > [..] Sounds really complicated to me. What's the purpose? -- I probably lost the context ... what real-world problems are trying to fix? Everything which comes to my mind should be solved by better tooling for updates-testing testers. Have you considered the recent "bodhi for rawhide" proposal, too? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Creating cores in f25
On 12/18/2016 11:56 AM, Jan Kratochvil wrote: > On Sun, 18 Dec 2016 17:26:40 +0100, Steve Dickson wrote: >> How do I get f25 to create cores, these days? > > echo >/etc/sysctl.d/foo.conf "kernel.core_pattern=core"; reboot > > It gets broken by: > /usr/lib/sysctl.d/50-coredump.conf > > $ rpm -qf /usr/lib/sysctl.d/50-coredump.conf > systemd-231-10.fc25.x86_64 Unfortunately this did not work... :-( Thanks though... steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
release cycle thread (motivations, and... revisiting tick-tock?)
On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: > I probably lost the context ... what real-world problems are trying to fix? > Everything which comes to my mind should be solved by better tooling for > updates-testing testers. I've given this in several ways across the thread, but I don't mind restating. :) 1. I believe in the value of releases, for the project and for end users — as opposed to a "rolling release" system. But major releases are a lot of work across the project — not just release engineering, but marketing, ambassadors, design, docs, and others. One possible way to reduce this is to have major releases less frequently. I want a cadence that gives us the highest return on effort. Maybe that's six months — and maybe it isn't. 2. I really want releases to come at a known time every year, +/- two weeks. Keeping to this with six month targets means that if (when!) we slip, the next release may only have five or four months to bake. This doesn't seem like it's the ideal for the above — maybe we can get the engineering processes streamlined enough to make it comfortable, but there's still the matter of marketing and the rest. 3. The modularity initiative will mean that different big chunks of what we use to compose the OS can update at different speeds and have different lifecycles. That gives us a lot more flexibility in the above, and I'd like us to start thinking about what we *want* to. I suggested one release a year as an alternative to the current two per year. I guess three per year would be possible (but seems counter to the above); other plans like eight- or nine-month cycles don't have the fixed-calendar property I'm looking for (and I'm pretty sure no one wants to go to one every two years). The proposals previously in this thread are ideas aimed at presenting users with an annual release from a marketing/ambassadors/design, etc., point of view, but also addressing our upstream stakeholders' desire to have Fedora ship their software fast. (For example, GNOME.) I hoped we could find ways to make them also reduce release effort for developers, packagers, releng, and QA, but from the feedback so far people don't really feel like those particular suggestions do. Another possibility would be to simply keep releases as normal but go revist the "tick-tock" cadence we talked about a while ago: that is, a May/June release aimed at features, and faster Oct/Nov release where we concentrate on infrastructure — and then call that second release each year the ".1". And yet another possibility is that we keep things as they are. If that's the overall consensus, okay. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Creating cores in f25
On 12/19/2016 12:38 PM, jfi...@fedoraproject.org wrote: > Hi Steve, > > Please have a look at this email: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQ4JFTYLPT5GRW6AD4M2MWGMRAPE7ITN/ Thanks for the pointer... > > systemd developers has decided to change the default RLIMIT_CORE (ulimit -c) > from "0" to unlimited, therefore ABRT must stop creating the core dump files > in CWD. > Otherwise, you will get core dumps spread all over your file system - > that is because of crashes of daemon that used to not crash with core > dump file (their RLIMIT_CORE were 0 by default; starting with systemd-229 > the default RLIMIT_CORE is unlimited). I guess I really don't care where the core dump is created... I just need one to be created!! ;-) steved. > > > Regards, > Jakub > > -- Původní zpráva -- > Od: Steve Dickson > Komu: Development discussions related to Fedora > > Datum: 18. 12. 2016 17:35:43 > Předmět: Creating cores in f25 > > > Hello, > > How do I get f25 to create cores, these days? > > I'm getting the segfault > [55108.290610] rpc.gssd[13264]: segfault at 0 ip 55dc90af9dde sp > 7f9fb73cb7c0 error 4 in rpc.gssd[55dc90af3000+14000] > > but no core so those address are meaningless. > > Everything in the kernel is set: > f25# sysctl -a | grep kernel.core > kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I > kernel.core_pipe_limit = 4 > kernel.core_uses_pid = 1 > > The abrtd daemon is up and running > f25# ps ax | grep abrtd > 713 ? Ssl 0:00 /usr/sbin/abrtd -d -s > > What am I missing? > > tia, > > steved. > ___ > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fwd: churchyard's python-breathe-4.2.0-5.fc26 failed to build
I updated python-breathe to 4.4.0 and it build successfully but it appears that happened right after the rebuild of 4.2.0 for Python 3.6 and it keeps retrying the failed build. Is there something I need to do to stop the retries? Thanks, Dave -- Forwarded message -- From: Date: Tue, Dec 20, 2016 at 9:20 AM Subject: churchyard's python-breathe-4.2.0-5.fc26 failed to build To: davejohan...@gmail.com Package:python-breathe-4.2.0-5.fc26 Status: failed Built by: churchyard ID: 827042 Started:Tue, 20 Dec 2016 16:06:40 UTC Finished: Tue, 20 Dec 2016 16:08:10 UTC Closed tasks: - Task 16999383 on buildhw-06.phx2.fedoraproject.org Task Type: build (noarch) Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999383 error building package (arch noarch), mock exited with status 1; see build.log for more information Task 16999405 on buildvm-23.phx2.fedoraproject.org Task Type: buildSRPMFromSCM (noarch) Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999405 logs: https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/state.log https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/root.log https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/build.log srpm: https://kojipkgs.fedoraproject.org/work/tasks/ 9405/16999405/python-breathe-4.2.0-5.fc26.src.rpm Task 16999816 on buildhw-04.phx2.fedoraproject.org Task Type: buildArch (noarch) Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999816 error building package (arch noarch), mock exited with status 1; see build.log for more information http://koji.fedoraproject.org/koji/buildinfo?buildID=827042 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/daveisfera. id.fedoraproject.org/email/27208 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On Tue, Dec 20, 2016, at 05:20 PM, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: > > I probably lost the context ... what real-world problems are trying to fix? > > Everything which comes to my mind should be solved by better tooling for > > updates-testing testers. > > I've given this in several ways across the thread, but I don't mind > restating. :) > > 1. I believe in the value of releases, for the project and for end >users — as opposed to a "rolling release" system. But major releases >are a lot of work across the project — not just release engineering, >but marketing, ambassadors, design, docs, and others. One possible >way to reduce this is to have major releases less frequently. I want >a cadence that gives us the highest return on effort. Maybe that's >six months — and maybe it isn't. If we prepare to do more "significant" updates during the release cycle we are going to need to do some of this streamlining regardless. It sounds like this is worthy of exploring solely as a need to grow area. > 2. I really want releases to come at a known time every year, +/- two >weeks. Keeping to this with six month targets means that if (when!) >we slip, the next release may only have five or four months to bake. >This doesn't seem like it's the ideal for the above — maybe we can >get the engineering processes streamlined enough to make it >comfortable, but there's still the matter of marketing and the rest. We build Fedora for a lot of reasons, and I think this one is as important as the others. I believe that we will find an easier time creating energy around our releases if they are more known in time. I am not sure they have to be once per year on a fixed calendar, but they need to represent the culmination of work to introduce significant features. I actually would prefer to see a feature-gated release option as opposed to only thinking in terms of time-gates. I think having something to say is more important than knowing when you're going to speak. > 3. The modularity initiative will mean that different big chunks of >what we use to compose the OS can update at different speeds and >have different lifecycles. That gives us a lot more flexibility in >the above, and I'd like us to start thinking about what we *want* >to. Building on this, major module releases might be the feature-gate trigger we need to do a new "release" while incremental improvement gets pushed out as a .X release. > I suggested one release a year as an alternative to the current two per > year. I guess three per year would be possible (but seems counter to > the above); other plans like eight- or nine-month cycles don't have the > fixed-calendar property I'm looking for (and I'm pretty sure no one > wants to go to one every two years). > > The proposals previously in this thread are ideas aimed at presenting > users with an annual release from a marketing/ambassadors/design, etc., > point of view, but also addressing our upstream stakeholders' desire to > have Fedora ship their software fast. (For example, GNOME.) I hoped we > could find ways to make them also reduce release effort for developers, > packagers, releng, and QA, but from the feedback so far people don't > really feel like those particular suggestions do. > > Another possibility would be to simply keep releases as normal but go > revist the "tick-tock" cadence we talked about a while ago: that is, a > May/June release aimed at features, and faster Oct/Nov release where we > concentrate on infrastructure — and then call that second release each > year the ".1". Tick-tock makes me worried that people will begin to assume the Tick isn't worthwhile and they should wait on Tock. > And yet another possibility is that we keep things as they are. If > that's the overall consensus, okay. :) Now you're talking crazy :P j/k! regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > Surely it's more likely that it just delays the discovery of the > botched > update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. > The only way it reduces the risk of releasing a botched update is > the > the updates somehow get more testing just by staying in the testing > channel longer. ...and actual QA, from the professionals and volunteers on the QA team, who are very good at finding bugs pre-release but currently do zero QA on our updates because it's an unmanageable rolling stream of a bazillion separate updates. With batched updates, you can test a batch with the same overall criteria used for releases to see if it's botched. That's the advantage of batching over simply extending the amount of time spent in updates-testing. > Which makes the question whether botched updates happen because not > enough people use testing, or because there are enough people using > it > but they don't have enough time to spot the problems before the > updates > get pushed. We indeed do not need batched updates to extend the length of time updates remain in testing. We could (and should) do that immediately. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On 12/20/2016 06:27 AM, Tom Hughes wrote: On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of batched updates is we reduce the risk of releasing botched updates. If we batch the updates together and release them all at once, possibly with new installation media, then that's something that we can QA, and that reduces the risk of a botched update. Surely it's more likely that it just delays the discovery of the botched update? The only way it reduces the risk of releasing a botched update is the the updates somehow get more testing just by staying in the testing channel longer. Which makes the question whether botched updates happen because not enough people use testing, or because there are enough people using it but they don't have enough time to spot the problems before the updates get pushed. Batched updates are valuable when testing happens with the whole. It sorts out complex interactions between multiple package updates by testing them all together. It's a thing that could be adopted whether or not Fedora moves to a once-a-year release and it could be done in addition to rolling updates. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On Tuesday, December 20, 2016 11:20:49 AM CET Matthew Miller wrote: > 1. I believe in the value of releases, for the project and for end >users — as opposed to a "rolling release" system. But major releases >are a lot of work across the project — not just release engineering, >but marketing, ambassadors, design, docs, and others. One possible >way to reduce this is to have major releases less frequently. I want >a cadence that gives us the highest return on effort. Maybe that's >six months — and maybe it isn't. I believe in both -- and I believe Fedora could have both -- "rolling release" and "major releases" as a separate "products". There are people in the wild who will never use Fedora as the workstation system because they seek for rolling distro (while Rawhide is _almost_ there). It is sad we loose those users. > I suggested one release a year as an alternative to the current two per > year. I don't have a strong opinion here ... but I personally like the idea about annual "major release" cycle (supporting one stable fedora for 2Y+). > The proposals previously in this thread are ideas aimed at presenting > users with an annual release from a marketing/ambassadors/design, etc., > point of view, but also addressing our upstream stakeholders' desire to > have Fedora ship their software fast. (For example, GNOME.) Would the 'rolling release' approach help WRT upstream stakeholders, even if we had longer major release cycle? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On 12/20/2016 08:20 AM, Matthew Miller wrote: On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: I probably lost the context ... what real-world problems are trying to fix? Everything which comes to my mind should be solved by better tooling for updates-testing testers. I've given this in several ways across the thread, but I don't mind restating. :) 1. I believe in the value of releases, for the project and for end users — as opposed to a "rolling release" system. But major releases are a lot of work across the project — not just release engineering, but marketing, ambassadors, design, docs, and others. One possible way to reduce this is to have major releases less frequently. I want a cadence that gives us the highest return on effort. Maybe that's six months — and maybe it isn't. 2. I really want releases to come at a known time every year, +/- two weeks. Keeping to this with six month targets means that if (when!) we slip, the next release may only have five or four months to bake. This doesn't seem like it's the ideal for the above — maybe we can get the engineering processes streamlined enough to make it comfortable, but there's still the matter of marketing and the rest. 3. The modularity initiative will mean that different big chunks of what we use to compose the OS can update at different speeds and have different lifecycles. That gives us a lot more flexibility in the above, and I'd like us to start thinking about what we *want* to. I'd like to clarify what people have in mind here because it's pretty fundamental to how to take the proposal. More on my interpretation below. I suggested one release a year as an alternative to the current two per year. I guess three per year would be possible (but seems counter to the above); other plans like eight- or nine-month cycles don't have the fixed-calendar property I'm looking for (and I'm pretty sure no one wants to go to one every two years). The proposals previously in this thread are ideas aimed at presenting users with an annual release from a marketing/ambassadors/design, etc., point of view, but also addressing our upstream stakeholders' desire to have Fedora ship their software fast. (For example, GNOME.) I hoped we could find ways to make them also reduce release effort for developers, packagers, releng, and QA, but from the feedback so far people don't really feel like those particular suggestions do. Another possibility would be to simply keep releases as normal but go revist the "tick-tock" cadence we talked about a while ago: that is, a May/June release aimed at features, and faster Oct/Nov release where we concentrate on infrastructure — and then call that second release each year the ".1". And yet another possibility is that we keep things as they are. If that's the overall consensus, okay. :) You can't implement modularity *and* keep things as they are. So here's how I take your proposal: Once per year a new base Fedora release comes out. It has a nice new stable glibc, gcc, etc. This is the content that all editions and spins have in common. Each edition or spin makes releases of their content layered on top of the above package stream, but they can inject packages that are unique to their edition. So the desktop edition can still make multiple releases per year if they want, but they're layering on top of the basic annual Fedora release. Is that what people have in mind, or something else? -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On Tue, Dec 20, 2016 at 05:51:33PM +0100, Pavel Raiskup wrote: > I believe in both -- and I believe Fedora could have both -- "rolling > release" and "major releases" as a separate "products". > > There are people in the wild who will never use Fedora as the workstation > system because they seek for rolling distro (while Rawhide is _almost_ > there). It is sad we loose those users. I have a two-pronged approach here. First, I very frequently hear this: "Fedora should have an LTS — or be a rolling release." These two things are very far apart in actual implication, but they have one big thing in common, and when pressed, it usually comes down to: "Upgrades are painful and scary." We have been working really hard on making upgrades fast and seamless, so we need to deliver that message to users (and of course work to make further improvements). Second, yeah, for the enthusiasts and people who really _do_ want the *bleeding* edge and do not mind all that entails, let's improve Rawhide (and/or Bikeshed). > > The proposals previously in this thread are ideas aimed at presenting > > users with an annual release from a marketing/ambassadors/design, etc., > > point of view, but also addressing our upstream stakeholders' desire to > > have Fedora ship their software fast. (For example, GNOME.) > Would the 'rolling release' approach help WRT upstream stakeholders, even > if we had longer major release cycle? Maybe? I think the value in getting the upstream software into Fedora is getting it to more mainstream users, and I think rolling-Fedora via Rawhide/Bikeshed would still be niche. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On 20/12/16 16:48, Michael Catanzaro wrote: On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: Surely it's more likely that it just delays the discovery of the botched update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. I didn't think updates-testing would be, it's just I don't think many people use it so I'm not sure having things there for longer will actually help. The only way it reduces the risk of releasing a botched update is the the updates somehow get more testing just by staying in the testing channel longer. ...and actual QA, from the professionals and volunteers on the QA team, who are very good at finding bugs pre-release but currently do zero QA on our updates because it's an unmanageable rolling stream of a bazillion separate updates. With batched updates, you can test a batch with the same overall criteria used for releases to see if it's botched. That's the advantage of batching over simply extending the amount of time spent in updates-testing. Well yes obviously if those batched updates get some formal QA then that's a different matter, but I didn't realise that was proposed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly batches instead. we would push >> daily security fixes and updates-testing. However this would make atomic >> host >> 2 week releases much less useful, as there would be no updates except for >> once >> a month. > > You gave just one disadvantage of this proposal and no advantages at > all. Why do you think the above is a good idea? I, for one, do not like > waiting a month to get bug fixes that are not security-related. We are > not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes > available as soon as they're ready is valuable (even if you choose to > wait before installing them). Also, as was pointed out elsewhere in this > subthread, updates get tested only after they're released to stable very > often, so it's also valuable to get the feedback earlier rather than in > a month. Having bug fixes available sooner also means having regressions. It's inevitable. And that's why there's updates-testing repo, and why it's not enabled by default on release. Why is user opt in to updates-testing insufficient? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly batches instead. we would push >> daily security fixes and updates-testing. However this would make atomic >> host >> 2 week releases much less useful, as there would be no updates except for >> once >> a month. > > You gave just one disadvantage of this proposal and no advantages at > all. Why do you think the above is a good idea? I, for one, do not like > waiting a month to get bug fixes that are not security-related. We are > not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes > available as soon as they're ready is valuable (even if you choose to > wait before installing them). Also, as was pointed out elsewhere in this > subthread, updates get tested only after they're released to stable very > often, so it's also valuable to get the feedback earlier rather than in > a month. I keep hearing different opinions on update frequency, and it suggests a discoverable dial is needed on the users' end of this equation. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 10:48 -0600, Michael Catanzaro wrote: > On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > > Surely it's more likely that it just delays the discovery of the > > botched > > update? > > I don't think updates-testing should be batched. Testers should of > course still get all test updates ASAP. > > > The only way it reduces the risk of releasing a botched update is > > the > > the updates somehow get more testing just by staying in the testing > > channel longer. > > ...and actual QA, from the professionals and volunteers on the QA team, > who are very good at finding bugs pre-release but currently do zero QA > on our updates because it's an unmanageable rolling stream of a > bazillion separate updates. This is an exaggeration. We do test updates. We could always test everything *better*, and that applies to updates, but it is not true to say we 'do zero QA' on them. > With batched updates, you can test a batch > with the same overall criteria used for releases to see if it's > botched. That's the advantage of batching over simply extending the > amount of time spent in updates-testing. This is also an exaggeration, or at least it's a long way from proven. I don't think we could say that just batching updates would suddenly allow us to QA them as extensively as we QA a release. Release testing involves a lot of work by a lot of people; especially desktop validation is rather onerous. If we're talking about *weekly* batched updates, no, it is not at all practical to assume we'll magically be able to find the time to do release-validation level testing of each update batch every week. We could in theory apply what automated functional testing we have to batched updates, but it's not at all a simple thing to do, and we could in fact apply it to *non*-batched updates too. It's something I've been wanting to do for a while, just have not had time for yet. -- 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: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: > Batched updates are valuable when testing happens with the whole. It > sorts out complex interactions between multiple package updates by > testing them all together. Of course, a corollary of this is that you have to try and figure out which bit of the batched update actually caused the bug you saw. -- 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: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: > I didn't think updates-testing would be, it's just I don't think many > people use it so I'm not sure having things there for longer will > actually help. We do in fact have numbers on this. For instance, since F25 came out, 218 people have filed 1,404 items of feedback on F25 updates in 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: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, 2016-12-20 at 09:33 -0800, Adam Williamson wrote: > If we're talking about *weekly* batched > updates, no, it is not at all practical to assume we'll magically be > able to find the time to do release-validation level testing of each > update batch every week. Of course it wouldn't make sense to do a weekly batch. I was thinking monthly. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On 20/12/16 17:40, Adam Williamson wrote: On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: I didn't think updates-testing would be, it's just I don't think many people use it so I'm not sure having things there for longer will actually help. We do in fact have numbers on this. For instance, since F25 came out, 218 people have filed 1,404 items of feedback on F25 updates in Bodhi. I wonder how many have updates-testing enabled, and how many have just installed particular updates to test them... I don't have updates-testing enabled, but I will test specific updates that relate to bugs I have filed by updating that package with "--enablerepo=updates-testing" and then file feedback,. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
I'll repost this because I believe Kevin had a good point: I don't understand why we are trying to reinvent the wheel here. The infrastructure for Kevin's suggestion is in place now - KDE has been using it and it works. On Thu, Dec 8, 2016 at 9:07 PM, Kevin Kofler wrote: > However, I also do not see why we cannot just do such big updates through > the regular update process rather than in a big .1 drop. The KDE SIG has > experience with pushing big grouped updates that look a lot like a .1 > release for Plasma users. They go through the regular update process just > fine. Grouping them together with updates to GNOME, LibreOffice etc. in one > batch is not necessary and would only add unnecessary delays. > > I think pushing all updates in a big drop will actually make them LESS > tested than if they just trickle through one at a time. > That is an excellent point. KDE for some time has been pushing out large updates using the regular update process. What is the issue with just doing this? It certainly seems much more straight forward and easier than ~.x updates. Fedora version releases could then be reserved for structural / architectural concerns rather than software updates and bug fixes. Fedora stays fast moving and Fedora X releases come less often - seems like a win / win. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On Tuesday, December 20, 2016 12:11:32 PM CET Matthew Miller wrote: > First, I very frequently hear this: "Fedora should have an LTS — or be > a rolling release." These two things are very far apart in actual > implication, but they have one big thing in common, and when pressed, > it usually comes down to: "Upgrades are painful and scary." We have > been working really hard on making upgrades fast and seamless, so we > need to deliver that message to users (and of course work to make > further improvements). Indeed, I don't remember when I had troubles with N->N+1 major fedora upgrade last time (though I always do distro-sync) on _my workstation_. Upgrades on production servers (services built on top of Fedora) is probably what scares users (with N->N+1 you can always expect a lot of library API changes). But maybe this is the thing which might be solved by modularity; one version of "module" version to span multiple Fedora major versions... Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On 12/20/2016 09:34 AM, Adam Williamson wrote: On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: Batched updates are valuable when testing happens with the whole. It sorts out complex interactions between multiple package updates by testing them all together. Of course, a corollary of this is that you have to try and figure out which bit of the batched update actually caused the bug you saw. Or to be even more specific: 1. Batched update testing is more work. 2. Fixing bugs found in batched updates is more work. Of the two I think we already end up doing #2, it's just a question of when. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > I'll repost this because I believe Kevin had a good point: > > I don't understand why we are trying to reinvent the wheel here. The > infrastructure for Kevin's suggestion > is in place now - KDE has been using it and it works. This has the same downside as a rolling release to end users. It asks them to take a big user interface / user experience update whenever we push it, or else disable all updates including security fixes and bugfixes that do not change user experience. Modularity, however, will allow us to update module stacks — like GNOME or KDE — while still also maintaining older versions for some time... without tying the whole release to that cycle. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
Maybe a bit bit off topic WRT $Subject, sorry if it is the case. On Tuesday, December 20, 2016 8:23:12 AM CET Michael Catanzaro wrote: > Batched updates are something I really want to do regardless. > Of course having fixes available sooner is valuable, but you have to weigh > that against the cost of releasing a *botched* update. The advantage of > batched updates is we reduce the risk of releasing botched updates. If we > batch the updates together and release them all at once, possibly with new > installation media, then that's something that we can QA, and that reduces the > risk of a botched update. Not always, unless we have https://fedorahosted.org/bodhi/ticket/663 fixed first. Packages which depend like: A -> concrete_version_of(B) -> concrete_version_of(C) .. are now updated in "batches". People interested in 'C' give karma to 'C', but also approve 'A' and 'B' (without paying attention to test those packages independently). But breaking 'A' or 'B' breaks stable release anyway. So batched update _increases_ the risk of a "botched" update. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 10:08 AM, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > > I'll repost this because I believe Kevin had a good point: > > > > I don't understand why we are trying to reinvent the wheel here. The > > infrastructure for Kevin's suggestion > > is in place now - KDE has been using it and it works. > > This has the same downside as a rolling release to end users. It asks > them to take a big user interface / user experience update whenever we > push it, or else disable all updates including security fixes and > bugfixes that do not change user experience. > > Modularity, however, will allow us to update module stacks — like GNOME > or KDE — while still also maintaining older versions for some time... > without tying the whole release to that cycle. Well, it isn't some theoretical construct... it's being done now with KDE and has been working just fine. It stays in updates-testing until you decide to push it to stable. KDE folks by and large want the updates as fast as possible. If the GNOME folks would like their updates to age for six months, they can just keep them in updates-testing. Seems like we're just making this more complicated than it is. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On 20 December 2016 at 11:20, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: >> I probably lost the context ... what real-world problems are trying to fix? >> Everything which comes to my mind should be solved by better tooling for >> updates-testing testers. > > I've given this in several ways across the thread, but I don't mind > restating. :) > > 1. I believe in the value of releases, for the project and for end >users — as opposed to a "rolling release" system. But major releases >are a lot of work across the project — not just release engineering, >but marketing, ambassadors, design, docs, and others. One possible >way to reduce this is to have major releases less frequently. I want >a cadence that gives us the highest return on effort. Maybe that's >six months — and maybe it isn't. > > 2. I really want releases to come at a known time every year, +/- two >weeks. Keeping to this with six month targets means that if (when!) >we slip, the next release may only have five or four months to bake. >This doesn't seem like it's the ideal for the above — maybe we can >get the engineering processes streamlined enough to make it >comfortable, but there's still the matter of marketing and the rest. > > 3. The modularity initiative will mean that different big chunks of >what we use to compose the OS can update at different speeds and >have different lifecycles. That gives us a lot more flexibility in >the above, and I'd like us to start thinking about what we *want* >to. > I am having a hard time reconciling 2 and 3. We want to have regular releases AND we want them to be whenever we want... this is Quantum Mechanics all over... the release is both a particle and a wave.. and the cat is both alive and dead. The difference is that only one of the two events is 'real' after you have opened the box. Do we end up with a release which is regular? Or do we end up with a release which has different life-cycles? If the answer is 'yes', ok but we will need to be clearer when and how we measure both. > I suggested one release a year as an alternative to the current two per > year. I guess three per year would be possible (but seems counter to > the above); other plans like eight- or nine-month cycles don't have the > fixed-calendar property I'm looking for (and I'm pretty sure no one > wants to go to one every two years). > > The proposals previously in this thread are ideas aimed at presenting > users with an annual release from a marketing/ambassadors/design, etc., > point of view, but also addressing our upstream stakeholders' desire to > have Fedora ship their software fast. (For example, GNOME.) I hoped we > could find ways to make them also reduce release effort for developers, > packagers, releng, and QA, but from the feedback so far people don't > really feel like those particular suggestions do. > The only way I can see that working is that QA, releng, etc only deal with a small part of the OS that the rest of the OS is built from. Everything else above either a sack of potatoes or a well oiled machine but it depends on the group (be it KDE, GNOME, Docker/Atomic/etc, i386/ppc/arm, etc) putting the work into it to make it so. It may make things look like 'second class citizens' but every group has called itself that when it doesn't get its way so it just makes it clearer. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 10:22:41AM -0800, Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with > KDE and has been working just fine. It stays in updates-testing until > you decide to push it to stable. KDE folks by and large want the > updates as fast as possible. If the GNOME folks would like their > updates to age for six months, they can just keep them in > updates-testing. Seems like we're just making this more complicated > than it is. Right, KDE on Fedora is more like a rolling release. TBH, this is something of a luxury because none of the Editions are dependent on KDE. If Workstation were KDE-based, I'd be inclined to push back against the practice. I don't think anyone said we want the GNOME updates to "age" for six months. What I'm saying is that the release model allows us to provide a new shiny version quickly after the upstream release, but users get to choose if they want it right now. If we did this by putting a big GNOME update into updates-testing, a) people would have to opt into getting testing updates to get it, or do the even more advanced thing of cherry-picking from the updates repo, and b) once having done that, would presumably get all future updates to that stack through updates-testing, and c) if there's a fix to the older GNOME, we wouldn't have a way to provide it. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ssh using kerberos (was: Packagers - Flag day 2016 Important changes)
On Mon, 2016-12-19 at 12:45 +0100, Nikos Mavrogiannopoulos wrote: > On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote: > > Greetings. > > > > As previously announced, releng has made a number of changes as > > part > > of > > it's 2016 "flag day". > > > > All package maintainers will want to make sure they have updated to > > the > > following package versions (some may be in testing as of this > > email): > > > > python-cccolutils-1.4-1 > > fedpkg-1.26-2 > > fedora-packager-0.6.0.0-1 > > pyrpkg-1.47-3 > > koji-1.11.0-1 > > > > Please also see the following links for up to date information: > > > > https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 > > > > The following changes were made: > > > > * koji and the source lookaside were changed to use kerberos > > authentication > > instead of ssl certificates. All maintainers will need to: > > > > kinit your-fas-accountn...@fedoraaproject.org > > > > to get a valid kerberos TGT and be able to authenticate to koji > > and > > the lookaside upload cgi. > > Will this include a switch to GSSAPI for SSH? As it is now the SSH > private key is still needed to commit to git repositories, even if a > valid ticket is present. Maybe down the road. but certainly not in the immediate future. Dennis 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
New sources format
What's with the new sources format? The old format, I could do `md5sum -c sources` Why not make the new format with SHA512 follow the same pattern, so I could do: `shasum -c sources` or `sha512sum -c sources`? Is there any standard command-line tool to parse this new format, or do I just gotta grep/awk/bash my way through it? -- Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
pkgdb: Could not save the request for branch: master, has it already been requested?
Hi I filed the request to unretire eigen2, but I accidentally specified only the rhbz ticket number instead of the full URL so it got denied with "Invalid review BZ". I now tried filing a new unretirement request with the full ticket url, but now I'm getting Could not save the request for branch: master, has it already been requested? It looks like the denied request still counts as pending request? Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New sources format
On 20/12/16 22:28, Christopher wrote: > What's with the new sources format? > The old format, I could do `md5sum -c sources` > Why not make the new format with SHA512 follow the same pattern, so I could > do: `shasum -c sources` or `sha512sum -c sources`? > > Is there any standard command-line tool to parse this new format, or do I > just gotta grep/awk/bash my way through it? As far as I can see it's using the BSD tagged format, which the coreutils sha512sum command can parse. I.E. the following format is supported since v8.20 (2012-10-23) SHA512 (filename) = ... cheers, Pádraig ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New sources format
On Tue, Dec 20, 2016 at 6:31 PM Pádraig Brady wrote: > On 20/12/16 22:28, Christopher wrote: > > What's with the new sources format? > > The old format, I could do `md5sum -c sources` > > Why not make the new format with SHA512 follow the same pattern, so I > could do: `shasum -c sources` or `sha512sum -c sources`? > > > > Is there any standard command-line tool to parse this new format, or do > I just gotta grep/awk/bash my way through it? > > As far as I can see it's using the BSD tagged format, > which the coreutils sha512sum command can parse. > I.E. the following format is supported since v8.20 (2012-10-23) > > SHA512 (filename) = ... > > cheers, > Pádraig > Ah, okay, my mistake. `sha512sum -c sources` works fine. I accidentally ran `shasum -c sources` twice! Thanks! I wasn't previously aware of this format being a standard anywhere. `man sha512sum` has enlightened me :) -- Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
>> The only way it reduces the risk of releasing a botched update is >> the >> the updates somehow get more testing just by staying in the testing >> channel longer. > > ...and actual QA, from the professionals and volunteers on the QA team, > who are very good at finding bugs pre-release but currently do zero QA > on our updates because it's an unmanageable rolling stream of a > bazillion separate updates. With batched updates, you can test a batch > with the same overall criteria used for releases to see if it's > botched. That's the advantage of batching over simply extending the > amount of time spent in updates-testing. I've not seen that proposed anywhere, I'm not sure QA has the resources to actually do that. >> Which makes the question whether botched updates happen because not >> enough people use testing, or because there are enough people using >> it >> but they don't have enough time to spot the problems before the >> updates >> get pushed. > > We indeed do not need batched updates to extend the length of time > updates remain in testing. We could (and should) do that immediately. At the moment the time is a week, basically I don't see any real proposal to extend that overall, just to batch updates out on a Monday (not sure that is the best day if no one tests over a weekend). Most of the updates that go out quicker than a week are due to receiving the explicitly requested amount of karma. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 1:23 PM Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with KDE > and has > been working just fine. It stays in updates-testing until you decide to > push it to stable. KDE > folks by and large want the updates as fast as possible. If the GNOME > folks would like > their updates to age for six months, they can just keep them in > updates-testing. Seems > like we're just making this more complicated than it is. > You can't keep things simmering in updates-stable for a long time. What if you need to push a bug fix or security fix that is not tied to a new major upstream release? Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 5:45 PM, Rahul Sundaram wrote: > Well, it isn't some theoretical construct... it's being done now with KDE >> and has >> been working just fine. It stays in updates-testing until you decide to >> push it to stable. KDE >> folks by and large want the updates as fast as possible. If the GNOME >> folks would like >> their updates to age for six months, they can just keep them in >> updates-testing. Seems >> like we're just making this more complicated than it is. >> > > You can't keep things simmering in updates-stable for a long time. What > if you need to push a bug fix or security fix that is not tied to a new > major upstream release? > > Rahul > I was just repeating what I thought was a good suggestion - which is based upon what has already been implemented using the current infrastructure. Reserve "new" releases only for things that absolutely require it and let everything else be updated piecemeal. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 9:26 PM Gerald B. Cox wrote: > > I was just repeating what I thought was a good suggestion - which is based > upon what has > already been implemented using the current infrastructure. Reserve "new" > releases only for things > that absolutely require it and let everything else be updated piecemeal. > Right. I understand that but the solution of letting things stay in updates-testing for a long time isn't a great way to implement that. It an abuse of updates-testing. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 6:30 PM, Rahul Sundaram wrote: > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > No one is doing that. You have to read the whole thread. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 9:33 PM Gerald B. Cox wrote: > > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > > > No one is doing that. You have to read the whole thread. > What makes you assume I didn't? I am quoting you again " KDE folks by and large want the updates as fast as possible. If the GNOME folks would like their updates to age for six months, they can just keep them in updates-testing." ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 6:41 PM, Rahul Sundaram wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > Obviously you missed it. Again, you have to take that comment in context of the entire thread. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 23 End Of Life
As of the 20th of December 2016, Fedora 23 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 23. A previous reminder was sent on 28th of November 2016 [0]. Fedora 24 will continue to receive updates until approximately one month after the release of Fedora 26. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions [2] on how to upgrade from a previous release of Fedora to a version receiving updates. Mohan Boddu. [0]https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HLHKRTIB33EDZXP624GHF2OZLHWAGKSJ/#Q5O44X4BEBOYEKAEVLSXVI44DSNVHBYG [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 9:59 PM Gerald B. Cox wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > > > Obviously you missed it. Again, you have to take that comment in context > of the entire thread. > I don't see any context missing in a direct quote which I responded to. If you believe otherwise, feel free to summarize your position and include any context you need to. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > That's ok... I don't think you'd get the point - as I said the context was the thread. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20161219.n.0 compose check report
On Mon, 2016-12-19 at 15:46 -0800, Adam Williamson wrote: > > * Installs or upgrades of any package set besides minimal seem to hang > during boot > > That second one is a doozy - it causes most of the failures - and I'm > going to look into it a bit more now. But it's at least the case that > default installs of the KDE live, Server netinst and Server DVD, and > the 'KDE package set' install test from the Server DVD, all install > fine, but just get stuck at a black screen after grub when trying to > boot the installed system. Minimal installs, however - like the default > install of the Everything netinst, and the 'universal' tests which > explicitly select the 'Fedora Custom Operating System' package set > (which is basically the same thing as 'minimal install') - boot fine. > > I'll poke into this a bit more manually. So this seems to be some kind of kernel issue which showed up with kernel 4.10; when the openQA VMs are run with '-cpu host', this problem happens. I poked into it a bit and filed https://bugzilla.redhat.com/show_bug.cgi?id=1406609 . Running the tests with '-cpu Nehalem' instead seems to work fine, so I've changed both openQA instances over to that for now, and done a full re-run of the 20161219.n.0 tests on both instances (those are running now). -- 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: Two more concrete ideas for what a once-yearly+update schedule would look like
On Tue, Dec 20, 2016 at 10:25 PM Gerald B. Cox wrote: > > On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > > > That's ok... I don't think you'd get the point - as I said the context was > the thread. > I have read the thread. If you are going to insist that I missed a context repeatedly, I would recommend you explicitly state what it is without making any assumptions about whether the other person can understand it. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packages FTBFS with Python 3.6
On Wednesday, December 21, 2016 12:18:47 AM CET Miro Hrončok wrote: > Hi all, > We've recently tried to rebuild all Python packages with Python 3.6. > However, we currently have bunch of packages that simply fail to build. > ... > Everything currently happens in a side tag. I will notify you when the > side tag gets merged. The 'gettext' FTBFS is not related only to Python 3.6 tag [1, FWIW, still without answer]. Once I resolve those issues, am I expected to build the package against both 'f26' and (with bumped version) 'f26-python3' targets? When do you expect merging 'f26-python3' into f26? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PQD576JZLERFY6ROI3GF7UYXKZIRI33G/ Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: release cycle thread (motivations, and... revisiting tick-tock?)
On Ter, 2016-12-20 at 11:20 -0500, Matthew Miller wrote: > 2. I really want releases to come at a known time every year, +/- two > weeks. Keeping to this with six month targets means that if > (when!) > we slip, the next release may only have five or four months to > bake. This is a problem IMHO. We shouldn't shorter the next release when we slip. But I remember when we got a big slip (because Fedora have one of the first releases that support secure boot), I saw a big concern with marketing , that was a bad image (the big slip) etc etc. So I think this rule was created by marketing/image of the Fedora to outside. So at least we should assume that we may do less 2 release per year and break the cycle of releases on May/Jun and Nov/Dec. One more note , I didn't agree that slip was bad , Fedora software is based in many upstream software if other parts slip we may/should also slip until get things stable. So maybe here is more a question of marketing to have more freedom in choice of the cycles. Maybe we can do a schedule with more 3 or 4 week and instead slip we could anticipate the release, I don't know just another idea. > This doesn't seem like it's the ideal for the above — maybe we can > get the engineering processes streamlined enough to make it > comfortable, but there's still the matter of marketing and the > rest. -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
