[00:00] <cjwatson> kirkland: probably means that the script does some other things in shell before forking the main process, and upstart follows the first fork
[00:00] <cjwatson> even 'if [ ... ]' can cause that
[00:01] <ion> Yeah, it’s very easy to break current Upstart’s fork following code. 0.10 will fix that issue.
[00:01] <kirkland> cjwatson: http://pastebin.ubuntu.com/352593/
[00:01] <kirkland> cjwatson: modeled off of ssh.conf
[00:01] <cjwatson> well, that looks ok, maybe libvirt forks twice?
[00:01] <cjwatson> libvirtd that is
[00:01] <kirkland> cjwatson: must be
[00:02] <cjwatson> if so, 'expect daemon'
[00:02]  * slangasek nods
[00:02] <kirkland> cjwatson: would that be causing my problems stopping the job?
[00:02] <slangasek> certainly
[00:02] <cjwatson> yes, there's a bug where you can completely bugger upstart to the point where you have to reboot
[00:02] <kirkland> fwiw, libvirtd does write its own pid file
[00:03] <slangasek> upstart doesn't have any secret ways to stop jobs, it uses the same PID information that it reports to you with 'status' :)
[00:03] <cjwatson> I don't believe upstart cares about pid files
[00:03] <slangasek> indeed not
[00:03] <cjwatson> indeed the general philosophy of upstart is that pid files are obsolete
[00:03] <kirkland> slangasek: okey doke
[00:03] <ion> cjwatson: How *does* one get Upstart to a state you need a reboot to fix? :-)
[00:04] <douglasawh-work> cjwatson: this is the pull command: ssh target_address dd if=remotefile | dd of=localfile
[00:04] <kirkland> slangasek: cjwatson: \o/
[00:04] <cjwatson> ion: I forget, but I did it while writing ssh.conf and Keybuk said "oh, yeah, known bug"
[00:04] <kirkland> "expect daemon" worked like a champ
[00:05] <cjwatson> douglasawh-work: well, grub2 doesn't store anything anywhere magic, it just puts it on the disk with everything else ...
[00:05] <kirkland> cjwatson: so your comment in ssh.conf, about editing the exec line, rather than /etc/default/* ... i mimic'd that.... is that correct, or lazy?
[00:05] <cjwatson> douglasawh-work: I don't understand how your *encryption* is laid out, though. when you get time, could you please file a bug with full details of what you're trying to make work?
[00:05] <cjwatson> kirkland: it's following strong preference from Keybuk
[00:05] <douglasawh-work> cjwatson: yeah, that's what I thought, but it doesn't work.  I'm just using the alternate cd full disk encryption
[00:06] <cjwatson> kirkland: besides, after starting to use upstart's oom feature, there really wasn't that much left in /etc/default/ssh
[00:06] <kirkland> cjwatson: yeah, there's nothing of value (except for "-d" == deamonize") in /etc/default/libvirt-bin
[00:06] <kirkland> cjwatson: i'm on board ;-)
[00:07] <cjwatson> douglasawh-work: (I'm partly asking for a bug because unfortunately I don't really have time to look into this right now)
[00:08] <douglasawh-work> cjwatson: I'll file a bug. I just mainly wanted to make sure it wasn't already fixed in lucid before submitting
[00:09] <cjwatson> douglasawh-work: not to my knowledge, but then I didn't know it was broken :)
[00:09] <cjwatson> so it's always possible I missed something
[00:10] <kirkland> cjwatson: slangasek: what do I need to do to get the server ISO build cronjob changed?  File an RT?
[00:10] <cjwatson> ion: bug 406397
[00:11] <cjwatson> kirkland: RT is no use at all
[00:11] <cjwatson> (for this!)
[00:11] <kirkland> cjwatson: heh
[00:11] <cjwatson> kirkland: if you want to file a bug, file it on the ubuntu-cdimage project, but it's probably quicker to just ask somebody in the ubuntu-cdimage team ...
[00:11] <kirkland> cjwatson: send you chocolate, then?
[00:11] <slangasek> kirkland: close your eyes, click your heels three times, and 'bzr update' to reveal that it's already been done
[00:11] <kirkland> slangasek: ah, send slangasek chocolate :-)
[00:11] <slangasek> assuming you mean 'run ubuntu-server earlier' :)
[00:11] <kirkland> slangasek: yeah, thanks
[00:12] <ion> cjwatson: Ah, that. I managed to get out of it without needing a reboot (as a reboot would have been inconvenient with users on the box in question). :-)
[00:21] <Shiran> hi anyone know how can i get involved with ubuntu developmenting?
[00:27] <cjwatson> Shiran: http://wiki.ubuntu.com/ContributeToUbuntu, http://wiki.ubuntu.com/UbuntuDevelopment
[00:28] <Shiran> yea yea i don't get it
[00:28] <Shiran> i registered myself in launchpad
[00:28] <Shiran> and i dont get how to find stuff to work on in there
[00:30] <cjwatson> Shiran: you won't find that an effective way to get started, no. It's much more effective to find something that you actually want to work on (e.g. a bug that's annoying you personally) and work on that
[00:30] <cjwatson> Launchpad has *everything*, it's a bit like wandering into a field and looking for an interesting blade of grass
[00:30] <cjwatson> you can try https://bugs.launchpad.net/ubuntu but it will still be overload :)
[00:31] <Shiran> i wanna get involved with programming
[00:31] <Shiran> isn't there a way to find teams that work on stuff that need more people?
[00:32] <cjwatson> it is much more effective to decide what you want to work on and then look for a relevant team
[00:32] <cjwatson> "programming" is a bit too vague for this purpose, try to narrow it down :)
[00:32] <Shiran> how can i narrow it down?
[00:32] <cjwatson> based on your interests
[00:33] <Shiran> my interest is writing code
[00:33] <cjwatson> yes, try to be a bit more specific :)
[00:33] <Shiran> im not sure i can :P
[00:34] <Shiran> c++
[00:34] <Shiran> is that more specific?
[00:34] <cjwatson> not really, but it may help you to find (for example) some programs already installed on your system that are written in that language that you might like to help with
[00:35] <cjwatson> distributions, by their nature, are rather more involved in integrating existing code from elsewhere than they are in writing lots of new code, although of course some of the latter does happen
[00:36] <cjwatson> so if you want to work in the context of a distribution, you're generally talking about either maintaining existing code (bug-fixes, feature enhancements, etc.) or finding one of the areas where the distribution is trying to distinguish itself
[00:36] <Shiran> isn't there a way to find teams of programmers?
[00:37] <Shiran> say i wanna work on KDE
[00:37] <cjwatson> http://wiki.ubuntu.com/Teams
[00:41] <Riddell> Shiran: Kubuntu developers are in #kubuntu-devel, we do occational bits of c++ but mostly its working with upstream KDE code.  KDE developers are in #kde-devel
[01:41] <ikthus> hi :)
[02:38] <douglasawh-work> cjwatson: installed grub1 and the problem is resolved, so thanks for that suggestion.  At some point I'll test whether the problem exists in Lucid at all...I just know it's a problem in karmic. after I test that, I'll file a bug
[03:27] <lunatic> hey could anyone help a newbie apply a patch? http://www.mail-archive.com/hydrogen-devel@lists.sourceforge.net/msg00083.html this one particularly
 i eed it for the hydrogen source code to compile
[06:39] <alkisg> TheMuso: Hi, Ubuntu doesn't work with libsdl1.2debian-alsa, but it does work with the pulseaudio variants. The same is true for LTSP (thin clients). Could we make it so that either libsdl1.2debian-pulseaudio or libsdl1.2debian-all are installed when an Ubuntu user installs an SDL-using app?
[06:40] <alkisg> For libsdl1.2debian-all to work with pulse, SDL_AUDIODRIVER=pulse needs to be in the environment, but than can be taken care of by e.g. LTSP.
[06:48] <persia> alkisg: The simple way to do that is to just adjust the relative dependencies of apps.  My memory is that we spent a lot of time changing to use -alsa some time back, and those changes can probably be reverted.
[06:49] <alkisg> persia: then those apps wouldn't work in kubuntu...
[06:49] <alkisg> (and also, they're 387 on them using sdl in my current installation)
[06:49] <persia> I thought the phonon pulse backend was first-class now.
[06:49] <persia> Is the vlc backend still default?
[06:50] <alkisg> I don't use Kubuntu or Xubuntu, but I was told that those still need -alsa
[06:51] <persia> I haven't looked at it for lucid, but I believe the blocker for Xubuntu was xfce4-mixer running into bugs with gstreamer0.10-pulseaudio, which I thought were fixed.
[06:52] <persia> For Kubuntu, the issue is all about having a fully-featured pulse backend for phonon so that users don't end up without sound.  I don't know the status on that.
[06:52] <alkisg> OK, so the plan is to switch all derivatives to using pulseaudio? That's fine, but why then do we have libsdl1.2debian depend on libsdl1.2debian-alsa first? Shouldn't we switch that to -pulseaudio?
[06:52] <persia> But I don't know of any way (other than including in the default install) of preferring alternate libsdl implementations based on flavour, especially for people who use subsets of flavours.
[06:53] <persia> My personal opinion is that everything should use pulse, and we should make that switch.  I don't imply that this is an official plan.
[06:53] <persia> It's just the easiest way to get out of the mess.
[06:54] <alkisg> persia: the packaging problem can be solved with libsdl1.2debian-all, as this contains support for all backends
[06:54] <persia> I know there was discussion about it at UDS Karmic, but I don't remember follow-up discussion at UDS Lucid.
[06:54] <persia> alkisg: Well, except that then each flavour has to somehow handle setting SDL_AUDIODRIVER in some way.
[06:55] <persia> Unless you want to change libsdl1.2debian-all to be smart enough to use pulse if it is available and fall back to alsa if it isn't.
[06:55] <alkisg> Right
[06:56] <alkisg> I think that's the best plan, it would work out of the box in all cases, and it would still enable some extreme user to select his own output
[06:56] <persia> Right.
[06:56] <alkisg> ...and it's already in main, while libsdl1.2debian-pulseaudio isn't.
[06:58] <persia> Well, I think that if we're going to default to pulse if it's available, it's worth putting together an MIR for libsdl1.2debian-pulseaudio.
[06:59] <persia> Actually, looking at it, it doesn't even need an MIR.  It just needs to get pulled with a dependency.  The source is already in main.
[06:59] <alkisg> I was going to write one, but I don't think that's needed, -all is still the best plan even if we want the default output to pulse, as it enables users to select their own output
[06:59] <persia> Well, except we need -all to recommend -pulseaudio if we want the default to be pulse
[07:00] <alkisg> No - it conflicts with -pulseaudio
[07:00] <persia> Ah, and it already includes the pulse bits.
[07:00] <alkisg> Right
[07:00]  * persia hasn't actually looked at libSDL for far too long
[07:01]  * alkisg is a teacher and unfortunately he gets complains for all sdl-based edu* apps :(
[07:01] <persia> Well, that's a good thing.  Helps highlight the issue.
[07:01] <persia> Of course, it quickly becomes a bad thing if we can't fix it.
[07:04] <alkisg> Also, crimsun has said that -alsa with be patched to work even when pulseaudio is installed (I don't know the details). In that case, all workstation users will be satisfied, as SDL apps will work out of the box. But LTSP users wouldn't be satisfied because they'd require pulseaudio output as the sound goes through the network. In that case, LTSP could set SDL_AUDIODRIVER=pulse, and everyone is satisfied again.
[07:04] <persia> Well, except it's a bit of a hack doing it that way.
[07:04] <persia> Yes, ALSA can route clients into pulse which then routes back into ALSA which then routes to ears.
[07:04] <persia> But it'd be cleaner if the apps talked to pulse directly.
[07:05] <alkisg> Right, the correct way would be for Ubuntu to use libsdl1.2debian-all, and for -all to use pulse if it's available, else fall back to alsa.
[07:06] <alkisg> So, 2 things need to be done: a small change in libsdl1.2debian dependencies, and a code fix in -all.
[07:06] <persia> Well, that's the least invasive way to do it.  I still think everything should use pulse :)
[07:08] <alkisg> In that case, libsdl1.2debian should me modified to depend on -pulseaudio first. But we proposed that already, and it looked like it wasn't going to happen (because of K|Xubuntu), at least in the Lucid time frame...
[07:08] <alkisg> https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/203158
[07:09] <persia> Right, but that requires testing/changes to phonon and xfce4-mixer
[07:09] <persia> If that work is done, then the bug can proceed.
[07:09] <persia> The detection code in libsdl1.2debian-all is just a workaround
[07:12] <alkisg> There were also complains from people not wanting to use pulseaudio at all... wouldn't libsdl1.2debian-all give them a way to do that?
[07:13] <persia> Well, yeah, but most of those complaints come from people who ran into bugs and blame pulse (even when pulse wasn't the cause)
[07:13] <persia> Mind you, I have a number of use cases where I *really* don't want pulse, but in those cases, I'm not using SDL audio anyway.
[07:15] <alkisg> I'm a pulseaudio fan myself, as I use LTSP a lot, but "preferring" pulse instead of "forcing" it seems better imo...
[07:15] <persia> I guess I see both as expressions of preference, but I agree forcing is wrong.
[07:16] <alkisg> Anyway, both of them would solve my problem. So I'll stop nagging people and wait for K|Xubuntu to be fixed so they are able to use pulseaudio before I start nagging again :D
[07:16] <alkisg> Thanks a lot persia for your time & advice :)
[07:16] <persia> alkisg: Well, if you're up for trying to do autodetection, that gives us a nice workaround.
[07:17] <persia> Alternately, if you're up for testing the xfce4-mixer pulse interaction, that should be in good shape, and strong feedback that it is (or bugs that the devs can fix) would probably sway Xubuntu.
[07:17] <persia> I know that upstream xfce4-mixer devs would like it to work properly, but don't have many user reports.
[07:18] <persia> I'm less knowledgeable about the situation with phonon: I think that is still a bit of a mess, because there's just so much needed to make a working backend.
[07:18] <persia> But I'd be glad to be wrong about that.
[07:18] <mneptok> ISP has been up and down all day. Reddit is down. just ate the last Kasugai gummy. life bites.
[07:18] <alkisg> I could give the autodetection thing a try. But for xfce4-mixer testing, as I never use Xubuntu, I wouldn't like to go ahead and report that "it works OK when ran from the live cd"... :)
[07:18] <dholbach> good morning
[07:20] <alkisg> Ah, a last argument for -all just came to me, that it would enable users with different needs to use different outputs even *on the same pc*
[07:21] <alkisg> (e.g. on a multiuser workstation or on some kind of a server where they don't have administrative rights)
[07:22] <alkisg> So user A logs on and wants pulse => OK, user b logs on and wants alsa => he just sets an environment variable.
[07:22] <persia> Well, OK, but let's analyse that.  esound and arts are deprecated.  pulse supplies many of the core nas features.  alsa was breaking stuff, and the latest OSS drivers aren't shipped by default.
[07:22] <ScottK> arts isn't just deprecated.  It's dead.
[07:23] <ScottK> We've removed it from the archive and upstream has closed the bug tracker.
[07:23] <persia> ScottK: I thought there was still support for KDE3 for some time (maintenance mode)
[07:23] <persia> Ah, then it's very dead.
[07:23] <ScottK> persia: There is, but not with arts.
[07:23] <persia> ScottK: Do you happen to know the current state of phonon & pulse?
[07:24] <ScottK> There were patches done to integrate them somewhat in KDE 4.4.  We have them in Lucid.
[07:24] <ScottK> I don't know the details.
[07:24] <persia> So it's just a matter of testing at this point, or should be?
[07:24] <ScottK> Should be.
[07:24] <ScottK> Kmix needs some work too and that's not complete.
[07:25] <ScottK> There is currently some back and forth about breaking feature freeze to squeeze that in.
[07:25] <ScottK> Mandriva (where the work is being done) will ship it as a distro patch if it doesn't go upstream for 4.4.
[07:25] <ScottK> We didn't consider it yet.
[07:25] <ScottK> Regardless, Kubuntu will not ship pulse in Lucid.
[07:25] <persia> That's colin guthrie's work?
[07:26] <ScottK> I don't recall.
[07:26] <ScottK> persia: Yes.
[07:26] <alkisg> ScottK: Kubuntu will work fine with libsdl1.2debian-all with no modifications, right?
[07:26] <ScottK> Current state of play: http://colin.guthr.ie/2010/01/mix-it-up/
[07:27] <alkisg> *would
[07:27] <ScottK> alkisg: I don't know.
[07:27] <ScottK> It's also 2:30 AM here, so anything I pretend to know, unless i give references, be skeptical.
[07:27] <alkisg> So, if Kubuntu won't ship pulse in Lucid, and if I test all derivatives to see if they work with -all, could we make the dependency switch?
[07:27] <persia> ScottK: Thanks for the references: this is looking promising (albeit for Lucid+1)
[07:28] <ScottK> alkisg: Didn't crimsun say that was just a workaround and the wrong way to go about it?
[07:28] <persia> alkisg: From -alsa to -all?  That should be easy enough, so long as -all is configured to be sane about which backend it chooses.
[07:28] <alkisg> ScottK: he said that for workstations, but when I mentioned that LTSP *needs* pulseaudio, I got the feeling that he accepted that.
[07:29] <alkisg> persia: yes.
[07:29] <ScottK> alkisg: When it comes to stuff like this, I'm personally going to go with what crimsun says.
[07:29] <ScottK> So get him to agree and I'm all for it then.
[07:30] <alkisg> OK, so /me writes down the steps he needs to make: (1) verify that all derivatives work with -all, (2) talk to crimsun about it, (3) [if everyone seems to agree] nag until the dependency is changed to -all first. :)
[07:31] <alkisg> Ah and (4) try to get -all to use pulse by default when it's available
[07:31] <ScottK> If you get 1 and 2 done, 3 will be easy.
[07:31] <persia> Well, except don't nag.  Just file a bug with the conclusions of your verifications and discussions.
[07:31] <persia> And make sure to have tasks for any packages that need modification.
[07:32] <alkisg> persia: sure, I was just kidding with that word. I don't go around nagging people... Sorry for my lack in English language.
[07:32] <persia> alkisg: No worries.  Just wanted to be clear for the logs :)
[07:32] <alkisg> :)
[08:14] <pitti> Good morning
[08:19] <joaopinto> Good morning
[08:25] <jjardon> hello, any recent change in GDM code? After today upgrade, GDM doesnt start
[08:25] <jjardon> (lucid here)
[08:35] <pitti> jjardon: gdm didn't change, but yesterday we got a lot of new gnome libs
[08:36] <jjardon> pitti, maybe that is the problem: I can see the "x" cursor, but GDM doesnt boot
[08:37] <pitti> jjardon: does it work if you boot with "text", log into a VT, and "sudo start gdm"?
[08:37] <ttx> cjwatson: there still is an issue with UEC installer not using the preseed file
[08:37] <pitti> (that's how I have to boot my machine these days)
[08:37] <ttx> cjwatson: https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/504157
[08:38] <ttx> cjwatson: wget.gnu seems to work ok now, so it comes from something else
[08:38] <jjardon> I can switch to a VT but sudo start gdm does nothing
[08:38] <cjwatson> ttx: I'll need the full syslog
[08:38] <ttx> ok, just a sec
[08:38] <cjwatson> ttx: ideally with DEBCONF_DEBUG=developer
[08:38] <seb128> pitti, I just joined but the changes from yesterday should not make a difference for login...
[08:38] <ttx> hm
[08:39] <ttx> cjwatson: where do I specify that ?
[08:41] <jjardon> pitti, any other idea? your machine works ok?
[08:41] <pitti> jjardon: yes (except for gdm starting too early)
[08:42] <ttx> cjwatson: existing installer syslog attached to the bug
[08:42] <ttx> cjwatson: looking into how to regenerate it with DEBCONF_DEBUG=developer
[08:45] <cjwatson> ttx: on the boot command line
[08:45] <ttx> cjwatson: I'm on it
[08:46] <jjardon> pitti, I'm going to restart and try some things. Wish me luck!
[08:52] <jjardon> weee, I'm very lucky! I've just executed locale-gen and now all works again
[08:52] <jjardon> strange
[08:54] <pitti> ah, yesterday's glibc broke all locales for some reason
[08:55] <pitti> I did locale-gen as well
[08:55] <pitti> but right after dist-upgrading
[09:04] <ttx> cjwatson: syslog with DEBCONF_DEBUG=developer uploaded to bug
[09:12] <davmor2> seb128: thanks for updating my rhythmbox bug.  Is there a better way of looking for bugs cause I looked it up before filing and couldn't find it :(  bug 503887 (for your info).  I'm assuming it down to the keywords you use etc
[09:12] <seb128> davmor2, you're welcome, I just looked for bugs with the name "icon"
[09:12] <seb128> sorting by most recent first...
[09:13] <seb128> there is not too many of those
[09:13] <davmor2> seb128: cool ta for the info :)
[09:17] <siretart`> since yesterday's dist-upgrade, I experience segfaults in gdm/X: http://paste.ubuntu.com/352787/ - Any idea what this could come from? is there perhaps some bug on this open already?
[09:18] <jmarsden> siretart`: The consensus is that the glibc update destroed all locales, and running locale-gen fixes things.  I think.
[09:18] <siretart`> let's try...
[09:19]  * alkisg is also having gdm problems, but locale-gen didn't solve them. startx works, though...
[09:20] <cjwatson> pitti: maybe the locale definition format changed?
[09:20] <siretart`> jmarsden: excellent hint, locale-gen regenerated *only* the german locales (6), the english ones where already up-to-date. thanks a bunch!
[09:20] <cjwatson> in which case the installer is going to need an update ...
[09:20] <jmarsden> siretart`: You're welcome.
[09:21] <cjwatson> ttx: hmm. could I see the preseed file as well, which it allegedly downloaded? something isn't adding up here
[09:24] <ttx> cjwatson: I can't find anything in /tmp/eucalyptus-udeb*, does it delete it after "successfully loading" it ?
[09:24] <cjwatson> ttx: I mean the one at the URL you cited
[09:25] <ttx> cjwatson: ah ok
[09:25] <cjwatson> yes, it deletes it
[09:25] <cjwatson> might be worth double-checking that this shows something sensible when run in the installer: wget.gnu -q --no-check-certificate -O - $url
[09:26] <cjwatson> from the syslog, it looks rather as if it downloaded an empty file
[09:27]  * alkisg has el_GR.UTF-8 as the system locale, and while locale-gen didn't solve his gdm problems, locale-gen --purge did
[09:28] <ttx> cjwatson: the command gets the right contents, let me pastebin what it gets
[09:30] <ttx> maybe $url is not what we think it is
[09:31] <cjwatson> I'll make it syslog the URL
[09:31] <ttx> preseed contents is http://people.canonical.com/~ttx/preseed.conf
[09:35] <cjwatson> ok, so it definitely didn't actually load that
[09:37] <ttx> cjwatson: I think I got it
[09:37] <ttx> clouds="$(euca_find_component cloud)"
[09:37] <ttx> cloud="${clouds#* }"
[09:37] <ttx> cloud_preseed "https://$cloud:8443/preseed/preseed.conf"
[09:38] <ttx> euca_find_component returns "CLC 192.168.0.151:8773"
[09:38] <cjwatson> so it does
[09:39] <ttx> and wget.gnu doesn't really mid trying to fetch from 192.168.0.151:8773:8443, apparently
[09:39] <cjwatson> willfix
[09:40] <ttx> cjwatson: assigning to you then. Some more logging could come in handy :)
[09:41] <cjwatson> already added :)
[09:41] <ttx> cjwatson: heh :)
[09:41] <cjwatson> node->cluster preseed fetching has a similar bug
[09:41] <cjwatson> actually no it doesn't
[09:42] <ttx> no, it works
[09:42] <cjwatson> ... yes it does. COFFEE
[09:42] <cjwatson> it has it in at least some modes, I'm pretty sure. The code is cognate
[09:42] <ttx> right but maybe :8773:8773 just works
[09:42] <cjwatson> oh, you're right, actually the cluster code never appends a port
[09:43] <ttx> the CLC+Walrus+CC+SC / NC topology works
[09:43] <ttx> those bugs come from my testing of CLC+Walrus / CC+SC / NC
[09:43] <ttx> Then more bugs might come from CLC / Walrus / CC / SC / NC :)
[09:44] <cjwatson> ttx: fix committed, want me to upload?
[09:44] <ttx> cjwatson: sure, I could use an ISO with that
[09:45] <ttx> I still haven't had time to get into your netboot magic
[09:45] <ttx> this week is crazy (I should get used to it)
[09:46] <cjwatson> gah, eucalyptus bzr is out of sync with the archive
[09:46] <ttx> beh
[09:46] <ttx> which branch ?
[09:46] <cjwatson> ~trout kirkland
[09:46] <ttx> arh
[09:46] <cjwatson> lp:~ubuntu-core-dev/eucalyptus/ubuntu
[09:47] <cjwatson> kirkland: use 'bzr bind' and then you won't forget to push ...
[09:48] <cjwatson> ttx: should I wait for kirkland to get back and merge whatever he has locally?
[09:48] <cjwatson> bzr is missing:
[09:48] <ttx> cjwatson: he uploaded to archive what he had locally, so in theory we could reapply it to branch
[09:48] <cjwatson> +  * debian/control, debian/eucalyptus-nc.upstart: (LP: #446036, #452572)
[09:48] <cjwatson> +    - add a versioned depends for eucalyptus-nc on a new version
[09:48] <cjwatson> +      of libvirt-bin that starts using upstart
[09:48] <cjwatson> +    - start eucalyptus-nc on started libvirt-bin
[09:49] <cjwatson> yes, if you'd like me to do that, I can
[09:49] <ttx> cjwatson: if you don't mind, I really could use those hours before he wakes up for more testing
[09:49] <ogra> can some archive admin let the uboot-imx binary out of NEW (it changed the binary name to -to3 from -to2 with teh new upstream)
[09:51]  * ttx tries netboot magic in the mean time
[09:57] <pitti> argh
[09:58] <smb> pitti, irc went mad for you, to?
[09:58] <pitti> doko__: does the new glibc disable that ipv6 patch again? my internet connection sucks, and now I found out that apparently that DNS bug is back
[09:58]  * pitti puts back the old workaround
[10:01] <pitti> aah, sanity again
[10:17] <cjwatson> it always scares me when I accidentally type 'bzr di' in (say) a git branch AND IT WORKS ANYWAY
[10:18] <pitti> oh, you got bzr-git working?
[10:20] <cjwatson> pitti: it worked for basic working tree stuff well before you could use it to branch
[11:03] <slangasek> doko__: why has my en_US.UTF-8 locale broken on eglibc upgrade?
[11:26] <doko__> pitti: it's still enabled
[11:27] <doko__> slangasek: didn't see that, how is this broken?
[11:28] <slangasek> doko__: bug #504198
[11:28] <slangasek> caused at least one maintainer script crash on upgrade
[11:33] <pitti> slangasek: in gnome-menus?
[11:33] <pitti> (I fixed that this morning)
[11:34] <seb128> well fixing the crash doesn't fix the fact that locales are broken
[11:34] <seb128> ie everything is in english
[11:34] <pitti> of course
[11:34] <slangasek> pitti: yes
[11:35] <pitti> at least libc6's script should call locale-gen to rebuild them
[11:35] <seb128> that's not enough to fix the locale there
[11:35] <slangasek> I don't think missing locales are the problem, it looks to me like glibc is getting the path lookup wrong
[11:36] <slangasek> or at least, when it finds /usr/lib/locale/en_US.utf8/LC_CTYPE, it decides it's no good and keeps looking
[11:36] <Laney> caused a software-center maintainer script crash for me
[11:36] <seb128> pitti, I did run locale-gen and it says fr_FR.UTF-8 is still up-to-date but I get warnings on running gtk applications saying the locale is no supported by the C library...
[11:37] <pitti> hm, I did that, and a reboot, and everything is working again
[11:37] <seb128> not there
[11:38] <pitti> oh, "up-to-date"? that's wrong
[11:38] <pitti> it should regenerate it
[11:38] <seb128> I think it did on the first run
[11:38] <seb128> now it says that
[11:38] <pitti> sudo locale-gen --purge
[11:38] <seb128> no hurry it's the mini config
[11:38] <seb128> I use it only for bootchart
[11:39] <seb128> I will let the system in state to verify that the fix work when there will be one
[11:40] <slangasek> ah; so indeed, locale-gen regenerates my non-English locales with success
[11:40] <slangasek> but says the English ones are up-to-date
[11:57] <doko__> slangasek: is locale-gen --purge just enough to fix the problem?
[11:57] <slangasek> doko__: yes
[11:59] <ior3k> hey, I'm sorry to be asking questions here, but there doesn't seem to be anyone around on #ubuntu+1
[11:59] <ior3k> my keyboard stopped working with X
[11:59] <ior3k> since yesterday
[11:59] <ior3k> can anyone give me some pointers on how I can fix it?
[11:59] <ior3k> this is lucid, btw
[12:01] <siretart`> slangasek: I can confirm your observations, only my non-english locales were regenerated. - however, the effects were more grave: it made gdm and X segfault on the next reboot.
[12:02] <slangasek> oh, I haven't gone so far as to reboot yet :/
[12:03] <siretart`> that was fun. espc since the segfault is pretty unobviously hidden in /var/log/syslog
[12:34] <ttx> pitti, cjwatson, slangasek: I could use a server CD respin to test the eucalyptus 1.6.2~bzr1120-0ubuntu5
[12:34] <pitti> ttx, cjwatson, slangasek: triggering
[12:34] <slangasek> ok
[12:35]  * ttx needs a local archive mirror to use netboot in a satisfying way :)
[12:54] <ion> It seems hal is back in the default desktop.
[12:54] <ion> ubuntu-desktop recommends pitivi, pitivi recommends hal.
[12:55] <highvoltage> it doesn't want to die
[13:03] <tjaalton> running apt-get install --fix-policy wants to remove grub-pc and replace it with the old one..
[13:03] <tjaalton> among other scary things
[13:06] <slangasek> --fix-policy?
[13:08] <slangasek> pitti: ^^ who can look at fixing pitivi's recommends on hal?
[13:09] <pitti> slangasek: I discussed that with upstream, but it's not trivial; pitivi is in python, and there are no python gudev bindings yet (and probably won't be), and the python gobject-introspection support still needs to land
[13:09] <pitti> slangasek: but I changed hal to not start on boot, but on demand (dbus activation)
[13:09] <pitti> so it's not reintroduced into the boot path
[13:10] <sebner> pitti: beside other breakage, is xorg broken? Seeing this in lucid: http://pastebin.com/m3cc1d9d5
[13:10] <pitti> in fact I always feared that we had to do that anyway to not break brightness settings for hardware without xbacklight
[13:11] <pitti> sebner: bug 504198
[13:11] <sebner> pitti: ohhh, my hero :D
[13:11] <slangasek> pitti: ok, ack
[13:12] <sebner> slangasek: do I need to do a X restart after locale-gen --purge ?
[13:13] <pitti> ion: there's an upstream bug for pitivi, FYI
[13:13] <slangasek> sebner: shouldn't be?
[13:13] <tjaalton> slangasek: to install all recommends
[13:13] <pitti> ion: https://bugzilla.gnome.org/show_bug.cgi?id=605920
[13:14] <sebner> slangasek: I'll try xserver reboot because your "workaround" doesn't fix it for now
[13:14] <tjaalton> seems to be undocumented though
[13:14] <slangasek> tjaalton: hmm, indeed
[13:15] <sebner> slangasek: ahh, sudo ;)
[13:15] <slangasek> sebner: hem, yes... :)
[13:16] <sebner> slangasek: wondering why xserver reconfig isn't working but at least the warnings are gone ^^
[13:16] <sebner> slangasek: any chance you use nvidia-glx?
[13:17] <tjaalton> reconfig? it's been removed
[13:17] <tjaalton> there is no xorg.conf anymore (by default=
[13:17] <tjaalton> )
[13:18] <sebner> tjaalton: ahh, right, just need it for haXX0ring the nvidia driver evidently (which is now broken for me)
[13:18] <slangasek> tjaalton: I don't see anything in lucid with wrong Recommends on grub; sounds to me like the undocumented option is broken...
[13:18] <slangasek> sebner: nvidia-glx> not at all
[13:18] <sebner> slangasek: kk, thx anyways
[13:19] <tjaalton> slangasek: it's probably something recommending grub, and it conflicts with grub-pc
[13:19] <slangasek> tjaalton: nothing in lucid recommends grub
[13:19] <tjaalton> slangasek: huh, ok then :)
[13:19] <slangasek> everything correctly recommends grub-pc | grub
[13:20] <tjaalton> mvo: ^^
[13:33] <mvo> tjaalton: hello, could you please add "-o Debug::pkgDepCache::AutoInstall=true -o Debug::pkgProblemResolver=true" and send me the output?
[13:33] <mvo> tjaalton: btw, it looks like my xorg patch is in the xorg-devel moderation queue
[13:33] <ttx> cjwatson: CC/SC picks up CLC preseed perfectly now, thanks !
[13:37] <ion> !summon Keybuk
[13:40] <cjwatson> ttx: excellent
[13:42] <sebnerr> ok xserver really looks b0rken, nv segfaults X (gdm starts, black screen but mouse is visible, also loginable) and nvidia-glx wants to remove the entire X stack :(
[13:43] <sebnerr> tjaalton: now I can't use vesa because I removed my xorg.conf :P
[13:44] <tjaalton> sebnerr: yes, nv is broken but mvo has fixed it partially (rest is on the way) :)
[13:44] <tjaalton> and tseliot has a ppa for the blob
[13:44] <tjaalton> mvo: ahah, got the error.."Installing grub as Recommends of linux-image-2.6.30-5-generic" :P
[13:45] <mvo> sebnerr: if you try https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/494627 that would be helpful
[13:45] <tjaalton> mvo: I'll ask people to push it through the queue
[13:45] <mvo> many thanks tjaalton
[13:46] <tjaalton> mvo: thanks for letting me see the error :)
[13:46]  * tjaalton runs the cleanup app
[13:47] <tjaalton> mvo: when did you send the patch?
[13:47] <tjaalton> to the list
[13:47] <mvo> tjaalton: yesterday in the afternoon, I can give you the exact time, give me a sec
[13:48] <mvo> tjaalton: Message-ID: <20100106135338.GL2603@tas>
[13:48] <tjaalton> mvo: it's on the list
[13:48] <mvo> tjaalton: Date: Wed, 6 Jan 2010 14:53:38 +0100
[13:48] <mvo> tjaalton: oh, cool
[13:48] <tjaalton> jcristau accepted it
[13:48] <mvo> tjaalton: sorry for the noise then
[13:48] <mvo> sweet
[13:48] <tjaalton> no replies yet ;)
[13:48] <dholbach> ion: do you have a link to your bug report or patch for mountall again?
[13:49] <sebner> mvo: ohhhhhhhh, testbuilding xserver? Sure I'll try :D /me removed -nv btw to let vesa start  somehow ^^
[13:50] <tjaalton> hmm computer-janitor crashes, need to clean up manually
[13:50] <tjaalton> sweet, a kernel crash
[13:50] <dholbach> ion: nevermind, found it - I think I'll try it out and build a package for myself locally
[13:51] <dholbach> the machine just restarted itself again :/
[13:52]  * dholbach summons Keybuk too
[13:53] <ion> dholbach: Here’s the merge request, https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868
[13:53] <dholbach> thanks
[13:54] <sebner> mvo: please fiXX0r your patch. you are patching xserver-xorg where apt-get source xserver-xorg which fetches xorg
[13:55] <dholbach> ion: I'll let you know how it works for me
[13:55] <tjaalton> sebner: hmm? the source for xserver is xorg-server
[13:56] <sebner> tjaalton: me gets xorg-7.5~3ubuntu4
[13:56] <ion> dholbach: Aye
[13:56] <tjaalton> sebner: apt-get source xorg-server or xserver-xorg-core
[13:56] <sebner> oho!
[13:56] <sebner> mvo: sorry false alarm ;)
[13:56] <sebner> tjaalton: thx
[13:56] <slangasek> ccheney: is it possible for openoffice to be rebuilt against libicu42 in advance of alpha-2?
[13:57] <slangasek> ccheney: should kick a 7MB .deb off the alternate and make me happy again :)
[13:58] <doko__> ccheney: if you rebuild, please apply the visibility patch for arm
[14:01] <sebner> mvo: unstable should be lucid btw
[14:02] <zul> doko__: ping
[14:02] <doko__> zul: just ask/write
[14:03] <mvo> sebner: indeed
[14:03] <zul> doko_: can you review those python-pastescript and python-pastebin MIR?
[14:04] <doko__> ok
[14:06] <sebner> mvo: haven't seen any blob by tseliot yet, still work in progress or anything to test already (besides installing upstream driver manually)
[14:08] <tseliot> sebner: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements (still WIP)
[14:10] <sebner> tseliot: uhhh, mighty tseliot :) I'll test (190 driver)
[14:10] <tjaalton> could someone remove libxcb from the sync blacklist, if there is such
[14:10]  * sebner fiXX0rs his xserver first
[14:11] <sebner> tseliot: what do you think about mvo's xserver patch?
[14:11] <tjaalton> libxcb still isn't autosynced, though lp support debsrc3.0
[14:11] <tjaalton> supports
[14:12] <tseliot> sebner: what patch?
[14:12] <pitti> tjaalton: looking
[14:12] <pitti> tjaalton: it's not blacklisted
[14:12] <tjaalton> pitti: thanks
[14:12] <sebner> tseliot: fiXX0r broken nv/xserver https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/494627
[14:13] <slangasek> pitti: do you think the cryptsetup SRU could be published, or is there more verification you'd like to see there first?  I think the lack of screams that we broke the world is a positive sign...
[14:13] <tjaalton> pitti: ok, bug 503290 then :)
[14:15] <pitti> tjaalton: done
[14:15] <tjaalton> pitti: great, thanks
[14:21] <sebner> mvo: Is this a problem to have the "fixed" xserver + the "fixed" nv installed because in the bug report it's the best to revert your nv fix
[14:22] <mvo> sebner: without the revert for the initial fix I get funny colors
[14:22] <sebner> mvo: so I downgrade nv then
[14:22] <mvo> sebner: do you get funny colors with the latest nv?
[14:22] <sebner> mvo: didn't restart yet
[14:22] <mvo> ok
[14:23] <tjaalton> mvo: but the -nv change is already upstream, you mean it should be reverted?
[14:23] <sebner> mvo: /me tries now
[14:23] <tseliot> sebner: the patch looks good but I'm not very familiar with the nv driver
[14:26] <soren> I'm having all sorts of locale related problems today. Does that sound familiar to anyone?
[14:26] <tjaalton> yes, run locale-gen --purge
[14:27] <mvo> tjaalton: I'm not sure, but it sounds to me like it should be, unless they are working on gamma_set anyway already
[14:27] <mvo> tjaalton: for me 2.1.15+patched xserver works without a hitch since yesterday
[14:28] <mvo> tjaalton: but again, I do not know enough about X direction to properly judge, if the old-style colormap code gets depercated (no idea if it is nor not) then it might be the time to do the color dac programming in gamma_set
[14:28] <mvo> upstream will know :)
[14:28] <tjaalton> mvo: yeah
[14:29]  * mvo just wanted a working X :
[14:29] <mvo> :)
[14:29] <tjaalton> don't we all *sigh* :)
[14:30] <sebner> mvo: my screen was still blank but downgrading to the old -nv fixed the issue for me
[14:30] <sebner> tseliot: I'll try nvidia blob now
[14:31] <mvo> lol@tjaalton
[14:32] <sebner> soren: + sudo ;)
[14:33] <soren> sebner: Yeah, I guessed :)
[14:33] <sebner> soren: I didn't at the first try *cough*
[14:34] <tseliot> is it just me or tabs in nautilus are at the bottom in Lucid?
[14:34] <sebner> hahaha
[14:34] <sebner> tseliot: here too
[14:35] <tseliot> :-/
[14:36] <sebner> tseliot: :/ http://pastebin.com/m68641479
[14:37] <seb128> tseliot, it's a design choice
[14:37] <mvo> upstream?
[14:37] <seb128> yes
[14:37] <sebner> seb128: a really bad one tbh
[14:37] <seb128> why?
[14:38] <seb128> it's not to have everything at the same location
[14:38] <sebner> seb128: longer way imho
[14:38] <tseliot> I assume this is only in nautilus
[14:38] <seb128> toolbar, pathbar, tab
[14:38] <soren> sebner: I fixed that by running "apt-get dist-upgrade" again.
[14:38] <soren> sebner: (the stuff you pastebin'ed)
[14:38] <sebner> seb128: I (and I suppose most) didn't have a problem with it
[14:38]  * sebner tries
[14:38] <sebner> gnahahh
[14:38] <sebner> installs b0rken nv
[14:38] <sebner> :P
[14:39] <seb128> there was no split view mode by then though
[14:39] <tseliot> sebner: you should have updated your system with my PPA first
[14:39] <sebner> seb128: is there still a discussion or will be see it in the final too
[14:40] <sebner> tseliot: I guess it's because of the fiXX0red Xserver
[14:40] <sebner> soren: not working :(
[14:41]  * sebner runs sudo apt-get remove xserver-xorg
[14:41] <sebner> xD
[14:41] <kirkland> cjwatson: thanks, i didn't know about 'bzr bind'
[14:41] <tseliot> sebner: I meant, apt-get dist-upgrade instead of installing nvidia directly
[14:42] <kirkland> ttx: sorry about that
[14:42] <soren> sebner: That driver doesn't work, or the package still doesn't install?
[14:42] <sebner> tseliot: I had the old driver removed anyways
[14:42] <ttx> kirkland: you owe cjwatson a beer ;)
[14:42] <sebner> soren: package but I'll try something out
[14:42] <kirkland> ttx: probably several, in fact ;-)
[14:43]  * sebner reboots
[14:45] <cjwatson> kirkland: (it's like bzr checkout but you can do it after branching without having to build the branch again from scratch)
[14:45] <kirkland> cjwatson: that's really, really cool
[14:46] <slangasek> didrocks: how is https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-une coming along?
[14:47] <sebner> mvo: funnily I had strange colours with new nv and tseliot xserver
[14:47] <pitti> slangasek: I think the only thing left is to add transitional packages to the new ubuntu-netbook{,-default-settings} packages (for the former -remix) name, and remove the old packages
[14:48] <sebner> tseliot: nvidia blob installed and working but only ~1000 frames/s instead of 15000
[14:48] <slangasek> pitti: ok, cool
[14:48] <slangasek> pitti: just wanting to make sure that since this is for alpha-2, it lands this week, not next :)
[14:48] <tseliot> sebner: my xserver contains only changes in the packaging scripts (no code change whatsoever)
[14:48] <tseliot> sebner: what does "glxinfo | grep direct" say?
[14:49] <pitti> slangasek: yeah, would be nice indeed; StevenK was working on that last, will ping him again (or help out)
[14:49] <sebner> tseliot: direct rendering: Yes
[14:49] <tseliot> sebner: really? Can I have a look at your /var/log/Xorg.0.log?
[14:50] <sebner> tseliot: http://pastebin.com/m67df35b5
[14:51] <sebner> tseliot: btw, I had to use nvida-xconfig else nv would start
[14:52] <tseliot> sebner: glx seems to be broken. Restart your computer or it won't work
[14:52] <tseliot> restarting X is not enough with the new system
[14:52] <sebner> tseliot: I restarted the laptop ;)
[14:53]  * sebner gives it another try anyways
[14:53] <tseliot> it says that it failed to initialize the GLX module
[14:54] <sebner> tseliot: same result
[14:54] <StevenK> pitti: I think that's done, but I'd welcome the second set of eyes to see if I've missed anything.
[14:55] <pitti> StevenK: awesome
[14:55] <StevenK> pitti: Er, rather, all that remains to be done is remove u-n-r-d-s from lucid
[14:55] <tseliot> sebner: let's discuss this in #ubuntu-x
[14:55] <pitti> StevenK: was unr-meta superseded as well?
[14:56] <pitti> ah, netbook-meta, nevermind
[14:57] <pitti> StevenK: ubuntu-netbook-default-settings still needs to build a transitional ubuntu-netbook-remix-default-settings package AFAICS
[14:58] <pitti> StevenK: likewise, netbook-meta (or something else) needs to build a transitional ubuntu-netbook-remix package
[14:58] <pitti> and ubuntu-netbook needs to C/R/P: ubuntu-netbook-remix
[15:00] <slangasek> mvo: bug #494627> hmm, when will that be uploaded?  that looks an awful lot like my periodic X-segfault-on-lid-close problem here w/ intel, I'd love to check :)
[15:01] <sebner> slangasek: you need a reverted -nv too though
[15:01] <slangasek> no, I don't
[15:02] <sebner> slangasek: creates funny colours for mvo and me
[15:02] <mvo> slangasek: I was waiting for upstream on this, but tjaalton said he now merged it
[15:02] <mvo> sebner: I just uploaded a reverted -nv
[15:02] <sebner> mvo: \o/
[15:04] <tjaalton> I need to fix my laptop first, though
[15:04] <tjaalton> something is killing gdm on boot, dropping it in failsafe which doesn't work at all when kms is used
[15:05] <StevenK> pitti: Notes taken, I'll upload them both (and remove u-n-r-d-s) later today
[15:05] <pitti> StevenK: thanks muchly
[15:06] <pitti> StevenK: unr-meta should be removed as well, right?
[15:06] <StevenK> pitti: I thought it already had been, but I'll check it too and bin it too
[15:08] <tseliot> ara: I think we found out what your problem with nvidia was
[15:09] <ara> tseliot, nice! what was it?
[15:10] <tseliot> ara: it looks like X tries to load the wrong glx binary which is in a sub-directory instead of the right one (which is a link)
[15:11] <tseliot> ara: you can move /usr/lib/xorg/modules/extensions/standard/libglx.so out of the way and restart or wait for my fix
[15:12] <ara> tseliot, I'll wait for the fix, so I can verify that the new PPA actually fixes it, thanks :)
[15:12] <tseliot> thanks for testing :-)
[15:14] <sebner> tseliot: /me waits too :)
[15:15] <tseliot> good
[15:21] <sbalneav> mvo: I think I cracked Bug #501559 last night.  Have a look at the second patch I attached.  forkpty isn't enabled, and it works for me in all the use cases I could test, including enabling tty_tickets in sudo.
[15:24] <mvo> sbalneav: cool, I have a look
[15:25] <sbalneav> I think there was a "logic error" in the way things were being attempted in the "no forkpty" case.
[15:30] <mvo> sbalneav: thanks, I have a look now, may take a little bit as the #ifdef logic in the code tends to confuse me :)
[15:31] <ccheney> doko__: location of patch?
[15:32] <doko__> ccheney: in your inbox since October
[15:33] <ccheney> doko__: ah ok
[15:37] <barry> doko__: ping
[15:37] <doko__> barry: pong
[15:38] <barry> doko__: hi!  say, did you know that distribute (the setuptools replace) supports automatic 2to3 invocation at install time?
[15:39] <tseliot> my PPA build of the xserver will start in 4 hours... :-(
[15:40] <Laney> tseliot: smile sweetly for a rescore ;)
[15:40] <tseliot> :-D
[15:40] <tseliot> too much?
[15:40] <sebner> tseliot: nvidia blob rebuild! :P
[15:40] <doko__> barry: yes
[15:40] <tseliot> sebner: nope just X
[15:41] <sebner> tseliot: that enough?
[15:41] <tseliot> yep
[15:41] <sebner> tseliot: cool :D don't forget to smile bright *cough*
[15:42]  * tseliot smiles sweetly to pitti
[15:42] <tseliot> :-P
[15:42] <sebner> tseliot: even better, I testbuild it locally! :P
[15:43] <tseliot> sebner: I can but I don't have an nvidia card in my testing box and I can't unplug it from my main pc right now
[15:43] <sebner> tseliot: np, I'm testbuilding it locally right now ^^
[15:44] <tseliot> sebner: ah, thanks
[15:44] <sebner> tseliot: Do I have to reinstall nvidia current or just setting up xserver and reboot?
[15:45] <barry> doko__: i didn't know before yesterday, but that is *really* cool
[15:45] <tseliot> sebner: the latter should be enough
[15:45] <doko__> barry: yes, it eases packaging
[15:45] <sebner> tseliot: aye, I'll tell you the result then :)
[15:46] <tseliot> ok
[15:47] <pitti> smb: sorry, rescore what?
[15:48] <barry> doko__: so if a python package uses distribute, and is python 3 clean (i.e. works after 2to3), a packager doesn't need to do anything special to package it for both py2 and py3 on ubuntu?
[15:48] <smb> pitti, Uh, did I say something here lately?
[15:48] <pitti> smb: nevermind me
[15:49] <pitti> tseliot: sorry, rescore what?
[15:49] <barry> doko__: i'm actually trying to do this today, so i guess i'll find out :)
[15:49] <tseliot> pitti: we were joking about the fact that my xserver build in my ppa will start in 4 hours
[15:50] <doko__> barry: no, you still want to have two binary packages
[15:50] <pitti> tseliot: if that's urgent for testing, I can bump it; URL?
[15:50] <barry> doko__: that makes sense
[15:51] <tseliot> pitti: the sooner we test the sooner I can start uploading things in Ubuntu: https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+packages
[15:51] <tseliot> pitti: xorg-server
[15:52] <pitti> tseliot: amd64 building, i386 bumped
[15:53] <tseliot> pitti: thanks a lot
[16:13] <kees> james_w: hi! my memory sucks, which was the oid package that you had examined and was using the less secure protocols?
[16:13] <james_w> python-oauth
[16:13] <james_w> oauth no oid
[16:16] <kees> oauth! yes, that's why I could find it in my mail
[16:16] <kees> james_w: by any chance have you looked at python-openid?
[16:17] <james_w> I have
[16:18] <james_w> I had more confidence in the implementation, but that may have just been because there was more code :-)
[16:18] <kees> hah
[16:20] <ccheney> slangasek: it looks like all i have to do to get it to use the new libicu is rebuild without changes, does that sound correct? libicu-dev seems to be for libicu42 now
[16:20] <slangasek> ccheney: AFAIK, yes
[16:20] <ccheney> slangasek: ok thanks :)
[16:20]  * ccheney is doing a test build then will add doko's patch and get it uploaded
[16:24] <sebner> tseliot: anything I need to mind after installing -21?
[16:25] <tseliot> sebner: no, just make log with the nvidia-bug-report command
[16:25] <sebner> tseliot: I thought it should work then ^^
[16:26] <tseliot> sebner: yes, it should work but I just want to be sure that everything's ok
[16:26] <sebner> sure :)
[16:29] <slangasek> zul: were you taking care of seeding irqbalance and tickcount?
[16:30] <zul> yes
[16:30] <slangasek> ok
[16:31] <zul> slangasek: problem?
[16:31] <slangasek> zul: on the alpha-2 bug list, no action since before the holidays, so just checking that it's on someone's radar :)
[16:31] <zul> slangasek: oh yeah its on my radar :)
[16:31] <didrocks> slangasek: about UNE renamining, StevenK was the assignee. I guess it was changed to myself as I'll start next week.
[16:32] <slangasek> didrocks: ah; they assigned you a spec with a deadline before your start date, not nice :)
[16:32] <didrocks> slangasek: not really a pb. I think it'll be quickly done ;)
[16:32]  * ccheney forgot he has to update the build system for lucid too
[16:33] <didrocks> pitti: you spoke about it with StevenK yesterday I guess, do you know what's the status?
[16:34] <pitti> didrocks: Steve and I went through the remaining renaming bits, he'll do them today/tomorrow
[16:34] <pitti> didrocks: bonjour
[16:35] <didrocks> hey pitti ;)
[16:36] <pitti> didrocks: got my /query ?
[16:37] <didrocks> pitti: yeah, one sec. A lot of stuff to read (back to paris) :)
[16:44] <zul> slangasek: what do you think of installing irqbalance by default for everyone?
[16:45] <slangasek> zul: I think that question should be put to a larger audience; my own reaction is "new daemon - ick, no"
[16:46] <zul> slangasek: ok ill fire off an email to ubuntu-devel
[16:49] <mathiaz> kees: hi! During the discussion about pkg demotion, you mentionned that both logcheck and logwatch should be demoted to universe. What's the rationale?
[16:50] <kees> mathiaz: is that what I said?  I think I meant "one should be demoted if they do the same thing".  As it turns out, they don't do the same thing, so I'm okay with them staying in main.
[16:54] <mathiaz> kees: ah ok - I thought you said that both should belong to universe
[16:54] <mathiaz> kees: sorry for that
[16:54] <kees> mathiaz: I don't mind less stuff in main.  :)
[16:55] <mathiaz> kees: and then there is the ongoing discussion on ipsec
[16:55] <mathiaz> kees: IMO we should support an IPSEC stack in main
[16:55] <mathiaz> kees: as it's used in corportate environements
[16:55] <mathiaz> kees: and openvpn doesn't cover all use cases
[16:55] <kees> I'm on the fence.  my ubuntu-user hat says "keep ipsec", and my security hat says "I've done updates on it! out out!"  ;)
[16:56] <mathiaz> kees: understood
[16:56] <mathiaz> kees: the issue here is the ipsec-tools package
[16:56] <mathiaz> kees: another solution is isakmpd
[16:56] <ttx> kees: I know what color is your security hat, but what color is your ubuntu-user hat ? brown ?
[16:57] <jdstrand> I pick logcheck as supported
[16:57] <jdstrand> (I use that one ;)
[16:57] <zul> jdstrand: done! boot the other out ;)
[16:58] <jdstrand> :)
[16:58] <mathiaz> kees: and for redhat-cluster-suite, we'll wait for the result of ivoks testing of the new cluster components (pacemaker, etc...)
[16:59]  * kees nods
[17:13] <tjaalton> doko__: you added a dep on xauth to xvfb, although it had been dropped right after jaunty opened
[17:13] <tjaalton> doko__: and the failure log didn't have anything related to xauth
[17:16] <kees> mathiaz: let's leave ipsec-tools in main for now.
[17:21] <doko__> tjaalton: well, an xvfb-run true doesn't succeed for me without having xauth installed
[17:22] <tjaalton> doko__: how come it took a year to find out?-)
[17:22] <mvo> sbalneav: I attached a new diff (very small) could you please have a quick look/test ? it works in my tests and is whatthe original gksu in karmic did
[17:24] <seb128> tjaalton, it didn't, we had this discussion before, where "we" might not be you for xorg
[17:24] <seb128> tjaalton, we had to add xauth build-depends to several packages
[17:24] <tjaalton> seb128: ok
[17:25] <tjaalton> I won't touch it again then ;)
[17:25] <seb128> well if we added the xauth build-depends that's probably because there was good reason to drop if from xvfb
[17:26] <seb128> I would say doko's change should be undone and build-depends should be added to whatever he tried to build
[17:26] <tjaalton> seb128: it's a Recommends anyway
[17:26] <tjaalton> in debian
[17:31] <mathiaz> bdmurray: hi!
[17:32] <bdmurray> mathiaz: hello
[17:32] <mathiaz> bdmurray: I'm going through the ubuntu-main-sponsorship queue - bug 62529 has patch attach to it
[17:33] <mathiaz> bdmurray: 1. the patch is not a proper debdiff and 2. the package is maintained in bzr
[17:33] <mathiaz> bdmurray: is there a standard reply to cover that use case?
[17:34] <bdmurray> mathiaz: no there isn't
[17:34] <mathiaz> bdmurray: ok - I'll write something up then
[17:37] <sbalneav> mvo: ok, one sec:
[17:39] <genii> With upstart, is the tool to replace update-rc.d now initctl ?
[17:41] <sbalneav> mvo: I'll give it a try tonight.  Unfortunately, I'm on my day job, and the lucid box is at home.
[17:41] <sbalneav> mvo: I'll update the bug with my findings thisevening.  Thanks for working on this with me.  Sabayon's important for a lot of teachers, and they'll appreciate the work.
[17:42] <mathiaz> bdmurray: how about that: http://paste.ubuntu.com/353029/
[17:43] <bdmurray> mathiaz: The reply reads fine but that patch has been languishing for 4 months as it is...
[17:44] <mathiaz> bdmurray: oh well - I can't really commant on the patch itself - I'm just trying to move things forward and get the sponsorship queue cleaned up
[17:44] <mathiaz> bdmurray: as of now the patch is not in a good format - that's the best I can do in my position
[17:46] <bdmurray> mathiaz: ah, okay then but isn't there somebody else on that sponsorship team who might be able to comment on the patch itself?  Removing it from the queue because it isn't perfectly formatted seems like a way to lose the patch to me.
[17:47] <mathiaz> bdmurray: hm... right
[17:47] <mathiaz> bdmurray: so may be I shouldn't unsubsribe the sponsor team then
[17:48] <mathiaz> bdmurray: just leave a comment on how to move things forward
[17:48] <bdmurray> mathiaz: that seems best to me
[17:51] <kees> cjwatson: quick check, did the installer ever grow the logic to do a "service apparmor reload" in the final stages of install to generate the profile cache?
[17:51] <Pici> 22
[17:52] <cjwatson> kees: not AFAI
[17:53] <cjwatson> K
[17:55] <kees> cjwatson: ok, should I bug you or ev about that?  just needs a quick "/etc/init.d/apparmor reload; /etc/init.d/apparmor stop" near the end of the install.
[17:56] <cjwatson> kees: probably ev given how my week's been ...
[17:56] <kees> cjwatson: cool
[17:57] <mdz> has anyone else seen this on lucid:
[17:57] <mdz> [113006.639028] cron[5446]: segfault at 0 ip (null) sp 00007fffabb9dec8 error 14 in cron[400000+9000]
[17:57] <mdz> [113006.639065] Process 5446(cron) has RLIMIT_CORE set to 0
[17:57] <mdz> [113006.639070] Aborting core
[17:57] <kees> mdz: known, in progress
[17:57] <mdz> there are three of those in my dmesg today
[17:57] <mdz> kees, ok, thanks
[17:57] <kees> (well, not the cron crash, but the rlimit_core issue)
[17:58] <kees> mdz: rlimit_core is bug 498525.  haven't seen the cron crash, though.
[18:03] <ev> kees: added to my todo list for tomorrow
[18:03] <Shiran> anyone know how can i turn .po file to .qm file?
[18:04] <kees> ev: ok, thanks!
[18:04] <mdz> kees, thanks. I'm more concerned about the cron crash then
[18:04] <kees> mdz: yeah
[18:04] <mdz> kees, oddly, cron is running fine and has been for several days:
[18:05] <mdz> “Fine,” you say, “but I have software to deliver, budgets to stay within, schedules to meet.” Indeed you do. But here’s the thing – either your system is capable of delivering those results or it is not. Trying to force results beyond what your development system is capable of not going to get you where you need to be. You are not going to improve your system by stressing it to achieve aggressive targets. Systems don’t work that way. You
[18:05] <mdz> may get a local or temporary optimization, but you will not get a system capable of delivering high quality software reliably, repeatedly on time.
[18:05] <mdz> So how do you get results? You start by making sure that work is structured so that it is a system – one that gives knowledge workers visibility into the needs and expectations of your customers. Then you focus on developing the technical capability of the system and of the people developing your products. You structure your delivery system so that workflows are steady and predictable. Finally, you develop workers who accept the challenge to continuo
[18:05] <mdz> ack, sorry about the flood
[18:07]  * mdz pummels inconsistent X clipboard / app shortcut semantics
[18:07] <mathiaz> kees: jdstrand: what's your advise on bug 194472? Should there be visual feedback when you type your password for sudo?
[18:07] <mathiaz> mdeslaur: ^^?
[18:07] <mdz> kees, do you know of any time when /usr/sbin/cron is started other than from the init script?
[18:08] <ion> mathiaz: Rather remove the visual feedback from gksudo et al. instead. :-P
[18:08] <kees> mdz: forking for running subprocesses?
[18:08] <mdz> kees, hmm, yes
[18:08] <jdstrand> mathiaz: imo it is not worth diverging from upstream for that. if they want to take a patch, then fine, but good luck with that ;)
[18:08] <kees> mathiaz: well, there never has been for sudo.  that's a common and long-standing "feature" in *nix
[18:09] <mathiaz> ion: well yes may be. First we should decide wether giving visual feedback when typing a password is recommended or not
[18:09] <mdeslaur> mathiaz: how is that a papercut?
[18:09] <mdz> it's happening at *:17 when cron.hourly runs
[18:09] <mathiaz> jdstrand: well - upstream has an option as of 1.7.1
[18:09] <mathiaz> jdstrand: so it can easily be enabed
[18:09] <kees> mdz: weird, cron hasn't changed.  perhaps the new eglibc ?
[18:10] <jdstrand> mathiaz: then I have no opinion, other than to say that shoulders surfers can figure out how many characters the password is
[18:10] <mathiaz> jdstrand: 1.7.1: A new Defaults option "pwfeedback" will cause sudo to provide visual feedback when the user is entering a password.
[18:10] <ion> mathiaz: Some visual feedback an attacker may not use to determine the length of the password would be okay.
[18:10]  * jdstrand assumes that feedback is '****'
[18:11] <kees> mathiaz: I would prefer the default be left to no feedback to match login, ssh, etc.
[18:11] <mdz> I'm also getting locale warnings from perl, though locale-gen says my locale is up-to-date
[18:12] <ion> mdz: Ditto. Forcing the regeneration of the locales is a workaround.
[18:12] <mdz> kees, curiously, gdb has this to say:
[18:12] <mdz> warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)
[18:12] <mdz> warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?)
[18:13] <mathiaz> kees: ok - would you mind adding a comment to the bug?
[18:13] <mdz> ion, is there a bug open?
[18:13] <jdstrand> mathiaz, kees: I already am
[18:13] <mathiaz> jdstrand: great - thanks
[18:14] <mathiaz> jdstrand: I'm going to unsusribe main-sponsors as long as the core issue isn't settled
[18:14] <mdz> ion, ah, bug 504198
[18:18] <mdz> argh, gdb failure
[18:18] <mdz> [New process 9748]
[18:18] <mdz> [Thread debugging using libthread_db enabled]
[18:18] <mdz> Cannot find new threads: generic error
[18:23] <mdz> ...and restarting cron has made the problem go away :-/
[18:35] <mathiaz> pitti: rickspencer3: hi - re bug 197657 - there is a merge proposal ready for review
[18:35] <mathiaz> pitti: rickspencer3: however noone is assigned to review - is there a specific desktop team review?
[18:43] <chrisccoulson> mathiaz - i was going to say that i could probably review that gnome-panel change, but it seems like i can't upload gnome-panel anyway. it might be a good idea to have vuntz review it (he hangs around in #ubuntu-desktop), but he's already got quite a lot of gnome-panel changes to review
[18:44] <mathiaz> chrisccoulson: are you refering to bug 62529?
[18:45] <chrisccoulson> mathiaz - i was referring to bug 197657
[18:45] <mathiaz> chrisccoulson: ok - thanks for the suggestion
[18:46] <chrisccoulson> i have a feeling that bug 62529 is one that we're already waiting for vuntz to look at
[18:46] <chrisccoulson> i'll ask seb128 though
[18:46] <chrisccoulson> pitti - do you know if there is a reason that gnome-panel is part of the "core" packageset (and not ubuntu-desktop)?
[18:48] <pitti> mathiaz: it's in the sponsoring queue, so we'll get to it
[18:48] <pitti> chrisccoulson: because it's also used by xubuntu and other derivatives
[18:48] <mathiaz> pitti: you mean the main-sponsoring queue?
[18:48] <chrisccoulson> pitti - thanks
[18:48] <pitti> chrisccoulson: apt-cache rdepends libpanel-applet2-0 :)
[18:48] <pitti> mathiaz: yes
[18:48] <mathiaz> pitti: ok
[18:49] <charlie-tca> chrisccoulson: thanks for your help on that xubuntu panel bug
[18:49] <chrisccoulson> pitti - there's a lot of desktop components i still can't upload. perhaps i should consider going for core-dev one day ;)
[18:50] <chrisccoulson> charlie-tca - you're welcome
[18:51] <pitti> chrisccoulson: that'd be great
[18:52] <tseliot> doko__, cjwatson: if I put the path to a library in a conf file in /etc/ld.so.conf.d/ this library should be used instead of the one in /usr/lib. Is this correct?
[18:52] <sebner> pitti: how likely is breakage with new gdm 2.29.4? ^^
[18:53] <tseliot> doko__, cjwatson: or shall I use preload?
[18:53] <pitti> sebner: I don't know; but it's just a microrelease, so without knowing any details I'd say low?
[18:53] <sebner> great :D
[19:17] <vish> mathiaz: hi... mpt has been trying to get Bug #194472 fixed for a long time... you can note his comments in lp and upstream as well
[19:18] <vish> mathiaz: does the change need to be approved by anyone else?
[19:20] <mathiaz> vish: well - I'm not sure whether mpt states that visual feedback should be turned on by default
[19:21] <mathiaz> vish: my understanding is that he advocates for having consistency
[19:21] <vish> mathiaz: comment 6 > "why not fix it, by getting sudo to show asterisks as you type your password?"
[19:22] <mathiaz> vish: well - comment 8 is more precise
[19:23] <mathiaz> vish: depending on the decision wether visual feedback should be enabled by default, different applications should be fixed
[19:24] <vish> mathiaz: hmm... i dont think #8 is different either... in both his first mention is to show the password and only if it is not safe to change the default of others at once too...
[19:25] <mathiaz> vish: well - may be. mpt is just offering his advice. The security team also commented on it.
[19:26] <mathiaz> vish: to move things forward I'd suggest to send an email to ubuntu-devel to ask for feedback and may be reach a conclusion.
[19:26] <vish> mathiaz: from what andrew mentions the password is shown only when the user is entering it and the feedback is removed once the user has hit enter [i havent applied the patch myself]
[19:27] <vish> mathiaz: so -devel is the best approach ?
[19:28] <mathiaz> vish: I guess so - the core issue to answer is whether visual feedback when entering a password should be enabled by default or not.
[19:29] <unggnu> hi all
[19:29] <mathiaz> vish: depending on the answer, relevant applications may require to be fixed.
[19:29] <vish> mathiaz: hmm... oh boy... we'd probably end up discussing this for a long time ;)
[19:29] <vish> on the ML
[19:30] <unggnu> I think an option for fstab which suspends the mount a little after the boot would be great for Lucid. It could optimize the boot process for partitions which aren't needed directly on boot but should be still mounted and checked without user interaction.
[19:30] <mathiaz> vish: if the ML discussion doesn't work out, the next step is to take it to the Technical Board.
[19:32] <vish> mathiaz: well.. this might be a way out of my league... I'll assign the bug to mpt and request him to carry it forward :)
[19:42] <chrisccoulson> i just enabled pwfeedback for sudo on my debian install
[19:43] <chrisccoulson> just out of curiosity
[19:43] <chrisccoulson> it clears the feedback from the terminal after you entered your password, so i don't think it's any less secure than other places that give visual feedback
[19:53] <tseliot> slangasek: ping
[19:56] <asac> slangasek: wrt meeting action about how to get file list that still need to rebuild: i have a script that prints out sources that are of same version in lucid and karmic. wanted to extend that by checking if thos have any binary package with Architecture != all ...
[19:56] <asac> is that enough?
[19:58] <asac> or do you have better ideas or scripts that are ready to use for that?
[20:05] <godane> hey everyone
[20:18] <pitti> apw: FYI, lp:~work-items-tracker-hackers/launchpad-work-items-tracker/2.0/ is the reorganized WI tracker
[20:18] <pitti> apw: I got the DB layout, collector, and HTML reporter implemented
[20:18] <pitti> apw: now I'll work on porting the burndown chart generation, and making that easier along the way, too
[20:19] <pitti> apw: the wiki-status script is broken now, I'm afraid
[20:19] <pitti> but hopefully it will get much simpler now, too
[20:20] <pitti> apw: I created a library "report_tools.py" which now has the logic (like blueprint_completion() and assignee_completion()), and the DB has all the info about milestones, their due date, etc.
[20:22] <pitti> apw: http://people.canonical.com/~pitti/tmp/lucid.db is a current lucid import (so that you don't need to generate one yourself and can just work with an existing DB)
[20:23] <tweakt> what's the easiest way to get the latest available version of a package for a given release, where it may be running on a different (newer) release?
[20:25] <ia> Hello. I know, probably this is not the best place for my question, but i'll try, if you let : i'm experimenting with python/gtk/(gnome)applets. Could anyone tell me, please, how to tell menu (gtk.Menu widget) making popup menu not on top of the other widget(s) (gtk.Icon/gtk.Label, for example), but near? Little illustration about my "problem" - http://yfrog.com/j9gtkmenup (so, indicator-session applet makes it right, and my testing applet - don't) ; I will
[20:25] <ia>  be very appreciate for any clues.
[20:28] <exosyst> Hey guys, is there any code up for https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-gdmsetup
[20:57] <jcole> i have a scenario im trying to figure out... ive got packages that users install, but i want a "migration" script to run after the install (as the current mortal user logged into gnome)
[20:57] <jcole> i notice for kernel updgrades and such, a "reboot is required box" pops up in the tray.. guessing dbus... can someone point me to a shell script example of how to do this?
[20:58] <apw> pitti, sounds good, will look over it tommorrow and get some of my stuff working again
[21:02] <ion> keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868
[21:03] <Keybuk> ah, thanks
[21:05] <ion> keybuk: There seems to be some issue remaining with initramfsless boots judging from the latest comment at <https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/503212>. That’ll need further investigation.
[21:05] <Keybuk> probably
[21:06] <Keybuk> but I've been battling Plymouth all day
[21:06] <Keybuk> and it won
[21:06] <Keybuk> isn't that the same bug?
[21:08] <jcole> what the best channel to ask about ubuntu development... dont want to question spam inappropriate channels... ive also asked in #ubuntu-motu
[21:08] <jcole> what's*
[21:09] <ion> My branch should fix two things: a nih_assert_not_reached bug dholbach encountered and the segfault initially reported in 503212. Now that it doesn’t segfault immediately, someone in 503212 seems to have found further problems with initramfsless boots.
[21:09] <Keybuk> oh, cool
[21:09] <Keybuk> if you can keep investigating that'd be awesome
[21:09]  * Keybuk has to do plymouth as an alpha 2 deliverable
[21:09] <Keybuk> and I'm on a plane to Sydney from Tuesday ;)
[21:11] <ion> Yeah, i’ll make a VM environment that should be able to boot without an initramfs and see what happens. (My current VM i’ve been using to test mountall uses LVM root, i don’t think that can be booted without an initramfs.)
[21:29] <kirkland> superm1: can you point me to the dell 1220 service manual?
[21:30] <freinhard> hi!
[21:31] <freinhard> what's the relation between debian/foo.install and debian/foo.dir? i know .install split the files into packages defined in control, but what does the .dir file do?
[21:33] <siretart> freinhard: see dh_installdirs(1)
[21:59] <mathiaz> james_w: hi!
[21:59] <james_w> hello mathiaz
[22:00] <mathiaz> james_w: I was looking into python-boto branches and run into this error: http://paste.ubuntu.com/353148/
[22:00] <mathiaz> james_w: "Revisions have no common ancestor:"
[22:00] <james_w> ouch
[22:00] <james_w> wth?
[22:01] <james_w> something is screwed up there
[22:02] <james_w> I'm not sure what off the top of my head
[22:02] <mathiaz> james_w: glad to hear it's not *me* :D
[22:02] <mathiaz> james_w: ok - I'll workaround it
[22:02] <mathiaz> james_w: what should I do about it?
[22:02] <james_w> mathiaz: file a bug against udd please
[22:03] <mathiaz> james_w: ok
[22:03] <mathiaz> james_w: would this be related to bug 503702?
[22:04] <james_w> it's quite possible
[22:06] <mathiaz> james_w: ok - bug 504482 filed :)
[22:08] <james_w> thanks mathiaz
[22:16] <mathiaz> james_w: hm - something is wrong in here: http://paste.ubuntu.com/353162/
[22:16] <mathiaz> james_w: the tags are completly different between debian and ubuntu
[22:18] <mathiaz> james_w: ha found the problem!
[22:18] <mathiaz> james_w: I checked out the squeeze *package* instead of the python-boto package!
[22:22] <james_w> mathiaz: ha!
[22:22] <james_w> mathiaz: you may find python-boto is out of date anyway though
[22:24] <mathiaz> james_w: bzr diff -rancestor:../lucid/ debian/ looks funny though
[22:24] <mathiaz> james_w: for example debian/control is completely removed and added in the diff
[22:24] <james_w> yeah, there's apparently file-id differences between the two branches
[22:25] <james_w> it's a problem in the coversion
[22:25] <mathiaz> james_w: however: lucid$ bzr diff -rancestor:../squeeze/
[22:25] <mathiaz> james_w: looks good to me
[22:26] <geser> is there a work-around for bzr failing with "Cannot have multiple roots." when doing a bzr merge-package? (the package is mutter)
[22:27] <james_w> mathiaz: that is odd
[22:27] <james_w> geser: I think there was some discussion on that bug today/yesterday, I think there is a proposed fix but not a workaround.
[22:29] <geser> james_w: have you a bug number at hand? I've only found bug #490039 so far
[22:30] <james_w> ah
[22:31] <james_w> I was thinking of bug 494269, they might be the same
[22:43] <ebroder> Is anybody else having trouble debootstrapping a squeeze chroot? I'm getting dependency resolution errors. Tried asking in #debian-devel, but didn't get any reply
[22:50] <ebroder> Oh hmm...never mind. I think this might be my fault...
[23:13] <freinhard> can somewone tell me why the upload went wrong? http://launchpadlibrarian.net/37597230/upload_1435073_log.txt
[23:15] <crimsun> just as a sanity-check, it was a source upload, correct?
[23:16] <wgrant> freinhard: That's probably a Launchpad bug.
[23:17] <wgrant> freinhard: Can you link me to the build that produced that error, please?
[23:17] <freinhard> https://launchpad.net/~freinhard/+archive/ppa/+build/1435073
[23:18] <wgrant> freinhard: Yeah, that's a Launchpad bug that shows up sometimes. A build occasionally gets retried after it completes successfully.
[23:18] <wgrant> freinhard: Ignore it for now -- all the binaries were successfully uploaded the first time.
[23:19] <wgrant> So the only result of this bug will be that the build status is wrong.
[23:20] <freinhard> so the .deb files are actually in the repo
[23:21] <wgrant> Yes.
[23:21] <geser> yes, and also published (listed in the Packages file)
[23:56] <freinhard> how do i make pbuilder use my ppa to satisfy dependencies? /etc/apt.config is a symlink to /etc/apt which contains my ppa in the sources.list
[23:58] <slangasek> asac: I don't have any ready-to-use scripts for that; the script you describe seems as good as anything