[10:04] hi all. is there any more info I can give for bug 1171945 to be fixed any quicker? [10:04] Launchpad bug 1171945 in mdadm (Ubuntu) "Nested RAID levels aren't started after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1171945 [10:05] RoyK: no, not really. You can try fixing it though =) highlighting me on mdadm / pinging about the same bug every day does not help much. [10:09] RoyK, i would assume getting everything sorted upstream would help, as would getting the bug triaged [10:10] xnox: only asked twice - yesterday and today... thought perhaps more people were in here [10:11] I don't think it's an mdadm bug, though, more of an ubuntu startup bug [10:13] RoyK: sure, the bug is in initramfs, but the scripts that are executed in the initramfs to mount raid devices are provided by the mdadm package. [10:14] are you sure this is done in the initramfs? [10:14] RoyK: if nested raid is rootfs device, yes. [10:15] it isn't [10:15] if it's not rootfs device, it may or may not be handled in initramfs, depending on how quick the raid comes up. [10:16] where is it handled outside the initramfs? [10:19] udev rules, shipped by mdadm package. [10:19] here /lib/udev/rules.d/64-md-raid.rules ? [10:25] correct. [10:28] doing more testing first... [10:57] hm... I don't really know my way around udev :( [10:58] could it be possible mdadm's udev rules aren't triggered/parsed for md devices as needed with nested md? [12:36] xnox: seems it can't be only that file - tested with Wheezy now, with almost exactly the same rules file - see update in the bug [12:37] RoyK: wheezy does not activate mdadm arrays using udev, but rather using an init script and mdadm.conf. So ubuntu & wheezy are not directly comparable. [12:37] but they share the same mdadm rules file_ [12:37] ? [12:37] but I see what you mean [12:38] xnox: but where are the arrays assembled in precise? [12:40] same as in quantal/raring/saucy. [12:43] haven't tested saucy, but same in raring [12:44] works in lucid === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === greyback is now known as greyback|food === psivaa is now known as psivaa_afk === greyback|food is now known as greyback [17:26] Is there a way to have upstream mark a variable in their C program as "sensitive" so it won't get published on retracing? [17:26] you'd have to ask the upstream devs that one. [17:27] TheLordOfTime: sorry, I'm asking on behalf of an upstream developer who found a user's session key in a launchpad bug. [17:27] which bug [17:27] so the question is "what changes should we make in the future" [17:27] or you could answer my question [17:27] "which bug" [17:27] * TheLordOfTime is on bugcontrol ;P [17:28] if its a bug in ubuntu and it's got private data as public that's a problem [17:28] TheLordOfTime: me too, I just didn't see your message asking for the bug number when mine was sent... [17:28] TheLordOfTime: 1185863 [17:28] * TheLordOfTime shrugs [17:29] LP #1185863 [17:29] yeah i can't see the bug [17:29] lfaraone: is the bug itself marked "private"? [17:29] if it is then the data's going to be that much harder for anyone to find [17:29] (this is why the "private" bug type exists) [17:29] TheLordOfTime: I just remarked it as Private, the user initially marked it as public. [17:30] lfaraone: then explain to the individual about the difference between private / public [17:30] lfaraone: but to change your question a tad [17:30] bug 1185863 [17:30] you're asking whether you can selectively block a retracer from detecting data such as a session key [17:30] or block apport from sending that data in the first place? [17:30] TheLordOfTime: Either, sure. [17:31] what does it take to get a bug triaged? [17:31] okay, i don't have an answer for you, lfaraone [17:31] RoyK: depends on the bug [17:31] what bug? [17:31] TheLordOfTime: like, I can mlock() memory to prevent it from being paged to disk... [17:32] lfaraone: if you're working with upstream then upstream should handle it, i'm not sure why you're asking here what upstream can do to block it [17:32] since i can think of a thousand ways to block data from being stuck in memory data that's being dumped/traced [17:33] TheLordOfTime: I'm asking if there's a documented, preferred way for an upstream to sanitise variables before they're sent to apport. [17:33] bug 1171945 [17:33] Launchpad bug 1171945 in mdadm (Ubuntu) "Nested RAID levels aren't started after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1171945 [17:33] afaik, no, but you can stick around for other bugcontrollers to comment, or apport devs. [17:34] RoyK: you might be interested in the bugsquad docs on how to triage: https://wiki.ubuntu.com/Bugs/HowToTriage [17:35] only when there's a certain handful of criterion that're met does it go from confirmed -> triaged [17:37] RoyK: i'm pretty certain there's at least a handful of other people qualified to work on the bug watching it, but since I'm on my phone I can't do anything from here :/ [17:38] TheLordOfTime: well, I've documented all I've found [17:38] RoyK: my point was I don't have my bugcontrol access on my phone [17:38] (timeout from login screen) [17:38] so while i may or may not believe it's ready for triaging, i don't have access for changing either way [17:38] :) [17:39] ... whoopsies i'm late for a meeting... >.< [17:39] ok [17:39] thanks for the input [17:45] lfaraone, TheLordOfTime: pelase note that all persons already subscribed to the bug will keep their subscriptions even if the bug is marked private now [17:45] hggdh: understood. [17:46] I'm curious why TheLordOfTime said they weren't able to access the bug, shouldn't bugcontrol be able to see it?hggdh [17:46] lfaraone: depends... [17:46] lfaraone: probably part of it is because i got logged out of my lp login [17:46] bug 1185863 [17:46] but hggdh is right, it depends [17:46] bah, the bot is inactive [17:46] lfaraone: let me open it directly [17:48] eheh [17:48] hggdh: i tried opening it just now after login, it said "not found" [17:48] as if it's hidden [17:48] :P [17:48] TheLordOfTime: so we do not have subscription to it [17:48] (mine also failed) [17:48] yep [17:49] bugcontrol doesn't always have access to everything [17:49] although sometimes we do [17:49] * hggdh goes to a meeting [17:49] ... that reminds me, there's two SEGV bugs I need to slap into nothingness because they only affected oneiric [17:49] s/SEGV/SEGV private crash bugs/ [18:05] hggdh: I can sub bugcontrol to it. [18:05] done [18:09] ack on the subscription just hit my email [18:09] but why's it marked "Fix Released"...? [18:09] or is this just an exemplar bug of the issue you're asking about, relating to hiding data from apport. [18:11] ... actually the whole private vs. public issue here looks like a PEBKAC issue. [18:11] looks like the user didn't realize there was private data on their bug. [18:12] besides, crash bugs are normally set to 'private' automatically [18:12] at least, last i checked how those get reported. [18:13] which bug_ [18:13] ? [18:15] RoyK: private bug, the one lfaraone referenced [18:15] lfaraone: read above. [18:18] when is a bug private_ [18:18] ? [18:18] RoyK: when it's a crash bug [18:18] or when it's set as "private" === greyback is now known as greyback|away === greyback|away is now known as greyback === pedro_ is now known as Guest77619 === greyback is now known as greyback|away === hggdh_ is now known as hggdh === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha