=== null_vector is now known as brward === brward is now known as null_vector [01:27] Has anybody else noticed the return of normal window open/close effects to Firefox form autocomplete and AwesomeBar, after installing Fx3b5? [01:41] Heya gang [01:43] Heya bddebian [01:43] Hi ScottK2 [02:15] asac: do you know if the window class for the address-bar drop-down completion window thingie changed between ff3 b4 -> b5? [02:15] asac: because now with b5, compiz in Gutsy does this annoying transition-in effect as if it were a full window [02:16] jdong: Aha, so it's not just me. [02:17] It's not just the awesomebar, it's also the suggestions for form entries. [02:18] jdong: i don't think it changed [02:18] its always been a full window :) [02:18] The behaviour has certainly changed within the last 12 hours. [02:19] Fujitsu: confirmed, form suggestion windows do the same [02:19] asac: well something regressed, because this didn't happen with the b4 packages [02:19] asac: whether it's the fault of Firefox or some compiz quirking heuristic is less clear [02:20] 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] jdong: trey downgrading ffox [02:20] 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] As am I. === rzr is now known as rZr [02:23] asac: looks like bug 212600 has been reported [02:23] 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] jdong: mozilla bug 412954 [02:27] 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] thats what landed and looks related [02:28] Let me guess... it broke the Firefox quirk thing in Compiz? [02:28] jdong: maybe try if reverting that patch helps [02:28] maybe ;) [02:29] Fujitsu: before that patch we had: - // treat popups with a parent as top level windows [02:29] gtk_window_set_wmclass(GTK_WINDOW(mShell), "Toplevel", cBrand.get()); [02:29] now everything is: [02:29] gtk_window_set_wmclass(GTK_WINDOW(mShell), "Popup", cBrand.get()); [02:29] with proper hints [02:29] https://bugzilla.mozilla.org/attachment.cgi?id=305729 [02:30] 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] Turning off the workarounds doesn't fix it :( [02:30] Why not make Firefox use GTK properly? Or would that make too much sense? [02:30] Fujitsu: that doesn't make sense [02:30] Fujitsu: they already do it properly [02:31] on a best efford base [02:31] jdong: tweaking the compiz rules [02:31] now everything is vmclass "popup" [02:31] wmclass [02:31] so now firefox is correct [02:33] i added compiz and invalidated firefox task until we know that its firefox [02:33] I think asac is right [02:33] based on comment #27 on the mozilla bugzilla [02:36] jdong: please add that reference to the bug so the compiz people see it [02:36] e.g. link to that comment [02:38] There's a bug on -plugins-main with the patch attached. [02:38] #212600 should probably be marked as a dupe. [02:39] Fujitsu: please ensure that the same info goes to that bug then [02:39] and take care that its milestoned [02:39] i guess that should be fixed for release [02:40] Milestoned, duped, appropriate information moved over to #212542. === null_vec1or is now known as null_vector [02:54] 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] 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] we should do it there for gutsy i guess [02:57] 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] jdong: please base it on the .dev branch [02:58] will do [02:58] should be easy to merge down on every release then [02:59] right [02:59] .dev will become .hardy once that is stable [02:59] (released) [02:59] but will be just a rename i guess [03:03] ok scrapbook is done [03:06] oops wrong channel :) [03:11] :) [03:11] asac: mmmkay, pushed up backports changes rebased against .dev to LP :) [03:18] cool [03:18] rebased? [03:18] using bzr rebase? [03:18] jdong: ? [03:18] heya people :) [03:19] asac: nah I didn't go that fancy, I just lumped it all up into one commit [03:19] ;) [03:19] asac: some embarassing mistakes best not see the light of day ;-) [03:19] yeah [03:19] i know what you mean [03:20] 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] 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] what was the problem with ffox? [03:24] we try to be as cooperative as possible. if there are glitches, we want to know about that ;) [03:24] suggestions welcome :) [03:27] 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] asac: not your fault in any way :) [03:28] is there a command to invert a patch or do I have to patch -R then diff? [03:29] jdong: you can drop the patch from series? [03:29] or do you mean something else? [03:29] asac: well I'm referring to the firefox window toolbar patch from bugzilla [03:30] hmm [03:31] nvm I'll just hand-do it. The inverse of that patch is more intrusive than necessary to restore old behavior anyway [03:31] maybe flipdiff using an empty patch as second argument :) [03:31] great [03:32] but I do like the creativity of that approach :D [03:32] should be simple to do when using quilt ;) [03:32] yay, I love quilt..... ;-) [03:32] welcome ;) [03:43] grr *whine* this code is in xulrunner? === kitterma is now known as ScottK2 [04:44] can anyone offer me some advice regarding a broken translation? [04:50] hello [04:52] ashes_of_youth: I'd suggest ask in #ubuntu-doc [05:13] ScottK2: Hello, I just made another upload: http://revu.tauware.de/details.py?package=ubuntume-themes [05:14] AnAnt: Looking [05:15] ScottK2: btw, I see usplash theme is on Ubuntu's repos now ! Thanks! [05:16] AnAnt: You're welcome. [05:19] AnAnt: Is the bug this fixes reported in Launchpad? [05:20] nope [05:20] that's why there isn't a Closes: # in changelog [05:20] OK. Just checking. [05:20] Also there are other changes you made that need to be documented. [05:21] moving x11-apps to Build-Depends-Indep: ? [05:21] Yes and the changes in the package description. [05:21] Ok, didn't know that they were worth mentioning [05:22] After the initial upload they all need to be mentioned. [05:22] People need to be able to recontruct from the changelog not only what was done, but why (if it's not obvious). [05:23] AnAnt: If you would re-upload to REVU with a more verbose changelog, then I think I could upload it. [05:24] so I should mention why I changed long description ? [05:24] For that it's enough to say minor edits in the package description. [05:29] uploaded [05:30] AnAnt: OK. There's a cron job that needs to run that goes on a ten minute periodic before I see it. [05:30] ok, rebooting [05:35] 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] ScottK2: did you have a chance to look at the ff3 backport yet? [05:37] ScottK2: ok, it appears on REVU now [05:39] AnAnt: Looking [05:44] * jdong does some backports triaging [05:45] AnAnt: Uploaded [05:50] ScottK2: thanks [05:51] AnAnt: Thank you for making the extra effort to work through the official archives. [05:51] jdong: I'm looking at it now. [05:51] ScottK2: thanks :) [05:52] jdong: What xulrunner am I supposed to backport? [05:53] ScottK2: this one: http://jdong.mit.edu/~jdong/motu/ff-backport/beta4/xulrunner-1.9_1.9~b4+nobinonly-0ubuntu1~gutsy1.dsc [05:53] and corresponding firefox: http://jdong.mit.edu/~jdong/motu/ff-backport/beta4/firefox-3.0_3.0~b4+nobinonly-0ubuntu1~gutsy1.dsc [05:53] Figured out the problem. [05:53] I have the wrong xulrunner. [05:54] ah [05:54] I had xulrunner, not xulrunner-1.9 [05:54] yeah, that'll do it :) [05:54] that's extreme backporting! :) [06:00] jdong: Should we mangle the maintainer? [06:00] Nevermind [06:02] ScottK2: I don't think it'd be necessary. Plus, spamming asac with bug reports might be fun ;-) === asac_ is now known as asac [06:02] Yeah. [06:03] jdong: You've tested these are all good and I'm just your mule on this. Right? [06:03] ScottK2: yes, it's all tested for several weeks and known good :) [06:03] OK. [06:04] ScottK2: we can play this game with beta5 again in around two weeks :D [06:08] jdong: Uploaded. If you'd please do that Launchpad update. [06:09] ScottK2: awesome [06:09] jdong: Now how about wine? [06:09] Is the current version good to go back? [06:10] ScottK2: I've been running 0.9.57, not 0.9.58, but that's on my TODO list to look at [06:10] for tonight [06:10] Great. [06:10] 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] stupid Debian question, does Debian keep old revisions of their packages somewhere? [06:28] snapshot.debian.net [06:34] thanks! [06:34] it would also help if I look for the patch in the right version of the package :D === neversfelde_ is now known as neversfelde [10:20] G'morning. === YokoZa1 is now known as YokoZar === Frogzoo_ is now known as frogzoo [14:15] siretart: I don't know if you have seen this: http://patches.ubuntu.com/b/boxbackup/boxbackup_0.10+really0.10-1ubuntu3.patch === Frogzoo_ is now known as frogzoo [14:26] Dear jdong: Please have a look at Bug #211910 and let us know what you think. [14:26] Launchpad bug 211910 in rtorrent "[FFe] request for new upstream version " [Wishlist,New] https://launchpad.net/bugs/211910 [14:28] jdong: Shouldn't the wine bug for gutsy-backports be set to In Progress? === hefe_bia_ is now known as hefe_bia [14:43] ScottK2: If you have time today, could you look at Bug 212301 and sponsor an upload? [14:43] Launchpad bug 212301 in glom "Please update glom to newest version (1.6.13)" [Undecided,New] https://launchpad.net/bugs/212301 [15:32] ScottK2: ping [15:33] 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] james_w: I finally got round to emailing the ML ;) [15:43] Laney: ah, thanks. [15:43] No probs. I suddenly realised on the way back from campus that I'd not done it yet [15:50] james_w: oh, no thanks for the hint! [15:50] err, insert a '.' at the appropriate place :) [15:55] :-) [15:55] siretart: you don't want a bug with the patch in Debian? [15:57] ScottK2: nevermind. Looks like RainCT_ is taking a look. === RainCT_ is now known as RainCT === ember_ is now known as ember [16:17] 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] s/sb end [16:22] 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] jdong: Please mark it in the bug. [16:29] Hobbsee: Pong: I don't think anything. [16:29] ScottK2: good, OK [16:30] RainCT: thanks for sponsoring glom [16:30] protonchris: no problem, thanks for working on it :) [16:31] 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] RainCT: ah thanks. Yeah I was waiting. I wanted to see the additional changes you added. [16:32] RainCT: any advice? [16:32] protonchris: It's better to have someone sponsoring you that does not, on a grumpy day, consider breaking Gnome a feature. [16:32] ScottK2: LOL. Good to know. === Nightrose2 is now known as Nightrose [16:33] Actually it's mostly just Mono I consider breaking a feature, but the two go together just a little. [16:36] 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] RainCT: great thanks. [16:37] ScottK2: heh, what happened? [16:37] RainCT: Nothing, just don't like Mono. [16:37] ah, lol [16:42] * jdong looks at cherrypicking clutchbt.... [16:43] Does anyone know of a good resource on the accepted way to build a single source package from what are several upstream tarballs? === fta_ is now known as fta [16:48] 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] 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] siretart: sure, I'll file one. [16:58] siretart: I don't use it, I was just looking at the diff. [16:58] siretart: I used to work with one of the developers though. [17:47] jdong: Please say something nice in Bug #211910 and then I'll approve it. [17:47] Launchpad bug 211910 in rtorrent "[FFe] request for new upstream version " [Wishlist,New] https://launchpad.net/bugs/211910 [17:47] ScottK2: I thought I already was quoted in that? [17:48] jdong: You were, but I'd like to have a "No, really, we want this" that comes after the last comment. [17:49] ScottK2: ok :) [17:49] Thanks [17:50] ScottK2: done :) [17:50] Thanks [17:55] jdong: Approved, so some motu might want to look at sponsoring the changes ... [17:56] ooh I haven't hit the upload button in a while :) [17:56] 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] pochu: Are you worrying after screenlets? [17:58] pochu: It looks like it needs some grabbing of patches from the upstream bzr. [17:59] ScottK2: I feel blind.... is the debdiff/interdiff/diff.gz even on the bug report? [18:01] jdong: It's not. I had a brain dump about the requestor being a MOTU. I'm sure he'll upload it. [18:01] ah ok [18:01] excellent [18:01] ScottK2: I'm not, and I'm busy... [18:02] OK. [18:02] (and I'm not here) [18:02] jdong: Care at all about screenlets? That needs some uploading by someone who cares about Gnome. [18:02] ScottK2: I don't know what it does, if that says anything :) [18:02] Heh. [18:02] OK. [18:03] jdong: something like dashboard widgets in OS X [18:03] There we go. A volunteer... [18:03] ScottK2: Are you one of the build admins who can promote a package to main? [18:03] slytherin: No. [18:04] Promotions are done via Main Inclusion Report. You can file one. [18:04] ScottK2: No the package is in main for i386 and amd64 already. It is not for powerpc [18:05] slytherin: Ah. You'll want to discuss that with pitti then on Monday probably. [18:05] slytherin: Do you have any interest in screenlets? [18:06] 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] Whats the difference between screenlets and desklets? [18:06] ScottK2: I have just used them once. [18:06] Dunno. I mostly see a lot of bugs being filed and upstream commenting which bzr commit fixes the bug. [18:06] I was hoping someone like slytherin might go through them and pull the patches in. [18:07] ScottK2: Any specific bug? [18:09] slytherin: Bug 197712 Bug 212175 Bug 198675 Bug 195036 Bug 205526 and probably more. [18:09] Launchpad bug 197712 in screenlets "ACPIBatteryScreenlet.py crashed with OSError in __create_tempfile()" [Medium,Confirmed] https://launchpad.net/bugs/197712 [18:09] Launchpad bug 212175 in screenlets "VolumeControlScreenlet.py crashed with IOError in __create_tempfile()" [Undecided,Fix committed] https://launchpad.net/bugs/212175 [18:09] Launchpad bug 198675 in screenlets "SensorsScreenlet.py crashed with TypeError in update()" [Undecided,Fix committed] https://launchpad.net/bugs/198675 [18:09] Launchpad bug 195036 in screenlets "MainMenuScreenlet.py crashed with TypeError in __render_cell()" [Undecided,Fix committed] https://launchpad.net/bugs/195036 [18:09] 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] 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] Bug 106244 [18:10] 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] 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] OK, not sure where to begin with helping [18:11] 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] '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] ScottK: you are wise. very wise [18:13] ScottK2: same message -> you are wise. very wise [18:14] ScottK2: how about we package screenlets 0.1? [18:24] For critical debian bug fixes, is it preferred to try and patch the ubuntu version or sync the new package version? [18:24] protonchris: it depends how much else is changed in the new Debian version. [18:25] if its only the bug fix then sync, otherwise it is your call. [18:27] 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] protonchris: sure [18:28] Thanks. I wanted to make sure I wouldn't be overstepping my bounds. [18:42] sebner? [18:42] mok0: yes? [18:43] I was just wondering: [18:44] you filed a whole bunch of sync requests. Have you cleared it with the release team? [18:45] mok0: these are normal syncs and we have the 6th april. so I don't need a release team!? [18:45] *the [18:45] sebner: not if there are no new features [18:45] mok0: there are now features ;) I checked it. But you are invited to check and give an ACK ;) [18:46] *no new feautres [18:46] *feature -.- [18:46] sebner: ah :-) [18:46] sebner: I am not in the release team though [18:46] mok0: MOTU ACK is enough ;) [18:47] sebner: he, yes, I can assign them to the archive admin [18:47] mok0: please check it before ;) [18:47] mok0: doesn't seem to are familiar with u-u-s? [18:48] sebner: not really :-) [18:48] ^^ [18:49] 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] sebner: I will go through some of them, going for dinner soon [18:49] mok0: thanks so much :) [18:49] sebner: right [18:50] sebner: are those bugs from the rcbugs page? [18:50] mok0: about 90% [18:50] sebner: great [18:50] :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] Check and make sure neither are in Debian already or have Debian ITP bugs indicating someone else is already working on them. [19:14] ^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] mok0: your comments are unusual and interesting. rock on :D [19:17] sebner: unusual? [19:17] :) [19:18] 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] *write -.- [19:18] sebner: Perhaps I will get sloppier with time [19:19] mok0: would be a pitty :) [19:20] :-D [19:20] Dinner!!! [19:20] 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] hi people [20:04] StevenK, ping [20:09] hey cody-somerville :) [20:10] Heya emgent :) [20:40] 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] ! packaging [20:41] 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] JohnPinWa: or if you want to chase bugs: https://wiki.ubuntu.com/Bugs/HowToFix [20:44] and ... ! bugs [20:44] !bugs [20:44] 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] 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] 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] JohnPinWa: another task is triaging bugs, i.e. see if you can reproduce them, and supply additional information to the bug report [20:46] 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] 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] JohnPinWa: https://edge.launchpad.net/+about will give you an idea of what launchpad is and what it can do. [20:49] For the record: It's me that's ignorant of launchpad. Wasn't saying launchpad was the problem. [20:49] I'll take a look Iulian. [20:49] JohnPinWa: I have a few PHP tasks for Brainstorm if you want... [20:50] ... but est. 90% of users only use the "Bugs" feature, or perhaps ask and/or answer questions in "Answers" [20:50] 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] too bad :) [20:51] nand: i'm curious, what are those tasks? [20:51] JohnPinWa: You mean you know Python, bash, etc., but not PHP? [20:52] Yep. PHP just looked ugly. Never got interested. [20:52] RainCT: one of those: http://www.ndeschildre.net/brainstorm-todo-list/ [20:52] Dang near as bad as perl. [20:53] 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] that's quite a lot of tasks, from easy to hard ones [20:55] 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] JohnPinWa: It has been settled mostly [20:58] 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] 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] mok0: Well I can see that makes sense from both points of view. [21:00] 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] Hi all! === Allan_ is now known as Hit3k === ^linux26_ is now known as ^linux2 [21:16] 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] 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] RainCT: I'll look that up, thanks === rzr is now known as rZr [22:02] haha, jdong's lazy crack of the day: cached rmadison dependency checker [22:02] a python script using a sqlite-cached rmadison backend to parse build-deps and check em against various Ubuntu distros [22:02] for those extra lazy and impatient backporting days :D [22:13] 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] It's an autotools/libtool package. Any suggestions? [22:22] null_vector: you can ignore those errors [22:23] null_vector: they appear when you build shared libraries [22:27] I'm splitting the package into lib / executable packages though and getting those warnings for the executables though [22:27] That was almost a coherent sentence. [22:36] null_vector: you can safely ignore them [22:44] thanks [22:49] good night [23:01] 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] 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] 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] JohnPinWa: What bug? [23:08] On this website: https://launchpad.net/%7Ebugsquad/+mentoring [23:09] 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] JohnPinWa: For bugsquad-mentored bugs, you likely want #ubuntu-bugs, as the process is a little different. [23:10] I've joined mailing lists as well. Perhaps I should give a shout out there? [23:10] JohnPinWa: For those, I'd recommend asking for help with the bug in IRC. [23:10] Yeah, I asked there a while back. No response. [23:10] Actually I need to go, so hopefully someone else will help you out. [23:10] Persia: thanks. [23:10] ScottK2: thanks. [23:11] JohnPinWa: Maybe just a bad time of day :( [23:11] yeah. Or I'm spectacularly dense. Not an option I ever dismiss lightly. [23:12] 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] JohnPinWa: I don't think so. Is there a bug you would particularly like to work on? [23:15] 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] 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] 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] Just a quick procedure question: how do I upload a package that someone else has signed off in debian/changelog [23:33] should I just sign the changes file? [23:34] ... or specify my own keyid [23:34] mok0: debuild -S -k [23:35] or just debsign -k existing_source.changes [23:35] But you should be building the .changes yourself anyway, so the former should be easier. [23:35] Fujitsu: thx! No "-sa" switch? [23:35] -sa if you need it. [23:36] But that shouldn't be needed much, particularly now we're well past FF. [23:36] Fujitsu: which is.. when the tar.gz is already in the archive? [23:36] -sa is when the .tar.gz isn't in the archive. [23:36] It doesn't hurt to upload it again, but it's a waste of time. [23:36] Fujitsu: got it, thx [23:38] Fujitsu: Why should he be building the .changes himself? [23:39] mok0: In the case where the package has multiple new changelog entries (e.g. merges), don't forget the -v to debuild. [23:39] persia: ok, but this one doesn't. [23:40] soren: because I need to upload a diff.gz also [23:40] soren: Verification and review? The typical sponsoring model is to receive a debdiff, apply it, and build the .changes. [23:40] If someone has provided you with a .changes file, they will also have provided you with a diff.gz. [23:41] 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] soren: I got a debdiff from LP; I want to build and upload the source package [23:41] I think that's a good workflow. [23:41] mok0: Ok, got it. [23:42] It's a lot easier to review the debdiff than review the debdiff, .dsc and .changes. [23:42] 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] As neither of the last two are trustworthy. [23:43] 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]