[02:23] <darkxst_> jbicha, gdm reads locale from /etc/default/locale, but that is always en_US
[02:26] <darkxst_> jbicha, if you change the locale in that file, gdm will load in another language fine
[02:31] <jbicha> darkxst_: settings a different language works here, are you using ricotz' latest gdm from ~8 hr ago?
[02:46] <darkxst_> jbicha, umm, so what was broken then?
[02:46] <darkxst_> or is it fixed
[02:46] <jbicha> darkxst_: I think the pam symlink fixed that too
[02:52] <darkxst_> jbicha, ah cool!
[03:08] <darkxst_> ubuntu works suprisingly well in a VM except gdm (and lightdm) are always at 640x480
[03:49] <pitti> Good morning
[03:50] <ajmitch> morning pitti
[03:50] <pitti> hey ajmitch
[05:28] <slangasek> @pilot out
[06:23] <bkerensa> stgraber: do you plan to get another landscape-client update in before Wednesday?
[06:50] <_ruben> good morning xnox, i understood you're the (software) raid expert? :)
[06:51] <xnox> _ruben: in a way, yes. Go on =)
[06:52] <_ruben> xnox: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1020914 .. got some workarounds that "work", but looking for a clean solution
[06:52] <_ruben> 2 disks, each disk has 2 partition, which has 2 mdadm volumes on top, one for /boot (ext2) and the other using lvm for the rest of the system
[06:53] <xnox> _ruben: can you please install mdadm from precise-updates? =)
[06:53] <_ruben> at boottime it gives the not yet ready message and allows me to enter the recovery shell
[06:53] <xnox> _ruben: it has 3.2.5-1ubuntu0.2
[06:54] <_ruben> i have 3.2.5-1ubuntu-0.2 installed
[06:54] <_ruben> (not from -proposed tho)
[06:54] <xnox> ok. bug report said Package: mdadm 3.2.3-2ubuntu1
[06:54] <_ruben> ah yeah, i've done some updates in the meantime
[06:55] <xnox> oh. ok.
[06:55] <_ruben> its up to date as of yesterday
[06:55] <_ruben> bug was created right after clean install a while ago, upgrade didnt fix it tho
[06:55] <_ruben> the only "working" solution so far is adding nobootwait to fstab and doing a mount -a in rc.local
[06:56] <_ruben> adding wait_for_udev to the initramfs mdadm script doesn't do anything (afaics)
[06:59] <_ruben> xnox: when i do a strace mountall in the recovery shell, it doesn't show any signs of /boot and ends up hanging at a select() call .. if i mount /boot and then run mountall, booting continues (but in an odd state as mountall stays lingering about)
[07:00] <_ruben> like it's waiting for an event to fire or smth like that
[07:07] <xnox> if I am reading this right the events for the later partitions e.g. sd[a|b][3|4] didn't fire quick enough
[07:07] <xnox> maybe because they are towards the end of the disk?
[07:08] <xnox> I am pondering if a "better" "workaround" is to specify rootdelay parameters and set it to a high value e.g. 120 seconds
[07:08] <xnox> _ruben: why is raid towards the end of the disk?
[07:08] <_ruben> http://pastebin.ubuntu.com/1171271/
[07:09] <_ruben> xnox: first 2 partitions are dell recovery
[07:09] <xnox> _ruben: why is it 2 raids, instead of 1 partinionable raid.
[07:09] <xnox> ?
[07:09] <_ruben> xnox: that'd be old habit
[07:09] <xnox> =)))))
[07:09] <_ruben> does d-i even support partitionable raid (never really tried)
[07:09]  * xnox probably not =))))
[07:10] <dholbach> good morning
[07:10] <_ruben> mornin
[07:11] <xnox> dholbach: aloha =)
[07:11] <dholbach> hey hey :)
[07:11] <_ruben> xnox: i wonder why swap, / and /var/log do mount properly tho, those are on lvm tho
[07:11] <xnox> _ruben: once md is up, udev fires and LVM volumes come up very quick, even on like external drives.
[07:12] <xnox> those are not a problem =) ever.
[07:12] <xnox> (tm)
[07:12] <_ruben> so a lv comes up faster than a ext2 voluem?
[07:13] <_ruben> i'd expect the latter to be "simpler" :)
[07:14] <_ruben> xnox: where would i put those rootdelay params? willing to try anything ;)
[07:18] <xnox> _ruben: it's a kernel / boot parameter "quiet splash rootdelay=120"
[07:18] <xnox> either in /etc/default/grub & update-grub
[07:19] <xnox> or simply in the grub menu with edit functionality
[07:26] <_ruben> not ready yet ... wonder if it'll go on after 2 minutes
[07:28] <_ruben> still not ready, seems rootdelay isn't gonna help here
[07:29] <_ruben> this is odd, hitting M for manual recovery makes it continue to boot, but no recovery shell
[07:29] <_ruben> and no mounted /boot either
[07:31] <_ruben> xnox: heh, hitting M within those 120secs does give a recovery shell
[07:32] <xnox> _ruben: now this is peculiar. and I bet cannot be reproduced in a VM?!
[07:34] <_ruben> xnox: i could give that a try .. creating a vm with 2 similar sized extra partitions before the actual used ones
[07:34] <xnox> _ruben: if boot is not ready, where does it take initramfs from?! so it is readable, but not assembled/synced?! I'll need to think about that one a bit more
[07:34] <_ruben> xnox: perhaps grub reads off the raw disks and not the raid?
[07:34] <xnox> _ruben: please try, that would be a massive help, if it is reproducible in a VM.
[07:35] <xnox> _ruben: well... new enough grub understands md raid, but I don't know how knew  our grub is
[07:36] <stgraber> bkerensa: no. I'm not maintaining that package, the landscape team is. I just happen to be the last uploader for it.
[07:37] <_ruben> crap, lets create a 2-disk vm, not single disk :P
[07:38] <ev> @pilot out
[07:38] <ev> slangasek: nope :)
[07:39]  * dholbach hugs ev
[07:39] <xnox> ev: just a day and a bit later =)
[07:51] <xnox> stgraber: how big is ltsp-* bits and bobs =)
[07:51] <xnox> s/is/are/ ?
[07:52] <xnox> stgraber: looking at edubuntu my understanding was that it's dvd because of all the education packages, not because of ltsp.
[07:52] <stgraber> xnox: not terribly big, however they bring thing like isc-dhcp-server, tftpd-hpa, openssh-server, ...
[07:52] <xnox> =/ guk
[07:52] <stgraber> xnox: well, as I just replied to ubuntu-devel, Edubuntu DVD also contains a 500MB LTSP squashfs on top of the main squashfs ;)
[07:53] <stgraber> because we want to have an i386 LTSP squashfs when installing on amd64 systems
[07:53] <stgraber> alkisg's trick is really nice, but only works when your server is the same architecture as your clients, which isn't that often true in the LTSP world (most clients are old intel atoms at best, servers are usually big SMP systems with a lot of memory)
[07:53] <xnox> stgraber: /me w
[07:54]  * xnox waits 30s to see the follow-up to the follow-up
[07:54] <xnox> I see.
[07:54] <xnox> shipping a hybrid 32/64 bit is a no-go for ubuntu-desktop cd
[07:54] <stgraber> right :)
[07:55] <xnox> so the only path here is ubiquity with mdadm support
[07:55] <stgraber> Edubuntu is great for that, we have plenty of space, the only concern at the moment is really the lack of RAID support in ubiquity as we'd usually point these users to the alternate media and with dropping it, wouldn't have anywhere to point them to
[07:55] <stgraber> anyway, I have to run to the airport... talk to you later
[07:56] <xnox> stgraber: yeah, i was wondering why are you up?!
[07:56] <xnox> =)
[07:56] <xnox> take care
[07:56] <stgraber> hehe, yeah, having a flight at 7:30am does that to you ;)
[08:12] <_ruben> xnox: install completed .. performing first boot .. fingers crossed :P
[08:12] <_ruben> bugger, it boots just fine :/
[08:17] <xnox> _ruben: yeah, VM hardware comes up instantly hence you don't get the bare metal experience.
[08:18] <_ruben> xnox: indeed
[08:25] <hrw> what is a proper way of fixing ftfbs for packages which just need rebuild? like lot of those haskell packages which ftfbs because of transition and build now
[08:26] <hrw> ghc-mod for example builds but is listed as ftfbs
[08:27] <_ruben> xnox: any other ideas you can think of?
[08:28] <xnox> hrw: are those next in the queue? see http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[08:29] <xnox> hrw: if you are sure they are, I can retry them. Strahnge I don't see ghc-mod on the list... is that the source package name?
[08:29] <hrw> xnox: yes, its source name
[08:30] <hrw> xnox: git-annex is other one
[08:31] <iulian> hrw: Where do you see ghc-mod listed as FTBFS?
[08:31] <xnox> _ruben: I've confirmed the bug and added it to the reliable raid spec for me to look at later. Busy with ubiquity right now ;-)
[08:31] <iulian> The transition is almost over now. Just a few more rebuilds to go and we're done.
[08:32] <hrw> xnox: github-backup, haskell-hledger-web also
[08:32] <hrw> iulian: http://qa.ubuntuwire.com/ftbfs/ and https://launchpad.net/ubuntu/+source/ghc-mod
[08:32] <xnox> hrw: ok, i've requeued i386 of ghc-mod, if that will be fine, I'll requeue other arches.
[08:32] <hrw> xnox: thanks
[08:33] <_ruben> xnox: ah, ok. i'll get on with the current workarounds active and continue this deployment. i'll likely have another set of 2 pretty similar boxes to be deployed soon. those will probably behave the same (i'm seeing this on 2 nearly identical boxes)
[08:33] <xnox> _ruben: *sigh*
[08:38] <xnox> hrw: ghc-mod: i386 success, amd64/powerpc requeued, arms are dep-wait anyway.
[08:38] <xnox> hrw: git-annex: i386 re-queued
[08:41] <Laney> xnox: hrw is motu and could have done this himself
[08:41] <Laney> teach a man to fish ...
[08:41] <Laney> ps. good morning
[08:42] <xnox> Laney: good morning. I requested rebuilds myself from somebody the other day. Little did I know I can do it myself as a core-dev. =)
[08:42] <xnox> Laney: plus this is my first time clicking that button! Exciting =)
[08:42] <hrw> Laney: I asked which way would be proper and xnox said that this is part of transition and handled queue
[08:43] <Laney> hrw: I know, I was suggesting that him showing you how to do it instead of doing it for you would have been more profitable
[08:43] <xnox> hrw: tbh. Well my assumption was wrong =)
[08:43] <Laney> as you'd have been able to learn
[08:43] <Laney> (also, for these a retry is only good if it never built on any arch, as the others will need rebuilding anyway)
[08:44] <hrw> Laney: I suspect that 'press rebuilt button for i386|amd64' was easiest answer
[08:44] <xnox> hrw: that's what I did, after verifying.
[08:45] <hrw> btw: bug 1028761 is ~fine to go or would require FFE?
[08:45] <xnox> Laney: I checked that build-deps were uninstallable in the build-log. Did not suceed to build on any arch. Did i386 first, wait for it to succeed, then requeue other arches.
[08:45] <Laney> great, good work
[08:45] <Laney> this transition is almost done now
[08:45] <Laney> apart from investigating the arm problem, of course
[08:46] <xnox> hrw: git-annex is in main (?!)
[08:46] <hrw> Laney: armhf and haskell one?
[08:46] <hrw> xnox: in Debian yes
[08:46] <Laney> hrw: yeah
[08:46] <Laney> see e.g. haskell-chell
[08:47] <xnox> Laney: this is confusing https://launchpad.net/ubuntu/+source/git-annex why does it say main, when it isn't....
[08:47] <Laney> the table at the top is about the Debian publishing for some reason
[08:47] <Laney> presumably because it's synced and shows you the original place the package came from
[08:48] <hrw> xnox: lower it says "release (universe)"
[08:48] <xnox> hrw: hmmm.... true.
[08:48]  * xnox doesn't like that
[08:50] <hrw> speaking of main... bug 824708 has aptitude fix for precise which also fixes  bug #975793
[08:51] <hrw> its 'fix released' in quantal only
[08:51] <xnox> i'd say you should never use this "aptitude safe-upgrade -d -y" in general, and especially on amd64 with multi-arch.
[08:51] <hrw> xnox: but it is possible to use so...
[08:51] <hrw> xnox: and -d == download only so its safe
[08:52] <hrw> xnox: years ago I had similar command in cron for 5:23 to be able to do system updates at start of daily routine without waiting long time for downloads
[08:53] <hyperair> xnox: why not?
[08:53] <hyperair> also there's a patch on bugs.debian.org that fixes this
[08:53] <xnox> hyperair: ok. fair enough.
[08:54] <hyperair> i think safe-upgrade should be safe enough
[08:54] <hyperair> full-upgrade -y is the scary one
[08:54]  * xnox wishes aptitude would strop removing all of the i386 packages from my amd64 machine
[08:54] <lifeless> don't use it then :)
[08:55] <xnox> Laney: if the build finished recently e.g. github-backup on armel. Is it safe to rebuild others or a new upload required. Also why are they not in the transition tracker?
[08:55] <xnox> lifeless: the answer to everything eh ;-) =))))
[08:55] <hrw> xnox: I use aptitude on amd64 system which has i386/armel/armhf packages installed and it works
[08:55]  * xnox ponders if hyperair and lifeless have highlighs on 'aptitude' keyword
[08:56] <hyperair> haha
[08:56] <hyperair> i don't
[08:56] <hyperair> you just had good timing
[08:56] <lifeless> xnox: I've had some weirdness from aptitude with multiarch
[08:56] <lifeless> xnox: I don't know if its sorted yet
[08:56] <hrw> xnox: you 'just' need to mark all other-arch packages to upgrade each time
[08:56] <hyperair> lifeless: when anything conflicts, aptitude attempts to purge all :i386 packages
[08:56] <xnox> hrw: joy.
[08:57] <hyperair> lp 831768
[08:57] <hyperair> corresponding debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672340
[08:57] <hyperair> debian bug has a patch
[08:57] <hyperair> i'm using it locally since debian hasn't slapped on the patch yet.
[09:00] <xnox> hyperair: you should propose debian release policy to "slap the patches from bts" as a GR =)
[09:00] <lifeless> hyperair: yeah, that looks like at least part of it
[09:00] <hyperair> heh
[09:01] <hyperair> oh looks like the bug has been closed now
[09:01] <hrw> it is with 0.6.8.1-1 upload
[09:01] <hyperair> weird that the graph doesn't show it.
[09:01] <hyperair> i didn't see any green entries in the graph so i assumed it wasn't done.
[09:01] <hrw> merging should be much easier then it was with current quantal version
[09:01] <hyperair> can we SRU this?
[09:02] <hyperair> seems like an annoying enough bug.
[09:02] <hrw> hyperair: to 12.04 you mean?
[09:02] <hyperair> yes
[09:02] <hrw> hyperair: first land it in quantal
[09:03] <hyperair> yeah
[09:03] <hrw> hyperair: then merge into my debdiff from bug 824708 and happy sruing
[09:03] <hyperair> heh
[09:03] <hyperair> maybe this weekend if i'm free
[09:03] <hrw> hyperair: this way sru would fix 3 bugs at once
[09:04] <hyperair> nice
[09:05] <hrw> aptitude 0.6.8.1-1 is in incoming so far
[09:07] <hrw> I will merge
[09:07] <Laney> xnox: the tracker has a little blind spot where stuff has never built
[09:25] <hrw> aptitude 0.6.8.1 really helps on multiarch systems
[09:37] <hrw> I am uploading aptitude 0.6.8.1-1ubuntu1 to http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/
[09:38] <hrw> done
[09:39] <hrw> and this one should go though FFE process - right?
[10:03] <xnox> yes.
[10:04] <xnox> everything goes through FFe =)
[10:05] <hrw> ok
[10:05] <sladen> particularly if it's system wide and mission critical ;-)
[10:06] <hrw> sladen: I am just motu so would not upload aptitude anyway ;)
[10:08] <svenx> cjwatson: where's debian's source repo for grub2 these days? http://anonscm.debian.org/viewvc/pkg-grub/ was updated 2 years ago
[10:13] <xnox> svenx: have you tried $ debcheckout ?
[10:14] <xnox> svenx: http://anonscm.debian.org/bzr/pkg-grub/trunk/grub/ ?
[10:14] <xnox> last commit 2012-08-24
[10:21] <svenx> xnox: ah, i've looked in the wrong place
[10:21] <svenx> thanks!
[10:21] <xnox> svenx: no problem ;-)
[10:21] <mr_pouit> seb128_: hey, do you know if "internal" indicator dbus services (e.g. ./usr/lib/indicator-messages/indicator-messages-service) will stay compatible?
[10:22] <mr_pouit> seb128_: to know whether I can ship only the .so in the gtk2 package, or if I need to include everything
[10:23] <seb128_> mr_pouit, hey, what are you trying to do? get old versions or get the new version built with gtk2?
[10:24] <seb128_> mr_pouit, the indicator-messages protocol changed in quantal, you can't use the old version, like applications are ported from libindicate to libmessaging-menu
[10:25] <hrw> ok, some ftfbs entries removed by retrying builds
[10:25] <mr_pouit> seb128_: "last uploaded gtk2 version", so old version I guess (it's a bit messy though, some 12.10-0ubuntu1 uploads still had gtk2 support)
[10:27] <seb128> mr_pouit, I don't know over time but I think that for quantal the service will stay compatible (out of indicator-messages where you really need the version uploaded yesterday because clients will work only with this one)
[10:29] <mr_pouit> ok, so only indicator-messages will be problematic
[10:29] <mr_pouit> thanks
[10:30] <xnox> hrw: https://launchpad.net/ubuntu/+source/haskell-hledger-web/0.18.1-1 retries failed.
[10:36] <hrw> ops, sorry
[10:37] <xnox> hrw: http://xkcd.com/838/
[10:39] <hrw> ;)
[12:02] <hrw> ~curse torcs debian/rules
[12:09] <hrw> giving up on that one. rewriting rules just to make one ftfbs less is waste of time
[12:30] <hrw> made it.
[12:31] <hrw> bug 941619
[13:06] <zeusk> I'm getting totally corrupted display using the latest 12.10 nightlies on Nvidia adapter, is this a known bug ?
[13:31] <xnox> @pilot in
[13:32] <ogra_> safe flight !
[13:33]  * xnox Zoom Zoom
[13:41] <sconklin> @patch in
[13:41] <udevbot> Error: "patch" is not a valid command.
[13:41] <sconklin> @pilot in
[13:49] <xnox> sconklin: do we need to coordinate? I was thinking to take: llvm, ubiquity, ubiquity-slideshow as first candidates
[13:50] <sconklin> xnox: go ahead, I generally only look at kernel anyway
[13:50] <xnox> sconklin: ah... I see =)
[13:50] <xnox> sconklin: I don't ever look at kernel =))))
[13:50] <hrw> xnox: happy you
[13:51] <xnox> hrw: well.... i file complex kernel bugs =) that's enough
[13:51] <sconklin> xnox: it's what I do every day, so I'm tooled up for it, and know the workflow. bzr, not so much
[13:51] <xnox> sconklin: as infinity puts it "pick one side of the syscalls and stick to it, otherwise you will go mad"
[13:52] <sconklin> haha, had not heard that one but it's true
[13:52] <ogra_> poor syscall developers then
[13:53] <hrw> did I already said that I do not like torcs packaging?
[13:54] <hrw> I do not understand why they call configure in clean step
[13:54] <sconklin> to paraphrase Inigo Montoya: "You keep using that syscall. I do not think it does what you think it does".
[13:54] <ogra_> hehe
[13:54] <xnox> hrw: scons?
[13:55] <xnox> that thing does that for no reason.....
[13:55] <hrw> xnox: rather own + cdbs
[14:03] <hrw> first FFe today: bug 1042752
[14:06] <hrw> but I have a question about it. https://wiki.ubuntu.com/FreezeExceptionProcess says: "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it. The developer should explicitly document that this is a bugfix-only upload in the changelog or sync request." My debdiff is only patch to get it stop ftfbs in quantal (as 1.3.3 got uploaded but never built) - so it may look like 'meh, thats 
[14:11] <xnox> hrw: what's the debdiff like against torcs_1.3.1-6.2.dsc  ?
[14:11] <xnox> cause that is the effectively the changes you are trying to land =)
[14:12] <hrw> xnox: good point
[14:12] <iulian> 1.3.3 is already in quantal and thus no FFe is needed as it's just a bug fix.
[14:13] <hrw> iulian: even when 1.3.3 never built in quantal?
[14:13] <xnox> iulian: source tarball is, no binaries though.
[14:14] <iulian> Well, the source is already in the archive so it doesn't really matter. You just work on the latest version which is 1.3.3.
[14:15] <hrw> ok, so will run dput
[14:15] <xnox> hrw: i disagree with iulian interpretation.
[14:16] <iulian> Why?
[14:16] <xnox> iulian: $ apt-cache show torcs | grep Version
[14:16] <xnox> Version: 1.3.1-6.2
[14:16] <hrw> basically I will just wait - have few other things on a list, bug is opened so let ubuntu release team decide there
[14:16] <iulian> xnox: That's because there's no binaries.
[14:17] <hrw> once I will get answer in a bug from someone from release team I will apply
[14:17] <xnox> iulian: the binaries is what counts, not the source package. and it's the binaries we are freezing not the version strings on the source package.
[14:17] <iulian> xnox: Try apt-cache showsrc torcs.
[14:17] <xnox> iulian: but that is just my interpretation, and I am not on the release team or anything.
[14:17] <iulian> hrw: You just got.
[14:18] <xnox> iulian: I totally understand your point though. "It landed on time, let's make it build now"
[14:18] <iulian> Correct.
[14:19] <xnox> iulian: and well, you wear release team hat =)
[14:19] <hyperair> xnox: hmm aptitude still has issues when doing install -f.
[14:20]  * hrw builds source package, dput, close bug
[14:20] <hyperair> i.e. the typical dpkg -i foo.deb; aptitude install -f still doesn't work well with multiarch
[14:20] <xnox> yeah, I know =/
[14:21] <xnox> hyperair: apt-ftparchive package ./ > Packages
[14:21] <xnox> =))))
[14:22] <hrw> xnox: I prefer dpkg-scanpackages - has less dependencies
[14:22] <hrw> ;D
[14:22] <xnox> hrw: learned something new ;-)
[14:22] <hrw> xnox: effect is same and do not need libapt
[14:23] <hrw> xnox: embedded linux work learnt me such tricks
[14:27] <tumbleweed> iulian: ah, we both reviewed that at the same time
[14:27]  * tumbleweed took a more middle-ground approval approach though :P
[14:27] <iulian> tumbleweed: Hehe.
[14:28] <hrw> ;))
[14:28] <iulian> Oh well.
[14:28] <hrw> builds started
[14:29] <xnox> hrw: you built it locally first, right?! =))))))))
[14:30] <hrw> xnox: several times
[14:30] <hrw> xnox: https://bugs.launchpad.net/ubuntu/+source/torcs/+bug/1042752/+attachment/3280649/+files/torcs_1.3.3-5ubuntu1_amd64.build was in FFe bug
[14:30]  * xnox hrw +1 point after FTBFS on the rebuilds. Current Balance: 0.
[14:31] <hyperair> xnox: i use reprepro, but i don't really feel up to apt-get update.
[14:31] <hyperair> xnox: when you've got loads of PPAs and live in a region where canonical's servers are slow..
[14:31] <hyperair> well.. you don't really feel like doing apt-get update just for a single package you have locally
[14:31] <hrw> hyperair: apt-cacher-ng on router (with hdd) helps
[14:31] <hyperair> hrw: it does, but for some reason apt-get update still takes a long time.
[14:32]  * tumbleweed develops against snapshots that are 6-12hours old and it's never been an issue (I guess I just stay clear of the fast-moving stuff)
[14:32] <hyperair> apt-cacher-ng caches debs well enough, but doesn't do so well with package indexes.
[14:32] <hrw> dpkg-deb: building package `torcs-data-tracks' in `../torcs-data-tracks_1.3.3-5ubuntu1_all.deb'.
[14:32] <hrw> yay:)
[14:32] <tumbleweed> apt-cacher-ng is terrible with indexes, and even worse with pdiffed indexes
[14:32] <hyperair> yeah that
[14:32] <hyperair> squid might do better
[14:37] <ogra_> approx ftw !
[14:38] <hyperair> approx?
[14:39] <hyperair> oh nice.
[14:39] <hyperair> is it more stable than acng?
[14:39] <ogra_> apt-cache show approx ?
[14:39] <ogra_> :)
[14:39] <hyperair> ?
[14:39] <hyperair> is it?
[14:39] <ogra_> dunno, i have never used any other package cacher
[14:39] <ogra_> its rock solid though
[14:40] <hyperair> hmm
[14:40] <hyperair> no problems whatsoever?
[14:40] <hyperair> i should try it out
[14:40] <hyperair> i wonder if i can import my existing archives
[14:47] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek is starting in a bit more than 10 minutes in #ubuntu-classroom
[14:49] <dholbach> ogra_, bilal, barry: ready for later on?
[14:49] <ogra_> no, but i will be if i'm up to speak :)
[14:53] <PaoloRotolo> Hi all!
[14:57] <bilal> dholbach: yup :)
[14:57] <dholbach> awesome
[14:59] <barry> dholbach: getting there :)
[14:59] <dholbach> great
[14:59] <barry> dholbach: is it a problem if i have 3 hrs worth of material? :)
[14:59] <dholbach> not at all :)
[14:59] <dholbach> ok, got to start :)
[15:10] <siretart> stgraber: just curious, does ltsp in quantal netboot the thinclients with root on nfs using live-boot?
[15:23] <smoser> is it acceptable to write a file in /etc/ in a post install?
[15:24] <smoser> to avoid it being a conf file ?
[15:24] <smoser> and only create if non-existing and only remove on purge?
[15:25] <stokachu> xnox, sconklin : feel like doing multi-arch sru reviews? :D:D
[15:26] <xnox> stokachu: you still have some?! =)
[15:26] <stokachu> xnox: yea all the ones from last week's meeting
[15:27] <stokachu> i know slangasek is busy so i dont want to nag
[15:28] <siretart> smoser: if you create it, I see no problem with it, but you need to pay special attention wrt. preserving local changes on upgrade. the ucf package may help with that
[15:30] <smoser> siretart, well my thought was to never change it.
[15:30] <smoser> only write the initial
[15:30] <smoser> and then only if it did not exist.
[15:31] <siretart> smoser: what if the local admin deleted the file and did not want to have it reintroduced on upgrades?
[15:32] <siretart> with conffiles, dpkg does the right thing here.
[15:34] <smoser> siretart, true.
[15:56] <xnox> I used to be affect by arch:all skew, now I am also affected by arch:i386 skew =/
[15:56]  * xnox multiarch.... win?!
[15:57]  * xnox just did a "complex" downgrade of a locally compiled package back to the disto version
[16:07] <Will123456> hey guys. i'm thinking about adding HUD support to blender, but it'd have to be ubuntu specific as the blender devs aren't interested. is this the right place to talk about it?
[16:07] <seb128> Will123456, hey, try #ubuntu-unity rather
[16:08] <Will123456> seb128: thanks :)
[16:25] <xnox> please reject https://code.launchpad.net/~roger.light/ubuntu/precise/mosquitto/fix-972389/+merge/119973 ?
[16:25] <xnox> or should I s/precise/precise-proposed/
[16:25] <xnox> no fix in quantal yet, though
[16:32] <killown> https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035675.html  DONT DO THAT
[16:32] <killown> this alternate CD is a lot useful
[16:33] <killown> I have a raid setup here would be useless if I would need install ubuntu 12.10 from scratch
[16:33] <killown> I ubuntu devels really do that I will need to chance of distro, VERY VERY BAD DECISION
[16:34] <killown> RAID is relatively straightforward to turn on post-install.
[16:34] <killown> MAN how can I install without setup my raid before?
[16:36] <killown> please ignore this request, it's insane
[16:57] <xnox> killown: you would use mini.iso and get all the updates from the internet instead of downloading ~300MB of 0day SRUs
[16:57] <xnox> killown: which has the exact same installer as the alternative installer including RAID.
[16:57] <xnox> killown: sans the package pool, which you will have to pull from the network / mirror
[16:58] <xnox> killown: or the server cd, if your hardware is amd64
[17:00] <seb128> ev, hey, is e.u.c timing out of the start page (like default daily view) a known issue?
[17:01] <ev> seb128: with launchpad=false set?
[17:01] <seb128> ev, no, without it, just opening the page
[17:02] <ev> seb128: oh, so even before you get any content at all you get a timeout?
[17:03] <seb128> ev, right, I get "Loading..." in the table for 30s
[17:03] <seb128> and then "an error occurred..."
[17:03] <ev> oh, that
[17:03] <seb128> like no content
[17:04] <ev> yes - please set launchpad=false for now. There have been a number of speed ups to the launchpad color-coding in trunk, but we're blocked on another RT before those can land
[17:04] <seb128> thanks
[17:04] <ev> (the caching of open ID credentials one)
[17:04] <ev> sure thing
[17:12] <xnox> @pilot out
[17:13] <xnox> but I will be back again later.
[18:50] <stokachu> could someone look at bug https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/941673 it was marked fix released but i doubt a release is present
[18:53] <seb128> stokachu, set it back to triaged, you might want to point the qa team (or bdmurray) to the user who vandalized the bug that way
[18:53] <stokachu> seb128: ok thanks, i tried to set it back the other day it just error'ed on me
[18:57] <trism> doko: I don't think bug 1037566 is fixed, it is still missing the multiarch path to pyconfig.h, http://paste.ubuntu.com/1172348/
[19:20] <stgraber> siretart: ltsp uses nbd and doesn't use live-boot
[22:29] <mterry> jdstrand, on the remote-login-service test suite errors, tedg told me those were expected failures, and he added code to not have the error output cause a test failure