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