Schedule for Wednesday's FESCo Meeting (2012-01-16)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #986 F19 Feature: DualstackNetworking - https://fedoraproject.org/wiki/Features/DualstackNetworking .fesco 986 https://fedorahosted.org/fesco/ticket/986 = New business = #topic #985 F19 Feature: Pillow - https://fedoraproject.org/wiki/Features/Pillow .fesco 985 https://fedorahosted.org/fesco/ticket/985 #topic #990 F19 Feature: PHP 5.5 - https://fedoraproject.org/wiki/Features/Php55 .fesco 990 https://fedorahosted.org/fesco/ticket/990 #topic #991 F19 Feature: PackageSignatureCheckingDuringOSInstall - https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall .fesco 991 https://fedorahosted.org/fesco/ticket/991 #topic #992 F19 Feature: NodeJS - https://fedoraproject.org/wiki/Features/NodeJS .fesco 992 https://fedorahosted.org/fesco/ticket/992 #topic #993 F19 Feature: NetworkManagerCLIAddConnection - https://fedoraproject.org/wiki/Features/NetworkManagerCLIAddConnection .fesco 993 https://fedorahosted.org/fesco/ticket/993 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Shall we modify '-g' to '-g3' to have gcc save the macro info?
Hi guys, Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. The gdb info says, GDB knows about preprocessor macros and can show you their expansion (*note Macros::). Most compilers do not include information about preprocessor macros in the debugging information if you specify the `-g' flag alone. Version 3.1 and later of GCC, the GNU C compiler, provides macro information if you are using the DWARF debugging format, and specify the option `-g3'. Thanks, xning -- Xibo Ning Hosted and shared services Red Hat Asia Pacific IRC Account: xning at #hss #eng-china #libra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wireshark
On 01/15/2013 06:27 PM, Samuel Sieb wrote: > See https://bugzilla.redhat.com/show_bug.cgi?id=863602 for the gtk3 > resizing issue. I have attached a patch there that fixes the resizing > issues for me. Really unfortunate that this has been known for 3 1/2 months, and the package maintainer/bug assignee hasn't bothered to even respond. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wireshark
On 01/15/2013 09:29 AM, Ian Pilcher wrote: Wireshark in F18 has some significant problems, caused by the change to Gtk3. Can this please be reverted to build against Gtk2 until upstream works these issues out? https://bugzilla.redhat.com/show_bug.cgi?id=894655 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7377 Not sure if this has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=871091 See https://bugzilla.redhat.com/show_bug.cgi?id=863602 for the gtk3 resizing issue. I have attached a patch there that fixes the resizing issues for me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange Build problem....
On Tue, Jan 15, 2013 at 01:42:21PM -0500, Steve Dickson wrote:
> Hello,
>
> I'm seeing following build error
>http://kojipkgs.fedoraproject.org//work/tasks/1677/4871677/build.log
>
> But I'm not seeing this error on local f18 or f17 builds...
>
> Note, the same version of python-matplotlib (1.2.0-5) is being used in all
> the builds...
>
> How do I debug something like this??
>
Trial and error probably :-(
Grep the sources to find out where the error message is coming from:
./nfsometerlib/config.py:import_error("Error importing matplotlib
submodules - this is probably an incompatible version of matplotlib")
Take a look at the code there:
try:
# Don't require $DISPLAY to be set!
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import matplotlib.font_manager as fm
except:
import_error("Error importing matplotlib submodules - this is probably an
incompatible version of matplotlib")
The comment might be a clue or might be a red herring. It looks like
matplotlib.use() sets the library to output to something that doesn't need
DISPLAY. If the Agg output has changed in F18, that might be the problem.
The try: except: is swallowing all errors here. Getting a more verbose
traceback may help diagnose. You can remove the try: except: and dedent the
remaining code one level to get the actual traceback in the build.log.
-Toshio
pgpDSwVSTWNt_.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' "standard" group spring cleaning?
(mashing together a few replies. Sorry about the delay.)
Michael Scherer (m...@zarb.org) said:
> Le vendredi 11 janvier 2013 à 08:05 -0600, Chris Adams a écrit :
> > Once upon a time, Bill Nottingham said:
> > >
> > > - ed
> >
> > I don't know how widely it is used, but ed is also part of POSIX/SUS.
>
> based on my understanding, POSIX do not mandate them to be there by
> default, just to support them :
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html
>
> so not installing them by default will not change much, given that we
> already do not support several command :
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html
...
> A separate group would be better because :
> - this is easier to audit ( especially if the norm is updated )
> - this doesn't force to install a compiler by default ( fort77 )
Things like ed & bc are required by redhat-lsb-core. (You can repoquery
it for its full list). Would it be worth it to just list that, and not
worry about the smaller things? Biggest size downfall to this is that
it drags cups into the system. :/
Chris Adams (cmad...@hiwaay.net) said:
> > - ftp
>
> Either ftp or lftp should still be in the standard install (command line
> FTP is sometimes essential, especially when trying to add to a minimal
> install). lftp is bigger than ftp (because lftp does more, such as sftp
> and http).
If you're adding to an install, and you already have curl, rsync, and sftp,
how much do you need an interactive ftp client itself?
> > - btrfs-progs
> >
> > Will be installed by anaconda if you install on btrfs; can move
> > to @core if it becomes the default FS.
>
> There are several common things that you list as installed by anaconda
> if needed; that can give you problems if you install in one system or
> setup and then move the drive, add other drives, etc.
Sure, but I would assume that if you're doing that, you know what you're
doing.
> > - lftp
> >
> > Removed; ftp is in legacy-unix.
>
> If legacy-unix is not part of standard install, that is a poor
> justification ("we removed one FTP client, so better remove the other as
> well").
The idea is that if the functionality is provided elsewhere, all uses
of it should go there; splitting the functionality between groups doesn't
make much sense.
> I guess my comments get back to: is there a defined goal, other than
> "remove things Bill doesn't use" (not trying to pick on you Bill, but
> you did make this list)? Are we trying to shrink the installed disk
> footprint (none of the these are very big)? Does removing these reduce
> install time significantly?
This came up in the bugzilla ticket as well, and it's probably a better
place to start.
So, first principles of the group, IMO:
'Standard' would be 'tools and utilities you expect to be on a standard
Linux install, but that aren't needed in a minimal install'. It's included
in every non-minimal install. (In general, that means all the desktops;
people who install servers usually start at minimal and work their way up.)
This then brings up the following discussion points:
* bc, ed, talk, etc.
Should we just list redhat-lsb-core?
* ftp vs lftp, info vs pinfo, traceroute vs mtr
If we're talking about a 'standard' group of things that people would expect
to be there, then perhaps we drop all the newer, "better" version of things.
Sure, people still can install and use pinfo or mtr. But is that the
standard that people expect to be there every time?
* ftp, finger, etc.
Are these things that are still expected in a 'standard' Linux install?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 01/15/2013 01:01 PM, Adam Tkac wrote: > Another interesting thread is > http://sourceforge.net/mailarchive/message.php?msg_id=30352453 > > We are currently discussing drop of the > https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature > because > SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was > rejected > by ISO and actually doesn't bring any benefit over widely used png/webp > codecs. > > So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer > reveals some new facts about SmartScale. All facts are currently against > SmartScale (image quality/size, compression/decompression speed). Upstream Tracker shows 0% of binary compatibility with previous releases: http://upstream-tracker.org/versions/libjpeg.html I hope other distributions don't use that release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedup ui
Just tried fedup f17->f18. After digging for correct command line, I got it to work. BUT, after reboot it sits at fedora splash screen, which is pulsating. It gives almost no indication that it actually isn't dead. Attempts to switch vt do nothing, so no way to see what's happening. I eventually noticed a very small, very slowly progressing bar. Really needs better user feedback. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Strange Build problem....
Hello, I'm seeing following build error http://kojipkgs.fedoraproject.org//work/tasks/1677/4871677/build.log But I'm not seeing this error on local f18 or f17 builds... Note, the same version of python-matplotlib (1.2.0-5) is being used in all the builds... How do I debug something like this?? tia, steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Wireshark
Wireshark in F18 has some significant problems, caused by the change to Gtk3. Can this please be reverted to build against Gtk2 until upstream works these issues out? https://bugzilla.redhat.com/show_bug.cgi?id=894655 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7377 Not sure if this has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=871091 -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reminder: Fedora 16 end of life on 2013-02-12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings. This is a reminder email about the end of life process for Fedora 16. Fedora 16 will reach end of life on 2013-02-12, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 18, no new packages will be added to the Fedora 16 collection. Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading from Fedora 16 to a newer release. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD1ijoACgkQkSxm47BaWffE1gCgwpIOp4jT/vuwMLuG9VWpXHYH p8MAn2f0RY3InfKcquvgmyCEHF7pXqPF =UOtn -END PGP 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
[Test-Announce] Announcing the release of Fedora 18.
The Fedora Project is incredibly delighted to announce the release of Fedora 18
("Spherical Cow"). Heck, we'd even say that getting this release to you has
been a mooving experience.
Fedora is a leading-edge, free and open source operating system that continues
to deliver innovative features to many users, with a new release about every
six months...or so. :-D But no bull: Spherical Cow, is of course, Fedora's
best release yet. You'll go through the hoof when you hear about the Grade A
Prime F18 features. You can always cownt on us to bring you the best features
first.
Can't wait for a taste? You can get started downloading now:
http://fedoraproject.org/get-fedora
Detailed information about this release can be seen in the release notes:
http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/
== What's New in Fedora 18? ==
The Fedora Project takes great pride in being able to show off features for all
types of use cases, including traditional desktop users, systems
administration, development, the cloud, and many more. But a few new features
are guaranteed to be seen by nearly anyone installing Fedora and are
improvements that deserve to be called out on their own.
The user interface for Fedora's installation software, Anaconda, has been
completely re-written from the ground up. Making its debut in Fedora 18, the
new UI introduces major improvements to the installation experience. It uses a
hub-and-spoke model that makes installation easier for new users, offering them
concise explanations about their choices. Advanced users and system
administrators are of course still able to take advantage of more complex
options. The general look and feel of the installation experience has been
vastly upgraded, providing modern, clean, and comprehensible visuals during the
process. While the new installer should work well for most users in most
configurations, there are inevitably a few teething problems in the first
release of such a major revision.
Known design limitations of the new installer in F18 are listed here:
http://fedoraproject.org/wiki/Anaconda/NewInstaller
Known significant bugs can be seen here:
http://fedoraproject.org/wiki/Common_F18_bugs#Installation_issues
We welcome your constructive and specific feedback as we continue to work on
refining the installer for future releases.
The upgrade process for Fedora now uses a new tool called FedUp (Fedora
Upgrader). FedUp replaces pre-upgrade as well as the DVD methods for upgrading
that have been used in previous Fedora releases. FedUp integrates with systemd
to enable the upgrade functionality, doing the work in a pristine boot
environment.
Of course, it wouldn't be a release announcement without a spotted -- er,
dotted -- list of all the other fantastic features you'll see in Fedora 18:
=== For desktop users ===
Mve over, stale desktops. We've got a small herd of choices udderly suited
to your preferences.
* GNOME 3.6: The newest version of the GNOME desktop provides an enhanced
Messaging Tray, support for Microsoft Exchange and Skydrive, and many more new
features.
* Cinnamon: Fedora users now have the option of using Cinnamon, an advanced
desktop environment based on GNOME 3. Cinnamon takes advantage of advanced
features provided by the GNOME backend while providing users with a more
traditional desktop experience.
* MATE Desktop: The MATE desktop provides users with a classic GNOME 2.x style
user interface. This desktop is perfect for users who have been running GNOME
Classic or other window managers like XFCE as an alternative to GNOME 3.
* KDE Plasma Workspaces 4.9: KDE Plasma Workspaces has been updated with many
new features and improved stability and performance, including updates to the
Dolphin File Manager, Konsole, and KWin Window manager.
* Xfce 4.10: The lightweight and easy-to-use Xfce desktop has been updated to
the 4.10 version with many bug fixes and enhancements, including a new MIME
type editor, a reworked xfce4-run dialog, improved mouse settings, tabs in the
Thunar file manager, and options to tile windows in xfwm4. Through all of these
and more, Xfce continues to improve without getting in your way.
Regardless of your desktop choice, Fedora 18 offers...
* Improved storage management: SSM (System Storage Manager) is an easy-to-use
command-line interface tool that presents a unified view of storage management
tools. Devices, storage pools, volumes, and snapshots can now be managed with
one tool, with the same syntax for managing all of your storage. (It's great
for systems administrators, too!)
=== For developers ===
For developers there are all sorts of moo-tivating goodies:
* Fresh versions of programming languages: Using Perl, Rails, or Python? All
three of these languages are updated in Fedora 18. We've got Rails 3.2, Python
3.3, and Perl 5.16 fresh off the farm.
* Clojure gets more love with the addition of tooling packages, including the
L
[Bug 895440] perl-threads-shared-1.43 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=895440 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Last Closed||2013-01-15 09:06:02 Status|ASSIGNED|CLOSED Fixed In Version||perl-threads-shared-1.43-1. ||fc19 -- 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=nDeaE6eyUZ&a=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
[Bug 895542] perl: Double-free when using subroutine load
Product: Security Response
https://bugzilla.redhat.com/show_bug.cgi?id=895542
--- Comment #3 from Jan Lieskovsky ---
Public reproducer information (from upstream bug [1]):
--
$ perl -MDigest::SHA -e 'my $d = Digest::SHA->new(256); $d->load("x");'
--
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=bJhS3UW8Zs&a=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: OpenImageIO 1.1.3 Build failure in Fedora rawhide
On Mon, Jan 14, 2013 at 7:16 PM, gil wrote: > Il 14/01/2013 21:10, Richard Shaw ha scritto: > > undefined reference to > `OpenImageIO::v1_1::CSHA1::Update(unsigned char const*, unsigned int)' > > take a look here > https://github.com/OpenImageIO/oiio/issues/473 > > hope it will be useful Thanks for the tip. I didn't think to look at a arch specific problem. I've occasionally had problem where it would build in mock but not on the build server so I assumed that was the case this time. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On Mon, Jan 14, 2013 at 04:42:59PM +0100, Xose Vazquez Perez wrote: > hi, > > As Fedora was pioneering in the libjpeg-turbo inclusion > maybe you are interested in this discussion. > > http://sourceforge.net/mailarchive/forum.php?thread_name=50E4AF86.50203%40users.sourceforge.net&forum_name=libjpeg-turbo-users Another interesting thread is http://sourceforge.net/mailarchive/message.php?msg_id=30352453 We are currently discussing drop of the https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature because SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was rejected by ISO and actually doesn't bring any benefit over widely used png/webp codecs. So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer reveals some new facts about SmartScale. All facts are currently against SmartScale (image quality/size, compression/decompression speed). Regards, Adam > Original Message > Subject: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future > role of this project > Date: 2013-01-01 08:32 > From: DRC dcommander > To: libjpeg-turbo-users > > I am not casting blame, because I realize that the libjpeg API, by > virtue of exposing all of its data structures, necessitates breaking > backward API/ABI compatibility whenever additional features are added. > Unfortunately, however, the reality is that jpeg-9 (due to be released > in a few weeks) has broken API/ABI compatibility yet again, introducing > a new field called "color_transform" to both jpeg_compress_struct and > jpeg_decompress_struct. This field was implemented to further support > generating lossless RGB JPEG files, which require the SmartScale format > that can only (currently) be decoded using the IJG's software. > > As most of you know, libjpeg-turbo has never really tried to be anything > other than a very fast implementation of baseline JPEG. We implemented > jpeg-7 and jpeg-8 API/ABI emulation at the behest of a commercial > software company, primarily so that their application could take > advantage of turbo baseline encoding/decoding without recompiling. > However, this also opened the door for libjpeg-turbo to be adopted by > other projects (including several O/S distros) that had already made the > switch to jpeg-7 or jpeg-8. I never actively sought this out, but I am > happy that others have found uses for libjpeg-turbo that go beyond the > initial scope of the project. Even though I'm the only maintainer, this > is a community project, and almost 100% of the modifications that have > been made to it have either been ideas that others paid me to implement > or code that others have contributed. > > Thus, I'm curious to hear your thoughts regarding jpeg-9 and the future > role of this project. My background is in computer architecture, > performance optimization, HPC, and visualization, so providing faster > implementations of existing algorithms is my strong suit, but improving > the algorithms themselves or supporting new formats isn't. I've never > tried to make libjpeg-turbo into a reference implementation or a home > for such new formats, but it seems like most people don't care about > anything but baseline anyhow. Thus, even though libjpeg-turbo doesn't > accelerate any other type of encoding/decoding, that has not seemingly > been a hindrance to its adoption. > > Although it is possible to stub out the new "color_transform" field as a > GNDN (goes nowhere/does nothing) feature and thus provide API/ABI > compatibility with jpeg-9, I don't really see the point of this unless > there are projects that might upgrade to jpeg-9 and then later want to > cross-grade to libjpeg-turbo (in which case, it seems more prudent to > address that situation when or if it arises.) It seems like most of the > justification for emulating the v7 and later libjpeg API/ABI may have > passed. It was needed to enable cross-grading for those who had already > upgraded, but at this point, projects have probably made the decision to > either go with more speed or to go with the format extensions offered in > jpeg-8 and later. > > My personal take on it is that tracking the upstream code may no longer > be a battle worth fighting. Most of the recent IJG changes (post > jpeg-8b) have been related to lossless JPEG encoding or SmartScale. > Best case, SmartScale is a new format that has not been adopted as a > standard yet and is not widely used, and worst case, it may be a mostly > useless extension. The IJG's method for generating lossless JPEG files > using SmartScale is interesting, but I struggle to think of a reason why > one would want to use SmartScale for any other purpose (apparently I'm > not the only one who struggles with this: > http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/). And it > hasn't been proven that the use of this extension for lossless encoding > is significantly better than, for
Re: Out of date (behind stable) build in testing
On Mon, 14 Jan 2013, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sun, 13 Jan 2013 20:55:16 -0600 Bruno Wolff III escribió: On Sun, Jan 13, 2013 at 12:30:19 -0700, Kevin Fenzi wrote: I'll untag it manually. If I had manually untagged it, would that have done the trick? I wasn't sure if that was all that was needed or if there was more too it? (I seemed to remember that testing tags could be changed by packagers.) you wouldnt have permissions to untag it manually. but yes thats whats needed. its likely due to a bug in bodhi with updates not being obsoleted right, or not being unpushed then being deleted. I have seen a problem like this if you submit 2 updates too close together then the second may not obsolete the first. The submitter does seem to be able to unpush problem updates though and they do seem to get obsoleted by subsequent updates. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
