[01:14] Snow-Man: Howdy. [01:14] I don't suppose anyone else is seeing crashes with ipv6-enabled systems under the latest 14.04 kernel? [01:14] Linux tamriel 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [01:14] JackFrost: uhm, hi. [01:15] I've just installed crashdump to see if I can catch it happening again. [01:15] if so, I'll probably boot into the prior kernel I was running (3.13.0-40.69). [01:16] I'm not 100% sure that it's ipv6-related, but the piece of the stack trace still visible clearly showed ipv6 in the output. [01:17] perhaps also interesting is that this is happening to a KVM box and the physical box (which also has ipv6 enabled) isn't having any issues. [01:17] (the physical box the KVM is sitting on, that is) [01:18] that box is running 3.13.0-43-generic #72-Ubuntu [01:21] Doesn't seem to be network load related tho, as I can do a bump of ipv6 stuff (download debs, etc). [01:21] anyway, was just curious if anyone else saw anything similar. After the next crash I'll hopefully have enough information to file a useful bug report. [03:34] this may be a stupid suggestion, but I think that 'rm' should be required to have root privileges, and that a new program called 'dl' should be added which asks for confirmation on each record before deletion, and rather than removing the nodes from the filesystem it marks them and moves them to a trash directory of limited size [03:34] lose something? [03:35] nah, just reading a book called 'The Unix Haters Handbook' [03:35] Some of these people have had horrendous mistakes with rm [03:35] You know, if these silly filesystems worked like databases do and required you to do a 'commit;'... [03:36] (says the PostgreSQL committer) [03:36] 1. That'd be so terribly annoying, when I want to rm something, I want it removed (yes, I've made mistakes. I don't want it changed.) 2. Simple fix: alias rm='rm -i' [03:38] I *hate* that alias. [03:38] and, I really *love* rollback;. ;D [03:38] It'd be no different than the 'del' command for DOS. you could call it with -, or type 'A' when it asks for the first confirmation to skip all others [03:39] and you'd be able to restore files, rather than scraping your disk with fsck if you mess up [03:39] eh, this is all uninteresting. [03:39] If you really want that, go write a filesystem to do it for you. [03:39] Shouldn't be too hard to do and you don't have to monkey around w/ rm. [03:40] It's probably not realistic to attempt to do this anyway, with all the tools that rely on rm. I just think it's a little to dangerous to be called directly. Like dd [03:42] Are any DMB members lurking? It looks like the shimmer-themes source package fell out of the xubuntu packageset upload rights [03:44] Snow-Man: Yeeah, I got used to using -rf because of that alias. [03:44] JackFrost: indeed, that's one of the big problems w/ it. [03:45] pfft, dd isn't dangerous [03:45] doing things as *root* is dangerous [03:45] dd if=/dev/hd0 of=/dev/hd0 skip=1 [03:47] that's like divide by zero button for unix [04:08] still gotta be root to do it tho. [05:38] bluesabre: Please send mail to the devel-permissions ML. [07:07] good morning [07:09] hi all [07:10] dholbach: I'm about to submit a SRU (later today) for landscape-client. What is the now favorite way to do this? Sending branches with the bug? Should I push some binary packages to -proposed for each version I'm targetting? [07:10] hi Tribaal [07:10] dholbach: our docs indicate attaching debdiffs - but that feels... barbaric :) [07:11] Tribaal, branch is fine, source package is fine, patch is fine, but binary packages are not [07:11] dholbach: roger. So attaching branches to the bug + subscribing the SRU team (to the bug) is all I need? [07:12] subscribe 'ubuntu-sponsors' for somebody to upload the patches as well [07:13] dholbach: oh ok. So the sponsors/SRU guys do their own "debuild" dance then? (just curiosity, I'm re-documenting the process on our end) [07:13] yes, they do [07:13] dholbach: awesome, thanks a lot [07:13] if I'd upload it, I'd do a local test build, check the diff, and whatever feels necessary to see if things make sense :) [07:13] anytime [07:16] dholbach: yeah, we have a pretty long procedure with many tests in place, I just installed the new package to a combination of 4 distros, 3 landscape server versions, and "fresh install" versus "upgrades". So I'm becomming an expert at local builds :p [07:17] :) [11:17] Riddell: is kubuntu-plasma5 still valid? [11:17] IIRC that's folded into main kubuntu now [11:18] Laney: right yes [11:18] Laney: in which context? [11:18] DMB: we were considering it when generating the kubuntu packageset [11:18] * Laney drops [11:48] thanks Laney! [11:48] bbl [11:50] ari-tczew: re d-feet: please talk to seb128, the revert was on his request [11:50] mitya57: ok, thanks for reply [11:50] (I am personally fine with syncing it) === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [14:09] mitya57: hmm, true, I was hoping that it would return different exit codes for different things [14:59] dholbach: so I just subscribed the SRU team to the latest landscape-client bug, as promised :) Don't hesitate to let me know here if I can do anything else to help [15:01] ubuntu-sponsors too? [15:01] or did you upload it already? [15:01] dholbach: oh right, subscribed. [15:01] cool :) [15:02] dholbach: I might apply for single-package upload rights at some point, so I can do this part [15:02] excellent :-)) [15:03] dholbach: I might annoy you for a testimonial once the wiki paperwork is done :) [15:03] sure, let me know :) [15:04] dholbach: thanks :) [15:07] mlankhorst: Is there a reason you're still arch-restricting your lts backport stacks? [15:08] mlankhorst: (Note: we're not doing so for the lts-u kernel) [15:08] oh no not at all [15:09] I just don't have a way to test it on arm [15:09] mlankhorst: That's true for the dev release too, it doesn't stop us from building packages on all arches. :P [15:09] hah [15:10] I'd have to do the re-upload tomorrow then [15:10] mlankhorst: (ppc* are actually more my concern than arm, but I don't see any point in artificially restricting any of it in the backport) [15:10] mlankhorst: Worst case scenario, some driver or something works worse in one stack than in another, but people get choice that way. *shrug* [15:10] there's just no way for me to test with 100% certainty.. [15:11] I might be able to test installability though [15:11] mlankhorst: We're only building point release desktop CDs on x86 (so far), so the 100% certainty testing really only needs to happen there. [15:11] mlankhorst: But giving people on other arches choice to flip stacks doesn't hurt, IMO. [15:13] true [15:13] i may be able to test installability on armhf at least [15:28] infinity: but what's the point when the only working 3d driver on other archs is llvmpipe [15:56] mlankhorst: nouveau works on some/most PPC machines. [15:56] mlankhorst: radeon is off again on again. [15:57] mlankhorst: In theory, most PCI drivers should work, in practice, it's hit and miss. [16:40] ok [16:41] why would you update thoose though :p === ev_ is now known as ev === czchen_ is now known as czchen === ken_ is now known as kenvandine === _salem is now known as salem_ === salem_ is now known as _salem