devel February 2013

devel@lists.fedoraproject.org

286 participants
252 discussions

Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
by Simone Caronni 07 May '13

07 May '13

Spinning of from this, I think there is some mess around the Virtio drivers; I would be glad if someone could explain that to me. Sorry for the length of this mail but I could not shorten it. Let's say I would like to grab the latest virtio drivers and tools for my Windows guest and the accompanying source code; this is what I found: 1) Recent version from Fedora in iso format - No WHQL, no changelog, no QXL drivers, no Spice Agent available, no source - Updated every once in a while http://secondary.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ 2) Roughly the same versions of Fedora, in zip format - No WHQL, no changelog, no QXL drivers, no Spice Agent but the changelog available. - All the changelog points to an internal Redhat git repository. - From my understanding, these tarballs are the one that every once in a while make their way into the Fedora iso and the "pre WHQL" Redhat ones. - The source is there in a zip file. http://people.redhat.com/vrozenfe/ 3) Official Spice Agent (very old and buggy): http://spice-space.org/download/binaries/vdagent-win32_20111124.zip 4) Spice Guest Tools setup - Unofficial Spice Agent, built from the latest sources using the mingw based package: - Latest Fedora iso drivers - Recent built from source QXL driver, but unfortunately unsigned so it doesn't work properly in Fedora. - The Balloon Service is not installed as part of the setup http://spice-space.org/download/binaries/spice-guest-tools/ 5) Official RHEL drivers (need an account for this) - virtio-win-1.5.3-1.el6_3.noarch.rpm - Contains signed and WHQL drivers for everything. - Always a bit older than the Fedora ones. - Follows the same numbering and logs as no. 2. - Contains signed WHQL drivers for Windows XP and Windows 7 32/64 bits, but outside of the normal iso (why?) - Does not contain the Spice Agent. 6) Yan Vugenfirer's repository - Contains only source, and is public. - Does not match with Fedora or RHEL provided drivers. - Contains only the Virtio drivers, no Spice Agent or QXL driver. https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commits/master 7) QXL drivers for various targets - Sometime, someone builds an updated driver and posts it to the spice-devel mailing list. - All the drivers are not signed, of course. ====== So far, my best setup is to recreate an iso everytime there is an update to the following: - Latest Fedora drivers for Windows XP, 2003 - Latest QXL binary from the Spice Guest Tools for Windows XP - Latest signed RHEL drivers for Windows Vista and up - Latest signed QXL driver for Windows Vista and up - Latest Spice Agent binary from the Spice Guest Tools I would say this is suboptimal, especially when I try to explain someone moving from Windows that si trying to virtualize Windows on their newly converted laptop. At the best case, they don't have the QXL driver, causing lag in the desktop, no Spice Agent for cut&paste and usually a lot of problems with Windows 7. Before this, I used to compile drivers myself with the DDK following the instructions. This gave me the option to compile the QXL drivers for Windows 2003 and Windows 2008 targets as well, but I always had the same problems with signing. ====== Since all the problems go back to signing the binaries for making them work out of the box in Windows Vista/7/2008/2008r2/8, I would like to know if it's possible to do this from time to time: - Have Fedora build the latest Virtio drivers (this is already done) - Build also the Spice Agent for 32/64 bit (this is done at spice-space.orgas part of the Spice Guest Tools) - Build the latest QXL drivers for all the Windows targets supported by the Virtio drivers (I know the Windows 8 XWDM driver will come eventually later) - Sign everything with the Redhat key, as it's doing for the drivers at point 2. - Pack everything into an iso. I'm not asking for WHQL as I understand this is a "benefit" for the Redhat subscriptions. All the bits are there except they are dispersed everywhere, so I don't think it's a big effort. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).

8 19

Most buggy packages
by Miroslav Suchý 06 Apr '13

06 Apr '13

I was curious what is the most buggy [1] package in Fedora and I made this chart: http://tinyurl.com/bx6brjh Click on "Total" and you get it sorted from most buggy to least buggy. (I do not know if this sort flag can be made part of URL). Lazy to click? Here is Top 10:. Component NEW ASSIGNED TOTAL Package Review 943 384 1327 kernel 884 118 1002 gnome-shell 619 15 634 anaconda 463 85 548 xorg-x11-server 439 15 454 yum 335 14 349 python 334 5 339 tracker 294 8 302 control-center 205 1 206 rhythmbox 202 1 203 And most overloaded assignee is: http://tinyurl.com/a39bawg again click on "Total". Lazy to click? Here is Top 10: Assignee NEW ASSIGNED TOTAL nobody(a)fedoraproject.org 871 37 908 kernel-maint(a)redhat.com 680 63 743 xgl-maint(a)redhat.com 704 14 718 bnocera(a)redhat.com 635 20 655 otaylor(a)redhat.com 637 15 652 tbzatek(a)redhat.com 476 20 496 rstrode(a)redhat.com 460 28 488 mclasen(a)redhat.com 398 25 423 dakingun(a)gmail.com 373 9 382 dmalcolm(a)redhat.com 358 7 365 [1] I know there can be plenty of metrics, I just used this one. -- Miroslav Suchy Red Hat Systems Management Engineering

13 28

New Online search for the Fedora Source
by Pádraig Brady 04 Apr '13

04 Apr '13

Benjamin Boyter has recently indexed the entire Fedora Source code. I.E. all 2 billion lines, 11K packages, 132 GB of it. For details including search syntax, please see: http://www.pixelbeat.org/docs/fedora_source.html thanks, Pádraig.

4 4

Mass Rebuild for Fedora 19
by Dennis Gilmore 04 Apr '13

04 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 it was requested in https://fedorahosted.org/fesco/ticket/1004 that we do a mass rebuild for Fedora 19 for http://fedoraproject.org/wiki/Features/GCC48 Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support we will start the mass rebuild on 2013-02-12 This is a heads up that it will be done in a side tag and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEUx/4ACgkQkSxm47BaWffzcQCggHykVzb0MlCY+sXoHsbjbQxm aVgAnjTb32kw6gmXTwlrIxhnU+N2YHkD =fj3Q -----END PGP SIGNATURE----- _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

12 18

64-bit stat (or not) in 32-bit Fedora binaries
by Eric Sandeen 03 Apr '13

03 Apr '13

XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let inode numbers creep past 2^32 as well. While most applications don't care one bit about st_ino returned from a stat() call, the sad fact is that you'll get EOVERFLOW from stat32 if the inode number is too big to fit in 32 bits, even if you just wanted to get the file size. I have a script (http://sandeen.net/misc/summarise_stat.pl) which Greg Banks wrote; it can check a path or list of filenames for binaries which contain non-64bit-safe stat calls. A quick look over my F18 install finds the situation to be only slightly in favor of executables using 64-bit variants: # ./summarize-stat.pl /usr 270229 91.5% are scripts (shell, perl, whatever) 22633 7.7% don't use any stat() family calls at all 913 0.3% use 32-bit stat() family interfaces only 1335 0.5% use 64-bit stat64() family interfaces only 73 0.0% use both 32-bit and 64-bit stat() family interfaces and it's not just weird obscure packages: # ./summarize-stat.pl `rpm -ql sendmail` 69 78.4% are scripts (shell, perl, whatever) 2 2.3% don't use any stat() family calls at all 17 19.3% use 32-bit stat() family interfaces only Anyway, if you want to check your package(s) and maybe make them 64-bit-stat safe, the perl script above might help. It's more than just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to overflow any large values you get back from stat64 etc. Might be nice to get out ahead of this before, say, btrfs comes into wide use. I don't know if there could be any more of a formal effort in this direction? Thanks, -Eric p.s. here's a list of what was on my system that turned up hits: advancecomp-1.15-17.fc18.src.rpm alsa-tools-1.0.26.1-1.fc18.src.rpm at-3.1.13-10.fc18.src.rpm bc-1.06.95-7.fc18.src.rpm bluez-4.101-6.fc18.src.rpm brltty-4.3-12.fc18.src.rpm ccache-3.1.9-1.fc18.src.rpm cdparanoia-10.2-12.fc18.src.rpm cdrdao-1.2.3-16.fc18.src.rpm checkpolicy-2.1.11-2.fc18.src.rpm crash-6.0.8-2.fc18.src.rpm cronie-1.4.10-1.fc18.src.rpm cscope-15.8-3.fc18.src.rpm ctags-5.8-9.fc18.src.rpm dbus-1.6.8-2.fc18.src.rpm dbus-glib-0.100-1.fc18.src.rpm dconf-0.14.1-3.fc18.src.rpm deltarpm-3.6-0.11.20110223git.fc18.src.rpm diffstat-1.55-2.fc18.src.rpm doxygen-1.8.3-3.fc18.src.rpm dvd+rw-tools-7.1-10.fc18.src.rpm eclipse-4.2.2-0.1.git20121217.fc18.src.rpm ed-1.6-2.fc18.src.rpm elfutils-0.155-1.fc18.src.rpm enca-1.13-4.fc18.src.rpm espeak-1.46.02-6.fc18.src.rpm exempi-2.2.0-5.fc18.src.rpm expat-2.1.0-4.fc18.src.rpm fakeroot-1.12.4-5.fc18.src.rpm file-roller-3.6.3-1.fc18.src.rpm finger-0.17-47.fc18.src.rpm fontconfig-2.10.2-1.fc18.src.rpm fuse-2.9.2-1.fc18.src.rpm gcalctool-6.6.2-1.fc18.src.rpm GConf2-3.2.5-3.fc18.src.rpm glibc-2.16-28.fc18.src.rpm gnome-bluetooth-3.6.1-2.fc18.src.rpm gnome-font-viewer-3.6.2-1.fc18.src.rpm gnome-keyring-3.6.2-3.fc18.src.rpm gnome-session-3.6.2-3.fc18.src.rpm gnome-system-monitor-3.6.1-3.fc18.src.rpm gpm-1.20.6-26.fc18.src.rpm hostname-3.11-4.fc18.src.rpm hplip-3.12.11-1.fc18.src.rpm indent-2.2.11-7.fc18.src.rpm iok-2.1.3-2.fc18.src.rpm irda-utils-0.9.18-16.fc18.src.rpm isdn4k-utils-3.2-88.fc18.src.rpm js-1.8.5-12.fc18.src.rpm kbd-1.15.3-6.fc18.src.rpm krb5-1.10.3-5.fc18.src.rpm libbluray-0.2.3-1.fc18.src.rpm libdb-5.3.21-3.fc18.src.rpm libiptcdata-1.0.4-8.fc18.src.rpm libplist-1.8-5.fc18.src.rpm lrzsz-0.12.20-31.fc18.src.rpm ltrace-0.7.2-1.fc18.src.rpm mailx-12.5-7.fc18.src.rpm minicom-2.5-8.fc17.src.rpm mpage-2.5.6-11.fc18.src.rpm nautilus-3.6.3-4.fc18.src.rpm ncftp-3.2.5-4.fc18.src.rpm net-tools-2.0-0.2.20121106git.fc18.src.rpm newt-0.52.14-3.fc18.src.rpm nmap-6.01-9.fc18.src.rpm obex-data-server-0.4.6-4.fc18.src.rpm opencv-2.4.3-3.fc18.src.rpm opensp-1.5.2-15.fc18.src.rpm openssl-1.0.1c-7.fc18.src.rpm oprofile-0.9.8-3.fc18.src.rpm optipng-0.7.4-1.fc18.src.rpm pam_krb5-2.4.1-1.fc18.src.rpm pam_pkcs11-0.6.2-9.fc18.src.rpm php-5.4.11-1.fc18.src.rpm pinentry-0.8.1-8.fc18.src.rpm pinfo-0.6.10-6.fc18.src.rpm policycoreutils-2.1.13-55.fc18.src.rpm postfix-2.9.6-1.fc18.src.rpm procps-ng-3.3.3-2.20120807git.fc18.src.rpm qt-4.8.4-11.fc18.src.rpm rarian-0.8.1-8.fc18.src.rpm recordmydesktop-0.3.8.1-8.fc18.src.rpm sane-backends-1.0.23-4.fc18.src.rpm sendmail-8.14.6-2.fc18.src.rpm shared-mime-info-1.0-7.fc18.src.rpm socat-1.7.2.1-2.fc18.src.rpm spice-vdagent-0.12.1-1.fc18.src.rpm strace-4.7-2.fc18.src.rpm stunnel-4.53-2.fc18.src.rpm sudo-1.8.6p3-2.fc18.src.rpm swig-2.0.8-1.fc18.src.rpm sysprof-1.2.0-1.fc18.src.rpm systemtap-2.0-6.fc18.src.rpm sysvinit-2.88-9.dsf.fc18.src.rpm texlive-2012-16.20130205_r29034.fc18.src.rpm totem-3.6.3-2.fc18.src.rpm usermode-1.111-1.fc18.src.rpm valgrind-3.8.1-4.fc18.src.rpm virtuoso-opensource-6.1.6-1.fc18.src.rpm virt-viewer-0.5.4-3.fc18.src.rpm wavpack-4.60.1-4.fc18.src.rpm which-2.20-4.fc18.src.rpm xdg-user-dirs-0.14-3.fc18.src.rpm xorg-x11-server-1.13.2-2.fc18.src.rpm xorg-x11-xkb-utils-7.7-4.fc18.src.rpm

17 40

Drupal 8
by Shawn Iwinski 20 Mar '13

20 Mar '13

I have started packaging the development version of Drupal 8. There is still plenty of work to do (please help!) and I would also like to get the maintainers of drupal6 and drupal7 packages involved. Besides "simply" packaging Drupal itself, I am trying to implement some additional features: * provide RPM macros -- this will help simplify spec files * virtual packages (i.e. "drupal8(<drupal_machine_name>)") -- this will especially help with the requiring of sub-modules * virtual package auto-provides (parsed from *.info filenames) -- this allows a package to provide the main module itself as well as any sub-module(s) that are included * virtual package auto-requires (parsed from *.info files' "dependencies[]" entries) -- this will help simplify spec files * formalized packaging guidelines I must give major credit for the auto provides and requires to the nodejs and npm package owners as I took a lot from their setup. Drupal 8 itself is still in major development and this package will not be ready for Fedora for a good while. I am doing all of my work out of GitHub. If you would like to help out or review anything, please see the links below: Specs and issues: https://github.com/siwinski/drupal8-rpms Dev repos: http://repos.fedorapeople.org/repos/siwinski/drupal8/ Draft packaging guidelines: https://fedoraproject.org/wiki/User:Siwinski/Draft:Packaging:Drupal8 -- Shawn Iwinski Sr. Software Applications Engineer Red Hat, Inc. siwinski(a)redhat.com shawn.iwinski(a)gmail.com IRC: siwinski GPG: 0x7cd74d05

4 6

Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
by Jakub Jelinek 19 Mar '13

19 Mar '13

Hi! As part of preparations for possible switch of system compiler in F19 to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.7.2-9.fc19 to quickly remove from the list packages that fail for non-gcc related reasons. 11687 packages built fine, 933 packages failed to build with both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm (ignored for this analysis, unlikely to be gcc 4.8 related). The remaining packages, that failed to build with 4.8.0-0.1 and succeeded with 4.7.2-9 are listed below. 67 of these look like issues on the package side, 22 gcc bugs that were supposedly fixed by now upstream and thus should be ok in 4.8.0-0.3 when it is built next week and 3 are not yet fixed gcc issues. CCing Benjamin if he is again interested in writing http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this information useful. Besides build failures, the -Wsizeof-pointer-memaccess warning triggered in several packages that succeeded building, but it would be nice if package maintainers actually checked those and fixed up, most likely those are real package bugs. The list of such packages is included in first attachment. For the more aggresive loop optimizations if the loop contain undefined behavior, while it caused build failures just for 12 packages during the mass rebuild, supposedly more packages will be affected, just the problems weren't triggered during package build. Usually such loops are either turned into infinite loops that soon crash, or hang, or as can be seen on the perl-PDL case loops can be turned into just conditional non-looping code (e.g. when compiler assumes that it can validly loop just at most once). blktap-2.0.90-6.git20111216.62de90d.fc18.src.rpm cdrkit-1.1.11-14.fc19.src.rpm elfutils-0.155-1.fc19.src.rpm isomd5sum-1.0.9-2.fc18.src.rpm libopensync-plugin-opie-0.22-8.fc18.src.rpm linphone-3.5.2-4.fc18.src.rpm lldpad-0.9.45-3.fc19.src.rpm openvas-libraries-5.0.4-1.fc19.src.rpm pilot-link-0.12.5-13.fc18.src.rpm sh-elf-binutils-2.21-5.fc19.src.rpm packages built with -Werror, for which the new -Wsizeof-pointer-memaccess warning included in -Wall warns and -Werror makes a fatal error out of it bamf-0.2.104-4.fc18.src.rpm byzanz-0.3-0.5.fc17.src.rpm fvkbd-0.2.2-6.fc18.src.rpm gedit-collaboration-3.6.0-1.fc18.src.rpm gtkimageview-1.6.4-6.fc18.src.rpm gypsy-0.8-6.fc17.src.rpm libindicator-0.4.94-3.fc18.src.rpm ltrace-0.7.0-1.fc19.src.rpm mail-notification-5.4-64.git.eab5c13.fc19.src.rpm ModemManager-0.6.0.0-2.fc19.src.rpm physfs-2.0.2-3.fc18.src.rpm roboptim-core-0.5-6.fc18.src.rpm v8-3.10.8-2.fc18.src.rpm xen-4.2.0-6.fc19.src.rpm packages built with -Werror, for which the new -Wunused-local-typedefs warning included in -Wall warns and -Werror makes a fatal error out of it trafficserver-3.2.0-3.fc18.src.rpm package built with -Werror, and -Wmaybe-uninitialized warns about possibly uninitialized fields which are uninitialized if inc_gmtime_r returns -1 (and ink_time_current_mdy doesn't bother to check that return value) armacycles-ad-0.2.8.3.2-3.fc18.src.rpm irrlicht-1.8-1.fc19.src.rpm kdevelop-4.4.1-2.fc19.src.rpm kst-2.0.3-7.fc18.src.rpm maildrop-2.5.0-17.fc18.src.rpm megaglest-3.7.1-1.fc19.src.rpm opal-3.10.9-2.fc19.src.rpm oxygen-gtk2-1.3.1-1.fc19.src.rpm oxygen-gtk3-1.1.1-2.fc19.src.rpm supertuxkart-0.7.3-3.fc19.src.rpm syncevolution-1.3.2-1.fc19.src.rpm gcc bug - internal compiler error in inline_call, fixed upstream already, see http://gcc.gnu.org/PR55683 pari-2.5.3-1.fc19.src.rpm gcc bug - internal compiler error in LRA, fixed upstream already, see http://gcc.gnu.org/PR55775 avrdude-5.11.1-2.fc18.src.rpm gcc bug - internal compiler error in remove_redundant_iv_tests, fixed upstream already, see http://gcc.gnu.org/PR55684 openttd-1.2.2-1.fc19.src.rpm gcc bug - the package is built with LTO, and the problem is extremely hard to reduce, just rebuild without --with-lto for now b43-openfwwf-5.2-8.fc18.src.rpm ccache-3.1.8-1.fc18.src.rpm openchange-1.0-12.fc19.src.rpm openttd-opengfx-0.4.5-1.fc19.src.rpm samba-4.0.0-171.fc19.rc6.src.rpm /usr/include/stdc-predef.h issues gcc preprocessor now in C/C++ modes automatically includes <stdc-predef.h> header, packages which are using preprocessor for non-C/C++ code or doing weird things with the preprocessor might run into issues. For non-C/C++ code, it is always better to preprocess as assembly instead of C libxc-1.2.0-2.fc18.src.rpm /usr/include/stdc-predef.h issues - using cpp -C -ansi to preprocess Fortran sources is simply a very bad idea adobe-source-libraries-1.0.43-13.fc19.src.rpm asl-gcc.patch patch needs to be tweaked also for GCC 4.8 aws-2.11.0-11.fc19.src.rpm gprbuild-2011-5.fc18.src.rpm matreshka-0.3.0-2.fc19.src.rpm needs dependencies rebuilt with GCC 4.8 gnat cp2k-2.3-1.fc19.src.rpm loop iterator passed as INTENT(INOUT) argument, see http://gcc.gnu.org/PR30146 dragonegg-3.1-18.fc19.src.rpm needs to be ported to GCC 4.8+ flterm-1.0-1.rc3.fc18.2.src.rpm gedit-code-assistance-0.1.5-1.fc18.src.rpm hfsplus-tools-540.1.linux3-2.fc18.src.rpm clang needs to be updated not to require libstdc++-devel 4.7 gambas3-3.3.4-2.fc19.src.rpm gcc bug for --enable-checking=yes compiler only, see http://gcc.gnu.org/PR55878 distro compilers are always --enable-checking=release, so non-issue except for the testing compiler gccxml-0.9.0-0.13.20120309.fc19.src.rpm supposedly needs to be ported for GCC 4.8, some tests failed getdata-0.7.3-3.fc18.src.rpm GCC is now more aggresive in turning loops that invoke undefined behavior into endless loops. In test/get_uint32.c there is: uint32_t data_data[128]; int fd, n, error, r = 0; ... for (fd = 0; fd < 128; ++fd) data_data[fd] = fd * (0x02000001); When fd is 64 or above, fd * 0x02000001 overflows, which is invalid in C/C++ for signed types (int here). To fix use data_data[fd] = fd * 0x02000001U; or data_data[fd] = (uint32_t) fd * 0x02000001; etc. instead. sys_basher-1.1.24-3.fc18.src.rpm similarly to getdata bug: for(i=0;i<MAX_THREADS;i++) { csvt[i] = 0; seed[i] = (i + 1LL) * 0x0123456789ABCDEFLL; } again, should have been 1ULL or 0x0123456789ABCDEFULL (or both) ipv6calc-0.93.1-3.fc18.src.rpm similarly to getdata bug: for (i = 0; i < (int) (sizeof(newidentifier->in6_addr.s6_addr) / sizeof(newidentifier->in6_addr.s6_addr[0])); i++) { /* copy into */ newidentifier->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i]; newtoken->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i + 8]; }; s6_addr array size is 16 (i.e. i < 16 is the loop condition), digest array has size 16, but obviously for i 8 and above the [i + 8] accesses are all out of bounds. No idea what the code meant to do. mpir-2.6.0-2.fc19.src.rpm similarly to getdata bug, another clear out of bounds access in a loop: #define numberof(x) (sizeof (x) / sizeof ((x)[0])) ... for (oindex = 0; oindex <= numberof (offset); oindex++) { o = offset[oindex]; ... } hdf-4.2.8-1.fc19.src.rpm similarly to getdata bug: for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { ... ui32[i][j] = (uint32) ((i * 400000000) + j); /* range: 0 ~ 4-billion */ } ... } skf-1.99.0-1.fc18.2.src.rpm similar to getdata bug: #define BIG5P_TBL_LEN 23940 /* BIG5-Plus 190 * 126 */ ... #define HKSCS_FA_LEN 1140 /* f940 - fefe */ ... unsigned short big5a_uni_byte[BIG5P_TBL_LEN]; skf_ucode big5uao_fa_uni_byte[HKSCS_FA_LEN] = { ... }; ... for (j=0;j<HKSCS_FA_LEN;j++) { /* fa00 - */ big5a_uni_byte[BIG5P_TBL_LEN+j-950] = big5uao_fa_uni_byte[j]; }; yap-6.2.2-4.fc18.src.rpm similar to getdata bug: LAST_FLAG = 23 ... #define NUMBER_OF_YAP_FLAGS LAST_FLAG ... #define yap_flags Yap_heap_regs->yap_flags_field ... Int yap_flags_field[NUMBER_OF_YAP_FLAGS]; ... /* This must be done before initialising predicates */ for (i = 0; i <= LAST_FLAG; i++) { yap_flags[i] = 0; } avr-gcc-4.7.2-1.fc19.src.rpm gcc-4.7.2-9.fc19.src.rpm mingw-gcc-4.7.2-6.fc19.src.rpm msp430-gcc-4.6.3-2.fc19.src.rpm another occurrences of similar issue, fixed upstream with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186590 when using older gcc codebases (4.6 and 4.7 based), this needs to be backported. perl-PDL-2.4.10-4.fc19.src.rpm struct pdl_trans { ... pdl *pdls[1]; ... }; ... for(j=0; j<trans->vtable->nparents; j++) { if(trans->vtable->per_pdl_flags[j] & 0x01) { par_pvaf++; if(!trans->pdls[j]) {return;} pdl_make_physvaffine(trans->pdls[j]); } else { if(!trans->pdls[j]) {return;} pdl_make_physical(trans->pdls[j]); } } for(; j<trans->vtable->npdls; j++) { ... } From pdls[1] above the compiler figures out the first loop iterates at most once (otherwise it would be an out of bounds access). As the function is called with ->nparents ranging from 0 to roughly 11 and ->npdls ranging from 1 to roughly 14 if it happened to "work" before, it was purely by luck. glm-0.9.3.4-2.fc19.src.rpm test/core/core_setup_message.cpp needs to be adjusted to grok GLM_COMPILER_GCC48 inkscape-0.48.3.1-4.fc19.src.rpm qelectrotech-0.30-0.4.svn1844.fc18.src.rpm texmaker-3.5-1.fc19.src.rpm xmlcopyeditor-1.2.0.4-4.fc18.src.rpm stray comma at the end of declaration, see http://gcc.gnu.org/PR55368 struct A { void *member,; }; used to be accepted, now is rejected as invalid. kdbg-2.5.1-2.fc18.src.rpm lemonpos-0.9.4-5.fc19.src.rpm libaccounts-qt-0.31-6.fc18.src.rpm qgis-1.8.0-10.fc19.src.rpm rosegarden4-12.04-3.fc18.src.rpm scribus-1.4.1-3.fc19.src.rpm sir-2.4-1.fc18.src.rpm unixODBC-gui-qt-0-0.6.20120105svn98.fc18.src.rpm gcc bug, fixed upstream by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194816 llvm-3.1-12.fc19.src.rpm gcc bug, not fixed yet, see http://gcc.gnu.org/PR55875 openjpa-2.2.1-1.fc19.src.rpm flaky (every time failed in a different spot) java issue, not clear if in any way related to gcj/libgcj python-webob1.2-1.2.1-8.fc19.src.rpm flaky (every time failed in a different spot), doesn't contain any non-python code, so I don't see how it could be related to gcc snapper-0.1.0-1.20121026git1aaa372.fc19.src.rpm includes <auto_ptr.h> which is declared to be a libstdc++ internal header not supposed to be included directly, see http://gcc.gnu.org/PR55866 sunpinyin-2.0.4-0.4.fc18.src.rpm seems to be flaky SConstruct, with scons -j16 install (or even -j4) it usually fails to install, with -j1 or -j2 it always succeeds zarafa-7.0.9-1.fc19.src.rpm gcc bug, fixed upstream already, see http://gcc.gnu.org/PR55877 blender-2.64a-2.fc19.src.rpm centerim-4.22.10-6.fc18.src.rpm HippoDraw-1.21.3-6.fc19.src.rpm meshlab-1.3.1-7.fc18.src.rpm /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character ('/builddir/build/BUILD/' vs '/usr/src/debug/') See https://bugzilla.redhat.com/show_bug.cgi?id=304121 , avoid using double slashes in path names and filenames. E.g. for centerim it is in AM_CPPFLAGS = -I$(top_srcdir)/kksystr/include -I$(top_srcdir)//kkstrtext (note the useless // there, just making it / fixes this issue). Jakub

11 16

system freezes after loading gdm/gnome
by mordae 18 Mar '13

18 Mar '13

Hi, I am running rawhide for fun and since a few days ago a few seconds after starting gdm the whole system freezes. I am sorry that I can't really pinpoint the exact update as I suspend and this only manifested after a reboot. The problem is that I don't get any logs and running startx with "exec gnome-session" in .xinitrc leads to the exactly same problem. Interestingly, if I run just "gnome-terminal" from my .xinitrc, close it and then re-run with full gnome-session, I get the shell and everything seems to work. Well, except it is somewhat sluggish, suggesting some hidden breakage. Any advices? Best regards, Jan Dvorak

12 15

Re: Should MariaDB touch my.cnf in %post?
by Sergei Golubchik 17 Mar '13

17 Mar '13

Hi! On Feb 12, Honza Horak wrote: >> grep -q '!includedir /etc/my.cnf.d' /etc/my.cnf || \ >> (echo; echo '!includedir /etc/my.cnf.d') >> /etc/my.cnf > > Thanks for that idea. It would work, but honestly I'm not sure if we > want touch my.cnf during update. I've shared this idea with other > fedora developers to collect their opinions -- feel free to join the > discussion at: > > http://lists.fedoraproject.org/pipermail/devel/2013-February/178475.html So, here I am, replying... On Feb 12, Reindl Harald wrote > any real used mysqld will have a customized /etc/my.cnf and no admin > should do this migartion without take really care what happens and > test this before - unclean soltutions will hurt sooner or later > in moments where this is not expected The solution in my email was clean, as far as I could see. /etc/my.cnf.d directory is empty in our packages (there are files in it, but they contist of comment lines only), so it cannot break anything if added to my.cnf On Feb 12, Toshio Kuratomi wrote > There are several reasons that user's config files shouldn't be touched: > > * Possibility of getting the change to the user's config wrong is very high > as user's can change their config in arbitrary ways. Do you handle the > case where a user has added their own includedirs? Do you handle the case > where a user has commented out their own includedir? Do you handle the > case where a user has a comment about includedir? Do you handle the case > where a user has deleted the includedir line? There are many corner cases > that can be missed here. Yes, it handles the case where a user has added his own includedirs. Yes, it handles the case where a user has commented out his own includedir. Yes, it handles the case where a user has a comment about includedir. Yes and no. If the user has deleted the includedir line, it will be added back. It is, probably, not what the user wants [thus "no"], but achieves exactly the same effect as the other proposed solution (automatically read files in /etc/my.cnf.d/ no matter what's in /etc/my.cnf) [thus "yes"] > * User expectation is currently that their configs aren't going to change on > version upgrade. Instead, they need to look for .rpmnew and .rpmsave > files to tell them if anything has changed that they need to be aware of. > A user updating to F19 won't be expecting that files in /etc/my.cnf.d > should affect their installation if they didn't have to migrate that over > from the my.cnf.rpmnew file themselves. Okay, so you suggest to do nothing - neither append the includedir line to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically and implicitly. That's fine :) I was only trying to find an alternative to "let mariadb read /etc/my.cnf.d implicitly" - because I don't like an idea of adding more magic to the server, it has more than enough of it already. Regards, Sergei -- MariaDB.org

26 93

Self introduction
by Ben Harper 13 Mar '13

13 Mar '13

Hello Fedora faithful, My name is Ben Harper and work for Rackspace as a RPM developer in Austin, TX. My duties include creating RPMs for internal use, but also for iuscommunity.org (IUS). IUS provides new versions of packages found in RHEL. I am looking to become a package maintainer for EPEL. There are some cases where IUS packages have dependences that are not available from packages provided by RHEL and should be provided by EPEL. Currently I do not have package I am looking to get approved, but just looking for a sponsor. I would like to prove that I can follow the documation and create quality packages. I have been reading over the docs and created the needed accounts with this email account. -Ben

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2013