[Bug 1307196] New: perl-Lingua-Stem-Ru-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1307196 Bug ID: 1307196 Summary: perl-Lingua-Stem-Ru-0.04 is available Product: Fedora Version: rawhide Component: perl-Lingua-Stem-Ru Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.04 Current version/release in rawhide: 0.03-1.fc24 URL: http://search.cpan.org/dist/Lingua-Stem-Ru Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
lorax changes in 24.10
Just a heads up in case this goes pear shaped. lorax-24.10 has moved the templates into a template directory under /usr/share/lorax/. This shouldn't break anything, and provides for future customization of boot.iso contents via custom templates. Documentation is here - https://rhinstaller.github.io/lorax/lorax.html#custom-templates -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: access denied
On Thu, 11 Feb 2016 18:32:57 +0100 gil wrote: > Il 11/02/2016 18:23, Stephen John Smoogen ha scritto: > > On 11 February 2016 at 09:58, gil wrote: > >> https://gil.fedorapeople.org/ > > > > Part of a rebuild outage. This should be fixed now. > > > yes, now work > thanks > regards Just as a side note, when people see these kinds of issues, could you file an infrastructure ticket instead of asking on list? The ticket will get to the folks that can fix things faster and not bother the entire list about it. kevin pgp2H9r7ikQ31.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True exclude=kernel Excerpt from man dnf.conf: installonlypkgs list List of provide names of packages that should only ever be installed, never upgraded. Kernels in particular fall into this category. These packages are never removed by dnf autoremove even if they were installed asdependencies(see clean_requirements_on_remove for auto removal details). The num‐ ber of kept package versions is regulated by installonly_limit. installonly_limit integer Number of installonly packages allowed to be installed concur‐ rently. Defaults to 3. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora Rawhide 20160212 compose check report
On Fri, 2016-02-12 at 19:44 +, Fedora compose checker wrote: > > Failed openQA tests: 16 of 63 32-bit tests are still failing to boot, still kernel issue there. > ID: 5252 Test: x86_64 workstation_live default_install@uefi > URL: https://openqa.fedoraproject.org/tests/5252 > ID: 5251 Test: x86_64 workstation_live default_install > URL: https://openqa.fedoraproject.org/tests/5251 The workstation lives seem to be failing to boot properly, I'm on vacation so I haven't looked into it in detail yet. In openQA they get stuck on the Plymouth bootsplash. If someone can take a look and see if they can see what's going wrong, that'd be great. > ID: 5194 Test: x86_64 universal package_set_kde > URL: https://openqa.fedoraproject.org/tests/5194 This looks like a false alarm, package install step of the test got stuck (seems to happen occasionally). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips wrote: > Dear all, > > I would like to formally send a mail requesting some feedback from cicku > regarding the maintenance of the backintime package. > There is one open bug, which requests an update [1] and additionally a > trac ticket [2] was also opened, not by me. > I can see, that with an upgrade to later versions we'll loose the > differentiation between a KDE and Gnome GUI, but I don't see why that > really is an issue. > Additionally two request to become co-maintainer are unanswered so far, so > I hope that we'll get that sorted pretty quick. > Possibly there are some Chinese New Year festivities, so perhaps we'll > give him some more time, but I would love to get some feedback. > > Johannes > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1186184 > [2] https://fedorahosted.org/fesco/ticket/1542 > CCing Christopher. jeff -- Jeff Backus jeff.bac...@gmail.com http://github.com/jsbackus -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 2:55 PM, Johannes Lips wrote: >> On Fri, Feb 12, 2016 at 1:48 PM, Johannes Lips >> > >> You make a lot of assumptions in that statement. People filter email >> quite a bit and relying on bugzilla mail alone is not sufficient. >> >> I find it ironic that your original email said "I would like to >> formally send a mail requesting some feedback from cicku.." but you >> didn't bother to email him directly. That doesn't strike me as very >> formal. I'm under no illusions that he is likely to respond to direct >> contact either, but it should at least be attempted. >> > Why do I need to defend myself for following, perhaps not perfectly, the > normal procedure in these cases and additionally I offered my help > maintaining that package. > I and another packager requested co-maintainership and are willing to help > out, so I really don't see why I need to defend myself for the willingness to > give up my valuable spare time. I asked if you had sent him an email directly and instead of doing that you waved off my question with assumptions. I think it's fantastic you want to pick up the packages and I fully support that. However your attempt to follow the process is one of many lately that don't actually follow the process and seem to want to short-circuit to the end result. The purpose of having a process is to follow it because we have reasons for doing so. Reminding people of that is part of the deal. Conversely, if those reasons don't make sense then perhaps we need to revise the process. Either way, having a discussion around it isn't an attack that you need to defend yourself against. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
> On Fri, Feb 12, 2016 at 1:48 PM, Johannes Lips wrote: > > You make a lot of assumptions in that statement. People filter email > quite a bit and relying on bugzilla mail alone is not sufficient. > > I find it ironic that your original email said "I would like to > formally send a mail requesting some feedback from cicku.." but you > didn't bother to email him directly. That doesn't strike me as very > formal. I'm under no illusions that he is likely to respond to direct > contact either, but it should at least be attempted. > Why do I need to defend myself for following, perhaps not perfectly, the normal procedure in these cases and additionally I offered my help maintaining that package. I and another packager requested co-maintainership and are willing to help out, so I really don't see why I need to defend myself for the willingness to give up my valuable spare time. Johannes > josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160212 compose check report
Missing expected images: Kde disk raw armhfp Cloud_atomic disk raw x86_64 Kde live i386 Minimal disk raw armhfp Kde live x86_64 Images in this compose but not Rawhide 20160211: Mate live i386 Xfce live x86_64 Cinnamon live x86_64 Games live x86_64 Design_suite live x86_64 Robotics live i386 Workstation live x86_64 Robotics live x86_64 Lxde live i386 Soas disk raw armhfp Security live x86_64 Workstation live i386 Cinnamon live i386 Soas live x86_64 Xfce live i386 Security live i386 Lxde live x86_64 Soas live i386 Games live i386 Design_suite live i386 Mate live x86_64 Images in Rawhide 20160211 but not this: Cloud_atomic disk qcow x86_64 Cloud_atomic disk raw x86_64 Cloud_atomic vagrant libvirt x86_64 Cloud_atomic vagrant virtualbox x86_64 Failed openQA tests: 16 of 63 ID: 5256Test: i386 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/5256 ID: 5252Test: x86_64 workstation_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/5252 ID: 5251Test: x86_64 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/5251 ID: 5250Test: i386 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/5250 ID: 5235Test: i386 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/5235 ID: 5236Test: i386 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/5236 ID: 5237Test: i386 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/5237 ID: 5234Test: i386 universal package_set_minimal URL: https://openqa.fedoraproject.org/tests/5234 ID: 5238Test: i386 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/5238 ID: 5239Test: i386 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/5239 ID: 5240Test: i386 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/5240 ID: 5241Test: i386 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/5241 ID: 5194Test: x86_64 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/5194 ID: 5244Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/5244 ID: 5242Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/5242 ID: 5243Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/5243 Passed openQA tests: 44 of 63 3 openQA tests may be still running or broken! -- 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: dnf remove qemu-img uninstall kernel
On Fri, Feb 12, 2016 at 8:36 PM, Mattia Verga wrote: > Il 12/02/2016 19:22, Sérgio Basto ha scritto: >> On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: >> >> clean_requirements_on_remove=true >> >> in /etc/dnf/dnf.conf >> > Thanks, setting it to "false" avoid kernel uninstalling. Setting it to false does not work properly in all cases (any more?), so I wouldn't trust that alone. https://bugzilla.redhat.com/show_bug.cgi?id=1292915 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 8:48 AM, Richard Shaw wrote: > On Fri, Feb 12, 2016 at 7:47 AM, Josh Boyer > wrote: >> >> On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips >> wrote: >> > Dear all, >> > >> > I would like to formally send a mail requesting some feedback from cicku >> > regarding the maintenance of the backintime package. >> >> Did you actually email cicku directly? I don't see him on CC. > > > He may be on another Fedora hiatus again. I have a stalled review from last > October and have attempted to ping him both in the BZ and direct email with > no response. That is helpful to know. Thank you for chiming in. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 1:48 PM, Johannes Lips wrote: >> On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips >> > >> Did you actually email cicku directly? I don't see him on CC. >> > Well, apparently I didn't add him to this e-mail, but he should have received > enough notifications from bugzilla already. Additionally from someone who > maintains more than 200 packages in fedora, I kind of expect that he is > reachable within a reasonable time-frame. Otherwise it might be too much > hassle, if something needs to be fixed. You make a lot of assumptions in that statement. People filter email quite a bit and relying on bugzilla mail alone is not sufficient. I find it ironic that your original email said "I would like to formally send a mail requesting some feedback from cicku.." but you didn't bother to email him directly. That doesn't strike me as very formal. I'm under no illusions that he is likely to respond to direct contact either, but it should at least be attempted. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
On 02/12/2016 07:18 PM, Mattia Verga wrote: I've installed qemu to play with arm virtualization, now I want to uninstall it, but it seems that trying to uninstall anything qemu related also removes all installed kernels Is this a DNF bug? Yes, kernels must never be removed unless explictly requested. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fwd: Use suid_dumpable=2 for development releases
On Fri, Feb 12, 2016 at 10:32 AM, Richard W.M. Jones wrote: > On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote: >> The default value 0 is there for good security reason, but I would >> like to propose changing the default value to 2 for development >> Fedora releases (Alpha, Beta, Rawhide). In this case, kernel would >> send core dump to ABRT (or systemd-coredump) and the ABRT record >> would be accessible only to root. > > It seems like this would be unsafe if core_pattern is not a pipe or > fully qualified path. > > Ref: https://lwn.net/Articles/503682/ > > That's fine when ABRT is running, but would be unsafe if someone > disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but > forgot about suid_dumpable. > > The kernel does emit KERN_WARNING about this situation (upstream > commit 54b501992dd2), but it's not clear if a sysadmin would notice. > > (I'm actually quite happy for the default to be changed as you > suggest, but can see it's a bit of a minefield.) We could change the kernel to add suid_dumpable == 3 which is like suid_dumpable==2 but only if the core_pattern is a pipe. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
On Sex, 2016-02-12 at 19:36 +0100, Mattia Verga wrote: > Il 12/02/2016 19:22, Sérgio Basto ha scritto: > > On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: > > > I've installed qemu to play with arm virtualization, now I want > > > to > > > uninstall it, but it seems that trying to uninstall anything qemu > > > related also removes all installed kernels Is this a DNF bug? > > no this is : > > > > clean_requirements_on_remove=true > > > > in /etc/dnf/dnf.conf > > > Thanks, setting it to "false" avoid kernel uninstalling. > > But if it's not a bug, I can hardly see the reason to have a > "feature" > that removes the kernel... dnf should not autoremove mandatory > system > components. But that's my opinion, there's probably an important > reason > for which I'm wrong. You may mark kernel and other packages that you want keep installed and by default dnf have autoremove , I don't remember now the exact commands ... > > Mattia > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
> On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips wrote: > > Did you actually email cicku directly? I don't see him on CC. > Well, apparently I didn't add him to this e-mail, but he should have received enough notifications from bugzilla already. Additionally from someone who maintains more than 200 packages in fedora, I kind of expect that he is reachable within a reasonable time-frame. Otherwise it might be too much hassle, if something needs to be fixed. Johannes > josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
On Sex, 2016-02-12 at 19:36 +0100, Mattia Verga wrote: > Il 12/02/2016 19:22, Sérgio Basto ha scritto: > > On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: > > > I've installed qemu to play with arm virtualization, now I want > > > to > > > uninstall it, but it seems that trying to uninstall anything qemu > > > related also removes all installed kernels Is this a DNF bug? > > no this is : > > > > clean_requirements_on_remove=true > > > > in /etc/dnf/dnf.conf > > > Thanks, setting it to "false" avoid kernel uninstalling. > > But if it's not a bug, I can hardly see the reason to have a > "feature" > that removes the kernel... dnf should not autoremove mandatory > system > components. But that's my opinion, there's probably an important > reason > for which I'm wrong. You may mark kernel and others stuff that you don't want install and by default dnf have autoremove , I don't remember now the exact commands ... > > Mattia > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
Il 12/02/2016 19:22, Sérgio Basto ha scritto: On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: I've installed qemu to play with arm virtualization, now I want to uninstall it, but it seems that trying to uninstall anything qemu related also removes all installed kernels Is this a DNF bug? no this is : clean_requirements_on_remove=true in /etc/dnf/dnf.conf Thanks, setting it to "false" avoid kernel uninstalling. But if it's not a bug, I can hardly see the reason to have a "feature" that removes the kernel... dnf should not autoremove mandatory system components. But that's my opinion, there's probably an important reason for which I'm wrong. Mattia -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fwd: Use suid_dumpable=2 for development releases
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote: > The default value 0 is there for good security reason, but I would > like to propose changing the default value to 2 for development > Fedora releases (Alpha, Beta, Rawhide). In this case, kernel would > send core dump to ABRT (or systemd-coredump) and the ABRT record > would be accessible only to root. It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path. Ref: https://lwn.net/Articles/503682/ That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable. The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice. (I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned packages looking for new point of contact
Per today's FESCo meeting, we have orphaned tuxbrewr's packages. Please take a look and see if any of the following are packages you would like to become point of contact on and steward for the Fedora collection: rpms/acpi -- Command-line ACPI client ( master f23 f22 ) rpms/acpitool -- Command line ACPI client ( master f23 f22 ) rpms/conman -- ConMan - The Console Manager ( master f23 f22 ) rpms/cppunit -- C++ unit testing framework ( master f23 f22 ) rpms/digikam -- A digital camera accessing & photo management application ( master f23 f22 ) rpms/esmtp -- User configurable send-only Mail Transfer Agent ( master f23 f22 ) rpms/gmm -- A generic C++ template library for sparse, dense and skyline matrices ( master f23 f22 ) rpms/kmess -- Messaging client for MSN ( master f23 f22 ) rpms/liferea -- An RSS/RDF feed reader ( master f23 f22 ) rpms/netmonitor -- The free linux network bandwidth monitor ( master f23 f22 ) rpms/powerman -- PowerMan - Power to the Cluster ( master f23 f22 el6 el5 ) rpms/python-mwclient -- Mwclient is a client to the MediaWiki API ( master f23 f22 epel7 el6 el5 ) rpms/sugar-analyze -- Analysing tool for Sugar ( master f23 f22 ) rpms/sugar-calculator -- Calculator for Sugar ( master f23 f22 ) rpms/sugar-chat -- Chat client for Sugar ( master f23 f22 ) rpms/sugar-clock -- Clock activity for Sugar ( master f23 f22 ) rpms/sugar-connect -- Connect for Sugar ( master f23 f22 ) rpms/sugar-distance -- Distance measurement for Sugar ( master f23 f22 ) rpms/sugar-finance -- Financial planning for Sugar ( master f23 f22 ) rpms/sugar-flipsticks -- A keyframe animation activity for Sugar ( master f23 f22 ) rpms/sugar-getiabooks -- Internet Archive Books receiver for Sugar ( master f23 f22 ) rpms/sugar-help -- Help and Dokumentation for Sugar ( master f23 f22 ) rpms/sugar-imageviewer -- Simple Image viewer for Sugar ( master f23 f22 ) rpms/sugar-implode -- Implode for Sugar ( master f23 f22 ) rpms/sugar-infoslicer -- Downloader for articles from Wikipedia ( master f23 f22 ) rpms/sugar-maze -- Maze for Sugar ( master f23 f22 ) rpms/sugar-memorize -- Memorize for Sugar ( master f23 f22 ) rpms/sugar-pippy -- Pippy for Sugar ( master f23 f22 ) rpms/sugar-playgo -- Go for Sugar ( master f23 f22 ) rpms/sugar-record -- Recording tool for Sugar ( master f23 f22 ) rpms/sugar-speak -- Speak for Sugar ( master f23 f22 ) rpms/sugar-stopwatch -- Simple stopwatch for Sugar ( master f23 f22 ) rpms/sugar-terminal -- Terminal for Sugar ( master f23 f22 ) rpms/sugar-view-slides -- Image serie viewer for Sugar ( master f23 f22 ) rpms/sugar-write -- Word processor for Sugar ( master f23 f22 ) rpms/sugar-xoirc -- IRC client for Sugar ( master f23 f22 ) rpms/tripwire -- IDS (Intrusion Detection System) ( master f23 f22 el6 el5 ) Thanks, kevin pgpCwwN7ZknWB.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf remove qemu-img uninstall kernel
On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: > I've installed qemu to play with arm virtualization, now I want to > uninstall it, but it seems that trying to uninstall anything qemu > related also removes all installed kernels Is this a DNF bug? no this is : clean_requirements_on_remove=true in /etc/dnf/dnf.conf > # dnf remove qemu-img > Dipendenze risolte. > = > > PackageArch Versione Repository > Dim. > = > > Rimozione in corso: > SDL2 x86_64 2.0.3-7.fc23 @fedora 1.0 M > brlapi x86_64 0.6.3-10.fc23 @fedora 459 k > brltty x86_64 5.2-10.fc23 @fedora 5.1 M > corosync x86_64 2.3.5-1.fc23 @fedora 471 k > corosynclibx86_64 2.3.5-1.fc23 @fedora 281 k > glusterfs x86_64 3.7.6-2.fc23 @updates 1.6 M > glusterfs-api x86_64 3.7.6-2.fc23 @updates 141 k > glusterfs-client-xlators x86_64 3.7.6-2.fc23 @updates 3.3 M > glusterfs-fuse x86_64 3.7.6-2.fc23 @updates 317 k > glusterfs-libs x86_64 3.7.6-2.fc23 @updates 1.0 M > gperftools-libsx86_64 2.4-5.fc23 @fedora 1.3 M > hexeditx86_64 1.2.13-7.fc23 @fedora 69 k > hivex x86_64 1.3.11-11.fc23 @fedora 221 k > ipxe-roms-qemu noarch 20150407-3.gitdc795b9f.fc23 > @fedora 1.3 M > kernel x86_64 4.3.3-303.fc23 @updates 0 > kernel x86_64 4.3.4-300.fc23 @updates 0 > kernel x86_64 4.3.5-300.fc23 @updates 0 > libfdt x86_64 1.4.1-4.fc23 @fedora 41 k > libguestfs x86_64 1:1.32.2-1.fc23 @updates 3.8 > M > libguestfs-tools noarch 1:1.32.2-1.fc23 @updates 30 > k > libguestfs-tools-c x86_64 1:1.32.2-1.fc23 @updates 15 > M > libibverbs x86_64 1.1.8-4.fc23 @fedora 123 k > libiscsi x86_64 1.15.0-1.fc23 @fedora 186 k > libldm x86_64 0.2.3-8.fc23 @fedora 123 k > libosinfo x86_64 0.2.12-2.fc23 @fedora 1.4 M > libqb x86_64 0.17.2-1.fc23 @updates 181 k > librados2 x86_64 1:0.94.5-2.fc23 @updates 4.9 > M > librbd1x86_64 1:0.94.5-2.fc23 @updates 5.3 > M > librdmacm x86_64 1.0.18.1-4.fc23 @fedora 136 > k > libvirt-daemon-driver-interface > x86_64 1.2.18.2-2.fc23 @updates 108 > k > libvirt-daemon-driver-nodedev x86_64 1.2.18.2-2.fc23 @updates 103 > k > libvirt-daemon-driver-nwfilter x86_64 1.2.18.2-2.fc23 @updates 165 > k > libvirt-daemon-driver-qemu x86_64 1.2.18.2-2.fc23 @updates 1.3 > M > libvirt-daemon-driver-secret x86_64 1.2.18.2-2.fc23 @updates 83 > k > libvirt-daemon-driver-storage x86_64 1.2.18.2-2.fc23 @updates 561 > k > libvirt-daemon-kvm x86_64 1.2.18.2-2.fc23 @updates 0 > lsscsi x86_64 0.28-2.fc23 @fedora 101 k > lzop x86_64 1.03-13.fc23 @updates 103 k > mesa-libGLES x86_64 11.1.0-2.20151218.fc23 > @updates > 55 k > netcf-libs x86_64 0.2.8-3.fc23 @updates 199 k > nfs-utils x86_64 1:1.3.3-6.rc3.fc23 @updates > 867 k > perl-Sys-Guestfs x86_64 1:1.32.2-1.fc23 @updates 1.2 > M > perl-Sys-Virt x86_64 1.2.16-3.fc23 @fedora 781 k > perl-hivex x86_64 1.3.11-11.fc23 @fedora 91 k > perl-libintl x86_64 1.20-18.fc23 @fedora 4.2 M > qemu-commonx86_64 2:2.4.1-6.fc23 @updates 878 k > qemu-img x86_64 2:2.4.1-6.fc23 @updates 3.0 M > qemu-kvm x86_64 2:2.4.1-6.fc23 @updates 0 > qemu-system-x86x86_64 2:2.4.1-6.fc23 @updates 14 M > scrub x86_64 2.5.2-7.fc23 @fedora 115 k > seabios-binnoarch 1.8.2-1.fc23 @fedora 1.5 M > seavgabios-bin noarch 1.8.2-1.fc23 @fedora 228 k > sgabios-binnoarch 1:0.20110622svn-8.fc23 > @fedora > 4.0 k > sheepdog x86_64 0.3.0-10.fc23 @fedora 232 k > spice-server x86_64 0.12.6-1.fc23 @fedora 1.2 M > supermin x86_64 5.1.13-3.fc23 @fedora 1.7 M > vte-profilex86_64 0.42.3-1.fc23 @updates 2.0 k > vte3 x86_64 0.36.5-1.fc23 @fedora 987 k > zerofree x86_64 1.0.3-4.fc23 @fedora 47 k > > Riepilogo della transazione > ==
dnf remove qemu-img uninstall kernel
I've installed qemu to play with arm virtualization, now I want to uninstall it, but it seems that trying to uninstall anything qemu related also removes all installed kernels Is this a DNF bug? # dnf remove qemu-img Dipendenze risolte. = PackageArch Versione Repository Dim. = Rimozione in corso: SDL2 x86_64 2.0.3-7.fc23 @fedora 1.0 M brlapi x86_64 0.6.3-10.fc23 @fedora 459 k brltty x86_64 5.2-10.fc23 @fedora 5.1 M corosync x86_64 2.3.5-1.fc23 @fedora 471 k corosynclibx86_64 2.3.5-1.fc23 @fedora 281 k glusterfs x86_64 3.7.6-2.fc23 @updates 1.6 M glusterfs-api x86_64 3.7.6-2.fc23 @updates 141 k glusterfs-client-xlators x86_64 3.7.6-2.fc23 @updates 3.3 M glusterfs-fuse x86_64 3.7.6-2.fc23 @updates 317 k glusterfs-libs x86_64 3.7.6-2.fc23 @updates 1.0 M gperftools-libsx86_64 2.4-5.fc23 @fedora 1.3 M hexeditx86_64 1.2.13-7.fc23 @fedora 69 k hivex x86_64 1.3.11-11.fc23 @fedora 221 k ipxe-roms-qemu noarch 20150407-3.gitdc795b9f.fc23 @fedora 1.3 M kernel x86_64 4.3.3-303.fc23 @updates 0 kernel x86_64 4.3.4-300.fc23 @updates 0 kernel x86_64 4.3.5-300.fc23 @updates 0 libfdt x86_64 1.4.1-4.fc23 @fedora 41 k libguestfs x86_64 1:1.32.2-1.fc23 @updates 3.8 M libguestfs-tools noarch 1:1.32.2-1.fc23 @updates 30 k libguestfs-tools-c x86_64 1:1.32.2-1.fc23 @updates 15 M libibverbs x86_64 1.1.8-4.fc23 @fedora 123 k libiscsi x86_64 1.15.0-1.fc23 @fedora 186 k libldm x86_64 0.2.3-8.fc23 @fedora 123 k libosinfo x86_64 0.2.12-2.fc23 @fedora 1.4 M libqb x86_64 0.17.2-1.fc23 @updates 181 k librados2 x86_64 1:0.94.5-2.fc23 @updates 4.9 M librbd1x86_64 1:0.94.5-2.fc23 @updates 5.3 M librdmacm x86_64 1.0.18.1-4.fc23 @fedora 136 k libvirt-daemon-driver-interface x86_64 1.2.18.2-2.fc23 @updates 108 k libvirt-daemon-driver-nodedev x86_64 1.2.18.2-2.fc23 @updates 103 k libvirt-daemon-driver-nwfilter x86_64 1.2.18.2-2.fc23 @updates 165 k libvirt-daemon-driver-qemu x86_64 1.2.18.2-2.fc23 @updates 1.3 M libvirt-daemon-driver-secret x86_64 1.2.18.2-2.fc23 @updates 83 k libvirt-daemon-driver-storage x86_64 1.2.18.2-2.fc23 @updates 561 k libvirt-daemon-kvm x86_64 1.2.18.2-2.fc23 @updates 0 lsscsi x86_64 0.28-2.fc23 @fedora 101 k lzop x86_64 1.03-13.fc23 @updates 103 k mesa-libGLES x86_64 11.1.0-2.20151218.fc23 @updates 55 k netcf-libs x86_64 0.2.8-3.fc23 @updates 199 k nfs-utils x86_64 1:1.3.3-6.rc3.fc23 @updates 867 k perl-Sys-Guestfs x86_64 1:1.32.2-1.fc23 @updates 1.2 M perl-Sys-Virt x86_64 1.2.16-3.fc23 @fedora 781 k perl-hivex x86_64 1.3.11-11.fc23 @fedora 91 k perl-libintl x86_64 1.20-18.fc23 @fedora 4.2 M qemu-commonx86_64 2:2.4.1-6.fc23 @updates 878 k qemu-img x86_64 2:2.4.1-6.fc23 @updates 3.0 M qemu-kvm x86_64 2:2.4.1-6.fc23 @updates 0 qemu-system-x86x86_64 2:2.4.1-6.fc23 @updates 14 M scrub x86_64 2.5.2-7.fc23 @fedora 115 k seabios-binnoarch 1.8.2-1.fc23 @fedora 1.5 M seavgabios-bin noarch 1.8.2-1.fc23 @fedora 228 k sgabios-binnoarch 1:0.20110622svn-8.fc23 @fedora 4.0 k sheepdog x86_64 0.3.0-10.fc23 @fedora 232 k spice-server x86_64 0.12.6-1.fc23 @fedora 1.2 M supermin x86_64 5.1.13-3.fc23 @fedora 1.7 M vte-profilex86_64 0.42.3-1.fc23 @updates 2.0 k vte3 x86_64 0.36.5-1.fc23 @fedora 987 k zerofree x86_64 1.0.3-4.fc23 @fedora 47 k Riepilogo della transazione = Remove 59 Packages -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2016-02-12)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === #fedora-meeting: FESCO (2016-02-12) === Meeting started by sgallagh at 17:00:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2016-02-12/fesco.2016-02-12-17.0 0.log.html . Meeting summary - --- * init process (sgallagh, 17:00:20) * #1478 F24 Self Contained Changes (sgallagh, 17:06:32) * AGREED: Graphical System Upgrades, Shenandoah and Atomic Developer Mode are approved. (+6, 0, -0) (sgallagh, 17:12:13) * #1540 F24 System Wide Change: Langpacks Installation With RPM Weak Dependencies (sgallagh, 17:12:24) * AGREED: "Langpacks Installation With RPM Weak Dependencies" is approved (+6, 0, -0) (sgallagh, 17:13:37) * #1541 F24 System Wide Change: LiveUserCreator as Primary Downloadable (sgallagh, 17:13:47) * LINK: https://copr.fedorainfracloud.org/coprs/mbriza/liveusb-creator/ (number80, 17:30:24) * ACTION: number80 to contact the LUC Change Owners and get clarification on points discussed here (sgallagh, 17:33:03) * AGREED: Defer one week to gather information (+5, 0, -0) (sgallagh, 17:33:45) * #1543 F24 System Wide Change: Mono 4.2 (sgallagh, 17:33:59) * AGREED: Mono 4.2 is approved (+6, 0, -0) (sgallagh, 17:35:28) * #1545 F24 System Wide Change: The GNU C Library version 2.23 (sgallagh, 17:35:32) * AGREED: glibc 2.23 is approved (+5, 0, -0) (sgallagh, 17:37:50) * #1546 F24 System Wide Change: Removal of librtkaio from glibc (sgallagh, 17:37:55) * AGREED: Remove librtkaio from Fedora's glibc (+6, 0, -0) (sgallagh, 17:41:03) * #1547 F24 System Wide Change: GNOME 3.20 (sgallagh, 17:41:10) * AGREED: GNOME 3.20 is approved (+6, 0, -0) (sgallagh, 17:43:26) * #1535 quassel maintainer (tuxbrewr) not responding (sgallagh, 17:43:42) * AGREED: Orphan all of tuxbrewr's packages (+6, 0, -0) (sgallagh, 17:46:25) * #1539 Are 32-bit upgrades to Fedora 24 release blocking? Supported? (sgallagh, 17:46:44) * AGREED: Upgrade issues unique to ix86 do not block the release (+6, 0, -0) (sgallagh, 17:55:16) * Next week's chair (sgallagh, 17:55:24) * ACTION: jwb to chair next week's FESCo meeting (sgallagh, 17:56:26) * Open Floor (sgallagh, 17:57:57) * LINK: https://fedorahosted.org/packager-sponsors/ticket/232 (nirik, 18:00:37) * LINK: https://fedorahosted.org/packager-sponsors/ticket/251 (nirik, 18:00:45) * LINK: https://fedorahosted.org/packager-sponsors/ticket/254 (nirik, 18:00:48) * LINK: https://fedoraproject.org/w/index.php?title=How_to_sponsor_a_new_contributor&dif f=434010&oldid=430417 (nirik, 18:05:57) * AGREED: Sponsorship requests will be closed after one week. If the total differential between positive and negative votes is not at least +3, the sponsor will not be approved and may reapply later. (+6, 0, -0) (sgallagh, 18:07:05) Meeting ended at 18:15:08 UTC. Action Items - * number80 to contact the LUC Change Owners and get clarification on points discussed here * jwb to chair next week's FESCo meeting Action Items, by person - --- * jwb * jwb to chair next week's FESCo meeting * number80 * number80 to contact the LUC Change Owners and get clarification on points discussed here * **UNASSIGNED** * (none) People Present (lines said) - --- * sgallagh (139) * nirik (63) * number80 (60) * jwb (34) * maxamillion (23) * zodbot (20) * paragan (16) * kalev (0) * jsmith (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAla+IVUACgkQeiVVYja6o6OHXwCfWV/sjBMNBVTR6R/KFRAWpkY8 qWkAnAl3Kk8XdqS9Ri/qNZFQE8YqRDJj =fz3e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: fedora git server, git and ssh down ??
On Sex, 2016-02-12 at 17:01 +0100, Xose Vazquez Perez wrote: > Hi, > > Only works http, git and ssh protocols don't. > > -thanks- > > $ git clone git://pkgs.fedoraproject.org/rpms/iptables.git > Cloning into 'iptables'... > fatal: remote error: access denied or repository not exported: > /rpms/iptables.git > --- > $ git clone ssh://pkgs.fedoraproject.org/rpms/iptables.git > Cloning into 'iptables'... > Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. you need say that you are anonymous: https://bugzilla.redhat.com/show_bug.cgi?id=670485 fedpkg clone iptables -a > --- > $ git clone http://pkgs.fedoraproject.org/git/rpms/iptables.git > Cloning into 'iptables'... > remote: Counting objects: 859, done. > remote: Compressing objects: 100% (562/562), done. > remote: Total 859 (delta 431), reused 599 (delta 274) > Receiving objects: 100% (859/859), 171.43 KiB | 332.00 KiB/s, done. > Resolving deltas: 100% (431/431), done. > Checking connectivity... done. > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: fedora git server, git and ssh down ??
sounds simple and stupid to ask but: 1) Do you have a ssh key in fas ? 2) Is said key in the acl for that instance? 3) have you tried other repos on that instance to rule out a repo centric failure vice the whole system ? 4) if you have a fedorapeople.org/people-repos/ do those clone properly? Corey W Sheldon ph: +1 (310).909.7672 skype:cwwsheldon Freelance IT Consultant, Multi-Discipline Tutor Fedora Ambassador,FamNA (corey84) City-Gate Server Team Intern Ameridea LLC Founder, President cshel...@ameridea.ne t core...@fedoraproject.org linuxmod...@keybase.io Find me elsewhere: https://gist.github.com/linux-modder/ac5dc6fa211315c633c9 Contact me securely: PGP: 0xCe2ad4c03a9eff1c FP= ba7e aeba 7c64 1eca f4b9 70a8 ce2a d4c0 3a9e ff1c PGP: 0x76ef54b9aed032e2 FP= 984e 1693 de66 2109 596c 0930 76ef 54b9 aed0 32e2 Tox: core...@toxme.io 9357bc6a5944a08afc7d1effd61f6a73b9eabf8b2fb84acf1dac9a1a4d0a4705ffccd0e5499b Linphone: inuxmodder ricochet:qxcgel5jqoqcb3q2 btc:15cn1BvAFEREHk8UekJ6i9Dxi9Wbw6vzDD "Have no way as way, no limitation as limitation. One must never underestimate the power of boredom...from which creativity and laziness are borne, which can spark great works of chaos and genius." This document, including attachments, is intended for the person or company named and contains confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please destroy this message and notify the sender. On Fri, Feb 12, 2016 at 11:01 AM, Xose Vazquez Perez wrote: > Hi, > > Only works http, git and ssh protocols don't. > > -thanks- > > $ git clone git://pkgs.fedoraproject.org/rpms/iptables.git > Cloning into 'iptables'... > fatal: remote error: access denied or repository not exported: > /rpms/iptables.git > --- > $ git clone ssh://pkgs.fedoraproject.org/rpms/iptables.git > Cloning into 'iptables'... > Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > --- > $ git clone http://pkgs.fedoraproject.org/git/rpms/iptables.git > Cloning into 'iptables'... > remote: Counting objects: 859, done. > remote: Compressing objects: 100% (562/562), done. > remote: Total 859 (delta 431), reused 599 (delta 274) > Receiving objects: 100% (859/859), 171.43 KiB | 332.00 KiB/s, done. > Resolving deltas: 100% (431/431), done. > Checking connectivity... done. > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
fedora git server, git and ssh down ??
Hi, Only works http, git and ssh protocols don't. -thanks- $ git clone git://pkgs.fedoraproject.org/rpms/iptables.git Cloning into 'iptables'... fatal: remote error: access denied or repository not exported: /rpms/iptables.git --- $ git clone ssh://pkgs.fedoraproject.org/rpms/iptables.git Cloning into 'iptables'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. --- $ git clone http://pkgs.fedoraproject.org/git/rpms/iptables.git Cloning into 'iptables'... remote: Counting objects: 859, done. remote: Compressing objects: 100% (562/562), done. remote: Total 859 (delta 431), reused 599 (delta 274) Receiving objects: 100% (859/859), 171.43 KiB | 332.00 KiB/s, done. Resolving deltas: 100% (431/431), done. Checking connectivity... done. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ntpstat
On 2/12/2016 3:36 AM, Peter Lemenkov wrote: 2016-02-12 12:10 GMT+01:00 Miroslav Lichvar : I could write a new man page and put it in the ntp package as a replacement. Or it could be added as a new package in Fedora, which ntp could recommend or suggest. Would that make sense? Another option is to simply drop ntpstat from ntp with no replacement. Thoughts? I'd simply remove it. Otherwise you have to act as upstream for this outdated thing. Whatever "outdated" means in this context, if it's functional (or can be made functional) and provides actual utility then why /not/ keep it? I'd suggest it getting its own package, though, lest it get sucked into whatever systemd is doing with ntp. -jc -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
show changelogs script
I made small bash script to show the changelogs of potential updates.
There used to be yum plugin that did this but I didn't really see
anything.
warning, the script is a quick hack, it just reaches into the dnf cache
after a download only run, must run as root cause i'm lazy, and the
changelog diffs will probably be off for packages like the kernel with
multiple installs. ymmv.
begin 644 dnfchlog
M(R$O8FEN+V)A2P@;75S="!R=6X@=&AI
M2`M+61O=VYL;V%D
M;VYL>2!U<&1A=&4*"E)035,])"AF:6YD("1#04-(141)4B`M;F%M92`G*BYR
M<&TG*0I53DE14E!-4STH*0I$55`],`H*:68@6R`M>B`B)%)035,B(%T[('1H
M96X*"65X:70*9FD*"F9OU5.25%2
M4$U36T!=?3L@9&\*"0E54E!-4U)#/20HTY!345])R`M
M<7`@)%)032`R/B]D978O;G5L;"D*"65C:&\@(CT]/2`D3$]#04Q24$TB"@ED
M:69F("UU("`\*')P;2`M+6-H86YG96QO9R`M<2`D3$]#04Q24$TI(#PH/3T]
%("XJ)PH`
`
end
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2016-02-12)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-02-12 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1539 Are 32-bit upgrades to Fedora 24 release blocking? Supported? .fesco 1539 https://fedorahosted.org/fesco/ticket/1539 #topic #1535 quassel maintainer (tuxbrewr) not responding .fesco 1539 https://fedorahosted.org/fesco/ticket/1535 = New business = #topic #1478 F24 Self Contained Changes .fesco 1478 https://fedorahosted.org/fesco/ticket/1478 #topic #1540 F24 System Wide Change: Langpacks Installation With RPM Weak Dependencies .fesco 1540 https://fedorahosted.org/fesco/ticket/1540 #topic #1541 F24 System Wide Change: LiveUserCreator as Primary Downloadable .fesco 1541 https://fedorahosted.org/fesco/ticket/1541 #topic #1543 F24 System Wide Change: Mono 4.2 .fesco 1543 https://fedorahosted.org/fesco/ticket/1543 #topic #1545 F24 System Wide Change: The GNU C Library version 2.23 .fesco 1545 https://fedorahosted.org/fesco/ticket/1545 #topic #1546 F24 System Wide Change: Removal of librtkaio from glibc .fesco 1546 https://fedorahosted.org/fesco/ticket/1546 #topic #1547 F24 System Wide Change: GNOME 3.20 .fesco 1547 https://fedorahosted.org/fesco/ticket/1547 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAla97YMACgkQeiVVYja6o6Oj5QCeJyGgqPPw8YtpH/a3utBsFwI1 hlYAoIBcelY4SouwlB3xCUbiJx6feppM =bSXu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20160212 changes
Compose started at Fri Feb 12 05:15:02 UTC 2016 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 [asterisk] asterisk-alembic-13.7.2-2.fc24.i686 requires alembic [bluetile] bluetile-0.6-30.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) bluetile-0.6-30.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) [bustle] bustle-0.4.8-6.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) bustle-0.4.8-6.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) [compat-gcc-34] compat-gcc-34-c++-3.4.6-38.fc24.i686 requires libstdc++ < 0:6.0.0 [cone] cone-0.91.1-3.fc23.i686 requires libunicode.so.1 [devtodo2] devtodo2-2.1-15.20120711git8dee6.fc24.i686 requires libgo.so.8 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [ejabberd] ejabberd-14.07-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 ejabberd-14.07-6.fc22.i686 requires erlang(erl_drv_version) = 0:3.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-15.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-bitcask] erlang-bitcask-1.6.3-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-eleveldb] erlang-eleveldb-1.3.2-7.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 [gcc-python-plugin] gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 [ghc-glade] ghc-glade-0.12.5.0-7.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) ghc-glade-devel-0.12.5.0-7.fc24.i686 requires ghc-devel(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) [ghc-gtk] ghc-gtk-0.13.9-2.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) ghc-gtk-devel-0.13.9-2.fc24.i686 requires ghc-devel(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) [ghc-gtk3] ghc-gtk3-0.14.1-2.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) ghc-gtk3-devel-0.14.1-2.fc24.i686 requires ghc-devel(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) [ghc-gtksourceview2] ghc-gtksourceview2-0.13.1.3-2.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) ghc-gtksourceview2-devel-0.13.1.3-2.fc24.i686 requires ghc-devel(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) [ghc-hakyll] ghc-hakyll-4.5.4.0-6.fc24.i686 requires libHShaddock-library-1.1.1-ghc7.8.4.so [ghc-ltk] ghc-ltk-0.14.3.0-4.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) ghc-ltk-devel-0.14.3.0-4.fc24.i686 requires ghc-devel(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) [ghc-webkit] ghc-webkit-0.13.1.3-2.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) ghc-webkit-devel-0.13.1.3-2.fc24.i686 requires ghc-devel(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) [ghdl] ghdl-0.33dev-1.20151120gitff4bc5f.0.fc24.i686 requires libgnat-5.so ghdl-llvm-0.33dev-1.20151120gitff4bc5f.0.fc24.i686 requires libgnat-5.so ghdl-mcode-0.33dev-1.20151120gitff4bc5f.0.fc24.i686 requires libgnat-5.so ghdl-mcode-0.33dev-1.20151120gitff4bc5f.0.fc24.i686 requires libgnarl-5.so [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
Re: ntpstat
On 02/12/2016 06:10 AM, Miroslav Lichvar wrote: ntpstat is a small utility included in the ntp package, which prints the synchronization status of ntpd, the maximum error of the clock and few other fields. Apparently, there are people who find it useful for monitoring. It has been included in the ntp package for a very long time, but it's not actually part of the upstream ntp package (and can't be as it's licensed under GPL). I guess ntpstat should rather have its own package. Since you are thinking of rewriting, it would make sense to offer it to upstream. Do you think they'd take it? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 7:47 AM, Josh Boyer wrote: > On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips > wrote: > > Dear all, > > > > I would like to formally send a mail requesting some feedback from cicku > regarding the maintenance of the backintime package. > > Did you actually email cicku directly? I don't see him on CC. He may be on another Fedora hiatus again. I have a stalled review from last October and have attempted to ping him both in the BZ and direct email with no response. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Non-responsive package maintainer process - backintime
On Fri, Feb 12, 2016 at 5:04 AM, Johannes Lips wrote: > Dear all, > > I would like to formally send a mail requesting some feedback from cicku > regarding the maintenance of the backintime package. Did you actually email cicku directly? I don't see him on CC. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ntpstat
On Fri, Feb 12, 2016 at 12:36:16PM +0100, Peter Lemenkov wrote: > 2016-02-12 12:10 GMT+01:00 Miroslav Lichvar : > > > I could write a new man page and put it in the ntp package as a > > replacement. Or it could be added as a new package in Fedora, which > > ntp could recommend or suggest. Would that make sense? Another option > > is to simply drop ntpstat from ntp with no replacement. > > > > Thoughts? > > I'd simply remove it. Otherwise you have to act as upstream for this > outdated thing. FWIW, I'd have no problem with maintaining a hundred-line shell script. I think it would rarely need an update. Of course, if there were no users for it, then I'd rather drop it. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fwd: Use suid_dumpable=2 for development releases
On Fri, Feb 12, 2016 at 12:40:37PM +, Tom Hughes wrote: > On 12/02/16 12:24, Jakub Filak wrote: > >I believe that maintainers of packages like chrony will be really delighted > >with this change, while will not weaken security of Fedora for regular users. > > What part of chrony is setuid? I don't see an suid bit on any of it's > executables... Nor any file capabilities which is the other thing the manual > page says triggers this. The chrony files don't have any set*id bits set, but the chronyd process, like many other daemons, calls setuid()/setgid() in order to drop root privileges. The proc(5) man page lists that as a reason for not producing a coredump. I was wondering what security implications would setting suid_dumpable to 2 by default had and why it needs to be restricted to development. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fwd: Use suid_dumpable=2 for development releases
On 12/02/16 12:24, Jakub Filak wrote: As a maintainer of ABRT, I have been asked several times why ABRT does not catch crashes of many processes and one kind of reasons dominate among other reasons - processes that executes set-user-ID programs (man 5 core). These processes are not dumped at all if the value of /proc/sys/fs/suid_dumpable is 0 (man 5 proc) which is the default value. With the default suid_dumpable value, crashes caused by SIGABRT are not detectable because kernel doesn't even write a log message about that. The default value 0 is there for good security reason, but I would like to propose changing the default value to 2 for development Fedora releases (Alpha, Beta, Rawhide). In this case, kernel would send core dump to ABRT (or systemd-coredump) and the ABRT record would be accessible only to root. I believe that maintainers of packages like chrony will be really delighted with this change, while will not weaken security of Fedora for regular users. What part of chrony is setuid? I don't see an suid bit on any of it's executables... Nor any file capabilities which is the other thing the manual page says triggers this. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fwd: Use suid_dumpable=2 for development releases
- Forwarded Message - From: "Jakub Filak" To: secur...@lists.fedoraproject.org Sent: Thursday, February 11, 2016 9:51:04 AM Subject: Use suid_dumpable=2 for development releases Hello, As a maintainer of ABRT, I have been asked several times why ABRT does not catch crashes of many processes and one kind of reasons dominate among other reasons - processes that executes set-user-ID programs (man 5 core). These processes are not dumped at all if the value of /proc/sys/fs/suid_dumpable is 0 (man 5 proc) which is the default value. With the default suid_dumpable value, crashes caused by SIGABRT are not detectable because kernel doesn't even write a log message about that. The default value 0 is there for good security reason, but I would like to propose changing the default value to 2 for development Fedora releases (Alpha, Beta, Rawhide). In this case, kernel would send core dump to ABRT (or systemd-coredump) and the ABRT record would be accessible only to root. I believe that maintainers of packages like chrony will be really delighted with this change, while will not weaken security of Fedora for regular users. Regards, Jakub -- security mailing list secur...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/secur...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ntpstat
2016-02-12 12:10 GMT+01:00 Miroslav Lichvar : > I could write a new man page and put it in the ntp package as a > replacement. Or it could be added as a new package in Fedora, which > ntp could recommend or suggest. Would that make sense? Another option > is to simply drop ntpstat from ntp with no replacement. > > Thoughts? I'd simply remove it. Otherwise you have to act as upstream for this outdated thing. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ntpstat
ntpstat is a small utility included in the ntp package, which prints the synchronization status of ntpd, the maximum error of the clock and few other fields. Apparently, there are people who find it useful for monitoring. It has been included in the ntp package for a very long time, but it's not actually part of the upstream ntp package (and can't be as it's licensed under GPL). I guess ntpstat should rather have its own package. There are few issues with it, however. The last ntpstat release is from 2002 and there is no upstream now. We have a couple of patches that make it work with the current ntp code. It implements the mode 6 protocol (used by ntpq for instance), but it's really the minimum needed to send a request and parse the data if it happens to be in the first packet of the response. It can break easily. Also, it doesn't support IPv6, to get an IPv6 address for the system peer it would have to iterate over the NTP associations. Instead of fixing and maitaining the C code, I thought it would be much easier to rewrite it from scratch as a bash script using ntpq. Also, it would be easy to add support for chronyd using the chronyc utility. This is what I have now, its output should be in most cases identical to what the original ntpstat produced. https://raw.githubusercontent.com/mlichvar/ntpstat/master/ntpstat I could write a new man page and put it in the ntp package as a replacement. Or it could be added as a new package in Fedora, which ntp could recommend or suggest. Would that make sense? Another option is to simply drop ntpstat from ntp with no replacement. Thoughts? -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Non-responsive package maintainer process - backintime
Dear all, I would like to formally send a mail requesting some feedback from cicku regarding the maintenance of the backintime package. There is one open bug, which requests an update [1] and additionally a trac ticket [2] was also opened, not by me. I can see, that with an upgrade to later versions we'll loose the differentiation between a KDE and Gnome GUI, but I don't see why that really is an issue. Additionally two request to become co-maintainer are unanswered so far, so I hope that we'll get that sorted pretty quick. Possibly there are some Chinese New Year festivities, so perhaps we'll give him some more time, but I would love to get some feedback. Johannes [1] https://bugzilla.redhat.com/show_bug.cgi?id=1186184 [2] https://fedorahosted.org/fesco/ticket/1542 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora 24 Mass Rebuild
tor 2016-02-11 klockan 20:52 -0600 skrev Yaakov Selkowitz: > On 2016-02-06 00:08, Dennis Gilmore wrote: > > The Mass Rebuild has been completed, 16129 builds have been tagged > > into f24, > > there s currently 1155 failed builds that need to be addressed by > > the package > > maintainers. FTBFS bugs will be filed shortly. > > Is https://bugzilla.redhat.com/show_bug.cgi?id=1305208 the intended > tracker for these? If so, per past mass rebuilds, a F24FTBFS alias > would be helpful. However, there are only a handful of bugs filed so > far. I didn't see it announce anywhere - though I might have missed it - but I found the list of failed builds here: http://alt.fedoraproject.org/pub/alt/mass-rebuild/f24-failures.html Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned LemonPOS
I orphaned package LemonPOS. Upstream developer seems to not be longer working on the project, and the software is not stable and reliable as it should. Best regards -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning The Mana World (tmw and tmw-music)
Hi, As far as I know, manaplus and tmw refer to the same project. The latter is just the upstream name of the source archives. So according to the naming guidelines, tmw is a valid package name but I guess, it would also be fine to rename it to manaplus as it's more descriptive. Concerning the project status, I'm not up to date. Maybe Erik can give some more input about that. I put him on CC. Martin TMW basically is the specific server (scripts, graphics, configuration). Manaplus is a fork of the Mana Client (which is no longer being developed). It is more an independent client. Other servers are using Manaplus as their client too. So the branding package "tmw" only only provides a bit of theming for manaplus / mana. However the branding "upstream" moved into the manaplus package now. So if you look into the data/ dir of the Manaplus tarball you can see all the theming there. So this is why I suggested to make manaplus providing the tmw package. I think this would be the easiest to maintain... Also this way one could maybe add theming for other servers too (for evol for example). The best way to get support is to ask in #themanaworld-dev on freenode. Simply highlight 4144 and me (Ablu) there. As a side note: I find the name "manaworld" a bit weird... I never heard anybody calling the game this way... Regards, Erik -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Bug 1306875] perl-SQL-Interp-1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1306875 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-SQL-Interp-1.24-1.fc24 Resolution|--- |RAWHIDE Last Closed||2016-02-12 03:06:51 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
