Re: Disabling ABRT?
On Sat, 2013-12-28 at 21:48 +, Richard Fearn wrote: > Hi, > > On 28 December 2013 21:29, Brendan Jones wrote: > > I'm doing some development at the moment and I want the coredumps to be > > dropped somewhere sane (like the executing directory). How do I do it? > > I think you want to do: > > $ sudo systemctl stop abrt-ccpp You should use 'systemctl disable' instead of 'systemctl stop' if you want the change to be persistent across reboots. For unpackaged executables, ABRT should be creating core dumps in the processes' directory, so you shouldn't need to disable it. I think that might be broken, though. signature.asc Description: This is a digitally signed message part -- 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: octave (Re: Unannounced soname bump: tracker)
On 12/28/2013 02:15 PM, Kevin Fenzi wrote: There's another one yesterday... octave... This one is a bit weird in that the bump was actually committed early in december, but a build was only done yesterday. It seems like the new octave breaks a number of the existing octave* packages too: (from a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6339287 ) ... untar (/builddir/build/BUILD/control, /tmp/oct-9CnltV) unpack: FILETYPE must be gunzip for a directory error: called from 'unpack' in file /usr/share/octave/3.8.0-rc2/m/miscellaneous/unpack.m near line 70, column 7 error: called from: error: /usr/share/octave/3.8.0-rc2/m/pkg/private/install.m at line 146, column 5 error: /usr/share/octave/3.8.0-rc2/m/pkg/private/build.m at line 50, column 3 error: /usr/share/octave/3.8.0-rc2/m/pkg/pkg.m at line 516, column 7 I went and pushed rebuilds on some of the other ones, but likely the above will have to be fixed before the octave* ones can rebuild. :( kevin Yeah, sorry about that - see my other posts about octave. A fixed version should be available shortly - waiting on the arm build now... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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: Problem changing symlink to directory with %pretrans scriptlet
[Sending to the right list this time] Hi Bruno, On 28 December 2013 16:43, Bruno Wolff III wrote: > https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scriptlet > Notes that you need to use lua in pretrans scriptlets, not shell commands. Thanks. I've already seen that. It doesn't seem to make any difference whether it's a bash scriptlet or a lua scriptlet, though; irrespective of what language is used to delete the symlink, the problem still occurs. > I haven't found an example for you to copy, but note there are still some > cases where changing symlinks to directories or vise versa won't work with > rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909). I think deleting the symlink manually may be revealing a problem in rpm. It seems to treat /usr/share/javadoc/test-1/ hello (from the old package) and /usr/share/javadoc/test/hello (from the new package) as the same thing. Since the new package is installing /usr/share/javadoc/test/hello, it therefore decides to 'skip' the old 'hello' file, rather than 'erase' it. I'm not sure yet why these two paths are considered to be the same... Rich -- Richard Fearn richardfe...@gmail.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: Octave updated to 3.8.0-rc2
On 12/28/2013 02:43 PM, Orion Poplawski wrote: On 12/28/2013 02:25 PM, Orion Poplawski wrote: Sorry for the late notice - but in rebuilding for an updated hdf5 I hadn't realized that we had never yet built octave-3.8.0 for rawhide. It is now built and many things need to get rebuilt and there are some cmake issues as well https://bugzilla.redhat.com/show_bug.cgi?id=1047051 I'll see what I can do to fix things... And as I feared, octave packages can't be rebuilt until we've re-hacked the octave pkg build system again... Okay - I should have a fixed version of octave building now (octave-3.8.0-0.4.rc2.fc21). I've also added -nodeps to the %octave_pkg_build macro. I'll try to do some builds later. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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: Disabling ABRT?
Hi, On 28 December 2013 21:29, Brendan Jones wrote: > I'm doing some development at the moment and I want the coredumps to be > dropped somewhere sane (like the executing directory). How do I do it? I think you want to do: $ sudo systemctl stop abrt-ccpp Before: $ cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e i.e. send core dumps to abrt. After: $ cat /proc/sys/kernel/core_pattern core $ cat /proc/sys/kernel/core_uses_pid 1 i.e. write core dumps to files named core.xxx. Regards, Rich -- Richard Fearn richardfe...@gmail.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: Octave updated to 3.8.0-rc2
On 12/28/2013 02:25 PM, Orion Poplawski wrote: Sorry for the late notice - but in rebuilding for an updated hdf5 I hadn't realized that we had never yet built octave-3.8.0 for rawhide. It is now built and many things need to get rebuilt and there are some cmake issues as well https://bugzilla.redhat.com/show_bug.cgi?id=1047051 I'll see what I can do to fix things... And as I feared, octave packages can't be rebuilt until we've re-hacked the octave pkg build system again... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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
Disabling ABRT?
I'm doing some development at the moment and I want the coredumps to be dropped somewhere sane (like the executing directory). How do I do it? Cheers B -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Octave updated to 3.8.0-rc2
Sorry for the late notice - but in rebuilding for an updated hdf5 I hadn't realized that we had never yet built octave-3.8.0 for rawhide. It is now built and many things need to get rebuilt and there are some cmake issues as well https://bugzilla.redhat.com/show_bug.cgi?id=1047051 I'll see what I can do to fix things... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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
octave (Re: Unannounced soname bump: tracker)
There's another one yesterday... octave... This one is a bit weird in that the bump was actually committed early in december, but a build was only done yesterday. It seems like the new octave breaks a number of the existing octave* packages too: (from a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6339287 ) ... untar (/builddir/build/BUILD/control, /tmp/oct-9CnltV) unpack: FILETYPE must be gunzip for a directory error: called from 'unpack' in file /usr/share/octave/3.8.0-rc2/m/miscellaneous/unpack.m near line 70, column 7 error: called from: error: /usr/share/octave/3.8.0-rc2/m/pkg/private/install.m at line 146, column 5 error: /usr/share/octave/3.8.0-rc2/m/pkg/private/build.m at line 50, column 3 error: /usr/share/octave/3.8.0-rc2/m/pkg/pkg.m at line 516, column 7 I went and pushed rebuilds on some of the other ones, but likely the above will have to be fixed before the octave* ones can rebuild. :( kevin signature.asc Description: PGP signature -- 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: Unannounced soname bump: tracker
On Sat, 2013-12-28 at 12:21 +, Debarshi Ray wrote: > On Fri, Dec 27, 2013 at 05:50:18PM -0800, Adam Williamson wrote: > > Sigh. Yes, another of these. > > > > On 2013-12-18, tracker was bumped to 0.7.0: > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=485698 > > > > the sonames of libtracker-extract, libtracker-miner and > > libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without > > announcement, and without all dependent packages being successfully > > rebuilt. At least the following still depend on the old sparql library: > > The thing with Tracker is that they bump the bump the soname and their > pkgconfig file version somewhat gratuitously every six months. That sucks, sure. I suggest you get 'em to stop doing that. But as long as they're doing it...if you bump tracker in Fedora you get to take the bullet. > I built a new tracker because some applications (eg., gnome-photos) > specifically want the features in the 0.17/0.18 series. > > I thought I had rebuilt all the affected packages, but obviously I > missed some. > > > bijiben-0:3.11.1-1.fc21.x86_64 > > brasero-0:3.11.3-1.fc21.x86_64 > > I thought the round of builds for 3.11.3 would take care of these two, but > it looks like bijiben was not built by mclazy and brasero got built before > the new tracker hit the trees. :-/ > > > grilo-plugins-0:0.2.9-2.fc21.x86_64 > > media-explorer-0:0.4.4-5.fc21.x86_64 > > These two need new upstream releases, but the patches are already in > Git. Then fix 'em. You can't really just leave Rawhide broken for a week. Well, obviously you *can*, but you really shouldn't. I did it for you, it took me a couple of hours. If the monkey can do it in two hours... > > What does it take for people to handle soname bumps properly? > > Barring media-explorer, everything else is part of the GNOME stack so > chances of other spins being broken by this was low. GNOME is quite an important spin, however. This being broken means everyone running GNOME on Rawhide gets incomplete updates, and we don't get nightly GNOME lives. We have been trying to keep Rawhide from getting broken like this too often for the last few years... Plus it wasn't just happening on its own; the state of Rawhide when everyone else bogged off for Christmas was that it was suffering from this, the borkage in libevdev, the gnome-bluetooth soname bump / library drop (which affects other desktops), the lack of a gsettings-desktop-schemas build *and* two SELinux bugs, and that's just what I noticed because it directly affects me. Cue comedy scenes of the monkey trying to keep the damn show on the road. > My assumption was that sooner or later this would be sorted by the > GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME > schedules are quite a bit out of sync these days, I was hoping for > some transient rawhide breakage during the Christmas break to go > largely unnoticed. No, that's not going to happen. People do run Rawhide and we want them to. It's really not acceptable to break Rawhide, know you're breaking it, and just go 'meh'. It's going to break sometimes, I recognize that, but that doesn't mean you can just go around whacking it with hammers with wilful abandon. There is a duty to at least do the *best you can* not to break it. > I mean if this is the only thing broken in Rawhide > at the moment, then I would be more than happy. :) Well, I'm not. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Problem changing symlink to directory with %pretrans scriptlet
On Sat, Dec 28, 2013 at 13:23:35 +, Richard Fearn wrote: Hi all, I'm trying to change a symlink to a directory but it's not working. I've reduced the problem down to a simple test case. https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scriptlet Notes that you need to use lua in pretrans scriptlets, not shell commands. I haven't found an example for you to copy, but note there are still some cases where changing symlinks to directories or vise versa won't work with rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Taskotron (was: Re: Unannounced ABI change without soname bump in libevdev-0.6 in Rawhide (and F19 and F20...) breaks GNOME, probably other consumers)
On Thu, Dec 26, 2013 at 07:52:04PM -0800, Adam Williamson wrote: > No. There's a bad one, which is AutoQA. The problem with it is it's more > or less considered obsolete now as far as new development goes; the devs > are working on Taskotron to replace it, but I don't believe it's ready > for test contributions yet, unfortunately. > > Once we have Taskotron up and going (which I believe is aimed for the > first half of 2014), we can start adding more automated tests, which > we'd very much like to do, but I don't think anyone's keen on adding > extra tests to AutoQA at this point, as any time spent implementing them > and keeping them working takes away from time spent developing > Taskotron. Please can I *urge* the Taskotron developers to fix the major deficiency with AutoQA: Allow package maintainers to flexibly upload tests to run on their package. Ideally these tests would be contained in dist-git; for example Taskotron could look in the current branch for a 'test.sh' file and run it. Thus allowing the developer to associate tests with the package, have them run after a build, and be able to change/disable the tests at any time. (I did read the Taskotron wiki page before posting this .. I could not see any place where this AutoQA shortcoming would be fixed, but my apologies if this is already planned) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Problem changing symlink to directory with %pretrans scriptlet
Hi all, I'm trying to change a symlink to a directory but it's not working. I've reduced the problem down to a simple test case. This package: http://richardfearn.fedorapeople.org/test/1-1/test.spec creates the following: * a directory /usr/share/javadoc/test-1 (named after the package version) * a file within the test-1 directory * /usr/share/javadoc/test, a symlink to test-1 In the next version: http://richardfearn.fedorapeople.org/test/1-2/test.spec the Javadoc directory is unversioned, so the 'test' symlink is now a directory (containing one file). As expected the 1-1 to 1-2 upgrade fails: file /usr/share/javadoc/test from install of test-1-2.fc20.noarch conflicts with file from package test-1-1.fc20.noarch So in the next version: http://richardfearn.fedorapeople.org/test/1-3/test.spec a %pretrans scriptlet deletes /usr/share/javadoc/test, if it's a symlink. However during the 1-1 to 1-3 upgrade, the old test-1 directory isn't deleted. The verbose rpm output from this upgrade: http://richardfearn.fedorapeople.org/test/1-3-upgrade.txt shows that rpm doesn't erase /usr/share/javadoc/test-1/hello. It does seem to try to erase the /usr/share/javadoc/test-1 directory, but can't because it still contains a file. Does anyone have any idea what's going on here? Regards, Rich -- Richard Fearn richardfe...@gmail.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: Unannounced soname bump: tracker
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=485698 >> >> the sonames of libtracker-extract, libtracker-miner and >> libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without >> announcement, and without all dependent packages being successfully >> rebuilt. At least the following still depend on the old sparql library: > > The thing with Tracker is that they bump the bump the soname and their > pkgconfig file version somewhat gratuitously every six months. > > I built a new tracker because some applications (eg., gnome-photos) > specifically want the features in the 0.17/0.18 series. > > I thought I had rebuilt all the affected packages, but obviously I > missed some. > >> bijiben-0:3.11.1-1.fc21.x86_64 >> brasero-0:3.11.3-1.fc21.x86_64 > > I thought the round of builds for 3.11.3 would take care of these two, but > it looks like bijiben was not built by mclazy and brasero got built before > the new tracker hit the trees. :-/ > >> grilo-plugins-0:0.2.9-2.fc21.x86_64 >> media-explorer-0:0.4.4-5.fc21.x86_64 > > These two need new upstream releases, but the patches are already in > Git. > >> What does it take for people to handle soname bumps properly? > > Barring media-explorer, everything else is part of the GNOME stack so > chances of other spins being broken by this was low. > > My assumption was that sooner or later this would be sorted by the > GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME > schedules are quite a bit out of sync these days, I was hoping for > some transient rawhide breakage during the Christmas break to go > largely unnoticed. I mean if this is the only thing broken in Rawhide > at the moment, then I would be more than happy. :) Ultimately the rule of thumb is if it's a soname bump you need to rebuild all the packages that are dependent on it when you push the build. Relying on the possibility that some time in the future there maybe a new release of something is not good enough as there are people that use rawhide constantly and you're unnecessarily causing pain for them and extra work for others to cleanup the mess. If the soname is bumped you need to rebuild all the dependent packages no matter what even if tomorrow or next week there will be new releases. Peter -- 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: Unannounced soname bump: tracker
On Fri, Dec 27, 2013 at 05:50:18PM -0800, Adam Williamson wrote: > Sigh. Yes, another of these. > > On 2013-12-18, tracker was bumped to 0.7.0: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=485698 > > the sonames of libtracker-extract, libtracker-miner and > libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without > announcement, and without all dependent packages being successfully > rebuilt. At least the following still depend on the old sparql library: The thing with Tracker is that they bump the bump the soname and their pkgconfig file version somewhat gratuitously every six months. I built a new tracker because some applications (eg., gnome-photos) specifically want the features in the 0.17/0.18 series. I thought I had rebuilt all the affected packages, but obviously I missed some. > bijiben-0:3.11.1-1.fc21.x86_64 > brasero-0:3.11.3-1.fc21.x86_64 I thought the round of builds for 3.11.3 would take care of these two, but it looks like bijiben was not built by mclazy and brasero got built before the new tracker hit the trees. :-/ > grilo-plugins-0:0.2.9-2.fc21.x86_64 > media-explorer-0:0.4.4-5.fc21.x86_64 These two need new upstream releases, but the patches are already in Git. > What does it take for people to handle soname bumps properly? Barring media-explorer, everything else is part of the GNOME stack so chances of other spins being broken by this was low. My assumption was that sooner or later this would be sorted by the GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME schedules are quite a bit out of sync these days, I was hoping for some transient rawhide breakage during the Christmas break to go largely unnoticed. I mean if this is the only thing broken in Rawhide at the moment, then I would be more than happy. :) Anyway. Thanks for taking care of this, and sorry for the trouble. Cheers, Debarshi -- Wearing non-prescription glasses and embracing obscurity doesn't necessarily make you a hipster. -- Anonymous pgpVCqzvqJGyZ.pgp Description: PGP signature -- 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: review swap: python-funcparserlib and python-webcolors
On Tue, Dec 17, 2013 at 2:39 PM, Dridi Boukelmoune wrote: > On Tue, Dec 17, 2013 at 2:36 PM, Miro Hrončok wrote: >> Út 17. prosinec 2013, 14:13:30 CET, Dridi Boukelmoune napsal: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=python-webcolors >>> https://bugzilla.redhat.com/show_bug.cgi?id=python-funcparserlib >> >> So I take them and you ow me two, ok? > > Deal ;) > >> >>> Good news, those packages are already python3-ready, as are blockdiag >>> and its friends. >> >> Great :) Hi, Now that funcparserlib and webcolors are available in rawhide I have submitted blockdiag. https://bugzilla.redhat.com/show_bug.cgi?id=python-blockdiag Best Regards, Dridi >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
