[12:20] <Nergar> hello
[12:21] <Nergar> where can i file a complaint against an IRC op?
[12:22] <minghua> Nergar: maybe #ubuntu-ops
[12:24] <Nergar> thnx
[12:42] <hikenboot> can anyone give me an example of apt-get remove used in a for loop where the input is a kicklist from a file?
[12:44] <Fujitsu> hikenboot: #ubuntu for support, thanks.
[05:59] <therealnanotube> could someone please tell me about ubuntu package versioning conventions. e.g, if i have something with Version: "4.19-1ubuntu2.1", i understand that 4.19 is the actual software version, but what's the 1ubuntu2.1 stand for?
[05:59] <therealnanotube> i want to package my software into an ubuntu deb, and i want to know how the versioning stuff goes...
[06:00] <therealnanotube> i hope this is a good place to ask... :)
[06:00] <ion_> Try #ubuntu-motu
[06:00] <persia> therealnanotube: 1 is the debian revision, and 2.1 is the ubuntu revision.  This probably means Ubuntu made two uploads after the last Debian upload, and then there was a security release (or the like).  #ubuntu-motu may be a better place to ask about packaging.
[06:00] <therealnanotube> persia: ion_: thanks, i'll try motu :)
[06:14] <khermans> "E: Couldn't configure pre-depend coreutils for debianutils, probably a dependency cycle."
[06:14] <khermans> http://lists.debian.org/debian-devel/2006/09/msg00135.html
[06:42] <Hobbsee> right, aptitude and debtags uploaded
[06:42] <Hobbsee> :)
[06:42] <RAOF> Hobbsee: Yay!
[06:42] <Hobbsee> waiting on python-apt to checkout, will upload that too, then will upload adept and synaptic
[06:46] <Hobbsee> oh grrr.  apt never got built.
[06:46] <Hobbsee> therefore, those two uploads are worthless.
[06:47] <Hobbsee> but one got rejected anyway
[07:22] <superm1> Hi guys, anyone available for sponsorship for a package from main?
[07:23] <Hobbsee> depends what it is
[07:23] <superm1> Hobbsee, lirc
[07:23] <Hobbsee> mneptok: why +t?
[07:25] <superm1> Hobbsee, bug: #124842
[07:29] <Hobbsee> superm1: i'd prefer not to
[07:30] <superm1> Hobbsee, why is that?
[07:31] <Hobbsee> because i'm doing various things here already, and that looks big
[07:32] <superm1> oh okay :)
[07:32] <superm1> getting all our apt toys fixed is more important anyhow :P
[07:33] <Hobbsee> superm1: well, yeah.  i'd like to be able to fix that, but i cant.
[07:34] <superm1> Hobbsee, what happened?
[07:34] <Hobbsee> superm1: before, or now?
[07:34] <Hobbsee> superm1: now, i'm waiting for cjwatson and co to wake up
[07:34] <superm1> ah okay
[07:34] <Hobbsee> so they can fix soyuz up with a bit more string
[07:35] <Hobbsee> superm1: the problem now is that soyuz is accepting the sources, but isnt actually allocating the binaries to be built
[07:36] <superm1> why do things like this where soyuz gets a little quirky happen?
[07:40] <Hobbsee> well, when soyuz breaks...the stuff that it does also breaks...
[07:41] <Hobbsee> i dont understand your question, beyond that
[07:41] <Fujitsu> superm1: Because Soyuz is nice and buggy and likes to have fits over weekends, I guess.
[07:41] <superm1> of course :)
[07:42] <Fujitsu> And doesn't seem to be able to restart the build queuer without manual intervention.
[07:47] <Fujitsu> TheMuso: It's empty at the moment :P
[07:48] <Fujitsu> That's the whole problem.
[07:48] <TheMuso> Fujitsu: ah.
[07:49] <Hobbsee> nwo that will be evil
[07:49] <Fujitsu> Whatever it is that's meant to create builds from published sources and stick them in the queue has got some issues.
[07:49] <Fujitsu> At least it isn't eating uploads.
[07:50] <persia> Fujitsu: That may not be a good thing.  It's too easy to upload something that build-depends on something else that changed with a significant build/release delay.
[07:51] <Hobbsee> persia: well, of course soyuz breaking is not good...
[07:51] <Hobbsee> we're still a week and a half away from our next tribe, anyway
[07:51] <StevenK> Ubuntu, Launchpad, or both?
[07:51] <Fujitsu> (as well as the all too common complete failures over a weekend)
[07:52] <Fujitsu> Launchpad
[07:53] <Fujitsu> Well, cjwatson killed cron.daily last night because it had been hanging for a couple of hours.
[07:53] <Fujitsu> It seemed the build queuer came down with that, and never came back up.
[07:53] <Fujitsu> *smees.
[07:53] <Fujitsu> Bah.
[07:53] <Fujitsu> **seems
[08:11] <Mithrandir> Hobbsee: hm, what is b0rken today?
[08:11] <Hobbsee> Mithrandir: soyuz.  apt source has been published, but the binaries havent been built
[08:11] <Hobbsee> Mithrandir: good morning, btw :)
[08:11] <Hobbsee> Mithrandir: how is london?
[08:11] <Mithrandir> morning
[08:11] <Mithrandir> nice and warm
[08:11] <StevenK> The binaries haven't even been registered yet.
[08:11] <Mithrandir> I went for a run which ended up being a bit short.
[08:12] <Hobbsee> warm.  hmmm.
[08:12] <Fujitsu> Mithrandir: Builds aren't registering for published sources since cjwatson killed cron.daily 24 hours ago.
[08:12] <Mithrandir> StevenK: give me the name of a source which should build?
[08:12] <StevenK> Mithrandir: kwave
[08:12] <Hobbsee> early run, seeing as current time there is 7am
[08:12] <Hobbsee> Mithrandir: apt!
[08:12] <StevenK> Hobbsee: Beat you. :-P
[08:12] <Fujitsu> Take your pick from DONE in the last 24 hours.
[08:12] <StevenK> Ouch! That tickles.
[08:13] <Hobbsee> StevenK: dont enjoy it too much :P
[08:14] <Mithrandir> debugging python with strace++
[08:15] <StevenK> Oh twitch. I've done that more often than I care to recall.
[08:15] <StevenK> Perl is a little more insane, given it's internals.
[08:20] <Sp4rKy> hi
[08:21] <Sp4rKy> is there someone to review my initramfs-tools update ?
[08:21] <Sp4rKy> s/update/merge
[08:21] <TheMuso> Sp4rKy: Is the main sponsors team subscribed to the bug?
[08:22] <Sp4rKy> TheMuso: i've not yet open the bug
[08:22] <Sp4rKy> as i would someine check debdiff before
[08:22] <TheMuso> Sp4rKy: It might be an idea.
[08:22] <TheMuso> Attach the debdiff to the bug, and subscribe ubuntu-main-sponsors.
[08:22] <Sp4rKy> k
[08:34] <Sp4rKy> Bug #124855
[08:34] <ubotu> Launchpad bug 124855 in initrd-tools "please merge initramfs-tools from Debian (unstable)" [Undecided,New]  https://launchpad.net/bugs/124855
[08:36] <Hobbsee> Mithrandir: any luck?
[08:36] <persia> Sp4rKy: You may wish to set the bug to be against the initramfs-tools package, so as to get the attention of the appropriate parties.
[08:37] <Sp4rKy> oh yes
[08:37] <Sp4rKy> done :)
[08:38] <Mithrandir> Hobbsee: not really. :-/
[08:38] <Hobbsee> Mithrandir: :(
[08:38] <Mithrandir> but I need some fod
[08:38] <Mithrandir> food
[08:38] <Hobbsee> mmm...food.
[08:39] <TheMuso> Hobbsee: lol
[08:48] <Hobbsee> oh yay, now apt says "needs building"
[08:54] <Fujitsu> Yay, thanks Mithrandir.
[09:01] <Hobbsee> uh, what?
[09:01] <Hobbsee> why are people subscribing ubuntu-release to bugs?
[09:02] <Hobbsee> hi cprov
[09:02] <cprov> Hobbsee: morning.
[09:05] <Fujitsu> bug #58410
[09:05] <Fujitsu> !ping
[09:05] <persia> Fujitsu: It's about limitations to "subscribe someone else".
[09:06] <Fujitsu> Ah, right.
[09:06] <Fujitsu> That's the only way to go about it, IMO.
[09:07] <persia> Fujitsu: Depends.  It breaks current U-U-S, U-M-S, and U-A workflow to completely restrict, but not all groups are like that.
[09:07] <Hobbsee> i was about to say that
[09:07] <Fujitsu> It needs to be an option linux restricted/moderated/open/ondemand is now.
[09:07] <Fujitsu> Uh, s/linux/like
[09:08] <persia> Fujitsu: If you've got a plan - comment on the bug :)
[09:12] <Hobbsee> works on i386,w hich is what i tested on.  dies on ppc, sparc
[09:12] <Fujitsu> Are sparky and intrepid still around?
[09:13] <Fujitsu> And can someone look at the build logs for libfilesys-diskspace-perl and work out why it fails on the buildds but nowhere else?
[09:18] <Fujitsu> Heh. That's all telemarketers are good for.
[09:18] <Hobbsee> actually, wasnt a proper telemarketer
[09:18] <Hobbsee> seeing as they're on the do not call list
[09:32] <siretart> Hobbsee: you uploaded aptitude earlier today? I hope I didn't confuse you with mine ;
[09:32] <siretart> ;)
[09:32] <Hobbsee> siretart: my upload for that is waasted
[09:32] <Hobbsee> it'll need another rebuild anyway
[09:32] <siretart> Hobbsee: oh :(
[09:33] <Hobbsee> Mithrandir: can you giveback apt on all arches that didnt build (ie, !i386) please?  this just built on amd64 too
[09:34] <Hobbsee> siretart: did you upload aptitude before or after me?
[09:35] <siretart> Hobbsee: I uploaded it about 14hours ago
[09:36] <Hobbsee> siretart: right.  so mine was way after
[09:36] <Hobbsee> siretart: i rebuilt whatever was in the archive, so...
[09:36] <siretart> you's was 14h ago as well: https://launchpad.net/ubuntu/+source/apt
[09:36] <Hobbsee> oh.  that's why it failed!
[09:37] <Hobbsee> i wondered why i got an error about it, but then discovered that apt hadnt built anyway
[09:37] <Hobbsee> siretart: it needs to be rebuilt on the new apt nayway, so...
[09:37] <siretart> Hobbsee: I'll let you handle this then ;)
[09:37] <Hobbsee> siretart: was yours a rebuild too?
[09:37] <siretart> Hobbsee: yes, rebuild only
[09:38] <Hobbsee> right, cool.  ok
[09:38] <siretart> I wanted to dist-upgrade and noticed that aptitude was held back (for about 2 days)
[09:38] <Fujitsu> Hobbsee: That's a fairly large world.
[09:38] <siretart> indeed
[09:38] <Hobbsee> true
[09:38] <StevenK> Mis-spelt world, too
[09:38] <StevenK> Eww, Melbourne germs!
[09:38] <Fujitsu> Yay, other Ubuntuers.
[09:38] <Hobbsee> siretart: so is anything else depending on libapt
[09:39] <siretart> Hobbsee: speaking of apt, any chance we get ept-cache soon?
[09:39] <StevenK> apt != libept
[09:39] <siretart> Hobbsee: from the changelog I see that adept is blocking the new libept version
[09:39] <siretart> StevenK: I know
[09:40] <siretart> StevenK: I've seen demonstration about ept-cache at debconf. I very much liked ept-cache
[09:43] <Hobbsee> siretart: no idea, ask manchicken
[09:50] <TheMuso> 0/c
[09:50] <TheMuso> ugh
[09:50] <TheMuso> ugh
[09:51] <StevenK> Geez. Give i386 another hour and it'll be saying, "What backlog?"
[10:55] <dholbach> good morning
[10:59] <simira> morning
[10:59] <simira> dholbach: you are going to guadec, right? When do you go to Birmingham?
[11:00] <dholbach> simira: nope
[11:00] <dholbach> simira: won't go there - mvo and seb128 are going to
[11:00] <simira> oh :(
[11:00] <dholbach> I'll be at the sprint now and ubuntulive and after that on holidays
[11:00] <dholbach> so that's going to be enough time away from my desk at home
[11:00] <simira> sounds nice :)
[11:01] <dholbach> sorry, I would have liked to go guadec too - maybe next one :)
[11:01] <simira> I'm not really going there - only to Birmingham :p
[11:01] <simira> for the weekend
[11:01] <dholbach> right - have a good time there then :)
[11:02] <simira> I will
[11:02] <simira> dropping by London on Friday as well, btw
[12:31] <Keybuk> evand:
[12:31] <Keybuk> http://forums.opencompositing.org/viewtopic.php?f=40&t=522
[12:50] <sabdfl-afk> howdy all
[12:51] <calc> sabdfl: hello :)
[12:51] <sabdfl> upgrades on my laptop are currently wedged on somthing to do with libcurl3-gnutls
[12:52] <sabdfl> is that a known issue, or something i should help debug specially?
[12:52] <calc> sabdfl: openoffice probably, doko i believe uploaded a new version of it yesterday
[12:53] <stgraber> sabdfl: OpenOffice + libcurl3-gnutls work here on amd64, but IIRC build failed on i386
[12:53] <sabdfl> ah, that could be it
[12:55] <StevenK> calc: Which failed on i386, if I recall.
[12:55] <evand> thanks Keybuk, I'll give that a try
[12:55] <stgraber> failed on sparc, powerpc and i386, succeeded on amd64 and ia64
[12:55] <calc> StevenK: lovely
[12:55] <StevenK> sabdfl: openoffice.org is the last cog in the chain of this libcurl4{,-{openssl,gnutls} mess.
[12:56] <StevenK> calc: Enjoy. :-P
[12:56] <calc> StevenK: openoffice fails in strange and mysterious ways depending on the phase of the moon ;)
[12:56] <StevenK> calc: I'm well aware of that, I've read enough of the failures. :-)
[12:57] <stgraber> 27 hours for a fail :)
[01:00] <doko> calc, yes the OOo version should have fixed that; didn't see the build failure yet. it's not obvious with parallel builds :-/
[01:00] <StevenK> fabbione: Is London hot enough for you? :-P
[01:01] <fabbione> StevenK: no women are hot enough for an iTalian :P
[01:01] <simira> how is London?
[01:01] <fabbione> warm
[01:01] <fabbione> but not hot
[01:01] <StevenK> fabbione: Could you repeat that, I have your wife on the other line ...
[01:01] <stgraber> fabbione: I updated the ISO Testing Tracker yesterday, now we have a single DB with all test results (even Feisty), here : https://isotesting.stgraber.org/isotesting/archive/Ubuntu (for Ubuntu)
[01:02] <fabbione> stgraber: great thanks but what I got was enough
[01:02] <fabbione> StevenK: sure.. i tell her all the time :)
[01:03] <calc> stgraber: our i386 buildd takes 27+ hr to build ooo?
[01:04] <StevenK> Depends if palmer grabbed it or not.
[01:04] <StevenK> Given that palmer is twice as fast as rothera.
[01:04] <calc> takes about 4hr on my desktop machine, maybe buildds need an upgrade ;)
[01:05] <StevenK> Hold on, don't you use ccache?
[01:05] <calc> get some of those nice shiny Q6600 chips (~ 250 USD) at the end of the year for amd64 and i386 buildd
[01:05] <calc> StevenK: yea, but iirc 3-4hr is for uncached build
[01:06] <calc> StevenK: with hot ccache i can do it in ~ 30m from what i recall
[01:06] <StevenK> I recall a friend of mine porting OO.o to AIX. The machine they gave him access too would build it in about 2 weeks...
[01:06] <calc> actually iirc 3-4hr is for uncached build without nogsi, i think was able to build with nogsi uncached in about 1.5-2hr
[01:07] <calc> i have a C2D E6300
[01:08] <calc> i think it may already be discontinued now, but was ~ $160 USD
[01:50] <ScottK> keescook: Please let me know if there is anything else that needs to be done on my end for the gnupg updates.  The updated debdiff (geser figured out my problem) is in Bug #76983.
[02:06] <nysosym> hi there
[02:06] <dholbach> nixternal: what do you think about setting the maintainer address of tapioca-qt and decibel to kubuntu-devel@lists.ubuntu.com or something?
[02:06] <nysosym> does gutsy use the madwifi driver from svn?
[02:07] <Riddell> dholbach: isn't our policy to set everything to -motu ?
[02:07] <dholbach> Riddell: no, we set ubuntu-desktop@lists.ubuntu.com for a couple of packages too
[02:08] <dholbach> ubuntu-motu@ and ubuntu-devel-discuss@ are a fallback for everything else
[02:08] <Riddell> dholbach: it seems like a good idea, but then we have lots of kde packages that might be best set to kubuntu-devel
[02:08] <dholbach> Riddell: also... I meant Maintainer + XSBC-Original-Maintainer
[02:08] <beuno> nysosym: the versioning doesn't suggest it does, no, porbably a sync from debian
[02:09] <dholbach> I'm happy if nixternal and other Kubuntu folks take care of it,
[02:10] <nysosym> beuno, thx, hmm ok, i hope this driver will used, because my macbook doesn't have wifi out of the box and ndiswrapper is very crappy
[02:15] <keescook> ScottK: cool, thanks!  I'll get to it :)
[02:17] <ScottK> keescook: Great.  He added one more bug to the mix.  I've no opinion on that.
[02:21] <Hobbsee> hi simira
[02:47] <KnowledgEngineer> hellp
[02:47] <KnowledgEngineer> hello
[02:47] <KnowledgEngineer> this is the good channel for ask everything about programming under ubuntu?
[02:48] <ion_> Please read the topic.
[02:48] <KnowledgEngineer> there is a channel good for me?
[02:50] <ion_> Programming isnt really different under Ubuntu or any other similar environment, so you probably should look for generic channels about the thing youre programming with.
[02:50] <persia> KnowledgEngineer: For proper development, you'll get better support from a channel dedicated to your programming language or target libraries, rather than one for the distribution you'll be using.  For packaging, #ubuntu-motu might help.
[02:51] <KnowledgEngineer> my problem is related to lisp and asdf-install
[02:51] <KnowledgEngineer> asdf-install is a program for download and install lisp extensions
[02:51] <KnowledgEngineer> example graphic library .....
[02:52] <KnowledgEngineer> on lisp channel nobody helped me
[03:03] <evand> mvo: http://www.vmware.com/community/thread.jspa?messageID=677688
[03:03] <evand> and the any-any 110 update
[04:11] <shawarma> When adding an argument at the end of a function's prototype (in C), is a SONAME bump required. It seems to work, but is that just a coincidence?
[04:12] <shawarma> "is a SONAME bump required" was a question, not a statement.
[04:12] <infinity> Addind an argument at the end of a prototype doesn't break backward compat.
[04:12] <shawarma> infinity: Great. Thanks.
[04:13] <infinity> From the POV of Debian shlibs, though, you need to bump the shlibdeps.
[04:13] <infinity> Cause anything using the new interface won't work with the old lib, obviously.
[04:14] <seb128> infinity: you sort of break compatibility because programs that used to build fine will not
[04:15] <infinity> Not on the planet I live on...
[04:15] <ogra> planet ubuntu ?
[04:15] <ogra> or pizza planet ?
[04:15] <infinity> Well, assuming this new argument is optional.
[04:15] <seb128> infinity: how do you define an optional argument?
[04:15] <infinity> If it's mandatary then, yes, you broke builds.
[04:17] <infinity> It's also possible that I'm half asleep and thinking in the wrong language. :P
[04:17] <broonie> infinity: You can't do optional arguments in C except via varargs.
[04:17] <infinity> See?
[04:17] <broonie> (well, and struct sizing tricks too)
[04:18] <infinity> Doesn't help that I've just been staring at apt source (thanks, mvo), which could be causing temporary insanity.
[04:18] <shawarma> seb128: You you put a #define API_VERSION to the header files, you can check that.
[04:18] <Sp4rKy> is there some main sponsor ?
[04:19] <persia> Sp4rKy: Best to use the ubuntu-main-sponsors queue, rather than hunting people.
[04:19] <Sp4rKy> persia: i already subscribe them :)
[04:20] <Sp4rKy> subscribed*
[04:23] <nixternal> dholbach: that is fine with me
[04:30] <dholbach> nixternal: so will you do that?
[04:30] <Hobbsee> dholbach@
[04:30] <Hobbsee> !
[04:30] <dholbach> hey Hobbsee!
[04:30] <nixternal> Hobbsee@
[04:30] <nixternal> !
[04:30] <Hobbsee> :)
[04:30] <nixternal> dholbach: sure
[04:30] <Hobbsee> !nixternal
[04:30] <ubotu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
[04:30] <nixternal> I will put.....omg no you didn't!
[04:30] <nixternal> ;)
[04:30] <dholbach> nixternal: rock on
[04:51] <Keybuk> mvo: compiz enhancement request (file appropriately)
[04:52] <Keybuk> if a window grabs the keyboard, compiz should fade out all other windows and the background to a dull grey
[04:53] <Chipzz> is there a way of, when filing a bug, indicating that the bug applies to the development release, and if possible should be triaged sooner or not at all?
[04:54] <Chipzz> I have received first replies on bugs that are over 6 months or a year old
[04:54] <Chipzz> at which point the bug doesn't matter anymore
[04:55] <Hobbsee> Chipzz: you can either mention it in the bug, or make a gutsy task for it.  it really depends if people are actually looking at the bugs, though
[04:55] <Hobbsee> as in, it's assumed that all bugs are for the development release
[04:56] <Chipzz> uhu
[04:56] <Chipzz> I'm not saying those bugs were important
[04:56] <Chipzz> because they were not
[04:56] <Chipzz> quite the contrary, really small issues (pollish if you want) that could be fixed really fast
[04:56] <Hobbsee> Chipzz: the problem there is in not enough people triaging bugs.  not that "the bugs didnt contain 'this is in the development version' so didnt get looked at"
[04:57] <Chipzz> uhu
[04:57] <Chipzz> but nagging someone on irc about it would also not be correct I guess
[04:57] <Chipzz> :P
[04:58] <Hobbsee> true.  but then, the right person, especially if you've provided a patch, is helpful
[04:58] <Hobbsee> and making sure that if the package is directly from debian, you file the bug in debian too, and link it.
[04:58] <Hobbsee> it really depends
[04:59] <simira> Hobbsee: isn't it late night for you now?
[04:59] <Hobbsee> simira: it's about 1am.  not that bad.
[04:59] <Hobbsee> :)
[04:59] <Mithrandir> she's trying to move .au closer to europe by staying up all night.
[04:59] <Hobbsee> simira: i tend to live european days, i think
[04:59] <Hobbsee> exactly
[04:59] <simira> Hobbsee: oh, so no work tomorrow morning? ;)
[04:59] <Hobbsee> simira: no.  not to my knowledge.  although they tried to call me twice tonight
[05:00] <Hobbsee> simira: i've already had my roster completely changed once this week
[05:00] <StevenK> Oh damn, I didn't think it was this early.
[05:01] <simira> early? Not really.
[05:01] <simira> didn't you guys just have lunch?
[05:02] <StevenK> 1 *am*, not pm
[05:02] <Hobbsee> simira: actually...where lunch == second meal of the day...yes i did.
[05:02] <simira> uhm, StevenK, I thought you were in London
[05:02] <Hobbsee> simira: wrong IP for that
[05:02] <StevenK> simira: Oh, right. It seems I wasn't invited. :-)
[05:03] <simira> Hobbsee: uh, what does an ip on irssi say anyway? Check Tollef's :p
[05:04] <Hobbsee> simira: excluding those who are ssh'ing out of london, into their machines in their homes / their offices
[05:04] <simira> Hobbsee: I mostly ssh from anywhere I go...
[05:04] <Hobbsee> you are lucky enough to have a server to do that.
[05:04] <Mithrandir> IPs are overrated anyway. :-P
[05:04] <StevenK> Heh
[05:05] <StevenK> I usually ssh home and screen in for IRC.
[05:05] <StevenK> Except in cases where the link is dreadful for real-time traffic.
[05:06] <Hobbsee> simira: i was thinking in the case of [01:05]  [Whois]  fabbione is i=fabbione@nat/canonical/x-670f3c1f0d7cb4c8 (Fabio Massimo Di Nitto)
[05:06] <Hobbsee> simira: but yes, it doesnt cover those who ssh
[05:10] <Hobbsee> simira: i'll just admit to being wrong, and go back into hiding.  that sound good?   :P
[05:11] <infinity> Admitting to being wrong is a sign of weakness.  Just do what I do, and pretend you don't understand the language.
[05:12] <zul> heh
[05:12] <Hobbsee> infinity: heh
[05:13] <Hobbsee> hiya pitti_!
[05:13] <simira> hehe
[05:13] <pitti> hey Hobbsee
[05:13] <simira> Hobbsee: you might consider going to bed?
[05:13] <simira> ;)
[05:13] <simira> infinity: how's London?
[05:14] <Hobbsee> simira: i might.  i'm more tempted to just hide from irc.
[05:14] <infinity> simira: Same as always.  They didn't move the river or anything.
[05:14] <Hobbsee> simira: or behind some other alias, indefinetly.
[05:14] <simira> infinity: last time I heard, they expanded it?
[05:15] <StevenK> infinity: What, they just aren't putting the effort in? :-P
[05:15] <infinity> simira: Looks vaguely similar to me.
[05:16] <infinity> simira: I'll admit to not being an expert on the width of rivers around the world...
[05:17] <Hobbsee> infinity: get a longer tape measure, then.
[05:17] <simira> infinity: I'd guess. But the place where the sprint is, is nice?
[05:17] <alex-weej> does anyone know anything about spontaneous xorg crashes today? :E
[05:17] <infinity> simira: The new offices are nice, yeah.
[05:19] <simira> alex-weej: sounds like a real distro-sprint :D
[05:19] <desrt> guadec guadec guadec
[05:19] <alex-weej> it's happened to me three times today while browsing the web... absolutely stumped
[05:19] <alex-weej> anyone know how i debug?
[05:19] <Hobbsee> desrt: no guadec for you!  NOT YOURS!
[05:19] <alex-weej> i haven't had an Xorg crash since i used Gentoo :P
[05:19] <desrt> guadec for me.  no guadec for hobbsee.
[05:20] <Hobbsee> desrt: oh well.  no one trying to break me then, if i'm not at guadec
[05:20] <desrt> no akademy for hobbsee either
[05:20] <desrt> sucks to live in .au, eh?
[05:20] <desrt> alex-weej; guadec this year?
[05:21] <alex-weej> desrt: hopefully, awaiting charity for accommodation
[05:21] <Hobbsee> desrt: seems a fair few others had
[05:21] <thom> this could be a somewhat fight-club esque situation...
[05:21] <alex-weej> i have no laptop so it's going to be an interesting week hehe
[05:21] <Hobbsee> thom: hm?
[05:21] <Hobbsee> desrt: i'm sure you'll cope
[05:21] <desrt> alex-weej; :)
[05:21] <desrt> Hobbsee; i see it as a positive thing, really :)
[05:22] <Hobbsee> hah.  thanks a lot.  :P
[05:22] <simira> desrt: I'm not going to guadec, I just pretend to
[05:22] <desrt> oh.
[05:22] <thom> Hobbsee: the first rule of Hobbsee-breaking is...
[05:22] <desrt> thom; DON'T TALK ABOUT HOBBSEE BREAKING
[05:22] <simira> desrt: but I might meet up with some poor volunteers for dinner and beer on saturday night. I leave sunday 2 pm
[05:23] <Hobbsee> thom: is probably something to the effect of "go for the bits that break the easiest"
[05:23] <alex-weej> GRR
[05:23] <alex-weej> stuff keeps crashing, i think i have proper issues :(
[05:23] <desrt> simira; drop by the conservatoire
[05:23] <desrt> simira; it's always a fun crowd :p
[05:23] <desrt> Hobbsee; just don't try and put it in your carryon bags
[05:23] <simira> desrt: where is that? Pretty central anyway, I guess. And yes, I probably will.
[05:23] <StevenK> Buy one there, much simpler
[05:23] <Hobbsee> right, right.
[05:24] <desrt> simira; it's the conference venue
[05:24] <desrt> simira; very close to the train station
[05:24] <simira> desrt: ah. Well, I might hang around until  my train leaves.
[05:24] <simira> *sigh* no one wants to play with me :-/
[05:25] <Hobbsee> simira: play what?
[05:25] <desrt> simira; you just have to be in the right places
[05:25] <simira> carcassonne
[05:25] <desrt> nobody wants to play at the train station
[05:25] <simira> I AM in the right place
[05:25] <ogra> carcassonne ? oh envy
[05:25] <desrt> no guadec for ogra
[05:26] <Hobbsee> hiya ogra
[05:26] <simira> ogra: the German game
[05:26] <ogra> hey Hobbsee
[05:26] <desrt> i guess we get seb, dh, mvo and maybe scott?
[05:26] <simira> desrt: for guadec, yes
[05:26] <ogra> desrt, dh is on holiday that time
[05:27] <desrt> wow.  that's creepy.
[05:27] <Keybuk> asac:
[05:27] <Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  starting...
[05:27] <ogra> no, well deserved
[05:27] <Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: lo, ifi_flags: 65609, IFF_RUNNING: 64, IFF_VOLATILE: 199770
[05:27] <desrt> "scott"
[05:27] <Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: eth0, ifi_flags: 4098, IFF_RUNNING: 64, IFF_VOLATILE: 199770
[05:27] <desrt> *joins scott
[05:27] <Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: irda0, ifi_flags: 128, IFF_RUNNING: 64, IFF_VOLATILE: 199770
[05:27] <Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: eth1, ifi_flags: 4098, IFF_RUNNING: 64, IFF_VOLATILE: 199770
[05:27] <seb128> ogra: he's not
[05:27] <desrt> seb128; did you vendor patch that compositing fix yet? :p
[05:27] <seb128> ogra: he just take a non travelling week before Ubuntulive
[05:28] <seb128> desrt: what composite fix? ;)
[05:28] <desrt> seb128; the one that landed upstream a few days ago :p
[05:28] <seb128> desrt: did it get commited to git now?
[05:28] <Keybuk> asac: in fact, let me grep and paste you the entire thing, there's a lot here
[05:28] <seb128> desrt: do you have the git revision handy?
[05:28] <desrt> no.  but it's recent.  i'll find it.
[05:28] <seb128> thanks
[05:28] <ogra> seb128, ah, i thought his vacation would extend to that as well...
[05:29] <desrt> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=866f092ca0160a366add01b48ad03438926c4d16
[05:29] <Keybuk> asac: http://people.ubuntu.com/~scott/syslog.nm
[05:30] <StevenK> dholbach: Can you not get dh_iconcache to print "Warning: Please use dh_icons instead. dh_iconcache is going to go away." in a loop? sbuild will kill building processes that print the same thing over and over to prevent busy-loop spinning on the buildds. Worse, it gives the build to another buildd so they can do the same thing. BAD.
[05:30] <seb128> desrt: thanks
[05:30] <desrt> seb128; honestly, you can probably just wait
[05:30] <dholbach> StevenK: hu?
[05:30] <seb128> wait for what?
[05:31] <desrt> next release, i guess?
[05:31] <dholbach> StevenK: what happens? how does it happen? I didn't see that happening?
[05:31] <desrt> unless that's not going in gutsy....
[05:31] <seb128> desrt: right ...
[05:31] <StevenK> dholbach: http://launchpadlibrarian.net/8340553/buildlog_ubuntu-gutsy-i386.kwave_0.7.7-3ubuntu1_NEEDSBUILD.txt.gz
[05:31] <desrt> ya.  better do it now, then :p
[05:31] <nixternal> dholbach: what about telepathy-qt? do the same thing with or just leave that one alone?
[05:31] <dholbach> nixternal: yeah, sounds like a good idea
[05:31] <nixternal> roger dodger
[05:31] <desrt> it'll be nice if people at guadec can sample the bling :)
[05:32] <dholbach> StevenK: I have no idea what's happening there :-(
[05:32] <nixternal> my laptop has spinners! does that count for bling? :)
[05:32] <dholbach> StevenK: dh_iconcache just calls dh_icons now
[05:34] <StevenK> I know why it happens.
[05:34] <StevenK> print "Warning: Please use dh_icons instead. dh_iconcache is going to go away.\n
[05:34] <StevenK> ";
[05:34] <StevenK> Recursion much?
[05:34] <StevenK> system("dh_iconcache @ARGV");
[05:34] <StevenK> dholbach: Shall I upload a fix?
[05:35] <infinity> StevenK: Still around?
[05:35] <dholbach> StevenK: yeah, that would be great
[05:35] <StevenK> infinity: Yup
[05:35] <infinity> StevenK: I have over 8000 dh_iconcache processes on my buildd.  Plsfixkthx.
[05:35] <StevenK> infinity: ^
[05:35] <infinity> Kay.  I'm going to kill the builds, and assume your fix is imminent.
[05:35] <dholbach> sorry, that was my fault
[05:36] <StevenK> infinity: Yup, give me a few minutes.
[05:36] <dholbach> great that I'm sharing room with infinity - I will be murdered in my bed
[05:36] <StevenK> Muahahaha
[05:36] <StevenK> dholbach: It was nice knowing you.
[05:36] <ogra> dholbach, any plans who will get your laptop ?
[05:36] <StevenK> Haha
[05:37] <dholbach> ogra: my brother, he needs it more than you do
[05:37] <Hobbsee> dholbach: i suggest you attempt to find another room.  pronto
[05:37] <ogra> dholbach, heh :)
[05:37] <pitti> Mithrandir: (CC: dholbach, cjwatson): I added some stuff to https://wiki.ubuntu.com/NewPackageRequirements; do you have any further ideas?
[05:37] <dholbach>  P R O N T O
[05:37] <dholbach> pitti: checking it
[05:37] <Mithrandir> that's the first time I've seen Ccs on IRC. :-P
[05:38] <dholbach> pitti: thanks - that looks good
[05:39] <StevenK> dholbach, infinity: Uploaded.
[05:39] <dholbach> StevenK: thanks a lot
[05:39] <StevenK> If the buildds have a heartache between now and the time the binaries get published is another story.
[05:40] <Mithrandir> pitti: prefered => preferred;  Also, whether an editor exists or not is actually not relevant to whether we're allowed to distribute it.
[05:40] <Mithrandir> pitti: the problem is when we get something which is not in the preferred form of modification, and I'd like it if you put something about PDF files as an example.
[05:41] <pitti> Mithrandir: ok, I'll tweak the 'common errors' point about PDF
[05:41] <Mithrandir> pitti: the GFDL is in /usr/share/common-licenses as of gutsy
[05:41] <pitti> ah, sweet
[05:42] <Mithrandir> pitti: and the openssl linking clause could use an "directly or indirectly".
[05:42] <Mithrandir> apart from that it looks fine to me
[05:43] <Hobbsee> pitti: an exhaustive list of things that are and are not allowed might be useful
[05:43] <Hobbsee> at least, the most common ones
[05:43] <MidMark> hi guys
[05:44] <MidMark> are there problems with Feisty and Santa Rosa platform that someone knows?
[05:45] <MidMark> because I have this problem and if you have some time to help me will be much appreciated
[05:45] <MidMark> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/124187
[05:45] <ubotu> Launchpad bug 124187 in linux-source-2.6.20 "cdrom recognized with alternate installation after installation is disappeared" [Undecided,New] 
[05:46] <MidMark> I have provided as many informations as I can
[05:46] <geser> infinity: Hi, have you had a chance to look on bug #87077?
[05:46] <ubotu> Launchpad bug 87077 in launchpad-buildd "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,New]  https://launchpad.net/bugs/87077
[05:46] <geser> xmms2 doesn't use scons any more but other packages still use it and probably FTBFS for the same reason
[05:47] <pitti> Mithrandir: page updated with your feedback, thanks
[05:47] <Mithrandir> Hobbsee: exhaustive list would require a lot of work, and people seem to be able to come up with too many ways to do crackful things for us to make a good list. :-P
[05:50] <wwoods> pitti: hey, got some apport stuff to talk to you about
[05:50] <pitti> hey wwoods, long time no see
[05:51] <wwoods> yeah, had to do a bunch of other stuff before I freed up enough time for apport
[05:51] <pitti> wwoods: I did a lot of abstraction work on apport since we talked last
[05:51] <wwoods> I saw!
[05:51] <pitti> so it should be much easier to adapt to bugzilla and such
[05:51] <wwoods> actually I have a really small patch for you that relates to that
[05:52] <pitti> wwoods: do you see any major obstacles left?
[05:52] <wwoods> well, I was thinking we should get both of us using the same method for gathering info from the core
[05:52] <wwoods> I should give you the elfcore.py code
[05:53] <wwoods> it seems your kernel patch is unlikely to make it upstream, so..
[05:53] <pitti> wwoods: oh, is it?
[05:53] <wwoods> the major thing ATM is the crashdb bit - you mention on the wiki that you want to have a separate crashdb
[05:53] <pitti> wwoods: I would really be happy if it would make it, to avoid writing the dump to disk temporarily
[05:54] <wwoods> pitti: avoid writing to disk temporarily? I'm not sure we're talking about the same patch
[05:54] <pitti> wwoods: separate crashdb> for Launchpad, right
[05:54] <wwoods> I need to figure out all of the diffs in core_pattern support between vanilla and ubuntu kernels
[05:54] <pitti> wwoods: elfcore.py sounds like you extract the pid and signal from the core file instead of getting it from the environment?
[05:54] <wwoods> pitti: right - as it comes over the pipe
[05:55] <pitti> wwoods: there aren't that many, I can point them to you
[05:56] <wwoods> now that you mention it.. yeah, when using core_pattern I end up with a crash report *and* a corefile
[05:56] <wwoods> that should probably be configurable
[05:56] <wwoods> we actually started work on a kernel coremonitor generic netlink socket
[05:56] <wwoods> so you could connect to this netlink socket and get headers + corefile when a program dumps core
[05:57] <wwoods> but.. I realized.. it's almost exactly the same as reading the core over a pipe and extracting that info from the headers
[05:57] <pitti> wwoods: ah, so you wrote code to extract pid, signal, and exename from the first few kB of the core?
[05:57] <wwoods> pitti: yep
[05:57] <pitti> wwoods: that sounds indeed cool
[05:57] <wwoods> it could be extended to get further info
[05:58] <wwoods> depending on what you want from the ELF headers
[05:58] <pitti> those three are enough, I think
[05:58] <wwoods> but those are the only ones I was interested in
[05:59] <pitti> wwoods: that still leaves the ulimit overriding
[05:59] <wwoods> http://pastebin.ca/610661 has a patch you should take
[05:59] <wwoods> the patch is obvious
[05:59] <wwoods> but.. in RPM-land it's possible to have versions that aren't identical strings but *are* equal
[06:00] <wwoods> e.g. "0:2.1-4.fc7" versus "2.1-4.fc7"
[06:00] <wwoods> hence.. gotta use compare_versions any time you're comparing versions
[06:00] <pitti> wwoods: ah, I see
[06:01] <Mithrandir> wwoods: you have that in dpkg-land too
[06:01] <pitti> wwoods: in fact that's true for .deb, too, although noone explicitly writes 0:
[06:01] <Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions 0:1 eq 1 && echo true
[06:01] <Mithrandir> true
[06:01] <wwoods> it's rare in rpmland but it happens. I was getting apport refusing to create a report because it thought I had obsolete packages
[06:01] <Mithrandir> and more surprisingly, maybe:
[06:01] <Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions 1-0 eq 1 && echo true
[06:01] <Mithrandir> true
[06:01] <wwoods> there's a bunch of perl packages that have an explicit 0:
[06:02] <wwoods> anyway.. as for the ulimit override
[06:02] <wwoods> it seems sensible that writing to a pipe should override ulimit
[06:02] <wwoods> but on the other hand, it means that we need to trust userspace process to honor it
[06:02] <pitti> right, of course
[06:02] <wwoods> I'm not sure if that's a security problem or not
[06:03] <pitti> wwoods: not a security problem
[06:03] <pitti> wwoods: but of course it creates a potential bug
[06:03] <wwoods> the kernel guys were kind of wary, but then.. that's exactly the problem we'd have with the netlink socket
[06:03] <pitti> wwoods: i. e. if the program you specify in core_pattern does not honor it, it'll clutter your disk and such
[06:03] <wwoods> indeed
[06:04] <evand> bryce: bug 124913
[06:04] <ubotu> Launchpad bug 124913 in linux-restricted-modules-2.6.22 "glxinfo segfaults with nvidia-glx-legacy" [Undecided,New]  https://launchpad.net/bugs/124913
[06:04] <pitti> if you specify random crack in core_pattern, you have more to worry about :)
[06:04] <wwoods> so yes, I'm not sure how we should pass the real rlim to the crash handler
[06:04] <wwoods> could you point me to the kernel patches you've got?
[06:04] <pitti> wwoods: so I have a lot of test cases for this, since I'm aware that it is a sensitive spot
[06:04] <wwoods> naturally
[06:04] <wwoods> oh, so how long have you been using apport in Ubuntu? is it on by default?
[06:05] <wwoods> I'm getting the feeling that devs are unhappy with it filing a bug for every crash
[06:05] <pitti> wwoods: hm, I don't see them in the history of http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=history;h=dbd5c7f140e0b48bdfc0272d065cb5246260811f;f=fs/exec.c, I'll generate it manually
[06:05] <wwoods> which makes me want to avoid doing so for Fedora
[06:05] <wwoods> ..I should make my bzr branch public somewhere
[06:05] <pitti> wwoods: we have used it for edgy, feisty, and gutsy development cycles, but disabled it in final releases (edgy and feisty)
[06:05] <wwoods> so you can see what changes I've made
[06:05] <wwoods> interesting
[06:05] <pitti> wwoods: with the recent improvements we plan to leave it on
[06:06] <Hobbsee> Mithrandir: [01:47]  <Mithrandir> Hobbsee: exhaustive list would require a lot of work, and people seem to be able to come up with too many ways to do crackful things for us to make a good list. :-P  <--true that.  i was hoping for the *most* common.  like, top 10 or so
[06:06] <wwoods> one problem we have is that bugzilla doesn't seem to have an RPC for attaching a file
[06:06] <pitti> wwoods: I recently implemented https://wiki.ubuntu.com/CrashReporting and https://wiki.ubuntu.com/ApportCrashDuplicates, that helped a lot
[06:07] <wwoods> which is why I was thinking of having a separate crashdb, which allows authorized people to link a crash to a new bugzilla/etc bug
[06:07] <pitti> wwoods: so in particular, we left apport itself on, so it continues to generate crash reports in stables; but we disabled the automatic notifications about them
[06:07] <pitti> wwoods: so that community members can still call the UI manually
[06:07] <wwoods> interesting
[06:08] <pitti> wwoods: right; right now we (ab)use private bugs for crash reports, but eventually LP will get a real crash db concept
[06:08] <wwoods> "avoid exposing potentially sensitive data to the public and avoid sending unwanted bug email to developers" is the thing that made me start work on this
[06:08] <pitti> wwoods: that's what we mitigated with CrashReporting
[06:08] <wwoods> basically each uploaded crash gets a UUID, which can be used to look up your crash report. only authorized fedora devs / QA people would be able to browse the crashdb
[06:09] <mneptok> Hobbsee: moo.
[06:09] <Hobbsee> hiya mneptok!
[06:09] <pitti> wwoods: your patch> 'avail' is not defined, the test suite fails now
[06:09] <mneptok> Hobbsee: -devel is -t?
[06:09] <wwoods> hrm?
[06:09] <Hobbsee> mneptok: yes.
[06:09] <mneptok> k
[06:09] <mneptok> sowwy
[06:09] <wwoods> avail = packaging.get_available_version(pkg)
[06:09] <pitti> wwoods: right, that's what happens now for our crashes
[06:09] <Hobbsee> mneptok: no problem
[06:09] <pitti> wwoods: ah, I recently modified the code :)
[06:09] <wwoods> maybe that patch got reformatted..? oh raths
[06:09] <wwoods> err rats
[06:09] <wwoods> heh
[06:10] <wwoods> it's only been 3 days since my last pull. slow down!
[06:10] <pitti> :)
[06:11] <wwoods> oh, here's one thing - apport-retrace is only useful for deb/apt implementations
[06:11] <wwoods> so I might just add a bin called apport-retrace-fedora and install that instead
[06:11] <wwoods> but both can be kept in the source
[06:12] <pitti> wwoods: right, apport-{retrace,chroot} are the two remaining tools which do not use the abstract packaging interface
[06:12] <wwoods> oh, so you're planning on changing them to use the abstracted interface?
[06:12] <pitti> wwoods: I'm happy to rename mine to *-apt
[06:12] <pitti> wwoods: I'm not sure, TBH; it would basically mean to move 90% of their code into the packacing interface
[06:13] <wwoods> right, I think it's OK to have separate implementations per-distro
[06:13] <pitti> wwoods: it's on my wishlist, though
[06:13] <wwoods> since, like you said, 90% of the code in there is distro-specific anyway
[06:14] <pitti> wwoods: I'm fine with having -apt and -rpm versions in the upstream trunk and mangle debian/* to install the right one
[06:14] <wwoods> sure - we already do that with packaging_impl anyway
[06:14] <pitti> wwoods: python report.py -v is happy now; committing
[06:15] <wwoods> oh, I wrote packaging_fedora.py as a subclass of a semi-abstract packaging_rpm.py, so someday we can go bother the SuSE/Mandriva folks to join us
[06:15] <wwoods> JOOOIN USSSSS
[06:17] <Hobbsee> pitti: but i'm dominating the world!
[06:17] <Hobbsee> or will be
[06:18] <pitti> hm, /me did not consider that :)
[06:19] <Hobbsee> pitti: combine forces. :P
[06:20] <kagou> hi
[06:21] <wwoods> pitti: so, every crash is still a new bug? doesn't that generate huge amounts of mail?
[06:21] <pitti> wwoods: http://people.ubuntu.com/~pitti/patches/apport-exec.c.diff
[06:22] <pitti> wwoods: email> not any more, since those are now private bugs with a 'black hole' team email address
[06:22] <wwoods> ahhh
[06:22] <wwoods> so (in bugzilla terms) it gets assigned to its own special component for crash dumps
[06:22] <pitti> wwoods: the plan is to use canned searches and automatically generated reports now
[06:23] <wwoods> and then gets moved to the right place by the retracer?
[06:23] <pitti> wwoods: i. e. sorting by number of duplicates, or packages which have the most crash reports, etc.
[06:23] <pitti> wwoods: please take a look at the wiki page, it explains our setup
[06:23] <pitti> wwoods: but please note that CrashReporting is both Ubuntu specific and also a temporary hack until we get a real crash db
[06:23] <pitti> wwoods: so every distro/bug tracker has to find its own workflow which works best
[06:24] <wwoods> right, which is why I was thinking about hacking up a proper crash db webapp-type thing
[06:24] <wwoods> so I spent this weekend wrestlin' with turbogears trying to do that
[06:24] <pitti> wwoods: not sure, maybe the google breakpad already provides that?
[06:25] <wwoods> haven't looked at the server-side breakpad stuff, but doesn't that require linking in breakpad libs?
[06:25] <pitti> I don't know
[06:25] <pitti> wwoods: recently I talked to the upstream bug-buddy Gnome guys
[06:25] <pitti> wwoods: they use the client-side stuff for generating a minidump etc.
[06:25] <pitti> wwoods: but they still use bugzilla for the crashes
[06:26] <wwoods> "Breakpad provides client libraries for each of its target platforms."
[06:26] <pitti> I haven't looked at it for a long time, it just might be worth checking out
[06:26] <wwoods> yeah, it's basically a cross-platform reporter, like talkback (or whatever firefox/mozilla used)
[06:26] <pitti> wwoods: but in any case it's easier for us to integrate it into LP than to maintain a second system, since LP already has the users, their teams and privileges, etc.
[06:27] <wwoods> we want something linux-specific that doesn't require extra libraries to be linked in
[06:27] <pitti> doesn't even need to be linux specific
[06:27] <pitti> wwoods: I recently wrote a documentation about the data format
[06:27] <pitti> wwoods: after discussing joining efforts with the Gnome guys
[06:28] <pitti> wwoods: it's in doc/, so maybe you are interested in taking a look
[06:28] <pitti> wwoods: I kept platform independence in my mind when writing this, but because I'm slightly biased :)
[06:29] <pitti> wwoods: did you get the kernel patch?
[06:29] <pitti> wwoods: it's a bit hard to tell apart the changes for the environment passing and the core limit overriding, since both use the same mechanism
[06:29] <wwoods> pitti: I did
[06:30] <wwoods> so really it's just CORE_REAL_RLIM that tells the process what's up
[06:30] <pitti> right
[06:31] <pitti> wwoods: and the if (core_pattern[0]  == '|') { .. } bit, of course
[06:31] <wwoods> I'll talk to the kernel dudes about this and see if they think it's sensible
[06:31] <pitti> wwoods: I'm not stuck with this particular patch, I'm happy to adapt apport to a different solution
[06:31] <wwoods> right - but this seems sensible.
[06:32] <pitti> it's a seb128!
[06:32] <seb128> hey pitti!
[06:32] <Hobbsee> hiya seb128
[06:32] <seb128> hey Hobbsee
[06:32] <pitti> wwoods: I'm curious about your elfcore.py (or what was it called like?), that seems to make it a bit more independent from the kernel patch
[06:33] <wwoods> pitti: hang on, I'll construct a patch
[06:33] <pitti> wwoods: do you have that in your branch?
[06:33] <wwoods> yep
[06:36] <wwoods> hrm. can bzr use webdav, I wonder?
[06:36] <pitti> hm, I'm not sure
[06:36] <pitti> wwoods: Launchpad :)
[06:38] <mvo> mdz_: I think the problem you experience is: bug #103306
[06:38] <ubotu> Launchpad bug 103306 in compiz "compiz or aiglx breaks fitt's law with scrollbars in a maximized window, or panels" [Medium,Triaged]  https://launchpad.net/bugs/103306
[06:38] <pitti> wwoods: did you add your public ssh key? bzr push to lp needs that (it won't accept the password)
[06:42] <wwoods> yeah, I've added my key but.. I'm not sure how or where I'd push my branch
[06:43] <pitti> wwoods: bzr push sftp://yourlogin@bazaar.launchpad.net/~ubuntu-core-dev/apport/fedora
[06:43] <Mithrandir> bzr push sftp://bazaar.launchpad.net/~yourusername/productname/branchname
[06:43] <pitti> wwoods: the last component is the branch name
[06:43] <wwoods> gotcha
[06:43] <Mithrandir> pitti: uh, he's not member of core dev, is he?
[06:43] <pitti> wwoods: you can also call it 'rpm-backend' or similar
[06:43] <pitti> wwoods: oh, good point, hang on
[06:43] <pitti> wwoods: s/~ubuntu-core-dev/~yourlogin/
[06:43] <pitti> Mithrandir: thanks
[06:44] <pitti> wwoods: if it's your first push, it will remember the URL, otherwise you can call it with --remember
[06:44] <wwoods> pitti: cool! it's pushing! heh
[06:44] <pitti> \o/
[06:45] <wwoods> chugga chugga. go little bzr branch go.
[06:46] <pitti> https://code.launchpad.net/apport has it now
[06:49] <wwoods> so yeah. apport/elfcore.py is the elfcore class, and there are changes in bin/apport to use it
[06:50] <dholbach> thanks nixternal
[06:50] <nixternal> no problem :)
[06:52] <wwoods> http://rdr.to/aa <-- that's the changes to bin/apport
[06:56] <pitti> wwoods: ah, just looking at it
[07:02] <aruiz> hi there
[07:02] <aruiz> could anybody tell me if its possible that a package can substite another package as a dependency?
[07:02] <aruiz> let's say package A depends on package B and I want package C to satisfy that dependency so I don't need package B?
[07:02] <jumpula> provides
[07:03] <jumpula> package c provides package b
[07:03] <aruiz> jumpula, thanks!
[07:04] <aruiz> jumpula, how flexible is it?
[07:04] <Mithrandir> you can't have versioned provides, but apart from that it, well, works.
[07:05] <aruiz> Mithrandir, I'm thinking about splited package cases
[07:05] <jumpula> for example, text editors in debian
[07:05] <jumpula> package vim provides editor
[07:05] <aruiz> Mithrandir, where half of the package is provided by one package and the other half by the other one
[07:05] <aruiz> is there any solution to that?
[07:05] <Mithrandir> aruiz: uh, what is the problem you are trying to solve?
[07:07] <aruiz> Mithrandir, I have a collection of packages, and I want to rename them, some of them might be splitted, some of them merged, but I want to keep backwards compatibility to the current naming
[07:07] <aruiz> on merging, there is no problem
[07:07] <Mithrandir> usre transitional packages, then
[07:07] <aruiz> how does that works?
[07:07] <Mithrandir> s/r//
[07:07] <Mithrandir> have an empty package with the old name that depends on the new one
[07:08] <aruiz> that's a good idea
[07:19] <mdz_> mvo: that bug needs a better title I think :-)
[07:20] <mvo> mdz: thanks :)
[07:53] <geser> keescook: can you look over bug #124725 and bug #124629 if they are ok?
[07:53] <ubotu> Launchpad bug 124725 in fireflier "[CVE-2007-2837]  Unsafe tmp file handling" [Undecided,Confirmed]  https://launchpad.net/bugs/124725
[07:53] <ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,Confirmed]  https://launchpad.net/bugs/124629
[08:47] <roger25> is usplash known not to work with lilo ?
[08:48] <mjg59> It works fine with lilo
[08:50] <roger25> well i got blank and buggy consoles (big green pixels) after having set up lilo to lunch usplash, did i missed something
[08:52] <roger25> just added append="quiet splash" and vga=791
[08:55] <roger25> sort of the reset of the console is not performed
[08:55] <mjg59> Don't pass vga=791
[09:04] <roger25> hmm ... and i get a 640x480 console then
[09:09] <mjg59> Yes
[09:09] <roger25> that's not what i call working fine
[09:12] <mjg59> Using vesafb tends to cause a variety of issues
[09:21] <roger25> damn i miss my bootsplash, i had a cute console a cute startup and a cute lilo then (and a lot of blinking screen until i get the desktop)
[09:25] <roger25> btw the timeout blank screen on console doesn't erase colored text... that's ... too bad
[10:46] <pygi> hey ho pitti
[10:46] <pitti> hi pygi
[10:47] <pygi> pitti, how is it going? :)
[10:47] <pitti> pygi: just came back from dinner, and finally got a room wifi access voucher :)
[10:48] <pygi> pitti, great ^_^
[10:48] <ajmitch> hello pitti
[10:48] <pitti> hi ajmitch
[11:10] <pygi> hey seb128
[11:10] <seb128> hi pygi
[11:10] <calc> seb128: hi
[11:11] <seb128> Hi calc