[01:10] <psusi> cjwatson, you played much with lazy_itable_init yet?  I wrote a patch today to e2fsck that I think will address ted's concerns about enabling it by default
[01:46] <SpamapS> is there a good wiki page on how to make sure your fixes get pushed back up to debian?
[01:54] <psusi> email the debian maintainer?
[01:55] <SpamapS> hah, it sounds so easy.. almost.. too easy
[01:56] <RAOF> There's a submittodebian command in ubuntu-dev-tools; that sends a bug to the Debian BTS and sets a bunch of usertags.
[01:57] <ScottK> SpamapS: As RAOF says.
[01:57] <xnox> SpamapS, i do a debdiff or a patch against Debian packaging $vcs, file the bug in BTS and link it in the lp bug where the patch was introduced. That way the bug is still visible in bugs.launchpad.net/~me and i get updates =) i do set tags manually though
[07:37] <dholbach> good morning
[09:35] <NCommander> bdrung__: ping
[09:36] <NCommander> bdrung__: can you look at https://bugs.edge.launchpad.net/ubuntu/+source/d-shlibs/+bug/579187 again? (I honestly don't understand why you had me respin the debdiff however)
[09:38] <\sh> moins
[09:38] <NCommander> morning \sh
[09:38] <seb128> NCommander, speaking of which bug, did you read my comment about it?
[09:39] <seb128> NCommander, the debian maintainer disagree with the change
[09:39] <seb128> NCommander, can you either follow up on the bts or drop the change?
[09:39] <seb128> either the debian maintainer is right and we should drop the change
[09:39] <seb128> or he's wrong and somebody should explain why on the bts
[09:45] <NCommander> seb128: I didn't see your comment before. Let me look at the maintainers comment on the BTS
[09:46] <seb128> NCommander, thanks
[09:49] <NCommander> seb128: I didn't see the comment on the BTS before or I would have responded to it. Its indeed possible an issue with eglibc on ARM only, but this is how the .la files are generated on this platform, and the same bug effects Debian as well as Ubuntu. I don't know the subject well enough to say if this is an actual bug in eglibc or not, nor am I strongly happy about the notion of changing glibc at all at risk of greater breakage
[09:50] <seb128> NCommander, could you at least open a bug against debian glibc pointing to this bts comment?
[09:50] <seb128> NCommander, so both debian maintainer can argue over the issue and decide where to fix it
[09:51] <ogra> NCommander, erm
[09:51] <NCommander> ogra: ?
[09:51] <ogra> looking at the diff, wasnt that a temporary hack we applied ?
[09:52] <NCommander> ogra: TBH, I can't remember
[09:52] <ogra> with doko saying it should only be temporary until its properly fixed
[09:52]  * ogra remembers something like that
[09:52]  * NCommander doesn't, but I'll take your memory over mine any day :_)
[09:52] <seb128> can somebody check with doko before uploading that change?
[09:53]  * ogra points to the committer :)
[09:54] <NCommander> doko_: ping, do you remember if the issue that required us to patch d-shlibs (original bug: https://bugs.edge.launchpad.net/ubuntu/+source/d-shlibs/+bug/504365) was fixed?
[10:04] <hrw> lool: "import gcc-4.4/4.5 packaging in bzr" work item - I can publish it in my private branch on LP and let someone else import it as official one?
[10:07] <lool> jrdnyquist: 11:06 < lool> hrw: I think the gcc bzr import is going to relate to moving to  CodeSourcery patches, we're discussing this next Tuesday on the  toolchain WG call (please join if you like)
[10:07] <lool> hrw: 11:06 < lool> hrw: I'd start on top of lp:ubuntu/gcc-4.4 in the mean time
[10:07] <lool> jrdnyquist: Sorry
[10:20] <hrw> lool: hmm.. if gcc-4.4 and gcc-4.5 are already imported then can we just mark that work item as done? looks like it was not needed to be listed
[10:22] <lool> hrw: This is an import of the package uploads
[10:22] <lool> hrw: The idea during the session was to import the packaging repo (SVN)
[10:24] <hrw> svn of gcc source tree?
[11:14] <hrw> lool: ping me when you will be available.
[11:16] <hrw> lool: 'extend binutils binary target to produce cross-compilers and drop binary-cross target' - does it mean that during normal build of binutils we want also to build all cross-binutils (armel, powerpc, x86, x86-64, sparc etc)?
[11:19] <tkamppeter> To fix bug 465916 in Lucid we would need to add a package post-release. Someone knows how to proceed with that?
[11:24] <lool> hrw: No, it's just that we'd call dpkg-buildpackage and not binary-cross to build them -- after setting a debian/target architecture
[11:25] <lool> hrw: SVN of packaging tree
[11:25] <lool> hrw: I'd rather have the conversations on #ubuntu-arm BTW; zumbi is usually following these
[11:25] <lool> Depends whether you want Matthias or Hector following I guess :-)
[11:26] <hrw> lool: ok, lets move there
[12:27] <doko_> NCommander: I remember the issue, but I can't remember if it's needed for 2.10 as well. it's a typical answer of this debian maintainer ;) let's delay this until 2.11 is in debian
[12:28] <doko_> NCommander: your lzma process is still running on jocote ...
[12:28] <NCommander> doko_: yeah. its a test build of qt4 to find out why it timed out
[12:28]  * NCommander brings death to it
[12:28] <doko_> ahh, ok
[12:28] <NCommander> doko_: needless to say, we've found out why it times out ;-)
[13:17] <ArneGoetje> chrisccoulson: ping
[13:17] <chrisccoulson> hi ArneGoetje
[13:17] <ArneGoetje> chrisccoulson: which version of xulrunner will we have in Hardy and Jaunty?
[13:18] <chrisccoulson> ArneGoetje, we will be adding xulrunner-1.9.2, but xulrunner-1.9 will still be in the archive too
[13:20] <ArneGoetje> chrisccoulson: how about translations? firefox3.0/3.5 and xulrunner 1.9/1.9.1 have split translations, FF3.6 carries both. Means, the current xulrunner1.9 translations need to be stripped from the langpacks, right? Or should they stay?
[13:26] <ArneGoetje> chrisccoulson: I guess we keep the xul1.9 translations in the langpacks... xul1.9.2 should do the right thing and take the translations from firefox3.6, right?
[13:27] <chrisccoulson> ArneGoetje, yeah, i'm just trying to work out how this should work
[13:27] <ArneGoetje> chrisccoulson: thanks
[13:32] <happyaron> google code has changed and we need a new debian/watch, but what if I need to use dfsg? I mean dealing with googlecode should have and opts=downloadurlmangle=something, and for dfsg an opts=dversionmangle=something, how to make it work?
[13:38] <chrisccoulson> ArneGoetje, i think we should just drop the translations for firefox-3.0
[13:38] <chrisccoulson> if we keep them, then they will appear in the firefox extension manager as an unsupported extension, and i'm not sure anything in xulrunner needs those anyway
[13:39] <Ian_Corne> Het idee van RBO is dat er slechts \'e\'en domein bestaat, namelijk de waarneembare werkelijkheid. Dit wilt ook zeggen dat iedereen alles op dezelfde manier waarneemt en interpreteert.
[13:39] <Ian_Corne> In de echte wereld is dit echter ver van de waarheid. Waar de meeste Europeanen maar \'e\'en woord hebben voor sneeuw, daartegenover staat dat de Inuit er minstens twee\"entwintig hebben.
[13:39] <Ian_Corne> Indien men een ontologie per domein of context zou hebben, wordt dit opgevangen. Veel van deze onderscheiden zijn ook subjectief, wat de classificatie moeilijker maakt. Zo hebben de Inuit
[13:39] <Ian_Corne> ooops sorry
[13:39] <Ian_Corne> pasted in the wrong channel :)
[13:47] <ayan> good morning everyone!
[14:01] <snodnipper> does anyone have a sec to help out with a dpatch problem?
[15:26] <siretart> james_w: are you going to check with the TB? - I'm not sure what your concerns are...
[15:51] <nisshh> jcastro: do you have a minute, i have a quick question?
[15:54] <hrw> doko_: can you take a look at binutils change? http://paste.ubuntu.com/440913/
[15:56] <hrw> james_w: you take care of lp:ubuntu/binutils imports? it does not have maverick uploads
[16:11] <psusi> ScottK: Ted said that Scott had argued that e2fsck needs a "clock totally broken" flag for systems with broken real time clocks.  Did he mean you or Keybuck?
[16:13] <\sh> seb128: could it be that libebook1.2-dev which ships libebook-1.2.pc does have a totally wrong include dir for e-book.h? I'm trying to get giggle compiled, and it complains about e-book.h not being found...and it seems that the include dir in the libebook pkgconfig file is wrong
[16:15] <seb128> \sh, lucid?
[16:15] <\sh> seb128: maverick...but it's not wrong as I see now...giggle is doing something strange during the build...*grmpf*
[16:34] <\sh> strange it finds the libebook1.2 stuff, but doesn't replace EBOOK_CFLAGS in Makefile
[16:39] <ScottK> psusi: Keybuk
[16:40] <ogra> psusi, there is a bug upstream about it
[16:40] <ogra> psusi, http://sourceforge.net/support/tracker.php?aid=2992187
[16:41] <ogra> pfft
[16:43] <james_w> siretart: I didn't see a clear statement of their position, but I may be misremembering
[16:45] <psusi> ogra: you know much about it?  it seems like the problems arise from the clock being set to a very low value when the root is mounted, then corrected later... I thought that this might be resolved by forcing the clock to be >= the mkfs time stored in the root superblock before mounting it
[16:45] <siretart> james_w: I'm observing that this issue has been open for a really long time now, and I feel it's gotten stalled again now. I'd love to finally get it done.
[16:45] <ogra> psusi, seems like ted solved it already in e2fsprogs 1.41.12
[16:46] <ogra> (see the bug comment on SF)
[16:46] <james_w> siretart: I think it's resolved in the TBs mind, I just don't remember without looking whether it was "there's no problem", or "it's non-free but redistributable"
[16:46] <james_w> siretart: do you have a reference to the TB meetings where it was discussed?
[16:47] <siretart> not at hand, would need to search the archives as well
[16:49] <siretart> hm the last minutes from the technical board minutes are from 2010-04-20:
[16:49] <psusi> ogra: I don't see a comment at the url you linked... but it sounded like the "fix" was simply to disable the checks entirely by setting an option in the config file on systems with know broken clocks.  It seems it would be better to let the checks run, but after forcing the clock to a sane value
[16:49] <siretart> it reads: cjwatson to drive libfaac issue to conclusion: * Outstanding
[16:49] <ogra> psusi, its SF tracker, you need to expand the comments section :)
[16:49] <siretart> cjwatson: is the libfaac item still outstanding?
[16:49] <ogra> there is a little arrow
[16:49] <james_w> hrw: done
[16:50] <psusi> ahh, there it goes... wasn't obvious that was clickable ;)
[16:50] <ogra> yeah
[16:50] <ogra> i dont know what he did though, you need to look at the code
[16:50] <psusi> pretty sure it's what I just said
[16:51] <cjwatson> siretart: yes, sorry, it fell down my to-do list.  no time to think about it now
[16:51] <ogra> psusi, the "fix" we have downstream is that we set the clock to the last mount time from an initramfs script currently
[16:51] <ogra> and then leave fsck do its duty
[16:51] <siretart> cjwatson: ah, okay. No problem, I just wanted to know its status.
[16:51] <siretart> james_w: ^^
[16:51] <psusi> ogra: yes, I was thinking mkfs time, but last mount time works too... that seems a better fix to me
[16:52] <james_w> thanks siretart, cjwatson
[16:52] <ogra> psusi, but its an initramfs script without initramfs you are screwed ...
[16:52] <psusi> yep
[16:52] <ogra> so having it in fsck proper is essential
[16:56] <hrw> have a nice weekend everybody
[16:57] <psusi> I'm trying to figure out how such systems impact this patch I'm working on to allow us to turn on LAZY_ITABLE_INIT by default so mkfs goes MUCH faster... it clears inodes found with ctime < mkfs time since they obviously are leftover cruft from a previous fs, but if the system clock is broken....
[18:46] <ebroder> Is there documentation somewhere on the config file format for Upstart? I'm not really sure where to start looking
[18:56] <smoser> ebroder, man 5 init
[18:56] <ebroder> smoser: Thanks, I actually just found that
[18:57] <ebroder> Does upstart not support dropping privileges?
[18:57] <smoser> it does..
[18:57] <smoser> or maybe not
[18:57] <smoser> i'm onts re
[18:58] <psusi> it's init.. it kinda needs them
[18:58] <ebroder> I meant for the jobs it spawns
[18:59] <ebroder> It doesn't look like it can, though
[19:03] <smoser> i think it may just expect the daemon to do it
[19:20] <wise_crypt> i really hope this http://ubuntuforums.org/showthread.php?t=1494955 will be fixed soon enough :(
[19:22] <smoser> ebroder, i would look at how apache works.
[19:22] <smoser> oh wait.
[19:23] <smoser> yeah, i just looked at sshd (/etc/init/ssh.conf) it just expects for the daemon to change uid if its doing it.
[19:24] <ebroder> That's unfortunate. I was very close to not needing my daemons to know anything about daemonizing themselves
[19:27] <smoser> ebroder, i do recall that it has been on the feature list
[19:28] <ebroder> smoser: I don't see it in LP - I'll file a bug against the project
[19:43] <ricotz> seb128, hello
[19:47] <ricotz> seb128, i have started and worked my way through to a gtk+3.0 package
[20:24] <bryceh> slangasek or cjwatson, might one of you know where in Launchpad there is a page entitled "Copy archive contents"?
[20:24] <bryceh> (I'm fiddling with some Launchpad CSS which might affect that page so want to test it locally before committing)
[20:29] <slangasek> bryceh: never heard of such a page; afaik we still have to do all our archive copying from the command line
[20:30] <bryceh> mm ok
[20:32] <bryceh> slangasek, thanks I think I found it
[22:28] <mkarnicki> hi all, I'd like to setup my lp project (Google Summer of Code) https://launchpad.net/androidu1
[22:28] <mkarnicki> and I'm not sure to what branch should I push my in-progress sources
[22:28] <mkarnicki> (a, my mentor is not around, that's why I'm here :) )
[22:30] <mkarnicki> I just realized how that's done.. trunk for development, and adding 'stable' to version to indicate that.
[22:30] <mkarnicki> Never like answering your own question ;)
[22:30] <james_w> heh
[22:31] <mkarnicki> lol, I was looking for a project with something more than one branch (trunk), and it's actually featured by lp on main page :D exaile it is.
[22:32] <james_w> mkarnicki: you can push to any branch you like
[22:32] <james_w> say lp:~mkarnicki/androidu1/trunk
[22:33] <mkarnicki> james_w: my mentor just didn't want someone to pull my in-progress (= broken?) code ;)
[22:33] <james_w> then when you have done that you can link it to your "trunk" series and it people can then refer to it as lp:androidu1
[22:33] <mkarnicki> aa
[22:33] <james_w> release early, release broken!
[22:33] <mkarnicki> hahahah =D
[22:34] <mkarnicki> that made my day, thank you james_w :D (I know 'release early, release often')
[22:34] <mkarnicki> hahah :) thanks for help james_w
[22:35] <mkarnicki> james_w: your a gsoc student?
[22:35] <mkarnicki> *you're
[22:35] <james_w> nope
[22:35] <mkarnicki> mentor? :)
[22:36] <james_w> yes
[22:36] <james_w> well, co-mentor I guess
[22:36] <mkarnicki> I see you on ubuntu-gsoc, that's why I asked ^ ^ I think I also recall you from some mailing list
[22:36] <james_w> or just a helpful lurker :-)
[22:36] <mkarnicki> james_w: cool ^ ^! thanks for help, good to have to around :)
[22:36] <mkarnicki> helpful indeed
[22:37] <james_w> helpful this time
[22:37] <james_w> at least
[22:37] <mkarnicki> don't be so modest :D
[22:39] <james_w> I'm looking forward to trying your project though
[22:39] <mkarnicki> I'm happy to hear people say that ^ ^
[23:08] <AgentLime> got a question about ubiquity... anyone have any experience with it?
[23:16] <fta> siretart, hi, do you plan to re-upload mplayer in maverick?
[23:16] <fta> siretart, (the last ffmpeg upload killed it)
[23:18] <bloopbloop> Can anyone here help me compile a kernel module on Ubuntu 10.04?