| antarus | cjwatson: I have a weird question. Canonical is sort of slowish at SRUing stuff for gPrecise, particular once it is aged...What do I have to do to be able to have folks on my team SRU changes ourselves? | 02:09 |
|---|---|---|
| cody-somerville | antarus: Canonical is not responsible for the Stable Release Update process - the community SRU team is. The wikipage at https://wiki.ubuntu.com/StableReleaseUpdates describes the process. The SRU team is tasked with determining if an update meets the SRU criteria but the rest of the process can be handled by any contributor (with support from a Ubuntu developer to handle the upload). | 02:25 |
| cody-somerville | Or are you talking about the internal Google version of Ubuntu? | 02:31 |
| infinity | antarus: What do you mean by "particular once it is aged"... When SRUs are aged *and tested*, we release them. | 02:33 |
| infinity | antarus: If things you care about aren't being tested/verified, the solution is fairly obvious. | 02:34 |
| antarus | cody-somerville: I guess my question is then 'how do I join the community SRU team' | 06:35 |
| antarus | cody-somerville: I want to avoid forking a bunch of stuff interally because it takes weeks to get an SRU | 06:35 |
| antarus | infinity: once a package is in proposed, we are pretty quick to test and get back to you on launchpad | 06:35 |
| antarus | We have discussed before about being more involved in the community, process / contribution wise | 06:37 |
| antarus | (discussed internally, that is) | 06:37 |
| antarus | Hrm although I guess in the bug I am thinking of | 06:44 |
| antarus | there is no SRU on launchpad yet | 06:44 |
| * antarus tsks | 06:44 | |
| * antarus should really just join Ubuntu | 06:45 | |
| antarus | infinity: I guess the end result I am looking for is that we don't actually mind doing an internal fork, as long as we are sure that our fork is the same fork Ubuntu is doing. | 07:05 |
| antarus | infinity: so if the answer is 'do an internal fork and post it to the bug so it is SRU'd into Ubuntu' | 07:06 |
| antarus | then I'd be happy to do more of the SRU'd work | 07:06 |
| antarus | but if Ubuntu doesn't approve the SRU, I'm stuck maintaining the package myself, which has ended badly in the past | 07:06 |
| antarus | right now we basically never do forks, and wait for Ubuntu to SRU everything. But particularly as precise gets older and older, the SRUs seem to be..more difficult? | 07:07 |
| infinity | antarus: Well, there's no such guarantee, really. If a sponsor thinks the SRU is worth uploading, if the SRU team thinks the bug fits the SRU criteria, then it'll get into proposed. Then if it verifies okay, it'll get to updates. | 07:37 |
| infinity | antarus: This process doesn't change regardless of whether you're submitting patches to bugs or doing the uploads yourself. | 07:37 |
| infinity | antarus: But, absolutely, submit patches to bugs. A lot of bugs in stable releases go unhandled just due to nobody having the time to fix them. If you have the fix, don't hold out. :) | 07:38 |
| antarus | infinity: thanks for the feedback | 08:13 |
| ev | Jasper, xnox: can you explain why it would need to live on GNOME git? | 09:42 |
| xnox | ev: in the past, not being in gnome git hindered zeitgeist framework adoption. | 09:43 |
| ev | xnox: hindered how? | 09:53 |
| xnox | ev: it did not get accepted into the gnome packagesets (the jhbuild xml sets) thus standard gnome app maintainers were not accepting zeitgeist patches, or if they did couldn't enable them by default due to packageset dependency constraints. | 09:59 |
| ev | that's silly. | 10:00 |
| xnox | =)))) yes, it seemed so to me as well. | 10:00 |
| xnox | ev: i'm not sure why Jasper wants it in GNOME git. But it looks like there are mockups/things that gnome-design wants to do with it. https://raw.github.com/gnome-design-team/gnome-mockups/master/system-settings/date-and-time/date-and-time-hi-res.png | 10:01 |
| mpt | We're not using those time+date designs, because we already have better designs implemented, ;-) but if we can share the map code at least, all well and good. | 10:03 |
| cjwatson | antarus: I think the worst blockage in the SRU process right now is in queue review, which is fairly privileged and hard to help with - but there are definitely other places to help, as infinity said. Perhaps a Goobuntu engineer or three should be looking at becoming Ubuntu developers? | 10:03 |
| ev | I'm all for cooperation, but I think the whole, "this must live in our house for us to help with it" thing is sad. | 10:03 |
| ev | xnox: that said, we're just speculating. I'm keen to hear what Jasper has to say. | 10:08 |
| FourDollars | Where is the main development branch of ubiquity? Is it lp:ubiquity? | 11:52 |
| cjwatson | Yes | 11:54 |
| FourDollars | Thx | 11:55 |
| FourDollars | I find a problem that 'self.custom_title = self.db.get('ubiquity/custom_title_text')' can not be l10n. | 11:57 |
| FourDollars | Are we still able to change ubiquity for Ubuntu 12.04.2 now? | 12:00 |
| cjwatson | Unlikely | 12:03 |
| cjwatson | Running out of time | 12:04 |
| cjwatson | Do send fixes for the development release though; I expect we'll do more ubiquity backports for 12.04.3 | 12:04 |
| FourDollars | Should I open a bug for this? | 12:09 |
| cjwatson | Yes | 12:10 |
| cjwatson | Though I have no ideas on how to fix it sensibly without breaking compatibility | 12:10 |
| cjwatson | Internationalisation should generally be done by metaget description rather than get, but that's hard to preseed | 12:10 |
| cjwatson | Actually I'm not totally sure I understand the requirement; surely for a preseeded install you're typically preseeding the locale too, and for a customised installation image you can just change ubiquity directly | 12:11 |
| cjwatson | It kind of seems to me that if you need internationalisation in ubiquity/custom_title_text you're doing something wrong ... | 12:11 |
| FourDollars | I am working on a patch based on lp:ubiquity. Maybe you can give me some advice after I come out the patch. | 12:13 |
| cjwatson | Requirements before patch | 12:13 |
| FourDollars | OK. | 12:15 |
| FourDollars | I am going to open a bug first. | 12:16 |
| mpt | xnox, hi, are you doing RAID this cycle? | 12:16 |
| cjwatson | OK - please include the answer to the question I asked above | 12:16 |
| xnox | mpt: in the installer? it's "undecided" priority for now (below low) | 12:19 |
| mpt | weird | 12:19 |
| mpt | Hi lisettte :-) | 12:21 |
| lisettte | hi mpt | 12:21 |
| FourDollars | cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1100256 | 12:24 |
| ubot2` | Launchpad bug 1100256 in ubiquity (Ubuntu) "ubiquity/custom_title_text can not be l10n." [Undecided,New] | 12:24 |
| cjwatson | And you haven't answered my question, so Incomplete :) | 12:25 |
| FourDollars | Err.. >_< | 12:26 |
| xnox | FourDollars: i don't understand why, or more importantly how. Where are the translations going to come from? Since you want multiple translations, one should be modifying ubiquity.pot and doing the translations. Or do you want prefix/suffix/substitute string in the title? | 12:26 |
| xnox | e.g. "Installing $FOObuntu" | 12:26 |
| cjwatson | FourDollars: It's not useful to just say "This is a requirement" - explain why | 12:27 |
| FourDollars | xnox: For example, "HP installer". | 12:27 |
| cjwatson | Specifically, why it is necessary to be able to preseed more than one translation of your string | 12:27 |
| cjwatson | And why that can't be done using a customised ubiquity package, if that's what you're doing. custom_title_text is not intended to scale up to lots of translations | 12:28 |
| FourDollars | We will get prepare the translation for "HP installer". | 12:28 |
| cjwatson | Then you should have a customised build of ubiquity for the HP installer | 12:28 |
| cjwatson | And you should change the text for ubiquity/text/live_installer | 12:28 |
| cjwatson | (And fill in the appropriate translations in .po files) | 12:29 |
| cjwatson | ubiquity/custom_title_text is simply not what you need | 12:29 |
| cjwatson | change the text> that is, in debian/ubiquity.templates | 12:29 |
| FourDollars | http://paste.ubuntu.com/1537520/ | 12:31 |
| FourDollars | This is my idea. | 12:31 |
| cjwatson | That's technically possible, but now you have to get the translated debconf template into the debconf database somehow, which can't be done using preseeding alone in any case. I don't understand why you can't just build a modified ubiquity package with the text you want. | 12:32 |
| cjwatson | Particularly since your patch requires that the template be in the ubiquity/text/ namespace ... | 12:32 |
| xnox | FourDollars: you just re-implemented ubiquity/text/live_installer for a second time =) | 12:33 |
| FourDollars | xnox: OK. So maybe I can use ubiquity/text/live_installer to achieve my goal. :) | 12:34 |
| FourDollars | Thanks. Let me try if ubiquity/text/live_installer works to me. | 12:35 |
| FourDollars | ubiquity/text/live_installer doesn't work to me. | 12:38 |
| FourDollars | I am working on a fork of dell-recovery. | 12:38 |
| FourDollars | dell-recovery is an ubiquity plugin. | 12:38 |
| xnox | FourDollars: did you edit the *.pot and *.po files? (e.g. sed s/Installer/Vendor Recovery/) did you rebuild .debs? did you upgrade and run updated debs? | 12:40 |
| FourDollars | xnox: no | 12:41 |
| FourDollars | Let me try again. | 12:41 |
| FourDollars | Can I avoid to maintain a customized ubiquity? | 12:45 |
| FourDollars | Can I avoid maintaining a customized ubiquity? | 12:45 |
| cjwatson | You have to maintain a customised *something*; you can't do this entirely using preseeding. | 12:46 |
| cjwatson | Given that, I don't think it's necessary to incur the code cost in ubiquity of helping you avoid maintaining a customised ubiquity | 12:46 |
| xnox | FourDollars: a translation patch is easier than extra code in upstream ubiquity. | 12:47 |
| cjwatson | And I don't think it would be appropriate, since branding usually involves more than just changing the window title, sooner or latere | 12:47 |
| cjwatson | We are not going to start adding lots of customisation templates that allow you to override each one of our strings individually | 12:47 |
| cjwatson | It would get very silly quite quickly :) | 12:47 |
| FourDollars | But the plugin will only be run once before any other plugin, and then reboot when it finish. The following will be the general process of oem-config-gtk. | 12:50 |
| * FourDollars is trying ubiquity/text/live_installer and hope it to work. | 12:51 | |
| FourDollars | Is it posiible to change the dialog title in an ubiquity plugin? | 13:07 |
| cjwatson | FourDollars: It's slightly sketchy, but the PageGtk part of a plugin can access self.controller._wizard.live_installer which is the dialog object. | 13:14 |
| cjwatson | (I think I've got that right.) | 13:14 |
| FourDollars | cjwatson: Many thanks. :D | 13:14 |
| FourDollars | Can I provide an empty ubiquity/custom_title_text to disable the dialog title? | 13:16 |
| cjwatson | Not currently. | 13:21 |
| FourDollars | cjwatson: self.controller._wizard.live_installer does work. Thank you. | 13:21 |
| cjwatson | That could be done by being a bit more disciplined about how self.custom_title is handled in frontends: the default should be None, not False, and tests for it should be 'if self.custom_title is not None:' rather than 'if self.custom_title:'. | 13:22 |
| FourDollars | cjwatson: Yes, that is great. | 13:24 |
| Jasper | ev, xnox: it's easier for us to manage | 16:13 |
| Jasper | ev, xnox: if we ship a GNOME module, it's nice to have bugs on GNOME, tarballs on GNOME, translations on GNOME, etc. | 16:14 |
| ev | Jasper: so is bzr for us, though. | 16:14 |
| cjwatson | You're going to hit a part of the stack you don't manage at *some* point | 16:15 |
| Jasper | The plan was to have it be a git submodule. | 16:15 |
| Jasper | mpt, mind if I see your designs? | 16:16 |
| mpt | Jasper, https://wiki.ubuntu.com/TimeAndDate | 16:16 |
| Jasper | I don't see much of a distinction. | 16:18 |
| Jasper | ev, git submodules allow us to make a static library where consumers don't have to update to new APIs immediately -- they can be on an old commit or branch if they want., | 16:19 |
| Jasper | It's convenient in that way. | 16:19 |
| mpt | Jasper, for example, "In the clock, show: (*) 12-hour time ( ) 24-hour time" is clearer than "24 Hour Format OFF/ON" | 16:20 |
| Jasper | OK, I'll relay it on to our design team. | 16:20 |
| Jasper | mpt, is this implemented in your g-c-c fork? | 16:21 |
| Jasper | It's not substantially different enough that it might make sense to pull it upstream. | 16:21 |
| mpt | Jasper, most of the differences are in two categories. That's the first one, where Gnome uses switches at the expense of clarity. The second is extra modality, for example having to go into a separate dialog to actually change the date and time, and a separate dialog to change the time zone. | 16:22 |
| mpt | Jasper, as far as I know, our settings panel is in <https://code.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.04>. larsu or charles in #ubuntu-desktop could be more precise. | 16:24 |
| Jasper | Thanks! | 16:24 |
| xnox | Jasper: it would be great to share apis, the underlying datamap and etc. but i'd be worried if gnome devs go ahead and start breaking ability for us to maintain our design/ui to the point where we'd be forced to fork it again. | 16:27 |
| Jasper | OK. | 16:28 |
| xnox | Jasper: e.g. we see currently loads of changes in 3.X series which cause us in ubuntu to constantly revert commits (which break a11y in the installer, ability for apps to add pages/settings in system settings and etc.) | 16:28 |
| Jasper | xnox, a11y bugs are always bugs. If you have issues with a11y, please, please report them upstream. | 16:28 |
| xnox | Jasper: I understand that gnome leads and does amazing work, just give a little thought if there are downstream developers, e.g. collaborate =) | 16:29 |
| Jasper | xnox, we don't mean to cause harm. | 16:30 |
| Jasper | xnox, a11y regressions are taken very seriously upstream, so if you have issues, please report them. We've probably broken things accidentally. | 16:33 |
| Jasper | a11y has been a moving target for 3.6 because we've been trying to turn it on unconditionally, so we've been trying to fix performance regressions, crashes, etc. | 16:33 |
| Jasper | memory leaks | 16:33 |
| xnox | Jasper: past all feature freezes there was some refactoring done to stop a11y on main-loop quiting, thinking that nobody restart main-loop second time around. Resulting in screen reader stopping in our installer, which happes to restart main-loops. | 16:34 |
| xnox | https://bugzilla.gnome.org/show_bug.cgi?id=685453 | 16:34 |
| ubot2` | Gnome bug 685453 in gtk "If an application quits the main loop, and restarts it again, accessibility is lost." [Normal,Unconfirmed] | 16:34 |
| xnox | in ubuntu we reverted that patch. Still unconfirmed upstream. | 16:34 |
| xnox | and further indication that gtk wants to completely remove nested mainloops which will further break our software, with no consideration of wider software outside of core gnome. | 16:35 |
| Jasper | Yikes. | 16:36 |
| xnox | there are further indications of removing painting desktop background picture from g-s-d/nautilus "because it is all now done in gnome-shell" apart from distros that support other gtk based DE which don't have gnome-shell.... | 16:36 |
| Jasper | xnox, having background rendering in the compositor is the right thing to do. | 16:36 |
| xnox | system-settings removed ability to have custom apps add in settings pages to system-settings via desktop files. | 16:36 |
| xnox | instead all settings pages must be statically compiled in. | 16:37 |
| Jasper | xnox, it's really unfortunate that the way it currently works is to punt a giant chunk of bitmap data over to X, which has to be rebound as a GL pixmap. | 16:37 |
| xnox | Jasper: yeah =/ but surely all DEs need to paint a background picture so why not poll the 2-5 devs involved who has to do it anyway. Since making that gnome-shell specific will result in extra implementations using gtk outside of core gnome, which is an overall code debt. | 16:38 |
| xnox | removing dynamic settings is silly. | 16:38 |
| Jasper | xnox, gnome-settings-daemon is meant to be used with GNOME. | 16:38 |
| Jasper | Having it in the compositor allows us to do rendering once, and then when we want to cross-fade, do compositing on the GPU. | 16:39 |
| Jasper | xnox, the code for rendering backgrounds won't work for you guys, because we use Clutter. | 16:39 |
| xnox | yeah, but on ubuntu/debian we have apps made by independent software developers which want good gnome integration of settings. we simply don't know about all of them at gnome-setttings-daemon compile time. | 16:40 |
| Jasper | Er, sorry. | 16:40 |
| Jasper | gnome-control-center is the thing that provides System Settings | 16:40 |
| xnox | maybe I am wrong. | 16:40 |
| Jasper | gnome-settings-daemon is the thing that provides background rendering, etc. | 16:40 |
| xnox | which has been commented by gnome-settings-daemon maintainer to be removed and moved into gnome-shell. | 16:41 |
| Jasper | It's called "gnome-settings-daemon" for legacy reasons. | 16:41 |
| xnox | (as far as i know, it hasn't happened yet) | 16:41 |
| Jasper | xnox, there's patches, and they're going to land for the 3.8 cycle. | 16:41 |
| xnox | anyway, this cycle we are not using gnome rc, and using the last stable release. | 16:41 |
| Jasper | xnox, the reason is that crossfading, etc. should be done on the GPU. | 16:41 |
| xnox | because last cycle too many subtle things where getting broken for us with each dev/preview release. | 16:41 |
| Jasper | xnox, sure, that makes sense. | 16:42 |
| Jasper | xnox, the gnome-control-center story is an unfortunate story, and you can look at it from multiple ways. | 16:42 |
| xnox | Jasper: i would welcome to share and use timedate with gnome and have it on gnome infrastructure. It just makes me sad that it may go and become fully "GNOME".... | 16:43 |
| Jasper | xnox, in what way? | 16:43 |
| Jasper | xnox, user testing showed that when people went to look for app settings, they looked for application menu items, they didn't go to the control center | 16:44 |
| Jasper | xnox, so, we decided that applications should provide a menu item to bring up their settings panel, and we'd leave gnome-control-center purely for system settings. | 16:44 |
| xnox | committing changes & releasing gnome 3.X+1 which breaks in ubuntu indicators, ubuntu installer (the top two high profile use cases of that widgets). | 16:44 |
| xnox | Jasper: good. our user testing is different, due to different desktop environment and how our indicators work. For us it currently still makes sense to have pluggable system settings, especially for those components that control "our" non-GNOME system components. | 16:46 |
| Jasper | If you have non-GNOME system components, I'd make a branch of gnome-control-center which adds those components, not add pluggable modules back. | 16:46 |
| Jasper | I don't know much about how your indicators work. | 16:47 |
| Jasper | Apologies. | 16:47 |
| * xnox is not involved in the desktop side of things. I'm mostly involved with foundations/core components. So my experience is a bit second hand (last minute pre-milestone cd respins with gtk bug fixes). | 16:49 | |
| xnox | Jasper: jhbuild bzr support is excellent! I wrote patches for it =) | 16:49 |
| Jasper | OK. | 16:50 |
| xnox | Jasper: but it's not about code/tarball/bugs location - it's about core-review, testing on !fedora and considerate development which has been lacking between ubuntu<->gnome for a while know and seems to only deteriorate. | 16:50 |
| Jasper | Right, we have a new system. | 16:51 |
| Jasper | cgwalters has been working on a new system called "ostree" which is designed to make full OS builds much easier. | 16:51 |
| Jasper | Because he agrees: right now every few months we run a command, upload a tarball, and then wait for something to break. | 16:51 |
| Jasper | Integration testing is something he's working hard to achieve. | 16:52 |
| xnox | Jasper: we build daily gnome 3.X jhbuild in jenkins in our labs and run automatic as installed package testing to catch stuff. (since we need to be prepared for when 3.8 lands and we do a hop onto it) | 16:53 |
| Jasper | Right. | 16:53 |
| xnox | actively fixing bugs and creating workaorounds on our side. | 16:53 |
| xnox | but it's not enough, currently. | 16:53 |
| Jasper | Right, and that's what cgwalters is hoping to achieve. | 16:53 |
| xnox | Jasper: in ubuntu projects were we are upstream: each merge proposal goes through code review, unit tests and integration tests (UI testing using xpresser) before being merged in trunk & automatically uploaded into the distribution. | 16:56 |
| xnox | Jasper: are you happy willing to do that with timedate? | 16:57 |
| Jasper | xnox, do what? | 16:58 |
| xnox | for us ubuntu+1 is dogfood and always usable. we had a couple minor brakeges this cycle, but all were quickly resolved. | 16:58 |
| xnox | https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog | 16:58 |
| xnox | Jasper: smoke-test each commit before pushing to master and/or releasing tarballs. | 16:59 |
| Jasper | xnox, of course | 16:59 |
| Jasper | That's something we want to achieve. | 16:59 |
| Jasper | I'll talk to cgwalters about integration xpresser. | 16:59 |
| xnox | on our side, we figured our story out already with launchpad, bzr, jenkins, distro-uploads all working in orchestration. we are currently up on about 30% of our developed software doing this (mostly the desktop & high visible things) and we are ramping it up. | 17:01 |
| Jasper | xnox, are all your tests open? | 17:01 |
| xnox | the jenkins & testings is VCS agnostic and can work with git, but I am not sure about automatic package generates and uploads. | 17:01 |
| Jasper | And can we integrate them back upstream? | 17:01 |
| xnox | i need to check which bits are enabled and done. we primary focus on testing our unity/desktop stack. I'm not sure where / how / if at all timedate is being tested already or not. | 17:03 |
| xnox | Jasper: most results are public here: https://jenkins.qa.ubuntu.com/ | 17:03 |
| Jasper | I mean the GNOME parts. | 17:03 |
| cjwatson | We don't have a mechanism for closed-source tests | 17:03 |
| cjwatson | (AFAIK) | 17:04 |
| cjwatson | This is not a problem I'm keen to fix :-) | 17:04 |
| Jasper | I don't quite understand Xpresser, but OK. | 17:05 |
| Jasper | It seems to use images? | 17:05 |
| Jasper | That would be quite annoying for us to rebuild images every time our artists modify the theme, so I'd be curious to hear how you handle it. | 17:06 |
| Jasper | Do you force the default theme? | 17:06 |
| xnox | Jasper: xpresser - images; autopilot - interspection. Tries to emulate user-activity and verify that correct things are displayed/painted/shown with timeouts on different hardware platforms. | 17:06 |
| xnox | we mix in interspection =) | 17:06 |
| Jasper | Do you have a page somewhere describing this? | 17:06 |
| xnox | e.g. we had embarrassing bug on KDE desktop where "update notification" bubble did not pop-up post-release graphically, while the unit tests were passing fine =))) | 17:07 |
| xnox | Jasper: talk to #ubuntu-quality or #ubuntu-unity folks on how it's done. | 17:07 |
| Jasper | OK. | 17:07 |
| xnox | we are meant to have developer tutorials / school week soon on how to do this. | 17:08 |
| xnox | Jasper: dholbach is planning/organising that. | 17:08 |
| Jasper | OK. | 17:12 |
| xnox | gnome release shedule, ftp tarball / vcs / bug hosting so far doesn't change nor improve anything for us apart from potentially hindering current qa integration. | 17:16 |
| xnox | (release schedules got slightly out of sync nowaways I believe) | 17:17 |
| infinity | xnox: Hey, do you know if there's any way to ask d-i nicely to create raid devices with old metadata formats (0.90 or 1.0 instead of 1.2)? | 21:12 |
| xnox | you wish | 21:13 |
| infinity | I really do. | 21:13 |
| xnox | let me double check. I daubt it's possible. | 21:13 |
| infinity | I guess I could create them by hand and then install to them? | 21:13 |
| xnox | yes you can. | 21:13 |
| xnox | mind the --home-hostname parameter name. | 21:14 |
| xnox | and please make it match the $hostname | 21:14 |
| xnox | --homehost that is | 21:14 |
| cjwatson | infinity: why? | 21:15 |
| infinity | cjwatson: https://bugs.gentoo.org/show_bug.cgi?id=198529 | 21:15 |
| ubot2` | bugs.gentoo.org bug 198529 in Core system "sys-boot/yaboot{,-static} mishandles RAID devices with v1.[12] metadata" [Major,Confirmed] | 21:15 |
| cjwatson | another reason to use grub :0 | 21:16 |
| cjwatson | :P | 21:16 |
| infinity | cjwatson: (Yes, that would be a non-issue if I used grub, but the inability to boot from a CD is irksome) | 21:16 |
| cjwatson | wait, that bug prevents CD booting? | 21:16 |
| xnox | infinity: you can use very old installer which had 0.9 metadata by default. (e.g. lucid?!) | 21:16 |
| infinity | I mean boot the installed system from a CD's yaboot prompt. | 21:16 |
| cjwatson | ah | 21:17 |
| cjwatson | should really find a spare week to switch powerpc to grub properly ... | 21:17 |
| cjwatson | (ho ho ho) | 21:17 |
| infinity | Yeah, or that. Now's a good chance to debug. :P | 21:17 |
| xnox | infinity: you can override default metadata format in mdadm.conf and in udeb that is located in | 21:17 |
| infinity | Though, the system under my desk is similar enough that we could debug there. | 21:18 |
| xnox | /tmp/mdadm.conf | 21:18 |
| infinity | Oh, indeed. | 21:18 |
| infinity | ARRAY /dev/md/0 metadata=1.2 UUID=76175fcc:4b805933:48f9fd2c:fead070b name=sagari:0 | 21:18 |
| xnox | CREATE=0.90 | 21:18 |
| infinity | The question is, how and when does that get overwritten? | 21:18 |
| xnox | that's during install. once the mdadm metadata created it will not be auto-upgraded. | 21:19 |
| xnox | and always detected. | 21:19 |
| infinity | The Gentoo bug implies I might want 1.0... Though 0.90 seems to work too, despite having "endian issues" (that's not a scary statement when tossed about unvalidated, nooo..) | 21:19 |
| xnox | infinity: well yes, choose the one you want =) the higher the better. | 21:19 |
| infinity | xnox: No, no. I know metadata can't be changed post-create. I mean that /tmp/mdadm.conf file, if I change it, will d-i just overwrite it? :P | 21:20 |
| xnox | change it during partman/early-command | 21:20 |
| xnox | cause by this time mdadm udebs are unpacked. yet nothing was started / done yet. | 21:20 |
| infinity | I'm doing this by hand, not preseeding. | 21:20 |
| infinity | Man, I wish I had more than one console... | 21:21 |
| xnox | i tinker the stuff after udebs are unpacked but before partman started something like "username" step?! | 21:21 |
| xnox | oh, you don't have another tty?! =) | 21:21 |
| cjwatson | I usually poke about at the hostname prompt | 21:21 |
| infinity | I have a serial console. | 21:21 |
| cjwatson | so go back from that to the main menu and exec shell | 21:21 |
| infinity | So, I get to exit/return/exit/return. | 21:22 |
| infinity | Yeah. | 21:22 |
| infinity | Well, except... | 21:22 |
| cjwatson | by then everything should be unpacked ... although partman-md is a bit odd | 21:22 |
| infinity | That file won't exist until one runs partman and tells it to create something, right? | 21:22 |
| cjwatson | worst case, anna-install mdadm-udeb | 21:22 |
| infinity | So, there's clearly a short window of opportunity to fool it. | 21:22 |
| cjwatson | you could edit the partman script in question | 21:22 |
| cjwatson | s'all shell ... | 21:22 |
| infinity | Or that, yeah. | 21:23 |
| infinity | Yeah, there's no window where I can edit that file in between defining and creating. But I could just stop it and recreate it by hand, which might be sane. | 21:26 |
| infinity | 127734656 blocks super 1.0 [2/2] [UU] | 21:39 |
| infinity | 127734656 blocks super 1.0 [2/2] [UU] | 21:39 |
| infinity | I win. | 21:39 |
| infinity | Twice, apparently. | 21:39 |
| infinity | xnox: I might give you a patch for an expert-only partman-md/metadata preseed. Looks like it'd be trivial to inject it (as I just did with nano :P) into the create commands. | 21:40 |
| infinity | Not that most people would ever need to care, but there are reasons other than esoteric bootloaders to prefer 1.0/1.1/1.2 (all the same, except for metadata placement) | 21:40 |
| xnox | infinity: sure. i'll push it for jessie & our partman. | 21:41 |
| xnox | infinity: should the default of mdadm package on powerpc be 1.0 until this is resolved in the bootloader? | 21:41 |
| xnox | or whatever arch you are using. | 21:41 |
| xnox | i guess that's too much. | 21:42 |
| infinity | xnox: Nah, if you're trying to be magical, this is only required if bootloader=yaboot && array=place_with_kernel (so, /, or /boot) | 21:42 |
| infinity | I'm sure there's enough logic hidden in partman to determine that, but it also sounds like a bit of effort to go to. | 21:42 |
| xnox | hmm... we create arrays first, then assign mount-points to them. so not always detectable upfront. | 21:43 |
| infinity | Oh, right. | 21:43 |
| infinity | In fact, it gets really messy if you do array->lvm->ext4->mountpoint. | 21:43 |
| infinity | Probably something better left to the mountpoint selector to bitch that its underlying array is the wrong metadata format. | 21:43 |
| infinity | All in all, likely better for someone to either fix yaboot, or switch all yaboot-using systems to grub2. :P | 21:44 |
| infinity | (not against both happening, really) | 21:44 |
| infinity | grub's the obvious answer for the future, mind you, since yaboot has the same general limitations as lilo and others. | 21:46 |
| infinity | It can only boot from "raid" if your "raid" happens to look suspiciously just like a normal partition. :P | 21:46 |
| infinity | (ie: a mirror with no garbage blocks) | 21:46 |
| * xnox is back to pretending to study "Life in the UK - Journey to Citizenship" book for my test. | 21:47 | |
| infinity | Sounds thrilling. | 21:50 |
| xnox | infinity: yeah. Apparently while Britain was busy getting it's imperial swag on, potato crop failed and ireland suffered a famine. and other interesting facts of life that in scotland to buy a house one first goes to a solicitor, while in england to an estate agent. | 21:59 |
| infinity | xnox: I fail to understand why a citizen needs to know these things, but good luck. :) | 22:04 |
| xnox | it has all sorts of things: uk school education system, how many one gets time off work for holidays, maternity, paternity. how legal system works, how to pay taxes, get married and divorsed. it's a lot of stuff =) | 22:06 |
| infinity | Oh sonofa... I forgot to install my custom kernel in the target system. | 22:11 |
| * infinity head -> desk. | 22:11 | |
| stgraber | infinity: bah, who needs network post-install anyway ;) | 22:39 |
| infinity | stgraber: No network would be fine. No console is a bit less useful. | 22:39 |
| stgraber | ah, no shiny kvm or usable IPMI console? | 22:40 |
| infinity | stgraber: And, to make matters more hilarious, I assume d-i ejected my CD before it rebooted. And the machine didn't suck it back in for me. So, I need to sucker some poor DCE in Boston to go push the tray with his finger. | 22:40 |
| stgraber | ;) | 22:40 |
| cjwatson | infinity: For next time, boot the installer with cdrom-detect/eject=false | 22:40 |
| infinity | stgraber: I have a lovely serial console. But without a custom kernel, it no workie. Said custom kernel is on the d-i CD that's not in the tray. | 22:40 |
| infinity | cjwatson: There shouldn't be a next time past this one, cause I'll remember to install my kernel! :) | 22:41 |
| cjwatson | You hope | 22:41 |
| infinity | cjwatson: (But, yeah, belt-and-bracers, I'll remember the commandline too... And hopefully, I remember one of those two things) | 22:41 |
| infinity | If only the firmware had an obvious "suck the CD tray back in, pleeeeease" option. | 22:42 |
| stgraber | that's assuming the drive can physically do that ;) | 22:43 |
| infinity | Can any of the ones built in the last decade not? | 22:43 |
| infinity | Oh, I guess it might be a slimline laptop-style drive. | 22:43 |
| infinity | Those are pretty common in rack machines. | 22:43 |
| infinity | Fair point. | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
