[00:00] <mrooney|w> do you happen to know off-hand if the trend has been towards more or less?
[00:00] <slangasek> mrooney|w: I doubt there's a clear trend; we always stuff as many langpacks on as we can, some releases we manage more, some we manage fewer
[00:00] <slangasek> overall the trend is probably towards "less"
[00:00] <mrooney|w> I'm interested to know to know if Ubuntu is getting bigger or smaller over timem when you subtract the langpacks from the 700MB
[00:00] <mrooney|w> ah ok
[00:04] <RainCT> Survived the reboot with GDM not showing up unless being started manually and /etc/resolv.conf getting "nameserver 127.0.0.1" as content.
[00:05] <RainCT> No visible speed change (forgot to do a benchmark before, will get one now), and I've also seen this: http://img215.imageshack.us/img215/1502/10092009118.jpg
[00:05] <RainCT> although maybe the ML would be a better place to say all this :P
[00:06] <bluefoxicy> http://static.arstechnica.com/windows_linux_bb_9.png
[00:06] <bluefoxicy> I can't figure out how "hundreds of updates a month" are hard to maintain in the context of Ubuntu specifically
[00:07] <RainCT> bluefoxicy: Why do you even look at such stuff? :)
[00:07] <bluefoxicy> this is a direct lie and false advertisement, even out of context.  In context, ... we're talking about netbooks, aimed at end-users in freaking Best Buy, who just turn on Automatic Updates in whatever OS they use.
[00:08] <bluefoxicy> RainCT:  Actually what's interesting me here is that encouraging the dissemination of false information about a specific business competitor by a third party may be slander, unethical, and illegal.
[00:09] <bluefoxicy> Microsoft basically directly attacked Canonical, LTD with libelous written-word falsehoods and encouraged a third party to repeat the written word as slanderous spoken word in a false advertisement campaign.
[00:10] <mdz> mathiaz, not necessarily, but I think you should ask him for help diagnosing whether it is an apt bug or a packaging bug (and what the problem is exactly)
[00:38] <TheMuso> slangasek: If you deny an FFE, what do you usually set the bug to? I am responding to the alsa FFe, and don't think its worthwhile at this time, and I want to be sure the status is consistant with other denied FFes.
[00:39]  * TheMuso will just use wont fix for now.
[00:40] <slangasek> TheMuso: didn't I already mark that 'wontfix'?
[00:41] <TheMuso> slangasek: don't know, I am just responding to bug mail as I go through it. If you did already, then sorry. :)
[01:01] <Riddell> jdstrand: I've no plans to upload qt4, did you do your upload?
[01:10] <ScottK> Riddell: I saw it recently listed as building in their PPA
[05:49] <liw> is there any chance that the gdu-notification-daemon dialog can be shut up so it doesn't uselessly whine at me every time I log in?
[06:40] <dholbach> good morning
[07:02] <pitti> Good morning
[07:02] <pitti> kirkland: test .dmrc> just select a different session (like "xterm") or a different keyboard layout and check ~/.dmrc that it has the setting afterwards (and that it exists in the first place)
[07:03] <pitti> kirkland: will look at the bug and comment there; thanks for working on this!
[07:20] <dholbach> is anybody else waiting for a upload confirmation of LP too?
[07:22] <pitti> I'm waiting for LP to display my bugs, or file one
[07:22] <pitti> it keeps timing out
[07:33] <dholbach> pitti: * spm has changed the topic to: ** Launchpad Is Having Issues atm ** | [.......]
[07:34] <spm> pitti: dholbach: fwiw, edge appears unaffected, only lpmain seems to be having woes.
[07:34] <pitti> hm, not really
[07:35] <pitti> filing a bug on edge times out as well
[07:35] <spm> heh. I'll rephrase - I have a sea of nagios red on lpmain; not on edge :-)
[07:35]  * dholbach goes back to all the emails he wanted to write for a longer while
[07:36] <dholbach> pitti: how can I submit a crash report to LP later on?
[07:36] <dholbach> I just got "502: bad gateway"
[07:36] <pitti> spm: heh, ok; so then I'll just hope that fixing production will magically fix edge, too :)
[07:37] <pitti> dholbach: cancel, and then click on /var/crash/... in nautilus or ubuntu-bug /var/crash/... later on
[07:37] <spm> pitti: you and me both... :-)
[07:37] <dholbach> pitti: thanks, I'll do that
[07:37] <dholbach> it's funny: LP is broken, then I decide to do emails, then evo crashes on me and I can't send the crash report in
[07:37] <dholbach> seems like I should do something completely different today
[07:38] <dholbach> I know it sounds a bit like "my dog ate my homework" :)
[07:38] <pitti> dholbach: same for me; I was supposed to debug an X hang on suspend, and kernel -10 broke suspend
[07:38] <liw> dholbach, I had that happen once in school
[07:39] <liw> dholbach, although it happened to the teacher
[07:39]  * StevenK tries to convince edge to talk nicely to him
[07:39] <dholbach> liw: the dog's teacher ate your homework? sounds like you were on the safe side then and nobody could accuse you of shamelessly lying :)
[07:39] <liw> dholbach, yes :)
[07:40] <liw> the whole class's homework, to be exact
[07:40] <StevenK> Haha, way cool
[07:40] <dholbach> nice :)
[07:44] <YokoZar> What package has the "system restart required" notifier?
[07:44] <YokoZar> I don't think it's update manager
[07:44] <dholbach> update-notifier
[07:44] <YokoZar> thanks dholbach
[07:49] <YokoZar> dholbach: actually I'm not sure that's it either.  I'm talking about the actual "System restart required.  In order to complete the update of your system, it needs to be restarted.  Until you do so, security updates..."
[07:49] <YokoZar> grepping through update-notifier and update-manager doesn't give me that as a string anywhere :(
[07:50] <dholbach> you mean the upgrade from one distro release to another?
[07:50] <YokoZar> No like after you install a kernel update
[07:50] <slangasek> no, it is update-notifier
[07:51] <YokoZar> hmm maybe I'm looking wrong
[07:51] <slangasek> the strings are provided by the individual packages
[07:51] <dholbach> daniel@miyazaki:~/update-notifier-0.87$ grep -ri restart * | wc -l
[07:51] <dholbach> 125
[07:51] <dholbach> daniel@miyazaki:~/update-notifier-0.87$
[07:51] <dholbach> there's a lot of restart in there :)
[07:53] <\sh> where is the gnome .desktop entry gone after latest karmic updates? ;)
[07:55] <pitti> \sh: you mean the gnome session in gdm?
[07:55] <\sh> pitti: yepp
[07:55] <pitti> \sh: sounds like bug 426800
[07:55] <YokoZar> ah, found it in the .ui dialog
[07:56] <YokoZar> I guess this makes sense
[07:57] <\sh> pitti: ihh...sounds like removing xfce will bring it back then...
[07:58] <superm1> \sh, just xubuntu-default-settings for now
[07:58] <superm1> once the proper solution is in place for gdm to use default.desktop, those hacks can be dropped on mythbuntu-default-settings and xubuntu-default-settings
[08:01] <\sh> superm1: I wanted to remove xubuntu anyways..cause I don't use it .. just installed it earlier to test something...
[08:02] <ivoks> pitti: hi! around?
[08:04] <pitti> ivoks: hey
[08:04] <ogra> Keybuk, ??
[08:04] <pitti> superm1: second-next on my list
[08:04] <ivoks> pitti: hey, regarding bug 426652
[08:04] <ivoks> pitti: you've acked the upload
[08:04] <pitti> right after unbreaking DVD builds
[08:06] <ivoks> pitti: there's an issue with compression level of orig.tar.gz in ubuntu's package; so, if you could upload it manually, that would be great :)
[08:08] <pitti> oh, fakesync?
[08:09] <ivoks> don't know what fakesync is :/
[08:09] <StevenK> spm: Edge now gives 'please try again' immeadiately
[08:10] <spm> StevenK: yes
[08:10] <StevenK> spm: Oh, so you know. Okay. :-)
[08:10] <spm> :-)
[08:10] <spm> yes. sorrry. terse atm :-)
[08:15] <pitti> ivoks: -ENOLAUNCHPAD, sorry; can you assign it to me and ask for a fakesync in the bug?
[08:19] <pitti> ivoks: (later on, I mean, when it comes back)
[08:26] <ivoks> pitti: sure
[08:26] <spm> ** launchpad should be back to normal now **
[08:27] <slangasek> whee
[08:28] <slangasek> spm: thanks :)
[08:28] <pitti> spm: merci
[08:31] <pitti> oh, now going offline?
[08:31] <cjwatson> pitti: I think I already muttered about fakesync when denying the archive admin request in that bug
[08:32] <pitti> ivoks: ah, I get the bug now; doing
[08:32] <ivoks> pitti: awesome, thanks!
[08:43] <seb128> shrug, edge is not able to reassign bugs since yesterday
[08:43] <seb128> it keeps timeouting
[08:47] <seb128> bah, edge keeps timeouting and that drops the comments I write when going back
[08:48] <seb128> very annoying
[08:48]  * seb128 switches to non edge
[09:08] <apachelogger> ArneGoetje: language-selector gnome and qt are so incredibly different, it's not even funny
[09:10]  * pitti chuckles
[09:10] <pitti> $ sudo service network-manager start
[09:10] <pitti> Rather than invoking init scripts through /etc/init.d, use the service(8)
[09:10] <pitti> utility, e.g. service network-manager start
[09:10] <pitti> Keybuk: hmm... ^ want a bug for that somewhere?
[09:11] <ArneGoetje> apachelogger: I know. And I'm trying to port some of the functionality from the gnome to the qt version
[09:13] <apachelogger> ArneGoetje: IMHO the qt thing needs a complete rewrite
[09:13] <apachelogger> it's ab abomination of Qt
[09:14] <slangasek> pitti: hmm, and does it know not to spit that out when called from rc?
[09:19] <pitti> slangasek: I didn't see those on boot, but then again it's made very quiet by default
[09:19]  * slangasek nods
[09:23] <ArneGoetje> apachelogger: I won't be able to do that as I have no idea about qt or pyqt. I just want the combobox for input method choosing to get in.
[09:24]  * apachelogger aint got no idea about python :D
[09:24] <apachelogger> ArneGoetje: combobox population implemented, moving on to applying the setting
[09:25] <ArneGoetje> apachelogger: is my description in the mail enough for you to understand what's going on?
[09:26] <apachelogger> ArneGoetje: sure :)
[09:26] <soren> Is there a 64 bit equivalent to htonl?
[09:26] <ArneGoetje> apachelogger: thanks a lot for helping out :)
[09:55] <slangasek> pitti: <blink> I'm cc:ed on this mail because... I filed bad FFe requests? :-)
[09:56] <pitti> slangasek: heh, no; "CC" FYI, not because it's aimed at you :)
[10:16] <slangasek> pitti: huh, how were you able to conclude that quickly that bug #427224 was bugfix-only?
[10:16] <pitti> slangasek: I read the upstream changelog
[10:16] <slangasek> http://launchpadlibrarian.net/31581311/pulseaudio-changelog.txt?
[10:17] <slangasek> half of those one-liners are completely opaque to me, so I have no idea if they're bugfixes :/
[10:18] <apachelogger> ArneGoetje: btw, did you take a look at making kde langpacks depend on kde-l10n-$code? Riddell said that youd give that a shot IIRC
[10:18] <pitti> hm, they mostly sounded like code cleanup; and it's just rc -> final, too, and TheMuso also said it's just bug fixes
[10:19] <slangasek> ah, so he did
[10:19] <Riddell> apachelogger: recommend I think rather than depend
[10:19] <apachelogger> something default-installish at least :D
[10:23] <ArneGoetje> apachelogger: it's in the latest language-selector code. please give it a try. when starting up, l-s should give a message about missing packages for the given language. the check should include several kde related packages now.
[10:24] <apachelogger> Missing: ['kde-l10n-engb', 'gnome-user-guide-en', 'kde-l10n-es', 'language-pack-gnome-es', 'gnome-user-guide-es', 'openoffice.org-l10n-es']
[10:24] <apachelogger> sweet
[10:24]  * apachelogger hugs ArneGoetje
[10:24] <ArneGoetje> apachelogger: see data/pkg_depends in the source tree
[10:31] <StevenK> ArneGoetje: We will just sync the new ibus into karmic?
[10:33] <slangasek> StevenK: the new upstream version?
[10:35] <StevenK> slangasek: At this point, just trying to figure out the plan, so ... maybe?
[10:40] <ArneGoetje> StevenK: I think so. Unless you have any reason not to do so...
[10:41] <StevenK> ~,
[10:42] <apachelogger> mvo: bzr upgraded the app-install-data-ubuntu branch, should now be a bit faster :)
[10:43] <apachelogger> good thing that bzr2 is supposed to handle large histories better
[10:44] <mvo> apachelogger: wehh, great :)
[10:44] <mvo> apachelogger: many thanks (also for your work on software-store!)
[10:44] <apachelogger> ArneGoetje: lp:~apachelogger/language-selector/karmic-qt++ merge r273..274
[10:44] <apachelogger> mvo: I didn't do work on software-store?
[10:45] <mvo> apachelogger: eh, typo - software-properties
[10:45] <mvo> apachelogger: my fingers auto-complete software- to software-store these days it seems ;)
[10:46] <apachelogger> oh, yeah, that also needs some more love still :)
[10:46] <apachelogger> work all over the place, but fist utf8ing in apturl-kde
[10:46] <apachelogger> Riddell: btw, did you ever consider implementing that stuff in some python module?
[10:47] <apachelogger> def _ and def utf8 are a perfect example of code duplication
[10:47] <ArneGoetje> apachelogger: thanks a lot
[10:56] <Riddell> apachelogger: well it's all a cludge the utf8 stuff, I'm hoping python 3 will fix it
[10:58] <apachelogger> Riddell: ScottK said that it will still be some time until that becomes default, so I think that a more maintainable implementation would be a good idea :)
[11:05] <Keybuk> pitti: bug for what?
[11:05] <pitti> Keybuk: "service" saying that you should run "service"
[11:05] <Keybuk> pitti: that's a server bug
[11:05] <Keybuk> err service bug
[11:05] <pitti> ok, sysvinit then?
  kees: could you set OGRA=n on that script? :)
[11:07] <ogra> Keybuk, that was in my lastlog output without much context, mind explaining what you were referring to ?
[11:07] <ogra> did i trash something without knowing ?
[11:08] <Keybuk> ogra: don't worry ;)
[11:08] <ogra> ok :)
[11:09] <Keybuk> I believe I was making light fun of your occasional habit of panicing about things unnecessarily
[11:09] <Keybuk> just like that init script was doing ;)
[11:09] <ogra> ah :)
[11:12] <pitti> done, bug 427277
[11:57] <stooj> Hi all. I've written a wee gui in python. How can I graphically prompt for a sudo password?
[11:59] <pitti> stooj: ideally you wouldn't need to; but first, what is wee?
[12:00] <stooj> pitti: Heh. Sorry. Wee = small.
[12:00] <pitti> ah
[12:00] <stooj> pitti: I have a collection of DVDs that used to be part of a LinuxMCE collection.
[12:00] <pitti> stooj: so, the "modern" way of doing privileged things is to have a d-bus backend with PolicyKit-protected functions
[12:01] <pitti> and GUIs running as normal user, calling the d-bus functions
[12:01] <pitti> if your frontend itself needs root privileges, then start it through gksu in its .desktop file
[12:01] <pitti> e. g. /usr/share/applications/synaptic.desktop
[12:02] <stooj> OK. The gui just runs an mount command when you choose a file in a filepicker
[12:02] <pitti> eww
[12:02] <stooj> So, d-bus would be the way to go.
[12:02] <stooj> Bad?
[12:03] <pitti> stooj: well, devicekit-disks already provides that d-bus interface for mounting for you
[12:03] <pitti> and you don't even need to  mess with d-bus yourself; if you have GNOME, you can call gvfs-mount from python
[12:04] <pitti> there's a nice library libgdu for this, but it doesn't have a Python binding right now
[12:04] <pitti> but doing the mount through devkit-disks should be okay
[12:05] <pitti> stooj: you can just call "devkit-disks --mount /dev/sdc1", or (for more control), call the corresponding d-bus method
[12:06] <stooj> Wow. OK.
[12:07] <stooj> Any documentation in particular I should look at for that?
[12:08] <pitti> stooj: http://hal.freedesktop.org/docs/DeviceKit-disks/ is pretty comprehensive
[12:08] <pitti> "man devkit-disks" should probably get you going in 2 minutes
[12:09] <pitti> Keybuk: just as a warning, I uploaded a new gdm to fix an alpha-6 bug; this has a higher version number than your PPA
[12:10] <stooj> Many thanks pitti!
[12:22] <Keybuk> pitti: no problem
[12:22] <Keybuk> "bzr update" for me ;)
[12:24] <Keybuk> pitti: talking of which, any idea when all of the network-manager updates in the bzr branch will be uploaded?
[12:25] <apachelogger> mvo: any objections to making apturl use debhelper 7 automation?
[12:30] <Keybuk> http://img193.imageshack.us/img193/9544/travislaptopkarmic20090.png
[12:30] <Keybuk> ^ I wonder what the "exe" is
[12:33] <Keybuk> pitti: you have the mysterious "exe" in your graph too
[12:33] <Keybuk> but it goes away again after the first boot
[12:33] <Keybuk> wonder whether it's an ext4 thing
[12:36] <mvo> apachelogger: no
[12:37] <cjwatson> apachelogger: dh7++
[12:37] <cjwatson> (for whatever that's worth :-) )
[12:38] <apachelogger> hehe
[12:39] <jdstrand> Riddell: not yet, but will today for sure
[12:40] <liw> dh7: the power of cdbs, and the obfuscation of cdbs, but with the good taste of joeyh
[12:40] <directhex> yum yum joeyh
[12:44] <apachelogger> mvo: should apturl get bug reports related to encoding within the next few days, then I seriously screwed up ... now encodes to utf8 all over the place (as seen in gdebi)
[12:45] <apachelogger> other than that is apturl-kde all awesome now and lintian all happy again
[12:46] <mvo> apachelogger: wonderful, I think if its following gdebi, then we should be fine
[12:47] <apachelogger> *nod* I still think we should move that stuff to one module imported by all of our pyapps though
[12:47] <evand> pitti: am I okay to reopen bug 395103, given your discovery in the upstream report that the existing patch breaks variants?
[12:51] <ogra> Keybuk, the exe ?
[12:51] <ogra> Keybuk, clearly the first steps of http://www.tuxradar.com/content/ubuntu-rewrite-linux-kernel-using-mono
[12:53] <apachelogger> about time
[13:44] <kelemengabor_> Heya
[13:44] <kelemengabor_> yeah, that is the penguinfucker's night
[13:46] <cjwatson> kelemengabor_: that's unnecessary; please cut it out
[13:46] <kelemengabor_> cjwatson: nevermind
[13:47] <kelemengabor_> just I try little spammer troll-bot
[13:47] <cjwatson> try it somewhere else
[13:47] <kelemengabor_> it is run under ubuntu sucked penguin 12.4 release candidate
[13:50] <liw> hm, that's the third troll/spammer I see in two days
[13:54]  * ScottK notes the +o came less than a minute after the initial troll.  Very solid reaction time.
[13:54] <cjwatson> it only took that long because for some reason my /op alias wasn't working
[13:55] <cjwatson> oh, that's because I called it /opself, bah
[13:57] <liw> heh, I had a habit of using my native language for naming scripts, aliaes, and other such things I wrote for myself, so they'd not be confused with stuff that came from elsewhere
[13:57] <ogra> Keybuk, geez, thats an insanely long changelog
[13:57] <liw> then I kept forgetting which native language I used in each instance, since I have to choose from
[13:57] <ogra> (sysvinit)
[14:04] <pitti> Keybuk: I noticed that I get a couchdb instance started, for no reason; that's a bug as well; perhaps "exe" is something from erlang
[14:05] <Keybuk> no, the exe is happening inside the initramfs
[14:05] <pitti> Keybuk: network-manager> redirecting to asac; I don't know
[14:09] <asac> dont see the question. repost please ;)
[14:10] <cjwatson> exe> presumably /proc/$pid/exe
[14:12] <rgreening> pitti: I need some assistance with build_kdeui in python-distutils-extra and using the kde ui file to generate translations in the usb-creator project. I am at a loss. I see build_kdeui can generate a .py file, but my app uses the pyqt.uic.loadui method to load the ui directly rather than a compiled version.
[14:13] <rgreening> pitti: so, I was wondering what the correct way to generate the necessary pot info sould be for this project to combine with the gtk pot/po (if you have some pointers)
[14:14] <pitti> rgreening: hi
[14:16] <pitti> rgreening: for .ui> right, Apport still uses loadUi() as well; your setup.py manually needs to install the *.ui files in data_files
[14:17] <pitti> rgreening: I spoke with some KDE devs, and they said that the preferred way would be to build and ship the .py files instead, which is why distutils-extras does that by default; but you don't need to use that, of course
[14:17] <rgreening> pitti: done that. so it loads the ui fine. The issue at hand is getting the translations template to include my stuff in the ui
[14:17] <pitti> rgreening: pot> usually you just have one domain for the project, and try to share as many strings between the projects as possible; you want to have several domains?
[14:17] <pitti> ah
[14:18] <rgreening> pitti: no, want to merge to domain usbcreator
[14:18] <asac> anyone knows a eager + not-so-overloaded debian ftpmaster?
[14:18] <rgreening> just to make sure we don't miss any differences
[14:19] <pitti> it's not picking them up automatically?
[14:19] <rgreening> pitti: for example, I use Close not Exit, in the window. there are some minor differences.
[14:19] <rgreening> nope.
[14:19] <pitti> rgreening: indeed, seems you found a bug
[14:19] <rgreening> pitti, maybe you could have a look at usb-creator in lp and see what I may be doing wrong
[14:19] <Riddell> rgreening: we use extractrc to extract strings from .ui files, see the script extract-messages.sh
[14:19] <pitti> rgreening: mind to report it against python-distutils-extra? I'll fix it ASAP, but probably not today
[14:19] <rgreening> Riddell: doesn't that require cdbs
[14:20] <florian__> Hey guys. I saw that UIFreeze is in place for Karmic. Is there a place we can see what it will look like ? I search the wiki with no success.
[14:20] <Riddell> rgreening: no, it's from upstream KDE
[14:20] <cjwatson> asac: pick on one of http://lists.debian.org/debian-devel-announce/2009/08/msg00004.html ?
[14:20] <rgreening> Riddell: are there any required deps to ensure extract-messages is called?
[14:20] <pitti> florian__: grab the current daily CD and start the live system?
[14:20] <Riddell> rgreening: I did say I'd look at i18n for usb-creator, although I utterly failed to get to it yesterday I'm afraid
[14:21] <florian__> pitti: not a bad idea... is there anything easier ?
[14:21] <rgreening> pitti: I'll try what Riddell suggest first. If it still doesn't work as expected, I'll open a bug report.
[14:21] <Riddell> rgreening: cdbs kde.mk will call it, you can also call it any other way you wish.  it uses Messages.sh files
[14:21] <asac> cjwatson: good idea. fresh blood :)
[14:21] <pitti> rgreening: cool, thanks
[14:22] <rgreening> Riddell: so I include a Messages.sh and where do I call extract-messages.sh? In the makefile I assume
[14:22] <rgreening> pitti: ty. I'm so not good with translations :)
[14:22] <kirkland> cjwatson: in qemu-kvm, we have a very simple shell script called 'kvm-ok' that basicly does egrep "flags.*:.*(svm|vmx)" /proc/cpuinfo
[14:22] <kirkland> cjwatson: i often ask people to run that, to tell me if they have VT
[14:22] <pitti> rgreening: don't worry; distutils-e is supposed to extract them, but it seems that fails for some reason
[14:23] <kirkland> cjwatson: i was thinking that script belongs somewhere more basic than qemu-kvm package
[14:23] <cjwatson> kirkland: oh, I dunno, qemu-kvm sounds OK
[14:23] <rgreening> pitti: what are the requirements to enable it to extract them?
[14:23] <cjwatson> we don't really have any more general place that I can think of
[14:23] <kirkland> cjwatson: because i often tell them to run kvm-ok, which they run that script, find out they can't do VT, and then uninstall the package
[14:23] <pitti> rgreening: me fixing the bug, I suppose :)
[14:23] <rgreening> maybe I misses something
[14:23] <rgreening> lol
[14:23] <kirkland> cjwatson: i was thinking pciutils, perhaps
[14:23] <pitti> rgreening: you can of course have a manual po/POTFILES.in with everything
[14:23] <cjwatson> kirkland: stick it on a web page then :)
[14:23] <cjwatson> well, maybe shell scripts on web pages not a great plan
[14:24] <cjwatson> kirkland: pciutils doesn't make sense to me, but I can't think of anywhere better
[14:24] <rgreening> pitti: does the kdeui file need to be tagged with a special tag in POTFILES.in? like the text: gettext/glade is?
[14:24] <kirkland> cjwatson: web page didn't do it; telling people to do that grep didn't do, hence the stupid script
[14:24]  * rgreening wishes there was documentation for all this :)
[14:25] <kirkland> cjwatson: it can stay where it is, i suppose; i was just thinking that it's a little strange to install a package to run a script to tell you if you can use the package at all; would be nice to know that ahead of time
[14:25] <pitti> rgreening: I know that GtkBuilder .ui files work with "[type: gettext/glade] file.ui"
[14:25] <rgreening> pitti: so, does the kde ui have an equiv?
[14:26] <pitti> rgreening: hm, according to intltool-extract(8) apparently not :-(
[14:26] <rgreening> heh
[14:27] <pitti> it should really..
[14:28] <rgreening> pitti: should the setup be using auto mode for this to work?
[14:29] <pitti> rgreening: well, it won't make much difference; if intltool can't handle them, then auto mode can't do magic
[14:29] <rgreening> ok
[14:32]  * rgreening wishes translations were easier :) or at least more documented :)
[14:32] <rgreening> Riddell: so, if I want to merge the .pot into the same domain, the sample Messages.sh I have assumes a seperate domain.. suggestions?
[14:33] <pitti> rgreening: you want to merge two .pot files? I think msgcat can do that
[14:34] <pitti> (untested)
[14:34] <rgreening> msgmerge maybe also?
[14:34] <pitti> I don't think so
[14:34] <pitti> that joins on msgids
[14:34] <rgreening> ah, so that may be what I was doing wrong
[14:34] <rgreening> haha
[14:35] <rgreening> pitti: you are golden :P
[14:35] <rgreening> I'll try the msgcat...
[14:36]  * rgreening really wants to ship usb-creator-kde with working translations
[14:36] <kirkland> cjwatson: do you ack, nack, or abstain, on the move of kvm-ok from kvm to pciutils?
[14:37] <kirkland> cjwatson: i ask because we're about to do a qa community call for testing of kvm, and the qa team wants to give the community easy instructions to find out if they can participate or not
[14:37] <Laney> oh dear
[14:37] <cjwatson> kirkland: abstain leaning towards nack; it's not a pci thing
[14:37] <Laney> I shouldn't have remotely updated with the new boot stuff
[14:37] <kirkland> cjwatson: fair enough, thanks
[14:37] <ScottK> Laney: Defintely not.
[14:38] <Laney> dhcp-20-65:~ laney$ ssh laney@home.orangesquash.org.uk
[14:38] <Laney> ssh: connect to host home.orangesquash.org.uk port 22: Connection refused
[14:38] <Laney> :(!
[14:38] <Daviey> Laney: no worries, use the serial console to resolve it :P.
[14:39] <Laney> oh yeah... that...
[14:39] <Laney> nah it's my workstation at home, I can just prod it when I get back later
[14:47] <rgreening> pitti: just to confirm, if this was working as expected, I wouldn't need to add build_kdeui to my setup.py nor call it, as the build_il8n (in theory) would handle the kde ui file if listed in the po/POTFILES.in, correct?
[14:47] <rgreening> if so, then I'll file a bug to get that working.
[14:47] <pitti> rgreening: those are two entirely different things
[14:47] <YokoZar1> slangasek: Just a heads up, one last UI change that I hoped to sneak through after mpt and I discussed: http://yokozar.org/blog/archives/142  -- I uploaded a bzr branch just before feature freeze, though the package isn't live yet.
[14:48] <pitti> rgreening: extracting strings from KDE *.ui files to the POT doesn't work, and needs intltool support
[14:48] <rgreening> yeah, just wanted to confirm that kdeui was something different than what I was trying to achienve
[14:48] <pitti> rgreening: build_kdeui is for compiling *.ui into *.py files which you would ship instead of the *.ui files
[14:48] <rgreening> ya. cool. Ok, I'll file a bug about the second part then. ty pitti
[14:51] <jcastro> Keybuk: fyi I filed bug 421422 about the desktopcouch launching xulrunner
[14:51] <jcastro> Keybuk: sorry, I meant bug 427036
[14:55] <soren> doko: Is python-central still our preferred python packaging system?
[14:56] <Keybuk> jcastro: cool, can you subscribe me
[14:57] <rgreening> pitti: bug 427358
[14:58] <jcastro> Keybuk: done, you don't have a boot tag for bugs or anything do you?
[14:58] <Keybuk> no
[14:58] <Keybuk> (since you can't subscribe by tag)
[14:58] <jcastro> I see
[15:09] <ScottK> soren: On the off chance you care, the Debian Python teams have picked python-support to standardize on.
[15:10] <soren> ScottK: Is python-central frowned upon?
[15:10] <soren> ScottK: Or is it just a preference?
[15:10] <ScottK> The DD that sponsors ~70% of sponsored uploads for those packaging teams will no longer sponsor python-central stuff.
[15:11] <ScottK> The perception in Debian is that python-central is not maintained.
[15:12] <ScottK> My view is that each one has it's advantages and disadvantages.  Python-support has improved a lot recently.
[15:14] <soren> ScottK: Ok, thanks.
[15:15] <pitti> Keybuk: $ sudo stop -q anacron
[15:15] <pitti> stop: Unknown instance:
[15:15] <pitti> Keybuk: anacron isn't a daemon, so does that command even make sense?
[15:15] <pitti> Keybuk: (it's in /usr/lib/pm-utils/sleep.d/95anacron and currently breaking suspend)
[15:16] <pitti> I'm not quite sure whether it should be a daemon, controlled by /etc/init/anacron.conf, or a cronjob, controlled by /etc/cron.d/anacron
[15:17] <pitti> Keybuk: but the manpage doesn't talk about a daemon at all, and ancron -s just processes pending jobs and returns
[15:19] <cr3> mathiaz: do you think it would be reasonable to reuse bug #426613, regarding checkbox 0.8.2, in order to apply for a FFE?
[15:19] <Keybuk> pitti: I already fixed that in the PPA
[15:19] <Keybuk> "stop anacron" *will* stop any running anacron instance
[15:19] <Keybuk> ie. if cron.daily is underway
[15:19] <pitti> Keybuk: great, thanks
[15:19] <Keybuk> which is what the sleep.d is trying to do
[15:20] <Keybuk> it just needed an || :
[15:20]  * pitti dist-upgrades -- lots of new stuff
[15:21] <Keybuk> just minor tweaks
[15:22] <Keybuk> pitti: I'm surprised that I haven't got any of one bug report, and more more of another
[15:22] <Keybuk> the one I've had a couple of reports of, which I expected, is the "computer just sits on boot with the hard drive light on"
[15:22] <Keybuk> ie. fsck running ;)
[15:22]  * Keybuk hadn't hooked the progress stuff up yet
[15:23] <pitti> Keybuk: argh, dist-upgrade just killed my session again
[15:23] <Keybuk> the other is that gdm is currently started even in recovery mode ;)
[15:23] <pitti> does anything there restart gdm or so?
[15:23] <Keybuk> pitti: nope
[15:23] <Keybuk> I think X crashes
[15:24] <superm1> pitti, for your 15_default_session, it looks like the file name is favors is default.desktop, not default.session, correct?
[15:24] <superm1> or would either work?
[15:24] <pitti> superm1: erm, sorry, yes; I meant xsessions/default.desktop
[15:24] <superm1> no problem, thanks :)
[15:25] <Laney> Keybuk: Might have something for you later... when I discover why my PC didn't boot ;)
[15:25] <Keybuk> Laney: ?
[15:25] <Laney> I upgraded to the PPA and it never came back up
[15:26] <Keybuk> Laney: I'd like to help with that "discovery" :)
[15:26] <Laney> well I'll be going home in a couple of hours so we can check it out then
[15:26] <Keybuk> ok
[15:26] <Keybuk> anything unusual or non-standard about your setup?
[15:26] <Keybuk> in particular, the contents of your /etc/fstab /
[15:27] <Laney> I've got it partitioned into a few LVs
[15:27] <Laney> across... 4 disks I think
[15:28]  * seb128 grrrs at Keybuk for opening a collection of tasks on the same bug
[15:28] <seb128> which means spamming everybody subscribed to any of those components
[15:29] <Laney> Boots took ages before anyway, probably because it's been upgraded since forever (http://orangesquash.org.uk/~laney/chicken-karmic-20090910-1.png)
[15:30] <genii> Are there any plans to package Clonezilla?
[15:30] <Keybuk> seb128: I was told to do it that way <g>
[15:30] <seb128> who told you to do that?
[15:30] <Keybuk> seb128: robbie
[15:30] <Keybuk> besides, that's how LP is supposed to work ;)
[15:30] <seb128> robbiew, could you please not recommend people to do that? ;-)
[15:31] <Keybuk> seb128: just ignore the bug
[15:31] <Keybuk> Laney: huh, lvm taking that long kinda implies that you have an actual problem there
[15:32] <Laney> well I wouldn't be surprised if some of the disks are on the way out (indeed I have ordered the replacements)
[15:32] <robbiew> seb128: if you are talking about the FFE...slangasek recommend that
[15:32] <doko> soren: yes
[15:32] <seb128> *shrug*
[15:32] <seb128> ok
[15:32] <Laney> so yes it could just be a coincidence
[15:32] <seb128> the issue with such bugs is that you get email for every change to any of the tasks
[15:33] <Keybuk> seb128: the counter-argument to that issue is that if you're a bug contact, you should be aware of changes to those packages *and* how they fit in with the other tasks
[15:33] <seb128> ie when there is 19 components you don't care about and one you are subscribed to, you get all the trafic for the 19 other by email
[15:34] <seb128> Keybuk, I just dislike multi-tasking, it makes it also almost impossible to rely comments to your component
[15:34] <Keybuk> I don't really find that it makes much difference
[15:34] <Keybuk> it all ends up in your mail folder anyway either way
[15:34] <Keybuk> it's no worse than having two subscribers to the bug both replying to requests for information
[15:35] <ScottK> The problem is once one package is fixed and you really don't care anymore.
[15:35] <seb128> anyway let's not discuss for hours how launchpad sucks ;-)
[15:35] <pitti>  hm, but having tasks on a bug is how LP is supposed to work
[15:36] <pitti> but it's missing the possibility of unsubscribing from bugs where you don't have open components any more that you are sub'ed to
[15:36] <ScottK> Yep
[15:36] <seb128> pitti, I found that making different tasks basically impossible to track and flooding people by email
[15:36] <seb128> it's fine when a bug needs a change in several components to be fixed
[15:37] <Laney> there was an LP bug about supporting negative subscriptions
[15:37] <seb128> but thinks like freeze exception would be better tracked with different bugs
[15:38] <seb128> if you start mixing question and concern about 15 different components in one bug it becames really hard to read or to find what applies to your component
[15:38] <Laney> bug 204980
[15:39] <pitti> seb128: well, actually you wouldn't want to get these FFEs in the first place, would you?
[15:39] <seb128> pitti, I would like to know what's going on with gdm
[15:39] <seb128> but I don't care about all the other things there
[15:40] <seb128> but right if I could opt-out that would be fine I guess
[15:40] <seb128> which is the bug Laney listed
[15:41] <pitti> *nod*
[15:52] <mathiaz> cr3: yes - bug 426613 can be used to ask for a FFe.
[16:11] <cjwatson> my rule of thumb is that if it's the same bug that needs to be fixed in several places in order for the bug to go away, use tasks
[16:12] <cjwatson> if it's the same issue that is independently present in N different places, then use separate bugs
[16:13] <cjwatson> so, let's say, that bug where upstart and some bit of the installer had to cooperate to get /etc/event.d/tty1 setting up getty properly for 8-bit text, that was a good case for tasks
[16:13] <cjwatson> but something like that mega-bug about all the different packages that need to use dpkg --print-architecture rather than --print-installation-architecture should really have been one bug per affected package
[16:13] <cjwatson> IMO
[16:17] <sgallagh> mathiaz: ping
[16:17] <mathiaz> sgallagh: hey - just sending emails to sssd-devel
[16:17] <sgallagh> mathiaz: Yeah, I saw the first one. I wanted to make sure you pulled in both patches that were likely to affect you
[16:18] <mathiaz> sgallagh: yop - I've also included the proxy enumration patch
[16:19] <sgallagh> mathiaz: Ok, great :)
[16:19] <mathiaz> sgallagh: anything else worth integrating?
[16:20] <sgallagh> mathiaz: Looking at the git log right now :)
[16:21] <sgallagh> mathiaz: I think most of the rest of the patches we've pushed lately have been related to new functionality since 0.5.0, so you should be alright.
[16:21] <mathiaz> sgallagh: there was a thread about testing as well (started by jenny)
[16:21] <mathiaz> sgallagh: are there any tests publicly available?
[16:22] <mathiaz> sgallagh: great! thanks for keeping me in the loop
[16:22] <sgallagh> mathiaz: There are some unit tests available in the tarball
[16:22] <sgallagh> mathiaz: It's hard to make the rest of the tests public, because they rely on the availability of a remote data provider to work (e.g. LDAP and Kerberos)
[16:23] <mathiaz> sgallagh: right - I'm looking into this as well
[16:23] <mathiaz> sgallagh: one option I'm investigation is to use ec2
[16:23]  * pitti looks at /builders..
[16:23] <pitti> amd64  9   7790 jobs (four days)
[16:23] <pitti> i386 15 14434 jobs (three days)
[16:23] <pitti> WTH?
[16:23] <mathiaz> sgallagh: with public AMIs
[16:23] <sgallagh> mathiaz: I'm not familiar with it. Can you give me some details?
[16:24] <pitti> oh, archive rebuild test?
[16:24] <mathiaz> sgallagh: ec2 is amazon's public cloud
[16:24] <mathiaz> sgallagh: it should be possible to create a default ldap+krb infrastructure
[16:24] <sgallagh> Too many acronyms/initializations to keep track of :-P
[16:24] <mathiaz> sgallagh: and run tests in there
[16:24] <sgallagh> That's a very interesting idea
[16:25] <mathiaz> sgallagh: right - it can be a bit overwhelming if you're not following all of this closely
[16:25] <sgallagh> Could we move this discussion to #freeipa? I think there are a few others who'd love to be involved in this
[16:26] <mathiaz> sgallagh: sure
[16:37] <kirkland> cjwatson: is it possible to downgrade a karmic system from grub2 to grub1 ?
[16:42] <cjwatson> install grub, make sure /boot/grub/menu.lst is right, and then run grub-install?
[16:42] <cjwatson> I don't really want to spend time supporting that though ...
[16:43] <kirkland> cjwatson: no problem, i'm trying to work around a bug in vmbuilder, it doesn't work with grub2
[16:47] <cr3> mathiaz: FFE completed, now we play the waiting game. good thing I prepared well before Alpha 6
[17:30] <RainCT> Keybuk: Hey. Tried the boot stuff out with both PPAs now. The first boot worked but took 90 seconds instead of 40 before; now it's failing to boot with: "mountall: unable to write pid file: read-only file system" (and a moment later: "init: module-init-tools main process (xxxx) terminated with status 1")
[17:31] <ion> rainct: In /etc/init/mountall.conf, comment out ‘expect daemon’ and replace ‘exec mountall --daemon...’ with ‘exec mountall --debug...’
[17:31] <mathiaz> mvo: hi
[17:31] <ion> rainct: That should provide a nice amount of debug output.
[17:31] <mathiaz> mvo: I've got another bug for your apt debugging skills - bug 194140
[17:33] <RainCT> ion: there is no such file (nor an /etc/init/ directory)
[17:34] <RainCT> err ignore that
[17:34] <ion> Which both PPAs, btw? ubuntu-boot and
[17:34] <RainCT> Yes, doing what you said now. Stupid me, trying /etc when I have the filesystem in /mnt :)
[17:35] <ion> Ah, i misread what you said. It’s module-init-tools that returns 1, not mountall. The problem is probably not in mountall then.
[17:36] <ion> Do you have /etc/modules?
[17:36] <RainCT> ion: Yes, contains "lp" and "rtc"
[17:39] <RainCT> (both PPAs = ubuntu-boot/ppa/ubuntu and ubuntu-boot/staging/ubuntu)
[17:41] <RainCT> ion: So should I try out the mountall thing?
[17:43] <ion> rainct: Try adding the line ‘console output’ to module-init-tools.conf first, and also add ‘set -x’ as a new line immediately after the ’script’ line.
[17:45] <RainCT> ion: OK. Is "console output" right after author or where should that go?
[17:46] <kees> slangasek: thanks for helping triage 426658.  one down.  :)
[17:48] <ion> rainct: Anywhere, except for inside the script block
[17:48] <RainCT> ok, trying it out..
[17:49] <popey> directhex: when you have a little time, I'm still having issues building tomboy if you wouldn't mind helping me.
[17:57] <seb128> evand, bug #421212 is similar to the one you reopened?
[17:59] <pitti> evand: BTW, I already talked to upstream about that; they don't seem to want to replicate the entire variety of variants and options in hal/gdm..
[18:00] <pitti> since bug 395103 originally was karmic RC, but fixed for most folks, I would either like to see it being closed again and have a new bug for the remaining issues (whcih aren't likely to be fixed in karmic), or downgrade that bug, which changes history
[18:02] <evand> pitti: that's problematic for us, as (as far as I can tell) the current code completely breaks dvorak being set in XKB_VARIANT (see bug 408292)
[18:03] <pitti> okay, but still it's a different cause now; we might need some workarounds for that
[18:03] <pitti> evand: if it's important, can we please bump the prio of bug 421212, set it to karmic, and use that?
[18:04] <evand> absolutely
[18:04]  * pitti doesn't like reopening old bugs
[18:04] <pitti> ok, great
[18:04] <evand> apologies for reopening your old bug
[18:04]  * pitti shuffles bugs
[18:04] <pitti> evand: none needed, just coordinating here :)
[18:04] <RainCT> ion: it doesn't find the rtc module
[18:04] <evand> :)
[18:06] <pitti> evand: how's that now?
[18:08] <ion> rainct: Ok, that isn’t the problem either. Dunno then...
[18:09] <evand> pitti: Looks good.  I just moved mdz's bug to be a duplicate of the new master.
[18:09] <RainCT> ion: well, thanks :)
[18:09]  * RainCT looks at Keybuk
[18:09] <ArneGoetje> apachelogger: any chance we can get the language-selector changes uploaded?
[18:09] <evand> pitti: thanks for sorting that
[18:10] <pitti> evand: thanks to you; I don't have a clear idea yet how to fix that in gdm, since it requires changes in gnome-settings-daemon as well (hopefuully not in the stack below, like libxklavier)
[18:10] <pitti> but I'll have a look at it
[18:10] <evand> best of luck
[18:10] <evand> if you need any help testing, do let me know
[18:10] <pitti> testing should be easy
[18:13] <kees> Keybuk: do you have an ETA for the udev signal bug getting fixed?  I can upload it if you don't have other changes pending (which I suspect you do...)
[18:15] <Keybuk> kees: I'm waiting on an upstream release
[18:16] <kees> okay
[18:17] <kees> Keybuk: is that coming soon?  :)  My VMs keep breaking.
[18:17] <Keybuk> kees: yes
[18:17] <Keybuk> *shrug* karmic ;)
[18:19] <Keybuk> ion: the modprobe failure thing is fixed
[18:19] <Keybuk> though don't know why it would stop the boot
[18:19] <Keybuk> nothing waits for module-init-tools (and even if it did, nothing waits only for success)
[18:20] <ogra> i have a slowdown as well due to modprobe, remember ?
[18:20] <ion> Yeah, it probably isn’t the one stopping the boot. I only wanted the modprobe output in case it had been something like ‘read-only filesystem, can write blahblah’.
[18:20] <ogra> (with my unsupported touchscreen that has no driver and gets probed in a loop)
[18:20] <ion> Which would have strongly suggested an issue in mountall. :-)
[18:20] <ion> Oh, now that i think of it, modprobe probably doesn’t need to write anything ever.
[18:21] <Keybuk> yeah
[18:21] <Keybuk> the virtual 1/2 type lines in the mountall --debug output are the important ones
[18:21] <Keybuk> they tell you why it's waiting
[18:21] <Keybuk> so far, all three people complained have "remote 0/4" or something in there
[18:21] <Keybuk> and I get to do the "I told you not to try it if you had network filesystems" dance
[18:22] <mathiaz> zul: so what's the state of moving puppet into main?
[18:22] <zul> mathiaz: almost done, working on enabling the testsuite
[18:22] <zul> ill take one more crack at it today
[18:22] <mathiaz> zul: great!
[18:24] <Keybuk> (and that's easy to fix 'echo initctl emit net-device-up > /etc/network/if-up.d/somescript' ;)
[18:26] <soreau> Hello. I am having some trouble with snd_46xx on an old thinkpad and I found something that I want to try but I need a modules.conf file which of course doesnt exist. If I create one, where should it go so it will be respected?
[18:28] <Pici> soreau: Under /etc/modprobe.d/
[18:28] <soreau> Pici: ok thanks
[18:29] <Laney> Keybuk: Interested in doing some debugging? sreadahead main process ... terminated with status 1, mountall: unable to write pid file: read only FS, debug pre-start process terminated with status 1, module-init-tools terminated with status 1
[18:55] <mathiaz> zul: there are a lot of puppet dependencies in universe - http://paste.ubuntu.com/268694/
[18:56] <mathiaz> zul: do all the required src packages have MIR written?
[18:57] <mathiaz> zul: it seems that some of them are useless - like rails, wwwconfig-common
[18:57] <zul> mathiaz: dont think so
[18:58] <mathiaz> zul: it seems that the dependencies need to be reviewed - and only relevant one should be kept
[18:58] <mathiaz> zul: before puppet can be moved to main
[18:58] <zul> kees: ^^^
[18:59] <kees> holy cow
[19:00] <kees> zul:  your MIR report said only 3 weren't in main??
[19:00] <zul> kees: uh...wtf
[19:00] <zul> i need to go look at this again
[19:02] <zul> puppetmaster recommends rails
[19:02] <mathiaz> zul: also - one of your upload disables starting puppetmaster at install time - why?
[19:02] <mathiaz> zul: right - I think most of what got pulled in are recommends - these can be dropped to suggests
[19:02] <mathiaz> zul: dropping rails would be a good start
[19:02] <mathiaz> zul: unless puppetmaster requires rails to run :/
[19:03] <zul> mathiaz: i disabled it because it was required for the MIR
[19:03] <mathiaz> zul: hm - in bug 408297? where?
[19:04] <zul> mathiaz: see kees' comment: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/408297/comments/1
[19:05] <mathiaz> zul: are you refering to debian bug 518831?
[19:06] <zul> mathiaz: yes
[19:06] <mathiaz> zul: IIUC the fix is to not start puppetd (ie the client) - I don't think the puppetmaster should be disabled as well
[19:07] <zul> mathiaz: noted
[19:07] <zul> actually its not started as well
[19:09] <mathiaz> zul: bug 427466 - can I assign it to you?
[19:11] <kees> Keybuk: given that alpha6 is next week, do you mind if I upload the udev fix now, just to get it solved?  it may be causing issues with rsyslogd too
[19:11] <zul> mathiaz, of course
[19:20] <superm1> kees, if you do upload, coulud you also cherry pick http://git.kernel.org/?p=linux/hotplug/udev.git;a=blobdiff;f=extras/hid2hci/70-hid2hci.rules;h=e133afd62546a37a598ffd317badd0cb7081823e;hp=b332c168e981682eb58e29699b64f7b154fb6663;hb=8a0217ffd432e56231b0d1bccda71449bca5f8f6;hpb=2ffc9cc1917b1bb6fe86881a94a47dce9aa15168 ?  i was figuring we'd wait till udev 147, unless opportunistic
[19:22] <kees> superm1: sure
[19:25] <zul> mathiaz: you dont need rails for puppetmaster
[19:26] <zul> mathiaz: rails would only be useful for the testsuite
[19:26] <zul> and that seems to be broken atm still :(
[19:26] <mathiaz> zul: right - if the test suite requires rails, it means it will be a build-dependency
[19:27] <mathiaz> zul: and thus rails would have to be moved to main as well
[19:27] <mathiaz> zul: and I don't think this is something we wanna do
[19:27] <mathiaz> zul: (ie moving rails to main)
[19:27] <mathiaz> zul: does all the test require rails?
[19:30] <zul> mathiaz: it needs rails to build
[19:31] <zul> and to run
[19:31] <mathiaz> zul: to build and run the tests?
[19:31] <mathiaz> zul: or to build puppet?
[19:31] <zul> mathiaz: to build and run the tests
[19:32] <mathiaz> zul: hmmm
[19:32] <mathiaz> kees: ^^ what's your opinion on this?
[19:32] <mathiaz> kees: I don't think we should pull rails into main
[19:32] <mathiaz> zul: which part of rails is required?
[19:32] <zul> but there is a MIR for rails that look it got approved
[19:32] <mathiaz> zul: ?
[19:33] <zul> havent got that far yet its still failing for me and im not a ruby expert
[19:33] <mathiaz> zul: I don't a MIR for rails on wiki.u.c
[19:33] <zul> i was wrong about the rails MIR must have been look at something else
[19:33] <mathiaz> zul: I don't *see* a MIR for rails on wiki.u.c
[19:34] <zul> yeah so its not something we want in main
[19:34] <kees> I don't want rails in main
[19:35] <zul> neither do i
[19:35] <mathiaz> kees: zul: great - we all agree then :)
[19:35] <kees> heh
[19:36] <mathiaz> that means tests can't be enable in the build
[19:36] <zul> ill fix that puppet bug then
[19:36] <mathiaz> zul: can they still be run outside of the build process?
[19:36] <mathiaz> zul: ie - could they be packaged separately?
[19:36] <zul> mathiaz: i think so havent tried yet
[19:37] <mathiaz> zul: I think the first step is to try to get them running
[19:37] <mathiaz> zul: if that works try to package them - or leave instructions in a readme file
[19:37] <zul> gotcha
[19:38] <mathiaz> kees: ^^ would that work for you?
[19:40] <kees> mathiaz: you're proposing documentation how to run the tests and verifying that they pass (but not during the build)?
[19:40] <mathiaz> kees: yes
[19:40] <kees> mathiaz: yeah, that seems like a fair compromise
[19:41] <NCommander> any archive admin, can someone binNEW linux-mvl-dove? I'm kinda depwait for that to pass through the NEW queue
[19:48] <kees> superm1: does the hid2hci commit fix a specific LP bug?
[19:49] <NCommander> jdstrand, you around?
[19:50] <jdstrand> NCommander: yeah
[19:50] <superm1> kees, let me see, looks like it was bug 385934
[19:50] <NCommander> jdstrand, can you debinNEW a kernel for me?
[19:50]  * NCommander has been depwait on this since yestreday :-/
[19:51] <kees> superm1: okay, thanks.
[19:53] <jdstrand> NCommander: did you try StevenK or Muharem? (it is thier day)
[19:53] <jdstrand> NCommander: if they aren't available I can do it
[19:53] <NCommander> jdstrand, LP was very unstable last night, so StevenK didn't want to try deNEWing anything at risk of breaking LP, and Muharem doesn't seem to be on (or at least, I can't see him on IRC)
[19:54] <jdstrand> NCommander: is LP any better now?
[19:54] <NCommander> jdstrand, its not 502ing forme anymore
[19:55] <jdstrand> alright
[19:56] <NCommander> jdstrand, thanks, sorry that you keep getting hit with the random kernels
[20:08] <cr3> is there a way to detect whether a script is running in a live environment programmatically?
[20:11] <NCommander> cr3, why?
[20:12] <cr3> NCommander: if I'm running from live, I could easily use echo ubuntu | sudo -S in order to run commands as root without having to prompt the user for a password they might not even know
[20:12] <cr3> NCommander: oddly, I thought there was no password and gksudo wouldn't even ever prompt anyways
[20:12] <NCommander> cr3, sudo should just give you root on the live envirionment sans password
[20:13] <cr3> NCommander: thanks for the confirmation, even better then :)
[20:13] <NCommander> cr3, well, you could just download a livecd and check ;-)
[20:26] <ahe> join #launchpad
[20:37] <robbiew> udevadm trigger is not premitted while udev is unconfigured.
[20:37] <robbiew> Gave up waiting for root device. Common problems:
[20:37] <robbiew> -Boot args (cat /proc/cmdline)
[20:37] <robbiew>   -Check rootdelay= (did the system wait long enough)
[20:37] <robbiew>   -Check root= (did the system wait for the right device?)
[20:37] <robbiew> -Missing modules (cat /proc/modules; ls /dev)
[20:37] <robbiew> ALERT! /dev/disk/by-uuid/05d79451-0ad0-43fc-9f51-a2c98b4831f2 does not exist.
[20:37] <robbiew> Dropping to a shell!
[20:37] <robbiew> argh!
[20:37] <robbiew> i hate this bug
[20:39] <robbiew> kees: ^^^^^ once I fix this, should I run the script in bug 358654 to find the offending package(s)?
[20:49] <jelmer> aaa~>
[20:50] <kees> robbiew: yes please :)
[20:51] <robbiew> kees: shell script identifies: fuse-utils and initramfs-tools
[20:52] <robbiew> Keybuk broke it! ;)
[20:53] <jdstrand> NCommander: done
[20:53] <robbiew> well at least if initramfs-tools is the culprit...from the ubuntu-boot ppa...fun times!
[21:06] <NCommander> jdstrand, +1 beer (to be redeemed at next meatspace meet)
[21:06] <ScottK> Did someone say beer?
[21:07] <NCommander> ScottK, jdstrand gotten stuck NEWing every ARM kernel since they seem to land around Fridays :-/
[21:07] <ScottK> I see.  Well I'd suggest something stronger than beer then.
[21:12] <engla> DktrKranz: ping
[21:14] <DktrKranz> engla: pong
[21:16] <jdstrand> heh, np
[21:34] <apachelogger> ArneGoetje: sure, in a bit