| === xivulon_ is now known as xivulon | ||
| CIA-3 | user-setup: cjwatson * r154 ubuntu/debian/changelog: releasing version 1.23ubuntu11 | 12:30 |
|---|---|---|
| CIA-3 | tasksel: cjwatson * r1392 ubuntu/ (9 files in 4 dirs): | 12:44 |
| CIA-3 | tasksel: Offer manual package selection via aptitude if the cdebconf terminal | 12:44 |
| CIA-3 | tasksel: plugin is available (LP: #21570). | 12:44 |
| CIA-3 | ubiquity: evand * r3032 ubiquity/ (4 files in 3 dirs): Move the resize functionality into the segmented bar widget. | 14:21 |
| CIA-3 | ubiquity: evand * r3033 ubiquity/ubiquity/segmented_bar.py: | 14:41 |
| CIA-3 | ubiquity: Unround the corners of the segmented bars on the automatic partitioning page. | 14:41 |
| CIA-3 | ubiquity: Show the size of each partition when resizing. | 14:41 |
| CIA-3 | tasksel: cjwatson * r1393 ubuntu/tasksel.pl: fix manual package selection: use --schedule-only to mark packages, then plain aptitude (without "--visual-preview install") to display the UI | 14:48 |
| CIA-3 | ubiquity: evand * r3034 ubiquity/ (debian/changelog scripts/install.py): | 15:04 |
| CIA-3 | ubiquity: Copy the Distribution Channel Descriptor (DCD) file into the target | 15:04 |
| CIA-3 | ubiquity: filesystem if it exists in /cdrom/.disk/. | 15:04 |
| shtylman | when building packages...shouldn't template sorting happen only if template files change? or are the sorts not stored? | 15:21 |
| evand | mpt: Ignoring the poorly drawn resize handle (I'll fix that in a bit), do you have any comments on this cut of the resize widget integration: http://people.ubuntu.com/~evand/tmp/ubiquity-new-resize.png . We can now make those options below say whatever we want, by the way. | 15:26 |
| evand | cjwatson: I'm equally keen to hear any comments you may have as well. | 15:28 |
| mpt | evand, yay for square corners! | 15:28 |
| evand | :) | 15:28 |
| shtylman | evand: I pulled your latest changes and the installer failed to draw the after bar for me | 15:29 |
| mpt | I was going to ask "what type of FS does the black section represent", then I realized that's the resize handle... | 15:29 |
| evand | shtylman: interesting. I'll poke at it and see if I can reproduce the bug. | 15:29 |
| evand | yeah, I need to actually draw something resembling one there, but I wanted to get the fundamentals down first. | 15:30 |
| mpt | evand, currently the text for the first chart's legend is closer to the second chart than it is to the first chart | 15:30 |
| shtylman | evand: gtk_ui:3019, assertion width >= -1 failed self.new_os.set_siz_request(pixels, -1) | 15:30 |
| mpt | evand, why does the "100%" not have an accompanying size, while the other percentages do? | 15:31 |
| evand | mpt: I'd need to add code to calculate it, whereas we get it for free with the partitions that are being resized. But I can do that quite easily. | 15:32 |
| * evand makes a note | 15:32 | |
| evand | shtylman: bzr pull again? | 15:32 |
| mpt | It would be nice if "Before:" and "After:" were centered with the actual bars, ignoring their legends, but that's probably really difficult | 15:33 |
| shtylman | evand: on mpt's note, I wanted more fine grained partition info in the before bar, so what I did for the kde side (currently) was to regain priv and ask parted server for a disk list, store that and drop privs...all in the set_autoparti... | 15:33 |
| shtylman | mpt: centering with the bars is a problem for small partitions | 15:34 |
| evand | shtylman: indeed, that's effectively what I just made a note to do. | 15:34 |
| evand | mpt: indeed, but I can take a shot at it | 15:34 |
| mpt | shtylman, in what way? | 15:34 |
| mpt | (I mean the "Before:" and "After:" labels vertically centered, not the legend bits horizontally centered) | 15:35 |
| shtylman | ops...sorry completely read that wrong | 15:35 |
| evand | ( | 15:35 |
| evand | whoops | 15:35 |
| shtylman | *oops | 15:35 |
| shtylman | yea...by bad | 15:35 |
| evand | (I've also made a note to better space between the two widgets) | 15:35 |
| shtylman | are we thinking that square ends are better than rounded? | 15:36 |
| mpt | shtylman, mainly because it's more accurate when the first/last partition is small, and partly because it makes it look less like iTunes | 15:37 |
| shtylman | hahaha | 15:37 |
| mpt | (the texture is still a pixel-precise iTunes ripoff, but one step at a time) | 15:37 |
| evand | :) | 15:38 |
| shtylman | (sulks...as he changes the kde one back to square) | 15:38 |
| mpt | (and so is the reflection) | 15:38 |
| mpt | (and so is the legend) | 15:38 |
| shtylman | but it cools cool :) | 15:39 |
| shtylman | and thats what counts! | 15:39 |
| mpt | "How do you want to partition the disk?" is still a moderately loaded question | 15:40 |
| evand | mpt: What would you suggest? | 15:40 |
| evand | and on that, does "Use entire disk" and "Resize a partition above and use the freed space" sound ok? | 15:41 |
| mpt | evand, probably nothing you'd have time to implement before feature freeze | 15:41 |
| mpt | I think a good intro line would be of the form | 15:41 |
| shtylman | evand: I have spmehow messed up my branch regarding the debian/changelog...how do I just tell bzr to use the one from the main branch? | 15:41 |
| shtylman | and throw away mine? | 15:42 |
| mpt | The disk [SCSI1 (4.3 GB ATA) :^] is empty. | 15:42 |
| mpt | The disk [SCSI1 (4.3 GB ATA) :^] has Windows XP on it. | 15:42 |
| mpt | The disk [SCSI1 (4.3 GB ATA) :^] has two operating systems on it. | 15:42 |
| mpt | etc | 15:42 |
| evand | shtylman: assuming it's complaining about a conflict, I would copy the main branch copy over top and say bzr resolve. | 15:42 |
| evand | mpt: is that a drop down box? | 15:43 |
| shtylman | evand: ok, also, you said 'pull' earlier, but I looked at the main branch and I have the latest...do you have a separate branch? | 15:43 |
| mpt | evand, yes if there are multiple eligible disks for installation, otherwise just plain text | 15:43 |
| mpt | (or even just "This computer", if there's only one eligible disk) | 15:44 |
| mpt | This computer has Windows Vista on it. | 15:45 |
| mpt | [ Windows Vista (120 GB) ] | 15:46 |
| shtylman | evand: ok, I ran it again (and on my local version it seemed to work..but one problem I found was that it doesn't actually limit itself to that partition | 15:46 |
| evand | mpt: perhaps we should pass back and forth pieces of paper :) | 15:46 |
| shtylman | I have a disk I am using to test the bars and it has a small ext3 (8bg) at the head | 15:46 |
| shtylman | about 40gb free space | 15:46 |
| shtylman | and 2gb swap at end | 15:47 |
| evand | shtylman: indeed, I noticed that a few minutes ago and will need to fix it. | 15:47 |
| shtylman | and when I click the resize above option, it makes a slider over the whole disk | 15:47 |
| shtylman | (k) | 15:47 |
| shtylman | also...another note...I think something usefull would be to have the 'use largest free space' option actually show which free space will be used | 15:47 |
| shtylman | versus being 100% for the whole bar | 15:48 |
| shtylman | and on a final note: for the manual option...I hide the after bar altogether | 15:48 |
| evand | shtylman: That's a bug | 15:48 |
| mpt | evand, katkin might demand to read each of them first | 15:48 |
| evand | or rather, could be considered one | 15:48 |
| shtylman | gotcha | 15:49 |
| mpt | evand, I'm disappointed I didn't get time to spend on this a couple of weeks ago | 15:49 |
| evand | mpt: No worries, I am well aware of how busy you are with other things | 15:49 |
| mpt | evand, does "Use entire disk" disable the resize handles? | 15:50 |
| evand | yes, and adds a "this will permanently delete Windows XP" message to the side with a warning icon | 15:51 |
| mpt | evand, I think the "After:" chart would therefore make more sense below the radio buttons than above. | 15:52 |
| evand | mpt: ah, good call | 15:52 |
| evand | I need to figure out what I am going to do to decouple the labels from the bars (the descriptions of each partition, Ubuntu Jaunty 9.04 (development release) for example, can often make the bar extend beyond the allocated space for it. I was going to leave just the colored boxes and sizes and move matching colored boxes and labels into a chart to the right of the options, but that would make things quite crowded and all over the place | 16:01 |
| evand | by all over the place I mean you'd be looking at sources of information to the top, bottom, right, and center. | 16:02 |
| shtylman | why do you want to decouple them? | 16:02 |
| shtylman | seems like they go nicely under that bar...? | 16:02 |
| evand | they force the size of the partition bars to grow beyond the allocated space | 16:02 |
| evand | forcing us to stuff the partition bar in a scroll window when that happens | 16:03 |
| shtylman | when you get more labels? or more text? | 16:03 |
| evand | which can be quite ugly | 16:03 |
| shtylman | ahh | 16:03 |
| evand | well, both | 16:03 |
| evand | but more often more text | 16:03 |
| evand | though some people do have systems with an infinitely large number of partitions. Damn extended partitions. | 16:03 |
| evand | Why would anyone need more than four? :) | 16:04 |
| mpt | I overflowed with as few as four, iirc | 16:04 |
| mpt | http://launchpadlibrarian.net/18799517/screenshot.png | 16:05 |
| evand | indeed :) | 16:05 |
| shtylman | wow | 16:06 |
| mpt | Looking at that again, I see half my problem was tiny scraps of free space between the partitions | 16:06 |
| shtylman | what about hover labels? | 16:07 |
| shtylman | when you hover over the partition? | 16:07 |
| mpt | or labels inside the sections that are drawn fully if there is room, or completed on hover if there isn't room | 16:08 |
| mpt | like in Netscape 4 Mail for Mac! (no, really) | 16:08 |
| evand | hrm, like the resize widget used to be? | 16:08 |
| shtylman | yea...something like that | 16:09 |
| evand | mpt: do you have a screenshot of this by any chance? | 16:09 |
| mpt | evand, no, but I'll sketch it for you now | 16:10 |
| evand | mpt: much appreciated | 16:10 |
| * mpt hands over the sketch and sadly returns to notification bubbles :-) | 16:20 | |
| evand | haha | 16:20 |
| CIA-3 | tasksel: cjwatson * r1394 ubuntu/disconnect: pass some environment variables through to disconnected aptitude | 17:06 |
| CIA-3 | tasksel: cjwatson * r1395 ubuntu/debian/changelog: releasing version 2.73ubuntu14 | 17:09 |
| CIA-3 | ubiquity: evand * r3035 ubiquity/ (3 files in 3 dirs): | 17:32 |
| CIA-3 | ubiquity: Disable the encrypted home option. This cannot be considered secure | 17:32 |
| CIA-3 | ubiquity: without encrypted swap. The option can still be enabled by preseeding | 17:32 |
| CIA-3 | ubiquity: it. | 17:32 |
| CIA-3 | partman-auto-lvm: cjwatson * r211 ubuntu/debian/ (65 files in 2 dirs): Remove "Please try again" from templates, per Christian Perrier. | 17:33 |
| CIA-3 | installation-guide: cjwatson * r447 ubuntu/ (debian/changelog en/appendix/preseed.xml): Document partman-auto-lvm/guided_size. | 17:37 |
| cr3 | is it known that the current image has dependency problems: libart2.24-cil: Conflicts: libart2.0-cil but 2.20.1-1ubuntu1 is to be installed | 19:06 |
| cjwatson | it's been mentioned, but it isn't a topic for this channel | 19:28 |
| shtylman | how exactly should the 'resize partition above and use freed space' option work? | 22:11 |
| shtylman | lets say I have 60gb drive | 22:11 |
| shtylman | first 8gb are ext3 | 22:11 |
| shtylman | then 50gb of free space | 22:11 |
| shtylman | and then swap | 22:11 |
| shtylman | if the user picks resize...does that mean it will allow them to scale down the ext3 partition and use whatever is there plus the free space partition since that one immediately follows it? | 22:12 |
| cjwatson | if you have 50gb of free space, it won't bother offering the resize option in the first place | 22:33 |
| cjwatson | but let's say the amount of free space is smaller | 22:33 |
| cjwatson | in that case it would resize down the ext3 partition, and then there would be a single big block of free space after it, which it would use for guided partitioning | 22:34 |
| cjwatson | there's no such thing as two contiguous blocks of free space - free space is just the absence of a partition, and doesn't have a real existence itself in the partition table | 22:35 |
| cjwatson | i.e. no such thing as a "free space partition", really, even though partman presents free space in the same kind of way as it presents partitions for the sake of UI convenience | 22:35 |
| cjwatson | shtylman: ^- | 22:35 |
| kirkland | cjwatson: it occurred to me ... | 22:46 |
| kirkland | cjwatson: while highly inadvisable, it's trivially easy to lock yourself out of a system where you use encrypted-home with 'sudo apt-get remove ecryptfs-utils' | 22:47 |
| kirkland | cjwatson: what do we do with other shoot-yourself-in-the-foot packages like this? | 22:47 |
| cjwatson | I have a hard time getting worried about that. There are lots of such cases | 22:47 |
| kirkland | cjwatson: okay, cool :-) | 22:47 |
| kirkland | cjwatson: good enough for me | 22:47 |
| superm1 | can they be marked 'essential'? | 22:47 |
| cjwatson | absolutely not. | 22:47 |
| kirkland | superm1: well, it's only essential if you want encrypted home | 22:48 |
| cjwatson | ecryptfs-utils ain't essential | 22:48 |
| kirkland | which is not everyway | 22:48 |
| kirkland | *everywhere* | 22:48 |
| superm1 | i dont think i conveyed that right. if they're installed can they be reported as essential, but not installed by default of course | 22:48 |
| cjwatson | 'sudo apt-get remove gdm' breaks the system as far as a user who has no idea how to use the console is concerned, but we don't prevent people from doing that | 22:48 |
| cjwatson | superm1: no, there is no mechanism for that at the moment | 22:48 |
| superm1 | ah okay | 22:49 |
| cjwatson | if we wanted to do this, then yes that's the sort of way one would need to fix it | 22:49 |
| cjwatson | but there is no existing infrastructure | 22:49 |
| cjwatson | the closest we have is that apt has a special-case hack to complain if you try to remove apt | 22:49 |
| cjwatson | * I cannot self-terminate. Closes: #74928 | 22:49 |
| kirkland | cjwatson: :-) fair enough. seems i'm not the only package in this situation | 22:50 |
| cjwatson | kirkland: actually, there might be one ugly way to prevent it, although it might leave apt rather dazed nd confused | 22:50 |
| cjwatson | and | 22:50 |
| cjwatson | kirkland: make 'prerm remove' check whether ecryptfs is actually in use, and if so bail out with an error message | 22:51 |
| cjwatson | I vaguely recall that there's some precedent for that | 22:51 |
| kirkland | cjwatson: i think i might just wait until the first moron does this crazy thing :-) | 22:52 |
| cjwatson | ah yes | 22:52 |
| cjwatson | sudo.prerm | 22:52 |
| cjwatson | I think it would be a reasonable check for ecryptfs-utils.prerm, although you might want to make sure that apt ends up in a sane state afterwards (i.e. ecryptfs-utils still installed) | 22:53 |
| cjwatson | and have a look at sudo.prerm which has an override switch in case you really know what you're doing | 22:53 |
| cjwatson | maybe we should write that trick down somewhere :) | 22:54 |
| cjwatson | I remember discussing it with pitti at the time, but it was years ago and took a while to page back in from backing store as it were | 22:54 |
| * TheMuso can't help but think this *COULD* be useful for dmraid. | 22:55 | |
| StevenK | I think exit 1 in the prerm will make dpkg throw up it's tentacles and go "Well *fine*!" | 22:55 |
| TheMuso | but then again, there are many other packages that are similar | 22:55 |
| TheMuso | as has already been stated. | 22:55 |
| cjwatson | the Debian Policy Manual says that if prerm remove fails then dpkg will leave the package in either failed-config or installed state | 22:55 |
| cjwatson | it is somewhat confusingly worded and I might try to get it made more definite | 22:56 |
| StevenK | I was thinking it was more likely the former | 22:56 |
| cjwatson | (since I appear to be a Debian policy editor now) | 22:56 |
| cjwatson | installed would make more sense to me personally, but this is why I was recommending checking :) | 22:56 |
| cjwatson | how about we just test this | 22:57 |
| StevenK | Right. Define in policy an exit code for the prerm that makes dpkg say "Oh, okay, I have just undone everything" | 22:57 |
| cjwatson | huh? no | 22:58 |
| cjwatson | dpkg doesn't in general distinguish exit codes from maintainer scripts, and I don't think it should | 22:58 |
| StevenK | Ah | 22:58 |
| cjwatson | oh, blast, test-removing sudo takes out a bunch of other stuff | 22:58 |
| persia | The only issue with changing policy to require "Installed" rather than "Failed Config" is that all the prerms out there need to recover gracefully from failure (in that if they partially removed things those ought be restored), | 22:59 |
| superm1 | that and then it leaves its status as "deinstall ok installed" | 22:59 |
| cjwatson | ah, I think I've interpreted what policy is saying | 23:00 |
| cjwatson | persia: that's true anyway. | 23:00 |
| cjwatson | policy says that if 'prerm remove' fails, then 'postinst abort-remove' is called. If 'postinst abort-remove' fails, then the package is left in failed-config. Otherwise the package remains installed. | 23:00 |
| persia | cjwatson, In the sense that they are supposed to restore all the arrangements (e.g. put back alternatives, etc.)? | 23:00 |
| cjwatson | persia: yes. postinst abort-remove MUST do that. | 23:00 |
| persia | OK. This makes sense. | 23:01 |
| cjwatson | superm1: the first field is desired state, so that's fine | 23:01 |
| cjwatson | Ian admitted to me once that it was a mistake to have that in /var/lib/dpkg/status along with the actual state - it was basically there for dselect | 23:02 |
| cjwatson | kirkland: so, to summarise, exiting in 'prerm remove' is the right answer and you should do it. | 23:02 |
| kirkland | cjwatson: :-) okay, i'll take care of it | 23:02 |
| cjwatson | kirkland: you should do it as early as possible in 'prerm remove' before cleaning up anything else (if applicable). If you do it after something else, make sure that 'postinst abort-remove' undoes it. | 23:03 |
| kirkland | k | 23:03 |
| cjwatson | Ian said something relatively recently that I hadn't realised: the maintainer script calls are generally arranged so that you often don't need to check the first argument | 23:04 |
| cjwatson | i.e. the transition from "prerm remove failed, rollback" to "installed" should involve basically the same code as the transition from "unpacked" to "installed" | 23:05 |
| cjwatson | persia: just to be clear, I wasn't suggesting a change in dpkg behaviour, only clearer documentation of it | 23:05 |
| persia | Right. I missed understanding of postinst abort-remove, and thought that the apparent indecision was due to the possibility of failure in prerm remove, rather than the possibility of failure when restoring things in postinst abort-remove. | 23:07 |
| persia | Clarification to indicate that the selection of "Installed" or "Failed-Config" depends on the return of postinst-abort-remove would probably be of benefit. | 23:07 |
| cjwatson | on a second reading the language is precise, but it does take at least two readings :-) | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
