Re: Expanding the list of "Hardened Packages"
Steve Grubb wrote:
> On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
>> which I interpret to mean that after using -fstack-protector-all and
>> removing prelink, SELinux would become obsolete because no executable
>> can be exploited.
>
> I would say there is a place for SE Linux even if we compiled everything with
> "all" because FORTIFY_SOURCE coverage is not absolute. For example, about a
> month ago i ran the following test:
>
> procs=`ls /proc | grep '^[0-9]' | sort -n`
> for p in $procs
> do
> res=`cat /proc/$p/maps 2>/dev/null | awk '$2 ~ "wx" { print $2 }'`
> if [ x"$res" != "x" ] ; then
> cat /proc/$p/cmdline | awk '{ printf "%-35s\t", $1 }'
> printf "%s\n" "$p"
> fi
> done
Neat.
I saved that in a script, then realized I could simplify it.
This is nearly equivalent:
$ grep -lE '^[0-9a-f-]+ .wx' /proc/*/maps 2>/dev/null \
|perl -ne 'm!^(/proc/(\d+))/.*! and printf qq(%5d %s\n), $2, `cat $1/cmdline`'
Sample output on an F18 system running the awesome window manager:
1836 /usr/lib/firefox/firefox-no-remote-Pdefault
Notice that the NUL-separated arguments aren't shown properly,
so filter the result through e.g., | tr '\0' ' '
Adjusted output:
1836 /usr/lib/firefox/firefox -no-remote -P default
> What this does is display the programs with Writable and Executable memory.
> All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome,
> Cinnamon, and Mate.) WX memory is dangerous because the normal exploit pattern
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On Mon, 2013-04-22 at 17:48 -0600, Kevin Fenzi wrote: > On Mon, 22 Apr 2013 19:55:02 +0200 > Rave it wrote: > > > Am Mon, 22 Apr 2013 16:37:34 + > > schrieb devel-requ...@lists.fedoraproject.org: > > > > For me as compiz maintainer those info's are complete useless whithout > > having more infomation what the user did if abrt would trigered. > > Maybe thy played arround without knowledge about the programm and did > > wrong things? > > Better the abrt guys forced the user to write what they did if abrt > > trigger a alarm. > > For me a bug whithout a comment isn't a bug. > > And honestly, if i get such bugs without a comment, i asked the user > > friendly what they did. > > In case of 50% i get no answer. > > 50% is much higher than I have gotten. ;) > > On any new abrt bugs I get, I typically: > > - Check to see if the submitter filled in the 'description of problem' > which something I could try and work into a reproducer. I'd say > perhaps 1% do. > > - If not, then I ask them what they were doing when the crash happened > and if they can reproduce it. I'd say 90% never reply to that and the > bug sits there until EOL. Some folks do, and those I can gather info > from or ask various troubleshooting things which often results in a > fix or at least an upstream bug. The same workflow, same problems with the exception that after a while I close as insufficientdata (to avoid having to wait for EOL). Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Tue, 16 Apr 2013 14:05:39 +0200 Florian Weimer wrote: > On 04/15/2013 08:17 PM, Miloslav Trmač wrote: > > Sure, moving away from C/C++ does not make programs > > completely secure; however, on average, C/C++ programs > > are noticeably less secure (because most vulnerabilities > > that can happen in higher-level languages can also happen > > in C, but not the other way around). > > To illustrate this point, here's a fairly concrete > example: If you have got a program that is written in a > memory-safe language which also provides some form of > encapsulation, it is possible to demonstrate convincingly > (*) that a software module which provides an > encryption/decryption service never leaks the key > material. If there is no memory safety, other code in the > program could peek at the key bits, and encapsulation is no > longer guaranteed. What should be a local property of the > module now turns into a global property of the program, > making review more difficult. > > (*) As soon as cryptography is involved, mathematically > rigorous results are the exception. > Memory-safe languages don't protect against key material being left un-zeroed in pages, nor against side-channel attacks due to non-constant operation timing, power, etc. Sure there is a certain class of problems you aren't going to get in Python that you are in C, but it's not a panacea. Conrad -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package review statistics: 2013-04-16 - 2013-04-23
Hi! Here are the package review statistics for the past week, from 2013-04-16 to today, 2013-04-23. Anderson did the most reviews this week. In total, there were 64 reviews this week. Start Date: 2013-04-16 00:00:00 End Date: 2013-04-23 14:18:24.572433 Anderson Silva : 14 https://bugzilla.redhat.com/show_bug.cgi?id=925968 drupal6-node_import https://bugzilla.redhat.com/show_bug.cgi?id=925972 drupal6-stringoverrides https://bugzilla.redhat.com/show_bug.cgi?id=925974 drupal6-user_badges https://bugzilla.redhat.com/show_bug.cgi?id=925975 drupal6-userpoints https://bugzilla.redhat.com/show_bug.cgi?id=925976 drupal6-userpoints_votingapi https://bugzilla.redhat.com/show_bug.cgi?id=925978 drupal6-vertical_tabs https://bugzilla.redhat.com/show_bug.cgi?id=925979 drupal6-views_customfield https://bugzilla.redhat.com/show_bug.cgi?id=925980 drupal6-views_datasource https://bugzilla.redhat.com/show_bug.cgi?id=925982 drupal6-vote_up_down https://bugzilla.redhat.com/show_bug.cgi?id=925984 drupal6-wikitools https://bugzilla.redhat.com/show_bug.cgi?id=925989 drupal6-devel https://bugzilla.redhat.com/show_bug.cgi?id=925990 drupal6-path_redirect https://bugzilla.redhat.com/show_bug.cgi?id=925991 drupal6-messaging https://bugzilla.redhat.com/show_bug.cgi?id=925995 drupal6-notifications Petr Šabata : 7 https://bugzilla.redhat.com/show_bug.cgi?id=947454 perl-ExtUtils-InstallPaths https://bugzilla.redhat.com/show_bug.cgi?id=951396 perl-JSON-Pointer https://bugzilla.redhat.com/show_bug.cgi?id=951874 perl-DBD-Firebird https://bugzilla.redhat.com/show_bug.cgi?id=952544 perl-Object-Tiny https://bugzilla.redhat.com/show_bug.cgi?id=952555 perl-Getopt-Lucid https://bugzilla.redhat.com/show_bug.cgi?id=952563 perl-App-mymeta_requires https://bugzilla.redhat.com/show_bug.cgi?id=952579 perl-IO-Event T.C. Hollingsworth : 5 https://bugzilla.redhat.com/show_bug.cgi?id=907018 stbi https://bugzilla.redhat.com/show_bug.cgi?id=907027 rapidxml https://bugzilla.redhat.com/show_bug.cgi?id=907213 lmfit https://bugzilla.redhat.com/show_bug.cgi?id=907261 poly2tri https://bugzilla.redhat.com/show_bug.cgi?id=953379 tipcutils Michal Srb : 3 https://bugzilla.redhat.com/show_bug.cgi?id=859110 glassfish-management-api https://bugzilla.redhat.com/show_bug.cgi?id=859112 glassfish-gmbal https://bugzilla.redhat.com/show_bug.cgi?id=859114 grizzly gil cattaneo : 3 https://bugzilla.redhat.com/show_bug.cgi?id=920037 maven-jsf-plugin https://bugzilla.redhat.com/show_bug.cgi?id=920038 infomas-asl https://bugzilla.redhat.com/show_bug.cgi?id=920039 atmosphere Brendan Jones : 2 https://bugzilla.redhat.com/show_bug.cgi?id=947049 qxkb https://bugzilla.redhat.com/show_bug.cgi?id=952632 qtermwidget Fabian Affolter : 2 https://bugzilla.redhat.com/show_bug.cgi?id=922708 supybot-irccat https://bugzilla.redhat.com/show_bug.cgi?id=954100 sendxmpp Mario Blättermann : 2 https://bugzilla.redhat.com/show_bug.cgi?id=915427 python-zc-customdoctests https://bugzilla.redhat.com/show_bug.cgi?id=953384 Review Orion Poplawski : 2 https://bugzilla.redhat.com/show_bug.cgi?id=815566 mybatis https://bugzilla.redhat.com/show_bug.cgi?id=954134 mybatis-parent Paulo Andrade : 2 https://bugzilla.redhat.com/show_bug.cgi?id=903428 lfsc https://bugzilla.redhat.com/show_bug.cgi?id=927477 remake Pierre-YvesChibon : 2 https://bugzilla.redhat.com/show_bug.cgi?id=951777 python-pygal https://bugzilla.redhat.com/show_bug.cgi?id=952141 python-mccabe Robert Kuska : 2 https://bugzilla.redhat.com/show_bug.cgi?id=950907 python-jedi https://bugzilla.redhat.com/show_bug.cgi?id=952093 python-wtf-peewee Dan Mashal : 1 https://bugzilla.redhat.com/show_bug.cgi?id=951817 libreatlas Eugene A. Pivnev : 1 https://bugzilla.redhat.com/show_bug.cgi?id=913367 gpick Greg Bailey : 1 https://bugzilla.redhat.com/show_bug.cgi?id=912152 lua-event Jamie Nguyen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=928097 tweak Jared Smith : 1 https://bugzilla.redhat.com/show_bug.cgi?id=91 php-pecl-zendopcache Jaromír Cápík : 1 https://bugzilla.redhat.com/show_bug.cgi?id=750902 java-sleep Jerry James : 1 https://bugzilla.redhat.com/show_bug.cgi?id=877651 sagemath Lokesh Mandvekar : 1 https://bugzilla.redhat.com/show_bug.cgi?id=949214 python-iptools Mario Ceresa : 1
Re: [Test-Announce] Fedora 19 Graphics Test Week starts tomorrow (2013-04-23)!
Count me in for Nouveau - I have a problem I've been trying to nail down for months on my ancient GeForce 6150SE nForce 430. Symptoms (Fedora 18) none with 3.6 kernel. With 3.7 or later, GNOME desktop comes up but as soon as I launch Firefox, I get diagonal lines across the screen and I need to power cycle the machine to use it again. With the KDE desktop, it does the same thing during the login and I don't even get a desktop. I had to switch to the 'nv' X driver to get the machine to function with 3.7. And there's no log file anywhere I can attach to a bug report. If there are things I can do to capture a log of this beast, please let me know! On Mon, Apr 22, 2013 at 4:46 PM, Adam Williamson wrote: > Hi, folks. It's that time again: Graphics Test Week! Tomorrow (2013-04-23) > is Intel Test Day, Wednesday 2013-04-24 is Nouveau Test Day, and Thursday > 2013-04-25 is Radeon Test Day: > > https://fedoraproject.org/wiki/Test_Day:2013-04-23_Intel > https://fedoraproject.org/wiki/Test_Day:2013-04-24_Nouveau > https://fedoraproject.org/wiki/Test_Day:2013-04-25_Radeon > > This is one of those events where we really need as much data as possible - > the idea is just to get testing on as wide a range of hardware as we can > manage. So please, if you have a few spare minutes, come out and test! It's > very easy. Live images will be available on the Wiki pages soon (martix is > just finishing those off), and we'll be in #fedora-test-day all week to help > out with testing and debugging. > > There's a longer announcement post on my blog at > http://www.happyassassin.net/2013/04/22/fedora-19-graphics-test-week-kicks-off-tomorrow/ > - if you want to spread the word about the event (and please do!), that's > probably the best thing to link to. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > ___ > test-announce mailing list > test-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/test-announce > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench http://j.mp/CompJournBench/ I am not an IP address! I am a free man! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Embedded SIG
On Dom, 2013-04-21 at 21:00 +0200, Markus Mayer wrote: > On 04/21/2013 04:23 PM, John J. McDonough wrote: > > On Sun, Apr 21, 2013 at 5:01 AM, Markus Mayer wrote: > > > >> So I have decide to ask if there are others like me, and if there are > >> willing to form a SIG (special interest group) to enhance embedded > >> developing with fedora. > > > > I have an interest in an Embedded SIG, although less for the ARM as for > > the Microchip devices (PIC, dsPIC) which are reasonably well supported. > > Not that I don't play with ARM, too, but it is somewhat less of a > > passion. > > > > --McD > > > > > > As it was pointed out to me, there already exists and embedded SIG > (https://fedoraproject.org/wiki/Embedded). I am trying to contact and > join them, but I do not know if they are still alive. https://fedoraproject.org/wiki/Architectures you have here a little information about arches supported or wish supported like MIPS -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clock-applet memory leak
On Mon, 22 Apr 2013 12:55:00 -0400
Przemek Klosowski wrote:
> I reported the large memory leak in clock-applet:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=952763
>
> (TLDR: clock-applet grows by 1GB/day when reporting weather)
Ouch. Until this is fixed, I duct-taped around by adding this
line to cron:
*/5 * * * * /home/conrad/kill_clock_applet_leak.sh
Script:
#!/bin/bash
memused="`ps auxwww|grep clock-ap[p]let | awk '{ print $6 }'`"
if [[ $memused -gt 25 ]]; then
memhuman="$((memused/1024))"
echo "Clock-applet using $memhuman MB, killing panel"
pkill gnome-panel
fi
It's ugly and dumb, but should prevent run-away stupidity...
(kills at 250MB RSS).
Conrad
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [F18][ATI Rage XL] Problems with install on ATI Rage XP video driver
I have updated and added debugging information and screen shots on these two bugs on F18 https://bugzilla.redhat.com/show_bug.cgi?id=951643 and F19Live https://bugzilla.redhat.com/show_bug.cgi?id=951648 On 14 April 2013 17:23, Aaron Gray wrote: > I have put in two bugzilla entries :- > > https://bugzilla.redhat.com/show_bug.cgi?id=951643 > https://bugzilla.redhat.com/show_bug.cgi?id=951648 > > On for F18 and another for F19-Live as they seem to be different results. > > Aaron > > > On 5 April 2013 12:58, Aaron Gray wrote: > >> Yeah I am getting the same messed up graphics results for F19 Alpha Live >> Spin on both monitors. Better than with F18 which would only work using >> VESA. >> >> BTW The Samsung has the following modes :- >> >>- IBM, 640 x 480 >>- VESA, 800 x 600 >>- VESA, 800 x 600 >>- VESA, 1024 x 768 >>- VESA, 1280 X 960 >>- VESA, 1280 X 1024 >>- VESA, 1600 X 1200 >>- VESA, 1920 X 1200 >> >> >> >> >> On 5 April 2013 12:41, Aaron Gray wrote: >> >>> On 5 April 2013 06:59, Felix Miata wrote: >>> On 2013-04-05 01:38 (GMT-0400) Aaron Gray composed: Its quite strange. > The Samsung monitor is 1920 x 1200 > What other modes does it support? >>> >>> >>> Quite a range AFAICT. >>> >>> This problem on F18 arose using a smaller 1280 by 1024 monitor, which is >>> now giving the same results. >>> >>> --- >>> Aaron >>> >> >> > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: question about journald and rsyslogd in f19, are both enabled by default?
On Mon, 22.04.13 18:21, Reartes Guillermo (rtgui...@gmail.com) wrote: > Hi, > > I noticed this after many freezes (due to bug 954181) in the messages: > > [3.549075] systemd-journald[177]: File > /var/log/journal/4697cb8e07b94ed28925792b701e629f/system.journal corrupted > or uncleanly shut down, renaming and replacing. Make sure to run the newest systemd RPM, and this shouldn't happen anymore unless you turned off the machine abruptly at the worst possible moment. > But why is it running if i did not enable it nor have i changed the default > syslog? In contrast to syslog journald is running in early and late boot and collects output from all services's stdout/stderr. It forwards all that to syslog if one is running, so that syslog gets substantially more data this way than on classic sysvinit setups. journald cannot be turned off, since all service stdout/stderr is connected to it, it's simply too integrated. If you think the journal is evil, then you can set Storage=none in /etc/systemd/journald.conf which will still leave it running but without storing anything locally on disk. It will then act as a concentrator only, and will simply make the data logged to syslog more comprehensive. Instead of turning storage off, I can only recommend you giving "journalctl" a try, since it is so much nicer than anything that existed before: https://www.youtube.com/watch?v=i4CACB7paLc In F18, storage in journald was disabled by default, in F19 we enabled it by default, since it greatly improves the usefulness of "systemctl status" (simply because we can store a bit more data this way, where before we only used a tiny ringbuffer in /run). Also, this has the effect of allowing unprivileged users access to their own journals. Note that rsyslog remains turned on in F19 by default (we were a bit tired to fight this through for now). You hence get journald and rsyslog running side-by-side by default. Both of them store data in /var/log/. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Graphics Test Week starts tomorrow (2013-04-23)!
Hi, folks. It's that time again: Graphics Test Week! Tomorrow (2013-04-23) is Intel Test Day, Wednesday 2013-04-24 is Nouveau Test Day, and Thursday 2013-04-25 is Radeon Test Day: https://fedoraproject.org/wiki/Test_Day:2013-04-23_Intel https://fedoraproject.org/wiki/Test_Day:2013-04-24_Nouveau https://fedoraproject.org/wiki/Test_Day:2013-04-25_Radeon This is one of those events where we really need as much data as possible - the idea is just to get testing on as wide a range of hardware as we can manage. So please, if you have a few spare minutes, come out and test! It's very easy. Live images will be available on the Wiki pages soon (martix is just finishing those off), and we'll be in #fedora-test-day all week to help out with testing and debugging. There's a longer announcement post on my blog at http://www.happyassassin.net/2013/04/22/fedora-19-graphics-test-week-kicks-off-tomorrow/ - if you want to spread the word about the event (and please do!), that's probably the best thing to link to. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login to Koji
>> Hopefully, last problem is how do I specify proxy for koji commands? >> Does it not support proxies? I found this being asked earlier, >> http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html? kevin> I think it uses the normal http_proxy and https_proxy env variables... Dennis> Koji doesnt support proxies. the ssl code opens sockets directly I think Dennis is right. Even after setting proxy env vars, koji is not able to connect. Given that I have to do it from behind a proxy, what is the alternative for me in this case? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On Mon, 22 Apr 2013 19:55:02 +0200 Rave it wrote: > Am Mon, 22 Apr 2013 16:37:34 + > schrieb devel-requ...@lists.fedoraproject.org: > > For me as compiz maintainer those info's are complete useless whithout > having more infomation what the user did if abrt would trigered. > Maybe thy played arround without knowledge about the programm and did > wrong things? > Better the abrt guys forced the user to write what they did if abrt > trigger a alarm. > For me a bug whithout a comment isn't a bug. > And honestly, if i get such bugs without a comment, i asked the user > friendly what they did. > In case of 50% i get no answer. 50% is much higher than I have gotten. ;) On any new abrt bugs I get, I typically: - Check to see if the submitter filled in the 'description of problem' which something I could try and work into a reproducer. I'd say perhaps 1% do. - If not, then I ask them what they were doing when the crash happened and if they can reproduce it. I'd say 90% never reply to that and the bug sits there until EOL. Some folks do, and those I can gather info from or ask various troubleshooting things which often results in a fix or at least an upstream bug. I'm not personally finding these faf reports of much use. They seem to have a sanitized backtrace with even less info in them, and I also have no way at all of finding out from people who saw this what they were doing or ask them debugging steps. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
question about journald and rsyslogd in f19, are both enabled by default?
Hi, I noticed this after many freezes (due to bug 954181) in the messages: [3.549075] systemd-journald[177]: File /var/log/journal/4697cb8e07b94ed28925792b701e629f/system.journal corrupted or uncleanly shut down, renaming and replacing. But why is it running if i did not enable it nor have i changed the default syslog? # cat /etc/fedora-release Fedora release 19 (Schrödinger’s Cat) # uname -r 3.9.0-0.rc7.git3.1.fc19.x86_64 # systemctl list-units |grep -i journal systemd-journald.serviceloaded active running Journal Service systemd-journald.socket loaded active running Journal Socket # systemctl list-units |grep -i syslog rsyslog.service loaded active running System Logging Service syslog.socket loaded active running Syslog Socket # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: active (running) since Mon 2013-04-22 17:06:33 ART; 20min ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 177 (systemd-journal) Status: "Processing requests..." CGroup: name=systemd:/system/systemd-journald.service └─177 /usr/lib/systemd/systemd-journald Apr 22 17:06:33 stark.espada systemd-journal[177]: Allowing runtime journal files to grow to 399.3M. Apr 22 17:06:33 stark.espada systemd-journal[177]: Journal started Apr 22 17:06:34 stark.espada systemd-journal[177]: Allowing system journal files to grow to 4.0G. Apr 22 17:07:24 stark.espada systemd-journal[177]: Forwarding to syslog missed 53 messages. # systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled) Active: active (running) since Mon 2013-04-22 17:06:34 ART; 20min ago Main PID: 333 (rsyslogd) CGroup: name=systemd:/system/rsyslog.service └─333 /sbin/rsyslogd -n # ls -l /var/log/messages* -rw---. 1 root root 598516 Apr 22 17:21 /var/log/messages -rw---. 1 root root 1982160 Apr 13 15:56 /var/log/messages-20130413 -rw---. 1 root root 550418 Apr 20 17:04 /var/log/messages-20130420 -rw---. 1 root root 514731 Apr 21 13:09 /var/log/messages-20130421 # ls -l /var/log/journal/ total 8 drwxr-xr-x+ 2 root root 4096 Apr 22 17:06 4697cb8e07b94ed28925792b701e629f # ls -l /var/log/journal/4697cb8e07b94ed28925792b701e629f/ total 76360 -rw-r-+ 1 root systemd-journal 7462912 Apr 5 15:06 system@0004d9a0f39c9cf9-f6c68c6aa8300de3.journal~ -rw-r-+ 1 root systemd-journal 9494528 Apr 5 17:53 system@0004d9a34756be53-519bcb0f6de7ed66.journal~ -rw-r-+ 1 root systemd-journal 5353472 Apr 5 18:13 system@0004d9a38d8574e1-0ec56d6bae16b243.journal~ -rw-r-+ 1 root systemd-journal 8417280 Apr 7 17:04 system@0004d9cad4c2a0ec-be79b785f140e32d.journal~ -rw-r-+ 1 root systemd-journal 20258816 Apr 21 12:27 system@0004dae096de651e-cace31ff8c7f7724.journal~ -rw-r-+ 1 root systemd-journal 6901760 Apr 21 15:56 system@0004dae381c7f9ac-122c42176d3ec2af.journal~ -rw-r-+ 1 root systemd-journal 4919296 Apr 21 16:54 system@0004dae452a0f1bf-da4c74f3ea564679.journal~ -rw-r-+ 1 root systemd-journal 6795264 Apr 22 17:06 system@0004daf89b05d07b-c306684d77ae2787.journal~ -rw-r-+ 1 root systemd-journal 4751360 Apr 22 17:24 system.journal -rw-r-x---+ 1 root systemd-journal 3743744 Apr 5 15:11 user-1000.journal # ps aux|grep -i journald | grep -v grep root 177 0.0 0.2 299340 17180 ?Ss 17:06 0:00 /usr/lib/systemd/systemd-journald # ps aux|grep -i rsyslogd | grep -v grep root 333 0.0 0.0 254700 1660 ?Ssl 17:06 0:00 /sbin/rsyslogd -n Do i have both rsyslogd and journald running at the same time? I re-checked my F17 Box and also both systemd-journald.service and rsyslog.service are up. But unlike F19a, there are no /var/log/journal directories nor any .journal file. On the F19a Host, when i encounter the freeze event: /var/log/messages (rsyslogd) shows: Apr 22 18:01:41 stark kernel: [ 3312.986034] kvm [1866]: vcpu0 unhandled rdmsr: 0xc001100d Apr 22 18:01:41 stark kernel: [ 3312.986067] kvm [1866]: vcpu0 unhandled rdmsr: 0xc0010112 Apr 22 18:01:41 stark kernel: [ 3313.128231] kvm [1866]: vcpu0 unhandled rdmsr: 0xc0010001 Apr 22 18:03:08 stark rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="348" x-info="http://www.rsyslog.com";] start journalctl -r (journald) shows: Apr 22 18:03:03 stark.espada systemd-journal[68]: Allowing runtime journal files to grow to 399.3M. -- Reboot -- Apr 22 18:01:45 stark.espada setroubleshoot[1871]: writing database (/var/lib/setroubleshoot/setroubleshoot_database.xml) mod Apr 22 18:01:45 stark.espada setroubleshoot[1871]: KeyboardInterrupt in RunFaultServer Apr 22 18:01:45 stark.espada setroubleshoot[1871]: received signal=14 Apr 22 18:01:41 stark.espada kernel: kvm [1866]: vcpu0 unhandled rdmsr: 0xc0010001 Apr 22 18:01:41 stark.e
Re: clock-applet memory leak
On Mon, Apr 22, 2013 at 12:55:00PM -0400, Przemek Klosowski wrote: > I reported the large memory leak in clock-applet: > > https://bugzilla.redhat.com/show_bug.cgi?id=952763 > > (TLDR: clock-applet grows by 1GB/day when reporting weather) > > Since clock-applet is a default install on every Fedora, I thought > this would be widely reported---it essentially makes the system > unusable within a day or two if you run into this problem---but > that doesn't seem to be the case. I guess people don't see it > because nobody reconfigures clock-applet. > > Anyway, I am looking for a way to debug this: I tried attaching GDB > to the running process but the results are unreliable (see BZ). I > couldn't figure out how to run valgrind on the executable: it has to > be run in the context of the Gnome panel, so how do I tell it to run > 'valgrind /usr/libexec/clock-applet', and how do I get access to the > results? > Is there another way? One trick I've used in the past is to core dump the process (set 'ulimit -c unlimited' before startx, then kill -SEGV $clockpid), and parse it with some simple command line tools. sort < core | uniq -c | sort -nr Example: https://bugzilla.redhat.com/show_bug.cgi?id=890039#c2 This will tell you if some obvious string is being leaked. Unfortunately it's not useful for any other type of leak. But you never know, and it only takes a few minutes to do this analysis. Rich. PS. If you can't coredump the process, you can probably read /proc/$pid/mem instead, but note that simple 'cat' won't work: http://unix.stackexchange.com/questions/6267/how-to-unswap-my-desktop/6271#6271 -- 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
Re: Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
Am Mon, 22 Apr 2013 16:37:34 + schrieb devel-requ...@lists.fedoraproject.org: For me as compiz maintainer those info's are complete useless whithout having more infomation what the user did if abrt would trigered. Maybe thy played arround without knowledge about the programm and did wrong things? Better the abrt guys forced the user to write what they did if abrt trigger a alarm. For me a bug whithout a comment isn't a bug. And honestly, if i get such bugs without a comment, i asked the user friendly what they did. In case of 50% i get no answer. Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
clock-applet memory leak
I reported the large memory leak in clock-applet: https://bugzilla.redhat.com/show_bug.cgi?id=952763 (TLDR: clock-applet grows by 1GB/day when reporting weather) Since clock-applet is a default install on every Fedora, I thought this would be widely reported---it essentially makes the system unusable within a day or two if you run into this problem---but that doesn't seem to be the case. I guess people don't see it because nobody reconfigures clock-applet. Anyway, I am looking for a way to debug this: I tried attaching GDB to the running process but the results are unreliable (see BZ). I couldn't figure out how to run valgrind on the executable: it has to be run in the context of the Gnome panel, so how do I tell it to run 'valgrind /usr/libexec/clock-applet', and how do I get access to the results? Is there another way? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On Mon, Apr 22, 2013 at 8:05 AM, Richard Marko wrote: > Yes, we did that and started filing bugs for everything that seemed > worth (even old stuff). After initial sync between bugzilla and faf > server it won't create as much tickets for old components as it does now > which is partially caused by the order in which the bot creates these > tickets. > > Creation of new tickets is stopped for now until we fix few issues > reported to us. > More feedback is welcome. Here is some feedback. The bugs say to send email to crash-catc...@lists.fedorahosted.org if a bug report is wrong or not helpful, so that the tool may be improved. I sent an email with some suggestions. It bounced back: You need to subscribe before you can post to this list. That's not very friendly. Either suggest an open email address to which suggestions can be sent, or modify the bugzilla message so that the necessity of subscribing before posting is made clear. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On 04/22/2013 06:24 AM, Dan Mashal wrote: Seems like someone turned on a bot this morning. Just a heads up.. these have [faf] in the subject line and seem to be filing bugs on old components (for me at least). Looks like it's just starting to make the rounds. Who owns this? Dan I also find it annoying that the crash-catcher list is not open, since that is where comments are asked to be sent to. I really don't want to have to subscribe to yet another list. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On 04/22/2013 02:24 PM, Dan Mashal wrote: > Seems like someone turned on a bot this morning. Just a heads up.. > these have [faf] in the subject line and seem to be filing bugs on old > components (for me at least). Looks like it's just starting to make > the rounds. Who owns this? > > Dan Yes, we did that and started filing bugs for everything that seemed worth (even old stuff). After initial sync between bugzilla and faf server it won't create as much tickets for old components as it does now which is partially caused by the order in which the bot creates these tickets. Creation of new tickets is stopped for now until we fix few issues reported to us. More feedback is welcome. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
On Mon, Apr 22, 2013 at 1:24 PM, Dan Mashal wrote: > Seems like someone turned on a bot this morning. Just a heads up.. > these have [faf] in the subject line and seem to be filing bugs on old > components (for me at least). Looks like it's just starting to make > the rounds. Who owns this? The age of the components look fine for the ones that I've received and some of them even look useful but it's always nice for the people that are going to generate mass bug spam to sent a heads up to the list so people are aware it's happening. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gradle problem in f{19,20}
Il 22/04/2013 12:58, Mikolaj Izdebski ha scritto: On 04/22/2013 10:16 AM, gil wrote: 1) Run gradle in a debugger and try to investigate what exactly is causing the problem; "unexpected internal error" is not helping much. already done And? Any results? the same error reported in the previous emal 2) Check if the problem persists after replacing all dependencies with binary JARs used by upstream. If the issue is solved this way then you can try bisection method (replace half of dependencies, then quarter and so on, narrowing the possible cause of the problem). i use f18 And what is your point? Does using F18 prevent you from trying the bisection method? It helped me solve several difficult cases. Besides that the message title says you are using F19/F20, so I'm a bit confused now. sorry, tried to rebuilt gradle on koji in non boostrap mode for F19/F20 3) Talk to the upstream. They surely know more about gradle internals and hopefully they will give you some advice how to fix the problem. i applied a patch (#31) as suggested by A. Murdoc, gradle developer [1] http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-printStackTrace.patch but dont work ... probably did something wrong ... Try changing the patch to print the stack trace even when failure is not instance of GradleException (i.e. uncomment line 13). ok thanks now try regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130422 changes
Compose started at Mon Apr 22 09:15:20 UTC 2013 Broken deps for x86_64 -- [accerciser] accerciser-3.8.0-2.fc19.noarch requires python3-ipython-console [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [astromenace-data] astromenace-data-1.2-7.fc19.noarch requires astromenace = 0:1.2 [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libguestfs] 1:libguestfs-1.21.26-4.fc19.i686 requires libk5radius.so.0 1:libguestfs-1.21.26-4.fc19.x86_64 requires libk5radius.so.0()(64bit) [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [maven-dependency-plugin] maven-dependency-plugin-2.7-1.fc19.noarch requires mvn(org.apache.commons:commons-io) [mygui] mygui-3.2.0-4.fc19.i686 requires libCommon.so mygui-3.2.0-4.fc19.x86_64 requires libCommon.so()(64bit) mygui-demos-3.2.0-4.fc19.x86_64 requires libCommon.so()(64bit) mygui-tools-3.2.0-4.fc19.x86_
Receiving bugs from "Crash Catcher" with [faf] in the subject line
Seems like someone turned on a bot this morning. Just a heads up.. these have [faf] in the subject line and seem to be filing bugs on old components (for me at least). Looks like it's just starting to make the rounds. Who owns this? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130422 changes
Compose started at Mon Apr 22 08:15:31 UTC 2013 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.12-4.fc20.x86_64 requires libmgl.so.5()(64bit) [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eg] eg-1.7.5.2-1.fc20.noarch requires perl(one) eg-1.7.5.2-1.fc20.noarch requires perl(it) eg-1.7.5.2-1.fc20.noarch requires perl(an) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [mapserver] php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [mgetty] mgetty-1.1.36-20.fc20.x86_64 requires /sbin/sendmail mgetty-sendfax-1.1.36-20.fc20.x86_64 requires /sbin/useradd [mygui] mygui-3.2.0-4.fc20.i686 requires libCommon.so mygui-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit) myg
Re: gradle problem in f{19,20}
On 04/22/2013 10:16 AM, gil wrote: >> 1) Run gradle in a debugger and try to investigate what exactly is >> causing the problem; "unexpected internal error" is not helping much. > already done And? Any results? >> 2) Check if the problem persists after replacing all dependencies with >> binary JARs used by upstream. If the issue is solved this way then you >> can try bisection method (replace half of dependencies, then quarter and >> so on, narrowing the possible cause of the problem). > i use f18 And what is your point? Does using F18 prevent you from trying the bisection method? It helped me solve several difficult cases. Besides that the message title says you are using F19/F20, so I'm a bit confused now. >> 3) Talk to the upstream. They surely know more about gradle internals >> and hopefully they will give you some advice how to fix the problem. >> > i applied a patch (#31) as suggested by A. Murdoc, gradle developer [1] > http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-printStackTrace.patch > > but dont work ... probably did something wrong ... Try changing the patch to print the stack trace even when failure is not instance of GradleException (i.e. uncomment line 13). -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange ssh / openldap linking problem
On Mon, Apr 22, 2013 at 11:27:42AM +0200, Michael Schwendt wrote: > 3) Funny things going on (f19 here), but haven't examined anything > beyond this: > > # rpm -e openldap-devel > # ldconfig -v|grep ldap > libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.9.1 > libldap-2.4.so.2 -> libldap-2.4.so.2.9.1 > # yum -y install openldap-devel > # ldconfig -v|grep ldap > libldap_r-2.4.so.2 -> libldap_r.so > libldap-2.4.so.2 -> libldap.so > > That makes no sense. On my (now fixed) system I get the same output from ldconfig: $ sudo ldconfig -v | grep ldap ldconfig: Can't stat /libx32: No such file or directory ldconfig: Path `/usr/lib' given more than once ldconfig: Path `/usr/lib64' given more than once ldconfig: Can't stat /usr/libx32: No such file or directory libsmbldap.so.0 -> libsmbldap.so.0 libldap_r-2.4.so.2 -> libldap_r.so libldap-2.4.so.2 -> libldap.so which as you say makes no sense. On the other hand, the links on the filesystem are still correct: $ ll /usr/lib64/libldap-2.4.so.2 lrwxrwxrwx. 1 root root 20 Apr 22 09:26 /usr/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FirewallD - terminology
https://fedorahosted.org/firewalld/ticket/7 thanks -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange ssh / openldap linking problem
On Mon, 22 Apr 2013 09:36:34 +0100, Richard W.M. Jones wrote: > > I'm not sure whether or not this is a bug, but it sure looks strange. > > $ rpm -qf /usr/bin/ssh > openssh-clients-6.1p1-6.fc18.x86_64 > > $ ldd /usr/bin/ssh|grep ldap > libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fad274fc000) > > /usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link > which passes through a -devel package. > > /usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18 > /usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18 > /usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18 > > To cut a long story short, I fixed this by uninstalling openldap-devel > and reinstalling it. Now there is no -devel package in the chain: > > $ ldd /usr/bin/ssh | grep ldap > libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fe8caf69000) > > /lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0 > > I'd like to understand how the original situation happened, because it > broke a supermin-built appliance (RHBZ#954185). I assume ldconfig > must have something to do with it. There is nothing unusual in the > %scripts of openldap (it just runs ldconfig as you'd expect), nor is > there any special openssh/openldap config file in /etc/ld.so.conf.d. Some thoughts: 1) ldconfig does not touch the non-versioned .so libs (especially not if they are development-only symlinks), since it only cares about the run-time libs. It adjusts the SONAME -> FULLY-VERSIONED-LIBNAME symlinks, so .so.2 will point at the latest .so.2.x.y, for example. It would not recreate a deleted .so symlink and would not redirect it either. 2) The openldap-devel package contains a (harmless) bug, since it runs ldconfig in its scriptlets. It doesn't need to. 3) Funny things going on (f19 here), but haven't examined anything beyond this: # rpm -e openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.9.1 libldap-2.4.so.2 -> libldap-2.4.so.2.9.1 # yum -y install openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 -> libldap_r.so libldap-2.4.so.2 -> libldap.so That makes no sense. In /lib64 it looks different (and correct), however: # ls -la /lib64/*ldap* lrwxrwxrwx. 1 root root 20 Apr 17 22:30 /lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.1 -rwxr-xr-x. 1 root root 336504 Apr 15 10:56 /lib64/libldap-2.4.so.2.9.1 lrwxrwxrwx. 1 root root 22 Apr 17 22:30 /lib64/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.9.1 -rwxr-xr-x. 1 root root 358720 Apr 15 10:56 /lib64/libldap_r-2.4.so.2.9.1 lrwxrwxrwx. 1 root root 22 Apr 22 11:18 /lib64/libldap_r.so -> libldap_r-2.4.so.2.9.1 lrwxrwxrwx. 1 root root 20 Apr 22 11:18 /lib64/libldap.so -> libldap-2.4.so.2.9.1 -rwxr-xr-x. 1 root root 45896 Apr 10 16:52 /lib64/libsmbldap.so.0 -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc7.git3.1.fc19.x86_64 loadavg: 0.27 0.17 0.26 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Strange ssh / openldap linking problem
I'm not sure whether or not this is a bug, but it sure looks strange. $ rpm -qf /usr/bin/ssh openssh-clients-6.1p1-6.fc18.x86_64 $ ldd /usr/bin/ssh|grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fad274fc000) /usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link which passes through a -devel package. /usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18 /usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18 /usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18 To cut a long story short, I fixed this by uninstalling openldap-devel and reinstalling it. Now there is no -devel package in the chain: $ ldd /usr/bin/ssh | grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fe8caf69000) /lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0 I'd like to understand how the original situation happened, because it broke a supermin-built appliance (RHBZ#954185). I assume ldconfig must have something to do with it. There is nothing unusual in the %scripts of openldap (it just runs ldconfig as you'd expect), nor is there any special openssh/openldap config file in /etc/ld.so.conf.d. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gradle problem in f{19,20}
Il 22/04/2013 07:18, Mikolaj Izdebski ha scritto: groovy 2.x series (and other libraries) require gradle for build, but with gradle there is a problem I tried to solve without success in f19 and f20 (in f18 work fine :( ). (the same happen when rebuild gradle in non bootstrap mode) gradle --debug jar javadoc -g /builddir/build/BUILD/hibernate-release-4.1.7.Final/gradlehome -b /builddir/build/BUILD/hibernate-release-4.1.7.Final/buildSrc/build.gradle 10:28:52.228 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer@14bd4d1, org.gradle.logging.internal.slf4j.Slf4jLoggingConfigurer@180fd99, org.gradle.logging.internal.JavaUtilLoggingConfigurer@18955ea] 10:28:52.282 [ERROR] [org.gradle.BuildExceptionReporter] 10:28:52.284 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build aborted because of an internal error. 10:28:52.287 [ERROR] [org.gradle.BuildExceptionReporter] 10:28:52.288 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong: 10:28:52.290 [ERROR] [org.gradle.BuildExceptionReporter] Build aborted because of an unexpected internal error. Please file an issue at: http://forums.gradle.org the same using -S (--full-stacktrace) parameter. any ideas? My ideas are: 1) Run gradle in a debugger and try to investigate what exactly is causing the problem; "unexpected internal error" is not helping much. already done 2) Check if the problem persists after replacing all dependencies with binary JARs used by upstream. If the issue is solved this way then you can try bisection method (replace half of dependencies, then quarter and so on, narrowing the possible cause of the problem). i use f18 3) Talk to the upstream. They surely know more about gradle internals and hopefully they will give you some advice how to fix the problem. i applied a patch (#31) as suggested by A. Murdoc, gradle developer [1] http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-printStackTrace.patch but dont work ... probably did something wrong ... thanks regards [1] Is it possible for you to temporarily add some trace to the Gradle source that you're using, as it looks like our logging is throwing away some useful details. In BuildExceptionReporter.execute(), can you add a call to failure.printStackTrace(), so that we get the full details for the failure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-04-22 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-04-22 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again today/tomorrow! We signed off on Alpha this week (yay!), so it's time for some Beta prep. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130422 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 19 Alpha recap 3. Beta release criteria 4. Test Days 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
