[00:00] <TheMuso> slangasek: I don't know. I simply put it back to the way things were before. I'll have a look.
[00:00] <TheMuso> slangasek: afaik originally they conflicted.
[00:01] <slangasek> TheMuso: ah, indeed they do
[00:01] <slangasek> TheMuso: perhaps ia32-libs needs to have a Conflicts: added in the other direction?
[00:02] <cjwatson> they originally conflicted and there was a bug about that
[00:02] <cjwatson> I think you need to revert slightly less far - I think that was fixed at one point?
[00:06] <TheMuso> Anyway, I'll have a look today.
[00:06] <slangasek> cjwatson: I'm not sure that's true; my recommendation (which, er, somehow isn't in the list web archive?) was to put alsa back into ia32-libs
[00:06] <TheMuso> It will take me several hours to upload ia32-libs as it is.
[00:06] <slangasek> yeah
[00:06] <slangasek> ia32-libs is in universe, not blocking anything for beta, so take your time
[00:06] <cjwatson> slangasek: that may be, I might be misremembering
[00:15] <slangasek> cjwatson, TheMuso: reviewing the current state: lib32asound2-plugins is built from alsa-plugins, which build-depends on libpulse-dev, which has no biarch equivalent; so we end up with a biarch plugins package without the key default plugin - I think that binary package should be nuked entirely for karmic, and ia32-libs have a conflicts: added only if that conflicts: is needed for upgrades from jaunty
[00:15] <TheMuso> slangasek: Ok I can take care of both.
[00:26] <seb128> slangasek, I've uploaded a patched indicator-session with changes from ted to fix the crash at login issue
[00:27] <seb128> I tried the change there they seem to work correctly, ie I didn't get the crash yet where I was getting it half of the time before
[00:30] <smoser> slangasek, regarding your question above about bug #431103. we need a kernel build of 2.6.31-300.3. jjohansen was looking to get one, i think.
[00:49] <Rashko> hi all
[00:49] <Rashko> how can I enable more than 4 serial ports
[00:50] <Rashko> I need some help please
[00:51] <Rashko> 2 pci cards 6 + 4 serial ports but only 4 ports is active
[00:51] <Rashko> how can I enable more than 4 serial ports
[00:51] <mathiaz> smoser: slangasek: is uec-images.ubuntu.com rsyncable?
[00:52] <smoser> according to soren at https://wiki.ubuntu.com/UEC/Images/Testing , yes. and my experience agrees
[01:15] <slangasek> smoser: the kernel build is already done; I'm asking about the task open on ec2-init
[01:15] <smoser> as far as I know the kernel build is not done.
[01:16] <smoser> $ rmadison --suite karmic linux-ec2
[01:16] <smoser>  linux-ec2 | 2.6.31-300.3 |        karmic | source
[01:16] <smoser>  linux-ec2 | <IP_ADDRESS>0.0 |        karmic | amd64, i386
[01:16] <smoser> and my feeling about ec2-init is that no changes are needed, but I would like an official kernel build to verify that in.
[01:16] <smoser> i could be reading that information wrong, or otherwise ignorant
[01:17] <slangasek> smoser: your rmadison is out-of-date wrt the archive
[01:18] <smoser> oh?
[01:18] <cjwatson> our rmadison only updates every six hours
[01:19] <smoser> this makes me happy
[01:22] <smoser> slangasek, so, maybe nothing. i'll wait till the build pulls that version, and picks it out with initrd/kernel then will upload those kernels and test them.
[01:24] <slangasek> smoser: the current build /already/ has that version :)
[01:24] <slangasek> would be good to have this confirmed, since that's marked as a beta blocker
[01:30] <mase_wk_> i'm having some problems building a kernel package on 8.04 which will automatically run update-initramfs. I am passing the --initrd flag to make-kpkg however it does not seem to update the initramfs
[01:30] <smoser> slangasek, i meant http://uec-images.ubuntu.com/karmic/current/ubuntu-uec-karmic-amd64.manifest
[01:31] <slangasek> smoser: yes, I see -300.3 listed there
[01:33] <slangasek> smoser: oh, I see; you're looking at the linux-ec2 *binary* package, which is not built from linux-ec2 source - it's built from linux-ec2-meta source and will not have a matching version number
[01:33] <slangasek> smoser: the actual kernel image is already at version -300.3, so this fix should be present
[01:33] <slangasek> mase_wk_: this is not a support channel; please see #ubuntu
[01:33] <mase_wk_> slangasek: np, thanks
[01:38] <smoser> slangasek, ok. there will be a 0929 build in the next 20 minutes or so. i'll take its output and upload to ec2 later tonight.
[01:38] <slangasek> smoser: why are you waiting when the existing one already has the relevant kernel?
[01:39] <smoser> i guess i can upload the kernel from last nights you're correct. i just was being lazy.
[01:39] <smoser> and i might as well refresh the nightly that i have out there (or at least check whats different in the manifest0
[02:13] <rgreening> ScottK: ping
[02:13] <rgreening> Can you look at bug 425751
[02:14] <rgreening> ScottK: not sure if you can fix or at least direct to someone who can and set the correct milestone
[02:32] <ScottK> rgreening: Fixed.
[02:32] <rgreening> ty ScottK
[02:36] <rgreening> ScottK: will you be updating the bug to reflect? Thanks
[02:37] <ScottK> rgreening: Did already.
[02:37] <rgreening> ah.. I see it has updated.
[02:37] <rgreening> cool
[02:37] <rgreening> yay
[02:38] <rgreening> ScottK: just read the comment... does this mean it is ok for Ubuntu seed as well? Or does it just need to be in 'a' seed?
[02:39] <ScottK> rgreening: "a seed" is all that was needed.
[02:39] <rgreening> cool. understood.
[03:00] <LaserJock> so hmm, I can't seem to get Karmic to play a CD
[03:01] <LaserJock> seems to be bug 435035 but there's not a lot of info
[03:04] <LaserJock> darn it, now I can't get the CD to eject :(
[03:13]  * ScottK hands LaserJock a large hammer and a screwdriver ...
[03:15] <LaserJock> I got it out eventually
[03:15] <LaserJock> but still sucks that I can't listen to my brand new CD :(
[03:16] <ajmitch> Yes, it does seem a bit of a problem if it just doesn't work in karmic
[03:17] <ajmitch> I'm too used to having all the music on the computer already
[03:17] <LaserJock> rhythmbox, banshee, totem, nothing works
[03:17] <ajmitch> they all use the same gstreamer plugins
[03:18] <LaserJock> yep
[03:18] <LaserJock> I guess I could try amarok ... but yuck
[03:18] <ajmitch> or try & use sound-juicer to create .oggs?
[03:18] <LaserJock> hmm, perhaps. I was assuming if it wouldn't play it wouldn't rip very well
[03:19] <ajmitch> from what I read in that bug, they still had sound-juicer working, which is odd
[03:19] <ajmitch> since it also uses gstreamer for ripping & encoding
[03:19]  * ajmitch doesn't have an up-to-date karmic install booted to check
[03:49] <Darxus> It's looking like the upcoming ubuntu release will have a default chat client that will not let you use it without saving your passwords.
[03:50] <Darxus> How do I get the attention of somebody who can prevent that?
[03:50] <Darxus> https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/118800
[04:02] <ScottK> Darxus: That's a pretty old bug, is it still accurate for the current release?
[04:05] <jdong> ScottK: yup reproduced here
[04:05] <jdong> the apply button is greyed out unless you type in a password
[04:05]  * ScottK looks
[04:06] <jdong> I see no obvious way from the UI to create an account without saving a password
[04:07] <Darxus> ScottK: Yup.
[04:07] <Darxus> Bizarre, huh?
[04:08] <jdong> well yeah kind of; I can certainly understand the concern
[04:08] <jdong> though I have to point out 99% of users will want their passwords remembered
[04:08] <jdong> (not saying we shouldn't cater to the others)
[04:09] <ScottK> Darxus and jdong: I did the LP magic to get it on the release team's radar.  Not sure what they will do with it.
[04:09] <jdong> ScottK: *nods* thanks
[04:10] <jdong> I just admit I haven't touched Empathy much to know if it'd be a big deal (tm) to implement this feature
[04:10] <Darxus> ScottK: Thank you.
[04:10] <TheMuso> It would likely break UI freeze
[04:11] <jdong> we could just... bring back pidgin
[04:11] <jdong> *puts on flamesuit*
[04:13] <LaserJock> jdong: +1
[04:17] <LaserJock> I thought pidgin had a good chance of coming back, but I guess it's a little late now
[04:17] <Darxus> LaserJock: Why did you think it had a good chance of coming back?
[04:18] <LaserJock> well, it's hard to put it well
[04:18] <LaserJock> I just felt like empathy really didn't rise to the occasion
[04:19] <Darxus> Ah.
[04:19] <LaserJock> it seems like a basic, minimalistic IM client but not much more
[04:19] <Darxus> Heh.
[04:20] <LaserJock> I haven't seen much of an "improvement" in empathy in like a year, I expected more I guess
[04:20] <Darxus> I'm disappointed it doesn't have the gui and backend separated into client / server pieces like quassel.
[04:21] <Darxus> Because as long as I can't do a single reattach to get back to my four irc servers, jabber, aim, and yahoo, I'll still primarily be using a console client in screen :/
[04:22] <jdong> well I'm not impressed with how quassel is separated either
[04:23] <Darxus> I haven't actually tried it yet.
[04:23] <jdong> why is there a single system daemon installed by the package to be shared by all users?
[04:23] <Darxus> Ew.
[04:23] <Darxus> Well... I don't know....
[04:23] <jdong> but yeah, the IDEA behind quassel/smuxi is nice
[04:24] <Darxus> Oh, thanks for mentioning smuxi, wasn't aware of that one.
[04:25] <jdong> Darxus: it's pretty nice and I found its codebase to be very clean to work with; though in terms of raw features it lags behind quassel, irssi, weechat
[04:25] <Darxus> But it would be nice to be able to drop bitlbee too (mostly requiring jabber support).
[04:26] <Darxus> How hard could this stuff really be, I've done irc over telnet?  :P
[04:26] <jdong> but as far as empathy is concerned, I totally agree with what LaserJock's opinions are on the matter
[04:26] <jdong> in its current state it still looks and feels like a proof-of-concept/rough-cut basic IM client, not something I feel should've replaced pidgin by default
[04:27] <ScottK> jdong: I don't think that there is a single system daemon shared by all users with the quassel monlithic client (the one we use as default).
[04:27] <ScottK> If you use a remote core on a server somewhere, it can support multiple clients.
[04:27] <Darxus> And you feel that pidgen is more solid?
[04:27] <jdong> ScottK: the last time I installed it on Jaunty (two weeks ago) it ran a single server via an init job
[04:28] <ScottK> I'll have a look.
[04:28] <jdong> Darxus: yes, I do feel it's more solid and featureful though it lacks the AV capabilities
[04:28] <Darxus> Interesting.
[04:28] <LaserJock> and it has *gasp* preferences
[04:28] <jdong> LaserJock: but... we don't need those!
[04:28] <jdong> LaserJock: the last time *I* made an IM client, it had a big textbox and a little textbox!
[04:29] <Darxus> Hehe.
[04:36] <Darxus> I created a bug for quassel/smuxi type functionality in empathy:  https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/438502
[04:36] <Darxus> I realize it's not going to happen any time soon.
[04:36] <Darxus> I can't nominate for Lucid yet?  :P
[04:37] <ScottK> That's something to file in an upstream bug tracker.  Ubuntu wouldn't do that split without upstream.
[04:38] <Darxus> Oh, hmm.
[04:39] <ajmitch> it is a fairly major change for an app
[04:39] <Darxus> I realize.
[04:39] <Darxus> I'm filing an upstream bug.
[04:40] <LaserJock> ajmitch: pfft, I'm sure it'd make the Papercut list ;-)
[04:42] <Darxus> Doesn't LP have a way to link to a gnome bug?
[04:42] <ajmitch> LaserJock: I'll let you take on that one :)
[04:44] <Darxus> Hehe.
[04:44] <johnp> hello.
[04:47] <Darxus> Cool, figured out how to link the upstream bug.
[04:47] <Darxus> ("also affects project")
[05:45] <YokoZar> package ttf-tahoma-replacement 1.1.30-0ubuntu2 failed to install/upgrade: error writing to '<standard output>': No such file or directory
[05:45] <YokoZar> ^^ best error report yet :)
[05:46] <StevenK> Haha
[05:47] <YokoZar> https://bugs.launchpad.net/bugs/438391
[06:36] <al-maisan> Good morning!
[06:39]  * slangasek waves
[06:44] <slangasek> TheMuso: hmm, your alsa-plugins upload also drops three patches out of debian/patches
[06:49] <dholbach> good morning
[07:18] <TheMuso> slangasek: hrm I'll have a look.
[07:22] <TheMuso> slangasek: hrm screwed up with creating the package. Feel free to reject, and I'll re-upload.
[07:29] <pitti> Good morning
[07:31] <al-maisan> Good morning pitti
[07:37] <slangasek> TheMuso: ack, rejected the first one
[08:21] <stefanlsd> YokoZar: Just wanted to say thanks so much for the wine1.2 packages and quick updates. Its really awesome :)
[08:33] <YokoZar> stefanlsd: at some point soon I'm going to have to freeze it for karmic though
[08:33] <YokoZar> although I still need some manual patches (eg one that lets photoshop install)
[08:35] <stefanlsd> YokoZar: yeah. will go back to your ppa then i guess once its frozen.
[08:40] <highvolt1ge> morning YokoZar and stefanlsd
[08:51] <AnAnt> LP 438092
[08:59] <dholbach> cjwatson_: AFAICT you fixed the alt-f7 gdm switching thing - good work! :)
[09:17] <tkamppeter> pitti, hi
[09:19] <pitti> hey tkamppeter
[09:21] <tkamppeter> pitti, it is about bug 420015
[09:21] <tkamppeter> There are still users who cannot access their USB printers.
[09:23] <pitti> tkamppeter: Debian users complain _a lot_ about the libusb change as well
[09:23] <pitti> it breaks tons of stuff and third-party apps which need it
[09:23] <tkamppeter> pitti, then I have tried the situation of my HP printers and found that the HP DesignJet 130 appears in "ls -l /dev/bus/usb/*/*" but not in "lsusb". Looks like a low-level USB problem.
[09:23] <pitti> tkamppeter: nope
[09:23] <pitti> tkamppeter: try "sudo lsusb"
[09:23] <pitti> tkamppeter: the problem is that these devices aren't world-readable any more with the new udev rule (it makes them 660 root:lp)
[09:25] <maxb> cjwatson_: It seems that something is causing postinst failure on upgrade - your emit events change seems like a likely candidate
[09:25] <tkamppeter> Yes, it is exactly only the DesignJet 130 which needs "sudo usblp".
[09:25] <Whoopie> asac: Hi, I tested the patch for bug 413053 and it's working.
[09:25] <maxb> cjwatson_: err, oops, the word "gdm" was supposed to be in that sentence somewhere :-)
[09:26] <maxb> lp 438561
[09:27] <tkamppeter> pitti, what I have seen in bug 420015 is that a user uses /dev/usbmon3 as URI for an Epson. Seems that this is a third-party device generated by a daemon of a manufacturer-supplied driver and this daemon passes the data on to something like /dev/usb/lp0 which does not exist any more with CUPS 1.4.x.
[09:30] <asac> Whoopie: checking
[09:30] <Whoopie> asac: just told you as you were asking in the report. ;)
[09:31] <asac> ok
[09:31] <asac> we will get it fixed after beta
[09:32] <Whoopie> asac: ok, a new 2.28.1 was tagged in gnome-bluetooth git which fixes it (and some other issues I debugged with the maintainer)
[09:33] <asac> Whoopie: ok. thanks. if you know further launchpad bugs fixed, please set to fix committed
[09:34] <Whoopie> asac: what do you think about bug 436694? Could we ship the same udev rule as fedora does?
[09:34] <cjwatson> dholbach: excellent, glad it works for you
[09:34] <cjwatson> maxb: hmm
[09:35] <cjwatson> maxb: I don't think that can possibly be my change, since the gdm postinst doesn't actually restart the job
[09:35] <cjwatson> maxb: it's more likely the pre-existing 'status gdm' in the postinst
[09:35] <slangasek> asac: epiphany> if you want it demoted, please go ahead and unseed it
[09:36] <cjwatson> maxb: I could be wrong of course, but I can't see the mechanism by which my change would have broken this
[09:37] <Whoopie> asac: btw, why after beta? it's one month since then.
[09:37] <asac> Whoopie: one month? read /topic ;)
[09:38] <asac> slangasek: ok. i will double check with seb one last time.
[09:38] <seb128> asac, go for it
[09:38] <asac> kk
[09:39]  * asac updates seeds
[09:39] <Whoopie> asac: hehe, sorry. on https://wiki.ubuntu.com/KarmicReleaseSchedule, I just read "23" and "october". ;)
[09:52] <asac> Whoopie: how does that udev rule help?
[09:54] <mat_t> cjwatson: hi
[09:54] <YokoZar> seb128: I believe https://bugzilla.gnome.org/show_bug.cgi?id=468445  needs to be reopened now (and you are the reporter upstream)
[09:55] <cjwatson> mat_t: hello
[09:56] <seb128> YokoZar, reopening closed bugs because you have a similar issue in newer versions is usually not the right thing
[09:56] <YokoZar> I think it's the same issue though
[09:56] <YokoZar> The save as dialog is still focusing wrong
[09:57] <seb128> YokoZar, the code could have changed and comments about debugging on the old code will just creating confusion
[09:57] <YokoZar> Ahh ok
[09:57] <YokoZar> https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/130224  <-- launchpad link, should file a new gnome one then
[09:57] <seb128> open a new bug if you want rather
[09:57] <seb128> and mention the old one number
[09:57] <YokoZar> yeah np
[09:57] <seb128> thanks
[09:57] <seb128> I'm too busy to work on minor issues like that
[09:57] <seb128> but opening upstream would be nice
[09:58] <pitti> tkamppeter: right, what I meant; there are also tools for ink levels etc. which only work with usblp
[10:00] <ogra> casper on slow media with no progressbar at all in usplash is not a very pleasant experience
[10:01] <MacSlow> asac, can you quickly look over https://bugs.edge.launchpad.net/notify-osd/+bug/438312
[10:05] <asac> MacSlow: invalidated and moved to applet ... even though i dont think its something we did before
[10:05] <asac> thx
[10:06] <MacSlow> asac, ok thanks... I wasn't sure... initially I thought Mio ran into a "suppress display of a notification"-situation, but then I wanted to also get your view on it as I don't know what network-manager does and does not with notifications.
[10:08] <asac> i might be wrong, but afaik we dont display notifications for that ... but i kept it open for nm-applet to check
[10:08] <MacSlow> ok
[10:13] <joaopinto> mvo_, does it make sense to have a "Price: Free" field on a Get Free Software section :) ?
[10:15] <mvo_> joaopinto: check bug 419295 for a discussion about this
[10:15] <joaopinto> ah ops :P
[10:16] <mvo_> joaopinto: its a valid question, no problem. I think we need a faq or something to link to the discussion
[10:18] <joaopinto> mvo_, in the long term apturl will be integrated with aptdaemon right ?
[10:18] <ttx> cjwatson: we'll need at least one more cycle on the eucalyptus package, I'm fixing critical issues revealed in my UEC-install-from-daily testing
[10:19] <joaopinto> I would like to be able to install apps from a web page using multiple links without entering the password for each click, I am not sure it that will be available keeping a reasonable security
[10:19] <mvo_> joaopinto: with software-center and aptdaemon, yes
[10:19] <mvo_> joaopinto: should be done for lucid already
[10:20] <mvo_> joaopinto: I mean, it will be done for lucid
[10:20] <joaopinto> that would require some whitelist mechanism, to keep credentials for a specific page
[10:20] <ttx> cjwatson: the PUBLICIPS postinst fails if you set multiple addresses, see bug 438586
[10:22] <joaopinto> ok,  apturl will just queue the requests into software-center
[10:25] <Whoopie> asac: right now, /dev/rfkill has permission 644 so that gnome-bluetooth can enable/disable BT. This rule seems to allow users the access to /dev/rfkill.
[10:25] <mvo_> joaopinto: right, the current ui will just be integreated with software-center (and made look nicer)
[10:25] <joaopinto> ok :)
[10:27] <Whoopie> asac: http://www.spinics.net/lists/hotplug/msg02404.html
[10:28] <tkamppeter> pitti, should we perhaps return to the usblp-based CUPS backend and tell the manufacturers to stop using usblp, so that in the next release we can switch over to not use usblp.
[10:28] <pitti> tkamppeter: is that possible with 1.4?
[10:29] <pitti> tkamppeter: allegedly it is with --enable-libusb=no
[10:29] <pitti> tkamppeter: but I didn't test it
[10:29] <tkamppeter> pitti, problem is once that next release is LTS and second, if we stay with usblp manufacturers could stay using it.
[10:29] <pitti> tkamppeter: but that would again break system-config-printer, I guess?
[10:30] <pitti> tkamppeter: the advantage would be that people upgrading from jaunty and earlier would actually not end up with a broken printer (since libusb changes the device strings)
[10:30] <pitti> tkamppeter: or does s-c-p get along with both?
[10:30] <tkamppeter> pitti, principally, CUPS can be built also with a usblp-based "usb"backend.
[10:30] <pitti> tkamppeter: for LTS I wouldn't change the backend, we should keep with what we have in karmic
[10:31] <tkamppeter> s-c-p works with both versions, and CUPS intends that both give the same URLs.
[10:31] <pitti> tkamppeter: oh, so why didn't we do this from day one then?
[10:31] <pitti> (build with usblp support)
[10:31] <pitti> it was a real pain to do the switch to libusb, and it feels wrong, too
[10:32] <tkamppeter> pitti, the USB backend of CUPS can be built EITHER usblp-based OR libusb-based, not both (with auto-detection of usblp presence) in one backend.
[10:32] <pitti> tkamppeter: right, I understand
[10:32] <pitti> tkamppeter: I meant, why didn't we keep usblp in 1.4.0?
[10:34] <tkamppeter> One could make a workaround building both backend versions and renaming them (usb-usblp and usb-libusb), then add a wrapper script (usb) which checks presence of the usblp module with lsmod and then starts the appropriate real backend.
[10:34] <pitti> tkamppeter: what's the advantage of using the libusb one?
[10:34] <pitti> it seems so much easier and backwards compatible to use usblp only
[10:36] <tkamppeter> pitti, once HPLIP is libusb-based, it grabs the device and takes it away from the usb backend (usblp) of CUPS 1.3.x.
[10:36] <cjwatson> pitti: as ogra observes, casper on slow media is pretty nasty with no progress bar. Is there any way we could make the progress bar run-time-optional in usplash-theme-ubuntu somehow, rather than just commenting it out entirely?
[10:37] <pitti> tkamppeter: right (but that's a different backend?)
[10:37] <ogra> ++
[10:37] <ogra> the bouncing bar would suffice i think
[10:37] <pitti> cjwatson: with some small hacks, yes
[10:37] <ogra> so you see it didnt die at least
[10:37] <cjwatson> we could have a new command in usplash to turn it on
[10:37] <tkamppeter> pitti, this causes sonme confusion, especially the UDEV scripts must always check both the low-level signals and the usblp signals coming from the printer to reliably determine when a printer appears and when it disappears.
[10:38] <pitti> I guess it won't be precise any more with upstart scripts, but it'd at least show something
[10:38] <ogra> another option would be to drop quiet on slow live media
[10:38] <pitti> it requires changing the logo position and adding a new command line switch or usplash_write command
[10:38] <ogra> but i guess that would require additional translations we havent prepared
[10:38] <pitti> I'll ask the design team
[10:38] <pitti> oh, mat_t is here ^
[10:39] <pitti> mat_t: since you asked for dropping the progress bar, any opinion about bringing it back on the live system boot?
[10:39] <asac> Whoopie: yes. understood that. didtn know how that ACL_MANAGE works ... but now i know ;)
[10:39] <asac> thx
[10:39] <mat_t> pitti: in the meeting atm - will get back to you in a bit
[10:40] <pitti> it also requires new artwork, and moving the icon further up by default (not almost-centered)
[10:40] <Amaranth> pitti: you could just drop the progress bar down
[10:40] <cjwatson> pitti: I was actually wondering yesterday if it would be worth adding a way for upstart to prod usplash occasionally, say when events occur
[10:40] <pitti> Amaranth: then the text area gets pretty small on smaller resolutions (like 400 pixel y)
[10:40] <ogra> or let the icon pulsate or something
[10:41] <Amaranth> text area? I thought you just wanted a progress bar
[10:41] <pitti> the text area is still there, and required
[10:41] <cjwatson> pitti: if it were built-in, it would be fairly efficient
[10:41] <ogra> Amaranth, you can still drop quiet
[10:41] <pitti> (fsck, password entry, etc.)
[10:41] <tkamppeter> pitti, second, the usblp backend disables bi-di access for several important manufacturers, as usblp does not work with most printers of them
[10:41] <cjwatson> though at the moment you'd have to reopen the fifo each time, which isn't idedal
[10:41] <cjwatson> ideal
[10:41] <pitti> cjwatson: "more" built in than usplash_write?
[10:42] <cjwatson> something that doesn't involve spawning a process each time, yes
[10:42] <tkamppeter> pitti, third, the libusb-based backend supports also some more general access, for example to allow printing and non-printing functions on an MF device to be done in parallel.
[10:42] <Amaranth> so basically usplash_write built into upstart that just keeps the connection open?
[10:42] <cjwatson> I wouldn't want to hack it in without consulting with Keybuk, obviously, but it was something I was thinking about while upstartifying usplash
[10:43] <pitti> Amaranth: probably more like usplash listening to upstart events, I think
[10:43] <ogra> we're pre upstart, arent we ?
[10:44] <cjwatson> ogra: casper is, yes
[10:44] <ogra> right
[10:44] <Amaranth> pitti: ah yeah, then usplash can just listen for starting events and show some text
[10:44] <cjwatson> ogra: sorry, my question about upstart prodding usplash occasionally was not directly related to your problem
[10:44] <ogra> yes, i thought so
[10:45] <cjwatson> usplash listening to upstart events would be a little tricky, since it starts before upstart - doable but tricky
[10:45] <cjwatson> and the main loop would need to be rewritten, though it needs rewritten anyway!
[10:46] <ttx> cjwatson/slangasek: new eucalyptus (0ubuntu11) uploaded to fix critical issues uncovered in daily CD testing. Please review/approve/respin if appropriate
[10:46] <cjwatson> Amaranth: even if it were done in upstart, can't keep the connection open the way usplash is at the moment
[10:46] <cjwatson> Amaranth: the comms protocol is a fifo not a socket
[10:46] <Amaranth> ah
[10:48] <cjwatson> but pitti's probably right, better the other way up
[10:48] <pitti> cjwatson: I just feel that coding usplash knowledge into upstart seems a bit wrong
[10:48] <tkamppeter> pitti, what I would like to see as a CUPS USB backend would be one acting similar to the hp backend. Instead of simply giving up silently if a printer is grabbed by the usblp backend it should simply detach the printer and access it through libusb. This way one could leave the usblp kernel module loaded so that third-party backends can still use it.
[10:49] <pitti> tkamppeter: that would be nice indeed
[10:51] <tkamppeter> pitti, one would need to have a look into the "hp" backend to see how it works and patch the CUPS USB backend, and also test on printers which are not from HP.
[10:52] <ogra> asac, what do i have to do to make NM like my NIC on my babbage board ?
[10:53] <ogra> asac, i can get it to work with ifconfig eth0 up and dhclient, NM doesnt see it at all though
[10:56] <mat_t> pitti: how long does the live system boot take? Until we can display xsplash that is
[10:57] <pitti> ogra: ^
[10:57] <ogra> on armel its 40-50sec
[10:57] <pitti> mat_t: I guess a magnitude of 30 seconds to a minute?
[10:57] <ogra> depending on the SD card i use up to 1.5min
[10:59] <mat_t> pitti: 30 secs until xsplash?
[10:59] <pitti> I guess so
[10:59] <mat_t> hmm
[10:59] <pitti> on a CD it's a similar magnitude, though
[11:00] <pitti> stuff needs to be loaded from CD, squashfs unpacked, casper configures some things, etc.
[11:00] <mat_t> sabdfl was very clear on progress bars, since they're not really reliable... For most of the time you see it going from side to side anyway
[11:00] <mat_t> and then it accelerates, decelerates, etc
[11:00] <pitti> by and large they will, unless we do some heavy changes (see above)
[11:00] <pitti> mat_t: could we make the logo pulsate instead?
[11:00] <pitti> ogra: ^ WDYT?
[11:01] <pitti> we already have the fading code anyway
[11:01] <mat_t> pitti: we could (I mean, you probably could) :)
[11:01] <mat_t> pitti: we could have it going fade in-out slighly
[11:01] <ogra> ++ on any kind of indication that the system doesnt hand
[11:01] <ogra> *hang
[11:02] <mat_t> pitti: but only on live cd/installer, not in the real session
[11:02] <ogra> i dont care *what* we do but sitting in front of a white logo for a minute doesnt make me feel confident my system still boots
[11:02] <asac> ogra: what driver is it using?
[11:02] <ogra> asac, a forwardported version of the FEC driver from 2.6.28
[11:02] <pitti> mat_t: that can be arranged, yes
[11:02] <pitti> by calling usplash with --pulsate or so
[11:02] <ogra> asac, built into the kernel
[11:03] <mat_t> ogra: 1 minute boot is annoying in any scenario :)
[11:03] <pitti> I'm fairly sure that casper runs early enough to be able to modify the usplash startup
[11:03] <cjwatson> it can send a command to usplash, at any rate
[11:04] <ogra> mat_t, well, its a special case for me, but the CD isnt much faster either
[11:04] <pitti> cjwatson: right, or that
[11:04] <lifeless> or change stuff for the initramfs in its hooks?
[11:04] <cjwatson> mat_t: live CD boot is pretty much always slow no matter how you shake it
[11:04] <cjwatson> lifeless: bikeshed
[11:04] <lifeless> cjwatson: uhm sure, was just saying it should clearly be possible
[11:04] <cjwatson> it can be done, yes :)
[11:05] <mat_t> cjwatson: pitti: how about displaying some text info for live CD?
[11:05] <ogra> effectively we should indeed look into cleaning up casper and make it faster :)
[11:05] <cjwatson> mat_t: beware that we have a long-standing lack of translatability at this stage
[11:05] <pitti> mat_t: simple matter of sending an usplash command
[11:05] <pitti> mat_t: but no i18n
[11:05] <pitti> right
[11:05] <cjwatson> so while it's certainly possible you should be a bit careful about relying on it for everything
[11:05] <mat_t> right
[11:06] <cjwatson> ogra: fundamentally you have to get several hundred megabytes of data off slow media, there's a limit
[11:06] <cjwatson> well, obviously you don't have to get *all* of it off, but a fair bit
[11:06] <doko_> fta, asac: what is the name of the ubuntu-chromium-daily PPA? how do I turn on verbose logs?
[11:06] <ogra> cjwatson, well, there is a lot of old cruft in casper
[11:06] <mat_t> ok, let's go with pulsation then. I think it will provide a nice experience
[11:06] <pitti> actually, I was quite surprised about how fast the live system boots from an USB stick nowadays
[11:07] <cjwatson> sure, but cleaning it up isn't going to solve this problem really
[11:07] <ogra> cjwatson, only talking about all the hooks and scripts we have
[11:07] <pitti> heck, it's almost faster than booting my normal system from my slow HD..
[11:07] <seb128> pitti, you have a fast usb key or something? it takes some minutes there
[11:07] <ogra> there is stuff we carry along since breezy/dapper that totally isnt needed anymore
[11:07]  * ogra plans a lucid spec for that
[11:07] <pitti> ogra: we could perhaps get rid of reconfiguring X; locale configuration is also pretty slow, but still necessary; most of it should be fairly harmless, though, like setting gconf keys and doing small file changes?
[11:08] <asac> doko_: https://edge.launchpad.net/~chromium-daily/+archive/ppa
[11:08] <pitti> seb128: it's much faster than jaunty, anyway
[11:08] <cjwatson> most of the slow stuff is still needed, I think :-/
[11:08] <asac> doko_: https://wiki.ubuntu.com/Chromium/Debug
[11:08] <doko_> asac: thanks!
[11:09] <asac> http://code.google.com/p/chromium/wiki/LinuxDebugging
[11:09] <asac> http://code.google.com/p/chromium/wiki/LinuxDebugging#Logging
[11:09] <asac> doko_: ^^
[11:10] <asac> ogra: udevadm info --query=all --path=/devices/pci0000:00/0000:00:08.0/net/eth2
[11:10] <asac> something like that
[11:10] <asac> what do you get?
[11:10] <asac> (of course find your device)
[11:17] <joaopinto> mvo_, software-center crashed rebuilding the app info cache during today's update
[11:17] <ogra_> grrr
[11:18] <asac> ogra: did you get my last message?
[11:18] <ogra> nope
[11:18] <joaopinto> known issue ? should I report it ?
[11:18] <ogra> nothing since 12:08
[11:19] <mvo_> joaopinto: hm, bad. could you please submit a bugreport?
[11:19] <mvo_> joaopinto: I check it after lunch
[11:19] <joaopinto> ok, done, bug 438639
[11:20] <joaopinto> Title: software-center crashed with DatabaseError in _database_gen_postlist_iter()
[11:21] <pitti> ogra: would you mind filing a bug against usplash about the pulsating and assign it to me? (for post-beta tracking)
[11:24] <ogra> pitti, will do
[11:33] <ogra> asac, so what was your last message ?
[11:35] <asac> one sec
[11:39] <tkamppeter> pitti, I have found the following in io/hpmud/musb.c of the HPLIP source tree: http://pastebin.ubuntu.com/281172/
[11:39] <tkamppeter> pitti, so it seems that libusb has a function to detach a device from a kernel module.
[11:39] <pitti> tkamppeter: nice
[11:40] <pitti> tkamppeter: I guess it unbinds the printer device from the usblp driver
[11:41] <asac> 2:10 < asac> ogra: udevadm info --query=all --path=/devices/pci0000:00/0000:00:08.0/net/eth2
[11:41] <asac> 12:10 < asac> something like that
[11:41] <asac> 12:10 < asac> what do you get?
[11:41] <asac> 12:10 < asac> (of course find your device)
[11:41] <asac> ogra: ^^
[11:46] <ogra> asac, no pci bus on that HW
[11:46] <tkamppeter> pitti, I think so. And seeing these few lines it will be a rather small patch in the usb backend for CUPS. Once the usb backend patched this way we can stop blacklisting the kernel module.
[11:46] <ogra> asac, its a virtual device and i think we had solved that in jaunty and it regressed now
[11:47] <ogra> asac, http://paste.ubuntu.com/281190/
[11:47] <asac> hmm
[11:48] <pitti> tkamppeter: that would solve a lot of headaches indeed
[11:48] <ogra> iirc you had a special patch for virtual devs
[11:48] <tkamppeter> pitti, we only need to be careful to not detach the module for discovery, as discovery already happens if we do not use the usb backend (and want to use the backend from the manufacturer).
[11:48] <pitti> tkamppeter: although, I'm not actually sure it would
[11:48] <pitti> tkamppeter: since unbinding the printer from usblp would again break those ink level tools etc. which rely on usblp
[11:48] <asac> ogra: sudo killall NetworkManager ... sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt
[11:48] <asac> wait a bit and post the log
[11:49] <asac> (we dont have those patches anymore)
[11:49] <ogra> asac, hmm, NM dies
[11:50] <tkamppeter> pitti, for which printers are there usblp-based ink level tools?
  nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken
[11:51] <pitti> tkamppeter: I bounced you the mail from Markus Heinz (was on pkg-cups-devel@)
[11:51] <ogra> asac, that bug will likely hit us on dove as well btw, no exposed pci bus there either
[11:51] <tkamppeter> pitti, escputil can send the ink level and maintenance requests into a print queue and then it should work with whatever backend is used for the printer.
[11:52] <asac> ogra: you didnnt successfully killall NetworkManager if you get that message
[11:52] <ogra> yeah
[11:52] <ogra> it doesnt let me
[11:52] <ogra> fun
[11:52] <ogra> ogra@babbage2:~$ sudo service network-manager stop
[11:52] <ogra> network-manager stop/waiting
[11:52] <ogra> heh
[11:53] <ogra> looks better now
[11:53] <asac> ogra: killall usually works for me
[11:53] <ogra> asac, not if upstart owns it and has respawn set ;)
[11:53] <asac> hmm
[11:53] <asac> maybe because i am quick enough ;)
[11:53] <ogra> new world order
[11:53] <asac> well. i am doing it everywhere still ;)
[11:54] <ogra> http://paste.ubuntu.com/281196/
[11:55] <tkamppeter> pitti, we must check for all these tools whether they are really needed. HP printer maintenance can be done with HPLIP, so no third-party tool is needed, escputil can act through print queues, so that way one can perhaps also work without usblp.
[11:55] <asac> ogra: ok so its the not detected device driver
[11:56] <ogra> well, its compiled in
[11:56] <tkamppeter> I do not know which printers are really supported by libinklevel and which ones have no alternative to libinklevel.
[11:57] <ogra> asac, what is device_creator() looking for ?
[11:57] <tkamppeter> pitti, one should perhaps even make the CUPS usb module detach the printer before starting to access and reattach when done. This would be the ideal solution (the hp backend does not reattach).
[11:58] <asac> ogra: http://paste.ubuntu.com/281198/
[11:59] <ogra> hrm
[11:59] <asac> ogra: you could put a udev rule that adds that label?
[12:00] <asac> i think its safer to do that for your specific device id rather than allowing all that dont have drivers
[12:00] <ogra> evil, but would work i guess
[12:00] <ogra> asac, though it will bite us on all other armel systems too i guess
[12:01] <tkamppeter> pitti, problem is that there is no "attach" function in libusb, and if one detaches more than one device at a time onr could probably no guarantee that they get attached to the same /dev/usb/lp* as before.
[12:02] <pitti> tkamppeter: hm; seems that this would rip out more race conditions than it solves..
[12:07] <asac> ogra: the regression we would get when allowing net devices without drivers is that all virtual devices get managed (like vmnet etc.)
[12:08] <asac> ogra: so i think we need to explicitly whitelist vid/pid in rules somehow
[12:08] <asac> but i will check with dan
[12:08] <ogra> i'll ckeck with amitk_ if we can get a fake entry in there kernel side
[12:08] <tkamppeter> pitti, I discovered the following comment in the HPLIP source:
[12:09] <asac> ogra: can you install connman please and see if it labels your device properly?
[12:09] <asac> ogra: like what i have here: http://paste.ubuntu.com/281205/
[12:09] <tkamppeter> pitti: http://pastebin.ubuntu.com/281206/
[12:09] <asac> if that works we can check what connman does
[12:09] <ogra> will do, just rebooting to test a udev hack
[12:09] <asac> kk
[12:10]  * ogra just noticed he didnt have a 70-persistent-net.rules entry
[12:11] <tkamppeter> pitti, for that HP takes the vendor/product ID and gets the model name from their own database which comes with HPLIP. So the method does not work for non-HP printers.
[12:12] <tkamppeter> pitti, so to get make/model/device ID of a USB printer one must claim it on one of libusb or usblp.
[12:13] <mvo_> joaopinto: thanks
[12:13] <tkamppeter> pitti, to not disturb any other backend (which could use the other method) the universal backend must be ready to discover and access the device with both methods.
[12:17] <tkamppeter> pitti: It is possible to switch a device from usblp to libusb, but not from libusb to usblp, as the latter would not guarantee that the printer gets the same /dev/usb/lp* as it had in the beginning.
[12:18] <pitti> tkamppeter: so my gut feeling is that we should only use one; seems that trying to use both dynamically just results in more error situations?
[12:18] <seb128> ogra, what indicator session version do you use?
[12:18] <seb128> indicator-session
[12:19] <ogra> seb128, ogra@babbage2:~$ dpkg -l |grep indicator-session
[12:19] <ogra> ii  indicator-session                   0.1.5-0ubuntu1                             An indicator showing session management, sta
[12:19] <seb128> ogra, it's fixed in 0ubuntu2
[12:20] <ogra> ok, thanks
[12:20] <tkamppeter> pitti, an ideal CUPS USB backend goes through all printer devices identified as such by interface classes (07/01), then it should try to get the ID with libusb but without trying to detach the device. If the device is not accessible it should try to access via usblp. Same strategy when accessing to print.
[12:20] <ogra> ubuntu2 wasnt on the image i used for install apparently
[12:21] <seb128> it was uploaded this night
[12:22] <pitti> my X.org has used 50% CPU for more than ten minutes now; I already killed firefox, but that wasn't it; is there a way to find out what keeps it busy?
[12:23] <pitti> xrestop doesn't seem to tell me that
[12:24] <AnAnt> htop ?
[12:25] <pitti> AnAnt: the only real busy process is Xorg..
[12:25] <pitti> oh, found it
[12:25] <pitti> there was a runaway gdm-simple-greeter
[12:27] <ogra> asac, meh installing connman via ssh = bad idea :P
[12:28] <pitti> ArneGoetje: argh; something went wrong with the recent manual langpack upload
[12:29] <pitti> ArneGoetje: e. g. language-pack-gnome-de-base only has a tiny subset of what it should have
[12:29] <pitti> and desktop is now mostly in English
[12:31] <ogra> asac, connman works
[12:31] <pitti> ArneGoetje: did something go wrong with the tarball merging?
[12:32] <tkamppeter> pitti, such an ideal USB CUPS backend should not be too difficult to code, all the code is already in the two USB backends of CUPS, one only needs to merge this code in the correct way.
[12:36] <asac> ogra: yeah. i have to check that. but i assume that connman also would manage vmnet's
[12:36] <ogra> might be ... its the first time i use it :)
[12:36] <asac> ogra: connman is supposed to not touch your existing interfaces ;) ... at least according to marcel
[12:38] <ogra> asac, you mean /e/n/i ?
[12:38] <ogra> or which ones ?
[12:39] <ogra> note that i removed NM from upstart and rebooted ... so eth0 is free
[12:39] <ogra> (and i didnt touch /e/n/i)
[12:40] <asac> ogra: no . connman claims to not touch anything that is already upped (not related to eni)
[12:40] <ogra> ah, yes, the interface is definately down when i boot
[12:40] <ogra> oh, you mean because of the ssh ?
[12:40] <asac> ogra: my comment was about "ssh = bad idea"
[12:41] <ogra> i indeed shot down NM and that teared down the interface it seems
[12:41] <asac> yeah
[12:41] <asac> ogra: i didnt want you to test connman ... rathher just see if connman adds those udev labels
[12:42] <asac> you can have both running side by side because connman doesnt touch anything that is already up
[12:42] <ogra> ah
[12:42] <asac> (minus issues with wifi because connman fires up its own supplicant)
[12:42] <ogra> udev output didnt change
[12:44] <asac> ogra: so your device didnt get any CONNMAN_ labels (like what i posted?)
[12:45] <ogra> asac, nope, didnt change at all
[12:45] <ogra> http://paste.ubuntu.com/281226/
[12:45] <asac> ogra: ok. means that connman wouldnt manage it either
[12:45] <ogra> ogra@babbage2:~$ ps ax|grep conn
[12:45] <ogra>  1436 ?        Ss     0:00 /usr/sbin/connmand
[12:45] <ogra>  1450 ?        S      0:00 /sbin/dhclient -d -q -e BUSNAME=org.moblin.connman -pf /var/run/connman/dhclient.eth0.pid -lf /var/run/connman/dhclient.eth0.leases -cf /usr/lib/connman/scripts/dhclient.conf -sf /usr/lib/connman/scripts/dhclient-script eth0 -n
[12:45] <ogra> well, it does manage it
[12:46] <asac> /etc/udev/rules.d/92-connman.rules
[12:46] <ogra> /etc/udev/rules.d/92-connman.rules: No such file or directory
[12:47] <asac> http://paste.ubuntu.com/281227/
[12:47] <asac> ogra: ^^
[12:47] <asac> hmm. that should be /lib i guess
[12:47] <ogra> 0.30+git.1.5b69740e1+dfsg-0ubuntu1
[12:47] <asac> anyway. for me the /etc/ file exists ;)
[12:48] <ogra> created by postinst ?
[12:48] <ogra> its definately not in the package here
[12:48] <asac> most likely not
[12:48] <ogra> ogra@babbage2:~$ dpkg -L connman|grep rules
[12:48] <ogra> ogra@babbage2:~$
[12:49] <ogra> hmm, postinst only adds reboot notification
[12:49] <ogra> http://paste.ubuntu.com/281228/
[12:49] <asac> i would think you are struck by conffiles mechanism
[12:50] <ogra> no udev rule
[12:50] <ogra> ogra@babbage2:~$ cat /var/lib/dpkg/info/connman.conffiles
[12:50] <ogra> /etc/dbus-1/system.d/connman.conf
[12:50] <ogra> /etc/init.d/connman
[12:50] <asac> yeah strange
[12:50] <asac> anyway
[12:50] <asac> so connman isnt a better example ;) ... it just manages all eth devices
[12:51] <ogra> yeah, apparently
[12:51] <asac> maybe we should make NM manage all eth devices
[12:51] <ogra> well, i'll try to get amitk_ to add DRIVER to the actual driver
[12:51] <asac> and allow packages that come with vmnet etc. to blacklist their individual things in udev rules
[12:52] <ogra> well, if oyu match on the ethX naming ...
[12:52] <asac> you can have all kind of names
[12:52]  * ogra needs to test the next image, can i kill that install (wont be able to test stuff for 1.5h)
[12:53] <asac> ok
[13:32] <ArneGoetje> pitti: looking
[13:35] <pitti> ArneGoetje: don't worry, it's all good
[13:40] <ArneGoetje> pitti: puh...
[13:40] <ArneGoetje> pitti: what was the issue?
[13:41] <pitti> ArneGoetje: apparently they were unpacked in a bad order; but that's not something we changed recently
[13:41] <pitti> I installed some test packages manually, that might have screwed it up
[13:41] <ArneGoetje> pitti: right
[13:55]  * ogra carefully knocks on LP ...
[13:55] <ogra> is there still life in it ?
[13:56] <highvoltage> ogra: I can point you to some good LP support?
[13:57]  * beuno pokes the sysadmins about LP
[13:59] <highvoltage> ogra: I mean, I could point you to some real good LP assitance
[13:59] <ogra> seems to work atm
[13:59] <beuno> *very* slow
[14:00] <highvoltage> (*sigh* I wish someone would take the bait for once so that I could paste http://photos.jonathancarter.co.za/v/paris2006/800_PICT0125.jpg.html)
[14:02] <ogra> asac, amitk_ bug 438687 ... feel free to have a foodfight about on which end it needs fixing :)
[14:02] <asac> imo it needs to be fixed on the vmnet drivers
[14:03] <ogra> vmnet ?
[14:03] <ogra> do i need to add another package ? :P
[14:03] <asac> everything that provides "ethernet" devices that shouldnt be managed should ship their own udev rules somehow
[14:03] <asac> i dont know
[14:04] <amitk_> ogra: looks like YOU get to fix it in that case :-p
[14:05] <ogra> meh
[14:05] <ogra> amitk_, how would i add such a udev rule to the kernel package ?
[14:05] <amitk_> though I can look at the DRIVER property and fix it if it isnt too hard. (right after dealing with RTC)
[14:05] <asac> amitk_: do you know if those DRIVER properties always go away if you link stuff statically?
[14:06] <asac> would be great if everything had a driver;)
[14:06] <ogra> amitk_, do we know about a single board in the company where the battery is working for sure ?
[14:06] <ogra> amitk_, i'm not sure its not caused by my battery
[14:07] <amitk_> asac: not sure. But it sounds like the driver didn't provide it in the first place.
[14:07] <ogra> i see it on the dove board btw
[14:08] <ogra> though the driver sits under platform, not virtual
[14:09] <amitk_> ogra: see what?
[14:09] <amitk_> ogra: it does see like a problem with your board.
[14:10] <ogra> amitk_, DRIVER in udevadm output
[14:10] <ogra> ??
[14:10] <ogra> my bopard is running with your kernel .. the driver doesnt export the property
[14:11] <amitk_> My board survived being powered off for over 3 days (stopped working on it in Portland on Friday). And i see the correct date and time now
[14:11] <amitk_> ogra: I meant RTC
[14:11] <ogra> oh, you switched topics :)
[14:11] <ogra> yeah
[14:11] <amitk_> sorry
[14:12] <ogra> thats what i mean, but i dont know the value of the battery to replace it ... and i'm still irritated that i dont see any charge power
[14:12] <amitk_> ogra: I will measure the charge power. But in this case I suspect your battery is too dead to be charged.
[14:13] <ogra> there is nothing printed on it ... so i wouldnt even know the voltage/kind of battery i need to buy
[14:13] <amitk_> ogra: btw, even my ethernet came up automagically
[14:13] <ogra> with NM ?
[14:13] <amitk_> nope
[14:13] <ogra> it surely works with /etc/network/interfaces
[14:13] <ogra> its just the NM part thats missing
[14:13] <amitk_> I had the ethernet cable plugged in and it autonegotiated with dhcp (serial console)
[14:14] <amitk_> 'iface eth0 inet dhcp' in /etc/network/interfaces, that is
[14:14] <ogra> yeah, that definately works
[14:14] <ogra> connman works too
[14:14] <ogra> just NM doesnt because it looks for that property
[14:14] <amitk_> *sigh*
[14:15] <amitk_> ok, I'll look at it. But I am tempted to mark the RTC bug invalid
[14:15] <ogra> lets see if we can get confirmation it works from someone else first
[14:16] <amitk_> ogra: you did get confirmation! From me :)
[14:16] <ogra> we have enough boards, if yours works there sdhould be at least one other one
[14:25] <joaopinto> does it make sense to report such an obvious bug like flash failing to install from firefox plugin finder service ? Does anyone know a bug report about it ?
[14:40] <doko_> lool, seb128: Is this meant to be applied for armel as well?
[14:41] <doko_> gst-plugins-base0.10 (0.10.9-2) unstable; urgency=medium
[14:41] <doko_>   * Don't build the doc on arm and m68k.  It's painfully long, and -- at least
[14:41] <doko_>     on arm -- it segfaults; this is to lower the impact of #383147.
[14:41] <doko_>   * Update TODO list.
[14:41] <doko_>  -- Loic Minier<EMAIL_ADDRESS>Sat, 19 Aug 2006 23:25:01 +0200
[14:41] <doko_> currently ftbfs on armel, but unsure if that's releated
[14:41] <seb128> doko_, no idea, I didn't try on armel if the issue shows there
[14:42] <doko_> dh_installinfo -pgstreamer0.10-plugins-base-apps
[14:42] <doko_> dh_installinfo: dpkg-architecture failed
[14:42] <doko_> make: *** [binary-install/gstreamer0.10-plugins-base-apps] Error 1
[14:42] <doko_> I'll try a rebuild first
[14:42] <ogra> doko_, gst-...-good currently chokes on the dh-shlibs issue
[14:42] <ogra> because of graphviz and libshout
[14:43] <doko_> ogra: which I fixed on Sunday. wake up ;p
[14:43] <ogra> oh, i thought you only fixed it in debian yet :)
[14:43]  * ogra wasnt aware it was in ubuntu already
[14:48] <pitti> stgraber, highvoltage: is edubuntu purely a DVD nowadays? I can't find dailies on http://cdimage.ubuntu.com/edubuntu/
[14:50] <davmor2> pitti: as I understand it yes.
[14:50] <highvoltage> hmm, there was dailies recently
[14:50]  * highvoltage checks
[14:50] <highvoltage> pitti: http://cdimage.ubuntu.com/edubuntu/dvd/20090929/
[14:50] <highvoltage> pitti: yes, purely a DVD
[14:53] <pitti> highvoltage: ok, thanks
[14:54] <pitti> added to tracker
[14:55] <highvoltage> thank you pitti
[15:07] <lool> doko_: What was the buildd with the dpkg-architecture bug?
[15:08] <lool> doko_: I've seen that segfault on the new arm board
[15:10] <doko_> lool: sorry, I didn't write this down
[15:16] <tkamppeter> pitti, I have tried to merge the two USB CUPS backends together, but I have found another problem: The two backends coming from the same version of CUPS produce different URIs for the same printer.
[15:16] <pitti> tkamppeter: right, that's what I meant with "not break everyone's printers on upgrade"
[15:16] <pitti> there are several reports about that
[15:17] <lool> doko_: disabled doc building on armel too; thanks
[15:44] <tkamppeter> pitti, it looks like a bigger problem: The simplest solution to make everything just work is to keep the usblp version of the CUPS backend, but on the other side there are several advantages in favor of switching to the new technology: The three I mentioned earlier and the possibility to get the serial number from every printer, even if the device ID does not contain it.
[15:45] <hunger> LP is getting more confusing each time I try to use it:-(
[15:46]  * hunger wonders why he can no longer report bugs there.
[15:46] <tkamppeter> pitti, the new backend needs to made tolerant in accepting URIs when printing, especially accepting URIs where serial number and/or interface are missing.
[15:48] <cjwatson> hunger: while I don't like the current form, the wiki page it redirects you to does have instructions if you read down a bit
[15:48] <pitti> tkamppeter: serial number is if you have more than one printer of the same vendor/product?
[15:49] <hunger> cjwatson: Yeah, I tried the first couple of things and they do not work here:-(
[15:50] <hunger> cjwatson: They seem to be tailored to ubuntu, not kubuntu and particularly not some customized kubuntu like I always end up using:-(
[15:50] <cjwatson> hunger: read further down :-/
[15:50] <cjwatson> hunger: it does include a URL hack
[15:51] <hunger> Yes, I just saw that.
[15:52] <tkamppeter> pitti, yes, that is the reason why we want to have serial numbers in URIs for USB printers.
[15:53] <tkamppeter> piit, the number of use cases is small but not zero.
[15:55] <hunger> cjwatson: I keep up ending on the bug reporting "help" wiki page whatever I try to do. Sorry, I seem to be too stupid to report bugs.
[15:57] <Riddell> hunger: run   ubuntu-bug <packagename>
[15:57] <hunger> Ah, I missed the blindingly obvious ?no-redirect.
[15:57] <hunger> Riddell: krunner does not let me do that.
[15:58] <Riddell> hunger: what kubuntu version are you running?
[16:01] <LaserJock> was there any idea of when they were going to change it back so you can file with +filebug as normal?
[16:01] <LaserJock> it sounded like it was just going to be a temporary thing to gain some stats or something
[16:02] <jdstrand> ttx: I just saw your comment in bug #438747
[16:02] <ogra> pitti, you wanted bug 438762 assigned ?
[16:02] <pitti> ogra: please
[16:03] <jdstrand> ttx: are you guys using dhcp3-server?
[16:03] <ogra> done
[16:03] <ttx> jdstrand: meeting, can't talk right now
[16:04] <hunger> Riddell: karmic.
[16:04] <jdstrand> ttx: well, when you get back, feel free to respond. I ask because if you are, you are likely going to need to adjust the dhcpd3 apparmor profile to deal with /var/run/eucalyptus/net/euca-dhcp.conf
[16:05] <hunger> Riddell: But I do tend to move most of the ubuntu specific recommended stuff.
[16:05] <jdstrand> ttx: we can easily add that path to the package so it works out of the box
[16:18] <kees> doko_: what's needed for libelf 0.8.12?
[16:18] <kees> doko_: (I assume post-beta?)
[16:20] <doko_> kees: a FFe
[16:21] <kees> doko_: okay, cool;  -0ubuntu1, or do you think Debian will close their 548865 bug you just opened?
[16:22] <doko_> kees: I have a -0ubuntu1 which I can upload
[16:24] <kees> doko_: ok, cool.
[16:26] <doko_> gah, subscribed the wrong motu team
[16:26] <alkisg> gnome-power-cmd shutdown is no longer there in Karmic, how would a script poweroff the PC without having sudo rights? (talking about https://bugs.launchpad.net/ubuntu/+source/italc/+bug/367960)
[16:39] <smoser> slangasek, http://paste.ubuntu.com/281408/ has the amis for beta candidates
[16:40] <smoser> am i able to update iso tracker or does someone more worthy have to ?
[17:00] <beuno> pitti, pin
[17:00] <beuno> ping even
[17:01] <beuno> pitti, there's a, what i'd consider a critical issue with gdm that I'd like to discuss
[17:01] <beuno> we pre-select the user, so it's not clear what they should do
[17:02] <beuno> that's bad, but what's really bad, is that if you start typing your password (assuming it's selected), it shows what you're typing in clear text
[17:02] <beuno> I'm guessing it's trying to search or some default gnome behavior
[17:03] <cjwatson> isn't that username selection?
[17:03] <cjwatson> i.e. so that I can type 'cjwatson' rather than having to reach for the mouse
[17:04] <beuno> cjwatson, maybe, but since it shows me the text I'm typing, it feel insecure
[17:05] <beuno> if we didn't select the user by default, it would be less likely that users assume they should type, although I think we shouldn't show you the search text all together
[17:05] <beuno> they may be orthogonal issues, but piling them up is a bit concerning  :)
[17:05] <cjwatson> hmm, I haven't noticed a user being selected by default
[17:05] <beuno> not sure what the criteria is, maybe the first one on the list
[17:06] <cjwatson> it doesn't do that at all for me
[17:06] <beuno> you click on it, and it brings up the password field
[17:06] <beuno> I just did this on a fresh karmic install
[17:06] <cjwatson> it shows the username, but it is not selected
[17:06] <beuno> do you have more than 1 user?
[17:06] <cjwatson> perhaps the UI is confusing if you only have one user; there are several here
[17:06] <beuno> right, I think that's the case
[17:06] <cjwatson> anyway, I would like to request that the fix for this not involve breaking username selection via the keyboard
[17:07] <beuno> sure, I don't see why we would have to break keyboard navigation at all
[17:08] <cjwatson> the reason, I think, why keyboard username selection needs to show the text right now is that it lets you select by username not by full name
[17:08] <cjwatson> i.e. I don't have to type in a prefix of "Colin Watson"
[17:08] <cjwatson> and so it'd be a bit confusing to jump around in the list depending on username prefix without showing you the text
[17:09] <beuno> I agree, but I think it's safe to guess the people using the keyboard and with more than one user is a pretty small subset of people
[17:09] <cjwatson> perhaps if it were more explicit that you *can* type in a username, rather than it being a hidden feature ... but I thought that was removed deliberately
[17:09] <beuno> maybe it's not one or the other, but I'd rather we drop the text from the screen if we have to pick one
[17:09] <cjwatson> I don't think either of us have any evidence on which to base a conversation about that assertion
[17:10] <bgamari> It seems that there is something quite wrong with the firefox-3.5-dbg package
[17:10] <cjwatson> "more than one user" is common for family computers, so that at least is not in itself a corner case
[17:10] <bgamari> /usr/lib/debug/usr/lib/firefoxd-3.5.3/firefox has no symbols in it according to nm
[17:10] <beuno> cjwatson, right, but more than one user *and* keyboard selection?
[17:10] <cjwatson> but beyond that, we have no data
[17:10] <cjwatson> (as far as I know)
[17:10] <beuno> either way, lets discuss that *if* it's one or the other
[17:10] <cjwatson> beuno: *shrug* all I know is I use it ;-)
[17:10] <beuno> is pitti the right person to talk to about this?
[17:11] <beuno> cjwatson, so we'll make sure you can still use it!
[17:11] <cjwatson> I am happy to be dismissed as a corner case if there is actually evidence that I am
[17:11] <pitti> beuno: pong
[17:11] <beuno> cjwatson, you should probably still be able to find-by-typing, but maybe just not display the text on the screen
[17:11] <beuno> pitti, hi!
[17:12]  * pitti reads backscroll
[17:12] <cjwatson> beuno: do you not think that would look pretty bizarre?
[17:12] <beuno> cjwatson, yes I do
[17:13] <pitti> beuno: what's the problem, gdm having an username input box? I'm afraid I don't quite understand what the problem is
[17:13] <beuno> pitti, so, when you only have one user
[17:13] <beuno> it's selected by default
[17:13] <pitti> right
[17:13] <beuno> that's confusing in itself, because it's not clear that you have to click a selected item
[17:13] <beuno> on top of that, if I assume that since it's selected I should just type my password
[17:14] <pitti> well, you can also just type your user name, as in the past 50 years of unix history
[17:14] <beuno> as I type, a search box comes up and shows me what i'm typing in clear text
[17:14] <pitti> right, I read that
[17:14] <pitti> the user selector right now is just a way to shortcut the user name entry
[17:14] <beuno> I understand that
[17:14] <pitti> I'm indeed not really happy about how it looks nowadays
[17:14] <pitti> but the face browser didn't land in time
[17:14] <beuno> ok, good, that's a start
[17:15] <beuno> can we not select a user by default?
[17:15] <beuno> that would improve the situation already
[17:15] <pitti> beuno: we could theoretically
[17:15] <pitti> but then you'd have to look harder
[17:15] <pitti> whether it's a password or username prompt
[17:15] <pitti> so far you'll always have an user name prompt
[17:15] <pitti> so it's confusing either way, I think
[17:16] <cjwatson> speaking of keyboard navigation, I wish we hadn't made it completely non-obvious how to restart the computer using the keyboard
[17:16] <beuno> pitti, can we show the password prompt, with focus, if there's only 1 user?
[17:16] <cjwatson> apparently nobody designing this stuff is worried about RSI :)
[17:16] <beuno> that would be the best solution, I think
[17:19] <pitti> beuno: theoretically yes; it's similar to what should happen if you select another user in the user switcher applet
[17:19] <pitti> it just doesn't work, you always get the user picker
[17:20] <beuno> pitti, so what's the best way to make that happen?  bug report?
[17:20] <beuno> I have the whole design team looking at me waiting for an answer  :)
[17:20] <pitti> sure, bug reports are always good
[17:21] <pitti> however, we have tons of release-critical bugs still to fix, so please don't hold your breath
[17:21] <beuno> and the karma is nice
[17:21] <pitti> there's a relatively low chance of getting this fixed in karmic
[17:21] <beuno> hm
[17:22] <beuno> do we auto-login by default?
[17:22] <Ng> beuno: can I humbly suggest epic care in this regard, to avoid people typing their username into the password field, getting bounced back to a username field and typign their password in the clear ;)
[17:22] <Ng> I've seen people get confused by what state the login screen is in and do that sort of thing :/
[17:23] <beuno> yes, I've done it myself
[17:23] <beuno> it's a good point
[17:23] <pitti> beuno: you have to select that in the installer (auto login/manual)
[17:23] <cjwatson> we do not auto-login by default, although there is an option in the installer to do so
[17:23] <beuno> pitti, can we "not select by default" for karmic?
[17:23] <pitti> beuno: that's what I actually meant (what Ng said)
[17:23] <pitti> beuno: in the past 50 unix years, people have become conditioned to type username/passwordr
[17:23] <beuno> yeah, Ng has a good point
[17:23] <pitti> now it's inconsistent
[17:24] <pitti> I mean, it will be, if we do what you propose
[17:24] <beuno> agreed, I will take this back to the design team to have a better plan for Lucid
[17:24] <beuno> but, can we not select it by default?
[17:24] <beuno> you have to click on the username anyway
[17:25] <beuno> and clicking on something that is already selected is not an expected pattern
[17:25] <pitti> no, you can just press enter
[17:25] <pitti> it is selected by default already; doesn't that work for you?
[17:25] <beuno> it does
[17:25] <pitti> I always just press enter, then type my password
[17:25] <beuno> I *don't* want it selected
[17:25] <pitti> oh
[17:25] <beuno> so it's clear I have to click on it
[17:25] <beuno> if it's selected, you don't feel compelled to click on it
[17:26] <pitti> well, right now you don't have to click on it..
[17:26] <beuno> you do if you're the average person who uses a computer
[17:26] <beuno> who uses the mouse as much as possible
[17:26] <beuno> we present you with a graphical screen with options, people will interact with it with their mice
[17:27] <beuno> if we gave them a terminal, sure
[17:27] <beuno> I understand the history behind this, and we don't want to annoy people who ahve be using unix for 40 years
[17:27] <beuno> can we come up with something that works for everybody?
[17:27] <beuno> ...and that can be implemented for karmic
[17:28] <pitti> well, the current state does work for everybody, it's just that you want it to work differently :)
[17:28] <pitti> right now, it's either click/type password, or enter/type password
[17:28] <pitti> or type user/type password
[17:29] <pitti> so from what I understand, you wnat to eliminate the second option
[17:29] <sistpoty|work> if you can just press enter, it would make sense to also prefill the username box with the selected username?
[17:29] <beuno> I don't want to eliminate any behavior
[17:29] <pitti> sistpoty|work: could do, if the text is selected
[17:29] <pitti> sistpoty|work: we don't want to break the 3rd option
[17:29] <cjwatson> sistpoty|work: it's not a box with an allocated location on screen - it's a search box that only comes up while you're typing
[17:29] <sistpoty|work> pitti: yep
[17:30] <beuno> I want us to make it clear what the user needs to do on the first screen they will get when they instlal ubuntu
[17:30] <cjwatson> sistpoty|work: like a GTK list search
[17:30] <beuno> the current way it works, exposes their password
[17:30] <pitti> beuno: oh, so you want to add a real input line for the user?
[17:30] <beuno> that's not a great experience
[17:30] <sistpoty|work> cjwatson: ah, I see (/me is a xdm user *g*)
[17:30] <beuno> pitti, I'm trying really hard not to prescribe a solution here
[17:30] <pitti> beuno: well, I'm still in the "understand the problem" phase TBH
[17:30] <beuno> just to figure out what would make you everyone happy
[17:31] <beuno> pitti, the critical issue for me is that the way we're presenting it right now, can lead up to people exposing their password
[17:31] <beuno> if someone sees it, it's a problem for them, if it's just them, they will feel insecure
[17:31] <beuno> we look bad either way
[17:32] <beuno> we can tackle this in different ways
[17:32] <djsiegel> beuno: the issue is that we show list of users, and a username text entry?
[17:32] <beuno> one of them is making it so the screen doesn't imply that you're user is selected already
[17:32] <pitti> djsiegel: we don't have an username text entry
[17:32] <beuno> djsiegel, no, lets stick with the only-one-user case for simplicity
[17:32] <beuno> it's that we show the users' name
[17:32] <beuno> selected
[17:32] <beuno> in a list
[17:33]  * pitti -> desktop meeting; following with half an eye
[17:33] <beuno> and what the user needs to do, is click on an already selected item
[17:33] <beuno> which is not obvious
[17:33] <beuno> I've done this test with 4 different people now
[17:33] <TomaszD> the new gdm UI is not designed very well. Why, if the first user is preselected, doesn't the Password dialog come up anyway without user interaction?
[17:33] <TomaszD> this is really, really weird to me.
[17:33] <beuno> present them the gdm, and ask them what they need to do now
[17:33] <djsiegel> beuno: so, it looks selected but is not?
[17:33] <beuno> *none* of them could guess without playing
[17:33] <beuno> djsiegel, it is selected, but only so you can hit enter to get a password field
[17:34] <beuno> so yes, it's selected but it's not, to the user
[17:34] <beuno> djsiegel, so, if the user assumes it's selected, and we need their password
[17:34] <djsiegel> beuno: ah, and we just select the first user in the list?
[17:34] <beuno> if they type
[17:34] <pitti> tedg: when you select a user in i-s, gdm comes up with the user picker, instead of the user being preselected; is that a gdm or i-s bug?
[17:34] <pitti> (it's related to this discussion here)
[17:34] <beuno> their password appears in clear text on the screen, because we assume he is searching for a username
[17:34] <TomaszD> beuno, wouldn't it be better to have the Password field displayed for the preselected user, rather than not select any user by default?
[17:34] <beuno> djsiegel, yes
[17:35] <beuno> TomaszD, yes, I think that's what I'd prefer at this point, although Ng had a good point about people typing their username into it
[17:35] <djsiegel> so, what we really need is the user to complete the task of picking a user, then complete the task of entering a password, and make sure they strictly observe that order
[17:35] <tedg> pitti: I think it's a feature that gdm doesn't have.
[17:35] <djsiegel> or else they will expose the password
[17:35] <TomaszD> beuno, but it makes more sense than the current design anyway
[17:35] <beuno> yes
[17:35] <pitti> tedg: ok, too bad; the old one had it
[17:35] <TomaszD> the current design makes no sense at all.
[17:35] <siganderson> do anybody know why there is nomore serivces-admin (the service manager) in karmic koala?
[17:36] <djsiegel> beuno: what can we do to make it clear that they must pick a user, and not type a password?
[17:36] <pitti> siganderson: we killed it because it was already utterly broken before, and now with upstart it doesn't work at all
[17:36] <beuno> djsiegel, half way there is not selecting the user, and maybe telling them to?   I can't remember if we do, althought I feel that if we're having to explain, "we're doing it wrong"
[17:36] <siganderson> pitti, will it be restored in the beta version?
[17:37] <TomaszD> what I find horrifying is how the dialog window elements move around and pop up from nowhere, there should be a law against it. It confuses the hell out of new users. But that's a different story.
[17:37] <djsiegel> beuno: they will not read any messages
[17:37] <pitti> siganderson: no plan for this; it needs some heavy upstream work
[17:37] <djsiegel> beuno: so we could hide or disable the password field
[17:37] <djsiegel> I prefer hide, because disabled looks strange
[17:37] <beuno> djsiegel, it is hidden today
[17:37] <siganderson> pitti, ok thank you
[17:37] <beuno> and it shows up when you click on the already-selected user
[17:37] <djsiegel> beuno: and people are typing their password without seeing a field?
[17:38] <djsiegel> beuno: so what is the problem exactly?
[17:38] <TomaszD> yeah, I don't understand the argument here really
[17:38] <beuno> djsiegel, it's 2 problems
[17:38] <beuno> 1. It's not obvious what the user needs to do, our visual cues tell them that their username is already selected
[17:39] <TomaszD> true
[17:39] <beuno> 2. If they decide to assume that that step is done, and they need to type their password, it shows up in clear text
[17:39] <djsiegel> 1. so we need to make it obvious that nothing is selected yet, right
[17:39] <djsiegel> ok
[17:39] <TomaszD> but I can't believe that people click on an already selected username, see the password field... and type in your username
[17:39] <beuno> I'm not saying that 2. is something that will happen a lot, but when it does, it will be very bad
[17:39] <djsiegel> make it obvious that no user is selected yet
[17:39] <beuno> 1. makes 2. worst, but they are orthogonal in a way
[17:39] <beuno> yes
[17:40] <djsiegel> it takes an advanced user to hit enter
[17:40] <beuno> correct
[17:40] <djsiegel> they may try hitting enter in the absence of a visual cue
[17:40] <beuno> that was my argument to pitti and cjwatson
[17:40] <cjwatson> TomaszD: it would be more likely if we displayed the password prompt before giving them the opportunity to select username
[17:40] <djsiegel> so they don't lose that featyre
[17:40] <djsiegel> feature*
[17:40] <cjwatson> djsiegel: err. I think you need some more levels in between novice and advanced, there!
[17:40] <djsiegel> cjwatson: I have more levels, I am just making a rough decision here
[17:40] <djsiegel> :)
[17:40] <djsiegel> rules of thumb
[17:41] <beuno> I'm certain we can find a solution that makes everyone happy
[17:41] <TomaszD> I would personally go for either 1) no-one selected, password field visible and disabled, or 2) pre-selected user, password field visible and enabled
[17:41] <beuno> but we have to figure it out together:  what can be done by karmic, and what addresses both use cases
[17:41] <TomaszD> it does not make sense to hide the password field, the window needlessly jumps around
[17:41] <pitti> a complete redesign is too late for karmic, but in the lucid range
[17:42] <pitti> small tweaks can still be done, but we are in UI and beta freeze, mind you
[17:42] <beuno> pitti, ok, so let's not do a complete redesign, but we need to do something for karmic
[17:42] <TomaszD> so make the password field visible and focused by default
[17:42] <pitti> also, we don't have time for that in the desktop team any more, I'm afraid (external contributions welcome, of course)
[17:42] <beuno> yes, I am aware of it
[17:42] <TomaszD> not that big of a change, a lot of help though
[17:42] <djsiegel> beuno: so, what is the objection to (1) a list of users with uniform visual treatment (none looks selected)
[17:42] <pitti> beuno: well, we could also just do it properly in lucid..
[17:42] <djsiegel> 2. show the password field once user has made a selection
[17:42] <beuno> djsiegel, I have no objections, pitti does
[17:43] <beuno> that enter will not work then
[17:43] <djsiegel> how is enter used?
[17:43] <djsiegel> when there is a single user?
[17:43] <beuno> boot, enter, password
[17:43] <djsiegel> make enter still work
[17:43] <pitti> djsiegel: well, it's not a hard objection, but right now you can just press enter, type password, go
[17:43] <djsiegel> just don't select a user in the list
[17:43] <pitti> that would magically select the first one?
[17:43] <beuno> yes, that would work, if it's possible to do
[17:43] <djsiegel> pitti, sure
[17:44] <djsiegel> pitti: or enter could be made only meaningful when one user is available
[17:44] <djsiegel> that might be smarter
[17:44] <djsiegel> making it always do the first seems arbitrary
[17:45] <djsiegel> but on a single user system
[17:45] <djsiegel> make it choose the only choice available
[17:45] <ScreamerX> hello
[17:45] <TomaszD> wait a second... if there is only one user available, why would you not display the password field by default?
[17:45] <ScreamerX> is there any key combination that puts my fullscreen opengl application into background?
[17:46] <TomaszD> it seems absolutely unnecessary to either click or hit enter when there is only one choice to be made
[17:46] <djsiegel> TomaszD: yes, good question
[17:46] <beuno> TomaszD, right now, because we need to do something for karmic
[17:46] <beuno> so lets do what we can, but lets do something
[17:46] <beuno> and, for lucid, we'll kick ass
[17:46] <djsiegel> TomaszD: you're right, we should show something different for single-user systems, but that might require some heavy lifting
[17:46] <beuno> user test it, etc
[17:47] <TomaszD> djsiegel, not much different, just the password field visible, focused.
[17:47] <djsiegel> we got a paper cut the other day "typing my password is annoying, I should never have to do it"
[17:47] <beuno> TomaszD, if we focus it, we may run into what Ng said, which is valid for old-time linux users
[17:48] <beuno> so we need to back up the change with data
[17:48] <beuno> that change at least
[17:48] <djsiegel> beuno: I would not worry about 50-year UNIX veterans being confounded by our GUI...
[17:48] <TomaszD> beuno, old-time linux users tend to read what's on the screen
[17:48] <djsiegel> not a significant use case to design for
[17:48] <TomaszD> I would not really worry about them
[17:48] <cjwatson> 50-year Unix veterans - how about the last five years of Ubuntu users
[17:48] <ScreamerX> i am slackware user
[17:48] <beuno> TomaszD, they read the least
[17:48] <cjwatson> that is perhaps a slightly better and less hyperbolic example
[17:48] <beuno> cjwatson, that's kind of what I meant
[17:49] <beuno> all our current userbase
[17:49] <TomaszD> I've used Ubuntu for the last 5 years and when I see a new login dialog I read what's on there
[17:49] <cjwatson> exactly
[17:49] <djsiegel> cjwatson: don't accuse me of being hyperbolic, i was just quoting what someone said earlier!
[17:49] <djsiegel> :)
[17:49] <TomaszD> especially if's just my username and "Password:" field
[17:49] <cjwatson> djsiegel: I know, but it's still a better example
[17:49] <beuno> ok, back to the issue
[17:49] <djsiegel> sure
[17:49] <djsiegel> what are we talking about anyway?
[17:49] <djsiegel> people who will type their username into a password field?
[17:49] <beuno> can we not select it, and enter auto-selects the first user?
[17:49] <beuno> no change in behavior, and we address the bulk of this issue
[17:49] <mvo_> Riddell: I see a update-manager commit from 28 sep - I fixed the problem there on 25th, was your tree outdated? or did I miss anything with the fix?
[17:51] <mvo_> Riddell: nevermind, found it
[17:51] <TomaszD> anyway, at least now I know what's been freaking me out about the new gdm *and* I know that the enter key works, don't have to reach for the mouse
[17:51] <TomaszD> :)
[17:51] <Hatl> is there a way to minimize a fullscreen opengl application?
[17:55] <beuno> pitti, let me know when you're back so we can make sure this is on someone's plate for karmic
[17:55] <Amaranth> Hatl: ctrl-alt-d (if you're using compiz)
[17:56] <pitti> beuno| can we not select it, and enter auto-selects the first user
[17:56] <pitti> beuno: if you think that helps, it sounds doable for karmic
[17:56] <Hatl> Amaranth: im using kde. but the kde-shortcuts don't work
[17:56] <Amaranth> Hatl: Well, this is more of a question for #kubuntu (and I have no idea)
[17:56] <pitti> beuno: it just doesn't appear to me as making the dialog less confusing (since it's not how gtk lists usually work)
[17:57] <Hatl> Amaranth: ok :)
[17:58] <djsiegel> pitti: I thought our goal was not to make the dialog less confusing, but to satisfy the use case of pressing ENTER on single user systems, and to avoid giving users the impression that a default user is selected in the list by not highlighting any without explicit user action.
[17:58] <pitti> djsiegel: ok; so that's the karmic goal, and for lucid we'll turn it upside down then?
[17:58] <djsiegel> I guess that does make it less confusing (not highlighting so users don't get the impression that it's time to type the secret code)
[17:59] <djsiegel> pitti: what are we turning upside down? I am not sure.
[17:59] <pitti> djsiegel: perhaps in lucid we'll get the real facebrowser, then we can get rid of this user chooser entirely
[17:59] <pitti> djsiegel: like, redesigning the entire thing
[17:59] <beuno> pitti, for lucid, we will do research and come back with data so we can find a screen that makes everyone proud
[17:59] <beuno> pitti, so I'll capture this in a bug and assign to...?   :) :) :)
[18:00] <pitti> beuno: good question; as I said, we already have more critical bugs in the desktop team than we can possibly handle
[18:00] <pitti> beuno: not making the first user selected is easy; making enter magically work requires more intrusive code, since it's not how gtk lists are working
[18:00] <beuno> pitti, so it's a prioritization issue. Who prioritizes?
[18:01] <pitti> beuno: for desktop, basically rickspencer3 and me
[18:01] <seb128> I guess the change you want is not trivial
[18:01] <seb128> if the first item is not selected it will not react to key events
[18:01] <rickspencer3> what exactly is going on?
[18:01] <seb128> needs some tweaking
[18:01] <Amaranth> hmm, you could look for keypress events on the GtkWindow?
[18:01] <rickspencer3> I thought we were past beta freeze
[18:01] <rickspencer3> we should be removing features that don't work well, not adding to them
[18:02] <pitti> let's remove gdm :)
[18:02] <djsiegel> pitti: here here
[18:02] <rickspencer3> hehe
[18:02] <seb128> rickspencer3, seems they want the list to have an empty selection but act as if there was a selection
[18:02] <beuno> rickspencer3, hi  :)
[18:02] <pitti> djsiegel: (this thing gave us nothing but trouble anyway...)
[18:02] <seb128> which is a non standard widget behaviour...
[18:02] <djsiegel> seb128: some element has input focus -- the window? It just has to pick the first user in the model and continue.
[18:02] <cjwatson> just as a point of terminology, beta freeze is the period that runs from the week before the beta release until the beta release
[18:02] <rickspencer3> uh, can users log in as it is? I mean functionally?
[18:02] <cjwatson> after the beta release, we go back to feature freeze status
[18:02] <cjwatson> (and UI freeze etc.)
[18:02] <pitti> rickspencer3: yes
[18:02] <djsiegel> no need to hack the list widget
[18:02] <Amaranth> rickspencer3: yes but they have to know they have to click on the thing that is already selected
[18:03] <rickspencer3> if we are going to replace GDM with our own UI in Lucid, mucking with it after beta freeze is illogical
[18:03] <pitti> if we are fine with droppping the "just press enter to select first user" behaviour, it's a simple change
[18:03] <rickspencer3> that;s unfortunate, but it doesn't crash
[18:03] <rickspencer3> we need to *prioritize* now
[18:03] <beuno> rickspencer3, can we have a quick call so i can explain this?
[18:03] <rickspencer3> beuno, I don't think I have time for that
[18:03] <rickspencer3> we have four weeks until we *ship*
[18:03] <beuno> rickspencer3, I understand
[18:03] <pitti> (more like three)
[18:03] <rickspencer3> we need to be crystal clear on priorities
[18:04] <Amaranth> changing it to not select any user is a simple enough change
[18:04] <beuno> rickspencer3, this is a big problem, with a potentially very simple solution
[18:04] <rickspencer3> I can't see something that is annoying like this raising to the level of a change that we would introduce
[18:04] <Amaranth> slows down power users a bit but makes the interaction clearer
[18:04] <beuno> rickspencer3, this is *not* an annoying issue
[18:04] <rickspencer3> beuno, how many things are like that on the desktop?
[18:04] <pitti> Amaranth: right, what I said
[18:04] <beuno> rickspencer3, this is a situation where we end up showing the users password in creal text
[18:05] <beuno> rickspencer3, so, I'll start explaining it *again*
[18:05] <Amaranth> d'oh, the user list has searching
[18:05] <seb128> beuno, well your suggested change will not fix that password issue
[18:05] <pitti> I'm fine with just dropping the first selection
[18:05] <rickspencer3> is this caused by the the default answer is "no"
[18:05] <beuno> seb128, it will make it less likely. Ideally, we would not show clear text at all
[18:05] <rickspencer3> at some point we have to stop making changes and start fixing bugs
[18:05] <rickspencer3> that time is defined to be weeks ago
[18:06] <pitti> beuno: if you have many users, you certainly want typeahead search; using the mouse with more than 5 users will kill you
[18:06] <beuno> pitti, I agree, which is why I'm comprising here
[18:06] <seb128> pitti++
[18:06] <beuno> comprimising even
[18:06] <beuno> I don't want to break anyone's use case, and I want this fixed for karmic
[18:06] <pitti> beuno: so, if we just drop the initial selection?
[18:06] <djsiegel> pitti beuno seb128, dropping the selection seems important, but ENTER to pick single user is not
[18:06] <Amaranth> if you drop the selection you lose the typeahead
[18:06] <seb128> having to use the mouse is annoying
[18:06] <djsiegel> as seb128 and rick point out
[18:06] <rickspencer3> this is for machines with how many users?
[18:07] <pitti> Amaranth: oh?
[18:07] <djsiegel> Ah, you lose typeahead when you drop selection?
[18:07] <djsiegel> \
[18:07] <pitti> rickspencer3: 1
[18:07] <Amaranth> pitti: the list has to be focused for that to work
[18:07] <pitti> Amaranth: you can still focus the list, but not select the first entry?
[18:07] <djsiegel> You can focus a list without selection
[18:07] <rickspencer3> this only impacts people who have one user on their machine, or one or more?
[18:07] <djsiegel> At least from code
[18:07] <djsiegel> maybe not with a mouse
[18:07] <pitti> rickspencer3: by and large one
[18:07] <seb128> I fail to see that as an important issue to be honest
[18:08] <cjwatson> unless this is just me, if you have more than one user then there's no default selection
[18:08] <rickspencer3> I can't believe we are even discussing mucking with gdm at this point
[18:08] <seb128> other distro are shipping with that screen for several cycles and nobody really complained during karmic
[18:08] <cjwatson> yay, I think I just got wubi working
[18:08] <djsiegel> cjwatson: it's not just you
[18:08] <pitti> cjwatson: you rock!
[18:08] <cjwatson> it forgot my real name, but aside from that ...
[18:09] <beuno> rickspencer3, mt said he reported this ages ago, and it did not bubble up. It's most likely a failure in our team to communicate, I'm sorry about that
[18:09] <asac> pitti: dont forget nm ride-along :)
[18:09] <pitti> asac: yep
[18:09] <asac> (for wubi)
[18:12] <beuno> rickspencer3, so, not going to happen?
[18:12] <beuno> I need to report back
[18:12] <rickspencer3> beuno, right
[18:13] <beuno> rickspencer3, even with a trivial fix?
[18:13] <asac> beuno: we first have to see that trivial fix. from the discussion above it felt there is no trivial fix
[18:13] <seb128> beuno, if somebody add a patch to the bug we will review it
[18:13] <seb128> beuno, but we are not going to work on it
[18:14] <beuno> ok, I'll report that back
[18:14] <seb128> I still fail to see that as an important issue, it seems to confuse no user so far
[18:14] <seb128> based on feedback we got during the cycle
[18:19] <beuno> seb128, I've said this 3 times
[18:19] <beuno> I've done this with 4 users already
[18:19] <beuno> sat them down on the laptop
[18:19] <beuno> with GDM
[18:19] <beuno> and asked them what they had to do now
[18:19] <beuno> NOBODY KNEW
[18:20] <beuno> this *is* a problem
[18:20] <beuno> wether it's critical or not to you, it's different
[18:20] <beuno> we are olishing ubuntu making it nice to use
[18:20] <beuno> this is a critical part of that
[18:20] <beuno> the first screen you run into
[18:20] <beuno> the fact that everyone is being snarky about it does not help *anyone*
[18:21] <seb128> nobody is being snarky there
[18:21] <seb128> but it's amazing that nobody raised that before beta if that's such an issue and so obvious
[18:21] <beuno> it's a critical bug in Ubuntu
[18:21] <beuno> seb128, I have raised this multiple times, it just hasn't bubbled up
[18:21] <beuno> which is why I'm here
[18:21] <beuno> I will file the bug, as critical, as it's a bug, not a feature
[18:22] <seb128> there is a bug open
[18:22] <beuno> #?
[18:22] <seb128> couldn't you look for the number?
[18:22] <seb128> it would take you as long to find it as it will take me
[18:22]  * seb128 searches the number
[18:22] <beuno> bug #410337
[18:22] <beuno> look at that
[18:23] <beuno> reported by me, almost 2 months ago
[18:23] <seb128> yes
[18:23] <seb128> I know about it, I triaged it and set it upstream
[18:24] <beuno> ok, so this has been on the plate for a while
[18:24] <beuno> I stated the user testing in the bug
[18:24] <seb128> I've added a comment saying that enter works as suggested for me
[18:24] <seb128> but nobody followed up or commented
[18:24] <beuno> using the keyboard is *not* the common case
[18:25] <seb128> right but the description didn't suggest any change
[18:25] <beuno> there's a wiki, and a suggestion, and a mock up
[18:25] <beuno> rickspencer3, ^
[18:25] <beuno> this no longer is "this just popped up"
[18:25] <beuno> yes it did
[18:25] <beuno> and comment #1 does it precisely
[18:25] <Amaranth> So... if I make this patch will it be considered? Should be simple to do the not selected part at least
[18:25] <mdz> kirkland, I seem to have missed ttx. can you update me on eucalyptus wrt beta?
[18:25] <beuno> and it's *exactly* what we're asking for now
[18:25] <seb128> "The user name displayed at the top of the list should not be selected by default. Pressing Enter should result in selecting the user from the top of the list, unless any other menu item or button has been manually highlighted."
[18:25] <seb128> that?
[18:26] <Amaranth> Making enter still work is more complicated but not much so
[18:26] <seb128> beuno, I fail to understand why not selecting an user will solve the fact that it's not obvious what to do
[18:26] <Amaranth> I've poked into gdm code recently, mostly know my way around
[18:26] <seb128> beuno, and the "Pressing Enter should result in selecting the user from the top of the list, unless any other menu item or button has been manually highlighted."" already works
[18:26] <rickspencer3> seb128, beuno I don't see how this could have been in Karmic so long without this coming back as a "Critical" issue from usrs
[18:27] <pitti> Amaranth: yes, as we already said, patches will be considered, and are appreciated
[18:27] <rickspencer3> and secondly, we are past beta freeze
[18:27] <pitti> Amaranth: my main concern is that we don't really have spare time in the desktop team, but contributors are always welcome
[18:27] <rickspencer3> at this point, every change is considered risky, and must be traded off against fixing crashers
[18:27] <rickspencer3> pitti, but even a "trivial" change takes some work ...
[18:27] <pitti> rickspencer3: well, if someone makes a patch who wouldn't otherwise fix bugs, it's not really a tradeoff
[18:27] <rickspencer3> and risks a regression
[18:28] <pitti> the regression potential needs to be considered, of course
[18:28] <rickspencer3> and what if we get user feedback that they don't like what it was changed to
[18:28] <rickspencer3> I don't understand why we are even discussing it
[18:28] <seb128> well I don't see a clear suggestion in the bug to make the thing obvious
[18:28] <rickspencer3> it's functional and it doesn't crash
[18:28] <beuno> rickspencer3, so you'll go with "users haven't yelled hard enough about this, so lets ignore user testing"
[18:28] <rickspencer3> beuno, we have to *ship*
[18:28] <rickspencer3> it is time to *ship*
[18:29] <beuno> rickspencer3, I don't think "functional and doesn't crash" is the theme here, sorry
[18:29] <beuno> I understand the stress
[18:29] <rickspencer3> we must stop making changes and fix our most serious bugs and *ship*
[18:29] <seb128> beuno, how unselecting will make it obvious what to do?
[18:29] <seb128> I would understand if you asked to add a button or icon in the list
[18:29] <beuno> but it's a bad excuse to not spend an hour fixing an experience that will affect every single user that installs ubuntu
[18:29] <beuno> seb128, because what you need to do is select it
[18:29] <seb128> but it's not the selection which will make people click on the list if they don't do now
[18:29] <rickspencer3> beuno, as I said, we need to have crystal clear focus
[18:29] <beuno> and if it's already selected
[18:30] <beuno> then it tells you not to click it
[18:31] <seb128> anyway seems Amaranth is wanting to provide a patch so let's see how that goes
[18:31] <mat_t> beuno: you said you run some tests on that didn't you?
[18:31] <Amaranth> oh boy, custom widgets galore :)
[18:31] <beuno> mat_t, I've tried this with 4 different people now
[18:31] <kirkland> mdz: sure ... would you like it here or elsewhere?
[18:31] <beuno> 3 non-techie users, and one techie
[18:31] <mat_t> beuno: did everyone have the same problem?
[18:31] <beuno> all of them failed to tell me what they needed to do with that screen when it came up
[18:31] <seb128> beuno, next time start raising issues before beta
[18:32] <beuno> seb128, yes, I should of been more vocal before
[18:32] <mat_t> seb128, that bug was filed 2 months ago!
[18:32] <rickspencer3> are you saying that users can't figure out how to log in after installing their systems?
[18:32] <beuno> I filed the bug, did not presure
[18:32] <rickspencer3> beuno, ^
[18:32] <seb128> mat_t, like 1 thousand others on my list
[18:32] <beuno> rickspencer3, not without experimentation, no
[18:32] <kirkland> mdz: several of us have been testing; i have one minor fix to your upstart script uploaded
[18:32] <rickspencer3> that sounds like an outlandish claim to me
[18:32] <beuno> they click around, and eventually figure it out
[18:32] <seb128> mat_t, that one got almost no comment nor duplicate, it stayed in the noise
[18:32] <mat_t> yeah, I understands
[18:32] <rickspencer3> I can't imagine that this would not have been escelated by users immediately
[18:32] <seb128> mat_t, we get ton of bugs which get duplicates and comments daily
[18:32] <kirkland> mdz: committed; not yet uploaded
[18:32] <kirkland> mdz: that needs to be uploaded and cd re-spun
[18:33] <seb128> mat_t, how do you expect us to pick bugs which have sit there and nobody complained about?
[18:33] <beuno> rickspencer3, users did not complain about notifications before either
[18:33] <kirkland> mdz: i'm looking over the bugs right now to see if there's anything beta-critical and/or low-hanging to batch into this upload
[18:33] <beuno> seb128, I'm sorry about bringing this so late to the table, it was a failure in processes
[18:34] <mdz> kirkland, does that minor fix have to do with the failed registrations? that seemed to be the biggest issue
[18:35] <kirkland> mdz: this fix allows images to run; otherwise, you make a reservation, and it terminates immediately because /var/run/eucalyptus/net doesn't exist
[18:35] <mat_t> seb128: sure, I though since you marked it as triaged it would be on your (meaning desktop team) radar. I may be wrong here, I know you have tons of triaged bugs
[18:36] <seb128> mat_t, right, we have some thousand triaged bugs, that just means we passed the message to people writting the code
[18:36] <kirkland> mdz: i'm still looking at registration
[18:36] <mat_t> sure
[18:36] <mdz> kirkland, ah, right, the bug that ttx mentioned on IRC earlier
[18:36] <beuno> rickspencer3, we have a team built specifically to address usability issues. If in the end, it's going to be ignored, and the only valid measure is user complaints, then we have a problem
[18:36] <kirkland> mdz: that's still not working reliably for ttx or i
[18:36] <WildBill> Is this page the right one for Eucalyptus testing? http://testcases.qa.ubuntu.com/System/Eucalyptus
[18:36] <mdz> kirkland, is there anything I can do to help debug registration?
[18:36] <seb128> mat_t, as said that one has got almost no activity since it has been filed, and activity is the metric to spot common issues
[18:36] <mathiaz> mdz: how to enable upstart debugging?
[18:37] <mdz> mathiaz, there's a page in the upstart wiki about it
[18:37] <kirkland> mdz: yeah, sure; we seem to have a timing issue, that i would have thought upstart should have solved for us
[18:37] <mdz> I think it involves passing a command line option
[18:37] <seb128> beuno, nobody is ignoring your team but the beta weeks is not the week to wake up with all the issues
[18:37] <mathiaz> mdz: I looked at this yesterday and I suspect that the upstart cc-registration job is not run
[18:37] <rickspencer3> beuno, I am supremely unconvinced that users can't log in
[18:37] <kirkland> mdz: i'm still digesting your upstart changes now
[18:37] <mdz> mathiaz, it was definitely run for me
[18:37] <kirkland> mdz: i've held off on uploading with this one minor change, in the interest of solving registration too
[18:37] <mdz> though I could not test all possible orderings
[18:37] <rickspencer3> as seb128 says, if this was an organized design process and I had confidence that it was going to make the project better and not interfere with us shipping, we would be helping you
[18:37] <mdz> in fact, I didn't test the case where reboot happens before registration, which is what's happening here
[18:38] <mathiaz> mdz: kirkland: I'm looking into this as well
[18:38] <beuno> I am not saying they can't, i'm saying it's a clumsy process, which makes them experiment, and one of their experiments makes them expose their password
[18:38] <rickspencer3> I mean we would actively allocated resources to help with this goal
[18:38] <rickspencer3> beuno, well, we need to trade off shipping without crashers and hitting our release dates
[18:38] <mat_t> seb128: usability bugs are very often ignored by current users, who simply get used to them or find a bypass. Users who are most affected by them are often silent, because they would never use launchpad, etc
[18:38] <kirkland> mdz: i have one comment, though on your upstart scripts, somewhat related to the /var/run change i'm making
[18:38] <beuno> rickspencer3, you are being overly stubborn, this seems to be a pretty trivial change
[18:39] <rickspencer3> "shipping is a feature"
[18:39] <kirkland> mdz: the init scripts previously chowned a bunch of that /var/run/eucalyptus stuff to eucalyptus:eucalyptus
[18:39] <rickspencer3> beuno, that's my job
[18:39] <seb128> mat_t, right, but we fail to spot those without our metrics then and it's your role to raise those issues early
[18:39] <kirkland> mdz: in the upstart implementation, all of that is owned by root:root
[18:39] <rickspencer3> *it's time to ship*
[18:39] <seb128> mat_t, the beta week is really late
[18:39] <kirkland> mdz: i haven't seen a problem with it yet, necessarily
[18:39] <ogra> thats what the milestonre tag is for btw ...
[18:39] <kirkland> mdz: just something i've noted
[18:39] <rickspencer3> I need to make the call about where we allocate our precious resources, and I do this on behalf of our users
[18:39] <ogra> if the bug would have been milestoned it would have shown up in the weekly release team meeting
[18:39] <kirkland> mdz: of course, euca_root_wrap might be handling all of that :-)
[18:40] <mat_t> seb128: you are totally right that we should've raised this earlier
[18:40] <rickspencer3> our users need us to focus on the highest priority issues in the most organized manner possible now
[18:40] <mdz> kirkland, iirc the only /var/run stuff I touched were pid files, temporary files and the like.  don't think there was anything there used by eucalyptus itself (which runs as eucalyptus) as opposed to the init script (which runs as root)
[18:40] <mdz> if I overlooked something, we should check it
[18:40] <kirkland> mdz: okay, good
[18:40] <mat_t> seb128: we'll be better in the future :)
[18:40] <beuno> rickspencer3, and you do it ignoring usability data. This is concerning. I'm not going to continue hammering at this, I've raised it with Ivanka, we will go from there
[18:40] <seb128> mat_t, right, learning experience ;-)
[18:41] <rickspencer3> beuno, I have not seen any "data"
[18:41] <rickspencer3> and in any case, it's too late
[18:41] <seb128> mat_t, we will probably sort this one since Amaranth seems to be one the case but that's a lesson learnt for next time in any case
[18:41] <kirkland> mdz: my fix is mkdir -p /var/run/eucalyptus/net (which ensures that both eucalyptus and net get created); and chowning those two directories to eucalyptus:eucalyptus
[18:41] <mat_t> seb128: totally :)
[18:41] <mdz> kirkland, I certainly don't mind that change
[18:41] <beuno> rickspencer3, I've told you, 4 times now, I have done user testing. You continue to ignore that.
[18:41] <mat_t> seb128: thanks for your help!
[18:41] <kirkland> mathiaz: let's sync up on the registration thing
[18:42] <kirkland> mathiaz: where are you with it?
[18:42] <mathiaz> kirkland: sure
[18:42] <seb128> mat_t, you're welcome
[18:42] <beuno> rickspencer3, which is why I'm saying you're being overly stubborn
[18:42] <kirkland> mathiaz: i'm parsing the upstart scripts now
[18:42] <seb128> that said, dinner time there and other issues waiting
[18:42] <kirkland> mathiaz: and mdz is offering to help
[18:42] <mathiaz> kirkland: I'm reinstalling a test vm for that
[18:42] <kirkland> mathiaz: let's figure out what we can do in parallel
[18:42] <rickspencer3> beuno, as a usability engineer, you need to understand that your user testing needs to be done in manner that is both timely and compelling
[18:42] <mathiaz> kirkland: first step - making sure that the upstart jobs are actually run
[18:42] <mathiaz> kirkland: using a pre-script to touch a file
[18:43] <mathiaz> kirkland: I'm also wondering whether the *registration jobs should written as services or tasks
[18:43] <beuno> rickspencer3, it *was* timely, the bug just fell off the radar. We can do this all day, but it's not getting anywhere. If Amaranth is working on it, awesome. We will bring this up in the Nov sprint, and discuss the failure in the process.
[18:44] <rickspencer3> beuno, sounds good
[18:44] <ogra> beuno, using the milestone filed in launchpad was the missing bit
[18:44] <seb128> we need a better process than having bugs filled in the middle of thousands
[18:44] <ogra> milestoned bugs are reviewed weekly
[18:44] <ogra> it would have shown up early if i milestone would have been set
[18:44] <ogra> s/i/a/
[18:45] <Amaranth> ugh, so ugly
[18:45] <seb128> beuno, for the record I think having a "select user" button would work better than no selection
[18:45] <seb128> and would probably be easier code wise
[18:46] <Amaranth> gdm created a custom widget for the user switcher then went and used it for the keyboard and session selectors too, apparently
[18:47] <beuno> seb128, I'm happy to discuss alternatives if it makes it easier. I have to go now, but if you decide to address this, let me know and I'll provide you whatever I can to get it fixed
[18:47] <beuno> seb128, rickspencer3, pitti, cjwatson, thanks for looking into it
[18:47]  * beuno -> off
[18:47] <robbiew> IMHO, we've done enough late changes in this release...I don't like this idea at all
[18:48] <robbiew> for the record, a bug that stays in "New" and "Undecided" has little chance of being fixed...especially at this stage
[18:48] <robbiew> when we have more critical issues to address
[18:48] <kirkland> mdz: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/438602
[18:49] <kirkland> mdz: that's ttx's writeup on the current issue
[18:49] <kirkland> mdz: i've confirmed that walrus autoregistration is working; though cc is not
[18:50] <mathiaz> mdz: so the other part in the upstart jobs I don't understand is that registration should be run once - how is this expressed in upstart?
[18:50] <mathiaz> mdz: is it the use of a task?
[18:50]  * robbiew corrects himself:  a bug that stays in "Triaged" and "Low" has little chance of being fixed
[18:51] <mdz> mathiaz, it isn't.  it's run every time we notice that the components have come up
[18:51] <mdz> this is by design
[18:51] <mdz> nurmi says it is idempotent, so it is harmless to register again
[18:51] <mathiaz> mdz: design in upstart?
[18:51] <mathiaz> mdz: ah ok.
[18:51] <mdz> and if our IP address changes or something, we need to re-register anyawy
[18:52] <mdz> mathiaz, design of the jobs
[18:52] <mathiaz> ok - so eucalyptus-cc-registration is not run
[18:53] <mathiaz> I've added a pre-start script to the cc-registration job:http://paste.ubuntu.com/281524/
[18:53] <mathiaz> IIUC /tmp/cc-registration.started
[18:54] <mathiaz> should be created if the job is run
[18:54] <mathiaz> I've rebooted the system - and after 5mn /tmp/cc-registration.started isn't there
[18:54]  * lamont looks at the current  'hello' source, cries a little.  what's a good _trivial_ source package these days?
[18:54] <lamont> I suppose I could just build one
[18:54] <kirkland> mathiaz: note that the author is still set to mdz; you might update that if you wrote that script
[18:55] <mdz> mathiaz, interesting.  upstart debugging sounds like the next step
[18:55] <mdz> mathiaz, http://upstart.ubuntu.com/wiki/Debugging
[18:55] <mdz> kirkland, I did write that, but it's not important anyway
[18:56] <kirkland> mdz: ah, i misunderstood mathiaz then
[18:56] <mathiaz> so the other strange thing is this: http://paste.ubuntu.com/281528/
[18:56] <mdz> mathiaz, your job looks correct; if the file is not being created, then it doesn't seem tob er unning
[18:56] <mathiaz> note that eucalyptus-walrus-registration stop/waiting
[18:56] <mdz> mathiaz, check "status eucalyptus-cc"
[18:57] <mdz> mathiaz, and "status eucalyptus-cloud"
[18:57] <mdz> eucalyptus-cc-registration is supposed to run when both of those come up and running
[18:57] <mathiaz> while the walrus registration is actually sucessfull
[18:57] <mathiaz> eucalyptus-cloud start/running
[18:58] <mathiaz> ^^ but there isn't any pid there
[18:58] <mathiaz> and the eucalyptus-cloud job defintion doesn't have any script/exec defition
[18:58] <mathiaz> it only has a post-script definition
[18:59] <mathiaz> http://paste.ubuntu.com/281529/
[18:59] <mdz> mathiaz, the -registration jobs are tasks, which means they don't stay running, they go back to stopped/waiting
[18:59] <mdz> stop/waiting
[18:59] <mdz> so that's normal
[18:59] <mathiaz> ^^ I wonder what eucalyptus-cloud is meant for then
[18:59] <mdz> mathiaz, eucalyptus-cloud is meant to wait for the cloud service to come up, and emit a signal when it is ready
[19:00] <mdz> mathiaz, -cloud, -sc and -walrus all run within the same process, but don't all come available at the same time
[19:00] <mdz> (necessarily)
[19:00] <cjwatson> is post-start actually run at all if there's no main process?
[19:00] <mdz> mathiaz, -cc runs as a separate process, so it comes with its own pre-start
[19:00] <mathiaz> mdz: eucalyptus-sc-registration.conf has a respawn whereas cc-reg and walrus-reg don't
[19:00] <mdz> cjwatson, it worked for me
[19:00] <ion> cjwatson: It should.
[19:01] <mdz> mathiaz, that's an anomaly; I was starting to experiment with respawn but found it wasn't needed
[19:01] <mdz> it should be harmless
[19:01] <mathiaz> mdz: ok.
[19:01] <mdz> respawn means that if it fails to start, it will get retried until it succeeds
[19:01] <mdz> it wouldn't hurt, but might mask bugs
[19:01] <mathiaz> mdz: -cc is a different process, while walrus is the same as -cloud?
[19:02] <mdz> mathiaz, that's correct
[19:02] <fta> doko_, i guess you have your answers for chromium now, right?
[19:02] <mdz> mathiaz, -cc is actually an apache2 process using axis2
[19:02] <mathiaz> eucalyptus-cc-registration.conf: start on (started eucalyptus-cc and started eucalyptus-cloud)
[19:02] <mdz> -cloud/-sc/-eucalyptus is one JVM process
[19:02] <cjwatson> IMO, respawn with a limit would be neater than that timeout loop
[19:02] <mathiaz> eucalyptus-walrus-registration.conf: start on (started eucalyptus-walrus and started eucalyptus-cloud)
[19:02] <mathiaz> could that be an issue^^?
[19:03] <mdz> cjwatson, hmm, I think I agree. I didn't know that respawn had a limit
[19:03] <mdz> mathiaz, could what be an issue?
[19:03] <cjwatson> you would probably still need the sleep 1 to avoid it respawning too rapidly
[19:03] <mathiaz> cc-registration depends on two different processes, while walrus-registration depends on the same process?
[19:03] <mathiaz> eucalyptus-walrus-registration.conf: start on (started eucalyptus-walrus and started eucalyptus-cloud)
[19:03] <cjwatson> anyway, not really directly relevant
[19:03] <mdz> mathiaz, cc registration requires that the cloud service and cc service are running
[19:03] <doko_> fta: yes, besides I don't know why the python-tlslib is not in jaunty/karmic ...
[19:03] <mdz> mathiaz, walrus registration requires that the walrus service and cloud service are running
[19:04] <mdz> mathiaz, we should get nurmi in here
[19:04] <mathiaz> mdz: well - I'm still not convinced that this is not an issue with the upstart jobs.
[19:05] <kirkland> mdz: i just poked nurmi over here
[19:05] <mathiaz> mdz: I'm trying to figure out why the cc-registration job is not started
[19:05] <mdz> mathiaz, I know, I'm trying to help
[19:05] <mathiaz> mdz: while the walrus-registration job is
[19:05] <mdz> it worked for me in my tests yesterday
[19:05] <mdz> mathiaz, did you try the status commands I suggested?
[19:05] <cjwatson> mdz: FWIW, when I was trying to get usplash working with upstart yesterday, I hacked up http://paste.ubuntu.com/281538/ and ran upstart with that
[19:06] <mdz> mathiaz, you said eucalyptus-cloud was running; what about eucalyptus-cc?
[19:06] <cjwatson> the log format is screwy (times on a separate line) but I had better things to do than fix that
[19:06] <mathiaz> mdz: they're all running: http://paste.ubuntu.com/281540/
[19:06] <cjwatson> also that's a bit more than strictly necessary for you, I was trying to debug something specific :)
[19:06] <nurmi> o/
[19:07] <mdz> mathiaz, grep eucalyptus /var/log/syslog? upstart will log if any jobs failed
[19:07] <kirkland> nurmi: we're discussing -cc auto registration
[19:07] <nurmi> kirkland: nod
[19:07] <kirkland> nurmi: seems we're successfully autoregistering walrus, but not the cc
[19:07] <mathiaz> mdz: empty
[19:08] <mdz> mathiaz, if you run 'start eucalyptus-cc-registration', that works, right?
[19:08] <mdz> it's just not getting triggered at the right time?
[19:08]  * mathiaz tries
[19:08] <mathiaz> mdz: yes - it works as expected
[19:08] <mdz> mathiaz, it'll write to /var/log/eucalyptus/cc-registration.log
[19:08] <mdz> hmm
[19:08] <mathiaz> mdz: so the job is not triggered
[19:09] <mdz> is Keybuk on holiday?
[19:09] <mdz> cjwatson, did you have to hack up that logging because the built-in debugging wasn't sufficient?
[19:09] <Amaranth> no way, this gdm bug can't be as simple as commenting out one line of code
[19:09] <ion> mdz: Proper logging of jobs’ output is in TODO list.
[19:09]  * Amaranth builds
[19:10] <seb128> Amaranth, the line which focus the first entry in the list? ;-)
[19:10] <cjwatson> mdz: not for the very early stages, at least
[19:10] <cjwatson> mdz: Keybuk is having DSL problems
[19:10] <fta> doko_: it's no longer used, i should drop the build-dep or re-add my patch in chromium (it's a matter of /usr/bin/tls vs /usr/bin/tls.py)
[19:10] <mdz> mathiaz, maybe something to try would be stopping and starting -cloud and/or -cc to see if that triggers it
[19:10] <Amaranth> seb128: yeah, but it's obfuscated through 4 layers of custom widgets
[19:11] <doko_> fta: good to know
[19:11] <Amaranth> seb128: I figured with that much crazy going on I'd have to change more
[19:12] <cjwatson> mdz: (early stages> I was trying to debug stuff happening before rsyslog ... but in any case I wanted a complete log of upstart's operation in one place)
[19:13] <kirkland> mathiaz: i grabbed nurmi; do you know what mdz wanted from him here?
[19:13]  * nurmi waves
[19:14] <mathiaz> nurmi: I don't think we need you right now
[19:14] <kirkland> nurmi: just idle here, if you don't mind
[19:14] <nurmi> mathiaz: okay, available if needed for most of today (PST) :)
[19:14] <kirkland> nurmi: we'll poke you if we need something
[19:14] <nurmi> nod
[19:14] <mathiaz> nurmi: I may have more questions later on the best way to make sure that one of the service is actually operational
[19:15] <mathiaz> kirkland: for now, the symptom is that the cc-registration job is not started by upstart
[19:16] <nurmi> mathiaz: got it, i'll try to help, although I am having trouble starting eucalyptus services (start eucalyptus-cloud hangs forever) on the latest build.  I can offer advice, but may be limited in testing
[19:16] <mathiaz> nurmi: right. Advices is already better than nothing :)
[19:16] <nurmi> mathiaz: :)
[19:17] <fta> doko_, but if you want to have python-tlslib in the archives, feel free to takeover my branch
[19:19] <doko_> fta: last release 2005? no, thanks. just remove the b-d
[19:24] <fta> doko_, yes, but that means more 3rd party code in chromium
[19:24] <nurmi> sorry folks, I have some meetings for a few hours, but please email/msg me with anything i can help with
[19:28] <oxocoffee> Any one here can help with strange socket/multicast problem. I am getting data but double copy
[19:34] <ogra> pitti, haha, spamalot :)
[19:34] <mathiaz> kirkland: I've managed to get more debug
[19:34] <mathiaz> kirkland: /sbin/initctl log-priority debug
[19:34] <kirkland> mathiaz: pastebin?
[19:35] <mathiaz> kirkland: ^^ add this as the first line of the pre-script from the eucalyptus.conf job
[19:35] <mathiaz> kirkland: it's huge - a complete log
[19:36] <kirkland> mathiaz: ack
[19:38] <mathiaz> kirkland: http://people.canonical.com/~mathiaz/syslog
[19:38] <kirkland> You don't have permission to access /~mathiaz/syslog on this server.
[19:39] <mathiaz> kirkland: retry
[19:39] <kirkland> mathiaz: i have my own here now
[19:39] <mathiaz> kirkland: ok great.
[19:40] <kirkland> mathiaz: looks like the cc job is registered
[19:40] <mathiaz> kirkland: are you looking at my syslog file?
[19:41] <kirkland> mathiaz: yeah, let's just look at yours for now, so that we're on the same data
[19:41] <kirkland> mathiaz: though mine looks similar
[19:41]  * mathiaz nods
[19:44] <mathiaz> kirkland: hm - I don't see anything special here
[19:45] <mathiaz> kirkland: except that the upstart configuration is reloaded
[19:45] <mathiaz> kirkland: in the process
[19:45] <mathiaz> kirkland: could that lead to lost events?
[19:46] <Darxus> I could swear yesterday when I clicked "Also affects project" on launchpad, it gave me the option to enter a url for an upstream bug.  Am I wrong?  It's not there today.
[19:46] <mathiaz> kirkland: http://paste.ubuntu.com/281576/ <- this is when the walrus-registration is started
[19:48] <kirkland> mathiaz: cool, yep
[20:10] <jdong> kees: is there a way to attach an apparmor profile to only a specific process without hardlinking galore?
[20:10] <jdong> kees: as an example in OS X you can do something like sandbox-exec {profile} {executable}
[20:11] <kees> jdong: libvirt does dynamic profile attachment, but it does require a little bit of code to implement it.
[20:11] <kees> jdong: there isn't an arbitrary way to do it at the moment.  I'd like to see sandboxes implemented with apparmor.  Saw a demo of selinux sandboxing; it seems easy enough to do.
[20:12] <jdong> kees: *nods* how does libvirt do it?
[20:14] <kees> jdong: it creates a profile with a random UUID, then calls apparmor_change_profile from libapparmor before exec'ing, I think.  jdstrand would know the details better.
[20:14] <jdong> kees: LOL ok :)
[20:14] <jdong> kees: I might look at hacking up something similar to that
[20:15] <jdong> kees: wanted to provide a way for people on a public shell server (standard users) to elect into their own AA restrictions
[20:16] <jdstrand> libvirt has been modified to aa_change_profile() before the exec() as kees said
[20:17] <jdstrand> profiles are created dynamically based on the uuid of the domain in question
[20:17] <jdstrand> so each gets it's own unique, tailor made profile
[20:17] <jdstrand> (each kvm/qemu process that is)
[20:18] <jdong> jdstrand: ok, aa_change_profile() is the magic I need then
[20:18] <jdong> thanks
[20:18] <jdstrand> aa_change_profile() and change_hat() require that the application be modifed
[20:18] <jdstrand> np
[20:18] <jdstrand> most of the work on libvirt was creating the dynamic profiles sanely
[20:19] <jdong> right
[20:19] <jdstrand> simply calling aa_change_profile() is pretty straight forward. see the include in libapparor-dev
[20:19] <jdong> theoretically it can be done from an agnostic "aa-exec" type wrapper, right?
[20:19] <jdstrand> yeah
[20:19] <jdong> cool
[20:19] <jdstrand> that is kinda what virt-aa-helper does in libvirt
[20:20] <jdstrand> well, not really-- it does the dynamic stuff, but sure you should be able to do that
[20:20] <kees> this could be handy for gdm-guest-session too
[20:21] <jdstrand> (virt-aa-helper is a wrapper around apparmor_parser, so libvirt isn't messing around with apparmor directly, but I digress)
[20:21]  * jdong nods
[20:22] <jdong> likely I'll need both something to interface with aa_parser and change_profile
[20:22] <jdstrand> depending on your application, yeah
[20:22] <jdong> I think if properly done the idea of voluntarily electing into an AA confinement domain is a very powerful feature
[20:23] <jdstrand> I split out the apparmor_parser stuff so that I could confine libvirtd to using virt-aa-helper whnever messing with apparmor, to prevent bootstrapping
[20:23] <jdstrand> it certainly sounds interesting
[20:24] <jdstrand> fyi, aa has user-defined profiles on the Roadmap as well, but they aren't implemented yet
[20:24]  * jdong nods
[20:31] <rrva> Hi. Since upgrading to upstart boot process hangs after cryptdisks are enabled. I suspect mountall to not let boot continue. If I reconfigure control-alt-delete so that a getty is spawned I can see that filesystem / is read-only and swap is not enabled.
[20:33] <slangasek> rrva: I've not heard of such a bug; mountall shouldn't block getting swap mounted and mounting the rootfs rw
[20:33] <slangasek> rrva: can you post your fstab somewhere?
[20:34] <rrva> yes
[20:34] <slangasek> rrva: and can you try setting -v in /etc/init/mountall.conf?  Maybe it has something interesting to tell us
[20:34] <rrva> yes
[20:34] <rrva> I did
[20:34] <rrva> but I only have one comp, so bear with me when rebooting
[20:34] <slangasek> sure, understood :)
[20:34] <slangasek> please bear with us while we shake out your bugs
[20:35] <rrva> also udevd complains before the "hang"
[20:35] <slangasek> there's a known udevd warning that's unrelated noise
[20:35] <slangasek> "SYMLINK"?
[20:36] <rrva> no
[20:36] <slangasek> oh, perhaps you have another bug then
[20:36] <slangasek> the exact error message would help
[20:37] <rrva> posting fstab soon, then reboot, then error message
[20:37]  * slangasek nods
[20:38] <rrva> http://pastebin.com/f94435f
[20:38] <rrva> away for reboot
[20:40] <slangasek> rrva: hmmm, I wonder if we fail to handle swapfiles
[20:40] <slangasek> anyone else here running with a swapfile with karmic?
[20:42] <slangasek> ... anyone else want to *test* using a swapfile with karmic? :)
[20:42] <rrva> udevd[533]: inotify_add_watch(6, (null), 10) failed: Bad address
[20:42] <rrva> this is repeated many times
[20:42] <slangasek> hmm
[20:43] <rrva> * Starting init crypto disks ... [OK]
[20:43] <rrva> is the last line
[20:44] <rrva> I tried disabling swap
[20:44] <slangasek> and no luck?
[20:44] <rrva> no difference
[20:46] <rrva> if I configure tty2 to run at runlevel 6, press control-alt-delete and quickly control-s, I can login on tty2 and kill the runlevel 6 killall scripts. This is how I get a running system at all.
[20:51] <sharms> pitti: how does cups / userspace drivers work when the user has a usb2parallel adapter? LP #436495
[20:51] <slangasek> rrva: the udev problem seems the most likely cause of your failure, then; could you please file a bug report about this in Launchpad?
[20:51] <sharms> should it just be assumed they wont be autoconfigured in that scenario?
[20:52] <slangasek> rrva: our udev expert is offline today due to DSL problems, so that's the best way to get the bug in front of the right eyeballs
[20:55] <slangasek> sharms: the usb-parallel adapter won't be able to provide printer identification information, so yeah, I don't think that's going to autoconfigure
[20:55] <rrva> how to file bug without working X?
[20:55] <LLStarks> hi. is the ubuntu keyserver down?
[21:00] <sharms> slangasek: I am wondering how that works since usblp is blacklisted by default now
[21:00] <slangasek> rrva: https://bugs.launchpad.net/ubuntu/+source/udev/+filebug (I hope this is working currently... :/)
[21:00] <slangasek> sharms: that part, I don't know
[21:11] <mdke> slangasek: did you catch my hilight about gnome-user-docs?
[21:12] <slangasek> mdke: ah - yes, then it slipped through my fingers into the stream of other beta preps :( pulling it up now
[21:12] <slangasek> mdke: I agree that this is the wrong time to be changing the package split
[21:12] <mdke> slangasek: awesome, thanks. I'd like to get it sorted by beta but having said that, I'm pretty sure you have plenty of other urgent things which are more important
[21:13] <mdke> slangasek: nod
[21:13] <slangasek> mdke: /usr/share/iso-codes/iso_639.tab has been rudely deprecated in favor of an XML file: /usr/share/xml/iso-codes/iso_639.xml
[21:13] <mdke> aha. is it just a straight replace?
[21:14] <slangasek> mdke: at this point we're already in the process of trying to vet final ISOs for beta, so I don't think we're going to get these changes in pre-beta - we should try to get it so it's ready to build immediately post-beta, though
[21:14] <mdke> find by me
[21:14] <mdke> fine*
[21:15] <rrva> slangasek: bug #438962
[21:15] <mdke> colin mentioned an application called iso-query but I don't know how it would fit in with the relevant line in debian/rules, because I can't understand that line :)
[21:15] <slangasek> mdke: it's a straight replacement for the /content/, but of course instead of being a sensible text format it's now xml :P Perhaps iso-query is a tool they provide to convert the XML to text... I'll try to have a look later today
[21:15] <mdke> slangasek: ok, thanks. Let me know if you need anything from me, and sorry to burden you with that
[21:16] <mathiaz> kirkland: so I think it's a timing problem
[21:16] <slangasek> mdke: no worries, I touched it last so I have it coming ;)
[21:16] <mathiaz> kirkland: I was able to make the walrus-registration job not run by adding a sleep 10 as the walrus job script
[21:17] <Hatl> hi! aptitude crashes if i want to start minesweeper: Aborted
[21:17] <zul> slangasek: after beta I was going to upload samba 3.4.1
[21:18] <slangasek> zul: feature freeze applies, please make sure the changes are appropriate for where we are in the release cycle
[21:18] <zul> k
[21:19] <zul> ill subscribe ubuntu-release
[21:22] <rrva> could someone just add the info at http://pastebin.com/f94435f to 438962, i have only lynx and navigating is hard
[21:23] <slangasek> pitti: so... is core-dev transitively a member of ubuntu-art-pkg, or is this another packaging branch with permissions that don't match the archive?
[21:23] <mathiaz> kirkland: http://people.canonical.com/~mathiaz/syslog
[21:23] <slangasek> rrva: will do, thanks
[21:23] <mathiaz> kirkland: ^^ this is an updated log file - there are two boots in there
[21:23] <rrva> thanks, i'll check back tomorrow if more info is wanted
[21:24] <kirkland> mathiaz: hmm, so respawn should make it retry indefinitely, right?
[21:24] <mathiaz> kirkland: the first one doesn't run walrus-register (because the walrus job has a sleep 10 as a script) while the second runs walrus-registration
[21:24] <mathiaz> kirkland: respwan in walrus or walrus-register?
[21:25] <mathiaz> kirkland: walrus-register is *not* even started in the former case
[21:25] <kirkland> mathiaz: all of the registration ones have "respawn"
[21:25] <mathiaz> kirkland: I don't think so
[21:26] <mathiaz> kirkland: they're all task
[21:26] <mathiaz> kirkland: instead of services (the default)
[21:28] <kirkland> mathiaz: okay, tell you what ...
[21:28] <kirkland> mathiaz: i'm going to shift my focus for a bit on euca_conf, and the part of the code that's throwing the "you need to be on the CLC host and the CLC needs to be running" error
[21:29] <mathiaz> kirkland: yeah - I think we need the upstart expert to debug this
[21:29] <rgreening> who the resident HAL expert? :) I need some assistance or advice on my bug 438316
[21:29] <kirkland> mathiaz: he's still offline :-/
[21:30] <mathiaz> kirkland: I'm going to update the euca bug with the current state
[21:30] <slangasek> mathiaz, kirkland: can you summarize the problem?
[21:30] <mathiaz> slangasek: sure - the eucalyptus-cc-registration job is not started
[21:30] <mathiaz> slangasek: when its dependencies are satisified
[21:31] <mathiaz> slangasek: while the eucalyptus-walrus-registration job is correclty started
[21:31] <mathiaz> slangasek: eucalyptus-cc-registration.conf:start on (started eucalyptus-cc and started eucalyptus-cloud)
[21:31] <mathiaz> slangasek: eucalyptus-walrus-registration.conf:start on (started eucalyptus-walrus and started eucalyptus-cloud)
[21:32] <mathiaz> slangasek: eucalyptus-walrus is a job with a post-script that waits for the http service to be answering correclty
[21:33] <mathiaz> slangasek: whereas eucalyptus-cc actually starts a process (via exec)
[21:33] <c_korn> is it related to virtualbox that I still get this "Superblock last mount time is in the future" bug on restart ? all related bugs have been marked as fixed released
[21:33] <mathiaz> slangasek: now if a script stanza (that sleep 10) is added to the eucalyptus-walrus job, eucalyptus-walrus-registration is not run as well
[21:33] <slangasek> mathiaz: right; looking
[21:34] <slangasek> mathiaz: oh, where are these -registration upstart jobs?
[21:34] <sharms> if usblp is going to be disabled by default and no work around is found, who do I contact about getting it added to the release notes?
[21:34] <mathiaz> slangasek: in /etc/init/eucalyptus-*
[21:34] <mathiaz> slangasek: or you're asking in the source package?
[21:34] <slangasek> yes
[21:35] <slangasek> I don't see -registration upstart jobs in the eucalyptus core-dev branch
[21:35] <kirkland> slangasek: what branch are you looking at?
[21:35] <kirkland> slangasek: ~ubuntu-core-dev/eucalyptus/ubuntu
[21:35] <slangasek> kirkland: yes, that one
[21:35] <kirkland> slangasek: see debian/*regist*
[21:36] <slangasek> oh
[21:36] <slangasek> tab completion fail
[21:36] <slangasek> kirkland, mathiaz: is there a reason to run apache2 in the foreground as opposed to using 'expect fork'?
[21:36] <kirkland> slangasek: globs for the win!
[21:36] <ttx> kirkland, mathiaz: I gather setting the external IP rather than localhost didn't help in any way ?
[21:37] <kirkland> ttx: howdy, welcome back
[21:37] <mathiaz> ttx: well - the job are not started
[21:37] <slangasek> kirkland, mathiaz: and you've confirmed that 'status eucalyptus-cc' shows it started?
[21:37] <ttx> mathiaz: hm
[21:37] <mathiaz> slangasek: yes
[21:37] <slangasek> ok, looks like an upstart bug to me, then :P
[21:38] <kirkland> slangasek: yes, running
[21:38] <ttx> mathiaz: it did start with me, when I did sudo stop eucalyptus / sudo start eucalyptus (error appears in /var/log/eucalyptus/*registration.log)
[21:38] <mathiaz> ttx: to test whether a job has started, I've added a pre-script to all the registration job that touch a file in /var/tmp/
[21:38] <mathiaz> ttx: right - I suspect a timing issue in upstart
[21:39] <mathiaz> ttx: if I modify the walrus job to sleep for 10 seconds, then the walrus-registration job is not started as well
[21:39] <ttx> mathiaz: be careful with "restart" btw, mdz saw that env isn't set in that case...
[21:39] <mathiaz> ttx: slangasek: http://people.canonical.com/~mathiaz/syslog
[21:39] <mathiaz> ttx: ^^ this is a syslog with upstart debug information
[21:39] <ttx> which crashes eucalyptus-cc httpd (if EUCALYPTUS=/ is not set)
[21:40] <mathiaz> ttx: I meants a system reboot
[21:40] <mathiaz> ttx: the first boot doesn't start walrus-registration, while the second does
[21:40] <ttx> mathiaz: ok.
[21:41] <slangasek> mathiaz: yeah... really looks like an upstart bug to me
[21:41] <ttx> mathiaz: that log looks a lot like an upstart bug.
[21:41] <slangasek> mathiaz: I do wonder whether using 'expect fork', dropping the -f argument to apache, and dropping the post-start script would make a difference
[21:41]  * mathiaz agrees that this really look like an upstart bug
[21:41] <ttx> we all agree, cool ;)
[21:42] <slangasek> if it works, it might make for a nicer job, though it's a workaround in any case
[21:42]  * mathiaz flies to Europe to fix some DSL lines
[21:42] <slangasek> (hmm, and maybe your post-start script depends on something more than just apache being started, so.)
[21:43]  * ttx goes to sleep, you seem to be on the right track
[21:43] <davmor2> mathiaz: say the word I'll drive over and get him ;)
[21:43] <ttx> mathiaz, kirkland: if for whatever reason this can't be solved before the end of your day, please push the other fix on an ISO nevertheless.
[21:44] <mathiaz> ttx: I think that's what we gonna do
[21:44] <ttx> then we'll decide if that should still be solved for beta or if we stay with that known bug.
[21:44]  * ttx disappears
[21:51] <kirkland> mathiaz: i think i'm going to go ahead and upload my other fix
[21:51] <kirkland> mathiaz: get that onto an iso
[21:51] <kirkland> mathiaz: we can continue working this one in parallel
[21:51] <mathiaz> kirkland: agreed.
[21:56] <kirkland> slangasek: hey, did we merge those packaging fixes you gave us on Friday?
[21:56] <slangasek> I don't know
[21:56] <kirkland>   [ Steve Langasek ]
[21:56] <kirkland>   * Move eucalyptus-nc "no VT" handling for LP: #426830 to a debconf script
[21:56] <kirkland>     instead, so that users are a bit more likely to see this.
[21:56] <kirkland>   * Drop the dpkg-statoverride check on /var/lib/eucalyptus/keys in the
[21:56] <kirkland>     eucalyptus-common postinst; this was ineffective anyway because we'd done