[01:27] <Fujitsu> Has anybody else noticed the return of normal window open/close effects to Firefox form autocomplete and AwesomeBar, after installing Fx3b5?
[01:41] <bddebian> Heya gang
[01:43] <ScottK2> Heya bddebian
[01:43] <bddebian> Hi ScottK2
[02:15] <jdong> asac: do you know if the window class for the address-bar drop-down completion window thingie changed between ff3 b4 -> b5?
[02:15] <jdong> asac: because now with b5, compiz in Gutsy does this annoying transition-in effect as if it were a full window
[02:16] <Fujitsu> jdong: Aha, so it's not just me.
[02:17] <Fujitsu> It's not just the awesomebar, it's also the suggestions for form entries.
[02:18] <asac> jdong: i don't think it changed
[02:18] <asac> its always been a full window :)
[02:18] <Fujitsu> The behaviour has certainly changed within the last 12 hours.
[02:19] <jdong> Fujitsu: confirmed, form suggestion windows do the same
[02:19] <jdong> asac: well something regressed, because this didn't happen with the b4 packages
[02:19] <jdong> asac: whether it's the fault of Firefox or some compiz quirking heuristic is less clear
[02:20] <Fujitsu> It's a change in Firefox and not in Compiz or anything else, as Firefox is all I've restarted since I upgraded.
[02:20] <asac> jdong: trey downgrading ffox
[02:20] <jdong> asac: this is a test backport to gutsy, that's the only thing that has chagned on my system in the past 3 hours, so I'm 100% confident it was not caused by any other package changing
[02:21] <Fujitsu> As am I.
[02:23] <jdong> asac: looks like bug 212600 has been reported
[02:23] <ubotu> Launchpad bug 212600 in firefox-3.0 "Location bar dropdown is animated with Compiz Glide effects in Beta 5" [Undecided,New] https://launchpad.net/bugs/212600
[02:27] <asac> jdong: mozilla bug 412954
[02:27] <ubotu> Mozilla bug 412954 in Widget: Gtk "menus should have Menu, PopupMenu or DropdownMenu window type" [Trivial,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=412954
[02:27] <asac> thats what landed and looks related
[02:28] <Fujitsu> Let me guess... it broke the Firefox quirk thing in Compiz?
[02:28] <asac> jdong: maybe try if reverting that patch helps
[02:28] <asac> maybe ;)
[02:29] <asac> Fujitsu: before that patch we had: -            // treat popups with a parent as top level windows
[02:29] <asac> gtk_window_set_wmclass(GTK_WINDOW(mShell), "Toplevel", cBrand.get());
[02:29] <asac> now everything is:
[02:29] <asac> gtk_window_set_wmclass(GTK_WINDOW(mShell), "Popup", cBrand.get());
[02:29] <asac> with proper hints
[02:29] <asac> https://bugzilla.mozilla.org/attachment.cgi?id=305729
[02:30] <jdong> asac: yeah it seems like that patch caused the problem, but I'm not 100% convinced at what's the best fix, reverting this or tweaking our compiz rules
[02:30] <Fujitsu> Turning off the workarounds doesn't fix it :(
[02:30] <Fujitsu> Why not make Firefox use GTK properly? Or would that make too much sense?
[02:30] <asac> Fujitsu: that doesn't make sense
[02:30] <asac> Fujitsu: they already do it properly
[02:31] <asac> on a best efford base
[02:31] <asac> jdong: tweaking the compiz rules
[02:31] <asac> now everything is vmclass "popup"
[02:31] <asac> wmclass
[02:31] <asac> so now firefox is correct
[02:33] <asac> i added compiz and invalidated firefox task until we know that its firefox
[02:33] <jdong> I think asac is right
[02:33] <jdong> based on comment #27 on the mozilla bugzilla
[02:36] <asac> jdong: please add that reference to the bug so the compiz people see it
[02:36] <asac> e.g. link to that comment
[02:38] <Fujitsu> There's a bug on -plugins-main with the patch attached.
[02:38] <Fujitsu> #212600 should probably be marked as a dupe.
[02:39] <asac> Fujitsu: please ensure that the same info goes to that bug then
[02:39] <asac> and take care that its milestoned
[02:39] <asac> i guess that should be fixed for release
[02:40] <Fujitsu> Milestoned, duped, appropriate information moved over to #212542.
[02:54] <jdong> asac: would you mind if I, for the possible gutsy backport of beta5, back out this patch, as trying to fix compiz in both gutsy and gutsy-backports doesn't sound like fun?
[02:56] <asac> jdong: no ... i won't backout that from hardy because of gutsy. do you have a bzr branch for gutsy based on our .dev branch?
[02:56] <asac> we should do it there for gutsy i guess
[02:57] <jdong> asac: no, I don't have a gutsy bzr branch set up based on the .dev's ancestry... I do use bzr locally to track the changes in the packaging and it'd probably be prudent for me to graft that onto a proper bzr branch :)
[02:58] <asac> jdong: please base it on the .dev branch
[02:58] <jdong> will do
[02:58] <asac> should be easy to merge down on every release then
[02:59] <jdong> right
[02:59] <asac> .dev will become .hardy once that is stable
[02:59] <asac> (released)
[02:59] <asac> but will be just a rename i guess
[03:03] <asac> ok scrapbook is done
[03:06] <asac> oops wrong channel :)
[03:11] <jdong> :)
[03:11] <jdong> asac: mmmkay, pushed up backports changes rebased against .dev to LP :)
[03:18] <asac> cool
[03:18] <asac> rebased?
[03:18] <asac> using bzr rebase?
[03:18] <asac> jdong: ?
[03:18] <emgent> heya people :)
[03:19] <jdong> asac: nah I didn't go that fancy, I just lumped it all up into one commit
[03:19] <asac> ;)
[03:19] <jdong> asac: some embarassing mistakes best not see the light of day ;-)
[03:19] <asac> yeah
[03:19] <asac> i know what you mean
[03:20] <jdong> yeah in general xulrunner was quite cooperative with backporting (fortunately), but firefox-3.0 took me at least 5 rounds to get right per release
[03:20] <jdong> though that nspr/nss typo did cause a xulrunner build to fail at the very last step :D
[03:20]  * jdong shakes fist
[03:23] <asac> what was the problem with ffox?
[03:24] <asac> we try to be as cooperative as possible. if there are glitches, we want to know about that ;)
[03:24] <asac> suggestions welcome :)
[03:27] <jdong> asac: well I have to back out the changes that make firefox 3.0 the default firefox, and the process of doing so always seems to be trial-and-error
[03:27] <jdong> asac: not your fault in any way :)
[03:28] <jdong> is there a command to invert a patch or do I have to patch -R then diff?
[03:29] <asac> jdong: you can drop the patch from series?
[03:29] <asac> or do you mean something else?
[03:29] <jdong> asac: well I'm referring to the firefox window toolbar patch from bugzilla
[03:30] <asac> hmm
[03:31] <jdong> nvm I'll just hand-do it. The inverse of that patch is more intrusive than necessary to restore old behavior anyway
[03:31] <asac> maybe flipdiff using an empty patch as second argument :)
[03:31] <asac> great
[03:32] <jdong> but I do like the creativity of that approach :D
[03:32] <asac> should be simple to do when using quilt ;)
[03:32] <jdong> yay, I love quilt..... ;-)
[03:32] <asac> welcome ;)
[03:43] <jdong> grr *whine* this code is in xulrunner?
[04:44] <ashes_of_youth> can anyone offer me some advice regarding a broken translation?
[04:50] <ashes_of_youth> hello
[04:52] <ScottK2> ashes_of_youth: I'd suggest ask in #ubuntu-doc
[05:13] <AnAnt> ScottK2: Hello, I just made another upload: http://revu.tauware.de/details.py?package=ubuntume-themes
[05:14] <ScottK2> AnAnt: Looking
[05:15] <AnAnt> ScottK2: btw, I see usplash theme is on Ubuntu's repos now ! Thanks!
[05:16] <ScottK2> AnAnt: You're welcome.
[05:19] <ScottK2> AnAnt: Is the bug this fixes reported in Launchpad?
[05:20] <AnAnt> nope
[05:20] <AnAnt> that's why there isn't a Closes: # in changelog
[05:20] <ScottK2> OK.  Just checking.
[05:20] <ScottK2> Also there are other changes you made that need to be documented.
[05:21] <AnAnt> moving x11-apps to Build-Depends-Indep: ?
[05:21] <ScottK2> Yes and the changes in the package description.
[05:21] <AnAnt> Ok, didn't know that they were worth mentioning
[05:22] <ScottK2> After the initial upload they all need to be mentioned.
[05:22] <ScottK2> People need to be able to recontruct from the changelog not only what was done, but why (if it's not obvious).
[05:23] <ScottK2> AnAnt: If you would re-upload to REVU with a more verbose changelog, then I think I could upload it.
[05:24] <AnAnt> so I should mention why I changed long description ?
[05:24] <ScottK2> For that it's enough to say minor edits in the package description.
[05:29] <AnAnt> uploaded
[05:30] <ScottK2> AnAnt: OK.  There's a cron job that needs to run that goes on a ten minute periodic before I see it.
[05:30] <AnAnt> ok, rebooting
[05:35] <null_vector> i'm trying to package flam3 and convert it to 3 packages, executables, so and dev.  are there any resources or examples I could look at to figure out hows to go about this?
[05:35] <jdong> ScottK2: did you have a chance to look at the ff3 backport yet?
[05:37] <AnAnt> ScottK2: ok, it appears on REVU now
[05:39] <ScottK2> AnAnt: Looking
[05:44]  * jdong does some backports triaging
[05:45] <ScottK2> AnAnt: Uploaded
[05:50] <AnAnt> ScottK2: thanks
[05:51] <ScottK2> AnAnt: Thank you for making the extra effort to work through the official archives.
[05:51] <ScottK2> jdong: I'm looking at it now.
[05:51] <jdong> ScottK2: thanks :)
[05:52] <ScottK2> jdong: What xulrunner am I supposed to backport?
[05:53] <jdong> ScottK2: this one: http://jdong.mit.edu/~jdong/motu/ff-backport/beta4/xulrunner-1.9_1.9~b4+nobinonly-0ubuntu1~gutsy1.dsc
[05:53] <jdong> and corresponding firefox: http://jdong.mit.edu/~jdong/motu/ff-backport/beta4/firefox-3.0_3.0~b4+nobinonly-0ubuntu1~gutsy1.dsc
[05:53] <ScottK2> Figured out the problem.
[05:53] <ScottK2> I have the wrong xulrunner.
[05:54] <jdong> ah
[05:54] <ScottK2> I had xulrunner, not xulrunner-1.9
[05:54] <jdong> yeah, that'll do it :)
[05:54] <jdong> that's extreme backporting! :)
[06:00] <ScottK2> jdong: Should we mangle the maintainer?
[06:00] <ScottK2> Nevermind
[06:02] <jdong> ScottK2: I don't think it'd be necessary. Plus, spamming asac with bug reports might be fun ;-)
[06:02] <ScottK2> Yeah.
[06:03] <ScottK2> jdong: You've tested these are all good and I'm just your mule on this.  Right?
[06:03] <jdong> ScottK2: yes, it's all tested for several weeks and known good :)
[06:03] <ScottK2> OK.
[06:04] <jdong> ScottK2: we can play this game with beta5 again in around two weeks :D
[06:08] <ScottK2> jdong: Uploaded.  If you'd please do that Launchpad update.
[06:09] <jdong> ScottK2: awesome
[06:09] <ScottK2> jdong: Now how about wine?
[06:09] <ScottK2> Is the current version good to go back?
[06:10] <jdong> ScottK2: I've been running 0.9.57, not 0.9.58, but that's on my TODO list to look at
[06:10] <jdong> for tonight
[06:10] <ScottK2> Great.
[06:10] <jdong> I'm first going through the obvious/trivial backports that are already confirmed, then I'll take a look at wine and finish this SRU I promised
[06:23] <jdong> stupid Debian question, does Debian keep old revisions of their packages somewhere?
[06:28] <Fujitsu> snapshot.debian.net
[06:34] <jdong> thanks!
[06:34] <jdong> it would also help if I look for the patch in the right version of the package :D
[10:20] <Iulian> G'morning.
[14:15] <james_w> siretart: I don't know if you have seen this: http://patches.ubuntu.com/b/boxbackup/boxbackup_0.10+really0.10-1ubuntu3.patch
[14:26] <ScottK2> Dear jdong: Please have a look at Bug #211910 and let us know what you think.
[14:26] <ubotu> Launchpad bug 211910 in rtorrent "[FFe] request for new upstream version " [Wishlist,New] https://launchpad.net/bugs/211910
[14:28] <ScottK2> jdong: Shouldn't the wine bug for gutsy-backports be set to In Progress?
[14:43] <protonchris> ScottK2: If you have time today, could you look at Bug 212301 and sponsor an upload?
[14:43] <ubotu> Launchpad bug 212301 in glom "Please update glom to newest version (1.6.13)" [Undecided,New] https://launchpad.net/bugs/212301
[15:32] <Hobbsee> ScottK2: ping
[15:33] <Hobbsee> ScottK2: what do i need to know about the release stuff, apart from the info gained from having read the emails to the list?
[15:33] <Laney> james_w: I finally got round to emailing the ML ;)
[15:43] <james_w> Laney: ah, thanks.
[15:43] <Laney> No probs. I suddenly realised on the way back from campus that I'd not done it yet
[15:50] <siretart> james_w: oh, no thanks for the hint!
[15:50] <siretart> err, insert a '.' at the appropriate place :)
[15:55] <james_w> :-)
[15:55] <james_w> siretart: you don't want a bug with the patch in Debian?
[15:57] <protonchris> ScottK2: nevermind.  Looks like RainCT_ is taking a look.
[16:17] <siretart> james_w: if want and have the time, please do. I'll try to think about it when I do the next upload of boxbackup. btw, do you use boxbackup yourself?
[16:21] <jdong> s/sb end
[16:22] <jdong> ScottK2: (!) Yeah, I did forget to change the status in wine; fixed. (2) I talked to sistpoty about rtorrent the other day, I think it's a good candidate for FFe
[16:28] <ScottK2> jdong: Please mark it in the bug.
[16:29] <ScottK2> Hobbsee: Pong: I don't think anything.
[16:29] <Hobbsee> ScottK2: good, OK
[16:30] <protonchris> RainCT: thanks for sponsoring glom
[16:30] <RainCT> protonchris: no problem, thanks for working on it :)
[16:31] <RainCT> protonchris: (if you are wondering why you haven't got the mail yet, that's because the .orig.tar.gz is still being uploaded :P)
[16:31] <protonchris> RainCT: ah thanks.  Yeah I was waiting.  I wanted to see the additional changes you added.
[16:32] <protonchris> RainCT: any advice?
[16:32] <ScottK2> protonchris: It's better to have someone sponsoring you that does not, on a grumpy day, consider breaking Gnome a feature.
[16:32] <protonchris> ScottK2: LOL.  Good to know.
[16:33] <ScottK2> Actually it's mostly just Mono I consider breaking a feature, but the two go together just a little.
[16:36] <RainCT> protonchris: the changes are just that debian/copyright only mentioned GPL2 but the source files say "2 or later" so I replaced that with the full GPL header as it is there (in the source), and that there was a ". Homepage:" left in glom's description
[16:36] <protonchris> RainCT: great thanks.
[16:37] <RainCT> ScottK2: heh, what happened?
[16:37] <ScottK2> RainCT: Nothing, just don't like Mono.
[16:37] <RainCT> ah, lol
[16:42]  * jdong looks at cherrypicking clutchbt....
[16:43] <megabyte405> Does anyone know of a good resource on the accepted way to build a single source package from what are several upstream tarballs?
[16:48] <jdong> megabyte405: I'd suggest grouping all of them into a single orig.tar.gz, if it's a good idea to group them together in the first place.
[16:49] <megabyte405> that's what I was planning on doing. They untar into program-version, program-plugins-version, and so on, where version is all the same and the same as the "orig" version - is there a variable I can use so I don't have to rename the untarred folders?
[16:58] <james_w> siretart: sure, I'll file one.
[16:58] <james_w> siretart: I don't use it, I was just looking at the diff.
[16:58] <james_w> siretart: I used to work with one of the developers though.
[17:47] <ScottK2> jdong: Please say something nice in Bug #211910 and then I'll approve it.
[17:47] <ubotu> Launchpad bug 211910 in rtorrent "[FFe] request for new upstream version " [Wishlist,New] https://launchpad.net/bugs/211910
[17:47] <jdong> ScottK2: I thought I already was quoted in that?
[17:48] <ScottK2> jdong: You were, but I'd like to have a "No, really, we want this" that comes after the last comment.
[17:49] <jdong> ScottK2: ok :)
[17:49] <ScottK2> Thanks
[17:50] <jdong> ScottK2: done :)
[17:50] <ScottK2> Thanks
[17:55] <ScottK2> jdong: Approved, so some motu might want to look at sponsoring the changes ...
[17:56] <jdong> ooh I haven't hit the upload button in a while :)
[17:56] <jdong> ack so that's why Firefox is crashing
[17:57]  * jdong notes that flashplugin gets very very upset when it's not allowed to write to ~/.macromedia
[17:58] <ScottK2> pochu: Are you worrying after screenlets?
[17:58] <ScottK2> pochu: It looks like it needs some grabbing of patches from the upstream bzr.
[17:59] <jdong> ScottK2: I feel blind.... is the debdiff/interdiff/diff.gz even on the bug report?
[18:01] <ScottK2> jdong: It's not.  I had a brain dump about the requestor being a MOTU.  I'm sure he'll upload it.
[18:01] <jdong> ah ok
[18:01] <jdong> excellent
[18:01] <pochu> ScottK2: I'm not, and I'm busy...
[18:02] <ScottK2> OK.
[18:02] <pochu> (and I'm not here)
[18:02] <ScottK2> jdong: Care at all about screenlets?  That needs some uploading by someone who cares about Gnome.
[18:02] <jdong> ScottK2: I don't know what it does, if that says anything :)
[18:02] <ScottK2> Heh.
[18:02] <ScottK2> OK.
[18:03] <slytherin> jdong: something like dashboard widgets in OS X
[18:03] <ScottK2> There we go.  A volunteer...
[18:03] <slytherin> ScottK2: Are you one of the build admins who can promote a package to main?
[18:03] <ScottK2> slytherin: No.
[18:04] <ScottK2> Promotions are done via Main Inclusion Report.  You can file one.
[18:04] <slytherin> ScottK2: No the package is in main for i386 and amd64 already. It is not for powerpc
[18:05] <ScottK2> slytherin: Ah.  You'll want to discuss that with pitti then on Monday probably.
[18:05] <ScottK2> slytherin: Do you have any interest in screenlets?
[18:06] <slytherin> ScottK2: Ok. As suggested by Hobbsee I have already filed a bug. I will talk with pitti tomorrow. The problem is that f-spot has depwait due to this.
[18:06] <cody-somerville> Whats the difference between screenlets and desklets?
[18:06] <slytherin> ScottK2: I have just used them once.
[18:06] <ScottK2> Dunno.  I mostly see a lot of bugs being filed and upstream commenting which bzr commit fixes the bug.
[18:06] <ScottK2> I was hoping someone like slytherin might go through them and pull the patches in.
[18:07] <slytherin> ScottK2: Any specific bug?
[18:09] <ScottK2> slytherin: Bug 197712 Bug 212175 Bug 198675 Bug 195036 Bug 205526 and probably more.
[18:09] <ubotu> Launchpad bug 197712 in screenlets "ACPIBatteryScreenlet.py crashed with OSError in __create_tempfile()" [Medium,Confirmed] https://launchpad.net/bugs/197712
[18:09] <ubotu> Launchpad bug 212175 in screenlets "VolumeControlScreenlet.py crashed with IOError in __create_tempfile()" [Undecided,Fix committed] https://launchpad.net/bugs/212175
[18:09] <ubotu> Launchpad bug 198675 in screenlets "SensorsScreenlet.py crashed with TypeError in update()" [Undecided,Fix committed] https://launchpad.net/bugs/198675
[18:09] <ubotu> Launchpad bug 195036 in screenlets "MainMenuScreenlet.py crashed with TypeError in __render_cell()" [Undecided,Fix committed] https://launchpad.net/bugs/195036
[18:09] <ubotu> Launchpad bug 205526 in screenlets "screenlets-manager.py crashed with UnboundLocalError in get_info_from_package_name()" [Undecided,Fix committed] https://launchpad.net/bugs/205526
[18:09] <absoluteuri> Hi, new here, trying to help. I see https://wiki.ubuntu.com/MOTU/TODO#WeeklyTasks the first one (#106244) the last entry was 2007-07-29...I thought that list gets reset weekly? Is this still an active bug?
[18:10] <ScottK2> Bug 106244
[18:10] <ubotu> Launchpad bug 106244 in mysql-dfsg-5.0 "CONF Variable in /etc/init.d/mysql unused - support for multiple instance/version of mysql" [Wishlist,In progress] https://launchpad.net/bugs/106244
[18:10] <ScottK2> Looks like, but it's also a package in Main, so I'm not sure what it's doing on the MOTU list.
[18:11] <absoluteuri> OK, not sure where to begin with helping
[18:11] <ScottK2> absoluteuri: One area that needs work is to see if there are critical bug fixes in Debian that we don't have.  See http://qa.ubuntuwire.com/bugs/rcbugs/
[18:12] <absoluteuri> 'approx' is Ubuntu V 3.0.0 but Debian 3.1.0 so this means that the fixes in 3.1.0 need to be ported to the ubuntu 3.0?
[18:13] <sebner> ScottK: you are wise. very wise
[18:13] <sebner> ScottK2: same message -> you are wise. very wise
[18:14] <slytherin> ScottK2: how about we package screenlets 0.1?
[18:24] <protonchris> For critical debian bug fixes, is it preferred to try and patch the ubuntu version or sync the new package version?
[18:24] <james_w> protonchris: it depends how much else is changed in the new Debian version.
[18:25] <james_w> if its only the bug fix then sync, otherwise it is your call.
[18:27] <protonchris> I noticed that sebner has marked the list with the ones he is working on.  Is it possible for me to do the same?
[18:27] <sebner> protonchris: sure
[18:28] <protonchris> Thanks.  I wanted to make sure I wouldn't be overstepping my bounds.
[18:42] <mok0> sebner?
[18:42] <sebner> mok0: yes?
[18:43] <mok0> I was just wondering:
[18:44] <mok0> you filed a whole bunch of sync requests. Have you cleared it with the release team?
[18:45] <sebner> mok0: these are normal syncs and we have the 6th april. so I don't need a release team!?
[18:45] <sebner> *the
[18:45] <mok0> sebner: not if there are no new features
[18:45] <sebner> mok0: there are now features ;) I checked it. But you are invited to check and give an ACK ;)
[18:46] <sebner> *no new feautres
[18:46] <sebner> *feature -.-
[18:46] <mok0> sebner: ah :-)
[18:46] <mok0> sebner: I am not in the release team though
[18:46] <sebner> mok0: MOTU ACK is enough ;)
[18:47] <mok0> sebner: he, yes, I can assign them to the archive admin
[18:47] <sebner> mok0: please check it before ;)
[18:47] <sebner> mok0: doesn't seem to are familiar with u-u-s?
[18:48] <mok0> sebner: not really :-)
[18:48] <sebner> ^^
[18:49] <sebner> mok0: If you want to 1) check if my syncs requests are really *normal* syncs" 2) give a comment with "ACK" 3) subscibe the archive admins
[18:49] <mok0> sebner: I will go through some of them, going for dinner soon
[18:49] <sebner> mok0: thanks so much :)
[18:49] <mok0> sebner: right
[18:50] <mok0> sebner: are those bugs from the rcbugs page?
[18:50] <sebner> mok0: about 90%
[18:50] <mok0> sebner: great
[18:50] <sebner> :D
[19:13] <^linux26> I was thinking about packaging the Bullet Physics engine (v2.67, http://www.bulletphysics.com/) and the Horde3D graphics engine (v0.5.0, http://www.nextgen-engine.net/). Do you have any suggestions or I can start packaging right away?
[19:14] <ScottK> Check and make sure neither are in Debian already or have Debian ITP bugs indicating someone else is already working on them.
[19:14] <RainCT> ^linux26: just remember that it's to late to get it into Hardy now
[19:15] <^linux26> RainCT: sure, the feature freeze
[19:15] <^linux26> ScottK: okay I'll do that
[19:17] <sebner> mok0: your comments are unusual and interesting. rock on :D
[19:17] <mok0> sebner: unusual?
[19:17] <mok0> :)
[19:18] <sebner> mok0: normally they just right "ACK" or "Sync request ACK". Normally it doesn't matter how important it is. but your comments are nice ^^
[19:18] <sebner> *write -.-
[19:18] <mok0> sebner: Perhaps I will get sloppier with time
[19:19] <sebner> mok0: would be a pitty :)
[19:20] <mok0> :-D
[19:20] <mok0> Dinner!!!
[19:20] <sebner> hf
[19:25] <^linux26> It appears that Blender3D uses the Bullet Physics engine - but there is no 'bullet' package in debian/ubuntu; looks like the library is embedded in the package
[19:35] <^linux26> ScottK: looks like no-one ever packaged the Bullet Physics engine or the Horde3D graphics engine yet
[19:36] <emgent> hi people
[20:04] <cody-somerville> StevenK, ping
[20:09] <emgent> hey cody-somerville :)
[20:10] <cody-somerville> Heya emgent :)
[20:40] <JohnPinWa> Hello.  I'm looking for ways to contribute to Ubuntu as a developer.  I'm reading the "How to get involved" web pages but can't find the "Do this step next" instructions.  Who do I tell I'm here and ask how I can help?
[20:41] <mok0> ! packaging
[20:41] <ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[20:43] <mok0> JohnPinWa: or if you want to chase bugs: https://wiki.ubuntu.com/Bugs/HowToFix
[20:44] <mok0> and ... ! bugs
[20:44] <mok0> !bugs
[20:44] <ubotu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
[20:44] <JohnPinWa> I've been using Linux and Ubuntu for a while but should probably start on the basics.  What's "ground level" grunt work in this outfit?
[20:45] <mok0> JohnPinWa: Finding and reporting bugs -- i.e. stress testing of programs -- is very useful and you will learn finding your way around Launchpad
[20:46] <mok0> JohnPinWa: another task is triaging bugs, i.e. see if you can reproduce them, and supply additional information to the bug report
[20:46] <JohnPinWa> MokO: Launchpad is really stumping me at this point.  I see what I see but can't figure out how to DO anything with it.  Probably a good place to start huh?
[20:47] <mok0> JohnPinWa: yeah. It is pretty stumping, but once you get to know it, it's a pretty powerful tool. It's what Ubuntu is using anyway
[20:48] <Iulian> JohnPinWa: https://edge.launchpad.net/+about will give you an idea of what launchpad is and what it can do.
[20:49] <JohnPinWa> For the record: It's me that's ignorant of launchpad.  Wasn't saying launchpad was the problem.
[20:49] <JohnPinWa> I'll take a look Iulian.
[20:49] <nand> JohnPinWa: I have a few PHP tasks for Brainstorm if you want...
[20:50] <mok0> ... but est. 90% of users only use the "Bugs" feature, or perhaps ask and/or answer questions in "Answers"
[20:50] <JohnPinWa> I don't know diddly about PHP.  Python, bash, and a few other scripting/special purpose languages.  I'd love for this to wind up with me working with C.
[20:51] <nand> too bad :)
[20:51] <RainCT> nand: i'm curious, what are those tasks?
[20:51] <mok0> JohnPinWa: You mean you know Python, bash, etc., but not PHP?
[20:52] <JohnPinWa> Yep.  PHP just looked ugly.  Never got interested.
[20:52] <nand> RainCT: one of those: http://www.ndeschildre.net/brainstorm-todo-list/
[20:52] <JohnPinWa> Dang near as bad as perl.
[20:53] <mok0> JohnPinWa: Python is installed a bit differently in Ubuntu than intended by Guido et al. You may want to read up on that
[20:53] <nand> that's quite a lot of tasks, from easy to hard ones
[20:55] <JohnPinWa> Mok0: yeah, that's inherited from Debian I think.  I used to watch that mailing list and the discussion on it was endless.
[20:56]  * Iulian is going to sleep - g'night.
[20:57] <mok0> JohnPinWa: It has been settled mostly
[20:58] <JohnPinWa> mok0: it should be by know but settled "Debian style" which may not have been "Python style".  Still, I've never had a problem with python on Ubuntu.
[20:59] <mok0> JohnPinWa: Basically, the distribution needs to allow for several versions of Python installed simultaneously, which is not the focus of Guido et al
[20:59] <JohnPinWa> mok0: Well I can see that makes sense from both points of view.
[21:00] <mok0> JohnPinWa: but python-central is the preferred tool being used now, it takes care of all the grunt work (e.g. byte-compiling for all the different versions)
[21:06] <warp10> Hi all!
[21:16] <linux26> I have a big upstream tarball (Horde3D SDK) which contains a library and demos and data for the demos. How can I split it into several deb packages?
[21:30] <RainCT> linux26: install the stuff into a temp directory (usually debian/tmp/) and from there move it into the different packages (with *.install files for example)
[21:31] <linux26> RainCT: I'll look that up, thanks
[22:02] <jdong> haha, jdong's lazy crack of the day: cached rmadison dependency checker
[22:02] <jdong> a python script using a sqlite-cached rmadison backend to parse build-deps and check em against various Ubuntu distros
[22:02] <jdong> for those extra lazy and impatient backporting days :D
[22:13] <null_vector> I'm trying to package flam3 and I'm getting the shouldn't be linked with errors from dpkg-shlibdeps but I can't find how those libs are being included in the first place.
[22:13] <null_vector> It's an autotools/libtool package.  Any suggestions?
[22:22] <mok0> null_vector: you can ignore those errors
[22:23] <mok0> null_vector: they appear when you build shared libraries
[22:27] <null_vector> I'm splitting the package into lib / executable packages though and getting those warnings for the executables though
[22:27] <null_vector> That was almost a coherent sentence.
[22:36] <mok0> null_vector: you can safely ignore them
[22:44] <null_vector> thanks
[22:49] <RainCT> good night
[23:01] <JohnPinWa> When someone offers mentoring in Launchpad how do you contact him/her to let them know you'd like to learn about it?
[23:04] <ScottK2> I'd suggest commenting in the bug about what you'd plan to do and what questions you have and see if they react.
[23:07] <JohnPinWa> ScottK2:  Okay.  Now how do I "comment in a bug"?  Seriously I've spent the day wandering from wiki page to wikipage trying to figure out how to get started.  No joy.
[23:07] <ScottK2> JohnPinWa: What bug?
[23:08] <JohnPinWa> On this website: https://launchpad.net/%7Ebugsquad/+mentoring
[23:09] <JohnPinWa> There are a list of bugs that people are available to mentor on.  I'd love to learn how to start helping but I'm stuck.
[23:10] <persia> JohnPinWa: For bugsquad-mentored bugs, you likely want #ubuntu-bugs, as the process is a little different.
[23:10] <JohnPinWa> I've joined mailing lists as well.  Perhaps I should give a shout out there?
[23:10] <persia> JohnPinWa: For those, I'd recommend asking for help with the bug in IRC.
[23:10] <JohnPinWa> Yeah, I asked there a while back.  No response.
[23:10] <ScottK2> Actually I need to go, so hopefully someone else will help you out.
[23:10] <JohnPinWa> Persia: thanks.
[23:10] <JohnPinWa> ScottK2: thanks.
[23:11] <persia> JohnPinWa: Maybe just a bad time of day :(
[23:11] <JohnPinWa> yeah.  Or I'm spectacularly dense.  Not an option I ever dismiss lightly.
[23:12] <JohnPinWa> I'll keep plugging.  Something will give.  Not sure if this is for me but I'm sure I want to find out.
[23:12] <james_w> JohnPinWa: I don't think so. Is there a bug you would particularly like to work on?
[23:15] <james_w> JohnPinWa: also, those bugs won't be the simplest ones. It looks they are ones that would take a bit of work, but someone would be willing to give you pointers.
[23:15] <james_w> there are a load of bugs that would be quite easy, and that people would be willing to help you with, but mentoring hasn't been offered for them.
[23:30] <JohnPinWa> james_w: Thank you.  perisa just walked me through a bit in the bugs channel.  And there's a hug day coming up Tuesday.  I'll just hang around pestering people until I get my feet on the ground.
[23:33] <mok0> Just a quick procedure question: how do I upload a package that someone else has signed off in debian/changelog
[23:33] <mok0> should I just sign the changes file?
[23:34] <mok0> ... or specify my own keyid
[23:34] <Fujitsu> mok0: debuild -S -k<yourkeyid>
[23:35] <Fujitsu> or just debsign -k<yourkeyid> existing_source.changes
[23:35] <Fujitsu> But you should be building the .changes yourself anyway, so the former should be easier.
[23:35] <mok0> Fujitsu: thx! No "-sa" switch?
[23:35] <Fujitsu> -sa if you need it.
[23:36] <Fujitsu> But that shouldn't be needed much, particularly now we're well past FF.
[23:36] <mok0> Fujitsu: which is..  when the tar.gz is already in the archive?
[23:36] <Fujitsu> -sa is when the .tar.gz isn't in the archive.
[23:36] <Fujitsu> It doesn't hurt to upload it again, but it's a waste of time.
[23:36] <mok0> Fujitsu: got it, thx
[23:38] <soren> Fujitsu: Why should he be building the .changes himself?
[23:39] <persia> mok0: In the case where the package has multiple new changelog entries (e.g. merges), don't forget the -v to debuild.
[23:39] <mok0> persia: ok, but this one doesn't.
[23:40] <mok0> soren: because I need to upload a diff.gz also
[23:40] <persia> soren: Verification and review?  The typical sponsoring model is to receive a debdiff, apply it, and build the .changes.
[23:40] <soren> If someone has provided you with a .changes file, they will also have provided you with a diff.gz.
[23:41] <soren> persia: I'm perfectly happy to accept a signed .changes and diff.gz and do my review from that, and if it's good, resign just the .changes file and upload.
[23:41] <mok0> soren: I got a debdiff from LP; I want to build and upload the source package
[23:41] <soren> I think that's a good workflow.
[23:41] <soren> mok0: Ok, got it.
[23:42] <Fujitsu> It's a lot easier to review the debdiff than review the debdiff, .dsc and .changes.
[23:42] <persia> soren: I guess.  I prefer to see things in LP for documentary purposes, and think more than a debdiff is typically wasteful of librarian storage.
[23:42] <Fujitsu> As neither of the last two are trustworthy.
[23:43] <soren> Fujitsu: It's either one or the other.
[23:43]  * persia doesn't see any value to .changes, if a debdiff or diff.gz is available
[23:44] <soren> It makes for good practice for coming MOTU's.
[23:44] <persia> How?
[23:45] <soren> If they're used to providing .changes+dsc+diff, then the upload process will not be as alien to them, when they get upload rights.
[23:45] <soren> It's not so much of an issue anymore with ppa's and all that, though.
[23:45] <persia> The upload process consists of calling dput.  There are lots of places to practice.
[23:45] <persia> Anyway, one typically generates all of that in the process of creating a debdiff.
[23:46] <soren> persia: Yes. Possibly incorrectly.
[23:46] <soren> persia: If I get a .changes file, I review that too. It's especially handy for merges.
[23:46] <persia> soren: I suspect I'm missing something.  Which part concerns you?
[23:46] <persia> Ah.  The -v :)  Yes, that's a good bit.