Re: Broken chkconfig in rawhide?
Helllo Reindl, Rex, thanks for your comments: I'll wait for new mariadb package Best, Mario On 14 August 2013 17:04, Rex Dieter wrote: > Rex Dieter wrote: > > > Mario Ceresa wrote: > > > >> Dear all, while trying to rebuild InsightToolkit in rawhide I get the > >> following error ( > >> http://kojipkgs.fedoraproject.org//work/tasks/3964/5813964/root.log): > >> > >> DEBUG util.py:264: Error: Package: 1:mariadb-5.5.32-9.fc20.x86_64 > >> (build) > >> DEBUG util.py:264: Requires: /sbin/update-alternatives > > > > Looks like a bug in mariadb packaging not following > > http://fedoraproject.org/wiki/Packaging:Alternatives > > > > chkconfig provides /usr/sbin/update-alternatives > > Should (hopefully) be fixed in mariadb-5.5.32-10 build underway now. > > -- rex > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
heads up: BlueZ 5 has landed in rawhide
Hi all, FESCo accepted BlueZ 5 for F20 at yesterday's meeting and I've gone ahead and imported it in Rawhide. Small status report where we currently stand: bluez- updated to 5.8 gnome-bluetooth - updated to 3.9.3 that has BlueZ 5 support gnome-user-share - won't get ported in time for F20 pulseaudio - updated to a git snapshot with BlueZ 5 support. Upstream is currently redoing the BlueZ 5 support, so expect changes there before the PA 5.0 release. NetworkManager - currently not ported in Rawhide; the NM people are working on this KDE's BlueDevil - Rex Dieter updated it to a git snapshot last night; some functionality (file transfer) is currently missing, some (pairing) is working. Upstream is working on this. blueman - should get retired from rawhide, dead upstream and not ported to BlueZ 5 panel applet:- for MATE/XFCE/LXDE - Blueman is going away and mate-bluetooth isn't receiving much love upstream. The working plan is to resurrect the applet from gnome-bluetooth in a separate module. raveit65 started the work on this, but could use some help there. -- 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
Re: Broken dependencies: python-osmgpsmap
On Wed, Aug 14, 2013 at 1:34 PM, Jeffrey Ollie wrote: > Sorry, just seeing this discussion now. What happened was that the > newest version of osm-gps-map added gobject introspection, so Python > bindings can be automatically generated. The older python-osmgpsmap > bindings I believe are deprecated now. I haven't had the time to set > up a rawhide system to do any testing though but probably what needs > to happen is make sure that anything that used the older bindings get > ported and then the old bindings be retired. AFAIK the only thing > that used the bindings is Gramps, but I haven't used that in a long > time and turned over ownership. Checking my F18 system only two packages require python-osmgpsmap... # repoquery --whatrequires python-osmgpsmap gramps-0:3.4.2-1.fc18.noarch kismon-0:0.6-4.fc18.noarch I wonder if the current/latest version of gramps and kismon able to use these auto-generated bindings? Richard -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say "fedora is for testing". It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of "we don't support that upgrade path/method". We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. Paul -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 2013-08-15 at 09:40 -0400, Paul Wouters wrote: > We can't tell people to re-install from scratch every 6 months. What > we need is an "apt-get dist-upgrade" equivalent. +1 -- Best Regards, Artem Bityutskiy -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2013 09:40 AM, Paul Wouters wrote: > On Thu, 15 Aug 2013, Matthew Garrett wrote: > >> I want increased participation in the creation of Fedora, which >> is a product with a defined set of software shipped as default. >> I'm also happy with people working to make it practical to use >> Fedora as the basis for derived products (such as the spins and >> remixes), providing that they don't compromise the product that >> we're producing. > > I feel that people mostly say "fedora is for testing". It is > somewhat supported by responses to upgrade problems to a new > version which invariable are along the lines of "we don't support > that upgrade path/method". > > We can't tell people to re-install from scratch every 6 months. > What we need is an "apt-get dist-upgrade" equivalent. > I think your information is out of date. For the last two releases, we've had the excellent 'fedup' tool that performs a supported distribution upgrade, similar (but better than) 'apt-get dist-upgrade'. I strongly suggest taking a look. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIM4zMACgkQeiVVYja6o6PqgQCgqiOXDD2FjM9OxLtiB7dwPR7Y MXIAnjGGBNUOV1HPNbtmHcaMJ6hQpq1X =rZHt -END PGP 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: RFC: Old packages remain on the mirrors for one week
On 13. 8. 2013 at 11:04:52, Chris Murphy wrote: > What's the interval of repomd changes, daily? What approximate percentage of > the entire repomd changes between day 1 and day 7? If the delta is > comparatively small to full metadata files, what about implementing a daily > repomd_delta sorta like deltarpms? This notion has already been out there for some time and we've got a proof-of- concept implementation. However even if the design is accepted and the implementation get finished in both yum and dnf, we are still looking at a long term solution which will not take place any time soon (you first need to have a support in the infrastructure everywhere to utilize this functionality). > I see both yum and dnf downloading large repomd files once the local cache > is considered stale. Yes, but the download only takes place once a week instead of every single day. Thanks Jan -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:40 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say "fedora is for testing". It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of "we don't support that upgrade path/method". We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. Paul I agree our updates should be supported option ;-) They are usually working very well. Marcela -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 09:40:01AM -0400, Paul Wouters wrote: > On Thu, 15 Aug 2013, Matthew Garrett wrote: > > >I want increased participation in the creation of Fedora, which is a > >product with a defined set of software shipped as default. I'm also > >happy with people working to make it practical to use Fedora as the > >basis for derived products (such as the spins and remixes), providing > >that they don't compromise the product that we're producing. > > I feel that people mostly say "fedora is for testing". It is somewhat > supported by responses to upgrade problems to a new version which > invariable are along the lines of "we don't support that upgrade > path/method". What's wrong with fedup? -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known I had tried preupgrade/fedup in the past, but it tried to stuff too many files in /boot because my root partition was encrypted, so this method was never usable for me. The wiki mentions that files now go into /var/lib/fedora-upgrade (which btw should really be /var/cache/fedora-upgrade) which is only available after asking for my disk encryption password. I'll try it for f18->f19, and if this got fixed that is a big step towards running fedora longterm across releases. Paul -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 8:19 AM, Richard Shaw wrote: > > Checking my F18 system only two packages require python-osmgpsmap... > > # repoquery --whatrequires python-osmgpsmap > gramps-0:3.4.2-1.fc18.noarch > kismon-0:0.6-4.fc18.noarch > > I wonder if the current/latest version of gramps and kismon able to use > these auto-generated bindings? I'm pretty sure gramps will, as it was a request from that community that propmpted me to update osm-gps-map in rawhide. -- Jeff Ollie -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 9:47 AM, Jeffrey Ollie wrote: > On Thu, Aug 15, 2013 at 8:19 AM, Richard Shaw > wrote: > > > > Checking my F18 system only two packages require python-osmgpsmap... > > > > # repoquery --whatrequires python-osmgpsmap > > gramps-0:3.4.2-1.fc18.noarch > > kismon-0:0.6-4.fc18.noarch > > > > I wonder if the current/latest version of gramps and kismon able to use > > these auto-generated bindings? > > I'm pretty sure gramps will, as it was a request from that community > that propmpted me to update osm-gps-map in rawhide. As a side note, it looks like it will also use GTK3 instead of GTK2, which also seems to have GObject introspection (no pygtk3 package exists or is required). Richard -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 9:47 AM, Jeffrey Ollie wrote: > On Thu, Aug 15, 2013 at 8:19 AM, Richard Shaw > wrote: > > > > Checking my F18 system only two packages require python-osmgpsmap... > > > > # repoquery --whatrequires python-osmgpsmap > > gramps-0:3.4.2-1.fc18.noarch > > kismon-0:0.6-4.fc18.noarch > > > > I wonder if the current/latest version of gramps and kismon able to use > > these auto-generated bindings? > > I'm pretty sure gramps will, as it was a request from that community > that propmpted me to update osm-gps-map in rawhide. > > -- > Jeff Ollie > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Speaking as the new gramps maintainer, if the osm-gps-map Python bindings were built, I would be happy to test gramps with them and switch if they work. -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Hi On Thu, Aug 15, 2013 at 10:36 AM, Paul Wouters > I'll try it for f18->f19, and if this got fixed that is a big step > towards running fedora longterm across releases. > Fedup is not the same thing as preupgrade and it appears you are complaining about issues in preupgrade and haven't tried fedup yet. Preupgrade doesn't exist anymore and Fedup is still the recommended option and all it does is run a yum upgrade is a more constrained environment. If you run into any problems, these are just bugs which needs to get filed and fixed. Rahul -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: > I'm pretty sure gramps will, as it was a request from that community > >> that propmpted me to update osm-gps-map in rawhide. > > > Speaking as the new gramps maintainer, if the osm-gps-map Python bindings >> were built, I would be happy to test gramps with them and switch if they >> work. > > Jon, you've got to have a ton of packages you maintain, let me know if you want some help with this one. This transition may be a bit much for me but I can help out. Richard -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: > > Speaking as the new gramps maintainer, if the osm-gps-map Python bindings > were built, I would be happy to test gramps with them and switch if they > work. It's my understanding that with gobject introspection that Python bindings don't need to be "built", they are automatically generated at runtime. So all you need is the latest osm-gps-map installed... I'm not an expert in that area so I could be wrong though. -- Jeff Ollie -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 9:56 AM, Richard Shaw wrote: > On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: > >> I'm pretty sure gramps will, as it was a request from that community >> >>> that propmpted me to update osm-gps-map in rawhide. >> >> > > >> Speaking as the new gramps maintainer, if the osm-gps-map Python bindings >>> were built, I would be happy to test gramps with them and switch if they >>> work. >> >> > Jon, you've got to have a ton of packages you maintain, let me know if you > want some help with this one. This transition may be a bit much for me but > I can help out. > Testers always welcome. :) > > Richard > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 10:02 AM, Jeffrey Ollie wrote: > On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: > > > > Speaking as the new gramps maintainer, if the osm-gps-map Python bindings > > were built, I would be happy to test gramps with them and switch if they > > work. > > It's my understanding that with gobject introspection that Python > bindings don't need to be "built", they are automatically generated at > runtime. So all you need is the latest osm-gps-map installed... I'm > not an expert in that area so I could be wrong though. > So, in theory, I could remove the Requires on python-osmgpsmap (and remove the package from the system) and run gramps and it works? -J > -- > Jeff Ollie > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 10:07 AM, Jon Ciesla wrote: > > > > On Thu, Aug 15, 2013 at 10:02 AM, Jeffrey Ollie wrote: > >> On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: >> > >> > Speaking as the new gramps maintainer, if the osm-gps-map Python >> bindings >> > were built, I would be happy to test gramps with them and switch if they >> > work. >> >> It's my understanding that with gobject introspection that Python >> bindings don't need to be "built", they are automatically generated at >> runtime. So all you need is the latest osm-gps-map installed... I'm >> not an expert in that area so I could be wrong though. >> > > So, in theory, I could remove the Requires on python-osmgpsmap (and remove > the package from the system) and run gramps and it works? > > Of course, looking at the gramps code, it's already broken, it's importing the module incorrectly. . . ./plugins/lib/maps/osmgps.py:from gi.repository import OsmGpsMap as osmgpsmap ./plugins/lib/maps/markerlayer.py:from gi.repository import OsmGpsMap as osmgpsmap ./plugins/lib/maps/placeselection.py:from .osmgps import OsmGps ./plugins/lib/maps/constants.py:from gi.repository import OsmGpsMap as osmgpsmap ./grampsapp.py:from gi.repository import OsmGpsMap as osmgpsmap -J > -J > > >> -- >> Jeff Ollie >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > -- > http://cecinestpasunefromage.wordpress.com/ > > in your fear, seek only peace > in your fear, seek only love > > -d. bowie > -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 10:07 AM, Jon Ciesla wrote: > On Thu, Aug 15, 2013 at 10:02 AM, Jeffrey Ollie wrote: > >> On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla wrote: >> > >> > Speaking as the new gramps maintainer, if the osm-gps-map Python >> bindings >> > were built, I would be happy to test gramps with them and switch if they >> > work. >> >> It's my understanding that with gobject introspection that Python >> bindings don't need to be "built", they are automatically generated at >> runtime. So all you need is the latest osm-gps-map installed... I'm >> not an expert in that area so I could be wrong though. >> > > So, in theory, I could remove the Requires on python-osmgpsmap (and remove > the package from the system) and run gramps and it works? > I'm testing that theory right now in a local mock build... Removed: BuildRequires: pygtk2-libglade Requires: python-osmgpsmap Changed: (from python-devel) BuildRequires: python2-devel Added: BuildRequires: pygobject2-devel BuildRequires: osm-gps-map-devel Requires: osm-gps-map Looks like I missed adding gtk3... I'll fix that and try again. Richard -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 10:16 AM, Richard Shaw wrote: > On Thu, Aug 15, 2013 at 10:07 AM, Jon Ciesla wrote: > >> On Thu, Aug 15, 2013 at 10:02 AM, Jeffrey Ollie wrote: >> >>> On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla >>> wrote: >>> > >>> > Speaking as the new gramps maintainer, if the osm-gps-map Python >>> bindings >>> > were built, I would be happy to test gramps with them and switch if >>> they >>> > work. >>> >>> It's my understanding that with gobject introspection that Python >>> bindings don't need to be "built", they are automatically generated at >>> runtime. So all you need is the latest osm-gps-map installed... I'm >>> not an expert in that area so I could be wrong though. >>> >> >> So, in theory, I could remove the Requires on python-osmgpsmap (and >> remove the package from the system) and run gramps and it works? >> > > I'm testing that theory right now in a local mock build... > > Removed: > BuildRequires: pygtk2-libglade > Requires: python-osmgpsmap > > Changed: (from python-devel) > BuildRequires: python2-devel > > Added: > BuildRequires: pygobject2-devel > BuildRequires: osm-gps-map-devel > Requires: osm-gps-map > > Looks like I missed adding gtk3... I'll fix that and try again. > Cool. If that works, let me know and I'll update rawhide. -J > > Richard > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known I had tried preupgrade/fedup in the past, but it tried to stuff too many files in /boot because my root partition was encrypted, so this method was never usable for me. The wiki mentions that files now go into /var/lib/fedora-upgrade (which btw should really be /var/cache/fedora-upgrade) which is only available after asking for my disk encryption password. I'll try it for f18->f19, and if this got fixed that is a big step towards running fedora longterm across releases. AFAIK, during an upgrade, fedup stores all required rpms below /var/cache/yum. This means, if you don't have a sufficiently large /var partition, you are likely to hit similar issues as with preupgrade. Though this is less likely to hit users than storing packages under /boot, it's still possible to happen (it did happen to me). Another issue I encountered with all 3 upgrade methods, was them not being able to compute required disk space sizes correctly, occasionally causing rpmdb corruptions (I did encounter this issue). And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. A pretty nasty such case had been F18 been equipped with a newer kernel than F19 for a larger time frame. 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
Re: rawhide report: 20130815 changes
On 08/15/2013 04:32 PM, Fedora Rawhide Report wrote: Compose started at Thu Aug 15 08:15:02 UTC 2013 Broken deps for i386 -- [FlightGear] [fgrun] Fallout of the OpenSceneGraph upgrade. Now fixed in rawhide. 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
Re: Broken dependencies: python-osmgpsmap
The requirements from the gramps webpage is a little hard to follow since it has information from both 3.X and 4.X but I'm trying to work through it, however, looking at the BR in the spec, it seems like there are more than typically required for a pure python project... I'll look through the setup files and see which requirements it's actually checking for during build and which just need to be "Required". Richard -- 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: python-osmgpsmap
On Thu, Aug 15, 2013 at 10:25 AM, Richard Shaw wrote: > The requirements from the gramps webpage is a little hard to follow since > it has information from both 3.X and 4.X but I'm trying to work through it, > however, looking at the BR in the spec, it seems like there are more than > typically required for a pure python project... I'll look through the setup > files and see which requirements it's actually checking for during build > and which just need to be "Required". > Yeah, I wouldn't be surprised if I'd carried along a few things no longer needed. -J > > Richard > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 15:40, schrieb Paul Wouters: > We can't tell people to re-install from scratch every 6 months. > What we need is an "apt-get dist-upgrade" equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known they are *not* more predictable as yum, the opposite is true and two months after the new release while your setup got updates as well as the new release *nobody* knows more how predictable fedup would be than yum 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 17:17, schrieb Ralf Corsepius: > On 08/15/2013 04:36 PM, Paul Wouters wrote: >> On Thu, 15 Aug 2013, Reindl Harald wrote: >> >>> Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. >>> >>> *we have* >>> >>> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum >>> >>> i currently count 450 dist-upgrade this way and the oldest >>> setups are upgraded from Fedora 9 to Fedora 18 - the only >>> stupid is that instead spend more effort in the yum-upgrades >>> waste all the time with preupgrade/fedup and whatever the >>> next inkarnation is known >> > And yet another issue is the fedora-distribution occasionally carrying > packages > with greater NEVRs in older releases than in newer release. what does *not* matter in case of "yum distro-sync" because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while "fedup" no normal user touchs half a year 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald wrote: > what does *not* matter in case of "yum distro-sync" because it does > also downgrades and if fedup has a problem with it the people who say > yum is not officially supported (while no support in any case exists) > should ask theirself who in the world needs fedup instead keep > fous on *one* well working tool > > besides the fact that yum-upgrades are most times better > yum is used and tested every single day from thousands > of users while "fedup" no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade. The difference is that since it's in a minimal env, you don't have possible problems with running processes, and you can make changes that would otherwise not be possible to a running system. If you use and like yum dist upgrades on running systems, thats great. However, fedup is more safe since it's not happening on a running system. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 05:37 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald wrote: what does *not* matter in case of "yum distro-sync" because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while "fedup" no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, ... and stores them in /var/cache/yum/... If you don't have a sufficiently large /var/cache, such a download easily exceeds the amount of available diskspace and fails. then reboots into a very minimal env and uses yum to do the upgrade. The difference is that since it's in a minimal env, you don't have possible problems with running processes, and you can make changes that would otherwise not be possible to a running system. Well, may-be I am wrong, but this does not match with what I experienced during the ca. 8 fedup driven updates, I've done. If you use and like yum dist upgrades on running systems, thats great. However, fedup is more safe since it's not happening on a running system. If you say so ... I saw f17->f18 hang during the "fedup reboot" and not come up at all, and had 2 f18->f19 systems suffering from corrupt rpmdbs. All f18->f19 systems had f18 kernels after fedup had completed, due to the kernel-versions. 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
Re: Review Request 45: Improve asset management
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/45/#review65 --- The problem here is how to deploy this in production - there is a python-flask-assets package but it is at 0.7 instead of upstream's 0.8 and there does not appear to be an el6 build either way (branch exists but it's empty). Once the dep is figured out and the spec updated, we can talk about getting this code in but right now it can't be deployed to production - Tim Flink On Aug. 12, 2013, 2:46 p.m., Martin Krizek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard-tflink.rhcloud.com/r/45/ > --- > > (Updated Aug. 12, 2013, 2:46 p.m.) > > > Review request for blockerbugs. > > > Bugs: 357 > https://fedorahosted.org/fedora-qa/ticket/357 > > > Repository: blockerbugs > > > Description > --- > > commit d86f88d7f9da899ffef44ad617a8a831327b7d80 > Author: Martin Krizek > Date: Mon Aug 12 16:40:16 2013 +0200 > > Improve asset management > > Fixes: #357 > > > I have not minified two js files in milestone_stats.html template as I am not > sure it's worth it, any objections? > > > Diffs > - > > requirements.txt 09e0318bc189512f5d324bda8879ad74c4763f95 > blockerbugs/templates/layout.html 49cdbd70ef8347965dfca93971449688f9cd6cb0 > blockerbugs/__init__.py bd9973579e80fc859f3e8d22c35753fbd024c5f0 > > Diff: http://reviewboard-tflink.rhcloud.com/r/45/diff/ > > > Testing > --- > > Loaded pages, seems like css and js work as expected after being minified. > > > Thanks, > > Martin Krizek > > ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 05:32 PM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of "yum distro-sync" It does matter, esp in case of the kernel, because the kernel is treated differently from most other packages in yum. Another case it matters is case when package versions are identical. In these cases, even though the NEVRS may be identical, the contents can be different (different paths, different deps etc.) 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
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 17:59:30 +0200 Ralf Corsepius wrote: > On 08/15/2013 05:37 PM, Kevin Fenzi wrote: ...snip... > > It gathers up the packages you will need to do the upgrade, > > ... and stores them in /var/cache/yum/... > > If you don't have a sufficiently large /var/cache, such a download > easily exceeds the amount of available diskspace and fails. Sure, but how would a live yum dist upgrade work there? It also has to download the rpms and store them before starting the transaction. ..snip... > If you say so ... I saw f17->f18 hang during the "fedup reboot" and > not come up at all, and had 2 f18->f19 systems suffering from corrupt > rpmdbs. You filed bugs on these I hope? :) > All f18->f19 systems had f18 kernels after fedup had completed, due > to the kernel-versions. Yeah, not sure what happened there. kevin signature.asc Description: PGP 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: Review Request 44: Update URLs should contain the update ID when possible
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/44/#review66 --- Does this work with ilgiz's update_sync code? Is anything other than the display code relying on having the URL? ie, what else could break by suddenly changing the update url during sync? - Tim Flink On Aug. 12, 2013, 12:57 p.m., Martin Krizek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard-tflink.rhcloud.com/r/44/ > --- > > (Updated Aug. 12, 2013, 12:57 p.m.) > > > Review request for blockerbugs. > > > Bugs: 386 > https://fedorahosted.org/fedora-qa/ticket/386 > > > Repository: blockerbugs > > > Description > --- > > commit be73d7514172ad122ec969b74a1bac37f14f28f4 > Author: Martin Krizek > Date: Mon Aug 12 14:52:39 2013 +0200 > > Update URLs should comtain the update ID when possible > > Fixes: #386 > > > Diffs > - > > blockerbugs/util/update_sync.py d664839ec1c5979dce980e7baad58154f4622e11 > > Diff: http://reviewboard-tflink.rhcloud.com/r/44/diff/ > > > Testing > --- > > Run sync without the fix to fetch urls with title in them. Then I run sync > with the fix, the sync process updated the urls to contain updateid instead > of title. > > > Thanks, > > Martin Krizek > > ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 11:32 AM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an "apt-get dist-upgrade" equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of "yum distro-sync" because it does also It seemed to matter yesterday when I tried to update a Fedora 19 vm to rawhide. Try it and see. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 18:02, schrieb Ralf Corsepius: > On 08/15/2013 05:32 PM, Reindl Harald wrote: >> >> >> Am 15.08.2013 17:17, schrieb Ralf Corsepius: >>> On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: > Am 15.08.2013 15:40, schrieb Paul Wouters: >> We can't tell people to re-install from scratch every 6 months. >> What we need is an "apt-get dist-upgrade" equivalent. > > *we have* > > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum > > i currently count 450 dist-upgrade this way and the oldest > setups are upgraded from Fedora 9 to Fedora 18 - the only > stupid is that instead spend more effort in the yum-upgrades > waste all the time with preupgrade/fedup and whatever the > next inkarnation is known >>> And yet another issue is the fedora-distribution occasionally carrying >>> packages >>> with greater NEVRs in older releases than in newer release. >> >> what does *not* matter in case of "yum distro-sync" > It does matter, esp in case of the kernel, because the kernel is treated > differently > from most other packages in yum. the only case and exactly here is yum the *better* variant you can verify kernel/grub-config *before* reboot and it is no problem to fix this before the shiny tools for upgrade including anaconda in F13 days did leave me machines more than once in a unbootable state which not happened in any of the 450 yum-dist-upgrades i made so far from FC6 to F19 > Another case it matters is case when package versions are identical. > In these cases, even though the NEVRS may be identical, the contents > can be different (different paths, different deps etc.) nonsense yum-3.4.3-54.fc18.noarch > yum-3.4.3-54.fc17.noarch 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 18:19, schrieb Kaleb KEITHLEY: > On 08/15/2013 11:32 AM, Reindl Harald wrote: > Am 15.08.2013 15:40, schrieb Paul Wouters: >> We can't tell people to re-install from scratch every 6 months. >> What we need is an "apt-get dist-upgrade" equivalent. > > *we have* > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum > > i currently count 450 dist-upgrade this way and the oldest > setups are upgraded from Fedora 9 to Fedora 18 - the only > stupid is that instead spend more effort in the yum-upgrades > waste all the time with preupgrade/fedup and whatever the > next inkarnation is known >>> And yet another issue is the fedora-distribution occasionally carrying >>> packages >>> with greater NEVRs in older releases than in newer release. >> >> what does *not* matter in case of "yum distro-sync" because it does also > > It seemed to matter yesterday when I tried to update a Fedora 19 vm to rawhide what exactly was the unsolveable problem you could not fix before reboot? and according to the message below how do someone imagine fedup could solve the specific problem without manual intervention? Original-Nachricht Betreff: Re: Schedule for Wednesday's FESCo Meeting (2013-08-14) Datum: Thu, 15 Aug 2013 09:37:57 -0600 Von: Kevin Fenzi > besides the fact that yum-upgrades are most times better > yum is used and tested every single day from thousands > of users while "fedup" no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 10:16 AM, Marcela Mašláňová wrote: I agree our updates should be supported option ;-) They are usually working very well. We really should try to stop using the word "supported" since it misleading for everybody. "Best effort" is what accurately describes what the community does so surely there is a word in the English vocabulary that is a better match to that then "support" and we can try to use... JBG -- 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: Review Request 42: Indicate bugs that are needinfo
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/42/#review67 --- the sync crashed for me when I tried to run it, will put the tb in trac since I don't know how to do preformatted text in a review. On a side note, those css diffs make me want to migrate to foundation 4 even more than before - that's a crazy diff for such a small change :-/ - Tim Flink On Aug. 8, 2013, 11:33 a.m., Martin Krizek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard-tflink.rhcloud.com/r/42/ > --- > > (Updated Aug. 8, 2013, 11:33 a.m.) > > > Review request for blockerbugs. > > > Bugs: 316 > https://fedorahosted.org/fedora-qa/ticket/316 > > > Repository: blockerbugs > > > Description > --- > > This patch adds a needinfo field into the Bug table. The field is filed with > the name of a user that the info is needed from, or empty string if needinfo > is not set. If needinfo is set, an icon is displayed in bug list in the same > way as the 'recently modified' icon -- any ideas on how to display the > information better? > > > Diffs > - > > sass/app.scss 061016495d9c46aef0efb5dcfc9e3a5eab43f72c > blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3 > blockerbugs/templates/blocker_list.html > 17cdc74d5cac7be3d3843196eeda9e01f1c91ff3 > blockerbugs/static/css/app.css 99b6fbc81b231c7f876f1365cfc63f6eade1217e > blockerbugs/static/css/app-foundation.css > 852272bf1bd1c629b30933b451daceec31812de7 > blockerbugs/models/bug.py 095cf7294a5b0a5b3fb9979abf9e669e4acd157c > alembic/versions/23cc8daafea8_add_needinfo_to_bug.py PRE-CREATION > > Diff: http://reviewboard-tflink.rhcloud.com/r/42/diff/ > > > Testing > --- > > Run db sync, one of the bugs had needinfo flag set, everything worked as > expected. > > > Thanks, > > Martin Krizek > > ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 10:26 AM, "Jóhann B. Guðmundsson" wrote: On 08/15/2013 10:16 AM, Marcela Mašláňová wrote: I agree our updates should be supported option ;-) They are usually working very well. We really should try to stop using the word "supported" since it misleading for everybody. "Best effort" is what accurately describes what the community does so surely there is a word in the English vocabulary that is a better match to that then "support" and we can try to use... tested? -- Nathanael d. Noblet t 403.875.4613 -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 09:40 AM, Paul Wouters wrote: I feel that people mostly say "fedora is for testing". It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of "we don't support that upgrade path/method". Well whomever choose to decide that we "support" upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is "preferred","supported" or "recommended". The fact is we have always had more testing with yum upgrade vs preupgrade/fedup since that is always been the preferred choice of our QA community members and what we recommend ourselves to use [1]. The bottom line is that we cannot "support" upgrades et all since we cant test cover all the upgrade path of mixed match combination of our ca 12.000 components. ( and that's excluding any testing with 3rd party repo's involved ) . We don't even provide a fallback method encase something goes awry but hopefully that will change for all the spins that decide to default to btrfs if/when that time comes and we should be able to implement something that boots into the volume before upgrade. From my personal opinion we should not be "supporting" upgrade et all since in all reality we cant do that and we end up sending misleading signals to Fedora consumers when doing that. JBG 1. https://fedoraproject.org/wiki/Releases/Rawhide?rd=Rawhide#Yum_from_Existing_install -- 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: Suggestion: bmap files and bmaptool
On 8/13/13 8:58 AM, Artem Bityutskiy wrote: > # Make the image to be sparse > $ cp --sparse=always Fedora-x86_64-19-20130627-sda.raw > Fedora-x86_64-19-20130627-sda.raw.sparse > > # Generate the bmap file > $ bmaptool create Fedora-x86_64-19-20130627-sda.raw.sparse -o > Fedora-x86_64-19-20130627-sda.raw.sparse.bmap So this is the part that interests me . . . There seem to be two issues here; how do we efficiently (compress and) transport sparse files while retaining sparseness, and how do we efficiently operate on files which are already sparse. For the latter, you're using your bmap tool to map what is hopefully a static file (via fibmap or fiemap, I guess?). I haven't looked at how you've done it, but you do need to be very careful that the file is stable & quiesced on disk. Mapping it this way can be fraught with errors if the file is changing, or has delalloc blocks, etc. And of course getting the mapping wrong means data corruption. If the file is known to be sparse, then going forward, using SEEK_HOLE / SEEK_DATA is probably the best approach. But then there's the issue of transporting these sparse files around. We have had the same problem in the past with large e2image metadata image files, which may be terabytes in length, with only gigabytes or megabytes of real data. e2image _itself_ creates a sparse file, but bzipping it or rsyncing it still processes terabytes of zeros, and loses all notion of sparseness. xfs_metadump worked around this by creating its own compact format describing a sparse file's data & sparseness, which is "unpacked" into a normal sparse file by xfs_mdrestore. More recently e2image gained something slightly similar, but used the existing qcow format to encode the sparseness. qemu-image convert to "raw" type turns it back into a "normal" sparse file readable by e2fsprogs tools. So I guess your solution requires 2 pieces of information; the existing file, and the mapping file. Are there mechanisms to ensure that they are in sync? Another approach which might (?) be more robust, is to somehow encode that sparseness in a single file format that can be transported/compressed/copied w/o losing the sparseness information, and another tool to operate efficiently on that format at the destination, either by unpacking it to a normal sparse file or piping it to some other process. Just some thoughts... -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned: libgnomecups
Underlying dep of libgnomeprint22/libgnomeprintui22, which is used by a few end-user things (gpp, conglomerate, gnome-genius), but nothing I need for now, so giving up ownership. Bill -- 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: RFC: Old packages remain on the mirrors for one week
Le mercredi 14 août 2013 à 11:26 -0600, Kevin Fenzi a écrit : > I guess I'm open to the idea, but I have long wished we could have some > way to always keep the previous version of a package for yum > downgrades. ;( > > Keeping all that in metadata would bloat it a lot. I think Debian does that by having a special mirror that use date information in the url. See http://snapshot.debian.org/ So http://snapshot.debian.org/yesterday serve the debian set of package as seen yesterday, etc, etc That use some fuse magic, according to a quick check of http://anonscm.debian.org/gitweb/?p=mirror/snapshot.debian.org.git;a=tree ( and it was based on pdumpfs before ) -- Michael Scherer -- 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: BlueZ Status in Fedora.
On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote: > Otherwise we are looking at possibly reforking gnome-bluetooth at this > point in time. Reforking? And then wait until the bitrot sets in again? ;-) Can't you just use gnome-bluetooth proper and resurrect the panel icon stuff like Kalev proposed? Lars -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 01:02:42PM -0400, "Jóhann B. Guðmundsson" wrote: > Well whomever choose to decide that we "support" upgrades in the > first place bypassed the QA community entirely in making that > decision as well as to which tool is "preferred","supported" or > "recommended". If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL] gimp-paint-studio failed to build on el6
Hello, I wonder why the build failed[1] despite assigning a quotation on a doc file listed on: http://pkgs.fedoraproject.org/cgit/gimp-paint-studio.git/tree/gimp-paint-studio.spec?h=el6 Is there a way to fix that? Ref [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=456904 Luya -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, "Jóhann B. Guðmundsson" wrote: Well whomever choose to decide that we "support" upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is "preferred","supported" or "recommended". If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Could you point me to the individual(s) and the discussion to support upgrades in the first place, took place so we in the QA community can finally see who made the decision to open that pandora box and why? It might even reveal why the QA community was excluded from that discussion in the first place... JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 9:02 PM, "Jóhann B. Guðmundsson" wrote: > On 08/15/2013 02:26 PM, Matthew Garrett wrote: >> >> On Thu, Aug 15, 2013 at 01:02:42PM -0400, "Jóhann B. Guðmundsson" wrote: >> >>> Well whomever choose to decide that we "support" upgrades in the >>> first place bypassed the QA community entirely in making that >>> decision as well as to which tool is "preferred","supported" or >>> "recommended". >> >> If QA is testing something other than the supported upgrade mechanism, >> then QA should rectify that. The communication has been very clear - >> if fedup fails to upgrade then that's considered a bug, and if any other >> approach fails then it may not be. > > > > Our release criteria and everything we defined *after* we found out that we > suddenly supported upgrades is solid which is not what I was saying or > referring to. Suddenly? They always have been "supported" that even dates back to the Redhat Linux days ... > Could you point me to the individual(s) and the discussion to support > upgrades in the first place, took place so we in the QA community can > finally see who made the decision to open that pandora box and why? See above. -- 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: [EPEL] gimp-paint-studio failed to build on el6
tor 2013-08-15 klockan 11:57 -0700 skrev Luya Tshimbalanga: > Hello, > I wonder why the build failed[1] despite assigning a quotation on a doc > file listed on: > http://pkgs.fedoraproject.org/cgit/gimp-paint-studio.git/tree/gimp-paint-studio.spec?h=el6 > > Is there a way to fix that? > > Ref > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=456904 > > > Luya Try: %doc License?for?Contents License_gpl-2.0.txt Readme.txt See: http://www.rpm.org/ticket/858 Mattias smime.p7s Description: S/MIME cryptographic 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 12:32 PM, Josh Boyer wrote: > On Wed, Aug 14, 2013 at 12:04 PM, Kevin Fenzi wrote: >> On Tue, 13 Aug 2013 22:41:37 -0700 >> Toshio Kuratomi wrote: >> >>> Additional agenda item: >>> >>> Mattdm, sgallagh, and I were talking about the general fesco sentiment >>> towards mattdm's fedora future direction proposal and the multiple >>> fedora products idea at post-flock breakfast. My understanding is >>> that the sentiment was that it would be a board decision whether to >>> go that route, that fesco would be on charge of implementing it, and >>> that fesco was generally in favour of it. >>> >>> The three of us thought it would be a good idea for fesco to >>> officially vote on whether we can get behind the idea and then send >>> it to the board so that we can start putting some proposals together. >>> >>> (Sorry for top-posting... on my phone.) >> >> Well, or would it be better to have a concrete proposal to take to >> them? >> >> I don't see any harm I guess in fesco deciding that we are in favor in >> general of this plan and ask the Board if we are going down a path they >> don't want us to before writing up concrete proposals. > > Right. Less worrying about what the Board thinks, more worrying about > what FESCo thinks. If those two entities wind up not agreeing, then > we can discuss that. > > As for the Board, I'm hoping to bring up the future direction stuff as > a topic we should at least be paying close attention to in the next > meeting. Having something from FESCo to review would be great too. The Board discussed this today. We agree with the development of a working group to describe an implementation proposal for the future of Fedora, and encourage the involvement of existing desktop, cloud and server contributors in the process. We look forward to reviewing the proposal. Thanks. 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
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:16 PM, drago01 wrote: On Thu, Aug 15, 2013 at 9:02 PM, "Jóhann B. Guðmundsson" wrote: On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, "Jóhann B. Guðmundsson" wrote: Well whomever choose to decide that we "support" upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is "preferred","supported" or "recommended". If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Suddenly? They always have been "supported" that even dates back to the Redhat Linux days ... Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:16 PM, drago01 wrote: On Thu, Aug 15, 2013 at 9:02 PM, "Jóhann B. Guðmundsson" wrote: On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, "Jóhann B. Guðmundsson" wrote: Well whomever choose to decide that we "support" upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is "preferred","supported" or "recommended". If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Suddenly? They always have been "supported" that even dates back to the Redhat Linux days ... I should clarify what I'm talking about is the discussion of "officially" supporting upgrading while you probably mean it has been technically possible which has indeed been available for a long time. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 03:02:37PM -0400, "Jóhann B. Guðmundsson" wrote: > Our release criteria and everything we defined *after* we found out > that we suddenly supported upgrades is solid which is not what I was > saying or referring to. We've always supported upgrades. Before fedup, preupgrade was the supported upgrade mechanism. That's been true as long as I've been involved in Red Hat. > Could you point me to the individual(s) and the discussion to > support upgrades in the first place, took place so we in the QA > community can finally see who made the decision to open that pandora > box and why? Preupgrade was accepted into Fedora 8, so you'd probably need to go back and review the feature discussion from then. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 15:36:53 -0400 "Jóhann B. Guðmundsson" wrote: > Interesting since they did not do that when I joined QA what 5 or 6 > years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Oh, and to clarify - upgrades were supported even before then, but required booting Anaconda from new install media. That's been true since the Red Hat Linux days, so years before Fedora even existed. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 15 August 2013 15:48, Matthew Garrett wrote: > Oh, and to clarify - upgrades were supported even before then, but > required booting Anaconda from new install media. That's been true since > the Red Hat Linux days, so years before Fedora even existed. > > I believe we are arguing over words which have different meanings depending on what each person is talking about. Does supported mean: a) We guarantee that upgrade works always and without problems? b) We guarantee that upgrade code works but may encounter problems if you have done stuff other than a default install/stuff. c) We guarantee that the upgrade code is there, and it should work but you should know what you are doing d) There is some code, we worked on it, you can activate it, but that is all we can say. Each of those has been said of upgrade by various developers over the years (Jeremy Katz would try to get it down to D but Gafton would want it to be b) and every new person on anaconda would say they wanted to get to a someday.) > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Stephen J Smoogen. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:47 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 15:36:53 -0400 "Jóhann B. Guðmundsson" wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. We tested for it to a limited extent ( via yum ) but we never officially supported it. We always stayed away from opening that pandora box and it was not until we found out that someone had stamped upgrades to be "officially" supported that we actually properly defined what should be tested, added the criteria for it and made it release blocking. And the discussion around who "officially" stamped it and why is what I'm looking for ( not that it has been technically possible for number of years ) and I'm pretty sure it was neither Jeremy,Will,Chris or Seth that pushed for that "official upgrade" stamp when they introduced pre-upgrade once they had finish writing it, since all four knew the ramification for us in QA by doing so. I can tell you that fedup blindly inherited the "offically upgrade tool/support" from pre-upgrade by fesco decision, while Will was still scratching his head designing/writing it and Tim being the only one that was properly testing what Will threw over the wall. To many including me that seemed like an odd decision making instead for example simply not "officially" support upgrades ( thus not making it release blocking ) until that tool had been written. JBG -- 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: RFC: Old packages remain on the mirrors for one week
Richard Hughes (hughsi...@gmail.com) said: > On 12 August 2013 19:36, Bill Nottingham wrote: > > I could see doing this, but it is a non-trivial change to how the > > repositories are made, and there aren't really any resources assigned to > > work on that. I can give some pointers to where and what would need changed, > > if you're interested in looking at it. > > Yes please, thanks. Ok. = HOW PACKAGES GET INTO REPOSITORIES = 1. Packages are tagged into a koji tag. For rawhide and some branched trees, this is done directly after build (i.e., tagged into f20). For updates, they are tagged into -updates or -updates-testing by bodhi as part of the push process. 2. 'mash' is called to create a repository. You can find the mash code in fedpkg, or at: https://git.fedorahosted.org/cgit/mash This is done either by bodhi (as part of an updates push), or by a rawhide/branched compose script. 3. The created repository is then rsynced to the mirror master. 4. The mirrors then sync it from there. = HOW MASH CREATES THE REPOSITORY = 1. Calls into koji to get a list of all packages built for a tag (such as 'f20' or 'f19-updates') 2. Sorts them by architecture, noarch, whether they're signed, etc. 3. Downloads them into a directory. Runs createrepo (via python API). 4. Solves the repositories for multilib. Removes packages not wanted as multilib. Runs 'createrepo --update' (via python API). ... From the above, you'll note that the repository, whether it's rawhide, updates, or something else, is created fresh every time. So, it's initially incompatible with your proposal. Potential solutions, off the top of my head: 1) Change mash to optionally keep more than one version of a package. When mash talks to koji to get packages in a tag (via session.listTaggedRPMS), it passes a boolean flag to either grab the latest package (the default) or all packages. It could be possible to allow this to be a number, on the mash side, whereby mash would retrieve info on *all* tagged RPMs from koji, and only keep/download the last N. Pros: doesn't require changing any other tools Drawbacks: makes the mash process slow, if you're sorting tens of thousands of builds to limit it to the last few versions. Would require a bit of extra code to keep the same concept of latest (last tagged in, *not* newest NVR) that koji does. Where to look: mash/__init__.py:doCompose(), ~line 290-300. 2) Don't just rsync the mashed repository over, but change it to merge in the old packages Drawbacks: kind of ugly to do. Involves copying lots of data around. Where to look: Would require changing the buildrawhide/buildbranched scripts from: https://git.fedorahosted.org/cgit/releng/tree/ to do the merge before rsyncing into place, when considering rawhide/branched trees. For updates, likely involves changing code in bodhi itself. 3) When rsyncing repositories over, run the rsync without delete, and have a different script do cleanup later. Pros: simpler than #2 Drawbacks: requires writing a new scheduled task to clean old cruft out of the repo Where to look: Changing the same places as #2 - buildrawhide/buildbranched, and bodhi. There are almost certainly more radical ideas out there as well for how to do this. Feel free to holler if you have more questions. Bill -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 22:12, schrieb Jóhann B. Guðmundsson: > On 08/15/2013 03:47 PM, Kevin Fenzi wrote: >> On Thu, 15 Aug 2013 15:36:53 -0400 >> "Jóhann B. Guðmundsson" wrote: >> >>> Interesting since they did not do that when I joined QA what 5 or 6 >>> years ago so again can you refer me to that discussion. >> It's always been a test case/critera that I remember... >> >> http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 >> >> Shows upgrade test cases were there in Fedora 7 and one of the things QA >> was testing and ensuring. > > We tested for it to a limited extent ( via yum ) but we never officially > supported it. > > We always stayed away from opening that pandora box and it was not until we > found out that someone had stamped > upgrades to be "officially" supported that we actually properly defined what > should be tested, added the criteria > for it and made it release blocking honestly: if dist-upgrade swould not work *nobody* would use Fedora for anything relevant Fedora would be *completly* meaningless from this moment on why? because nobody has the time and effort to install from scratch twice a year if he does more with his computer than click on the icons of the default screen after login this is not only the point for Fedora *any* relevant software which would only work a few months would become meaningsless expect for people which are bored and play around just for fun with no goal 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
Bundled Flash
It's come to my attention that a number of packages contain Flash (.swf) files, but absolutely none of them have BuildRequires on a free software Flash toolchain, nor do any of them seem to be shipping the source for these files. :-( It has never been permissible to included prebuilt files of this nature in Fedora [1], and FPC unequivocally stated during today's meeting that they have no interest in making an exception for this. Please remove this prohibited content from your packages, or ensure that any included .swf files are built from source using a free software toolchain like `swfc` during the %build phase. A list of affected packages sorted by owner is included below, and I'll be filing bugs for these soon. -T.C. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries brummbq owncloud echevemaster python-django-ckeditor hicham gnash iarnell mojomojo itamarjp bugzilla jdetaeye frepple jnovy texlive jsteffan graphite-web ke4qqq php-simplepie lbazan django-typepad limb gallery2 limb moodle limb roundcubemail miminar wt mkrizek yourls ngompa tinymce orion ckeditor remi glpi remi php-ezc-Graph remi wordpress robert phpMyAdmin salimma hop sharkcz wxPython sharkcz zabbix sundaram evas-generic-loaders sundaram lastuser thias python-nevow topdog dojo toshio loggerhead toshio python-docutils yuwang python-django-tinymce -- 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: Bundled Flash
On 08/15/2013 02:45 PM, T.C. Hollingsworth wrote: It's come to my attention that a number of packages contain Flash (.swf) files, but absolutely none of them have BuildRequires on a free software Flash toolchain, nor do any of them seem to be shipping the source for these files. :-( It has never been permissible to included prebuilt files of this nature in Fedora [1], and FPC unequivocally stated during today's meeting that they have no interest in making an exception for this. Please remove this prohibited content from your packages, or ensure that any included .swf files are built from source using a free software toolchain like `swfc` during the %build phase. A list of affected packages sorted by owner is included below, and I'll be filing bugs for these soon. -T.C. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries orion ckeditor Thanks. Turns out ckeditor also had a raw .fla file. I don't know if any package would have a .fla without a .swf, but it might be worth checking for. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 16:12:48 -0400 "Jóhann B. Guðmundsson" wrote: > On 08/15/2013 03:47 PM, Kevin Fenzi wrote: > > On Thu, 15 Aug 2013 15:36:53 -0400 > > "Jóhann B. Guðmundsson" wrote: > > > >> Interesting since they did not do that when I joined QA what 5 or 6 > >> years ago so again can you refer me to that discussion. > > It's always been a test case/critera that I remember... > > > > http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 > > > > Shows upgrade test cases were there in Fedora 7 and one of the > > things QA was testing and ensuring. > > We tested for it to a limited extent ( via yum ) but we never > officially supported it. Thats not my recollection... upgrades via DVD media were always mentioned as "supported" and were tested by QA. Perhaps someone who was around inside Red Hat in the Fedora Core days could comment, but I remember Fedora pretty much carrying on with that in F7. Anyhow, we are getting far afield. if there's a desire change user expectations, we could discuss doing that. I think we will have to see what the proposal looks like and what upgrades and methods would make sense. kevin signature.asc Description: PGP 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: RFC: Old packages remain on the mirrors for one week
On Wed, 14 Aug 2013 18:22:34 -0500 Michael Cronenworth wrote: > On 08/14/2013 12:26 PM, Kevin Fenzi wrote: > > I guess I'm open to the idea, but I have long wished we could have > > some way to always keep the previous version of a package for yum > > downgrades. ;( > > > > Keeping all that in metadata would bloat it a lot. > > You could have an additional metadata package that contained these > packages. It would only be downloaded/used when "yum downgrade" or > "yum install foo-$oldversion" is called. That sounds like it would be a lot of duplication in mirrormanager and other parts of the project. ;) kevin signature.asc Description: PGP 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
Introduction
Per request at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join I would like to introduce myself. Who am I? Brian Schonecker, RHCE and complete novice at building packages? What will I contribute? I have access to an IBM mainframe s390x and am running Red Hat s390x kernel on zLinux. I would like to create a new repository for s390x packages. I see that there are CentOS, Red Hat of 32 and 64 bit architectures. I think that there must be someone out there that would appreciate binary RPMs available from a Yum repository for the Z series mainframe. I'm not sure exactly how to start. I certainly won't maintain the source or the SPEC files as all I've done so far is just build the binary RPMs from source. I'm looking to build the binary RPMs and then upload them for the world to enjoy. Any help from veterans or novices would be appreciated. Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review: Ticket #47465 problem with 389-adminutil detection in m4/adminutil.m4
https://fedorahosted.org/389/attachment/ticket/47465/0003-Ticket-47465-problem-with-389-adminutil-detection-in.patch https://fedorahosted.org/389/attachment/ticket/47465/0001-Ticket-47465-problem-with-389-adminutil-detection-in.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: RFC: Old packages remain on the mirrors for one week
On Thu, 15 Aug 2013 15:15:11 -0600 Kevin Fenzi wrote: > That sounds like it would be a lot of duplication in mirrormanager > and other parts of the project. ;) > > kevin Why not do it's on the users PC\Laptop. (As a change\feature?) /etc/yum.repos.d/updates.repo (ditto testing if enabled) keepcache=1 cron.weekly repomanage --keep=2 /path/to/cache default on rawhide.repo -- Regards, Frank "When in doubt PANIC!" I check for new mail app. 20min www.frankly3d.com -- 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: BlueZ Status in Fedora.
On Thu, Aug 15, 2013 at 10:55 AM, Lars Seipel wrote: > On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote: >> Otherwise we are looking at possibly reforking gnome-bluetooth at this >> point in time. > > Reforking? And then wait until the bitrot sets in again? ;-) > > Can't you just use gnome-bluetooth proper and resurrect the panel icon > stuff like Kalev proposed? Not so simple as reverting a commit. Must discuss with upstream. Dan -- 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: BlueZ Status in Fedora.
On Thu, Aug 15, 2013 at 3:04 PM, Dan Mashal wrote: > On Thu, Aug 15, 2013 at 10:55 AM, Lars Seipel wrote: >> On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote: >>> Otherwise we are looking at possibly reforking gnome-bluetooth at this >>> point in time. >> >> Reforking? And then wait until the bitrot sets in again? ;-) >> >> Can't you just use gnome-bluetooth proper and resurrect the panel icon >> stuff like Kalev proposed? > > Not so simple as reverting a commit. Must discuss with upstream. > > Dan Also as Wolfgang (comaintainer for MATE) said and I personally would like to reiterate: "3. Also runtime dependencies needs to be checked, we don't want to be install more gnome as necessary in mate." The whole point of forking to be dependant on gnome upstream as little as possible. Dan -- 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: [EPEL] gimp-paint-studio failed to build on el6
On 15/08/13 12:28 PM, Mattias Ellert wrote: Try: %doc License?for?Contents License_gpl-2.0.txt Readme.txt See: http://www.rpm.org/ticket/858 Mattias Thank you Mattias, your suggestion worked. http://koji.fedoraproject.org/koji/buildinfo?buildID=456936 Luya -- 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: [dnf] dnf-0.3.11
On 14.08.2013 14:05, Ales Kozumplik wrote: > On 08/14/2013 11:46 AM, poma wrote: >> Summ. >> yum - kernel-PAE-modules-extra - Installing - OK >> dnf - kernel-PAE-modules-extra - Upgrading - ? >> >> >> poma > > Hi, > > this looks like a new bug related to Yum's installonly feature which is > still a bit problematic in DNF, for instance see [1]. > > Please open a bugzilla for this. > > Thank you, > Ales > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=880524 Thanks for the replay. rhbz 997658. poma -- 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: Bundled Flash
On Thu, Aug 15, 2013 at 2:02 PM, Orion Poplawski wrote: > Thanks. Turns out ckeditor also had a raw .fla file. I don't know if any > package would have a .fla without a .swf, but it might be worth checking > for. Thanks for pointing that out! .fla files are source files, so it's not strictly against the guidelines to include them. But, they're pretty useless to end users. ;-) So, here's the list of packages that contain .fla files: brummbq owncloud echevemaster python-django-ckeditor ke4qqq php-simplepie limb gallery3 orion ckeditor sundaram evas-generic-loaders topdog dojo -T.C. -- 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: Bundled Flash
On Thu, Aug 15, 2013 at 3:38 PM, T.C. Hollingsworth wrote: > On Thu, Aug 15, 2013 at 2:02 PM, Orion Poplawski wrote: >> Thanks. Turns out ckeditor also had a raw .fla file. I don't know if any >> package would have a .fla without a .swf, but it might be worth checking >> for. > > Thanks for pointing that out! > > .fla files are source files, so it's not strictly against the guidelines to > include them. But, they're pretty useless to end users. ;-) > > So, here's the list of packages that contain .fla files: > > brummbq owncloud > echevemaster python-django-ckeditor > ke4qqq php-simplepie > limb gallery3 > orion ckeditor > sundaram evas-generic-loaders > topdog dojo > > -T.C. Forgive me if I sound rude and correct me if I'm wrong, but arent the free versions of Flash pretty useless as well? Dan -- 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: Bundled Flash
On Thu, 15 Aug 2013 15:46:36 -0700 Dan Mashal wrote: > On Thu, Aug 15, 2013 at 3:38 PM, T.C. Hollingsworth > wrote: > > On Thu, Aug 15, 2013 at 2:02 PM, Orion Poplawski > > wrote: > >> Thanks. Turns out ckeditor also had a raw .fla file. I don't > >> know if any package would have a .fla without a .swf, but it might > >> be worth checking for. > > > > Thanks for pointing that out! > > > > .fla files are source files, so it's not strictly against the > > guidelines to include them. But, they're pretty useless to end > > users. ;-) > > > > So, here's the list of packages that contain .fla files: > > > > brummbq owncloud > > echevemaster python-django-ckeditor > > ke4qqq php-simplepie > > limb gallery3 > > orion ckeditor > > sundaram evas-generic-loaders > > topdog dojo > > > > -T.C. > > Forgive me if I sound rude and correct me if I'm wrong, but arent the > free versions of Flash pretty useless as well? > > Dan Yes they are. Flash is slowly dying though, only to be replaced by DRM in html5. Out of the frying pan... Ananda -- 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: Bundled Flash
On Thu, Aug 15, 2013 at 3:49 PM, Ananda Samaddar wrote: > On Thu, 15 Aug 2013 15:46:36 -0700 > Yes they are. Flash is slowly dying though, only to be replaced by DRM > in html5. Out of the frying pan... > > Ananda > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Adobe flash and Google Chrome flash still work, looking at your domain name makes me wonder.. does Opera bundle flash a la Chrome on Linux? Dan -- 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: Orphaned: libgnomecups
On Thu, Aug 15, 2013 at 6:39 PM, Bill Nottingham wrote: > Underlying dep of libgnomeprint22/libgnomeprintui22, which is used by a few > end-user things (gpp, conglomerate, gnome-genius), but nothing I need for > now, so giving up ownership. Isn't it just time we killed the old gnome printing infra once and for all? It was marked EOL years ago that the packages if they're remotely actively maintained should have migrated by now. Peter -- 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: Bundled Flash
On Thu, Aug 15, 2013 at 3:46 PM, Dan Mashal wrote: > Forgive me if I sound rude and correct me if I'm wrong, but arent the > free versions of Flash pretty useless as well? We're talking about SWF compilers here, not players. There are free compiler tools that work just fine for certain applications. -T.C. -- 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 of packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Jima has not been able to make enough time for Fedora lately and asked me to orphan and announce the packages he maintains. alsa-oss aoetools banner bwm-ng clusterssh conserver graphviz libdnet libstatgrab miau ngrep perl-X11-Protocol rblcheck scanssh vblade feel free to pick them up Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlINqGoACgkQkSxm47BaWffvnwCeON8fhdQ2m7gO1oUMXy6GiF3B 5LEAoMGWAeAHgit/h2YU2NrkPX98RYKm =EFde -END PGP 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: RFC: Old packages remain on the mirrors for one week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Aug 2013 14:47:03 +0100 Richard Hughes wrote: > Hi all, > > I'd like to ask for comments on a feature I need for the Fedora > Application Installer. The current yum backend in PackageKit does > something like this: > > * yum install foo > * depsolve transaction using cached metadata > * download foo-0.1.noarch.rpm > * error! foo-0.1.noarch.rpm doesn't exist > * download latest repomd, primary > * re-depsolve > * download latest filelists > * continue to re-depsolve > * download foo-0.2.noarch.rpm > * install foo using librpm > > Now, we do this as the metadata is cached on the client side for up to > a week as we don't want to unconditionally update the metadata for > every transaction, but we don't know if we can download the package > without downloading all the metadata beforehand. This is incompatible > with the swish UX in the application installer where we can search for > things straight away without having "Downloading..." in the UI > appearing at odd times. So my proposal is thus: > > 1. We retain old packages on the mirrors for a minimum of 7 days. without completely rewriting how we compose the trees this is not a possibility. > 2. We regenerate the metadata on every compose like before > 3. We only include the latest package version in the metadata this would need the tools to be completely rewritten also. > 4. If the user is installing an "old" package we check if the new > package is a security or important update and re-download all metadata > if so this means downloading all the metadata > Point 3 means that the metadata size does not explode, and CLI tools > like yum don't spend minutes depsolving a much larger set of packages. > Although this increases the amount of space required on the mirrors > (by about 15% for fedora-19 by my approximation), the amount of > bandwidth saved is huge. By my calculations, over the last 7 weeks > [with ~10 offline updates, and hundreds of 'yum' commands] over 60% of > my traffic from the mirrors is metadata! > > FWIW; 1,2,3 is what Debian and Ubuntu do. Comments welcome, thanks. > > Richard with the schedules as they have been I really dont know when Id get any time to work on the tooling for composing. certainly not before Fedora 21 likely later than that. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlINry4ACgkQkSxm47BaWffHQACfQizrrtfRi+qX4+wBK6lQyUQh jMoAniirXFSRfkcgc63o0TIzISSBrtQI =s6rn -END PGP 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
evolution-data-server soname version bump for libedata-book/libedata-cal next week (3.9.90 release)
Hi, there will be a soname version bump in evolution-data-server update 3.9.90 the next week, namely for libedata-book and libedata-cal libraries. Affected might be evolution-mapi and evolution-ews, which are updated together with it anyway. If there will be more, and I have commit access to them, then I rebuild them as well. Bye, Milan -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 15. 8. 2013 at 09:37:57, Kevin Fenzi wrote: > On Thu, 15 Aug 2013 17:32:27 +0200 > > Reindl Harald wrote: > > what does *not* matter in case of "yum distro-sync" because it does > > also downgrades and if fedup has a problem with it the people who say > > yum is not officially supported (while no support in any case exists) > > should ask theirself who in the world needs fedup instead keep > > fous on *one* well working tool > > > > besides the fact that yum-upgrades are most times better > > yum is used and tested every single day from thousands > > of users while "fedup" no normal user touchs half a year > > You misunderstand how fedup works. > > It gathers up the packages you will need to do the upgrade, then > reboots into a very minimal env and uses yum to do the upgrade. Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 -- snip -- > However, fedup is more safe since it's not happening on a running > system. Based on the number of bugzillas that come to our team about broken system after fedup upgrade, I'm not so sure. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
