**** BEGIN LOGGING AT Sun Feb 21 02:59:57 2010 Feb 21 11:41:04 canonicals, installing lucid on sata hdd on dove fails, http://paste.ubuntu.com/380922/ contains the /var/log/installer/debug file Feb 21 11:43:27 you need to use gentoo Feb 21 11:43:28 * armin76 runs Feb 21 11:44:37 saeed: You'll probably do better to file a bug against debian-installer and attach the log (and maybe more: I know I've seen syslogs requested from failed installs as well). Feb 21 11:45:50 ok, I'll also run ubiquity with --debug Feb 21 11:45:56 l Feb 21 12:02:24 saeed: Could you file a bug against flash-kernel and you /var/log/installer logs? Feb 21 12:02:30 Ah persia asked you already Feb 21 12:02:45 saeed: This seems to be due to flash-kernel not handling your particular setup Feb 21 12:03:00 saeed: Did you format in any particular way? Feb 21 12:06:42 lool, I used default options, and in the partitions section, I chose the second option (use full disk) Feb 21 12:07:31 lool: should I modify the bug to be set for flash-kernel instead of debian-installer? Feb 21 12:08:53 * persia was giving completely generic advice without insight into the hardware or the issue, so should not take precedence. Feb 21 12:24:55 saeed: It's ok, it might actually be in some partition manager code instead of flash-kernel Feb 21 12:25:59 saeed: In general, if you're discovering installation bugs using the installer from the live CD, file them against ubiquity and subscribe ubuntu-armel; if using the text mode installer, file them against debian-installer and subscribe ubuntu-armel; we will eventually figure out which component is affected and triage them Feb 21 12:26:16 saeed: if you know which specific component it is, you may file it directly there of course! Feb 21 12:27:29 or just use: ubuntu-bug ubiquity from a terminal Feb 21 12:27:48 that will set all tags and attach all relevant logfiles Feb 21 12:28:11 (needs network connection on the board though) Feb 21 14:23:58 do you support substvars (@foo@) on debian/control file in Ubuntu? Feb 21 14:25:00 I generally use ${foo:Depends} or ${foo:Recommends} for some value of foo, but yes. Feb 21 14:25:10 I believe it must be ${variable} Feb 21 14:25:17 man deb-substvars for more info Feb 21 14:25:55 Note that some people use a debian/control.in which uses autotools to generate debian/control, but that's usually more than is required. Feb 21 14:33:54 persia: using substvars on control files violates debian-policy and it is not sane, it is better to use control.in files approach Feb 21 14:34:57 persia: i was wondering this because I saw openjdk (doko package) using substvars on control file, but only in ubuntu, maybe you had done the modifications to the tools for this behaviour to be sane Feb 21 14:35:08 lool: ^ Feb 21 14:36:43 zumbi_: Um, using things like ${shlibs:Depends} and ${misc:Depends} violates policy? Feb 21 14:36:50 I'm very suspicious about that. Feb 21 14:37:34 persia: no, that is allowed Feb 21 14:38:18 zumbi_: Then I think I don't understand you. Feb 21 14:38:28 persia: line 38: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head:/control Feb 21 14:38:59 Why is this bad? Feb 21 14:39:08 I agree it's kinda excessive. Feb 21 14:39:13 persia: and line 36 36 230 Feb 21 14:40:13 persia: uhm... i might be wrong as it uses ${foo:bar} not @foo@ (as more common on control.in) Feb 21 14:40:44 I don't think using @foo@ in debian/control is acceptable: I think that has to be in control.in Feb 21 14:41:23 persia: it would be dangerous because you can't ensure that the substitution will be done correctly (at the time it should be done), but I guess it is right as packagers know very much what they do Feb 21 14:41:28 But I don't see an issue with ${foo} in debian/control, as long as it doesn't affect anything in the source stanza or any of the names of the produced binary packages. Feb 21 14:41:50 persia: right, bad call... thanks Feb 21 14:41:52 Well, it always happens at dpkg-gencontrol time. Feb 21 14:42:36 So as long as debian/substvars is correct by the end of the install, it ought be safe. Mind you, policy demands that debian/substvars be removed in clean, if it can exist, so it's always generated afresh in debian/rules at build-time. Feb 21 14:42:56 But it still requires care, and can be done in vary awkward ways. Feb 21 14:43:32 (and it's possible to violate policy with it, if one isn't careful, by fiddling with the source stanza or the binary package names) Feb 21 14:43:38 yes, i agree :-) Feb 21 15:28:21 zumbi_: Sorry, which part do you want me to comment on? Feb 21 15:38:51 zumbi_: I don't see where substvars are a problem in openjdk-6's debian/control Feb 21 15:44:33 lool: no, no problem, i was wrong.. badcall Feb 21 15:53:56 zumbi_: Don't worry about it: It's better to raise anything you see like that, rather than let it slide, because it might be a huge potential bug. Feb 21 16:55:49 persia: hehe, i was only trying to understand if ubuntu had done some patching to made this posible, it was just curiosity. Feb 21 19:19:00 morning **** ENDING LOGGING AT Mon Feb 22 02:59:58 2010