SWAT will be removed from the Samba package
by Andreas Schneider
Hello,
the Samba Team has announced [1] that it will remove SWAT from the Samba
Suite. SWAT is unmaintained and has the most security bugs.
I plan to remove the samba-swat subpackage in Fedora 18, 19 and rawhide as
soon as it gets removed from the current Samba development tree.
Cheers,
-- andreas
--
Andreas Schneider GPG-ID: 8B7EB4B8
Red Hat asn(a)redhat.com
Samba Team asn(a)samba.org
10 years, 12 months
Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
by Simone Caronni
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).
11 years
Most buggy packages
by Miroslav Suchý
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
11 years, 1 month
Mass Rebuild for Fedora 19
by Dennis Gilmore
-----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
11 years, 1 month
64-bit stat (or not) in 32-bit Fedora binaries
by Eric Sandeen
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
11 years, 1 month
Drupal 8
by Shawn Iwinski
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
11 years, 2 months
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
by Jakub Jelinek
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 years, 2 months
system freezes after loading gdm/gnome
by mordae
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
11 years, 2 months
Re: Should MariaDB touch my.cnf in %post?
by Sergei Golubchik
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
11 years, 2 months
