Re: More gcc 5 issues - calling C++ from C
On 02/17/2015 03:48 PM, Orion Poplawski wrote: I'm starting to see a segfault in the plplot tests building on F23. I see that the C code is calling some C++ code in this case. This has worked before for a long time so I'm wondering what has changed it this regard. valgrind reports: 11: ==28186== Invalid read of size 8 11: ==28186==at 0x73079DC: operator (ostream:132) 11: ==28186==by 0x73079DC: operator std::ios_base (*)(std::ios_base) (LASi.h:121) It appears that recompiling the lasi package which this uses has cleared this up. Looks like more C++ ABI issues. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to install Rawhide?
On Tue, 17 Feb 2015 20:28:09 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Tue, 17 Feb 2015 09:55:37 -0700, Kevin Fenzi wrote: 1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? Strange. The mirrormanager mirrorlist for images looks good here, and the images look fine. Ah... it's because they are not signed. | Downloading failed: couldn't get boot images: No more mirrors to try. | Last error was: [Errno 14] HTTP Error 404 - Not Found Re-run with --nogpgcheck? D'oh! That seems to lead to something. A Fedora-specific tool could really know about rawhide and tell about --nogpgcheck being needed. fedup could emit a better error here. https://bugzilla.redhat.com/show_bug.cgi?id=1193599 Brand-new ticket, yes, that seems to be the issue. Yes, I filed it when I was looking at this. :) One can never be sure due to mirror servers that may or may not carry the stuff that's needed. It's in mirrormanager, so it gets a metalink of mirrors that claim to have that content. 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images Which wiki page? which 'app' ? https://fedoraproject.org/wiki/Releases/Rawhide/de - English (because the translation could be out-of-date, it doesn't mention fedup at all, and the links to koji aren't fast either when showing the list of images to download - a slow koji query!) Yeah, we should mention fedup and we should also mention adams new 'fedfind' tool. kevin pgpmaYRhW7KiU.pgp 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: Advice on naming a new library package - libunicode or courier-unicode?
On Mon, Feb 09, 2015 at 10:17:12AM -0800, Brian C. Lane wrote: I'm trying to get the new version of maildrop ready and they split out unicode support into a new library. The name of their archive is courier-unicode, but the actual name of the library installed is libunicode. That's what I picked after looking at a few other libs. I don't see any specific naming guidelines on this and I can see it going either way. package review can bee seen here: https://bugzilla.redhat.com/show_bug.cgi?id=1186964 Thanks for the feedback, updated with it renamed to courier-unicode. Note that maildrop depends on this, so if we want to see the recent version in F22 it could use a review. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More gcc 5 issues - calling C++ from C
I'm starting to see a segfault in the plplot tests building on F23. I see that the C code is calling some C++ code in this case. This has worked before for a long time so I'm wondering what has changed it this regard. valgrind reports: 11: ==28186== Invalid read of size 8 11: ==28186==at 0x73079DC: operator (ostream:132) 11: ==28186==by 0x73079DC: operator std::ios_base (*)(std::ios_base) (LASi.h:121) 11: ==28186==by 0x73079DC: ps_init(PLStream*) (psttf.cc:239) 11: ==28186==by 0x4E52F78: plP_init (plcore.c:144) 11: ==28186==by 0x4E5773B: c_plinit (plcore.c:2268) 11: ==28186==by 0x4009D9: main (x00c.c:44) 11: ==28186== Address 0xffe8 is not stack'd, malloc'd or (recently) free'd 11: ==28186== 11: ==28186== 11: ==28186== Process terminating with default action of signal 11 (SIGSEGV) 11: ==28186== Access not within mapped region at address 0xFFE8 11: ==28186==at 0x73079DC: operator (ostream:132) 11: ==28186==by 0x73079DC: operator std::ios_base (*)(std::ios_base) (LASi.h:121) 11: ==28186==by 0x73079DC: ps_init(PLStream*) (psttf.cc:239) 11: ==28186==by 0x4E52F78: plP_init (plcore.c:144) 11: ==28186==by 0x4E5773B: c_plinit (plcore.c:2268) 11: ==28186==by 0x4009D9: main (x00c.c:44) Program received signal SIGSEGV, Segmentation fault. ps_init (pls=0x77dcf600 pls0) at /builddir/build/BUILD/plplot-5.10.0-git/drivers/psttf.cc:239 239 doc-osBody() fixed; Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-14.fc22.x86_64 expat-2.1.0-10.fc22.x86_64 fontconfig-2.11.92-1.fc22.x86_64 freetype-2.5.5-1.fc22.x86_64 glib2-2.43.4-1.fc23.x86_64 graphite2-1.2.4-3.fc22.x86_64 harfbuzz-0.9.38-3.fc22.x86_64 lasi-1.1.2-2.fc22.x86_64 libffi-3.1-7.fc22.x86_64 libgcc-5.0.0-0.14.fc23.x86_64 libpng-1.6.16-1.fc22.x86_64 libstdc++-5.0.0-0.14.fc23.x86_64 libtool-ltdl-2.4.6-1.fc23.x86_64 pango-1.36.8-2.fc22.x86_64 qhull-2003.1-25.fc22.x86_64 shapelib-1.3.0f-5.fc22.x86_64 zlib-1.2.8-7.fc22.x86_64 (gdb) bt #0 0x75b039dc in ps_init(PLStream*) (pls=0x77dcf600 pls0) at /builddir/build/BUILD/plplot-5.10.0-git/drivers/psttf.cc:239 #1 0x77b88f79 in plP_init () at /builddir/build/BUILD/plplot-5.10.0-git/src/plcore.c:144 #2 0x77b8d73c in c_plinit () at /builddir/build/BUILD/plplot-5.10.0-git/src/plcore.c:2268 #3 0x004009da in main (argc=1, argv=optimized out) at /builddir/build/BUILD/plplot-5.10.0-git/examples/c/x00c.c:44 (gdb) print doc $1 = optimized out (gdb) print fixed No symbol fixed in current context. (gdb) list 234 if ( pls-psdoc != NULL ) 235 delete (PostscriptDocument *) pls-psdoc; 236 237 pls-psdoc = new PostscriptDocument(); 238 doc= (PostscriptDocument *) ( pls-psdoc ); 239 doc-osBody() fixed; 240 doc-osBody().precision( 3 ); 241 242 // Allocate and initialize device-specific data 243 (gdb) print pls $2 = (PLStream *) 0x77dcf600 pls0 (gdb) print pls-psdoc $3 = (void *) 0x62a930 (gdb) print fixed No symbol fixed in current context. -- 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: whatever happened to yum + btrfs snapshotting?
On Tue, Feb 17, 2015 at 2:40 PM, Matěj Cepl mc...@cepl.eu wrote: On 2015-02-17, 13:17 GMT, Josh Boyer wrote: Now, it is possible to do this in dnf (either with btrfs or with dm snapshots) but I'm not aware of anyone working on it. Fedora has the Snapper tool available in the repos, which could do snapshotting outside of dnf as well. Yeah, just that I was told by people who should know that snapper was mainly developed by SUSE people so it is quite leaning towards BTRFS. Support of DM-thinp snapshots is there, but its quality is really not perfect. Getting thin pool and volumes configured correctly for the many snapshots that snapper produces is non-obvious and non-trivial. If you don't do that correctly from the start, and near as I can tell the installer doesn't configure it for snapshots, even a handful of snapshots and writing into them will blow up the entire thin pool and all LV's on it. There's no hand holding and it's not fail safe. There are some btrfs multiple device gotchas (with device failures, removal and replace) that are equally non-obvious and non-trivial. But it's a neck deep swimming pool vs being thrown into the LVM thinp ocean with giant waves. Btrfs snapshots are deceptively fast and safe. Many snapshots or snapshots involving large files, can easily result in significant underestimates of how much free space remains due to the passive deduplication they imply. And that turns into logistical problems for backing up and restoring, even with btrfs send/receive, that are non-obvious and non-trivial. Many snapshots also confuses the installer, for example: https://bugzilla.redhat.com/show_bug.cgi?id=1185117 And that's with less than a day of life for a new openSUSE default installation. Anyway, snapshot buyers beware! I feel any future discussion of Btrfs by default needs an exception to the usual way of doing changes: change is proposed and implemented weeks before a branch. Instead, Btrfs should get months of Rawhide testing before branch, by becoming default in Rawhide only sooner than later. And this can explicitly acknowledge it being a non-committing change for Fedora 23. This is less abrupt of a change and more fail safe. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
PHP webapp configuration (apache / nginx / php)
Hi, Lot of webapp in fedora repository requires httpd + mod_php Reminder: since Fedora 21 we have now 3 working (out-of-the-box) way to have a webserver with php enabled: - apache + mod_php (the trivial way, but not the best for perf) - apache + php-fpm (using network socket of UDS since F22) - nginx + php-fpm You can check some already adapted applications: - phpMyAdmin - GLPI - roundcubmail (version 1.1.0, freshly build) Please check if the webapp you own can be adapted. If you provide a httpd configuration file, you just have to requires httpd-filesystem (for dir ownership) If you provide a nginx configuration file, you just have to requires nginx-filesystem (for dir ownership) And of course, webserver + php(httpd) Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nonresponsive maintainer - Axel Thimm
I'm continuing the nonresponsive maintainer process for Axel Thimm https://bugzilla.redhat.com/show_bug.cgi?id=1186467 Axel, your last login in FAS was on 2013-08-30 (according to fedora_active_user.py) and your last official build in koji was on 2011-05-09 (http://koji.fedoraproject.org/koji/userinfo?userID=200). There are outstanding issues in some of your packages: * freenx-server = https://apps.fedoraproject.org/packages/freenx-server/bugs * greylistd is out of date (we ship 0.8.7, debian 0.8.8.3: https://packages.debian.org/unstable/mail/greylistd) vtkdata in rawhide, f21, f20 can only be built by either you (athimm) or provenpackagers: https://admin.fedoraproject.org/pkgdb/package/vtkdata/ Please fix at least the access rights in pkgdb for vtk/vtkdata and, if you are unavailable, please edit the vacation calendar: https://apps.fedoraproject.org/calendar/list/vacation/ I've been effectively maintaining a number of Axel's packages for years now. Time to get them properly owned. - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Proposal] Ring-based Packaging Policies
On 2015-02-17, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher sgall...@redhat.com wrote: == Proposal == With these things in mind, I'd like to propose that we amend the packaging policy by splitting it into two forms: I think this needs to go beyond simple policy. It needs some buildsystem enforcement as well. [...] With the definition you have here, I'm afraid we are going to be constantly playing is or isn't on whether a package is core or not. E.g. things get sucked into the install media due to dependencies and nobody notices until it's time to trim the size. It just doesn't seem like this would scale, particularly since the distro is rather fluid. Perhaps instead the Base WG could come up with what they consider core, and we could really stick to that? Meaning, things in core cannot Require packages outside of core at runtime. [...] I'm OK with this if Ring packages land in a separated repo. That could be done by having a separate koji target that spits out things into a rings repo. My concern here is that if everything (ring and core combined) lands in the same koji tag and goes through koji just like packages do today, we're going to wind up with a big mess. Having dependencies on ring packages is going to entangle things and make it very hard to clean up later. I agree. While it's tempting to just tune policy a little (i.e. reduce packaging guidelines), it's not enough. The implications are huge (from security, suistainability, trust point of view). My impression from reading this thread is people do not want mixed system. Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? If the repository was fully supported by Fedora project (package databse, dist-git, koji, bodhi, bugzilla) with yum/dnf configuration knowing the easy-for-beginners repository, then both groups (deniers and supporters of the mixed system) would be satisfied. After some time, we can evaluate if the easy-for-beginners repository is a viable solution (from all the points of view I listed above). If the reduced policy is really the golden solution, then we will witness spontaneous move of packages from Fedora to easy-for-beginners repository. -- Petr -- 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: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Changes Completion deadline in one week - 2015-02-24
Greetings! Fedora 22 Change Checkpoint: Completion deadline (testable) is in one week - 2015-02-24 [1] and we're getting closer to this date. Other important milestones are scheduled for this date: * Alpha Freeze * Software String Freeze * Bodhi activation point At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Fedora 22 is strictly time based release and we want to adhere to the schedule. Incomplete and non testable Changes will be reported to FESCo for 2015-02-25 meeting. Contingency plan for System Wide Changes, if planned for Alpha (or in case of serious doubts regarding Change completion), will be activated. [1] https://fedoraproject.org/wiki/Releases/22/Schedule Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. Is this an official statement or is there a discussion going on somewhere? Pierre -- 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: [Proposal] Ring-based Packaging Policies
On Wed, Feb 18, 2015 at 12:54:24AM +0800, Mathieu Bridon wrote: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. The comparison isn't really valid, the difference between the two repos is not technical but more based on the license/re-distribution rights. While, what has been mentioned before would be two repos having the same redistribution policy but two different technical requirements. Pierre -- 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: [Proposal] Ring-based Packaging Policies
Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. The only difference in both repositories is the license of the software. The package guidelines are exactly the same as Fedora's (with the exception of kernel modules) in both repos. At another scale, it seems to not be working too badly already for Fedora+RPMFusion, where Fedora and RPMFusion have different standards for inclusion, and where packages in RPMFusion can depend on packages in Fedora, but not the other way. The standard for inclusion in rpmfusion is not being elegible to be in Fedora. Again, the reasons are purelly legal (with the exception of kernel modules). Again, there is no difference in the guidelines (bundled libraries must be unblundled, etc) -- 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: [Proposal] Ring-based Packaging Policies
Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. At another scale, it seems to not be working too badly already for Fedora+RPMFusion, where Fedora and RPMFusion have different standards for inclusion, and where packages in RPMFusion can depend on packages in Fedora, but not the other way. If I understand correctly, Ubuntu has a similar setup with main and universe, and so does Debian with main, contrib and nonfree. History doesn't seem to unambiguously prove what you think it does, but then I guess you can always argue that those examples just haven't failed yet. ;) -- Mathieu -- 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: How to install Rawhide?
On Tue, 17 Feb 2015 17:02:32 +0100 Michael Schwendt mschwe...@gmail.com wrote: 1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? Strange. The mirrormanager mirrorlist for images looks good here, and the images look fine. Ah... it's because they are not signed. Re-run with --nogpgcheck? fedup could emit a better error here. https://bugzilla.redhat.com/show_bug.cgi?id=1193599 2. yum distro-sync with rawhide repo enabled : first encountered upgrade path violation problems, unresolved deps. Then after enabling only the rawhide repo, it locked up hard after updating ~900 packages. This sounds like the lovely dbus bug: https://bugzilla.redhat.com/show_bug.cgi?id=1186018 There's some manual workarounds with killing dbus, etc 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images Which wiki page? which 'app' ? to download. Which one to take? No idea. Fedora-Live-Workstation-x86_64-22-20150216.iso crashes early with a Python traceback failing to import storage-something. That seems to be new today. I don't have a bug handy. So, where is the safe guide on how to install (or upgrade to) Rawhide any day? Impossible? It would sure be nice to keep track of the known installable ones. kevin pgp6RQ3hTqKbQ.pgp 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:54 PM, Mathieu Bridon wrote: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. RPMFusion working fine? Sorry, but I vehemently disagree with this. Many of their packages are of low quality and their infrastructure is more dead than alive. History doesn't seem to unambiguously prove what you think it does, but then I guess you can always argue that those examples just haven't failed yet. ;) I am referring to RHL + Powertools (?) (A historic desaster) and many of these distro life cycle extending attempts (RHL had one I don't even recall the name; Recently SuSE's Everlast went down). 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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 10:21:47AM -0500, Josh Boyer wrote: I may have misunderstood the conversation I'm remembering. Apologies for any confusion. The main issue is that we as a project can't take any money, even if Google really wants to send it somewhere. I don't think there's a problem as long as I think someone needs to step up as the main coordinator for Fedora and work with OSAS to make sure this is set. ... that. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration 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: Orphaning and seeking comaintainers of some packages
On 02/17/2015 02:19 AM, Christopher Meng wrote: Hi, There are some packages I don't use anymore, feel free to take them: libntlm python-durus barry spambayes rblcheck tokyocabinet jaxodraw flterm libquvi libquvi-scripts quvi python-django-socialregistration dayplanner gengetopt code2html elementary-icon-theme drehatlas-widelands-fonts pycryptopp drehatlas-xaporho-fonts qdevelop kawa perl-BDB txt2rss scanssh mimetex perl-Date-HolidayParser perl-Email-Find python-pymtp(epel7) These below are packages I seldom use, feel free to comaintain them: NetPIPE PyMca roxterm autoconf-archive freetalk unhide firehol npth exaile flickcurl jwm elektra dmenu profile-sync-daemon python-eyed3 oyranos Thanks. I think cicku took python-pymtp on Jan 27. https://lists.fedoraproject.org/pipermail/devel/2014-January/194744.html -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to install Rawhide?
1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? 2. yum distro-sync with rawhide repo enabled : first encountered upgrade path violation problems, unresolved deps. Then after enabling only the rawhide repo, it locked up hard after updating ~900 packages. 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images to download. Which one to take? No idea. Fedora-Live-Workstation-x86_64-22-20150216.iso crashes early with a Python traceback failing to import storage-something. So, where is the safe guide on how to install (or upgrade to) Rawhide any day? Impossible? -- 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: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, Feb 17, 2015 at 11:07:37AM -0500, Matthew Miller wrote: On Tue, Feb 17, 2015 at 04:02:35PM +0530, Sumit Bhardwaj wrote: Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. I was under impression Fedora about community and friendship. Not about control. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- 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: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, Feb 17, 2015 at 04:02:35PM +0530, Sumit Bhardwaj wrote: Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, Feb 17, 2015 at 05:12:35PM +0100, Tomasz Torcz wrote: Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. I was under impression Fedora about community and friendship. Not about control. I didn't mean control in some sort of fascist sense. Simply that often posts are not related to the Fedora community at all, and we really _didn't_ want to be draconian about locking that down. We're not shutting down the planet aggregator, and if you prefer it as a start page, http://planet.fedoraproject.org/ is still a a thing. If there's general consensus that people really prefer it on the default start page, we can revisit that for the next design. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, Feb 17, 2015 at 11:07:37AM -0500, Matthew Miller wrote: Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. After some coffee, I should add some more explanation. Fedora has many times more users than developers, and the start page should primarily appeal to that wider audience. Most of the content on the planet — even that which is properly Fedora-related — is pretty highly tilted towards the geekier contributor side. There's nothing wrong with that, but it can be overwhelming. So, the goal with the Magazine is to be more user-focused (although there's still a lot of contributor-focused stuff mixed in as well; we're still working on the balance). If you're deeply involved and want the firehose, http://planet.fedoraproject.org is there. If *you'd* like to contribute user-focused content (even reposting from your blog, or whatever), see https://ask.fedoraproject.org/en/question/52782/how-do-i-contribute-to-fedora-magazine/?answer=52786#post-id-52786 There's also value in having users aware of the wider community and drawing them in, so, again... we're working out the balance, and everyone's help figuring that out is welcome. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: whatever happened to yum + btrfs snapshotting?
Josh Boyer wrote: On Tue, Feb 17, 2015 at 7:53 AM, Neal Becker ndbeck...@gmail.com wrote: Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. Well, yum is being retired in favor of dnf and btrfs still isn't the default filesystem because it still isn't stable enough. So that's basically what happened. Now, it is possible to do this in dnf (either with btrfs or with dm snapshots) but I'm not aware of anyone working on it. Fedora has the Snapper tool available in the repos, which could do snapshotting outside of dnf as well. josh My recollection was that snapshots on btrfs worked, but it was difficult to really do the rollback because the snapshots were stored inside the root as a subtree, or something to this effect - and that to work nicely the original btrfs install needed to be done differently? -- -- Those who don't understand recursion are doomed to repeat it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 9:36 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. Is this an official statement or is there a discussion going on somewhere? No, it isn't official. I've heard a few comments to that effect over the past few weeks, but I'm not aware of any on-list discussion. Let's see if Matt has details or confirmation. 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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 9:48 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 09:43:45AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 9:36 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. Is this an official statement or is there a discussion going on somewhere? No, it isn't official. I've heard a few comments to that effect over the past few weeks, but I'm not aware of any on-list discussion. Anything public? I am asking as I was in close contact and helping the admins managing the Fedora organization for GSoC last year and I have not heard anything and thought we were going to apply as usual. I may have misunderstood the conversation I'm remembering. Apologies for any confusion. I think someone needs to step up as the main coordinator for Fedora and work with OSAS to make sure this is set. 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: whatever happened to yum + btrfs snapshotting?
Dne 17.2.2015 v 13:53 Neal Becker napsal(a): Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. yum-plugin-fs-snapshot should be what you are looking for. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher sgall...@redhat.com wrote:
== Proposal ==
With these things in mind, I'd like to propose that we amend the
packaging policy by splitting it into two forms:
I think this needs to go beyond simple policy. It needs some
buildsystem enforcement as well.
=== Core Packages ===
Any package that is provided on a release-blocking medium (which at
present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora
Workstation, the KDE Spin and several ARM images) must comply exactly
with the packaging guidelines as they are written today. These packages
must receive a full package review *when they are added to the install
media*. Any package present on the media if this proposal is adopted is
exempted from this requirement. Any package to newly appear on the
install media after this time *should* (I hate that word...) receive a
new package review, even if it is already present in Fedora.
With the definition you have here, I'm afraid we are going to be
constantly playing is or isn't on whether a package is core or not.
E.g. things get sucked into the install media due to dependencies and
nobody notices until it's time to trim the size. It just doesn't seem
like this would scale, particularly since the distro is rather fluid.
Perhaps instead the Base WG could come up with what they consider
core, and we could really stick to that? Meaning, things in core
cannot Require packages outside of core at runtime.
=== Ring Packages ===
Any new package that is *not* going to be part of the install media set
is required to pass a lighter review and is permitted to carry bundled
libraries, with caveats to be listed below.
I'm OK with this if Ring packages land in a separated repo. That
could be done by having a separate koji target that spits out things
into a rings repo.
My concern here is that if everything (ring and core combined) lands
in the same koji tag and goes through koji just like packages do
today, we're going to wind up with a big mess. Having dependencies on
ring packages is going to entangle things and make it very hard to
clean up later.
Ring Package Review Requirements
* A reviewer *MUST* establish suitability for the Fedora Project. This
means verifying that the package contains only permissible content
(legally-speaking).
* The package *MUST* conform to the FHS and other filesystem conventions
used by Fedora (such as %{python3_sitelib}), except when granted an
exception by the FPC.
* The package *MAY* contain bundled libraries or other projects, but if
it does so, it *MUST* contain a Provides: bundled(pkg) = version for
each such bundling. This is done so that we can use the meta-data to
identify which packages may be vulnerable in the event of a security
issue.
== Conclusion ==
So that is my proposal to consider for Fedora 23+ (it's too late in the
Fedora 22 cycle to consider this, but I'd prefer starting the F23
discussion right away). Comments and suggestions are strongly
encouraged.
Thank you for reading to the end.
I don't think the proposal is a bad start, but I'm concerned it isn't enough.
What I would really like to see if a proposal that focuses on the two
different needs: 1) packages that are used for the Operating System
(the distro/OS) 2) packages that run on the OS (Apps?). Packages that
are used to create Fedora itself should by most definitions wind up
being Core packages in your proposal here, regardless of whether they
are on install media (pretty sure gcc should be core...). Packages
that people want to run on top of Fedora could be the ring set. Some
might call that Core+Extras but that isn't my intention. Packages
in the ring set could move to core easily once they are cleaned up and
meet the existing FPC guidelines. There is also no separation of
schedule or dist-git or buildsystem or ACLs.
Really, I would like to see the Ring set of things not be RPMs at all.
RPMs are system wide installation. I know Dan Walsh would say that
containers do not contain, but the security model around them is
slightly better than blasting an RPM that bundles a bunch of stuff
onto the entire system. However, there is significant technical work
for that to be feasible and it isn't clear that there is a container
technology that is well suited for non-network apps yet.
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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 09:43:45AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 9:36 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. Is this an official statement or is there a discussion going on somewhere? No, it isn't official. I've heard a few comments to that effect over the past few weeks, but I'm not aware of any on-list discussion. Anything public? I am asking as I was in close contact and helping the admins managing the Fedora organization for GSoC last year and I have not heard anything and thought we were going to apply as usual. Pierre -- 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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 10:21:47AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 9:48 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 09:43:45AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 9:36 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. Is this an official statement or is there a discussion going on somewhere? No, it isn't official. I've heard a few comments to that effect over the past few weeks, but I'm not aware of any on-list discussion. Anything public? I am asking as I was in close contact and helping the admins managing the Fedora organization for GSoC last year and I have not heard anything and thought we were going to apply as usual. I may have misunderstood the conversation I'm remembering. Apologies for any confusion. I think someone needs to step up as the main coordinator for Fedora and work with OSAS to make sure this is set. That was similar to the note I was writing just now. If we have trusted folks who've stepped up to own the coordination effort, just make sure the Fedora component of OSAS also knows who they are, and can contribute as needed to the application process. Regardless of how critical the GSoC projects are, they're a good way to mentor open source contribution. And as they say, the rising tide lifts all ships. If there are questions about the admin side, where's the best place to have such discussions? Seems OT for this list. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
Josh Boyer jwbo...@fedoraproject.org writes: We should not include preprocessed source files by default without the user knowing and agreeing. People use gcc to build proprietary source still. There's a check box to this effect in ABRT. It's not much different from sending backtraces or some other things that ABRT already sends. Thanks, Petr -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek pola...@redhat.com wrote: odb-2.3.0-8.fc22.src.rpm build failure because the gcc plugin API has changed. odb has been updated to 2.4.0 which supports the new gcc 5.0 plugin API, but whenever I try to do the rebuild it fails to find libcutl (which I rebuilt last night): http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 Any ideas on what is going on there? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: pkgs.fedoraproject.org - 2015-02-19 09:00 UTC
Planned Outage: Migration to gitolite3 - 2015-02-19 09:00 UTC There will be an outage starting at 2015-02-19 09:00 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2015-02-19 09:00 UTC' Reason for outage: We will be upgrading our dist-git setup from gitolite2 to gitolite3 and from RHEL6 to RHEL7. The ssh host keys should be preserved in this migration. Uploads to lookaside cache, commits or checkouts of pkgs git and official builds that use git will be down during the outage. Affected Services: Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Secondary Architectures Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: pingou, kevin Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4651 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. pgpbMfv29gPlu.pgp Description: OpenPGP digital signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to install Rawhide?
On Tue, 17 Feb 2015 09:55:37 -0700, Kevin Fenzi wrote: 1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? Strange. The mirrormanager mirrorlist for images looks good here, and the images look fine. Ah... it's because they are not signed. | Downloading failed: couldn't get boot images: No more mirrors to try. | Last error was: [Errno 14] HTTP Error 404 - Not Found Re-run with --nogpgcheck? D'oh! That seems to lead to something. A Fedora-specific tool could really know about rawhide and tell about --nogpgcheck being needed. fedup could emit a better error here. https://bugzilla.redhat.com/show_bug.cgi?id=1193599 Brand-new ticket, yes, that seems to be the issue. One can never be sure due to mirror servers that may or may not carry the stuff that's needed. 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images Which wiki page? which 'app' ? https://fedoraproject.org/wiki/Releases/Rawhide/de - English (because the translation could be out-of-date, it doesn't mention fedup at all, and the links to koji aren't fast either when showing the list of images to download - a slow koji query!) - https://fedoraproject.org/wiki/Releases/Rawhide (it mentions --nogpg and an --instrepo somewhere in the details, it could be even easier!) - https://apps.fedoraproject.org/releng-dash/ - LiveCD Builds (rawhide) -- 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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 10:44:01AM -0500, Matthew Miller wrote: long as I think someone needs to step up as the main coordinator for Fedora and work with OSAS to make sure this is set. ... that. This would be nice, because I see an opportunity to get some development done for sigul, which needs someone fixing some issues for rel-eng. Regards Till -- 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: Now Publishing fedora developer PGP keys in DNSSEC
Hi, On Wed, Jan 28, 2015 at 06:10:13PM -0500, Paul Wouters wrote: I could put them under fedor...@fedoraproject.org ? Please use fedora-xx-primary and fedora-xx-secondary, these are now used starting with Fedora 23. Regards Till -- 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: recent/new Plasma5 crashes under investigation
Rex Dieter wrote: Miloslav Trmač wrote: and now Qt(4) doesn't build either, bug, https://bugzilla.redhat.com/show_bug.cgi?id=1192464 Any help, advice would be appreciated (particularly input from gcc maintainers). FESCo, work on the Plasma5 change/feature is suffering due to this. (Is this still applicable after the -no-use-gold-linker workaround?) Yes, there is at least one unexplained critical issue remaining, Could not sync environment to dbus. (startkde) https://bugzilla.redhat.com/show_bug.cgi?id=1191171 And this one is now reportedly fixed too, was apparently another symptom of the gold linker bug. -- 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
Re: [Test-Announce] Fedora 22 Branched 20150217 nightly compose nominated for testing
2015-02-17 14:11 GMT+01:00 adamw...@fedoraproject.org: Announcing the creation of a new nightly release validation test event for Fedora 22 Branched 20150217. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20150214: 22.19-1, 20150217: 22.20-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/22 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Base https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Server https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_22_Branched_20150217_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Maybe I am stupid but I can't find the download isos/images... -- 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: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, Feb 17, 2015 at 9:37 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Feb 17, 2015 at 04:02:35PM +0530, Sumit Bhardwaj wrote: Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. start.fedoraproject.org used to be the biggest referrer to my blog posts. Kushal -- Fedora Cloud Engineer CPython Core Developer Director Python Software Foundation http://kushaldas.in -- 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: [Proposal] Ring-based Packaging Policies
Am 17.02.2015 um 17:54 schrieb Mathieu Bridon: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way maybe you are newer to Fedora than me what you describe is what was changed around Fedora 7 http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#History * Fedora Core: Only Redhat * Fedora Extras: Community not that i say that was bad *but* it was changed intentional after the distribution is now claaed jsut Fedora you can turn and name it how you like but at the end of the day it would mean going back to the state of Fedora Core 6 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: Removal of Fedora Planet post links from start.fedoraproject.org
Well, I understand your point Matthew. Yes, often the post are on the geekier side and may not be related to Fedora project as such, but most of them are about Linux in general and day to day problems/solutions in a Linux user's life. I am not aware of the intentions behind the Planet Fedora aggregator's invention but if I am not wrong, all the blog posts that appear on it are from Fedora contributors only, from some project or other. Many times these posts are very informative and solve highly technical problems or provide way around some tricky situations based on real life experiences. So Planet Fedora is important for me personally, both as a user and as a developer. Going to it directly by entering the URL is ok but is a additional step. What you are saying about the start page is correct and yes, it should cater to the wider audience as much as possible. What I think can be done at least is since the new UI has tabs on top, another tab can be added that points to the planet fedora aggregator. It still won't be that useful but at least it won't be completely gone from the page. I think its an important part of it and I am sure there will be few other also, if not many, who developed a habit of checking it from start page over time like me. I will do some more thinking on it and if I come up with some subtle design changes that can incorporate planet Fedora links without actually changing the new design language and audience view of the page, I will surely share it. In that case, with whom can I share these? -- Regards, Sumit Bhardwaj On Tue, 2015-02-17 at 11:54 -0500, Matthew Miller wrote: On Tue, Feb 17, 2015 at 11:07:37AM -0500, Matthew Miller wrote: Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? Often, those posts were not Fedora related, and generally out of our control. I'm glad you found them usually interesting — that's valuable feedback. After some coffee, I should add some more explanation. Fedora has many times more users than developers, and the start page should primarily appeal to that wider audience. Most of the content on the planet — even that which is properly Fedora-related — is pretty highly tilted towards the geekier contributor side. There's nothing wrong with that, but it can be overwhelming. So, the goal with the Magazine is to be more user-focused (although there's still a lot of contributor-focused stuff mixed in as well; we're still working on the balance). If you're deeply involved and want the firehose, http://planet.fedoraproject.org is there. If *you'd* like to contribute user-focused content (even reposting from your blog, or whatever), see https://ask.fedoraproject.org/en/question/52782/how-do-i-contribute-to-fedora-magazine/?answer=52786#post-id-52786 There's also value in having users aware of the wider community and drawing them in, so, again... we're working out the balance, and everyone's help figuring that out is welcome. -- 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 kmplayer
I'm orphaning the kmplayer package (for f22+), last release was ~3 years ago, and it's project site @ http://kmplayer.kde.org/ is no more. (not sure if it's related at all to http://kmplayer.com/ , but that one doesn't appear to be opensource) -- 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
FUDCon APAC 2015 - Call for Papers
Hi All, FUDCon - The Fedora Users Developers Conference is back and this time to be held in Pune – one of the premiere IT Software hubs of India!. FUDCon is a major free and open source software event held in various regions around the world, with the aim of bringing Fedora community members together to engage in various innovative ideas/activities and showcase the new technologies developed. FUDCon APAC 2015 is organized in association with the Maharastra Institute of Technology College of Engineering (MIT COE) [2], one of the premiere engineering colleges in Pune, at their Campus. Keeping in line with the aim of increasing participation to Fedora and engaging with various OpenSource communities, we hereby invite you to submit proposals of interest for Talks, Workshops and Hackfests. Please submit the proposals through below link [1] on or before 9th March 2015. 1.http://fudcon.in/ 2.http://www.mitcoe.ac.in/ -- 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: yum or dnf in the Fedora 22 Docker base image?
Not that I know of. On 02/16/2015 09:50 AM, M. Edward (Ed) Borasky wrote: Thanks! Are there tracking bugs in Bugzilla I can subscribe to? On Mon, Feb 16, 2015 at 9:42 AM, Daniel J Walsh dwa...@redhat.com wrote: On 02/16/2015 12:31 PM, M. Edward (Ed) Borasky wrote: On Mon, Feb 16, 2015 at 5:19 AM, Daniel J Walsh dwa...@redhat.com wrote: I think the F22 and Rawhide (Is it F23 at this point), should both use dnf not yum. We need to get more testing on dnf in containers. I'm ready to start testing F22 containers either way and would prefer dnf. What's the best process to get this rolling? Who owns the image - release engineering or Project Atomic? The reason I ask is that Project Atomic has their own mailing list and uses Trac, not the Red Hat Bugzilla, for issue tracking. Either way, my main upstream component (RStudio Server) may end up stuck with F21 - it doesn't link with the latest Boost right now and they only support CentOS and Debian/Ubuntu. Vaclav is handling this right now. I don't see this as owned by ProjectAtomic. -- 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
Removal of Fedora Planet post links from start.fedoraproject.org
Hi All, Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? I, for one, used those links for quickly going through the new blog posts. Planet Fedora blog articles are much more frequent than those posted in fedora magazine (although that is needed as well). So 8 out of 10 times when I opened my browser, I used to get something new to read and follow from there to the actual blog if I find it interesting. Now with blog links gone, I feel less and less compelled to open the page every time I open my browser and I feel like removing it as my start page. I think the idea behind having a start page is to have users actually use it as start page and find value in doing that. I personally feel that is gone, because now, most of the times I get the same articles. So once a day visit to fedora magazine is enough. -- Regards, Sumit Bhardwaj -- 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: gcc5 ICE xserver build on ARM
On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote: On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote: Just kicked off an Xserver build in rawhide, and it appears gcc ICE. http://koji.fedoraproject.org/koji/getfile?taskID=8960146name=build.log libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/X11/dri -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/sync -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I../dbe -I../present -fvisibility=hidden -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC -o .libs/xdmcp.o xdmcp.c: In function 'XdmcpFatal': xdmcp.c:1413:16: internal compiler error: Segmentation fault status-length, status-length, status-data); ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Not sure how best to proceed. Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Thought, we have 3 bug reports about internal compiler error: Segmentation fault on ARM (#1193212, #1193244, #1193142), so perhaps opening another bug is not necessary. Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can access to get the files out from. Please file a bug and mark it a blocker to ARMTracker bug. It might be similar to some of the other ARM ICEs we're getting but I'd sooner have a dupe than miss a bug. Put the details of the koji tasks in the BZ and we can either extract the bits needed from the mock chroot or recreate the build to get the details. Which is why I hope gcc devs have such things once I point out the failure case! They do, you can also get one via beaker. 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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 8:56 AM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 17, 2015 at 08:45:09AM +, Andrew Haley wrote: On 17/02/15 07:21, David Airlie wrote: Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can access to get the files out from. I've been bitten by this several times. We need to find a better way to handle issues like this: when a build goes wrong a GCC developer needs to be able to see what went wrong, and that means direct access to the box so that they can reproduce the problem. So what might we do to solve this? Is there some way that we can freeze the contents of a buildroot to allow a dev to get in there and poke around? In most cases when the bug is reproduceable and a single preprocessed source is enough (e.g. not LTO build etc.), the gcc driver dumps all the required info into /tmp/. That is the -freport-bug Preprocessed source stored into /tmp/ccXX.out file, please attach this to your bugreport. message. So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with build.log / root.log etc. in case the build failed, that would be very much appreciated. We were actually speaking with the mock guys about this in Brno last week. From a koji PoV it just stores the files that mock spits out which at the moment is just the build logs plus any *rpm files so it shouldn't be too hard to extend mock to enable the output of extra debug files. 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: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 08:05:30PM +0100, Reindl Harald wrote: Am 17.02.2015 um 17:54 schrieb Mathieu Bridon: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way maybe you are newer to Fedora than me what you describe is what was changed around Fedora 7 http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#History * Fedora Core: Only Redhat * Fedora Extras: Community not that i say that was bad *but* it was changed intentional after the distribution is now claaed jsut Fedora you can turn and name it how you like but at the end of the day it would mean going back to the state of Fedora Core 6 This isn't correct. The division of Core/Extras was based on who was allowed to touch packages which isn't part of this proposal. That wasn't a sustainable way to build community. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.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: whatever happened to yum + btrfs snapshotting?
On 2015-02-17, 13:17 GMT, Josh Boyer wrote: Now, it is possible to do this in dnf (either with btrfs or with dm snapshots) but I'm not aware of anyone working on it. Fedora has the Snapper tool available in the repos, which could do snapshotting outside of dnf as well. Yeah, just that I was told by people who should know that snapper was mainly developed by SUSE people so it is quite leaning towards BTRFS. Support of DM-thinp snapshots is there, but its quality is really not perfect. Matěj -- 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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 08:45:09AM +, Andrew Haley wrote: On 17/02/15 07:21, David Airlie wrote: Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can access to get the files out from. I've been bitten by this several times. We need to find a better way to handle issues like this: when a build goes wrong a GCC developer needs to be able to see what went wrong, and that means direct access to the box so that they can reproduce the problem. So what might we do to solve this? Is there some way that we can freeze the contents of a buildroot to allow a dev to get in there and poke around? In most cases when the bug is reproduceable and a single preprocessed source is enough (e.g. not LTO build etc.), the gcc driver dumps all the required info into /tmp/. That is the -freport-bug Preprocessed source stored into /tmp/ccXX.out file, please attach this to your bugreport. message. So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with build.log / root.log etc. in case the build failed, that would be very much appreciated. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On 17/02/15 07:21, David Airlie wrote: Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can access to get the files out from. I've been bitten by this several times. We need to find a better way to handle issues like this: when a build goes wrong a GCC developer needs to be able to see what went wrong, and that means direct access to the box so that they can reproduce the problem. So what might we do to solve this? Is there some way that we can freeze the contents of a buildroot to allow a dev to get in there and poke around? Andrew. -- 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: gcc5 ICE xserver build on ARM
On Tue, Feb 17, 2015 at 11:21 AM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 17, 2015 at 11:18:54AM +, Peter Robinson wrote: Please file a bug and mark it a blocker to ARMTracker bug. It might be similar to some of the other ARM ICEs we're getting but I'd sooner have a dupe than miss a bug. Put the details of the koji tasks in the BZ and we can either extract the bits needed from the mock chroot or recreate the build to get the details. All the 3 recently filed ARM ICEs weren't in fact ARM related, and all of them are the same upstream already fixed bug. It should be fixed in gcc-5.0.0-0.15.fc22, though it will again take 18+ hours to make it into the buildroots. So they were generic issues? Any details as to why they seem to manifest easier on ARM? 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: ANNOUNCE: OCaml compiler will be updated in Fedora Rawhide
Update: It's nearly half way through the rebuilds now. Expected to be all finished by this time tomorrow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Regarding google summer of code 2015
Sir / Madam, I am an engineering student, and gsoc aspirant. I want to develop a easy-to-use voice recognition system, which would be capable of judging even minor changes in accents, for fedora systems. I wish to implement this system in python, making use of the open source CMU Sphinx system. I would love to do this under a mentor for gsoc 2015. Regards! Abhilash Mhaisne -- 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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 09:56:20AM +0100, Jakub Jelinek wrote: On Tue, Feb 17, 2015 at 08:45:09AM +, Andrew Haley wrote: On 17/02/15 07:21, David Airlie wrote: Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can access to get the files out from. I've been bitten by this several times. We need to find a better way to handle issues like this: when a build goes wrong a GCC developer needs to be able to see what went wrong, and that means direct access to the box so that they can reproduce the problem. So what might we do to solve this? Is there some way that we can freeze the contents of a buildroot to allow a dev to get in there and poke around? In most cases when the bug is reproduceable and a single preprocessed source is enough (e.g. not LTO build etc.), the gcc driver dumps all the required info into /tmp/. That is the -freport-bug Preprocessed source stored into /tmp/ccXX.out file, please attach this to your bugreport. message. So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with build.log / root.log etc. in case the build failed, that would be very much appreciated. Indeed, reproducing the failures only to get a /tmp/ccXX.out file is not exactly fun. In a related vein, I think ABRT should bundle the /tmp/ccXX.out files to its reports as well. From time to time we get reports as https://bugzilla.redhat.com/show_bug.cgi?id=1189122, but such a bug report is largely useless without preprocessed source + command-line options. Sorry if I'm driving this off-topic. Marek -- 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 and seeking comaintainers of some packages
Hi, There are some packages I don't use anymore, feel free to take them: libntlm python-durus barry spambayes rblcheck tokyocabinet jaxodraw flterm libquvi libquvi-scripts quvi python-django-socialregistration dayplanner gengetopt code2html elementary-icon-theme drehatlas-widelands-fonts pycryptopp drehatlas-xaporho-fonts qdevelop kawa perl-BDB txt2rss scanssh mimetex perl-Date-HolidayParser perl-Email-Find python-pymtp(epel7) These below are packages I seldom use, feel free to comaintain them: NetPIPE PyMca roxterm autoconf-archive freetalk unhide firehol npth exaile flickcurl jwm elektra dmenu profile-sync-daemon python-eyed3 oyranos Thanks. -- Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
npth (was: Re: Orphaning and seeking comaintainers of some packages)
On Tue, 17 Feb 2015 17:19:38 +0800, Christopher Meng wrote: These below are packages I seldom use, feel free to comaintain them: NetPIPE PyMca roxterm autoconf-archive freetalk unhide firehol npth nPth - The New Pth library : isn't that one of the forks of pth to be developed more actively? It isn't used by any package yet according to repoquery. It has been imported just 23 months ago. Are you aware of any anything that uses it? exaile flickcurl jwm elektra dmenu profile-sync-daemon python-eyed3 oyranos Thanks. -- 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: gcc5 ICE xserver build on ARM
David Airlie airl...@redhat.com wrote: Not sure how best to proceed. Can the software be cross-compiled? If so, I could provide you with a cross-compiler. David -- 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: ANNOUNCE: OCaml compiler will be updated in Fedora Rawhide
On Tue, Feb 17, 2015 at 10:23 AM, Richard W.M. Jones rjo...@redhat.com wrote: Update: It's nearly half way through the rebuilds now. Expected to be all finished by this time tomorrow. What's the state of rawhide expected to be in the interim? Is today/tomorrow's compose going to be hosed? 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: npth (was: Re: Orphaning and seeking comaintainers of some packages)
On 2/17/15, Michael Schwendt mschwe...@gmail.com wrote: nPth - The New Pth library : isn't that one of the forks of pth to be developed more actively? It isn't used by any package yet according to repoquery. It has been imported just 23 months ago. Are you aware of any anything that uses it? Maybe you don't use rawhide? gnupg2 uses it for a long time. You can query the dep info on rawhide machine, 3 packages need it: gnupg2, gnupg2-smime and npth-devel. I still maintain it, but other maintainers especially of gnupg2 are welcome. -- Yours sincerely, Christopher Meng http://cicku.me -- 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: Copr routinely swamped by nightly builds
2015-02-17 5:34 GMT+01:00 Kevin Kofler kevin.kof...@chello.at: IMHO, one of 2 things needs to happen: a) Copr gets a massive increase of resources (builders) to handle the load, OR b) we disallow nightly builds of huge packages such as python3 in Copr, because the infrastructure does not scale to that kind of load. Kevin Kofler Wouldn't it be better to (c) implement some sort of 'fair' scheduling instead of a pure first-come-first-serve system? Because (a) sounds unlikely, and (b) seems hard to define properly (what is a 'huge' package? when is 'night'? and when are people allowed to do these builds?) and also hard to enforce. - Thomas -- 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: gcc5 ICE xserver build on ARM
On Tue, Feb 17, 2015 at 11:18:54AM +, Peter Robinson wrote: Please file a bug and mark it a blocker to ARMTracker bug. It might be similar to some of the other ARM ICEs we're getting but I'd sooner have a dupe than miss a bug. Put the details of the koji tasks in the BZ and we can either extract the bits needed from the mock chroot or recreate the build to get the details. All the 3 recently filed ARM ICEs weren't in fact ARM related, and all of them are the same upstream already fixed bug. It should be fixed in gcc-5.0.0-0.15.fc22, though it will again take 18+ hours to make it into the buildroots. Jakub -- 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: ANNOUNCE: OCaml compiler will be updated in Fedora Rawhide
On Tue, Feb 17, 2015 at 11:26:06AM +, Peter Robinson wrote: On Tue, Feb 17, 2015 at 10:23 AM, Richard W.M. Jones rjo...@redhat.com wrote: Update: It's nearly half way through the rebuilds now. Expected to be all finished by this time tomorrow. What's the state of rawhide expected to be in the interim? Is today/tomorrow's compose going to be hosed? Hosed in what sense? About 30 OCaml libraries won't be installable because of dependency problems, with the number decreasing over the next 24 hours. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
Indeed, reproducing the failures only to get a /tmp/ccXX.out file is not exactly fun. In a related vein, I think ABRT should bundle the /tmp/ccXX.out files to its reports as well. From time to time we get reports as https://bugzilla.redhat.com/show_bug.cgi?id=1189122, but such a bug report is largely useless without preprocessed source + command-line options. Sorry if I'm driving this off-topic. Yes, the way to do that is to file a RFE in RHBZ against abrt, they are very responsive! 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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Feb 17, 2015 7:10 AM, Peter Robinson pbrobin...@gmail.com wrote: Indeed, reproducing the failures only to get a /tmp/ccXX.out file is not exactly fun. In a related vein, I think ABRT should bundle the /tmp/ccXX.out files to its reports as well. From time to time we get reports as https://bugzilla.redhat.com/show_bug.cgi?id=1189122, but such a bug report is largely useless without preprocessed source + command-line options. Sorry if I'm driving this off-topic. Yes, the way to do that is to file a RFE in RHBZ against abrt, they are very responsive! We should not include preprocessed source files by default without the user knowing and agreeing. People use gcc to build proprietary source still. 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: Copr routinely swamped by nightly builds
On Tue, 17 Feb 2015 11:35:57 +0100 Thomas Moschny thomas.mosc...@gmail.com wrote: 2015-02-17 5:34 GMT+01:00 Kevin Kofler kevin.kof...@chello.at: IMHO, one of 2 things needs to happen: a) Copr gets a massive increase of resources (builders) to handle the load, OR b) we disallow nightly builds of huge packages such as python3 in Copr, because the infrastructure does not scale to that kind of load. Kevin Kofler a) is in progress. We have hardware, just working on setting up a much more recent openstack. Once thats in and stable and maintainable, we should be able to increase the number of builders a great deal. Wouldn't it be better to (c) implement some sort of 'fair' scheduling instead of a pure first-come-first-serve system? Yes, that also has been talked about. I don't know where it is in implementation however. kevin pgpIWtR0tpdIW.pgp 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: Regarding google summer of code 2015
Oh my! Thank you Mr. Nico! :) I will pick up a smaller project for google summer of code. However, I am too much obsessed with voice recognition systems. But now I understand that it is not a small issue. Someday, I will surely work on speech synthesis. As you mentioned above, it is certainly not doable in small span of SoC. Thanks once again! :) On Tue, Feb 17, 2015 at 6:01 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Feb 17, 2015 at 5:49 AM, Abhilash Mhaisne abhilashmhai...@gmail.com wrote: Sir / Madam, I am an engineering student, and gsoc aspirant. I want to develop a easy-to-use voice recognition system, which would be capable of judging even minor changes in accents, for fedora systems. And I'd like a pony, with pretty wings that can fly to Jupiter and makes cookies. More seriously, voice recognition is one of the great challenges of the last 50 years of speech analysis, approached by large and small companies and research labs around the world. Judging even minor changes in accents is a nightmare in real work: every commercially available computer microphone system for the last few decades has made the same basic mistake for collecting speech. They completely screw up plosives, sounds like b and p that have a lot of high frequency information that gets completely munged by the digitization and undersampling. And do not get me *started* on the ongoing fallacy that if we just collect more speech samples, we'll somehow be able to analyze them. I'm aware of companies with software patents spending many millions of investment money in the work, and they're still getting their ass handed to them in the marketplace by smaller, local apps that handle basic speech locally and *don't try to get fancy*. And in case it's not clear: I did artificial hearing research for a dozen years, designing electronics for cochlear implants. Every modern microphone=speech analysis system screws up the plosives, for a stack of reasons we could discuss elsewhere. I wish to implement this system in python, making use of the open source CMU Sphinx system. I would love to do this under a mentor for gsoc 2015. Regards! Abhilash Mhaisne See above. voice recognition and accent immunity is not a python sort of problem, it's a massive ongoing computer and speech research issue. Pick something *smaller*. -- 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
Re: Removal of Fedora Planet post links from start.fedoraproject.org
On Tue, 17 Feb 2015 16:02:35 +0530 Sumit Bhardwaj sumitkbhard...@gmail.com wrote: Hi All, Hope its the right place to discuss this. Recently, during the redesign of the start.fedoraproject.org page, the links to updated/new posts from planet.fedoraproject.org were removed. Any specific reason for this? You likely want the fedora-websites list: https://admin.fedoraproject.org/mailman/listinfo/websites You should be able to talk with the folks that did the redesign there. kevin pgpl2yd7Lyc4F.pgp 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
[Test-Announce] Fedora 22 Branched 20150217 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 22 Branched 20150217. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20150214: 22.19-1, 20150217: 22.20-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/22 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Base https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Server https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150217_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_22_Branched_20150217_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Regarding google summer of code 2015
Nico Kadel-Garcia wrote: See above. voice recognition and accent immunity is not a python sort of problem, it's a massive ongoing computer and speech research issue. Pick something *smaller*. I would also add to that that Fedora would probably be the wrong mentoring organization for such a project to begin with, even if it were doable. These things need to be worked on with upstream projects. But they are very likely to reject this proposal for the same reasons. Improving the quality of the speech recognition, if it's possible at all, has to be done inside the C (Pocketsphinx) or Java (Sphinx4) code of CMU Sphinx. Trying to do it in a higher layer in Python doesn't make any sense whatsoever. Kevin Kofler -- 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: whatever happened to yum + btrfs snapshotting?
On Tue, Feb 17, 2015 at 7:53 AM, Neal Becker ndbeck...@gmail.com wrote: Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. Well, yum is being retired in favor of dnf and btrfs still isn't the default filesystem because it still isn't stable enough. So that's basically what happened. Now, it is possible to do this in dnf (either with btrfs or with dm snapshots) but I'm not aware of anyone working on it. Fedora has the Snapper tool available in the repos, which could do snapshotting outside of dnf as well. 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: npth (was: Re: Orphaning and seeking comaintainers of some packages)
On Tue, 17 Feb 2015 18:13:29 +0800, Christopher Meng wrote: nPth - The New Pth library : isn't that one of the forks of pth to be developed more actively? It isn't used by any package yet according to repoquery. It has been imported just 23 months ago. Are you aware of any anything that uses it? Maybe you don't use rawhide? True. It breaks my installations too often (and when I retry fedup, it gives a 404 not found error, and I always forget the special invocation or Wiki pages that may make it work). But I could have pointed repoquery at rawhide. gnupg2 uses it for a long time. Same author. ;-) You can query the dep info on rawhide machine, 3 packages need it: gnupg2, gnupg2-smime and npth-devel. So, just gnupg2 so far, since gnupg2-smime is a subpkg, and npth-devel belongs to npth (obviously). Okay. One should give it more time and see whether any issues will come up during the F22 test cycle then. I still maintain it, but other maintainers especially of gnupg2 are welcome. -- 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: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 07:19:35AM -0500, Josh Boyer wrote: On Feb 17, 2015 7:10 AM, Peter Robinson pbrobin...@gmail.com wrote: Indeed, reproducing the failures only to get a /tmp/ccXX.out file is not exactly fun. In a related vein, I think ABRT should bundle the /tmp/ccXX.out files to its reports as well. From time to time we get reports as https://bugzilla.redhat.com/show_bug.cgi?id=1189122, but such a bug report is largely useless without preprocessed source + command-line options. Sorry if I'm driving this off-topic. Yes, the way to do that is to file a RFE in RHBZ against abrt, they are very responsive! Oh, we already have an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1139841 We should not include preprocessed source files by default without the user knowing and agreeing. People use gcc to build proprietary source still. That is a good point; the users would have to agree with sending the preprocessed file. Marek -- 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: Regarding google summer of code 2015
On Tue, Feb 17, 2015 at 5:49 AM, Abhilash Mhaisne abhilashmhai...@gmail.com wrote: Sir / Madam, I am an engineering student, and gsoc aspirant. I want to develop a easy-to-use voice recognition system, which would be capable of judging even minor changes in accents, for fedora systems. And I'd like a pony, with pretty wings that can fly to Jupiter and makes cookies. More seriously, voice recognition is one of the great challenges of the last 50 years of speech analysis, approached by large and small companies and research labs around the world. Judging even minor changes in accents is a nightmare in real work: every commercially available computer microphone system for the last few decades has made the same basic mistake for collecting speech. They completely screw up plosives, sounds like b and p that have a lot of high frequency information that gets completely munged by the digitization and undersampling. And do not get me *started* on the ongoing fallacy that if we just collect more speech samples, we'll somehow be able to analyze them. I'm aware of companies with software patents spending many millions of investment money in the work, and they're still getting their ass handed to them in the marketplace by smaller, local apps that handle basic speech locally and *don't try to get fancy*. And in case it's not clear: I did artificial hearing research for a dozen years, designing electronics for cochlear implants. Every modern microphone=speech analysis system screws up the plosives, for a stack of reasons we could discuss elsewhere. I wish to implement this system in python, making use of the open source CMU Sphinx system. I would love to do this under a mentor for gsoc 2015. Regards! Abhilash Mhaisne See above. voice recognition and accent immunity is not a python sort of problem, it's a massive ongoing computer and speech research issue. Pick something *smaller*. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
whatever happened to yum + btrfs snapshotting?
Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. -- -- Those who don't understand recursion are doomed to repeat it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1193422] perl-System-Command-1.111 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193422 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-System-Command-1.111-1 ||.fc22 Resolution|--- |RAWHIDE Last Closed||2015-02-17 07:54:01 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pvO5A6KeA0a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Orphaning and seeking comaintainers of some packages
On Tue, Feb 17, 2015 at 3:19 AM, Christopher Meng cicku...@gmail.com wrote: Hi, There are some packages I don't use anymore, feel free to take them: libntlm python-durus barry spambayes rblcheck tokyocabinet jaxodraw flterm libquvi libquvi-scripts quvi python-django-socialregistration dayplanner gengetopt code2html elementary-icon-theme drehatlas-widelands-fonts pycryptopp drehatlas-xaporho-fonts qdevelop kawa perl-BDB txt2rss scanssh mimetex perl-Date-HolidayParser perl-Email-Find python-pymtp(epel7) I've taken tokyocabinet and mimetex. These below are packages I seldom use, feel free to comaintain them: NetPIPE PyMca roxterm autoconf-archive freetalk unhide firehol npth exaile flickcurl jwm elektra dmenu profile-sync-daemon python-eyed3 oyranos Thanks. -- Yours sincerely, Christopher Meng http://cicku.me -- 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
deadline for fedora org to appy in google summer of code 2015
https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining -- Itamar Reis Peixoto -- 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: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 3 days, 5 hours remaining I don't believe Fedora will be applying to this any longer in an official capacity. 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: Regarding google summer of code 2015
Oh I see. Did not know about these. I put it on fedora just cause it's my favorite distro. Thank you! On Tue, Feb 17, 2015 at 6:42 PM, Kevin Kofler kevin.kof...@chello.at wrote: Nico Kadel-Garcia wrote: See above. voice recognition and accent immunity is not a python sort of problem, it's a massive ongoing computer and speech research issue. Pick something *smaller*. I would also add to that that Fedora would probably be the wrong mentoring organization for such a project to begin with, even if it were doable. These things need to be worked on with upstream projects. But they are very likely to reject this proposal for the same reasons. Improving the quality of the speech recognition, if it's possible at all, has to be done inside the C (Pocketsphinx) or Java (Sphinx4) code of CMU Sphinx. Trying to do it in a higher layer in Python doesn't make any sense whatsoever. Kevin Kofler -- 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
[Bug 1193728] New: perl-Inline-C-0.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193728 Bug ID: 1193728 Summary: perl-Inline-C-0.74 is available Product: Fedora Version: rawhide Component: perl-Inline-C Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.74 Current version/release in rawhide: 0.73-1.fc22 URL: http://search.cpan.org/dist/Inline-C/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7LEb6Gk44pa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Hash-MultiValue-0.16.tar.gz uploaded to lookaside cache by cheeselee
A file has been added to the lookaside cache for perl-Hash-MultiValue: 508015312eb08cd2bcea987c4efbb93d Hash-MultiValue-0.16.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1193721] New: perl-DBD-Pg-3.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193721 Bug ID: 1193721 Summary: perl-DBD-Pg-3.5.1 is available Product: Fedora Version: rawhide Component: perl-DBD-Pg Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dev...@gunduz.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 3.5.1 Current version/release in rawhide: 3.5.0-1.fc23 URL: http://search.cpan.org/dist/DBD-Pg/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RqSoteWEz5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1193418] perl-Hash-MultiValue-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193418 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- cheeselee's perl-Hash-MultiValue-0.16-1.fc22 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612355 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WpediYTzIOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1193727] New: perl-Inline-0.79 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193727 Bug ID: 1193727 Summary: perl-Inline-0.79 is available Product: Fedora Version: rawhide Component: perl-Inline Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.79 Current version/release in rawhide: 0.78-1.fc22 URL: http://search.cpan.org/dist/Inline/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=W6R4wa4Byda=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Hash-MultiValue] Update to 0.16 (BZ#1193418)
commit 2da02015a699e8f0416c4f44d4d1470fa25ec42d
Author: Robin Lee cheese...@fedoraproject.org
Date: Wed Feb 18 11:47:35 2015 +0800
Update to 0.16 (BZ#1193418)
.gitignore|1 +
perl-Hash-MultiValue.spec |9 ++---
sources |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index dbb7552..ff1474e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Hash-MultiValue-0.08.tar.gz
/Hash-MultiValue-0.13.tar.gz
/Hash-MultiValue-0.14.tar.gz
/Hash-MultiValue-0.15.tar.gz
+/Hash-MultiValue-0.16.tar.gz
diff --git a/perl-Hash-MultiValue.spec b/perl-Hash-MultiValue.spec
index 2eeaec8..fb085e2 100644
--- a/perl-Hash-MultiValue.spec
+++ b/perl-Hash-MultiValue.spec
@@ -1,10 +1,10 @@
Name: perl-Hash-MultiValue
Summary:Store multiple values per key
-Version:0.15
-Release:4%{?dist}
+Version:0.16
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/Hash-MultiValue-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/A/AR/ARISTOTLE/Hash-MultiValue-%{version}.tar.gz
URL:http://search.cpan.org/dist/Hash-MultiValue
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -53,6 +53,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Wed Feb 18 2015 Robin Lee cheese...@fedoraproject.org - 0.16-1
+- Update to 0.16 (BZ#1193418)
+
* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 0.15-4
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 7c0469f..9665697 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eb7df1402b774b07a305dbb67873817a Hash-MultiValue-0.15.tar.gz
+508015312eb08cd2bcea987c4efbb93d Hash-MultiValue-0.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Hash-MultiValue/f22] Update to 0.16 (BZ#1193418)
Summary of changes: 2da0201... Update to 0.16 (BZ#1193418) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1193418] perl-Hash-MultiValue-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193418 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- cheeselee's perl-Hash-MultiValue-0.16-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612354 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cz6ApQLzifa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [EPEL-devel] el7 liblockfile
On Tue, Feb 17, 2015 at 08:11:46AM +0100, Matthias Runge wrote: Ugh. Good catch! It looks like liblockfile was added to EPEL7 by accident. I opened a ticket[1]. In the future, just retire the package in GIT/pkgdb and everything will be done correctly. Regards Till ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[perl-Crypt-OpenSSL-Random] require test::more for building
commit 59534df0844596430264e685938c6fef7a845aee
Author: Wes Hardaker opensou...@hardakers.net
Date: Tue Feb 17 09:07:06 2015 -0800
require test::more for building
perl-Crypt-OpenSSL-Random.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Crypt-OpenSSL-Random.spec b/perl-Crypt-OpenSSL-Random.spec
index 3952e7a..0d26125 100644
--- a/perl-Crypt-OpenSSL-Random.spec
+++ b/perl-Crypt-OpenSSL-Random.spec
@@ -1,6 +1,6 @@
Name: perl-Crypt-OpenSSL-Random
Version:0.10
-Release:5%{?dist}
+Release:2%{?dist}
Summary:Perl interface to OpenSSL for Random
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(AutoLoader)
BuildRequires: perl(Carp)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -54,6 +55,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Tue Feb 17 2015 Wes Hardaker wjhns...@hardakers.net - 0.10-2
+- build-req test::more
+
* Tue Feb 17 2015 Wes Hardaker wjhns...@hardakers.net - 0.10-1
- Update to 0.10
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl/f22] 5.20.2 bump; Resolved BZ#1177672
commit d903df44e65723eac65b3f17360599512dbd16e3
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Feb 17 17:49:25 2015 +0100
5.20.2 bump; Resolved BZ#1177672
.gitignore |1 +
perl.spec | 22 ++
sources|2 +-
3 files changed, 20 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 87e7d8c..500eb21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@ filter-requires.sh
/perl-5.18.2.tar.bz2
/perl-5.20.0.tar.bz2
/perl-5.20.1.tar.bz2
+/perl-5.20.2.tar.bz2
diff --git a/perl.spec b/perl.spec
index 05d155d..3ad2eee 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1,4 +1,4 @@
-%global perl_version5.20.1
+%global perl_version5.20.2
%global perl_epoch 4
%global perl_arch_stem -thread-multi
%global perl_archname %{_arch}-%{_os}%{perl_arch_stem}
@@ -30,7 +30,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:319%{?dist}
+Release:320%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -124,9 +124,12 @@ BuildRequires: groff-base
BuildRequires: libdb-devel, tcsh, zlib-devel, bzip2-devel
BuildRequires: systemtap-sdt-devel
%if %{with gdbm}
-BuildRequires: gdbm-devel
+BuildRequires: gdbm-devel
%endif
+# Regenerate a2p.c bug #1177672
+BuildRequires: byacc
+
# For tests
BuildRequires: procps, rsyslog
@@ -1355,7 +1358,7 @@ Summary:What modules are shipped with versions of
perl
Group: Development/Libraries
License:GPL+ or Artistic
Epoch: 1
-Version:5.020001
+Version:5.20150214
Requires: %perl_compat
Requires: perl(List::Util)
Requires: perl(version) = 0.88
@@ -2093,6 +2096,12 @@ rm -rf 'cpan/Memoize/Memoize/NDBM_File.pm'
sed -i '\|cpan/Memoize/Memoize/NDBM_File.pm|d' MANIFEST
%endif
+# Regenerate a2p.c bug #1177672
+pushd x2p
+yacc a2p.y
+mv -f y.tab.c a2p.c
+popd
+
%build
echo RPM Build arch: %{_arch}
@@ -3853,6 +3862,11 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Tue Feb 17 2015 Jitka Plesnikova jples...@redhat.com - 4:5.20.2-320
+- 5.20.2 bump (see http://search.cpan.org/dist/perl-5.20.2/pod/perldelta.pod
+ for release notes)
+- Regenerate a2p.c (BZ#1177672)
+
* Mon Feb 16 2015 Petr Pisar ppi...@redhat.com - 4:5.20.1-319
- Improve h2ph fix for GCC 5.0
diff --git a/sources b/sources
index 16ffb67..c0557ea 100644
--- a/sources
+++ b/sources
@@ -2,4 +2,4 @@ aceea3db13a159cd5f7e5f2e3ad9534f perl-5.8.0-libdir64.patch
ad5d07285d6e4914384b43c9abc2bdba filter-requires.sh
93b780a770906408a34b1c511e333a12 perl.stp
735480c6749c2aa86faa8311fe651142 perl-example.stp
-ede5166f949d9a07163bc5b086be9759 perl-5.20.1.tar.bz2
+21062666f1c627aeb6dbff3c6952738b perl-5.20.2.tar.bz2
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Term-ReadLine-Gnu/f22] Fix regression with Debug::Client
Summary of changes: 5d7a0af... Fix regression with Debug::Client (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Crypt-OpenSSL-Bignum-0.06.tar.gz uploaded to lookaside cache by hardaker
A file has been added to the lookaside cache for perl-Crypt-OpenSSL-Bignum: 5673ee17919231c6394382e48f80c582 Crypt-OpenSSL-Bignum-0.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Crypt-OpenSSL-DSA] (2 commits) ...merged
Summary of changes: c9730d5... new 0.15 release 3a81e36... merged -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Crypt-OpenSSL-DSA: 2/2] merged
commit 3a81e36f5cf7c288f547d280f2409e25ee9faabc
Merge: c9730d5 6df5940
Author: Wes Hardaker opensou...@hardakers.net
Date: Tue Feb 17 07:21:25 2015 -0800
merged
perl-Crypt-OpenSSL-DSA.spec | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
---
diff --cc perl-Crypt-OpenSSL-DSA.spec
index 62a4b31,cfa5105..34bcf8c
--- a/perl-Crypt-OpenSSL-DSA.spec
+++ b/perl-Crypt-OpenSSL-DSA.spec
@@@ -47,9 -47,24 +47,28 @@@ rm -rf %{buildroot
%{_mandir}/man3/*
%changelog
+* Tue Feb 17 2015 Wes Hardaker wjhns...@hardakers.net - 0.15-1
+- Update to 0.15
+
+ * Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.14-7
+ - Perl 5.20 rebuild
+
+ * Sun Aug 17 2014 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 0.14-6
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
+
+ * Sat Jun 07 2014 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 0.14-5
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
+ * Sat Aug 03 2013 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 0.14-4
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+ * Wed Jul 17 2013 Petr Pisar ppi...@redhat.com - 0.14-3
+ - Perl 5.18 rebuild
+
+ * Thu Feb 14 2013 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 0.14-2
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
++ 6df59403e51625cb4b2d401da8d71343d2e32209
+
* Wed Oct 17 2012 Wes Hardaker wjhns...@hardakers.net - 0.14-1
- Update to upstream 0.14 for bug fixes
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 991649] [abrt] perl-Padre-0.90-6.fc18: wxMBConv::FromWChar: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
https://bugzilla.redhat.com/show_bug.cgi?id=991649 Fedora End Of Life endofl...@fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL Last Closed||2015-02-17 11:32:26 --- Comment #12 from Fedora End Of Life endofl...@fedoraproject.org --- Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qIs7wwz6DOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File perl-5.20.2.tar.bz2 uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl: 21062666f1c627aeb6dbff3c6952738b perl-5.20.2.tar.bz2 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1188816] perl-Crypt-OpenSSL-Random-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1188816 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- hardaker's perl-Crypt-OpenSSL-Random-0.10-2.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612221 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IRK5ozv3yXa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
