[03:25] <superm1> at some point did things switch around so that ubiquity doesn't run the whole process as root?
[03:26] <evand> yes
[03:27] <evand> sorry, I should've told you that
[03:27] <superm1> whew that's not good, a lot of my scripts broke
[03:27] <evand> my apologies
[03:27] <superm1> hopefully not a big deal..
[03:27] <evand> well going forward you can control what gets run as root and what doesn't
[03:28] <evand> obviously some things need to run as root
[03:28] <superm1> were these very recent commits (i'll look over the history to see what you adjusted for items)
[03:28] <evand> I'll get you the exact revno
[03:29] <evand> bzr diff -r2464..2465 | vim -
[03:29] <evand> should give you most of it
[03:29] <evand> there was one or two changes after that
[03:30] <superm1> okay great thanks, i'll let you know if i have some difficulties switching things around
[03:30] <evand> yeah, please do
[03:30] <evand> best of luck
[03:30] <superm1> thx
[04:02] <CIA-44> ubiquity: superm1 * r2481 ubiquity/ (debian/changelog ubiquity/frontend/mythbuntu_ui.py): adjust permissions before/after launching external applications from ubiquity
[04:03] <superm1> luckily very easy fix :)
[04:03] <evand> yay
[05:50] <evand> cjwatson_: if you have a free moment today, can you take a look at the current state of ubiquity-dm?  I'm not entirely confident in the approach and I'd like the reassurance of a trained eye.
[05:50] <evand> and yay, CIA is down
[05:50]  * evand kicks CIA-44
[05:50] <CIA-44> ow
[06:02] <superm1> evand, you weren't really consistent with spacing in ubiquity-dm changes.  i'm making a few other changes to that file right now, i'll clean those up for you
[06:04] <evand> oh?  Thanks
[06:11] <CIA-44> ubiquity: superm1 * r2483 ubiquity/ (4 files in 2 dirs): add mythbuntu to list of possible frontends to look for upon ubiquity startup
[06:11] <CIA-44> ubiquity: superm1 * r2484 ubiquity/ (bin/ubiquity-wrapper debian/changelog): check for jockey-gtk instead of restricted-manager
[10:39] <xivulon> If anyone would like to help review the english text in wubi/umenu please see the following 2 files:
[10:39] <xivulon> http://bazaar.launchpad.net/~ubuntu-installer/wubi/hardy/annotate/agostino.russo%40gmail.com-20080225023058-shsf3oawibio0nxt?file_id=english.nsh-20070529205356-9mvslu0v3aodhtoy-1
[10:40] <xivulon> http://bazaar.launchpad.net/~ubuntu-installer/umenu/devel/annotate/evand%40ubuntu.com-20080220141346-5prmrb6va03jdtw1?file_id=english.nsh-20080212233008-kvy2sm0usmkk5nf3-18
[10:40] <xivulon> shouldn't take more than 5m
[12:15] <CIA-24> installation-guide: cjwatson * r409 ubuntu/ (656 files in 174 dirs): merge from Debian 20080211
[12:18] <CIA-24> installation-guide: cjwatson * r410 ubuntu/en/appendix/chroot-install.xml: adjust chroot-install for Ubuntu sources.list
[12:40] <CIA-24> installation-guide: cjwatson * r411 ubuntu/ (10 files in 5 dirs):
[12:40] <CIA-24> installation-guide: * Bump kernelversion to 2.6.24.
[12:40] <CIA-24> installation-guide: * Bump GNOME version to 2.22.
[12:40] <CIA-24> installation-guide: * Bump release version and names for Hardy.
[12:57] <CIA-24> installation-guide: cjwatson * r412 ubuntu/debian/changelog: releasing version 20080211ubuntu1
[13:11] <xivulon> cjwatson, evand, is there any interest in having lupin-casper ported to the alternate ISO?
[13:11] <xivulon> That would be mostly to support loopinstallations for distros that do not come with a live CD.
[13:12] <xivulon> If that is something you would like to see, I'd be glad to work on an implementation.
[13:32] <cjwatson> xivulon: well, I did partman-auto-loop as a udeb for a reason; but there's no rush for hardy, I think there are probably more important things to work on for that
[13:33] <cjwatson> speaking of which
[13:33] <cjwatson> evand: I diagnosed bug 188492 - comment in the bug
[13:33] <ubotu> Launchpad bug 188492 in ubiquity "console-setup/layoutcode settings are ignored" [Medium,Confirmed] https://launchpad.net/bugs/188492
[13:48] <xivulon> cjwatson, I was thinking of doing it using a udeb anyway, when you say that there is no rush for hardy, do you mean we should target hardy+1?
[13:49] <xivulon> for me too is a low priority, I have a few crashes to debug first...
[13:49] <xivulon> thanks for 188492 by the way
[13:51] <cjwatson> xivulon: that's what I meant, yes
[13:52] <cjwatson> I want the hardy installer to be really stable and don't want to rush many more features into it
[13:52] <xivulon> np
[13:59] <CIA-24> ubiquity: jriddell * r2486 trunk/debian/changelog: set me in changelog
[14:02] <evand> cjwatson: oh wow, whoops.  Thanks for catching that.
[14:03] <evand> cjwatson: did you happen to see my comments earlier in the day about ubiquity-dm?
[14:04] <cjwatson> evand: yeah, I wasn't sure exactly what was bothering you though?
[14:05] <evand> running X as root still.  I'm not sure if there are any side-effects of that.
[14:05] <cjwatson> you pretty much have to, surely
[14:05] <cjwatson> I think that's fine
[14:05] <evand> oh?
[14:05] <evand> ok, works for me
[14:05] <cjwatson> direct hardware access ...
[14:06] <cjwatson> the one thing that jumps out at me is chmodding the dm log file to 666
[14:06] <cjwatson> what's with that?
[14:06] <evand> ah, right
[14:06] <cjwatson> oh, and strictly we should fish HOME out of getpwnam too, although IIRC ubiquity has the same buglet in other places too
[14:07] <evand> and chmodding 666 so that "ubuntu" can write to it.
[14:07] <cjwatson> as a style point I would prefer 'import pwd' and 'pwd.getpwnam' just to make it clear where that function is coming from
[14:08] <cjwatson> chmod> shouldn't be necessary if you pass the fd around; it opens it with elevated privileges, doesn't it?
[14:08] <cjwatson> you can be handed an fd by root that you wouldn't be able to create yourself
[14:08] <cjwatson> the file mode just governs new opens
[14:08] <evand> I thought that was the case, but my testing seemed to prove otherwise
[14:08] <evand> I'll take another look
[14:09] <cjwatson> something else going wrong then, I guess
[14:09] <cjwatson> not a big deal under the circumstances, just jumped out
[14:11] <xivulon> evand re english^
[14:12] <cjwatson> whoa, how did the code behind bug 194688 ever work?
[14:12] <ubotu> Bug 194688 on http://launchpad.net/bugs/194688 is private
[14:13] <evand> uhh odd. I know I've seen it work for me.
[14:13] <cjwatson> it's only the popup menu that's broken
[14:13] <cjwatson> it passes two extra user parameters that on_partition_list_edit_activate doesn't expect
[14:13] <cjwatson> ah
[14:13] <cjwatson> r2452 broke it
[14:14] <cjwatson> I think you forgot to update the popup menu code too?
[14:15] <evand> hrmm
[14:15] <cjwatson> though he says later on in the report that he actually meant to report a different bug he also encountered
[14:15] <evand> ah looks like it, but how on earth did I not run into that in UI testing.  argh.
[14:17] <cjwatson> two different ways to do it ...
[14:18] <evand> ah
[14:18] <evand> yikes, so far not a great morning
[14:20] <cjwatson> plenty of time before the next alpha ;-)
[14:21] <evand> heh, that's one way of looking at it
[14:21] <evand> xivulon: can you elaborate?
[14:21] <evand> oh nevermind
[14:21] <xivulon> I mentioned the 2 english files that would need to be reviewed as we discussed earlier, no rush whatsoever
[14:22] <evand> indeed, I didn't see that at first
[14:26] <evand> I'll take a look after I fix the above mess.
[14:29] <cjwatson> evand: is bug 77966 handled by your fix for bug 48355? IIRC your solution was fairly general in the end and covered both
[14:29] <ubotu> Launchpad bug 77966 in ubiquity "MASTER: Should warn about insufficient disk space (manual partitioning)" [Medium,Confirmed] https://launchpad.net/bugs/77966
[14:29] <ubotu> Launchpad bug 48355 in ubiquity "MASTER: partitioner should warn about too small disk while autopartitioning (some_device)" [Medium,Fix released] https://launchpad.net/bugs/48355
[14:30] <evand> that would cover resizing as well, right?
[14:33] <cjwatson> eventually, though the resize might well fail first
[14:35] <evand> I figured, though never looked, that commit.d is run in all cases, but I'm pretty sure I fed partman a partition size that was too small using the resize widget and it let me go through.
[14:38] <cjwatson> it isn't run at resizing time; it would be run later when you actually try to finish off the partitioner
[14:38] <cjwatson> CIA is slow today
[14:38] <evand> better than last night when it didn't work at all
[14:38] <evand> right, but I'm saying I got all the way through to an ENOSPC on that one, I think.
[14:39] <evand> I should probably test again to be sure.
[15:13] <CIA-24> ubiquity: evand * r2489 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[15:13] <CIA-24> ubiquity: * Update partman_popup with respect to other recent changes (LP:
[15:13] <CIA-24> ubiquity:  #194688).
[15:14] <evand> welcome back, CIA-24
[15:16] <CIA-24> ubiquity: evand * r2490 ubiquity/debian/changelog: Whoops, make sure launchpad-bugs-fixed picks up the previous revno.
[15:27] <CIA-24> ubiquity: evand * r2492 ubiquity/ (debian/changelog ubiquity/components/console_setup.py):
[15:27] <CIA-24> ubiquity: * Regain root when moving /etc/default/console-setup out of the way
[15:27] <CIA-24> ubiquity:  (LP: #188492).
[15:28] <cjwatson> does CIA just not like me?
[15:29] <cjwatson> ah, it would help if I set cia-project
[15:29] <cjwatson> I was switching over to a bzr repository and it got lost along the way
[15:29] <evand> :)
[15:29] <CIA-24> ubiquity: evand * r2493 ubiquity/debian/changelog: Credit where credit is due.
[15:29] <CIA-24> ubiquity: cjwatson * r2487 ubiquity/ (debian/changelog partman/check.d/03partition_too_small):
[15:29] <CIA-24> ubiquity: * Slight shell efficiency improvement in
[15:29] <CIA-24> ubiquity:  partman/check.d/03partition_too_small.
[15:29] <CIA-24> ubiquity: cjwatson * r2488 ubiquity/ (configure configure.ac): bump to 1.7.12
[15:29] <CIA-24> ubiquity: cjwatson * r2491 ubiquity/ (37 files in 10 dirs):
[15:29] <CIA-24> ubiquity: * Use 'autoreconf -fi' so that Autotools files reliably get upgraded.
[15:29] <CIA-24> ubiquity: * Upgrade to gettext 0.17.
[15:29] <cjwatson> there you go
[15:30] <evand> thanks!
[15:45] <evand> xivulon: "Reboot into a new world..." sounds too evangelistic.  Perhaps somewhat replicate the text from the button, "Try or install Ubuntu"?
[15:45] <evand> Of course that suffers from the same problem that a few of the other strings have, that is explicitly naming the distribution.
[15:47] <xivulon> ahah loved that sentence
[15:51] <xivulon> I can name the disto by the way using a variable, at that stage I'd know the distro name anyway
[15:51] <evand> Doesn't that get you in trouble with translations?
[15:51] <xivulon> "Reboot and try ?buntu..."
[15:51] <xivulon> Should be ok
[15:52] <xivulon> If you look into wubi english.nsh there are a few $xxx variables within translation strings
[15:52] <xivulon> I will put a note not to translate $stuff
[16:00] <evand> I'd also change "booter" to "boot helper"
[16:01] <xivulon> evan pull both and feel free to change the text directly
[16:01] <evand> Access doesn't seem right, but I face the same problem when you asked me that originally.  I cannot think of a word for acessibility that fits in such a small space.  How many characters is the maximum for a button again?
[16:01] <evand> ok
[16:03] <xivulon> I will see if I can make the button larger, not sure about that.
[16:04] <evand> assistive would probably be better if you can fit it.  Though I wont make the change until we have confirmation of that.
[16:06] <xivulon> user32::SetWindowPos might do the trick
[17:04] <CIA-24> ubiquity: evand * r2494 ubiquity/ (bin/ubiquity-dm debian/changelog): * Minor changes to ubiquity-dm from suggestions by Colin Watson.
[17:40] <xivulon> evand got a log from the amd64 user
[17:40] <xivulon> http://ubuntuforums.org/showpost.php?p=4402468&postcount=6
[17:41] <xivulon> does not look to me like it is the same issue (freeze around console-setup), but the error is strange:
[17:42] <xivulon> 1) no swap (not sure why, does that cause a failure-command by the way?)
[17:42] <xivulon> 2) I/O error, dev fd0 (not sure if that is very relevant)
[17:46] <xivulon> 3) unsupported locale setting (LANG=en_US)?
[17:47]  * xivulon likes failure-commands
[17:48] <xivulon> ...would be even better if we could split out non critical warnings though...
[17:50] <xivulon> "interactive" warnings that is
[17:50] <CIA-24> ubiquity: evand * r2495 ubiquity/ (debian/changelog desktop/ubiquity-gtkui.desktop.in): * Remove suffix from icon path in .desktop file (LP: #188221).
[17:50] <evand> hooray for omni-completion.  Thanks for hacking that up, cjwatson.
[17:52] <xivulon> evand I was thinking that ubiquity should have 3 modes: interactive, automatic, semi-automatic.
[17:53] <xivulon> the last if for wubi type installation where the user is not supposed to answer any question, but he might be shown a failure message.
[17:53] <xivulon> after the failure message we can still trigger a failure-command
[17:58] <evand> 1) because it's asking a question.  As I explained in a post on ubuntuforums, we had intended to split failure_command into a complete failure and an "automation failure" (when ubiquity requires human interaction for something)
[17:58] <evand> You can avoid this question by preseeding it away.
[17:59] <evand> we had intended> I had intended to do it at the start of the Hardy cycle, but I completely forgot.  It's fairly straightforward and I've added it to my todo list.
[18:00] <evand> 2) No, don't worry about that.
[18:00] <evand> oh, I missed that comma.
[18:00] <evand> So yes, it does cause a failure_command.
[18:02] <evand> back to 1) now that I've reread it
[18:02] <evand> debconf (developer): <-- GET partman-auto-loop/recipe
[18:02] <evand> debconf (developer): --> 0     /ubuntu/disks/root.disk 3000 30001 30001 ext3 method{ format } format{ } use_filesystem{ } filesystem{ ext3 } mountpoint{ / } .
[18:02] <evand> so it looks like you're not preseeding swap creation in that case.
[18:03] <evand> really not sure why, as I imagine that's always done in your code, not just sometimes.
[18:05] <evand> 3) that should be en_US.UTF-8
[18:05] <evand> oh hrm
[18:05] <evand> you do set it as that
[18:08] <xivulon> hmm really strange, that should be in the preseed file
[18:08] <xivulon> Maybe it would help to copy preseed.cfg config.dat (other?) in the failure-command zip file.
[18:08] <xivulon> I mean swap recipe
[18:09] <evand> preseed.cfg> That would end up pulling in their password.
[18:09] <xivulon> 3) Isn't the preseeding supposeed to be "locale en_US"?
[18:09] <xivulon> might sed the password out
[18:10] <xivulon> would that be in config.dat too?
[18:10] <evand> no, it wouldn't
[18:10] <evand> but I don't really see the need
[18:10] <xivulon> of config.dat?
[18:10] <evand> indeed
[18:10] <xivulon> I'll add a sedded preseed then
[18:11] <evand> well, I don't see the need of either of them
[18:11] <evand> you already have debug enabled
[18:11] <xivulon> yes
[18:11] <xivulon> but in the case above how would I know the exact recipe string?
[18:12] <cjwatson> evand: you're welcome
[18:12] <evand> You'd look in debug, just as I did
[18:12] <cjwatson> preseeding should be en_US.UTF-8 not en_US
[18:13] <xivulon> evand does that contain the original "raw" string?
[18:13] <evand> Did we stop writing passwords to the debug output at some point?
[18:13] <cjwatson> no
[18:14] <xivulon> cjwatson is the locale going to be *.UTF-8 for all languages?
[18:14] <cjwatson> xivulon: unfortunately not quite. You need to know the actual locale from /usr/share/i18n/SUPPORTED not just make it up
[18:14] <evand> curious, I don't see the user's password in this debug log, and I doubt he stripped it out
[18:14] <cjwatson> I'd suggest incorporating that file in your build process somehow
[18:15] <xivulon> will do
[18:15] <evand> and xivulon doesn't appear to be sed'ing the passwords out of the debug log before zipping, as far as I can tell
[18:15] <evand> ah duh
[18:15] <evand> because it didn't get that far
[18:15] <evand> ok yikes, so using debug is probably a bad idea
[18:16] <evand> we've talked about enabling this by default before
[18:16] <xivulon> evand I don't sed anything at the moment, just zip the whole /var/log
[18:16] <evand> but the situation is even worse for wubi
[18:16] <evand> because there's no bold text warning them that their password will be in the logs
[18:16] <cjwatson> right, debug mode definitely isn't appropriate for any kind of default
[18:17] <xivulon> let me know if I need to exclude / sed any file in failure-command
[18:18] <evand> I think you should not use debug mode by default and add a command line option to wubi that enables it.
[18:18] <evand> that still doesn't address the lack of a warning in the UI that their password is going to be in the logs
[18:20] <xivulon> cjwatson I am looking at SUPPORTED, for US I have en_US.UTF-8, en_US, and en_US.ISO-8859-15
[18:20] <cjwatson> use the one with 'UTF-8' in the second column
[18:20] <xivulon> evand you mean for failure-command?
[18:21] <xivulon> or in general
[18:21] <xivulon> re pwd in the logs, isn't it possible to simply sed it out?
[18:22] <cjwatson> you could if you're careful. I did ask about including a patch to debconf that makes it never be included, but Joey noted (rightly) that it was fundamentally utterly awful
[18:22] <evand> I don't think so.  The text could change and you'd end up missing the password.
[18:23] <cjwatson> we have had very high-profile installer vulnerabilities before regarding leaked passwords, and it deserves the highest possible level of care
[18:23] <cjwatson> you don't get away with this sort of thing a second time
[18:24] <xivulon> I remember that news
[18:26] <xivulon> do all language have a second column with UTF-8? I also noticed that some lanugages have multiple @ variants all with UTF-8
[18:27] <xivulon> what shall I do with the log? is an (english) warning sufficient?
[18:28] <xivulon> I will copy the log only if the user selects debug mode at boot
[18:34] <xivulon> re (ubiquity) debug, that is not really enabled by default
[18:34] <xivulon> the user has to hit esc and select verbose mode
[18:34] <evand> oh?
[18:34] <evand> ah, I had no idea
[18:34] <xivulon> is that good enough (+pwd warning)?
[18:35] <evand> yeah, I think if you can fit it, a password warning would be great
[18:35] <evand> "(password included in logs)" perhaps
[18:35] <xivulon> hmm that should be localized too... bugger
[18:36] <xivulon> the password is only in /var/log/installer/debug, correct?
[18:36] <cjwatson> all languages should have a UTF-8-encoded locale; if they don't you can safely ignore them
[18:36] <cjwatson> for ones with multiple variants containing @ or . there should be one without those modifiers and you should use that
[18:36] <cjwatson> ca_ES.UTF-8@valencia is the only one I can think of offhand
[18:36] <xivulon> cjwatson thanks, will do that
[18:36] <cjwatson> oh, I see there are a few others
[18:37] <xivulon> yes
[18:37] <cjwatson> but yeah, looking through them, it's fine to just use the unmodified version; I suspect Windows does not have much in the way of Valencian support anyway and I don't think d-i does either
[18:38] <xivulon> by the way I'd need a mapping of windows registry keys to keyboard variants
[18:38] <xivulon> I have the code to use that info, and dvorak in as an example
[18:38] <xivulon> but not sure where to grab such mappings
[18:38] <cjwatson> I think somebody might have to invent them
[18:40] <xivulon> There is an hkl value in the registry, for instance 0x00010409=dvorak
[18:40] <xivulon> but do not know how to get the others
[18:43] <xivulon> ah http://softserv.murdoch.edu.au/pub/mswin/Citrix/Citrix4.21.779/MODULE.SRC
[18:58] <xivulon> there is also the issue of preseed.cfg
[18:58] <xivulon> that countains the pwd
[18:59] <xivulon> now it gets deleted upon successful installation
[18:59] <xivulon> but not upon unsuccessful installation
[18:59] <xivulon> should probably comment that in failure command too?
[19:02] <CIA-24> ubiquity: jriddell * r2496 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py): Fix QApplication args in ubiquity/frontend/kde_ui.py
[19:30] <bdmurray> evand: I'm planning on adding some bugs to the DebuggingUbiquity Known issues section and possibly try to make the page look more like the DebuggingTemplate page.  Does that sound alright to you?
[19:32] <evand> bdmurray: works for me, thanks for doing it
[19:32] <xivulon> evand what's your take on preseed.cfg password? ^
[19:36] <evand> hrm, yeah, I'd do what you can to strip it out in that event
[19:39] <xivulon> hmm the issue is that in many case the user will try to reboot and select "Ubuntu" to redo the installation if something goes wrong
[19:39] <xivulon> if I strip out stuff from preseed.cfg, then the user will need to start windows and reinstall again to regenerate a new preseed.cfg
[19:39] <evand> hrmm, indeed.
[19:40] <xivulon> preseed.cfg will be deleted on successfull wubi installation and of curse whenever wubi is uninstalled
[19:40] <xivulon> the problem are is if wubi installation fails and the user just keeps it around
[19:40] <evand> I guess we don't have any other option but to leave it in on a failed install then.
[19:41] <xivulon> I could add a note in failure-command, but if the error happens before (grub4dos / initrd) the user will not see that
[19:42] <evand> unless I split failure_command into failure_command and automation_failure_command.  Then stripping the password out and showing the user-setup page wouldn't be an issue.
[19:42] <evand> It'd be ugly though, as they wouldn't be expecting that.
[19:43] <xivulon> you mean asking for username/password in ubiquity as opposed in wubi?
[19:43] <evand> right
[19:43] <evand> I'm not too keen on the idea though
[19:43] <evand> don't get me wrong, I'd like to split failure_command
[19:43] <xivulon> pros and cons, might be a bit late for that though
[19:44] <evand> all it would take would be splitting failure_command.  ubiquity already handles showing a page when you haven't adequately answered all of the questions.
[19:45] <evand> I think we're fine with our current approach though, at least for the time being.
[19:45] <xivulon> I asked cjwatson whether we should ask for username/pwd in ubiquity and he rejected the idea.
[19:45] <xivulon> I guess also because it would look akward to have to go through 2 installer interfaces
[19:46] <xivulon> But on the other side, that would make wubi a true 1 click installer, and I like that!
[19:46] <evand> indeed, mind you only in the case where the install failed once, but still like I said, I'm not keen on the idea.
[19:46] <xivulon> ah I see
[19:46] <xivulon> Hmm I'd say either we do it always or never
[19:47] <evand> I vote for never
[19:48] <evand> wait a minute
[19:48] <evand> don't you use MD5 hashes anyway?
[19:48] <xivulon> yes
[19:49] <evand> so then I'm confused
[19:49] <xivulon> by what?
[19:49] <evand> how is the password exposed in preseed.cfg?
[19:49] <xivulon> in hashed form
[19:50] <xivulon> so the fact that preseed stays around on failure is half damage
[19:51] <evand> half damage?
[19:51] <evand> I don't think there's anything to worry about if you're using user-password-crypted.
[20:01] <cjwatson> what are the permissions on preseed.cfg?
[20:02] <CIA-24> debian-installer-utils: evand * r650 ubuntu/ (debian/changelog update-dev):
[20:02] <CIA-24> debian-installer-utils: * Avoid sound events as they will trigger audio to be played on every
[20:02] <CIA-24> debian-installer-utils:  call to udevtrigger; udevsettle (LP: #178057).
[20:05] <xivulon> cjwatson do you mean on the windows side? I think anyone can read it
[20:05] <cjwatson> can it be given stricter NTFS permissions somehow?
[20:06] <xivulon> can try that
[20:06] <xivulon> not that I think that will limit an attacker ability to access it anyway...
[20:08] <cjwatson> right, but if they have sufficient access on the Windows side they can do whatever they want anyway
[20:08] <cjwatson> what I want to avoid is the file being left around such that unprivileged users created on the Ubuntu side can read it
[20:09] <cjwatson> but if it's only on failed installs anyway, it's not a big deal
[20:09] <xivulon> yeah I'd skip that if possible it would involve adding an ACL plugin just for that
[20:17] <CIA-24> debian-installer-utils: evand * r651 ubuntu/debian/changelog: releasing version 1.50ubuntu2
[20:26] <bdmurray> evand: are there test cases documented for testing Wubi?  Actually is it testable yet?
[20:27] <evand> bdmurray: It is testable, there are no documented test cases yet.
[20:28] <evand> umenu should also replace WinFOSS testing
[20:29] <bdmurray> In the test lists at iso.qa.ubuntu.com?
[20:29] <evand> yes, WinFOSS is no longer used.
[20:30] <evand> I'll add Testing/Cases/umenu and Testing/Cases/Wubi pages to the wiki if you'd like.
[20:31] <bdmurray> evand: that'd be great and I'll get them added to the iso testing tracker
[20:32] <xivulon> how do those tests work? can I help on my side?
[20:32] <bdmurray> Is that arch specific at all?
[20:32] <evand> sure
[20:32] <evand> amd64 and i386
[20:33] <evand> works on both kubuntu and ubuntu (edubuntu is now an add on CD)
[20:34] <evand> xivulon: The test cases are linked from http://iso.qa.ubuntu.com . bdmurray can talk to stgraber to get them added.  The tests themselves are on the wiki
[20:34] <evand> https://wiki.ubuntu.com/Testing/Cases
[20:34]  * xivulon reading
[20:35] <stgraber> evand: I'll need to rework the testcases list anyway, so just put a list of what's wanted on the wiki Testing/TrackerUpdate (or something similar) or e-mail me
[20:35] <xivulon> ah those are human tests
[20:35] <stgraber> (following the Edubuntu changes and LTSP being now part of Ubuntu Alternate)
[20:35] <xivulon> re Edubuntu I do have it in the wubi list of desktops
[20:35] <evand> stgraber: ah, I had no idea you were in here :).  Will do.
[20:36] <xivulon> is it available as a Live ISO so that it can be targeted by wubi?
[20:37] <xivulon> I mean I can see: http://cdimage.ubuntu.com/edubuntu/daily-live/current/
[20:38] <xivulon> and http://cdimage.ubuntu.com/edubuntu/releases/8.04/alpha-5/
[20:39] <xivulon> first link seems to indicate a full ISO, second link an addon
[20:40] <evand> I'm not sure how long cdimage will continue to generate full live CD images.
[20:40] <xivulon> ah pls let me know, in case we have to take it out of wubi
[20:41] <xivulon> I hope they'll keep doing full CDs of course
[20:46] <stgraber> well, the live CD for edubuntu isn't that usefull as we don't have enough place on it to put the educational softwares
[20:47] <stgraber> and it ends up being just an ubuntu with a different artwork
[20:47] <stgraber> the add-on CD contains all the educational stuff and is then installed on a standard Ubuntu
[20:47] <stgraber> so if we wanted to install everything out of the box we would need ~900MB on the LiveCD (as the add-on contains ~200MB of usefull stuff at the moment)
[20:48] <xivulon> stgraber: 900MB would not be an issue for wubi since no CD is burnt ;)
[20:48] <xivulon> but of course that would be too much of a special case I guess
[20:49] <evand> 15:45:28 < slangasek> my understanding was that edubuntu desktop would remain a discrete image, only server was being  rearranged into an ubuntu-server adjunct?
[20:49] <xivulon> so my understanding is that it will be around but not too usueful because of lack of packages
[20:49] <stgraber> yes, we'll keep edubuntu desktop, it'll just be as usefull as it was in Gutsy
[20:50] <xivulon> my point is that someone uses wubi to demo edubuntu might get the wrong impression since it won't be fully loaded
[20:50] <evand> 15:50:06 < slangasek> evand: that's my understanding; plans may have changed when I wasn't looking
[20:51] <evand> gotcha
[20:51] <xivulon> for me it's fairly easy to add/remove distros, and I am not binded by ISO size restrictions, just let me know what you want to have in!
[20:53] <evand> I'll let stgraber and the rest of the edubuntu people speak for their distribution and needs.
[20:53] <evand> and its*
[20:53] <xivulon> absolutely, stgraber, let me know what you decide
[20:53] <evand> and then I can flip the necessary bits on cdimage, if any changes are needed
[20:54] <stgraber> xivulon: we have a meeting this wednesday at 12:00 UTC. I'll ask here (you can also attend it depending on your timezone)
[20:55] <xivulon> I'll try to.
[20:55] <xivulon> as mentioned, 900MB ISO, is still an option as far as wubi go
[21:32] <bdmurray> evand: was bug 48355 fixed in dapper updates or just Hardy?
[21:32] <ubotu> Launchpad bug 48355 in ubiquity "MASTER: partitioner should warn about too small disk while autopartitioning (some_device)" [Medium,Fix released] https://launchpad.net/bugs/48355
[21:32] <evand> hardy
[21:32] <bdmurray> That's weird the comment on the wiki pages says it was fixed in 6.06.1
[21:33] <evand> perhaps a different bug?  Or does it explicitly reference that bug number?
[21:34] <bdmurray> That number explicity, I'll change it though.
[22:22] <cjwatson> evand: do you know what happened to the notes from the USB stick production thing we discussed at UDS?
[22:23] <cjwatson> xivulon: we've already stopped doing full Edubuntu CDs; the desktop is just an accidental hangover that nobody has got round to disabling yet, AFAIK
[22:23] <cjwatson> bdmurray: we probably ameliorated it in 6.06.1
[22:25] <xivulon> cjwatson, I cannot do multiple ISO installations at this stage, if edubuntu is to be added the only option is to have a 900MB ISO
[22:25] <evand> cjwatson: I'll look through my laptop for it.
[22:25] <evand> xivulon: you wouldn't have to.  They install Ubuntu using wubi, then use the edubuntu addon CD.
[22:26] <xivulon> yeah that would be good enough
[22:26] <cjwatson> bdmurray: I seem to have added that text deliberately but it was a long time ago
[22:26] <xivulon> I will remove edubuntu then
[22:26] <cjwatson> evand: ta
[22:26] <cjwatson> the gobby notes may be available from IS if need be
[22:26] <xivulon> re USB stick, I have vague memories and remember that Wubi was involved somehow
[22:26] <xivulon> can you remind me briefly what was the objective?
[22:27]  * cjwatson -> bed, sorry, wife will be annoyed otherwise :)
[22:27] <cjwatson> another day
[22:27] <cjwatson> (it's not urgent)
[22:27] <xivulon> sure
[22:27] <xivulon> I'll be glad to hack something together anyway
[22:29] <xivulon> I'll wait wednesday meeting before removing edubuntu from wubi, I guess there is no rush
[22:34] <xivulon> cjwatson quick q
[22:34] <xivulon> might be good to use low swappiness as well?


[00:20] <keithzg> Yeesh, I guess I'm done buying ASUS motherboards ever. Got a response from their customer service and the only way to patch the Intel ME vulnerability is indeed to run the updater which only works on Windows.
[00:22] <sarnold> what is it with firmware / hardware people..
[00:24] <sdeziel> not even providing a bootable ISO with something like freedos is really bad
[00:43] <keithzg> Yeah, I mean frankly anything involving updating firmware on a motherboard you'd think you'd want to be able to do without relying on an installed OS!
[00:45] <metastable> I enjoy my MSI boards for that reason. Insert stick, push button. BIOS flash, even from soft-brick.
[00:58] <keithzg> metastable: To be fair though, the Intel Management Engine is an additional, somewhat self-contained entity with its own firmware, so the ease of flashing "BIOS" isn't necessarily an indicator that they'd get *this* right. I tried checking MSI's support pages to check how they've been handling Intel ME updates but I keep getting 504 errors from nginx on their servers . . .
[01:03] <keithzg> Hmm from what little information MSI provides on https://www.msi.com/news/detail/tbzkKfKPAi1ALASqaWkS99rxLH-FNw7O9AC8b2jsPHSoz1kSuAag52YLmCGiuuD9LhFJ7_wgczjFmbrnR5UGCA~~ it seems like they might also require you to run Windows to update the Intel Management Engine.
[01:23] <cncr04s> anyway to have mdadm scrub a raid array to look for inconsitencies ?
[01:31] <Sling> cncr04s: thats what you'd have raid 1 or raid 5 for
[01:31] <Sling> what kind of inconsistencies ar eyou expecting?
[02:26] <metastable> Ew. RAID 5...
[02:26] <metastable> cncr04s: echo check > /sys/block/mdX/md/sync_action
[02:27] <metastable> cncr04s: Where 'mdX' is the md device number of the mdadm array. Check /proc/mdstat for this.
[05:05] <cncr04s> i have a raid5 and a raid 6 array
[06:35] <cpaelzer> good morning
[06:44] <lordievader> Good morning
[06:46] <cpaelzer> hiho lordievader
[06:48] <lordievader> Hey cpaelzer
[06:48] <lordievader> How are you doing?
[07:04] <cpaelzer> lordievader: good, you as well I'd hope
[07:04] <lordievader> Yes, doing allright.
[07:04] <cpaelzer> great
[07:05] <lordievader> My zabbix experiments seem to pay off somewhat.
[07:05] <lordievader> We want to create some triggers wich compare the data of today with yesterday.
[07:05] <lordievader> So I build a graph which does that.
[10:54] <gun1x> guys, quick question
[10:54] <gun1x> just got an ubuntu server up on an infra that i do now own
[10:55] <gun1x> and i have something strange in terminal ... i get some strange characters
[10:55] <gun1x> does anybody know an apt command to install missing packages so i have all characters ?
[10:59] <Frickelpit> what do you mean by "strange characters"? did you check your locales settings?
[17:01] <add1ctus> I was enabling firewall on my server. Just added all the ports I need (22, 80, 443) to allowed list and did ufw enable. Everything else had default settings. Since then connections slowed down towards the server, and I disabled it immediately. But connections are still slow, and even apachectl status doesn't give any output. Checking with htop, it says server isn't under any load. Anything I could do?
[17:04] <rbasak> Slow how?
[17:04] <rbasak> Could it be reverse DNS timing out?
[17:06] <add1ctus> When I try rapidly checking tracert, every third request gets stuck. The website hosted on the server is also slow (Chrome gets stuck on Connecting..)
[17:09] <sdeziel> add1ctus: I'd make sure ICMP is authorized to have PMTU working
[17:10] <sdeziel> I think ufw allows what's needed by default but I don't know for sure
[17:14] <add1ctus> @sdeziel: I didn't kinda understand what you're trying to say. How should I check that?
[17:16] <sdeziel> add1ctus: A quick way to check this would be to add those 2 rules: sudo iptables -I INPUT -p icmp -j ACCEPT; sudo iptables -I OUTPUT -p icmp -j ACCEPT
[17:24] <rbasak> add1ctus: every third request getting stuck is a Cisco signature IIRC. I'd ignore that.
[18:40] <HackeMate> hello
[18:41] <HackeMate> i have some servers that i need to maintain, so i wanted to use something like teamviewer but for server (it means bypass firewalls)
[18:41] <HackeMate> exists a tool like that in ubuntu, or any way to do that?
[18:42] <HackeMate> both computers connect to a common servers via http port and share data
[19:27] <sdeziel> HackeMate: it's not like teamviewer but you can remote administer servers and transfer files using SSH
[19:31] <HackeMate> yes i know, but i cant pass trought firewalls or vlans
[19:31] <HackeMate> i dont know how teamviewer gets that
[19:37] <sdeziel> I think that teamviewer has the agent phone home to essentially build a HTTPS tunnel. You can then connect to teamviewer servers and access your servers through that.
[19:37] <sdeziel> HackeMate: this feels like a MITM to me so I prefer SSH :)
[19:38] <HackeMate> yes, thats the reason i want use an own method
[19:42] <sdeziel> HackeMate: you have several options. 1) you could tweak the firewall to expose your server's SSH via port forwarding 2) you could setup a VPN that connects to a server you trust 3) you could run tor on the servers to use it as a backchannel to SSH in
[19:42] <sdeziel> HackeMate: and probably a lot more
[21:39] <RoyK> hm - seems I'm getting this when attempting to install ubuntu 16.04 in a kvm/libvirt vm on jessie: Checking installer location failed: Could not find media '/data/iso/Linux/x64/Ubuntu/ubuntu-16.04.3-server-amd64.iso'.
[21:39] <RoyK> any ideas?
[21:42] <TJ-> RoyK: looks like a libvirt issue on the host based on the path
[21:44] <RoyK> TJ-: everything looks right, permissions and so on
[21:51] <TJ-> RoyK: have you refreshed the pool with "virsh pool-refresh default" (assuming it's using the default pool)
[22:06] <RoyK> TJ-: afaik it's not a pool, just "local" file
[22:07] <TJ-> RoyK: right, but the 'pool' should list it for the guest if I recall correctly
[22:17] <ahasenack> RoyK: was that error inside the vm, or in virt-manager?
[22:17] <TJ-> it's a virsh/libvirt error
[22:18] <RoyK> virt-manager - interesting, regardless of file rights, I tried to ln (not -s) the file to where the debian iso was, and that works, meaning it's quite possibly a pool thing - I've never seen that issue before
[22:21] <TJ-> I've seen it in the past, when I manually added an ISO rather than adding it to the pool, and had to refresh the pool for the guest to see it
[22:22] <RoyK> I didn't try to refresh the guest pool, though - I don't know too much about these pools
[22:24] <RoyK> TJ-: anyway - thanks
[22:28] <rbasak> cpaelzer, ahasenack: BTW, mail-stack-delivery is something I've wanted to deprecate for years, but never got round to driving.
[22:28] <ahasenack> rbasak: it seems handy, but I can see how it would be a maintenance burden
[22:29] <rbasak> But it doesn't really cause us any pain except in merges, because I think barely anyone actually uses it
[22:29] <ahasenack> it's in the lts guide
[22:29] <rbasak> Yeah so it's quite a bit of work to deprecate and remove :)
[22:29] <ahasenack> yeah
[22:29] <ahasenack> we just have to remember to update it with what is considered best practices that year :)
[22:30] <ahasenack> smtpd_tls_mandatory_protocols = SSLv3, TLSv1 <-- that isn't, for example
[22:30] <ahasenack> SSLv3
[22:30] <ahasenack> something I'm raising in my review
[22:32] <ahasenack> defaults from postfix:
[22:32] <ahasenack> # postconf -d smtpd_tls_mandatory_protocols
[22:32] <ahasenack> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
[22:33] <ahasenack> maybe we should leave it at the postfix's default instead of hunting down what's bad and what is not
[22:34] <rbasak> I think that's a good idea. Make sure it's matches the postfix's packages default too. Eg. if postfix ships a conffile with an important setting that gets overriden by mail-stack-delivery, that could be a problem.
[22:34] <rbasak> Sort of like you found it as it is now :)
[22:57] <morphine> hi guys, anyone here ever came across a situation where Apache 2.4 just wouldn't log rewrite activity no matter what you set the LogLevel rewrite:trace directive to?
[22:59] <sarnold> morphine: if you deliberately break the configuration in some blatant obvious way do you see that take affect as you expect? (I'm curious if perhaps the file you're editing is being ignored entirely)
[22:59] <morphine> yeah, this configuration is working perfectly and as expected. The context here is that I'm debugging a single rewrite rule
[23:00] <morphine> I went ahead and enabled rewrite logging, and two hours later I'm still trying to figure out why that never shows up on any of the logs
[23:00] <morphine> doesn't seem to be a unique problem, found a couple forum threads about it but no actualy solution
[23:00] <morphine> already tried a million things up to and including defining a vhost that has next to no configuration but the rewrite/log settings
[23:01] <morphine> (and no, I didn't forget to reload/restart Apache :)
[23:01] <sarnold> :)
[23:05] <sarnold> morphine: nothing in the docs stands out :/ it might be worth a bug report
[23:06] <morphine> could be, but it's probably some obtuse and apparently-unrelated setting
[23:06] <morphine> which has been my experience with Apache 2.4 in particular
[23:08] <sarnold> reminds me of the day I lost due to a '/' on the end of a directory name.
[23:11] <ahasenack> morphine: can you see the rule checks progressing until your rule is hit? Or not even that?
[23:11] <ahasenack> (in the debug logs)
[23:11] <ahasenack> I was in that situation a few times, it was always *something*
[23:11] <morphine> that's the whole problem, I don't see the rule logs *anywhere*
[23:12] <ahasenack> did you set LogLevel?
[23:12] <sarnold> are they maybe going to syslog rather than a file? or file rather than syslog?
[23:13] <ahasenack> that's new in 2.4, according to what I'm reading
[23:13] <ahasenack> "Those familiar with earlier versions of mod_rewrite will no doubt be looking for the RewriteLog and RewriteLogLevel directives. This functionality has been completely replaced by the new per-module logging configuration mentioned above."
[23:14] <morphine> yeeeep
[23:14] <morphine> because it made sense before, so it had to change!
[23:14] <morphine> (sorry)
[23:14] <ahasenack> mod_rewrite made sense?
[23:14] <ahasenack> :)
[23:14] <morphine> har
[23:15] <morphine> don't even get me started on the Log/ErrorLogFormat mess
[23:15] <ahasenack> http://httpd.apache.org/docs/current/mod/core.html#loglevel
[23:15] <ahasenack> hope that helps
[23:16] <morphine> I already tried like 10 variations of the LogLevel line (including some obtained from forums/how-tos)
[23:16] <morphine> but I might as well try a couple more
[23:16] <ahasenack> try setting it for other things, see if you get that to work
[23:17] <ahasenack> if not even that changes the logs you are seeing, then something else is going on
[23:17] <ahasenack> gotta go, g'night
[23:20] <morphine> thanks for the input