[00:14] <directhex> tip for the day: writing a full dep5 debian/copyright for 39k source files is hard work
[00:42] <slangasek> directhex: dep5 says nothing about the granularity you should provide, you know
[00:44] <directhex> slangasek, all copyright holders need listing in the appropriately licensed chunks, though. i'm *heavily* abusing wildcards to make life more bearable than it could be
[00:44] <mdeslaur> asac: do you mind if I merge liferea?
[00:45] <smoser> persia, hm... i pulled from lp:ubuntu/ubuntu-dev-tools
[00:45] <slangasek> directhex: well, you only have to list all copyright holders if the license or Policy requires it... dep5 only defines the format :)
[00:46] <directhex> slangasek, the aim is to avoid REJECT. experience teaches over-thoroughness is a more successful path than under-thoroughness
[00:46] <persia> smoser: Perhaps that's out of date.  Trunk is at lp:ubuntu-dev-tools.  This may change at some point.
[00:49] <persia> smoser: Once you've rebased, please push somewhere, and I'll redo my tgz handling based on your branch.
[00:50] <smoser> hlok
[00:50] <smoser> ok
[00:51] <directhex> now, bedtime. there's always more time for copyright tomorrow
[01:05] <smoser> persia, lp:~smoser/ubuntu-dev-tools/ubuntu-dev-tools.dev
[01:05] <smoser> i've got to run, so i didn't test the merge... i had tested what i had before at least for union
[01:23] <kees> smoser, persia: ran out of time today, but if you work from smoser's branch, I'll be able to pull it in quickly (i'm working from his branch too)
[01:27] <persia> smoser's branch is way cooler than mine was, and mine has since been discarded :)
[01:28] <persia> Or it would be, based on the patch.
[01:28]  * persia waits for LP more
[01:30] <Caesar> slangasek: ping
[01:30] <Caesar> slangasek: minor shambles detected wrt autofs
[01:31] <Caesar> slangasek: autofs is a dummy package in main
[01:31] <slangasek> Caesar: hi
[01:31] <Caesar> slangasek: autofs-ldap is a real package in universe claiming to be from the autofs source package
[01:31] <Caesar> it's possible to install autofs5 (via autofs) and still have autofs-ldap
[01:31] <Caesar> What should I file the bug against?
[01:32] <Caesar> and trying to install autofs after autofs5 has been installed produced ugly errors
[01:32] <slangasek> what's your target outcome?  autofs-ldap auto-upgraded to autofs5-ldap, or autofs restored as a real package?
[01:35] <Caesar> It sounds like autofs-ldap (and friends) needs to go/become a dummy package
[01:36] <slangasek> ok, please file it on autofs then
[01:36] <Caesar> Is it normal for dummy packages to be uninstallable after removal?
[01:36] <slangasek> any package in the archive should be installable
[01:36] <slangasek> if it's not installable, it shouldn't need to be there at all
[01:36] <Caesar> autofs (dummy package) is not installable when autofs5 is installed
[01:37] <slangasek> yah, autofs5 Conflicts: autofs; that's not right
[01:37] <slangasek> so I guess autofs5 needs fixing as well
[01:37] <Caesar> Two bugs?
[01:38] <slangasek> one bug, it's all of a piece really
[01:38] <Caesar> ok
[01:38] <Caesar> I'll file it shortly
[01:38] <slangasek> cheers
[02:24] <fullTummy> j e b i t e s e
[02:25] <fullTummy> Viđi vraga su sedam binjišah,
[02:25] <fullTummy> su dva mača a su dvije krune,
[02:25] <fullTummy> praunuka Turkova s Koranom!
[02:25] <fullTummy> Za njim jata prokletoga kota,
[02:25] <fullTummy> da opuste zemlju svukoliku
[02:25] <fullTummy> ka skakavac što polja opusti!
[02:25] <fullTummy> Francuskoga da ne bi brijega,
[02:25] <fullTummy> aravijsko more sve potopi!
[02:25] <fullTummy> San pakleni okruni Osmana,
[02:25] <kklimonda> !op
[02:25] <fullTummy> darova mu lunu ka jabuku.
[02:25] <fullTummy> Zloga gosta Evropi Orkana!
[02:25] <fullTummy> Vizantija sada nije drugo
[02:25] <fullTummy> no prćija mlade Teodore;
[02:25] <fullTummy> zvijezda je crne sudbe nad njom.
[02:25] <fullTummy> Paleolog poziva Murata
[02:25] <fullTummy> da zakopa Grke sa Srbima.
[02:25] <fullTummy> Svoju misli Branković s Gertukom.
[02:25] <elpargo> hi, if I want to write a program that will run "forever" listening to a streaming api (http1.1) will it be better to make a service out of it? or should I stick with a daemon?
[02:25] <fullTummy> Muhamede, to je za Gertuku!
[02:25] <fullTummy> Sjem Azije, đe im je gnjijezdo,
[02:25] <fullTummy> vražje pleme pozoba narode -
[02:25] <fullTummy> dan i narod, kako ćuku tica:
[02:25] <fullTummy> Murat Srpsku, a Bajazit Bosnu,
[02:25] <fullTummy> Murat Epir, a Muhamed Grčku,
[02:25] <fullTummy> dva Selima Cipar i Afriku.
[02:25] <fullTummy> Svaki nešto, ne ostade ništa;
[02:25] <fullTummy> strašilo je slušat što se radi!
[02:25] <fullTummy> Malen svijet za adova žvala,
[02:25] <fullTummy> ni najest ga, kamoli prejesti!
[02:26] <fullTummy> Janko brani Vladislava mrtva;
[02:26] <fullTummy> što ga brani, kad ga ne odbrani?
[02:26] <fullTummy> Skenderbeg je srca Obilića,
[02:26] <fullTummy> al' umrije tužnim izgnanikom. -
[02:26] <fullTummy> A ja što ću, ali sa kime ću?
[02:26] <fullTummy> Malo rukah, malena i snaga,
[02:26] <fullTummy> jedna slamka među vihorove,
[02:26] <elpargo> :(
[02:26] <fullTummy> sirak tužni bez nigđe nikoga...
[02:26] <fullTummy> Moje pleme snom mrtvijem spava,
[02:26] <fullTummy> suza moja nema roditelja,
[02:26] <fullTummy> nada mnom je nebo zatvoreno,
[02:26] <kklimonda> we need more operators
[02:26] <fullTummy> ne prima mi ni plača ni molitve;
[02:26] <elpargo> why people waste time and money doing that.
[02:26] <kklimonda> I have no idea
[02:26] <kklimonda> and I've thought really hard about it lately
[02:27] <tsimpson> better late than never I guess
[02:28] <elpargo> thanks tsimpson
[02:56] <zul> caesar: ping
[02:56] <Caesar> zul: pong
[02:56] <zul> Caesar: got a sec to chat?
[02:57] <Caesar> zul: if it's quick, otherwise I'll be home in a little bit
[04:18] <ebroder> Does anybody have any ideas about bug #276777? I'm running into something similar using gdebi, but I think it's the same bug
[04:19] <ebroder> The error popup is coming from the /usr/share/debconf/frontend process, which doesn't have DBUS_SESSION_BUS_ADDRESS set
[04:20] <ebroder> Nothing is bound to the socket it's complaining about, and it's different from the DBUS_SESSION_BUS_ADDRESS that my unprivileged user has set
[04:57] <micahg> kees: ping re NSS
[05:19] <kees> micahg: go for it (I just touched it for build changes)
[05:20] <micahg> kees: cool, thanks
[05:21] <kees> np, thanks
[06:48] <pitti> Good morning
[06:49] <pitti> apw: we don't close bug tasks when it's still in -proposed, so "fix committed" is more appropriate
[08:02] <pitti> james_w: I'm a bit confused about https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/ido/lucid-201002090705/+merge/18905
[08:03] <pitti> james_w: does that mean that kenvandine committed something different to the branch than what actually got uploaded?
[08:03] <pitti> kenvandine: ^
[08:09] <dholbach> good morning
[08:15] <kees> Ng: if the G45M has a TPM module, my rng-tools change should work with it.  what sort of stuff does it have?
[08:15] <pitti> hey dholbach, guten Morgen
[08:15] <dholbach> hi pitti
[08:20] <alkisg> The new tftpd-hpa is serving files from /srv/tftp instead of /var/lib/tftpboot (LP #518815). Is this change permanent? Should we change LTSP to use that new path?
[08:22] <kees> smoser: thanks, I've merged the mk-sbuild changes.
[08:30] <Ng> kees: I'm not entirely sure, but the bios for my thinkpad is full of talk of security chips
[08:31] <kees> Ng: hmmm, and none of the tpm_* modules are happy?
[08:33] <Ng> kees: not immediately. http://www.thinkwiki.org/wiki/Intel_GM45_TPM_device_iTPM_INTC0102 seems relevant
[08:33] <pitti> does anyone have an idea what I'm missing to get the AM_CHECK_PYTHON_HEADERS autoconf macro?
[08:41] <kees> Ng: it looks like the fix is upstream http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/char/tpm/tpm_tis.c;h=2405f17b29ddd87994f354e5530f264c726d5761;hb=HEAD  but not in lucid.  perhaps request a cherry-pick from the kernel-team?
[08:43] <Ng> kees: aha, ta
[09:13] <james_w> pitti: no, that's a bug, I'll take care of it
[09:18] <free> pitti: hey!
[09:18] <free> pitti: I'm preparing an SRU for the landscape-client, just to be extra sure, for each bug the SRU addresses I have to create a task by selecting Ubuntu in the "Also affects project" link, right?
[09:24] <pitti> free: right, it needs an Ubuntu package task, and then release tasks for lucid and the release(s) you want to SRU to
[09:24] <pitti> free: (the latter is "target to release...")
[09:24] <free> pitti: cool, thanks
[09:27] <free> pitti: does this one look good? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/218388
[09:27] <pitti> free: please make it public first
[09:27] <pitti> (I can't see it)
[09:27] <free> oops :) public now
[09:28] <pitti> free: yes, approved all tasks
[09:28] <free> pitti: thank you
[09:31] <pitti> james_w: thanks
[09:41] <lool> cjwatson: I need to add support for setting the credentials "C" flag in binfmt-support; would having a "credentials" line in the format description file in /usr be a good way for that, or do you prefer a different way?
[09:41] <lool> cjwatson: This is needed to allow sudo to work from armel chroots
[09:42] <pitti> james_w: I'm about to create a brand new package; if I do "bzr init" and "bzr import path/python-gudev-147.1.tar.gz", will this automagically do the pristine-tar magic?
[09:42] <james_w> pitti: unfortunately not
[09:42] <pitti> bzr help commands doesn't have anything about pristine-tar
[09:45] <pitti> james_w: is there some howto about using pristine tar with bzr?
[09:45] <james_w> pitti: you want to base your work off an upstream branch?
[09:45] <pitti> james_w: or should I just not use bzr, upload, wait for the auto-importer, and use it from then on?
[09:46] <pitti> james_w: upstream is in git
[09:46] <james_w> so? :-)
[09:46] <pitti> james_w: so I thought I'd just start with the last upstream tarball
[09:47] <james_w> in that case using import-dsc will work if you create something that builds a source package, do so, and then import it to a fresh branch
[09:48] <pitti> ok, so it seems for the initial packaging I shouldn't start with bzr right away then?
[09:49] <james_w> the functionality is not yet exposed at the UI level that makes it easy to do so
[09:50] <mvo> heh :) cron segfaults during a karmic->lucid upgrade
[09:51] <bryceh> mvo, erk!
[09:53] <dholbach> pitti: do you have an idea why https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-harvest-next-steps and https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-loco-directory-development are not on http://people.canonical.com/~pitti/workitems/canonical-community-ubuntu-10.04.html ?
[09:54] <pitti> dholbach: neither of those is milestoned for ubuntu-10.04
[09:54] <pitti> so they'll just appear on the "entire release" chart
[09:55] <pitti> http://people.canonical.com/~pitti/workitems/canonical-community.html
[09:55] <dholbach> bah, I'm sure they were
[09:55] <dholbach> thanks pitti
[09:55] <pitti> dholbach: or, more precisely, they have not any work items milestoned to ubuntu-10.04
[09:55] <pitti> (the milestone of the spec is merely the default milestone of WIs)
[09:55] <dholbach> jono: ^
[09:56] <jono> dholbach, I am positive they were
[09:56] <dholbach> jono: ok, I'll change it
[09:56] <jono> dholbach, this is going to screw our burndown :P
[09:57] <dholbach> C'est la vie
[09:57] <dholbach> both specs are looking quite OK
[09:57] <dholbach> in terms of done items
[09:57] <jono> dholbach, cool
[09:57] <jono> dholbach, so long you plough the actions and get us in shape, I am happy :)
[09:58] <dholbach> jono: no pressure, eh?
[09:58] <jono> dholbach, none at all :)
[09:58] <jono> you will tock 'em, I have no doubts, you always do :)
[09:58] <jono> rock, rather
[09:59] <dholbach> jono: now I wonder how many others are not on the list ;-)
[09:59] <jono> dholbach, from what I can tell, pretty much all of them are
[09:59] <jono> at least all the key ones I am tracking
[09:59] <dholbach> alrightie
[09:59] <jono> dholbach, ok, I am heading to bed
[09:59] <dholbach> thanks pitti
[09:59] <jono> night!
[10:00] <jono> thanks pitti :)
[10:00] <dholbach> jono: sleep tight
[10:05] <beuno> (for Lucid, that is
[10:05] <beuno> (window change fail)
[10:06] <cjwatson> directhex: I would be overjoyed if you did a grub2/lucid theme
[10:06] <asac> mdeslaur: no ... go ahead
[10:07] <directhex> cjwatson, is there an art style finalized yet? i was thinking something which has the same l&f as the login screen would be good
[10:07] <cjwatson> kirkland: no objection in general but (a) grub2 uses cdbs patches (b) please send the patch upstream (c) please commit to bzr (d) surely it should fail if there's no qemu available?
[10:10] <cjwatson> lool: I'm not familiar with it - could you file a bug with a description of the flag you're trying to support, please?
[10:10] <cjwatson> directhex: not sure, I don't think so
[10:11] <directhex> cjwatson, i'll leave it for now then - at least the gfxmenu stuff should be mostly bug-free now, thanks to the testing i did on debian
[10:12] <directhex> by "bug free" i don't mean "won't explode" i mean "will display what i actually put in the theme file in kvm", of course
[10:17] <lool> cjwatson: lp #519228
[10:18] <lool> cjwatson: Didn't test it, but am thinking of something like http://paste.ubuntu.com/372364/
[10:18] <lool> cjwatson: Correct me if I'm wrong, but as long as I'm adding optional fields and I deal with them being empty, I don't need to deal with upgrade issues for /var/lib/binfmt/* contents?
[10:19] <lool> (I don't quite get why that's a different format from /usr/share/binfmts/*)
[10:21] <cjwatson> lool: I'd like to think about this a little bit asynchronously if that's OK - it's a little while since I worked on this
[10:21] <dupondje> mvo: could you check this patch for me : https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 ? Want it into ubuntu since karmic alpha 2 ;)
[10:22] <lool> cjwatson: That's fine; I'll finish my patch because I have the contect in mind and we will rediscuss whenever you have slept over the request
[10:22] <cjwatson> lool: (and I'd like to make this change in Debian of course)
[10:22] <lool> Notably, it might well be that you want --flags instead of --credentials
[10:23] <lool> cjwatson: Oh of course; did you want me to open a Debian bug?
[10:23] <cjwatson> doesn't matter
[10:26] <mvo> dupondje: thanks, I have a look (but busy ATM)
[10:27] <dupondje> mvo: no problem, waiting for it so long now ;) but its a small patch. I also builded it, and it works perfect
[10:27] <mvo> dupondje: yeah, it looks like its not a big issue :)
[10:27] <mvo> dupondje: thanks for fixing it!
[10:29] <dupondje> mvo: well got fustrated about it, so fixed it myself ;)
[11:00] <cjwatson> james_w: I've upgraded lp:~ubuntu-core-dev/gfxboot-theme-ubuntu/mainline to 2a; does lp:ubuntu/gfxboot-theme-ubuntu point to that, and if not can it?
[11:02] <lool> james_w: I have a small issue with pushing to ubuntu branches: I pushed to lp:ubuntu/binfmt-support/lp-519228 but that seems to have been mapped to lp:ubuntu/lucid/binfmt-support
[11:02] <lool> (I initially branched lp:ubuntu/binfmt-support, debcommit, bzr push lp:ubuntu/binfmt-support/lp-519228, but the bug report shows and links to lp:ubuntu/lucid/binfmt-support)
[11:03] <lool> I just tried pushing to lp:ubuntu/lucid/binfmt-support/lp-519228 as well, and bzr told me "No new revisions to push." so I guess that too is mapped to the lucid branch
[11:03] <lool> I'll push to my namespace instead
[11:04] <lool> Bah lp:~lool/ubuntu/binfmt-support/lp-519228 => No such distribution series binfmt-support.
[11:04] <lool> lp:~lool/ubuntu/lucid/binfmt-support/lp-519228 worked
[11:05]  * lool uncommits lp:ubuntu/binfmt-support
[11:06] <james_w> lool: lp:~lool/ubuntu/lucid/binfmt-support/lp-519228
[11:06] <james_w> lool: please file a bug on bzr that it allowed you to do that
[11:06] <lool> james_w: Yup, that's what I used in the end
[11:06] <cjwatson> lool: not that I'll be able to merge that anyway ...
[11:06] <james_w> it may be an LP bug, but something is broken if it allowed you to push to that given that url
[11:07] <cjwatson> lool: sadly, lp:ubuntu/binfmt-support does not share branch history with lp:binfmt-support.  the latter is a mirror of the branch I'm actually doing development in
[11:07] <lool> cjwatson: There is no Vcs in the binfmt-support control, I thought I would be having multiple revisions for this work, but I ended up committing a single one, consider this a very expensive way to provide a patch  :)
[11:07] <cjwatson> err, yes there is!
[11:07] <lool> Uh
[11:07] <lool> I wonder how I missed it
[11:08]  * lool slaps forehead: I apt-cache show-ed instead of showsrc
[11:16] <mvo> ev_: thanks for fixing #519206 you beat me by 1h :)
[11:17] <ev_> mvo: sure thing :)
[11:17] <lool> james_w: LP #519244
[11:19] <james_w> thanks lool
[11:19] <lool> thanks for your patience  :)
[11:57] <MacSlow> any hints how to fix/avoid/work-around and "errorcode 2" from dpkg-deb --control for libglib2.0/-dev/-dbg libnih1 ?
[11:57] <MacSlow> thanks in advance
[11:58] <cjwatson> MacSlow: can you be more verbose about the exact problem, please?
[11:58] <cjwatson> MacSlow: error 2 is "no such file or directory"
[11:59] <cjwatson> but might not be in this case, if that's an error exit status from a script rather than from a C library function
[11:59] <cjwatson> i.e. could be anything and you haven't given enough information to disambiguate
[12:00] <MacSlow> cjwatson, I tried to update my desktop-machine with synaptic (lacking all lucid updates which happened during the week in Portland) and for the four mentioned packages I get this error reported for "dpkg-deb --control" presented in a dialog-box where synaptic probably just spits out stdout (or stderr)
[12:01] <MacSlow> mvo, ^^^
[12:01] <cjwatson> MacSlow: we need the exact message, not a paraphrase of it
[12:01] <seb128> MacSlow, can you run sudo apt-get -f install
[12:01] <cjwatson> I've never heard of dpkg saying literally "errorcode 2"
[12:01] <seb128> and copy the log on paste.ubuntu.com
[12:01] <MacSlow> crimsun, I'll try to get the english version of it... stand by
[12:02] <cjwatson> it is better to post an exact translated version rather than a guessed English version
[12:02] <cjwatson> the former is greppable; the latter is not
[12:02] <seb128> MacSlow, LC_ALL=C sudo apt-get -f install
[12:04] <MacSlow> cjwatson, seb128: http://pastebin.ubuntu.com/372425
[12:05] <cjwatson> I think you just have a corrupted download then
[12:05] <cjwatson> 'sudo apt-get clean' and try again
[12:06] <MacSlow> cjwatson, hm... guess all those the nvidia/flash "sponsored" freezes today (while trying to download 1.4 GBytes worth of updates) hosed the .debs then?!
[12:07] <cjwatson> it is possible for driver-induced crashes to cause filesystem breakage, yes, especially proprietary drivers
[12:09] <seb128> MacSlow, what do you upgrade from and to what do have that much to download?
[12:09] <MacSlow> ok... re-fetching 1.6 GBytes now :/
[12:09] <cjwatson> superm1: bug 508173> is it possible to get an upgrade log with DEBCONF_DEBUG=developer set in the environment?
[12:10] <seb128> MacSlow, note that apt-get clean will wipe all your cached debs, you need to download again
[12:10] <seb128> too late for that ;-)
[12:10] <MacSlow> seb128, it's my desktop (main working machine), which didn't see updates for a week (Portland)
[12:10] <seb128> 1.6G in a week?!
[12:10] <cjwatson> that's over twice as big as the .deb size for a complete default install ...
[12:10] <MacSlow> seb128, how do I know
[12:11] <MacSlow> seb128, cjwatson: you're the repo masters with all the oversight... I've no clue what goes on there
[12:11] <MacSlow> seb128, cjwatson: part could be that I've gnome and kde on this box
[12:11] <seb128> I've no oversight of the zillion things you installed
[12:11] <MacSlow> :)
[12:12] <seb128> but I usually get some 300 meg in a week
[12:12] <seb128> not 1.6G
[12:16] <mvo> MacSlow: could you run md5sum on the debs?
[12:17] <MacSlow> mvo, no... I'll not consider doing stuff like that as it side-tracks me too much... btw... re-downloading the fresh packages anyway now
[12:18] <kenvandine> pitti, that is a very strange merge request
[12:18] <pitti> kenvandine: james_w said it's a bug, and he'd handle it
[12:18] <mvo> MacSlow: hm, ok. it might be a real bug hidding somewhere
[12:28] <kenvandine> ok
[12:52] <dantti> cjwatson: ping
[12:53] <cjwatson> dantti: I replied to your e-mail
[12:53] <dantti> cjwatson: yep I saw it, sorry for not putting what I had in mind
[12:54] <dantti> cjwatson: I have just replyied to it
[12:54] <dantti> i just thought it woud be simpler to explain on IRC
[13:03] <cyphermox> cjwatson, I'm not sure if you're the right person to ask, but I sent my MOTU application to devel-permissions and the dmb, I'm not sure if it went through to the DMB address, but I can't see my message in the devel-permissions archives (I sent it on Feb 2)
[13:06] <geser> cyphermox: your mail reached at least the dmb ml
[13:06] <cyphermox> geser, thanks, just making sure :)
[13:19] <cjwatson> dantti: this is way too long for IRC.  Please can we continue by e-mail in future
[13:20] <cjwatson> cyphermox: thanks, I'm in the process of doing the minutes from the last meeting and catching up on associated actions
[13:20] <saispo> anyone use virt-manager ?
[13:21] <cyphermox> cjwatson, ok. When I saw you cleaned up the agenda I added myself in
[13:22] <dantti> cjwatson: ok, np
[13:31] <mdeslaur> saispo: I do
[13:33] <saispo> mdeslaur: i think i've found why i can't create arm vm ;)
[13:34] <mdeslaur> saispo: oh?
[13:34] <saispo> i miss installing qemu-* :)
[13:36]  * hyperair wonders if anybody managed to make a ppc vm
[13:36] <mdeslaur> saispo: ah, yes, I think there's a separate package for that now: qemu-kvm-extras
[13:37] <cjwatson> cyphermox: that's fine (and indeed best), thanks
[13:43] <saispo> mdeslaur: it's true
[13:43] <saispo> mdeslaur: have you tried to create a qemu-arm machine and try to boot it under a Debian iso image ?
[13:45] <mdeslaur> saispo: no, I haven't
[13:46] <ogra> saispo, use qemu-arm-static and use a chroot ... way faster than a full VM ... has issues with mono though
[13:46] <ogra> (and feel free to drop by in #ubuntu-arm for issues ;) )
[13:48] <saispo> ogra: ok, thanks
[13:50] <dholbach> cjwatson: regarding the DMB minutes: the DMB can't be made owner of ~universe-contributors by the CC, only the TB can (MC is owner right now which is owned by the TB)
[13:50] <persia> saispo: If you install the newest ubuntu-dev-tools, you can use pbuilder-dist or mk-sbuild-lv to create an emulated chroot.
[13:50] <persia> hyperair: There is work going on to make emulated powerpc chroots work, but it's not complete.  Needs lots of merging from Debian.
[13:51] <hyperair> persia: ooh cool.
[13:51] <saispo> ok persia, will see that
[13:51] <hyperair> persia: i tried running qemu with the openbios-ppc bios, but it kept hanging.
[13:51] <saispo> and where i can find openbios for sparc and ppc ?
[13:51] <persia> You need to get a new openbios-ppc: there's an issue with Soyuz that means we can't build it in Ubuntu right now :(
[13:52] <persia> saispo: You need to find someone to build you one, or try using Debian's.
[13:52] <saispo> ok
[13:52] <saispo> thanks
[13:52] <cjwatson> dholbach: if the CC tells us we may, then a TB member can change the ownership.  However what I heard seemed to indicate that this was something for the CC to authorise, which is why I didn't Just Do It
[13:53] <persia> hyperair: If you're up for it, try looking at the Debian "qemu" package, and see what bits from the "qemu-user-static" binary you can merge with the Ubuntu "qemu-kvm" package.
[13:53] <persia> cjwatson: The CC has authorised the action in a vote in a meeting, but didn't specifically authorise the TB to take that action.  I'm not sure how picky we ought be :)
[13:53] <hyperair> hmm okay, if i've got time
[13:56] <dholbach> cjwatson: gotcha, I will send a mail
[13:56] <ogra> persia, i talked to vagrantc in portland, he said ppc is far from stable
[13:57] <ogra> persia, dont pull it into pbuilder yet, i'll give you a heads up if i get one from him (he is doing the work on the static parts)
[13:57] <persia> ogra: Yep.  Sparc is apparently even less well, and we can't currently build openbios for either, which makes using them tricky, *but* it's especially hard to fix when we don't have it available at all :)
[13:58] <ogra> i dont think there is any work going on for a sparc static port yet
[13:58] <persia> My big fancy plan for emulated build systems for developers was to generalise the wrapped debootstrap calls, and then generalise the links in the tools.  Some stuff won't work, but getting it to work or not work shouldn't affect the tools.
[13:58] <persia> The SPARC static port is committed, but apparently doesn't work well enough to talk about much yet.
[13:59] <persia> I don't know of any ia64 static work being done though.
[13:59] <ogra> ah
[14:05] <cjwatson> dholbach: I've followed up to the existing thread
[14:05] <dholbach> me too :)
[14:07] <cjwatson> dholbach: ah, so you did, mail delays :)
[14:08] <smoser> persia, just wondering, why would you prefer tarball to directory in schroot ?
[14:08] <vish> dholbach: hi... i noticed the branding for the 5-a-day team is missing.. since you are the team owner and the only one who can upload it.. could you have a look at > http://dl.dropbox.com/u/1325768/5-bold.png   or  http://dl.dropbox.com/u/1325768/5-thin.png 14px icons
[14:09] <persia> smoser: 1) Takes up less space, 2) is one of the steps towards getting a working pbuilder->sbuild conversion script, which is itself a step towards helping pbuilder users use the ubuntu-security-tools stuff.
[14:09] <persia> smoser: But I left the default to directory, just added support for --type file
[14:09] <smoser> i'm not complaining, hadn't seen your changes, just wondering
[14:09] <dholbach> vish: aren't they both the same? :)
[14:09] <smoser> the big benefit of the directory (for me at lesat) is speed
[14:10] <vish> dholbach: hmm , one is a bold 5 other one is thin ..
[14:10] <persia> smoser: lp:~persia/ubuntu-dev-tools/more-schroot-types : it's complex enough I didn't want to commit without review.
[14:10] <dholbach> vish: oh sorry yes
[14:11] <vish> dholbach: just giving you options ;) you can choose which ever you like ;)
[14:11] <dholbach> cool
[14:12] <dholbach> vish: changed
[14:12] <vish> dholbach: neat thanks :)
[14:12] <dholbach> thank you
[14:18] <smoser> persia, just quickly looking at diff, i like the general cleanups
[14:20] <persia> Some of them are from kees, but I wanted to generalise.  I don't see any reason why we couldn't support all SCHROOT_TYPE variants, although only tgz advances my personal agenda, and I'm far too susceptible to episodes of yak-shaving to look at the rest right now.
[14:21] <persia> smoser: If you'd like, adding in candidate templates and support for all of them would make this a significantly more generalised tool, and might even be suitable for inclusion in schroot rather than being separate.
[14:22] <persia> (although that does remove the chance of abstracting the mirror detection code, etc. and sharing between pbuilder-dist and mk-sbuild (but I was kinda stuck on that anyway as writing code that works for both shell and python can be tricky))
[14:36] <dholbach> zul: can you maybe change the maintainer field to use ubuntu-devel-discuss@ instead? (update-maintainer of the ubuntu-dev-tools package does it automatically for you)
[14:38] <zul> dholbach: yep ill do that
[15:12] <kees> persia: I've merged the "file" type now.  thanks!
[15:13] <kees> heya BenC
[15:13] <BenC> kees: hey dude
[15:13] <persia> kees: Thanks.  I think it's now general enough to support the rest of the SCHROOT_TYPE values, if you find a volunteer ;)
[15:14] <kees> persia: yeah, probably.  I'm curious to do timing tests now between lvm-snapshot, directory, and file.
[15:15] <persia> directory will be fastest.  RAOF did some testing, and at least for some hardware, file is faster than lvm-snapshot.
[15:15] <kees> lvm-snapshot ends really quickly because it just releases the snapshot, but directory doesn't have to go through dm redirection.
[15:15] <kees> well, the main speed issue with lvm-snapshot is doing the build itself in the lv, which I side-step locally by mounting a common build directory.
[15:15] <persia> But I think it depends on available RAM, etc.  Plus I suspect we ought have this discussion when we're both not pretending to pay attention to another channel :)
[15:15] <kees> heh
[15:18] <jcastro> kees: where do your ubuntu+1 slides live online?
[15:19] <kees> jcastro: outflux.net/ul07/
[15:26] <kirkland> pitti: where did the work item tracker go?
[15:27] <pitti> http://people.canonical.com/~pitti/workitems/ (weeks ago)
[15:27] <kirkland> pitti: oh, i was looking at macaroni
[15:27] <pitti> kirkland: I just kept the macaroni one around for people not reading their mail fast enough :)
[15:27] <kirkland> pitti: or updating their bookmarks :-)
[15:27] <kirkland> pitti: thanks!
[15:27] <pitti> kirkland: you're welcome
[15:36] <paulliu> hi. "hornsey" is currently in Debian testing but still not in Ubuntu Lucid. Where can I query the auto-sync status?
[15:37] <kitallis> the empathy contact window seems to retain it's last position for a while after snapping back into the panel, comes back to the same left corner position after a longer period of time ; in accordance with this bug : https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/144348
[15:38] <kitallis> is this a WM problem, or is this application specific? I think pidgin does this alright.
[15:54] <directhex> seb128, 38,780 source files processed by hand - copyright file for moonlight 2.0 written
[15:55] <seb128> impressive!
[15:59] <Laney> have fun reviewing that one
[16:07] <persia> kees: re: common build directory: how does that work?
[16:07] <kees> persia: http://people.canonical.com/~kees/schroot/
[16:08] <persia> kees: Ah.  Do I end up with roughly the same thing by doing it in $HOME/src/${foo}
[16:09] <kees> yeah, though without the extra script, it lacks clean up
[16:26] <micahg> mvo: I have to talk to asac about the Firefox upgrade issue...I thought we needed transitional pacakges
[16:28] <directhex> seb128, so now i'm blocking on an update from upstream which fixes a few licensing bugs plus firefox 3.6 support. should be out within a week or two - they're currently rushing a 3.0 preview release for the winter olympics but will do the 2.0 point release after that
[16:29] <seb128> directhex, ok, no hurry, if we get it in lucid that's good
[16:29] <directhex> seb128, once it's in, i'll ubuntu1 monodevelop and re-enable the moonlight authoring which we disabled in debian
[16:31] <mvo> micahg: do you have a bug reference? I see a missing panel icon after the uprade
[16:32] <micahg> mvo: bug 513074
[16:34] <mvo> micahg: thanks, I check it out, I have a upgrade test profile for this that I can run and see if its a universal problem
[16:35] <micahg> mvo: I hope to have another release pushed out this week with the transitional packages in there to prevent the upgrade problem, if you can test after the next release, that would be great
[16:36] <mvo> micahg: cool, please also check https://code.edge.launchpad.net/~mvo/firefox/fix-518747/+merge/18928 if you do a firefox upload
[16:37] <micahg> mvo: I just rejected it due to merge conflicts, I'll add the replaces and conflicts when I add the transitional packages though
[16:37] <sebner> directhex: will you update to 2.2.1 before?
[16:38] <directhex> sebner, yes, it's on my TODO
[16:38] <sebner> k
[16:38] <kees> today's music care of dholbach!  thanks!  :)
[16:38] <mvo> micahg: ok, that is fine with me, the important bit is to have a replaces: firefox-3.0 there to avoid the file-overwrite bug
[16:38] <directhex> sebner, problem is not all the addins are 2.2.1 (some are still 2.2) so i need to double-check deps & re-upload everything
[16:39] <nxvl> slangasek: just noticed that we don't have alpha 5 anymore, and i used to move to the devel release once alpha 5 was out, which one is the equivalent now, alpha 3?
[16:39] <sebner> directhex: pretty much trouble so near to the FF, hmm? :\
[16:39] <micahg> mvo: I realize that I should have fixed the title in the first bug
[16:40] <dholbach> kees: eh?
[16:40] <directhex> sebner, i'm sure seb128 will let it by if i flutter my eyelashes
[16:40] <kees> dholbach: I just downloaded and am enjoying your first mix of 2010.  :)
[16:40] <dholbach> kees: ah, thanks :-)
[16:41] <seb128> directhex, sebner: doing some update should be ok yes
[16:47]  * apw has just updated and am getting apopup on the gdm screen 'Install problem!  The configuration default for GNOME PowerManager have not been installed correctly"  anyone else seeing that?
[16:47] <apw> (to lucid)
[16:48] <mvo> asac: sorry, just noticed the conflict and micahg rejected already. I fix it
[16:48] <asac> thx
[16:48] <apw> bah _and_ i cannot login now
[16:52] <mvo> micahg: I did a new proposal now that should fix the problems
[17:00] <Laney> mvo: Is the conffile prompt on brltty ubuntu4 -> ubuntu5 expected?
[17:01] <mvo> Laney: sort of, karmic (and before) -> ubuntu5 should work fine, but the versions in between are still prompting
[17:01] <Laney> alright, no worries then
[17:01] <mvo> Laney: TBH I'm not sure if its worth fixing, its lucid->lucid upgrades only that prompt
[17:02] <Laney> I wouldn't be too concerned about that, only for stable->current upgrades
[17:16] <dupondje> mvo: had any time yet ? :)
[17:17] <micahg> mvo: sorry, for the trouble, it's merged in and we'll do another release later this evening
[17:38] <slangasek> nxvl: alpha3 is the equivalent in some respects
[17:48] <nxvl> slangasek: ok, thanks
[17:55] <primes2h> pitti: Hello. Could you have a quick look at this please? A patch is attached. bug #394071 It needs a sponsor.
[17:59] <tjaalton> slangasek: hey, are you running lucid on a client with the nfs4/krb5 setup?
[17:59] <slangasek> tjaalton: yes
[18:00] <slangasek> tjaalton: why, are you fixing 480444? :)
[18:00] <tjaalton> slangasek: hmm ok, I'm having issues with expired tickets hanging the client..
[18:01] <slangasek> tjaalton: I haven't noticed this, since I get a ticket refresh every time I unlock my screensaver
[18:02] <tjaalton> slangasek: yep, a while after I do that the session is frozen, and for instance running just 'ps' hangs. root can still access the shares
[18:03] <tjaalton> now testing .33 and nfs-utils 1.2.2rc9
[18:03] <superm1> cjwatson, i'll see what i can do to fetch that log.  should be doable
[18:04] <slangasek> tjaalton: well, if I have no creds at all, trying to ls a v4+krb5 mount fails immediately for me
[18:04] <tjaalton> slangasek: oh, and the whole $HOME is behind nfs of course. there are plenty of apps that go berserk when the tickets expire. gconf/gnome-settings-daemon being one
[18:07] <tjaalton> slangasek: anyway, happy to hear it works for you, maybe our setup is broken somehow.. though hardy didn't have big issues with expired tickets
[18:11] <tjaalton> maybe I should try to get a network trace as well.. someone adviced that using iptables to drop the outbound nfs traffic would recover rpciod after a while, but that didn't work
[18:13] <cjwatson> superm1: ta
[18:21] <rickspencer3> any trial guru around who has a moment to help me run it over one of my libraries?
[18:30] <directhex> asac, did you get to the bottom of mono on lucid/arm issues? it was you who was looking, right?
[18:32] <primes2h> pitti: wait, changed description.. bug #394071
[19:07] <qense> I've got a problem with Indicator Application (C implementation) not using the actions as defined somewhere in the code. Instead it shows GTK+ stock menu items.
[19:07] <qense> What is needed to properly associate the actions with the menu passed to AppIndicator?
[19:36] <asac> directhex: i am debugging still
[20:05] <Caesar> slangasek: do you know if it's possible to write an upstart job such that it'll kick the service upon a file changing?
[20:06] <Caesar> More concretely, I'd like to restart gssd when /etc/krb5.keytab appears, disappears or otherwise changes
[20:10] <slangasek> Caesar: AFAIK no
[20:11] <Caesar> Drat
[20:12] <cjwatson> sorry to DMB members about the list spam; my mail server seems to have gone a bit odd and delivered the same message multiple times
[20:12] <mneptok> slangasek: fail. VORLON TAVUTNA CHOG!
[20:13] <Caesar> cjwatson: you got a few minutes to talk about OpenSSH?
[20:13] <cjwatson> Caesar: sure ...
[20:29] <lifeless> is there a dedicated UEC channel ?
[20:30] <persia> lifeless: I've seen occasional discussion on -virt and -server, but there may also be one.
[20:35] <kamalmostafa> I'm having trouble doing a requestsync for 'clxclient'.   Any advice?...
[20:35] <kamalmostafa>   $  requestsync --lp -d unstable -s clxclient lucid
[20:35] <kamalmostafa>   E: Did not retrieve any changelog entries. Was the package recently uploaded? (check http://packages.debian.org/changelogs/)
[20:35] <kamalmostafa> Yes, it was recently uploaded, but I see that the latest changelog (3.6.1-1.1) is present as of today at http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog.
[20:59] <slangasek> kamalmostafa: I can't reproduce this problem
[21:03] <kamalmostafa> slangasek: Interesting.  I do still get the same problem, using the exact command line I pasted.  This is Karmic with ubuntu-dev-tools (0.81.1).  Your version?
[21:04] <slangasek> using lucid, of course
[21:06] <kamalmostafa> slangasek: Okay, and I see that lucid sports newer ubuntu-dev-tools than I've got.   I'll chase down -- seems likely to be the cause of my problem.  Thanks.
[21:06] <slangasek> well, nothing in the changelog jumps out at me, but it might help
[21:06] <kamalmostafa> slangasek: well, certainly the first thing to try anyway...  Let me fire up a kvm and see what happens.
[22:47] <fagan> why is the git package called git-core ?
[22:48] <StevenK> Since a package called 'git' already existed
[22:48] <fagan> ah
[22:48] <fagan> In lucid there is no git package in the repo
[22:49] <StevenK> Ehhh
[22:49] <Laney> yes, it exist*ed* at the time
[22:49] <Laney> I believe there is a plan to transition git-core to git
[22:50] <fagan> I just thought I should ask in the interest of simplicity
[22:50] <seb128> directhex, Laney: any reason we don't use mono 2.6?
[22:51] <Laney> 2.4 is the LTS branch
[22:51] <Laney> from upstream
[22:51] <seb128> 2.6 is no stable?
[22:51] <Laney> stable yes, lts no
[22:51] <seb128> ok
[22:51] <seb128> so we will stay on 2.4 for lucid?
[22:51] <Laney> yep
[22:51] <Laney> and squeeze
[22:51] <seb128> thanks
[22:52] <seb128> I will do some tweaking to the versions page
[23:02] <directhex> seb128, we've found the 2.4 branch very dependable, and guessed that the security guys would prefer the branch with a 5-year support cycle rather than the one with the "until we get bored" cycle
[23:06] <directhex> seb128, if anyone asks, i try to run a supported repo with recent releases for LTS. it'll go live around the time lucid releases
[23:07] <seb128> directhex, thanks, nobody is asking so far, I was just reviewing our versions table for lucid and wondering if there was a reason to keep an outdated version there
[23:08] <seb128> directhex, seems to make sense if 2.4 is lts and not 2.6
[23:10] <directhex> seb128, 2.4 as lts is what novell have been telling me. i guess because it's what ships in sles11, and in a paid supported addon for sles10
[23:10] <seb128> ok
[23:11] <jcastro> directhex: does that mean we lose file dir watching in banshee?
[23:15] <crimsun> jcastro: no, watcher depends on mono >= 2.4.3
[23:16] <directhex> the only major item we miss out on is the new debugger
[23:19] <cjohnston> mbudde: ping