devel January 2013

devel@lists.stg.fedoraproject.org

334 participants
368 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler 24 Oct '13

24 Oct '13

Hi, the current xine-lib maintainer speaking. :-) The Xine project: http://www.xine-project.org/home has recently released a new major version, version 1.2.0. Unfortunately, among the list of changes: http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/vi… there are these new "features": * Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms, this makes use of libavutil even outside the FFmpeg decoding plugin, but avoid duplication of algorithms between different plugins. * Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed. * FFmpeg is now required as an external dependency; if you want to build xine-lib from source, please download a copy of FFmpeg from their SVN server. which basically mean that xine-lib now has a global, non-optional dependency on FFmpeg's libavutil library. So there are 4 possible ways forward: (a) Stick with 1.1.x forever. I don't think that's a good idea in the long run, upstream won't be providing security fixes for the old branch forever. (b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't think libavutil, as opposed to libavcodec, is actually patent-encumbered, though that'd also have to be checked.) The issue there is that FFmpeg upstream obviously doesn't support this. It would need some more black packaging magic of the kind already done in xine-lib, and more legal auditing. I don't think I want to investigate going down that road. (c) Bundle parts or all of libavutil with xine-lib. Yuck!!! (d) Move the whole thing (back) to RPM Fusion (where it originally was, before we started needing xine-lib for Amarok and Phonon, which both no longer use it). It would go to the Free section, of course. My proposal is to go with (d). The following packages currently depend on xine-lib: * gxine * (k9copy – already in RPM Fusion, not affected) * kaffeine (my package, the reason why I maintain xine-lib in the first place) * oxine * xine-plugin * xine-ui These packages would have to move to RPM Fusion along with xine-lib. In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git repository, so it will likely have to move to RPM Fusion sooner or later anyway. This means the affected packages are basically *xine*. So my plan is to retire (for my packages, resp. have the respective maintainer retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the respective maintainer get) them into RPM Fusion Free instead. (I'd take care of xine-lib and kaffeine myself, I hope the maintainers of the other packages will take care of them.) Comments? Objections? Kevin Kofler

4 15

Review Sugar Activities
by Danishka Navin 04 Jun '13

04 Jun '13

Hi, I need a help from some who can review packages I have been created and push them to build system. Please note that I do only work with packaging on Sugar Activities and packaged 8 activities so far. https://bugzilla.redhat.com/show_bug.cgi?id=841239 https://bugzilla.redhat.com/show_bug.cgi?id=842107 https://bugzilla.redhat.com/show_bug.cgi?id=842101 Best Regards, -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin http://www.flickr.com/photos/danishkanavin/

2 5

appliance-creator: how can I shorten the grub timeout in kickstart?
by Matthew Miller 31 May '13

31 May '13

This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

9 34

replacing folders with symlinks leads to rpm cpio rename errors
by Julian Sikorski 28 May '13

28 May '13

Hi list, one of the updates I am preparing is supposed to replace some of the folders with symlinks. Unfortunately, this leads to rpm cpio: rename errors upon an update attempt. Is there a standard way of dealing with this? Regards, Julian

6 10

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

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

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

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 January 2013