Re: PSA: If you are C/C++ developer, use cppcheck
On Wed, Dec 18, 2013 at 09:12:06AM +0100, Ondrej Vasik wrote: Publishing them is a bit tricky - I can of course publish them (we scan with cppcheck, enhanced gcc warnings, clang and coverity) - but the reports may contain some attack vectors - and for inactive packages, it would only show the doors to attackers. Then it's a good thing that attackers don't have any money and can't afford to buy a checker license themselves. Hiding bugs doesn't make them go away, and pretending we have tools bad people don't is a fallacy. Dave -- 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: Intent to retire: wimax, wimax-tools
On Thu, Sep 19, 2013 at 04:26:08PM -0500, Bill Nottingham wrote: Because it's pretty much dead upstream, getting towards dead in real-world deployments, and never really worked well anyway in Linux. Orphaned in F20, rawhide. If no one wants to grab it, will retire in a week or two. Kill it. We already disabled the kernel drivers in f20, because they're broken and unmaintained. Dave -- 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: abrt server report: 20130917
On Tue, Sep 17, 2013 at 03:57:55PM +0200, Michal Toman wrote: In last two weeks these components were crashing the most: 1. kernel seen 85925 times (52% of all reports) https://retrace.fedoraproject.org/faf/problems/1174076/ https://retrace.fedoraproject.org/faf/problems/1209703/ I've noticed a problem in your code that attributes blame to the 'function' field. In that second trace: Call Trace: [c043e33b] ? print_hardware_dmi_name+0x2b/0x30 [c043e3a3] warn_slowpath_common+0x63/0x80 [f7ea8413] ? carl9170_op_tx+0x733/0x810 [carl9170] [f7ea8413] ? carl9170_op_tx+0x733/0x810 [carl9170] [c043e462] warn_slowpath_null+0x22/0x30 [f7ea8413] carl9170_op_tx+0x733/0x810 [carl9170] the '?' fields are junk on the stack, and not actually the functions we're in. Instead of blaming print_hardware_dmi_name, this trace should be attributed to carl9170_op_tx. Everything else above that is either noise on the stack from previous calls, or parts of the dump trace logic. I'd ignore the ? functions completely for this purpose. Dave -- 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: numatop: %{optflags} fail the 32bit build
On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
This is the offending function:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(cpuid\n\t
: =a (*eax),
=b (*ebx),
=c (*ecx),
=d (*edx)
: a (*eax));
}
The cryptic GCC error message (inconsistent operand constraints in
an ‘asm’) refers to the fact that in PIC mode (which is activated
by the hardening flags), %ebx is a reserved register.
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (ebx),
=c (*ecx),
=d (*edx)
: 0 (*eax));
}
I have not actually tested this. There are other solutions
floating around, but they are clearly incorrect and produce wrong
code.
A better fix would be to rip all this out, and use reads from
/dev/cpu/*/cpuid, which is arch agnostic, and also takes care of cpu affinity
problems.
Dave
--
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: mass rebuild update
On Mon, Aug 05, 2013 at 02:14:55AM -0500, Dennis Gilmore wrote: going forward we need to work out how to do the perl builds quicker. there really is no reason why it needs to take as long as it does. Maybe only rebuild things that have a buildrequires on perl ? None of the rebuild notifications I got over the weekend use perl at all. Dave -- 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: Why does so much virt stuff depend on glusterfs?
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? (And why are mips ppc so much bigger ?) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote: I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently Well, it works fine for myself and for quite a few other folks I know. Cool story. I am pretty sure it's time to grow some, make this the default in Fedora, and then fix everything popping up quickyl with the necessary pressure. As it appears not having any pressure to stabilize btrfs certainly doesn't work at all for the project... Playing dangerous games with users data isn't how you effect change. All that switching default right now will achieve is a lot more pissed off users. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
On Thu, Mar 14, 2013 at 09:12:58PM +0100, Nicolas Mailhot wrote: Le Jeu 14 mars 2013 20:57, Adam Williamson a écrit : So - don't get bitten by this :) If you really want to get on the F19 branch, then just make sure you hand-check your grub config file before rebooting. Thank you for posting this I was trying to understand why grub refused to propose new kernels in boot menu. May I point out the problem would have been averted by using the correct unicode typographical apostrophe ’ (U+2019) instead of ' (U+0027) which is several symbols squatting on a single codepoint? or.. not putting the codename in the bootloader strings at all ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Tue, Mar 12, 2013 at 10:30:01AM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, F19 has been branched, please be sure to do a git pull --rebase to pick up the new branch, additionally rawhide/f20 has had inheritance cut off from previous releases, so this means that anything you do for f19 you also have to do in the master branch and do a build there. Dennis Having my local mirror wiped when I rsynced todays rawhide tree was unexpected. Having to do a full rsync again is a pain. wtf happened that caused the mirrors to be empty ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Wed, Mar 13, 2013 at 09:51:01AM -0600, Kevin Fenzi wrote:
On Wed, 13 Mar 2013 10:35:00 -0500
Chris Adams cmad...@hiwaay.net wrote:
Once upon a time, Dave Jones da...@redhat.com said:
Having my local mirror wiped when I rsynced todays rawhide tree was
unexpected. Having to do a full rsync again is a pain.
wtf happened that caused the mirrors to be empty ?
Ouch. I see that too. IIRC this happened before (maybe last
branch?). There should be some safety check that no more than X% of
files get removed in a push (where X is probably small).
It's being fixed up now.
Sorry for the trouble...
http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide
is the script that makes rawhide. Patches welcome.
Something like this (obv. untested) might at least stop wiping the whole tree
when something gets screwed up.
I guessed at the logging part, I don't know if 'failed' is valid there.
Dave
--- 1/buildrawhide~ 2013-03-13 12:28:34.613042461 -0400
+++ 2/buildrawhide 2013-03-13 12:34:03.488671561 -0400
@@ -111,7 +111,7 @@ mock -r $MOCKCONFIG --uniqueext=$DATE --
rm /mnt/koji/mash/rawhide
ln -s /mnt/koji/mash/rawhide-$DATE/rawhide$EXPANDARCH/ /mnt/koji/mash/rawhide
-echo Compose finisheded at `date --utc`
/mnt/koji/mash/rawhide-$DATE/logs/finish
+echo Compose finished at `date --utc`
/mnt/koji/mash/rawhide-$DATE/logs/finish
echo /mnt/koji/mash/rawhide-$DATE/logs/finish
# Emit a message using bodhi's cert (since we should be running as masher).
@@ -122,6 +122,19 @@ echo {\log\: \start\, \branch\: \
--json-input
cd /tmp
+
+# Check that we actually have RPMs to write out.
+COUNT=$(find . -name *.rpm | wc -l)
+if [ $COUNT-eq 0 ] ; then
+ echo No rpms generated. Something went horribly wrong\n
/mnt/koji/mash/rawhide-$DATE/logs/finish
+ echo {\log\: \failed\, \branch\: \rawhide\, \arch\: \$ARCH\} |
fedmsg-logger \
+--cert-prefix bodhi \
+--modname compose \
+--topic rawhide.rsync.complete \
+--json-input
+ exit
+fi
+
# data
$RSYNCPREFIX /usr/bin/rsync $RSYNC_OPTS --exclude repodata/
/mnt/koji/mash/rawhide-$DATE/rawhide$EXPANDARCH/ $DESTPATH
# repodata cleanup
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, Mar 04, 2013 at 08:35:08PM +0100, Miloslav Trmač wrote: On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer jwbo...@gmail.com wrote: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs Please define what you mean by stable kernel ABI. Do you mean the kernel - userspace syscall ABI? If you mean anything other than that I really don't think it's going to work. This means whatever the Linux kernel project says is their stable ABI. It was not at all intended to expand the ABI boundary. The only really guaranteed stable ABI the kernel exports is the syscall/ioctl interface, and to a lesser extent the proc/sysfs ABI. Kernels in rawhide do differ from what we end up shipping in releases, because they are continually rebased during the merge window/rc phase, wherein it's entirely possible that a new interface is refined. We've had situations for example where a new syscall added during the merge window has had additional parameters added/existing ones changed during -rc phase. This hasn't been a problem because typically, nothing relies upon an interface in unreleased kernels, but we need to make it clear here that nothing in new interfaces is frozen until a .0 release, in case people start thinking you shipped it in rawhide, so it must be stable. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abrt (was Re: Most buggy packages)
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote: I have a script that automates some of the workload of reassigning the component back to where the bug really is, but it currently requires some manual intervention: http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git so inevitably I don't run it on every bug that comes in every day, and so I gradually get behind. That looks useful. It's made of special-cases of course for your use-case, but I think we can come up with some similar rules for common things we see reported against the kernel. Perhaps one day it might be worth gathering use-cases to make some generic triage tool. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abrt (was Re: Most buggy packages)
On Tue, Feb 19, 2013 at 10:10:38PM +0100, Jiri Moskovcak wrote: So if you want to hack this into a tool for use on kernel bugs, go for it. ...and please integrate with abrt! Let's have it all working together :) - I am all for it, the abrt server is exactly the place where these kind of things should be What I have in mind is the cases where some human interaction is still necessary. Adding heuristics on the server side for certain cases would help us, but there are still a bunch of common operations we do that require a human to make a judgment call before we make a change. But, pursuing the server-side solution, here are some things that we'd find useful that *could* be automated. - Unlike most packages, we have individual maintainers for subcomponents (this is where our bugzilla implementation sucks, because we can't file by subcomponent). So when we get bugs against certain drivers, or filesystems etc, we reassign to those developers who signed up to work on those. This probably counts for a significant percentage of our interactions with bugzilla. I'm not sure what kind of heuristics you'd need to add to automate assigning to the right person. Maybe you can pull the symbol from the IP, translate that to a filename, and have a database of wildcards so you can do things like.. drivers/net/wireless/* - linville@ fs/btrfs/* - zab@ etc.. Because it's not always easy from a report to tell what component is responsible, sometimes parsing the Summary is necessary, which is the sort of thing I meant by 'needs human to make a judgment call'. But if we can automate the majority of the cases, it would still help a lot. - Similar thing as previous, but all graphics bugs get reassigned by us immediately to xorg-x11-drv-* because those guys deal with both the X and kernel modesetting/dri code. So any trace with 'i915', 'radeon' etc can probably be auto-reassigned. - When we get 'general protection fault' bugs, it's useful to run the Code: line of the oops through scripts/decodecode (from a kernel tree). This disassembly will allow us to see what instruction caused the GPF. (Note: *just* general protection faults, not every trace. Also, we only really need the faulting instruction, not the whole disassembly). Bonus points if it can suck the relevant data out of the debuginfo rpms to map the code line to C code. - Extrapolating from the above, when we see certain register values in those bugs, they usually hint at the cause of a bug. For example 0x6b6b6b6b is SLAB_POISON, and usually means we tried to use memory after it was freed. Adding a comment to point this out speeds up analysis. - Getting trickier.. We see a *lot* of flaky hardware, where we tried to dereference an address which had a single bit flip in memory. If the server side had some smarts so it knew what 'good' addresses looked like, it could detect the single bit-flip case, and guide the user to run memtest86 will save us a round-trip. That's all I have right now, but there are probably a bunch of other common operations we do which could be automated. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Fri, Jan 04, 2013 at 09:40:27PM +0100, Jakub Jelinek wrote: Hi! As part of preparations for possible switch of system compiler in F19 to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.7.2-9.fc19 to quickly remove from the list packages that fail for non-gcc related reasons. 11687 packages built fine, 933 packages failed to build with both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm (ignored for this analysis, unlikely to be gcc 4.8 related). The remaining packages, that failed to build with 4.8.0-0.1 and succeeded with 4.7.2-9 are listed below. 67 of these look like issues on the package side, 22 gcc bugs that were supposedly fixed by now upstream and thus should be ok in 4.8.0-0.3 when it is built next week and 3 are not yet fixed gcc issues. I'm pleasantly surprised that the kernel isn't in the failure list. No issues at all ? Or was it skipped for some reason ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; use a compressed filesystem, don't use a kernel at all and some container based approach instead of full virt for your cloud instances (you could even base them on a btrfs subvolume and save more space that way). Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. So while it is a way it is not the only way. As reluctant as I am to introduce new kernel packages, an ultra-minimal kernel package for use in cloud environments may make more sense than splitting up the one-size-fits-all packages into hundreds of sub-packages. But even this option is a lot of work, and isn't a panacea. With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On Thu, Oct 04, 2012 at 04:52:19PM +0200, Richard Marko wrote: kernel 220 ▁▂▄▅▇▇█ Nice graphs! What's this about? -- These are the statistics generated by ABRT Server deployed on [1]. We are going to send these reports weekly as they should help developers prioritize their work. We expect them to become more and more accurate as more people will start using new versions of ABRT with simplified reporting [2]. Note that kernel is incorrectly blamed as the most destabilized component as we started handling kerneloops reports only last week. Feedback is really appreciated mainly on these topics: - structure of this email, - clustering quality, - backtrace quality, - kerneloops processing. Feature request: Can you do the same backtrace hashing abrt does, and provide a link to any bugs in bugzilla with the abrt_hash in the whiteboard ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On Thu, Oct 04, 2012 at 11:02:43AM -0400, Dave Jones wrote: On Thu, Oct 04, 2012 at 04:52:19PM +0200, Richard Marko wrote: kernel 220 ▁▂▄▅▇▇█ Nice graphs! What's this about? -- These are the statistics generated by ABRT Server deployed on [1]. We are going to send these reports weekly as they should help developers prioritize their work. We expect them to become more and more accurate as more people will start using new versions of ABRT with simplified reporting [2]. Note that kernel is incorrectly blamed as the most destabilized component as we started handling kerneloops reports only last week. Feedback is really appreciated mainly on these topics: - structure of this email, - clustering quality, - backtrace quality, - kerneloops processing. Feature request: Can you do the same backtrace hashing abrt does, and provide a link to any bugs in bugzilla with the abrt_hash in the whiteboard ? Never mind. It seems you do that, and I was looking at reports where no bug had been filed. Perhaps print no bug filed yet in that case ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On Thu, Oct 04, 2012 at 11:10:47AM -0400, Dave Jones wrote: Feature request: Can you do the same backtrace hashing abrt does, and provide a link to any bugs in bugzilla with the abrt_hash in the whiteboard ? Never mind. It seems you do that, and I was looking at reports where no bug had been filed. Perhaps print no bug filed yet in that case ? Something else just occurred to me, that might be useful, would be to print the top-most function in the summary page. Looking at https://retrace.fedoraproject.org/faf/problems/hot/*/*/kernel/ it would be useful if I could see at a glance that bug 13935 was a wireless bug, without needing to click into it. But... A lot of the 'function' fields on kernel bugs are going to be the same. warn_slowpath_common or warn_slowpath_null. We have a billion WARN() statements all over the kernel, and it's more useful knowing the location of where those are placed than the function name of the WARN statement. Ie, the summary for https://retrace.fedoraproject.org/faf/problems/13955/ should show function: brcms_c_wait_for_tx_completion. There may be a few other function names that would also require similar special casing. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT Server
On Wed, Sep 05, 2012 at 11:39:31AM +0200, Michal Toman wrote: We believe this will help developers to better prioritize their work and make debugging easier (crashes in common libraries are grouped into a single problem, for each crash versions of affected packages/architectures are listed etc.). The 'hot problems' will be very useful for us, as we were just talking last week about reporting such a list upstream periodically. I looked at the only kernel bug caught so far.. https://retrace.fedoraproject.org/faf/reports/452/ 'my_init' isn't part of the kernel package. Could you add some way of filtering out reports from things we don't ship ? Or was this a test-case ? Related: How would I close reports so they don't show up on the list ? Further related: Clicking 'login' makes this happen.. DoesNotExist at /auth/login/ Site matching query does not exist. Request Method: GET Request URL: https://retrace.fedoraproject.org/faf/auth/login/?next=/faf/reports/452/ Django Version: 1.3.1 Exception Type: DoesNotExist Exception Value: Site matching query does not exist. Exception Location: /usr/lib/python2.6/site-packages/django/db/models/query.py in get, line 349 Python Executable: /usr/bin/python Python Version: 2.6.6 Python Path: ['/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.3-py2.6-linux-x86_64.egg', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/gtk-2.0', '/usr/lib/python2.6/site-packages', '/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info'] Server time:Wed, 5 Sep 2012 19:45:33 +0200 followed by 3-4 pages of additional spew. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Wed, May 09, 2012 at 11:20:43AM -0700, John Reiser wrote: 1G fits on both the smallest MiniDVD format and most extant USB sticks. Let's do it already. If so, then please acknowledge explicitly that Fedora would be discarding some 4% of running, otherwise-capable machines (especially old laptops) that can read only CD and not DVD As someone who frequently sees bugs that are attributed to old half-dead hardware that belongs in a recycling center, I'll happily acknowledge anything that leaves ancient junk behind. I'd like to see us introduce more explicit cut-offs for support of older hardware. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel-modules-extra and GFS2
On Wed, Apr 11, 2012 at 07:19:32AM -0400, Josh Boyer wrote: I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?) Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package? I'm leaning towards saying that would be the right thing to do. Things that are not widely used in a typical Fedora setup, or things that we might disable entirely but are moving to see if there are users that notice. GFS2 falls into the first set, not the second. For exactly this reason. Your comment about DLM is helpful, though I seem to recall there may have been another reason we couldn't move that to -extras at the time it was implemented. (Was that non-modular for a while maybe?). We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed. I've added an item to discuss this on the agenda for this weeks Fedora kernel meeting[*] for anyone interested. Dave [*] https://fedoraproject.org/wiki/Meeting_channel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel-modules-extra and GFS2
On Wed, Apr 11, 2012 at 04:48:38PM +0200, Thorsten Leemhuis wrote: [*] https://fedoraproject.org/wiki/Meeting_channel Related question: Should http://lists.fedoraproject.org/pipermail/kernel/2012-March/003711.html ([PATCH] rawhide: enable HYPERV drivers) also be on the agenda? It seems to me the topic was simply forgotten? Does it really need any discussion ? Seems like a no-brainer for rawhide really as long as it doesn't negatively affect any of the existing virt stuff. Justin, want to hook that up in the next build ? While at it: Why not enable those drivers for F17, too, even if the last hv driver leaves staging only in 3.4(¹)? I'd like it to at least shake out in rawhide for a little first, just to be sure there's nothing unexpected there. BTW: Why is the agenda not in the wiki? Or was I to stupid to find it? No real reason. Is there a namespace already on the wiki for agendas, or shall we just add it under the kernel namespace ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster. What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs? tmpfs contents are pageable, and will be swapped out if necessary. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. The buildroots get regenerated every time anyway, so journalling isn't really getting you anything. If a builder crashes, you probably want to throw the old buildroot away and start over anyway. out of curiousity, Is the setup of the builders documented somewhere ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:32:04AM -0400, Zach Brown wrote: On 03/21/2012 10:58 AM, Dave Jones wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. You could also turn off the journal in ext4. That'd lose the journal IO and stalls waiting for it and you'd still get the block mapping IO savings of delalloc and extents. Yes, that would be even better. (Hi Zab!) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 12:54:36PM -0400, Jon Masters wrote: The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Why are you even bringing up this as yet unreleased hardware in the context of arm32 builds are slow ? Even if it was released today, it doesn't solve this problem at all. Arm32 as primary and Arm64 as primary are two entirely separate discussions, and conflating the two isn't solving anything. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: No package should be automatically changing the sysrq policy. Why not? For example, I use a commercial backup program that makes extensive use of IPC and needs the msgmni and msgmnb limits raised beyond the default values. Why shouldn't they be able to include that change in their RPM? What happens if two packages want to set a sysctl to different values ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 09:42:50PM +0200, Muayyad AlSadi wrote: What happens if two packages want to set a sysctl to different values ? that's why they are prefixed with numbers, the higher number will take effect eg. 99-foobar.conf sometimes we have conventions for number ranges like this http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Choosing_a_ruleset_numeral_prefix 50 User overrides 51 Local system overrides ... But for a system wide change, that's insufficient. If 00-foo sets something to value A, and 99-bar sets it to B, and B A, foo may not function correctly. This isn't an ordering problem, it's an exclusivity problem, because sysctls are system-wide, not per-package. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Kernel Team Meeting agenda Mar 2 2012
The kernel has several widespread bugs that are affecting all releases, that are impacting a lot of users. * Hibernation There are so many bugs here it's hard to know where to begin. - We have cases where it fails to sleep, or resumes instantly. - There are cases where it looks to be working ok, but shortly after resuming, we see oopses/panics etc. It looks like something is scribbling over random parts of memory (usually landing on the dcache) - For some of those cases, it's an i915 bug where disabling modesetting works around it. We've seen similar bugs from non-i915 hardware though. * Root dentry has weird name A number of users are seeing this message, which again, looks like something scribbled over the dcache. Some, but not all were using hibernate, so we have possibly another case of kernel memory corruption. (or perhaps resuming from hibernate makes this bug easier to hit) * Page table corruption. We have an alarming number of reports from users seeing 'bad page map' or 'bad page entry' messages from the kernel. There's no real pattern here that we can see. We have a number of ideas to try and further diagnose this, which we'll discuss at 18:00UTC today, in our bi-weekly kernel meeting in #fedora-meeting. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 Linux 3.1 soft lockups
On Mon, Feb 20, 2012 at 06:39:54PM +0100, Michał Piotrowski wrote: Hi, W dniu 7 stycznia 2012 16:34 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: Hi, I've noticed some strange soft lockup behaviour on my system (please see the attachment). Soft lockup appears to be caused by kswapd0 process. It seems to me that in both cases this error occured when I used git fsck --full or git gc commands. I've got the same problem on 3.2.6-3.fc16. Any ideas what might be happening? I turned off the swap partition to see if this help. Is this happening inside a virtual guest ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, Feb 16, 2012 at 10:22:03AM +0530, Rahul Sundaram wrote: On 02/16/2012 10:08 AM, Genes MailLists wrote: Not to mention that the kernel devs use gcc to compile the kernel - and it most certainly puts a lot of pressure on the compiler. I suspect unless linus drops gcc as well, we'll at a minimum need to keep it to build the kernel itself. Not quite. LLVM can be used to build the kernel The last I heard on this, it was very basic. Parts of the kernel wouldn't compile/work. Including fundamental stuff, like the module loader. I believe it still used gcc for some parts that choked llvm too. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Slowness
On Thu, Feb 16, 2012 at 10:44:45AM -0600, Mike Chambers wrote: Just seeing if it's just me, or we back to being slow again during testing with the debug options and the kernel? Am on a F16 kernel and is little better than F17 3.3 kernels. the first -rc build of each kernel release has debug turned off. subsequent builds reenable it. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote: According to the updates policy the maintainer needs to consider that their change will cause problems for third party kernel module packagers and end users that are compiling their own kernel modules. We *know* we're going to break out of tree modules. It's entirely expected. There's nothing to consider here at all. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote: So, yes, it may be fully expected that issuing an update will break out of tree modules but that doesn't stop it from being one factor to *consider*. Consideration implies that the following thought process will occur This update will break out of tree modules, perhaps we shouldn't push it. That isn't going to happen. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 07:24:20PM +0100, Thomas Moschny wrote: 2011/11/22 Dave Jones da...@redhat.com: On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote: Consideration implies that the following thought process will occur This update will break out of tree modules, perhaps we shouldn't push it. That isn't going to happen. To me, this sounds like knowingly violating the Updates Policy, which states: Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. (Ignoring the fact that changing a documented unstable API isn't anything to do with a developer experience) The kernel gets more bugs filed against it than any other component in the distro. Obviously this needs to be dealt with somehow. Asides from rebasing, we have two alternatives. 1. We backport just the fixes from upstream. Not feasible with the limited manpower we have. (See F14 for a great example of this failing) 2. We close every bug with -NEXTRELEASE If someone wants to do the relevant beurocracy to document this in the policies, go wild, but the kernel has always been this way since Fedora's inception. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
no rawhide images/
Looking at http://kojipkgs.fedoraproject.org/mash/rawhide-2014/logs/mash.log (and previous logs), I don't see any obvious message for why the images/ directory isn't being created in the composes. anyone have info on what's broken ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: no rawhide images/
On Mon, Nov 14, 2011 at 10:29:10AM -0800, Jesse Keating wrote: On Nov 14, 2011, at 10:24 AM, Dave Jones wrote: Looking at http://kojipkgs.fedoraproject.org/mash/rawhide-2014/logs/mash.log (and previous logs), I don't see any obvious message for why the images/ directory isn't being created in the composes. anyone have info on what's broken ? Dave We don't make images for Rawhide, we haven't for a number of releases now. Images only get turned on when we branch. that's unfortunate. f16 doesn't pxe install for me, and I'd rather make sure this doesn't affect 17 sooner rather than later. Where can I find the compose scripts So I can build images locally to debug this ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Wed, Oct 05, 2011 at 07:33:22AM -0500, Bruno Wolff III wrote: On Mon, Oct 03, 2011 at 15:36:27 -0400, Dave Jones da...@redhat.com wrote: So we're thinking of trying this again this thursday with a focus on 16, (but triage work on older releases is welcomed too). I have a bug (36242 at the unavailable kernel bugzilla and 684424 in Fedora) where sound being played using my motherboard sound chip and high I/O (it seems like network traffic more so than disk) results in a hang. I haven't been able to get a crash dump or traceback once the hang occurs. I'd be interested in getting this bug looked at, but I think I need some suggestions for how to get a traceback, or there isn't going to be enough info to track this down. I tried some kernel boot parameters to get watchdog timeouts, but that didn't work. Maybe I need to rebuild the kernel with a different config to really enable that feature though? The kernel-debug rpm should have everything you'd need. Hardware specific problems like this are a nightmare for us to diagnose. It might even come down to you needing to do a bisect to find the individual kernel change that caused the problem. (assuming you know a 'good' version to start from) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
Some details about the triage day we are holding tomorrow. Where: #fedora-kernel on irc.freenode.net When: October 6th 2011 What: The primary focus is going to be on getting things in the best shape possible for Fedora 16's release. However there are some useful things that can be done for all releases. * Fedora 14 At this point in 14's lifecycle, many open bugs are not going to be fixed, due to the amount of work necessary to identify and backport individual fixes. Because of this, identifying open bugs that are still relevant on 15/16 is important, so we don't perpetually have to keep dragging these bugs forward every release. * Fedora 15 F15 bugs that are likely to affect F16 are obviously of importance, so triage assistance on those bugs is useful. If a bug is confirmed to be still present in Fedora 16, add 'F16' to the whiteboard field. * Fedora 16: With the release of the F16 beta, the primary focus will be to make sure the existing bugs are all properly assigned, and triaged. * Rawhide: At the moment, Rawhide is essentially in-sync with F16. The main difference is that Rawhide kernels have debugging enabled by default, whereas F16 doesn't (except for the kernel-debug builds). Because F16 is the upcoming release, we're focusing there but bugs found in Rawhide will likely still occur in F16 as well. However, there are a number of 'perpetual' bugs that are stuck in rawhide (especially Feature requests and WIP items) and those should probably be avoided for now. When in doubt, focus on F16. General info: * See https://fedoraproject.org/wiki/KernelTriage for further 'howto' info. * Of particular importance are bugs that will prevent installation, break networking, or cause system hangs. These bugs should be marked as blocking the f16blocker bug. To do this, you can use the 'f16blocker' alias or the actual bug number 713568. Confirm in IRC before adding them to the tracker bug. If you don't have the Bugzilla powers to add them to the tracker bug, ask in IRC and someone else will be able to do it for you. * Bugs that aren't serious enough to be blockers but might warrant special effort to fix might be added to the F16-accepted tracker (bug number 713566). Again, check in the channel before adding a bug to this tracker. Useful links: All open f14 kernel bugs: http://bit.ly/nmkC8m All open f15 kernel bugs: http://bit.ly/pIpDdM All open f16 kernel bugs: http://bit.ly/ouhRBY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Mon, Aug 22, 2011 at 10:24:45PM -0400, Dave Jones wrote: On Mon, Aug 22, 2011 at 03:33:24PM -0700, Adam Williamson wrote: We'll be doing this in #fedora-kernel next Monday (22nd) I expect that the wiki page will continue to evolve as we start working on this, and perhaps this can even become a regular thing. apologies for not helping with this; turned out to be bad timing for me, I didn't even get to decompress from Alpha last week before I had to spend three days at Linuxcon, and spent most of the weekend in a dazed heap on the couch...sorry again! You didn't miss much. Turned out to be a non-event. Maybe we'll give it another shot in a few weeks. So we're thinking of trying this again this thursday with a focus on 16, (but triage work on older releases is welcomed too). Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 03:59:02PM -0500, Bruno Wolff III wrote: I think the degree of slow down now, compared with the past, makes this issue a bug. If things are like they are now, I won't be running debug kernels on my rawhide systems. It costs me too much time. It would be nice to know why things changed, as maybe some adjustments could be made (or a bug fixed) so that debug kernels can provide useful information without making such a big impact. my last comment from the bug asked for someone to provide perf output. If we can at least narrow it down to which option is causing people pain, maybe we can start to investigate why. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Mon, Aug 29, 2011 at 10:31:09AM -0500, Jon Ciesla wrote: P.S. Your argument will be moot when the kernel drops the floppy module. Is there actually a plan for this to happen? Curious, not arguing here. Not any time soon. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Sat, Aug 27, 2011 at 05:35:19PM +0100, Richard W.M. Jones wrote: Why does it need so much to start with? Because the installer initrd contains the kitchen sink. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Mon, Aug 22, 2011 at 03:33:24PM -0700, Adam Williamson wrote: We'll be doing this in #fedora-kernel next Monday (22nd) I expect that the wiki page will continue to evolve as we start working on this, and perhaps this can even become a regular thing. apologies for not helping with this; turned out to be bad timing for me, I didn't even get to decompress from Alpha last week before I had to spend three days at Linuxcon, and spent most of the weekend in a dazed heap on the couch...sorry again! You didn't miss much. Turned out to be a non-event. Maybe we'll give it another shot in a few weeks. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora kernel bug day.
We've been planning on doing one of these forever, but never seeming to get around to it. The kernel gets a lot of bugs (possibly more than any other package), and as such, we've got nearly a thousand bugs open right now, and just three people working on it full-time. The problem we've faced with triage efforts in the past is that for many bugs, the person doing the triage really needs to have at least some kernel knowledge to know what information to ask the reporter. However, there are some basic tasks that would help us out a lot, like making sure bugs are assigned to the right people etc. There's a first pass at some 'how to' ideas at https://fedoraproject.org/wiki/KernelTriage We'll be doing this in #fedora-kernel next Monday (22nd) I expect that the wiki page will continue to evolve as we start working on this, and perhaps this can even become a regular thing. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji: kernel-2.6.40-3.fc15
On Sat, Jul 30, 2011 at 01:16:43AM +0200, Reindl Harald wrote: i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since some minutes, boot looked fine, after a minute a got a btrfs-stack-trace hope this helps (no i do not tend use btrfs in production *gg*) hmm, doesn't look like that one has been reported before. Can you file this in bugzilla please ? I expect Josef will want to take a look at it next week. thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji: kernel-2.6.40-3.fc15
On Fri, Jul 29, 2011 at 10:29:58PM -0400, Genes MailLists wrote: wasn't there some kind of issue in vm's ? Maybe I'm not remembering correctly. too vague to comment. there are always 'issues in vm's :) Dave - how is the 2.6.40 code different or not from 3.0.0-2 ? pretty much the same thing. Josh added a udl patch to f16 after I kicked off the f15 build. Likewise I added a scsi patch to f15 but didn't get around to adding it to 16. they'll sync up soon. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide openssh-server update kills sshd
On Tue, Jul 26, 2011 at 06:22:50PM +0200, Jim Meyering wrote: FYI, I've just yum-updated my rawhide VM to the latest (but not from the console) and was surprised to lose the connection while it was happening. Again. It happened to me last week, too. I got back in via the console and tried to reinstall it via yum reinstall openssh-server. That failed (sorry, didn't record the diagnostic). Just dug a little and found this was reported a week ago: http://bugzilla.redhat.com/722625 It bit me again yesterday, this time while in a screen session (I thought I'd learn from the earlier mistake). When I logged back in, somehow the screen session had vanished. This behaviour from sshd is pretty nasty. I don't recall it ever doing this before on updates, so why does it start doing it now ? arguably that bz should be reassigned to sshd, as that's the root cause for yum freaking out. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ INFO: possible recursive locking detected ] systemd-logind/651 is trying to acquire lock:
On Fri, Jul 15, 2011 at 12:11:43PM +0400, Lucas wrote: Dear All. Just updated and got the following in dmesg: Thanks, I just reported this upstream. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (v3)
On Thu, Jul 14, 2011 at 03:39:13PM -0400, Bill Nottingham wrote: Orphan isic seeing as I took ip6sic which is similar, I'll take this too. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Tue, Jul 12, 2011 at 05:12:07PM -0400, Bill Nottingham wrote: Orphan minicom comaintained by: jcapik If something is orphaned, but has comaintainers, is that enough to keep it in the distro ? Not really - we'd like one of the comaintainers to pick it up as primary maintainer. Once it gets closer to branch time, we may be poking comaintainers individually to pick things up. There's been talk of making pkgdb do that automatically on orphaning, but it does not at this time. I kinda rely on this package, so I'm prepared to step up if jcapik doesn't want to be maintainer for whatever reason, though my efforts would strictly be enough to just keeping it building. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Tue, Jul 12, 2011 at 05:04:51PM -0400, Dave Jones wrote: On Tue, Jul 12, 2011 at 03:28:59PM -0400, Bill Nottingham wrote: Orphan ip6sic I've used this from time to time. I'll pick it up. So I took maintainership in pkgdb. Now every time I commit, I get a bounce email from ip6sic-ow...@fedoraproject.org. Will that address be automatically recreated and pointed at me at some point ? Or do I need to go click something else in pkgdb ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, Jul 12, 2011 at 06:47:12PM -0400, Chuck Anderson wrote: Orphan midisport-firmware I own hardware that uses this. Taken. you'll want to take its dependancy too 'fxload' Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i915 errors from 3.0 kernel
On Wed, Jun 29, 2011 at 01:40:06PM -0400, Genes MailLists wrote: I thought so - glad its benign ... I assume the messages will sometimes be useful to the kernel team ... so should I keep mentioning new ones or only if its an actual OOPS? If you have abrt installed it will file bugs where necessary, (and also take care of dupes so you won't have to search for them first). Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appletalk+psnap+ipx modules in the kernel-3.0-0.rc3.git5.1.fc16
On Sat, Jun 18, 2011 at 12:54:14PM +0400, Lucas wrote: Dear All I have installed the latest kernel from koji and found out that now I have 3 new modules: appletalk psnap ipx I know what is IPX. But do we really need to have AppleTalk always loaded in the kernel? Protocols get auto-loaded when something tries to open a socket belonging to that family, or when a packet is recieved from the network. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Sat, Jun 11, 2011 at 01:27:44PM -0700, Garrett Holmstrom wrote: On 2011-06-11 12:11, Lucas wrote: Actually it does relabel by it self after boot with option selinux=0 That sounds rather useful. How does it know whether or not it was previously booted with selinux=0? booting with selinux=0 creates /.autorelabel If you boot without it, and that file exists, relabeling occurs. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: I agree. As virtualization technology becomes more and more involved and frequent on users systems, particularly with advanced Linux users, I think there needs to be a strong focus on ensuring that all releases run in virtualized environments without any major issues. ie. Virtualbox. Perhaps a dedicated team among the developers who specialize in this area. I don't think there are any developers working on this area, where this area is Virtualbox. We don't ship Virtualbox. We don't ship a kernel that has any knowledge of Virtualbox. There's a good argument for having this be part of the QA process and requiring that we boot in the common virtualisation environments as part of the release criteria, but I don't think we can realistically suggest that our virtualisation developers (who work on code that has nothing to do with Virtualbox) be responsible for that. I'm curious why virtualbox has gained so much inertia so quickly. Based solely on the number of kernel bug reports we get that seem to be related to it, I have almost zero confidence in it being reliable. Why are people choosing it over other solutions, and what can we change in qemu/kvm to get users using that instead ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning packages: fxload midisport-firmware
I don't own a device to test this any more, so I'm going to orphan these two. If anyone wants them, they're very low maintainence. (mostly just keeping up with package guideline changes, though there's a newer version of fxload available, but the absense of hardware made me nervous to blindly rebase without testing) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 9base in Fedora?
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote: What would cause someone to choose to use these tools rather than the ones that exist in Fedora already? They come from an environment where plan9 is more commonly used Rob Pike's house ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel: CONFIG_NF_CONNTRACK=y
On Mon, May 16, 2011 at 07:02:04PM +0200, Xose Vazquez Perez wrote: On 05/14/2011 06:10 PM, Dave Jones wrote: It used to be a module, but was converted to built-in as we were always loading it in the network scripts. A lot of the decisions made in those '5 second boot' days seem a bit boneheaded in hindsight. For f16, we should do a good re-review of such decisions, and decide what makes sense and what doesn't, and where possible fix the startup scripts instead of working around them. indeed, the *complete kernel config* should be reviewed by the fedora kernel team. There are modules included(yes) in the kernel, missing options and modules, etc... These greps should help: look for static values: $ egrep -v =m|=y|is not set config look for missing features/modules: $ egrep -v =\|=[0-9]|=m|=y config look for yes, included features/modules: $ egrep -v =\|=[0-9]|=m|is not set config and also take a look to menuconfig. For the 'missing' options, there's usually a reason why they haven't been enabled. We could do a better job at documenting those decisions (perhaps even in the config files themselves) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel: CONFIG_NF_CONNTRACK=y
On Sat, May 14, 2011 at 05:22:35PM +0200, Xose Vazquez Perez wrote: hi, why is it 'yes' instead of 'm'(module)? bug/feature?? performance troubles: http://marc.info/?l=linux-netdevm=130212178423334w=2 It used to be a module, but was converted to built-in as we were always loading it in the network scripts. A lot of the decisions made in those '5 second boot' days seem a bit boneheaded in hindsight. For f16, we should do a good re-review of such decisions, and decide what makes sense and what doesn't, and where possible fix the startup scripts instead of working around them. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: powertop2 vs powertop
On Mon, Mar 14, 2011 at 06:53:31PM +0100, jan.klepek wrote: In not so recent past, powertop2 alpha has been released [1] and it is currently in version 1.97. It is usuable and I was thinking about packaging it for Fedora. However, there is already old powertop. So I will have to package it as powertop2 because it is completely different tool. Does it have sense to package it as powertop2? Or should rather powertop package maintainer update powertop package with new sources (even when they are considered as alpha)? Is powertop1 going to continue to be updated ? I would assume not, and having both in the archive is just going to cause confusion. What's wrong with waiting for the non-alpha version, and then updating the existing powertop package ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)
On Mon, Dec 13, 2010 at 12:46:04AM +0100, Jiri Moskovcak wrote: Apropos of nothing: kerneloops reporting seems to have been broken ever since we switched from using the kerneloops client to abrt, but that's another story.. - I reported quite a few oops using abrt (even found them on the koops server), but it's quite some time since I checked if it's still working, I'll test that tmrw poking around the kerneloops site some more, I'm wondering if some stuff has broken server-side. As well as the number of submissions dropped off significantly, it isn't registering anything newer than 2.6.34rc I'll ping arjan about it tomorrow. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)
On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote: The problem here is that some maintainers doesn't want ABRT reports at all even those not yet reported... It's arguable that such people are 'maintainers' at all if this is the case. I find it quite sad that we have packagers who don't care about the quality of what they are packaging beyond the specfile. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)
On Sun, Dec 12, 2010 at 02:11:27AM +0100, Kevin Kofler wrote: Dave Jones wrote: On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote: The problem here is that some maintainers doesn't want ABRT reports at all even those not yet reported... It's arguable that such people are 'maintainers' at all if this is the case. I find it quite sad that we have packagers who don't care about the quality of what they are packaging beyond the specfile. … says the maintainer of the one package in Fedora for which ABRT reports the bugs directly upstream. I'm not sure what point you're trying to make, but there's a pretty big difference between completely ignoring automatically filed bugs (regardless of where they're filed), and automatically filing those bugs upstream. Apropos of nothing: kerneloops reporting seems to have been broken ever since we switched from using the kerneloops client to abrt, but that's another story.. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)
On Fri, Dec 10, 2010 at 10:51:39AM +0100, Jiri Moskovcak wrote: The problem is entirely cosmetic. No data is harmed, the program exits after that, it's just a child thread and the main process don't communicate the exit quite right. So, pretty much everyone who uses calibre sees this. I haven't been able to fix it (any help welcome), so in this case I might want to disable abrt reports for now until it's fixed, but enable them again once it is. If there was some easy way for me to do this without requiring a new abrt package be pushed out that would be great. ;) added as: provide a way for maintainers to blacklist their packages without changes into abrt package https://fedorahosted.org/abrt/wiki/Wishlist This sounds wrong to me. Blacklisting a specific trace so further reports of it get ignored makes sense, but not ignoring all (unrelated) crashes in a package. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
updates-testing trainwreck.
Wtf happened in updates-testing ? gdm and a bunch of other stuff crashes on startup.. NetworkManager[1059]: error [1290185488.399900] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name NetworkManager[1059]: error [1290185488.401072] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name NetworkManager[1059]: error [1290185488.401317] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name kernel: [ 13.535165] gnome-settings-[1555]: segfault at 7f481f9b1d70 ip 0031fa9323d8 sp 7fff0bdc9db8 error 4 in libc-2.12.90.so[31fa80+19a000] rtkit-daemon[1588]: Successfully made thread 1584 of process 1584 ((unreachable)/usr/bin/pulseaudio) owned by '42' high priority at nice level -11. rtkit-daemon[1588]: Successfully made thread 1606 of process 1584 ((unreachable)/usr/bin/pulseaudio) owned by '42' RT at priority 5. rtkit-daemon[1588]: Successfully made thread 1619 of process 1584 ((unreachable)/usr/bin/pulseaudio) owned by '42' RT at priority 5. kernel: [ 13.995347] gnome-power-man[1574]: segfault at 7fe10283ad70 ip 0031fa9323d8 sp 7fff6d775cd8 error 4 in libc-2.12.90.so[31fa80+19a000] gdm[1622]: *** START ** rtkit-daemon[1588]: Successfully made thread 1625 of process 1584 ((unreachable)/usr/bin/pulseaudio) owned by '42' RT at priority 5. gdm[1622]: [Thread debugging using libthread_db enabled] gdm[1622]: [New Thread 0x7f967700 (LWP 1581)] gdm[1622]: [New Thread 0x7f968500e700 (LWP 1580)] gdm[1622]: 0x0031fac0ef5d in waitpid () from /lib64/libpthread.so.0 gdm[1622]: #0 0x0031fac0ef5d in waitpid () from /lib64/libpthread.so.0 gdm[1622]: #1 0x004330cb in ?? () gdm[1622]: #2 0x0043317a in ?? () gdm[1622]: #3 signal handler called gdm[1622]: #4 0x0031fa9323d8 in __strcmp_ssse3 () from /lib64/libc.so.6 gdm[1622]: #5 0x003203110f91 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #6 0x003203116d3f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #7 0x0032031185ba in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #8 0x0032031189d6 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #9 0x0032031195aa in gtk_icon_theme_lookup_icon () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #10 0x00320311a08c in gtk_icon_theme_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #11 0x00320312ab63 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #12 0x00320312aff8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #13 0x00320312b0ac in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #14 0x0031fcc0df89 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 gdm[1622]: #15 0x0031fcc1e64c in ?? () from /lib64/libgobject-2.0.so.0 gdm[1622]: #16 0x0031fcc287b5 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 gdm[1622]: #17 0x0031fcc28b6d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 gdm[1622]: #18 0x0032031caf48 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #19 0x00320308ec61 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #20 0x0031fcc0df89 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 gdm[1622]: #21 0x0031fcc1e64c in ?? () from /lib64/libgobject-2.0.so.0 gdm[1622]: #22 0x0031fcc287b5 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 gdm[1622]: #23 0x0031fcc28b6d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 gdm[1622]: #24 0x0032031caf48 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #25 0x00320308649f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #26 0x0031fcc0df89 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 gdm[1622]: #27 0x0031fcc1e64c in ?? () from /lib64/libgobject-2.0.so.0 gdm[1622]: #28 0x0031fcc287b5 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 gdm[1622]: #29 0x0031fcc28b6d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 gdm[1622]: #30 0x0032031caf48 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #31 0x00424345 in ?? () gdm[1622]: #32 0x0031fcc0e03e in g_closure_invoke () from /lib64/libgobject-2.0.so.0 gdm[1622]: #33 0x0031fcc1e64c in ?? () from /lib64/libgobject-2.0.so.0 gdm[1622]: #34 0x0031fcc287b5 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 gdm[1622]: #35 0x0031fcc28b6d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 gdm[1622]: #36 0x0032031caf48 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #37 0x003203295faa in ?? () from
Re: updates-testing trainwreck.
On Fri, Nov 19, 2010 at 01:23:26PM -0500, Ray Strode wrote: Hi, On Fri, Nov 19, 2010 at 12:15 PM, Dave Jones da...@redhat.com wrote: Wtf happened in updates-testing ? gdm and a bunch of other stuff crashes on startup.. gdm[1622]: #9 0x0032031195aa in gtk_icon_theme_lookup_icon () from /usr/lib64/libgtk-x11-2.0.so.0 gdm[1622]: #10 0x00320311a08c in gtk_icon_theme_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 Maybe your icon cache got corrupt somehow? does touch /usr/share/icons/* fix things? it did! thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 04:23:56PM +0100, Jakub Jelinek wrote: It is very sad that Intel/AMD just didn't make sure rep movsb isn't the fastest copying sequence on all of their CPUs, which underneath could do whatever magic based on size and src/dst alignment (e.g. for small length handle it in hw so it is as quick as possible, for larger sizes perhaps handle it in microcode) - rep movsb can be easily inlined and is quite short as well. But on many, especially recent, CPUs it performs very badly compared to these much larger SSE* optimized routines. If you want exact numbers, best ask Intel folks who wrote and tuned the SSE4.2 memcpy routine. I wonder if the Intel people who benchmarked memcpy throughput also benchmarked the increased context switch time that will happen now that the kernels lazy-fpu state saving is effectively disabled every time something calls memcpy. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disable drm_kms_helper polling in kernel 2.6.35
On Thu, Nov 04, 2010 at 05:23:09PM +0300, macachuto wrote: Dear All. I would like to ask, when it will be possible to have kernel 2.6.35 with /sys/module/drm_kms_helper/parameters/poll to disable hotplug polling. I have laptop with i915GM video and experience mouse cursor freezes every 10 second. This is all about: issue with hotplug polling on those systems, https://bugs.freedesktop.org/show_bug.cgi?id=29536. Kernel 2.6.36 already has drm_kms_helper module parameter, but 2.6.35 still doesn't. f14 should be getting a .36 update fairly soon. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 04:51:01PM -0400, Owen Taylor wrote: [ But yes, 4% is a big hit. 1% I would accept without hesitation. 4% does make me hesitate a little bit. During devel cycles, we accept much more slowdown than that for the debug kernel, of course. If we can figure out profiling without frame pointers, that would be even better ] I've had a bunch of people talking to me about the impact of the kernel debugging causing grief for people wanting to do performance work. Our options as I see it are - Don't do debug by default, and ship kernel-debug in rawhide like we do in releases. Downside: We lose coverage testing because not everyone will run it. - We do the inverse of what we do in releases, and add a kernel-nodebug package I looked into this, and it really uglied up the spec file. - We do debug off builds on Mondays, and the rest of the weeks builds are debug-on like they are now. This way those doing perf work can just stay on the kernel from the beginning of the week. If we go ahead and do something about that problem, what about just using -fno-omit-frame-pointer during rawhide builds, and then switching it off at branch time ? As for the DWARF unwinder in the kernel.. I wouldn't rule out it ever making a reappearance, but it really needs a lot more testing before it gets merged. The reason it got ripped out was that it made backtraces unreliable, which was the whole reason for even having it, so.. Rather than improve it, and then re-merge it later, the authors seem to have got discouraged to the point where it just got dropped on the floor. (that said, it may still be alive in SLES for all I know). Additionally, back then, x86 maintainence in the kernel was a bit.. random. It's a lot more focussed these days, so I'm pretty sure Ingo co could be persuaded to get something merged as long as it was actually stable enough to be a viable replacement for the existing kernel backtrace infrastructure. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
policycoreutils needs cairo.
I did a minimal install yesterday, and was surprised to find that cairo, and a bunch of X libs were still installed. The dependancy chain that pulled them in looks like this.. policycoreutils - dbus-glib - gobject-introspection - fontconfig - cairo Could any part of that chain have its dependancies relaxed ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Beta Declared GOLD
On Wed, Sep 22, 2010 at 03:31:39PM -0700, John Poelstra wrote: At the Fedora 14 Beta Go/No-Go meeting today, the Fedora 14 Beta was declared GOLD and ready for release on September 28, 2010. is what's at rsync://mirrors.kernel.org/mirrors/fedora/development/14/ right now the beta tree, or is that post-beta ? I've been on vacation the last couple days, so out of the loop.. I did an install from the tree above this afternoon and hit this.. https://bugzilla.redhat.com/show_bug.cgi?id=636658 which would be kinda embarressing if that problem made it into beta, and the fix is sitting in updates-testing. (I had to boot with enforcing=0 to update and get it working) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 02:45:03PM -0500, Michael Cronenworth wrote: I can see a big increase in boot time with my desktop setup when using a debugging kernel among other slow-downs. From 8 seconds (non-debug) at least double that. I use modern CPUs (quad core a minimum) with SSDs and fast GPUs. Speed is very important to me. booting with slab_debug=- should mitigate one of the more expensive options. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with 2.6.35.4-12.fc14.x86_64
On Wed, Sep 15, 2010 at 08:11:47PM +0200, Michał Piotrowski wrote: One problem fixed, introduced another === [ INFO: suspicious rcu_dereference_check() usage. ] --- include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection! At least on my Atom 330 with 2.6.35.4-25.fc13.x86_64. Just committed a fix for this. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with 2.6.35.4-12.fc14.x86_64
On Wed, Sep 15, 2010 at 11:11:52PM +0200, Morten P.D. Stevens wrote: -Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt Sent: Wednesday, September 15, 2010 8:03 PM To: devel@lists.fedoraproject.org Subject: Re: Problem with 2.6.35.4-12.fc14.x86_64 On Wed, 15 Sep 2010 17:44:47 +0200 Morten P.D. Stevens wrote: Does anyone know something about this issue? [...] === [ INFO: suspicious rcu_dereference_check() usage. ] --- kernel/sched.c:616 invoked rcu_dereference_check() without protection! Try kernel = 2.6.35.4-21 from Koji. It has this change The same problem with the newest 2.6.35.4-28.fc14.x86_64 kernel. === [ INFO: suspicious rcu_dereference_check() usage. ] --- include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection! This is the 2nd variant that I just fixed. No builds yet. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: article on security of various linux
On Thu, Sep 09, 2010 at 10:30:57AM -0400, Gregory Maxwell wrote: On Thu, Sep 9, 2010 at 9:45 AM, Neal Becker ndbeck...@gmail.com wrote: This article: http://labs.mwrinfosecurity.com/notices/security_mechanisms_in_linux_environment__part_1___userspace_memory_protection/ seems to say that fedora is ranking poorly in deployment of various userspace memory protection mechanisms. Is this information accurate? I asked about one point of this on LWN: Library randomization / prelink Posted Sep 8, 2010 18:26 UTC (Wed) by gmaxwell (subscriber, #30048) [Link] Anyone know how the library randomization is being counted? 3 bits for fedora doesn't sound right. Is the 3 bits the value for a system vs itself or for this system vs all other systems? a note here: fedora uses exec-shield which maps libraries in two different regions: ascii-armor (lower 16MB) and the rest. i think what paxtest measured there is the former where the usable entropy is necessarily less than elsewhere and may not be representative of real life apps and their address spaces (not saying the whole ascii-armor region is worth anything for security though ;) This article was brought up on fedora-kernel-list last week. In my tests, I've not been able to reproduce the '3 bits' result. On current kernels, I see 12 bits for 32-bit, and 'no randomisation' for 64-bit. I'm not entirely sure yet why we're showing different results on some of the other tests to other distros too. I'll poke at it some more tomorrow. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
newer NVRs in older releases.
I just hit this on an f13 box. Transaction Check Error: package libgcc-4.4.4-11.fc12.x86_64 (which is newer than libgcc-4.4.4-10.fc13.i686) is already installed Could the buildsystem be changed to prevent newer NVRs from being built if an older one exists in a newer buildroot ? Should it ? Is there a valid reason for ever allowing this to happen? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote: On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote: # systemctl enable ge...@.service prefdm.service getty.target rc-local.service remote-fs.target And that should make things work again. even after doing this, I still haven't managed to get a single box running systemd. They all hang after complaining that it failed to load configuration for default.target (and a bunch of other services like distcache, livesys-late, cman) Have you seen the two follow-up messages I posted to this one? You need to create the default.target link as well. See those two mails for details. ah, missed that in the noise. thanks. It tells me to see the logs for details, but there's not a single message from systemd in the logs. There should be an explanation in dmesg, that it cannot find default.target. at the stage that it stopped, I guess syslog wasn't running, so it never made it into the boot logs. as an aside: it also prints out some bogus messages about autofs and ipv6 being missing. if you could remove those, that would likely save some pointless bug reports. Well, systemd by default uses autofs for certain API vfs mounts, such as binfmt_misc: we create the mount point and only when it is accessed we actually mount the file system on it. This has the effect that we'll load the binfmt kernel module only when somebody actaully writes something to the fs. i.e. we make the mount points availabale all the time in the file system, but the backing module is not necessarily loaded. Something similar applies to a couple of other non-essential virtual API file systems. When systemd initializes we will initialize autofs too (by opening /dev/autofs), and that will fail if the module is not loaded (and the usual module-autoloading won't work for the autofs device node since udev isn't around yet, and the device node is hence not created yet). this seems like a rube goldberg machine to me, but ok. systemd also configures the lo network device by default as part of early bootup, as part of its normal startup code (in C). here too module autoloading doesn't work, since configuring an ipv6 address on lo will not cause the protocol module to be loaded. So, in summary, we have to modprobe autofs and ipv6 manually before we go on with the startup, and given that this is how it is I don't think it makes much sense compiling them as a module anymore. It's similarly pointless as compiling unix.ko as a module, or the RTC module. It just slows down the boot and will be loaded into the kernel anyway. And that's why we complain. (note that systemd will still boot if autofs and ipv6 aren't available at all, it's not essential and we actually do honour the modprobe blacklist) we had to revert the ipv6=y change for rhel6 because someone showed that it's actually costly in high performance networking cases where ipv6 isn't even used. rhel7 may be a long ways away, but eventually, systemd will have to be made to handle that case, so it may as well get it right from the start. There will always be use cases for disabling ipv6, so building it in seems ill advised. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote: It tells me to see the logs for details, but there's not a single message from systemd in the logs. There should be an explanation in dmesg, that it cannot find default.target. at the stage that it stopped, I guess syslog wasn't running, so it never made it into the boot logs. Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so nothing should get lost -- as long as you manage to get a shell somehow. BTW, as a side note: a simply fix to bypass the problem with a missing default.target is to pass 5 on the kernel command line. This will then boot into gdm regardless whether default.target exists or not. the git version of systemd will automatically enter signle user mode if default.target is missing or borked. So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
On Fri, Aug 13, 2010 at 05:47:37PM +0200, Kevin Kofler wrote: Good luck getting Mozilla to accept anything. Just like the kernel, they're a very hard to work with upstream. If you don't know the right people, your stuff just doesn't get in. :-( Which is odd, because the number of changesets per release seems to be increasing. As does the number of new committers. It's almost like you're talking complete rubbish. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modification of sources file causes git corruption.
On Sat, Jul 31, 2010 at 10:58:26PM -0700, Matt McCutchen wrote: That's not corruption, that's just an unreferenced object, which does no harm except to waste space. git gc will delete such objects. (20:50:18:da...@gelk:kernel)$ git fsck --full dangling blob 41bc432a23a83d5775562572936792fc25aa9380 (20:50:29:da...@gelk:kernel)$ git gc Counting objects: 395, done. Delta compression using up to 2 threads. Compressing objects: 100% (274/274), done. Writing objects: 100% (395/395), done. Total 395 (delta 119), reused 388 (delta 115) (20:50:31:da...@gelk:kernel)$ git fsck --full dangling blob 41bc432a23a83d5775562572936792fc25aa9380 I've just been deleting them by hand from .git/objects/ but at the frequency the kernel rebases, this is a pain. They may be harmless, but if something was to go wrong, they'd make figuring out what happened more complicated. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
modification of sources file causes git corruption.
Check this out.. (00:13:25:da...@gelk:kernel)$ fedpkg -v upload patch-2.6.35-rc6-git6.bz2 Creating module object from /mnt/data/src/fedora/kernel Uploading: f73d01927a3150e729b44add5ea4923c patch-2.6.35-rc6-git6.bz2 Running curl -k --cert /home/davej/.fedora.cert --fail -o /dev/null --show-error --progress-bar -F name=kernel -F md5sum=f73d01927a3150e729b44add5ea4923c -F fi...@patch-2.6.35-rc6-git6.bz2 https://pkgs.fedoraproject.org/repo/pkgs/upload.cgi directly on the tty 100.0% Source upload succeeded. Don't forget to commit the sources file (00:13:35:da...@gelk:kernel)$ git fsck --full (00:13:59:da...@gelk:kernel)$ cat sources 10eebcb0178fb4540e2165bfd7efc7ad linux-2.6.34.tar.bz2 1205481c8d1b5ccecad87840ddaeaf81 patch-2.6.35-rc6.bz2 6488f89f618d7e03af865534b31d3419 patch-2.6.35-rc6-git5.bz2 f73d01927a3150e729b44add5ea4923c patch-2.6.35-rc6-git6.bz2 (00:14:02:da...@gelk:kernel)$ vim sources (00:14:05:da...@gelk:kernel)$ cat sources 10eebcb0178fb4540e2165bfd7efc7ad linux-2.6.34.tar.bz2 1205481c8d1b5ccecad87840ddaeaf81 patch-2.6.35-rc6.bz2 f73d01927a3150e729b44add5ea4923c patch-2.6.35-rc6-git6.bz2 (00:14:06:da...@gelk:kernel)$ git fsck --full (00:14:43:da...@gelk:kernel)$ git commit -a [master 89d0d88] 2.6.35-rc6-git6 3 files changed, 6 insertions(+), 2 deletions(-) (00:16:40:da...@gelk:kernel)$ git fsck --full dangling blob 64802926167a6aef0d71a5e6de35f0857674947b git show on that blob shows the variant of 'sources' before I removed the git5 entry. It seems if there's a pending staged commit to a file, and then you modify it, git loses its shit. Why can't fedpkg upload just leave the file modified instead of staging the commit ? This would also have the advantage of showing up in git diff without the need for --cached before doing the actual commit. If we're modifying sources for an upload, chances are we're going to want to remove a stale entry anyway, and having to do this as two commits seems a bit dumb. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Mon, Jul 26, 2010 at 02:39:55PM -0400, Bill Nottingham wrote: Dave Jones (da...@redhat.com) said: of those that it does open(),.. Is there seriously a use-case for someone wanting lvm partitioned /dev/ram disks ? or /dev/loop ? I would assume that's for testing. point being that for those who care about doing that, they probably know how to add a line to /etc/lvm.conf we don't need to support this and other madness out of the box at the detriment of the common case user. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Tue, Jul 20, 2010 at 04:26:14PM +0200, Lennart Poettering wrote: On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc It's been this way for years. I first noticed it when it triggered a bug in agpgart a long time ago. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Wed, Jul 21, 2010 at 02:30:03PM -0400, Dave Jones wrote: On Tue, Jul 20, 2010 at 04:26:14PM +0200, Lennart Poettering wrote: On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc looking closer, it seems to be only stat'ing, instead of opening most of them, which isn't quite so bad, but still pretty lame. of those that it does open(),.. Is there seriously a use-case for someone wanting lvm partitioned /dev/ram disks ? or /dev/loop ? I think we could probably use some extra filter definitions in /etc/lvm/lvm.conf Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outage: Updates - 2010-07-21 16:00 UTC
On Tue, Jul 20, 2010 at 04:47:38PM -0600, Stephen John Smoogen wrote: There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 3 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-21 16:00 UTC' Reason for outage: Updates to xen and other critical packages require rebooting servers to take effect. Affected Services: CVS / Source Control I noticed cvs has come back up, but the webserver on cvs.fedoraproject.org hasn't, which means make upload is failing. Is it still in the outage window, or did something not come back up correctly? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed release criteria additions for F14+
On Thu, Jun 24, 2010 at 11:28:16AM -0700, Adam Williamson wrote: * The desktop default update manager must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system tangentally related: Do we ever respin the live image if there are security updates ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NVR email I just sent
On Thu, May 27, 2010 at 11:28:08AM -0700, John Reiser wrote: greater for f12: x86info (davej ) f12 = 1:x86info-1.25-1.45.fc12.src f13 = 1:x86info-1.25-1.44.fc13.src These are actually the same, (I did two commits in f12, and combined both when I updated f13). is it worth rebuilding just to get it off the list ? Yes. It seems kinda pointless to push an update when nothing changes at all. The _name_ changes, and that is important because the name has semantic meaning. ok, rebuilt, and update pushed out. thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tor dependency insanity.
So after having heard the nth discussion about tor, I decided to check it out. I tried installing it on a stripped down f12 box that has no X, or other stuff unnecessary for routing network packets. What happened next has me lost for words. Our dependency chains suck. Dave (12:24:07:r...@firewall:~)# yum install tor Setting up Install Process Resolving Dependencies -- Running transaction check --- Package tor.i686 0:0.2.1.23-1200.fc12 set to be updated -- Processing Dependency: tor-core = 0.2.1.23-1200.fc12 for package: tor-0.2.1.23-1200.fc12.i686 -- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package: tor-0.2.1.23-1200.fc12.i686 -- Running transaction check --- Package tor-core.i686 0:0.2.1.23-1200.fc12 set to be updated -- Processing Dependency: fedora-usermgmt for package: tor-core-0.2.1.23-1200.fc12.i686 -- Processing Dependency: fedora-usermgmt for package: tor-core-0.2.1.23-1200.fc12.i686 --- Package tor-lsb.noarch 0:0.2.1.23-1200.fc12 set to be updated -- Processing Dependency: lsb-core-noarch for package: tor-lsb-0.2.1.23-1200.fc12.noarch -- Processing Dependency: lsb-core-noarch for package: tor-lsb-0.2.1.23-1200.fc12.noarch -- Running transaction check --- Package fedora-usermgmt.noarch 0:0.10-1200.fc12 set to be updated -- Processing Dependency: fedora-usermgmt-core = 0.10-1200.fc12 for package: fedora-usermgmt-0.10-1200.fc12.noarch -- Processing Dependency: instance(fedora-usermgmt) for package: fedora-usermgmt-0.10-1200.fc12.noarch -- Processing Dependency: setup(fedora-usermgmt) for package: fedora-usermgmt-0.10-1200.fc12.noarch --- Package redhat-lsb.i686 0:3.2-7.fc12 set to be updated -- Processing Dependency: /usr/bin/at for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/lp for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtCore.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libgtk-x11-2.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libpangoft2-1.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libICE.so.6 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtSql.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libcups.so.2 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libgdk_pixbuf-2.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/batch for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libasound.so.2 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libpangoxft-1.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libgdk-x11-2.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/pax for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtOpenGL.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtSvg.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtNetwork.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/lpr for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/man for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/foomatic-rip for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libXi.so.6 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libqt-mt.so.3 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libatk-1.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtXml.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libQtGui.so.4 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libSM.so.6 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libcupsimage.so.2 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libGL.so.1 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libXt.so.6 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/msgfmt for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /bin/gettext for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: /usr/bin/gs for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libgdk_pixbuf_xlib-2.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Processing Dependency: libpango-1.0.so.0 for package: redhat-lsb-3.2-7.fc12.i686 -- Running transaction check --- Package alsa-lib.i686 0:1.0.22-2.fc12 set to be updated --- Package at.i686 0:3.1.10-40.fc12 set to be updated --- Package atk.i686 0:1.28.0-1.fc12 set to be updated --- Package cups.i686 1:1.4.2-20.fc12 set to be updated -- Processing Dependency: libavahi-common.so.3 for package: 1:cups-1.4.2-20.fc12.i686 -- Processing Dependency: portreserve for package: 1:cups-1.4.2-20.fc12.i686 -- Processing Dependency: libavahi-client.so.3 for package: 1:cups-1.4.2-20.fc12.i686 -- Processing Dependency: poppler-utils
Re: tor dependency insanity.
On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote: On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote: -- Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package: tor-0.2.1.23-1200.fc12.i686 This is where things go to hell. Why in the hell is tor-lsb /required/ by tor? LSB isn't really good for anything except landing a bunch of crap on your system that you don't really want there. Making it required is rather... lame. Why do we even bother supporting bullshit standards like LSB ? We should make a stand and drop it from Fedora until it's not made up of bonghits and failure. (haha, yeah. thanks, here all week, etc) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
intent to orphan: oprofileui
I'm going to recommend dropping this package from Fedora entirely. - Upstream seems to have stopped development on it since intel acquired its developers (opened-hand) - The new profiling tools (perf) are in many cases easier to use than oprofile - oprofileui had a number of bugs that look like they'll not be fixed (profiling a 32bit target from a 64bit host it broken for eg) - the package never really got much interest. (I never heard a single report of someone using it) if someone wants to take it over from me, I won't stand in their way, but I think it's better to just drop it. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
