[04:41] <pitti> Good morning
[05:01] <ion> that
[05:23] <pitti> ogra_, slangasek: has there been any further discussion on bug 1187189, i. e. how to do fw loading? with the flipped container model that might have changed?
[05:58] <pitti> wgrant, StevenK: wrt https://translations.launchpad.net/ubuntu/saucy/+language-packs, what's missing for starting exports now?
[05:59] <wgrant> pitti: We need to adjust the export schedule
[05:59] <wgrant> That's about it
[06:00] <pitti> wgrant: for that to happen, which direction do I send beer to?
[06:01] <pitti> to you?
[06:01] <wgrant> 30 10 * * 1 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu precise --force-utf8-encoding -q --log-      file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
[06:01] <wgrant> 30 10 * * 2,4 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu raring --force-utf8-encoding -q --log-     file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
[06:01] <wgrant> 30 10 * * 3 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu quantal --force-utf8-encoding -q --log-      file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
[06:01] <wgrant> Is what we do atm
[06:01] <wgrant> I'
[06:01] <wgrant> I'd suggest s/raring/saucy/, s/quantal/raring/
[06:01] <wgrant> So stopping quantal exports
[06:01] <pitti> yeah, we don't use them any more
[06:02] <wgrant> OK, I'll make that change. You'll handle your end?
[06:06] <lifeless> wgrant: isn't that s/quantal/saucy/ ?
[06:06] <wgrant> Not in that order.
[06:13] <pitti> wgrant: adjusted, but disabled for now; I need to build full saucy packs initially
[06:13] <pitti> I'll do that when I see the first full export on +langpacks
[06:13] <wgrant> Thanks
[06:13] <pitti> wgrant: thanks to you!
[06:44] <dholbach> good morning
[07:49] <ogra_> pitti, we dont/cant do fw loading on the ubuntu side since it is part of the HW initialization happening on the android side ... loading it in ubuntu we would miss configs and parameters ... if you have a better idea how to prevent it than diverting the rules that would be super appüreciated :)
[08:07] <pitti> ogra_: i. e. we should revert the patch to grab firmware from /system and /vendor ?
[08:09] <ogra_> pitti, there is a patch ? i thought slangasek dropped it when we added the diversion for the firmware rule
[08:09] <pitti> ogra_: not a patch, we added /system/firmware and /vendor/firmware as fw lookup path
[08:09] <ogra_> we explicitly dropped the rule, so udev shouldnt even attempt to load fw at all
[08:10] <ogra_> which makes the patch useless i guess
[08:10] <pitti> ogra_: ah, then I guess that was a no-op change
[08:10] <pitti> ok, then I'll just revert it for now
[08:10] <ogra_> the patch was before dropping the rule altogether, i guess steve just forgot about it
[08:11] <ogra_> pitti, though it would be nice if udev could have a switch or some such to prevent fw loading, so that we dont need to divert the rule
[08:12] <pitti> ogra_: well, disabling the rule means to install one extra empty file into /etc/udev/rules.d/
[08:12] <pitti> ogra_: it can't get much easier than that; in particular, we don't want to change any existing file
[08:12] <pitti> no need for a divert there
[08:12] <pitti> just touch /etc/udev/rules.d/50-firmware.rules
[08:12] <ogra_> oh ... upstart style disablement ?
[08:13] <ogra_> ok
[08:13] <pitti> no, udev rules overriding; that has worked for many years
[08:13]  * ogra_ didnt know that exists
[08:13] <pitti> see /etc/udev/rules.d/README
[08:13] <ogra_> ah, just an empty rule with higher sequence ... k
[08:13] <pitti> ogra_: ok, that might simplify things on your end :)
[08:13] <pitti> ogra_: no, not with higher sequence, with exactly the same name
[08:14] <pitti> ogra_: /etc/udev/rules.d/foo.rules replaces /lib/udev/rules.d/foo.rules
[08:14] <ogra_> ah, i missed thats /etc, sorry
[08:14] <pitti> ogra_: as you can't undo the fw loading, a higher sequence number doesn't work here
[08:14] <ogra_> right
[08:14] <pitti> ogra_: so I guess that touching will happen in the image build process, or some u-phone specific package will ship it?
[08:15] <ogra_> yeah
[08:15] <ogra_> the lxc-android-config package holds all container stuff and related hacks
[08:16] <ogra_> as long as we use ueventd we dont want udev to initialize the HW
[08:16] <pitti> ogra_: ok; so I guess I'll follow up to the bug with that summary; thanks!
[08:17] <ogra_> (it's startup is delayed untila after the container is done atm, and we'll get an upstart bridge into the container so we can depend on "ueventd settle" inn it for starting udev
[08:17] <ogra_> )
[08:34] <pitti> jodh: hey James, how are you?
[08:34] <jodh> pitti: hi, good.
[08:34] <pitti> jodh: wrt. the apport log file collect work item in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-upstart-app-launching
[08:34] <rbasak> Bug 1199318. He shouldn't have saucy-proposed enabled, but is this also a bug anyway? Is there a missing Breaks/Replaces in apache2-utils 2.4.4-6ubuntu2?
[08:35] <pitti> jodh: I don't currently have any ~/.cache/upstart/application-*
[08:35] <pitti> jodh: will these appear at some point, or has the semantics of that changed?
[08:35] <pitti> rbasak: yes, there is
[08:37] <jodh> pitti: this is teds baby. Seems to be on hold currently: https://code.launchpad.net/~ted/indicator-application/upstart-job
[08:40] <rbasak> Thanks.
[09:48] <pitti> ogra_: do you know how to launch a Qt app on phablet builds from ssh? i. e. the equivalent of setting $DISPLAY?
[09:48] <ogra_> sudo -u phablet
[09:48] <pitti> ogra_: I tried with the terminal app and an external keyboard, but the terminal app doesn't work very well with a keyboard..
[09:48] <ogra_> that shoudl suffice
[09:49] <pitti> hm, I'm already logged in as phablet
[09:49] <pitti> ogra_: oh, indeed; it wasn't working the first time, but now it does
[09:49] <pitti> ogra_: thanks!
[09:49] <seb128> pitti, ssh<EMAIL_ADDRESS>[09:50] <pitti> yes, that's what I did
[09:50] <seb128> pitti,  qmlscene debug.qml --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop
[09:50] <seb128> you need the --desktop_file_hint
[09:50] <seb128> iirc
[09:50] <seb128> (that works there)
[09:50] <ogra_> right
[09:52] <ogra_> https://wiki.ubuntu.com/Touch/ReleaseNotes#Ubuntu_SDK_Alpha ... at the bottom has the instructions btw
[09:52] <pitti> so just calling "gallery-app" reproducibly doesn't work until I actually launch it from the terminal there; seb128's command segfaults
[09:52] <ogra_> seems you are missing env vars then
[09:52] <seb128> pitti, weird, I run system-settings like that and it works for me
[09:52] <seb128> system-settings --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop
[09:53] <pitti> I'm actually trying to reproduce bug 1198277, which concerns app startup
[09:53] <pitti> seb128: "qmlscene debug-qml --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop" also crashes
[09:54] <seb128> pitti, do you have a debug-qml?
[09:54] <seb128> pitti, qmlscren debug.qml was my command in that example, replace by whatever you want to run
[09:54] <pitti> so with autopilot I get a autopilot.introspection.dbus.gallery-app  object, but I don't see anything
[09:55] <pitti> seb128: no, I though that was some standard qml file to launch an app
[09:55] <seb128> pitti, "$ gallery-app --desktop_file_hint=/usr/share/applications/gallery-app.desktop" works for me
[09:55] <pitti> seb128: ah, that way around
[09:55] <seb128> pitti, oh, sorry
[09:55] <dpm> I believe plain 'qmlscene app.qml' should also work for the purposes of just launching the app. That's how I've been launching the music app for testing it
[09:55] <ogra_> for me too
[09:55] <ogra_> (though i'm logged in with adb and use sudo -u phablet -i here
[09:55] <ogra_> )
[09:55] <pitti> seb128: confirmed, merci beaucoup !
[09:55] <seb128> pitti, de rien ;-)
[09:55] <pitti> nah, "ssh nexus" FTW :)
[09:55] <popey> dpm: nope, you need more parameters or it doesn't show up
[09:56] <pitti> ogra_: *applaud* vi installed by default!
[09:56] <ogra_> haha, minimal pulls it in
[09:56] <dpm> ah, perhaps what I did was just to launch the executable line in the .desktop file, then, which includes the parameters
[09:56] <dpm> ignore my comment, then
[09:56] <ogra_> not my doing :)
[09:58] <Laney> huh, I'd been typing commands on the terminal of the device for all this time :P
[10:00] <pitti> ogra_: OOI, the MAC address (and thus the supposedly stable IPv6 address) of this thing seems to change with every boot; is there a trick to get a stable IP on that thing?
[10:00] <pitti> ogra_: or do you also just check the ip du jour every time?
[10:01] <ogra_> i honestly didnt even knwo it changes :)
[10:01] <pitti> ogra_: ah, you're using adb shell, not ssh?
[10:01] <ogra_> yes
[10:01] <pitti> ok
[10:01] <ogra_> but even then, it shouldnt change, what device is that ?
[10:02] <ogra_> probably worth a bug (though would need an android fix)
[10:03] <pitti> ogra_: nexus7
[10:03] <ogra_> ah, crap HW then :P
[10:03] <ogra_> j/k
[10:05] <xnox> pitti: i typically use the avahi hostname: ssh<EMAIL_ADDRESS>[10:05] <xnox> or whatever it is, and I ignore host verification on *.local.
[10:05] <popey> which is annoying if you have two phablet devices!
[10:05] <xnox> popey: *sigh*
[10:05] <tseliot> pitti: do you happen to remember if jockey.detection.get_hardware() is cached somewhere in Jockey? I'd like to access it from handlers without having to call the same function multiple times
[10:05] <popey> the hostnames should be unique
[10:05] <popey> we should get achiang generating awesome hostnames randomly for us
[10:05] <pitti> xnox: that was actually the first thing I tried, but it doesn't seem to WFM
[10:06] <xnox> popey: yeah, oobe app, which i am on the hook to write should let one choose the hostname.
[10:06] <xnox> pitti: right, cause i had to manually install and configure avahi (disable some $new-kernel-feature)
[10:06] <ogra_> popey, lol
[10:06] <Laney> I loved bisquicks and want it back
[10:06] <pitti> popey: yeah, way to break predictability of that, too :)
[10:06] <pitti> xnox: aah
[10:06] <Laney> I don't think I had to do anything to have avahi working to the device ...
[10:06] <pitti> anyway, adb or adb forwaring is fine
[10:06]  * ogra_ once had a "mofo" device thanks to that ...
[10:07]  * xnox whistles at broken launchpad and goes to make coffee, whilst the failover is in progress.
[10:09] <ogra_> GEEZ !
[10:09] <ogra_> the Lp error page tells me i need to install flash ?!?!
[10:10] <wgrant> Probably the Twitter streaming thing broken by a YUI update
[10:10] <wgrant> That page doesn't get tested much...
[10:12] <Laney> I just get a spinner
[10:12] <pitti> me 2
[10:12] <seb128> launchpad is back
[10:13] <tseliot> pitti: is it a no? ^^
[10:14] <pitti> tseliot: sorry; it is cached, see def _get_modaliases()
[10:15] <pitti> tseliot: the second time it shoudl be very quick and not actually do anything except returning the cache
[10:16] <xnox> seb128: yeah, it's back but not all cronjobs are back on.
[10:16]  * xnox 's uploads not accepted.
[10:16] <tseliot> pitti: ah, nice, I had missed the "if _get_modaliases.cache:" part. Thanks
[11:48] <Laney> Is this: https://launchpadlibrarian.net/145001004/buildlog_ubuntu-saucy-i386.gst-plugins-bad1.0_1.0.8-1ubuntu1_FAILEDTOBUILD.txt.gz a bug in gst-plugins-bad or the toolchain? It builds on amd64/armhf but not i386/powerpc (but building there using gold does work)...
[12:07] <infinity> Laney: Probably a link order issue, exacerbated by the silliness of using -nostdlib and -lc (who *does* this?)
[13:02] <Laney> infinity: AFAICT nostdlib is a libtool-added thing when linking C++ libraries
[13:30] <Laney> Grah
[13:31] <Laney> http://stackoverflow.com/questions/10050389/repeating-libs-on-libtool-command-line ← something like that does it
[13:31] <Laney> slomo_: ↑ — have you looked into this?
[13:35] <cjwatson> pitti: Do you have a minute to give me a hand with PolicyKit?
[13:35] <cjwatson> pitti: I'm trying to figure out how to tell it that installing click packages through PackageKit doesn't require admin auth
[13:35] <cjwatson> pitti: At the moment I have the rather inadequate workaround shown in https://bazaar.launchpad.net/+branch/click/view/head:/pk-plugin/README
[13:36] <seb128> cjwatson, /usr/share/polkit-1/actions/org.debian.apt.policy might be useful as an example?
[13:37] <pitti> hey cjwatson
[13:37] <pitti> cjwatson: sure
[13:37] <cjwatson> seb128: The problem is that the action isn't distinct, so I need to match on the data
[13:38] <pitti> cjwatson: oh, do we actually use PackageKit for that?
[13:38] <cjwatson> pitti: I'm planning to
[13:38] <pitti> cjwatson: aptdaemon has a concept of "high trust" packages, and already has a separate PK action
[13:38] <pitti> such a counterpart doesn't exist in PK AFAIK, maybe we can add it
[13:39] <cjwatson> aptdaemon isn't really a brilliant match
[13:39] <cjwatson> It would be possible, but I've already got most of the rest working in PK
[13:39] <stgraber> @pilot in
[13:39] <cjwatson> I think the way you're supposed to do this in PK is to match on the package_ids data it passes to PolicyKit?
[13:40] <pitti> cjwatson: so one option is to teach PK about such a class of applications that users can install without admin privs
[13:40] <cjwatson> I can make those package_ids contain "click"
[13:40] <cjwatson> But I can't work out how to match on that in a policy
[13:40] <pitti> cjwatson: the other is to write a wrapper which gets run as root, checks the package ID, and calls PK (no password needed if teh caller is root)
[13:41] <pitti> cjwatson: and then add a pkexec rule that any user can pkexec that wrapper on a local foreground session
[13:41] <cjwatson> OK, neither of those makes me very happy - I already have a working packagekit plugin and don't desperately want to turn it all inside out
[13:41] <pitti> cjwatson: you touch a sore point actually
[13:41] <slomo_> Laney: no, and i don't see what it would help other than working around bugs somewhere else
[13:42] <cjwatson> And I was really hoping not to have to modify PackageKit to do this, seeing as it *looks* as though I should be able to match on the details it passes?
[13:42] <pitti> cjwatson: besides the rather static .pkla files current polkit versions have a JavaScript backend which allow this kind of flexibility; but we never got it as it requires mozjs, which is a rather dubious thing to pull into our central priv management
[13:42] <cjwatson> Yeah, I noticed that
[13:43]  * ogra_ doubts we would like mozjs on the touch images :)
[13:43] <pitti> cjwatson: to my knowledge .pkla files can't match on details, only on user, group, session status, and action ID
[13:43] <cjwatson> Urgh :(
[13:43] <Laney> slomo_: I don't mean my solution, but the problem in general
[13:43] <pitti> cjwatson: the original idea was that things like "install a package", "upgrade a package" etc. would be different actions
[13:44] <pitti> cjwatson: so aptdaemon grew org.debian.apt.install-packages.high-trust-repo
[13:45] <pitti> cjwatson: it seems the most workable approach right now is a pkexec'ed wrapper which calls PK with the repo/package name as root after checking that it's a click package/appropriate repository/etc/?
[13:45] <slomo_> Laney: we're doing the same in the gstreamer android makefiles for various things, yes
[13:46] <cjwatson> pitti: That's problematic since I need to know the calling user
[13:46] <pitti> cjwatson: is PK actually fast enough for your purposes? last time I tried it it's still really slow
[13:47] <Laney> slomo_: sec, I found the --preserve-dup-deps option which seems to work
[13:47] <pitti> cjwatson: $PKEXEC_UID
[13:47] <cjwatson> pitti: overhead 0.4 seconds, doesn't seem like a problem
[13:47] <Laney> and seems to be designed for this purpose
[13:47] <pitti> cjwatson: wow
[13:47] <cjwatson> admittedly that's in lxc on an x86 laptop, but still, doesn't make me worried
[13:48] <pitti> so, that'll be a bit of a convergence story blocker, but I guess we can work that out somehow to allow PK and aptdaemon to be co-installable
[13:48] <cjwatson> If we're still using aptdaemon by the time we converge then I can work out how to make this work with aptdaemon too
[13:48] <cjwatson> For now it seems like largely a waste of cycles to go through aptdaemon
[13:49] <pitti> they mostly collide because aptdaemon ships a PK D-BUS compatibility layer
[13:49] <pitti> cjwatson: of course, with a pkexec wrapper it could just as well call apt :)
[13:49] <cjwatson> so I don't really understand the pkexec approach; how would that work given that the point of using packagekit here is to provide a d-bus API?
[13:50] <pitti> cjwatson: root can call any PK-protected API without needing to authenticate
[13:50] <pitti> cjwatson: i. e. that would do the "detail check" as a program
[13:50] <cjwatson> ah, hm, right.  I wonder if I mightn't be better off hacking PackageKit to have a way to use a different action here
[13:51] <pitti> cjwatson: do you actually use the PK signals for progress reports, etc? that would be much more difficult with a wrapper
[13:51] <cjwatson> pitti: no progress reports worth reporting
[13:52] <pitti> i. e. if you use signals, then a wrapper makes them hard to use (you'd need to relay them), and if you don't use signals we could just as well call apt in the pkexec wrapper instead of PK which just calls apt in the end, too
[13:52] <pitti> (or dpkg, or click-install or whatever)
[13:52] <pitti> cjwatson: download happens separately?
[13:53] <Laney> slomo_: http://paste.ubuntu.com/5877506/ is what I've come up with
[13:54] <cjwatson> pitti: haven't hooked up download yet but it's true that will want progress
[13:55] <cjwatson> pitti: at the moment I'm just implementing install_files - but yes, install_packages ultimately should use the download service to fetch from apps.ubuntu.com or wherever it is and then install that
[13:55] <mdeslaur> cjwatson, pitti: if you're going to write a pkexec wrapper, might as well not use packagekit and just call the click package installer with pkexec
[13:56] <cjwatson> mdeslaur: I need a d-bus api, and it's a complete waste of time to invent my own
[13:56] <cjwatson> I really want to use the pk api for this
[13:56] <pitti> mdeslaur: yes, that's what I mentioned above as well; download would need to happen unprivileged then, though (i. e. not into some root-owned cache directory)
[13:56] <cjwatson> so I feel the pkexec idea is interesting but probably a non-starter
[13:57] <cjwatson> it looks like perhaps having some way to override pk_transaction_role_to_action_* mightn't be too hard
[13:58] <cjwatson> until such time as we have a policykit where I can match on actions
[13:58] <cjwatson> er, on details
[13:59] <pitti> cjwatson: please don't hold your breath on that one; I'm honestly not a big fan of using mozjs for that either
[14:00] <pitti> cjwatson: conceptually, what's actually wrong with your 10-click.pkla? we don't want people to install any non-app ubuntu package, right?
[14:00] <Laney> slomo_: (LDADD not LDFLAGS)
[14:00] <pitti> i. e. it's the division between *-app and "any package" which is the concern here
[14:01] <cjwatson> well, on the phone, they *can't* install anything else since the system partition is read-only :)
[14:01] <cjwatson> except in developer mode
[14:02] <slomo_> Laney: why does it need -lc though? who removes it?
[14:02] <cjwatson> I'm not very comfortable with leaving it totally wide open in developer mode though, and it just doesn't really feel right
[14:02] <cjwatson> it'd certainly be a convergence problem
[14:02] <pitti> cjwatson: yeah, like we don't want an app to install openssh-server wihtout the user knowing
[14:02] <pitti> (known phablet:phablet user, etc.)
[14:04] <cjwatson> If I could just get the plugin to override the action to org.freedesktop.packagekit.package-install.click / org.freedesktop.packagekit.package-remove.click, that seems like it'd be good enough for now
[14:04] <cjwatson> ?
[14:04] <cjwatson> also - I don't suppose .policy files can match on details, can they?
[14:05] <pitti> cjwatson: yes, and we could just statically allow that (but preferably only for ResultActive)
[14:05] <cjwatson> Yeah, I only did the other two because I was bored of going round and round on tiny changes :)
[14:05] <dobey> what should one do if adt-run broke after the tests passed, and it's causing a package to be held in -proposed?
[14:05] <cjwatson> dobey: broke as in infrastructure failure?
[14:06] <pitti> cjwatson: I don't think .policy files can, but let me verify
[14:06] <dobey> cjwatson: probably. adt-run threw an exception, but looks like it could be casued due to network issues at the time
[14:06] <dobey> or possibly something else similar.
[14:07] <cjwatson> dobey: get jibel to retry it
[14:07] <dobey> jibel: ^^ can you retry software-center autopkgtest run?
[14:07] <cjwatson> pitti: (though my current lxc instance apparently requires ResultAny=yes - presumably I don't have the right consolekit bits set up or something)
[14:07] <pitti> dobey: I can also re-run them, so poke jibel and/or me
[14:07] <cjwatson> or indeed logind
[14:08] <dobey> pitti: ah ok. can you re-run software-center then? :)
[14:08] <Laney> slomo_: It's something to do with the stack protector but I don't know why it's not added automatically
[14:08] <jibel> dobey, done
[14:08] <jibel> pitti, ^
[14:08] <cjwatson> akthough I have logind installed here
[14:08] <dobey> thanks jibel
[14:09] <ogra_> cjwatson, our session doesnt register with it yet
[14:09] <cjwatson> ogra_: this isn't touch, it's an lxc instance, but noted
[14:09] <ogra_> ah, k
[14:11] <pitti> cjwatson: (FTR, no details matching in *.policy)
[14:12] <cjwatson> pitti: drat
[14:13] <pitti> cjwatson: so dynamically changing the action in your plugin sounds like a nice approach
[14:15] <pitti> cjwatson: and no details matching with the mozjs version either, so at least that's not what's blocking us
[14:15] <cjwatson> oh, really?  I thought I read it was possible there
[14:15] <cjwatson> though the policykit documentation is ... less than ideal
[14:17]  * ogra_ waits for the point where cjwatson just decides to fall back to /etc/sudoers.d/ :)
[14:17] <cjwatson> I don't mean to be annoying in rejecting the proposed solutions above, btw - partly I'm just reluctant to go back and redo several days of work with a demo deadline upcoming
[14:17] <pitti> cjwatson: ah, maybe thourgh action.lookup('DETAIL') or so, but it's not documented explicitly
[14:18] <pitti>    if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&
[14:18] <pitti>         action.lookup("drive.vendor") == "SEAGATE" &&
[14:18] <pitti> so indeed, with the mozjs bits one could most probably do that
[14:21] <cjwatson> fortunately this isn't a demo blocker as such - can always specially prepare the image
[14:21] <cjwatson> but would be nice not to have to
[14:21] <infinity> cjwatson: Would it upset you terribly for grub2-signed to have a hard '=' dep on grub2, so grub2 can't migrate without signed being uploaded to match?
[14:22] <cjwatson> infinity: not especially
[14:23] <infinity> Right, I think I'll go and invalidate my last upload with another that does that, then.
[14:29] <qengho> What is the behavior when a source package has some "any" and "all" arch packages? Not all builders make the "any" arch-independent package. I wish to be able to know from the environment in debian/rules if my sanity test should pass.
[14:29] <qengho>  [the test verifies we packaged everything that the upstream "install" intended us to take]
[14:30] <infinity> qengho: You mean not all builders make the "all" packages. :P
[14:31] <qengho> I deleted some hard-coded "i386" madness yesterday, but it turns out it did something, and I'd like to do it the right way.
[14:31] <infinity> qengho: In Ubuntu, the case is currently that i386 builds with "-b" and all other arches with "-B", meaning i386 produces the arch:all packages.  Relying on this to always be true wouldn't be ideal, however.
[14:31] <qengho> Right.
[14:31] <cjwatson> You can use dh_listpackages, or you could run your checks only in binary-arch
[14:31] <cjwatson> (or dh_override_foo-arch)
[14:32] <cjwatson> (the latter only available with debhelper >= 8.9.7)
[14:33] <qengho> infinity, cjwatson: thank you. That helps.
[14:33] <infinity> qengho: Anyhow, once you've come up with a plausible solution (via Colin's above hints, perhaps), you can test locally with "debuild -b" versus "debuild -B", there's nothing magic happening on the buildd side.
[14:34] <qengho> infinity: Yep.  "bzr bd -- -B" I suppose will do it.  Testing now.
[14:43] <dholbach> barry, did you hear back from mandel about the downloader packaging?
[14:44] <barry> dholbach: last week, i heard it was in progress.  we talked about a few details (e.g. # binary packages, etc.) so i believe it is in progress.  no word since then
[14:46] <cjwatson> pitti: so perhaps something a bit like http://paste.ubuntu.com/5877680/ for current pk master
[14:47] <cjwatson> I'll need to backport that to 0.7 to test it though
[14:47] <cjwatson> oh, and I suppose a .gir change
[14:48] <pitti> cjwatson: nice and generic
[14:49] <pitti> hughsie is very cooperative usually, so hopefully won't be too difficult to land this
[14:51] <dholbach> barry, ok
[14:51] <dholbach> barry, I just thought that it'd be good for it to land on the image soon, so folks can start integrating it in other places too - and it already looks like there's a lot of functionality in there
[14:52] <slangasek> pitti: yes, I think /system/firmware and /vendor/firmware should be dropped again from udev for the time being
[14:53] <barry> dholbach: agreed.  i need to find out where that's at.
[14:54] <dholbach> barry, https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/downloader is the link I was given last
[14:59] <achiang> popey: i don't need a random hostname generator, as we already have discovered the best hostname in the history of hostnames, ever.
[15:00] <dobey> jibel: the jenkins.qa.ubuntu.com is a mirror of the result data right? is there any way to see the jobs queue?
[15:00] <sergiusens> dobey: it's just used for publishing, all jobs are behind a vpn
[15:01] <jibel> dobey, jenkins.qa.u.c only publish the results once the test is done, before that the job queue is only visible on the private instances
[15:02] <jibel> and build 44 of s-c is still running
[15:32] <rbasak> infinity: I have a php5 merge ready. Apparently it's not in the server set though, so I can't upload :-/
[15:33] <rbasak> I just assumed that php would be!
[15:45] <rbasak> Daviey: do you think ~ubuntu-server-dev should be able to upload php5? Do you know why it can't? I'm not sure I really followed the way the set is determined.
[15:46] <stgraber> rbasak: the server team packageset is auto-generated from the seeds, it's not something we manage manually
[15:46] <stgraber> but even so, I'm surprised php5 wasn't included by the update script...
[15:47] <rbasak> stgraber: right, but how? Anything seeded by server or server-ship?
[15:47] <stgraber> ah, it's in core, so that may have been becaused flavours are also seeding it (at least mythbuntu appears to be)
[15:48] <stgraber> I "think" that cjwatson's script puts packages in core when they're in use by multiple flavours (in this case server and mythbuntu), but we can probably have php5 be added as an exception to that rule
[15:48] <cjwatson> I have a set of exceptions, yes
[15:48] <cjwatson> Will add
[15:48] <rbasak> Thank you
[15:49] <rbasak> http://paste.ubuntu.com/5877847/ is my debdiff if anyone wants to sponsor it sooner.
[15:49] <cjwatson> No point, it'll take minutes at most
[15:49] <rbasak> OK, thanks.
[15:52] <cjwatson> rbasak: done
[15:53] <dobey> can anyone tell me why ubuntuone-client is held in saucy-proposed?
[15:53] <rbasak> Thank you!
[15:53] <dobey> jibel, pitti: ^^ i don't see a job for ubuntuone-client on the public jenkins page, but maybe there was an infrastructure problem there too?
[15:53] <cjwatson> er it has nothing to do with them
[15:54] <cjwatson> dobey: looks like it needs some binaries decrufted; looking
[15:54] <dobey> oh
[15:54] <dobey> cjwatson: ah ok. wasn't sure since i added autopkgtests in that upload as well
[15:54] <dobey> thanks
[15:54] <cjwatson> they don't appear to have been run
[15:54] <infinity> Decrufting shouldn't be necessary, one would think...
[15:54] <cjwatson> that's odd, but it isn't blocking -proposed
[15:55] <infinity> NBS doesn't typically block migration unless there are NBS binaries in proposed.
[15:55] <cjwatson> infinity: slightly odd but perhaps the result of (includes-arch-dep) -> (doesn't) transition
[15:55] <infinity> cjwatson: Oh, all<->any can definitely cause a sad, I've seen that.
[15:56] <infinity> Though, in this case, nothing's changed archiness.  But I guess the lack of builds at all on !i386 is confusing.
[15:57] <cjwatson> anyway, it would have been stuck on ubuntuone-client-gnome needing to be removed even without that
[15:57] <cjwatson> dobey: I should interpret bug 1196684 as a removal request for the ubuntuone-client-gnome source?  ubuntu-archive isn't subscribed
[15:58] <dobey> cjwatson: yes; i was going to subscribe -archive after i got the other two bits fixed, to avoid the hassle of someone saying "it will break these other things" :)
[15:59] <dobey> cjwatson: why would ubuntuone-client be stuck on ubuntuone-client-gnome needing to be removed? because i removed the lib that -gnome depends on?
[15:59] <cjwatson> well, done now
[15:59] <cjwatson> dobey: yes
[15:59] <dobey> ah ok
[15:59] <dobey> thanks much
[15:59] <cjwatson> avoiding that kind of breakage is 90% of the point of proposed-migration :)
[16:00] <cjwatson> and decrufted now too, so that should help ubuntuone-client migrate
[16:00] <dobey> great
[16:01] <dobey> infinity: i guess because the source went any->all, though the binaries didn't change, would have hit that flag
[16:02] <pitti> StevenK, wgrant: a PPA lplib object doesn't have getPackageUploads(); how would I get the raw translation tarballs from a PPA build like https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4763305 ?
[16:02] <pitti> jibel: ^ can you take this? (no autopkgtest run for ubuntuone-client in saucy-proposed); need to run, and TBH I don't know why it doesn't appear in jenkins
[16:03] <jibel> pitti, I'll take it
[16:30] <jbicha> I wonder why saucy-changes is updating itself on such a delay
[16:31] <seb128> jbicha, you mean?
[16:33] <infinity> jbicha: Delayed mails on -changes aren't usually the list's fault, but launchpad's MTA having a bit of a sad.
[16:34] <jbicha> seb128: apparently there have been no saucy uploads today since 03:00 UTC https://lists.ubuntu.com/archives/saucy-changes/2013-July/
[16:36] <seb128> jbicha, oh, the archive ... the list is actually working fine
[16:36] <jbicha> maybe I should subscribe...
[16:37] <infinity> seb128: You have recent uploads on the list (like php5?)
[16:37] <seb128> infinity, [ubuntu/saucy-proposed] system-image 0.6-0ubuntu1 (Accepted)
[16:37] <seb128> is the most recent I got
[16:37] <seb128> it's from half an hour ago
[16:38] <seb128> php5 was just before it
[16:38] <seb128> infinity, so, yes
[16:39] <infinity> seb128: Kay, thanks for the anecdote.  Harassing someone about the archive being stalled. :P
[16:39] <seb128> ;-)
[17:16] <bdmurray> barry: I'm not having any luck verifying bug 1078697 using the provided test case
[17:17] <barry> bdmurray: looking
[17:19] <barry> bdmurray: i wonder if the affected packages need to be rebuilt?
[17:20] <bdmurray> barry: oh sorry, I mean I don't think it is failing for me with the apt in -updates
[17:20] <bdmurray> barry: http://pastebin.osuosl.org/2587/
[17:24] <barry> bdmurray: that pastebin is failing because there are no checksums in the output
[17:25] <barry> bdmurray: http://paste.ubuntu.com/5878113/
[17:26] <barry> (well, ignore the 1.0.0 version)
[17:26] <barry> bdmurray: http://paste.ubuntu.com/5878120/
[17:27] <dobey> jibel, pitti: looks like s-c failed again in the same way, with adt-run crashing. :(
[17:27] <bdmurray> barry: got it, thanks
[17:56] <jibel> dobey, this is a crash that happens when adt-run times out, so the real is elsewhere in the testsuite. Is there a test that requires access to internet resources?
[17:56] <jibel> s/real/real failure/
[17:57] <jibel> dobey, I'll re-run the testsuite and check what happens in the vm
[17:57] <dobey> jibel: i have no idea what the tests do there. :)
[17:57] <dobey> Laney: ^^ do you know?
[17:58] <Laney> i'll check what you uploaded tomorrow
[18:02] <Laney> dobey: but I was testing it with the stuff from lp:auto-package-testing if you want to do the same
[18:02] <Laney> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test
[18:02]  * Laney waves
[18:51] <stgraber> cjwatson: when you have a minute, can you let through the e-mail I just sent to ubuntu-devel-announce
[19:17] <dobey> what's the best way to get the architecutre in debian/rules with pure dh, to use in an if statement?
[19:22] <slangasek> dobey: for policy compliance, you still want to query dpkg-architecture directly; e.g., DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
[19:22] <slangasek> in practice this is usually already set in the environment by the build wrappers, but a package shouldn't rely on this
[19:23] <dobey> ah, thanks slangasek
[20:04] <cjwatson> stgraber: done
[20:04] <stgraber> cjwatson: thanks
[20:04] <stgraber> @pilot out
[21:51] <Noskcaj> roaksoax, kirkland: do either of you have a time for a testdrive "hackfest" or can you make a page explaining all the functions in testdrive? Either would hugely boost contributions to testdrive
[21:56] <wgrant> pitti: distroseries.getPackageUploads(archive=archive)
[21:57] <kirkland> Noskcaj: hi there...  okay, so here's the quick intro
[21:57] <kirkland> Noskcaj: bzr branch lp:testdrive
[21:57] <kirkland> Noskcaj: and you'll get the source
[21:57] <kirkland> Noskcaj: the majority of the logic is in:
[21:57] <Noskcaj> kirkland, I think howard and i could work out that much
[21:57] <kirkland> Noskcaj: testdrive/testdrive.py
[21:58] <Noskcaj> yes
[21:58] <kirkland> Noskcaj: there's a handful of variables that define default virtualization options, but enable advanced users to make their own tweaks
[21:59] <kirkland> Noskcaj: those can be set at the system level or at the individual user level
[21:59] <kirkland> Noskcaj: in /etc/testdriverc or ~/.testdriverc
[22:00] <kirkland> Noskcaj: we support a good number of Ubuntu flavors;  I understand you're interested in adding Kylin, which is cool
[22:00] <Noskcaj> kirkland, i don't think you understood me. The idea of the hackfest (even if it's at a time howard and i can't get to), is to get new people involved and to have you and andres help everyone fix the rather large list of bugs testdrive now has.
[22:01] <Noskcaj> the fact it's missing kylin, gnome, studio and i think edubuntu is the main thing
[22:01] <kirkland> Noskcaj: okay, sorry, I did not understand you
[22:01] <kirkland> Noskcaj: I thought that you personally wanted a tour of the code
[22:02] <Noskcaj> kirkland, maybe some other time when i'm not getting ready for school. Either way it's more aimed at everyone willing to help, rather than just me
[22:04] <kirkland> Noskcaj: I'm really sorry, but to be perfectly frank, that's not all that interesting to me
[22:05] <kirkland> Noskcaj: it's pretty straightforward Python
[22:05] <kirkland> Noskcaj: if people want to start attaching good patches and branches to open bugs, that's phenomenal, and I'll be happy to merge and release them
[22:06]  * kirkland doesn't mean to sound like a jerk, he's just a busy guy
[22:06] <Noskcaj> ok. That reminds me of the other thing, can you try and get someone else as an admin, you and andres are normally busy
[22:07] <Noskcaj> If you do have a little bit of spare time, please look at howard's kylin merge. No one can work out what's wrong
[22:10] <kirkland> Noskcaj: we will extend commit rights as soon as someone earns the privilege
[22:10] <Noskcaj> ok
[22:10] <kirkland> Noskcaj: that said, absolutely any MOTU in ubuntu can upload new versions of Testdrive, and are welcome to do so
[22:11]  * kirkland looks at howard's branch
[22:11] <Noskcaj> I'm mostly meaning commit stuff and fix the info page on launchpad (#testdrive doesn't exist).
[22:11] <Noskcaj> :)
[22:12] <kirkland> Noskcaj: description fixed.
[22:12] <Noskcaj> thanks, If you wanted somewhere to still be support, maybe link #ubuntu-quality
[22:12] <kirkland> Noskcaj: can you point me to the branch you want reviewed?
[22:13] <Noskcaj> We know it, and the current release of testdrive won't open, but for different reasons. I was hoping you would be able to work out what broke. https://code.launchpad.net/~smartboyhw/testdrive/lp-fix-ubuntukylin-1170617
[22:17] <kirkland> Noskcaj: I don't see anything obviously wrong in the review of the patch; let me test it
[22:18] <Noskcaj> FYI: I don't think the branch is based on revision 413


[19:35] <uros1> Hello all:  where to download official 12.10 logo in .svg please
[19:39] <uros1> Hello all:  where to download official 12.10 logo in .svg please
[19:39] <uros1> nihil_enochian: hello
[19:40] <uros1> there is official artwor catalog, take a look https://wiki.ubuntu.com/Artwork/Catalog
[19:41] <uros1> and, there is brand guidelines http://design.canonical.com/the-toolkit/ubuntu-brand-guidelines/
[19:41] <nihil_enochian> hello uros1
[19:41] <uros1> pozz
[19:41] <nihil_enochian> thanks for this
[19:41] <uros1> :)
[19:42] <uros1> for official logo, we must wait here, no other way for now
[19:42] <nihil_enochian> ok


[01:48] <kirkland> cjwatson: mathiaz and I have both experienced something strange with today's server iso's
[01:49] <kirkland> cjwatson: they seem to slow down (almost hang, but they do recover and finish)
[01:49] <kirkland> cjwatson: usually around configuring the language pack
[01:49] <kirkland> cjwatson: i'll get you more details on the precise point at which the install seems to "stall"
[01:49] <kirkland> cjwatson: i just wanted to mention this now, since mathiaz said he noticed the same thing
[02:15] <cjwatson> I'll need logs
[02:16] <cjwatson> syslog will be sufficient to show me what's happening at what times
[09:08] <evand> kirkland: nope, I've updated bug 349440 accordingly
[09:14] <evand> cjwatson: I'll see what I can do about that bug after I finish this test install using the latest daily-live.
[12:21] <davmor2> cjwatson: have you seen bug 361627 :(
[12:21] <cjwatson> no
[12:22] <cjwatson> well, I have now. Give me a minute
[12:23] <cjwatson> it's a rather specialised case, but I'll see if we can get it fixed
[12:29] <CIA-4> user-setup: cjwatson * r175 ubuntu/ (debian/changelog user-setup-ask):
[12:29] <CIA-4> user-setup: Install ecryptfs-utils if it's already in use by users on an existing
[12:29] <CIA-4> user-setup: /home (LP: #361627).
[12:31] <CIA-4> user-setup: cjwatson * r176 ubuntu/debian/changelog: releasing version 1.23ubuntu19
[12:42] <evand> I have most of the code in place for ubiquity understanding the use_biggest_free option, I'm just looking for the best way to extract the partition that's going to be used for use_biggest_free from partman.
[12:43] <evand> my current thought is to pull it out of /var/lib/partman/snoop
[12:49]  * cjwatson looks
[12:49] <cjwatson> I've sort of been hoping to drop use of the snoop file soon since the choices are now more automatically parseable than they used to be, but I don't object if that's the easiest way ... let's see
[12:53] <cjwatson> use snoop if it's easier to work into the code as it stands, but I think you can also fish it out of choices-c for whichever automatically_partition question you get
[12:53] <cjwatson> choices-c should have an entry something like 50biggest_free__________/var/lib/partman/devices/=dev=sda//32-1048576
[12:54] <cjwatson> and I think that's basically just what's in the snoop file as well (except that the lines in snoop also have <tab><description of partman-auto/text/use_biggest_free> at the end)
[12:55] <cjwatson> indeed, menu_options should have the contents of snoop pre-parsed for you
[12:55] <davmor2> evand: I'll re-test in about 10 minutes
[12:57] <cjwatson> you can use self.find_script(menu_options, 'biggest_free') which will give you a list of (currently) either zero or one elements; if the list is non-empty, its element will be a three-element tuple of which the second element should be something like '/var/lib/partman/devices/=dev=sda//32-1048576'
[12:57] <davmor2> evand: I still think that the oem map should be the new one it looks wrong.  But then I guess the end user would never know
[12:58] <cjwatson> the split_devpart method will take that string apart into device and partition ids
[12:59] <CIA-4> ubiquity: evand * r3216 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[12:59] <CIA-4> ubiquity: Fix a crash when in OEM mode. Child widgets are members of the the
[12:59] <CIA-4> ubiquity: self.userinterface list.
[13:00] <evand> cjwatson: that's the exact code I was already toying with :)
[13:03] <evand> cjwatson: (re davmor2 ^) are you still planning on reviewing the patch from shtylman for Jaunty, or have you decided to shelve it to Karmic?
[13:05] <cjwatson> which patch?
[13:05] <cjwatson> oh, oem-config?
[13:05] <cjwatson> I guess I can, I have a local branch with it mostly merged anyway, just need to update to your latest changes
[13:07] <evand> ok
[13:11] <CIA-4> oem-config: cjwatson * r657 trunk/ (47 files in 4 dirs): merge lp:~shtylman/oem-config/timezone_map_gtk, with some additional modifications by me
[13:13] <cjwatson> I have *not* tested that yet
[13:18] <CIA-4> ubiquity: evand * r3217 ubiquity/debian/changelog: Add LP bug reference.
[13:31] <CIA-4> ubiquity: cjwatson * r3218 ubiquity/ubiquity/frontend/kde_ui.py: typos
[13:32] <cjwatson> I'm really not happy with the Kubuntu autopartitioning bar code. It looks quite broken in a number of places :-(
[13:34] <cjwatson> and it definitely isn't working if there are no partitions to resize
[13:34] <cjwatson> I suppose I might be able to bodge it together somehow ...
[13:39] <davmor2> cjwatson: Should ubiquity be able to resize a ext4 partition?
[13:45] <cjwatson> yes
[13:46] <davmor2> cjwatson: I'll get the logs
[13:51] <davmor2> cjwatson: http://www.davmor2.co.uk/partman do you need syslog too
[13:52] <cjwatson> davmor2: what precisely is the problem here?
[13:52] <cjwatson> yes, I need syslog
[13:54] <davmor2> cjwatson: On ubuntu I did a manual install where I used ext4 for basically the whole drive bar swap.   In Kubuntu I've gone to resize the drive and it just says it can't and goes to manual mode
[13:55] <davmor2> http://www.davmor2.co.uk/syslog
[13:55] <cjwatson> Apr 15 12:37:29 ubuntu ubiquity: Please run 'e2fsck -f /dev/sda1' first.
[13:56] <cjwatson> looks like it wasn't cleanly unmounted. perhaps you just turned off the vm?
[13:59] <davmor2> cjwatson: it's hw I rebooted
[14:03] <cjwatson> not sure there's much I can do, resize2fs doesn't like it ... maybe it crashed before unmounting it properly
[14:04] <davmor2> cjwatson:  I've run the e3fsck and started ubiquity again and it's gone through this time.  I'll try it again after the tests are complete to makes sure it's not an issue
[14:05] <davmor2> e2 even
[14:10] <cjwatson> oh my
[14:10] <cjwatson>             if '(%s)' % k.strip('=dev=') in txt:
[14:11] <cjwatson> that SO doesn't do what the author expected
[14:12] <cjwatson> (try it with '=dev=vda' ...)
[14:13] <cjwatson> actually, how is this working at all for anyone? '=dev=sda' will be turned into 'sa'
[14:13] <evand> yikes, that's definitely my doing
[14:14] <soren> >>> '=dev=sda'.strip('=dev=')
[14:14] <soren> 'sda'
[14:14] <cjwatson> hmm
[14:14] <soren> It only really breaks for virtio devices.
[14:14] <cjwatson> oh, it'll only strip contiguous characters
[14:14] <soren> Or people with enough devices to have an "sde"
[14:14] <cjwatson> no, that won't break either
[14:14] <cjwatson> it'll stop at the 's'
[14:15] <cjwatson> oh, but it's strip not lstrip
[14:15] <cjwatson> so yes, you're right
[14:15] <soren> Only from the start and end of the string until it reaches a not-to-be-stripped character.
[14:15] <cjwatson> I ran into this because I decided to start using virtio devices for routine testing
[14:15]  * soren tips his hat at cjwatson for that
[14:16] <soren> There more testing I can get of virtio devices, the better :)
[14:19] <CIA-4> ubiquity: cjwatson * r3219 ubiquity/ (3 files in 2 dirs):
[14:19] <CIA-4> ubiquity: Fix stripping of '=dev=' from device names when creating partition bars
[14:19] <CIA-4> ubiquity: to avoid reducing e.g. '=dev=vda' to 'a'.
[14:28] <davmor2> cjwatson, evand: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/361674 is interesting.  It only seems to effect french installs.
[14:30] <cjwatson> ok, I take back my criticism of the Kubuntu autopartitioning bar code; it seems to be mostly working now that I've fixed that '=dev='-stripping bug
[14:48] <cjwatson> davmor2: will look, though I have two other things in front of that in the queue
[14:49] <davmor2> cjwatson: ara has found another couple too
[14:49] <davmor2> in d-i
[14:51] <cjwatson> ok, I'm reading #ubuntu-testing backlog
[14:52] <davmor2> cjwatson: I'm going to see if I can confirm them as I'm doing 64bit installs on alternate now
[14:52] <CIA-4> ubiquity: cjwatson * r3220 ubiquity/ (2 files in 2 dirs):
[14:52] <CIA-4> ubiquity: * KDE frontend:
[14:52] <CIA-4> ubiquity:  - Start the resize slider at the maximum possible size for the partition
[14:52] <CIA-4> ubiquity:  being resized; this is in line with the GTK frontend, and fixes the
[14:52] <CIA-4> ubiquity:  situation where the previous default (half-way between the minimum
[14:52] <CIA-4> ubiquity:  size and the current size) is out of range.
[14:57] <cjwatson> davmor2: I don't think ara's bug need confirmation or further information
[14:57] <cjwatson> bugs
[14:57] <cjwatson> the second is probably a dup of an old bug, but I need to wait for my browser to finish rebooting
[15:09] <CIA-4> ubiquity: cjwatson * r3221 ubiquity/debian/changelog: typo
[15:55] <shtylman> cjwatson: anything I should look at (relating to the partition bars)
[15:58] <cjwatson> 14:30 <cjwatson> ok, I take back my criticism of the Kubuntu autopartitioning bar code; it seems to be mostly working now that I've fixed that '=dev='-stripping bug
[15:59] <cjwatson> I think it was just failing because /dev/vda wasn't handled properly, and that's fixed
[15:59] <cjwatson> I made a correction to its handling of the resize bar's initial position
[16:01] <davmor2> shtylman: there is a suggestion for the colour on bug 348461
[16:02] <shtylman> davmor2: thanks...will try to put that in today :)
[16:08] <davmor2> cjwatson: I can confirm using max on auto-resize throws up an error about grub do you want me to add the log to ara's bug?
[16:09] <CIA-4> ubiquity: cjwatson * r3222 ubiquity/ (debian/changelog ubiquity/components/timezone.py):
[16:09] <CIA-4> ubiquity: Preseed tzsetup/selected up-front rather than filtering it and then
[16:09] <CIA-4> ubiquity: preseeding it; filtering it causes the backup state to be reset, which
[16:09] <CIA-4> ubiquity: causes an infinite loop when backing up from the timezone page when the
[16:09] <CIA-4> ubiquity: default country only has one timezone (LP: #361674).
[16:09] <cjwatson> davmor2: no thanks, I'm sure it's just that the default size needs to be increased
[16:10] <davmor2> cjwatson: now are you sure before I reboot?
[16:10] <cjwatson> yes, thanks
[16:10] <CIA-4> oem-config: cjwatson * r658 trunk/ (debian/changelog lib/components/timezone.py):
[16:10] <CIA-4> oem-config: Preseed tzsetup/selected up-front rather than filtering it and then
[16:10] <CIA-4> oem-config: preseeding it; filtering it causes the backup state to be reset, which
[16:10] <CIA-4> oem-config: causes an infinite loop when backing up from the timezone page when the
[16:10] <CIA-4> oem-config: default country only has one timezone (LP: #361674).
[16:10] <davmor2> cool
[16:40] <lool> How is it guaranteed that some items are translated in Ubuntu install mediums?
[16:40] <lool> Say, ubiquity is translated in French, how could I make sure other software is?
[16:40] <lool> Like language-selector
[16:41] <cjwatson> you can't, in general, since it requires language packs
[16:41] <lool> But ubiquity manages to
[16:41] <cjwatson> although I think language-selector is handled outside language packs
[16:41] <cjwatson> ubiquity does not use language packs, for good reason
[16:41] <cjwatson> but that doesn't mean we can do that in general
[16:41] <lool> Is it to make sure that the installer will be translated that ubiquity doesn't use langpacks?
[16:42] <cjwatson> language-selector uses a similar approach to ubiquity; it's excluded from translation stripping (in pkgbinarymangler) and we update the translations in there by hand every so often
[16:42] <cjwatson> it's because the installer displays text before it has a chance to install language packs ...
[16:42] <cjwatson> so if we didn't exclude the installer from language packs, we'd have a chicken-and-egg problem
[16:42] <lool> Exactly; in my case, after install, I was told that language data was incomplete
[16:42] <lool> With half of the strings in English
[16:43] <lool> And I'd like to blame it on $foo
[16:43] <cjwatson> can I see the syslog?
[16:43] <cjwatson> sometimes that happens because networking was unavailable; sometimes it's a bug
[16:44] <lool> networking wasn't available
[16:44] <lool> Because I did the install fullscreen, outside of a live session
[16:44] <lool> So didn't get the NM icon
[16:44] <cjwatson> right, can't do much about that right now although there is a bug open
[16:45] <lool> As long as it's a known limitation, I'm ok
[16:45] <lool> I had in mind that stuff like NM should be excluded as well
[16:45] <lool> Because you use it to grab langpacks
[16:45] <lool> But it quickly opens the door to a lot of things to have translated on the CD   :-/
[16:45] <cjwatson> the amount of NM text you actually need to bring up networking isn't very much really
[16:46] <cjwatson> and we can't ship translations for the whole desktop into all languages, sadly
[16:46] <cjwatson> I think there's a bug open, anyway. But at any rate it is known
[16:47] <lool> cjwatson: Yes, I think we agree strongly; it would be feasible, but it's hard to draw the final line on what we really need to include and I know we can't include all
[16:47] <lool> I guess you don't care about the syslog anymore
[16:49] <cjwatson> lool: nope, thanks
[17:37] <CIA-4> partman-auto: cjwatson * r288 ubuntu/ (2 files in 2 dirs):
[17:37] <CIA-4> partman-auto: Add another 300MB to the amount of space we require to be left by
[17:37] <CIA-4> partman-auto: automatic resizing, to account for (a) growth in installation size, (b)
[17:37] <CIA-4> partman-auto: variable language pack sizes, and (c) increased memory sizes resulting
[17:37] <CIA-4> partman-auto: in upward pressure on swap partition sizes (LP: #361707).
[18:00] <mdz> I just noticed that ubiquity prompts for the OEM ID before the keyboard is configured.  is this a problem?
[18:04] <cjwatson> mdz: yes, albeit a minor one since I expect most OEMs can cope with a US keyboard (or whatever the default for the language they selected at the boot loader is). Bug 290421, which I notice you filed ;-)
[18:05] <mdz> cjwatson: ah, the memories
[18:05] <cjwatson> it should probably go on the user setup page, but there was all that tempting free space on the language page ...
[18:05] <mdz> way back in intrepid RC
[18:06] <cjwatson> we've had trouble with the user setup page; its size has been one of the things impeding support for small screens
[18:06] <cjwatson> evand stuck a scrollbar in as a nasty workaround
[18:06]  * cjwatson -> dinner
[21:21] <lfaraone> Shouldn't usb-creator not display partitions that are marked with volume.ignore?