| saeed | canonicals, installing lucid on sata hdd on dove fails, http://paste.ubuntu.com/380922/ contains the /var/log/installer/debug file | 11:41 |
|---|---|---|
| armin76 | you need to use gentoo | 11:43 |
| * armin76 runs | 11:43 | |
| 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:44 |
| saeed | ok, I'll also run ubiquity with --debug | 11:45 |
| saeed | l | 11:45 |
| 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:02 |
| lool | saeed: Did you format in any particular way? | 12:03 |
| saeed | lool, I used default options, and in the partitions section, I chose the second option (use full disk) | 12:06 |
| saeed | lool: should I modify the bug to be set for flash-kernel instead of debian-installer? | 12:07 |
| * persia was giving completely generic advice without insight into the hardware or the issue, so should not take precedence. | 12:08 | |
| lool | saeed: It's ok, it might actually be in some partition manager code instead of flash-kernel | 12:24 |
| 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:25 |
| lool | saeed: if you know which specific component it is, you may file it directly there of course! | 12:26 |
| 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:27 |
| ogra_cmpc | (needs network connection on the board though) | 12:28 |
| zumbi_ | do you support substvars (@foo@) on debian/control file in Ubuntu? | 14:23 |
| 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:25 |
| 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:33 |
| 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:34 |
| zumbi_ | lool: ^ | 14:35 |
| persia | zumbi_: Um, using things like ${shlibs:Depends} and ${misc:Depends} violates policy? | 14:36 |
| persia | I'm very suspicious about that. | 14:36 |
| zumbi_ | persia: no, that is allowed | 14:37 |
| 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:38 |
| persia | I agree it's kinda excessive. | 14:39 |
| zumbi_ | persia: and line 36 36 230 | 14:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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 :-) | 14:43 |
| lool | zumbi_: Sorry, which part do you want me to comment on? | 15:28 |
| lool | zumbi_: I don't see where substvars are a problem in openjdk-6's debian/control | 15:38 |
| zumbi_ | lool: no, no problem, i was wrong.. badcall | 15:44 |
| 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. | 15:53 |
| zumbi_ | persia: hehe, i was only trying to understand if ubuntu had done some patching to made this posible, it was just curiosity. | 16:55 |
| === hrw|gone is now known as hrw | ||
| hrw | morning | 19:19 |
| === hrw is now known as hrw|gone | ||
| === wgrant_ is now known as wgrant | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!