[00:50] <soreau> Hello.
[00:52] <soreau> I am trying to detect whether or not a certain package is installed via bash script. Right now I have pkg --get-selections|grep <pkg-name>| grep -v "deinstall" which works to a certain extent but it also is true if packages with <pkg-name> is in another package name is installed. For instance if compiz is not installed and compiz-core is, it will still detect compiz is installed. How should I do this to get an exact match?
[00:53] <soreau> In short, I want a reliable way to tell if package X is installed from a bash script
[01:11] <TheMuso> soreau: dpkg -l could be what you are looking after.
[01:11] <TheMuso> looking for even
[01:11] <ion> dpkg --get-selections rather
[01:12] <ion> That is better for a machine to parse.
[01:12] <TheMuso> ion: right
[01:12] <soreau> ion: If you see in my first post, that's what I am currently using and it almost works.. just matches any package containing the string
[01:12] <soreau> TheMuso: As does grepping dpkg -l
[01:13] <ion> dpkg --get-selections compiz
[01:14] <soreau> huh
[01:14] <soreau> ion: That may be exactly what I need
[01:15] <soreau> ion: What are all the values that the 'other' field can be? purge, install, deinstall etc
[01:15] <soreau> If I grep for 'install' it will also match deinstall for instance
[01:16] <soreau> Is there anywhere I can see all the possible values for that column?
[01:16] <ion> if dpkg --get-selections compiz 2>/dev/null | grep -qE '\<install$'; then ...
[01:18] <soreau> ion: I'll bet that's exactly what I wanted. Thanks a lot!
[01:29] <soreau> ion: Thanks for your help. Still trying to figure out what that grep magic does but whatever it is, it is working :)
[01:33] <ion> \< stands for word boundary and $ stands for the end of a line.
[01:36] <lifeless> lambda!
[01:36] <ion> λ
[01:37] <lifeless> \ is haskell declares an anonymous function ;)
[01:38] <ion> Indeed.
[01:39] <ion> Unfortunately, one can’t use λ in its place even with Haskell’s Unicode support (the last time i checked).
[01:58] <soreau> thanks again
[04:08] <jdong> who can I thank for the policykit-ification of update-manager?
[04:11] <ScottK> Depends on if you like it or not.
[04:14] <pwnguin> who wouldn't like an upgrade button that asks for your password then looks at you confused
[04:15] <ScottK> In that case, it was definitely not me.
[06:19]  * cwillu_at_work pokes doko__
[06:19] <cwillu_at_work> doko__, bug #418962 is apparently fixed in bash-4.1; is there any chance of getting a patch into karmic, or updating to that version?
[06:21] <Hellow> Well, I'm glad that got fixed.
[06:26] <cwillu_at_work> s/got/may get/ :p
[06:26] <Hellow> :P
[06:26] <cwillu_at_work> looks like debian doesn't have 4.1 packaged yet
[06:28] <cwillu_at_work> hell, 4.1 hasn't been released at all yet :(
[06:39] <cwillu_at_work> hmm; 33 patches to 4.0 are on the maintainers site, none of which are obviously the fix to my eyes
[06:43] <dholbach> good morning
[06:43] <manitoba98> Excuse me; can anyone explain why it's necessary to send kernel log messages through dd, rather than letting klogd pick them up directly? Debian doesn't do it that way.
[06:44] <manitoba98> Other than "it lets us run it as user klogd", which isn't a reason in and of itself.
[07:11] <pitti> Good morning
[07:11] <pitti> pochu: oh, great!
[07:17] <dholbach> pitti: I uploaded didrocks' new gdl - it will need binary NEWing
[07:17] <dholbach> didrocks: will you taking care of uploading the 4-5 rdepends?
[07:18] <didrocks> hey pitti, hi dholbach
[07:19] <dholbach> didrocks: uploaded sabayon too
[07:20] <didrocks> dholbach: thanks. You want to handle the transition now and not dep on the old (with previous soname) bin library?
[07:20] <didrocks> I can do it, if you think it worthes before beta :)
[07:21] <dholbach> didrocks: it's sitting in the queue now - I'll defer that to the release team / archive admins
[07:21] <dholbach> I think it'd be a quick job and build times shouldn't be long either
[07:22] <dholbach> didrocks: just let me know what they think and I can help out if necessary
[07:22] <didrocks> dholbach: no pb, I'll ping them later today and handle it :)
[07:22] <pitti> hey dholbach; ok, thanks
[07:22] <dholbach> super
[07:27] <didrocks> pitti: so, what do you think about handling those rebuilds before beta?
[07:27] <pitti> dholbach: should be fine, better for testing
[07:28] <pitti> pochu: uploaded
[07:28] <didrocks> dholbach: ok, I put that on my schedule, so :)
[07:36] <pitti> dholbach, didrocks: please upload them ASAP with proper versioned build-depends, then we can already accept them and let the buildds figure it out
[07:37] <manitoba98> Excuse me; can anyone explain why it's necessary to send kernel log messages through dd, rather than letting klogd pick them up directly? Debian doesn't do it that way.
[07:37] <dholbach> didrocks: can you just put the debdiffs somewhere and I have a look at them?
[07:37] <dholbach> manitoba98: maybe the people who can answer the question are not around yet... why don
[07:37] <dholbach> 't you mail<EMAIL_ADDRESS>[07:38] <manitoba98> OK, thanks.
[07:45] <didrocks> dholbach: ok. I'm working on that this evening as soon as I get back home
[07:58] <pitti> didrocks, dholbach: gdl NEWed
[07:59] <dholbach> pitti: I'll take the dog for a walk and take care of the rdepends afterwards
[08:00]  * pitti hugs dholbach
[08:02] <didrocks> pitti: Thanks :)
[08:04] <pitti> ArneGoetje: argh
[08:04] <pitti> ArneGoetje: may it be that you forgot to remove the langpacks before the rebuild? The delta langpacks are very big
[08:05] <pitti> they should be empty..
[08:05] <pitti> well, a bit too late now, so we just have to cope and kick out some of them
[08:07] <ArneGoetje> pitti: no. LP 'forgot' my full-request... :(
[08:07] <pitti> ah, too bad
[08:07] <pitti> ArneGoetje: did that happen before?
[08:07] <pitti> we have to get it right for the final
[08:08] <ArneGoetje> pitti: I have done a merge with the last full-export and int import in lp-o-matic is currently running... do you still want to have it?
[08:08] <ArneGoetje> pitti: first time it happened... maybe LP had some hickup
[08:08] <pitti> ArneGoetje: there were some LP rollouts on Friday and apparently over the weekend, too
[08:08] <pitti> perhaps it forgot that state when it was restarted
[08:08] <ArneGoetje> pitti: that might be an explanation
[08:09] <pitti> ArneGoetje: it gets too late, I'm afraid; we need to have CDs tomorrow around European noon
[08:09] <ArneGoetje> pitti: hum... ok
[08:10] <ArneGoetje> pitti: the next export will be a full one again... (if LP doesn't forget it again), so users will need to upgrade
[08:11] <happyaron> mvo: ping
[08:12] <mvo> hey happyaron
[08:13] <happyaron> mvo: I have some question on software-center's pot
[08:13] <mvo> happyaron: sure
[08:13] <pitti> ArneGoetje: we don't really need a full export after beta, but I guess we should still do it to test that it still works
[08:13] <ArneGoetje> pitti: yep
[08:13] <pitti> hey mvo
[08:13] <happyaron> mvo: there is a po/software-store.pot, po/po/software-store.pot in your 0.4 version tarball
[08:14] <happyaron> mvo: and now you've uploaded a po/software-center.pot, which template should be in launchpad, and how to name it?
[08:20] <mvo> happyaron: software-center should be the one, let me fix that in my source. sorry for the confusion
[08:21] <happyaron> mvo: only po/software-center.pot should be imported, is that right? I have renamed the original template in lp to software-center, and is that po/po/software-store.pot not needed?
[08:22] <mvo> happyaron: correct
[08:22] <happyaron> ok
[08:22] <mvo> happyaron: the old name should go away everywhere
[08:22] <happyaron> only one template should be fine
[08:23] <krabador> NetworkManager Applet 0.7.996 is a massacre
[08:23] <krabador> all right with dhcp, but totally don't works form manual settings
[08:30] <cjwatson> krabador: please file bugs in Launchpad rather than on IRC; it'll usually get a better result that way
[08:51] <ArneGoetje> pitti: I could selectively upload a few language-packs it that helps... which languages are we going to ship on the CD?
[08:51] <pitti> ArneGoetje: that would help indeed
[08:52] <pitti> ArneGoetje: en es xh pt de fr bn
[08:52] <ArneGoetje> pitti: which languages do you want?
[08:52] <ArneGoetje> pitti: ok
[08:52] <pitti> ArneGoetje: that won't help the DVD, but at least we can have good CDs
[08:53] <pitti> ArneGoetje: thanks!
[08:53] <ion> What, not fi? I’m appalled.
[08:54]  * pitti hugs ion
[08:54] <ion> :-)
[09:11] <didrocks> pitti, dholbach: all libgdl universe rdeps are uploaded. Do you want that I give a hand on main ones?
[09:12] <pitti> didrocks: that would be nice, if you have some time to test them?
[09:12] <pitti> I hope most will "just build"?
[09:13] <didrocks> pitti: universe ones have built like a charm :) I do some minimal test (at work, it's more difficult, spawing a slow VM on my windows machine :/)
[09:13] <dholbach> uploaded
[09:13] <dholbach> gnome-python-extras
[09:13] <dholbach> and committed to the brancht oo
[09:13] <dholbach> too
[09:13] <dholbach> should be all set now
[09:14] <didrocks> great :)
[09:24] <pitti> mbiebl: any particular reason why you made libpolkit-gtk-1-dev arch: any? (it's arch: all in Ubuntu)
[09:24] <\sh> moins
[09:25] <tgpraveen> any chance we will get theora 1.1 in karmic?
[09:26] <seb128> tgpraveen, any chance you will stop asking every day if we will get new major version of software or features weeks after feature freeze now? ;-)
[09:32] <tgpraveen> seb128: i just wanted a yes/no answer :)
[09:33] <seb128> tgpraveen, which is try for my question too ;-)
[09:33] <seb128> tgpraveen, dunno, we didn't consider it it's way after feature freeze, if you have excellent recent open a bug asking for an exception
[09:33] <seb128> recent -> reason
[09:44] <asd123123> http://17fc5c36.linkbucks.com
[09:53] <pitti> tseliot: does nvidia 96 actually work on karmic?
[10:06] <tseliot> pitti: yes, it should. Why?
[10:07] <pitti> tseliot: ok, thanks
[10:07] <pitti> just cleaning the DVD seeds, and they had some nonexisting versions any more
[10:07] <tseliot> pitti: aah, ok
[10:09]  * directhex has downgraded his nvidia - 185 is crashy crashy crashy
[10:43] <dholbach> is there a bug open for "gdm only comes up after pressing alt-f7"?
[10:54] <pitti> dholbach: I don't see one
[10:54] <dholbach> ok
[10:54] <dholbach> I just have this on one machine
[10:54] <dholbach> booting will only show me a black screen until I press alt-f7
[10:55] <cjwatson> it happens on the live CD for me
[10:59] <seb128> dholbach, there is one
[10:59] <seb128> dholbach, bug #434361
[10:59] <dholbach> thanks seb128
[11:00] <seb128> it doesn't seem a gdm bug
[11:00] <pitti> seb128: I retitled the bug, so that it's a bit easier to find
[11:00] <dholbach> hum - I don't need to log in and restart gdm for gdm to work
[11:01] <cjwatson> seb128: certainly in my case, gdm starts fine, it just doesn't switch vt
[11:01] <dholbach> ah ok, comment 7 says the same on amd64
[11:01] <seb128> dholbach, right, read comments on the bugs, just people got confused before finding that ctrl-atl-f7 was working
[11:01] <cjwatson> ah
[11:02] <seb128> cjwatson, well some people have the issue with kdm too
[11:02] <seb128> and workaround are weird there
[11:03] <seb128> ie booting with splash workaround the bug
[11:03] <seb128> or reinstalling linux for some users
[11:03] <seb128> if somebody has a clue how to debug that help is welcome there
[11:04] <seb128> it's probably a beta blocker too
[11:04] <cjwatson> yeah
[11:04] <cjwatson> I wonder if the usplash init script needs to be migrated
[11:05] <cjwatson> we used to shut down usplash before starting gdm; now we don't
[11:05] <cjwatson> that seems very likely to be the cause
[11:06] <seb128> "without splash" before
[11:06] <seb128> but right, that makes sense
[11:12] <joaopinto> mvo, sorry for the duplicate bug repos on software-center I didn't noticed they were reported on the previous project name :\
[11:12] <joaopinto> reports
[11:13] <mvo> joaopinto: no problem, thanks for reporting the stuff, the rename caused some confusion unfortuatnely
[11:14] <cjwatson> hmm, this is slightly tricky, I *really* don't want to reproduce the busy-wait in the usplash init script in upstart-wordl
[11:14] <cjwatson> world
[11:16] <pitti> does upstart send a signal after a process has terminated?
[11:17] <cjwatson> well, even that wouldn't be sufficient, since the init script waits for a while and kills it if it doesn't die by itself
[11:19] <cjwatson> really, I think we want to have upstart take over supervision of the running usplash process when it starts, and pretend that it's a job, so that we can use the 'kill timeout' stuff
[11:40] <dholbach> seb128: do you know why bug 424311 is set to "low"? :)
[11:41] <seb128> dholbach, why not?
[11:41] <dholbach> I find it a bit annoying that the screen does not go to black
[11:41] <dholbach> it just flickers every few minutes
[11:41] <seb128> dholbach, because it has not been confirmed and happens to one user only
[11:41] <dholbach> ok
[11:41]  * dholbach can confirm
[11:42] <Laney> and me
[11:43] <dholbach> Laney: can you add your details to the bug too?
[11:43] <seb128> dholbach, did it start recently?
[11:44] <dholbach> seb128: no, a week I'd say
[11:45] <seb128> dholbach, it's probably not the same bug then
[11:45] <Laney> done
[11:45] <seb128> dholbach, yours probably started with the 2.28 update
[11:45] <dholbach> seb128: you think?
[11:45] <seb128> well that one has been opened 3 weeks ago
[11:45] <dholbach> maybe a bit longer already - I really dunno
[11:45] <seb128> well, you are the third one to mention screensaver today
[11:45] <seb128> I really think it's new since 2.28
[11:46] <seb128> I would prefer a new bug if that's the case rather than abusing an old bug about something different
[11:46] <Laney> no I had it before then
[11:46] <seb128> ok, cool, let's see if somebody is interested to work on that
[11:46] <seb128> we don't have anybody working on screensavers that I know
[11:47] <seb128> but maybe somebody will be annoyed enough to look at it ;-)
[11:47] <seb128> I put it on my list but I've like one hundred bugs already on my karmic list so low chance I look at that
[11:48] <Laney> can you view the sleep/wake events?
[11:50] <seb128> Laney, gnome-screensaver --no-daemon --debug
[11:50] <Laney> cool
[11:50] <Laney> i'll do it when i get home
[11:51] <seb128> but the power management tab is a gnome-power-manager thing
[11:51] <seb128> not a gnome-screensaver one
[11:52] <Laney> yeah
[12:34] <TomaszD> hey asac, would you care to upload a translation update for ubufox? https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/437604
[12:41] <asac> assigned myself now. thx. TomaszD
[12:41] <TomaszD> asac, cool, thanks!
[12:41] <asac> TomaszD: if you request a merge into lp:ubufox it would be even quicker ;)
[12:41] <asac> but not needed
[12:42] <TomaszD> asac, I know, but I don't have time to learn another DVCS just to upload a few files :P
[12:44] <asac> ll
[12:44] <asac> kk
[12:47] <cjwatson> seb128,pitti: FYI I'm experimenting with http://paste.ubuntu.com/280312/ - feel free to comment while I break my system with it :)
[12:49] <pitti> cjwatson: "start on stopped gdm" sounds a bit overzealous; shouldn't this rather mean "start on (rc0 or rc6)" or so?
[12:51] <pitti> nice, this looks so much cleaner than the current init script with its looping
[12:57] <amitk_> is it a bad time to upgrade (dist-upgrade fails with lots of python errors)
[13:04] <AnAnt> can someone review LP 438092 ?
[13:04] <sistpoty|work> james_w: bug #404003: source package is actually opencore-amr, sorry for the inconvenience
[13:05] <AnAnt> I dropped this Ubuntu change: build with g++ -fno-tree-ter on armel, since debian now uses g++-4.4
[13:05] <james_w> thanks
[13:06] <AnAnt> james_w: btw, I've done devscripts merge
[13:06] <james_w> thanks AnAnt
[13:07] <AnAnt> james_w: LP 414298
[13:07] <AnAnt> james_w: that's actually devscripts_2.10.55
[13:08] <cjwatson> pitti: I believe it has to start after gdm, or the chvt ordering goes wrong
[13:09] <cjwatson> pitti: at least it certainly used to fail if you tried to start usplash_down before gdm
[13:09] <cjwatson> it does mean that it won't run if you don't have a *dm, I concede
[13:48] <kalla> some audio sync problem with videoplayer in ubuntu... :(
[13:50] <Laney> http://launchpadlibrarian.net/32596463/buildlog_ubuntu-karmic-armel.sound-juicer_2.28.0-1_FAILEDTOBUILD.txt.gz - check out the UCF installation. Does that look transient?
[13:51] <pitti> re
[13:51] <pitti> cjwatson: ah, perhaps it'd need to be (stop gdm && (rc0 || rc6))?
[13:55] <cjwatson> pitti: mm, maybe
[13:55]  * cjwatson is wrestling with getting the initramfs->upstart import stuff Keybuk hacked in to work properly
[13:57] <pitti> ogra, lool: so bug 417009 is believed to be fixed now, right? You just keep it open until it's verified, or does it need more work?
[13:58] <amitk_> mvo, doko: do you deal with python/apt? I have a failed dist-upgrade and here is the result of trying to fix it. http://pastebin.ubuntu.com/280364/
[14:00] <mvo> amitk_: hm, that smeels like disk corruption "EOFError: EOF read where object expected
[14:00] <mvo> "
[14:00] <lool> pitti: Not sure why it isn't closed; I know we're actualy hiding an issue in some binaries instead of fixing it
[14:01] <lool> doko: Did you intend to keep it open?
[14:01] <amitk_> mvo: should I force reinstall some packages?
[14:03] <asac> ogasawara: plz check the patch in 334413 ... thx
[14:04] <ogasawara> asac: will do
[14:05] <mvo> amitk_: try reinstalling python2.6
[14:07] <doko> lool: yes, we have a work around, not a fix. just take it off the release radar once the build is in the archive
[14:07] <lool> doko: Ok thanks
[14:07] <lool> pitti: ^
[14:07] <amitk_> mvo: 'sudo dpkg-reconfigure python2.6' seems to have done the trick
[14:07] <AnAnt> can someone look at LP 416949
[14:08] <doko> amitk: bad files, zero lenght?
[14:08] <mvo> amitk_: hm, that is a bit scary
[14:08] <amitk_> doko: no, I checked that the files existed
[14:19] <amitk_> liw: moi! does Computer Janitor track how often a package is used? I am wondering why it is trying to remove deboostrap, kvm, qemu, etc.
[14:34] <cjwatson> oh usplash, why do you mock me
[14:38] <directhex> you were naughty in a previous life?
[14:54] <zul> archive-admins: i think linux-ec2 is sitting in binary-new can we get that in the archive? please k thx bye
[15:01] <pitti> zul: nothing like *ec2* in the NEW queue
[15:01] <zul> pitti: hmm..
[15:04] <pitti> zul: see https://edge.launchpad.net/ubuntu/+source/linux-ec2/2.6.31-300.3, nothing NEW there
[15:09] <zul> pitti: but it said it built?
[15:09] <pitti> right
[15:14] <fbond> mvo: Have a second to discuss possible bugs in python-apt?
[15:15] <fbond> Just want to confirm that the bugs exist as I see them before filing a report.
[15:16] <liw> amitk, computer janitor does not track how much packages are used; if you click on the package in the UI what does it tell you as the reason for the removal?
[15:18] <fbond> mvo: Nevermind, just confused by the various semi-dict-like interfaces.
[15:20] <mdz> ttx, good afternoon, how is the test going?
[15:22] <ttx> mdz: there is an issue with eucalyptus-cc upstartification. httpd child processes are crashing. That prevent sthe node from being correctly polled
[15:22] <ttx> (I'm testing your branch)
[15:22] <ttx> I'm slowly closing in on the issue, but axis2c is not easy to debug
[15:24] <mdz> ttx, the command line and config file used to start apache2 are identical.  I did drop the LD_LIBRARY_PATH change because it seemed superfluous, but we can put it back in if needed. did you test if that is the problem?
[15:24] <mdz> (command line -> except for "-D foreground")
[15:24] <ttx> mdz: I just managed to get a /etc/init/eucalyptus-cc.conf that doesn't crash. Now I need to find what in the combo of things I added fixed it.
[15:24] <mdz> ttx, send me the diff?
[15:26] <mdz> pitti, zul, I believe slangasek took care of it already:
[15:26] <mdz>  linux-ec2 | <IP_ADDRESS>0.0 | http://archive.ubuntu.com karmic/main Packages
[15:26] <mdz> pitti, zul was talking about the linux-ec2 binary package from linux-meta
[15:26] <zul> mdz: thanks
[15:27] <pitti> mdz: ah; well, I didn't see that in NEW either;
[15:27] <pitti> if it's done now, fine
[15:27] <mdz> pitti, zul, I can confirm that it's installed in the images at http://uec-images.ubuntu.com/karmic/current/ubuntu-uec-karmic-i386.manifest
[15:28] <ttx> mdz: http://pastebin.ubuntu.com/280428/
[15:28] <ttx> mdz: I'll reduce the patch to see what actually fixed the problem
[15:29] <ttx> mdz: http://pastebin.ubuntu.com/280430/ is better
[15:30] <mdz> ttx, /etc/eucalyptus/axis2/lib is a symlink to /usr/lib/axis2/lib
[15:31] <giskard> dude how you write stats (cpu , load) in the motd (before call pam_lastlog i mean)
[15:32] <mdz> ttx, it still segfaults when I use your LD_LIBRARY_PATH change
[15:32] <giskard> btw, hi all
[15:32] <ttx> mdz: yes, EUCALYPTUS=/ and LD_LIBRARY_PATH do not help...
[15:33] <mdz> ttx, have you debugged the segfault?
[15:33] <ttx> mdz: no
[15:34] <mdz> I have a stack trace
[15:34] <ttx> ah
[15:34] <ttx> env AXIS2C_HOME=/etc/eucalyptus/axis2
[15:34] <mdz> ttx, http://people.canonical.com/~mdz/temp/eucalyptus-cc-apache2-crash.png
[15:34] <ttx> seems to be the critical one. Let me doublecheck that.
[15:35] <AnAnt> fabrice_sp__: thanks
[15:35] <fabrice_sp__> AnAnt, for?
[15:36] <AnAnt> fabrice_sp: the tablelist bug
[15:36] <AnAnt> bugs
[15:36] <mdz> it's doing this:
[15:36] <mdz>   service = adb_getKeysType_get_serviceTag(request, env);
[15:36] <mdz>
[15:36] <mdz>   response = adb_getKeysResponseType_create(env);
[15:36] <mdz>   status = AXIS2_TRUE;
[15:36] <mdz>   rc = doGetKeys(service, &outCCCert, &outNCCert);
[15:36] <mdz> and crashing in DoGetKeys
[15:37] <fabrice_sp> AnAnt, ahhh, you're aelmahmoudy. You're welcome :-)
[15:37] <mdz> ttx, I still get the segfaults after setting AXIS2C_HOME
[15:37] <ttx> grmbl
[15:37] <AnAnt> fabrice_sp: yup
[15:39] <ttx> mdz: there is a combination of factors, probably two bugs.
[15:39] <TomaszD> mvo, hi, have you perhaps noticed that there is something wrong again with update-manager's template? Even the one waiting in the queue is not up-to-date, and the strings that have not been changed are now displayed in English
[15:39] <TomaszD> mvo, could you take a look at this issue?
[15:39] <cjwatson> pitti: I think this usplash upstartification is now working - I just needed to crank the initial timeout up a little bit
[15:40] <cjwatson> pitti: since native upstart jobs don't talk to usplash (at the moment?), so the timeout has a habit of expiring
[15:40] <ttx> oooooh
[15:40] <pitti> you rock!
[15:41] <mvo> TomaszD: I have a look
[15:41] <mvo> TomaszD: is ths about bug #438077 ?
[15:41] <cjwatson> hmm, it's not quite stopping properly if gdm isn't in use though
[15:42] <TomaszD> mvo, indeed it is
[15:42] <TomaszD> mvo, I'm especially worried about the policykit dialog window, where there's a new string about the system policy preventing updates or something close to that
[15:42] <ttx> mdz: can you crash it with the full patch ?
[15:42] <mdz> ttx, segfault is at:     home = strdup(getenv("EUCALYPTUS"));
[15:43] <mvo> TomaszD: that is comes from aptdaemon
[15:43] <ttx> mdz: yes... but if you set that alone, the polling to the node doesn't really occur.
[15:43]  * ttx rechecks
[15:45] <TomaszD> mvo, ok, but the rest is still worrying
[15:45] <cjwatson> pitti: actually - I wonder if the right answer would be for the gdm job to emit a stop-splash event
[15:45] <cjwatson> or even a dm-starting event
[15:45] <mvo> TomaszD: it is, I targeted it
[15:45] <mdz> ttx, adding export EUCALYPTUS=/ to the upstart job doesn't seem to get it into the apache2 enivronment for some reason
[15:45] <mdz> or env
[15:45] <cjwatson> pitti: that would save having to keep track of whether gdm actually gets started (e.g. 'text' on command line)
[15:45] <TomaszD> mvo, thanks
[15:45] <ttx> mdz: you need AXIS2C_HOME
[15:46] <ttx> with env EUCLYPTUS and AXIS2C_HOME set it works
[15:46] <cjwatson> mdz: the init(5) manual page documents env KEY=VALUE and export KEY, but not export KEY=VALUE
[15:46] <ttx> all the other changes in the patch are superfluous.
[15:47] <mdz> cjwatson, env KEY=VALUE is what I'm using
[15:48] <ttx> mdz: http://pastebin.ubuntu.com/280457/ works for me
[15:48] <mdz> it works for HTTPD_CONF=/var/run/eucalyptus/httpd-cc.conf
[15:48] <mdz> but not for EUCALYPTUS=/
[15:49] <apachelogger> asac: ping
[15:49] <mdz> ttx, if you look at /proc/xxx/environ do you see EUCALYPTUS=/ there?
[15:50] <ttx> mdz: yes
[15:51] <mdz> ttx, I can't get that to work for some reason
[15:52] <mdz> ttx, ararrggghh
[15:52] <mdz> using "restart" doesn't seem to process the new env stanzas
[15:52] <mdz> but 'stop' and 'start' did
[15:52] <mdz> keeeeyyyybbuuuuuuukkk....
[15:52] <ttx> mdz: uh :)
[15:52]  * dholbach hugs mdz
[15:52] <ttx> there were two bugs, the segfault was masking the other.
[15:53]  * ttx has been banging his head against that one for a few hours :)
[15:53] <cjwatson> hmm, now I have usplash stuck on
[15:53] <cjwatson> whoopsie
[15:54] <highvoltage> heh, so now you have to press alt+F1 AND alt+7?
[15:54] <mdz> ttx, gdb made quick work of the segfault, it was clear that it was missing $EUCALYPTUS
[15:54] <mdz> if my changes to the upstart job had actually worked, the second one would have been quick too ;-)
[15:56] <mdz> ttx, is the cc registration working?
[15:57] <ttx> mdz: yes.
[15:57] <cjwatson> highvoltage: no, it's just hosed. undoubtedly my fault
[15:57] <ttx> mdz: I tested from a daily + upgrade though, which is a slightly different test path
[15:57] <mdz> ttx, it doesn't seem to re-run the registration when I restart the cc, though I thought it would
[15:58] <mdz> ttx, I've pushed a new auto-registration branch
[15:58] <mdz> with the env fixes
[15:58] <mdz> ttx, are we ready to merge it into ubuntu and upload?
[15:58] <ttx> mdz: I think so. I was planning to rebuild and test, but the sooner it lands on the daily, the better
[15:59] <asac> apachelogger: ?
[16:00] <apachelogger> asac: any news on trademark in kubuntu-firefox-installer? also, I really really think that making the firefox packages conflict and replace kubuntu-firefox-installer is the best option at hand :)
[16:01] <apachelogger> asac: btw, is firefox-gnome-support a recommends?
[16:02] <mdz> ttx, yes, dialing
[16:03] <ogra> could $archive_admin_of_the_day get linux-fsl-imx51 and linux-mvl-dove out of NEW for me ?
[16:03] <mdz> ttx, uploaded
[16:04] <mdz> cjwatson, can you review and approve?
[16:04] <ogra> james_w, ^^^ ?
[16:04] <mdz> and spin new server ISOs?
[16:04] <asac> apachelogger: can you get me a mail with screenshots etc. ... would be easier for me to check with mozilla if i had something like that.
[16:04] <ttx> mdz: I'll spend some cycles this evening validating that iso
[16:05] <apachelogger> asac: sure
[16:05] <mdz> ttx, what about the public IPs issue?
[16:05] <james_w> ogra: already in the middle of the queue
[16:05] <ogra> merci :)
[16:20] <mok0> Any hints on how to easiest solve the getline() problem with karmic's libc=
[16:20] <mok0> ?
[16:25] <cjwatson> mok0: rename the local function
[16:25] <mok0> cjwatson: I've been doing that but in this particular instance I don't want to
[16:26] <mok0> cjwatson: not if I can avoid it.
[16:26] <mok0> cjwatson: The error comes from a 4-line change in stdio.h
[16:26] <cjwatson> that's correct, but it was an addition to POSIX
[16:27] <mok0> cjwatson: the addition is to include getline as a std. function?
[16:27] <ttx> mdz: did you commit the -0ubuntu9 changes to lp:~ubuntu-core-dev/eucalyptus/ubuntu ?
[16:28] <ttx> mdz: about the public IP issue, maybe we can discuss it on the call.
[16:28] <mok0> cjwatson: earlier you had to define __GNU to get it
[16:28] <mok0> cjwatson: now it's controlled by __USE_XOPEN2K8 which is apparently defined somewhere.
[16:29] <cjwatson> it used to be a glibc extension, but POSIX incorporated it
[16:29] <cjwatson> I'm sure you can use feature test macros to declare that you want an older version of POSIX
[16:29] <cjwatson> info libc, search for feature test
[16:29] <mok0> cjwatson: I'll look into it, thanks
[16:30] <cjwatson> that sort of declaration might be a stopgap; I wouldn't recommend it long-term
[16:30] <mok0> cjwatson: Well, we have an FTBFS list a mile long, ultimately upstream should fix it
[16:30] <sistpoty|work> mok0: if it uses autotools, you could also add a configure check for it
[16:31] <cjwatson> sistpoty|work: shouldn't need that ...
[16:31] <mok0> sistpoty|work: it's not a missing function, it's a dual declaration
[16:32] <mdz> ttx, yes I did
[16:32] <sistpoty|work> mok0: yep, in the sense of #ifndef HAVE_GETLINE local definition #endif, and let HAVE_GETLINE set by autotools, but you could also just remove the local definition though ;)
[16:33] <mok0> sistpoty|work: AFAICT it's not a standard getline()
[16:33] <sistpoty|work> mok0: then you'll need to rename it, like cjwatson first wrote
[16:34] <mok0> sistpoty|work: I have to edit a dozen files then
[16:34] <mok0> sistpoty|work: which is why I'd rather unset __USE_XOPEN2K8
[16:34] <ttx> mdz: ok, got it. launchpad is late.
[16:34] <cjwatson> do not touch that macro directly
[16:34] <cjwatson> it is internal
[16:35] <cjwatson> there are public macros available for your use
[16:35] <mok0> cjwatson: I am looking at features.h to find it
[16:35] <cjwatson> specifically, I should think, #define _POSIX_C_SOURCE 200112L
[16:37] <mok0> cjwatson: that doesn't sound like a public macro either
[16:37] <cjwatson> well, it is.
[16:37] <cjwatson> it's in info libc.
[16:37] <mok0> cjwatson: ah, thanks.
[16:38] <lolufail> hi
[16:39] <lolufail> I'm experiencing kernel oops in with my fresh raid5->dmcrylt->lvm2->ext4 configuration
[16:39] <lolufail> I cannot mkfs.ext4
[16:39] <lolufail> http://pastebin.com/m56628b69
[16:40] <lolufail> should I file a bugreport?
[16:43] <sistpoty|work> mok0: or you could use seddery: for i in *c; do sed -e 's/getline(/getline_local(/' $i | sponge $i; done
[16:43] <mok0> sistpoty|work: I could, yeah
[16:44] <sistpoty|work> (and review the debdiff, that only good things matched)
[16:44] <mok0> sistpoty|work: or an appropriate #define getline anothergetline
[16:47] <nh2> does it make any difference if I autoreconf before PPA upload?
[16:48] <mok0> Gotta go see you later
[17:21] <slangasek> ttx: question regarding the instructions in http://testcases.qa.ubuntu.com/Install/ServerEConfig
[17:22] <slangasek> ttx: will euca-bundle-image do the right thing if you pass it /boot/vmlinuz instead of /boot/vmlinuz-2.6.31-11-generic?  (I.e., will it follow symlinks?)
[17:22] <slangasek> davmor2: ^^
[17:22] <ttx> slangasek: no clue. I'd need to try
[17:23] <slangasek> ttx: low priority, but if it doesn't work I think we need to fix it so it does; otherwise we have to embed kernel ABI versions in our test case
[17:23] <ttx> would work with /boot/vmlinuz-$(uname -r) though
[17:23] <slangasek> true
[17:23] <slangasek> davmor2: can you switch the testcase to use the above rune?
[17:23] <davmor2> slangasek: np's
[17:24] <ttx> slangasek: in the end we would rather test the UEC kernel and ramdisk provided with the images
[17:25] <ttx> slangasek: see http://uec-images.ubuntu.com/karmic/current/
[17:26] <ttx> though I'd like to retest those on my now-working UEC
[17:26]  * ttx disappears again
[17:26] <slangasek> ttx: oh?  so we're now publishing kernels / initrds alongside the images?
[17:27] <slangasek> that's a rather late change to the release publishing
[17:27] <ttx> slangasek: bug 429106, see smoser
[17:27] <slangasek> ok
[17:28] <ttx> slangasek: this can be reverted easily.
[17:28] <ttx> :)
[17:29] <slangasek> well, one of the consequences of distributing kernels in this fashion is that they aren't accompanied by source code... or even a clear indicator of what version of the source they are
[17:29] <slangasek> (s/clear/unambiguous/; obviously the ABI version narrows it down, but it's not unique)
[17:30] <slangasek> smoser: see above; I don't think we should be publishing kernels / initramfs in this fashion, this has GPL compliance implications
[17:43] <smoser> slangasek, i'm not 100% bent on publishing kernels in that fashion
[17:43] <smoser> i have 2 thoughts though:
[17:44] <smoser> 1. we're essentially doing this with ec2 kernels on ec2 (we make them available to run, but similarly to above, there is no absolute link of source -> binary)
[17:46] <smoser> 2. if a user of UEC wants to create a kernel/initrd/guest image and they're running on their local system anything other than the release for which they want to create the guest, they're kind of SOL
[17:46] <smoser> we need to provide them with a kernel and initrd that they can easily pair with a.) our uec images b.) ones they make themselves
[17:46] <slangasek> smoser: 1) is also a bug we need to solve, then; it just wasn't as obvious to me in that case as it is when I'm being pointed at the uec-images directory listing :)
[17:47] <slangasek> smoser: 2) I guess that's fair - we should still get the GPL reqs addressed before we start publishing in this fashion, though
[17:48] <smoser> i agree that that directory listing is far from perfect . and in that bug, i mentioned that..
[17:49] <mvo> TomaszD: I think the u-m problem is fixed, it turns out something is meddling with gettext
[17:49] <smoser> slangasek, i really would like your insight on how to make that directory output easily usable and "correct" in other ways also.
[17:49] <smoser> the other thing that has come to my mind is the deletion of non-current kernel images (as i belive is done in the archives). that should then apply here too i think
[17:50] <TomaszD> mvo, great :)
[17:53] <slangasek> smoser: generally, by integrating anything you need into the scripts from the 'cdimage' branch that I copied to nectarine, and reusing those
[17:54] <smoser> slangasek, i guess i dont follow that. but i'll look more into it.
[17:55]  * hyperair wonders if anyone's looking at sreadahead
[17:55] <slangasek> smoser: cf. http://cdimage.ubuntu.com/daily/current/, which always includes an autogenerated header... we should be reusing the existing toolset for UEC publishing
[17:56] <slangasek> smoser: e.g., fixing the daily builds to call the checksum-directory tool as I had pointed out
[17:58] <davmor2> slangasek: what do you want me to do then leave the docs for now and wait till after beta to alter them?  So we at least have a working testcase for beta?
[17:59] <slangasek> davmor2: no, change them to use the $(uname -r) rune
[17:59] <cjwatson> hyperair: an upload went in last night to speed it up a lot
[17:59] <cjwatson> hyperair: if that's not what you mean, be more specific ...
[18:01] <smoser> slangasek, i can/will get the directory checksumming in.  i was asking more about the naming of files and such.  I'd like to name the kernels such that they can easily be referred to with, as you suggested, a static identifier (ie, like /vmlinuz). so that any scripts based on directory output wouldn't have to fish around for versions
[18:03] <davmor2> slangasek: how's that now?  http://testcases.qa.ubuntu.com/Install/ServerEConfig
[18:03] <slangasek> smoser: server-side scripts, or some sort of user-side scripts?
[18:04] <slangasek> smoser: for server-side, I don't think it should be much of a problem, since we *have* to publish information about what source package this came from
[18:04] <smoser> slangasek, i was meaning client side.
[18:05] <slangasek> davmor2: looks good to me, thanks
[18:05] <smoser> ie, when you document "heres how to install our UEC image on your cloud"
[18:05] <davmor2> np's
[18:05] <smoser> best if you don't have to say: download http://uec-images.u.c/releases/<release>/fish-for-kernel-name.img.gz
[18:06] <smoser> or what nt
[18:06] <smoser> not
[18:06] <slangasek> smoser: ok.  can be done; shouldn't be done until we first have the GPL issue addressed prominently
[18:06] <smoser> but rather http://uec-images.u.c/releases/i386/kernel.gz
[18:06] <smoser> slangasek, ok. so what do i need to do on the gpl issue.
[18:06] <slangasek> well, I would prefer ubuntu-uec-karmic-i386-vmlinuz-generic-pae
[18:06] <smoser> slangasek, thats fine
[18:07] <smoser> but a static name. rather than with a version in it
[18:07] <slangasek> smoser: we need a header that gives the user a link to the corresponding source code
[18:07] <smoser> but ew dont want to lose the source of that, and ideally would like to make the version info available
[18:07] <slangasek> that can be included in the header
[18:07] <hyperair> cjwatson: hmm that's what i meant. (it was no-op-ing)
[18:07] <hyperair> but i still don't see a pack file anywhere =\
[18:08] <hyperair> i guess i'll have to reboot twice to see
[18:08] <slangasek> we can't just point at the archive, because the matching kernel version isn't guaranteed to be there - so we'll want to link to the launchpad UI, specifying an exact version number
[18:08] <slangasek> smoser: and the kernel / initrd are being extracted from vm-builder, right?  So the information in the manifest is guaranteed to always be correct?
[18:09] <smoser> slangasek, right. they pull from vmbuilder image
[18:10] <slangasek> ok
[18:10] <slangasek> in that case, perhaps we don't have any more GPL problem here than for anything else in the image, it just wasn't obvious that this is the case
[18:10] <slangasek> (on EC2, OTOH, we may still have a GPL issue)
[18:14] <mdz> slangasek, can you notify me, kirkland, ttx and mathiaz when there is a server build with eucalyptus -0ubuntu9 available?
[18:15] <mdz> kirkland, and will you take responsibility for notifying eucalyptus and giving them a download URL?
[18:18] <emgent> k
[18:19] <davmor2> mdz: most of the testcase is written now I'm just finishing off a couple of bit then I'm going to do a fresh install follow the testcase to make sue I didn't miss any steps but if there is going to be a respin I might wait till after that in case anything changes.
[18:19] <mdz> davmor2, the main change in the next build is that the registration happens automatically, so that it actually works when it comes up
[18:20] <mdz> davmor2, there will be at least one more respin after that, where there will be one additional question asked during installation
[18:20] <davmor2> mdz: I'll wait then and make the mods once everything is in place.
[18:21] <mdz> davmor2, it's definitely worth trying with the next build (with eucalyptus -0ubuntu9)
[18:24] <davmor2> mdz: I've taken the steps to split out the current post install config to minimise damage to the cluster and node install pages so there are 3 pages currently.  So the changes shouldn't cause too much interruption.  I did actually mean I would wait for the updated version before I removed and text, I just didn't say it very well :)
[18:24] <davmor2> s/and/any text
[18:25] <slangasek> mdz: ack
[18:26] <pitti> james_w: still here by chance?
[18:26] <pitti> james_w: just going through couchdb update with kenvandine
[18:26] <james_w> I am
[18:26] <pitti> james_w: I'm curious why you recommended using Breaks: for a package split with moving files, instead of hte standard Conflicts:?
[18:27] <mdz> davmor2, if you send me a link, I can give you a heads up as to the expected changes
[18:27] <james_w> pitti: that was Colin's advice
[18:27] <davmor2> mdz: http://testcases.qa.ubuntu.com/Install/ServerEConfig
[18:27] <pitti> james_w: because it's confiles?
[18:27] <pitti> conffiles
[18:27] <pitti> since for non-conffiles, breaks: isn't strong enough
[18:28] <james_w> I'm not sure
[18:28] <davmor2> mdz: I'm assuming steps 1-7 can be dropped
[18:28] <slangasek> pitti: because the Conflicts: part of Conflicts/Replaces was never strictly necessary when one package takes over files from another
[18:28] <mdz> davmor2, exactly
[18:29] <pitti> slangasek: so using Breaks:/Replaces: sometimes makes apt's job easier?
[18:29] <slangasek> yep
[18:29] <pitti> ah, ok; thank you
[18:29] <mdz> davmor2, I think the euca-bundle-image call should use the kernel from the downloaded image, not the kernel from the local system (in /boot)
[18:30] <mdz> davmor2, http://uec-images.ubuntu.com/karmic/current/ provides the kernel and ramdisk which should be used
[18:30] <slangasek> pitti: in fact, Conflicts+Replaces has a special meaning that people usually forget about:  it means "this package should be preferred as a replacement for the other package on upgrade"
[18:30] <slangasek> mdz: though not under names that are going to stay as they are currently
[18:31] <davmor2> mdz: slangasek thought that would be a cleaner way around kernel updates.  I just bowed to the greater knowledge
[18:32] <cjwatson> once upon a time, people used to use Conflicts in addition to Replaces because Replaces didn't work when the packages were installed the wrong way round
[18:32] <cjwatson> that was fixed ages ago, but old habits die hard
[18:32] <slangasek> davmor2: no, I only said we shouldn't have hard-coded version numbers in the test case; mdz is talking about grabbing the kernel from somewhere else entirely
[18:32] <cjwatson> but if there really is a reason to avoid installing the old package simultaneously, then Breaks is independently a reasonable thing to do; it isn't really Breaks+Replaces
[18:33] <mdz> slangasek, davmor2, those two kernels are not the same
[18:34] <mdz> the one installed on the cluster controller is a -server kernel
[18:34] <mdz> the downloadable one should be the -virtual kernel
[18:34] <mdz> smoser, confirm?
[18:34] <cjwatson> the -virtual vmlinuz is the same as the -server one, no?
[18:34] <smoser> -virtual vmlinuz is subset of modules of -server
[18:34] <cjwatson> last I looked, -virtual was constructed by stripping down -server at the file level
[18:35] <slangasek> mdz: well, previously the instructions said 'generic', and the kernel available for download on uec-images is -generic-pae
[18:35] <davmor2> mdz: on my cluster install it reads 2.6.31-11-generic
[18:35] <smoser> for i386, the -virtual is subset of -generic-pae
[18:35] <smoser> for x86_64, subset of -server
[18:35] <cjwatson> huh, interesting
[18:35] <slangasek> ah
[18:35] <mdz> cjwatson, it is
[18:35] <mdz> more or less
[18:35] <mdz> the point being that we want to install a lighter kernel on virtual machines
[18:36] <slangasek> it's not lighter
[18:36] <slangasek> the vmlinuz is supposed to be the same
[18:36] <mdz> slangasek, lighter as in fewer modules
[18:36] <slangasek> ah - the initrd will be lighter, sure
[18:36] <mdz> and a smaller disk footprint
[18:37] <mdz> which matters when it will be used as the basis for hundreds of variations
[18:37] <davmor2> mdz: so should the lines relating to kernels/initrd's be specific to the download then?
[18:38] <smoser> lines related to ?...
[18:38] <smoser> one thing you *could* do is something like what pygrub does (or at least what i thought it does). mount the image, poke around for kernels
[18:39] <davmor2> smoser: http://testcases.qa.ubuntu.com/Install/ServerEConfig
[18:39] <smoser> ah
[18:40] <smoser> i think we want to have the test download the correct paired kernel.
[18:45] <jdstrand> kees, mdeslaur: can you look at a potential fix for bug #437854: http://paste.ubuntu.com/280574/
[18:45]  * kees looks
[18:46] <kees> jdstrand: erm, fix is where?
[18:46] <jdstrand> actually, /tmp/pulse-*/ should be /tmp/pulse-*/*
[18:47] <jdstrand> I'm not completely keen on it, cause abstractions/audio pulls in quite a bit
[18:47] <jdstrand> I'm not sure how to get away without it though
[18:48] <kees> I didn't see a patch on that bug -- you were thinking of just adding the audio abstraction plus the /tmp/* paths?
[18:48] <jdstrand> kees: that whole stanza (no, I don't have a patch)
[18:49] <jdstrand> kees: I need to add ipc_lock, deny kill, add /dev/shm/pulse-shm*, all of it
[18:49] <kees> oh! I totally missed the pastebin URL, reading
[18:50] <kees> jdstrand: I use this for pulse: http://paste.ubuntu.com/280576/
[18:50] <mdeslaur> jdstrand: why does it need /tmp/pulse-*/ w,?
[18:51] <jdstrand> mdeslaur: it needs to create that dir
[18:51] <jdstrand> kees: I can play with it more, but it didn't like when I used 'owner'
[18:51] <kees> hrm, weord
[18:51] <kees> weird too
[18:51] <jdstrand> kees: I think because kvm is running as root, but it is trying to access my uid's pulse stuff
[18:51] <kees> aah, yeah, good point
[18:52] <mdeslaur> jdstrand: hmm...why is it trying to access _your_ pulse?
[18:52] <mdeslaur> also, why isn't /tmp/pulse-* in abstractions?
[18:52] <kees> mdeslaur: that's a separate bug that needs to be fixed
[18:52] <jdstrand> mdeslaur: pulse has been a moving targer
[18:52] <jdstrand> target
[18:52] <jdstrand> we add stuff as it comes up
[18:53] <jdstrand> mdeslaur: I think you are right regarding root and my pulse
[18:54] <jdstrand> it may have failed cause of the /tmp stuff
[18:55] <jdstrand> kees, mdeslaur: anyhoo, pulse abstraction tinkering aside, I wasn't totally pleased with the access to the files in /dev or ipc_lock
[18:56] <jdstrand> it did flat refuse to allow 'kill' atm
[18:57] <jdstrand> also, if I use @{HOME} as is, that expands to all in /home/*/...
[18:57] <jdstrand> as this process is root, DAC won't do anything, so I want to be extra careful with the access
[18:58]  * jdstrand -> afk
[18:58] <davmor2> mdz: How is that I've added the 64 version after the /!\ hopefully it's right now.
[19:01] <mdz> davmor2, I don't see a step where you actually download the kernel and initrd from uec-images
[19:01] <mdeslaur> jdong: I probably wouldn't use the abstraction in order to not have the @{HOME}
[19:01] <mdeslaur> jdong: sorry, wrong auto-completion
[19:01] <mdeslaur> jdstrand: ^
[19:03] <mdeslaur> jdstrand: it shouldn't need anything besides the root-owned pulse files...nothing in /dev should be needed I think, and the esd stuff shouldn't be used anymore
[19:03] <davmor2> mdz: is that not what the wget and gunzip lines do?  It's still set for release beta but that's because that's what these notes are specific for?
[19:03] <mdeslaur> uhmm...that, of course, assumes libvirt is compiled with pulse support
[19:14] <ttx> mdz: nurmi just confirmed the mailhost patch, I can commit it, do a quick build/run test and release
[19:15] <ttx> mdz: just checking you aren't already committing that.
[19:18] <jdstrand> mdeslaur: ok, those are excellent points. I'll play with it. thanks!
[19:25] <jdstrand> mdeslaur: it does need access to /dev/snd/*
[19:26] <mdeslaur> huh
[19:26] <jdstrand> mdeslaur: it is kvm confinement that I'm adjusting
[19:26] <jdstrand> mdeslaur: it uses alsa
[19:27] <mdeslaur> oh :(
[19:32] <jono> folks, I am still getting a stack of boot messages before xsplash, should I file bugs against them
[19:33] <robbiew> jono: what are they?
[19:34] <robbiew> jono: if they start with some decimal number in brackets: [ 1198.829291]  foo: blah blah...then file against kernel
[19:35] <jono> robbiew, I get that, but also some kind of pci message, an apparmour message about firefox
[19:35] <jono> and I also see some services starting, like couchdb
[19:36] <jono> are these messages logged? dmesg and messages doesnt show them
[19:36] <doko> hmm, firewire disks are not mounted when they are already connected on start
[19:36] <robbiew> jono: I know Keybuk is aware of the firefox/apparmour stuff...I think that's handled by kees and the gang
[19:37] <jono> also, it seems KMS starts a little while into the boot
[19:37] <robbiew> jono: /var/log/syslog
[19:37] <jono> as opposed to right away
[19:37] <mathiaz> doko: right - I've seen the same behavior with usb disks
[19:37] <cjwatson> jono: apparently starting KMS early loses us 2-3 seconds, so Keybuk is trying to avoid it
[19:37] <cjwatson> which is why it was taken out of the initramfs
[19:37] <jono> syslog doesnt show anything
[19:37] <jono> cjwatson, ahh
[19:38] <kees> jono: if you have firefox/apparmor issues, please open a bug for it.  jdstrand has been doing that profile's development.
[19:38] <doko> mathiaz: hmm, the connected usb disk is always mounted on boot
[19:38] <jono> is there a way I can pause the boot to note down these messages?
[19:38] <jono> I don't seem to have them logged anywhere
[19:38] <mathiaz> doko: well - I connected my encrypted usb disk before booting my karmic laptop and I wasn't prompted for the usualy password
[19:38] <cjwatson> ctrl-s might do it
[19:38] <cjwatson> (ctrl-q to unpause)
[19:38] <kees> jono: oh, do you mean "Skipped: ...firefox?"  that's known and will be uploaded shortly.
[19:39] <robbiew> jono: you can also check if they are still on vt1
[19:39] <jono> kees, thats the one, it skips the profile
[19:39] <doko> mathiaz: is there already a bug report?
[19:39] <mathiaz> doko: hm - I don't know - I haven't had time to investigate that yet
[19:39] <jono> robbiew, they are on vt1
[19:40] <jdong> kees: a higher-level AA question; does the apparmor/lsm framework provide a feasible way to do some Windows-UAC-like interactive denials?
[19:40] <jono> I wonder if I can pipe them into a file somehow
[19:40] <kees> jono: if you want to subscribe: bug 435285
[19:40] <jono> thanks kees
[19:40] <cjwatson> jono: doubt it
[19:40] <jdong> kees: in some cases it'd be a cool feature to have for things like Firefox and an occasional, say, thumbdrive access
[19:40] <jono> ok, I will copy it into a file by hand in vt
[19:40] <jono> 2
[19:40] <jono> brb
[19:40]  * cjwatson admires jono's optimism in believing that there's a shell on vt2 at that point
[19:40] <kees> jdong: not presently (it would require user-space call-back and blocking the syscalls, etc)
[19:41]  * robbiew admires jono's optimism that we will fix his bugs
[19:41] <robbiew> lol
[19:41] <jdong> kees: *nods* would be pretty neat if implemented though, but yeah I was afraid it'd be nontrivial in how the userspace<->syscall interaction would be
[19:43] <mdz> ttx, see mail, I don't think we need it
[19:43] <jdstrand> kees, mdeslaur: I think this is as good as it gets: http://paste.ubuntu.com/280609/
[19:43] <mdz> ttx, so the only further change needed at this point is to fix up the question text to explain the allowed format
[19:43] <ttx> mdz: that was my guess as well.
[19:44] <jono> cjwatson, I am flicking into vt2 right now and copying over content from vt1 by hand into a text editior
[19:44] <mdz> ttx, I'm working on that now
[19:44] <jono> so I can get the boot messages
[19:44] <cjwatson> I'd use a digicam myself ...
[19:44] <kees> jdstrand: how about making that a "pulse" abstraction, and then adding that to the "audio" abstraction?
[19:44] <jono> cjwatson, I am most of the way through it now
[19:44] <ttx> mdz: ok. If you don't need me I'll call it a day. I'll test ISOs first thing tomorrow morning, and do some UEC image validation as well.
[19:45] <jdstrand> kees: well, I mentioned the @{HOME} issue with mdeslaur
[19:45] <kees> jdstrand: hrm, yeah, good point.
[19:45] <jdstrand> kees: @{HOME} will expand to /root and /home
[19:45] <cjwatson> sigh, this is confusing. is it really taking 30 seconds to get out of the initramfs, or am I doing something to block it by mistake?
[19:45] <jono> brb rebooting
[19:45] <jdstrand> kees: I am adding /tmp/pulse-*/ stuff to the audio abstractino though
[19:45] <cjwatson> oh, hah - & on that strace might be an idea
[19:46] <jdstrand> we never saw it cause our gui apps use user-tmp
[19:46] <kees> jdstrand: aaah, yeah
[19:47] <jdstrand> I'm really not keen on the /dev access, but there isn't anything I can do but add it and comment on it
[19:48] <jdstrand> people can fine-tune it if needed
[19:48] <mdz> ttx, I've pushed new question text to the Ubuntu branch
[19:48] <mdz> ttx, it should be ready to test and upload now
[19:48] <ttx> mdz: ok, building and quicktesting now.
[19:50] <jono> ok
[19:50] <jono> the error I get on boot shortly after it says grub is loading is:
[19:50] <jono> e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
[19:50] <jono> this is just before the AppArmour profile
[19:51] <jono> I assume this is a kernel bug
[19:51] <jono> pgraner, ^
[19:52] <robbiew> I get a similar message
[19:52] <robbiew> so it may be a thinkpad thing
[19:52] <jdstrand> oh, I do too
[19:52] <robbiew> worth reporting...could simply be a nag message
[19:52] <robbiew> for apw to help clean up
[19:52] <jdstrand> I do not have a thinkpad, but an intel mobo
[19:52] <jono> ok, I will file it
[19:52] <pgraner> jono, robbiew: I'm not seeing it on my non-stinkpad
[19:52] <robbiew> driver related then?
[19:53] <jono> pgraner, should I file against the kernel?
[19:53] <pgraner> robbiew: most likely we updated to .31.1 in the last upload
[19:53] <jono> I also have the messages I see before xsplash, will file a bug against those too
[19:53] <pgraner> jono: yea and assign it to rtg and make it high
[19:54] <jono> pgraner, will do
[19:54] <robbiew> jono: that pci_enable message should be in your dmesg output as well
[19:54] <jono> pgraner, what package name do I pass to ubuntu-bug?
[19:54] <jono> robbiew, thats where I dug it out from
[19:54] <mdeslaur> jderose: looks good to me
[19:54] <robbiew> linux
[19:54] <mdeslaur> jderose: sorry, not you
[19:54] <pgraner> jono: -p linux
[19:54] <mdeslaur> jdstrand: looks good to me
[19:55] <jono> pgraner, ta
[19:55] <jono> pgraner, might be sensible to have an alias for 'kernel' that points to 'linux'
[19:56] <pgraner> jono: give me the bug number when your done
[19:56] <jono> pgraner, will do
[19:57] <pgraner> jono: there you go thinking like a normal person...
[19:57] <robbiew> lol
[19:57] <robbiew> pgraner: I'm now deeply offended
[19:57] <robbiew> lol
[19:58] <maco> -p sound aliasing to linux but doing the "apport-collect -p alsa-base" thing might be nice too
[19:58] <maco> since right now thats two steps
[19:59] <jono> pgraner, it was already reported:
[19:59] <jono> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/436370
[19:59] <pgraner> jono: ack, I'll get rtg on it
[20:00] <jono> pgraner, I haven't changed the priority on this yet - you may want to do this
[20:00] <ttx> mdz: just updated the branch (got rev631), it's not the text with the "delimited by spaces" example.
[20:00] <jono> robbiew, where do you think I should file these boot messages before xsplash? is that an upstart thing?
[20:00] <pgraner> jono: ack
[20:00] <jono> pgraner, cheers buddy
[20:01]  * ttx pushes the revised version.
[20:02] <robbiew> jono: just add ubuntu-boot in the tag and subscribe me
[20:02] <jono> robbiew, will do
[20:02] <robbiew> then I can triage
[20:03] <jono> thanks pal
[20:07] <jono> robbiew, done: https://bugs.edge.launchpad.net/ubuntu/+source/upstart/+bug/438335
[20:08] <robbiew> ack
[20:10] <slangasek> mdz, kirkland, ttx, mathiaz: server ISO build is up
[20:10]  * mathiaz syncs
[20:10] <ttx> slangasek: ok
[20:10] <jono> kirkland, do you still need some community testing?
[20:10] <jono> or are you doing fine with the level of testing going on now?
[20:11] <davmor2> slangasek: is this the uec image with update?
[20:12] <slangasek> davmor2: no, this is a server ISO with updated eucalyptus packages
[20:12] <davmor2> slangasek: :) thanks
[20:15] <mdz> slangasek, thanks
[20:16] <mdz> mathiaz, davmor2's work in progress test plan is at http://testcases.qa.ubuntu.com/Install/ServerEConfig
[20:16] <mdz> kirkland, ttx, ^^
[20:20] <siganderson> a me su karmic è sparito sistema->amministrazione->servizi ... è normale?
[20:22] <siganderson> oops... sorry
[20:22] <pgraner> jono, robbiew: can you try booting with apparmor=0 on your grub line and see if that message goes away
[20:22] <robbiew> I could...if I cared :P
[20:23] <robbiew> sure one sec
[20:23] <pgraner> robbiew: dooh
[20:24] <jono> siganderson, sorry this is an english speaking channel
[20:24] <siganderson> I have nomore system->amministration->services is it normal? If i type services-admin in the terminal it says that I must install gnome-system-tools, but I have it already installed
[20:25] <jono> pgraner, glad Robbie cares :-)
[20:26] <pgraner> jono: yea tell me about it
[20:26] <jono> haha
[20:28] <slangasek> doko: is this openjdk nss build-dep going to change the package size and impact CD sizes?
[20:31] <doko> slangasek: no, libnss3 is already on the CD, but it's only useful if ca-certificates-java is accepted as well, and ca-certificates is synced to import the new certificates from the start
[20:31] <robbiew> pgraner: the message is gone...but I also got "* AppArmor not available as kernel LSM.                       [fail]"
[20:31] <doko> slangasek: ahh, wait ... please reject it
[20:32] <slangasek> doko: both? or just openjdk?
[20:33] <doko> slangasek: no openjdk-6 only, the dependency is libnss3-1d ... damn dlopened code ...
[20:33] <slangasek> ok, done
[20:33] <slangasek> (neither appears to be something I'm going to accept during the beta freeze, anyway)
[20:34] <pgraner> robbiew: ok thanks
[20:41] <smoser> slangasek, is it allowed to un-mark something for beta ? i think that bug 414997 is functioning as it should, with no chnages needed other than documentation. so i dont think it needs to be beta block, and i'd like to wait on soren before doing anything rash.
[20:42] <slangasek> smoser: that bug is /not/ marked as a beta blocker
[20:42] <slangasek> smoser: only bugs that are targeted to the release are blockers
[20:43] <smoser> oh. i didn't realize that. so that bug is set to 9.10 beta milestone, but it needs a karmic track that is milestoned that in order to be blocker ?
[20:43] <slangasek> smoser: correct.  so if there are other bugs that you think are marked as beta blockers, you may want to double-check that this is really the case
[20:43] <smoser> agreed!
[20:46] <rickspencer3-afk> slangasek, any chance you could do a review of desktopouch and couchdb?
[20:47] <slangasek> rickspencer3: reviewing of what?
[20:47] <rickspencer3> the packaging, I suppose
[20:47] <rickspencer3> before it gets uploaded
[20:47] <slangasek> rickspencer3: better to have someone else do it today
[20:47] <rickspencer3> slangasek, ok
[20:48] <slangasek> rickspencer3: btw, someone needs to attend to erlang's build-dependency on wxwidgets2.8
[20:48] <ia> hello. could you tell me, please, where (in system) i can find grub boot picture (which can be seen after boot menu, but before gdm appears) - white ubuntu logo on black background.
[20:48] <slangasek> rickspencer3: wxwidgets2.8 is in universe, either it needs an MIR or erlang needs to not b-d on it (I think the latter is much saner)
[20:49] <rickspencer3> oops
[20:50] <kenvandine> it should definately not b-d on wxwidgets
[20:50] <slangasek> -rw-r--r-- 1 lp_publish lp_publish 36710522 Nov  5  2008 /home/lp_archive/ubuntu/pool/universe/w/wxwidgets2.8/wxwidgets2.8_<IP_ADDRESS>.orig.tar.gz
[20:50] <slangasek> (much, /much/ saner)
[20:50] <ttx> slangasek: new eucalyptus just uploaded per mdz latest changes, please review and if approved, trigger a CD build with it.
[20:50]  * ttx is calling it a day
[20:50] <slangasek> ttx: how urgently is that wanted?  there are several other CD-affecting changes that I need to review and accept for beta
[20:50] <slangasek> (d-i)
[20:51] <slangasek> if it affects your testing timeline I'll do eucalyptus first, otherwise I'll process them in order of the number of CDs they affect
[20:51] <ttx> slangasek: it would be great if I could get the new server ISO toasted for tomorrow's breakfast (European time) :)
[20:51] <slangasek> ttx: right, that's not a challenge then :)
[20:52] <slangasek> ogra: redboot-tools> needed for beta?
[20:52] <ttx> slangasek: others might raise priority, though.
[20:52] <slangasek> ogra: (not clear from the changelog, no bug references)
[20:54] <slangasek> kenvandine: well, it builds the erlang-wx binary, which rather distinctly involves wxwidgets.  I'd be fine if we dropped it, but it has reverse-deps...
[20:54] <slangasek> (erlang-{common-test,debugger,megaco,reltool,x11})
[20:55] <kenvandine> i know nothing about the erlang package
[20:55] <slangasek> but you have an opinion on whether it should b-d on wxwidgets? :)
[20:58] <kenvandine> slangasek, looking
[21:00] <kenvandine> slangasek, it looks like this was added in debian back in april, have we just not synced with them in a while?
[21:00] <mathiaz> kirkland: mdz: why is postfix installed with a cluster controller?
[21:03] <slangasek> kenvandine: the present erlang package in Ubuntu dates to Jun 18, this has probably been an outstanding problem since erlang was promoted
[21:03] <rickspencer3> slangasek, is that erlang-wx dependency blocking beta?
[21:04] <mathiaz> kirkland: mdz: well I've found why - eucalyptus-cloud needs it to be able to send email when accounts are created
[21:04] <slangasek> rickspencer3: no, but we should be making progress on it now so it can be resolved immediately post-beta
[21:04] <rickspencer3> slangasek, ack
[21:04] <rickspencer3> is there a bug #?
[21:04]  * rickspencer3 checks
[21:05] <slangasek> rickspencer3: no, I haven't filed one yet
[21:05] <rickspencer3> ok
[21:05] <rickspencer3> slangasek, I'll take care of logging the bug
[21:05] <slangasek> rickspencer3: thanks
[21:05] <rickspencer3> I'll assign to kenvandine, and you should see progress in the next day or so
[21:05] <slangasek> rickspencer3: best to file the bug w/ tasks against both erlang and wxwidgets2.8
[21:06] <rickspencer3> k
[21:21] <rickspencer3> slangasek, I wasn't smart enough to figure out what wxwidgets project to assign it to ... so there's only the one task
[21:22] <slangasek> rickspencer3: 'also affects distribution' -> wxwidgets2.8 + ubuntu
[21:22] <slangasek> (bug #?)
[21:22] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/erlang/+bug/438365
[21:22] <rickspencer3> there's only wxwidgets2.6 (that I could find)
[21:23] <slangasek> rickspencer3: I think you're probably searching in the wrong place, then; note that you have to use "also affects distribution", not "also affects project"
[21:23] <rickspencer3> aah
[21:24] <rickspencer3> d'oh
[21:24] <slangasek> "project" is for things that aren't packages :)
[21:30] <jdstrand> soren: hi! I've been meaning to tell you that I have a little bash script you can use/extend/steal/whatever. it's not the prettiest thing you'll ever see, but I found it helpful
[21:30] <jdstrand> soren: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head%3A/scripts/apparmor/libvirt-apparmor.sh
[21:45] <slacker_nl> hello
[21:45] <slacker_nl> how can one change the something on the following page: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[21:55] <seb128> slangasek, I've just uploaded a nautilus update which fix a bug in the xsplash code, it's a one word change to use the correct software name
[21:56] <seb128> slangasek, without that xsplash waits for a "nautilus" which never registers
[21:59] <slangasek> seb128: ok - does that mean with this fix, we now get proper xsplash -> desktop transitions? (timeout + watch are both correct?)
[22:00] <seb128> slangasek, yes
[22:00] <slangasek> rockin'
[22:01] <seb128> slangasek, oh question for you since you are around
[22:01] <seb128> slangasek, how would you recommend running a command with an another user in a postinst?
[22:02] <slangasek> seb128: su -c?
[22:05] <seb128> slangasek, ok thanks
[22:07] <slangasek> mathiaz, soren, kirkland, smoser: should linux-headers-ec2 be seeded somewhere? (components-mismatches wants to drop them to universe)
[22:13] <slangasek> tedg: did I read correctly that you're working on bug #436181 today?
[22:13] <tedg> slangasek: Nah, we decided that it wasn't a bad enough user experience ;)
[22:14] <tedg> slangasek: Yeah, I'm not sure of the root cause.  But I have a branch that I can't get to crash.  seb128 has volunteered to test on his setup.
[22:14] <slangasek> ok
[22:14] <seb128> I'm just doing this gdm change first
[22:14] <seb128> slangasek, "su -c 'gconftool --get /desktop/gnome/interface/gtk_theme' gdm"
[22:15] <seb128> slangasek, is there anything stupid in this command?
[22:15] <slangasek> looks sane to me
[22:15] <seb128> it's not supposed to write on stdout?
[22:15] <slangasek> you may or may not need a '-i' as well to specify that it's a login shell
[22:15] <seb128> because it doesn't
[22:16] <slangasek> dunno
[22:16] <slangasek> er, not -i -- -l
[22:16] <slangasek> but no, that doesn't help either
[22:17] <slangasek> seb128: oh, -s /bin/sh
[22:17] <slangasek> instead of trying to execute the command using the /bin/false shell ;)
[22:17] <seb128> now it makes sense ;-)
[22:17] <seb128> slangasek, thanks
[22:17] <slangasek> sure
[22:20] <mathiaz> slangasek: yes - probably
[22:21] <mathiaz> slangasek: I'd suggest on the dvd seed
[22:21] <mathiaz> slangasek: to keep it in main
[22:21] <slangasek> mathiaz: mumble; nothing else from ec2 is on the dvd seed
[22:21] <mathiaz> slangasek: right - the rest is in the uec seed
[22:22] <slangasek> the dvd seed corresponds to an actual image, please don't use it "to keep [things] in main" :)
[22:22] <mathiaz> slangasek: which is what is installed by default in uec
[22:22] <mathiaz> slangasek: I don't think we wanna have the headers installed by default the uec image
[22:22] <mathiaz> slangasek: ok - so where else should it go?
[22:22] <slangasek> that's fine - in that case, the supported seeds would be the right place for it
[22:22] <mathiaz> slangasek: ok - supported then
[22:23] <slangasek> supported-kernel, specifically
[22:25] <mathiaz> slangasek: should I add to this line (in supported-kernel)? http://paste.ubuntu.com/280726/
[22:25] <mathiaz> slangasek: I'm not that ec2 should be considered at the same level as -virtual
[22:25] <slangasek> mathiaz: yep - I see a couple other things to clean up in there though, so I'm happy to take care of it
[22:26] <slangasek> (e.g., "backports-jaunty" is wrong :)
[22:26] <mathiaz> slangasek: ok - I'll let you add it during your cleanup
[22:38] <kirkland> mathiaz: right, email needed to create accounts
[22:38] <slangasek> siretart: any reason to regard the auctex upload as beta-critical?
[22:38] <kirkland> slangasek: mdz: i'm syncing the iso's now
[22:39] <kirkland> jono: some testing would be great, yeah;  what else do you need from us to make that happen?
[22:39] <kirkland> slangasek: regarding the kernel seed, "yes, probably so..."  but I'm not the expert on that one
[22:39] <kirkland> slangasek: do we have an ec2-image seed?
[22:40] <slangasek> kirkland: there's a uec seed; mathiaz said he didn't think it was needed there; I've seeded it in supported-kernel
[22:40] <kirkland> slangasek: hmm... maybe jjohansen1 knows?
[22:40] <slangasek> mm?
[22:40]  * jjohansen1 goes to read scroll back
[22:41] <slangasek> kirkland: I do agree with mathiaz that I think it's unlikely to be needed by default, so there's no need to include it in our image; so supported-kernel is the sensible place to keep it around
[22:42] <kirkland> slangasek: coolio
[22:42] <jono> kirkland, we would still need http://testcases.qa.ubuntu.com/System/Eucalyptus updating will a full set of tests and where to report feedback
[22:42] <jono> I can push the message if that page is updated, but I would need that first
[22:43] <kirkland> mdz: i'm just getting the message about notifying eucalyptus about iso's, as I've been flying all day today
[22:43] <kirkland> mdz: i'll tell them now
[22:44] <slangasek> smoser: what else is needed to close out bug #431103 for beta?
[22:49] <siretart> slangasek: no, auctex is not beta-critical. post-beta it is required for emacs23
[22:51] <slangasek> siretart: ok
[22:51] <slangasek> siretart: (motu-release has approved emacs23?)
[22:56] <siretart> slangasek: yes, they did. the bug is referenced in the changelog
[22:57] <siretart> that's bug #433397, BTW
[22:57] <slangasek> siretart: ok, cool
[23:00] <siretart> TBH, I even think we should even promote it for main, and demote emacs22 to universe. I've been using pre-release versions of emacs23 for over a year, and I'm totally sold by emacs23
[23:00] <siretart> but that's a different story
[23:00] <seb128_> slangasek, I've uploaded a new gdm which set a specific theme for the login screen
[23:01] <slangasek> seb128_: thanks, will review
[23:01] <seb128_> thanks
[23:01] <slangasek> siretart: not something I'm inclined to consider post-beta
[23:02] <siretart> you aren't an emacs user, are you? ;-)
[23:03] <siretart> anyway, you're probably right, because a lot of add-on package need to become 'emacs23'-enabled, like I just did for auctex
[23:03] <slangasek> siretart: heh, my editor usage is secondary to my RM hat. >:)
[23:04] <siretart> that's rather straight forward for most packages, but it will take some time to get it sorted out, given our bad performance at preparing the emacs23 package :-(
[23:08] <mathiaz> kirkland: hey - going through http://testcases.qa.ubuntu.com/Install/ServerEConfig
[23:08] <mathiaz> kirkland: point 3 ran into an error: http://paste.ubuntu.com/280758/
[23:08] <mathiaz> kirkland: BTW I don't have br0 interface configured on the CC
[23:16] <mdz> mathiaz, kirkland, how is it going?
[23:16] <mathiaz> mdz: I've just installed the CC and the NC on two physical systems
[23:16] <mdz> mathiaz, steps 1-7 are obsolete with the current build
[23:17] <mdz> everything should be registered automatically
[23:17] <kirkland> mdz: sync'd ISO's to home; i'm at the airport now, won't be home for a few hours
[23:17] <mathiaz> mdz: is the bridge interface supposed to be setup automatically on the CC?
[23:17] <kirkland> mdz: i just reviewed davmor's test instructions; they look good
[23:17] <mdz> mathiaz, not afaik; I believe only the node controller gets a bridge set up
[23:17] <kirkland> mathiaz: i don't think the CC needs a bridge
[23:18] <mdz> kirkland: you mean the steps after #7, right?
[23:18] <mathiaz> kirkland: mdz: oh right.
[23:18] <mdz> actually I lie. #2 and #6 are still valid
[23:18] <mdz> the node won't be registered automatically yet
[23:18] <kirkland> mdz: minus the manual registration, you mean?
[23:19] <mdz> I'll just go ahead and edit it
[23:19] <mdz> kirkland: the SC, walrus and CC will be registered automatically now
[23:19] <mdz> but the nodes are still manual
[23:21] <mathiaz> mdz: step 6# gave me an error: http://paste.ubuntu.com/280769/
[23:22] <mdz> mathiaz, I have never done that bit before; ask #eucalyptus?
[23:22] <mathiaz> mdz: ok
[23:29] <NCommander> Can someone confirm a bug for me? Anyone with the en_US lang, and latest karmic, please run apt-get update on the console, and see if you get , vs. .
[23:29] <NCommander> (separating numbers that is)
[23:30] <NCommander> er wait, nm
[23:30] <NCommander> bah, false alarm
[23:35] <Turl> Hi
[23:36] <Turl> can you guys tell me why my karmic firefox says "shiretoko" in the title? it has all the firefox branding in the other places
[23:44] <slangasek> mdz, kirkland, mathiaz: 20090928.2 is now the current server ISO, including eucalyptus ubuntu10
[23:49] <slangasek> TheMuso: where have things landed wrt alsa and ia32-libs for karmic?  update-manager tells me it doesn't want to upgrade lib32asound2-plugins
[23:50]  * mathiaz syncs
[23:54] <mdz> slangasek, thank you
[23:54] <TheMuso> slangasek: I put libasound2-plugins back into ia32-libs and reverted the changes made to lib32asound2-plugins...
[23:57] <slangasek> TheMuso: ok, cool - unfortunately, installing lib32asound2-plugins wants to remove ia32-libs, and nothing else wants to kick lib32asound2-plugins out for me... looks like some tweaking may still be needed here?