[00:29] <ScottK> barry : check and make sure you can import whatever module name
[00:52] <poolie> zyga: look at /usr/share/pyshared/lazr.restfulclient-0.11.1-nspkg.pth :)
[00:53] <ScottK> barry: Did you get a chance to merge python-defaults from Debian Experimental?
[01:02] <zyga> poolie: looking
[01:03] <zyga> oh $DIETY
[01:03] <zyga> poolie: what a mess
[01:03] <zyga> poolie: what is the purpose of that .pth file?
[01:04] <poolie> i don't know but the results are pretty psychedelic
[01:04] <poolie> lazr looks like a builtin module
[01:05] <zyga> poolie: and that is useful because... what? we save import lazr?
[01:06] <poolie> i think it's an unintended side effect of packaging a namespace package; bug 796992
[01:34] <poolie> maco, hi?
[01:43] <slug> anyone with experience building with the launchpad ppa virtual machines? what's the hardware characteristics of these ? I just started a build and wondering how long would it take.
[01:44] <slug> the other question is, what's the available disk space for compilation? is it 2GB or is it larger? my package is a large science C++ package and on my system takes a few GByte to compile.
[01:45] <infinity> slug: There should be enough space and horsepower to make it go.
[01:46] <slug> infinity: is there something similar to ganglia cluster monitoring ?
[01:47] <infinity> Err...
[01:47] <infinity> There's monitoring internal to their network.  Not that we expose to people building a single package, no...
[01:48] <infinity> Well, unless you count https://launchpad.net/builders as "monitoring".
[01:54] <slug> infinity: i see. is it only one cpu core assigned to each virtual machine?
[01:54] <infinity> slug: It's not what you think it is, I think.
[01:55] <infinity> slug: Our buildd network is a network of machines, not a cluster or supercomputer with virtual partitions.
[01:55] <infinity> slug: The only thing "virtual" about them at all is that the PPA builders are Xen instances that get scrubbed between builds.
[01:55] <infinity> slug: So, you get the machine you get.  Most of them are 2+ cores, most are over 2G of RAM, all have more than enough disk space.
[01:58] <slug> infinity: all right, i'm just trying to assess the amount of time the compile would take, that's all. do you have any experience with git-buildpackage ?
[01:58] <infinity> Lots of experience with git, lots of experience with building packages, very little with the specific tool. :P
[01:59] <infinity> (I tend to live in the past and not use the new and shiny methods of doing... Anything)
[01:59] <poolie> slug: i suggest you just upload a source deb and see if it passes
[02:00] <infinity> ^
[02:00] <slug> infinity: ok, so i have a question for you. the only reason i used git-buildpackage was to try to get a git format patch to send it to the debian/ubuntu maintainer.
[02:00] <poolie> if it needs too much memory, which is possible, let us know
[02:00] <infinity> Any patch will do.
[02:00] <infinity> Maintainers that are whiny about format should be smacked
[02:00] <poolie> they should have plenty of disk
[02:00] <slug> infinity: i updated the deal.ii package from 6.3.1 to 7.0.0, but git-buildpackage seemed a bit confusing, so i ended up creating my own private git repo.
[02:01] <slug> poolie: yeah, it's building now, i've uploaded it earlier. thanks for the offer
[02:01] <infinity> {git,arch,svn,bzr,cvs}-buildpackage are just convenience wrappers.
[02:02] <StevenK> s/arch/tla/
[02:02] <StevenK> (... isn't it?)
[02:02] <infinity> You can just as easily checkout/export and dpkg-buildpackage or even just "dpkg-buildpackage -I -S" (the -I makes sure it stips out common VCS directories and files)...
[02:02] <infinity> StevenK: Wasn't there both?
[02:02] <infinity> StevenK: But you might be right, with a ganish of "who cares?" :)
[02:02] <slug> infinity: i'm still going to give a try. the point of me using git-build... was that debian doesn't have the 7.0.0 package yet, so i wanted to create a new branch/tag to make it easier to send the patch to the maintainer.
[02:02] <StevenK> infinity: I'm not sure -- tla-buildpackage made me want to self-lobomotise a few times
[02:03] <infinity> StevenK: arch/tla had that effect in general...
[02:03] <slug> infinity: in the end, i've just created my own git repo, used quilt to update the patches and debuild -S to create the new source package.
[02:03] <ajmitch> StevenK: and then you went to work on LP?
[02:04] <infinity> ajmitch: He's not known for his decision-making skills.
[02:38] <nigelb> Morning!
[02:38] <nigelb> *yawn*
[02:43] <ajmitch> afternoon
[02:43] <micahg> evening :)
[02:49] <kees> hallyn: eugene teo says he's trying to find you. have you gotten emails from him?
[02:54] <hallyn> nope
[02:54] <hallyn> oh, a few days ago, yeah
[02:54] <hallyn> i responded (cc:ing the list)
[02:55] <hallyn> and, i frankly don't get what people are hoping to get out of the discussion
[02:55] <hallyn> kees: ^
[02:56] <kees> hallyn: I have no idea, he just pinged me to see if you were on vacation. I don't even know that it's about. :P
[02:56] <hallyn> hm, wonder if my reply got lost
[02:56] <hallyn> are you on security@kernel.org list?
[03:00] <hallyn> kees: oh well, if he asks again, tell him that I did reply :)
[03:00] <kees> hallyn: no, I'm not
[03:00] <hallyn> oh i figured you would be
[03:04] <kees> hallyn: nope, unfortunately
[03:06] <hallyn> kees: thx, good night
[03:06] <kees> hallyn: g'night!
[04:03] <jykae> morning
[04:38] <maco> poolie: whats up?
[05:12] <didrocks> good morning
[05:14] <ion> that.
[06:38] <mvo> @pilot in
[09:48] <didrocks> anyone know why winbind is now on the CD? it seems the cd growth was due to that
[09:49] <barry> ScottK: it's on my list, and i'll look at that today
[09:52] <seb128> didrocks, when?
[09:52] <seb128> didrocks, the iso didn't change for a while
[09:53] <didrocks> seb128: compare the 20110727 and 20110728 daily-live manifest
[09:54] <seb128> didrocks, cifs-utils Recommends it
[09:54] <didrocks> seb128: indeed, should we revert that?
[09:54] <seb128> didrocks, it's a side effect of the autosync
[09:54] <didrocks> yeah :)
[09:55] <seb128> didrocks, I don't know enough about cifs to have an opinion on whether that recommends is right or not
[09:55] <Laney> ask luk?
[09:56] <Laney> it is under "* Install cifs.idmap upcall binary and manpage" so presumably somehow useful for that
[09:56] <didrocks> Laney: doing that
[09:56] <Laney> :-)
[09:56] <didrocks> we have to way if it worths the 3+ extra MB on the CD…
[09:56] <didrocks> weigh
[09:58] <seb128> didrocks, well, it's probably not wanted on the CD but it might not be "just revert the recommends", it might also be "don't install that new binary which was added"
[09:58] <seb128> didrocks, "or add a new binary to the source for that"
[09:58] <didrocks> seb128: sorry, I don't get you, "don't install that new binary which was added" ?
[09:59] <seb128> didrocks, " it is under "* Install cifs.idmap upcall binary and manpage" so presumably somehow useful for that"
[09:59] <seb128> didrocks, those might need to be installed in a new binary
[09:59] <seb128> which recommends winbind
[09:59] <seb128> but is not on the CD
[10:00] <seb128> dunno how much cifs.idmap needs winbind
[10:00] <didrocks> slangasek: maybe, when you are online, luk shouldn't be far from you :) winbind is adding an extra 3+ MB to the CD as it's now recommended by cifs-utils. Can you have a look at that? (see also ^^)
[10:01] <didrocks> seb128: ok, got you this time :)
[10:01] <seb128> didrocks, sorry for not being clear ;-)
[10:01] <didrocks> let's say it's rather me being slow :-)
[10:02] <seb128> well in any case best to let somebody who has a clue about that stack decide, pinging slangasek seems about right
[10:02] <didrocks> indeed, he co-maintains the package
[10:02] <seb128> the "easy" way would be to revert the "install cifs.idmap, manpage and recommends"
[10:02]  * didrocks just adds a note to not forget that in case it's lost
[10:02] <seb128> didrocks, or open a bug, milestone it a3 and assign to slangasek?
[10:02] <didrocks> yeah, let's wait for them, just keep tracking it as the additional space is important
[10:03] <seb128> so you are sure it's on track
[10:03] <didrocks> will be better that my sticky note, indeed, doing
[10:03] <seb128> thanks
[10:03] <didrocks> yw :)
[10:14] <mvo> slangasek: you reported bug #809980 some days ago, was this a one-time crash? or is that something still reproducable?
[10:16] <mvo> https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/809980
[10:16] <Laney> w
[10:17] <Laney> oops
[10:41] <fhd> I'd like to contribute a bit to Ubuntu, to Unity 2D in particular. Is Launchpad just used for bugs? Where do you track feature requests?
[10:42] <Laney> unity people are in #ayatana AFAIK
[11:03] <artfwo> mvo, hopefully i made my policykit intentions clear in bug 815283, check it out, if you have time
[11:07] <mvo> thanks for this update artfwo!
[11:08] <artfwo> mvo, i just uploaded another build to revu with fixed install path for *.pkla
[11:10] <mvo> artfwo: so the file is needed for avoiding the password prompt? and if we just get it into policykit-desktop-priviledges directly it would not even be needed?
[11:10] <artfwo> mvo, that's right, but my indicator is going to be in universe and policykit-desktop-priviledges is providing defaults for main so far
[11:11] <artfwo> so i don't think it's sensible to include in policykit-desktop-priviledges
[11:13] <mvo> artfwo: right
[11:21] <zyga> RE
[11:32] <hrw> fhd: for me feature request is a wishlist bug
[11:48] <fhd> Laney: Ah, good to know
[11:48] <fhd> hrw: Found mostly bug. Guess my first contribution will be a bug fix anyway, but I was wondering where the feature requests are.
[12:08] <mdeslaur> @pilot in
[12:19] <mvo> @pilot out
[12:59] <apw> are we aware that indicator-messages and indicator-session are marked as breaks: indicator-me, which wants to be installed, triggering upgrade breakage ?
[13:00] <apw> and are we aware that lightdm-gtk-greeter is not being installed by default when -example is removed
[13:01] <seb128> apw, how so?
[13:02] <apw> the former actually triggers errors when you try and install the ubuntu-desktop^ task
[13:02] <apw> the greeter prevent login after reboot till you install the ubuntu-desktop^ task
[13:02] <apw> whuc
[13:04] <seb128> hum
[13:04] <seb128> doesn't really make sense
[13:04] <seb128> well the indicator is deprecated, indicator-session is replacing its features
[13:05] <seb128> lightm depends on lightdm-gtk-greeter | libghtdm-greeter
[13:05] <seb128> so there should be no way you get no greeter
[13:05] <apw> seb128, well i just upgraded and didn't get a greeter
[13:05] <apw> this was about 2 hours back i did the upgrade
[13:06] <apw> when the greeter didn't appear i used the ubuntu-desktop^ to get things better
[13:06] <apw> which did trigger apt-get dist-upgrade to then install the greeter
[13:06] <seb128> how can you get lightdm and no greeter it if has a depends on a greeter?
[13:06] <apw> but triggered errors about the me-indicate
[13:06] <apw> seb128, that i have no idea about but i am not the only one it happened to
[13:07] <apw> on dist-upgrade
[13:07] <apw> smb, ^^ i think you had this same thing
[13:07] <seb128> there were some issues, but lightdm was only recommending the greeter not depending on it
[13:07] <seb128> we fixed that yesterday
[13:07] <seb128> well if that's still an issue talk to mvo about how apt can ignore a depends
[13:07] <seb128> that seems a bug in apt
[13:08] <smb> apw, PRobably because the desktop task brought it
[13:08] <apw> seb128, ok will do
[13:09] <smb> when I saw it happen, there was some lightdm-greeter.*example removed but not the real gretter installed
[13:09] <apw> smb, same happend to me, was suppsoed to be fixed by the time i updated ... oddness
[13:09] <seb128> that's what happened before we promoted the recommends to a depends yesterday
[13:09] <smb> meh, which apw said already
[13:10] <seb128> apw, do you use a mirror? is it uptodate?
[13:11] <apw> seb128, interesting point.  i use gb.archive.com, but i am using ipv6 which i think points to somewhere in .se
[13:12] <jpds> apw: gb.archive is IPv6 enabled.
[13:12] <apw> jpds, its enabled yes, but by pointing it to another mirror
[13:12] <apw> (as i understand things)
[13:13] <jpds> apw: No, the machine has it's own address.
[13:13] <jpds> its*
[13:13] <jibel> seb128, indicator-me is what makes today's desktop image broken http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/20110729.1/livecd-20110729.1-i386.out
[13:14] <apw> The following packages have unmet dependencies:
[13:14] <apw>  indicator-messages : Breaks: indicator-me but 0.2.92-0ubuntu1 is to be installed
[13:14] <apw>  indicator-session : Breaks: indicator-me but 0.2.92-0ubuntu1 is to be installed
[13:14] <apw> seb128, and those are indeed exactly the messages i get when installing the ubuntu-desktop^ task
[13:15] <seb128> I think it's didrocks' fault
[13:15] <seb128> didrocks, can you make unity2d-panel-service stop recommending indicator-me?
[13:16] <didrocks> seb128: sure
[13:16] <seb128> thanks
[13:16] <seb128> well it's only a recommends not sure why it break anything
[13:16] <seb128> jibel, apw: does it break if you --no-install-recommends?
[13:17] <apw> i thought recommends always get installed
[13:17] <seb128> apw, they do when available but they used to be ignored rather than break the install when not
[13:17] <apw> seb128, had no effect on the ubuntu-desktop^ install
[13:17] <didrocks> seb128: so, not my fault :)
[13:17] <didrocks> still uploading without it
[13:18] <seb128> didrocks, well I don't see who else
[13:18] <seb128> nothing else recommends or depends on it in main
[13:18] <apw> seb128, can i ask apt-cache somehow on my system ?
[13:18] <seb128> apw, well aptitude should tell you what the issue is
[13:18] <seb128> can you try with it?
[13:19] <seb128> mvo, is there any way to ask apt why it tries to bring indicator-me in?
[13:20] <didrocks> hum, Connection failed, aborting. Check your network [Errno 111] Connection refused
[13:20] <didrocks> am I the only one having troubles to upload?
[13:20] <mvo> seb128: yes, apt-get install -o Debug::pkgDepCache::AutoInstall=true
[13:20] <seb128> apw, ^
[13:20] <seb128> apw, can you try that?
[13:21] <apw> and what am i looking for
[13:21] <jykae> how does natty run on exopc? has anyone tried?
[13:21] <seb128> apw, something which mentions indicator-me
[13:22] <apw> nothing other that those other two lines above
[13:23] <apw> seb128, are the Reverse Depends in apt-cache showpkg indicator-me the info we are looking for ?
[13:24] <seb128> mvo, ^ help
[13:24] <seb128> ;-)
[13:24] <apw> it appears that the indicator-session i have installed depends on indicator-me
[13:24] <apw> as does indicator-messages
[13:24] <apw> as does indicator-me-gtk2
[13:25] <apw> could it be that last one?
[13:25] <seb128> apw, indicator-messages Breaks indicator-me
[13:25] <seb128> it depends depends on it
[13:25] <didrocks> (they replaces: it here)
[13:26] <apw> seb128, right so i think the first two should resolve
[13:26] <apw> seb128, but if indicator-me-gtk2 needs it and is installed what will uninstall that
[13:27] <seb128> apw, uninstall indicator-me-gtk2
[13:27] <seb128> that should not be required
[13:27] <seb128> oneiric use gtk3
[13:28] <apw> so this could be an upgrade problem then
[13:29] <apw> but that would not affect the seeds and cd builds which also hit this
[13:29] <seb128> well jibel said the daily iso build failed on the same error
[13:29] <seb128> right
[13:31] <apw> seb128, and purging -gtk2 didn't do any good
[13:32] <seb128> we need mvo's help there
[13:32] <seb128> can you pastebin a log of the apt command which has an issue with -o Debug::pkgDepCache::AutoInstall=true used?
[13:35] <apw> seb128, http://paste.ubuntu.com/654491/
[13:36] <apw>  sudo apt-get install -o Debug::pkgDepCache::AutoInstall=true ubuntu-desktop^
[13:36] <seb128> do you have aptitude?
[13:36] <seb128> could you try with aptitude?
[13:36] <apw> i have aptitude installed now, but i am always told never to use it :)
[13:37] <apw> and it doesn't understand ubuntu-desktop^
[13:37] <ion> Whaat? aptitude is much better at problem resolution than apt-get.
[13:37] <apw> but ... if you want something run, ask
[13:37] <apw> well it doesn't know the task syntax it seems
[13:39] <mvo> barry: hello! shouldn't UDD automatically commit my transmission sponsored upload from today?
[13:40] <mvo> apw: apt-get install -o Debug::pkgProblemResolver=true -o Debug::pkgDepCache::AutoInstall=true usually gives a clue what is wrong … sorry for being late to the party
[13:40] <jibel> seb128, the only way it is installed it ubuntu-desktop depends on unity-2d depends on unity-2d-panel recommends indicator-me
[13:40] <mvo> I'm chasing down a apt crasher that drives me nuts
[13:41] <seb128> jibel, which didrocks uploaded a fix for
[13:41] <jibel> right
[13:41] <seb128> apw, wait an hour for the unity-2d update to be published
[13:41] <seb128> but I can confirm the issue in a pbuilder
[13:43] <apw> seb128, mvo, http://paste.ubuntu.com/654495/ with the extra debug options
[13:46] <roadmr> Hey folks! I used to be able to preseed auto-login with d-i passwd/auto-login boolean true, but this seems to have changed in Oneiric, anyone know where I could find the new setting to use?
[13:46] <apw> Broken indicator-messages:amd64 Breaks on indicator-me [ amd64 ] < none -> 0.2.92-0ubuntu1 > ( gnome )
[13:47] <apw> does that line make sense with (gnome) at the end ?
[13:47] <jibel> it is the section the package belongs to.
[13:47] <mvo> eh, indicator-messages has a unversionized breaks, that does not make much sense
[13:48] <mvo> that should probably be a conflicts instead
[13:48] <mvo> whats up with indicator-me, should it go away?
[13:49] <mvo> apw, seb128: I can prepare a new version with the fix, lets see
[13:49] <seb128> mvo, yes, I think it should be a c,r,p
[13:49] <bigon> -Werror=unused-but-set-variable << euh? is oneiric gcc failing with these now?
[13:49] <seb128> mvo, I told so to kenvandine a week ago, not sure what happened with that
[13:50] <seb128> mvo, I think he pinged you about it but by the time you reply he was not around and that got dropped on the floor
[13:50] <seb128> mvo, basically indicator-me is merged in indicator-session
[13:50] <kenvandine> i think i fixed it
[13:50] <seb128> kenvandine, current oneiric is still a Breaks, not a Conflicts,Replaces,Provides
[13:51] <seb128> $ apt-cache show indicator-session | grep Breaks
[13:51] <seb128> Breaks: indicator-me
[13:51] <seb128> $
[13:51] <mvo> I just uploaded a fix, will commit now
[13:51] <seb128> mvo, thanks
[13:51] <mvo> quick bzr, quick
[13:51] <mvo> yw
[13:52] <mvo> now back to the segfault
[13:52] <seb128> mvo, sorry for the distraction, thanks for fixing it ;-)
[13:52] <kenvandine> mvo, oh... you said i didn't need to change that
[13:53] <kenvandine> dist-upgrade did the right thing, it just wasn't something update-manager was designed for
[13:53] <seb128> kenvandine, no, he said that update-manager updates never uninstall things
[13:53] <kenvandine> right
[13:53] <seb128> kenvandine, still unversionned Breaks confuse the partial upgrade resolver
[13:53] <seb128> when Conflicts,Replaces,Provides help it
[13:54] <kenvandine> dist-upgrade did the right thing...
[13:54] <seb128> it tells it "that one is a solution to this one being uninstalled"
[13:54] <seb128> kenvandine, well, the resolver takes lot of parameters in account
[13:54] <seb128> kenvandine, like some people here had indicator-me-gtk2 still installed which put extra score in the "keep indicator-me installed"
[13:54] <kenvandine> ugh
[13:55] <kenvandine> ok
[13:55] <seb128> kenvandine, when it scores enough apt might decide to hold the update
[13:55] <mvo> kenvandine: sorry, maybe I misread it then, usually a breaks without a version indicates that something is not quite right. breaks really just means "the two can not be configured together". but conflicts "the two can not be on disk together". most of the time a breaks is transitional in some way whereas a conflict it permanent. does that make sense?
[13:55] <kenvandine> yeah
[13:55] <seb128> kenvandine, that's why the replaces,provides is useful, it tells the resolver that this upgrade is a solution
[13:55] <kenvandine> that makes sense
[13:55] <mvo> seb128: I would go one step further and say that a breaks without a version does not make too much sense semantically too
[13:56] <mvo> its really useful to help avoiding churn during a upgrade, no need to remove a version first, then install a later version with the breaks we can just unconfigure it and the n upgrade without the need to remove all the on-disk files
[13:56] <ion> Here aptitude wants to remove indicator-me-gtk2 when upgrading unity-2d, resulting in gwibber getting removed, and it says indicator-me is recommended, but it can’t be installed due to indicator-{messages,session} having Breaks on it.
[13:57] <geser> ion: see scroll-back, the indicator-me issue was just discussed
[13:58] <kenvandine> it should be wanting to remove libgwibber1
[13:58] <kenvandine> well, it shouldn't actually
[13:59] <ion> geser: Yes, i simply described my symptoms in case they were useful for someone, knowing they’re probably just redundant. :-)
[13:59] <geser> ah
[13:59] <ion> To clarify, indicator-me-gtk2 is being removed because it’s automatically installed and nothing depends on it anymore.
[14:51] <hevauq> hi all, how can one interface between a daemon and any user utility?
[14:52] <ion> With dbus
[14:55] <hevauq> um, no i am writing a custome daemon
[14:56] <hevauq> its a networing daemon, it service remote connection with sockets. but i am wondering how can it service local requiests?
[14:58] <hevauq> i am not making anything complicated, just trying to provide basic functionality
[14:59] <hallyn> hevauq: are you saying you want local requests to be treated differently from remote ones?
[14:59] <hallyn> (else I don't see the problem)
[15:00] <hevauq> well, i dont care. But i have no idea what is generally done.
[15:00] <hevauq> does most daemon service local requests over sockets?
[15:01] <hallyn> hevauq: yes, though i suppose the local clients usually connect to 127.0.0.1 instead of the eth0 ip
[15:04] <hevauq> ok, actually its not the same socket family so IP address is irrelvant. command_Line(connect_to_remote)-->daemon(over_socket)--->distant_daemon(do_stuff)-->daemon(send data)-->command)_line.
[15:05] <hevauq> command_line can send multiple command to daemon
[15:12] <barry> huh.  screensaver seems overly aggressive today
[15:13] <Laney> raargh i'm a screensaver aaaaargh brainsss
[15:13] <barry> :)
[15:43] <slangasek> didrocks: hrm, luk wasn't at DebConf and I no longer am; it would be better if someone else could look into bug #817962
[15:43] <slangasek> mvo: 809980 was a one-time crash for me
[15:44] <didrocks> slangasek: do you see anyone in the foundation team having that knowledge (samba essentially, it seems)? If not, I can have a look
[15:45] <jml> jelmer might be able & willing to help
[15:46] <didrocks> jelmer: interested to have a look? ^ :)
[15:50] <jml> how can I get gpg to forget my key password?
[15:51] <micahg> mdeslaur: can you sponsor the libjpeg8 fix for me as soon as it finishes test building?
[15:51] <mvo> thanks slangasek
[15:51] <mdeslaur> micahg: yes
[15:53] <jelmer> didrocks: looking
[15:54] <slangasek> didrocks: I don't think anyone is going to have existing familiarity with a new upcall interface; a samba expert will have only a moderate head start on figuring out the bug :)
[15:54] <micahg> mdeslaur: bug 818132
[15:54] <didrocks> slangasek: ok, thanks for the info, I'll try to ping luk if jelmer has no idea on this and then dogfooding :)
[15:55] <Daviey> Would an AA be able to promote ipxe please, bug #800340 .. it's causing upset. Thanks :)
[15:58] <mdeslaur> @pilot out
[16:00] <mdeslaur> micahg: uploaded
[16:00] <micahg> mdeslaur: thanks!
[16:01] <jelmer> didrocks, slangasek: I think it would be reasonable to drop winbind to Suggests; it's not necessary for normal operation and requires extra configuration (both of winbind itself, and in key.conf)
[16:02] <didrocks> jelmer: thanks for the analysis. Seems safe enough to do that for now, maybe envisionning a package split later if we see that some part can be extruded in a separate bin package. :)
[16:35] <hallyn> think i'll try to get vimprobable and vimprobable2 packages into universe next week...
[16:39] <hallyn> hmm, it's *possible* that I'm somehow to blame, but it seems like on an oneiric-virtual kernel, I can't do "sleep 60 & gdb -x gdb.commands -p $!"  (even setting yama ptrace_scope to 0).  It just hangs
[16:39] <hallyn> it works on my laptop though, with oneiric-generic kernel
[16:39]  * hallyn tries a new ec2 instance
[16:54] <hallyn> hm, seems to only happen on this one instance.
[16:54] <hallyn> clearly i've done *something*
[17:14] <nikitis> Who do I talk to about making my Ubuntu installer for Playstation 3 PPC?
[17:20] <nikitis> Anyone?
[17:24] <cjwatson> nikitis: hmm, we decommissioned it because (a) the hardware manufacturer is clearly aggressively against it and so there are fewer and fewer examples of hardware that could actually run it, (b) there were no interested developers
[17:24] <cjwatson> I think most of the code should still be in place, so it should just be a matter of building CD images
[17:24] <nikitis> cjwatson: time to start it up again.  Linux is back on PS3.
[17:25] <nikitis> i've already written an installer
[17:25] <cjwatson> why write a new one rather than use the existing one? :-)
[17:25] <nikitis> existing one doesn't work with new methods
[17:25] <nikitis> was designed for Older NAND Playstation 3's
[17:26] <nikitis> New otheros runs on Slims and Old Playstation 3's
[17:26] <nikitis> difference in hardware etc
[17:26] <cjwatson> to get installer code into Ubuntu, it should be a modification of the existing installer, rather than an entire new one
[17:26] <cjwatson> we have lots of framework stuff for supporting a variety of architectures and such, so it shouldn't be necessary to reinvent the whole thing
[17:26] <nikitis> Well I already have
[17:26] <nikitis> work is done
[17:27] <nikitis> maybe some polish
[17:27] <cjwatson> I know, but it isn't going to be accepted into Ubuntu that way
[17:27] <cjwatson> (though of course you can do whatever you like separately)
[17:27] <nikitis> i'm just curious though
[17:27] <cjwatson> it shouldn't be too hard to extract the small architecture-specific part and integrate it into d-di?
[17:27] <cjwatson> er, d-i
[17:27] <Chipzz> cjwatson: well he didn't say he started from scratch :)
[17:27] <nikitis> would it be hard to compile packages for ppc for 11.04
[17:27] <cjwatson> we already do
[17:27] <cjwatson> powerpc (the architecture as opposed to the PS3 subarchitecture) has never gone away
[17:28] <nikitis> can we debootstrap to it?
[17:28] <cjwatson> sure
[17:28] <cjwatson> debootstrap should even pick the ports mirror automatically
[17:28] <nikitis> well currently my installer debootstraps 10.04 Lucid
[17:29] <nikitis> i didn't know all packages were compiled for ppc 11.04 already
[17:29] <cjwatson> and oneiric too
[17:29] <cjwatson> lucid even still had powerpc+ps3 images, though I'm not sure they worked right
[17:29] <nikitis> Well i can tell you, Fedora has already accepted our installers.  And will be making version Fedora 16 with it.  I don't want to leave Ubuntu out of it.
[17:29] <cjwatson> (http://cdimage.ubuntu.com/ports/releases/lucid/release/)
[17:30] <cjwatson> the architecture-specific bits of an installer are really pretty small - it should mostly just be a boot loader installer and a bit of image boot stuff
[17:30] <nikitis> no the old cd images don't work with new otheros method on PS3
[17:30] <nikitis> at least not yet
[17:30] <nikitis> a driver is currently being written though
[17:31] <nikitis> for the blu-ray drive
[17:31] <cjwatson> so it shouldn't be too hard to extract - you'd mostly be replacing kboot-installer
[17:31] <cjwatson> I expect
[17:31] <nikitis> once written the cd images may work
[17:31] <cjwatson> patches for that would be welcome
[17:31] <cjwatson> (anyway, I have to go, dinnertime)
[17:32] <Chipzz> bon appetite!
[17:32] <nikitis> But for now the only way for ubuntu to install on Playstation 3's legally is via scripting either via wget, or usb stick
[17:35] <nikitis> Trying not to use sony blu-ray code as that would be illegal
[17:36] <nikitis> If ubuntu won't accept PPC in future builds I'm afraid they will get left behind
[17:38] <directhex> nikitis, it's already got ppc builds, as you've been told.
[17:38] <nikitis> Where are the natty?
[17:39] <directhex> there are two powerpc build servers, adare and ross, currently doing builds
[17:39] <directhex> nikitis, on ports.ubuntu.com?
[17:40] <nikitis> do i change debootstrap info from lucid to natty?
[17:40] <infinity> All the packages are built for every release for PPC.  We just don't have PS3-specific ISOs built for recent releases, that's all.  But, as Colin said, if you have fixes to make our current generic powerpc ISOs work with PS3, we'd love patches.
[17:40] <infinity> nikitis: Yeah, just debootstrap whatever release you want.
[17:40] <nikitis> hmm okay
[17:40] <infinity> (I run natty on my PowerStation with no issues)
[17:41] <infinity> Though, ironically, that needs some installer/ISO fixes too.  I need some round tuits to fix that.
[17:41] <nikitis> Well that's what i'm here to talk about, I want to know about checklists, for requirements to make it an official installer
[17:42] <infinity> nikitis: Like Colin said, we don't tend to accept new "installers", per se, we just need fixes to our existing ones.
[17:42] <nikitis> Current ISO's will NOT work nor will they ever on Current PS3 state.  It needs a new build from scratch.
[17:42] <nikitis> New drivers have been completely rewritten, the method and times at which things get installed is different
[17:43] <infinity> nikitis: So, if there are changes needed to debian-cd to make the ISOs bootable on PS3, that's checklist 1, if there are changes required to debian-installer components to actually make the installed system bootable, that needs doing, etc.
[17:43] <nikitis> I've written a debian installer already
[17:43] <nikitis> I wrote that one first
[17:43] <directhex> nikitis, if it wasn't clear: a completely from-scratch installer, not based on ubiquity or debian-installer, will never ever ever ever be accepted into ubuntu
[17:44] <infinity> I'm referring to the debian-installer project, not just "an installer for Debian".
[17:44] <nikitis> yeah but this is gonna require a new project
[17:44] <directhex> nikitis, the design of those two installers is extensible, and adaptable to any architecture.
[17:44] <infinity> I don't see why it should need a new project.
[17:44] <nikitis> That's because you don't see how different it is
[17:44] <barry> ScottK: in python-defaults, do we still need to suggest python-profiler?
[17:45] <Chipzz> nikitis: debian and ubuntu do not want to maintain to seperate codebases for installing things
[17:45] <Chipzz> or should I say 3? :)
[17:45] <infinity> Installation is always the same general idea:  Boot system, determine installation target, install junk, figure out how to make system bootable.
[17:45] <ScottK> barry: No
[17:45] <barry> ScottK: cool, didn't think so.  i'll drop that delta
[17:45] <infinity> nikitis: Trust me, I have some idea. :P
[17:45] <Chipzz> (if you count ubiquity, which I think is based on debian-installer anwyay)
[17:45] <nikitis> Well eventually you could add it to alternate cd
[17:45] <infinity> Chipzz: Just one, really, since ubiquity and oem-installer re-use d-i heavily.
[17:45] <nikitis> it's not big
[17:46] <Chipzz> infinity: that's what I just said :)
[17:46] <nikitis> few kb's
[17:46] <infinity> nikitis: Well, what does your installer do, precisely?
[17:46] <nikitis> it basicaly emulates a manual install atm
[17:46] <infinity> nikitis: Perhaps we're talking past each other, and what you've done it work that can easily be rolled into d-i.
[17:46] <Chipzz> nikitis: it's still different codepaths that need be tested seperately
[17:46] <nikitis> but automates it
[17:46] <nikitis> But
[17:46] <infinity> s/it work/is work/
[17:47] <directhex> "manual install"?
[17:47] <nikitis> there are quirks like how the PS3 harddrive regions are setup.  There is no /dev/sda or sdx for that matter
[17:47] <infinity> nikitis: That's fine.
[17:47] <nikitis> stuff that the normal installer will not work or detect properly
[17:47] <infinity> nikitis: No two architectures are the same in that regard.
[17:47] <directhex> i've a co-worker who might be more forthcoming with info on this
[17:47]  * directhex pokes kakaroto
[17:47] <infinity> nikitis: Like I said, trust me when I say that we can deal with this in d-i.
[17:47] <Chipzz> nikitis: maybe you should elaborate a little on how your installer works; is it a patched debian-installer, is it debian-installer preseeded with values, or is it your own home-rolled script?
[17:47] <Chipzz> or d) sth else
[17:48] <nikitis> home-rolled
[17:48] <nikitis> but functional
[17:48] <nikitis> it will install onto a PS3
[17:48] <nikitis> and i'm adding to it
[17:48] <nikitis> still wip
[17:48] <nikitis> but since it works now
[17:49] <nikitis> i was curious about the process of implementing it
[17:49] <Chipzz> nikitis: I think the partitioner from debian-installer is extensible in that regard
[17:49] <infinity> nikitis: Well, if you've covered the important bits (storage detection and bootloader setup, basically), that would be a good time to see if we can re-factor it into d-i.
[17:49] <Chipzz> you can probably adapt it to work correctly
[17:49] <nikitis> I use parted in my installer
[17:49] <Chipzz> so does the debian-installer I believe
[17:49] <directhex> nikitis, you're still not describing anything d-i can't do out of the box.
[17:49] <directhex> or doesn't already do by default out of the box
[17:50] <nikitis> you'd have to modify debian installer for text only install.  no plymouth no splash
[17:50] <Chipzz> nikitis: it might be a simple matter of teaching the partition component of debian-installer about /dev/whateverps3uses
[17:50] <infinity> nikitis: That's fine, some architectures do that already too.
[17:50] <nikitis>  /dev/ps3dd
[17:50] <directhex> nikitis, d-i already does text based and serial console based install. i still don't see an issue
[17:51] <nikitis> i guess right now it's just lack of cd support
[17:51] <directhex> the same installer code works on ultrasparcs and itaniums and amd64 desktops. you bet your ass it's extensible
[17:51] <nikitis> must run in /bin/ash
[17:51] <infinity> And that's where debian-cd comes in.
[17:51] <nikitis> at least until it debootstraps
[17:52] <Chipzz> nikitis: requiring /bin/ash can probably be fixed
[17:52] <nikitis> Older NAND PS3's cannot handle /bin/bash
[17:52] <nikitis> though newer slims can
[17:52] <directhex> doesn't the installer use busybox?
[17:52] <Chipzz> that sounds unlikely
[17:52] <Chipzz> (wrt not supporting bash)
[17:52] <nikitis> Chipzz: it's true because the image for nands has to be smaller and cannot fit
[17:53] <nikitis> it's a size issue,
[17:53] <Chipzz> nikitis: you shouldn't be using bash anyway, you should use dash
[17:53] <Chipzz> or busybox for the initramfs
[17:53] <nikitis> it is busybox
[17:53] <nikitis> modified
[17:53] <infinity> None of this matters from a d-i perspective.
[17:53] <nikitis> well maybe
[17:54] <infinity> The whole point of d-i is to boot into a functional system and install from there, we don't run d-i from flash, that would be insanity.
[17:54] <nikitis> but we still need blu-ray support before d-i can be used
[17:54] <nikitis> that could be awhile
[17:55] <nikitis> at the moment my installer is the only thing that will do it
[17:55] <infinity> By "blu-ray support", do you mean "support for blu-ray discs", or "support for the drive"?
[17:55] <nikitis> support for the drie
[17:55] <nikitis> drive*
[17:55] <infinity> Didn't we once have support for that?
[17:56] <infinity> I mean, we had ISOs that people claimed worked...
[17:56] <nikitis> For nands
[17:56] <nikitis> Older PS3's
[17:56] <nikitis> but sony wrote the drivers to accept those discs
[17:56] <nikitis> in otheross.bld
[17:57] <nikitis> our otheros build is different and written from scratch
[17:57] <barry> ScottK: http://pastebin.ubuntu.com/654650/
[17:57] <infinity> So, we're not really talking about installers here at all (or shouldn't be, just yet)
[17:57] <nikitis> we already have more drivers written than were provided by Sony with their otheros.
[17:57] <infinity> The real trick is making our ISOs bootable.
[17:58] <nikitis> we'd have to add the drivers to the installers
[17:58] <infinity> By "drivers", you mean kernel drivers, or bizarre userspace glue?
[17:58] <nikitis> kernel
[17:58] <nikitis> we have more access to PS3 now than ever
[17:59] <infinity> If there are kernel drivers available here, and they're free software, we won't say no to getting them in our kernel, I imagine.
[17:59] <nikitis> syscon drivers
[17:59] <infinity> (Although, why aren't they being upstreamed?)
[17:59] <ScottK> barry: Seems sane
[17:59] <nikitis> these are released yet
[17:59] <barry> ScottK: cool.  local build looked good, so i think i'll upload it :)
[18:00] <nikitis> and currently our kernel works with ubuntu, we have a separate kernel as well
[18:00] <nikitis> i'm sure things could be ported into ubuntu official kernel
[18:00] <Chipzz> infinity: legal issues might be a good bet ;P
[18:00] <nikitis> but as of now my installer compiles live on the PS3
[18:00] <infinity> nikitis: Releasing the drivers would be the best first step, yes.  And getting them integrated for oneiric.
[18:01] <nikitis> not my kernel though, another guys
[18:01] <nikitis> but he's given me permisison
[18:02] <nikitis> Okay well i have a good idea about what needs to be done to move forward
[18:02] <nikitis> When we finish disc drive drivers for new otheros.  I'll come back and start working on d-i ports
[18:03] <infinity> That would be lovely.
[18:03] <infinity> With no kernel, there's not a whole lot we can do.
[18:03] <nikitis> we get full SPU access too now.  Different from old PS3 linux
[18:03] <nikitis> Full RSX
[18:04] <infinity> If I had some free time, I'd work with you on integrating your non-upstream kernel with d-i in preparation for it being released, but I'm not sure that's something I can commit to just yet.
[18:04] <infinity> That said, feel free to email me and keep me in the loop (adconrad@ubuntu.com)
[18:04] <nikitis> well no need atm
[18:04] <nikitis> There is a workign installer
[18:04] <nikitis> released by myself.  Even if it's not accepted by the community
[18:05] <nikitis> may not be too hard to port over officially later
[18:06] <nikitis> Thanks for you time guys
[18:09] <Chipzz> nikitis: you also might want to join #debian-boot on irc.debian.org if you want to discuss integrating your installer into debian-installer
[18:13] <barry> ScottK: also, i think python-qt4 svn is ready for review
[18:15] <johan> Hi, sorry if this is not the right place to ask but I'm having trouble getting update-manager to install a .deb of mine which Provides/Replaces/Breaks another one
[18:16] <ScottK> barry: I've been looking at it.  I was to do sip4 at the same time, so figuring that out first.
[18:16] <barry> ScottK: cool
[18:21] <superm1> apw, since you're not subscribed to 812979, just wanted to make sure you saw that this is actually fixed in the latest version, just waiting for an archive admin to wack 811231
[18:37] <tilgovi> can anyone help me out with sbuild? it seems to completely fail for me on natty.
[18:43] <tumbleweed> tilgovi: how about providing some pastebinned errors :)
[18:44] <tilgovi> tumbleweed: one sec. I may have realized my stupidity. looks like I need both the .orig.tar.gz and the .dsc
[18:45] <tumbleweed> and the .debian.tar.gz / diff.gz :)
[18:45] <tilgovi> thanks!
[18:46] <tumbleweed> dget / pull-lp-source / apt-get source knows what to do
[18:46] <tilgovi> tumbleweed: can I use that to pull a specific series? I'm trying to roll my own backport.
[18:47] <broder> tilgovi: have you looked at backportpackage in ubuntu-dev-tools?
[18:47] <tumbleweed> tilgovi: pull-lp-source is the easiest for that. Also, there's a toolk called backportpackage in ubuntu-dev-tools
[18:48] <tilgovi> broder: no, didn't know it existed. thanks.
[18:48] <tilgovi> can it leverage sbuild for lvm snapshots, too?
[18:48] <tumbleweed> tilgovi: yes, it can use sbuild
[18:48] <broder> tilgovi: look at the --builder (-B) option
[18:49] <tilgovi> you're all awesome.
[19:18] <cody-somerville> soren, Hi. Currently the openstack-ubuntu-packagers team is subscribed to the lp:~openstack-ubuntu-packagers/glance/ubuntu branch. The MOTU team is a member of the openstack-ubuntu-packagers team which means that all MOTU get e-mails regarding merge proposals and the like. Is there a better team that could be subscribed for these things?
[19:19]  * tumbleweed can't say I've seen those mails
[19:20]  * ScottK neither.
[19:21] <cody-somerville> You didn't get '[Merge] lp:~antonym/glance/add-xattr into lp:~openstack-ubuntu-packagers/glance/ubuntu' about 20 minutes ago?
[19:22] <tumbleweed> cody-somerville: nope
[19:22] <MrNthDegree> hey guys, is there an easy way to enable install of all debug symbols for all packages?
[19:22] <MrNthDegree> (as in for all installed packages and when I install new packages)
[19:23] <stgraber> cody-somerville: I have membership in that team through DMB and Ubuntu Server Dev. So I guess you need to be part of one of these two.
[19:23] <MrNthDegree> the reason I ask is because it's a pain to wait on downloading specific debug packages whenever I need to submit a backtraced bugreport
[19:23] <cody-somerville> right
[19:23] <cody-somerville> MOTU team has contact address set
[19:24] <cody-somerville> so its probably one of my other routes of membership in that team like DMB that causes me to get the e-mails
[19:24] <stgraber> cody-somerville: ah, nevermind, LP was lying :) I get different data on https://launchpad.net/~stgraber/+participation and on https://launchpad.net/~openstack-ubuntu-packagers apparently :)
[19:24] <stgraber> but yeah, I receive these e-mails too and it's starting to be a bit annoying :)
[19:36] <Laney> X-Launchpad-Message-Rationale: Reviewer @openstack-ubuntu-packagers
[21:08] <micahg_> barry: are you planning on merging python 2.6.7-3 from Debian?  python-all in the archive is broke w/out it
[21:09] <micahg_> barry: otherwise, can the dependency be relaxed to 2.6.7-2? (I don't know what impact that will have)
[21:13] <micahg_> doko: you wouldn't happen to be around, would you ^^
[21:25] <barry> micahg_: oops!  i'll relax that dependency for now and leave it for doko to  merge -3 next week
[21:26] <micahg> barry: great, thanks!
[21:26] <micahg> doko: unping
[21:44] <micahg> barry: your upload had no diff aside from the changelog (forgot the .in file?)
[22:05] <fhd> Hi. I'm setting up a system for Ubuntu development, so I installed the latest daily build of oneiric. There is for some reason no /etc/X11/xorg.conf - how can I add more resolutions?
[22:06] <hallyn> fhd: check on #ubuntu-desktop I think
[22:07] <fhd> hallyn: k, thanks
[22:13] <soren> cody-somerville: Not really. It's implicitly subscribed on account of being the review team for the branches. We could remove ~motu from the team, though, but since all of ~motu can, so far, upload the packages, I think they should be members of the team.
[22:14]  * soren has to run
[22:19] <stgraber> soren: if you set a team contact address for that team, all these e-mails will go to it instead of being sent to everyone individually
[22:19] <stgraber> soren: this way, you keep the same rights but don't spam everyone with upload rights ;)
[22:19] <kirkland> jcastro: ping
[22:20] <kirkland> jcastro: isn't there a tool that you told me about some time that makes it trivial to just clone/forward a bug from Launchpad to Debian BTS?
[22:34] <ScottK> I'm guessing barry left without hearing his fix didn't work.
[22:34]  * ScottK will fix.
[22:35] <ScottK> OK, let's see how that works out ...
[22:45] <ScottK> micahg: Feel free to double check I fixed python-defaults correctly.
[22:51] <micahg> ScottK: you just needed to lower the one that was 2.6.7-3 to fix the archive issue, but I think that's fine (I personally don't understand the deps), thanks!
[22:53]  * micahg should probably learn how python packaging works at some point
[22:57] <apw> superm1, thanks for the info ...