Core file location and abrt
[I sent this to the users list a little while ago, but got no takers. Hopefully I'll have better luck here.] I'd like to ensure core files go to a local partition rather than the default location ($HOME), which is network-mounted in my case. Googling a bit, I found this: https://access.redhat.com/site/solutions/61536 In light of that, a few questions... Does this still apply to abrt in Fedora 19? That page suggests that when abrt is in use, core files would be generated in the location set by abrt, which defaults to /var/spool/abrt. However, I have abrtd running and I'm definitely getting core files in $HOME. Does abrt just make a copy to put in /var/spool/abrt? Might my problem be resolved as simply as telling abrt not to make a copy? I'd be fine with just having the core files in /var/spool/abrt. Otherwise, I imagine I'd like them somewhere named /var/users/$USER/dump (or similar). How do I do that and continue to play nicely with abrt? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Core file location and abrt
On Mon, 2013-11-11 at 20:00 -0600, Michael Catanzaro wrote: On Mon, 2013-11-11 at 15:50 -0500, Braden McDaniel wrote: That page suggests that when abrt is in use, core files would be generated in the location set by abrt, which defaults to /var/spool/abrt. However, I have abrtd running and I'm definitely getting core files in $HOME. Does abrt just make a copy to put in /var/spool/abrt? My naive answer is: check the DumpLocation setting in /etc/abrt.conf. The default is /var/tmp/abrt. If that doesn't work for you, it smells like a bug. DumpLocation is unset. Given that this is the case, are you saying that I shouldn't be getting core files in $HOME at all? Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F18 Beta: Freeze during boot
On Dec 5, 2012, at 3:35 AM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-12-05 at 00:08 -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 12:06 -0500, Braden McDaniel wrote: I posted about this a couple of days ago to the test list; but I've gotten no response so I'm fishing here. I'm not sure if this is a genuine freeze; but I have not managed to elicit a response to keyboard/mouse input. When booting Fedora 18 Beta, I see this: dracut-cmdline[121]: /etc/locale.conf: line1: locale.LANG=en_US.UTF-8: command that line appears to be truncated, but it almost seems like it's trying to run 'locale.LANG=en_US.UTF-8' as a command, which would be odd. Ah, actually that seems to be https://bugzilla.redhat.com/show_bug.cgi?id=870632 , and it's not likely the cause of the problem, just a cosmetic bug. Alright... Thanks for looking. I've filed a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=883940 Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F18 Beta: Freeze during boot
I posted about this a couple of days ago to the test list; but I've gotten no response so I'm fishing here. I'm not sure if this is a genuine freeze; but I have not managed to elicit a response to keyboard/mouse input. When booting Fedora 18 Beta, I see this: dracut-cmdline[121]: /etc/locale.conf: line1: locale.LANG=en_US.UTF-8: command dracut-pre-udev[193]: rpc.idmapd: Could not find group nfsnobody And a whole bunch of these: [2.160931] [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up I don't think the latter is related; I'm pretty sure I was seeing it before this problem started and it seemed reasonably innocuous. (And I think I recall a web search that suggested it may be related to my use of a DisplayPort-to-dual-link DVI adapter.) I did set up NFS/autofs on the box; and I believe I got it working. However, it's possible that I started seeing this problem at the first reboot *after* having set up NFS/autofs. (Or maybe the second one?) Not sure if I should file a bug on this (let alone what component I should file it against). Whatever I did, I'm inclined to think that failing to boot is not a reasonable thing. Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: openvrml
On Thu, 2012-05-17 at 14:56 +, build...@fedoraproject.org wrote: openvrml has broken dependencies in the rawhide tree: On x86_64: openvrml-java-0.18.9-2.fc18.x86_64 requires java-1.6.0-openjdk(x86-64) On i386: openvrml-java-0.18.9-2.fc18.i686 requires java-1.6.0-openjdk(x86-32) Please resolve this as soon as possible. openvrml BuildRequires java-devel. At first, I though the provider for java-devel just changed and I happened to be unlucky timing-wise; so I rebuilt openvrml. But I'm still seeing this. How come? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: openvrml
On Thu, 2012-05-17 at 21:22 -0500, Dennis Gilmore wrote:
El Thu, 17 May 2012 21:51:40 -0400
Braden McDaniel bra...@endoframe.com escribió:
On Thu, 2012-05-17 at 14:56 +, build...@fedoraproject.org wrote:
openvrml has broken dependencies in the rawhide tree:
On x86_64:
openvrml-java-0.18.9-2.fc18.x86_64 requires
java-1.6.0-openjdk(x86-64) On i386:
openvrml-java-0.18.9-2.fc18.i686 requires
java-1.6.0-openjdk(x86-32) Please resolve this as soon as possible.
openvrml BuildRequires java-devel. At first, I though the provider
for java-devel just changed and I happened to be unlucky timing-wise;
so I rebuilt openvrml. But I'm still seeing this. How come?
your spec file has
Requires: java-1.6.0-openjdk%{?_isa}
we no longer have java-1.6.0-openjdk we have java-1.7.0-openjdk
So it does. Thank you.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mock and non-local user accounts
On Sun, 2012-05-06 at 09:34 +0200, Niels de Vos wrote: On 6 May 2012 03:19, Braden McDaniel bra...@endoframe.com wrote: Does mock have problems with non-local user accounts? When I do $ fedpkg mockbuild I get: ERROR: Must be member of 'mock' group to run mock! (['users']) Traceback (most recent call last): File /usr/sbin/mock, line 520, in module def do_buildsrpm(config_opts, chroot, options, args): File /usr/sbin/mock, line 619, in main groupcheck(unprivGid) File /usr/sbin/mock, line 576, in groupcheck raise RuntimeError, Must be member of 'mock' group to run mock! (%s) % sorted(set(members)) RuntimeError: Must be member of 'mock' group to run mock! (['users']) I guess you have /usr/sbin before /usr/bin in your path. That does not appear to be the case: $ echo $PATH /home/braden/x86_64-redhat-linux-gnu/bin:/home/braden/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin This is happening on an up-to-date Fedora 16 installation. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mock and non-local user accounts
Does mock have problems with non-local user accounts? When I do $ fedpkg mockbuild I get: ERROR: Must be member of 'mock' group to run mock! (['users']) Traceback (most recent call last): File /usr/sbin/mock, line 520, in module def do_buildsrpm(config_opts, chroot, options, args): File /usr/sbin/mock, line 619, in main groupcheck(unprivGid) File /usr/sbin/mock, line 576, in groupcheck raise RuntimeError, Must be member of 'mock' group to run mock! (%s) % sorted(set(members)) RuntimeError: Must be member of 'mock' group to run mock! (['users']) And, yet: $ groups users desktop_admin_r ccache mock Does mock have a problem with the fact that my user account information is coming from LDAP? (And where is the proper place to report mock bugs? fedorahosted trac or Red Hat Bugzilla?) -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On Thu, 2011-07-28 at 08:41 -0400, Genes MailLists wrote: On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: On 07/28/2011 12:46 PM, Genes MailLists wrote: This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). Currently Fedora only separates out the /lib* directories in multilib installations - you'll find a mix of 32 and 64 bit binaries in the system binary paths on these systems. which is fine for a 'system' which is 64 bit and may support 32 bit as well - its not fine for a 'user' who logs in to a 32 bit machine from a 64 bit machine and now his binaries wont work. Really, sharing of $HOME can (and does) happen among much *more* disparate architectures than x86 and x86_64. We don't have to think about this as much these days now that MIPS and SPARC have waned in popularity; but the idea that we might start seeing a lot more consumer-oriented ARM devices running Linux isn't exactly far-fetched. I typically use ~/`config.guess`/bin. As it stands, ~/bin and ~/.local/bin are only appropriate for binaries that are not arch-specific. Any standard that doesn't take that into account needs some improvement. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On Wed, 2011-07-27 at 09:11 +0200, Nicolas Mailhot wrote: Le mercredi 27 juillet 2011 à 00:01 -0400, Braden McDaniel a écrit : Can someone explain (or point to) the rationale appending these to PATH rather than prepending them? I would have expected user binaries to supersede system ones. Security. You can do all kinds of mischief by overriding an (audited) system command with a user-level command (even appending is IMHO borderline dangerous till the usual infection/attack vectors, MUAs browsers have not been taught to triple-check and flag anything going there) Oh. So, user account-level security for user accounts that have already been compromised. Right. Say no more. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On Tue, 2011-07-26 at 08:45 -0430, Robert Marcano wrote: On 07/26/2011 08:36 AM, Genes MailLists wrote: On 07/26/2011 08:03 AM, Misha Shnurapet wrote: 26.07.2011, 18:34, Andrew Haleya...@redhat.com: On 26/07/11 10:22, Misha Shnurapet wrote: Since F15 ~/bin has been added to PATH, and commands that are supposed to run user scripts will work without changing into that directory. Meanwhile, ~/.local/bin isn't used. I'd like to propose that it is also added because technically it is ~/bin's brother. I've never heard of ~/.local/bin . Are there many people who use this? ~/bin is common. ~/.local/bin has been there by default. Unlike ~/bin, which is in PATH though not even created. Where in the path do the user 'bin' elements appear in the path? In /etc/skel/.bash_profile they are added to the end and I think that is ok PATH=$PATH:$HOME/.local/bin:$HOME/bin Never knew about ~/.local/bin my .bash_profile is really old from the time where the default was only ~/bin Can someone explain (or point to) the rationale appending these to PATH rather than prepending them? I would have expected user binaries to supersede system ones. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Failure to find ltdl.h in mockbuild
I'm getting this configure failure when doing an F16 mockbuild (on my F15 system): checking ltdl.h usability... no checking ltdl.h presence... no checking for ltdl.h... no configure: error: in `/builddir/build/BUILD/openvrml-0.18.8': configure: error: ltdl.h not found The package has: BuildRequires: libtool-ltdl-devel Why might this be happening? Did ltdl.h get moved? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
abrt finding closed bugs
From abrt: Logging into Bugzilla at https://bugzilla.redhat.com Checking for duplicates Bug is already reported: 701604 Logging out Status: CLOSED INSUFFICIENT_DATA https://bugzilla.redhat.com/show_bug.cgi?id=701604 Should this have resulted in the bug being reopened with the new stack trace attached? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide and LDAP
On Thu, 2011-02-10 at 08:18 -0500, Stephen Gallagher wrote: I suspect you are using SSSD to handle LDAP logins. This was broken in rawhide yesterday because I pushed a new version of libldb that apparently broke ABI without an SO bump. I have subsequently reverted this change. Please downgrade to libldb-0.9.10-25.fc15 and SSSD will work again. Figuring this would be fixed by now, I upgraded to libldb-1.0.2-1.fc16; but now I'm seeing the same problem again. What's the state of this? (Unfortunately, yum is no longer letting me downgrade after upgrading to this version.) -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On Sun, 2011-02-13 at 13:30 +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Hello. Few day ago I asked [1] build js without UTF-8 C strings. But before that was opposite request. As acceptable solution found update to recent version, starting from 1.8.0-rc1 [2]. But it have also known bugs and we move to 1.8.5 version from Firefox 4.0 [3] mercurial repository. 1.8 version introduce runtime UTF-8 support [4]. So, to use new version of js with UTF8 C strings support not enough to just rebuild and relink. Instead you need patch (or better ask upstream to do that) you software to add call function JS_SetCStringsAreUTF8. See [4] for more details. I plan build it today (I have still some troubles in it) and push in rawhide in middle of next week. Also in future it is suggested for F15 branch. In CC owners of dependent packages. [1] https://bugzilla.redhat.com/show_bug.cgi?id=676441 [2] https://developer.mozilla.org/En/SpiderMonkey/1.8 [3] https://developer.mozilla.org/en/javascript [4] https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8 Isn't there yet more breakage coming, as well? https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 Perhaps we should just wait for this? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On Sun, 2011-02-13 at 20:23 -0800, Christopher Aillon wrote: On 02/13/2011 12:32 PM, Braden McDaniel wrote: Isn't there yet more breakage coming, as well? https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 Perhaps we should just wait for this? Those patches already landed in tracemonkey on Wednesday and mozilla-central on Friday. Okay... I'm not sufficiently well versed in Mozilla development terminology to know whether that means that it'll be in the next XULRunner prerelease package in rawhide; but I think I can gather from the context of your statement that it does mean that. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide and LDAP
On Thu, 2011-02-10 at 08:18 -0500, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/09/2011 12:31 PM, Braden McDaniel wrote: On Wed, 2011-02-09 at 14:36 +0100, Jan Vcelak wrote: On Wednesday 09 February 2011 06:10:25, Braden McDaniel wrote: Something in a recent round of updates seems to have hosed use of LDAP-based user accounts for my rawhide installation. (My LDAP server is on a different machine; the rawhide one just doesn't seem to be able to use it.) Hi Braden, please, can you be more specific? Which versions of openldap-servers, openldap-clients, pam_ldap, nss_ldap, etc. do you have installed? openldap-servers, pam_ldap, and nss_ldap are not installed on the rawhide machine. openldap-clients is version 2.4.23-8.fc15. The server is running Fedora 14. It has: openldap-servers: 2.4.23-4.fc14 openldap-clients: 2.4.23-4.fc14 pam_ldap: 185-5.fc14 nss_ldap: 265-6.fc14 Are you using SSL/TLS? No. Is ldapsearch on your rawhide machine working? It is. What's not working is logging in as a user other than root. I can't even su to a user other than root. I am using Kerberos for user authentication; however, kinit user works fine from the rawhide machine. I suspect you are using SSSD to handle LDAP logins. Correct. This was broken in rawhide yesterday because I pushed a new version of libldb that apparently broke ABI without an SO bump. I have subsequently reverted this change. Please downgrade to libldb-0.9.10-25.fc15 and SSSD will work again. That did it. Thanks! -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide and LDAP
On Wed, 2011-02-09 at 14:36 +0100, Jan Vcelak wrote: On Wednesday 09 February 2011 06:10:25, Braden McDaniel wrote: Something in a recent round of updates seems to have hosed use of LDAP-based user accounts for my rawhide installation. (My LDAP server is on a different machine; the rawhide one just doesn't seem to be able to use it.) Hi Braden, please, can you be more specific? Which versions of openldap-servers, openldap-clients, pam_ldap, nss_ldap, etc. do you have installed? openldap-servers, pam_ldap, and nss_ldap are not installed on the rawhide machine. openldap-clients is version 2.4.23-8.fc15. The server is running Fedora 14. It has: openldap-servers: 2.4.23-4.fc14 openldap-clients: 2.4.23-4.fc14 pam_ldap: 185-5.fc14 nss_ldap: 265-6.fc14 Are you using SSL/TLS? No. Is ldapsearch on your rawhide machine working? It is. What's not working is logging in as a user other than root. I can't even su to a user other than root. I am using Kerberos for user authentication; however, kinit user works fine from the rawhide machine. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: --disable-dependency-tracking
On Wed, 2011-02-09 at 19:39 -0500, Neal Becker wrote: I just tried rpmbuild -ba blah.spec and got configure: error: unrecognized options: --disable-dependency-tracking I see /var/lib/rpm/redhat/macros: %configure \ ... --disable-dependency-tracking \\\ So maybe I need to add autoreconf --force before %configure to regenerate configure for new option. Nope. Still same error. Any ideas? What package is this? Are you quite certain its configure is autoconf-derived? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On Tue, 2011-02-08 at 09:16 +0100, Lennart Poettering wrote: On Fri, 04.02.11 13:31, Braden McDaniel (bra...@endoframe.com) wrote: On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote: On Mon, 31.01.11 02:22, Braden McDaniel (bra...@endoframe.com) wrote: I've recently set up a virtual machine running rawhide and I've noticed that NetworkManager never seems to start on boot; I must always start it manually. As far as I can tell, it is configured to start on boot. Is there something about the virtual machine context that would trigger this? what does systemctl status NetworkManager.service say? After booting and logging in as root: # systemctl status NetworkManager.service NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service) Active: inactive (dead) CGroup: name=systemd:/system/NetworkManager.service Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service ; echo $? ? # systemctl is-enabled NetworkManager.service ; echo $? 1 I'm not sure whether 1 means it is or it isn't; but system-config-services claims it's enabled. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote: On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote: what does systemctl status NetworkManager.service say? After booting and logging in as root: # systemctl status NetworkManager.service NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service) Active: inactive (dead) CGroup: name=systemd:/system/NetworkManager.service Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service ; echo $? ? # systemctl is-enabled NetworkManager.service ; echo $? 1 So, it isn't enabled. A zero exit code means it is enabled, a non-zero exit code means it isn't. (that's normal unix logic, even if it appears reversed) Try enabling it via systemctl enable NetworkManager.service Not sure what went wrong here, but normally this fragment in Networkmanager.spec should ensure that the systemd service gets enabled on upgrades from sysv versions: %triggerin -- NetworkManager 1:0.8.1-5 if /sbin/chkconfig NetworkManager ; then /bin/systemctl enable NetworkManager.service /dev/null 21 || : fi or is this a fresh install? if so, I am not entirely sure whose job it is to enable NM initially after install. Dan? I installed F14 from DVD and immediately did a yum upgrade to rawhide. I'm not sure whether 1 means it is or it isn't; but system-config-services claims it's enabled. s-c-s only covers sysv services. We probably should deprecate it or at least add a bit of code to point out that whether a service is on or off in sysv is ignored for native systemd services. Why not fix it? That is, why should a user of this app care whether a service is SysV or systemd? Or, is this app being replaced by some other UI? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide and LDAP
Something in a recent round of updates seems to have hosed use of LDAP-based user accounts for my rawhide installation. (My LDAP server is on a different machine; the rawhide one just doesn't seem to be able to use it.) Is anyone else seeing this? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote: On Mon, 31.01.11 02:22, Braden McDaniel (bra...@endoframe.com) wrote: I've recently set up a virtual machine running rawhide and I've noticed that NetworkManager never seems to start on boot; I must always start it manually. As far as I can tell, it is configured to start on boot. Is there something about the virtual machine context that would trigger this? what does systemctl status NetworkManager.service say? After booting and logging in as root: # systemctl status NetworkManager.service NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service) Active: inactive (dead) CGroup: name=systemd:/system/NetworkManager.service -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On 2/4/11 3:10 PM, Bastien Nocera wrote: On Fri, 2011-02-04 at 14:33 +0100, Petr Machata wrote: Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? Because of boost changes between December and yesterday, I wasn't able to recompile gnote: https://bugzilla.gnome.org/show_bug.cgi?id=641416 The build failures are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872 It's critical if we want gnote in F15's GNOME desktop. Isn't boost.m4 just some third-party macro? Perhaps upstream could be encouraged not to use it? It seems rather pointless to me. That is, it looks like it's checking a bunch of things that don't need checking. AFAIK, the only configuration information one needs to divine about Boost is the library name suffix. If one guesses that Boost libraries will end in -mt, one will be correct a large majority of the time. When that's wrong, one might want to make a few other guesses--or punt and make the user supply the suffix at configure time (which is not at all unreasonable, since the complete list of possible suffixes is *quite* long). Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On 2/4/11 4:11 PM, Bastien Nocera wrote:
On Fri, 2011-02-04 at 15:41 -0500, Braden McDaniel wrote:
On 2/4/11 3:10 PM, Bastien Nocera wrote:
[snip]
Could we please either have boost.m4 packaged in Fedora, or at least
changes for running with the latest boost in Fedora integrated upstream?
Because of boost changes between December and yesterday, I wasn't able
to recompile gnote:
https://bugzilla.gnome.org/show_bug.cgi?id=641416
The build failures are here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872
It's critical if we want gnote in F15's GNOME desktop.
Isn't boost.m4 just some third-party macro?
Perhaps upstream could be encouraged not to use it?
[snip]
I'm pretty sure the gnote developers would take any patches to remove
that code, as long as it did detection as you mentioned above. If boost
provided a pkg-config file, or their own macros, I'm pretty sure that
gnote wouldn't be using it.
I don't know enough about boost to make those changes myself, and wading
through 2 tarballs of 40 megs each to figure out the library layout of
boost is a bit beyond me.
I am pretty sure that wading is unnecessary.
All I do in my own Boost-dependent project is this:
---
AS_IF([test -z ${BOOST_LIB_SUFFIX+x}], [BOOST_LIB_SUFFIX=-mt])
AC_ARG_VAR([BOOST_LIB_SUFFIX], [Boost library name suffix [default=-mt]])
AC_CACHE_CHECK([for boost_thread$BOOST_LIB_SUFFIX library],
[ov_cv_boost_thread],
[ov_cv_boost_thread=no
ov_save_LIBS=$LIBS
LIBS=-lboost_thread$BOOST_LIB_SUFFIX $LIBS
AC_LANG_PUSH([C++])
AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include boost/thread.hpp]],
[[boost::thread t]])],
[ov_cv_boost_thread=yes])
AC_LANG_POP
LIBS=$ov_save_LIBS
])
AS_IF([test X$ov_cv_boost_thread = Xno],
[AC_MSG_FAILURE([libboost_thread$BOOST_LIB_SUFFIX not found])])
---
Then, references to Boost libraries in Makefile.am need to look like
-lboost_foo$BOOST_LIB_SUFFIX.
And you're done.
As you can see, I don't do any detection of the Boost library suffix;
and I don't have a very high opinion of attempts to do so. Indeed, I'm
generally of the mind that attempts simply to detect features that are
implemented consistently (when present at all) are misguided. When such
diagnostics are trivial or incidental, they're fine. But as soon as
they're the least bit nontrivial, you've got an unnecessary test that
can break--and that's a very silly reason for your package to stop building.
Braden
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On 2/3/11 1:33 PM, Dan Williams wrote: On Mon, 2011-01-31 at 02:22 -0500, Braden McDaniel wrote: I've recently set up a virtual machine running rawhide and I've noticed that NetworkManager never seems to start on boot; I must always start it manually. As far as I can tell, it is configured to start on boot. Is there something about the virtual machine context that would trigger this? Rawhide? F14? I've recently set up a virtual machine running rawhide There is a known issue in Rawhide with systemd that hasn't been tracked down yet, but it should be working in F13/F14 as long as NM is enabled in chkconfig. Indeed, I have not observed the issue on F14. Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On 2/1/11 6:02 PM, Daniel J Walsh wrote: On 02/01/2011 05:05 PM, Braden McDaniel wrote: On 1/31/11 4:04 PM, Naheem Zaffar wrote: There seems to be an SElinux denial for me which stops it from starting (I upgraded from Fedora 14 and its NOT a live machine). I would assume its the same error? So far, I have not identified an SELinux denial that appears to be associated with this. But I'll keep looking. Braden ausearch -m avc -ts today Does it work in permissive mode? If not then why do you think this is an SELinux issue? I never said I did; it was just an avenue of investigation that was suggested here. Based on others' comments (and the fact that I haven't found anything corroborating), it looks like a dead end. Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On 1/31/11 4:04 PM, Naheem Zaffar wrote: There seems to be an SElinux denial for me which stops it from starting (I upgraded from Fedora 14 and its NOT a live machine). I would assume its the same error? So far, I have not identified an SELinux denial that appears to be associated with this. But I'll keep looking. Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NetworkManager doesn't start on boot
I've recently set up a virtual machine running rawhide and I've noticed that NetworkManager never seems to start on boot; I must always start it manually. As far as I can tell, it is configured to start on boot. Is there something about the virtual machine context that would trigger this? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Inspecting/debugging a mock build
I'm pretty much a novice at both mock and chroot. Where can I find out how to change to the mock build chroot (using fedpkg or otherwise) so that I can debug a failed mock build? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inspecting/debugging a mock build
On Sun, 2010-09-05 at 21:54 -0400, seth vidal wrote:
On Sun, 2010-09-05 at 21:33 -0400, Braden McDaniel wrote:
I'm pretty much a novice at both mock and chroot. Where can I find out
how to change to the mock build chroot (using fedpkg or otherwise) so
that I can debug a failed mock build?
mock -r name-of-root-config --shell
that'll get you into the chroot
Thanks. Now, how do I get fedpkg to preserve it? I see (when doing
fedpkg mockbuild):
INFO: Cleaning up build root ('clean_on_failure=True')
So, where do I set clean_on_failure to False?
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inspecting/debugging a mock build
On Mon, 2010-09-06 at 00:03 -0400, Matt McCutchen wrote:
On Sun, 2010-09-05 at 23:57 -0400, Braden McDaniel wrote:
Thanks. Now, how do I get fedpkg to preserve it? I see (when doing
fedpkg mockbuild):
INFO: Cleaning up build root ('clean_on_failure=True')
So, where do I set clean_on_failure to False?
In /etc/mock/site-defaults.cfg or the file for the root configuration
you're using. The option is actually called cleanup_on_failure; the
message is wrong.
Success. Thanks, folks.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On Fri, 2010-06-25 at 16:27 -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can anybody tell me what went wrong with this update? It was submitted at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was submitted for stable two hours later. Between that submission and the push to stable (push to stable happened at 18:09 on 06-25) numerous negative karma came in due to broken deps. The update went out anyway, and now we have a mess of broken updates on a critical path package, and have to scramble to fix it with more updates, on a Friday. Can anybody help me understand the scenario here? Should we start filtering out push requests that have more than -2 karma? Updating F13 now works; but a yum upgrade from F12 still seems busted. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On Tue, 2010-06-29 at 06:58 +0200, Ralf Corsepius wrote: On 06/29/2010 06:17 AM, Braden McDaniel wrote: Updating F13 now works; Does it? Not for me. Sigh... You're right. Some other updates happened and I thought this one was included. But it just got skipped. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 x86_64
On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote:
Fedora Fails To Build From Source Results for x86_64
using rawhide from 2010-05-27
This is a full rebuild, the first for Fedora 14's rawhide. The
builders all have Fedora 13 installed.
Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
This seems to be diagnosing a good deal more than broken
BuildRequires...
openvrml-0.18.5-2.fc14 (build/make) braden
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml
-I../src/libopenvrml -I../src/local/libopenvrml-dl
-DOPENVRML_LIBDIR_=\/usr/lib64\
-DOPENVRML_PKGDATADIR_=\/usr/share/openvrml\
-DOPENVRML_PKGLIBDIR_=\/usr/lib64/openvrml\
-DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30
-I/usr/lib/jvm/java/include -I/usr/lib/jvm/java/include/linux -DNDEBUG
-I/usr/include/freetype2 -pthread -I/usr/include/libxml2 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-missing-braces -Wno-strict-aliasing
-Wno-unused-variable -c libopenvrml/openvrml/script.cpp -fPIC -DPIC -o
libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-script.o
{standard input}: Assembler messages:
{standard input}:71597: Warning: end of file not at end of a line; newline
inserted
{standard input}:72206: Error: expected comma after name
`_ZNK5boost6spirit7classic16assertive_parserIN8openvrml16vrml_parse_errorENS1_14functor_parserINS3_12int32_parser5parseINS1_7scannerINS1_10multi_passISt19istreambuf_iteratorIcSt11char_traitsIcEENS1_19multi_pass_policies14input'
in .size directive
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://bugzilla.redhat.com/bugzilla for instructions.
Ouch. I'm not sure if this is Random Badness or not; but i386 failed,
too; so maybe it's the same thing. Nope. While it *might* have the
same problem, i386 didn't get past configure:
checking for GIO... ./configure: line 21460: 19388 Segmentation fault
(core dumped) ( $PKG_CONFIG --exists --print-errors gio-2.0 ) 25
./configure: line 21476: 19392 Segmentation fault (core dumped) (
$PKG_CONFIG --exists --print-errors gio-2.0 ) 25
no
Well, that's... interesting.
If there were disc space issues (as Dan Horák suggests), that could
result in some rather exotic errors.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openal-soft .pc file compiling is broken i need help please
On Sun, 2010-04-04 at 17:18 +0200, LinuxDonald wrote:
Am 01.04.2010 23:01, schrieb Braden McDaniel:
[snip]
It looks like this line in CMakeLists.txt:
SET(libdir \${exec_prefix}/${LIB_INSTALL_DIR})
should be
SET(libdir ${LIB_INSTALL_DIR})
Yeah that fixed:
libdir=/usr/lib64
But what about that:
exec_prefix=${prefix}
includedir=${prefix}/include
?
That are broken to in the .pc file :(
Those don't look broken to me. Why do you think they are?
See man pkg-config under METADATA FILE SYNTAX.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libssh2 F11 update breaks Fedora 12 DVD update
On 3/17/10 3:40 PM, Rahul Sundaram wrote: On 03/18/2010 12:45 AM, Kevin Kofler wrote: DVD upgrades are just broken by design and will stay broken until they start pulling in the updates repository. Right now, they don't even offer the option. They do. I was given no such option when performing an upgrade using the F13 Alpha DVD. This option only appeared for the full install. I seem to recall the same behavior for the F12 DVD. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Broken deps in Upgrade from 12 to 13
On Sun, 2010-02-21 at 19:43 +0100, Michael Schwendt wrote:
On Sat, 20 Feb 2010 20:46:14 -0500, Braden wrote:
Upgrade from 12+updates to 13+updates+testing
broken deps look like below. While several may be due to dead packages
that have been removed in 13, some are likely due to violated upgrade
paths and bad/missing Obsoletes for old subpackages.
[...]
Summary of broken packages (by src.rpm name):
[snip]
openvrml
[snip]
openvrml-0.18.3-5.fc12.i686 requires libboost_thread-mt.so.5
openvrml-0.18.3-5.fc12.i686 requires libboost_filesystem-mt.so.5
This doesn't look to me like F12 updates are being factored in properly.
Not true.
Then I still don't understand this. openvrml-devel went away between
F12 and F12-updates.
Btw, the report explicitly refers to fedora-updates-12-i386
and fedora-updates-12-x86_64 in two of its section titles and lists
many packages found in those repos.
openvrml-0.18.3-10 is currently in F12 updates.
Doesn't matter, because your quote is truncated. The two .i686 lines
you've quoted are about openvrml.i686 in the fedora-12-x86_64 repo (!).
Yes, I missed that and consequently left some important information out
of my quote. But I'm not clear on why it doesn't matter that
openvrml-0.18.3-10 is currently in F12 updates.
So what exactly is the upgrade path that's being tested and failing
here?
It's multilib breakage. Some time between F12 updates and F13 you've
killed openvrml-devel,
That's not quite accurate. openvrml-devel was killed between F12 (not
updated) and F13. It was replaced by libopenvrml-devel;
libopenvrml-devel already Obsoletes: openvrml-devel.
These changes that are in F13 are also in F12 updates.
so openvrml is no longer chosen for the
multilib repo compose. Some packagers fix that with self-obsoletes.
In the openvrml package:
Obsoletes: openvrml %{version}-%{release}
That way, openvrml.x86_64 would replace an old/obsolete openvrml.i686,
if installed.
I can do this; but I don't understand why the existence of
libopenvrml-devel and its Obsoletes: openvrml-devel aren't sufficient.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost update status
On 1/27/10 5:13 PM, Benjamin Kosnik wrote: ... looking pretty good. Thanks everybody! Did it go so well we can do it again? That is, is there any chance of getting Boost 1.42.0 into F13? -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pkg-config standards for .pc file location?
On Tue, 2010-02-02 at 21:11 -0500, Matthew Saltzman wrote:
On Tue, 2010-02-02 at 19:16 -0500, Matthias Clasen wrote:
On Tue, 2010-02-02 at 19:04 -0500, Matthew Saltzman wrote:
I work on another open-source project that is considering using
pkg-config, and we are trying to establish standards. I found the
guidelines for how to package .pc files in Fedora (and EPEL), but I'm
curious if there are Fedora or Red Hat standards for the location where
the files are placed when the package is installed?
Normal .pc files go into %{_libdir}/pkgconfig
Arch-independent .pc files go into %{_datadir}/pkgconfig
That's helpful, thanks!
And just to be clear, this is not Fedora-specific. You can also find
this in man pkg-config, where the PKG_CONFIG_PATH environment variable
is described.
--
Braden McDaniel bra...@endoframe.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Sat, 2010-01-30 at 11:36 -0600, Rex Dieter wrote: Braden McDaniel wrote: On Sat, 2010-01-30 at 14:48 +0800, Liu Yu Fei Eric wrote: Hi, I noticed firefox was stuck on 3.5.6 for a rather long time. What about 3.5.7 and the recently 3.6? They are even not in koji. xulrunner-1.9.2 breaks API compatibility with 1.9.1, so downstream packages would need patching for this to happen. Even minor releases generally/often break ABI, requiring lots of dependent package rebuilds... or is this case even worse? I said API, and that's what I meant. At the very least, there have been subtle changes to the plug-in API that can cause compile failures. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
