=== skaet is now known as skaet_afk
=== nevrax is now known as Guest62798
=== skaet_afk is now known as skaet
=== skaet is now known as skaet_
[06:06] <juzzy__> hi
=== skaet_ is now known as skaet_afk
[09:27] <mpt> ev, I think these bugs are fixed in Natty:
[09:27] <mpt> bug 164326
[09:27] <ubot2> Launchpad bug 164326 in ubiquity "ability to use existing partitions to install Ubuntu" [Wishlist,Confirmed] https://launchpad.net/bugs/164326
[09:28] <mpt> bug 131084
[09:28] <ubot2> Launchpad bug 131084 in ubiquity "Partitioning language needs resimplification" [Undecided,Confirmed] https://launchpad.net/bugs/131084
[09:28] <mpt> bug 155185
[09:28] <ubot2> Launchpad bug 155185 in ubiquity "More warning about installation" [Undecided,Confirmed] https://launchpad.net/bugs/155185
[09:29] <ev> mpt: thanks! sorting now
[09:35] <mpt> bug 291677
[09:35] <ubot2> Launchpad bug 291677 in ubiquity "partitioner in installer forgets settings when you go back" [Undecided,Confirmed] https://launchpad.net/bugs/291677
[09:35] <mpt> or maybe not
[09:36] <mpt> (depending on whether it remembers the settings when going back after an error)
[09:38] <mpt> bug 374913, fixed by the new design
[09:38] <ubot2> Launchpad bug 374913 in ubiquity "the graphical partitioner shows complete nonsense" [Undecided,New] https://launchpad.net/bugs/374913
[09:41] <mpt> bug 445053
[09:41] <ubot2> Launchpad bug 445053 in ubiquity "installation is not user friendly" [Undecided,New] https://launchpad.net/bugs/445053
[09:43] <mpt> I think bug 349479 is either fixed, or a duplicate of bug 287620
[09:43] <ubot2> Launchpad bug 349479 in ubiquity "[Jaunty] partitioner doesn't fit on screen with large number of partitions" [Undecided,New] https://launchpad.net/bugs/349479
[09:43] <ubot2> Launchpad bug 287620 in ubiquity "Partition diagrams are far too wide for the default installer window" [Undecided,New] https://launchpad.net/bugs/287620
[09:46] <mpt> I assume bug 549432 is fixed, though I haven't seen it fixed myself yet. :-)
[09:46] <ubot2> Launchpad bug 549432 in ubiquity "Partitioning: unclear option with no reference" [Undecided,Confirmed] https://launchpad.net/bugs/549432
[09:58] <mpt> bug 362588 seems fixed
[09:58] <ubot2> Launchpad bug 362588 in ubiquity "Installer presents confusing/misleading partition information" [Medium,Confirmed] https://launchpad.net/bugs/362588
[10:48] <ev> replied
[12:31] <cjwatson> ev: any thoughts on https://bugs.launchpad.net/bugs/735072?  seems like a fairly fundamental problem with the new hostname selection algorithm
[12:31] <ubot2> Launchpad bug 735072 in ubiquity "The hostname proposed by installer is too long for file sharing to work correctly." [Undecided,New]
[12:31] <cjwatson> see also https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/150959
[13:01]  * cjwatson notices that subprocess.Popen.communicate doesn't retry on EINTR (bug 745014), contemplates Python bindings for libpipeline, and then realises libpipeline doesn't retry on EINTR either ...
[13:01] <ubot2> Launchpad bug 745014 in ubiquity "keyboard-configuration.postinst died with SIGPIPE" [Medium,Confirmed] https://launchpad.net/bugs/745014
[13:01] <cjwatson> still, at least I can fix the latter
[13:03] <ev> cjwatson: sorry, I was off helping the design team with natty screenshots
[13:03] <ev> reading now
[13:05] <ev> are we certain that this is a limit in the specification?
[13:05]  * ev digs
[13:10]  * ev sighs
[13:10] <ev> "This issue occurs because the NetBIOS domain name has a 15-character limitation."
[13:10] <ev> http://support.microsoft.com/kb/226144 http://support.microsoft.com/kb/909264
[13:10] <ev> cjwatson: truncate?
[13:11] <ev> cjwatson: mpt suggested showing a different name for netbios only
[13:11] <ev> so we could generate a stub smb.conf, I suppose
[13:11] <ev> does that sound insane?
[13:18] <cjwatson> I don't know enough about samba
[13:19] <cjwatson> slangasek would be a good person to ask
[13:19] <cjwatson> I wonder if we need to care about network uniqueness in the first n chars
[13:24] <ev> I don't follow on the network uniqueness point, but I've asked slangasek in #ubuntu-devel about truncation
[13:24] <cjwatson> don't we try to make sure that the hostname isn't seen on the network at installation time?
[13:25] <ev> yes
[13:25] <ev> separate from this, but indeed
[13:28] <cjwatson> well, truncation will change the uniqueness properties
[13:28] <ev> ah, good point
[13:28] <ev> I think we'll be okay
[14:00]  * cjwatson contemplates just calling signal.siginterrupt after every call to signal.signal
[14:01] <cjwatson> why oh why doesn't Python just let you set SA_RESTART directly (when available)?
[14:01] <cjwatson> silly language
[14:02] <cjwatson> but wait, we don't even install any signal handlers ourselves
[14:05] <cjwatson> so I don't see where EINTR is coming from, unless Qt installs some signal handlers or something
[14:15] <cjwatson> something is setting SIGCHLD without SA_RESTART in the ubiquity frontend process, so that's a possibility
[14:18] <cjwatson> I blame Qt
[14:20] <ev> generally a good approach
[14:21] <cjwatson> I think it may actually be accurate here :-)
[14:21] <cjwatson> QProcessManager does the thing above
[14:22] <davmor2> cjwatson: could it be you got too used to GTK commands and was spoilt :D
[14:23] <cjwatson> very tempting to have the KDE frontend do signal.siginterrupt(SIGCHLD, False)
[14:29] <cjwatson> Qt *used* to do SA_RESTART, but qt.gitorious.org doesn't go back far enough to show when that was deleted and why
[14:44] <CIA-31> ubiquity: cjwatson * r4626 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py):
[14:44] <CIA-31> ubiquity: * KDE frontend:
[14:44] <CIA-31> ubiquity:  - Force the SIGCHLD handler installed by QProcessManager to use
[14:44] <CIA-31> ubiquity:  SA_RESTART, in the hope of avoiding problems with Python's lack of
[14:44] <CIA-31> ubiquity:  EINTR-safety (LP: #745014).
[14:49] <CIA-31> ubiquity: cjwatson * r4627 trunk/ (2 files in 2 dirs):
[14:49] <CIA-31> ubiquity: Show ext2 and btrfs in the same colour as ext3 and ext4, rather than
[14:49] <CIA-31> ubiquity: in the same colour as free space.
[14:57] <ev> cjwatson: incidentally, I thought python handled eintr in subprocess now? http://hg.python.org/cpython/rev/6e664bcc958d/
[15:02] <cjwatson> not sufficiently
[15:02] <cjwatson> they only fixed part of the problem
[15:02] <ev> perhaps it's worth replying to http://bugs.python.org/issue1068268 then?
[15:03] <cjwatson> somebody already sent a patch that fixed the bits that matter and they ignored it
[15:03] <cjwatson> and there's another open python bug for fixing things further down the stack
[15:03] <ev> I don't suppose you have a link to this?
[15:04] <cjwatson> yes, I put my research in bug 745014
[15:04] <ubot2> Launchpad bug 745014 in ubiquity "keyboard-configuration.postinst died with SIGPIPE" [Medium,Fix committed] https://launchpad.net/bugs/745014
[15:04] <ev> thanks
[15:05] <cjwatson> using SA_RESTART for all signal handlers is arguably safer anyway
[15:05] <cjwatson> asking around locally, anything that uses stdio plus signal handlers without SA_RESTART is fundamentally unsafe
[15:05] <cjwatson> you can't retry stdio calls on EINTR since data may be buffered and you have no way to know this
[15:06] <cjwatson> so unless the library does it for you (which AFAICS glibc doesn't), you're out of luck
[15:07] <cjwatson> it's hard to see from python code at first glance whether it's using syscalls or stdio, but I think some of it may be stdio
[15:31] <ev> cjwatson: to break away from the eintr conversation briefly, mpt and I are working through the case where ntfs is in an error state
[15:31] <ev> we're still working through the ui, but..
[15:35] <ev> what are your thoughts on if ntfsresize --info fails, run ntfsfix, *ui goes here*, reboot
[15:36] <ev> cjwatson: obviously that doesn't help massively when the error is actually at the block level
[15:36] <ev> but chkdsk might have slightly better ui for that scenario anyway
[15:37] <ev> ntfsfix> apparently sets the dirty flag, which I hope is enough to trigger chkdsk before mount in windows, but would have to test
[15:37] <cjwatson> do all ntfsresize --info failures correspond to "run ntfsfix"?
[15:37] <davmor2> ev: it does
[15:38] <davmor2> ev: ntfsfix does some common repairs and then triggers chkdsk iirc from the man description
[15:39] <ev> cjwatson: well, that's why I mentioned the block level error case.  Are there others you can think of?
[15:41] <cjwatson> I'm not sure I know it well enough to make sure
[15:41] <cjwatson> I think it would require going through the source
[15:42] <ev> yeah, digging through it now
[15:44] <ev> SA_RESTART> odd that ronaldoussoren mentioned it as a solution in http://bugs.python.org/issue9867 yet it wasn't taken (at least not from what I can see looking at the cpython3 source)
=== skaet_afk is now known as skaet_
[15:47] <cjwatson> it's not something python can entirely enforce on its own
[15:49] <ev> fair enough, I think my not-entirely-complete knowledge of the signals in question are preventing me from entirely understanding the correction solution
[15:51] <cjwatson> you need everything that installs a signal handler anywhere in the process to use SA_RESTART
[15:51] <cjwatson> (or you need to hack around it with siginterrupt)
[15:53] <ev> right, but surely for the cases where that's python, it can handle it, no?
[15:54] <cjwatson> python's own signal handlers aren't problematic for this
[15:54] <cjwatson> so that's moot
[15:54] <cjwatson> for the most part, anyway)
[15:55] <ev> ah, okay
[15:55] <ev> that's where I was getting tripped up
[15:55] <cjwatson> it basically amounts to the SIGINT handler, which is likely to terminate the process anyway, and a few conditional things
[15:56] <cjwatson> setting signals to SIG_DFL or SIG_IGN doesn't count here, it's just explicit handler functions
[15:58] <ev> ugh, I need to spend more time with Stevens.
[16:01] <ev> god, the world before design specifications was a horrible place. Lets never go back.
[16:01] <ev> having a single place to point at any time something is queried or contested, and most importantly can be changed there is wonderful
[16:02] <ev> rather than having to trek back through bug reports, work items, wiki specs, ...
[16:02] <cjwatson> I find a lot of it a bit invisible TBH
[16:02] <ev> oh?
[16:02] <cjwatson> I rarely know where to look to find that stuff
[16:03] <ev> it should all be in the google doc
[16:03] <cjwatson> what google doc? :-)
[16:03] <ev> which I should actually link to on the wiki (and just just from a blueprint).  Fixes...
[16:03] <ev> indeed :)
[16:03] <ev> https://docs.google.com/a/canonical.com/Doc?docid=0AU5sFuLRpCpBZGZra2pqY2pfMTAxZ25rcnBnNXY&hl=en
[16:03] <cjwatson> memorable URLs FTW
[16:04] <ev> I know, right?
[16:04] <cjwatson> I guess when you aren't looking at it all the time ...
[16:05] <artnay> hi, is someone here in charge of ubiquity-debconf's strings/variables?
[16:05] <cjwatson> that doesn't really make sense as such, but just ask your question :)
[16:05] <artnay> translation template contains several strings with "${RELEASE}"
[16:06] <artnay> before maverick it used to be Ubuntu xx.xx but in maverick it was changed (just before freeze) to just "Ubuntu"
[16:06] <artnay> how will it be with natty? just Ubuntu or Ubuntu <version> ?
[16:08] <artnay> there are certain languages where one has to conjugate "Ubuntu" (for example, Try ${RELEASE} should be translated Kokeile ${RELEASE}a to be a proper sentence)
[16:10] <artnay> there seems to be 9 strings which use this ${RELEASE} variable
[16:12] <artnay> however, if the variable won't be "Ubuntu" in natty, those translations will look plain wrong if conjugated
[16:14] <artnay> hopefully you understand why I'm asking this. it's all about small details, right? ;-) having amateurish translations with the 1st phase of installation won't give good impression
[16:15] <cjwatson> "Ubuntu", as far as I can see
[16:17] <artnay> cjwatson: got it, thanks.
[16:24] <ev> cjwatson: google doc> I've added it to http://wiki.ubuntu.com/Ubiquity.  If you have any concerns with driving development of the installer from there, I would love to work to resolve them.
[16:34] <ev> bug 745687 :(
[16:34] <ubot2> Launchpad bug 745687 in ubuntu "Brief text over the background image restarting after install" [Undecided,New] https://launchpad.net/bugs/745687
[16:37] <cjwatson> yeah, I've seen that but it's a horrendous pain to debug live CD shutdown
[16:38] <ev> indeed
[16:39] <cjwatson> shall I stick it on plymouth for the time being, or do you think it's more likely to be ubiquity?
[16:39] <cjwatson> I don't suppose we know ...
[16:39] <mpt> artnay, depending on the circumstance, the partitioning step may say "This computer has Ubuntu 10.10 on it. What would you like to do?" -> "Upgrade Ubuntu to 11.04"
[16:40] <ev> I'd stick plymouth on it, just for an expanded set of eyes
[16:40] <artnay> mpt: good point, so maybe the version number should be included
[16:40] <mpt> artnay, and "This computer has Ubuntu 11.04 on it." -> "Reinstall Ubuntu 11.04"
[16:40] <ev> artnay: I'll stick comments in, but it's always Distro XX.XX where Distro is likely to be UBuntu and XX.XX may be 11.04
[16:41] <ev> Ubuntu*
[16:41] <cjwatson> it's a bit odd that ${RELEASE} gets expanded to the distribution name
[16:41] <artnay> mpt: that variable isn't used in those places
[16:41] <cjwatson> at least as far as I could see from testing
[16:41] <artnay> https://translations.launchpad.net/ubuntu/natty/+source/ubiquity/+pots/ubiquity-debconf/fi/+translate?batch=10&show=all&search=%24{RELEASE} this is what I see (in Finnish)
[16:41] <cjwatson> >>> misc.get_release()
[16:41] <ev> cjwatson: I don't follow. Is Ubuntu 11.04 not a release?
[16:42] <cjwatson> ReleaseInfo(name='Ubuntu', version='11.04')
[16:42] <cjwatson> ubiquity/plugins/ubi-language.py:306:        text = text.replace('${RELEASE}', release.name)
[16:42] <cjwatson> etc.
[16:42] <cjwatson> Ubuntu 11.04 is; Ubuntu is not
[16:42] <ev> oo
[16:43] <artnay> as I said, in previous versions it was with the version number, in maverick it was without
[16:44] <ev> dear lord Unity, think you could run for more than 15 seconds without crashing?
[16:45] <artnay> mpt: you're referring to this sentence: Install ${DISTRO} ${VER} alongside ${CURDISTRO}
[16:46] <ev> just checking through the code, one moment
[16:47] <mpt> artnay, that string isn't specced to have ${VER} in it, though actually maybe it should
[16:47] <mpt> artnay, https://docs.google.com/View?id=dfkkjjcj_101gnkrpg5v#4_5_1_Automatic_partitioning_o_8475526086986065
[16:49] <ev> cjwatson: # above Description lines will appear in rosetta, right?
[16:49] <mpt> artnay, sorry, my mistake, that string is supposed to have ${VER} in it when there's an older version installed
[16:49] <cjwatson> ev: which ones?
[16:49] <ev> I'd like to add a comment for translators.
[16:50] <cjwatson> oh, I misparsed
[16:50] <cjwatson> should do, yes
[16:50] <ev> okay, cool, thanks
[16:50] <cjwatson> though my rosetta memory is a bit rusty
[16:50]  * ev goes off to clarify this in the code
[17:01] <CIA-31> pkgsel: cjwatson * r173 ubuntu/debian/ (changelog postinst):
[17:01] <CIA-31> pkgsel: localechooser/supported-locales only lists additional locales, so
[17:01] <CIA-31> pkgsel: calculate the set of language packs to install using the union of it and
[17:01] <CIA-31> pkgsel: debian-installer/locale (LP: #741304).
[17:03] <artnay> so, umh, to clarify. "Try ${RELEASE}" and "Install ${RELEASE}" are the problematic ones (in certain languages) that might need conjugation. should those have ${VER} as well? If yes, I could file a bug (to remind you devs)
[17:07] <ev> artnay: hopefully that will help (it should end up on rosetta): http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/4628
[17:07] <CIA-31> ubiquity: evand * r4628 trunk/debian/ (changelog ubiquity.templates):
[17:07] <CIA-31> ubiquity: Clarify substitution variables in the automatic partition templates
[17:07] <CIA-31> ubiquity: using comments.
[17:08] <CIA-31> pkgsel: cjwatson * r174 ubuntu/debian/ (changelog postinst): Fix Chinese special cases for language packs to work properly.
[17:08] <ev> I'll add some more comments to cover RELEASE and friends now
[17:08] <artnay> ev: that doesn't contain a fix/explanation
[17:09] <artnay> ev: oh, ok. see 3.1 in mpt's link
[17:10] <artnay> Ubuntu presents a list of languages with TWO OPTIONS ONLY: Try or Install Ubuntu.
[17:10] <ev> see my previous comment
[17:19] <CIA-31> ubiquity: cjwatson * r4629 trunk/ (debian/changelog ubiquity/install_misc.py):
[17:19] <CIA-31> ubiquity: localechooser/supported-locales only lists additional locales, so
[17:19] <CIA-31> ubiquity: calculate the set of language packs to install using the union of it and
[17:19] <CIA-31> ubiquity: debian-installer/locale (LP: #741304).
[17:20] <CIA-31> ubiquity: evand * r4630 trunk/debian/ (changelog ubiquity.templates): Clarify more debconf questions using comments.
[17:28] <CarlFK> This should add to the installed /etc/apt/sources.list right?   d-i apt-setup/local0/repository string http://ddebs.ubuntu.com natty main restricted universe multiverse
[17:29] <CarlFK> I will swear it did, but even going back to my hardy installer it isn't.
[18:01] <CIA-31> pkgsel: cjwatson * r175 ubuntu/debian/changelog: releasing version 0.33ubuntu3
=== skaet_ is now known as skaet_otp
=== skaet_otp is now known as skaet
=== skaet is now known as skaet_afk
[22:41] <CIA-7> ubiquity: cjwatson * r4631 trunk/ubiquity/frontend/kde_components/PartMan.py: typoes
=== skaet_afk is now known as skaet
[23:38] <CIA-7> ubiquity: cjwatson * r4632 trunk/ (bin/ubiquity debian/changelog):
[23:38] <CIA-7> ubiquity: Do a quick check at startup to see if the debconf database is locked by
[23:38] <CIA-7> ubiquity: something else, and exit slightly more gracefully than by raising an
[23:38] <CIA-7> ubiquity: exception (LP: #746020).