[00:00] gouki: did you follow the recipes? [00:00] Packaging something from scratch is generally considered to be "advanced". Have you considered working on some bugfixes at first? [00:01] pangloss, yeah, pretty much. When I was able to do actually do something that worked, I bumped into a license problem, and ended up going back to 0 :) [00:01] Anyway, here's the list of my personal open needs-packaging bugs : https://bugs.launchpad.net/ubuntu/+bugs?field.bug_reporter=persia&field.tag=needs-packaging [00:02] Feel free to take one of those if you want an example to learn packaging, and if you don't want to maintain it, that's fine. [00:02] persia: thank you =) [00:03] pangloss, No, thank you. Those are toys I'd like to play with, but haven't actually gotten around to packaging. ingen is probably the most interesting, as there are a couple dupes to the bug report, and it means we get to drop the obsolete om. [00:03] If you package them, I get new toys and an opportunity to drop cruft :) [00:04] :) [00:06] persia, the entire output is here: http://paste.ubuntu.com/69053 [00:06] This would help me fix the typing game error I'm also having. [00:06] Since the error is the same, on both packages (and the game is actually fun :)) [00:08] Hmm, I didn't realise that we had amassed 120000 bugs in less than 11 months. [00:09] Well, LP, not us. [00:09] If you're packaging a game, I'll suggest you come join #debian-games on OFTC. We're a mix of Debian and Ubuntu folk, and just push everything to Debian to reduce the number of revisions. [00:10] persia, sure thing. Let me just tell you that this is text-based game, to practice fast typing :) Not something complex like a FPS :) [00:10] wgrant, A lot of those were Ubuntu, but a decreasing percentage. I'd say we're getting close to a throughput of about 2500 bugs a week. [00:10] gouki, That's OK. Some people claim kanatest isn't even a game. [00:10] persia: 2500.. wow thats great [00:11] is there a way to compare that to non opensource projects bug throughput? [00:11] 2500 is the opposite of great. [00:11] Non-free projects don't often have public bugtrackers. [00:11] And there is no non-free Ubuntu. [00:12] wgrant 2500 is bad for free? [00:12] o.O [00:12] We can't manage 2500 new bugs a week very well. === asac_ is now known as asac [00:12] wgrant, No, 2500 is great. That's bugsquad throughput. That bugsquad needs to attain such numbers is the opposite of great. [00:13] Oh. [00:15] Well, last week wasn't stellar. Only 2109 bugs closed, but it does get over 2500 some weeks. [00:17] Scaling to more incoming reports just needs more eyes, but that's not the real issue. The real issue is the 19321 bugs that are waiting for developer input. [00:17] That number is growing by 150-200 bugs a week, which is where we're really failing to scale. [00:18] (146 for week ending 1st November) [00:20] 19321 are Confirmed? Or New? [00:21] confirmed or triaged and unassigned. [00:21] Ah. [00:21] Mind you, the practice of the Ubuntu Desktop Bugs team of assigning themselves to lots of stuff masks the numbers some, so consider that a lower bound. [00:22] Yes... [00:22] And kernel team to. [00:22] +o [00:22] Yeah, well, I don't mind so much with the kernel team, as it's going to be the kernel team that fixes all of those. [00:23] Whereas with the Ubuntu Desktop Bugs team, I often encounter people who want to fix it, and are working on a patch, but aren't sure how to proceed because the bug is claimed. [00:23] True. [00:23] Right. [00:23] I've never seen a rationale for that policy. [00:23] persia: cant you just reassign the bug to yourself? [00:23] That said, I've seen bugs where members of the Ubuntu Desktop Bugs team pushed patches upstream *three* years ago, and they still aren't available in Ubuntu, which bothers me a bit. [00:23] pangloss, Dunno. Ask the Ubuntu Desktop Bugs team. [00:23] hm [00:23] I consider it impolite to reassign a bug without discussing with the current assignee. [00:24] I think that can be considered a special case where that usually sane rule can be disregarded. [00:26] Well, except that the Desktop team seems to get annoyed if someone pushes a patch to fix some bugs, and would rather that the patches get pushed upstream and accepted upstream, even if that takes several years because upstream is inactive. [00:27] Anyway, it's only about 50-60 packages that are covered by that team, so it's at most a minor irritant. If the bug is frustrating enough, talking to them may permit a patch to be applied. Just assigning oneself may well cause strife. [00:28] Quick question, in debian/control, you only need one Section tag under the Source section of the file, correct? You don't need one in the Source *and* in each Package section [00:30] nhandler, Depends on the package. If all the binary packages belong in the same section, putting it in source is fine. If a couple of the binary packages go in special sections, only add section to those stanzas. If every binary package belongs in a different section, there's not much point to having one in the Source stanza. [00:30] persia: Thanks a lot. I just wanted to verify this before telling someone to change it on REVU [00:31] So, say you're packaging something that produces a library, a development library, a daemon, a couple front-ends, and a plugins package. You'd put the right section in source, and add special sections for the libfoo and libfoo-dev binary packages. [00:32] Wheras something like libjs could probably just have binary sections because each of the binary packages belongs in a different section. [00:32] RAOF: got my first attempt at merging miro up at https://bugs.edge.launchpad.net/ubuntu/+source/miro/+bug/294459 :) [00:32] Launchpad bug 294459 in miro "Please merge miro 1.2.8-1 from Debian unstable" [Undecided,Confirmed] [00:32] s/libjs/libjsw/ [00:33] RAOF: if you wouldn't mind checking it out if you've got some time (no rush), I'd appreciate it [00:35] Yasumoto: Thanks. I noticed it, and it's on my list. This weekend's going to be a bit busy, though ;) [00:36] RAOF: yeah, no worries, I've got to work on stuff for SCaLE and some homework projects, just wanted to check in and let you know [00:38] Yasumoto: it's better if you list the remaining changes instead of the dropped changes in your merge changelog entry [00:39] geser: As I was going through, I didn't find any changes that were remaining, all the conflicts were just version updates [00:39] er.. That's what I should be making note of, right? Things the MoM found issues with? [00:40] Yasumoto: if you look at the Debian->Ubuntu debdiff: everything there is a remaining change [00:40] gouki, Sorry for the delay. I think I found it. You're pushing stuff to $(CURDIR)/bsod-0.1/ and you want to push to $(CURDIR)/bsod [00:41] geser: *doh* [00:41] that would make sense [00:43] geser: I wouldn't relist changelog entries, right? [00:43] Yasumoto, Depending on the changelog entry, that might be the easiest way. If the previous entries are particularly verbose, feel free to tighten up the wording, as long as it remains clear. [00:50] Anyone know how long DaD will be down? [00:50] geser + persia: thanks guys [00:50] I don't think it's a planned outage. Use MoM while you wait. [00:51] persia: Yes it is. It is being upgraded for jaunty [00:54] persia, ohh, thank you for getting back to me! [00:54] persia, I'll change that on rules and see if it works. [00:55] nhandler, Ah, in that case, probably be fixed over the weekend. May as well tackle UEHS, unless you'd rather look at MoM. [00:56] BTW ... Is it recommended to delete commented lines from rules? [00:56] UEHS should now have a working watch wizard and popcon results. [00:57] gouki, The more you can make debian/rules easier to read, the better. [00:57] gouki: depends on whether the comment is useful or not [00:57] persia, hmmm, OK. [00:57] wgrant, Is this new now, or as of ~ 12 hours ago? (It seemed to be working for me then) [00:57] persia: The watch wizard wasn't fully working until a few hours ago. [00:58] Ah. I grabbed a couple watch files, but that would explain the number of errors I saw. [00:58] There are still lots of errors, of course. [00:58] Poor quality debian/copyrights, I presume. [00:59] persia, as for the error, it's weird, since I don't have anything to change in rules that is pointing to $(CURDIR)/bsod-0.1/ [00:59] Does watch wizard understand the machine-readable debian/copyright format yet? [00:59] I don't quite know. [00:59] Was one ever decided on? [01:00] gouki, Compare your debian/rules to the build output. Look for what is being replaced. There's probably a hint somewhere to determine how it generated that, and fix it. [01:00] Decided upon, kinda. Approved, no. [01:00] OK, persia. [01:01] http://wiki.debian.org/Proposals/CopyrightFormat would be the current candidate, which seems to be seeing use in an increasing number of packages. [01:01] i used that one! [01:02] Mind you, few of these would show on UEHS, as we're (mostly) enforcing sanity in REVU, and packages that were updated are unlikely to be orphaned. [01:32] persia, sorry, but .. I've been looking at the rules files and comparing the output from pbuilder, and I can't find anything worth changing :S [01:32] OK. paste debian/rules and debian/control [01:36] persia, they're on REVU: http://revu.ubuntuwire.com/revu1-incoming/banihstypos-0811072139/banihstypos-0.2/debian/ [01:39] Ah, then I want a build log for that :p [01:39] persia, sure thing :) [01:39] uncomment DH_VERBOSE=1 for extra information. [01:44] http://paste.ubuntu.com/69071 [02:06] gouki, My apologies. I keep getting distracted. Could you paste a binary build log? The error isn't shown at 69071 [02:37] persia, no problem whatsoever! [02:37] persia, a binary build log, like the one generated on pbuilder? [02:39] Right. [02:39] The log that shows the build failre. [02:39] Could be pbuilder, sbuild, debuild -b, cowbuilder, PPA, etc. [02:39] On that note, does anyone know if qemubuilder is working properly? [02:40] I paste a pbuilder output a couple of hours ago: http://paste.ubuntu.com/69053/ [02:40] Would that be good? [02:42] These are two separate packages. Hard to compare. [02:43] how do i check what kind of patching I must use for a specific package. I am thinking about changing some paths in the source code [02:43] ? [02:43] persia, my bad! But bsod is also on REVU, let me get you the link [02:43] http://paste.ubuntu.com/69053/ vs. http://revu.ubuntuwire.com/revu1-incoming/banihstypos-0811072139/banihstypos-0.2/debian/rules [02:43] persia, http://revu.ubuntuwire.com/details.py?package=bsod [02:43] Oh, See I actually wanted to look at banihstypos. I'll look at bsod, if you've pushed the same version that generated that log. [02:44] persia, yeah. So: This is the package: http://revu.ubuntuwire.com/details.py?package=bsod and this is the output from the build: http://paste.ubuntu.com/69053/ [02:44] effie_jayx, what-patch might help, from ubuntu-dev-tools [02:44] persia, thanks [02:45] persia, it says "patchless?" [02:46] and I wouldn't be suprised if it is so [02:46] gouki, Ah, I think you want DESTDIR=$(CURDIR)/debian/tmp/ run debuild -b and check. [02:46] persia, sure thing. [02:46] ls [02:46] oops! :S [02:46] effie_jayx, Run lsdiff against the diff.gz. Sometimes what-patch doesn't catch those. [02:47] persia, lsdiff kipina_0.2.2-0ubuntu1.diff.gz gives no output at all [02:48] lsdiff -z [02:48] persia, thank you. I was able to see from the output of debuild -b that dependencies are not being satisfied. I have ncurses-dev on my control, and I'm sure it doesn't require anything else. Do you want me to paste it for you? [02:49] gouki, Remember that the dependencies are typically automatically pulled by pbuilder/sbuild/cowbuilder/etc. [02:49] You need to install them on your local system if you want debuild -b to work. [02:49] persia, ohhh, so let me try that again with the package installed. [02:49] * persia usually does debuild -b in a chroot to avoid cluttering the local system [02:50] persia, I'm running on a VM with a clean snapshot taken. :) [02:51] persia, I can see the files modified by the patch, how can I tell what patch system to use [02:52] effie_jayx, Look at the output of lsdiff. If there's stuff in debian/patches, what-patch is supposed to tell you, and if it doesn't, check debian/README.source, and if that doesn't help, check debian/rules. [02:53] If there's not stuff in debian/patches, and there's stuff outside of debian, it uses patch-in-diff.gz, so just change the stuff you want to change in an editor, and generate a new diff.gz against the orig.tar.gz. [02:54] If there's not stuff in debian/patches and there's nothing outside debian/ you get to choose. In this case, for packages from Debian, I recommend looking at other packages with the same maintainer, and using that patch system. Where that fails, if the package uses CDBS, use simple-patchsys. The rest of the time, use whatever you personally prefer. [02:54] persia, ok. there is no debian patches and there is stuff changed outsude debian [02:54] persia, http://paste.ubuntu.com/69080 is the output of debuild -b [02:56] effie_jayx, Then it's patches-in-diff.gz, so just edit in place, and generate a new diff.gz. [02:56] gouki, That's expected. However, right now you have the broken build-tree to play with. Check for debian/tmp and debian/bsod. See what exists and what doesn't. [02:56] This can help you troubleshoot your rules. [03:01] persia, my debian/bsod is empty. Normal? [03:03] There was a debian/bsod? [03:03] Was there a debian/tmp? [03:03] No, but apparently one was created when I ran debuild -b [03:03] No, there weren't any of those. [03:04] Right, that's why you ran debuild -b : to find out what was being created. [03:04] If it's empty, the upstream build system isn't creating the directory structure properly. [03:04] Add the directories you need to debian/bsod.dirs without the initial / [03:04] Also, you want to make it use /usr/bin, rather than /usr/local/bin [03:05] My mentor told me to delete dirs, since it was only creating know folders. [03:05] *known [03:08] Your mentor obviously didn't actually review just how broken the upstream build system apparently is :) [03:08] Most upstream build systems create the folders they need for installation. [03:08] In these cases, debian/dirs is mostly useless. [03:08] So, having the initial debian/dirs file is OK, with usr/bin in it. [03:08] In the rare case where upstream doesn't do that, you need it (which is why it exists). [03:08] If you need it, yes. [03:09] Always try without debian/dirs first, and only add it if the build breaks because the directory is missing. [03:09] Very well. I'll create the file again and give it another test drive :) [03:09] Oh, OK! Thank you very much persia, really! [03:09] gouki, No problem. Thanks for helping. Now purge bsod and concentrate on a useful package :) [03:10] LOL! OK! :P [03:10] * gouki goes back to his spelling game [03:15] Well, even with usr/bin on debian/dirs, it still fails with the same error :S [03:18] persia, this seems like looking for a nail in a hay stack [03:18] gouki, /tmp/buildd/bsod-0.1/debian/bsod/usr/local/bin': No such file or directory [03:19] gouki, Notice the lack of "/usr/bin" in that. [03:19] If you put /usr/local/bin in debian/dirs, that would make the error go away, but that would be wrong. [03:19] So put /usr/bin there, and find a way to tell the build system to use that instead of /usr/local/bin [03:19] effie_jayx, What? How do you mean? [03:20] persia, I am trying to find in line in the source code where the app loads a xml file from /usr/etc instead of /etc/ [03:21] effie_jayx, strace is the tool you seek. [03:21] ok [03:21] * effie_jayx man's strace [03:22] It shows every system call made by the program, so when you get to the access to /usr/etc you can see waht comes before it, and that can help you understand where in the code it is happening. [03:22] mmkey, very cool tool [03:22] If it's early enough in the output, you can probably step through the code while reading the strace and see every step it takes to get there. [03:23] uff lots of output [03:23] Well, it's *every* syscall :) [03:23] let me send it to a field [03:23] right [03:23] I usually pipe it into a file, and then view the file and search for the bits I want. [03:24] persia, cool [03:25] persia, hehe! Thanks! Found it, and it worked! :) [03:25] ls [03:30] persia, if you have a minute, I believe this is working OK: http://revu.ubuntuwire.com/details.py?package=banihstypos [03:31] gouki, Unfortuntely, I need to head out soon. Maybe someone else could take a look? [03:31] gouki: I'll take a look at it [03:31] nhandler, thank you very much! :) [03:39] persia, very helpfull your tips as usuall... I found my issue. I need to move a file to /home/$user/.kipina and that would be it [03:40] and install file would be good [03:53] nhandler: DaD: universe/multiverse is done, and universe.php is generated. I just launched main; main.php will be generated as soon as it is finished [03:55] also, everyone, note that unfortunately there are still a *lot* of broken merges (the /!\ ones) which seems to be mainly due to snapshot.d.n lacking some packages. in that case we cannot do anything except advising to use MoM. [03:57] anyone could point out a url that might help me get started on writing an install file? [03:57] Thanks a lot Adri2000 for the heads up [03:58] nhandler, just saw your comment. Will work on it right away. [03:59] gouki: I subscribed to the package, so I should get an email when you prepare a new upload. [03:59] nhandler, thank you very much. [04:01] nhandler, about the License ... Do I have to mention the /usr/share/common-licenses/GPL file even when the license used is gplv2? [04:01] Because I have the path to the license: "On Debian systems, the complete text of ..." under the license. [04:02] gouki: I must have skipped over that. [04:02] gouki: You can ignore that comment then [04:03] nhandler, ok. thank you. [04:04] Should I ask on REVU or is here OK? [04:04] About what? [04:04] Now would be about the games warning. [04:05] You can ask here [04:06] Even with this text-only (typing game) it should be installed to usr/games? [04:07] gouki: If you specify a Section of games in debian/control, I believe you are required to install to /usr/games [04:07] nhandler, OK. [04:07] One last thing .. [04:08] The error about the distribution ... [04:09] The first one gouki? [04:09] nhandler, yes, the first one. [04:09] jdong: You can ignore the "bad-ubuntu-distribution-in-changes-file jaunty". That will go away once lintian is updated in Ubuntu [04:09] Your distribution in debian/changelog is correct [04:09] You meant gouki, right? :) [04:10] Yes I did gouki ;) [04:10] Heheh! Sure nhandler, thank you very much. [04:10] Ohhh .. As for the manpage ... [04:11] What about it? [04:11] If the software doesn't come with a manpage ... ? [04:12] gouki: Most applications don't come with manpages. You need to create it. [04:13] nhandler, any pointers on how do I do that? [04:14] gouki: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles#Man%20Pages [04:18] Every time I delete the commented lines in rules, it fails to build the package sources. [04:19] Are you sure you are only removing the commented lines? [04:19] The commented lines are the lines beginning with a # [04:19] nhandler, yes. It happened several times before, and I can't understand why :S [04:19] yes. [04:20] That is really strange gouki. Comments should not affect how the package builds [04:23] nhandler, lintian -i to see a more detailed report, right? [04:23] Yes [04:23] Well, got it down to one error :) the jaunty one [04:25] You can ignore that one, so you are good :) [04:27] Hmm, not really :S [04:27] Fails to build [04:29] I changed what I had (/usr/bin) to usr/games on the makefile. doesn't seem to work very good === nellery_ is now known as nellery [04:31] Maybe I need the dirs file. [04:31] gouki: I'm too tired to think straight any longer. I'm heading off to bed. I'll be glad to help you some more tomorrow if you still need help [04:31] nhandler, ok. Thank you very much for the help. [04:31] You're welcome gouki [04:41] ls [04:44] hmm interesting, ondemand -> performance has significantly cut down on audio blipping on this iMac. [04:44] I thought these modern chips were supposed to transition frequencies fast enough for this not to be an issue. [04:44] perhaps timer/clock skew? [04:50] jdong: Doesn't mjg59 recommend against frequency scaling? [04:51] wgrant: does he really? [04:52] wgrant: I was unaware of that [04:52] wgrant: I've only read him recommending against locking your CPU in the lowest frequency (i.e. 'powersave') as it actually keeps the CPU awake longer, wasting more power [04:52] is revu day going on? [04:52] Right, http://mjg59.livejournal.com/88608.html is my reference. It seems he recommends running in ondemand, actually. [04:53] I haven't read that in a while, so might be a bit forgetful. [04:53] So it seems I was somewhat wrong. [04:54] hello, any one can review my package: iptux, fqterm and llk-linux, thanks [04:57] wgrant: interestingly in battery life tests I've done, ondemand vs performance had little impact. But I can feel right now the latency of those state switches. compiz desk switching is jerky. Sometimes scrolling in FF is jerky. Flash videos have skippy audio on CPU activity. For now, I'll go with performance... [05:00] jdong: What do I poke at to change the governor these days? [05:01] wgrant: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor [05:01] wgrant: if you use GNOME, the frequency scaling applet can do it too [05:01] it's now PolicyKit enabled too [05:02] wgrant: from my testing, removing powernowd using update-rc.d should lock you into performance at startup [05:03] Oh, I didn't know the applet could do anything but view it. [05:04] Aha, I see. [05:04] Convenient. [05:04] Thanks. [05:04] sure thing [05:10] PowerTop likes my batter: [05:10] +y [05:10] Power usage (5 minute ACPI estimate) : 0.1 W (453.8 hours left) [05:11] wgrant: do you have the world's first nuclear powered laptop? :) [05:12] jdong: Of course. [05:13] awesome :) [05:25] HPPA doesn't do nearly as good a job of keeping up when 80% of the packages on FTBFS on that arch. [05:30] ScottK: Hmm, is it really that high now? [05:30] No. It's doing quite well now. [05:31] For most of the latter part of Intrepid it was pretty bad. [05:31] Yes... [05:31] No, now that stuff's building it's way behind. [05:31] Poor ia64 isn't going too quickly this time. [05:31] No. PowerPC is doing well. [05:57] * NCommander wakes up [05:57] Did someone say PowerPC? [05:57] wgrant, we're waiting for at least alpha one before smashing the FTBFS in ports [05:57] Since a good number of failures are just misidentified dep-waits === superm1` is now known as superm1 [06:14] How did lpia finish building everything os fast .... [06:16] It has newish hardware, and a fair bit of stuff likely doesn't build there. [06:17] wgrant, you care about ia64? [06:17] * NCommander notes that lpia has LOADS of build failures :-/ [06:44] geser: Heya, may I steal the hnb merge from you? [07:16] * NCommander searches for intelligent conversation [07:28] geser: Anyway, I see bug 245706 which tells us we should sync instead of merge. As far as I can see the package was not tested in Ubuntu (using the Debian patch). I'm not really sure what to do. In the mean time I will test the debian version to see if it works using the Debin patch, if yes then we can sync, if not I will merge it keeping our patch. [07:28] Launchpad bug 245706 in hnb "Please sync hnb 1.9.18-4 (universe) from Debian unstable (main)" [Undecided,Invalid] https://launchpad.net/bugs/245706 [07:29] geser: Any advice would be appreciated. [07:29] Or anyone else. [08:17] directhex, ping [08:21] w [08:21] oops. [08:24] geser: OK, I tested the Debian version and confirmed bug 49618. On the other hand, the modified package (the one with the Ubuntu patch) FTBFS with the following message: http://paste.ubuntu.com/69135/plain/ [08:24] Launchpad bug 49618 in hnb "editing node: cursor stays at end of line" [Undecided,Fix released] https://launchpad.net/bugs/49618 [08:37] iulian: Hi and yes, you can have hnb for merging === ziroday` is now known as ziroday [08:45] geser: Thanks. Any ideas why it FTBFS? I resolved the conflicts by just removing the debian changes from the src/ui_draw.c and src/ui.edit.c files and kept the ubuntu changes. [08:47] geser: I can make a debdiff between the debian .dsc and the modified one to convince yourself. [08:49] iulian: but the Debian package builds? [08:50] the current Debian package uses quilt for patch management while the current Ubuntu delta is applied directly, so a first step would be to convert it into a quilt patch (perhaps it also solves your FTBFS problem this way) [08:51] geser: Yes, I tested the Debian package and it builds fine. [08:52] s/builds/built [08:53] OK, I'll see what I can do, thanks. [09:40] geser: I've no idea how to fix it. It seems that there are two different bugs regarding the position of the cursor. I will just leave the merge to someone more experienced than me. [09:41] gouki, Nuked. Thanks for asking. [09:42] iulian: no problem [10:00] wow [10:00] * NCommander just learned that Debian's spiral isn't the complete official logo [10:02] * jpds throws his http://www.amazon.co.uk/dp/1593270690/ in NCommander's direction. [10:03] * NCommander recongizes names on the review page [10:04] jpds, as an aside, that ain't the official logo either [10:05] NCommander: The book has a section on the logo. [10:05] it does? [10:05] Yeah, among a bunch of other things. [10:06] ok, care to sum up why the official logo isn't used any mor? [10:08] NCommander: http://www.debian.org/logos/ ? [10:08] yup [10:08] I've never seen the genie bottlle on before [10:09] Used to be available as a default background, although it's been a while since I ran a default install on a desktop. [10:09] not on edge or lenny [10:09] I don't think it was for sarge either [10:09] (which perhaps demonstrates about how long I've been running an Ubuntu desktop) [10:10] what release was before sarge [10:10] woody? [10:10] Yep. [10:10] woody was the first Debian system I used [10:10] I don't think it was there [10:12] Not the primary one, but in the standard desktop-backgrounds set. [10:12] I think there was a gdm theme with the bottle as well. [10:13] Might still be there, although I've long forgotten the relevant package name. [10:14] oh [10:14] I dunno then [10:16] * NCommander just learned backports.org backports kernels ... [10:19] Given a six-month release cycle, and the number of issues we have every cycle due to API changes, don't let that be an inspiration. [10:22] I didn't say anything ! [10:22] * NCommander is crazy, but not THAT crazy [10:23] pochu, if you have time, mind have a look at bug 260765? [10:23] Launchpad bug 260765 in gst-plugins-base0.10 "DVD playback does not work anymore" [Medium,Fix released] https://launchpad.net/bugs/260765 [10:32] * NCommander glances at the intrepid/hardy bug lists [10:32] hey DktrKranz [10:32] morning NCommander [10:33] but I guess is quite late there [10:33] DktrKranz, yup [10:33] DktrKranz, are you running intrepid? [10:33] no [10:33] jaunty, but I have a VM available [10:33] care to test something? [10:34] In `sudo pbuilder create --debootstrapopts --variant=buildd', how does the 'buildd' option affect the chroot/building process? [10:34] vmware is doing some cleanups, in a half an hour I guess, but sure [10:34] DRebellion, it installs build-essential [10:34] fakeroot, and devscripts I think [10:35] DktrKranz, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/mtd-utils/+bug/294428 [10:35] Launchpad bug 294428 in mtd-utils "mtd-utils build fail" [Undecided,Fix committed] [10:35] NCommander, that's it? And the normal pbuilder doesn't? [10:35] it doesn't matter [10:35] ok [10:35] NCommander, thanks. [10:35] pbuilder will install fakeroot/build-essential if needed [10:36] NCommander, I'll take it soon [10:37] thanks :-) [10:37] the package built w.o failure [10:37] SO it should just be an ACK [10:38] a verification one === cedric_ is now known as cedricv [11:27] How can I get pbuilder to build, then clean, then build again from the cleaned sources? Does revu-build do this? [11:31] DRebellion: it does that by default? [11:39] Hobbsee, pbuilder or revu-build? [11:40] DRebellion: pbuilder. no idea what revu-build as such does [11:40] oh... [11:40] * DRebellion checks his build logs [11:43] Hobbsee, it doesn't seem to have done that here. [11:43] `sudo pbuilder build --logfile xxx.log xxx.dsc' [11:43] DRebellion: it creates a new chroot, clean and without the build-deps in it, each time. [11:44] Hobbsee, oh, I think you have misunderstood. I want to create the chroot, install the deps, etc. Then build in the chroot, then clean those sources, then build again in the same chroot with the cleaned sources. [11:44] oh, right [11:45] * Hobbsee doesn't think it has a builtin for that. [11:46] Didn't someone add pbuilder --build-twice or something not too long ago? [11:47] Laney, Hobbsee, `man pbuilder': " --twice is for --build option It builds the package twice in a row to check for possible clean issues. It will generate the .deb of the second build." [11:47] that's it [11:47] : ) [11:47] oh, there you are, then. [11:48] excellent [11:48] DRebellion: hugs to nxvl for that feature ;) [11:51] NCommander: I see you updated jedit in jaunty. Do you have any plan to port the package to Debian? [11:52] slytherin, once I'm a DD, and Debian is out of freeze, I plan to move all 0ubuntuX packages I can if possible ;-) [12:00] NCommander: DD, big plans. :P [12:01] sebner, I'm through AM with a +1 from my sponsor [12:02] NCommander: AM? I only know DM [12:03] It means my application manager has +1ed me [12:03] I'm waiting on the buracat parts of the system [12:04] debianization is a loing scary process [12:04] i'm fine with just firing things though a sponsor ;) [12:05] NCommander: O_o I'm impressed even more about you [12:05] directhex: hi btw =) [12:05] sebner, get MOTUship first [12:05] mornin' [12:05] DktrKranz: /me isn't even NM :P [12:05] * NCommander was wondering if I would be a DD before MOTU [12:06] Context: my DD application is eight months old [12:06] NCommander, anu progress so far in your NM? [12:06] you're almost there ;) [12:06] DktrKranz, Final FD approval, DAM approval [12:06] cool [12:06]