[01:16] <psusi> mdeslaur: I see you got lvm2 merged... do you have any idea what the hell upstream-2.02.72.patch is?  the debian devs don't seem to bother ever documenting their quilt patches and the bzr commit that introduced it is rather terse.  It sounds like it is a diff to go from upstream .66 to .72, but then why is it  a patch rather than a new .orig.tar.gz, and why is the rev of the package still .66 instead of .72?
[01:17] <mdeslaur> psusi: let me take a look, hold on
[01:17] <mdeslaur> psusi: yes, that's what it looks like to me too
[01:17] <psusi> I've been trying to get that package updated for some time now and it's been a real pain trying to figure out these undocumented patches
[01:17] <mdeslaur> psusi: I don't know why they didn't just update to .72...
[01:18] <mdeslaur> oh, actually
[01:18] <mdeslaur> psusi: it may just be a diff between .71 and .72
[01:18] <mdeslaur> because that was a security fix
[01:19] <psusi> ahhh
[01:19] <mdeslaur> psusi: yeah, that's it...it's just the security fixes that were added for .72
[01:19] <psusi> I had updated to .76 and have been running that locally for a few months, testing out the snapshot merge support, but pitti wanted to avoid further divergence from debian
[01:21] <mdeslaur> psusi: maybe you could convince debian to go to .76 (or at least package that in experimental), then we could merge it
[01:54] <floam> for a package like zoneminder where it seems like it's mostly from debian unstable, should I report enhancement-ey bugs to ubuntu or to debian or both?
[01:55] <floam> (kinda late, already did it https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/691375 , but I'm trying to figure out the right way)
[01:58] <RAOF> floam: From the bug title it sounds like it also affects Debian, so filing a Debian bug (and linking it to the Launchpad bug) is a good idea.
[02:17] <floam> RAOF: thanks, will do
[06:24] <gs> i am a computer undergraduate and i want to contribute for ubuntu
[06:26] <gs> i need some guidance regarding how to start working for ubuntu development
[06:27] <RAOF> gs: So, what sort of thing are you interested in doing?
[06:28] <gs> i am interested in working on projects using c/c++
[06:28] <gs> i am also familiar with python
[06:29] <RAOF> So, almost all of the work involved in Ubuntu is done upstream; if you want to code, then picking a project and fixing something you find annoying that it doesn't do correctly is a good way to start.
[06:30] <gs> so i should work for debugging ??
[06:30] <RAOF> There are also a bunch of Debian/Ubuntu projects, many of which use Python (software-centre, apport, etc) or C/C++ (unity, upstart, apt)
[06:30] <RAOF> There's a huge amount to do; you can do whatever you want ☺
[06:30] <achiang> gs: the idea is to "scratch your own itch" -- find something in existing software today that makes you unhappy and fix it.
[06:30] <gs> actually sir i am interested in participating in gsoc so i wanted to be familiar with open source development procedure.
[06:32] <gs> RAOF : ok. so the idea is to take a source code and modify it according to my requirements
[06:32] <RAOF> Pretty much, yeah.
[06:32] <RAOF> If it's a simple change you do it first and then send a patch to the associated project (generally this is handled on mailing lists).
[06:33] <RAOF> If it's a more complex change it can often be worth sending a message to the mailing list outlining what you propose to do.
[06:34] <RAOF> Precisely what happens depends greatly on how the specific project is run.
[06:34] <gs> RAOF: ok. that sounds pretty interesting
[06:34] <gs> ok.
[06:34] <RAOF> Of course, there's *also* the option of wandering through bug reports on Launchpad and fixing them :)
[06:34] <gs> ok i will try that also
[06:35] <RAOF> But for gsoc you'll (probably) be working with an upstream project, so that's what I'd pick.
[06:35] <gs> ok ya i wanted to do something for that
[06:36] <gs> sorry but what do you mean by an upstream project?
[06:38] <RAOF> Almost all of the programs that make up Ubuntu aren't developed by us; they're developed by other people, each as their own separate project, and we do the integration work.
[06:39] <RAOF> So, projects like the linux kernel, X.org, GNOME, etc are “upstream” of us.
[06:39] <gs> ok so whats ubuntu ?
[06:40] <RAOF> We do the integration work; we take the code that upstreams release, optionally make some Ubuntu-specific changes, and build packages which conform to the various Debian policies.
[06:41] <gs> ok so i should start working for upstream projects rather than ubuntu
[06:41] <rigved> gs: ubuntu is much easier to work with than debian
[06:41] <gs> ok.
[06:41] <RAOF> rigved: That depends; and it's pretty much moot if you want to do upstream coding anyway.
[06:42] <gs> rigved : ok ya and i am ubuntu user so its a bit comfortable for me to work with ubuntu
[06:43] <rigved> RAOF: what i meant was that it's easier to use it. but yes ubuntu has made many things easier and safer to customise, like grub2 for example
[06:44]  * RAOF notes that our grub2 package is largely worked on *in* Debian :)
[06:44] <RAOF> I'll agree that Ubuntu is easier to use, though :)
[06:47] <rigved> RAOF: ok. well it's not there in lenny. maybe in squeeze. thanx for the info :)
[06:48] <RAOF> rigved: Oh, yeah.  You don't get the shiny new toys in Debian stable!
[06:50] <fargiolas> cjwatson: ping
[07:35] <cdbs> Package wmii depends on  suckless-tools | dwm-tools. Package dwm-tools is NBS and replacement is suckless-tools. However, I still get http://people.canonical.com/~ubuntu-archive/NBS/dwm-tools . IMHO if a package has choice depends (|) and one of them if available, then the other should be considered free of reverse-depends
[07:35] <cdbs> isn't it?
[07:37] <micahg> cdbs: it was dropped in the latest update
[07:38] <cdbs> micahg: In the latest update of what?
[07:38] <micahg> cdbs: latest sync of suckless-tools from Debian
[07:39] <cdbs> micahg: I know that. I am currectly talking about multiple possible depends, like: foo | bar | baz
[07:40] <micahg> cdbs: I'm saying, that's why you get the NBS and yes, it's rdepends free if it's an alternative
[07:40] <cdbs> micahg: package wmii depends on suckless-tools | dwm-tools , the former is a replacement of the latter, but still, it appears, that the script on people.canonical.com/~ubuntu-archive/NBS is taking it the wrong way
[07:40] <cdbs> micahg: yes, that's what I mean
[07:41] <micahg> cdbs: does that answer it sufficiently?
[07:41] <cdbs> yes
[08:32] <ebroder> cjwatson, tseliot: Apparently my IRC client has actually been bitbucketting traffic all day for me, so I missed the blacklist discussion until now. Please feel free to ping me if there's anything I can do to make the blacklists easier to manage
[09:42] <jibel> JamesPage, ping
[09:42] <JamesPage> jibel: pong
[09:44] <jibel> JamesPage, Hey, I've made some good progress on desktop iso smoke test using the server team work.
[09:44] <JamesPage> jibel: excellent; glad its been of use;
[09:44] <JamesPage> jibel: any issues or nuances you need a had with?
[09:45] <JamesPage> /had/hand/
[09:45] <jibel> JamesPage, Not really, I've done a small set of changes to the main script to adapt it to the desktop
[09:46] <jibel> JamesPage, and duplicated the templates directory.
[09:46] <JamesPage> jibel: makes sense; it would be good if we could consolidate the code base into a single project
[09:46] <JamesPage> jibel: maybe that would be a good objective to achieve during the platform rally in Jan
[09:47] <jibel> JamesPage, I use a casper hook instead of a preseed to install ldtp and download a script from couchdb which I autostart when the Live session user log in
[09:47] <jibel> JamesPage, I also had to increase memory and disk size, but basically that's all that needed to be changed.
[09:48] <bdrung> ebroder: do we really need the complicated chroots detection for sbuild.update() ?
[09:48] <JamesPage> jibel: sounds like we could easily consolidate then; I'd also like to abstract the tests from the rest of the code base;
[09:48] <ebroder> bdrung: We don't if we assume mk-sbuild, but I'd prefer not to make that assumption
[09:48] <JamesPage> jibel: so we can distribute a package for the code; but the test still come from a bzr branch
[09:49] <JamesPage> jibel: means they can be updated every time the tests are run using Hudson
[09:49] <ebroder> bdrung: sbuild-update and friends are really more schroot tools than sbuild. They take a chroot name. sbuild translates information about a target distribution and release into a chroot name using that logic (it's documented in sbuild(1))
[09:50] <jibel> JamesPage, sure, it can be easily done.
[09:50] <bdrung> ebroder: then i like to see the same translation logic in the sbuild-update and friends tools
[09:51] <ebroder> bdrung: mk-sbuild always uses %(distribution)-%(arch), but I've inherited configurations in the past that use %(distribution)-%(arch)-sbuild
[09:51] <jibel> JamesPage, I still have few bits to fix and I'll push my changes next week, then I'll need your review and help to integrate to hudson.
[09:51] <ebroder> bdrung: I'll make a note to open a bug with the sbuild maintainer. He's usually friendly
[09:52] <JamesPage> jibel: no problem
[09:52] <bdrung> ebroder: thanks
[09:52] <bdrung> ebroder: i'll fix sponsor-patch and merge your update-builder branch
[09:53] <ebroder> bdrung: Fix sponsor-patch?
[09:54] <ebroder> bdrung: Oh, that reminds me that I wanted to thank you for merging backportpackage, and also for pushing me on making the interface more flexible. I think that script has now completely replaced the functionality of 3+ simpler ones I've written in the past, not to mention innumerable hand-crafted shell loops
[09:55] <bdrung> ebroder: the update logic in sponsor-patch doesn't work correctly - i'll fix that
[09:55] <ebroder> bdrung: Ok, cool
[09:56] <bdrung> ebroder: one feature request left for backportpackage: an environment variable for the upload destination (e.g. BACKPORTPACKAGE_UPLOAD)
[09:56] <ebroder> bdrung: Oh, huh, that didn't make it to the todo list I was keeping. I'll add it back
[09:56]  * tumbleweed really must get around to the environment variable / connfille thing
[09:57] <tumbleweed> I thought I'd do that yesterday...
[09:58] <bdrung> tumbleweed: my idea, add the environment variable to devscripts config file - and then parse the files too
[09:58] <tumbleweed> bdrung: yeah, I like that idea
[09:58] <tumbleweed> it'll mean some central config parsing code for the whole of u-d-t, which will make it harder for people to just stick one of the scripts in ~/bin
[09:59] <ebroder> bdrung, tumbleweed: It would be kind of awesome if I could say something like ubuntutools.config.get_config('BUILDER') and it would check all of the permutations of os.environ[sys.argv[0].upper() + '_' + 'BUILDER'] and 'UBUNTUTOOLS_' + 'BUILDER' and so forth
[09:59] <tumbleweed> ebroder: yes, that's my plan
[10:00] <bdrung> tumbleweed: yes, and then putting the found variable into the environment
[10:00] <ebroder> tumbleweed: We're already moving in that direction. There's a *lot* of duplicated code right now, and I don't think it's a bad thing if that duplicated code consolidated into Python modules, even if it costs us the ability to drop things into ~/bin
[10:00] <tumbleweed> bdrung: yes and no, because you want the command line options to take precedence
[10:00] <bdrung> tumbleweed: look at our code - we use the env variable as default and override it with command line options
[10:01] <tumbleweed> bdrung: yes
[10:01]  * bdrung have to go  to university now.
[10:01] <bdrung> it's time to develop a compiler. :)
[10:01] <tumbleweed> sounds like you found a more interesting thesis topic than I ended up with :P
[10:02] <cdbs> heh
[10:03] <cdbs> BTW, should I go ahead with adding a command-line arg --pbuilder-dist in sponsor-patch to force usage of pbuilder-dist DISTRIBUTIONHERE rather than DIST=DISTHERE pbuilder whatever ?
[10:05] <tumbleweed> cdbs: no, I'd say pbuilder-dist should be supported as a Builder for u-d-t
[10:05] <cdbs> tumbleweed: hmmm?
[10:06] <cdbs> tumbleweed: so you mean all tools should support it?
[10:06] <ebroder> cdbs: Check out the ubuntutools/builder.py module bdrung just merged in from me
[10:06] <tumbleweed> cdbs: yes, there's a common builder abstraction in the ubuntutools package (in u-d-t)
[10:06] <cdbs> I have a slightly older version
[10:06]  * cdbs bzr pulls
[10:10] <cdbs> ebroder: so it doesn't have pbuilder-dist support yet
[10:10] <ebroder> cdbs: Correct, but it should be pretty trivial to add
[10:10] <cdbs> ebroder: yup, should I add? or you are adding?
[10:11] <ebroder> cdbs: I am not
[10:11]  * cdbs gets working :D
[10:38] <Keybuk> Admiral!  There be whales here!
[10:38] <Keybuk> deathspank calendar% ./nexttime2 "MDAY=-1"
[10:38] <Keybuk> Friday, 31 December 2010 00:00:00 GMT (+0000)
[10:38] <Keybuk> deathspank calendar% ./nexttime2 "MWDAY=-1THU"
[10:38] <Keybuk> Thursday, 30 December 2010 00:00:00 GMT (+0000)
[10:39] <Keybuk> (time_t of the last day in the month, and last Thursday of the month, respectively)
[10:43] <ev> \o/ well done
[11:00] <cjwatson> fargiolas: yes?
[11:55] <jhunt> apw: just so you know, my ppa rebuild for bug 683605 is due to start apparently in 7 hrs (!!! and will probably fail! :( )
[11:57] <jhunt> apw: annoying since there appear to be 4x idle i386 disto build machines.
[11:57] <apw> jhunt, can't you build it locally to test ?
[11:57] <apw> jhunt, but yes mine are in the morass too
[12:06] <StevenK> jhunt: The distro build machines are nothing like the ppa build machines ...
[12:10] <jhunt> apw: I've built it on maverick, but will need to spend some time getting a local natty build env setup. lp guys thought the failures I was seeing might be natty related. I'll find out...
[12:11] <jhunt> StevenK: we don't have xenmotion-type capabilities then?
[12:12] <StevenK> jhunt: The distro buildds are real hardware. So, it doesn't work that way.
[12:12]  * StevenK -> bed
[12:13] <jhunt> ah, I thought on the ppa boxes atleast VMs were being used.
[12:14] <cjwatson> yes, the PPA builds are in Xen
[12:14] <cjwatson> they're deliberately isolated so that a malicious PPA can't break the distro buildds
[12:14] <cjwatson> (or each other, for that matter)
[12:16] <cjwatson> jhunt: you may have trouble anyway since the earlier version you had failed to upgrade
[12:16] <jhunt> cjwatson: yeah, I'm struggling with this.
[12:16] <cjwatson> jhunt: which means that if you try to build a later version of util-linux in the same archive, it'll try to upgrade itself first and fail
[12:16] <cjwatson> jhunt: I'd recommend deleting the broken version from the archive first (you'll still need to use a later version number)
[12:17] <cjwatson> this strategy doesn't work for the distro itself - if this sort of thing happens there, we need to recover manually.  it's happened a few times
[12:18] <cjwatson> yeah, looks like that's what's happening.  deleting it then reuploading should help.
[12:18] <jhunt> cjwatson: thx!
[12:18] <cjwatson> (transitively) essential packages are such fun
[12:19] <cjwatson> actually not even transitively in this case, it's just plain Essential
[12:34] <AnAnt> Hello, please sponsor those merges: LP #691512 , LP #691448
[12:43] <diwic> Not knowing bazaar enough is one of my weaknesses, so excuse me for a (probably) newbie question.
[12:44] <diwic> If I do "apt-src install pulseaudio", it says:
[12:44] <diwic> NOTICE: 'pulseaudio' packaging is maintained in the 'Bzr' version control system at:
[12:44] <diwic> http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.natty
[12:44] <diwic> Please use:
[12:44] <diwic> bzr get http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.natty
[12:44] <diwic> to retrieve the latest (possibly unreleased) updates to the package.
[12:45] <diwic> But if I do that, I only get a "debian" subdirectory and not the upstream source.
[12:46] <diwic> Given that workflow, how do I get original source?
[13:15] <apw> diwic, does the packaging actually know how to get the source for you, sometimes you can debian/rules patch (or something similar)
[13:16] <diwic> apw, hmm, I think I solved the problem as it seems like bzr-buildpackage seems to go get the source for me; although I don't know from where it got that pointer
[13:17] <diwic> apw, but while you're listening, I'm not trying to push my branch with "bzr push bzr+ssh://bazaar..." but it asks for my canonical ssh key instead of a password
[13:17] <apw> diwic, have you logged in ?
[13:18] <apw> diwic, via bzr launchpad-login ?
[13:19] <diwic> apw, "bzr launchpad-login diwic" just returns after a moment, I'm assuming it does what it should
[13:19] <diwic> hmm
[13:19] <diwic> maybe I need to add the ssh key to the launchpad account?
[13:19] <apw> diwic, you need to have your ssh key in your account i think, the public part
[13:19] <apw> diwic, but i thought you needed that in there for our internal infrastructure too
[13:23] <diwic> apw, seems to have done it, thanks
[13:26] <jdstrand> seb128: hi! with the patch you backed out of compiz, my login hangs...
[13:26] <jdstrand> seb128: I think we can confirm this bug now ;)
[13:26] <seb128> jdstrand, :-(
[13:26] <seb128> jdstrand, can't win
[13:27] <jdstrand> seb128: fwiw, I did see the menu bug too, but oddly only after a few hours
[13:27] <seb128> njpatel, ^
[13:27] <seb128> it's going to be no fun, either way we are screwed
[13:28] <jdstrand> seb128: it there a bug for the stalled login?
[13:28] <jdstrand> (I don't have a usable desktop atm)
[13:28] <seb128> jdstrand, https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/690239
[13:28] <njpatel> seb128, urgh :/
[13:29] <seb128> jdstrand, starting the classic session doesn't work?
[13:29] <jdstrand> seb128: thanks. and finally-- is there something I can poke from a vt to get things going again?
[13:29] <seb128> jdstrand, are you sure compiz hangs?
[13:29] <seb128> like the process is running but hanging?
[13:30] <seb128> does ctrl-alt-right or left works?
[13:30] <jdstrand> I don't know what is hanging-- I login and I get a spinning cursor
[13:30] <apw> jdstrand, waht do you see? the background ?
[13:30] <jdstrand> apw: I see the background
[13:30]  * apw always recommends a windows-E to see if you get expose
[13:30] <jdstrand> ctrl+alt+right and left does nothing
[13:30] <apw> (likely not then)
[13:30] <jdstrand> windows+E does nothing
[13:31] <seb128> njpatel, is sam working today?
[13:31] <apw> i think rtg was seeing that failure mode too ...
[13:31] <seb128> jdstrand, here the classic session works
[13:31] <jdstrand> all I have in ps related to compiz is compiz-decorator
[13:31] <seb128> I had issue with the default one
[13:31] <seb128> jdstrand, seems similar to what I was having yesterday
[13:32] <jdstrand> seb128: well, right, I am kinda committed to the unity one since I blew away my gnome-panel gconf settings to run a small panel in unity
[13:32] <jdstrand> I do have a backup of those though...
[13:32] <seb128> jdstrand, well I can start the classic one, alt-f2, ccsm and activate unity
[13:32] <seb128> then I've a working unity session
[13:32] <seb128> the unity session in gdm is buggy in a way similar to what you get though
[13:33] <jdstrand> I thought didrocks expressly told me to *not* use ccsm to activate unity :)
[13:33] <seb128> I though that was maybe a local issue
[13:33] <seb128> jdstrand, well didrocks is away until eoy
[13:33] <seb128> I'm telling you what I did there
[13:33] <seb128> if you want a workaround to get back a working desktop...
[13:33] <jdstrand> hmm
[13:33] <jdstrand> seb128: I am not being testy, just thought it funny I got different info
[13:34] <jdstrand> :)
[13:34] <seb128> jdstrand, oh I didn't take it wrongly don't worry ;-)
[13:34] <seb128> I'm a bit annoyed by that compiz bug though
[13:34] <jdstrand> yes, me too ;)
[13:34] <seb128> it's being between a rock and an hard place
[13:34] <seb128> we have no compiz guy around today
[13:34] <seb128> then I'm on holiday as well until eoy
[13:35] <seb128> sucks if that stay this way for the next 2 weeks
[13:35] <jdstrand> well, I can downgrade compiz and live with the menus then
[13:35] <seb128> well it's not only you
[13:35] <seb128> but yeah, better menu issues than no desktop
[13:35] <seb128> jdstrand, can you try to downgrade to -0ubuntu1
[13:35] <jdstrand> that is way less painful than logging into classic, fiddling with my panel, starting unity, fiddling with my panel, etc
[13:35] <seb128> see if you get the issue as well?
[13:36] <seb128> jdstrand, why would you have to fiddle with those?
[13:36] <seb128> the panel config should be the same
[13:36] <seb128> ccsm and activate unity in your classic compiz config
[13:36] <seb128> you can alt-f2 to run it
[13:36] <jdstrand> I guess that's true
[13:36] <seb128> that's what I did there
[13:37] <seb128> the only difference between the sessions is the compiz plugin in use
[13:37] <apw> jdstrand, is that the no menus appearing on right click and stuff dissappearing issue ?
[13:37] <seb128> no
[13:38] <seb128> that's the side effect of rolling back the patch which created the menu issue
[13:38] <jdstrand> apw: I have nothing but a background. compiz didn't start
[13:38] <jdstrand> though compiz-decorator did
[13:38] <seb128> jdstrand, it's likely that compiz crashes
[13:38] <seb128> it does there
[13:38] <jdstrand> I suppose that's true about the gnome-panel-- I was thinking I need a working classic desktop. I do not
[13:39] <jdstrand> s/working/fully functional/
[13:43] <jdstrand> ok, going the classic route worked fine
[13:46] <seb128> jdstrand, ok, thanks, same issue than me then
[13:46] <jdstrand> seb128: I'm guessing since there are no compiz specialists around that there isn't a lot I can provide to help atm?
[13:47] <jdstrand> I also wonder if the next time I login to classic, if unity will try to start and then crash again...
[13:48] <jdstrand> seb128: do you still want me to try ubuntu1?
[13:48] <seb128> jdstrand, can you clean /var/crash, log in an unity session and see if it crashes?
[13:48] <jdstrand> yes
[13:49]  * jdstrand goes to try
[13:50] <mdeslaur> huh, indicator-sound isn't showing rhythmbox anymore
[13:52] <jdstrand> seb128: ok. I accidently logged into classic desktop and was pleased to see compiz did *not* crash even though I had the unity plugin checked
[13:52] <jdstrand> seb128: put to the point of your question
[13:53] <seb128> jdstrand, ok, I've the same issue there then
[13:53] <seb128> mdeslaur, try starting it once?
[13:53] <jdstrand> seb128: I logged in, I saw the unity launcher for half a second, it went away and compiz did crash, leaving a crash file in /var/crash
[13:53] <mdeslaur> seb128: nope, still not showing up
[13:54] <jdstrand> mdeslaur: weird, but it did before? I know yesterday or possibly the day before it was still there
[13:55] <mdeslaur> jdstrand: it worked fine until this morning updates and reboot
[13:55] <jdstrand> s/put/but/
[13:56] <jdstrand> seb128: that may not have all been clear. I accidentally logged into the classic desktop and it worked fine with unity (good). I then logged out, and back in with the unity desktop, saw the unity launcher for a moment, then compiz crashed with a crash file in /var/crash
[13:56] <seb128> jdstrand, can you upload the .crash to launchpad?
[13:56] <seb128> jdstrand, no, same than here, what I told you before
[13:56] <jdstrand> seb128: k
[13:56] <seb128> jdstrand, the unity session crashes but unity in a normal session works
[13:56] <seb128> I'm not sure why
[13:56] <jdstrand> seb128: apport-collect to a bug number or a new bug?
[13:56] <seb128> mdeslaur, try asking ronoc on #ayatana
[13:56] <mdeslaur> seb128: tanks
[13:56] <mdeslaur> s/tanks/thanks
[13:57] <seb128> jdstrand, new one, I couldn't submit mine because I've some other upgraded not done
[13:57] <seb128> jdstrand, so if your box is uptodate...
[13:57] <jdstrand> will do
[13:57] <jdstrand> it is
[14:09] <seb128> cjwatson (and pitti), thanks for the debconf libgnome cleaning ;-)
[14:11] <cjwatson> no problem, that's 660KB or so cleared
[14:11] <cjwatson> it's still not entirely free of deprecated interfaces, so may need further attention in future
[14:13] <bdrung> ebroder: merged
[14:25] <cjwatson> seb128: incidentally, do you read all of natty-changes or something? :)
[14:26] <seb128> cjwatson, I do go through the titles at least
[14:26] <seb128> ;-)
[14:26] <seb128> I stopped on debconf because I was waiting on that part of the stack to be able to go away
[14:28] <cjwatson> seb128: mvo's cleaning up the two remaining Recommends on it
[14:29] <mvo> seb128: uploaded
[14:30] <seb128> cjwatson, mvo: thanks ;-)
[14:31] <mvo> yw
[14:31] <doko> cjwatson: looking at http://launchpadlibrarian.net/60797448/buildlog_ubuntu-natty-i386.apturl_0.4.2ubuntu2_FAILEDTOBUILD.txt.gz
[14:33] <cjwatson> huh, didn't change anything in that area
[14:34] <cjwatson> ah, ok, python default change
[14:34] <cjwatson> doko: I can fix it if you like
[14:34] <doko> already doing
[14:34] <cjwatson> ok
[14:58] <jdstrand> seb128: bug #691561
[14:58] <jdstrand> seb128: I had to do my own apport-retrace since the crash report wasn't formatted correctly (lacked 'Package: compiz')
[14:58] <seb128> jdstrand, thanks
[14:58] <seb128> njpatel, ^
[14:58] <jdstrand> seb128: but it should be ok
[14:59] <njpatel> looking
[14:59] <seb128>  #1  0x00007f94bc80391d in UnityScreen::getWindowPaintList (this=<value optimized out>) at /build/buildd/unity-3.2.6/src/unity.cpp:246
[14:59] <seb128>          pl = @0x12b8d50
[14:59] <seb128>          xwns = @0x7fff5f672120
[14:59] <seb128> njpatel, ^ is unity bog
[15:00] <njpatel> well, it's a bad pointer
[15:00] <njpatel> from nux!
[15:00] <mvo> hm, how can it happen that we have a cups in maverick-updates that depends on "cups-ppdc" when the later is in universe?
[15:00] <njpatel>  :)
[15:00] <njpatel> mvo, !
[15:00] <njpatel> mvo, how are you :
[15:00] <njpatel> ?
[15:00] <njpatel> even
[15:00]  * njpatel can't type
[15:00] <mvo> hey njpatel - good, thanks!
[15:00] <mvo> and you?
[15:01] <njpatel> good thanks, looking forward to the break :)
[15:01] <mvo> me too :)
[15:02] <njpatel> jej
[15:02] <mvo> we have perfect winter weather, I will undust the sledge !
[15:02] <njpatel> heh*
[15:02] <mvo> lol
[15:02] <mvo> you really can't type today ;)
[15:02] <njpatel> mvo, no, which doesn't bode well for the unity release ;)
[15:03] <mvo> lol !
[15:05] <cjwatson> mvo: reminder about bug 671016, alpha-2-milestoned bug left over from last week's release meeting
[15:06] <mvo> cjwatson: cups in maverick-updates depends on cups-ppdc but that is in universe for maverick. is it possible to promote it in maverick-updates? if not I think I should uplodate a new version with cups-ppdc as a recommends instead a depends
[15:06] <mvo> cjwatson: EOL reminder> thanks
[15:07] <Keybuk> jhunt: you're good at coming up with random calendar schedules, can you think of a few tests?
[15:08] <jdstrand> mdeslaur: I can confirm rb is not in the sound indicator menu
[15:08] <jdstrand> mdeslaur: do you have a bug?
[15:08] <jhunt> Keybuk: how complex can we go here? Have we got knowledge of boot/resume times?
[15:08] <bdrung> geser, Laney, jpds: requestsync owns 13 of 45 ubuntu-dev-tools bugs. you touched the script. can you have a look at the bugs? https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools?field.searchtext=requestsync
[15:09] <Keybuk> jhunt: I think I've covered every reasonable complexity
[15:09] <Keybuk> durations are easy - this is more of the "last sunday of the year" variety
[15:10] <mdeslaur> jdstrand: bug 691556
[15:11] <cjwatson> mvo: normally we wouldn't, but since it's changed in -updates anyway, and since it's in main in natty, I think it's safe enough to promote
[15:12] <cjwatson> mvo: promoted, unless somebody screams at me really loudly
[15:12] <Keybuk> deathspank calendar% ./nexttime2 -c 3 "WDAY=SUN;HOUR=4;MIN=30;INTERVAL=2"
[15:12] <Keybuk> Sunday, 19 December 2010 04:30:00 GMT (+0000)
[15:12] <Keybuk> Sunday,  2 January 2011 04:30:00 GMT (+0000)
[15:12] <Keybuk> Sunday, 16 January 2011 04:30:00 GMT (+0000)
[15:12] <Keybuk> --
[15:13] <Keybuk> jhunt: e.g. every second sunday at 4:30am
[15:13] <jhunt> Keybuk: how about... last weekday of this year / 2nd tuesday after easter / first friday 2 months + 3 days from now.
[15:14] <Keybuk> can't do that first one
[15:14] <jdstrand> mdeslaur: thanks
[15:14] <mvo> thanks cjwatson
[15:15] <Keybuk> jhunt: I can do last day of the year, or last friday of the year, etc.
[15:15] <jhunt> Keybuk: oh - another nasty one: "Monday closest to 29th January" (aka "Auckland Anniversary Day")
[15:17] <Keybuk> nope, you can have last monday of jan or 1st monday of feb though ;-)
[15:18] <jhunt> Keybuk: can you discriminate between "every hour on the hour" vs. "every hour since boot/resume time"?
[15:18] <Keybuk> all of the rules I support are of the form "nth n in n"
[15:18] <Keybuk> jhunt: yes
[15:18] <jhunt> Keybuk: *awesome*
[15:19] <geser> bdrung: will try to triage them during the weekend. I've to think what I should do about the crashes somewhere down the chain towards LP API (mostly likely caused by timeouts)
[15:20] <Keybuk> can do things like "the day you get for xmas"
[15:21] <Keybuk> deathspank calendar% ./nexttime2 -b "25/12/2010" "WDAY=MON"
[15:21] <Keybuk> Monday, 27 December 2010 00:00:00 GMT (+0000)
[15:22] <jhunt> Keybuk: fwiw I think "remind" would handle the "last weekday of this year" scenario as "(first Friday of *next* year) - 7 days"
[15:23] <Keybuk> that doesn't necessarily give you the last weekday ;-)
[15:26] <jhunt> Keybuk: no, it also has to use scanning to slide back/forwards around a date looking for a goal.
[15:27] <Keybuk> yeah
[15:27] <Keybuk> we don't want upstart to be remind or calendar(1)
[15:30] <Keybuk> it's worth pointing out that as far as I could tell, remind works on the principle of "what time is it => do I have anything that I can run now?"
[15:30] <Keybuk> ie. same as cron
[15:42] <ari-tczew> after last updating natty, my pbuilder is broken
[15:42] <ari-tczew> E: File /root/pbuilder/natty-base.tgz does not exist
[15:42] <ari-tczew> pbuilder is installed
[15:44] <ari-tczew> and why it looks for natty-base.tgz in root instead in ~/pbuilder?
[15:44] <ari-tczew> yesterday pbuilder worked fine
[15:47] <seb128> could someone binNEW libzeigeist and dee?
[15:48] <seb128> they need promotion as well
[15:48] <seb128> the new unity will need those
[15:55] <mr_pouit> doko: thanks, hopefully, it should be the last abicheck.sh :p
[15:56] <doko> mr_pouit: please forward these upstream
[15:56] <doko> and debian
[15:56] <mr_pouit> yep, done already for upstream
[16:06] <seb128> hum
[16:07] <seb128> jdstrand, cjwatson, Riddell: ^ someone to do the 2 binNEW reviews?
[16:08]  * cjwatson needs to focus on release meeting just now ...
[16:08] <jdstrand> seb128: I am working on them today
[16:08] <jdstrand> cjwatson: ^
[16:09] <jdstrand> Riddell: ^
[16:09] <jdstrand> seb128: which 2 do you need right now?
[16:09]  * jdstrand was going oldest to newest
[16:09] <seb128> thanks
[16:10] <seb128> jdstrand, libzeitgeist and dee
[16:10] <jdstrand> k
[16:16] <mvo> doko: hm, maverick-updates has a newer glibc than natty, that makes the auto-upgrader unhappy
[16:17] <doko> mvo: I asked to copy it to natty
[16:17] <doko> cjwatson: ^^^
[16:17] <mvo> aha, thanks
[16:21] <cjwatson> doko: done
[16:23] <mvo> thanks cjwatson
[16:24] <jdstrand> seb128: done. I threw in vte for giggles
[16:25] <seb128> jdstrand, thanks
[16:26] <jdstrand> sure
[16:27] <rickspencer3> mvo, are you waiting for someone to provide you text for bug #671016
[16:27] <rickspencer3> ?
[16:28] <mvo> rickspencer3: I can write a page up, but someone (a native speaker) should have a look once its ready
[16:28] <mvo> rickspencer3: sorry, that its not done yet, I put it high on my list
[16:28] <rickspencer3> mvo, let me see if I can find someone to just write it for you
[16:28] <rickspencer3> mvo, no apologies necessary
[16:29] <rickspencer3> I'm just trying to make sure you have what you need
[16:29] <mvo> thanks rickspencer3
[17:18] <seb128> doko, or some other buildd admin?
[17:18] <seb128> can you get those score to build now?
[17:18] <seb128> https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2101832
[17:18] <seb128> https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2101831
[17:19] <seb128> that's a test build of the new unity
[17:21] <seb128> cjwatson, ^?
[17:21] <seb128> lamont, ^?
[17:21] <seb128> sorry but unity needs to land today
[17:21] <seb128> and I'm having issue building it
[17:22] <seb128> having that ppa build in less than 7 hours would be useful
[17:22] <cjwatson> I've scored both up
[17:23] <seb128> cjwatson, thanks a lot!
[17:23] <jdstrand> seb128: so, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, it seems (at least some) of the gir promotions are unseeded or not depended on. did I do too much or have you not finished your gir work yet?
[17:25] <seb128> jdstrand, this page seems buggy
[17:25] <seb128> jdstrand, apt-cache rdepends gir1.2-gconf-2.0
[17:26] <seb128> jdstrand, gir1.2-gtk-3.0 is a rdepends of apport and language-selector
[17:26] <seb128> not sure what's going on
[17:55] <marjo> hi folks
[17:56] <marjo> anybody else experiencing a startup problem after today's update to natty?
[17:56] <marjo> i do not get to a login screen, only a blank screen after initial ubuntu splash screen
[17:57] <marjo> this is with kernel-2.6.37-9 and kernel-2.6.37-7 behaves same
[17:58] <marjo> last message (text mode, removed quiet and splash) states " running /scripts/init-bottom done
[17:58] <marjo>  at the top, it says "loading, please wait"
[17:58] <marjo>  then it goes into that blank screen"
[18:08] <ebroder> marjo: Sounds like https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
[18:09] <ebroder> Well, maybe, depending on what you mean by "initial splash"
[18:09] <marjo> ebroder: yes, thx for the pointer
[18:28] <mterry> jdstrand, ping about libmono-system-data-linq2.0-cil needing to be in main
[18:29] <porthose> hey guys is there a list somewhere of companies that use ubuntu in an enterprise setting? I have a friend (a teacher) who is trying to convince the schools superintendent that FOSS is a good thing
[18:32] <charlie-tca> jcastro: Do you know where the list of enterprise users is?
[18:32] <jdstrand> mterry: is there a bug? (I have no context)
[18:32] <jcastro> is there such a list?
[18:33] <charlie-tca> I thought there was, but my memory fails me
[18:33] <mterry> jdstrand, I was going to fill out context if you were around  :)
[18:33]  * charlie-tca thinks it could be wrong again, too
[18:33] <mterry> jdstrand, so we got a new mono from debian auto-sync
[18:33] <jdstrand> mterry: I am around :)
[18:33] <mterry> jdstrand, it has a new binary package libmono-system-data-linq2.0-cil
[18:34] <mterry> jdstrand, and some main packages are failing to build because a lot of mono stuff depends on that package (for example, launchpad-integration fails)
[18:34] <cyphermox> slangasek, ping?
[18:34] <mterry> jdstrand, so I think it needs to be moved to main.  Changelog indicates some files from a previous package just got moved to a separate one
[18:34] <charlie-tca> porthose: ask in #edubuntu about schools
[18:34] <charlie-tca> That is made for them
[18:35] <porthose> charlie-tca, will do thx
[18:35] <jcastro> charlie-tca: yeah the only list I remember was one of schools
[18:35] <jdstrand> mterry: do you know off hand where System.Data.Linq was before?
[18:35] <charlie-tca> Thanks, jcastro
[18:35] <mterry> jdstrand, not off hand, let me find out
[18:35] <slangasek> cyphermox: hey there
[18:35] <seb128> Laney, ^
[18:35] <seb128> directhex, ^
[18:36] <seb128> jcastro, hey
[18:36] <cyphermox> slangasek, hey, so removing the /etc/hosts changing stuff in NM has just landed upstream. we'll rely on nss-myhostname at worst to always have a resolvable hostname
[18:37] <jcastro> seb128: hi
[18:37] <slangasek> cyphermox: yay :)
[18:37] <mterry> jdstrand, libmono-system-data2.0-cil
[18:37] <cyphermox> I'll upload NM with those bits soon, and file a MIR for libnss-myhostname
[18:37] <seb128> jcastro, new unity upload btw
[18:37] <slangasek> cyphermox: why do we need libnss-myhostname?
[18:37] <slangasek> cyphermox: Ubuntu *already* sets up /etc/hosts by default
[18:38] <cyphermox> slangasek, not necessarily needed, but it makes sure the hostname is resolvable in case it changes through DHCP or something
[18:38] <cyphermox> slangasek, I was still going to upload NM without recommending it yet, see if it ends up being necessary. I'd like to do some testing of that, I just need to find a way to setup a good testing rig
[18:38] <slangasek> "changes through DHCP" - does that mean NM will change the hostname if DHCP provides it with one?
[18:39] <slangasek> I would hope that's disabled by default
[18:39] <jdstrand> mterry: too easy. that was already in main. promoted. thanks for checking! :)
[18:39] <cyphermox> slangasek, that hasn't been removed
[18:40] <slangasek> cyphermox: "removed"?  Sorry, I was unaware that NM ever did anything of the sort
[18:40] <cyphermox> slangasek, unless we already disable that from dhcp's config, I can't recall
[18:40] <slangasek> I would scream bloody murder if NM ever changed my hostname :)
[18:40] <mterry> jdstrand, awesome, thnks
[18:41] <cyphermox> slangasek, so would I, but in some cases people may want it -- see office users in some very restrictive environments (like my former workplace)
[18:41] <slangasek> cyphermox: sure, but I would expect that to be a non-default option that gets explicitly enabled on the client
[18:41] <slangasek> so that's a special case, no need for libnss-myhostname to be installed in the common case
[18:42] <cyphermox> alright
[18:42] <cyphermox> did you file the bug about changing /etc/hosts yet? :)
[18:46] <cody-somerville> Is there any metrics on how long packages take to install to identify packages that might have performance issues in their maintainer scripts or what not?
[18:48] <slangasek> cyphermox: no....
[19:01] <ScottK> How slow is arm ...  It's sooo slow that two ia64 builders can build KDE faster than 8 arm builders.
[19:11] <JontheEchidna> ScottK: at least you could run the compiles off of a battery due to lower power consumption :P
[19:13] <micahg> should teh langpacks be much larger?
[20:08] <directhex> my scrollback is too small to see what seb128 wanted
[20:14] <ScottK> relevant backscroll delivered via PM
[20:15] <directhex> mterry: the assembly in libmono-system-data-linq2.0-cil used to be in libmono-system-data2.0-cil - that one assembly was moved out into a distinct package to avoid pulling in a ~6 meg dep chain when using system.data. we didn't see anything in debian that the move broke, but obviously launchpad-integration isn't debianish
[20:15] <directhex> although it shouldn't ftbfs, since mono-devel should pull it in...
[20:16] <mterry> directhex, right, but it builds in a main-only chroot, whereas linq2.0-cil was a new package and hadn't yet been promoted to main
[20:16] <directhex> i see
[20:16] <mterry> directhex, it was a good and correct change, just we had to fix stuff because of main/univers
[20:17] <directhex> i forgot that new packages on main source packages go to universe first
[20:17] <directhex> mterry: but at least now you know! :)
[20:17] <mterry> :)
[20:19] <directhex> mterry: dunno how meebey got a NEW package past debian-release, but he seems to have just the right way of fluttering his eyelashes
[20:20] <mterry> heh
[20:45] <barry> james_w: hi.  there are four pkgme branches waiting to be merged.  do you want me to take care of those?  would you do a quick review of my envar branch?  i want to do a bit more pkgme hacking but would like to get the existing mp's dealt with first
[20:53] <james_w> barry, merge them, and I'll review the env one in a short while
[20:55] <barry> james_w: cool
[21:30] <cjwatson> seb128: I figured out why component-mismatches was hopelessly wrong - should be fixed shortly
[21:30] <seb128> cjwatson, oh great, thanks
[21:31] <cjwatson> was related to a recent Launchpad change I made, and forgot about a transitional requirement to remove some old files
[21:31] <cjwatson> so effectively it was referring to Sources files from the 14th
[21:31] <seb128> ok
[21:32] <cjwatson> hmm, or maybe not!  what's going on
[21:33] <cjwatson> oh, more files to remove maybe
[21:33] <cjwatson> might need another LP change at some point then :-/
[21:34] <cjwatson> should at worst be able to tide it over manually until then
[22:11] <ScottK> barry: Looks like we'll want a newer cdbs (4.90) for python3-distutils.mk
[22:11] <barry> ScottK: earlier versions don't support py3?
[22:12] <ScottK> They don't have python3-distutils.mk (see POX's commits just now in #debian-python)
[22:12] <ScottK> Last I heard he was waiting for someone to do the CDBS stuff.  I guess he found someone.
[22:13]  * ScottK hasn't tried any Python3 stuff with CDBS, so no idea.
[22:13] <barry> ScottK: today is my last official work day of the year, so i likely won't get to it until 2011 ;)
[22:14] <sistpoty> you lucky one, I'll have to work until Dec 23.
[22:14] <ScottK> barry: OK.  Please mark it on your list for 2011 then.
[22:15] <barry> sistpoty: that's what you get for not taking vacation earlier in the year ;)
[22:15] <ScottK> Unless I hit a package that uses CDBS and I care about it having Python3 support, I'm unlikely to do it.
[22:15] <barry> ScottK: putting it on my todo
[22:15] <sistpoty> haha
[22:19] <sistpoty> buxy: btw, the new dpkg (as in 1.15.8.6ubuntu1, though I've seen it on unstable as well) is very bad wrt. perfomance on ext4, my feeling is that it's even worse than previous versions which called sync directly
[22:20] <sistpoty> s/ext4/ext4 on my sluggish system *g*/
[22:23] <cjwatson> sistpoty: 1.15.8.7 is coming soon with some important changes there
[22:23] <cjwatson> they're already in git
[22:24] <cjwatson> I'll merge it into natty as soon as I see it in unstable
[22:24] <sistpoty> cjwatson: oh, nice... :) are that the ones that have been proposed on debian-devel?
[22:24] <cjwatson> I have no idea
[22:25] <cjwatson> they were suggested by tytso in the relevant Debian dpkg bug
[22:25] <sistpoty> cjwatson: then I assume so, yes... thought these were already in, sorry
[22:29] <ebroder> bdrung: I wonder if update-maintainer (or possibly a successor) should also be expanded to handle things like Vcs-Bzr -> X-Debian-Vcs-Bzr
[22:29] <sistpoty> (oh, and sorry for the highlight/getting on your nerves buxy)
[22:29] <ebroder> bdrung: Or rather, I wonder if this is a good opportunity to have a discussion about policy-ifying that
[22:29] <bdrung> ebroder: yes, that's a good idea (there is a bug report for it)
[22:30] <bdrung> ebroder: i want to rewrite update-maintainer to fix bug #666504 and #688872
[22:30] <ebroder> bdrung: Yeah, that sounds good
[22:30] <bdrung> ebroder: we can fix bug #567629
[22:48] <bdrung> mdz: you wrote ubuntu-iso. can you please have a look at bug #637020
[22:50] <sistpoty> bdrung: it would be cool, if update-maintainer would use the same criteria that is taken into account for building a source package
[22:51] <bdrung> sistpoty: the source tarball creation will fail if "ubuntu" is in the debian version and that's what i was proposing.
[23:00] <sistpoty> bdrung: cool... I thought there was a slight difference between your proposal and source tarball creation in that anything that ends in ubuntu.com is accepted (but I've forgotten the details)
[23:01] <bdrung> sistpoty: i am not sure about that point
[23:02]  * sistpoty is neither, and can't find the source right now
[23:02] <bdrung> sistpoty: dpkg-dev
[23:14] <sistpoty> bdrung: actually it's' version contains ubuntu' and 'maintainer doesn't contain ubuntu' and 'env(DEBEMAIL), if set, contains @ubuntu.com' that makes the src-pkg build fail (Ubuntu.pm)
[23:15] <sistpoty> (at least from my reading right now)
[23:16] <bdrung> sistpoty: then my proposal is a valid subset
[23:20] <sistpoty> bdrung: no, it's not: changed-by: sistpoty@ubuntu.com; maintainer: ubuntu-motu@lists.ubuntu.com
[23:20] <sistpoty> bdrung: thought that's probably nitpicking ;)
[23:20] <sistpoty> -t
[23:21] <bdrung> sistpoty: the src-pkg build wont fail in your example
[23:25] <bdrung> sistpoty: what are you picking about?
[23:26] <sistpoty> bdrung: true, I guess if maintainer is someone@subdomain.ubuntu.com? (which shouldn't happen in the first place thought)
[23:27] <sistpoty> bdrung: it's really only nitpicking. I thought it would make an actual difference, and I was wrong, sorry
[23:29] <bdrung> sistpoty: if you want a different behaviour of update-maintainer, please respond to the mailinglist mail
[23:30] <sistpoty> bdrung: no, I don't... I just wanted to make sure right here that it matches dpkg-dev. Thanks for taking the time and explaining me that I was wrong ;)
[23:30] <bdrung> sistpoty: we just have to make sure that update-maintainer isn't less strict than the src-pkg build
[23:37] <xnox> bdrung, why can't we hook this thing into Ubuntu's dh_clean which checks for DEB_VENDOR and updates the maintainer automagically behind your back it is -ubuntu1 upload?
[23:37] <xnox> I really hate src-pkg build errors =) pointless and 100% automatable.
[23:37] <ebroder> xnox: That sounds really sketchy. I don't like my clean targets actually doing things
[23:37] <xnox> s/DEB_VENDOR/dpkg-vendor -qname/
[23:38] <bdrung> xnox: dh_clean is the wrong place
[23:38]  * xnox or whatever the call to dpkg-vendor was
[23:38] <xnox> bzr-bd pre-build hook?
[23:39] <ebroder> Better, but not sufficient so long as we're not exclusively using UDD
[23:39] <bdrung> xnox: sponsor-patch runs update-maintainer
[23:43] <xnox> bdrung, what about us non-uploading contributors?
[23:44] <bdrung> xnox: update-maintainer is only one command away