[00:12] does debian/compat not support versions like 5.0.38, only numbers like 5? [00:12] binarymutant, it just takes the whole number [00:12] thanks :) [00:14] No, it does support 5.0.38 [00:14] Once can do "debhelper (>=5.0.38)" and expect it to work. [00:14] s/Once/One/ [00:15] * persia runs out of time, and will process more applications later. [00:16] thanks persia for catching that :) I found the info on http://wiki.debian.org/DebianPython/NewPolicy [00:22] kickass, i made boycottnovell front page [00:22] directhex: Is that 'kickass' as in 'I can no longer live'? [00:24] directhex, which post? [00:24] wgrant, no, as in "i am filled with delight at being considered enough of a threat to truth and freedom by some guy who pushes a non-free maths package to warrant a frontpage mention on his blog of lies" [00:24] binarymutant, http://boycottnovell.com/2008/11/15/monument-of-mono/ [00:24] directhex: Hahaha. [00:25] watching the rms answer right now [00:25] wgrant, i'm trying to decide whether to comment on his heavily moderated comments or not [00:26] actually, this is my second time. the first was after i submitted my moonlight ITP [00:27] ( http://boycottnovell.com/2008/10/07/microsoft-influence-in-novell/ ) [00:27] I only know of 1 app that uses mono anyways... [00:28] binarymutant, two in the base ubuntu-desktop install. tomboy && f-spot [00:28] binarymutant, some others which seem popular, e.g. gnome-do and banshee [00:28] didn't know f-spot used it too, but I don't use it [00:28] I do like tomboy though :) [00:29] :o HATER OF FREEDOM! [00:29] lols [00:30] this doesn't have anything to do with Greg Kroah-Hartman's keynote does it, directhex [00:30] not specifically, no [00:31] * hyperair used to use tomboy, but it took up precious panel space so scrapped it [00:32] Has everybody read http://www.happyassassin.net/2008/10/28/why-i-dont-like-canonical/? [00:35] skim-read and paraphrased. that's even better these days [00:36] idk, Mandrake killed itself imho [00:36] wgrant, It reads like a rant about he doesn't like the fact Ubuntu has exceled past other distor's (especially mandrake) in an "unfair" manner. [00:37] csilk: Yes... [00:37] just been outside, my fingers are so cold i cant even fell the keyboard never mind type -_- [00:37] Yeah, he's just hating on Shuttleworth for being rich and providing an obscene amount of cash. [00:39] it's an anti-FLOSS rant [00:40] Third comment down sums up my opinion, I'd of included more profanity though [00:40] binarymutant, mandrake indeed committed seppuku [00:41] directhex, yeah I used to love them before they merged with that other company [00:41] binarymutant, connectiva, was it? [00:41] something like that [00:42] I wonder if drakconf is called drivaconf now [00:42] i dunno. i was never happy with mandrake as a distro [00:42] it was a great newbie distro at the time, mandrake 9 [00:46] i never really got into Linux until around 2001, 2002. it was hard to justify given how much better BeOS was as an 'alternative OS' [00:47] never touched beos, have you used the new one? I forgot what it's called [00:48] haiku [00:55] nah. haiku is still working on being where beos was a decade ago [00:55] which is a shame. beos had a lot of plus points [00:55] the 10 second boot times, the never-dropping-a-frame-under-load media abilities [00:55] the simple ui [00:55] lots [01:17] directhex, d00d what about 5-sec boot w/ linux? [01:18] binarymutant, this was out of the box, not via massive hax [01:18] that's pretty cool, only x86 arch? [01:23] very cool, I'll have to check it out later thanks for the info directhex [01:23] binarymutant, beos was ppc and x86 [02:06] what's the difference between AC_CONFIG_FILES([files]) followed by AC_OUTPUT and just AC_OUTPUT([files])? [04:28] if anyone has any time on their hands I would appreciate some critiques of my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :) [05:36] Hey guys, if anyone has a chance to see what we need to do to get this fix uploaded, I'd appreciate it: https://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/272316 [05:36] Launchpad bug 272316 in libgnomecanvas "[regression, intrepid] redraw problems, patches from fedora" [Low,Confirmed] === gouki_ is now known as gouki [09:46] fta: are you working on amsn merge? [10:00] If anybody is willing to comment, I'm online to reply to http://revu.ubuntuwire.com/details.py?package=metalink . Thanks in advance! [10:10] bmm, you reference a non-existant manpage in metalink.manpages [10:13] NCommander: ok, I'm looking into that... thanks! [10:14] From first glance it seems ok, but ATM I'm just waking up, so I'll do a more indept review later [10:14] NCommander: np [10:15] NCommander: the mapage is generated by the build rule (see grep sgml rules ) [10:15] Oh [10:15] I didn't catch that [10:16] Happens if you are just waking up ;) [10:16] Good morning btw [10:16] Thanks [10:16] Well, at first glance, nothing is jumping out at me [10:16] good morning. I am trying to help with getting OOo3 into good shape for ubuntu. I use my PPA to compile it. calc has already done it for Intrepid and now I want to see if it can be done for hardy [10:17] bmm, it's an extreme nitpick, but I would put a linebreak in the control file, between the two seperate paragraphs [10:18] There are a number of build-time deps that need to be backported to hardy. What I did so far is an iteration of "prepare sources, upload, wait for dependency error, backport, retry". Isn't there a faster way to check for build-time dependencies that cannot be satisfied? [10:18] NCommander: done, I've added "\n .\n" between the two paragraphs. [10:19] Laibsch: pbuilder might be faster? [10:19] no, thats not how you do it [10:19] bmm, here, let me post how [10:19] bmm: You mean pbuilder locally? [10:20] bmm, http://pastebin.ca/1257537 [10:20] Laibsch: yes. But I'm a still a beginner :) [10:20] In the description, to do a linespace, its a space, then a period [10:20] NCommander: haha, that's what I meant: a return, a space, a dot and another return :D [10:20] bmm: There is a problem with the number of packages I already backported. I don't think they will be considered by the build. [10:20] Ah [10:21] bmm: plus, I am afraid, the build will likely overwhelm my machine [10:21] it is a very small and old one [10:21] bmm, its just a style thing, but its easier to read in synaptic when its not WALL OF TEXT [10:22] NCommander: I agree, it looks better. If you want me to do the new upload let me know, otherwise I'm going to wait a few minutes so I can collect some more comments. [10:23] bmm, sure, no issue [10:23] Laibsch: you can probably get a list of packages and versions somewhere and check them using "grep", by hand. Or check every package at packages.ubuntu.com (again, by hand) [10:59] I just read https://help.launchpad.net/Packaging/PPA#Using packages from other distributions [10:59] (anchor broken) [11:00] Given an orig.tar, dsc and diff.gz file, what is the fastest way to arrive at a .changes file (which I think is necessary for upload with dput)? [11:02] Laibsch: dpkg-source -x *.dsc then go into the folder and do debuild -s -Sa [11:02] OK, that is basically what I do now [11:02] directhex: you mean you have neighborlee hang around on ubuntu channels now ? (wrt comment on my blog) [11:03] I thought there was something faster, not involving unpacking [11:03] slytherin: I think dpkg-buildpackage instead of debuild is already a bit faster [11:03] Laibsch: never used it. [11:22] persia: there? [11:22] slytherin, partially [11:24] persia: need one advice. As I said I planned to package jmeter. But I am stuck at a point where one commons library needs update. I made update in pkg-java svn and asked for sponsorship. I have not received any response. [11:24] Should I work on this in jaunty then? And later port packages to Debian? [11:24] slytherin, Given the Lenny freeze, you're probably stuck. Toss an Ubuntu revision on REVU, and request a sync when your Debian upload happens. [11:24] hmm [11:25] Were Debian not frozen, that wouldn't be my advice, but it's probably the fastest path right now. [11:25] Use Vcs-* pointing at alioth just to make things clear. [11:26] hmm [11:27] ping DktrKranz [11:27] I will start working with a modified chroot with this updated library. So by the time I finish the jmeter package I hope lenny will be out of door. [11:28] slytherin, That works. Use the alternate plan if you get stuck. [11:29] chrisccoulson, It's *always* better to provide context with a ping. It's often useful to just ask questions in case someone else has an answer. [11:29] no problem;) i wanted to speak about bug 294260 actually [11:30] Launchpad bug 294260 in hwinfo "Please merge hwinfo 15.3-1 (universe) from Debian Unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294260 [11:30] he asked if we needed the ubuntu change, which fixed a FTBFS on i386 [11:30] we still need the change (i just tried it again) [11:30] chrisccoulson, For that sort of thing, best to comment in the bug, verify the status, and make sure the sponsors are subscribed. [11:31] ok, i'll do that. i just thought it might be quicker on here;) [11:31] Can be if it's worth discussing something. [11:32] When you've confirmed a question, and it's clearly ready for upload, it rarely makes a difference. [11:32] thanks [11:32] So, the general rule is, when there's a need for interaction, come here. When it's clear-cut, and just needs processing, the bug is probably better (because it doesn't rely on who is around) [11:33] i'll bear that in mind [11:39] chrisccoulson, pong [11:40] hi [11:40] you've probably seen the conversation above ;) [11:40] oh, hwinfo [11:40] thats the one [11:40] it still fails to build on i386 without the ubuntu change [11:41] "which fixed a FTBFS on i386", I test-built it on amd64, so I overlooked the change [11:41] * DktrKranz fires up i386 pbuilder [11:41] thats ok;) [11:42] thanks for catching up [11:43] persia: your ack needed, bug 298535 [11:43] Launchpad bug 298535 in javassist "Please sync javassist 1:3.8.1-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/298535 [11:45] slytherin, I've a fairly steep queue right now, which is why I answered "partially" earlier. I'll try to hit it in the next 3-4 hours. If I miss, I'll try again later, but you might also want to poke others. [11:45] persia: Oh. No hurry. Take all the time you want. [11:47] NCommander: I've gone ahead and done a new upload with the extra line between the paragraphs. If you found anything else, let me know or post a comment on REVU. Thanks! [11:48] * NCommander nods [12:06] azeem: ping [12:08] hi - will my bug get backported : https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903 or is something not set right [12:08] Launchpad bug 293903 in easycrypt "Candidate revision easycrypt_0.2.3.0-0ubuntu1" [Wishlist,Fix released] [12:26] chrisccoulson: sponsored, thanks (and sorry for the noise) [12:27] thats ok:) thanks [12:44] mok0: pong [12:45] mok0: oh, nevermind, probably [12:45] azeem: yes :-) [12:45] azeem: just sent you an email this very minute [12:51] Hi [12:52] if anyone has any time on their hands I would appreciate some critiques of my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :) [12:53] binarymutant: what is the package about? [12:58] slytherin, its a livejournal client for the terminal/console [12:58] hmm [13:00] why revu doesn't recognize me as MOTU? [13:01] devfil, because the permissions bit is odd. Let me see if I can force it, or if that's still broken. [13:01] devfil, Did you register an email address at REVU? If so, which? [13:02] persia: d.filoni@techemail.com if I remember right [13:05] devfil, I don't think I can do anything, sorry. The alter_user.py file is gone. There's still an alter_user.pyc, but I'm not sure it's going to work cleanly. [13:05] Could a REVU Hacker please explain how to resolve permissions issues for MOTU? This is the second case where I can't fix it, and the first is still unresolved. [13:05] persia: so I can't advocate upload, right? [13:06] devfil, For now. Which package? I'll ack it as a workaround. [13:06] http://revu.ubuntuwire.com/details.py?package=amule-adunanza [13:07] devfil: better ask NCommander or RainCT to fix permissions for you. [13:08] NCommander, RainCT: --^ [13:10] slytherin, No, the REVU Admins *should* be able to do it. Better to ask them to fix the scripts so we can. [13:10] persia: in any case you will need to wake them. :-) [13:12] slytherin, I doubt either are asleep at this hour. A couple of the REVU hackers might be sleeping, but it should be day in both those places. [13:13] how many revu hackers do we have? [13:13] * RainCT reads the log [13:13] persia: thanks [13:13] slytherin, I think five or six. Check LP for details. [13:14] RainCT, Problem is that devfil can't advocate, and alter_user.py has been deleted, so I can't fix it. [13:14] RainCT, As nice as it would be to do proper tracking based on team membership, it would be great if it could be overridden cleanly from the CLI. [13:15] did someone say CLI? [13:15] oh, wait, not THAT CLI [13:16] * RainCT hits directhex with a stinkin fish [13:16] Blah [13:16] RainCT, i'm plotting how to get a boycottnovell hat-trick. i just need to be called out as a destroyer of freedom one more time [13:16] * NCommander smashs directhex with a mono bomb [13:17] is it ok to keep source name same of a package as what upstream tarballs are and name binary package as what is is popularly known? ex. source as jakarta-jmeter and binary as jmeter. [13:17] slytherin, yes! [13:18] slytherin, life is easier for everyone if the source package is called what upstream calls it [13:20] And life is also easier for everyone if the binary package is named what everyone calls it. [13:21] and life would be even easier for everyone if LP redirected from launchpad.net/ubuntu/+source/ to launchpad.net/ubuntu/+source/ :P [13:21] yay for an easy life! [13:23] RainCT, Has that bug been filed yet? [13:23] RainCT, Also, what happens when multiple source packages provide the same binary package (yes, this happens, especially if you're not inspecting versions) [13:24] show a page asking which source package you mean? [13:24] doko, do you still want sole maintainership of ironpython? there's been a new upstream for 3 months, and mandatory changes due to a mono packaging transition are due within a month or two [13:25] directhex: feel free to prepare an upload for jaunty [13:26] well, experimental [13:27] why do you ask in ubuntu-motu? [13:27] because i noticed you were *in* ubuntu-motu, mainly. it's full of interesting people [13:29] making as much of mono as syncable as possible is one of my goals for jaunty, so all work goes into debian first & foremost [14:00] So, who else is a MOTU but hasn't Reviewer status on REVU, beside devfil? [14:01] devfil: you have it now :) [14:01] RainCT: thanks :) [14:02] RainCT, Thank you. [14:06] np :) [14:27] is one of you motus working on a signed backport solution for openoffice3? [14:27] (i would do it but i can't sign) [14:28] * persia wishes that the backports team actually regularly idled in the #ubuntu-backports channel [14:29] how is the debian import process, all the .orig.tar.gzs are imported and the current ubuntu diff is applied ? [14:29] persia: a license header is necessary in every sourcefile right? [14:29] sebner, Not in autogenerated source files, even if it's autogenerated at packaging time rather than build time. [14:29] joaopinto: AFAIK we take all of debian. orig.tar.gz, dsc and diff [14:30] persia: sorry, I mean source files like *.c ... [14:30] s/AFAIK// :) [14:30] joaopinto, No. Packages unchanged from Debian are imported wholesale. Packages changed from Debian are listed as merge candidates. [14:30] sebner, so, I do you keep track of changes that were maded on ubuntu ? [14:30] joaopinto, patches.ubuntu.com does that. [14:30] RainCT: ?! [14:31] persia, what does it do ? [14:31] sebner: that you are right :P [14:31] joaopinto: keep diffs against Debian for all files modified in Ubuntu which have "ubuntuX" in the version name [14:31] joaopinto, Tracks all patches in Ubuntu as compared to Debian. [14:31] RainCT, No, for all packages modified in Ubuntu. [14:32] (and technically, for all packages not modified in Ubuntu, but those are all null, so it's moot) [14:32] rexbron: heh =) [14:32] but, thats from a past import right ? or is it from the current ubuntu dev version ? [14:32] it keep differences for which stage of the process ? [14:33] persia: is it bad when I made all in all 3 comments on REVU? I commented, found something more, commented, found something more .. or should I delete all of them and make 1 big comment? [14:33] joaopinto, It's from each available version. [14:33] RainCT: \o/ [14:33] sebner, Doesn't really matter. I tend to leave big comments. [14:33] persia: wasn't packages with "buildX" showing up there a bug, which was recently fixed? [14:33] persia: kay. /me is still wondering about the qualtiy differences of uploaded packages to REVU [14:34] RainCT, I wouldn't consider that a bug given the diffs I've seen in "buildX", and I don't know if it was "fixed". [14:34] sebner, Hrm? What do you mean? [14:34] how is patches.ubuntu.com used ? You get a new tarball/diff from Debian, it's built, then who checks for patches that were done on the previous ubuntu package and need to be added ? [14:34] persia: I think Debian complained about them showing up on their QA page [14:34] let me check.. [14:35] persia: Well some of the uploaded packages are generally OK, but the one I actually reviewed (very quick review) was in such a bad autogenerated state and FTBFS besides -.- [14:35] RainCT, That's not surprising. Maybe it's just not exported in the same place? I know every diff between every set of versions is ultimately available somewhere in that system. [14:35] sebner, They are intensely variable. Some good, some bad. Depends on the uploader. [14:35] yep [14:36] persia: uhm, I guess that it was about those being listed in the PATCHES file then [14:36] sebner, The point is that we only want good packages, so even MOTU submit packages there. By this system of peer review, only good packages should reach the archive. [14:36] persia: I just did a very quick review, if you are bored you can join if you want ;-D [14:36] basically I am trying to figure, if, by default, packages will come from Debian and may be available for the next release without guarantee that the ubuntu fixes (from the previous release) were applied [14:36] RainCT, That makes more sense to me. [14:36] persia: sure and that's good how it is [14:36] joaopinto, No. [14:36] joaopinto, Well, yes, but that only happens if someone manually decides to drop the diff. [14:37] so, there is an automated process to ensure that ? Where does the packages.ubuntu.com come in play ? [14:37] Nowhere at all. [14:37] persia: OK, it's that bug 195070 (and excluding buildX is mentioned in the comments) [14:37] Launchpad bug 195070 in merge-o-matic "Don't export patches if only the changelog changed" [Undecided,Fix released] https://launchpad.net/bugs/195070 [14:37] It's not generally reliable from a development perspective, although it can sometimes be useful. [14:38] you have, debian-package-a.orig, debian-package-a.diff, when does the ubuntu-package.diff get merged ? [14:38] RainCT, That's MoM, which is (slightly) different than patches. [14:38] joaopinto, Ideally, between archive open and DIF. [14:38] persia: patches.ubuntu.com is created by MoM, iirc [14:39] RainCT, Other way around. MoM relies on patches.ubuntu.com resources as input. [14:39] RainCT: DaD ftw! :P [14:39] is there some flow designed somewhere ? [14:39] !merge [14:39] https://wiki.ubuntu.com/UbuntuDevelopment/Merging [14:39] persia: read the description of bug 188955 [14:39] Launchpad bug 188955 in merge-o-matic "Don't export patches for simple rebuild" [Undecided,Fix released] https://launchpad.net/bugs/188955 [14:42] anyway, /me goes to finish homework [14:42] persia, the merging/syncing description does not describe the description with the debian import [14:42] * persia is baffled and suspects conflation [14:42] is debian import a mass sync ? [14:43] For unchanged packages, yes. [14:44] if anyone has any time on their hands I would appreciate a review of my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :) [14:45] and for changed packages, do they keep unavailable until someone decides if to merge/sync ? [14:46] Not unavailable, but unchanged. [14:47] persia: OK, now I make 1 big comment. I just don't want to make a 4th comment for a missing manpage xD [14:48] so, by default a package which was changed in debian is is synced ? [14:49] If it wasn't changed in Ubuntu. [14:49] Or rather, if Ubuntu has a previous version synced from Debian. [14:50] There are a couple classes of exception, but they really aren't very important. [14:50] (blacklists, rebuilds, etc.) [14:51] but what if the package was changed on ubuntu, who selectes to do the merge or sync ? [14:51] any interested party. For the first few weeks, it's usually left to the last uploader. If they don't do it, someone else usually does it. [14:52] Personally, I think we're about two weeks away from that crossover point, but it's sorta loose, and it might well wait until after UDS. [14:52] meanwhile what is the contents of the archive ? The imported package from debian ? [14:52] The current package in Ubuntu. [14:52] No sync means no upload means no change. [15:00] hi - will my bug get backported : https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903 or is something not set right [15:00] Launchpad bug 293903 in easycrypt "Candidate revision easycrypt_0.2.3.0-0ubuntu1" [Wishlist,Fix released] [15:01] StevenHarperUK: Why have you attached .diff.gz? You should attach debdiff. [15:01] I was told to attach them by a MOUT [15:01] *MOTU [15:02] slytherin: so do I have to make a debdiff now: for the 2 backports? [15:03] StevenHarperUK: If it was told by some MOTU then leave it as it is unless he tells you otherwise. [15:03] ok Ill leave it : otherwise should it get processed [15:06] slytherin: can any motu here process the package for backport or is it a seperate team [15:06] StevenHarperUK: it has to be first evaluated by MOTU SRUteam which is already subscribed to the bug. [15:09] slytherin: Great - ill wait for a message from one of them then: ta [15:10] Err, SRU != backport [15:11] persia: hi - nice to see you, is mine SRU or a backport then : https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903 [15:11] Launchpad bug 293903 in easycrypt "Candidate revision easycrypt_0.2.3.0-0ubuntu1" [Wishlist,Fix released] [15:13] StevenHarperUK, That's debateable. Once it gets into Jaunty, poke the SRU team to answer the question. [15:14] persia: it is in jaunty - how do I poke them [15:14] persia: https://edge.launchpad.net/ubuntu/+source/easycrypt [15:15] StevenHarperUK: ask in the bug and subscribe them [15:16] RainCT: is this the right team? https://bugs.edge.launchpad.net/~motu-sru [15:16] StevenHarperUK: if the package is in universe/multiverse, yes [15:18] RainCT: do I have to set the bug status to anything special [15:18] RainCT: or the assignment of the bug? [15:19] The bug is subscribed to the right parties. Just wait. [15:19] There's a queue, but they'll get to it at some point. [15:19] StevenHarperUK: Don't assign anybody. It may be that the status should be New, but I don't remember for sure.. [15:19] Once you have an SRU ACK or NACK, either subscribe the sponsors team or retarget as a backport. [15:20] persia: sorry I assumed it would be quicker than 1 week that's all [15:20] Status of "Fix Released" is not likely to gain much attention. [15:20] StevenHarperUK, Not enough people are chasing stable updates, so the queue is lagging. Part of it is that the nominations system is a bit broken, which causes confusion. [15:21] persia: I rekon I set it to confirmed? [15:22] StevenHarperUK, That might help. SRU would accept/reject the specific tasks, and maybe mark Jaunty Fix Released if it is. [15:24] persia: ok that's done, Ill wait another week now [15:27] persia: thanks for the help [15:27] RainCT: thanks also [15:27] slytherin: cheers also, also [16:03] persia, asac, yesterday, i discussed with asac about fennec, he asked me why you think fennec should go through revu, it's a mozilla-team package maintained in lp/bzr. why not just reviewing in lp ? === sepheebear is now known as Sepheebear [16:22] fta, Well, as long as it gets two ACKs somewhere publically visible, doesn't really matter. REVU is just the default place for such reviews. [16:34] persia: we should look into how better streamline such initial reviews around launchpad + bzr merges imo [16:34] for instance one could create an empty branch on launchpad and do a merge request ;) [16:38] or just submit a branch in a needs-packaging bug ... and subscribe revu team or something? [17:04] gouki, got a minute to pm me please? [17:09] mok0: btw, are you a Debian Maintainer? [17:40] http://revu.ubuntuwire.com/details.py?package=codelite <-- could someone review this for me please? [17:45] hyperair: your changelog is to large [17:46] hyperair: Initial release (LP: ....) + whay you made changes (pathcsystems) is sufficient [17:46] s/whay/why [17:52] it's annoying that clicking on the .diff links on revu makes my browser want to download that file, rather than to view it [17:58] fta: are you working on amsn merge? [17:59] azeem: do you know how to fix that? I added "AddType plain/text .diff" to mods-enabled/mime.conf but that didn't help [17:59] devfil, not at the moment, i'm on chromium. if you want to do it, feel free [17:59] sorry, no [18:00] azeem: Are you using firefox? [18:00] fta: thank you, how is going the work on chronium? [18:00] nhandler: epiphny [18:00] epiphany* [18:01] azeem: Well, I can't help you then. In firefox, there is an extension called 'Open in Browser'. It allows you to tell the browser to load the .diff file in firefox instead of downloading it [18:01] ah [18:01] sounds useful [18:01] azeem: It is very useful. I use it to view the diffs on Launchpad as well [18:03] azeem: if you know python you can write such an extension for epiphany yourself in like 10 minutes :P [18:03] devfil, so far, there's not much to see. the linux port is still far from ready upstream. i'm working with upstream to improve the build system and make it acceptable for us. [18:04] handschuh: i'm sorry, i don't really get what you mean [18:04] epiphany rocks \o/ (well, it would if it remembered the open tabs when it's closed, had tab restoring with Ctrl+Alt+H and undo for forms like Fx :P) [18:05] hyperair: wait ... [18:05] RainCT: epiphany = gnome stuff = \o/ :P [18:06] GNOME = don't start = \o/ :P [18:06] *doesn't [18:06] RainCT: don't matter if it starts or not. Gome is always \o/ :P [18:06] hyperair: I am also almost done with my review of your package [18:08] hyperair: http://paste.ubuntu.com/73001/ - dont create a new changelogentry on revu [18:26] handschuh: ah thanks [18:30] nhandler: so how's it look? [18:30] hyperair: There are a few things you need to change. I'm building the package now. Then I'll send my comments [18:32] Hey NCommander [18:33] hey nhandler [18:54] nhandler: thanks. i've actually just uploaded a new version. just changes in the changelog, like handschuh said [18:54] hyperair: Well, the package is still building for me. I'll update my comments to apply to the newer version [19:27] RainCT: I hope plain/text is a typo, IMHO it should be text/plain [19:36] nhandler: alright thanks [19:53] handschuh: Congratulations on first package in archive. :-) [19:54] slytherin: thanks! Also for your help [19:54] slytherin: I am preparing the next one right now [19:54] handschuh: will review tomorrow if I get time. Got to go now. [19:55] slytherin: thanks! I will ping you then [19:56] which archive, debian or ubuntu? [19:58] directhex: ubuntu, debian-day is tomorrow [19:59] * sebner winks mok0 =) [19:59] sebner, kinky [19:59] handschuh, well, once you do that, you get your own cool page on qa.debian.org [20:00] directhex: lol :P you don't know the passion of ubuntu/motu :P bad debian guy [20:00] debian guy? man, i'm an outcast wherever i go [20:01] hrhr [20:01] directhex: if I have some qq's about getting the packages into debian, can I directly ask you here? [20:03] handschuh, there are a few people here who can help, not just me [20:03] directhex: ok [20:03] e.g. i think slytherin is a debian person at heart [20:03] directhex: since when? I just have commit access to pkg-java svn. [20:04] directhex: yes, but i need slytherins time to review my packages :-) [20:05] slytherin, close enough [20:05] directhex: nah. I don't plan to become a DD. [20:06] slytherin, nor do i. too much politics [20:06] slytherin, i have convenient svn access to pkg-mono though [20:07] hmm. got to go. office tomorrow. [20:14] superm1: yes, about two years of bug reports and e-mails went into the "80%" selection [20:15] superm1: for jaunty, we shouldn't be worrying about mixer levels in the initscript, which is being overhauled. udev and alsactl init will be taking care of that. [20:28] slomo: yep, text/plain. but doesn't work [20:29] err, sorry, that was for slytherin [20:29] crimsun, can you elaborate more on that? on a codec by codec basis, defaults will be chosen? [20:29] or by a platform by platform basis? [20:45] if i have a bds-licensed package, do i just have to point out to the location at debian/copyright ? === geser_ is now known as geser [21:10] sebner: missed your wink ;-) [21:11] herh [22:01] hyperair: I finally got the package built and submitted my comments [22:05] nhandler: wow that sure took long =p [22:06] nhandler: thanks. i'll go look [22:06] hyperair: Sorry about that. I went out for a bit. [22:06] If I add additional files to the original package - where do I put them? in some special debian dir or under patches? [22:07] What type of files handschuh ? [22:07] nhandler: wah that's a LOT of lintian stuff X_x [22:07] nhandler: it is one build-file [22:07] handschuh: In most cases, you will want to put them in the debian directory. That keeps them separate from the upstream source. It also makes it easy to modify the files in the future [22:08] hyperair: That is one reason I wanted to build the package before sending in my comments. I wanted to include the lintian warnings [22:09] nhandler: well thanks =) [22:09] You're welcome hyperair. Keep up the good work [22:09] nhandler: i'm pretty sure it validated. are you sure it doesn't validate? [22:09] desktop file i mea [22:09] n [22:09] nhandler: but the build-files' location is important - is there a method to automatically put it into the right location if its in the debian dir? [22:09] it didn't validate to begin with, so i patched it [22:10] hyperair: Let me double check. It looked like you were adding an Encoding tag and some other stuff [22:10] oh whoops [22:10] yeah i just ran it by again [22:10] :) [22:11] alright now it validates [22:11] next step... [22:12] nhandler: I got it, thanks :-) [22:13] nhandler: regarding executable-not-elf-or-script, what should i do? chmod everything in binary-install or something? [22:13] hyperair: What file is that for? [22:13] nhandler: lintian errors [22:13] warnings i mean [22:13] Yeah, but what file caused that warning? [22:13] Oh yeah, most of those shouldn't be +x [22:15] nhandler: so it's a bunch of chmods then? [22:15] Yeah, most likely [22:15] nhandler: what's "script-with-language-extension"? [22:16] It doesn't like that you have a .sh extension for a script in /usr/bin. [22:16] nhandler: can i simply add the file if I put the diff into debian/patches? [22:17] What does the diff do? Create the file? If so, then there is nothing to add [22:17] nhandler: the diff creates the file [22:18] nhandler: there is nothing to add? [22:18] Right [22:18] The diff will take care of adding the file [22:18] nhandler: ok, great [22:24] nhandler: so should i do some agressive patching? or are some lintian warnings worth ignoring? [22:25] hyperair: lintian has to be clean [22:26] handschuh: so.... aggressive patching then? [22:27] hyperair: yes :-/ [22:28] i think i'll go bug the upstream developer again [22:28] it's hard to patch non-autotools stuff [22:28] hyperair: that seems to be the best way. But it is always usefull to be in contact with upstream [22:29] yeah [22:29] nhandler: have you the time for a fast review at http://revu.ubuntuwire.com/details.py?package=uiflite (the package is very small and basic) [22:30] handschuh: I'll look it over in a minute. I just need to finish up a merge I'm working on [22:30] nhandler: take your time! there is no need to hurry [22:38] handschuh: Did I ever tell you how much I appreciate building these java packages ;) openjdk-6-jre-headless is 25 MB! [22:39] nhandler: I don't like java, guess why :P [22:40] nhandler: :-) sry about that [22:40] handschuh: Don't worry about it. As long as the package eventually gets into the repositories, I'm fine [22:40] :-) [22:50] handschuh: I didn't find much wrong with the package. Nice job [22:50] nhandler: thanks!! [22:50] You're welcome handschuh [22:53] nhandler: you wrote "much" ... so you did find something wrong? [22:53] nhandler: a now i see [22:54] See what I mean handschuh? There were only minor issues. Nothing serious [22:54] nhandler: yes, thanks. I just refreshed the page :-) [23:11] Anybody have an answer for https://answers.launchpad.net/soyuz/+question/51583 ? [23:12] I'm supposed to be able to upload unchanged sources to the PPA, but I don't see how that can be done since I usually don't have the GPG key for the latest entry in the changelog. [23:12] Laibsch: You don't have to sign with the changelog's key. [23:13] OK [23:13] I know about -uc -us [23:13] But I don't think that is what you mean [23:13] Laibsch: The '-k' option to dpkg-buildpackage/debuild allows you to use your own keyid, or you can debsign. [23:13] * Laibsch studies man page [23:13] Oh, I see [23:13] Thanks [23:13] * RAOF has never signed anything with debsign, though. [23:14] RAOF: Are you OK that I upload this chatlog as answer to answers.LP? [23:14] Yeah? That's OK with me. [23:14] Nice [23:19] debsign is useful. [23:20] * Hobbsee suspect it's the signing part in dpkg-buildpackage, though [23:22] if anyone has any time on their hands I would appreciate a review of my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :) [23:26] binarymutant: have you ever looked at cdbs? [23:27] binarymutant: it could shorten your rules-file a lot [23:27] handschuh, I have looked at it but thought that my rules file was already pretty short [23:31] binarymutant: lots of hyphen fixes needed in manpage [23:31] mok0, what do you mean/ [23:32] My my! grub2's picked up a fair few patches in Debian. [23:33] binarymutant: in nroff files, options need to be escaped like this: \- [23:34] binarymutant: you know how to do patches? [23:34] patch -p1 ? [23:34] binarymutant: uhm, yes, but I mean how to use patches in packaging [23:35] mok0, so should I ditch upstream's man page and create my own? [23:35] I've never used dpatch [23:36] binarymutant: perhaps now is a good time to learn? [23:37] binarymutant: you don't ditch upstream manpage, you just patch it [23:38] binarymutant: so it gets fixed when the package is built [23:39] ok thats cool [23:39] should I send the patch back upstream? [23:39] binarymutant: if you want to be a good citizen :-) [23:40] mok0: time for a short review? : http://revu.ubuntuwire.com/details.py?package=uiflite :-) [23:40] handschuh: I'm looking at binarymutant's package right now [23:40] mok0: a ok sry [23:40] mok0, I do, I like this app [23:40] np [23:41] binarymutant: can you receive files via DCC? [23:41] mok0, uh no, can you email me? [23:42] binarymutant: pm me your email address === gouki_ is now known as gouki [23:55] Oh dear. Throttled internet is now! [23:56] RAOF_: oh? why? === RAOF_ is now known as RAOF__ === RAOF__ is now known as RAOF_298 [23:57] Hobbsee: Care of profligate downloading. [23:57] RAOF_298: oh. right. [23:57] on the 17th. nasty. [23:58] The anniversary is on the... 24th, I think. [23:58] * RAOF_298 wonders quite how he downloaded so much. [23:58] handschuh: looks good [23:59] Nothing says "fun" quite like pbuilder at 4000B/sec [23:59] mok0: thanks. it seems that i learned a lot this weekend :-) [23:59] handschuh: I can't test the package [23:59] handschuh: yes you did [23:59] RAOF_298: lucky you! [23:59] * ajmitch quickly checks to see how much he's used