[00:01] <ajmitch> directhex: lucky you, I had to compile a kernel only 2 days ago
[00:01] <ajmitch> though it was just grabbing the ubuntu kernel, modifying 1 file to add a USB device ID, and push it through pbuilder
[00:19] <freinhard> hi!
[00:19] <freinhard> is it possible to write a debian/watch file for google code? doesn't provide directory listing
[00:19] <jpds> freinhard: It is.
[00:19] <jpds> See: pidgin-facebookchat
[00:26] <freinhard> jpds: great, works!
[00:31] <freinhard> would be nice if someone could comment (and maybe advocate) http://revu.ubuntuwire.com/p/ctemplate
[00:35] <persia> freinhard: From a quick glance, you have some unanswered lintian reports (you don't need Section: in the source stanza) you're forcing debhelper 7, but using CDBS: what feature from debhelper 7 do you require? You don't need .dirs files for directories identified to dh_install, you haven't included a symbols file to check for ABI shifts.
[00:35] <persia> There's likely more, but that's a batch to dig at for now :)
[00:36] <freinhard> persia: just reuploaded witout the unneeded second section line
[00:37] <persia> OK.  How about the rest?
[00:37] <freinhard> just removed debhelper and i'll check the .dir files
[00:38] <persia> removed debhelper?  Check the debhelper changelog: you may want something newer than the 5.0.30 that cdbs pulls.  Also, be sure to adjust debian/compat if you're supporting older debhelper.
[00:39] <persia> Also, there's a lintian bug that some people work around by adding an unversioned debhelper build-dependency.  If you end up with the complaint that there's no build-depends on debhelper, and you do have build-depends on CDBS, you can ignore it because CDBS depends on debhelper.
[00:40] <freinhard> in fact i've no idea which debhelper and compat i need. build on karmic, that's all i know. upstream requires 4.0.0 but no idea if this is still valid
[00:40] <freinhard> s/build/builds/
[00:40] <persia> upstream shouldn't require any version of debhelper: it's only used in packaging.
[00:41] <persia> Check the debhelper changelog (in reverse order).  The first time you see a feature you think you're using, set that as a minimum version of debhelper.
[00:41] <persia> If you get back to the version that CDBS requires (5.0.30 for karmic), stop, and don't bother with a versioned depends.
[00:41] <freinhard> i know, they provided some two years old debian/ folder which, except for the controls and .install files, i dumped
[00:42] <persia> Similarly, it's likely worth checking the CDBS changelog to see if you need a specific version.
[00:42] <freinhard> the only thing i can do is to require karmics current cdbs version. i know that it builds on karmic and i can't test anything else.
[00:43] <persia> Well, don't bother with a versioned build-dep on cdbs then.
[00:43] <persia> If someone tries to backport it, they may file a bug.
[00:44] <freinhard> that's what i wanted to hear :D
[00:45] <freinhard> any package where i can have a look how the debian/symbols file works?
[00:47] <persia> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is an excellent write-up (which stefanlsd really ought push into the PackagingGuide at some point)
[00:47] <persia> Dunno about sample packages.
[00:53] <freinhard> if i don't depend on debhelper anymore, can i drop the debian/compat file?
[00:56] <persia> No.
[00:56] <persia> You need to tell debhelper which version of the files you're using.
[00:57] <freinhard> ok so i just ignore the lintian warning about debhelper and keep the compat file
[00:57] <persia> But if you're using CDBS, you can drop it to compatibility level 5, unless you're depending on some special feature of debhelper that requires a newer compatibility level (and you oughtn't be if you checked the changelog and aren't adding a versioned dependency)
[00:57] <persia> Yes, that's the lintian bug I mentioned earlier, that it fails to detect when debhelper will be installed by CDBS.
[00:58] <persia> As I said before, some people work around this with an unversioned debhelper build-dependency, but I usually just leave it there, because I know lintian is wrong in this case.
[00:59] <persia> Fixing it is tricky because the real fix would involve lintian building a recursive build-depends tree based on a current apt-cache for the target listed in debian/copyright and checking that, which would be slow (and quite possibly completely wrong in cases where special targets (e.g. UNRELEASED) are being used).
[01:00] <freinhard> so this will probably never happen.
[01:00] <persia> If you're super picky, you can set up a lintian override file that explains why lintian is brain-dead in this case and overrides the warning, but since it's not critical, it doesn't really require an explanantion in an override file.
[01:00] <freinhard> no,i'm not picky at all. if it works, i'm fine with it ;)
[01:01] <persia> Well, it's a tricky problem.  Needs someone who cares enough about CDBS and lintian and hiding the warning to spend a lot of time on it.
[01:01] <persia> Most such people would rather fix other stuff in lintian or make CDBS more flexible instead.
[01:02] <freinhard> lintian complains about leading spaces in the description when i run it on one of the resulting .deb files
[01:04] <freinhard> is the description indented with one or two spaces?
[01:05] <freinhard> i guess one...
[01:06] <persia> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description describes the syntax for Description fields.
[01:06] <persia> Sometimes you want one space, sometimes two.  It depends on what you're doing.
[01:31] <SoftwareExplorer> I'm tying to make a debdiff for bug 461104. I get the messageNOTICE: 'ubiquity' packaging is maintained in the 'Bzr' version control system at:http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk Please use:bzr get http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk to retrieve the latest (possibly unreleased) updates to the package. What one should I use?
[01:32] <ScottK> SoftwareExplorer: For that package you're better off to work from bzr and ask to have your branch reviewed.
[01:32] <persia> SoftwareExplorer: ubiquity development is a bit special, because the ubiquity branch doesn't quite match the ubiquity package (because the ubiquity package includes chunks of d-i).
[01:33] <persia> SoftwareExplorer: https://wiki.ubuntu.com/Ubiquity/Contributing might be a good place to start to untangle things
[01:34] <persia> SoftwareExplorer: https://wiki.ubuntu.com/Installer/Development has more pointers.
[01:35] <SoftwareExplorer> The main reason I was going to try to do this bug is that it seems to already have a patch for the python. Is this not a good bug to try to fix for my first time?
[01:36] <persia> Probably not.  That's an odd source package and runs in a tricky-to-test environment.
[01:37] <persia> Speaking of my experience, I ran into lots of difficulties when I first tried to change ubiquity, even after several years of experience with packaging and bugfixing in Ubuntu.
[01:37] <SoftwareExplorer> Ok. Well, at least I was able to confirm the bug.
[01:37] <persia> Alternately, if you have a real interest in how the installer works, more help in that area would likely be appreciated :)
[01:38] <SoftwareExplorer> I'm just trying to start learning to package. I don't really have a specific interest yet, mostly I just want to help.
[01:40] <ScottK> SoftwareExplorer: Were glad to have you.
[01:41] <ScottK> kamalmostafa: If you're around, now's not bad.
[01:41] <persia> ScottK: By the way, did you ever get an answer to your question about plymouth and art?
[01:42] <persia> (or am I misremembering the channel in which you asked?)
[01:42] <ScottK> persia: I did not, but davmor2 said he'd file the bug.
[01:42] <ScottK> persia: I think it was -devel, but thanks for remembering.
[01:42] <persia> In another context, I was told that the filename was hardcoded in the ./configure call in the plymouth source package.
[01:42] <kamalmostafa> ScottK: just a moment
[01:42] <ScottK> OK.
[01:42] <ScottK> persia: That's "special"
[01:43] <persia> I wondered if it might make sense to have that be some well-known-location and use alternatives for the different flavours, but I'm not likely to dig into that.
[01:43] <persia> Indeed :)  It broke several flavours.
[01:43] <ScottK> It also FTBFS on ports.  Dies in configure
[01:43] <persia> no artwork?  :)
[01:43] <ScottK> The error message isn't helpful
[01:44] <ScottK> I didn't get a chance to investigate
[01:45] <persia> It's the --with-logo=/lib/plymouth... that handles the artwork there.
[01:46] <persia> ScottK: Seems the issue is: configure:11953: error: Package requirements (libdrm libdrm_intel libdrm_radeon libdrm_nouveau) were not met:
[01:46] <persia> I'm guessing that string needs adjustment for any ports DRM that support it (but I'm not at all familiar with how DRM works for ports)
[01:46] <ScottK> Ah.  No, they wouldn't be, would they.
[01:47]  * ScottK neither.
[01:47] <ScottK> Maybe tseliot knows.
[01:47] <persia> Maybe we should have been having this discussion in -devel :)
[01:47] <persia> (but tseliot isn't there either)
[01:48] <ScottK> kamalmostafa: What have you got?
[01:50] <kamalmostafa> ScottK: ok, first off, I'm not at all sure that I actually did what you asked for, but here goes...
[01:50] <ScottK> kamalmostafa: That's fine.  Learning is a big part of the point of this.
[01:50] <kamalmostafa> Lets start with libtifiles:  https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge
[01:50] <ScottK> ok
[01:51] <kamalmostafa>   - Merged libtifiles2 --> libtifiles
[01:51] <kamalmostafa>   - I did not re-autoconf (ran into problems) so kept ubuntu versions' conf (autoconf-1.10.1)
[01:51] <kamalmostafa>   - Significant changes to debian/copyright files.  Is it okay?
[01:51] <kamalmostafa>   - I may have missed some instances of "2-removal" (po stuff? doc stuff?)
[01:52] <kamalmostafa> First question:  Is the debian/changelog version number correct?
[01:53] <kamalmostafa> I bumped up the "libtifiles2" version number by one "ubuntuN" unit to construct 1.1.2-0ubuntu2 but it looks weird as the next revision above libtifiles (1.1.1-1).   ..
[01:56] <ScottK> Bumping the version number was right.
[01:56] <ScottK> As first glance it looks pretty good.
[01:57] <ScottK> I don't think there's a way to do the changelog that wouldn't end up looking a bit odd.
[01:57] <kamalmostafa> Yeah, I fought it out with the version numbering for quite awhile -- this was the only way to convince Lucid to use *this* libtifiles instead of the one that appears newer from libtifiles2.
[01:57] <ScottK> kamalmostafa: It does look like there are some things you can do to minimize the diff from debian.
[01:58] <ScottK> kamalmostafa: Exactly.
[01:58] <ScottK> As an example, you have ordered the build-depends differently.
[01:58] <ScottK> That's a pointless diff and you should change to follow Debian.
[01:58] <ScottK> OTOH, the more precise debhelper version requirement in the Ubuntu package is good to retain
[01:59] <ScottK> You should make standards version and home page the same as Debian
[01:59] <kamalmostafa> But here's the thing... All those settings are what I lifted from "libtifiles2".
[02:00] <kamalmostafa> I mean to say -- that's the debian/control from "libtifiles2", except modified for the new name "libtifiles".
[02:01] <ScottK> Yes.
[02:01] <ScottK> So I think there's a little more work to do to make our diff from Debian only the meaningful ones
[02:01] <ScottK> For example I'd also use the Debian descriptions unless you think the Ubuntu ones are enough better to be worth sending a patch to Debian.
[02:02] <ScottK> It looks like debian/rules could be better aligned similarly.
[02:02] <ScottK> kamalmostafa: This is a very good start.
[02:02] <kamalmostafa> Okay that seems like a reasonable endeavor for e.g. debian/control, but what about the generated files in the root directory -- those are sure going to differ greatly from Debian.  Is that going to be a problem?
[02:03] <ScottK> I just looked in the debian dir so far.
[02:04] <ScottK> For that we'll keep one or the other, I don't know yet which.
[02:04] <kamalmostafa> :-)  Oh, you don't want to look up at Makefile.in  ;-)
[02:04] <ScottK> I'm banking on keeping "the one that works".
[02:05] <ScottK> Those should disappear on the next upstream release.
[02:05] <kamalmostafa> Well, as it stands, I think it actually "works" -- the two packages together do build in PPA and install on my Karmic machine.   But yes, I'll make another pass over the debian/* files to reduce the diff.   I'm for leaving the generated stuff alone though.
[02:06] <ScottK> OK.  Let's see.  You're off to a good start.
[02:07] <kamalmostafa> ScottK: you still looking at tifiles? or ready to move on to a ticalcs?
[02:11] <ScottK> kamalmostafa: I suspect if I did, I'd just tell you the same thing.  Want to take another pass at them both first?
[02:12] <kamalmostafa> Sure that's just fine, one side note:  What about libticables2?  (libticalcs-dev depends on libticables2-dev).   Is it going to need the same "2-removal" treatment?
[02:12] <ScottK> Yes.
[02:13] <ScottK> We'll want to switch to the Debian package names and if there are any reverse-build-depends they'll have to be changed
[02:13] <ScottK> Looks like tilp2 is affected as well.
[02:14] <kamalmostafa> What a mess.  Well, since those ones aren't breaking (yet), how about we just deal with tifiles & ticalcs as "stage 1", and then deal with the rest as "stage 2".  Will that work?
[02:18] <ScottK> Yes.
[02:19] <ScottK> libticables2-dev will be NBS (Not Built from Source) once we upload the new libticables, but won't actually be removed until it had no reverse-build-depends
[02:19] <ScottK> (or depends)
[02:19] <kamalmostafa> Okay, good plan.  Thanks for the review Scott -- I'm off to dinner, then will make another pass at these two.  Will let you know when ready for the next review.  All good?
[02:23] <ScottK> Ye[
[02:23] <ScottK> Yep
[03:20] <dhillon-v10> hi all, I am working on this merge and bzr says that there are conflicts in control and changelog, I understand the changelog part but my question is shouldn't there be conflicts in more than that or is that okay
[03:21] <crimsun> dhillon-v10: generally that means the merge is clean
[03:22] <dhillon-v10> crimsun, this is a merge from main so I was hoping something super complicated that I can't do but it seems plausible :)
[03:24] <RAOF2> There will only be conflicts where the both Ubuntu and Debian have made changes in the same place; unless we're both fixing the same bug independently, that should be fairly rare.
[03:24] <dhillon-v10> RAOF, crimsun thanks :)
[03:25] <dhillon-v10> RAOF2, oh btw what does >> mean in version numbers, is it greater than
[03:27] <RAOF2> Yup, greater than.
[03:27] <RAOF2> Strictly greater than, in fact.
[03:28] <dhillon-v10> RAOF2, thanks again
[04:26] <micahg> does debcommit automatically use --fixes lp:xxxxxx?
[04:28] <crimsun> yes
[04:28] <micahg> yay!
[04:29] <micahg> indeed
[04:30] <crimsun> example: http://pastebin.com/d66dc32c3
[04:30] <crimsun> O:-)
[04:35] <dhillon-v10> crimsun, I did the merge here: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 does it look right
[04:40] <JontheEchidna> jdong: ping on an SRU
[04:41] <JontheEchidna> wondering if I can get approval for bug 350902
[04:42] <jdong> sure, gimme 5 minutes
[04:42] <JontheEchidna> Thanks
[04:47] <slytherin> Why do we have a 'unapproved' queue for -proposed uploads. We never upload packages to -proposed without a SRU approval? So what is point of another approval?
[04:47] <micahg> slytherin: according to the wiki process, upload is supposed to occur before approval
[04:48] <slytherin> micahg: AFAIK, approval form SRU team is required before upload.
[04:49] <jdong> well...
[04:50] <micahg> both https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and https://wiki.ubuntu.com/ArchiveAdministration#Stable%20release%20updates seem to imply you don't
[04:50] <jdong> in the old days, ubuntu-sru tended to be a subset of ubuntu-archive
[04:50] <jdong> and archive admins found it much more natural to use queuediff to process SRU's as they're clearing the upload queues
[04:50] <jdong> hence upload and reference LP #, wait for approval
[04:50] <jdong> but MOTU-SRU (at first didn't have, later didn't know of) the tools, and preferred using LP team subscriptions
[04:51] <jdong> hence for MOTU, it tended to be ACK before upload
[04:51] <jdong> now, I guess upload-and-wait is the correct procedure? :)
[04:51] <micahg> well, if it's different the docs should be updated...
[04:52] <jdong> well I think for now, the right thing to do is to update the docs and slap the people who don't follow it
[04:52] <jdong> (innocently looks away)
[04:52] <micahg> jdong: approval first?
[04:52] <jdong> upload first
[04:53] <micahg> jdong: that's what it says :)
[04:53] <slytherin> jdong: And what happens when when Martin Pitt gives approval, package is uploaded and is waiting in queue? Whom do I need to bug about it.
[04:53] <jdong> slytherin: archive admins, in that case
[04:53] <ScottK> slytherin: What package?
[04:54] <jdong> wow, what a big debdiff :)
[04:54] <slytherin> ScottK: evolution-mapi.
[04:54] <ScottK> slytherin: What bug?
[04:54] <jdong> oh that's not a debdiff
[04:54]  * jdong obviously needs caffeine
[04:54] <slytherin> ScottK: bug 472552
[04:54] <JontheEchidna> jdong: would you prefer a debdiff?
[04:54] <ScottK> I can accept it if pitti approved it.
[04:54] <ScottK> Looking
[04:54] <jdong> JontheEchidna: haha no no, it's fine, I got it now :)
[04:55] <JontheEchidna> :)
[04:55] <jdong> silly midnight blind clicking
[04:55] <JontheEchidna> I was a bit unclear on the process too. Generally pitti just uploads and accepts at the same time :P
[04:56] <jdong> JontheEchidna: haha yeah, since the unification of the teams I guess there's been a bit of a shakeup :)
[04:56] <jdong> the dust will settle soon
[04:56] <jdong> JontheEchidna: ok you've got an ACK, carry on!
[04:57] <JontheEchidna> jdong: thanks
[04:57] <ScottK> slytherin: Done.
[04:57] <slytherin> ScottK: thanks. Do I need to add that response in bugs 'please test package from -proposed'?
[04:58] <ScottK> slytherin: No.  Did that as part of the process.
[04:58] <slytherin> great
[04:59] <slytherin> ScottK: I am wondering if I should request for standing exception for evolution-mapi.
[04:59] <ScottK> No opinion.  I'm not on the SRU team.
[05:00] <ScottK> You'd have to ask the tech board for the exception.
[05:00] <slytherin> I meant for micro releases actually
[05:00] <slytherin> Ok. I will mail them.
[05:00] <jdong> is there a standing-exception... yeah what ScottK said :)
[06:09] <slytherin> ScottK: You forgot to add comments on other bugs fixed in evolution-mapi upload. Should I do that?
[06:09] <ScottK> slytherin: Add a comment that test results should go in the bug I marked.
[06:10] <slytherin> Ok
[06:10] <slytherin> Or I could add comment and set the bugs is verification-needed.
[06:10] <slytherin> s/is/as/
[07:01] <jariq> Could someone please review new package ipwatchd ? http://revu.ubuntuwire.com/p/ipwatchd
[07:03] <persia> jariq: Regarding point 4 of my previous feedback: why do changes in debian/rules need to wait for an upstream release?
[07:04] <jariq> persia: hm.. i thought you were talking about "rm -f" in Makefile in upstream package
[07:04] <persia> Well, it's a good idea to fix that too :), but your debian/rules is also a makefile.
[07:05] <persia> Mind you, without all the other stuff, it becomes minor enough not to warrant another upload, I just wondered.
[07:05] <persia> My personal preference is to have the logs show if anything unexpected happens, just so that when something does fail, I can figure it out.
[07:05] <persia> On the other hand, the way you're doing it might save kilobytes of storage space over the package lifetime.
[07:06] <persia> (and it's exceedingly unlikely that failure to remove some stamp files would interrupt a build)
[07:06] <persia> Bah, your package is in good enough shape that it needs a real review.
[07:07] <persia> I'll hit it if I get time while I'm doing reviews tonight, but there's nothing I can tell you in a couple minutes that would improve it.
[07:08] <jariq> persia: ok thanx a lot.. I'll take a look at that 'rm -f ' stuff meanwhile
[07:08] <persia> Really, it's so minor it's not worth updating the package to make the change.
[07:08] <persia> It's just a stylistic thing.
[07:09] <persia> Probably more important if the target was an interesting file that might not be there or might have been created at the wrong time.
[07:09] <persia> But for stamp files, it doesn't matter at all.
[07:10] <jariq> ok
[07:11] <fabrice_sp> anyone has an idea why I'm getting this error: Function `gtk_tree_view_column_get_cell_renderers' implicitly converted to pointer at ignoregui.c:192
[07:11]  * persia idly wonders if a dh(1) package using rules.tiny could just ship debian/rules as a symlink to /usr/bin/dh
[07:11] <persia> fabrice_sp: In what context?
[07:11] <fabrice_sp> line is GList *list = gtk_tree_view_column_get_cell_renderers (col);
[07:12] <fabrice_sp> and function is declared as GList *             gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column);
[07:12] <fabrice_sp> (my upload of xchat is FTBFS in amd64)
[07:12] <persia> OK.  What's the type of the col variable at the time of the function call?
[07:13] <fabrice_sp> GtkTreeViewColumn *col;
[07:13]  * persia has no idea given that code
[07:13] <fabrice_sp> the same for me :-/
[07:14] <fabrice_sp> it's not a FTBFS as is, because the build is fine, but some sort of check is run on code after the building
[07:14]  * fabrice_sp never saw that before
[07:14] <persia> So it's a make tests failure?
[07:15] <fabrice_sp> it seems to be an "automated build log filter"
[07:15] <fabrice_sp> http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz
[07:15] <persia> Check the rules file.  Some rules files will run a test suite.  It may be that someone patched something and forgot to update the test suite.
[07:16] <fabrice_sp> hmm, actually, the message gives some links
[07:16]  * fabrice_sp should have looked at that before :-/
[07:17] <fabrice_sp> point to http://wiki.debian.org/ImplicitPointerConversions
[07:17] <persia> Also, look at line 1732 of the build log.
[07:17] <persia> The error is reported there, it's just not enough to kill the make.
[07:18] <fabrice_sp> ok
[07:18] <persia> It looks like some header is missing, because the compilation claims "ignoregui.c:192: warning: implicit declaration of function 'gtk_tree_view_column_get_cell_renderers'"
[07:18] <persia> So it may never be seeing " GList *             gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column);" for some reason.
[07:19] <persia> Maybe a scoping error also.
[07:19] <fabrice_sp> make sense. I'll have a look later. Thanks!
[07:19] <persia> Good luck.
[07:20] <fabrice_sp> thanks ;-)
[07:20] <persia> Note that this really only affects ia64, but it's worth checking for everything :)
[07:20] <persia> (because amd64 will *try* to use 32-bit-safe pointers, if it can)
[07:20] <fabrice_sp> I know: the problem is that it really blocks amd64 also :-/
[07:21] <fabrice_sp> FTBFS
[07:21] <persia> Doesn't it block all architectures on the buildds?
[07:21] <fabrice_sp> no: only ia64 and amd64
[07:21] <persia> If not, it's worth asking a buildd admin why not
[07:21] <persia> That seems silly to me, but OK.
[07:21] <fabrice_sp> have to go.  Could someone please review qt-shutdown-p (I'm waiting since days)? http://revu.ubuntuwire.com/p/qt-shutdown-p
[10:14] <bdrung_> dholbach: please unsubscribe u-u-s (and subscribe yourself) when sponsoring a merge
[10:14] <dholbach> bdrung_: why?
[10:15] <dholbach> bdrung_: once the bug is closed it shouldn't matter any more who's subscribed, or does it?
[10:17] <bdrung_> dholbach: when searching lp directly or when someone writes a comment
[10:19] <dholbach> hum, generally the bug (that's been closed after upload) shouldn't turn up in bug lists any more... only if you search for all bugs ever
[10:20] <bdrung_> dholbach: yes, but sometimes i search for all
[10:21] <dholbach> what is your use-case?
[10:21] <dholbach> I never bothered to do it and am not sure who else does :)
[10:22] <dholbach> but yeah I could do it if it's really necessary
[10:22] <dholbach> anybody else who has an opinion?
[10:30] <persia> dholbach: The sponsoring procedure documents unsubscribing, and lots of people do it.
[10:30] <dholbach> I see
[10:30] <dholbach> maybe I'm the only lazy guy then ;-)
[10:30] <persia> I wrote that bit, to cover two cases 1) often bugs will have other tasks not currently needing sponsorship, which clogs the LP view
[10:31] <persia> and 2) sometimes bugs need later attention because something went wrong, so it's good for the original sponsor to be paying attention, but nobody else needs to care (unless there's an issue, in which case the submitter might again subscribe the queue)
[10:32] <persia> dholbach: You're not the only lazy guy, just one of them :)
[10:33] <hakaishi> Could someone please review qt-shutdown-p?  ';.;'  *pleeeease*  http://revu.ubuntuwire.com/p/qt-shutdown-p
[10:34] <persia> hakaishi: Some reviewers have an informal policy that any package that gets reviews requested with less than 24 hours passing between requests get ignored.
[10:34] <persia> Not that your package doesn't deserve review, but just a warning that asking too much may have the opposite effect.
[10:35] <hakaishi> hmm... the last view days I asked just two times a day... I think this isn't too much to bear
[10:36] <hakaishi> but, thanks
[10:36] <persia> You may be right.  Depends on the reviewer.  I don't believe we have an active REVU coordinator this cycle, so I'm not sure there's any firm policy.
[10:38] <hakaishi> okay, then I'll just try to ask every 24 hours and 5 minutes ^^'
[10:38] <persia> That's what I used to advise people when I was REVU Coordinator.
[10:39] <persia> Well, actually, I used to advise about every 30 hours, to have the best chance of catching different people at different times of day.
[10:40] <hakaishi> okay, thank you! See you then ^^' (you seem to be online almost all the time)
[10:41] <persia> I'm almost always online, but sometimes I have significant lag (rarely more than 100Ksec)
[11:42] <freinhard> 0hi!
[11:44] <freinhard> fixed all lintian warnings on http://revu.ubuntuwire.com/p/ctemplate and the last thing remaining is, what is that .symbols file for and where do i get usefull documentation or a package using it?
[11:54] <slytherin> freinhard: http://wiki.debian.org/UsingSymbolsFiles
[11:58] <freinhard> slytherin: no example there
[11:59] <slytherin> freinhard: for example you can check gtk+2.0 package
[12:03] <freinhard> slytherin: ok, undestood what that file does and what it is for.
[12:03] <freinhard> slytherin: these files aren't manually created, are they?
[12:03] <slytherin> freinhard: I haven't used it so don't know the details.
[12:04] <persia> freinhard: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is fairly good documentation.
[12:05] <persia> I tend to create the file at packaging time (using tools), so that the package FTBFS if the symbols don't match.
[12:05] <freinhard> persia: not the shortest docs for a single file i've ever seen ;)
[12:05] <persia> Well, no, but that's not a bad thing.
[12:05] <persia> Consider all the documentation that exists on how to deal with debian/rules, when one can just use /usr/share/doc/examples/rules.tiny
[12:10] <slytherin> persia: is that path correct?
[12:11] <freinhard> slytherin: no it isn't, there's a debhelper missing
[12:11] <slytherin> :-)
[12:11] <persia> Good catch, both of you :)
[12:12] <freinhard> ok, from the docs i see that exporting a single environment variable should trigger dpkg-gensymbols and i can gather the output for the symbols file after building the dsc with pbuilder?
[12:18] <persia> freinhard: I've added some comments to ctemplate
[12:19] <persia> freinhard: Right.  Once done, copy that file back into your source package, so it will compare the generated results against the defined results at build-time.
[12:19] <persia> When upstream introduces new symbols without breaking ABI, add the right version hints.
[12:19] <persia> When upstream breaks the ABI, create a new symbols file.
[12:23] <freinhard> hmm didn't work with cdbs, looks like this gets called for debug packages only
[12:40] <freinhard> persia: if the environment variable is set, dh_makeshlibs should have called dpkg-gensymbols?
[12:44] <persia> freinhard: I don't remember having set an environment variable, but perhaps.  You might also try `touch debian/libctemplates.symbols` to generate a broken one and get the conflict output.
[12:45] <freinhard> just tried that, still running
[13:01] <freinhard> persia: where did you find a .la file?
[13:02] <freinhard> persia: just checked the .deb file with gdebi and couldn't see one.
[13:03] <persia> freinhard: I saw it listed in your .install file.
[13:03] <persia> http://revu.ubuntuwire.com/revu1-incoming/ctemplate-1001150403/ctemplate-0.96/debian/libctemplate-dev.install
[13:04] <persia> So if you're not seeing it in the package, then something else is wrong.  If you are seeing it in the package, you should change it so you don't (referenced to the squeeze release goal)
[14:29] <bddebian> Heya gang
[14:30] <persia> bddebian: !!!
[14:31] <slytherin> Need help with oython. I am trying to install reviewboard which defines dependency on paramiko. I have already installed package form repository but reviewboard installer is not detecting it.
[14:32] <bddebian> Heya persia!
[14:34] <sebner> huhu bddebian :)
[14:35] <bddebian> Heya sebner
[14:37] <iulian> Hey.
[14:38]  * sebner waves at iulian too
[14:46] <^arky^> hi, who's the right person to answer a question on upstart event handling
[14:47] <persia> ^arky^: I'm not sure there's any right person.
[14:48] <persia> But it also depends on context.  If you're looking to put an upstart job in a package, we might be able to help.  If you're writing an upstart job from scratch, you might want to talk to the upstart team.
[14:48] <^arky^> Then I will ask the question anyway, https://answers.edge.launchpad.net/upstart/+question/97511
[14:48] <^arky^> need to write upstart job for gnome-orca package, upstart team looks like a good bet
[14:50] <persia> Yeah, for that sort of thing, you probably need upstream support.
[14:59] <^arky^> Yeah, I have bug 507953 created for this, how do I bring it to the notice of upstart team
[15:00] <^arky^> think I'll subscribe upstart developers team and keep my fingers crossed
[15:00] <persia> Um, surely there's a better way.
[15:01] <persia> ^arky^: Try asking in #upstart (based on http://upstart.ubuntu.com/development.html)
[15:07] <^arky^> persia: I already did
[15:07] <^arky^> no response
[15:08] <persia> Have you tried the mailing list?
[15:26] <freinhard> persia: do i need to pass some magic commandline option to dh_makeshlibs to get the symbols output?
[15:26] <persia> freinhard: I'm afraid I don't remember offhand
[15:27] <persia> You can always run it manually if you do a local binary build (debuild -b) in a chroot (schroot -c or pbuilder --login)
[16:52] <freinhard> what's the benefit of having /usr/lib/libfoo.so in the -dev package?
[16:52] <geser> you can link against -lfoo
[16:53] <freinhard> ok, my question should have been: why put libfoo.so in the -dev and not in the main package?
[16:54] <geser> because you only need it during building other packages (or software in general)
[16:55] <freinhard> thank you for clearing that up!
[16:56] <sebner> huhu geser :D
[16:56] <freinhard> still trying to figure out how to get that symbols file
[16:56] <geser> Hi sebner
[16:56] <freinhard> tried debian/(dev-packagename|package-name|parent-directory-name).symbols
[16:57] <freinhard> none of them cause dh_makeshlibs to call dpkg-gensymbols
[16:58] <freinhard> what does "if (-e" in perl check? exists?
[16:59] <geser> have you also tried debian/libfoo1.symbols (or how exactly your library package is named)
[17:00] <freinhard> yes, do they need to contain something? just put a empty file there
[17:00] <geser> don't know, haven't need to use this yet
[17:04] <freinhard> if a package contains a optional .vim syntax file that's usually goes to /usr/share/docs, should i install it to /usr/share/vim/vimcurrent/syntax/ ?
[17:06] <freinhard> hmmi guess not, would imply having vim installed...
[17:12] <freinhard> persia: about the copyright file: copied that from upstream svn, so i guess this should be fine?
[17:39] <randomaction> What is the correct procedure for sponsored SRUs? Suppose we have a good debdiff and bug description. What happens next? ubuntu-sru ack or upload to -proposed?
[17:51] <freinhard> http://revu.ubuntuwire.com/p/ctemplate could need some more review :)
[17:57] <ScottK> randomaction: It's a bit confused, but I think the consensus is upload.
[17:59] <randomaction> Also, what does opening a task for a stable release imply? It means you think that the problem is worth a SRU, right?
[18:01] <ScottK> yes.
[18:02] <randomaction> thank you
[18:02] <ScottK> Although sometimes I'll open one against all affected releases and wontfix the ones I think we shouldn't do for clarity
[18:12] <freinhard> anyone willing to sponsor my (almost ;) ) perfect ctemplates package? http://revu.ubuntuwire.com/p/ctemplate
[18:31] <fabrice_sp> anyone knowing how to fix xchat in amd64? The log is there http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz
[18:33] <fabrice_sp> The line that fails is this one: GList *list = gtk_tree_view_column_get_cell_renderers (col); and I tried to include <gtk/gtktreeviewcolumn.h>
[18:35] <fabrice_sp> bbl
[18:37] <kamalmostafa> ScottK: Hi Scott.  I've re-done the libtifiles2 merge -- this time keeping the older Debian autoconf products and most of the debian/ file contents.  After folding in the one actual code change that Ubuntu picked up from the maintainer, the merge diff is really only a dozen lines or so:  https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge
[18:38] <kamalmostafa> fabrice_sp:  I see that in that header file, the prototype you need is wrapped by #ifndef GTK_DISABLE_DEPRECATED  -- is that the problem perhaps?
[18:41] <ScottK> kamalmostafa: Great.  I'm busy with $WORK right now.  I'll try and look at it tonight.
[18:41] <kamalmostafa> ScottK:  That's fine.
[18:49] <fabrice_sp> kamalmostafa, will have a look. Thnaks for the idea! :-)
[18:50] <kamalmostafa> fabrice_sp: glad to help!
[19:58] <kamalmostafa> Problem: After updating a .gmo file, my   bzr builddeb -S   fails:  dpkg-source: error: cannot represent change to .../po/fr.gmo: binary file contents changed
[19:58] <kamalmostafa> Advice?
[20:08] <fabrice_sp> kamalmostafa, update the source (.po file?), and modify the debian/rules to generate it again, if it's not the case
[20:13] <kamalmostafa> fabrice_sp:  I'm not at all familiar with the po/ methodology.  There is a fr.po file (and a fr.gmo) already checked into this bzr tree.  I'm trying to replace them with the fr.po and fr.gmo from a later version of the same package.   So I don't think the .gmo needs to be generated again -- just needs to be rolled into this change.   I can "bzr commit" it no problem -- just can't build a test source package with "bzr builddeb -
[20:14] <fabrice_sp> AFAIK, you can't commit a binary change
[20:15] <kamalmostafa> bzr commit accepts it with no argument.  :-)
[20:16] <kamalmostafa> Is it abnormal that a .gmo file would be checked in at all then?
[20:17] <maxb> kamalmostafa: Yes, quite abnormal
[20:17] <maxb> Unless it's by way of it being shipped in an upstream tarball, and thus imported.
[20:17] <fabrice_sp> sorry: building classpath is killing my computer :-/
[20:18] <maxb> In which case, what needs to happen is that the .gmo is unchanged whilst building the debian source package
[20:18]  * fabrice_sp was going to say the same thing :-)
[20:19] <kamalmostafa> maxb: okay, I think that does fit this situation -- both the "original" and my "target" packages were imported from upstream.
[20:20] <fabrice_sp> generally, in that cases, I modify the clean target to delete the generated binary files, and build them
[20:20] <fabrice_sp> even if the binary file comes from upstream
[20:21] <kamalmostafa> So now when exactly will the new .gmo be regenerated?  (just part of 'make'?)
[20:21] <maxb> kamalmostafa: OK. Make sure that _you_ don't commit any changes to those binary files - they should be left identical to those coming from the upstream import.
[20:21] <maxb> Well, that's dependent on the specific package's buildsystem, but hopefully yes
[20:23] <kamalmostafa> Got it (and I'll test it to make sure that happens).   So let me get it straight...  Its fine to change the .po, but leave the .gmo alone when building the source package;  the .gmo should get regenerated as part of the build anyway.  Yes?
[20:23] <maxb> Correct
[20:23] <kamalmostafa> maxb and fabrice_sp: Thanks very much!
[20:46] <qnix> hi, is there a page about the Prevu tool ? Who said exactly it does in its automated backporting ?
[21:01] <sistpoty> hi folks
[21:01] <sebner> huhu sistpoty :D
[21:01] <sistpoty> hi sebner
[21:01] <freinhard> hi
[21:01] <sistpoty> hi freinhard
[21:02] <maxb> qnix: prevu is mainly just a wrapper around pbuilder. If you want to use it for anything complex, I recommend learning about pbuilder directly.
[21:02] <freinhard> looks like people with sparetime! go for it: http://revu.ubuntuwire.com/p/ctemplate :D
[21:02] <maxb> qnix: See also cowbuilder / cowdancer, which will save you so much time if you do lots of things with pbuilder
[21:02] <qnix> ah, I already use cowbuilder.
[21:03] <maxb> Then you don't really care much about prevu
[21:03] <qnix> I thought prevu was something that fixes incompatibilities between different version of debhelper etc..
[21:03] <qnix> Ok
[21:03] <freinhard> selling stuff here is really really hard ;)
[21:03] <maxb> qnix: Well, I admit I only looked at it last a couple of distributions ago, but it didn't do anything of that sort back then
[21:04] <qnix> maxb: all right
[21:07] <sistpoty> freinhard: I'm already looking at it, just not telling you :P
[21:08] <freinhard> sistpoty: yay :D
[21:26] <sistpoty> freinhard: commented on it, some tiny tidbits, but nothing really serious. Nice package!
[21:30] <sistpoty> nixternal: from the try right now to fix gdcm it looks like I don't need ppc access after all... it ftbfs on amd64 now with the same reason (which I had slightly suspected)
[21:30] <sistpoty> nixternal: so feel free to disable/remove my account
[21:31] <freinhard> sistpoty: i was told that there should be a .symbols file for lib packages, but nobody seems to be able to tell me how to do it right.
[21:32] <siretart> please don't add .symbol files if you don't understand them. a broken symbol file can be very annoying...
[21:32] <nixternal> sistpoty: I will leave it, just in case you ever need it again :)
[21:32] <siretart> hi folks, btw!
[21:32] <nixternal> howdy sistpoty
[21:32] <sistpoty> hi siretart and nixternal
[21:32] <sistpoty> nixternal: ok :)
[21:33] <freinhard> siretart: i undestood what it's good for but i didn't even get that far to produce any content for the .symbols file
[21:33] <freinhard> sistpoty: thx for commenting
[21:34] <siretart> freinhard: you can use dpkg-gensymbols for creating a first version
[21:34] <sistpoty> freinhard: man dpkg-gensymbols might give some hints... however (and that's how I make it) unless libctemplate has many reverse dependencies, a symbol file is not too much needed in the first place
[21:35] <freinhard> sistpoty, siretart: i thaught dh_makeshlibs calls dpkg-gensymbols if there is a libctemplate0.symbols file in the debian folder, but that didn't happen, or there was no output on commandline
[21:36] <siretart> freinhard: it calls dpkg-gensymbols to check against the referencs .symbols file. you still have to generate and maintain the reference file
[22:09] <sistpoty> ... grumble... gdcm... grumble... it looks like it should work but doesn't :(
[22:12] <sistpoty> meh, I'm stupid, I really should read the context, now it's suddenly all clear
[22:26]  * Laney spanks RainCT
[22:26] <Laney> you broke pbuilder-dist in 560
[22:26] <RainCT> Laney: wha?
[22:26] <Laney> /usr/bin/pbuilder
[22:26] <Laney> should be sbin!
[22:27]  * Laney fixes
[22:27] <RainCT> uhm yeah sorry
[22:27] <sebner> lol
[22:27] <sebner> hi Laney
[22:27] <RainCT> I wanted to get ride of the hardcoded path entirely but apparently forgot to do so :P
[22:28] <Laney> hiya sebner
[22:41] <sebner> Laney: side note: Eagerness rather than immaturity. I care for my stuff and tend to give 110% for it. Might seem odd for some though. Call it immaturity if you think (evil hard) life will change me
[22:41] <sistpoty> sebner: huh?
[22:48] <Laney> I was trying to defend you
[22:55] <sistpoty> ScottK: I think I've got a fix for gdcm now, which should make it build on ppc (not tested, it ftbfs'd as I thought in the same way on amd64 now). problem is that it's a hack to fix debian 562775 and I'm not 100% sure if it will also cure rdepends
[22:55] <sistpoty> (due to lack of knowledge about both cmake and java)


[01:25] <hads> Let me help you with that...
[19:42] <ibeardslee> morning
[20:15] <ajmitch> morning
[20:44] <chilts> morning
[20:48] <Atamira> morning


[01:56] <pursuivant> muon (master) v5.4.1-41-gbd88d35 * Aleix Pol: libmuon/backends/DummyBackend/tests (2 files)
[01:56] <pursuivant> Include initial test for the UpdateModel
[01:56] <pursuivant> http://commits.kde.org/muon/bd88d35071e4057a6b63da88535e9283c7f8686a
[05:56] <sitter>   Uploading kwallet-kf5_5.15.0-0ubuntu2_source.changes: done.
[05:56] <sitter> Successfully uploaded packages.
[05:56] <sitter> solves https://bugs.kde.org/show_bug.cgi?id=351805
[05:56] <sitter> Riddell: ^
[05:56] <sitter> poor merger
[05:57] <sitter> how does that happen Oo
[05:57]  * sitter blinks
[06:54] <sitter> libphonon4qt5-dev: multimedia framework from KF5 - development files
[06:54] <sitter> vivid had one broken description
[07:46] <lordievader> Good morning
[07:54] <vip> moin
[08:18] <ovidiu-florin> sitter: ping
[08:22] <sick_rimmit> Hola
[08:23] <sitter> ovidiu-florin: pong
[08:23] <sick_rimmit> How are the developers today... Ooo release day tomorrow
[08:23] <sick_rimmit> very exciting
[08:23] <yofel> already?
[08:23] <ovidiu-florin> sitter: can you please help me understand the difference between the stable and unstable CI ppas?
[08:23] <yofel> time flies :O
[08:24] <sitter> ovidiu-florin: on integrates upstream stable branches and the other upstream masters
[08:24] <ovidiu-florin> and stable means the latest release?
[08:25] <sitter> no
[08:25] <sitter> it means upstream stable branch
[08:25] <sitter> so ... "next release" as it were
[08:26] <ovidiu-florin> so there is no ppa in the ci for the latest release/
[08:26] <ovidiu-florin> ?
[08:26] <ovidiu-florin> whait
[08:26] <ovidiu-florin> thatis not ci then
[08:27] <ovidiu-florin> I still don't get it: what's in the stable branch?
[08:28] <ovidiu-florin> sitter: ^
[08:28] <sitter> the upstream stable branch
[08:30] <ovidiu-florin> sitter: what's on it
[08:30] <ovidiu-florin> ?
[08:30] <sitter> that depends on the repository?
[08:31] <sitter> in kde-i18n you also got a stable and a trunk, same difference. one is the stable branch the other is the unstable branch
[10:47] <mparillo> Riddell: I tested WiFi on today's Wily Release Canddidate on two different laptops. It connected both times using the live ('try') option.
[10:56] <mparillo> New images: http://iso.qa.ubuntu.com/qatracker/milestones/347/builds
[10:56] <mparillo> !Testers
[10:56] <mparillo> ^^^^
[10:58] <pursuivant> muon (Plasma/5.4) v5.4.2-4-g46df03e * Harald Sitter:  (5 files in 5 dirs)
[10:58] <pursuivant> fix kuit markup calls
[10:58] <pursuivant> when using markup tags one must use xi18n* or the markup will not be
[10:58] <pursuivant> interpreted. while we fixed this for most of the code a while ago there
[10:58] <pursuivant> still were broken uses around.
[10:58] <pursuivant> http://commits.kde.org/muon/46df03e247fede140d95098f78af300eb3acb3d5
[10:59] <pursuivant> muon (master) v5.4.2-42-gd9fbd88 * Harald Sitter:  (2 files in 2 dirs)
[10:59] <pursuivant> Merge branch 'Plasma/5.4'
[10:59] <pursuivant> # Conflicts:
[10:59] <pursuivant> #CMakeLists.txt
[10:59] <pursuivant> http://commits.kde.org/muon/d9fbd88e90adfdddbac452a76c2d824779694011
[11:34] <mparillo> On today's images, do the icons on the Application Launcher look more like Oxygen than Breeze Icons?
[11:35] <sitter> that'd be a bug
[11:35] <sitter> logout and back in and they should be breeze again
[11:35]  * sitter thought 5.15 fixed that
[11:54] <mparillo> sitter: Going to shut down now. Interesting that the favorites tab looked like oxygen but the shut down tab looked breeze.
[11:55] <sitter> it's a caching bug
[11:55] <sitter> not entirely sure why or how but its a caching bug
[12:07] <mparillo> sitter: Yes, after a re-boot, the favorites icons look breeze-like. Which makes the FireFox Icon look almost garish
[12:07] <mparillo> compared to the flat breeze iconts
[12:07] <mparillo> icons
[12:18] <soee> https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/eHg5XryQ2dS :]
[12:18] <yofel> lolwhat
[12:21] <yofel> btw.
[12:21] <yofel> soee: lp #1507676
[12:21] <yofel> seems like they added some kind of workaround
[12:22] <soee> yofel: yes, still xserver-xorg-video-intel (Ubuntu)needs to updated
[12:22] <soee> but the good news is that it is in progress :D
[12:22] <yofel> well yeah, but I think they still have no idea how to fix it properly
[12:22] <soee> so maybe we will be able to use propriety drivers in the end in Wily -.-
[12:22] <soee> ;o
[12:23] <BluesKaj> Hey folks
[12:24] <soee> hiho BluesKaj
[12:24] <BluesKaj> hey soee
[12:24] <soee> yofel: did you tested this partial fiox already and does it chnage anything ?
[12:24] <yofel> not yet no
[13:59] <marco-parillo> sitter: Thanks for fixing https://bugs.kde.org/show_bug.cgi?id=351805
[14:01] <ghostcube> will there be any theme for this sddm?
[14:01] <ghostcube> looks very ugly :)
[14:02] <pursuivant> muon (redesign) v5.4.1-109-gb480e01 * Aleix Pol: discover/qml (4 files)
[14:02] <pursuivant> Improve sizes on phone form factor
[14:02] <pursuivant> Try not to get views under the scroll bar when there's no scroll bar.
[14:02] <pursuivant> http://commits.kde.org/muon/b480e018b2fe3f2ee4a70d593b274980f13280cb
[14:05] <marco-parillo> sitter: Do you need a bug report for the caching bug of Oxygen icons on the Favorites Tab on first boot, then being replaced by breeze icons after a re-boot?
[14:41] <Riddell> mparillo: it does seem to have reverted back to oxygen :(
[15:34] <marco-parillo> But only on the first boot and only on the Favorites tab.
[15:38] <Riddell> spooky
[15:38] <marco-parillo> sitter thinks it is a caching issue.
[15:43] <Riddell> well my wifi issue was real it seems, new images coming shortly with a fix
[15:43] <Riddell> mparillo: fancy making a https://wiki.ubuntu.com/WilyWerewolf/Final/Kubuntu ?
[16:07] <marco-parillo> Riddell: Will do. I wonder why my wi-fi worked? Do you have the bug number?
[16:09] <Riddell> mparillo: bug 1508075
[16:09] <Riddell> marco-parillo: many other people could not recreate it
[16:10] <marco-parillo> Riddell: Are you sure we put out a final last time? All I see is a bare-bones https://wiki.ubuntu.com/VividVervet/ReleaseNotes/Kubuntu
[16:10] <unascribed> I'm trying to write a kwin effect that draws stripes and an icon over windows owned by a process that has been suspended with a SIGSTOP; any ideas on how I could go about this?
[16:10] <unascribed> I've tried looking around for documentation but all I can find is the source code and things about the JS API, which I don't think can do this
[16:10] <marco-parillo> If you look at the change log for https://wiki.ubuntu.com/VividVervet/ReleaseNotes/Kubuntu you will see that we removed all the details.
[16:16] <Riddell> marco-parillo: no it needs to be moved over to the website for the announce
[16:16] <Riddell> but it might be easier to make it on the wiki as a first step to that
[16:17] <marco-parillo> Gotcha
[16:29] <Riddell> voila
[16:29] <Riddell> !testers | ^^
[16:31] <BluesKaj> ok of, I'm here
[16:31] <BluesKaj> Riddell, ?
[16:33] <marco-parillo> So your wifi error was in ubiquity, not in the live session. I never get to it because of this: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1018160
[16:33] <BluesKaj> Riddell, ping
[16:37] <lordievader> Riddell: Can I still test tommorow? I really have no time today.
[16:44] <marco-parillo> Riddell: Ugh, when I try to copy to https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes/Kubuntu it says the page exists, but it does not.
[16:47] <BluesKaj> lordievader, any idea what Riddell wants us to test , I don't see a url or is it the latest daily build ?
[16:48] <lordievader> BluesKaj: Wily Final? What else :P http://iso.qa.ubuntu.com/qatracker/milestones/347/builds
[16:49]  * BluesKaj shrugs. well let's be sure
[16:58] <lordievader> BluesKaj: The email to the kubuntu-developers mailing list confirms it.
[17:06] <BluesKaj> guess I'm not on the llist ;-)
[17:07] <lordievader> BluesKaj: https://lists.ubuntu.com/archives/kubuntu-devel/2015-October/010012.html
[17:10] <BluesKaj> yeah, downloading as we speak
[17:19] <Riddell> BluesKaj: yes wily final candidates
[17:20] <lordievader> Riddell: Can I test it tommorow?
[17:20] <Riddell> lordievader: sure
[17:20] <lordievader> Ah, cool :)
[17:38] <murthy> hello everyone
[18:44] <soee> hmm each boot i have Baloo File Indexind Daemon crash
[19:06] <marco-parillo> Riddell: https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes/Kubuntu Are any bugs likely to close or be added? Otherwise, I can update the bug list.
[19:25] <claydoh> https://bugs.kde.org/show_bug.cgi?id=350769
[19:25] <claydoh> marco-parillo:  the missing compress and extract on  right-click of compressed files
[19:26] <claydoh> I know it is listed, but could be clarified in the description
[19:27] <claydoh> well, listed as bug 1490221
[19:28] <marco-parillo> I think the descriptions come straight from Launchpad.
[19:29] <marco-parillo> So if you can improve its clarity, I say go for it. I know I have done it a couple of times.
[19:31] <claydoh> ok
[19:33] <claydoh> Anyway, the bug listed is marked as fixed, but there is another more relevant bug I'll add
[19:38] <allee> soee: dvratil from akonadi maintainer has no extra login delay with akonadi master.
[19:39] <soee> allee: so it is not akonadi in the end ?
[19:39] <BluesKaj> well installed the Final build and had no desktop at first boot, had to use the recovery kernel with the dialog with network enabled to install 2 missing packages which then gave me a desktop with lower resolution nouveau . The driver manager stalled and disn't load the recommended driver options , so I installed the nvidia-340 driver in the terminal and rebooted. All is well now, sorry  i can't recall the 2 packages that finally
[19:39] <BluesKaj> gave me a desktop
[19:40] <allee> CI: is there an easy way to install just KDEPIM deb pkgs from master to check if it goes away here too.
[19:40] <allee> soee: Dan got delay report also from others not only kubuntu. So something is wrong.
[19:41] <allee> That he can't reproduce it complicates things unfortunately :-(
[19:42] <allee> soee: replacing akonadiserver with a script doing: exit 0 gives here a login time of 4 sec instead of almost 30 sec.
[19:42] <allee> So akonadi is at fault or at least triggers another bug
[19:44] <vip> :)
[19:44] <soee> allee: but we can be sure it is softwere not hardwere related ?
[19:44] <vip> I would love to have an option to disable akonadi at all
[19:45] <vip> from my login screen there's also ~30s lag to desktop
[19:45] <vip> sometimes, the progressbar is at 100%, sometimes, it hangs at ~80%, and hangs
[19:49] <mamarley> A while back there were questions as to the future of Kubuntu after 15.10 (because of the UCC thing).  Has anything been decided about that?  (Do I need to start hunting for another distro?)
[19:50] <allee> vip: dpkg-divert --local --rename /usr/bin/akonadiserver;  ln -s /bin/true /usr/bin/akonadiserver
[19:51] <allee> vip: then I login in 4 sec instead of 30.
[19:52] <allee> vip: as I use KDEPIM heavily this is not an option for me.  Was just an (impressive) test ;-)
[19:53] <soee> vip: exactly, and this is what we are trying to figure out
[19:54] <marco-parillo> mamarley: Every time I try a different one, Kubuntu pulls me back in.
[19:55] <marco-parillo> Latest dalliance was Manjaro. I love the AUR, but it does not run well on my 1GB netbook or in a 1GB VM.
[19:55] <marco-parillo> Kubuntu does fine on both.
[19:56] <allee> mamarley: This will depend if *ubuntu manages to get wayland stable with all the hardware out in the wild (I assume canonical with concentrate on mir hw problems not waylands)
[19:57] <vip> allee: i'm using kmail too, but a friend of mine suggested that
[19:57] <vip> and I agree
[19:57] <vip> when somebody does not use kdepim, why should he be forced to install akonadi
[19:59] <allee> vip: well,   If  kubuntu would disabled korgan event daemon & applet autostart, then there is no akondi running after login.
[20:00] <allee> right now there a ~ 10 sec delay for unused akonadi before it quits but we/I work to get this fixed.
[20:01] <vip> allee: great
[20:01] <vip> (btw, /me hopes for kde 5.5, because of fixed bug i hate :-)
[20:02] <allee> we all have our favorite bugs :-)
[20:02] <vip> oh sorry, i meant "i love" :)
[20:03] <vip> because of it is fixed :)
[20:30] <mamarley> allee: I'm not sure I understand, what does Wayland have to do with the CC conflict?
[20:34] <mamarley> (And I completely agree, Kubuntu is the best KDE distro out there and I will be massively disappointed if it goes away.)
[20:41] <allee> mamarley: oh, sorry.  Nothing.  Misunderstanding.  I thought you refer the discussion that happened when ubuntu announced their  mir commitment and KDE their only-wayland statement
[20:55] <BluesKaj>  15.10 Final Build is very slow to load the panel and some apps like  vpn connection get timed out due to the slow response ...definitely needs attention
[20:55] <mamarley> allee: I didn't hear about that.  When is KDE going Wayland-only?
[21:45] <keithzg> mamarley: I think allee just meant for future development; at the time, Shuttleworth mentioned that other DEs would definitely be ported to Mir, but KDE folks including quite notably (and relevantly) Martin Gräßlin publicly replied that they had no such plans (and until the suddenly Mir announcement hadn't even known that Mir existed).
[21:45] <keithzg> There's no plans to drop X11 any time soon, but similarly there's no plans to port things to work on Mir. The only work being done is for Wayland.
[21:48] <mamarley> OK, cool.  That's what I thought; I hadn't heard any definite plans for dropping X quite yet.
[22:10] <lucass_> Is anyone interested in Kubuntu 15.10 promo  video?
[22:10] <lucass_> because i made one ;)
[22:14] <lucass_> For those who does not know. I also made Kubuntu 15.04 official video
[22:15] <lucass_> http://www.kubuntu.org/news/kubuntu-15-04/
[22:17] <marco-parillo> That is great. The Kubuntu Podcast team could definately publicize it.
[22:18] <marco-parillo> ahoneybun: ovidiu-florin: ^^^
[22:18] <lucass_> I am currently uploading it to you tube
[22:19] <lucass_> or I can give source file if you want
[22:19] <marco-parillo> Then I will do my part (Kubuntu wire which feeds both planets)
[22:19] <marco-parillo> But not until tomorrow.
[22:19] <lucass_> I
[22:20] <lucass_> sure
[22:20] <lucass_> anyway in a few minutes I will give yuo
[22:21] <lucass_> a link to the video
[22:21] <marco-parillo> TY
[22:50] <lucass_> ok here is the link https://youtu.be/oWzSxyZu0ac
[22:52] <lucass_> what do you think?
[23:18] <Riddell> ooh!
[23:19] <Riddell> lucass_: love it!
[23:20] <Riddell> lucass_: are you the person behind the secret KDEOK account?
[23:20] <lucass_> yep
[23:21] <Riddell> lucass_: ah hah
[23:22] <tsimonq2> I am doing the last of the QA tests now
[23:22] <tsimonq2> at least for Kubuntu
[23:22] <Riddell> thanks tsimonq2
[23:23] <Riddell> lucass_: priv msg
[23:26] <tsimonq2> because I can do 4 QA tests at once
[23:26] <tsimonq2> 4 vms at once
[23:28] <Riddell> :)
[23:33] <tsimonq2> but aww...I need an existing system for two of them
[23:33] <tsimonq2> I guess I can wait until the first two are done
[23:33] <tsimonq2> unless someone else wants to take the auto-resize
[23:36] <tsimonq2> speak or forever hold your peace(unless you catch me before I get those started)
[23:53] <tsimonq2> aaaaaalllright
[23:53] <tsimonq2> moving on
[23:57] <tsimonq2> umm I am having a problem
[23:57] <tsimonq2> Riddell: ping
[23:58] <tsimonq2> umm it won't show me installing Kubuntu alongside of something
[23:58] <tsimonq2> it just tells me to erase it all
[23:58] <tsimonq2> I don't know if this is a bug, or if I did it wrong
[23:59] <tsimonq2> any answer would be great right now
[23:59] <tsimonq2> thanks


  I came here to for help to triage this issue.
[18:19] <Laibsch> brb


[07:45] <kraut> moin
[08:37]  * apw waves
[08:37] <apw> morning lag
[08:37] <cking> morning
[08:38] <apw> hi cking
[08:38] <ikepanhc> good morning
[08:38] <apw> evening ikepanhc
[08:38] <ikepanhc> not evening yet - afternoon now
[08:38] <apw> ahh :)
[08:39] <ikepanhc> 15:38 here
[08:39] <apw> ahh early you slacker :)
[08:39] <lag> Morning apw ;)
[08:39] <ikepanhc> :P
[08:40] <psurbhi> good morning! o/
[08:41] <apw> psurbhi, hi-ya, you recovered from the ubu-plague ?
[08:41] <lag> Hey cking
[08:41] <ikepanhc> good morning surbhi
[08:41] <psurbhi> apw, not completely yet :( i have few tests lined up
[08:41] <psurbhi> but good enough to work :-) so not too bad!
[08:41] <ikepanhc> psurbhi: still sick?
[08:42] <apw> psurbhi, thats cirtainly a bad one ... glad to hear you are getting well(ish)
[08:42] <psurbhi> ikepanhc, a little.. but good during most of the day
[08:43]  * psurbhi notes the ubu-plague ;) thats not the virus for sure
[08:44]  * ikepanhc just confused about plugra and prague - thought why prague makes surbhi sick...
[08:44] <apw> ikepanhc, heh
[08:45] <ikepanhc> :P
[08:45] <psurbhi> :D
[09:00] <smb> morning .*
[09:00] <ikepanhc> good morning smb
[09:01]  * apw waves to smb
[09:01] <ikepanhc> smb: I am rebasing hardy netbook-lpia branch, will send email when done, could you review for me?
[09:01] <smb> ikepanhc, will do
[09:02] <lag> Morning smb
[09:02] <ikepanhc> smb: thanks
[09:07] <ogra> amitk, why does maverick still have the lucid omap binary ... and apw why does the meta package still point to it ?
[09:07] <apw> ogra, i would think the latter is triggering the former
[09:07]  * smb also relates good morning to ogra
[09:08] <ogra> oh, and the package description of the new one is wrong, it talks about omap3 and 4, we will need two distinct binaries for that
[09:08] <ogra> moring too, everyone :)
[09:08] <apw> ogra, given we don't even have the omap4 ... indeed so
[09:08] <ogra> apw, and if we have it the current patchset needs its own binary
[09:09] <ogra> (we'll need to have omap4 by A2)
[09:09] <apw> ogra, i've not seen any omap4 code proposed as yet
[09:09] <ogra> apw, well, cooloney will likely have to work on it (since 10.07 went happen)
[09:09] <cooloney> apw: i missed some context here.
[09:10] <amitk> apw: any ETA for TI to give us a re-based patchset on top of maverick master?
[09:10] <cooloney> apw: yeah, i got a omap4 branch but it is for lucid not maverick
[09:10] <amitk> and good morning
[09:10] <cooloney> amitk: morning, man
[09:10] <apw> amitk, i've not been told any dates no
[09:10] <cooloney> i don't know either.
[09:10] <ogra> cooloney, so the good news for you is that a) i have a panda branch: http://gitorious.org/pandaboard/u-boot/commits/omap4_panda (should be only a few patches on top of the current omap4 kernel)
[09:10] <apw> cooloney, are you owning omap4 for maverick or is that meant to be mathieu/lag ?
[09:10] <ogra> cooloney, and b) we dont do 10.07
[09:11] <smb> apw, \o Gm, when the others are done I have a question, too
[09:11] <cooloney> apw: i am going to do that. mathieu will own the omap thing in master branch. i think
[09:11] <apw> ok then ogra i refer you to the omap4 owner cooloney  :)
[09:12] <ogra> amitk, we were told they would rebase on to of our tree during this week, so i would expect something latests by beginning of next week
[09:12] <ogra> apw, ^^
[09:12] <apw> cooloney, seems we need something very very soon
[09:13] <apw> ogra, i think we need to get cooloney plugged into the information stream you have from ti
[09:13] <ogra> apw, the call is at an awkward time for him :(
[09:14] <apw> ogra, ok, but we need to make sure he gets the info either way, as you know things he needs to be on top of :)
[09:14] <cooloney> apw: yeah, normally i will email and irc contact with sebjan
[09:14] <ogra> apw, thats why i gave him the info right now :)
[09:14] <cooloney> apw: right, i need to sync up with ogra
[09:15] <ogra> apw, the decision to drop 10.07 was made friday evening
[09:15] <apw> ogra, sounds sane and will make smb happy
[09:15] <cooloney> ogra: what's kind of decision? hehe. i just arrived at hugh and haitao's hotel, and wifi from the lobby
[09:16] <cooloney> ogra: maybe i missed some info
[09:16] <smb> Everything which is a S.E.P. makes me happy
[09:16] <amitk> cooloney: NO LUCID OMAP4 KERNEL! :)
[09:16] <ogra> right
[09:16] <ogra> you can put your efforts into 10.10
[09:17]  * cooloney feels someone punch his head to the iron door
[09:17]  * smb immediately forgets about Lucid-ti-omap4
[09:18] <cooloney> amitk and ogra, really? skip 10.07 ti-omap4 kernel
[09:18] <cooloney> and just 10.10 ti-omap4 kernel, right?
[09:18] <ogra> right
[09:18] <cooloney> and how about the time frame of this
[09:19] <ogra> asap, but the ball is at TI
[09:21] <apw> smb you are up
[09:23] <smb> apw, Just wanted to check with you on the state of the upstream patches for the sync-time problem. I believe we said we will try to take the set of three and put it into the next proposed. I am not sure I missed something but I saw no mail or git update
[09:23] <apw> smb, indeed somehow i didn't get to it
[09:24] <apw> smb, i can look at it now
[09:24] <smb> apw, Ok, awesome. Thanks
[10:50] <amitk> dmesg
[10:50] <amitk> erm, -EWRONGWINDOW
[10:59] <ikepanhc> eh, looks like ecryptfs with chroot environment is a bad idea, I can not bind /home to chroot's /home
[11:08] <anoteng> Hello, I'm git-bisecting a kernel, and all of a sudden the kernel image deb depends on linux-tools-kernelversion which of course does not exist. Is it safe to force the installation? What does the linux-tools packages do?
[11:08] <apw> ikepanhc, heh
[12:44] <smb> anoteng, Just supplies user-space half of some tools (perf afaik). For testing it should be safe to force
[12:48] <apw> anoteng, i think you were pretty unlucjy there, pretty sure that that dependancy was not there for very long at all
[12:49] <apw> anoteng, and yes you can ignore it and push the package harder
[12:49] <smb> apw, pushed Karmic fsl-imx51 rebased to my current master
[12:50] <apw> smb, ahh thanks ... am still building the comparisons ... as they broke the first time
[12:50] <smb> apw, Something on master broke or the merge of abstracted?
[12:51] <RAOF> Ok, so it seems that both 2.6.34-5 and 2.6.35-1 have a habit of panicking and then rebooting.  Is there a debug kernel I can install to make these events maximally useful?
[12:51] <apw> smb, the first breakage was because the existing packaging actually is broken and does not make the contents of the docs package ... which does not work, a minor source tweak to the kernel itself sorts that out
[12:52] <apw> smb, the second is because the new packaging produces the debug packages with the correct new names, which i'd not allowed for
[12:52] <smb> Ah ok... Not nice but ok...
[12:52] <smb> Hm... haven't I changed that already?...
[12:52] <apw> smb, i am assuming we are happy to have the debug images have the new name ?
[12:53] <Sarvatt> 2.6.35-1 is nasty, my netbook no longer goes into C3 on it and idles around 2x higher power usage :D
[12:54] <smb> apw, Yeah sure. Ah, ok I only fixed the packaging to be using the contents of CurrentlyBuilding, not the naming
[12:54] <apw> smb, ahh ok makes sense
[12:54] <smb> Sarvatt, I think I saw a patch for that today
[12:54] <Sarvatt> yea it was on master just before rc2 released luckily
[12:54] <apw> Sarvatt, does not supprise me at _all_, noone should run an -rc1 kernel they are crack smoking messes
[12:55] <apw> i am sure we'll be uploading -rc2 asap
[12:55] <smb> apw, If noone would run -rc1, who would find the bugs. ;-P
[12:55] <apw> s/noone/noone sane/  perhaps :)
[12:55] <smb> heh
[12:57] <Sarvatt> finding bugs gives me an excuse to learn more about what's broken, i don't mind :)
[12:57] <apw> Sarvatt, yeah if i had more time i'd be like that too
[13:01] <RAOF> So, is there a kernel debug package?  And if so, where is it? :)
[13:04] <apw> RAOF, there is a a package with more symbols, nothing with more debugging code in it
[13:06] <RAOF> The former was what I was expecting.  What's the package called?  “aptitude search linux” doesn't seem to pick up anything relevant.
[13:15] <apw> RAOF, they are in the ddebs archive
[13:16] <smb> Though I am not sure this is what RAOF is expecting. More for post mortem debugging and disassembly that more verbose output. Maybe saying debug on the kernel command line (instead of quiet) is enough for that purpose
[13:18] <apw> RAOF, what are your symptoms on failure
[13:19] <RAOF> The screen stops for about a second, perhaps getting distorted colours, and then the system shuts down.
[13:21] <RAOF> Without the plymouth splash kicking in.  One of the lines is something along the lines of “kernel panic, restarting”.
[13:21] <RAOF> Basically what I want to do is to produce a useful bug for you, preferably without rebuilding my kernel a hojillion times.
[13:28]  * cking-afk goes for some food
[13:45] <apw> RAOF, ok so i'd first try booting without quiet and splash on your command line and see how that looks
[13:46] <pgraner> tgardner: emerald is back in the rack
[13:47] <Daviey> Hi, there seems to be bit of a kernel regression in current maverick that is potentially pretty critical for the server.  It seems to (oddly), caused a userspace issue of a *java* library not working as expected.  I don't know if it's related to entropy or something, but the function is handling en/de-cryption.  I would appreciate input, thanks :)  bug #588861
[13:47] <ubot2> Launchpad bug 588861 in linux (Ubuntu) (and 1 other project) "Instances block in pending state, and don't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/588861
[13:48] <Daviey> ^^ Unrelated to KVM.
[13:48] <tgardner> pgraner, ack
[13:48] <apw> Daviey, i suspect there will be an -rc2 kernel very shortly and that has to be less broken than -rc1
[13:49] <Daviey> apw: that is great, do you think that will be this week?
[13:49] <apw> Daviey, i'd say that is very likely
[13:49] <Daviey> apw: awesome, thanks
[13:50] <apw> its probabally not worth spending to much time debuggnig on -rc1 is really my feeling
[13:50] <Daviey> apw: Ok, moving on :), thanks
[13:51] <Daviey> apw: Whilst i'm here.....
[13:51] <Daviey> Is there anything that can assist bug #576601
[13:51] <ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 85) (heat: 588)" [High,Triaged] https://launchpad.net/bugs/576601
[13:51] <Daviey> crikey, i notice there is now a bounty!
[13:53] <apw> Daviey, other than trying upstream releases like -rc2, probabally not a lot
[13:53] <Daviey> apw: ok, thanks.
[14:09] <anoteng> apw: thanks for your reply earlier. Didn't see it until now...
[14:34] <smb> tgardner, apw *sigh* ok for the sake of simplicity I would squeeze in the sfc update into the same bug as <IP_ADDRESS>. There don't seem other updates for that in .33. 2.6.34.y did not have a stable release, yet. So the other parts of this Frankenkernel had no counterparts, yet (beside of a lot of skipping for thinkpad-acpi)
[14:34] <tgardner> smb, too late, I've already created a bug
[14:34] <apw> smb, sounds ok
[14:35] <smb> tgardner, Ok, we can decide that then in July
[14:35] <smb> apw, Could you have a quick look and potentially ack or are you quite busy?
[14:35] <tgardner> smb, bug #590783
[14:35] <ubot2> Launchpad bug 590783 in linux (Ubuntu Lucid) (and 1 other project) "Lucid sfc stable updates from <IP_ADDRESS> (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/590783
[14:36] <apw> smb, if it can wait about 30 mins i may be able to, trying to fix an install bug i think we are about to hit
[14:36] <smb> apw, It can
[15:31] <JFo> smb, do we do re-rolls of non-free firmware for older releases?
[15:31] <JFo> by reroll, I mean do we update that package for them?
[15:31] <smb> JFo, tgardner and cnd took care of that mostly. I think not too far back, but for LTS
[15:32] <smb> Depends a bit on the driver too
[15:32] <JFo> ah, my Q was in reference to the last comment in bug 387875
[15:32] <ubot2> Launchpad bug 387875 in linux (Ubuntu) "Samsung N120 Realtek wireless fails in Karmic (affects: 4) (heat: 34)" [Medium,Confirmed] https://launchpad.net/bugs/387875
[15:32] <cnd> JFo: is it marked against linux-firmware or linux-firmware-nonfree?
[15:32] <tgardner> JFo, I consider those to be desktop issues, therefore encourage a more recent release
[15:33] <JFo> tgardner, i thought as much
[15:33] <JFo> thanks
[15:33] <JFo> cnd, no it was against the linux pkg
[15:42] <Keybuk> hmm, since the latest kernel update on maverick, my laptop can't connect to the wireless network anymore
[15:45] <apw> Keybuk, is that using wl ?
[15:46] <apw> NAME = Sheep on Meth
[15:46] <apw> i note that 2.6.35 is names at above currently
[15:46] <Keybuk> apw: iwl3945
[15:46] <apw> Keybuk, no working from starbucks for you then
[15:47] <Keybuk> known bug or not?
[15:49] <tgardner> Keybuk, likely not, so you should try the mainline kernel as well, then complain upstream if its still not working.
[15:58] <apw> ogasawara, yo!  you about ?
[15:58] <ogasawara> apw: yep, just startin my day
[15:59] <apw> ogasawara, ok you are going to his this build issue as soon as you rebase to -rc2 ... the one i was seeing last friday
[15:59] <apw> i think i know the right fix now, just need a tree to do it to :)
[16:00] <ogasawara> apw: cool, was going to apply any outstanding patches from the k-t ml and then rebase to -rc2
[16:00] <apw> ogasawara, awsome, i'll push out a patch for it for you shortly
[16:00] <ogasawara> apw: sweet
[16:24] <cnd> JFo: I'd put bug 577114 as kernel-net since it's dealing with rfkill wifi issues
[16:24] <ubot2> Launchpad bug 577114 in linux (Ubuntu) "Wireless and Bluetooth switch does not work correctly on lenovo ideapad s10-3 (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/577114
[16:28] <bjf> cnd, fyi: http://gizmodo.com/5556985/apple-multitouch-trackpad-peripheral-leaked
[16:28] <cnd> bjf: yep, saw that this morning
[16:29] <cnd> I usually read a live blog of wwdc keynote, so I'll see what it's all about
[16:29] <ogasawara> JFo: I notice the top 50 bug list counts bugs which we've closed (ie Fix Released, Invalid, etc.)
[16:30] <cnd> ogasawara: maybe they're bugs we've closed in the past week?
[16:30] <ogasawara> JFo: would you prefer if I modify the script to show the # of open vs closed rather than the total
[16:30] <cnd> his list is manually created
[16:31] <ogasawara> cnd: right, I was just thinking along the lines that when the # goes above 50 it indicates we need to hammer on the list, but that's not exactly true right now
[16:32] <cnd> ahhh, yeah
[16:45] <apw> ogasawara, but that is in the 'added this week' section isn't it?  and those stay there
[16:46] <apw> even when closed
[16:47] <apw> fir t
[16:48] <apw> for the week they were added
[16:48] <manjo> bjf, http://people.canonical.com/~manjo/netbooks/
[16:48] <ogasawara> apw: that's true, so I assume JFo will then go clear out the closed ones
[16:49] <apw> ogasawara, he may need to be taght
[16:51] <apw> smb, about
[16:51] <apw> ?
[16:52] <apw> ogasawara, i thought that in that table generator that the curernt week was always in full, and there was actually two tables 'this week' and 'the lot' and in the second table the closed ones are elided ?
[16:53] <JFo> cnd, cool
[16:54] <JFo> ogasawara, I can remove them during our meeting, I actually like them being there so that we can see what has happened over a week.
[16:54] <ogasawara> apw: but for the top50 list we only have a single table
[16:54]  * manjo otp ... brb soon...
[16:54] <ogasawara> apw: that can obviously be changed though
[16:54] <apw> ogasawara, i had assumed when i saw 'added this week' that this would work like the other one
[16:55] <apw> if its easy to do it might be nice to keep that semantic
[16:56] <ogasawara> apw: should be easy to add back the bits
[16:57] <apw> ogasawara, no biggie
[16:58] <ogasawara> JFo: I'll get you an updated script
[16:58] <JFo> ogasawara, cool
[17:00] <JFo> cnd, you joining us for bug chat or you busy?
[17:00] <manjo> JFo, do we have a call ?
[17:00] <cnd> I'm going to join
[17:01] <JFo> cnd, cool
[17:01] <JFo> manjo, mumble
[17:02] <JFo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
[17:09] <smagoun> Anyone know much about power mgmt/batteries in ubuntu on apple hardware? I bought a 63 watt-hr battery for my macbook pro. /proc/acpi/battery/BAT0/info shows the design capacity is only 58000mWh, and last full capacity is 52000 mWh. How likely is it that those values are accurate? They don't match what I expect from the hardware.
[17:10] <smagoun> (i'm on 10.04, fwiw)
[17:10] <amitk-afk> smagoun: the question is does, MacOS show the capacity correctly?
[17:10] <jjohansen> smagoun: they should be accurate
[17:11] <smagoun> amitk-afk: good question, I dunno. Haven't booted macos w/ this battery yet
[17:16] <smagoun> jjohansen: hmm, I just swapped in my old (OEM) battery, which is clearly labeled 60 watt-hr. /proc/acpi/battery/BAT0/info shows the design capacity is 56000mWh. At least the system is consistently wrong
[17:17] <jjohansen> smagoun: I've never had a battery match its printed capacity, though they are usually have higher values, not lower
[17:17] <smagoun> jjohansen: It's Apple kit, Think Different I guess
[17:17] <amitk> doesn't a LiON battery require a few charge-discharge cycles to reach its pull capacity?
[17:17] <amitk> *full
[17:18] <smagoun> amitk: that shouldn't affect the design capacity, just the last full capacity
[17:18] <amitk> true
[17:22] <smagoun> 63 W-hr is 5833 mAh * 10.8v (the design voltage). That's pretty close to the reported design capacity (58000mWh). Any chance the hardware reports design capacity in mAh rather than mW? Where does the value come from, is it pulled directly from ACPI or is it calculated?
[17:24] <jjohansen> smagoun: yeah I think it does actually report in mAh now that you mention it
[17:34] <bjf> ogasawara, where is the source for the source_linux.py apport hooks ?
[17:34] <ogasawara> it's in apport
[17:58] <bjf> ogasawara, a "bzr branch lp:apport" does not give me the source_linux.py anywhere in the resulting tree
[18:03] <ogasawara> bjf: I'd typically do a `debcheckout apport` and it should be in data/package-hooks/source_linux.py
[18:05] <bjf> ogasawara, just did that and data/package-hooks only has "source_apport.py"
[18:05] <ogasawara> bjf: hrm, not sure what's happened then
[18:06] <bjf> ogasawara, thanks, i'll figure it out
[18:06] <ogasawara> bjf: I'm seeing it here, but it's lucid.  http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu/files/head:/data/package-hooks/
[18:07] <bjf> ogasawara, hmmm
[18:08] <bjf> ogasawara, i've been "bzr branch bzr+ssh://bazaar.launchpad.net/~apport-hackers/apport/trunk/" which doesn't get it for me
[18:09] <manjo> apw, heh.. https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
[18:10] <bjf> ogasawara, or even "bzr branch lp:~apport"
[18:10] <ogasawara> bjf: not sure what the apport-hackers team is
[18:11] <ogasawara> bjf: https://wiki.ubuntu.com/Apport - "If you want to contribute to it or develop your own system based on it, you can get your own branch with bzr get lp:apport for trunk, or debcheckout -a apport for the Ubuntu packaging branch."
[18:11] <ogasawara> bjf: but then the "browse it online" link point to the apport-hackers
[18:11]  * ogasawara is confused
[18:12] <ogasawara> bjf: is that the upstream source?
[18:12] <bjf> ogasawara, not sure what you are asking?
[18:13] <ogasawara> bjf: just trying to figure out what the code shown in apport-hackers is
[18:13] <bjf> ah, yes, that "seems" the latest and greatest
[18:14] <bjf> ogasawara, a "debcheckout -a apport" got it for me, but I still don't understand
[18:16] <manjo> psurbhi, long time no see
[18:18] <psurbhi> manjo, hie :)
[18:20] <manjo> psurbhi, looks like you finally recovered ubuntuflu
[18:20] <psurbhi> hey, i did not have a ubuntuflu and nor have i fully recovered.. infact i have to do some tests to eliminate further infection :)
[18:21] <psurbhi> so will soon find out if i am out of it or not :)
[18:21] <manjo> psurbhi, sorry to hear that... looks like it got you good this time
[18:21] <psurbhi> :-/
[18:22] <manjo> psurbhi, will you be in shape to attend the platform sprint ?
[18:22] <psurbhi> manjo, yes! i think so... so we can meet up then!
[18:25] <manjo> psurbhi, yep
[18:28]  * manjo out for lunch
[18:53] <apw> JFo, ok ... i've put together a very basic todo and style guide linked from the Kernel page
[18:53] <JFo> cool
[18:54]  * JFo goes to peruse
[18:54] <apw> JFo, what do you think about mixing debugging and testing together, or does that need its own section ?
[18:55] <JFo> hmmm
[18:55] <JFo> I actually like that idea
[18:55] <amitk> apw: do you start editing 20 pages at once and do an atomic save?!
[18:55] <JFo> as there will be parts pertinent to both
[18:55] <amitk> *wiki pages
[18:55] <apw> amitk, heh no why ?
[18:56] <amitk> apw: just wonderig about the 10 emails with wiki updates from you :)
[18:56] <apw> amitk, ahh no just incompetant
[18:58] <amitk> hehe
[18:59] <JFo> looks great apw, I especially like the current layout of both the todo and the gardening guide
[19:02] <apw> JFo, so what do you think about testing?  should i add it to debugging?
[19:02] <apw> or perhaps we could have a longer list of topics on the front page
[19:03] <apw> and that could be one of them
[19:03] <apw> JFo, i think i'll mock that up for testing and see how it looks
[19:03] <JFo> hmmm
[19:03] <JFo> ok
[19:04] <JFo> maybe we will need to have testing and then set up debugging links from the testing bit?
[19:04] <JFo> I'd really like for testing to be a bit separate from debugging, i think
[19:04] <JFo> I could be completely wromg though
[19:06]  * JFo heads to a quick lunch
[19:09] <apw> JFo, i'll treat it separate, we can have a full list of areas on the front page, but only links in the menu to those which are critical and commonly used
[19:09] <apw> see the current front page for what i mean
[19:12] <JFo> yeah, I like having that in the Topics section
[19:17] <apw> JFo, ok i've added that to the documentation and copied over the testing topics
[19:19] <JFo> sweet
[19:19]  * JFo goes to grab that lunch now
[19:34] <pgraner> ogasawara: ping
[19:34] <ogasawara> pgraner: pong
[19:34] <pgraner> ogasawara: [14:09] <robbiew> pgraner: looks like broadcom (STA) driver is busted on latest maverick kernel (2.6.35)
[19:34] <pgraner> [14:10] <robbiew> I'll file a bug, just an fyi
[19:34] <pgraner> [14:10] <robbiew> DKMS crapping out on building the module...works fine in the previous 2.6.34-5 kernel
[19:35] <robbiew> :)
[19:35] <ogasawara> robbiew: can you point me to your bug# so I can keep it on the radar
[19:35] <pgraner> ogasawara: I have notified the proper authorities
[19:35] <JFo> heh
[19:35] <robbiew> will do..need to recreate so I have stuff to post :)
[19:36]  * robbiew finds his ethernet cable :/
[19:36] <ogasawara> heh
[19:36] <pgraner> tgardner: any idea when henry will get the OSS driver free?
[19:44] <tgardner> pgraner, I asked him that just last week. He said he'd let me know as soon as possible. kind of vague.
[19:45] <tgardner> I've been pushing himto get it available in time for Maverick
[19:45] <pgraner> tgardner: yea, would be nice if they gave us some beta code to test, I'm sure we would help this whip it into shape, would be nice to have it this early in the cycle
[19:54] <robbiew> ogasawara: bug 590924
[19:54] <ubot2> Launchpad bug 590924 in linux (Ubuntu) "Broadcom STA (bcmwl) driver fails to build with 2.6.35-1 kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/590924
[19:54] <ogasawara> robbiew: thanks
[19:55] <robbiew> ogasawara: I'll leave it with that version if you all need me to do any testing or log grabbing
[19:55]  * robbiew used ubuntu-bug, so you should have all the standard files
[20:15] <jjohansen>  -> Lunch
[20:26] <ogasawara> robbiew: just want to check, were the dkms errors you saw the same as http://launchpadlibrarian.net/49811242/DKMSBuildLog.txt
[20:28]  * tgardner wished we could stop packaging wl
[20:28] <tgardner> wishes*
[20:44] <manjo> JFo, I marked BGug #564051  as invalid, can you remove bugs marked invalid from your top 50 list ?
[20:59] <robbiew> ogasawara: I never saw that on the screen...is there a logfile I can check?
[21:39] <ogasawara> robbiew: do you have anything under /var/lib/dkms/bcmwl/<version>/log/make.log ?
[22:43] <kees> ogasawara: do you know which of the maverick CVEs have been fixed?  http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html
[22:43] <kees> ogasawara: I want to get the tracker updated
[22:44] <ogasawara> kees: let me try to get a list together for you as we split them up amongst stefan, surbhi, and myself
[22:44] <kees> ogasawara: ah, cool.  I wasn't sure if maverick was being done the same way as the stables.
[22:45] <ogasawara> kees: typically for maverick smb will tell me which one's I need fixes for.  but assuming if they're already upstream I might not need to do anything.
[22:46] <kees> ogasawara: yeah, that where I'm a bit lost.  I assume nearly all of them are fixed, but finding them isn't always obvious to me.
[22:52] <robbiew> ogasawara: okay...exact same text
[22:52] <robbiew> except mine was ALL in english
[22:52] <robbiew> no cyrillic
[22:52] <robbiew> lol
[22:52] <ogasawara> robbiew: cool, thanks :)
[23:09] <ogasawara> kees: http://pastebin.ubuntu.com/446324/
[23:10] <ogasawara> kees: a few I marked not-affected? based solely on the CVE description but I didn't dig any further to officially verify
[23:10] <ogasawara> kees: so you may want to actually mark those needs-triage just so we can double check
[23:11]  * bjf[afk] will be back later
[23:21] <kees> ogasawara: cool, thanks
[23:35] <kees> ogasawara: I validate the ones you had question marks on; all not-affected.  :) wheee
[23:36] <ogasawara> kees: sweet
[23:36] <kees> er, validated.


[01:15] <pace_t_zulu> jfenn2199: yea ... programming takes patience and effort to learn
[01:22] <chris4585> indeed
[01:22] <chris4585> I have like neither of those :(
[01:22] <chris4585> well I have some


[02:07] <Daskreech> valorie: http://www.washingtonpost.com/world/asia-pacific/285-indian-girls-replace-names-meaning-unwanted-to-rise-above-gender-discrimination/2011/10/22/gIQAb9vI6L_story.html Thought you would like that
[02:37] <valorie> thanks Daskreech
[02:37] <valorie> reading
[02:39] <valorie> that's great that they are changing
[02:39] <valorie> but how horribly sad that they were ever named that, or were unwanted
[02:39] <valorie> :(
[02:40] <valorie> India will not become the great nation she can be until all humans are valued equally
[02:50] <Daskreech> valorie: I know it's such a mixed emotion article
[02:50] <valorie> progress is good, celebration is good
[02:51] <Daskreech> yes. I like that the school peers are choosing to use the new names
[02:51] <valorie> I knew my parents wanted a boy, but I didn't feel unwanted
[02:51] <valorie> here in the US, when parents CAN choose, they are more often choosing girls
[02:53] <valorie> I would like all children to be wanted, loved, nurtured
[02:53] <valorie> we'll get there eventually
[02:54] <ScottK> JontheEchidna: No.  I think it's the opposite.  ppa-purge removes the packages from your system.  I think klearppa removes the packages from the PPA.
[02:54] <JontheEchidna> aah,makes sense
[02:55] <Daskreech> THey choose girls?
[02:55] <Daskreech> hmm wonder why?
[02:55] <maco> Daskreech: perception that boys are pains in the rear to raise?
[02:55] <maco> that whole "*sigh* boys will be boys....*tut tut*"
[02:56] <Daskreech> maco: They are
[02:57] <Daskreech> Not saying that it's a breath of fresh air raising girls
[02:57] <ScottK> No, but it's definitely different.
[02:59]  * Daskreech smiles
[03:00] <JontheEchidna> ScottK: btw, how hard would it be to get muon/libqapt 1.2.2 SRU'd if they follow KDE point release policy?
[03:00] <Daskreech> Does the new LTS rule apply for Kubuntu ?
[03:00] <ScottK> JontheEchidna: I think it'd be an email to the TB.  Not a big deal.
[03:00] <ScottK> Daskreech: What rule?
[03:00] <Daskreech> LTS is 5 yr support
[03:01] <ScottK> Probably.
[03:01] <ScottK> It'd be weird for it not to since it's exactly no more work to do so.
[03:01] <ScottK> I suppose that'll get worked out at UDS.
[03:02]  * Daskreech wants to start pimping Kubuntu locally
[03:06] <Daskreech> But it seems that they are making LTS to LTS upgrades much more centered around when the new LTS comes out
[03:08] <valorie> what do you folks think about testing http://www.jupiterapplet.org/ to use in Kub?
[03:09] <valorie> I keep hearing that battery use in *buntu is half as good as Windows
[03:12] <Daskreech> valorie: I dont' know about 1/2 but it's certainly poorer
[03:14] <Daskreech> sabdfl got elected to the Community Council. Nice
[03:26] <ScottK> valorie: It'd need to be really tested to see if it's better.  At a glance, some of the things they are doing (changing CPU mode) are obsolete with modern kernels.
[03:31] <valorie> I haven't heard about anyone else working on solutions for the problem
[03:32] <valorie> seems like more folks would be interested
[04:37] <yofel_> JontheEchidna: ppa-purge removes packages from your system, klearppa removes sources from a PPA
[04:37] <JontheEchidna> cool
[04:37] <yofel_> good morning btw. :)
[04:45] <JontheEchidna> haha, I'm about to go to bed
[04:45] <JontheEchidna> yay timezones :P
[08:36] <shadeslayer> Quintasan: yeah, but I can't do anything till they crack the sbk v2 key and fix the mini boot loader thingy
[08:37] <shadeslayer> and stupid xbox .. doesn't come with a variable voltage adapter
[08:37] <shadeslayer> -.-
[09:26] <bambee> hi
[09:30] <Riddell> bonjour bambee
[09:31] <bambee> salut Riddell  :)
[10:47] <Riddell> apachelogger: did you register blueprints for UDS or did I imagine that?
[10:51] <apachelogger> Riddell: you must have imagined, or launchpad ate them :)
[10:55] <Riddell> nom nom
[10:56] <Riddell> JontheEchidna: do we need/want a session for muon?
[10:58] <Riddell> Quintasan: https://wiki.kubuntu.org/Kubuntu/Specs/UDS-P has a maybe by your name, do you know if you're coming?
[11:01] <Riddell> maco: are you expecting to be in kubuntu sessions?  can I put you on that page?
[11:17] <JontheEchidna> Riddell: yeah, I think I'd like a session and maybe see what the Kubuntu dev community can come up with as a wishlist.
[11:22] <JontheEchidna> is there anybody who speaks french that could help me with bug 283728? If I could get him to provide a backtrace I think it would help.
[11:22] <JontheEchidna> kde bug 283728
[11:22] <JontheEchidna> er
[11:22] <JontheEchidna> kde bug 284896
[11:22] <Riddell> c'est un boog!
[11:23] <Riddell> un moment
[11:25] <Riddell> JontheEchidna: translation added, it's not very enlightening
[11:25] <JontheEchidna> Hmm :(
[11:26] <JontheEchidna> gotta go, bbl
[11:54] <Riddell> bambee: quel est la difference entre "bonsoir" et "bonne soiree"?
[12:03] <bambee> Riddell: "bonsoir" est équivalent à "good evening", tu salues une personne et c'est le soir. "bonne soirée" est équivalent à "have a nice evening", tu l'utilises lorsque tu souhaites dire au revoir et souhaiter une bonne soirée à une personne.
[12:04] <bambee> Riddell: that's probably better to continue this discussion on #kde-fr, nop ?
[12:46] <txwikinger> Any idea why muon during upgrade always freezes?
[12:47] <txwikinger> apt-get upgrade works fine
[12:55] <ScottK> Quintasan: I confirmed the Kickoff thing is a regression from 4.7.1.  Also switch to classic kickoff is missing.
[13:28] <maco> Riddell: yeah
[13:31] <yofel> rekonq needs testing btw: bug 880922
[13:35] <Quintasan_> ScottK: I see, the bug was reported by someone else I guess?
[13:35]  * Quintasan would like to backport the patch
[13:36] <Quintasan> Riddell: I'll be coming for sure, forgot to edit
[14:17] <CIA-130> [lp:kubuntu-dev-tools] Philip Muškovac * 132 * bin/klearppa clean up the options, add an option to use a different source package status than Published and workaround lplib weirdness
[14:20] <CIA-130> [lp:kubuntu-dev-tools] Philip Muškovac * 133 * bin/klearppa typo
[14:22] <_Groo_> hi/2
[14:22] <_Groo_> all
[14:22] <yofel> o/ _Groo_
[14:23] <_Groo_> yo yofel :D
[14:23] <_Groo_> im doing git calligra packages for oneiric as we speak
[14:27] <jtechidna> txwikinger: hicolor-icon-theme's update trigger script is hanging when gtk-update-icon-cache errors out: https://launchpad.net/bugs/855793
[14:28] <txwikinger> jtechidna: Well. but apt-get does not hang
[14:29] <jtechidna> dpkg is doing the hanging. muon just seems to expose the bug
[14:29] <txwikinger> hmm.. I hear you, I am still confused why I never get the problem with apt-get
[14:29] <yofel> too many errors to stderr maybe?
[14:30] <yofel> as I remember the flood of messages when you update that
[14:30] <txwikinger> or maybe you need a timeout
[14:30] <jtechidna> apt-get is usually run in a full-blown terminal emulator usually. That might be the difference
[14:30] <jtechidna> eh, too much usually in that sentence ;-)
[14:30] <txwikinger> the problem is that inexperienced users use muon and it freezes, they reboot and dpkg is locked
[14:30]  * yofel usually just uses aptitude :P
[14:31] <jtechidna> it also seems to be a regression, since the same version of qapt/muon don't exhibit this error in 11.04
[14:32] <txwikinger> yes.. I always havee those GdkPixbuf errors on commandline
[14:33] <txwikinger> Why do we need to run gtk-update-icon-cache in KDE?
[14:34] <txwikinger> ubuntu is so messed up :(
[14:35] <jtechidna> Gtk uses an icon cache for its core icon system, and it needs to be updated when the icons change. So if hicolor-icon-theme and a gtk package are both installed the update occurs
[14:36] <jtechidna> so as long as gtk is installed, the icon cache update is needed for icons to work properly with gtk apps
[14:43] <txwikinger> Still no reason to have all those errors for several releases now
[15:02] <Quintasan> godamn
[15:02] <Quintasan> Kubuntu fails to discover my intergrated ethernet card
[15:02] <Quintasan> ...
[15:03] <yofel> o.O
[15:06] <Quintasan> I mean, how the hell it's even possible
[15:06] <Quintasan> AH !#%@#$@# THIS
[16:28] <rbelem> Quintasan, i just generated an arm cross compiler tarball pkg to use with icecc
[16:28] <rbelem> :-D
[16:28] <apachelogger> <3 xcompiling
[16:28]  * rbelem hugs apachelogger
[16:29] <rbelem> apachelogger, i will build the active packages with that
[16:30] <apachelogger> rbelem: I thought we have a PPA?
[16:30] <rbelem> apachelogger, they are really busy
[16:30] <rbelem> :'(
[16:30] <apachelogger> how about we install an open build serivce on the arm farm at ScottK's
[16:31] <rbelem> apachelogger, that would be awesum
[16:31] <rbelem> :-D
[16:37]  * rbelem goes for lunch
[17:34] <yofel> uhm. Why does kubuntu-full recommend nvidia-current and fglrx?
[17:35] <yofel> depending on something like bcmwl-kernel-source at least doesn't break anything
[17:36] <yofel> installing the nvidia or ati drivers will at least disable MESA. So if you're using intel you're left without opengl
[19:48] <apachelogger> yofel: cause it is full of brekage? *shrug*
[19:48] <yofel> why are we shipping breakage? ...
[19:48] <apachelogger> why do the prop drivers screw with MESA anyway?
[19:48] <apachelogger> seems rather brain dead to me
[19:48] <yofel> well, nvidia ships it's own libGL, so you somehow need to manage that
[19:49] <apachelogger> yofel: listen to the oneiric defaults sessoin from last uds
[19:49] <apachelogger> there is reasons, they are not good IMHO, but they are there
[19:49] <apachelogger> yofel: ah, right
[19:50] <apachelogger> yofel: well, that is a pain in the neck right there
[19:50] <apachelogger> it would totally make sense to have full provide all the rubbish one might or might not need
[19:51] <apachelogger> however if stuff is mutually exclusive that sort of compromises the use of it all
[19:51] <yofel> well, it's not mutually exclusive.... but you would've to run a few update-alternative switches after installing it for it to work...
[19:52] <apachelogger> right, so they are effectively mutually exclusive or something :P
[19:52]  * yofel files a bug and leaves the discussion for UDS
[19:53] <apachelogger> which reminds me
[19:53] <apachelogger> rbelem: I submitted the harmattan app to nokia store, see what they have to say about it
[19:53] <rbelem> apachelogger, nice :-)
[19:54] <apachelogger> if it is good I'll try to squeeze symbian in too
[19:54] <apachelogger> also Quintasan still needs to make the android ui
[19:54] <apachelogger> or maybe shadeslayer
[19:55] <rbelem> apachelogger, could it be the same ui?
[19:56] <apachelogger> structure wise, yes, for android2 anyway
[19:56] <apachelogger> android2 also has a page like navigation system inside apps
[19:56] <apachelogger> BUT we'd need new components for android
[19:56] <apachelogger> we can't simply copy the harmattan or symbian components unfortunately
[19:57] <apachelogger> though doing android components (from a non-UI) pov is not too complicated
[19:57] <apachelogger> copy the page stack impl from harmattan components and you are half way done
[19:58] <apachelogger> IIRC qtandroid even has screen size and rotation hinting implemented
[19:58] <Quintasan> derrpt
[19:58]  * Quintasan wonders how many dollarz should he take
[19:59] <apachelogger> 200 should be more than enough
[19:59] <apachelogger> unless you wanna go buy disney swag :P
[19:59] <Quintasan> Nah, I'll take 300 in case I see some hardware I want
[19:59] <Quintasan> or some other stuff
[19:59] <jjesse> you going to buy a phone or something while in US?
[20:00] <apachelogger> Quintasan: unlikely you have time to go shopping :P
[20:00] <rbelem> apachelogger, i saw an app that was published in android market and nokia store
[20:00] <apachelogger> anyhow... they have ATMs in the US ;)
[20:00] <rbelem> built in qt
[20:00] <rbelem> apachelogger, do you know about this app?
[20:01] <apachelogger> I read about it, but I forgot what it was
[20:01] <apachelogger> but IIRC it did not have a 'platform' ui but a highly themed artwork based one
[20:01] <rbelem> maybe its source would be helpful
[20:01] <apachelogger> if it is floss ;)
[20:01] <rbelem> it is
[20:01] <rbelem> let me check the name
[20:02] <Quintasan> rbelem: You are coming to UDS?
[20:02] <rbelem> Quintasan, yup
[20:03] <Quintasan> rbelem: Great
[20:03] <apachelogger> Quintasan: yeah, and he will whip your booty hard if you don't get started on the android ui
[20:03] <Quintasan> I told you I ain't doing it
[20:04] <Quintasan> Let us have sheytan design something
[20:04] <apachelogger> how does that help coding?
[20:04] <apachelogger> plus rbelem has someone already on it
[20:04] <apachelogger> or so he claimed, I have yet to see results :P
[20:04] <Quintasan> Problem solved
[20:05] <rbelem> i will poke the designers again here
[20:05] <Quintasan> apachelogger: Would it be possible to port my QTrollface to androidz?
[20:06]  * apachelogger would poke his designers, but they don't seem to be approachable much ^^
[20:06] <Quintasan> WITH the memleak feature of coursse
[20:07] <Quintasan> Oh well, going to bed
[20:08] <yofel> nini Quintasan
[20:27] <rbelem> apachelogger, here is the post http://tamss60.tamoggemon.com/2011/10/11/first-android-meego-symbian-qt-app-released-to-stores/
[20:29] <afiestas> Quintasan: you're still under 21, right?
[20:29] <afiestas> Mueheheh
[20:31] <rbelem> afiestas, apachelogger, an app that i've been working http://a5.sphotos.ak.fbcdn.net/hphotos-ak-ash4/313313_10150354902107017_529232016_8435036_234663579_n.jpg
[20:31] <rbelem> it was presented today night
[20:32] <rbelem> in the party of qt dev days
[20:32] <rbelem> :-D
[20:32] <rbelem> Quintasan, hahaha you cannot drink :-D
[20:39] <afiestas> rbelem: ready for our week of hacking in "All sharing stuff" ?
[20:39] <afiestas> you better be :p
[20:44] <rbelem> afiestas, i'm ready ya ;-)
[20:44] <rbelem> :-D
[20:44] <afiestas> rbelem: :p
[20:45] <rbelem> afiestas, bring it on
[20:45] <rbelem> :-D
[20:46] <rbelem> street fighters talks
[20:46] <afiestas> xd
[21:00] <apachelogger> rbelem: is jukebox open? :P
[21:04] <rbelem> apachelogger, yup
[21:04] <rbelem> apachelogger, the source will be released soon :-D
[21:04] <apachelogger> woohooo
[21:04] <apachelogger> awesome
[21:04]  * apachelogger hugs rbelem
[21:05] <rbelem> apachelogger, like chicken wranglers
[21:05]  * apachelogger totally failed when trying to get hold of the n9 browser code :P
[21:05]  * rbelem hugs back apachelogger
[21:05]  * apachelogger has a total code fetish
[21:06] <rbelem> apachelogger, do you know if they released the code?
[21:06] <apachelogger> they haven't
[21:07] <apachelogger> I wasn't even able to find out who would be responsible for that at this point *shrug*