[00:38] <slangasek> Riddell: ping
[00:49] <Riddell> slangasek: I'm asleep
[00:49] <slangasek> Riddell: then I suggest putting down the keyboard, you don't want to wake up with keyboard marks on your face ;)
[00:51] <slangasek> Riddell: I was wondering what your take was on jcrigby's response that the kernel packages aren't really building the common headers package despite it being listed in debian/control.  Could these be accepted as-is with that explanation, or do you need us to get debian/control fixed up?
[00:55] <Riddell> slangasek: oh aye, sorry, I ment to process that today, his explanation seems reasonable enough
[00:55] <slangasek> Riddell: no worries! just wanted to make sure whether action was still needed on our side
[00:55] <Riddell> slangasek: I'll accept it now
[00:55] <slangasek> thanks! :)
[01:55] <twb> Is there a way to point rmadison at the partners repo?
[01:58] <cjwatson> twb: it already does by default
[01:58] <twb> rmadison -uubuntu opera ==> no hits
[01:59] <cjwatson> let me clarify that, it's already supposed to by default :-/
[01:59] <twb> Is that an ubuntu-only patch to devscripts?
[01:59] <cjwatson> rmadison talks to a server CGI script
[01:59] <cjwatson> it's up to the server what it shows
[01:59] <twb> Yeah, I thought maybe "by default" meant something bad like "we patched it to ask -uubuntu and -usomethingelse by default"
[02:00] <cjwatson> -uubuntu is the default if you're running rmadison on Ubuntu, but that's all
[02:01] <cjwatson> opera is genuinely not in partner
[02:01] <cjwatson> https://launchpad.net/ubuntu/+source/opera/+publishinghistory
[02:02] <cjwatson> try 'rmadison -uubuntu -S skype' instead as an example
[02:02] <twb> Hmm.
[02:02] <twb> http://archive.canonical.com/pool/partner/o/opera/
[02:02] <twb> That existed, which confused me
[02:03] <twb> skype works in rmadison, so it's A-OK
[02:09] <ScottK> Opera used to be there.
[04:31] <vorian> http://vorian-ubuntu.blogspot.com/feeds/posts/default
[06:45] <nukem> hey im trying to compile the vanilla linux kernel using make-kpkg however every time make-kpkg goes to make the actual Debian package I get a really weird error
[06:45] <nukem> it says dpkg-gencontrol: error: package linux-image-2.6.37-anfs+ not in control info
[06:45] <nukem> i never added the +
[06:46] <nukem> can someone please help me
[06:50] <poolie> if it's the vanilla kernel why does it have the anfs+ suffix?
[06:51] <nukem> I'm planning on adding some stuff to NFS(I havn't yet) so i added -anfs with the --apend_to_version arugment
[06:51] <nukem> to + got there on its own
[06:51] <nukem> which is really confusing me
[06:54] <nukem> the only thing I can think of is because I did a git checkout of the kernel source
[06:54] <poolie> i don't know, you'd have to trace into make-kpkg
[06:54] <poolie> see where it's getting that version from
[06:55] <nukem> so you think its a bug with make-kpkg?
[06:55] <poolie> mm, not necessarily
[06:55] <poolie> i wonder if you're meant to add that to the control file yourself
[06:55] <nukem> when I used make-kpkg on Debian(awhile ago I admit) I just had to run make-kpkg
[06:57] <poolie> just for curiousity, what is anfs?
[06:57] <nukem> I'm working on a senior design project which will add redundancy to NFS
[06:57] <nukem> RAID 1 like with multiple servers
[06:58] <nukem> we're also adding encryption and compression
[06:58] <poolie> interesting
[06:58] <poolie> have you done make-kpkg clean after changing the option?
[06:59] <nukem> every time
[07:00] <poolie> maybe it's a bug there then
[07:01] <nukem> hmm ill try debians kernel-package then
[07:01] <poolie> nukem, are you doing that in-kernel
[07:01] <poolie> personally i would be inclined to make a userspace client side proxy first
[07:01] <poolie> of course maybe that's not interesting enough for your project
[07:02] <nukem> it seemed easier to just add it to the kernel itself
[07:02] <nukem> plus I really want to get more into kernel development
[07:02] <poolie> it will be a bigger learning experience for sure
[07:02] <poolie> probably harder to debug though
[07:13] <startagainlol> elky here too darling
[07:17] <mneptok> startagainlol: please stop.
[07:18] <startagainlol> amazing somebody with manners
[07:18] <mneptok> elky: did you just see that?
[07:18]  * mneptok needs a reality check, STAT!
[07:19] <poolie> amazing indeed
[07:20] <Tm_T> prolly just got bored
[07:21]  * mneptok waves maniacally at poolie 
[07:21]  * elky blinks.
[07:21] <dholbach> good morning
[07:21]  * poolie waves more sedately
[07:21] <elky> Exceedingly amazing considering the homocidally racist chant he had going.
[07:22] <mneptok> elky: hold me. my reality is crumbling.
[07:22] <elky> Just find someone else's to substitute.
[07:23] <mneptok> i could probably borrow Jono's, but i'm not sure i want to live in a world of beer-dispensing electric guitars.
[07:23]  * maco2 suspects dholbach is now very confused
[07:23] <dholbach> hm
[07:23] <dholbach> ?
[07:24] <mneptok> dholbach: problematic user discussion.
[07:24] <mneptok> dholbach: set the alarm for 10m later and you can avoid this. :)
[07:24] <maco2> mneptok: nice euphemism
[07:46] <didrocks> good morning
[08:19] <dholbach> if you're on the ubuntu-sponsors mailing list, sorry for the spam - I'm reassigning old bugs from ubuntu-main-sponsors to ubuntu-sponsors, so we can get the team deleted
[08:46] <cdbs> dholbach: that ain't spam :)
[08:47] <cdbs> @pilot in
[08:49]  * dholbach hugs cdbs
[08:49]  * cdbs hugs dholbach 
[09:24] <jibel> cjwatson, ev when you have a minute can you look at my comments (21,22) in bug 650703 . I think the problem comes from the upstart job which starts too early and there's a race for some reason. Now I don't know the right fix.
[09:25] <ev> jibel: will do, thanks
[11:46] <lool> barry: computer-janitor-gtk depends on gir1.2-pango-2.0, but probably you meant gir1.2-pango-1.0?
[11:46] <dholbach> lool, where we go there's no room for "1.0" versions!
[11:46] <dholbach> lool, comment ça va? :)
[11:46] <lool> dholbach: Good good  :-)   you?
[11:46] <dholbach> great :)
[11:50] <lool> bah can't commit to the Vcs branch
[11:51] <dholbach> mvo and pitti maybe can?
[11:53] <lool> Ah didn't think of pinging mvo on that one
[11:53] <lool> pitti didn't seem to be around today
[11:53] <ogra> just upload, merge later ?
[11:53] <lool> ogra: I've uploaded commenting out Vcs-Bzr, yes
[11:53] <ogra> tsk
[13:14] <ogra> Riddell, is teher any trace of the new QT soon ? i really need NEON runtime detection now that unity-2d is on the armel images
[13:18] <janimo> ogra, upstream bugtracker shows 3 more bugs that need to be fixed
[13:18] <ogra> hrm
[13:18] <janimo> but that is the case for the past weeks I think
[13:18] <ogra> janimo, thanks
[13:18] <Riddell> ogra: doesn't seem to be
[13:19] <ogra> do you think it will arrive in time for natty ?
[13:19] <Riddell> I would expect so yes
[13:19] <ogra> or should we look at backporting the patch
[13:19] <ogra> iirc rsalveti pointed to a patch with only a few lines
[13:19] <Riddell> or just package a git snapshot
[13:20] <janimo> right
[13:20] <Riddell> also "Qt" :)
[13:20] <ogra> afaik the autodetection hasnt been tested even upstream yet
[13:20] <ogra> so getting it in asap would surely help
[13:21] <rsalveti> and maybe get it working for non neon devices for alpha 3
[13:21] <ogra> ++
[13:22] <ogra> so git snaphot would be good. yeah
[13:34] <ScottK> How about git snapshot in a PPA?
[13:34] <ScottK> Tossing semi-random Qt git snapshots into the archive is not a recipe for success, IMO.
[13:36] <ogra> ScottK, doesnt help building images
[13:36] <ogra> we really need that feature tested on the current images
[13:36] <ScottK> ogra: No, but it can be used to test NEON support.
[13:37] <ogra> well, if its clear that it makes natty a git snapshot wont do harm imho
[13:37] <ScottK> There are a LOT of packages in the archive that use Qt and we ought to be careful about introducint non-released versions of it.
[13:37] <ogra> if that isnt clear indeed then we should instead start backporting and testing the fix
[13:38] <ogra> in any case feature freeze is soon and we need it working
[13:38] <ScottK> I disagree it's OK to upload an untested Qt snapshot because it will get fixed eventually.
[13:38] <ogra> its a development release
[13:38] <ScottK> It won't work any better in the main archive than in a PPA test package.
[13:38] <ogra> if the bugs are fixed by release it should be fine
[13:39] <ScottK> There's no need to potentially break a lot of unrelated things and affect other people's work to see if this is fixed.
[14:00] <hallyn> jdstrand: jumping from libvirt 0.8.7 to 0.8.8, debuild gives me:
[14:00] <hallyn> dpkg-source: error: cannot represent change to libvirt-0.8.8/po/hr.gmo: binary file contents changed
[14:00] <hallyn> (lots of those)  what's the normal way to handle that?
[14:01] <jdstrand> hallyn: are you using the pristine upstream tarball?
[14:05] <hallyn> jdstrand: yes, as fetched by 'uscan'
[14:08] <jdstrand> hallyn: so, you should snag the upstream tarball, rename it libvirt_0.8.8.orig.tar.gz, untar it, drop debian/ into it, adjust debian/changelog, and then use debuild -S -sa
[14:08] <hallyn> i thought that was what uscan did
[14:08] <jdstrand> hallyn: actually, debuild -S -sa -v0.8.5-0ubuntu5
[14:09] <jdstrand> hallyn: I've not used uscan enough to advise on its use
[14:10] <hallyn> ok.  trying manual
[14:10] <hallyn> -v?
[14:10] <jdstrand> hallyn: that makes sure that the changes file has all the changes since that version
[14:10] <jdstrand> hallyn: it is useful for merges with Debian for example, where we want apt-listcahnges and update-manager to show all the changes
[14:11] <jdstrand> since the last version in Ubuntu
[14:12] <jdstrand> hallyn: you might want to look at 0.8.7-2 from Debian, and merge in those changes, rather than just grabbing 0.8.8 and using the updated ubuntu debian/ directory
[14:12] <smoser> @pilot in
[14:12] <jdstrand> hallyn: http://packages.debian.org/changelogs/pool/main/libv/libvirt/libvirt_0.8.7-2/changelog
[14:12]  * dholbach hugs smoser
[14:13] <smoser> dholbach, is that an automated response ? i feel like i'm getting a hug from a machine :)
[14:13] <dholbach> man - that's an original dholbach hug
[14:13] <dholbach> a machine, tststs :)
[14:13] <mvo> hallyn: I tend t use bzr-builddeb that automatically puts stuff into a build dir (and uses uscan if there is a tarball missing). very convinient IMO
[14:13] <hallyn> jdstrand: ok, my first version (without -v, as i'd started before you said that) seemed to succeed.  Which makes me wonder what the heck uscan does beyond what i need it to
[14:13] <mvo> d'hugmachine'holbach
[14:14] <hallyn> mvo: last time i tried a major new release merge (in qemu) with udd i got into trouble :)  so until i have more time to devote to it, i'm doing it the non-udd way
[14:15] <hallyn> mvo: i'll try it again,j ust not this week
[14:15] <mvo> hallyn: yeah, its quite different from the "normal" workflow, but once you get used to it I found it to be a real time-saver
[14:15] <mvo> (except for the slow initial setup when getting the branch(es) ready)
[14:16] <jdstrand> mvo: libvirt is source format v3 quilt
[14:16] <jdstrand> and we've not been able to get that working right with udd
[14:16] <hallyn> mvo: I really like it for bugfixes
[14:16] <jdstrand> (we as in us libvirt mergers)
[14:17] <mvo> jdstrand: aha, indeed
[14:18] <hallyn> jdstrand: i wonder how much ive been messing things up by not doing -sa and -v
[14:19] <hallyn> anyway, that worked.  shoulda done that from the start i guess
[14:19] <hallyn> jdstrand: thanks
[14:20] <jdstrand> hallyn: -sa ensures that the orig.tar.gz is uploaded. It may be added automatically with -0ubuntu.. and -1. I don't recall off-hand. -v isn't critical, but nice
[14:21] <barry> lool: i grabbed that dependency from pitti's branch.  i should have checked that more closely.  i see your fix this morning - thanks for that, i'll merge it and make sure you can commit to the branch
[14:22] <jdstrand> hallyn: so looking at the Debian changes, I think the way to go is -> perform 0.8.7-2 merge with Debian and get the debian/ dir in order, then create 0.8.8-0ubuntu1 based on the merged debian/ dir
[14:22] <lool> barry: ty
[14:22] <jdstrand> hallyn: what do you think?
[14:22] <jdstrand> (it is certainly what I would do)
[14:23] <jdstrand> hallyn: if we don't, we'll be diverging pretty far from Debian
[14:26] <lool> barry: Just tested the fixed packages, start fine; I've spotted a minor issue with them: (computer-janitor-gtk:29179): Gtk-WARNING **: Could not load image 'computerjanitor-24x24.png': Impossible d'ouvrir le fichier « /usr/share/computer-janitor/computerjanitor-24x24.png » : Aucun fichier ou dossier de ce type
[14:26] <lool> barry: This seems to be missing from debian/computer-janitor-gtk.install
[14:27] <hallyn> jdstrand: i think...  that sounds like in the short term making a lot of work for ourselv es given that we have a working build
[14:27] <hallyn> jdstrand: but long term it may pay off
[14:27] <lool> barry: Hmm actually, the issue is that the .ui uses the 24x24 filename instead of just computerjanitor
[14:27] <hallyn> jdstrand: I'm goign to upload what I have now to people.canonical.com.  When I finish some other stuff I"ll look at the debian package
[14:28] <jdstrand> hallyn: well, that is the nature of merges. I think you have permanently forked qemu-kvm iirc. That is not normal operating procedure, and I personally have strived to stay close to Debian
[14:28] <jdstrand> hallyn: and by 'you' I mean the server team
[14:29] <jdstrand> hallyn: but since you, hallyn, work on that and libvirt primarily, it might seem like a not bad idea...
[14:29] <hallyn> jdstrand: yes, I do prefer being close to debian for many reasons.
[14:29] <hallyn> I'm just saying I don't have time for that right now
[14:29] <jdstrand> hallyn: the problem is that things will get very weird if we upload an 0.8.8-0ubuntu1 without Debian's changes, and then 0.8.8-0ubuntu2 that does
[14:30] <hallyn> jdstrand: how far have we diverged so far?
[14:30] <jdstrand> hallyn: I wasn't aware that Debian had 0.8.7 until Daviey mentioned it this morning
[14:30] <hallyn> hm
[14:30] <jdstrand> hallyn: 0.8.5-1 entered experimental in November
[14:31] <hallyn> all right, then I guess forgetabout what I've uploaded so far
[14:31] <jdstrand> hallyn: our 0.8.5-0ubuntu1 predated that
[14:31] <hallyn> I'm 100% in favor of reducing packages for which we have to have custom bug handling :)
[14:31] <barry> lool: gotcha, i'll check that too
[14:31] <jdstrand> hallyn: so we did the right thing in november. but they have 0.8.7 now, we don't. the right thing to do is to merge, then pull in 0.8.8
[14:32] <hallyn> jdstrand: any good reason not to just merge 0.8.7 and ask debian to take any other patches we need on top of that?  (like the arm tests failures)
[14:32] <jdstrand> hallyn: would you have time before FF?
[14:32] <hallyn> jdstrand: iow, ignore 0.8.8 for now
[14:32] <hallyn> jdstrand: is that next tuesday?
[14:32] <jdstrand> hallyn: we should be pushing everything back if possible
[14:33] <jdstrand> hallyn: they don't have apparmor yet, so those can be skipped
[14:33] <hallyn> jdstrand: I don't know, bc you have a boatload of patches in there :)
[14:33] <jdstrand> hallyn: that boatload predates me btw :)
  I"ll aim to do that tomorrow
[14:33] <hallyn> ok, s/you/our libvirt package/ :)
[14:33] <jdstrand> hallyn: hehe
[14:34] <jdstrand> hallyn: but giving everything back to Debian is another issue
[14:34] <hallyn> jdstrand: yes, I like the fact that this roadmap makes it *feasible* to send the patches back to debian
[14:34] <jdstrand> hallyn: that is long-standing
[14:34] <hallyn> (so far it hasn't been)
[14:35] <lool> barry: LP #720743
[14:35] <hallyn> all right, i put that in my tickler file for tomorrow.
[14:35] <jdstrand> hallyn: it has been difficult because we have been ahead of Debian a lot with that package
[14:35] <barry> lool: thx!
[14:35] <lool> barry: I'm thinking the quickest way is adding the 24x24 to the setup.py + gtk.install file
[14:35] <lool> but that might not be the most correct way
[14:35] <hallyn> cjwatson: the grub2 in qemu with VBE bug (bug 717445) is bisected down to the offending commit, fwiw
[14:35] <jdstrand> hallyn: so, your plan is merge Debian 0.8.7-2, maybe snag the upstream patch for that kernel/virtio bug, and then have me review?
[14:36] <hallyn> jdstrand: yup (i'll also need those two patches for the arm+ppc tests failure)
[14:37] <jdstrand> hallyn: sure. definitely include your 0.8.7 work as part of the new ubuntu delta
[14:38] <jdstrand> hallyn: I think your plan is good. it'll actually give us the opportunity to get in sync with Debian again, and have them take our delta. that wasn't really possible before since the patches changed each time
[14:38] <hallyn> jdstrand: actually that reminds me.  FOr the last few days, 'debuild' has been adding a 'debian-changes-xyz' patch at the top of my quilt patchset.  What is that about?
[14:38] <hallyn> jdstrand: \o/  :)
[14:39] <jdstrand> hallyn: you have changes made outside of debian/. the source format v3 noticed this and helpfully created a patch for you
[14:39] <jdstrand> hallyn: you should loke at that patch and make a proper quilt patch
[14:39] <jdstrand> s/loke/look/
[14:40] <hallyn> jdstrand: feh.
[14:40] <cjwatson> hallyn: hmm, that is pretty big
[14:40] <hallyn> (I just deleted all and re-did dpkg-source x whenever that happened)
[14:40] <hallyn> cjwatson: yeah :(
[14:40] <cjwatson> hallyn: what I really need is a way to reproduce this with grub-mkrescue
[14:40] <hallyn> cjwatson: but it's clearly VBE related
[14:40] <hallyn> cjwatson: bc it affects all the bioses built with VBE (-vga std, -vga vmware)
[14:40] <cjwatson> hallyn: having to build an entire lucid ISO image for it is going to take too long
[14:41] <hallyn> cjwatson: ok, I was goign to look at the patch in more detail, just wanted to check if something obvious spring out at you
[14:41] <jdstrand> hallyn: one thing about quilt source v3 is it makes sure that you use quilt as the patch mechanism rather than letting you sneak in things outside of it
[14:41] <hallyn> cjwatson: as for grub-mkrescue - i just need to go RTFM and learn how to use it
[14:41] <cjwatson> hallyn: BTW that also doesn't explain why it's allegedly broken in maverick
[14:41] <jdstrand> hallyn: anyhoo, sounds like you are on track. thanks for all your work on it! :)
[14:41] <hallyn> cjwatson: why, is that commit in maverick's grub?
[14:42] <cjwatson> yes
[14:42] <hallyn> jdstrand: thanks, hopefully i'll be checking in with you tomorrow afternoon :)
[14:42] <hallyn> cjwatson: #(*&$(*#&$
[14:42] <hallyn> then i should probably un-dupe that other bug
[14:42] <cjwatson> hallyn: TBH it seems a bit coincidental to me
[14:42] <cjwatson> hallyn: adding those extra drivers might cause GRUB to use them rather than VBE
[14:43] <cjwatson> (they're preferred if available)
[14:43] <cjwatson> hallyn: but that would still leave the VBE module itself broken
[14:43] <jdstrand> hallyn: and I will be more responsive :) (I had a couple of security updates I'm trying to get out before tomorrow)
[14:43] <cjwatson> this is why it needs to be cut down to a situation with grub-mkrescue
[14:43] <hallyn> ok, let me send out this patchset i have to get out, then i'll go RTFM on grub-mkrescue
[14:43] <cjwatson> because that isolates us from changes in the configuration file machinery
[14:43] <hallyn> jdstrand: np.  keep me safe :)
[14:44] <barry> lool: just wondering too, if you know anything about the dbus.proxies.Introspect error (bug 715707).  it's new in natty - same code in maverick does not produce that error
[14:44] <cjwatson> with an upstream tree of lucid vintage, we're probably talking something like:  PATH=.:$PATH ./grub-mkrescue --output=grub.iso disk
[14:44] <cjwatson> where disk is a directory containing boot/grub/grub.cfg as you see fit
[14:45] <cjwatson> the syntax changed around later, but that was post-maverick
[14:45] <cjwatson> sorry, no, between lucid and maverick
[14:45] <cjwatson> in maverick vintage, it's:  ./grub-mkrescue --grub-mkimage=./grub-mkimage --override-directory=. --output=grub.iso disk
[14:46] <cjwatson> and nowadays that would be --override-directory=grub-core instead
[14:46] <lool> barry: It's quite certainly some dbus policy which is missing, not sure where
[14:47] <barry> lool: yep, probably from the janitord policy, but it has to be some change to dbus or python-dbus since mav
[14:47] <barry> lool: oh well, no worries
[15:04] <hallyn> cjwatson: thanks
[15:47] <JordiGH> I created an i386 .deb, compiled on 10.10 machine, but when I install it on a i368 machine with Software Center, I get a large warning that the architecture is wrong, but the package installs anyways. Any clues?
[15:48] <cjwatson> show us the package
[15:48] <JordiGH> The binary, or just the debian/ directory?
[15:49] <cjwatson> both, for preference
[15:49] <JordiGH> Okay... the actual source is like 500 megs, so I'd rather not upload that
[15:49] <cjwatson> no need for the full upstream source
[15:55] <JordiGH> Ok, uploading, this is gonna take a while...
[16:18] <JordiGH> ze debian/ dir: http://jordi.platinum.linux.pl/debian.tar.gz
[16:19] <JordiGH> ze .deb http://jordi.platinum.linux.pl/goweb_0.9.1_i386.deb
[16:19] <cjwatson> the second is 404
[16:19] <JordiGH> Durr...
[16:19] <JordiGH> http://jordi.platinum.linux.pl/goweb_0.9-1_i386.deb
[16:20] <azeem> I read that as platform and thought you'd be running for DPL
[16:20] <cjwatson> JordiGH: what's the exact error message you get?
[16:20] <JordiGH> Nah, Stefano is doing a good job.
[16:20] <cjwatson> the source and binary there look fine
[16:21] <JordiGH> cjwatson: It's in Spanish... Uhm, a big warning flashes on top of Software Centre and say the architecture is wrong... Let me find it again.
[16:21] <cjwatson> I'd rather have the exact Spanish message than anything else
[16:21] <cjwatson> at least I can look that up in .po files
[16:21] <cjwatson> also, does this package live in an apt repository?
[16:22] <JordiGH> No, it's for a small startup.
[16:23] <cjwatson> that seems like a non sequitur, but OK
[16:24] <JordiGH> Like, we're not doing this properly.
[16:24] <JordiGH> We just have one giant package that should include most of everything in one place.
[16:24] <JordiGH> It's a rebranded/modified xbmc, and Marillat has packaged this properly.
[16:25] <JordiGH> I'm about to leave the startup, so I want to give them a monolithic package that will be easier for them to understand.
[16:27] <cjwatson> was the error "No se encuentra disponible para su arquitectura hardware."?
[16:27] <JordiGH> Hm, no.
[16:28] <JordiGH> It was "Perdón, «goweb» no está disponible para este equipo (i386)"
[16:28] <JordiGH> Now that I read that, it's not about architecture?
[16:28] <JordiGH> It sounds like it's about architecture because it's mentioning it.
[16:29] <JordiGH> But I think it's complaining that the package isn't available from an apt source?
[16:29] <cjwatson> I can't find that string in software-center
[16:29] <JordiGH> Well, without «goweb», that's the name of te package.
[16:29] <JordiGH> the
[16:29] <cjwatson> sure
[16:29] <Chipzz> one giant package... ugh. /me has nightmares about zimbra :/
[16:29] <cjwatson> I know enough to avoid the obvious substitution elements :)
[16:30] <JordiGH> cjwatson: Is the .po available via web?
[16:30] <cjwatson> probably
[16:30] <cjwatson> don't ask me where
[16:30] <cjwatson> what version of Ubuntu is this?
[16:30] <JordiGH> 10.10
[16:30] <cjwatson> the system where you're running software-center, I mean
[16:30] <Chipzz> cjwatson: could it be an error from apt/python-apt or sth of the sort?
[16:30] <jpds> That does sound like an architecture problem.
[16:31] <cjwatson> Chipzz: certainly possible, but I also grepped apt and came up with nothing
[16:31] <cjwatson> I'll grep the language pack in a minute
[16:31] <Chipzz> doesn't rosetta have a search function?
[16:32] <JordiGH> Ugh, I gotta login to launchpad in order to download a translation?
[16:32] <JordiGH> https://translations.launchpad.net/software-center/trunk/+pots/software-center-doc/es/+translate
[16:33] <JordiGH> And looks like it needs javascript as well.
[16:33] <JordiGH> wtf
[16:34] <cjwatson> complaining about LP here is useless - we don't work on it
[16:34] <cjwatson> are you sure it wasn't "... para este tipo de equipo"?
[16:34] <JordiGH> That could be it, I might have omitted a word when I was copying it.
[16:34] <JordiGH> It flashed rather quickly on the screen.
[16:34] <cjwatson> #: ../softwarecenter/db/application.py:420
[16:34] <cjwatson> #, python-format
[16:34] <cjwatson> msgid "Not available for this type of computer (%s)."
[16:34] <cjwatson> msgstr "No disponible para este tipo de equipo (%s)"
[16:34] <JordiGH> Yeah, that sounds like it could be it. Except it's missing the apology.
[16:35] <cjwatson> ah, sorry, different one
[16:35] <cjwatson> msgid "Sorry, '%s' is not available for this type of computer (%s)."
[16:35] <cjwatson> msgstr "Perdón, «%s» no está disponible para este tipo de equipo (%s)."
[16:35] <JordiGH> Yes, that's it!
[16:36] <cjwatson> how are you getting this solitary .deb that isn't in an apt repository into software-center?
[16:36] <JordiGH> I double click on it from nautilus.
[16:37] <cjwatson> bug 694963
[16:37] <cjwatson> I think that you can very probably work around this by putting it in an apt repository
[16:37] <cjwatson> that's my guess from drive-by reading the source, anyway
[16:38] <JordiGH> Hm.
[16:38] <JordiGH> I see.
[16:38] <cjwatson> mvo: ^- FYI
[16:39] <JordiGH> Thanks again, quite helpful.
[16:39]  * JordiGH still feels in very foreign lands in Ubuntu.
[16:40] <JordiGH> cjwatson: Btw, re the Octave thing the other day...
[16:40] <JordiGH> http://octave.1599824.n4.nabble.com/Ubuntu-and-Debian-packaging-td3299300.html
[16:41] <ari-tczew> next bintuils upgrade?
[16:41] <ari-tczew> I noticed package which built yesterday, today is not buildable
[16:42] <cjwatson> JordiGH: I can understand his viewpoint
[16:42] <ari-tczew> good idea a week before feature freeze
[16:42] <JordiGH> cjwatson: Maybe, but it's distressing for me to know that most of the users of my package see a buggy version of it.
[16:42] <cjwatson> it's great when people are happy to read our bugs directly, but it's fair to say "sorry, I'm already swamped"
[16:44] <JordiGH> I'd like to just *hear* about it. I could have done something about that bug in the 6 months nobody looked at it.
[16:45] <cjwatson> if you want to get reports yourself, and other folks on pkg-octave-devel don't want to, then the right answer seems to be for you to subscribe yourself directly to the derivatives keyword (or whatever) in the PTS
[16:45] <JordiGH> I may have not, but it's distressing when a bug in a package I worked on doesn't even get an acknowledgement in six months and most of my users are experiencing that bug.
[16:45] <JordiGH> Well, there only seems to be one other person besides me and Thomas.
[16:45] <JordiGH> I'll ask them.
[16:45] <JordiGH> Well, him.
[16:46] <cjwatson> if I were in your shoes, I would just subscribe directly
[16:46] <cjwatson> it seems the course of least resistance, given that Thomas has explicitly objected
[16:46] <cjwatson> why have that argument when you don't need to? :)
[16:49] <JordiGH> Because I don't want to become an Ubuntu developer either.
[16:49] <cjwatson> uh
[16:49] <JordiGH> And I *do* want other members to at least know about Ubuntu bugs.
[16:49] <cjwatson> sorry, I don't see the connection
[16:49] <JordiGH> I don't want to feel responsible for Ubuntu bugs either.
[16:50] <cjwatson> anyone can subscribe to keywords in the Debian PTS - that facility isn't even offered by us
[16:50] <JordiGH> I'd start to feel like that if I knew I was the only one in the DOG that was reading Ubuntu bugs.
[16:50] <cjwatson> I'm not sure I can really help you with this, then. :)
[16:50] <cjwatson> perhaps create another mailing list?
[16:50] <JordiGH> I'll ask Sébastien. If he objects to that as well, then it's clear.
[16:50] <cjwatson> pkg-octave-derivatives or something
[16:51] <JordiGH> pkg-octave-ubuntu, let's call a space a fucking shovel.
[16:51] <JordiGH> It's not derivatives, it's Ubuntu, because that's where the vast majority of our users are.
[16:51] <micahg> !ohmy | JordiGH
[16:51] <cjwatson> whatever you like, it was just a suggestion
[16:52] <JordiGH> micahg: A пиздатая shovel.
[16:52] <micahg> JordiGH: :)
[16:54] <SpamapS> JordiGH: that makes me wish I had an auto-translator in my chat client so I didn't have to figure out what it means in.. I'm guessing Russian due to the Cyrillic chars.
[16:55] <JordiGH> SpamapS: Probably, unless I misspelled.
[16:55] <JordiGH> My Russian spelling is terrible.
[16:58] <JordiGH> cjwatson: I find the argument of comparing Ubuntu to 120 derivatives very facile. It's not just another distribution, and paying attention to Ubuntu doesn't mean you have to pay attention to 120 other derivatives.
[16:59] <cjwatson> if you don't mind, I would rather not have this argument
[16:59] <cjwatson> I didn't name the PTS keyword
[17:00] <cjwatson> and as an Ubuntu developer I would prefer to be gracious to other derivatives, anyway
[17:00] <cjwatson> but as I say, just a suggestion, the name is unimportant to me
[17:01] <canesin> Hi all... I have added Spinbottoms for my project in Glade but it looks like it is "not spinning" when running it
[17:15] <mvo> thanks cjwatson, let me read scrollback
[17:16] <mvo> JordiGH: that was for goweb you said?
[17:16] <JordiGH> mvo: Yeah. The download link is above, if you want to try it.
[17:17] <JordiGH> It's a pretty simple package, and I want to keep it that way, because I have to pass it on to people who barely know their way around bash. ;-)
[17:17] <mvo> JordiGH: I get a 404 for http://jordi.platinum.linux.pl/goweb_0.9.1_i386.deb
[17:18] <JordiGH> I corrected the link... :P
[17:18] <mvo> aha, have it now
[17:20] <canesin> Hi all... I have added Spinbottoms for my project in Glade but it looks like it is "not spinning" when running it
[17:21] <mvo> canesin: try .start() on the spinner
[17:22] <canesin> mvo: In the glade itself ??
[17:22] <canesin> mvo: or should I add a signal to it ?
[17:22] <mvo> in the py or C code
[17:24] <canesin> AttributeError: 'gtk.SpinButton' object has no attribute 'start'
[17:26] <mvo> ups, sorry, misread. I though it was a  gtk.Spinner()
[17:27] <canesin> mvo: =) ..
[17:27] <canesin> mvo: Do you know how i should proceed ?
[18:25] <h0ar3> guys I have cloned Linus' kernel branch
[18:25] <h0ar3> how can I compile and install it for ubuntu
[18:31] <penguin42> h0ar3: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[18:32] <ricotz> cjwatson, hello :), is there a bzr packaging branch of gnupg?
[18:32] <h0ar3> penguin42: awesomely helpful
[18:32] <h0ar3> thanks
[18:36] <ricotz> cjwatson, if not perhaps could look at this merge http://people.ubuntu.com/~ricotz/gnupg/
[18:42] <smoser> @pilot out
[18:57] <chrisccoulson> "On 2005-02-16 00:00z (2192 days 18 hours 31 minutes ago), you uploaded a translation template for firefox in Ubuntu Maverick package "firefox" in Launchpad. The template has now been imported successfully."
[18:57] <chrisccoulson> nice!
[18:57] <chrisccoulson> about time ;)
[18:57] <micahg> ah, not just me :)
[18:57] <chrisccoulson> lol
[18:58] <micahg> that date seems a little off though ;)
[18:58] <chrisccoulson> yeah, i must have uploaded to the future
[19:02] <dpm> chrisccoulson, I was just explaining it to micahg on #launchpad :)  that's because a bug was fixed yesterday in Firefox translations in LP and we needed to upload a new template to clean up the one imported last. We noticed that yours had never been imported and that manually approving them would be much easier than regenerating a new one. The funny date is because we bumped the priority in the imports queue by making it much older (oldest templates are
[19:02] <dpm>  imported first)
[19:02] <dpm> there were two templates pending import, approving one made the other one be approved as well
[19:05] <cjwatson> ricotz: no idea.  sorry, doing too many things right now to be able to look at it.  perhaps you could add it to the sponsors queue
[19:08] <ricotz> cjwatson, ok, do i need special rights to upload there? could you point me to a wiki howto?
[19:10] <ricotz> cjwatson, nvm, i will file a bug
[19:52] <GunnarHj> tedg: Hello Ted, new attempt today?
[19:53] <tedg> GunnarHj, Sure
[19:53] <tedg> I'm only making kenvandine's life difficult today -- I can take a little break from that. ;)
[19:54] <GunnarHj> tedg: Ok. :) It's https://launchpad.net/bugs/636693 I'd like to discuss with you.
[19:55] <kenvandine> thx tedg
[19:56] <tedg> GunnarHj, Yes, /usr/bin/guest-session should definitely not be locking the session :)
[19:59] <GunnarHj> tedg: But why not? The argument you initially mentioned on the bug, that there might be situations when no screen locking should take place, is not valid any longer, since locking now is a condition for launching a guest session.
[19:59] <tedg> GunnarHj, Why is it a condition?
[20:01] <ohsix> hm, why does aptitude try and remove everything i've installed via apt-get the first chance it gets; clean install (my old install didn't, i suspect it had to do with some Recommends related setting)
[20:01] <GunnarHj> tedg: Because the whole idea with gdm-guest-session is to restrict access - if you wouldn't lock the session from where the guest session is launched, you could as well let the guest use the regular session.
[20:02] <tedg> GunnarHj, I use guest session all the time where restriction isn't the issue, it's having a clean set of preferences to make sure a package works.
[20:03] <tedg> GunnarHj, I think there's also a use case for "don't mess up my settings" more than "restrict access"
[20:09] <GunnarHj> tedg: Hmm... Then you use it as a developer tool, which is not wrong, of course, but it's not the intended use. If you as a developer want to use it that way, you can easily disable the locking code in /usr/share/gdm/guest-session/guest-session-launch
[20:09] <GunnarHj> tedg: Besides, how would using gdm-guest-session that way be a reason for _not_ removing the locking code from indicator-session?
[20:11] <tedg> GunnarHj, Indicator session does a more nuanced view of when to lock the session -- for instance if the user has disabled screen locking -- so it makes a better choice.  Sure, guest-session could be updated to do the same, but I think it violates the unix philosophy of "Do one thing, and do it well".  guest-session should "start a guest sesion" no "and" after that.
[20:11] <tedg> GunnarHj, If guest-session enforces locking, there's no way around it, while if it doesn't we get a choice.
[20:18] <GunnarHj> tedg: Making it easier to provide options is the original reason why I suggested that locking is dropped from indicator-session, and I mentioned choosing the guest session language as one example.
[20:19] <GunnarHj> That kind of option is more likely appreciated by the average user than the option to not lock the regular session.
[20:19] <GunnarHj> There are people who would like to see a guest session feature that you can launch from gdm's login screen, but then we are talking about a different kind of feature IMO.
[20:21] <tedg> GunnarHj, Well, as you noted there is a blueprint (only half implemented) to provide for other types of items there.   One of the ones we were considering is "Unity Smoke test" where you could launch a guest session into a session where Unity ran a smoke test on your graphics hardware.  For that my intention was to provide a "configure" command and a "do it" command so those use cases could be supported.
[20:21] <tedg> GunnarHj, If the guest-session command automatically locks, it's hard to use it in higher level scripts like the unity-smoke script as well.
[20:28] <GunnarHj> tedg: I didn't know that. Have a feeling that you and Martin P. ought to talk it over. From my Ubuntu newbie perspective, I see that the way it currently works is not optimal. As an example, at http://ubuntuforums.org/showthread.php?t=1566078 I need to advise people to not launch guest sessions from indicator-session.
[20:31] <tedg> GunnarHj, Certainly, I think the best thing at this point is to provide for a "--no-lock" option on guest-session.
[20:37] <GunnarHj> tedg: It sounds reasonable to me, but that would not make it less important to remove the locking code from indicator-session. Shall we make a deal? ;-)
[20:44] <tedg> GunnarHj, Well, I think it'd be better to separate out the configuration and execution, so I'll try to get that working.  Then you can build exactly what you want, and infact, several of the different combinations :)
[20:45] <kirkland> slangasek: cjwatson: where can i find documentation as to building a server installation ISO locally?
[20:47] <slangasek> kirkland: you need a copy of debian-cd; probably the forked version that runs on the Ubuntu CD buildserver
[20:48] <kirkland> slangasek: where abouts do I find that ?
[20:48] <GunnarHj> tedg: Ok, thanks. :-)  But I do think that a --no-lock option is a good idea, so I'll propose the addition of it. Then, if you want to use the guest session as a testing environment when developing things, you can do it without a need to edit a program file.
[20:49] <slangasek> kirkland: I think https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu might be it
[20:49] <slangasek> kirkland: documentation is probably upstream in Debian
[20:52] <persia> kirkland, slangasek: that is indeed the branch you want
[20:57] <kirkland> persia: okay, thanks;  got it;  i'm looking at the README in there;  is that the best place to learn how to build an Ubuntu Server ISO?
[20:58] <persia> kirkland, How much do you like reading make?
[20:59] <highvoltage> heh
[21:00] <kirkland> persia: somewhere above Emily Bronte but below Neal Stephenson
[21:00] <persia> Right.  Let me look about a bit to make sure I'll give you the right reference then.
[21:03] <persia> kirkland, Quick'n'dirty (so, when it breaks, fix that, rinse, repeat): bzr branch lp:ubuntu-cdimage; ubuntu-cdimage/for-project ubuntu-server cron.daily
[21:03] <dobey> any archive admin around?
[21:04] <persia> You will need to have the debian-cd branch identified above available locally for this to even pretend to start working properly.
[21:05] <dobey> hi persia :)
[21:06] <persia> hey dobey
[21:06] <dobey> how's it going?
[21:06] <persia> It's Thursday :(
[21:06] <dobey> yes it is
[21:07] <dobey> and i just made a dumb mistake, but is easily redactable
[21:07] <persia> What sort of mistake needs an archive-admin?
[21:07] <sebner> persia: isn't that a good thing as weekend is in sight?
[21:08] <dobey> persia: disapproving my upload to lucid-proposed. i made a brain fart and it was supposed to be to maverick-proposed (which i subsequently fixed the changelog and uploaded to)
[21:09] <persia> OOps.  I'd recommend mentioning that in the relevant bug as well, just in case it ends up getting looked at by one of the ubuntu-sru folks, rather than someone catching it here.
[21:09] <ScottK> I can remove it.
[21:09] <ScottK> dobey: What package?
[21:11] <dobey> ScottK: ubuntuone-client
[21:11] <ScottK> dobey: You want it removed from lucid, right?
[21:12] <ScottK> removed/rejected
[21:12] <dobey> ScottK: yeah, the lucid-proposed upload was an oops
[21:12] <ScottK> dobey: Done.
[21:12] <dobey> ScottK: thanks much!
[21:33] <Keybuk> one day, somebody should explain the whole ubuntu-virt-manager thing
[21:33] <Keybuk> until then I'll run the much simpler kvm one-liner to run ubuntu in a virtual machine ;)
[21:33] <mok0> Keybuk: amen to that
[21:33] <soren> Keybuk: You mean virt-manager, right?
[21:34] <ogra> isnt that a redhat app anyway ?
[21:34] <mok0> soren, trigged a keyword huh :-)
[21:34] <Keybuk> soren: might be ubuntu-vm-builder & virt-manager :p
[21:34] <maco> i'll just keep using virtualbox
[21:34] <maco> virt-manager requires that i go read a wiki page every time i want to use it
[21:35] <ogra> yu could print it out and stick it to the back of your laptop ;)
[21:35] <soren> Keybuk: They're quite different beasts. Both have their set of idiosyncracies.
[21:35] <soren> Keybuk: ...so I can't really explain them as one, is my point.
[21:38] <kirkland> soren: i seem to recall you knew how to build the server ISO...
[21:38] <kirkland> soren: i have lp:cdimage local
[21:38] <kirkland> soren:  ... now what?
[21:39] <soren> kirkland: Long forgotten, sorry.
[21:40] <kirkland> soren: k
[21:40] <soren> kirkland: ...and I never bothered doing it locally. I just triggered it on the build servers.
[21:53] <mathiaz> SpamapS: hi!
[21:53] <mathiaz> SpamapS: do you know if using the restart command will pick up a new upstart job?
[21:53] <mathiaz> SpamapS: it seems that if the memcached.conf file is updated and then restart memcached is called
[21:54] <mathiaz> SpamapS: the command from the old memcached.conf file used
[21:54] <mathiaz> SpamapS: rather than the new one
[21:59] <soren> mathiaz: It won't.
[21:59] <soren> mathiaz: restart by design uses the in-memory definition of jobs.
[21:59] <mathiaz> soren: ok - so start, stop would do the job?
[21:59] <soren> mathiaz: Yes.
[21:59] <mathiaz> soren: great - thanks
[22:00] <soren> mathiaz: upstart knows there's a new job definition. It just considers it a branch new definition, not a redefinition of the old one.
[22:00] <soren> err..
[22:00] <soren> s/branch/brand/
[22:00]  * soren uses bzr a lot... Can you tell? :)
[23:25] <hallyn> is there a standard way to add a mount entry when a package is installed?
[23:25] <hallyn> i need a tmpfs mounted at /sys/fs/cgroup/
[23:26] <hallyn> Daviey: ^
[23:26] <hallyn> oh, prolly too late for him
[23:35] <soren> hallyn: If it's not something that is generally applicable (and thus could be put in the standard fstab for everyone), you'd probably mount it from an upstart job (so not use fstab at all).
[23:36] <hallyn> soren: hm.  ok, that sounds simple enough from pkg point of view
[23:36] <hallyn> soren: though i hate the idea of random programs mounting junk all over the place :)
[23:36] <hallyn> soren: thanks, i'll do that until someone yells at me
[23:37] <soren> hallyn: It's Linux. It's a patch work of random programs doing random things all over the place. Noone will notice one more or one less.
[23:37] <hallyn> lol
[23:37] <hallyn> "long as they haven't noticed my little backdoor"
[23:38] <soren> Noone will notice one more or one less.
[23:38] <soren> :)
[23:38] <hallyn> I like my programs to be as transparent as possible - but adding a mount to fstab seems intrusive and will still leave ppl wondering where it came from :)
[23:38] <penguin42> pity fstab hasn't gone to a .d type arrangement like most other stuff
[23:42] <bryceh> penguin42, maybe they're waiting on a patch from you?  ;-)
[23:43] <bryceh> penguin42, but yeah, my fstab's are crufted over with mounts for chroots, nfs shares, ... so a .d for configuration would make things a lot tidier
[23:44] <penguin42> I guess quite a few things would need to be updaed, but I guess not too bad
[23:44] <broder> hallyn: -1 for adding to fstab. i think doing it from an upstart/init.d job sucks, but is the best current option
[23:44] <broder> until somebody writes up fstab.d support :)
[23:45] <a3Dman> why natty daily images is forced to the gnome-icon-theme?
[23:49] <hallyn> broder: ok, thanks.
[23:49] <hallyn> heh, maybe i'll try my hand at dh_fstab :)
[23:49] <hallyn> fstab.d, not so much
[23:51] <jbernard> hallyn: why is tmpfs needed? Is this an integration issue, or are you seeing failure that I can fix in teh debian package?
[23:52] <jbernard> hallyn: also, if there's anything I can do to help, please do let me know
[23:54] <hallyn> jbernard: i'ts for libcgroup.  They want to (are encouraged to) create directories under /sys/fs/cgroup
[23:54] <hallyn> but you can't do that
[23:54] <hallyn> so they're supposed to mount a tmpfs under there
[23:55] <hallyn> admittedly we could just use /cg or /cgroup or /mnt/cgroup, but general consensus has been that /sys/fs/cgroup should exist for that purpose
[23:55] <hallyn> jbernard: thanks
[23:55] <hallyn> anyway i think i've just about got libcgroup yanked out of the garbage dump
[23:55] <jbernard> it should mount them in /sys/fs/cgroup, is that not occuring?