Re: Orphaning json_simple
On 09/15/2014 05:16 PM, Peter MacKinnon wrote: > On 09/15/2014 10:48 AM, Steve Traylen wrote: >> Excerpts from Josh Boyer's message of 2014-09-15 16:39:53 +0200: >>> On Sep 15, 2014 10:37 AM, "Steve Traylen" wrote: Hi, I am orphaning json_simple >>> Why? >> It's the only piece of java in my packaging life and the packaging >> became hard where I need to learn all the maven macro stuff to fix >> bugs. Happy to maintain while trivial though can't justify more. Thanks for letting us know. >> >> Steve. >> >>> josh > > I will take this please. I've taken this package in Fedora (not EPEL) and added pmackinn as comaintainer. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken dependencies: vdsm
[Adding vdsm-devel/ovirt-devel] - Original Message - > From: "Kaleb S. KEITHLEY" > To: "Balamurugan Arumugam" , "Dan Kenigsberg" > > Cc: "Lalatendu Mohanty" , build...@fedoraproject.org, > "Development discussions related to > Fedora" , glusterfs-ow...@fedoraproject.org > Sent: Monday, September 15, 2014 9:27:03 PM > Subject: Re: Broken dependencies: vdsm > > Posting to -devel because I can't post to vdsm-owner or virt-maintenance. > > On 09/15/2014 10:09 AM, Kaleb S. KEITHLEY wrote: > > gluster server. AFAIK it's a mistake for vdsm to have these as > > dependencies. > > Correcting myself. glusterfs-cli is okay, and should, AFAIK, be in > RHEL6, although I'm not seeing that it is. > > glusterfs-server is not in RHEL6, and won't ever be in RHEL6, and AFAIK > it's a mistake for vdsm to have it as a dependency. > Looks like to me too. Lets check with vdsm-devel/ovirt-devel? Regards, Bala -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 14 packages were orphaned - autoconf-archive [f20, f21, f19, master, el6, epel7, el5] was orphaned by kevin The Autoconf Macro Archive https://admin.fedoraproject.org/pkgdb/package/autoconf-archive gtk-aurora-engine [master, f21, f19, el6, f20] was orphaned by kevin Aurora GTK+ theme engine https://admin.fedoraproject.org/pkgdb/package/gtk-aurora-engine gtk-chtheme [master, f21, f19, el6, f20] was orphaned by kevin Gtk+ 2.0 theme preview and selection made slick https://admin.fedoraproject.org/pkgdb/package/gtk-chtheme gtk-equinox-engine [master, f21, f19, el6, f20] was orphaned by kevin Equinox theme engine for GTK+ 2.x https://admin.fedoraproject.org/pkgdb/package/gtk-equinox-engine jwm [el6] was orphaned by kevin Joe's Window Manager https://admin.fedoraproject.org/pkgdb/package/jwm mercurial [el5] was orphaned by ausil A fast, lightweight distributed source control management system https://admin.fedoraproject.org/pkgdb/package/mercurial mozilla-googlesharing [f21, f19, f20] was orphaned by matriux Anonymizing proxy service for google sharing system https://admin.fedoraproject.org/pkgdb/package/mozilla-googlesharing pards [f21, f19, master, f20] was orphaned by kevin A library for PARallel programs with Dataflow Synchronization https://admin.fedoraproject.org/pkgdb/package/pards python26 [el5] was orphaned by dmalcolm Parallel-installable Python 2.6 for EPEL5 https://admin.fedoraproject.org/pkgdb/package/python26 python26-distribute [el5] was orphaned by dmalcolm the "Distribute" fork of setuptools for the python26 EPEL package https://admin.fedoraproject.org/pkgdb/package/python26-distribute python26-nose [f21, f19, master, f20, el5] was orphaned by dmalcolm The "nose" testing package for the python26 EPEL package https://admin.fedoraproject.org/pkgdb/package/python26-nose rktime [f21, f19, f20] was orphaned by matriux Multi-zone time display utility https://admin.fedoraproject.org/pkgdb/package/rktime rubygem-rubigen [el6, el5] was orphaned by lkundrak A framework to allow Ruby applications to generate file/folder stubs https://admin.fedoraproject.org/pkgdb/package/rubygem-rubigen wallpaperd [f21, f19, master, f20] was orphaned by kevin Background setter supporting random images and per-workspace images https://admin.fedoraproject.org/pkgdb/package/wallpaperd 6 packages were retired celt [f21, master] was retired by pbrobinson An audio codec for use in low-delay speech and audio communication https://admin.fedoraproject.org/pkgdb/package/celt eclipse-wtp-common [master] was retired by arobinso Eclipse Web Tools Platform common libraries. https://admin.fedoraproject.org/pkgdb/package/eclipse-wtp-common openstack-swift-plugin-swift3 [el6] was retired by apevec The swift3 plugin for Openstack Swift https://admin.fedoraproject.org/pkgdb/package/openstack-swift-plugin-swift3 python-greenlet [epel7] was retired by apevec Lightweight in-process concurrent programming https://admin.fedoraproject.org/pkgdb/package/python-greenlet sssd [el5] was retired by sgallagh System Security Services Daemon https://admin.fedoraproject.org/pkgdb/package/sssd virt-v2v [f21, master] was retired by mdbooth Convert a virtual machine to run on KVM https://admin.fedoraproject.org/pkgdb/package/virt-v2v 15 packages unorphaned -- APLpy [f21, f19, master, f20] was unorphaned by sergiopr The Astronomical Plotting Library in Python https://admin.fedoraproject.org/pkgdb/package/APLpy CQRlib [f20, f21, f19, master, el6, el5] was unorphaned by krege ANSI C API for quaternion arithmetic and rotation https://admin.fedoraproject.org/pkgdb/package/CQRlib CVector [f20, f21, f19, master, el6, el5] was unorphaned by krege ANSI C API for Dynamic Arrays https://admin.fedoraproject.org/pkgdb/package/CVector NearTree [f20, f21, f19, master, el6, el5] was unorphaned by krege An API for finding nearest neighbors https://admin.fedoraproject.org/pkgdb/package/NearTree bzrtools [el6, el5] was unorphaned by stevetraylen A collection of utilities and plugins for Bazaar-NG https://admin.fedoraproject.org/pkgdb/package/bzrtools dar [el5] was unorphaned by lbazan Software for making/restoring incremental CD/DVD backups https://admin.fedoraproject.org/pkgdb/package/dar dnsenum [f21, f19, master, f20] was unorphaned by fab A tool to enumerate DNS info about domains https://admin.fedoraproject.org/pkgdb/package/dnsenum jwm [f21, f19, master, f20] was unorphaned by cicku Joe's Window Manager https://admin.fedoraproject.org/pkgdb/package/jwm linux-igd [f21, f19, master, f20] was unorphaned by mooninite The Linux UP
Re: Broken dependencies: vdsm
Posting to -devel because I can't post to vdsm-owner or virt-maintenance. On 09/15/2014 10:09 AM, Kaleb S. KEITHLEY wrote: gluster server. AFAIK it's a mistake for vdsm to have these as dependencies. Correcting myself. glusterfs-cli is okay, and should, AFAIK, be in RHEL6, although I'm not seeing that it is. glusterfs-server is not in RHEL6, and won't ever be in RHEL6, and AFAIK it's a mistake for vdsm to have it as a dependency. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 21 Cockpit test day tomorrow (Tuesday 2014-09-16)
Hi. There is planned Fedora testday for new feature: *** Cockpit *** It is new web Monitoring&Management interface (system, services, journal, network, storage, containers, users) http://cockpit-project.org/ When: 2014-09-16 Where: https://fedoraproject.org/wiki/Test_Day:2014-09-16_Cockpit #fedora-test-day at freenode It is easy to use. Come and test your favourite part. Bugs&RFEs are very welcomed. Thanks&Regards Honza -- Jan Scotka ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning json_simple
On 09/15/2014 10:48 AM, Steve Traylen wrote: Excerpts from Josh Boyer's message of 2014-09-15 16:39:53 +0200: On Sep 15, 2014 10:37 AM, "Steve Traylen" wrote: Hi, I am orphaning json_simple Why? It's the only piece of java in my packaging life and the packaging became hard where I need to learn all the maven macro stuff to fix bugs. Happy to maintain while trivial though can't justify more. Steve. josh I will take this please. -- Peter MacKinnon CTO Office: Big Data Red Hat Inc. Raleigh, NC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, Sep 15, 2014 at 04:07:39PM +0200, Vít Ondruch wrote:
> Dne 15.9.2014 14:28, Richard W.M. Jones napsal(a):
> > On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
> >> Every of the script is based on assumption that you already read some
> >> library/unit whatever. But that is not enough. I wonder how you want to
> >> detect that you need restart in case that I have something like this:
> >>
> >> $ ls
> >> foo.rb
> >> bar.rb
> >>
> >> $ cat foo.rb
> >>
> >> def some_function
> >> require 'bar'
> >> end
> >>
> >> And now
> >>
> >> 1) I run some application, which loads my foo.rb file.
> >> 2) I later update the package which removes bar.rb file.
> >> 3) And I call some_function which fails due to missing bar.rb
> > How is this not 'foo' simply being broken?
>
> They might come from different packages.
OK, in which case the package that needs bar was broken because it
didn't express that need in its dependencies, nor guard against the
possibility that bar was not installed.
> Or there might be also another
> level of requires, where bar.rb requires by baz.rb. In case that bar.rb
> stays and baz.rb is removed, you still cannot predict that this will
> fail in the future, since neither of these files was loaded before.
In which case bar.rb was similarly broken, for the same reason as
above.
> Or there might be another example of code with similar issues:
>
> $ cat foo.rb
>
> def some_function
> $files.each {|f| require f}
> end
>
> $files = Dir.glob('*.rb')
>
> I.e. during initialization, you list available files and you want to
> load them later, but at that moment, they are not there already.
This code is still by any measure broken. There are lots of ways that
such code could fail to work.
Plainly what I'm trying to say is: If the potentially insecure code
has been loaded into a Python process, and the python interpreter has
the small modification that I suggested, then we will be able to
detect that the insecure code is loaded into memory and flag the
process/service as needing to be restarted.
That's all.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning json_simple
Excerpts from Josh Boyer's message of 2014-09-15 16:39:53 +0200: > On Sep 15, 2014 10:37 AM, "Steve Traylen" wrote: > > > > Hi, > > > > I am orphaning json_simple > > Why? It's the only piece of java in my packaging life and the packaging became hard where I need to learn all the maven macro stuff to fix bugs. Happy to maintain while trivial though can't justify more. Steve. > > josh -- -- Steve Traylen, CERN IT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning json_simple
On Sep 15, 2014 10:37 AM, "Steve Traylen" wrote: > > Hi, > > I am orphaning json_simple Why? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning json_simple
Hi, I am orphaning json_simple Steve -- -- Steve Traylen, CERN IT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken dependencies: vdsm
Posting to -devel because I can't post to vdsm-owner or virt-maintenance. On 09/15/2014 09:57 AM, Balamurugan Arumugam wrote: [Adding Dan] - Original Message - From: "Kaleb S. KEITHLEY" To: "Lalatendu Mohanty" , build...@fedoraproject.org, vdsm-ow...@fedoraproject.org Cc: glusterfs-ow...@fedoraproject.org Sent: Monday, September 15, 2014 4:54:50 PM Subject: Re: Broken dependencies: vdsm On 09/15/2014 04:39 AM, Lalatendu Mohanty wrote: On 09/14/2014 09:58 AM, build...@fedoraproject.org wrote: vdsm has broken dependencies in the epel-6 tree: vdsm-4.16.4-0.el6.ppc64 requires glusterfs-rdma vdsm-4.16.4-0.el6.ppc64 requires glusterfs-fuse vdsm-4.16.4-0.el6.ppc64 requires glusterfs-cli vdsm-4.16.4-0.el6.ppc64 requires glusterfs-api vdsm-4.16.4-0.el6.ppc64 requires glusterfs >= 0:3.4.2 vdsm-4.16.4-0.el6.ppc64 requires fence-agents On x86_64: vdsm-gluster-4.16.4-0.el6.noarch requires glusterfs-server On ppc64: vdsm-gluster-4.16.4-0.el6.noarch requires glusterfs-server Just to add, Glusterfs (Server and Client) bits are not available in EPEL because GlusterFS RPMs (client RPMs) are available in RHEL base channel. Not sure how to fox this issue. To expand on Lala's comment, everything above _except_ glusterfs-cli and glusterfs-server are in RHEL. No part of glusterfs is in EPEL. Why does vdsm now require glusterfs-cli and glusterfs-server? It didn't use to AFAIK. gluster storage domain in vdsm uses glusterfs-cli for mounting gluster volume. Huh? The glusterfs-cli RPM has /usr/sbin/gluster and its manpage. That's it. That's not the command used to mount a gluster volume. A simple `mount -t glusterfs $server:$volname $mntpoint` is all it takes. (Assuming you have glusterfs and glusterfs-fuse RPMs installed.) glusterfs-server and glusterfs-cli and for people to set up and manage a gluster server. AFAIK it's a mistake for vdsm to have these as dependencies. But I am not sure about glusterfs-server dependency. Dan, could you help us resolving the requirement of glusterfs-server package dependency for vdsm? Regards, Bala -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
Dne 15.9.2014 14:28, Richard W.M. Jones napsal(a):
> On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
>> Every of the script is based on assumption that you already read some
>> library/unit whatever. But that is not enough. I wonder how you want to
>> detect that you need restart in case that I have something like this:
>>
>> $ ls
>> foo.rb
>> bar.rb
>>
>> $ cat foo.rb
>>
>> def some_function
>> require 'bar'
>> end
>>
>> And now
>>
>> 1) I run some application, which loads my foo.rb file.
>> 2) I later update the package which removes bar.rb file.
>> 3) And I call some_function which fails due to missing bar.rb
> How is this not 'foo' simply being broken?
They might come from different packages. Or there might be also another
level of requires, where bar.rb requires by baz.rb. In case that bar.rb
stays and baz.rb is removed, you still cannot predict that this will
fail in the future, since neither of these files was loaded before.
Or there might be another example of code with similar issues:
$ cat foo.rb
def some_function
$files.each {|f| require f}
end
$files = Dir.glob('*.rb')
I.e. during initialization, you list available files and you want to
load them later, but at that moment, they are not there already.
> ie. Not expressing its
> needs properly in its RPM dependencies?
We typically express dependencies between packages, the separate library
files are typically considered just implementation detail. But I agree
that it would be more precise to express dependencies between separate
library files, instead of packages. Anyway, this is case of dynamic
loading, so I am not sure how you would specify the dependencies.
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, Sep 15, 2014 at 02:49:34PM +0200, Reindl Harald wrote: > > > Am 15.09.2014 um 14:44 schrieb Richard W.M. Jones: > > On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote: > >> > >> Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones: > >>> On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote: > 1) I run some application, which loads my foo.rb file. > 2) I later update the package which removes bar.rb file. > 3) And I call some_function which fails due to missing bar.rb > >>> > >>> How is this not 'foo' simply being broken? ie. Not expressing its > >>> needs properly in its RPM dependencies? > >>> > >>> It would still have been broken even with a reboot > >> > >> no - why should it? > >> > >> 'foo' is loaded in memory, updated and now has different dependencies > >> no longer require 'bar.rb' but your running version still do > > > > Please read closely. 'foo' has *not* been updated. > > > > If 'foo' had been updated, we would have spotted it and restarted that > > process using my technique outlined in the previous email > > cross deps coming in my mind > foo -> library -> library -> library > > * the first maybe already loaded > * also loaded the second one in a previous call > * that version relies on teh third one for some operations > * in a update the deps have changed > > so you may have a mix with different dep-chains in memory > and some parts used the first time from disk with unexpected > results I have absolutely no idea what you are talking about. 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
Am 15.09.2014 um 14:44 schrieb Richard W.M. Jones: > On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote: >> >> Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones: >>> On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote: 1) I run some application, which loads my foo.rb file. 2) I later update the package which removes bar.rb file. 3) And I call some_function which fails due to missing bar.rb >>> >>> How is this not 'foo' simply being broken? ie. Not expressing its >>> needs properly in its RPM dependencies? >>> >>> It would still have been broken even with a reboot >> >> no - why should it? >> >> 'foo' is loaded in memory, updated and now has different dependencies >> no longer require 'bar.rb' but your running version still do > > Please read closely. 'foo' has *not* been updated. > > If 'foo' had been updated, we would have spotted it and restarted that > process using my technique outlined in the previous email cross deps coming in my mind foo -> library -> library -> library * the first maybe already loaded * also loaded the second one in a previous call * that version relies on teh third one for some operations * in a update the deps have changed so you may have a mix with different dep-chains in memory and some parts used the first time from disk with unexpected results signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote: > > Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones: > > On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote: > >> 1) I run some application, which loads my foo.rb file. > >> 2) I later update the package which removes bar.rb file. > >> 3) And I call some_function which fails due to missing bar.rb > > > > How is this not 'foo' simply being broken? ie. Not expressing its > > needs properly in its RPM dependencies? > > > > It would still have been broken even with a reboot > > no - why should it? > > 'foo' is loaded in memory, updated and now has different dependencies > no longer require 'bar.rb' but your running version still do Please read closely. 'foo' has *not* been updated. If 'foo' had been updated, we would have spotted it and restarted that process using my technique outlined in the previous email. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-09-16)
WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston, 22:00 Tokyo) in #fedora-meeting on Freenode. = Topics = * Language specific mirrors for Fedora Playground compliant packages * SCLs, building above them and their position in Fedora/EPEL * Picking chairman for the next meeting * OpenFloor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones: > On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote: >> 1) I run some application, which loads my foo.rb file. >> 2) I later update the package which removes bar.rb file. >> 3) And I call some_function which fails due to missing bar.rb > > How is this not 'foo' simply being broken? ie. Not expressing its > needs properly in its RPM dependencies? > > It would still have been broken even with a reboot no - why should it? 'foo' is loaded in memory, updated and now has different dependencies no longer require 'bar.rb' but your running version still do yes, such corner cases are possible, regardless no reason for go the windows way and reboot after any minor update signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote: > Every of the script is based on assumption that you already read some > library/unit whatever. But that is not enough. I wonder how you want to > detect that you need restart in case that I have something like this: > > $ ls > foo.rb > bar.rb > > $ cat foo.rb > > def some_function > require 'bar' > end > > And now > > 1) I run some application, which loads my foo.rb file. > 2) I later update the package which removes bar.rb file. > 3) And I call some_function which fails due to missing bar.rb How is this not 'foo' simply being broken? ie. Not expressing its needs properly in its RPM dependencies? It would still have been broken even with a reboot. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On 09/15/2014 10:57 AM, Vít Ondruch wrote: Every of the script is based on assumption that you already read some library/unit whatever. But that is not enough. I wonder how you want to detect that you need restart in case that I have something like this: $ ls foo.rb bar.rb $ cat foo.rb def some_function require 'bar' end And now 1) I run some application, which loads my foo.rb file. 2) I later update the package which removes bar.rb file. 3) And I call some_function which fails due to missing bar.rb Indeed, would foo.rb and bar.rb comes from different packages, then there is really no way. There is no universal and reliable way how to detect this scenario IMO. Well, if you are operator of nuclear power plant, then I understand the need of reboot after each upgrade. But *I* do not want to reboot after each upgrade. Those crashes will be 0.1% of all crashes on my workstation, which is less PITA than rebooting because I upgraded 'foo-doc' package. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GNOME 3.13.92 megaupdate
Hi all, This week brings us the GNOME 3.13.92 release and I'm coordinating the builds and the megaupdate in Bodhi. Same thing as two weeks ago: I'll pick up any builds from the f21-gnome target (you can see the builds in there with 'koji list-tagged f21-gnome'); use 'fedpkg build --target f21-gnome' for builds. In addition, I'll pick up any builds listed in the spreadsheet and I'll also mark any bug numbers listed there as fixed by the megaupdate. Extra builds and bugs fixed go here: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc&pli=1#gid=0 -- Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20140915 changes
Compose started at Mon Sep 15 07:15:02 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [couchdb] couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-10.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-2.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-4.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-2.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.8.git05ae1bb.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-3.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-5.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-7.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.7.git80db168.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [hibernate-search] hibe
Re: Finding all the source packages that include a copy of valgrind.h
On 09/15/2014 11:21 AM, Mark Wielaard wrote: On Sun, 2014-09-14 at 11:42 +0200, Mark Wielaard wrote: Thanks. That is a much bigger list than the packages I already filed bugs for based on the reproquery against the debuginfo packages. https://bugzilla.redhat.com/show_bug.cgi?id=1141461 Specifically missing are: cockpit, exim, gearmand, ghostscript, ipxe, libmemcached, mingw-glib2, mingw-qt5-qtjsbackend, mongodb, openvswitch, qemu, R, realmd, rubygem-passenger, squid, wine-mono. I think that means they either don't enable valgrind support in the binary package or they don't generate proper debuginfo. I assume it still makes sense to file a bug report against these packages so the maintainer can investigate. If it turns out the package source does include a private copy of valgrind.h, but they don't actually use/activate support for it in the binary package, how should the package be marked? I checked out and prepped all the above packages. Some of the above were false positives. Quite likely. As I said, this was a more or less brute-force, scripted "unpackage/prep/find valgrind.h"-loop over all src.rpms. I let it run over my local rawhide mirror, over night :-) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140915 changes
Broken deps for i386 -- [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [bustle] bustle-0.4.7-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [cp2k] cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc22.i686 requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [debhelper] debhelper-9.20140613-2.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [elk] elk-openmpi-2.3.22-7.fc21.i686 requires libmpi_usempi.so.1 [elpa] elpa-openmpi-2013.11-4.008.fc21.i686 requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [freefem++] freefem++-3.30-5.fc22.i686 requires libcholmod.so.2 freefem++-mpich-3.30-5.fc22.i686 requires libcholmod.so.2 freefem++-openmpi-3.30-5.fc22.i686 requires libcholmod.so.2 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hgettext] ghc-hgettext-0.1.30-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so ghc-hgettext-0.1.30-3.fc22.i686 requires ghc(setlocale-1.0.0-fa663a40688afbabfd6017337b0554c3) ghc-hgettext-devel-0.1.30-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so ghc-hgettext-devel-0.1.30-3.fc22.i686 requires ghc-devel(setlocale-1.0.0-fa663a40688afbabfd6017337b0554c3) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.
Re: Finding all the source packages that include a copy of valgrind.h
On Sun, 2014-09-14 at 11:42 +0200, Mark Wielaard wrote: > Thanks. That is a much bigger list than the packages I already filed > bugs for based on the reproquery against the debuginfo packages. > https://bugzilla.redhat.com/show_bug.cgi?id=1141461 > Specifically missing are: cockpit, exim, gearmand, ghostscript, ipxe, > libmemcached, mingw-glib2, mingw-qt5-qtjsbackend, mongodb, openvswitch, > qemu, R, realmd, rubygem-passenger, squid, wine-mono. > > I think that means they either don't enable valgrind support in the > binary package or they don't generate proper debuginfo. I assume it > still makes sense to file a bug report against these packages so the > maintainer can investigate. If it turns out the package source does > include a private copy of valgrind.h, but they don't actually > use/activate support for it in the binary package, how should the > package be marked? I checked out and prepped all the above packages. Some of the above were false positives. They contained a valgrind.h which wasn't actually a copy of the upstream valgrind version of that file (but often a wrapper to use in case the system valgrind.h was missing). But most of them did indeed include a private copy of valgrind.h. I filed bugs for those that did and added them to the tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141461 Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
Every of the script is based on assumption that you already read some library/unit whatever. But that is not enough. I wonder how you want to detect that you need restart in case that I have something like this: $ ls foo.rb bar.rb $ cat foo.rb def some_function require 'bar' end And now 1) I run some application, which loads my foo.rb file. 2) I later update the package which removes bar.rb file. 3) And I call some_function which fails due to missing bar.rb There is no universal and reliable way how to detect this scenario IMO. Vít Dne 15.9.2014 10:06, Richard W.M. Jones napsal(a): > On Mon, Sep 15, 2014 at 09:50:36AM +0200, Miroslav Suchý wrote: >> On 09/12/2014 07:09 PM, Reindl Harald wrote: >>> never worked relieable here on multiple machines >>> >>> it often showed nothing where i knew the thing >>> which should be restarted without looking and >>> "lsof" proved it >> I am one of those guys who refuse to reboot after each upgrade (and >> it works for me) and needs-restarting is ugly and insufficient to >> me. >> >> Therefore I initiated this project: >> https://github.com/FrostyX/tracer >> http://copr.fedoraproject.org/coprs/frostyx/tracer/ >> >> It is still not finished and ready for announcement, but if you are >> looking for some other way than offline-upgrade, this might be worth >> of participating. > It wasn't clear to me how tracer works for non-C programs. > > However there was some Red Hat only discussion recently about how to > do this for Python programs, with minimal overhead. Below I'm just > reproducing a technique (untested) that I think will work for Python. > > It requires a small patch to the Python interpreter, and a similar > patch to any other language interpreters (eg. Perl, Ruby). > > Rich. > > --- > For each module (*.py or *.pyc) that it imports, have it mmap the > first page of that file into its memory. > > The mmap would be PROT_NONE because it's not actually used, and the > associated file descriptor should be closed. > > This will appear in /proc/PID/maps, with a "(deleted)" flag if the > underlying file gets deleted (and hence the process needs restarting). > > The cost should be almost nothing: > > - 4K of virtual memory, no real memory > - an extra mmap syscall on import > - an extra segment in the kernel's VM AVL > --- > > Rich. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On 09/15/2014 10:06 AM, Richard W.M. Jones wrote: It wasn't clear to me how tracer works for non-C programs. https://github.com/FrostyX/tracer/commit/4abfc4ecbc6d1d4cd89b7162e1ba3f63088db3ff Which basicaly checkout output of `ps` and if there is e.g. python as executable, it will check for arguments and use those. But I agree that interpreted languages are problem, because they open the file, read it and close the handler. So there are no footsteps to track. However there was some Red Hat only discussion recently about how to do this for Python programs, with minimal overhead. Below I'm just reproducing a technique (untested) that I think will work for Python. It requires a small patch to the Python interpreter, and a similar patch to any other language interpreters (eg. Perl, Ruby). Rich. --- For each module (*.py or *.pyc) that it imports, have it mmap the first page of that file into its memory. The mmap would be PROT_NONE because it's not actually used, and the associated file descriptor should be closed. This will appear in /proc/PID/maps, with a "(deleted)" flag if the underlying file gets deleted (and hence the process needs restarting). The cost should be almost nothing: - 4K of virtual memory, no real memory - an extra mmap syscall on import - an extra segment in the kernel's VM AVL --- Very nice. Is there some bugzilla RFE report for this? Or should I file it? -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, Sep 15, 2014 at 09:50:36AM +0200, Miroslav Suchý wrote: > On 09/12/2014 07:09 PM, Reindl Harald wrote: > >never worked relieable here on multiple machines > > > >it often showed nothing where i knew the thing > >which should be restarted without looking and > >"lsof" proved it > > I am one of those guys who refuse to reboot after each upgrade (and > it works for me) and needs-restarting is ugly and insufficient to > me. > > Therefore I initiated this project: > https://github.com/FrostyX/tracer > http://copr.fedoraproject.org/coprs/frostyx/tracer/ > > It is still not finished and ready for announcement, but if you are > looking for some other way than offline-upgrade, this might be worth > of participating. It wasn't clear to me how tracer works for non-C programs. However there was some Red Hat only discussion recently about how to do this for Python programs, with minimal overhead. Below I'm just reproducing a technique (untested) that I think will work for Python. It requires a small patch to the Python interpreter, and a similar patch to any other language interpreters (eg. Perl, Ruby). Rich. --- For each module (*.py or *.pyc) that it imports, have it mmap the first page of that file into its memory. The mmap would be PROT_NONE because it's not actually used, and the associated file descriptor should be closed. This will appear in /proc/PID/maps, with a "(deleted)" flag if the underlying file gets deleted (and hence the process needs restarting). The cost should be almost nothing: - 4K of virtual memory, no real memory - an extra mmap syscall on import - an extra segment in the kernel's VM AVL --- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On 09/12/2014 07:09 PM, Reindl Harald wrote: never worked relieable here on multiple machines it often showed nothing where i knew the thing which should be restarted without looking and "lsof" proved it I am one of those guys who refuse to reboot after each upgrade (and it works for me) and needs-restarting is ugly and insufficient to me. Therefore I initiated this project: https://github.com/FrostyX/tracer http://copr.fedoraproject.org/coprs/frostyx/tracer/ It is still not finished and ready for announcement, but if you are looking for some other way than offline-upgrade, this might be worth of participating. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
python-urlgrabber to be orphaned
FYI: According the: https://bugzilla.redhat.com/show_bug.cgi?id=985288#c10 it seems that python-urlgrabber will be orphaned and dropped from future releases. There is still some packages, which use it: anaconda-0:20.25.15-1.fc20.x86_64 cas-0:1.0-5.fc20.noarch cobbler-0:2.4.0-2.fc20.noarch koji-0:1.8.0-2.fc20.noarch liveusb-creator-0:3.12.0-1.fc20.noarch osc-0:0.140.1-108.1.1.fc20.noarch pyjigdo-0:0.4.0.3-7.fc20.noarch pykickstart-0:1.99.48-1.fc20.noarch python-imgcreate-1:20.1-1.fc20.x86_64 sigul-0:0.100-3.fc20.noarch transifex-0:1.2.1-11.fc20.noarch virt-manager-common-0:0.10.0-5.git1ffcc0cc.fc20.noarch yum-0:3.4.3-106.fc20.noarch yumex-0:3.0.13-1.fc20.noarch If you still want to use it, please contact upstream and you can take over maintainership in Fedora and take over the upstream work. Otherwise there is python-request, however it is less feature-rich. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
