[11:41] <saeed> canonicals, installing lucid on sata hdd on dove fails, http://paste.ubuntu.com/380922/ contains the /var/log/installer/debug file
[11:43] <armin76> you need to use gentoo
[11:43]  * armin76 runs
[11:44] <persia> 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).
[11:45] <saeed> ok, I'll also run ubiquity with --debug
[11:45] <saeed> l
[12:02] <lool> saeed: Could you file a bug against flash-kernel and you /var/log/installer logs?
[12:02] <lool> Ah persia asked you already
[12:02] <lool> saeed: This seems to be due to flash-kernel not handling your particular setup
[12:03] <lool> saeed: Did you format in any particular way?
[12:06] <saeed> lool, I used default options, and in the partitions section, I chose the second option (use full disk)
[12:07] <saeed> lool: should I modify the bug to be set for flash-kernel instead of debian-installer?
[12:08]  * persia was giving completely generic advice without insight into the hardware or the issue, so should not take precedence.
[12:24] <lool> saeed: It's ok, it might actually be in some partition manager code instead of flash-kernel
[12:25] <lool> 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
[12:26] <lool> saeed: if you know which specific component it is, you may file it directly there of course!
[12:27] <ogra_cmpc> or just use: ubuntu-bug ubiquity from a terminal
[12:27] <ogra_cmpc> that will set all tags and attach all relevant logfiles
[12:28] <ogra_cmpc> (needs network connection on the board though)
[14:23] <zumbi_> do you support substvars (@foo@) on debian/control file in Ubuntu?
[14:25] <persia> I generally use ${foo:Depends} or ${foo:Recommends} for some value of foo, but yes.
[14:25] <persia> I believe it must be ${variable}
[14:25] <persia> man deb-substvars for more info
[14:25] <persia> Note that some people use a debian/control.in which uses autotools to generate debian/control, but that's usually more than is required.
[14:33] <zumbi_> persia: using substvars on control files violates debian-policy and it is not sane, it is better to use control.in files approach
[14:34] <zumbi_> 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
[14:35] <zumbi_> lool: ^
[14:36] <persia> zumbi_: Um, using things like ${shlibs:Depends} and ${misc:Depends} violates policy?
[14:36] <persia> I'm very suspicious about that.
[14:37] <zumbi_> persia: no, that is allowed
[14:38] <persia> zumbi_: Then I think I don't understand you.
[14:38] <zumbi_> persia: line 38: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head:/control
[14:38] <persia> Why is this bad?
[14:39] <persia> I agree it's kinda excessive.
[14:39] <zumbi_> persia: and line 36 36 	230 	
[14:40] <zumbi_> persia: uhm... i might be wrong as it uses ${foo:bar} not @foo@ (as more common on control.in)
[14:40] <persia> I don't think using @foo@ in debian/control is acceptable: I think that has to be in control.in
[14:41] <zumbi_> 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
[14:41] <persia> 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.
[14:41] <zumbi_> persia: right, bad call... thanks
[14:41] <persia> Well, it always happens at dpkg-gencontrol time.
[14:42] <persia> 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.
[14:42] <persia> But it still requires care, and can be done in vary awkward ways.
[14:43] <persia> (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)
[14:43] <zumbi_> yes, i agree :-)
[15:28] <lool> zumbi_: Sorry, which part do you want me to comment on?
[15:38] <lool> zumbi_: I don't see where substvars are a problem in openjdk-6's debian/control
[15:44] <zumbi_> lool: no, no problem, i was wrong.. badcall
[15:53] <persia> 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.
[16:55] <zumbi_> persia: hehe, i was only trying to understand if ubuntu had done some patching to made this posible, it was just curiosity.
=== hrw|gone is now known as hrw
[19:19] <hrw> morning
=== hrw is now known as hrw|gone
=== wgrant_ is now known as wgrant