| 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:04 |
| 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:05 |
| Noskcaj | RoyK, i would assume getting everything sorted upstream would help, as would getting the bug triaged | 10:09 |
| RoyK | xnox: only asked twice - yesterday and today... thought perhaps more people were in here | 10:10 |
| RoyK | I don't think it's an mdadm bug, though, more of an ubuntu startup bug | 10:11 |
| 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:13 |
| RoyK | are you sure this is done in the initramfs? | 10:14 |
| xnox | RoyK: if nested raid is rootfs device, yes. | 10:14 |
| 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:15 |
| RoyK | where is it handled outside the initramfs? | 10:16 |
| xnox | udev rules, shipped by mdadm package. | 10:19 |
| RoyK | here /lib/udev/rules.d/64-md-raid.rules ? | 10:19 |
| xnox | correct. | 10:25 |
| RoyK | doing more testing first... | 10:28 |
| RoyK | hm... I don't really know my way around udev :( | 10:57 |
| RoyK | could it be possible mdadm's udev rules aren't triggered/parsed for md devices as needed with nested md? | 10:58 |
| 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:36 |
| 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:37 |
| RoyK | xnox: but where are the arrays assembled in precise? | 12:38 |
| xnox | same as in quantal/raring/saucy. | 12:40 |
| RoyK | haven't tested saucy, but same in raring | 12:43 |
| RoyK | works in lucid | 12:44 |
| === 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 | ||
| 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:26 |
| 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:27 | |
| 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:28 | |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| TheLordOfTime | RoyK: you might be interested in the bugsquad docs on how to triage: https://wiki.ubuntu.com/Bugs/HowToTriage | 17:34 |
| TheLordOfTime | only when there's a certain handful of criterion that're met does it go from confirmed -> triaged | 17:35 |
| 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:37 |
| 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:38 |
| TheLordOfTime | ... whoopsies i'm late for a meeting... >.< | 17:39 |
| RoyK | ok | 17:39 |
| RoyK | thanks for the input | 17:39 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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/ | 17:49 |
| lfaraone | hggdh: I can sub bugcontrol to it. | 18:05 |
| lfaraone | done | 18:05 |
| 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:09 |
| 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:11 |
| TheLordOfTime | besides, crash bugs are normally set to 'private' automatically | 18:12 |
| TheLordOfTime | at least, last i checked how those get reported. | 18:12 |
| RoyK | which bug_ | 18:13 |
| RoyK | ? | 18:13 |
| TheLordOfTime | RoyK: private bug, the one lfaraone referenced | 18:15 |
| TheLordOfTime | lfaraone: read above. | 18:15 |
| 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" | 18:18 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!